aDNA Compliance Walkthrough

Auditors ask five questions about AI-assisted work. The vault answers all five using the same files the team already edits — the audit trail is the working artifact, not a parallel workstream. For compliance officers, security reviewers, and procurement leads; the sibling Enterprise Adoption Checklist organizes the same evidence by evaluation domain.

1 · Who wrote this artifact?

Every governed file carries last_edited_by and updated in its frontmatter; the matching session file in how/sessions/ records intent and scope. Attribution scales from a single frontmatter line up to a full session narrative.

• Frontmatter attribution: last_edited_by: agent_{username} on every content file.
• Session-level attribution: session file opens with ID, intent, and scope — a reviewable work-unit narrative, not just a file-level diff.
• Git as second witness: every commit is signed and dated; session records cross-reference the commit.

2 · What context did the agent have?

Agent output is only as good as its inputs. The session file names the intent and files consulted; the context engineering layer makes the context-assembly rules explicit. Reviewers answer "what was the agent told to do, with what reference material" without re-running the agent.

• Session intent: every session file names the stated objective at the top.
• Context inputs: routing files (AGENTS.md) and context recipes name which knowledge objects the agent loaded — traceable, not opaque.
• Scope declaration: Tier-2 sessions declare scope and run a conflict scan before editing shared configuration; the declared scope is part of the audit record.

3 · Was the work reviewed?

Review is structurally required: CLAUDE.md names standing orders; who/governance/ holds role definitions; every multi-session mission closes with an AAR under how/missions/artifacts/ before it can be marked complete.

• Standing orders: CLAUDE.md at the vault root names the rules that apply to every session — including the rule that every mission gets an AAR before closure.
• Review artifacts: the AAR template (Worked / Didn't / Finding / Change / Follow-up) is mandatory on mission close, producing a short, structured review record.
• Escalation cascade: anomalies propagate session → mission → campaign → STATE.md, so a reviewer can follow a flag from discovery to resolution.

4 · What stops two agents from clobbering each other?

The collision-prevention contract is three frontmatter fields plus one procedural rule: last_edited_by, updated, and read-before-write. Git closes the loop — the authoritative history is the HEAD commit, not any agent's in-memory belief.

• Read before write: no file is modified without reading current state first — catches stale-state edits.
• Updated-date check: if updated is today and the current agent didn't make the last edit, the agent pauses and confirms — a lightweight merge-conflict substitute.
• Truth hierarchy: git HEAD outranks any agent's cached read or memory; authoritative state is what's committed.

5 · How is the audit trail preserved?

A vault's history is append-only by convention. Sessions move from active/ to history/YYYY-MM/ on completion; missions and campaigns are archived with status: completed or abandoned, never deleted. Standing order #6 ("archive, never delete") applies to every governance artifact.

• Archive, never delete: session records, mission files, and campaign documents are a permanent audit trail.
• Monthly partitioning: session history under how/sessions/history/YYYY-MM/ — scan by month, query by quarter, no ORM required.
• Queryable with standard tools: sessions and ADRs are YAML-headed markdown — grep, jq, yq read them.

Self-reference: this vault is the worked example

The audit trail described here is the one this vault runs on — including the session that produced this page. Browse how/sessions/history/ and read a few closed sessions end-to-end to evaluate the audit model directly.

Next Steps