Every material mutation in the control plane — key minted, budget changed, plan flipped, release activated, member added — writes an immutableDocumentation Index
Fetch the complete documentation index at: https://docs.karta.sh/llms.txt
Use this file to discover all available pages before exploring further.
AuditEvent in
the same transaction as the mutation itself. If the mutation commits, so
does its audit row; they can’t drift apart.
Immutable by construction
Immutability is enforced at two levels so neither application bugs nor raw SQL can rewrite history:Application level
The model is
readonly?; before_update and before_destroy callbacks
raise.Database level
Postgres
BEFORE UPDATE/BEFORE DELETE triggers reject changes — even
update_columns and direct SQL can’t alter an audit row.What’s recorded
Each event captures the actor, the action, the affected resource, and a timestamp, alongside structured request context (request_id, user_id,
org_id, remote_ip) carried through the control plane’s structured logs.
Sensitive values — bearer tokens, BYOK plaintext — are never recorded.
Retention & access
Audit history is retained (1-year retention is the stated target) and surfaced in the dashboard’s audit views for owners and admins. Because it’s written in-transaction and locked, it’s a trustworthy basis for the operators-don’t-read-conversations posture described in Personas → the trust claim.The audit log records control-plane mutations (identity, money, deploys). It
is not a transcript of agent conversations — conversation history lives in
the harness (Sessions & participants).