Playbooks
Task-oriented procedures. Numbered steps, commands to copy, and a check that tells you when you are done.
Each playbook is a procedure for one task. Steps are numbered and meant to be followed in order; every command runs from the root of your project unless a step says otherwise; each playbook ends with a Done when check you can verify.
| Task | Playbook |
|---|---|
| Move business rules out of existing code | Rules from existing code |
| Change a rule and get it to production | Author and ship a rule change |
| Drive a form from the rules | Add rule enforcement to a React form |
| Make the API the place that decides | Enforce in a backend API (Java, Node.js, Go, Python) |
| Use the rules from Ruby, PHP, Rust, C#, a shell script ... | Run rules from any other language |
| Check thousands of records | Batch processing |
| Let an LLM agent check before it acts | AI agent tools |
| Organisation baseline, feature rules, field targets | Multi-level inheritance and overrides |
| Run the HTTP rule server in production | Deploy the rule server on Kubernetes |
RULE-EVALUATION-ERROR findings are rising | Incident: RULE-EVALUATION-ERROR spike |
The playbooks build on the enforcement guide, which states each obligation with MUST and SHOULD and ends with an audit checklist.
Change a rule safely across levels
A child ruleset overrides what it inherits, within the parent's policy. Tightening loads; loosening is refused at load time.
Rules from existing code
An engineering playbook for moving business rules out of application code into rulesets, safely, in any language, with or without an AI agent.