Data Retention and Deletion

​

The posture

Graphor retains primary customer data indefinitely until the customer explicitly deletes it. No automatic time-based pruning runs on sources, conversations, or extractions. The customer is the source of truth on retention; Graphor provides the API and UI to act on it. This posture is intentional. Regulated customers (legal, financial, healthcare) typically need to control retention themselves — for example, to align with a case-file matter-management retention schedule, with an audit obligation under CVM or Bacen rules, or with a patient-record retention requirement under CFM resolutions. A platform that prunes on a fixed schedule does not fit those constraints. Three commitments balance this posture against the right to deletion:

1. Every delete propagates end-to-end. When the customer issues a delete, every backing store that holds the data drops it.
2. A customer-callable DSR API satisfies LGPD art. 18 / GDPR art. 17. The customer (or their data subjects, when the customer routes the request) can issue a verifiable deletion request through the API; the response confirms each store that was acted upon.
3. Observability traces have bounded server-side retention (and a tier-aware default-off for enterprise) so that any incidental customer content that survives the masking floor does not accumulate indefinitely.

The rest of this page documents what gets retained, where, for how long, and how to act on it.

​

1. Retention by data category

​

2. The delete cascade

When the customer (or the DSR API) issues a delete on a Source, an end-to-end cascade runs across every store that holds data derived from the Source. The delete is not acknowledged until every step completes successfully — partial failures roll back where possible and surface to the caller. The cascade covers, at minimum:

• Any flow or downstream artifact that referenced the Source (the reference is removed and the downstream artifact is marked as out of date).
• The graph-store representation of the Source and every retrievable unit derived from it (chunks, embeddings, annotations).
• The original document bytes in object storage. After this step there is no recoverable copy.
• Any in-memory or cache entries keyed on the Source identifier.

Conversation deletes follow an analogous cascade across the relational database tables associated with the conversation, plus a call to the Trace DSR API for the corresponding observability traces. Defense in depth — object-storage lifecycle backstop. The object-storage buckets that hold ephemeral artifacts (staging uploads, expired signed-URL targets) carry a lifecycle rule that purges orphaned objects after a short window. This rule does not apply to customer-content paths, which follow the infinite-until-DELETE posture in §Posture — the lifecycle rule exists to clean up orphaned partials, not to enforce retention on Customer Content.

​

3. The DSR API

The Data Subject Request endpoints satisfy LGPD art. 18 (eliminação) and GDPR art. 17 (right to erasure). They are authenticated with a project-admin API token (see Tenant Isolation for the token model). Each endpoint returns a JSON acknowledgement listing every store class that was acted upon. Acknowledgements are persisted for 90 days so the customer can verify the action after the fact. Account-level deletion (delete the user account and every project owned by it) is handled out-of-band via privacy@graphorlm.com until the in-app self-service flow ships.

​

4. Observability traces

Graphor operates a self-hosted observability store in the Graphor production region for application tracing. The full subprocessor characterization is in Subprocessors; the model-use rules are in Model Use and Training. This section covers the retention and deletion posture only. Tier-aware default. Whether your project’s traces reach the observability store depends on the tier:

• Enterprise tier — tracing is off by default. No traces are produced for Enterprise-tier projects unless the project owner explicitly enables tracing in project settings.
• Free and Pro tiers — tracing is on by default with the Brazilian PII mask applied before send.

The mask. When tracing is enabled (Enterprise opt-in or Free/Pro default), every string sent to the observability store passes through a regex-based mask that scrubs email addresses, CPF, CNPJ, BR phone numbers, and OAB registration patterns. The mask is a floor, not a substitute for the tier-aware default: customers with stricter PII concerns should keep tracing off rather than rely on the mask alone. Server-side retention TTL.

• Free/Pro-tier traces: 90 days then automatic purge.
• Enterprise-tier traces (when tracing has been opted in): 30 days then automatic purge.

Customer-controlled deletion. Independent of TTL, the customer can issue ad-hoc trace deletion at any time via the DELETE /api/v1/dsr/traces endpoint. The endpoint covers traces by conversation_id (single conversation) or user_id (all conversations associated with a user). Cascade integration. Deleting a conversation via DELETE /api/v1/conversations/{conversation_id} automatically issues the trace deletion for that conversation — the customer does not need to call the trace endpoint separately for the conversation case. Operational improvement use. Synapse personnel access the observability store for incident debugging only. Customer Content is never extracted from the store for product improvement, model evaluation, or any other secondary purpose. See Model Use and Training §6 for the explicit non-commitments.

​

5. Backups and disaster recovery

Database backups exist solely to enable disaster recovery and are not a primary customer-data surface. The customer cannot read individual backup contents; the backup window exists so that a catastrophic database failure can be recovered without data loss. A customer delete is not undone by a backup restore. A restore from backup that pre-dates a customer delete would re-introduce the deleted data; in that scenario Synapse re-runs the original delete operation against the restored database before opening the restored instance to traffic, so the customer’s deletion intent is preserved across recoveries. This is documented in the Incident Response runbook.

​

6. Billing data

Billing records (payment-processor customer and subscription identifiers, invoice metadata, payment-attempt timing) are retained separately from Customer Content and are subject to Brazilian tax and accounting record-keeping obligations (commonly 5 years from invoice issuance).

• Billing records do not contain Customer Content. No document, no conversation, no prompt, no completion is stored alongside billing records.
• Deleting an account does not delete billing history, because doing so would violate legal record-keeping obligations. Billing history is purged after the statutory retention window elapses.
• The payment processor is the controller-of-record for full payment-card data. Graphor stores only payment metadata (last 4 digits, card brand, billing address). For the payment processor’s own retention practices, see the corresponding entry in Subprocessors §5.

​

7. Customer responsibilities

A few responsibilities sit on the customer side. These are listed here so that nothing surprises an auditor reviewing the end-to-end retention story:

• Export before delete. Once a Source or conversation is deleted, the deletion is final (no object-storage versioning on the customer-content bucket). If you need a portable copy of your data for audit or migration, export it before issuing the delete.
• Token hygiene. Customer-issued API tokens that are leaked, lost, or simply unused are not auto-revoked. Set expires_at on tokens that should not live forever, and revoke unused tokens promptly.
• DSR cascading from your own data subjects. When a data subject of your customer (e.g., a person mentioned in a document you ingested) requests deletion from you under LGPD art. 18, you remain the controller. Graphor provides the DSR API in §3 so you can act on that request inside your project; the actual evaluation of whether the request applies is yours to make.

​

8. Change history

When the retention posture, the TTL, the DSR endpoint inventory, or the backup configuration changes, this table is updated and subscribers to subprocessors@graphorlm.com receive an email.

​

Contact

• General privacy and DSR inquiries: privacy@graphorlm.com
• Subprocessor and retention-policy notifications: subprocessors@graphorlm.com
• Customer support: support@graphorlm.com