Run Audit
Per-entity provenance — why each entity was recognized and what happened to it
Activity Log
Per-workspace actions — who did what, and when
Run Audit
Every run produces an audit describing what detection found in one document:Context
The context travels from analysis through to redaction, so the conditions an entity was recognized under are recorded alongside the finding:Entity Provenance
Each recognized entity carries anaudit — a chain of events explaining how it
reached its final state. Every event records a kind, confidence,
timestamp, source, parents, and a hash.
Because events carry
parents, the trail is a graph rather than a flat list —
you can trace a final entity back through every merge and reconciliation that
produced it.
The
hash on each event makes the chain verifiable: an audit can be checked
for tampering without reference to the original document content.Reviewer Overrides
Alongside each entity is an optionalreview, recording the reviewer’s
override and the policy authority it draws from. The policy reference is not
only for the record — it selects which per-policy vault and key provider a
reversible operator resolves against.
When review is absent, the matching policy rule applied unmodified.
Exporting
Run audits export in two formats for archiving:Activity Log
Separately from run audits, each workspace records the actions taken within it:
Payloads are typed per subject — files, pipelines, pipeline runs, policies,
members, invites, connections, and webhooks each carry their own parameters.
Activity payloads store identifiers and parameters, not rendered sentences.
The client localizes the description, so the log stays language-neutral and
stable as wording changes.
Retention
Files record their role, which drives retention scope:
For deployments where retention is governed internally, see
on-premise deployment.
Next Steps
Redaction Workflow
Where the audit fits in the run lifecycle
API Reference
Audit and activity endpoints