/v1/governance: actor mappings (link opaque actor IDs to PII, with GDPR pseudonymize/erasure), archives (download completed audit-log archives from cold storage), and audit logs (immutable, hash-chained history you can independently re-verify). The tenant is always resolved from the JWT — never from a path or body.
Every governance route is scoped to the caller’s tenant. Actor-mapping reads are split into two authorization tiers: the PII-free list versus the single-record de-anonymization read, so identity resolution stays separable from browse access.
Actor mappings
An actor mapping links an opaque
actorId (for example user:550e8400-e29b-41d4-a716-446655440000) to human-readable PII (displayName, email). List rows are PII-free by design — only the single-record GET returns cleartext identity.
List actor mappings
Cursor-paginated, PII-free rows. Filter by an actor-ID prefix.actorId (prefix filter), limit (default 25, capped at 100), and cursor.
Upsert an actor mapping
Creates or updates the PII for an actor ID.PUT is idempotent — the same call creates the record on first use and updates it thereafter. At least one of displayName or email must be supplied.
Get one actor mapping (de-anonymize)
Returns the cleartext PII for a single actor ID. This is the de-anonymization primitive, so it is gated behind the narrowerdeanonymize permission rather than plain read.
Pseudonymize (GDPR)
ReplacesdisplayName and email with [REDACTED] while preserving the record and its actorId link — the audit trail stays intact but the PII is gone. Responds 204 No Content.
Delete (right to erasure)
Permanently removes the mapping for GDPR right-to-erasure. Responds204 No Content.
Pseudonymize keeps the record (PII scrubbed); delete removes it entirely. Choose pseudonymize when you must retain the audit linkage, delete when the record itself must not persist.
Archives
When audit-log partitions age out, they are compressed and moved to object storage. The archives endpoints list completed archives and issue time-limited download URLs.
List archives
Offset-paginated. Filter by date range.from, to (YYYY-MM-DD or RFC 3339), limit (1–200, default 20), and offset. Only COMPLETE archives are listed — in-progress and failed archives are never surfaced.
Download an archive
Returns a presigned URL plus the checksum for integrity verification.Audit logs
Every governance-relevant change is written to an immutable, per-tenant audit log. Each record is linked into a tamper-evident SHA-256 hash chain (
recordHash = SHA-256(prevHash || canonical content)), so a client can independently re-verify integrity.
List audit logs
Cursor-paginated, with rich filters.actor, action, entity_type, date_from, date_to (YYYY-MM-DD or RFC 3339), limit (1–200, default 20), and cursor.
When a diff exceeds the outbox payload cap, changes carries a truncation-marker envelope instead of the full diff, and truncated becomes true with originalSize reporting the pre-truncation byte size.
Verify the audit chain
Re-verifies that every inspected record links to the previous one and matches its stored hash. This is strictly read-only — it proves tamper-evidence, never mutating a record.intact is true when the whole inspected span is unbroken; if a break is found, firstBrokenSeq reports the tenantSeq of the first failing record and verifiedCount reports how many held before it. truncated is true when the chain holds more records than the maxRecords inspection bound allowed.
Get one audit log
You can also list an entity’s history directly with
GET /v1/governance/entities/{entityType}/{entityId}/audit-logs (cursor-paginated), which is convenient when you already know the entity you are auditing.Response codes
| Status | Meaning |
|---|---|
200 | Mapping, archive, or audit data returned |
204 | Actor mapping pseudonymized or deleted |
400 | Invalid input (missing displayName/email, bad date/pagination) |
403 | Missing the required permission tier (e.g. deanonymize for single-record PII) |
404 | Actor mapping, archive, or audit log not found |
422 | Malformed field (e.g. invalid email format) |

