Audit Records and Transaction Boundaries in Ilavrita

Audit Records and Transaction Boundaries in Ilavrita

Version: dev
Source revision: 1aa13a38a06ae151d5a73713132b487d2a7c5216
Last verified: September 27, 2026

An audit record is useful only when it agrees with the state it describes. Ilavrita therefore treats interaction recording as part of the transaction boundary rather than as a message written afterwards.

At the current revision, an allowed FHIR interaction and its internal event record commit together. A refused interaction rolls its tentative state back and records the refusal separately, so the refusal does not disappear with that rollback. The server also holds an allowed response until the transaction has committed.

The implementation is centralized in apps/ilavrita/audit.go. TestEverySignificantInteractionIsRecorded checks that the served interaction table and recording table stay aligned. TestAWriteThatCannotBeRecordedIsNotPerformed covers failed recording. TestARefusalIsRecordedAsLoudlyAsASuccess covers refused interactions. TestAnInteractionThatWritesAndThenRefusesCommitsNothing covers rollback after tentative work.

This verification also found documentation drift. Current README, roadmap, known-limitations, and security documentation describe audit as implemented, while docs/deployment.md still opens with an older statement saying authorization, tenancy, and audit are not enforced. That deployment statement is stale for this revision.

Verification note: a clean clone was attempted on September 27, 2026, but DNS resolution for github.com failed in the publishing environment. The source and tests were inspected through the connected GitHub repository API instead; no fresh local test execution is claimed.

This is not a production-readiness or compliance claim. Ilavrita remains a developer preview and the project still requires external security review.

See docs, known limitations, and the roadmap.

Primary evidence: audit implementation, audit tests, and FHIR R4 AuditEvent.