Annex A: Comparisons SPEC-A1
How OCOM relates to adjacent models is documented as a set of structured comparisons. These are informative and do not change any normative definition.
References
Annex B: FAQ SPEC-A2
Is OCOM a database?
No. OCOM is an operating model; a database may store an OCOM model.
Is OCOM the same as a Knowledge Graph?
No. An OCOM model may be projected as a Knowledge Graph, but OCOM adds governance, lifecycle and evidence.
Where are the definitions?
At four: Meta, Models, Memory and the AI extension. The thirteen Core Vocabulary terms (Object, Identity, Metadata, Relationship, Reference, Registry, Classification, Capability, Contract, Policy, Constraint, Ownership, Organization) are each defined at the Meta tier and referenced everywhere else, with one exception: Relationship also has a Models-tier document, and the divergence between the two definitions was recorded as AO-002 and AO-017; AO-002 was closed on 16 September 2026 by CAND-016 (Meta/Relationship.md is the canonical definition, Models/Relationship.md its specialization for Entities), and AO-017 remains open. Entity, Domain, Event, State, Lifecycle and Workflow are defined at the Models tier and have no term record; Memory is specified at the Memory tier, where the Definition of Evidence is reserved for a future version (FW-001, AO-021); Agent, Tool and Evaluation are defined in the AI extension.
What does adopting OCOM cost?
Nothing is bought or installed: the text is CC BY 4.0, and no software, license, certification or service comes with it. Adoption is incremental by design.
The repository's Adoption guides (docs/Adoption/) start small: Getting Started suggests picking one Domain the team already owns and modeling two or three Entities with a minimal Lifecycle, and says that one Entity, correctly defined, is a complete, useful starting point; First Pilot suggests a team of 5 to 10 people and 10 to 20 Entities for a pilot that finishes in weeks rather than quarters, runs against real work, and can be a shared document.
Nothing requires an all-at-once adoption, tooling or automation, event sourcing, AI or Memory, or rewriting existing systems, which keep running unchanged. The specification's own change process (ADR candidates, Reference Cases, Architecture Observations) governs the specification, not the adopter.
What conformance obliges is set out in Chapter 8 as four mandatory requirements: implement the required language and structural constructs of Chapters 4 to 6, preserve their semantics, support applicable validation, and preserve identifier integrity and namespace consistency. The models produced under a claim satisfy Chapters 2, 5 and 6, the claim names the version it is made against, and partial support may be documented without a claim. The published Implementation Case is distilled from real rollouts under NDA, with the organization, names and details changed; its order of work (identity first, events and evidence second, the commercial and governance layers, then projections) can be reused, while its storage choices and rebuilt projections were that operator's decisions, not requirements. What remains is people's time and two decisions the Why OCOM essay names: agreeing who owns what early, and keeping projections rebuildable in the systems already in use. A five-person company with one product and a two-step process should not adopt this.
References
Annex C: Examples SPEC-A3
Worked examples are drawn from the term records themselves rather than restated here; the Object term record, for instance, lists concrete examples of Objects. A fuller set lives under Adoption and Examples.
References