# OCOM Specification

Version 0.1. A projection of the canonical model; definitions live in the Core Vocabulary and are referenced, never restated.

## Executive Specification

### What is OCOM? (SPEC-E1) — Informative v0.1

OCOM — the Object-Centric Operating Model — is an open specification for modelling an organization as a set of interconnected, governable Objects.
It is a machine-authoritative model: one canonical source usable equally by a human, an LLM, an API, a validator and a compiler. This document does not restate any definitions; each concept is defined once in the Core Vocabulary and referenced from here.

_References: [Object](/vocabulary/object)_

### Why OCOM exists (SPEC-E2) — Informative v0.1

Organizations describe the same reality many times over — in process tools, data models, wikis and spreadsheets — with no single governed source.
OCOM gives every operational object one canonical identity, with governance, lifecycle, ownership and evidence attached, so that humans and machines reason over the same authoritative model instead of many divergent copies.

### Design Principles (SPEC-E3) — Informative v0.1

OCOM is shaped by a small set of principles: Object-Centric Reality, Evidence Before Belief, a Domain-Neutral Core, Extensibility Over Enumeration, and Governance by Default.
These principles are why the model favours one canonical source with many projections over a single monolithic document.

### Core Vocabulary (SPEC-E4) — Informative v0.1

The OCOM Specification defines the following core concepts. Each is defined normatively in the Core Vocabulary; this section only lists and links them.

_References: [Object](/vocabulary/object), [Identity](/vocabulary/identity), [Metadata](/vocabulary/metadata), [Relationship](/vocabulary/relationship), [Reference](/vocabulary/reference), [Registry](/vocabulary/registry), [Classification](/vocabulary/classification), [Capability](/vocabulary/capability), [Contract](/vocabulary/contract), [Policy](/vocabulary/policy), [Constraint](/vocabulary/constraint), [Ownership](/vocabulary/ownership), [Organization](/vocabulary/organization)_

### Architecture (SPEC-E5) — Informative v0.1

OCOM is memory-first: a single canonical knowledge model is the source of truth, and every publication — HTML, JSON, JSON-LD, Markdown, a knowledge graph, an API — is a deterministic projection of it, never a parallel source.
The graph, the registries and the retrieval API are all views of the same records, which is why they cannot drift apart.

_References: [Object](/vocabulary/object), [Relationship](/vocabulary/relationship)_

### Governance (SPEC-E6) — Informative v0.1

New core concepts are not added directly. A candidate is observed, reviewed, and only then proposed through a Reference Case and an Architecture Objection before any change is accepted.
Concepts the model refers to but has not yet defined are surfaced automatically as governance candidates rather than silently adopted.

_References: /governance/candidates_

### Conformance (SPEC-E7) — Informative v0.1

An implementation conforms to OCOM when every managed object satisfies the requirements of the Core Vocabulary terms it uses.
The normative conformance requirements are stated in the Normative Specification.

## Normative Specification

### Scope (SPEC-01) — Normative v0.1

This specification defines the OCOM Core Vocabulary and the rules governing its use. It does not mandate a serialization, storage engine, or query language.
Where this specification and the Core Vocabulary appear to differ, the Core Vocabulary term record is authoritative for that term's definition.

### Normative References (SPEC-02) — Normative v0.1

The definitions in the Core Vocabulary are normative and are incorporated by reference. This specification MUST NOT restate them.
Each term record carries its own status and version; a term is normative only at the status recorded in its record.

_References: [Object](/vocabulary/object)_

### Core Concepts (SPEC-03) — Normative v0.1

The OCOM Specification defines the following core concepts. Each is defined normatively and only in the Core Vocabulary; this section references them and does not define them.

_References: [Object](/vocabulary/object), [Identity](/vocabulary/identity), [Relationship](/vocabulary/relationship), [Reference](/vocabulary/reference), [Ownership](/vocabulary/ownership), [Policy](/vocabulary/policy), [Constraint](/vocabulary/constraint), [Contract](/vocabulary/contract)_

### Conformance (SPEC-04) — Normative v0.1

A conforming implementation SHALL assign every managed object a stable Identity, SHALL record its Metadata and Ownership, and SHALL preserve its Relationships and Lifecycle as required by the corresponding Core Vocabulary term records.
A conforming implementation SHALL NOT redefine a core term; it MAY extend the model through additional, clearly separated concepts.

_References: [Identity](/vocabulary/identity), [Metadata](/vocabulary/metadata), [Ownership](/vocabulary/ownership), [Relationship](/vocabulary/relationship)_

### Extensibility (SPEC-05) — Normative v0.1

OCOM favours extension over enumeration. Implementations MAY introduce domain concepts, provided they do not alter the meaning of a core term.
Extensions SHOULD reference the core terms they build upon so that the extended model remains traceable to the canonical source.

_References: [Classification](/vocabulary/classification), [Capability](/vocabulary/capability)_

## Informative Annexes

### Annex A — Comparisons (SPEC-A1) — Informative v0.1

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: [OCOM vs Knowledge Graph](/comparisons/knowledge-graph), [OCOM vs BPMN](/comparisons/bpmn), [OCOM vs Digital Twin](/comparisons/digital-twin), /comparisons_

### Annex B — FAQ (SPEC-A2) — Informative v0.1

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 adds governance, lifecycle and evidence.
Where are the definitions? Every definition lives once in the Core Vocabulary and is referenced everywhere else.

_References: /comparisons/knowledge-graph_

### Annex C — Examples (SPEC-A3) — Informative v0.1

Worked examples are drawn from the term records themselves rather than restated here; the Object term record, for instance, lists concrete examples of Objects.

_References: [Object](/vocabulary/object)_