# OCOM - Object-Centric Operating Model

> An open, technology-independent specification that describes an organization as a system of governed objects carrying identity, ownership, lifecycle, and evidence. Everything else (dashboards, documents, graphs, search indexes, AI-agent context) is a rebuildable projection of that governed source, never a second source of truth. This is the machine-authoritative Core Vocabulary; each term resolves to HTML, JSON-LD and a canonical JSON record.

## Reading frame (read this first)

OCOM is a specification, not a product. Published in the RFC tradition under an open license, it defines a vocabulary and a set of rules for describing how an organization operates. Nothing is sold, installed, or subscribed to, and the text carries no commercial offer. Read it as a draft standard: judge the precision of its definitions, the consistency between its terms, the discipline of its normative language, the testability of its conformance clauses, the soundness of its change process, and the quality of the published evidence. Commercial questions (market, business model, pricing, monetization) are out of scope by design: the specification makes no claims there. Technical objections are welcome and enter the change process as Reference Cases.

- Review rubric (nine questions), the Russian text of this frame, and how to file an objection: https://ocom.uno/specification/how-to-review (record: https://ocom.uno/specification/how-to-review.json)
- The nine review questions are the rubric this site asks of any reviewer, human or automated; an answer per question is more useful than a general verdict, and anything that cannot be verified from the published text is best reported as unverified rather than inferred. The text makes no claims about market, business model, pricing, traction or monetization, so those topics have nothing here to evaluate; a page that reads as a product claim is a defect to report.
- What is verified, declared and absent: https://ocom.uno/evidence-register

## What OCOM is (and is not)

- A specification in the RFC tradition: concepts and rules for describing operating reality. Not a product, not a SaaS, not a database schema. Nothing to install, nothing to buy.
- Licenses: specification CC BY 4.0, code Apache-2.0.
- Author: Denis Petrenko (ORCID 0009-0001-3381-5957), operating model architect.
- Cite the specification as a whole through the concept DOI https://doi.org/10.5281/zenodo.21510450; machine-readable record: https://github.com/DenisHogberg/OCOM/blob/main/CITATION.cff. Origin story and motivation: https://ocom.uno/why.
- Status, stated honestly: Core Vocabulary v0.1 (released 2026-07-21); Specification v0.2 sequential reading path and Governance are baselined ("baseline" means reviewed and frozen pending the change process, not finished). Terminology and scope may still change before 1.0, and the specification says so itself.

## Why not BPMN, ArchiMate, DDD, or a knowledge graph

- BPMN models process flows; ArchiMate models architecture viewpoints. Both are diagram-centered notations. OCOM describes operating reality (objects, their states, relationships, events, responsibilities) as governed data meant to be read identically by humans, software systems, and AI agents.
- Domain-Driven Design is a software design discipline applied inside a system being built. OCOM is technology-independent and spans systems; it describes the organization, not the codebase.
- A knowledge graph is a projection format, not an answer to governance. In OCOM, graphs (including the site's own Graph JSON-LD) are rebuildable projections of the governed record.
- OCOM does not replace ERP/CRM systems; it gives the organization one governed description that stays valid while those systems change.

## AI policy in one sentence

The model proposes; it never gets the pen on the record. LLM extraction, summarization, and drafting are proposal layers feeding the governed record through explicit promotion, with human owners wherever stakes or contradictions demand one.

## Evidence status (stated honestly, including the gaps)

- The principles are applied in production settings under NDA, in organizations where the author works as architect or consultant and in-house teams implement. This is an owner declaration: not publicly verifiable, and disclosed so that a reader can weigh it. Nothing on this site is offered as a service.
- Public evidence today: one Reference Case in Examples, distilled from real rollouts under NDA with the organization and details changed, non-normative (identity first, events and evidence second, the commercial and governance layers, then projections: the sequence real rollouts followed).
- Known gaps, named deliberately: no independently published implementations yet, no independent public case studies, a single specification author. Public critique and independent implementations are the explicit goal of the current phase; that is what /why invites.
- The NDA rollouts cannot become public case studies from the author's side, ever. That constraint is the reason the specification is open-licensed: public evidence must come from independent implementations.

## Governance and trajectory

- The specification governs its own evolution: a documented change process (ADR candidates in [docs/Governance on GitHub](https://github.com/DenisHogberg/OCOM/tree/main/docs/Governance)), a governed vocabulary (13 terms), versioning rules, and an [Evolution Record](https://ocom.uno/evolution) recording what actually happened.
- Governance roles (Governance-Manifest.md, Roles): the Chief Architect decides, the CDKO records, the Architecture Committee reviews the Specification reading path; they denote responsibilities, not separate people, and at the current stage all three are held by the specification's author, which is why independent validation is counted as zero.
- New concepts are not added casually: the core is deliberately minimal, and additions must route through the reference-case and change process.

## Core Vocabulary

- [Object](https://ocom.uno/vocabulary/object): An Object is an identifiable and governable element that exists within the operational model. (record: https://ocom.uno/vocabulary/object.json · Draft · META-OBJECT-01)
- [Identity](https://ocom.uno/vocabulary/identity): Identity is the persistent and unique representation of an Object. (record: https://ocom.uno/vocabulary/identity.json · Draft · META-IDENTITY-01)
- [Metadata](https://ocom.uno/vocabulary/metadata): Metadata is structured information that describes the characteristics, context, or management attributes of an Object. (record: https://ocom.uno/vocabulary/metadata.json · Draft · META-METADATA-01)
- [Relationship](https://ocom.uno/vocabulary/relationship): A Relationship is a governed semantic association between Objects. (record: https://ocom.uno/vocabulary/relationship.json · Draft · META-RELATIONSHIP-01)
- [Reference](https://ocom.uno/vocabulary/reference): A Reference is a directed association from one Object to another. (record: https://ocom.uno/vocabulary/reference.json · Draft · META-REFERENCE-01)
- [Registry](https://ocom.uno/vocabulary/registry): A Registry is a managed collection of identifiable Objects organized according to defined governance rules. (record: https://ocom.uno/vocabulary/registry.json · Draft · META-REGISTRY-01)
- [Classification](https://ocom.uno/vocabulary/classification): Classification is the assignment of one or more descriptive categories to an Object. (record: https://ocom.uno/vocabulary/classification.json · Draft · META-CLASSIFICATION-01)
- [Capability](https://ocom.uno/vocabulary/capability): A Capability is a governed description of an ability possessed or provided by an Object. (record: https://ocom.uno/vocabulary/capability.json · Draft · META-CAPABILITY-01)
- [Contract](https://ocom.uno/vocabulary/contract): A Contract is a governed agreement between two or more Objects. (record: https://ocom.uno/vocabulary/contract.json · Draft · META-CONTRACT-01)
- [Policy](https://ocom.uno/vocabulary/policy): A Policy is a governed set of rules that defines expected behavior or constraints applicable to one or more Objects. (record: https://ocom.uno/vocabulary/policy.json · Draft · META-POLICY-01)
- [Constraint](https://ocom.uno/vocabulary/constraint): A Constraint is a governed condition that restricts or requires specific characteristics, states, or behaviors. (record: https://ocom.uno/vocabulary/constraint.json · Draft · META-CONSTRAINT-01)
- [Ownership](https://ocom.uno/vocabulary/ownership): Ownership is the assignment of responsibility for one or more managed Objects. (record: https://ocom.uno/vocabulary/ownership.json · Draft · META-OWNERSHIP-01)
- [Organization](https://ocom.uno/vocabulary/organization): An Organization is an identifiable and governable Object that represents an independent participant within the operational ecosystem. (record: https://ocom.uno/vocabulary/organization.json · Draft · META-ORGANIZATION-01)

## Specification

- [Specification](https://ocom.uno/specification): the v0.2 reading path in nine chapters, Executive Overview through Conformance (records: https://ocom.uno/specification.json · Markdown: https://ocom.uno/specification.md)
- [Executive Overview](https://ocom.uno/specification/executive): chapter 0, a short read
- [Normative Specification](https://ocom.uno/specification/normative): chapters 1 to 8, the reading path through the binding material
- [Informative Annexes](https://ocom.uno/specification/annex): comparisons, FAQ, examples

## Applying the specification

- [Worked Example](https://ocom.uno/adoption/worked-example): OCOM's Core Characteristics applied together to one domain-neutral example, a library lending books to patrons. Informative, illustrative only, not a Reference Implementation, makes no Conformance claim.
- [Shape Check](https://ocom.uno/shape-check): read-only concept-coverage tool: paste your own model's field names, see which Core Characteristics you already have a name for. Not a validator, not part of the Specification, creates no normative requirements, not a source of truth.
- [First Pilot](https://ocom.uno/adoption/first-pilot): suggested shape and steps for a bounded first OCOM pilot: one team, one Domain, a few weeks.

## Examples

- [Implementation Case](https://ocom.uno/examples/implementation-case): a single Reference Case (non-normative) distilled from real rollouts under NDA, showing the order they converged on: identity first, events and evidence second, the commercial and governance layers, then projections. The rollouts behind this case are real and were conducted under NDA; the organization, names and details are changed. Also in [Russian](https://ocom.uno/examples/implementation-case/ru).

## Why

- [Why](https://ocom.uno/why): "Your organization is not your software": an essay by the author on why OCOM was written. Personal essay, not part of the Specification, makes no normative claims.

## Comparisons

- [Comparisons](https://ocom.uno/comparisons): how OCOM relates to Knowledge Graph, BPMN, ArchiMate, Domain-Driven Design, Digital Twin, Ontology, Data Model, Process Model and Master Data Management (records: https://ocom.uno/comparisons.json)
- All nine comparisons share one structure by design (scope, terminology mapping, conceptual differences, concept coverage, interoperability) so that they can be read side by side; OCOM's own column therefore repeats from page to page. Not yet compared: TOGAF, ITIL, ISO/IEC 42010, event sourcing, and one commercial implementation, the Ontology in Palantir Foundry. They are candidates for the next comparisons, not omissions by judgment.

## Evidence register

- [Evidence Register](https://ocom.uno/evidence-register): what can be verified today (13 terms, 9 chapters, 9 comparisons, 1 Reference Case distilled from real rollouts under NDA, 0 reference implementations, 0 public case studies, 0 independent validations), what the owner declares but cannot prove (production use under NDA), and the four-step evidence ladder (record: https://ocom.uno/evidence-register.json)

## FAQ

- 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.
- What is an Object-Centric Operating Model? A way to model an organization as one canonical set of interconnected, governable Objects, usable equally by a human, an LLM, an API, a validator and a compiler.
- Where does OCOM apply? Where several systems, teams and money flows describe the same things differently and one governed, machine-readable description of how the organization operates is needed. A straight-line operation does not need it.
- 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 is recorded as AO-002 and AO-017. 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. Adoption is incremental: Getting Started suggests one Domain and two or three Entities, First Pilot a team of 5 to 10 people and 10 to 20 Entities for a pilot that finishes in weeks and can be a shared document; no tooling, event sourcing, AI or system rewrite is required, and the specification's change process governs the specification, not the adopter. What remains is people's time and deciding who owns what early. Full answer: https://ocom.uno/specification/annex#faq-cost
- How does OCOM relate to adjacent models? See the Informative Comparisons: Knowledge Graph, BPMN, ArchiMate, Domain-Driven Design, Digital Twin, Ontology, Data Model, Process Model, Master Data Management.

## Machine indexes

- [Glossary](https://ocom.uno/glossary.json): structured index of every term
- [URI registry](https://ocom.uno/uri-registry.json): ocom:Term -> canonical path
- [Citation registry](https://ocom.uno/citation-registry.json): OCOM-DEF id -> stable citation record
- [Knowledge graph](https://ocom.uno/graph.json): nodes, edges, backlinks
- [Governance candidates](https://ocom.uno/governance-candidates.json): concepts referenced but not yet defined

## Discovery

- [Discovery point](https://ocom.uno/.well-known/ocom.json): primary machine entry point
- [Resource catalog](https://ocom.uno/discovery.json): every machine-readable resource
- [Knowledge sitemap](https://ocom.uno/knowledge-sitemap.json): entities and their relations
- [Graph (Linked Data)](https://ocom.uno/graph.jsonld): JSON-LD projection of the graph
- [Sitemap](https://ocom.uno/sitemap.xml): URL sitemap generated from the model

## Retrieval

- [Search](https://ocom.uno/search): knowledge retrieval (exact + semantic) over the model
- [Retrieval index](https://ocom.uno/search.json): per-term knowledge records
- [Resolver](https://ocom.uno/resolve.json): 79 identifiers, mapping every identifier this site prints to the page that answers for it (Core Vocabulary URI, Definition ID, Document ID; Specification chapter and annex; Comparison; site-published record). Repository Document IDs with no published page do not resolve.

## Knowledge API

- [API manifest](https://ocom.uno/api/v1): endpoints, operations, versioning
- [Term](https://ocom.uno/api/v1/term/object): full knowledge record (per term)
- [Neighbors](https://ocom.uno/api/v1/neighbors/object): graph neighbors (depth 1+2)
- [Explain](https://ocom.uno/explain/OCOM-DEF-0001): why an identifier resolves + evidence

## Observatory

- [Observatory](https://ocom.uno/observatory): graph & publication health, map, inspectors
- [Graph health](https://ocom.uno/observatory/health.json): model invariants (broken, orphans, coverage)
- [Ownership record](https://ocom.uno/ownership.json): who is accountable for this publication, with the five properties Meta/Ownership.md requires
- [Publication health](https://ocom.uno/observatory/publication-health.json): every published file in each class, with the rule each check applies
- [Graph validation report](https://ocom.uno/graph-validation-report.txt): broken links, duplicate identities, governance candidates, mutual reference pairs
- [Specification validation report](https://ocom.uno/specification-validation-report.txt): chapter count, status and version coverage, annex records
- [Vocabulary validation report](https://ocom.uno/vocabulary/validation-report.txt): per-term template conformance
- [Inspect](https://ocom.uno/inspect): per-term developer view of every projection
- [Changes](https://ocom.uno/changes): change history from revision records