aDNA Compliance Walkthrough

Auditors ask five questions about AI-assisted work. The vault answers all five — using the same files the team already edits every day. The audit trail is not a parallel workstream; it is the working artifact. Read the questions in order, or jump to the one your team owns.

Who this is for

Compliance officers, security reviewers, and procurement leads working through an AI-assisted-work audit. The sibling page Enterprise Adoption Checklist organizes the same evidence by evaluation domain; this page organizes it by the question an auditor would actually ask.

1 · Who wrote this artifact?

Every change to a governed file carries attribution in its frontmatter. last_edited_by names the agent or human; updated dates the change. The corresponding session file in how/sessions/ records the session ID, the stated intent, and the scope of files touched — so "who" scales from a single line of frontmatter up to a full session-level narrative.

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

2 · What context did the agent have?

Agent output is only as good as its context inputs. aDNA makes those inputs inspectable: the session file records the intent and the files consulted; the context engineering layer (context recipes, AGENTS.md routing) makes the context assembly rules explicit rather than implicit. A reviewer can answer "what was this agent told to do, with what reference material" without running the agent again.

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

3 · Was the work reviewed?

Governance files declare the review policy at a fixed path. CLAUDE.md names the standing orders and escalation cascade; who/governance/ holds role definitions and policies; every multi-session mission closes with an AAR under how/missions/artifacts/. Review is structurally required before a mission is 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 upward — session → mission → campaign → STATE.md — so a reviewer can follow a flag from its discovery point to its resolution.

4 · What stops two agents from clobbering each other?

Multiple agents and humans can edit the same vault concurrently. The collision-prevention contract is three lines of frontmatter plus one procedural rule: last_edited_by, updated, and read-before-write. Git closes the loop — the authoritative history is always the HEAD commit, not any agent's in-memory belief about file state.

• Read before write: no file is modified without reading its current state first — the rule 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 — the authoritative state is always what's committed.

5 · How is the audit trail preserved?

A vault's history is append-only by convention. Sessions move from how/sessions/active/ to how/sessions/history/YYYY-MM/ on completion; missions and campaigns are archived with status: abandoned or status: completed, never deleted. The standing order "archive, never delete" applies to every governance artifact. The audit trail is the git history plus the on-disk vault — both self-contained and portable.

• Archive, never delete: standing order #6 — session records, mission files, and campaign documents are a permanent audit trail.
• Monthly partitioning: session history lives 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, or any scripting language reads them.

Self-reference: this vault is the worked example

The audit trail this page describes is the one this vault runs on. Session records for every edit — including the session that produced this page — live in how/sessions/ with SITREP and Next Session Prompt. The campaign that produced the entire site is governed by how/campaigns/campaign_rosetta/, with every mission closing on an AAR. The structure is the lesson: to evaluate the audit model, browse how/sessions/history/ in the repository and read a few closed sessions end-to-end.

Next Steps