GDPR

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.

​

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. 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.

​

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 and subprocessor list. 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. 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.