> ## Documentation Index > Fetch the complete documentation index at: https://docs.graphorlm.com/llms.txt > Use this file to discover all available pages before exploring further. # Data Retention and Deletion > How long Graphor retains each category of customer data, where it lives, how it is deleted, and the customer-controlled DSR mechanisms that satisfy LGPD art. 18 and GDPR art. 15–22. ## 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 | 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](#2-the-delete-cascade) — 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](#3-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](mailto: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](#4-observability-traces)) | 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](#3-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](mailto: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](#3-the-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-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](/trust/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](#2-the-delete-cascade). | | `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](mailto: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](mailto: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](/trust/subprocessors); the model-use rules are in [Model Use and Training](/trust/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`](#3-the-dsr-api) 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](/trust/model-use-and-training#6-what-graphor-explicitly-does-not-do) 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](/trust/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](/trust/tenant-isolation#6-things-that-explicitly-do-happen-at-the-synapse-personnel-layer). 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](/trust/subprocessors#5-payment-and-billing). * **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](#3-the-dsr-api) 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](mailto:subprocessors@graphorlm.com) receive an email. ## Contact * General privacy and DSR inquiries: [privacy@graphorlm.com](mailto:privacy@graphorlm.com) * Subprocessor and retention-policy notifications: [subprocessors@graphorlm.com](mailto:subprocessors@graphorlm.com) * Customer support: [support@graphorlm.com](mailto:support@graphorlm.com)