OCOM, the Object-Centric Operating Model: an open specification for a machine-readable description of an organization

Abstract

OCOM, the Object-Centric Operating Model, is an open, technology-independent specification that describes an organization as a system of governed objects carrying identity, ownership, lifecycle and evidence. Everything else an organization produces about itself, dashboards, documents, knowledge graphs, search indexes and AI-agent context, is treated as a rebuildable projection of that governed source, never as a second source of truth. Read it online at https://ocom.uno. Concept DOI: https://doi.org/10.5281/zenodo.21510450. What problem does an operating model specification solve? Most organizations describe themselves through the software they run on. When a system changes, the description changes with it, and the same fact ends up living in a CRM, a spreadsheet, a dashboard and a chat thread, each slightly different. An operating model in the OCOM sense is the governed description that stays valid while those systems change: which objects exist, who answers for each of them, how each changes state, and what evidence stands behind every claim about them. It is written so that a person, a software system and an AI agent read the same thing. OCOM is a specification in the RFC tradition, not a product. Nothing is sold, installed or subscribed to. The text is licensed CC BY 4.0 and the repository Apache-2.0. What this release bundles The Release identifier is an independent track; it names a bundle and does not mirror any single component's number. Constitution: 1.0.1 Core Vocabulary: 0.1 (13 governed terms) Specification reading path: 0.2 Release: 1.1.1 (annotated git tag v1.1.1) What can a machine read? Every governed term resolves to four representations from one canonical record: HTML, JSON, JSON-LD and Markdown. The machine-readable entry points are: https://ocom.uno/llms.txt, the entry point written for AI agents and LLM retrieval https://ocom.uno/api/v1, the Knowledge API: terms, a resolver for every identifier the site prints, explain, neighbors, graph and governance https://ocom.uno/graph.jsonld, the vocabulary as a JSON-LD graph using schema.org types, with every relationship between terms and every concept the specification references but has not yet defined https://ocom.uno/observatory, the site's own checks that each projection matches its canonical source after every build The repository itself is the canonical source: Markdown under docs/, git-tracked, individually versioned, with no code. How is OCOM different from BPMN, ArchiMate, DDD or a knowledge graph? Nine published comparisons state the relationship to neighbouring models explicitly rather than by name only: BPMN, ArchiMate, Domain-Driven Design, Master Data Management, ontologies, knowledge graphs, data models, process models and digital twins. The short version: BPMN and ArchiMate are diagram-centred notations, DDD is a software design discipline applied inside a system being built, MDM governs master data about things, and a knowledge graph is a projection format. OCOM describes the operating reality itself as governed data, and treats each of those as either a neighbouring concern or a projection of the governed record. The comparisons are at https://ocom.uno/comparisons. What is new since v1.0.0 v1.0.0 was tagged before OCOM Constitution v1.0 and the Architecture Freeze existed. This release contains both, the governance layer that grew up around them, and a full pass of corrections and disclosures. Constitution 1.0.1: fourteen Canonical Principles, adopted through ADR CAND-006 and frozen under CAND-007. Principles 9 and 11 were transcribed from their recorded interpretations in this release, so that the Domain-Neutral Core carries its own scope test and Structural Isolation reads as a verifiable capability requirement rather than an architecture mandate. Governance layer: 15 ADR Candidates (CAND-001 to CAND-015) and 61 Architecture Observations (AO-001 to AO-061), the recorded tensions the specification discloses rather than patches. Two decisions landed in this release: the Memory, Knowledge and World Model derivation chain is settled as a three-layer split by time horizon (CAND-014), and the two competing definitions of Domain are resolved with Models/Domain.md as canonical (CAND-015). AO-059 to AO-061 record the first external practitioner review of the published model. Reference Case: one anonymized end-to-end adoption narrative, distilled from real rollouts conducted under NDA, with the organization, names and details changed. Machine-readable licensing and supply-chain hygiene: REUSE 3.3 compliance with SPDX identifiers for every file, an OpenSSF Scorecard workflow, an OpenSSF Best Practices badge, a security policy, a code of conduct, and issue and pull request templates that mirror the change process. Citability: CITATION.cff bound to the author's ORCID iD and the concept DOI; the README rebuilt as an entry page with the five publication tiers drawn out. Status, stated honestly Early-stage. The v0.1 Core is released; Governance and the Specification v0.2 reading path are baseline, which means reviewed and frozen pending the change process, not finished. Terminology, structure and scope may still change before a v1.0 of the specification itself. Evidence, from the Evidence Register at https://ocom.uno/evidence-register: one Reference Case published; reference implementations, verified implementations and independent validations all stand at zero. Independent implementations and public critique are the explicit goal of this phase. The open questions are public. The Architecture Observations register lists every tension the specification has found in itself or had pointed out to it, including the ones still unresolved, at https://github.com/DenisHogberg/OCOM/blob/main/docs/Governance/Architecture-Observations.md. How to review or object Review it against the nine questions at https://ocom.uno/specification/how-to-review. Found a real gap, a contradiction between two rules, or a page that disagrees with its source? The repository's issue templates route each to the change process: Reference Case, Architecture Observation, Projection defect. Release notes This is the first release whose name matches what it contains. It supersedes v1.0.0 in scope, not in git: v1.0.0 stays in history exactly as published, and this release, cut from the audited public build, is the one to cite from here on. v1.1.1 is a metadata-only patch over v1.1.0, published the same day: it adds .zenodo.json, the deposit metadata the Zenodo GitHub integration reads, and narrows the licence field of CITATION.cff to the specification text's CC BY 4.0, which Zenodo's citation reader accepts only as a single value. The specification text under docs/ is byte-identical to v1.1.0. v1.1.0 carries no version DOI because its deposit was rejected on that field. Cite Petrenko, D. (2026). OCOM, the Object-Centric Operating Model: an open specification for a machine-readable description of an organization. https://ocom.uno. https://doi.org/10.5281/zenodo.21510450. CC BY 4.0. Author: Denis Petrenko, ORCID https://orcid.org/0009-0001-3381-5957. The concept DOI always resolves to the most recent archived version; publishing this release mints a fresh version DOI under it.