GLOSSARY
The Six Primitives
Every operation — all of them, always — decomposes into these six irreducible building blocks. Everything else is a composition. Nothing decomposes further. Nothing is missing.
Policy
The rule. Why something must happen. Policies are declarative — they state what must be true, not how to make it true. Policy is constraint, not intelligence.
Policies answer the questions your system must know from day one:
- "Can this operator take this job?" → assignment policy
- "Does this step require a photo?" → spot check policy
- "How many kids fit in a party slot?" → capacity policy
- "Does this critical finding need escalation?" → escalation policy
Procedure
The steps. How to do the thing. A procedure is a sequence of actions that satisfies a policy. Procedures are specific — they name the thing, the steps, and the order.
"Property Inspection — Unit Turnover" — condition check, photos, repairs flagged, manager sign-off, keys.
"Lawn Service — Full Visit" — arrive, assess, mow, edge, blow, photograph, complete.
Asset
The thing being acted on. An asset has state that can be good or not good. Not all assets are physical — some are ephemeral (a party booking, a job, a legal case). They exist for a window, then become historical.
A water heater. A property. An emergency room patient. A SaaS subscription. A consulting engagement.
Person
Who does the work. Three roles always emerge: the person doing it, the person overseeing it, the person paying for it. A person carries two dimensions: availability (when they can work) and qualifications (what they can do).
| Context | Doer | Overseer | Customer |
|---|---|---|---|
| Property | Steward | Manager | Homeowner |
| ER | Clinician | Charge Nurse | Patient |
| Lawn Care | Provider | Platform Ops | Homeowner |
Event
The trigger. What causes work to happen. Events don't just trigger individual procedures — they trigger chains of work. Event + Policy together are the operational brain.
Scheduled — Monday 8am. Quarterly. 30 minutes before close.
Condition-based — Member count > 45. Provider rating < 3.5. Coverage gap detected.
Occurrence-based — Customer books service. Provider marks complete. Injury reported.
Ledger
The record. Proof it happened. Every execution of every procedure writes to the ledger. The ledger is append-only. The ledger is the moat.
The ledger also feeds back into operations: policies can query the ledger to make decisions ("3 complaints in 30 days" requires reading historical entries). Over time, the ledger becomes the training set for cross-business intelligence.
What does "authored" mean?
An operation is authored when its rules, steps, people, things, triggers, and records are made explicit — written down by humans, named, and enforced by the system. Not guessed at. Not carried in someone's head. Not inferred from behavior after the fact.
The opposite of authored is inferred: policies that exist only because a senior person "just knows," procedures that vary by who's on shift, records that depend on someone remembering to write things down. Inferred operations work — until the person who holds the knowledge leaves, or scales, or makes a mistake.
The act of authoring is making the implicit explicit. Your operation already has all six primitives. Authoring means naming them.
The Flow
Events signal that something happened (or should happen).
Policies decide what to do about it.
Procedures define the work and execute the steps.
People do the work, on Assets.
The Ledger records everything.
The Ledger feeds back into Policy decisions.This is not a linear pipeline. It's a loop. Events fire. Policies evaluate constraints. The engine runs procedures. The ledger records outcomes. Those outcomes feed back into future policy decisions.