Normative Specification

Introduction SPEC-01

Draft v1.0 docs/Specification/01 Introduction.md

Abstract

OCOM (Object-Centric Operating Model) is an open, technology-independent operating model for organizations, describing organizations through entities, domains, workflows, and their relationships. Core/Manifest.md defines the modeling framework through which that operating model is expressed. This reading path compiles that framework and the canonical documents built on it; it is not OCOM itself, whose normative terms live in the Core Vocabulary (Meta/) and the canonical documents cited at the end of each chapter.

The framework provides a common operational language that enables consistent understanding by humans, software systems, and artificial intelligence while remaining independent of implementation technologies, vendors, organizational structures, and industries.

Purpose

The purpose of this specification is to establish a universal operational language for describing how organizations function.

Rather than treating software systems, departments, or business processes as primary concepts, the framework models the organization itself through a consistent set of operational concepts and relationships.

The specification provides a stable foundation for documentation, analysis, governance, automation, and future operational development.

Vision

Organizations should be described independently of the technologies used to operate them. Operational knowledge should remain stable as software platforms, organizational structures, and implementation details evolve. Humans and artificial intelligence should be able to interpret the same operational model consistently.

Motivation

Operational knowledge is commonly distributed across documents, applications, teams, and software platforms. As organizations evolve, this knowledge often becomes fragmented, duplicated, inconsistent, and difficult to maintain.

Existing approaches usually describe isolated perspectives such as business processes, organizational structures, databases, or software architecture rather than the operational system as a whole. This specification introduces a unified operational model capable of representing an organization through consistent operational concepts and relationships.

Guiding Statement

Organizations are not defined by their software. They are defined by the operational relationships between the entities that create, transform, exchange, and preserve business value.

This specification provides a common operational language for describing those relationships independently of implementation.

Core Objectives

This specification aims to:

• establish a common operational vocabulary;
• improve consistency across operational models;
• reduce ambiguity in organizational documentation;
• support interoperability between operational systems;
• enable AI-assisted analysis and automation;
• provide a stable foundation for future operational standards.

Design Goals

The framework is designed to be:

• technology-independent;
• implementation-independent;
• vendor-neutral;
• extensible;
• deterministic;
• human-readable;
• machine-readable;
• AI-native.

Applicability

This specification may be applied to organizations of any size and across any industry. The framework is intended for operational modeling and may be adopted regardless of existing organizational structures, software platforms, or implementation technologies.

Scope

This specification defines:

• operational concepts;
• entities;
• domains;
• workflows;
• operational relationships;
• modeling principles;
• semantic interpretation rules.

This specification does not define:

• software architecture;
• databases;
• APIs;
• programming languages;
• user interface design;
• infrastructure;
• implementation technologies;
• business strategy;
• professional or expert judgments (legal, compliance, financial, or similar);
• the responsibilities of an organization's specialized functions (Legal, Compliance, Finance, Security, HR, and others), per Constitution Principle 14, Professional Responsibility.

Design Philosophy

The framework is based on several fundamental ideas. Organizations are composed of interacting entities. Domains define responsibility. Workflows transform entity states. Knowledge belongs to entities. Software implements the operational model but does not define it, per Constitution Principle 13, Adaptation Flows Toward the Model. Operational models should remain understandable by both humans and artificial intelligence.

Intended Audience

This specification is intended for:

• Enterprise Architects;
• Operations Leaders;
• Solution Architects;
• System Designers;
• Business Analysts;
• Product Organizations;
• Software Engineers;
• AI Engineers;
• Researchers.

Normative Language

Core/Manifest.md's "Normative Language" section is the single authoritative definition of MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY for this entire specification, including this reading path, and of the lowercase forms the canonical documents use. It is restated here, verbatim, for reader convenience; this chapter does not define these terms independently, and any future change to their meaning is made in Core/Manifest.md, not here:

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY, when they appear in all capitals in this document, and in every document of this specification, are to be interpreted as described in RFC 2119, as amended by RFC 8174:

• MUST indicates an absolute requirement.
• MUST NOT indicates an absolute prohibition.
• SHOULD indicates a recommended practice.
• SHOULD NOT indicates a practice that is generally discouraged.
• MAY indicates an optional capability or implementation choice.

This is the single authoritative definition of these key words for the entire specification. Independently of RFC 8174's own all-capitals restriction, this specification additionally extends the same defined meanings to the lowercase forms (shall, shall not, should, may, and the forms must and must not as used in Core/Constitution.md — the convention already used throughout Meta/, Models/, Core/, and Language/): a document using a lowercase form intends the same normative weight as its uppercase equivalent above, by this specification's own convention, not because RFC 8174 itself extends that far. Any document restating this definition, rather than citing it, is a duplication to be corrected, not a second source.

Chapters 2 to 8 use the lowercase forms under that convention.

How to Read This Specification

This document is the second of nine parts that together form the OCOM Specification v1.0 reading path:

0. Executive Overview (informative, non-technical)
1. Introduction (this document)
2. Design Principles
3. Core Concepts
4. Meta Model
5. Object Model
6. Lifecycle Model
7. Governance
8. Conformance

The v1.0 reading path is compiled from Constitution 1.0.1, the Core Vocabulary 0.1 (13 governed terms) and the canonical documents as they stand on 17 September 2026; the Release that publishes it names the exact commit in Governance/Publication-Manifest.md. Each concept introduced in Chapters 3 to 8 is defined in full, with complete normative detail, in the granular reference documents under docs/Meta/, docs/Models/, docs/Language/, and related sections. This reading path is a compilation and editorial layer over that material, not a replacement for it: every statement here is traceable to a source document, cited at the end of each chapter. The granular documents remain the normative source of truth and continue to evolve independently of this reading path.

Relationship to the Constitution

Since 26 July 2026, when CAND-006 adopted it, the specification is governed by Core/Constitution.md (Core-00, recorded there on 27 July 2026, version 1.0.1 since 11 September 2026). Its fourteen Canonical Principles govern every document of the specification, this reading path included. This reading path compiles the canonical source documents named at the end of each chapter and does not compile the Constitution; Chapter 2 cites the Constitution where a Design Principle is canonically stated there. Where this reading path and the Constitution differ, the Constitution and the canonical source documents govern, per Governance/Publication-Model.md. An Architecture Freeze (CAND-007, 27 July 2026) is in force; Chapter 7 states what it means for changes to the specification.

Future Evolution

This specification is intended to evolve through successive versions while preserving conceptual consistency. Future revisions may introduce new concepts, models, and extensions without changing the fundamental principles established by this specification.

Revision History

Source: compiled from Core/Manifest.md, with its Abstract, Purpose, Vision, Motivation, Guiding Statement, Core Objectives, Design Goals, Applicability, Scope, Design Philosophy, Intended Audience and Future Evolution sections carried verbatim (single-sentence paragraphs joined where the chapter groups them; the two Constitution references in Scope and Design Philosophy are written as "Constitution Principle 14" and "Constitution Principle 13" where the Manifest writes the section sign). The Normative Language section is quoted verbatim from Core/Manifest.md's own "Normative Language" section, which is the specification's single authoritative source for these key words (see Governance/Publication-Model.md); this chapter restates it, it does not independently define it. (Committee Review, 22 July 2026: minor wording fixes to the Intended Audience list and the Chapters 3–8 cross-reference; no normative change.) (21 August 2026: Abstract reworded to lead with the canonical identity statement used consistently across ocom.uno, llms.txt, and Core/Manifest.md, and to state explicitly that this Specification is a compiled reading path over OCOM, not OCOM itself — semantic positioning only, no normative change.) (16 September 2026: added Relationship to the Constitution, per Master-Architecture-Backlog.md EPIC-F; no requirement changed) (16 September 2026: adoption date stated as 26 July 2026 per CAND-006) (17 September 2026: recompiled as v1.0 against Core/Manifest.md as of this date; see Revision History)

Design Principles SPEC-02

Draft v1.0 docs/Specification/02 Design Principles.md

These principles are normative and apply to every model created using this specification.

1. Organization Before Technology

Operational models describe organizations independently of software, platforms, vendors, and implementation technologies. Technology implements the model but never defines it.

2. Entity-Centric Modeling

Object is the universal abstraction of the operational model (Constitution §1). Entity is a specialization of Object. Every operational concept shall be represented through identifiable entities. Entities are the primary building blocks of the operational model.

3. Explicit Ownership

Every entity shall have a clearly defined owner responsible for its lifecycle, integrity, and operational consistency. Ownership shall never be implicit.

4. State-Based Operations

Operational activities exist to transform entity states. Every significant operational change should be represented as a state transition.

5. Domain Responsibility

Responsibilities belong to domains. Domains define accountability, governance, and operational boundaries.

6. Separation of Model and Implementation

Implementations adapt to the operational model; the operational model never adapts to implementation-specific constraints (Constitution §13). The operational model shall remain independent of software architecture, databases, APIs, programming languages, and infrastructure. Implementations may change without changing the operational model.

7. Single Source of Truth

Each operational concept shall have a single authoritative definition within the model. Duplicate definitions should be avoided.

8. Semantic Consistency

Equivalent concepts shall be modeled consistently throughout the specification. Naming, behavior, and relationships should remain predictable.

9. AI Interpretability

Operational models should be understandable by both humans and artificial intelligence without requiring implementation-specific knowledge.

10. Evolvability

The framework shall support organizational evolution without requiring redesign of the underlying operational model.

11. Separation of Professional Responsibility

This principle is canonically stated in Constitution §14 — Professional Responsibility (Core/Constitution.md). OCOM deliberately separates the management of operational memory from professional expertise. OCOM is responsible for Operational Memory, the Object Model, Knowledge Management, Context Preservation, Workflow Coordination, Decision Tracking, and Action Tracking. Professional functions of the organization — including Legal, Compliance, Finance, Security, and HR — are responsible for expert judgments and decisions within their domains. OCOM shall not substitute for professional expertise; it supports that expertise through structured operational memory.

Conformance

All models created using this specification shall conform to these principles.

Revision History

Source: compiled from Core/Principles.md, verbatim, including principle titles. (Committee Review, 22 July 2026: an earlier draft retitled Principle 9 to "Interpretability"; the Architecture Committee directed reversion to the source title, on the basis that retitling a sourced principle is an architectural judgment requiring an ADR, not an editorial choice.) (4 September 2026: resynchronised with Core/Principles.md after Principle 11 (ADR CAND-003, 23 July 2026) and the Constitution cross-references in Principles 2 and 6 (CAND-006) were added to the source; editorial recompilation, no content of its own.) (17 September 2026: recompiled as v1.0 against the canonical documents as of this date; see Revision History)

Core Concepts SPEC-03

Draft v1.0 docs/Specification/03 Core Concepts.md

Purpose

This chapter orients the reader before the detailed Meta Model (Chapter 4) and Object Model (Chapter 5). It introduces, at a glance, the concepts that everything else in this specification is built from.

Object

Object is the universal abstraction within OCOM. It is an identifiable and governable element that exists within the operational model — something that can be described, managed, related, evaluated, or governed throughout its lifecycle, independently of implementation technology or business domain.

All managed concepts defined by this specification — Entity, Organization, Domain, Workflow, Event, Lifecycle, Policy, Contract, and others — are specializations of Object.

Entity

Entity is the primary operational construct built from Object. Every operational model defined by this specification is composed of entities and the relationships between them. An entity possesses identity, belongs to exactly one primary Domain, has defined ownership, contains attributes, defines one or more states, and follows a lifecycle.

Domain

Domain is an operational boundary responsible for governing one or more entities. A Domain organizes responsibility rather than organizational structure — it represents what is governed, not who performs the work.

Relationship and Reference

Relationship is a governed, semantic association between Objects — it expresses meaning ("Campaign targets Player"). Reference is a directed association that identifies a target Object without carrying semantic meaning. The two are deliberately distinct: a Reference is a pointer, a Relationship carries business meaning.

Lifecycle, State, and Event

State is a discrete operational condition describing an entity's status at a point in time. Lifecycle is the complete set of states and permitted state transitions that define an entity's operational existence — every entity has exactly one. Event is an immutable record of something that has occurred; events describe facts and do not themselves define behavior.

Workflow

Workflow is a structured sequence of operational activities that performs defined state transitions. Where Relationship and Event describe structure and facts, Workflow represents behavior.

Capability, Policy, and Contract

Capability is a governed description of an ability possessed or provided by an Object — potential functionality, not a specific execution. Policy is a governed set of rules that defines expected behavior or constraints applicable to one or more Objects. Contract is a governed agreement between two or more Objects specifying the conditions under which they interact.

How These Concepts Relate

Object
  |
  |-- is specialized by ----> Entity, Organization, Domain, Workflow, Event,
  |                            Lifecycle, Policy, Contract, Registry, ...
  |
  |-- is described by ------> Identity, Metadata, Classification, Ownership
  |
  |-- is connected by ------> Relationship (meaningful) / Reference (structural)
  |
  `-- is governed by -------> Policy, Constraint, Contract

An Entity belongs to a Domain, follows a Lifecycle expressed through States, is affected by Events, participates in Relationships with other Entities, and may be acted upon by Workflows.

What Is Deliberately Not Introduced Here

This reading path compiles the Meta Model, the Object Model and the Lifecycle Model (Chapters 4 to 6). Memory, Knowledge, Context and AI Agents are defined in their own sections of the repository (docs/Memory/, docs/AI/) and are governed by Core/Constitution.md; they are outside this reading path, neither prerequisites for Chapters 4 to 6 nor extensions of them. Runtime and execution semantics are not defined by the Core. Core Conformance (Chapter 8) is defined over Chapters 4 to 6.

Revision History

Source: synthesized from Meta/Object.md, Meta/Relationship.md, Meta/Reference.md, Meta/Capability.md, Meta/Policy.md, Meta/Contract.md, Models/Entity.md, Models/Domain.md, Models/Relationship.md, Models/Event.md, Models/State.md, Models/Lifecycle.md, Models/Workflow.md, Meta/Organization.md, Core/Constitution.md. No new concepts introduced. (17 September 2026: recompiled as v1.0 against the canonical documents as of this date; see Revision History)

Meta Model SPEC-04

Draft v1.0 docs/Specification/04 Meta Model.md

Purpose

The Meta Model defines the foundational, technology- and domain-independent abstractions shared across the entire specification. Every other document — Object Model, Domain profiles, Reference Architecture — is built on these definitions without redefining them.

Object — The Universal Abstraction

An Object is an identifiable and governable element that exists within the operational model. Objects are independent of implementation technologies and business domains.

Every Object is defined by these core characteristics: Identity, Metadata, Classification, Relationships, Lifecycle, Ownership, Governance. Objects may additionally support Evaluation, Versioning, Capabilities, Policies, Contracts, and Constraints.

Note on terminology. "Governance" here means the oversight and accountability applied to an individual Object. Chapter 7 uses the same word for a different, unrelated sense: how the OCOM Specification itself evolves over time. The two are not connected.

Architectural Role: Object is the universal abstraction within OCOM. All managed concepts defined by the specification — including Entity, Organization, Domain, Workflow, Event, Lifecycle, Policy, Registry, and Contract — are specializations of Object. Specifications may extend Object but shall preserve its core characteristics.

Organization

An Organization is an identifiable and governable Object that represents an independent participant within the operational ecosystem: an operating company, a partner, a supplier, a customer organization or a regulator, for example. It is not a subdivision of another Object, not a Domain, not a legal or regulatory term and not an organizational chart structure. Organization is a specialization of Object at the same architectural level as Entity, Domain, Workflow, Event, Policy and Contract; it is not a container for other Objects, does not sit above Domain or Entity, and connects to other Objects exclusively through ordinary, governed Relationships. It shares the core characteristics defined for Object and defines no additional characteristics, Relationship Types or Ownership rules of its own; where such rules are required they are addressed through the OCOM governance process (CAND-005).

Identity

Identity is the persistent and unique representation of an Object. Identity distinguishes one Object from all others regardless of changes to its metadata, state, relationships, or implementation, and shall remain stable throughout the Object's lifetime.

Metadata

Metadata is structured information describing the characteristics, context, or management attributes of an Object. It supplements an Object but does not define its identity or operational state.

Classification

Classification is the assignment of one or more descriptive categories to an Object, enabling grouping, filtering, governance, and operational organization without altering the Object's identity.

Relationship and Reference

A Relationship is a governed semantic association between Objects — it expresses how Objects are connected within the operational model and, unlike a Reference, conveys business meaning. Every Relationship defines an Identifier, Source Object, Target Object, and Relationship Type; it may additionally define direction, cardinality, status, and constraints.

A Reference is a directed association from one Object to another. A Reference identifies a target Object but does not define the semantic nature of the association — that meaning, if any, is defined separately by Relationship.

Capability

A Capability is a governed description of an ability possessed or provided by an Object. Capabilities represent potential functionality rather than specific executions, and may support one or more business objectives.

Policy

A Policy is a governed set of rules defining expected behavior or constraints applicable to one or more Objects. Policies express organizational intent independently of implementation technology, and may be mandatory, recommended, or optional.

Contract

A Contract is a governed agreement between two or more Objects. It specifies the conditions under which participating Objects interact, exchange information, perform activities, or provide Capabilities — the rules governing an interaction, not the interaction itself.

Constraint

A Constraint is a governed condition that restricts or requires specific characteristics, states, or behaviors. A Constraint defines what must remain true, not how it is enforced.

Ownership

Ownership is the assignment of responsibility for one or more managed Objects — the individual, team, organizational unit, or system accountable for governing an Object during all or part of its lifecycle. Ownership does not necessarily imply authorship or implementation responsibility.

Registry

A Registry is a managed collection of identifiable Objects, organized according to defined governance rules, providing controlled access while preserving identity, traceability, and operational consistency.

Conformance

A compliant implementation shall ensure that every managed Object possesses a unique identity, supports metadata, can participate in relationships, supports governance, preserves traceability, and remains technology independent.

Revision History

Source: compiled from Meta/Object.md, Meta/Organization.md, Meta/Identity.md, Meta/Metadata.md, Meta/Classification.md, Meta/Relationship.md, Meta/Reference.md, Meta/Capability.md, Meta/Policy.md, Meta/Contract.md, Meta/Constraint.md, Meta/Ownership.md, Meta/Registry.md. Full detail — including Design Principles, Auditability, and Independence clauses for each concept — remains in those source documents; this chapter is a normative summary, not a replacement. (Committee Review, 22 July 2026: added a terminology note disambiguating "Governance" from Chapter 7's unrelated use of the same word; no definition changed.) (16 September 2026: added Organization, compiled from Meta/Organization.md, and named that document in this Source line, per AO-065; no definition changed) (17 September 2026: recompiled as v1.0 against the canonical documents as of this date; see Revision History)

Object Model SPEC-05

Draft v1.0 docs/Specification/05 Object Model.md

Purpose

Where the Meta Model (Chapter 4) defines the abstract vocabulary, the Object Model defines the normative structure that vocabulary takes when used to build an operational model. A Model is an organized collection of Entities, Domains, Relationships, States, Lifecycles, Workflows, and Events that together describe an operational system — representing operational reality, not software implementation.

Entity

An Entity is a specialization of Object and the primary operational construct of this specification: an identifiable operational object that represents something with business meaning, existing independently of software implementations.

Every Entity shall:

• possess a unique identity;
• have operational meaning;
• belong to exactly one primary Domain;
• have defined ownership;
• contain attributes (each with a name, meaning, data type, and optional constraints);
• define one or more states;
• define a lifecycle;
• participate in relationships;
• be governed by the rules of this specification.

The minimum conforming Entity consists of: Identifier, Name, Domain, Owner, Attributes, State, Lifecycle.

An Entity shall not exist without identity, without ownership, without a lifecycle, belong to multiple primary Domains, or have ambiguous meaning.

Domain

A Domain is an operational boundary responsible for governing one or more Entities. A Domain organizes responsibility rather than organizational structure — it represents what is governed, not who performs the work. A Domain may govern multiple Entities; primary governance shall not be shared between Domains, and relationships between Domains define cooperation but do not transfer governance.

Relationship

A Relationship is an explicit operational association between two or more Entities. It defines structural connections and does not itself represent operational behavior. Every Relationship shall connect identifiable Entities, have a defined type, and define cardinality; direction shall be explicit whenever operational meaning depends on it. A Relationship shall not connect undefined Entities, have ambiguous meaning, duplicate another Relationship without justification, or exist without a defined type. This chapter's Relationship specializes the Relationship defined in Meta/Relationship.md, whose participants are Objects, for the case in which every participant is an Entity; a Relationship with a participant that is not an Entity, including an Organization, is governed by Meta/Relationship.md (CAND-016).

Editorial note. Meta/Relationship.md (Chapter 4) frames Relationship in terms of the business meaning it conveys ("unlike a Reference, a Relationship conveys business meaning"), while Models/Relationship.md (this chapter) frames it as a structural connection that "does not represent operational behavior." Read together, these are not stated as contradictory in the source documents — meaning and behavior are different properties, and a structural connection can still carry business meaning without describing behavior. This chapter records the difference in emphasis rather than resolving it, per editorial policy: apparent tensions between source documents are flagged, not corrected, in this reading path.

Editorial note (17 September 2026). The difference recorded above was settled on 16 September 2026 by CAND-016: Meta/Relationship.md is the canonical definition of Relationship and Models/Relationship.md its specialization for Entity participants, as the paragraph above now compiles from the latter's Purpose. The earlier note is kept as the record of what this reading path flagged.

Event

An Event is an immutable record describing something that has occurred within the operational model. Events describe facts; they do not define behavior and do not replace state.

State

A State is a discrete operational condition describing an Entity's status at a specific point in time. Every Entity exists in exactly one State at any given moment unless explicitly defined otherwise.

Workflow

A Workflow is a structured sequence of operational activities that performs defined state transitions according to the rules of this specification. A Workflow represents behavior rather than structure — the counterpart to Relationship (structure) and Event (fact).

Relationship to the Meta Model

An Entity is a specialization of Object as defined by the Meta Model. It shares the Identity, Ownership, Relationship, and Lifecycle principles defined for Object, and extends them with the Domain, Attributes, and State requirements defined in this chapter.

Conformance

An Entity, Domain, Relationship, Event, State, or Workflow conforms to this specification only if all mandatory requirements defined for it are satisfied.

Revision History

Source: compiled from Models/Model.md, Models/Entity.md, Models/Domain.md, Models/Relationship.md, Models/Event.md, Models/State.md, Models/Workflow.md. The Entity↔Object cross-reference reflects the explicit link added to Models/Entity.md during v0.1 stabilization. (Committee Review, 22 July 2026: "shall never," inherited verbatim from Models/Entity.md, normalized to "shall not" to match Chapter 1's keyword glossary; no requirement changed.) (17 September 2026: recompiled as v1.0 against the canonical documents as of this date; see Revision History)

Lifecycle Model SPEC-06

Draft v1.0 docs/Specification/06 Lifecycle Model.md

Purpose

This chapter defines how Entities change over time. It sits between the structural Object Model (Chapter 5) and the sections outside the Core chapters (1 to 8) that apply the Core to concrete scenarios: docs/Domains/, docs/Entities/, docs/Lifecycles/, docs/Examples/, docs/Workflows/ and docs/Reference Architecture/, which the Committee Review of 22 July 2026 called Reference Material. Each of those carries its own Status field, Draft (normative) or Informative, per Governance/Documentation-Standards.md. Lifecycle itself is normative; specific lifecycle patterns (Commercial, Financial, Operational, ...) are illustrations of it.

Definition

A Lifecycle is the complete set of States and permitted State Transitions that define the operational existence of an Entity. Every Entity shall have exactly one Lifecycle. A Lifecycle is a reusable operational model describing the allowed States and valid State Transitions of an Entity; it defines how an Entity evolves over time while preserving operational consistency.

Editorial note (18 September 2026). The source documents diverge on Lifecycle cardinality. Models/Lifecycle.md requires every Lifecycle to "belong to exactly one Entity"; Lifecycles/Lifecycles.md requires every Lifecycle to "be reusable by multiple Entities" and states that "Multiple Entities may share the same Lifecycle". This chapter states the Entity-side rule, that every Entity shall have exactly one Lifecycle, and the reuse sentence; it does not resolve the divergence, which is recorded as AO-028. No requirement changed.

States

A Lifecycle shall define one and only one initial State, and may define one or more terminal States; a terminal State represents the completion or permanent termination of the Entity Lifecycle. Each State shall have a unique meaning within the Lifecycle. At any point in time an Entity shall occupy exactly one valid State defined by its Lifecycle.

Transitions

A Transition defines movement from one State to another. Transitions shall be explicitly defined; undefined transitions are invalid. A Lifecycle shall not contain multiple initial States, contain unreachable States, contain undefined Transitions, or permit ambiguous State progression.

Lifecycle Ownership

Every Entity shall belong to exactly one primary Domain, and the Domain governs ownership, responsibility, and operational rules (Models/Entity.md). A Domain's responsibilities include ensuring lifecycle governance, and primary governance shall not be shared between Domains (Models/Domain.md).

Events and Lifecycle

An Event is an immutable record describing something that has occurred within the operational model; Events do not define behavior (Models/Event.md). A State does not define how transitions occur; transitions are defined by the Entity Lifecycle (Models/State.md). Which transitions are valid is therefore the Lifecycle's role alone.

Relationship to Domain-Specific Lifecycle Patterns

This chapter defines Lifecycle as a primitive. The specification's Reference Material demonstrates typical lifecycle patterns for recurring business scenarios — for example, a Commercial Lifecycle or a Campaign Lifecycle with states such as Draft, Approved, Active, Completed, Suspended, or Cancelled. Those patterns apply this chapter's rules; they do not extend or modify them.

Conformance

A Lifecycle conforms to this specification only if all mandatory requirements defined in Models/Lifecycle.md are satisfied, among them that no State it defines is unreachable and that no Transition is undefined.

Revision History

Source: compiled from Models/Lifecycle.md, Models/State.md, Lifecycles/Lifecycles.md, Models/Entity.md, Models/Domain.md, Models/Event.md. Domain-specific lifecycle patterns (Commercial, Financial, Operational, Organizational, Content) remain in docs/Lifecycles/ as Reference Material, per the Part I / Part II separation established for v0.2. (Committee Review, 22 July 2026: added an inline definition of "Reference Material" at first use, per committee direction; no source document changed.) (17 September 2026: recompiled as v1.0 against the canonical documents as of this date; see Revision History)

Governance SPEC-07

Draft v1.0 docs/Specification/07 Governance.md

Purpose

This chapter defines how the OCOM Specification itself evolves over time — not how Objects within an OCOM model are governed (that is Policy, Ownership, and Constraint, defined in Chapter 4).

Note on terminology. Chapter 4 uses "Governance" for a different, unrelated sense: the oversight and accountability applied to an individual Object. The two are not connected.

Objectives

Governance ensures that the specification remains consistent, stable, extensible, and implementation-independent.

Change Principles

Changes to the specification shall:

• preserve conceptual consistency;
• avoid unnecessary complexity;
• maintain backward compatibility whenever practical.

Proposal Process

Proposed changes should include motivation, rationale, expected impact, and a compatibility assessment.

Approval

Normative changes require review before becoming part of the specification. Architectural decisions are recorded and their context, alternatives, and consequences preserved — not left to reside only in discussion.

Operational Governance

The principles above are carried out through a dedicated Governance process, maintained independently of the normative Core:

• a documentation debt register separates real problems from consciously deferred decisions;
• architectural observations are recorded, not resolved, by whoever notices them — resolution is a separate, accountable step;
• proposed decisions are queued and explicitly decided, not made informally;
• a knowledge map keeps the relationships between sections traceable;
• documentation standards, release readiness, and architecture health are tracked continuously rather than assessed only at release time.

Governance Principles

Ten principles govern how the specification is maintained: Specification First; Architecture Before Implementation; Documentation Before Development; Traceability by Design; Decision Transparency; Continuous Quality; No Hidden Knowledge; Minimal Technical Debt; Version Integrity; Governance is Part of the Architecture.

Constitution and Architecture Freeze

Core/Constitution.md (Core-00), adopted through CAND-006 on 26 July 2026, recorded in Core/Constitution.md on 27 July 2026 and at version 1.0.1 since 11 September 2026, is the highest-authority document of the specification; it changes only by amendment recorded through the process above. Under the Architecture Freeze recorded as CAND-007 on the same day, no new Core concept, Canonical Principle or Domains subdomain enters the specification except through the pipeline of Governance/Standard Evolution Methodology.md: Reference Case, Observation, Repeated Pattern, ADR Candidate, Decision. Decisions on the candidates and observations already open on 27 July 2026, within their recorded scope, transcription of recorded decisions, and the work of Governance/Master-Architecture-Backlog.md remain permitted, as CAND-007 Section 3 lists.

Conformance

A change to this specification conforms to this chapter only if it has been proposed, reviewed, and approved through the process defined above, and its record is preserved.

Revision History

Source: compiled from Core/Governance.md (specification-evolution charter) and docs/Governance/Governance-Manifest.md (operational realization of that charter, established alongside this revision). (Committee Review, 22 July 2026: added a terminology note disambiguating "Governance" from Chapter 4's unrelated use of the same word; citing docs/Governance/ alongside Core/Governance.md was reviewed and confirmed acceptable, since docs/Governance/ is itself an approved Baseline.) (16 September 2026: added Constitution and Architecture Freeze, compiled from Core/Constitution.md, CAND-006 and CAND-007, per Master-Architecture-Backlog.md EPIC-F; no requirement changed) (16 September 2026, later the same day: adoption date stated as 26 July 2026 per CAND-006, recording date 27 July 2026) (17 September 2026: recompiled as v1.0 against the canonical documents as of this date; see Revision History)

Conformance SPEC-08

Draft v1.0 docs/Specification/08 Conformance.md

Purpose

Conformance establishes the criteria by which implementations may claim compliance with the OCOM Specification. It promotes interoperability, consistency, portability, and predictable behavior across independent implementations.

Definition

Conformance is the degree to which an implementation satisfies the normative requirements defined by this specification. Conformance applies to implementations, not to individual models.

Editorial note (5 September 2026). In this specification the adjectives conforming, compliant and conformant, when applied to an implementation, are used interchangeably and mean an implementation that satisfies the Mandatory Requirements of this document for the specification version it claims. (Source: Language/Conformance.md, Definition.)

Editorial note. Chapters 2, 5 and 6 state conformance conditions for models and model elements ("All models created using this specification shall conform to these principles"; "An Entity, Domain, Relationship, Event, State, or Workflow conforms to this specification only if ..."), while this chapter, following Language/Conformance.md, scopes conformance claims to implementations. Read together: an implementation makes the conformance claim, and the models it produces are required to satisfy Chapters 2, 5 and 6 as part of that claim. This chapter records the difference in scope rather than resolving it, per the editorial policy stated in Chapter 5; it is logged as an Architecture Observation.

Mandatory Requirements

A conforming implementation shall:

• implement the required language and structural constructs (Chapters 4–6);
• preserve their semantics as defined;
• support applicable validation;
• preserve identifier integrity and namespace consistency.

Optional Capabilities

The specification may define optional capabilities. Support for an optional capability shall not affect conformance unless a higher-level specification explicitly declares it mandatory.

Extension Conformance

Implementations may provide extensions. Extensions shall preserve compatibility with the core specification, avoid changing normative semantics, remain clearly identifiable, and be fully documented. Extensions shall not invalidate conformance with the core.

Conformance Levels

• Core Conformance — supports all mandatory requirements defined in Chapters 4–6.
• Extended Conformance — supports mandatory requirements together with documented extensions.
• Profile Conformance — supports a formally defined OCOM profile (a bounded, named subset or specialization of the specification) while preserving compatibility with Core Conformance.

Note on scope: Profile Conformance is defined by the form of a claimant's Profile Declaration, decided through CAND-002 on 16 September 2026 and grounded in docs/Governance/Concept-Paper-Profile-Conformance.md. A declaration names the claimant, pins a Release from docs/Governance/Publication-Manifest.md and that Release's commit, lists whole canonical source documents each with its content hash, contains every document Chapters 4 to 6 compile, adds nothing and restates nothing; OCOM publishes no profile and reviews, registers or certifies none. Chapters 4 to 6 remain the floor of every profile claim, consistent with the Non-Conformance clause below. The mechanics are kept in the Governance tier rather than folded into this chapter, consistent with the decision to keep set-scoped conformance a distinct discussion from the Core.

Non-Conformance

If an implementation does not satisfy one or more mandatory requirements, it shall not claim conformance with the corresponding version of this specification. Partial support may be documented without a conformance claim.

Version Conformance

An implementation shall identify the specification version against which conformance is claimed.

Independence

This chapter does not prescribe certification bodies, compliance programs, testing frameworks, or commercial products. Organizations remain free to establish their own conformance assessment processes.

Revision History

Source: compiled from Language/Conformance.md and the Conformance clauses of Core/Manifest.md and Core/Principles.md. The "Note on scope" reflects the explicit decision that set-scoped conformance remains a separate discussion from this Core reading path. (4 September 2026: editorial note added on the scope of conformance across Chapters 2, 5, 6 and 8; no requirement changed.) (16 September 2026: the Note on scope now points to the CAND-002 Decision and its grounding paper; no requirement changed) (17 September 2026: recompiled as v1.0 against the canonical documents as of this date; see Revision History)