MDAAI 2.0
The MDAAI 2.0 template family implements a portable operating contract with explicit authority, engineering obligations, evidence and recoverable task history.
By Eris Margeta Kurdali · Repository
What gets added at adoption
docs/ADOPTION.md defines a project-by-project pilot: inventory existing constraints/history and recovery state; reconcile conflicting first-generation rules; explicitly merge the root contract and five governance documents; author target-specific Elaboration and a fresh registry. A successful governance-file revision is not wholesale version adoption. No automatic installer or mass migration is implied. Record the selected authority in the pilot ADR. Adoption acceptance requires structural and targeted product checks, applicable ordinary startup/browser/device evidence, and a pilot exercising active-record editing, a deferred defect, a terminal result and resumption.
Core paths and ownership →Start with the target’s history, not the source’s
The adoption guide specifies schemaVersion 1, a project-specific uppercase taskPrefix and an empty tasks array. Add target-owned task rows before claiming work is active. Do not copy M20 tasks, the source proposal analysis or its package-specific ADR as the target’s task history.
{
"schemaVersion": 1,
"taskPrefix": "APP",
"tasks": []
}What changes from the first generation
The simplification is about where routine facts live, not removing all architecture or correction records. Reconcile root/nested instructions and older mandatory WO/checkpoint policies before activation. Preserve terminal legacy records unchanged; map active WO/CWO work to stable task rows or linked deferred entries.
| Concern | First-generation template | MDAAI 2.0 portable contract |
|---|---|---|
| Entry point | AGENTS.md routes to constitution, plan and protocols. | AGENTS.md is concise operating contract with five rule references. |
| Routine task execution | Open WO before implementation; register completion. | Update one task row and actual evidence; no routine per-edit WO. |
| Status | Project Elaboration progress and work-order registry. | TASKS.json alone; Elaboration keeps scope/order. |
| Errors | CWO remediation/protocol record. | Regression-first repair; separate record only when durable context is needed. |
| Architecture | Human-led ADR phase and template. | Compact ADR when architecture changes warrant it; retain accepted decisions. |
| Recovery | Read plan, work orders, registry and decisions. | Read relevant nonterminal task, evidence and current live state. |
| Adoption | Template instantiation + inherited/project-owned synchronization split. | Authorized target-specific migration/merge; preserve stronger constraints/history. |
What does not belong in every adopted repository
The source package’s README.md, VERSION, Justfile, proposal analysis, governance-v2 ADR, adoption documentation, laboratory code, dashboards, formal models and studies belong to that package. Its scripts/validate.py REQUIRED list includes package-delivery files; that is not the portable adoption inventory. Validator/tests are optional tools to adapt. Add real project commands only when they exist; merely copying tools does not test the target product.
Mapping and rollback
Active legacy WO/CWO records map to one canonical task row, with an extra linked record only for needed context. Completed/void records and checkpoints stay historical. Keep accepted ADRs; new decisions supersede them. For a failed pilot, preserve failure evidence and perform an authorized restoration of the pre-adoption instructions/status mapping. Governance rollback does not automatically undo product changes or external effects.
Protocol and software are separate
MDAAI 2.0’s source repository also implements research and governance-revision/publication software. That code is not installed merely by adopting the portable contract. This documentation describes the repository operating files, not a promise of automatic enforcement, autonomous migration or universal containment. Checks certify structure only to the extent actually tested.
Source references
Based on original contracts and templates. These are source locations, not installed-file claims. No private source archives are served.
MDAAI 2.0: AGENTS.mdMDAAI 2.0: CLAUDE.mdMDAAI 2.0: docs/ADOPTION.mdMDAAI 2.0: scripts/validate.pyMDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/AUTHORITY.mdMDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/ENGINEERING.mdMDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/EVIDENCE.mdMDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/REASONING.mdMDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/RECORDS.mdMDAAI 2.0: PROJECT-INTERNAL/MANAGEMENT/PROJECT-ELABORATION.mdMDAAI 2.0: PROJECT-INTERNAL/MANAGEMENT/TASKS.json