CurrentUnderstand · Guide
Architecture Decision Records
Find an accepted architectural decision and distinguish it from a proposal or repository-local implementation note.
Open the ADR registryEstimated time5 minutes
Trust, applicability, and sourcesCurrent public project policy or service surface
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.