Get Started
In this section
Back to use cases

Enterprise Team

ℹ Illustrative scenario — a composite archetype, not a real named adopter.

Meet Jordan Okafor

Jordan manages a 50-person platform engineering organization at a financial services company. Three teams run concurrent AI-agent-assisted projects. Compliance requires audit trails for all agent-generated work. Knowledge silos between teams mean the same problems get solved independently three times.

The Challenge

Governance is the pain point. AI agents produce useful work, but the company can’t answer basic compliance questions: “Which agent wrote this code?” “What context was it given?” “Was the output reviewed?” Each team has its own documentation approach — wikis, Confluence, markdown repos — making cross-team knowledge sharing impossible. Jordan needs structure without bureaucracy.

How aDNA Helps

Jordan deploys aDNA as the standard knowledge architecture across all three teams. Each team gets its own vault. Federation connects them.

Audit trails (how/sessions/): Every agent session creates a tracked file with session ID, intent, files touched, and SITREP. Compliance can trace any agent output back to its session, mission, and context inputs.

Cross-team sharing (federation): Team A’s data validation pipeline becomes a shared lattice that Teams B and C import. Instead of three implementations, there’s one — maintained by Team A, federated to the others.

Consistent governance (who/governance/): Each vault has the same governance structure — agent policies, review requirements, escalation procedures. New team members and new agents orient the same way regardless of which team they join.

What Their Vault Looks Like

# Each team has its own vault:
platform_team_a.aDNA/
├── what/
│   ├── context/         # Team-specific domain knowledge
│   ├── lattices/        # Shareable pipelines (federation.shareable: true)
│   └── decisions/       # Team ADRs
├── how/
│   ├── sessions/        # Full audit trail (compliance requirement)
│   ├── campaigns/       # Quarterly objectives
│   └── missions/        # Sprint deliverables
└── who/
    ├── governance/      # Agent policies, review requirements
    └── coordination/    # Cross-team notes

# Federation connects the three vaults:
# Team A publishes: latlab lattice publish validation_pipeline.lattice.yaml
# Team B imports:   latlab lattice pull validation_pipeline

Outcome

Compliance audits go from week-long investigations to SQL queries against session files. Cross-team duplication drops as shared lattices replace independent reimplementations. New hires orient in the same structured way regardless of team assignment. The governance overhead is minimal — the same session tracking agents do anyway becomes the compliance audit trail.

Typical Ontology Extensions

EntityTriadPurpose
compliance_checkhow/Audit checkpoints and review sign-offs
team_policywho/Team-specific agent behavior policies
shared_pipelinewhat/Cross-team reusable infrastructure patterns

The adoption checklist

A procurement-ready evaluation guide, grouped by the question each section answers.

Governance — what an auditor reads first

  • 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 compliance context, for 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. This is what keeps audit prep from becoming a separate workstream.

Audit trail — what you can prove after the fact

  • Session — 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.
  • Collision Prevention — the last-edited-by + updated + read-before-write contract stops parallel agents and humans clobbering one another. This is the primitive that makes a shared vault safe for concurrent work.
  • SITREP — the structured close-out every session ends with.

Federation — what leaves the building, and under what terms

  • Federation Readiness — a 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 an 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.

Integration — what it costs to coexist with what you already run

  • AGENTS.md Routing — drop-in routing files let aDNA coexist with existing documentation. Confluence, internal wikis, and repo READMEs stay authoritative; AGENTS.md just points agents at them.
  • Base + Extension — keep the 16-entity base ontology and add domain-specific types 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.

Where to go next

  • Extend the Ontology — 25 min — add a domain-specific entity type (directory + AGENTS.md + template) without forking the base standard.
  • Federate a Vault — 30 min — export, import, and compose across two aDNA instances: the handshake Teams A, B, and C will use in production.