Current
Architecture Decision Records
Preserve why durable technical and product decisions were made, what alternatives were rejected, and what would supersede them.
What belongs in an ADR
- A long-lived architecture, authority, ownership, compatibility, or publication decision.
- A choice whose rationale would otherwise be rediscovered repeatedly.
- A decision that affects more than one module, repository, deployment type, or public contract.
Editorial changes, routine implementation details, and temporary experiments usually do not need an ADR.
Current registry
ADR-0001: Markdown files are the documentation content authority→Accepted; generated registries and discovery artifacts are derived outputs.ADR-0002: Mobazha Docs owns public knowledge→Accepted; public explanations live here while runtime facts and versioned contracts remain with their owners.ADR template→Repository ADR guide→
Repository-owned architecture decisions
Cross-repository indexes point to the repository that owns each decision. They do not copy or renumber the decision in this documentation repository.
Open Core ADR-018: Extension architecture→Defines Ports, Modules, Functions, Controllers, Core authority, trust-dependent isolation, financial state-machine re-entry, and closed-by-default capabilities.Open Core extension guide→Explains the decision, its current implementation boundary, and the Collectibles case for portal readers.
Reading an ADR safely
An accepted ADR explains an intended durable decision. It does not by itself activate a capability, migrate a deployment, or prove that every repository has completed the decision. Check implementation, conformance tests, release notes, and effective runtime capability where applicable.