The Six Primitives, Composed

If your operation is inferred — living in habits, spreadsheets, and the memory of whoever has been there longest — you already know what the problem feels like. What you might not have is a vocabulary for the alternative.

An authored system is built from six primitives. Not six modules. Not six product categories. Six things a company actually consists of, once you stop calling them by vertical-specific names and look at the shape.

The six

Policy. The rule. Declarative: what must be true, not how to make it true. "Every water-heater inspection closes with a pressure reading." "No kid checks into a class without a signed waiver on file." Policies hold intent. They are the part of the business you want enforced.

Procedure. The steps. How to do the thing the policy requires. Ordered, with gates. A procedure is the only level of the system that knows how. Policies don't. Procedures do.

Asset. The thing being acted on. A property. A piece of equipment. A job that exists for a window and then becomes history. Assets have state that is either good or not good, and the procedures change that state.

Actor. Who does the work. Human or not. An operator, an admin, a customer, or a system actor that makes automated decisions. Actors have qualifications and availability, and the ledger attributes every recorded action to one of them.

Trigger. What causes work to happen. A scheduled time. A condition being met. An occurrence in the world — a customer messaging, an operator marking complete, a sensor crossing a threshold. Triggers don't decide anything; they signal.

Ledger. The record. Immutable, queryable, structured. Every time a procedure runs, every time a gate passes or fails, every time a policy fires — the ledger has a row for it. The ledger is not a log file. It is the history of the business in a shape you can ask questions of.

Why this specific set

You could imagine other lists. Most operations tools have their own: projects and tasks, jobs and workflows, cases and actions. Those lists exist to match how the tool stores data. They do not match how a business actually works.

The test for whether a primitive earns its place is whether you can describe any real operation using only these six and nothing else. When you cannot, you have either a gap in the model or a vertical-specific concept that belongs in configuration, not in the engine. In two years of pressure-testing this list against gyms, property managers, lawn crews, and restaurants, nothing has forced a seventh primitive. Lots of things have tried — "project," "workflow," "route," "shift" — and each one turned out to be a specific shape of one of the six.

A project is a procedure with longer steps. A workflow is a policy chained to procedures. A route is an asset collection. A shift is a trigger window. The vocabulary collapses inward, not outward. That is the signal that the set is the right size.

How they compose

The primitives are not a list. They are a loop.

A trigger fires. A policy evaluates against it and decides what must be true. The policy names a procedure and names the actor (or constrains who can act). The actor runs the procedure against an asset. Every step writes to the ledger. The ledger is then readable by the next policy that wants to ask a question — has this procedure fired in the last 60 days? how often does this actor complete this step on time? what is the state of this asset's last inspection? — and that question can itself be a trigger for the next policy.

The loop closes. Triggers feed policies feed procedures feed the ledger feeds triggers. Nothing is outside the loop. There is no escape hatch for "stuff that happens but isn't captured."

A business that runs this way has a property most businesses do not: you can point at anything that happened, or failed to happen, and trace it back to a rule. Not a vibe. Not an intuition. A rule, by name, in plain English, that someone wrote on a specific day and can be edited today.

What the composition gives you

When the primitives are authored — when each one is explicit instead of inferred — the engine can do things the inferred version cannot:

• Route work, because assets know their hierarchy and actors know their qualifications.
• Escalate on time, because triggers and policies know what "on time" means for this specific rule.
• Surface gaps, because the ledger knows what should have happened and can compare it to what did.
• Onboard new actors, because the procedures they are supposed to run are written down with the gates already in place.
• Survive the person who has been running everything in their head, because that person's rules are now the business's rules.

None of that requires a new product category. It requires the six primitives to exist as structured data instead of tribal knowledge.

Where this goes next

The next piece — a day at Sabir Homes while the owner is in a lender meeting — is what it looks like when a real business has been running on these primitives for eight months. Forty-three authored policies. One admin who handles exceptions. An operation that does not pause when the owner steps out.

That is the promise. The primitives are what it is made of.