Purpose
A first pilot exists to answer one question — does modeling our operations as OCOM Entities actually help — without betting the whole organization on the answer. Keep it small enough to finish in weeks, not quarters.
A pilot starts in a different place from a rollout. This document starts with one Domain the team already owns, because a pilot exists to test the idea cheaply. The Implementation Case (docs/Examples/Implementation-Case/) starts with identity across the whole organization, because a rollout has to reconcile the Domains a pilot deliberately leaves alone. The two are one sequence: a pilot is the first Domain of a rollout, and the identity work is what later turns several pilots into one model.
Suggested Shape
| Dimension | Suggested bound | Why |
|---|---|---|
| Team | 5–10 people | Small enough to agree on definitions without a formal process. |
| Domain | One | A Domain is a bounded area of responsibility by design (see Models/Domain.md) — a pilot should stay inside one. |
| Entities | 10–20 | Enough to be a real model, not so many that defining them becomes the whole project. |
| Events | A handful, only the significant ones | Events record facts, they do not need to capture everything from day one (see Models/Event.md). |
| KPIs | A small, obvious set | Just enough to notice whether the model reflects reality. |
What to Deliberately Leave Out
- Governance process —
docs/Governance/exists to govern how the specification itself evolves. A pilot team modeling its own Domain does not need to run that process; it only matters if you think you've found a gap in the Core (see Common Mistakes). - AI or Memory — neither is required to have a valid OCOM model. They are separate, optional layers (see
docs/Specification/03 Core Concepts.md, "What Is Deliberately Not Introduced Here"). - Cross-Domain integration — one Domain, one pilot. Relationships to other Domains can wait.
- Tooling and automation — a pilot can be a shared document. OCOM does not prescribe implementation technology (see
Core/Principles.md, Principle 6).
Suggested Steps
- Pick the one Domain your pilot team already owns.
- List the things that Domain manages. Keep only the ones with a clear owner and a clear lifecycle — that shortlist is your 10–20 Entities.
- For each Entity, write the minimal definition from
Getting Started.md§4: Identifier, Name, Domain, Owner, Attributes, State, Lifecycle. Owner is the one accountable party; anyone else responsible for part of the Entity is a further Ownership record, not a second Owner (seeMeta/Ownership.md, Shared Ownership). - Draw each Entity's Lifecycle as a small state diagram, four or five states.
- Name the two or three Events per Entity that actually matter to the business, not every possible occurrence.
- Pick one or two KPIs that would tell you, honestly, whether the model is useful.
- Run it for a few weeks against real work. See what breaks, what's missing, and what nobody actually looks at.
If your people report along two lines at once, a line manager and a functional lead, pick the Domain by responsibility, not by reporting line: a Domain organizes what the team is responsible for (see Models/Domain.md), and each Entity has exactly one primary Domain whatever the org chart says. The reporting lines themselves are not Domains; a person's line manager is the Manager attribute of the Employee Entity, and a second line is one further Relationship (see Entities/Department/Department.md). A department, a division or a business unit is a Department Entity, and a legal entity is an Organization; neither is a Domain (CAND-027).
What Success Looks Like
Not "we finished modeling the Domain." Success is: the team can point at the model and explain their own work more consistently than before, and they can name specific places where the model was wrong or incomplete. Both outcomes are useful — a pilot that surfaces real gaps is doing its job.
If a gap looks like it's in OCOM itself, rather than in how your pilot modeled it, that's a Reference Case — see docs/Governance/Standard Evolution Methodology.md, not something to solve by inventing new rules inside the pilot.
Where to go next
Site navigation added by the publication layer, not part of the canonical document. The four documents this page cites are not published here; they are linked in the repository.
- Getting Started, section 4: the minimal Entity definition this page asks you to write.
- Common Mistakes: the list to check a suspected gap against before calling it one.
- Standard Evolution Methodology: how a real gap becomes a Reference Case.
- How to Review: the nine questions, and how to file an objection.
- GitHub Issues: where an objection is filed.
- Evidence Register: what is and is not verifiable about use of OCOM today.
Show that you build on OCOM
Site section added by the publication layer, not part of the canonical document.
If your operating record follows the Core Vocabulary, you may say so. The badge links to the specification; it is not a conformance claim, and OCOM issues no certification.
HTML
<a href="https://ocom.uno" rel="noopener"><img src="https://ocom.uno/badges/built-on-ocom.svg" alt="Built on OCOM" height="20"></a>Markdown
[](https://ocom.uno)