aDNA Enterprise Adoption Checklist
A structured walkthrough for procurement, security, and platform engineering reviewers evaluating aDNA for multi-team deployment. Four domains — compliance, session audit, federation, and integration surface — each backed by concrete vault artifacts and spec citations. The pattern you evaluate is the pattern you deploy.
Who this is for
Platform engineering leads, compliance officers, and procurement teams assessing aDNA before a multi-team rollout. The shape of this page mirrors a procurement questionnaire — scan the section you own; the cards below each section link to the authoritative reference.
1 · Compliance posture
Every aDNA vault ships with the same four root-level governance files. The consistency is the audit primitive: an auditor who orients once can orient across every team vault without relearning structure. Policies, decisions, and current operational state live at fixed paths.
- Policy source of truth: CLAUDE.md at the vault root names standing orders, priority hierarchy, and escalation cascade.
- Decision trail: ADR files under
what/decisions/pair each technical choice with rationale, trade-offs, and reviewer attribution. - Operational snapshot: STATE.md captures current
phase, blockers tagged
#needs-human, and next actions — so status reviews don't require a meeting.
Governance Files
Four root-level files (CLAUDE.md, MANIFEST.md, STATE.md, AGENTS.md) declare policy, inventory, state, and agent routing — the same for every vault, so auditors orient once and reuse the mental model across teams.
Architecture Decisions
ADR files under what/decisions/ pair each technical choice with its rationale, trade-offs, and legal/compliance context — designed to satisfy both engineering and non-engineering reviewers.
Dual-Audience Review
Every governance artifact is legible to a platform engineer and to a compliance officer without translation — the pattern that keeps audit prep from becoming a separate workstream.
2 · Session audit trail
Agent work is not ephemeral. Every session — whether agent-assisted or
human — creates a tracked file in how/sessions/ with
session ID, intent, files touched, and a closing SITREP. The audit
trail is a byproduct of normal execution, not an additional workstream.
- Traceability: any committed artifact traces back to session → mission → campaign → context inputs.
- Collision prevention: the
last_edited_by+updated+ read-before-write contract makes concurrent work safe without locks. - Queryable history: session files are YAML-headed markdown — scriptable with standard tooling, no proprietary query layer.
Session Glossary
Every agent-assisted work unit produces a file in how/sessions/ with session ID, intent, files touched, and a SITREP. The audit trail is the working artifact, not an afterthought.
Enterprise Team Use Case
Narrative walkthrough: a 50-person platform org replaces week-long compliance investigations with SQL queries against the session corpus. The governance overhead is what the agents already do.
Collision Prevention
The last-edited-by + updated + read-before-write contract prevents parallel agents and humans from clobbering one another — the primitive that makes a shared vault safe for concurrent work.
3 · Federation surface
Three teams should not solve the same problem three times. aDNA's federation model lets Team A publish a validated pipeline as a lattice; Teams B and C pull and compose it with explicit version policy. Every shared artifact passes a six-point readiness check before it crosses a team boundary.
- Opt-in by default: nothing federates without
federation.shareable: trueand a declared source instance. - Version policy is explicit: locked / patch / minor / latest — downstream teams choose their own change tolerance.
- Provenance travels with the artifact: FAIR envelope (license, creators, keywords, provenance, identifier) is part of the file, not a side document.
Federation Readiness
Six-point checklist (schema valid, opt-in, source instance, license, keywords, resolved references) gates every shared artifact. Federation is never accidental.
Lattice Composition
Teams publish reusable pipelines as lattices; sibling teams pull and compose them. Three implementations collapse to one maintained source — with explicit version policy.
FAIR Envelope
License, creators, keywords, provenance, and identifier travel with every federated artifact. Legal provenance is a data field, not a separate document.
4 · Integration with existing practice
aDNA is a knowledge architecture, not a platform replacement. Confluence, internal wikis, existing repo READMEs, and your current identity stack stay where they are. aDNA adds a routing layer (AGENTS.md) that points agents at those systems and a governance layer that lives in git alongside the code it governs.
- No vendor lock-in: the standard is open and permissively licensed. The vault is plain markdown in git.
- Ontology extension without fork: add
compliance_check,team_policy, orshared_pipelineentity types per team without breaking the base specification. - Tool-agnostic: Obsidian, VS Code, JetBrains, plain CLI — any editor that reads markdown works.
AGENTS.md Routing
Drop-in routing files let aDNA coexist with existing documentation systems — Confluence, internal wikis, and repo READMEs remain authoritative; AGENTS.md just points agents at them.
Base + Extension
Keep the 14-entity base ontology; add domain-specific entity types (compliance_check, team_policy, shared_pipeline) per team without forking the standard.
Open Standard
The specification is open and permissively licensed — no vendor lock-in, no platform dependency. Teams can self-host, audit the spec, and exit cleanly.
Evaluation checklist
A reviewer working through this page should be able to answer the following in a procurement memo:
- Does the governance layer give us the same artifact for every team? Yes — four root files at fixed paths, identical across vaults.
- Can we trace any AI-assisted output back to its source context and reviewer? Yes — session → mission → campaign → context inputs.
- Can teams share work without three independent reimplementations? Yes — lattice publish / pull / compose with explicit version policy and a 6-point readiness gate.
- Can we adopt without replacing existing systems? Yes — AGENTS.md routes agents at existing wikis / repos / identity stacks.
- Can we exit cleanly? Yes — the vault is plain markdown in git, under an open specification.
Next Steps
Enterprise Team Persona
Quick-reference adopter profile: pain points, typical ontology extensions, and deployment pattern for platform engineering organizations.
Extend the Ontology
Step-by-step: add a domain-specific entity type (directory + AGENTS.md + template) without forking the base standard. 25 minutes.
Federate a Vault
Walk through export, import, and compose across two aDNA instances — the handshake Teams A, B, and C will use in production. 30 minutes.