The operating model
Eighteen components. One loop. Two models.
The complete anatomy of a governed team — what every serious discipline discovers when failure matters, made explicit and configurable.
Why it converges
Five layers every tradition found
Military doctrine, IT service management, cybernetics, lean manufacturing, safety science, and nursing all arrived — independently — at the same skeleton: a purpose layer, a contract layer, a flow layer, a control layer, and a learning layer. That convergence is the strongest evidence the model is genuinely universal. Domondon Dominium is that skeleton, made configurable.
| Layer | Military | ITIL / Ops | Cybernetics | Lean | Nursing | Here |
|---|---|---|---|---|---|---|
| Purpose | Commander's intent | Guiding principles | System 5 | True north | Mission of care | Components 1–2 |
| Contract | Mission orders | Service catalog, SLAs | System 1 boundaries | Standard work | Scope of practice | Component 3 |
| Flow | OODA loop | Request flow | Systems 1–2 | Flow, takt | Nursing process | Components 4–7, 12–13 |
| Control | Rules of engagement | Change enablement | System 3/3* | Jidoka, andon | Delegation, clinical governance | Components 8–9, 14–17 |
| Learning | After-action review | Continual improvement | System 4 | Kaizen, PDCA | Evaluate / reflect | Component 18 |
The anatomy
The eighteen components
Mission / Mandate
Why the team exists — with an intent clause so people and agents can make a sane call when the SOP runs out.
Stakeholders
Served vs. governing stakeholders, plus a harm registry: who can be hurt, and how.
Service Catalog
What the team offers — every service born with a default risk tier, automation ceiling, evidence level, and gate.
Inputs / Demand
Structured, semi-structured, and ambient demand — the last is where work disappears.
Intake & Triage
The governance checkpoint of first contact: a request's risk profile is set here and travels with it for life.
Prioritization
P0–P4 plus Reject as a logged, first-class outcome — with a protection override and a defended slack reserve.
Workflows / SOPs
Standard work, versioned like code — each step declaring its automation level, role, evidence, and gate.
Roles & Ownership
A mixed human/agent roster with one invariant: every chain of work terminates in a named human.
Decision Rights
Five decision levels crossed with one-way/two-way doors; AI recommends anywhere, decides only at Level 1 under written rules.
Knowledge Base
Sources tiered by authority — governed, working, ambient — with staleness tracked and stewards named.
Data & Systems
A permission matrix (system × agent × action). A rule that lives only in a prompt is a hope; access scoping is a boundary.
Communication Rhythm
Closed-loop handoffs, SBAR-shaped briefs, flattened authority gradients — anyone can challenge a confident AI.
Task & Portfolio
Work tracked from task to portfolio, carrying its governance profile — so leaders see what high-risk work is ungated.
Quality Control
Quality built in-line (jidoka), with gates that are active, measured, and independent.
Risk & Governance
Tier the task, not the tool — plus an enumerated prohibited zone AI never enters autonomously.
Metrics
Performance plus governance health: gate disagreement, override frequency, boundary blocks — the vital signs of real governance.
Escalation
Andon rights for anyone (including the AI), graded assertiveness, the two-challenge rule, deference to expertise.
Learning Loop
Four asset classes improved on one cadence: SOPs, prompts, knowledge, and the governance rules themselves.
The spine
The universal operating loop
Every department runs the same loop; the AI OS makes each step explicit, governed, and logged. It is the same loop nursing calls ADPIE, aviation calls OODA, Toyota calls PDCA, and NIST calls govern–map–measure–manage. One loop, five confirmations.
→ Structure the request
→ Classify risk and work type
→ Retrieve relevant knowledge
→ Recommend next action
→ Route to owner
→ Support execution
→ Apply human gates
→ Log decisions
→ Measure outcome
→ Improve the system
The most important distinction
Two models, never merged
Separate the human operating model (who does what, who decides, who reviews, who is accountable, what is the standard, what is the risk) from the AI support model (what AI may observe, retrieve, draft, recommend, route, automate — and what it must escalate and log).
Design them together. Never merge them. The human model is sovereign; the AI model derives from it.
You do not discover who is accountable by asking what the AI can do. You discover what the AI may do by asking who is accountable.
Without this distinction, an AI OS is a loose chatbot layer. With it, it is an actual operating system.
The aha moment
When it clicks, it sounds like this
Eighteen components — and I could name where my team bleeds by component five.
Ambient demand. That's the hallway ask. That's where all our disappearing work lives.
Reject as a first-class, logged outcome. We've never once said no on the record — we just let requests die in the backlog and called it prioritization.
"Every chain of work terminates in a named human." I ran our org chart against that sentence and found four chains that end in fog.
Our SOPs are work-as-imagined. The night shift runs work-as-done. The gap isn't deviance — it's my improvement backlog.
We've been asking "what can the AI do?" The question was "who is accountable?" all along.
The same five layers in the military, Toyota, aviation, and nursing. This isn't someone's clever framework — it's what everyone finds when failure matters.
Recognized your team in one of these? The component that stung is where to start. Take the vital signs →