Completed
Meta-model (Meta/), normative structural models (Models/), language and conformance rules (Language/), specification charter and principles (Core/), 13 business domain profiles (Domains/, one Overview.md each; Domains/Common/ holds shared material and carries none), a reference entity catalog (Entities/), Reference Architecture views (Reference Architecture/), the iGaming worked example (Examples/), and the Memory and AI extension layers (Memory/, AI/).
10 documents at the 22 July 2026 baseline in docs/Governance/ (the directory has since grown through the same process): the Governance Manifest, the Standard Evolution Methodology (how the Core may change), Documentation Debt, Architecture Observations, ADR Candidates, Knowledge Map, Documentation Standards, Development Readiness, Release Readiness, and Architecture Health. Reviewed and closed; further changes to this section go only through its own approved process.
docs/Specification/: a nine-chapter sequential entry point (Executive Overview through Conformance) compiling the existing normative documents above into one traceable reading path. It does not replace the granular documents and introduces no new architecture.
docs/Adoption/: a Getting Started guide, a First Pilot guide, an FAQ, and a Common Mistakes guide, restating the existing specification for a first-time reader.
Source-of-truth projections of this repository published as a machine-authoritative site: Vocabulary, Specification reading path, Comparisons, Knowledge API, Graph JSON-LD, Discovery, and llms.txt. Vocabulary, the Specification reading path and the Adoption pages are rebuildable projections of the repository; the site additionally holds its own informative records (the comparisons, the How to Review note, the release record, the Observatory reports, the governance-candidates record, the Knowledge API records and the Why essay) and one Consumer Tool (Shape Check, authorized by CAND-013), none of which defines a term or carries normative weight, and none of which is a second source of truth for anything the repository defines.
An anonymized end-to-end adoption narrative in Implementation Case: the sequence the rollouts converged on (identity first, events and evidence second, the commercial and governance layers, then projections). Distilled from real rollouts conducted under NDA; the organization, names and details are changed.
Published at ocom.uno/why: the motivation, origin, honest boundaries of applicability, and an open invitation to break the model.
Evidence defined, the integrity guarantee, Audit Record by reference and erasure that preserves the record (CAND-023, CAND-024, AO-085); accountability singular and responsibility plural (CAND-025); the Reference Serialization and its schema (CAND-026); the Department Entity and legal form as Organization (CAND-027); The First 90 Days (CAND-028); the Conformance Test Suite tooling with its example run. Published as Release v1.4.0 with a signed tag and signed assets, Zenodo version DOI 10.5281/zenodo.22900969; the Specification reading path stays 1.0.
docs/Specification/: the nine chapters recompiled against the canonical documents as they stood that day, each with a Revision History and a Source line naming what changed; the 22 July 2026 Committee Review Package keeps the v0.2 review record. Published as Release v1.3.0 with a signed tag and signed assets, Zenodo version DOI 10.5281/zenodo.22809694; the reading path pages on this site are regenerated from the same commit. Preceded by Release v1.2.0 (16 September 2026, DOI 10.5281/zenodo.22807178), which closed the Master Architecture Backlog's Part 8 bar ("OCOM Specification v1.0 Ready") with every item met or dispositioned.
Current State
- The Standard Evolution Methodology is active. Its first Reference Case (OBS-003, Object Attribute Lifecycle Categories) is logged and Open, pending independent corroboration before any Core impact is considered; see
docs/Governance/Architecture-Observations.mdin the canonical repository. - Governance and the Specification v1.0 reading path are baselines. Neither changes except through their own approved processes (editorial fixes, or ADR for architectural change).
- The canonical repository remains documentation only by design: the specification itself ships no runtime. In-house implementations run privately in production under NDA; none is independent of the author, who was the architect or consultant on each. Tooling around the specification, where it exists, is developed and governed separately from it; it is not part of OCOM and places no obligation on an implementer.
- The specification's principles are applied in production settings under NDA (the author works as architect or consultant; in-house teams implement). No public case studies exist yet; converting private practice into public evidence is the explicit goal of the current phase.
- The specification has entered its public review phase: ocom.uno/why invites critique, and independent implementations are actively sought.
Future Directions
These are directions for exploration, evidenced by observed need, not commitments or planned releases.
- Whether OBS-003 represents a real, repeated boundary: this depends on independent Reference Cases still to be submitted, not on a decision to build something.
- What a Reference Implementation and a Reference Agent would require, if and when the specification is judged stable enough to support them; not yet scoped.
- Whether further Domain-level practice (Business Intelligence, Operations, and others already present in
Domains/) surfaces additional Reference Cases worth recording. - Two items named in earlier planning were never realized as distinct deliverables and remain open, unscoped questions rather than committed work: an "Object Passport" concept (no corresponding document exists;
Meta/Identity.mdandMeta/Metadata.mdcover related but not identical ground), and a dedicated Security specification (nothing currently exists under this name anywhere in the repository). - Idea (not a governance artifact): Consider documenting the evidence thresholds and promotion criteria for Specification evolution if multiple independent governance reviews reveal recurring patterns not fully covered by Standard Evolution Methodology.
- Whether agent-facing access beyond the static Knowledge API (for example, a governed-context endpoint AI agents can consume directly) is warranted: depends on observed demand from the public review phase, not yet scoped.
- Public, independently authored case studies: the bar for claiming adoption maturity; sought, not scheduled.
Note on this revision: The previous version of this roadmap listed a v0.1/v0.2/v1.0 plan drafted before this work began. Some items it named (Business Objects, Reference Architecture) were delivered, in some cases under revised terminology; others (Object Passport, Security, Enterprise Integration) were never started. This revision replaces that forward-looking plan with a record of what actually happened, per docs/Governance/Standard Evolution Methodology.md's emphasis on evidence over prediction.