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:

Every delete propagates end-to-end. When the customer issues a delete, every backing store that holds the data drops it.
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.
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

Category	Where it lives	Default retention	Deletion mechanism
Source / `file_id` — raw uploaded documents (PDF, DOCX, HTML, audio, video, etc.)	Project-scoped object storage in the Graphor production region (`us-central1`).	Indefinite until explicit deletion.	`DELETE /api/v1/sources/{file_id}` or UI delete. Triggers the cascade in §2 — including removal of the original document from object storage.
Derived Content — partitions, retrievable units, embeddings, document and partition annotations	Graphor’s managed graph store.	Tied to the parent Source (same retention semantics, same delete cascade).	Deleted as part of the Source cascade.
Structured extractions (results from `/data-extraction`)	Graphor’s primary relational database.	Tied to the parent Source.	Deleted as part of the Source cascade.
Conversation / `conversation_id` — chat sessions, messages, summaries, observation records	Graphor’s primary relational database (multiple associated tables).	Indefinite until explicit deletion.	`DELETE /api/v1/conversations/{conversation_id}` (or UI). Cascade covers all associated tables and, for any conversation that produced observability traces, the corresponding traces via the DSR API.
Account Information — user profile, email, organization name, project membership	Graphor’s primary relational database.	Until account deletion.	Account deletion request via privacy@graphorlm.com; Synapse processes account-level deletion within 15 calendar days of request, applying the LGPD art. 19, II confirmation/access timeline by analogy to deletion under art. 18, VI as best practice. An in-app self-service flow is on the roadmap.
API tokens — hashed token records, scope, expiry, last-used timestamp/IP	Graphor’s primary relational database.	Indefinite until the token is revoked or (if `expires_at` is set) expires.	Revoke via UI; expired tokens are rejected at verification time and may be hard-deleted asynchronously.
Observability traces — when tracing is enabled per project (see §4)	Self-hosted observability store in the Graphor production region (`us-central1`).	Enterprise default OFF — no traces produced at all. If the project owner explicitly opts in, Enterprise traces have a 30-day TTL. Free/Pro tiers default ON with a 90-day TTL.	Automatic purge at TTL; customer can issue ad-hoc trace deletion via the DSR API by `conversation_id` or `user_id`.
Billing records — payment-processor customer/subscription identifiers, invoice metadata, payment-attempt logs	Graphor’s primary relational database + the payment processor.	Retained as long as legally required to comply with Brazilian tax and accounting obligations (typically 5 years from invoice issuance).	Customer Content is never stored alongside billing records; deletion of an account does not delete billing history because doing so would violate legal record-keeping obligations.
Operational telemetry — request paths, response codes, latency histograms, error stack traces	Cloud-provider operational log store. Synapse-side application logs and error stack traces (which may incidentally include identifiers) inherit the same store.	30 days for the live log store; identifiers in logs are scrubbed via the same Brazilian PII mask used on observability traces. Logs exported to long-term storage as confirmed incident-investigation evidence are retained until investigation close + 1 year, then deleted.	Telemetry that contains identifiers can be purged on DSR request via privacy@graphorlm.com.
Database backups	Managed by the cloud-provider’s automated backup service.	Per the configured backup retention window (7 days of automated daily backups + point-in-time recovery within that window). Backups are encrypted with cloud-provider-managed keys and are not customer-readable.	Backups follow the configured retention window and roll off automatically; an explicit out-of-cycle delete of backup contents is not exposed because backups exist to support disaster recovery, not as a primary customer-data surface.
Object storage versions	Project-scoped object storage.	Object versioning is disabled on the customer-content bucket — a delete is a hard delete with no recoverable noncurrent version.	n/a (no recoverable previous version exists for deleted source documents).

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 DSR endpoint returns success after the cascade reaches all stores; if a backing store is temporarily unavailable the cascade retries with backoff, and a reconciliation job runs to drive the cascade to convergence. Any persistent failure surfaces in the next DSR query against the same resource. 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).

Endpoint	Purpose	Coverage
`DELETE /api/v1/sources/{file_id}`	Delete a single Source and everything derived from it.	Triggers the full cascade in §2.
`DELETE /api/v1/conversations/{conversation_id}`	Delete a single conversation.	Cascades through the associated relational database tables and the corresponding observability traces (via the trace DSR call).
`DELETE /api/v1/dsr/traces` (body: `{ conversation_id }` or `{ user_id }`)	Bulk-delete observability traces by conversation or by user, without deleting the underlying conversation row.	Useful for trace-only deletion in projects where the customer wants to keep the conversation history but purge the trace surface.
`POST /api/v1/dsr/export` (roadmap)	Bundle the user’s data into an export package (LGPD art. 18 portabilidade).	Roadmap — not yet exposed. Customer can request manual export via privacy@graphorlm.com in the interim.

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. Synapse processes account-level deletion within 15 calendar days of request, applying the LGPD art. 19, II confirmation/access timeline by analogy to deletion under art. 18, VI as best practice. Deletes and in-flight inference. If a customer issues a delete on a Source or conversation while a sources.ask or /data-extraction request is mid-flight against that content, the in-flight request is allowed to complete and its response is discarded; no further request after the delete-acknowledgement uses the deleted content. The zero-retention commitments at AWS Bedrock, OpenAI (ZDR), and Cerebras ensure no provider-side persistence of the in-flight payload.

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.

Property	Value
Backup engine	Cloud-provider automated backup service
Backup retention	7 days of daily backups, automatically rolled off
Point-in-time recovery	Available within the 7-day backup window
Encryption	Cloud-provider-managed keys; backups inherit the encryption posture of the primary database
Customer-readable	No
Out-of-cycle deletion	Not exposed — backups are a disaster-recovery surface, not a retention surface

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 cascade across every restored store before opening the restored environment to traffic, so the customer’s deletion intent is preserved across recoveries. This is documented in the Incident Response runbook. Restore-window tenant isolation. During a restore, the restored instance is provisioned into an isolated network with no public ingress. Access during the restore window is limited to the on-call engineer; every action is audit-logged per the database audit-logging control in Tenant Isolation §6. The restored instance is not opened to customer traffic until reconciliation (including any deletion replay) completes, so per-tenant isolation is preserved end-to-end across the restore.

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.
Payment-processor-side retention persists beyond Synapse-side deletion. When a Synapse account is deleted, the payment-processor customer and subscription records remain in the payment processor’s systems under that processor’s own retention policy (a function of PCI DSS and the processor’s tax-record obligations in its own jurisdictions). Synapse can request payment-processor-side erasure on the customer’s behalf, but the payment processor controls the timeline and scope of that erasure as the controller-of-record for those records.

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

Version	Date	Change
1.0	2026-06-21	Initial publication.

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

​The posture

​1. Retention by data category

​2. The delete cascade

​3. The DSR API

​4. Observability traces

​5. Backups and disaster recovery

​6. Billing data

​7. Customer responsibilities

​8. Change history

​Contact