PRIM.A compilerfor rules.
PRIM is a deterministic runtime for written rules. Give it a grammar and a state, and it will tell you whether that state is valid, which clause it violated, and how it can be repaired back into compliance.
- Deterministic execution
- Versioned state
- Convergent repair
- Structured violations
- Explicit terminal states
Rules exist as text.
The systems that enforce them, usually don’t.
Most software that enforces rules does so with scattered validation code, lookup tables, or institutional memory held by individual people. The rules themselves live in one place, the enforcement logic in another, and the connection between them is ad-hoc.
PRIM gives the rules an executable form. Each clause becomes a constraint class, each check the engine runs points back to the clause that wrote it, and the runtime evaluates them deterministically. A sporting code becomes a versioned library of constraints, authored clause by clause and maintained the way any regulated codebase is.
One source of truth. One place the enforcement lives.
A constraint
is a function.
Takes the state, the action, and the next state. Returns a list of violations. Never mutates. Only judges. Every constraint is a pure function of those three inputs.
A real constraint · checks transition validity, never mutates
Every concept
has an equivalent.
If you have thought about how a compiler works, you already understand PRIM. The machinery is the same, only the substrate has changed. Code becomes clauses. Types become constraints. Stack traces become structured violations with article pointers.
Real type · engine_core/types.py
Not a human string.
Machine-readable.
When the engine says something is invalid, it returns the exact field that failed, the category of failure, and a structured payload the client can route. A violation is an API, not a log line.
Every state
has a hash.
States are serialised into canonical JSON (sorted keys, no whitespace) and hashed with SHA-256. Same data produces the same hash, regardless of representation. Two snapshots with identical content have identical identities.
The audit trail is a chain of these hashes. Replay any decision from any point by loading its predecessor state. Content-addressable, the way Git treats commits.
Content-addressable state · reproducible audit chain
Three layers,
strictly separated.
The engine at the bottom. Orchestration in the middle. Adapters on top. Nothing leaks between them, so a new domain plugs in without touching the core, and the core ships updates without breaking any deployed domain.
Deterministic execution
≈ the type-checker and execution unit
- Deterministic action execution
- State validation against constraints
- Structured violation reporting
- State identity hashing
Lifecycle and memory
≈ the linker, scheduler, and transaction manager
- Session lifecycle and phase transitions
- Repair escalation paths
- State versioning and mutation contracts
- Concurrency control and audit trails
Pluggable grammars
≈ domain-specific compiler plugins
- Phases, completion logic, mutations
- Repair candidates from the catalog
- Domain-specific invariants
- Core stays generic; the adapter defines the field
What the runtime
holds true.
These are architectural guarantees, baked into the engine core. Not aspirations, not feature requests.
Convergent repair
Repair steps reduce the number of open violations. Each step is validated before it executes, so repair loops always terminate.
Explicit terminal states
Every session ends in one of a finite set of named terminal states. No ambiguous limbos, no orphaned sessions, no "unknown" as an outcome.
Thin clients
Clients request, display, and relay. They never carry hidden logic or guess at state. The engine is the source of truth.
Watch the engine
process one decision.
Every step is logged, sourced, and reconstructable. The trace below is what the runtime emits under the hood.
Any field
with a written framework.
The engine does not care what the rules say, only that they are written down. Trip planning is where the engine was stress-tested; motorsport is where it first meets the world. The others are proofs the pattern generalizes.
Sport governance
Officiating decisions, penalty validation, precedent tracking across rotating panels. Motorsport is the first we’re building.
Trip planning
A multi-day itinerary built step by step against a real movement graph, activity registry, and fatigue budgets. Each proposed step is a transition the engine validates. The most built-out PRIM adapter to date.
Financial compliance
Transaction validation, threshold monitoring, and jurisdictional rule enforcement against written policy.
Emergency response
Protocol step validation, escalation rules, and policy enforcement under time-critical constraints.
Precise boundaries.
Neither more nor less.
The engine is designed for a specific shape of problem. Knowing what it is not is as important as knowing what it is.
- A deterministic runtimethat validates actions against a grammar
- A constraint checkerreturning structured violations with JSON pointers
- A domain-agnostic corewith pluggable adapters per field
- A versioned state machinewith content-addressable identity hashes
- An audit-first systembuilt for regulatory governance
- Not a rules engineno scripting DSL, no forward-chaining inference
- Not a constraint solverno optimisation, no SAT or SMT backend
- Not a workflow enginevalidates the actions humans or systems propose, does not orchestrate them
- Not a databasepersistence is the host’s job; PRIM runs in-process
- Not a probabilistic modelno weights, no training, no hidden state
See the engine
in motorsport, first.
Sport governance is where PRIM meets the world first. Motorsport is the first we’re building.