| Metadata | Value |
|---|---|
| Status | Active |
| Version | 1.2.0 |
| Last Updated | 2026-09-10 |
| Author | Sangeetha Grantha Team |
| Document Type | Current guide |
Every application mutation must create an audit_log event. Audit records identify the affected entity, action, actor where available, time, and available diff/metadata. They support operational and editorial investigation.
| Question | Use |
|---|---|
| Who performed an operation and on which entity? | Audit event |
| What section text was accepted at a particular time? | Canon revision and section snapshots |
| Which document/extraction produced a section? | Revision provenance and source-document/extraction joins |
| Which sources contributed to this composition overall? | Source evidence |
An audit event is not automatically a complete replayable snapshot. The versioned canon deliberately stores historical content separately.
Kotlin mutation paths use audit services/repositories alongside controlled persistence. Embedding-index scripts use shared audited write helpers for profile/index changes. Actorless automation should retain its script/run context rather than impersonating a curator.
The console exposes audit context through editorial views. AuditRoutes and AuditLogRepository define query behavior. Do not infer a public history API from an admin audit screen.
For a representative mutation, confirm entity identity, action, actor/script attribution, timestamp and relevant metadata agree with the accepted result. For content changes, additionally inspect revision text/source attribution and current API output. See post-import verification.