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.

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.

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: true and 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.

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, or shared_pipeline entity types per team without breaking the base specification.
  • Tool-agnostic: Obsidian, VS Code, JetBrains, plain CLI — any editor that reads markdown works.

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