The rate book, the eligibility rules, the pricing logic: one executable artifact that is the spec your business reads, the oracle that computes expected answers with an audit trail, the brain of your mock, and the source of your test data.
Authored and maintained by AI agents through the same API that runs it. Graded by the engine, with no judge in the loop. Checked against the live system.
rule "youthful-driver-surcharge"
when driver_age < 25 && vehicle_class == "sport"
then premium += base * 0.35
guarantee "premium is never negative"
HOLDS 12,404 inputs enumerated
guarantee "discount never exceeds the cap"
VIOLATED
smallest breaking input:
{ tenure: 10, bundle: "home+auto", claims: 0 }
REQ-088 -> FAILING, release blockedThe Problem
The rate book lives in a vendor platform, a spreadsheet, and a veteran's head, all at once. The test cases live in another spreadsheet. Nobody can say whether the cases would notice a defect.
The document says one thing, the rules engine does another, and the gap is discovered by a customer, not a test.
Simulation runs the cases someone thought of years ago. It says nothing about whether those cases would catch a threshold that quietly moved.
Every expected premium in the test sheet was computed by a person, once, and has been trusted ever since.
The Rulebook
The rulebook is the executable twin of the decision logic. Everything readable is generated from it, so the readable views cannot desynchronize from the logic.
Plain-English prose, decision tables, and flowcharts are generated projections of the executable rules. The business reviews one readable artifact; there is no second document to fall behind.
For any input, the rulebook computes the expected answer and a plain-English audit of how it was reached, so a disagreement between test and system can be adjudicated, not argued.
The same rules drive your stateful test double, so consuming teams develop against real domain behavior instead of canned payloads.
Boundary, pairwise, and covering-array decks fall out of the rules, every row with its computed expected result and requirement link.
Agent-Authored, Engine-Graded
The same API that executes the rulebook authors it, with parse-validated writes and review-gated AI work. Then "done" is decided by the engine alone: no live system required, no human referee, no LLM grading its own homework.
An arm no data reaches is dead logic or a missing partition. An arm that can never fire is a defect in the rules themselves. Both are found by analysis, not luck.
Business invariants are checked by exhaustive enumeration over the input space, and a violation arrives with the smallest breaking input as its counterexample.
A defect is seeded into a copy of the rules and the worked examples replay. Survivors name the defects your scenarios would miss.
This is what makes rulebook authoring the cheapest agentic loop there is to trust: the grade is deterministic, so an agent can iterate against it all day and a human reviews one readable artifact at the end. Maintenance becomes a worklist the machine hands you, not an archaeology project. The mutation machinery is the same one that grades your API tests: API mutation testing.
The Release Gate
Guarantees feed the readiness verdict
A business-rule guarantee is not a warning in a log. "The discount never exceeds the cap" is wired to the requirement it protects, and when enumeration finds a violating input, that requirement fails in the release verdict with the counterexample attached. Whoever reviews the release sees the exact input that breaks the rule, not a stack trace.
The verdict is computed by versioned code with no model in the path. The AI can explain it; it cannot decide it.
See how the release verdict worksFidelity
A twin you never reconcile is a second opinion. This one is measured against production behavior, and divergence is the product, not the failure mode.
When the live system and the rulebook disagree, the audit trail adjudicates: the test is wrong, the system is buggy, or the rules are stale. Each outcome is a different work item, and the report says which one you have, tied to the requirement it violates.
Our Guidewire fixtures rate to the cent against live PolicyCenter across the modeled paths. The rate book in the rulebook and the rate book in production agree, and the agreement is re-checked on every run, not asserted once.
Where It Sits
BDD promised business-readable, executable, never drifting, and glue code broke the promise. The rulebook inverts the mechanism: the logic is executable and the prose is generated. What the business reads is a projection of what runs, so it cannot lie.
Keep Camunda, Drools, or IBM ODM: your platform stays where rules are authored and executed. We are the adequacy layer it does not ship. Simulation replays the scenarios you thought of; adequacy measures whether they would notice a defect. In the field we surveyed in 2026, no rules platform combined a mutation score, property counterexamples, reachability, and requirement-joined coverage. That is the added layer.
OPA decides at runtime; we verify the decider. Permission logic is a predicate, business logic is a computation, and a rate book does not belong in an authorization language. The two compose: an OPA decision endpoint is an ordinary live system to Karate, so the same scenario corpus replays against it and diffs the observable decisions. What is measured is the decisions, never Rego internals.
FAQ
Verifying the decision logic your organization runs on, and grading whether the verification would actually notice a defect. Running scenarios is the easy half. Reachability, guarantees, and mutation are the half no simulation gives you.
It is the test asset you already owe, consolidated. The expected values in your spreadsheets and the assertions in your suites are already a shadow implementation of the rules; the rulebook makes that one executable artifact, and its drift against the live system is measured on every run instead of assumed away.
Mostly agents, gated by review. The authoring API is the execution API, writes are parse-validated, and AI-authored work carries a review marker until a human signs off. The engine's deterministic grade is what makes the loop safe to run unattended.
Decision tables and flowcharts are generated projections of the rulebook today, so the review artifact your analysts expect already exists. One-way import from DMN decision tables is on the roadmap, with source identities preserved and unsupported constructs disclosed, never dual authoring.
One artifact the business reads, the engine grades, and the release verdict trusts.