> ## Documentation Index
> Fetch the complete documentation index at: https://docs.enfinitos.com/llms.txt
> Use this file to discover all available pages before exploring further.
# GDPR
> EnfinitOS supports Article 15 (access) and Article 17 (erasure) at the platform layer — exposed via dedicated DSAR endpoints.
EnfinitOS exposes **GDPR Article 15** (right of access) and
**Article 17** (right to erasure) as first-class sandbox-tenant
endpoints rather than as bolt-on processes. These endpoints are live
in the sandbox today and are designed to carry into the production
tenant at the April 2027 launch.
Scope matters here. Article 15 access and Article 17 erasure operate
today on the **developer's sandbox tenant** — the configuration and
ledger blob keyed to that developer. The separate runtime-ingest
plane that holds end-user PII (anonymised viewer ID, IP, user-agent,
device ID) does **not** yet have per-subject access/erasure; that is
on the roadmap. Where this page describes a control as planned, it
is not implemented today.
### Controller / processor split
For AR and spatial-measurement workloads, EnfinitOS acts as a
**processor**. The **operator** that runs the estate is the
**controller**: they decide why and how end-user personal data is
processed, and — critically — they are responsible for capturing and
evidencing end-user consent at the point of collection. EnfinitOS
processes that data only on the operator's documented instructions.
EnfinitOS does **not** operate a server-side data-subject or consent
register today; the only consent mechanism in the codebase is the
marketing website's own cookie banner, which governs this website and
not end-user measurement data. A signed, platform-side consent
register — with consent state recorded into the provenance chain — is
a **roadmap item and is not implemented**.
## Article 15 — Subject Access Request
Access runs as an asynchronous **DSAR job pipeline**: create a job,
run it, download the export bundle.
| Method + path | Purpose |
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `POST /v1/compliance/dsar` | Create a job. `scope.kind` is `DATA_SUBJECT` (one subject — requires `scope.dataSubjectId`), `TENANT_FULL`, or `TENANT_SLICE` (requires `windowStart` + `windowEnd`). |
| `GET /v1/compliance/dsar` | List jobs with per-state counts. |
| `GET /v1/compliance/dsar/{jobId}` | Job status, timeline, and (once run) the audit report. |
| `POST /v1/compliance/dsar/{jobId}/run` | Drive `REQUESTED → COLLECTING → PACKAGING → READY`, materialising the export. |
| `GET /v1/compliance/dsar/{jobId}/download` | Serve the bundle. First download moves `READY → DELIVERED`; repeat downloads are idempotent. |
| `POST /v1/compliance/dsar/{jobId}/cancel` | Cancel before worker pickup (only `REQUESTED` jobs). |
Job states are `REQUESTED`, `COLLECTING`, `PACKAGING`, `READY`,
`DELIVERED`, `EXPIRED`, `FAILED`. Each tenant can hold 5 active
(non-terminal) jobs at once. The download link expires 7 days after
the job runs: an undownloaded `READY` job sweeps to `EXPIRED`, and a
fresh job regenerates an identical bundle, because the builder is
deterministic.
The export bundle carries its sections in the requested format
(`JSON`, `CSV`, `NDJSON`, or `PARQUET`), an **audit report** — who
requested it, what was included, and which rows were filtered out
and why — and an `integritySha256` digest over the canonical bundle
that any auditor can re-derive. `DATA_SUBJECT` exports exclude
tenant configuration sections under data minimisation.
For a synchronous whole-tenant Article 15 read there is also
`GET /v1/compliance/export`, which returns the full export inline.
## Article 17 — Right to erasure
Erasure is exposed today as `POST /v1/compliance/erase`. It is
treated as the destructive operation it is: the key must carry the
wildcard `*` scope and the body must be exactly `{"confirm":"ERASE"}`
(double opt-in). The endpoint deletes the developer's **sandbox
tenant** — the configuration and ledger blob keyed to that developer
(bases, rights, offers, challenges, proof packs, and the event log) —
and returns an erasure receipt counting every record class removed.
The developer-account profile itself is preserved; erasing the
account is handled out-of-band (contact `privacy@enfinitos.com`).
### Why this does not break the proof chain
A common worry with immutable, signed audit trails is that erasing a
person forces you to break a signature. EnfinitOS avoids that by
**data minimisation at the design layer (Article 25)**: the signed
proof and provenance payloads are scoped to **organisations, rights,
and content hashes — not to natural persons**. They carry no name,
email, device identifier, or other end-user PII. Because there is no
natural-person PII inside a signed pack, erasing a data subject does
**not** require removing anything from — or invalidating — a proof
pack. The cryptographic chain and the subject-erasure obligation do
not collide.
The current erasure endpoint operates on the **sandbox tenant
blob**. It performs a flat delete of that tenant's records; it does
**not** crypto-shred, and it does **not** pseudonymise per subject.
Those mechanisms are not implemented today.
### What is not yet implemented (roadmap)
The natural-person PII that *does* exist — runtime ingest identifiers
(anonymised viewer ID, IP, user-agent, device ID) and account/
applicant contact emails — lives in a **separate processing plane**
from the signed proof structures. Per-subject erasure of that plane
is **planned but not yet built**. Specifically, the following are
**roadmap items, not current controls**:
* **Per-subject erasure of the runtime-ingest PII plane** — selective
deletion or anonymisation of a single data subject's ingest records
(today, erasure operates at sandbox-tenant granularity, not
per-subject across the ingest plane).
* **Crypto-shredding** — destroying per-subject encryption keys to
render data unrecoverable rather than issuing row deletes.
* **A pseudonym → subject mapping with destruction-on-erasure** — not
built. (Earlier versions of this document described pseudonymising
the subject in future packs and destroying a pseudonym mapping;
that mechanism does not exist and is not how erasure works, because,
as above, the signed packs contain no natural-person PII to
pseudonymise.)
Until the per-subject runtime-plane erasure is built, an end-user
erasure request that reaches the operator is satisfied by deleting the
relevant tenant/account data through the operator's own controls and
the channels above, not by an automated per-subject sweep across every
plane.
## Data map
A formal, machine-maintained "data map" — a structured inventory that
enumerates every category of personal data, its legal basis, its
retention period, and the controllers / processors involved, surfaced
per-tenant on the operator dashboard — is **on the roadmap and not yet
implemented**. The authoritative descriptions of what personal data is
processed, on what basis, and by which subprocessors, are today
maintained in this documentation set and in the public
[privacy policy](https://enfinitos.com/privacy) and
[subprocessor list](https://enfinitos.com/privacy). The
`GET /v1/compliance/export` response returns the sandbox tenant's own
records; it is not a substitute for that controller-level data map.
## Where the proof shows up
DSAR access jobs record their lifecycle in the export's audit report
(who requested it, what was included, and which rows were filtered out
and why), and that report carries an `integritySha256` digest any
auditor can re-derive with the
[open-source auditor](/sdks/auditor). Routing every compliance action
(including erasure receipts) into the tenant's signed proof chain as a
first-class proof event is a roadmap item; today the erasure endpoint
returns a counts receipt to the caller rather than emitting a signed
chain event.