chaoz23/srdcheck

**A shared rules rail for agents: named, cited checks with explicit boundaries,
so every caller can use the same deterministic result without mistaking a
partial check for global legality.**
Machine verdicts over specific rules of the System Reference Document 5.2.1:
cited when a rule is applied, reproducible, offline, and honest enough to refuse
questions outside the shipped scope. The rules lawyer for agents — including an
agent acting as the authorized DM.
**Agents start here → SKILL.md** — the front door: when to call this, worked examples, MUST/MUST NOTs. Family contract: FAMILY.md.
> **Status: v0.9.0 alpha — young but real, building in the open.** The kill tests that shaped the product — including the one that killed half our original idea — are in eval/RESULTS-phase0.md; the with/without-rails demo is in demo/mage-hand/; the truth scorecard below is generated by CI.
Runtime and operating-system guarantees are defined in the support matrix: Python 3.10–3.13, a full Ubuntu suite, and explicit installed-artifact smoke contracts on Windows and macOS.
Why this exists
A game increasingly runs not as one model but as *several agents sharing one evolving state* — a GM, player agents, a rules referee, tool-callers. The moment more than one mind adjudicates, the binding problem stops being any single agent's knowledge or attention budget and becomes **consistency**: five capable models will each read the SRD and rule on grapple, concentration, or a death save a little differently, and the shared game state quietly desyncs. No amount of individual intelligence guarantees they agree with *each other*, and every re-derivation is another chance to drift. The fix is a deterministic rail they all call — the same atoms, the same citations, the same verdict every time — so every applied-rule result carries one provenance any agent (or a human) can audit. Table rulings retain separate ruling lineage. That is where srdcheck stops being a convenience and becomes load-bearing.
Even at a table of one, the rail earns its place. A model running a game is a brilliant improviser with a finite attention budget: every mechanical micro-check it handles in-context — *is this legal, is that slot spent, does the reaction refresh this round* — spends tokens and attention that belong to the only work that needs a mind, the story. And the checks a model *can* answer, it cannot **prove**, cannot **reproduce**, and — as our own benchmark showed — will not **refuse** when the question is outside the rules' jurisdiction.
We tested this before building. Frontier models answered our SRD rules questions nearly perfectly — and confidently ruled on house rules, GM discretion, and content that doesn't exist in the SRD, where the only correct answer is "not my call." Small local models got 19–30% wrong with zero refusals. So srdcheck does not compete with what models know. It is a rail: structured facts in, a deterministic scoped result out, with citations whenever it applies a rule — and the *same* rail for every agent at the table.
What it is
srdcheck answers named, bounded questions such as: *does this proposal pass the
modeled action-economy check?* and *which modeled budget option kinds remain?*
See the generated capability and claim map for the
canonical checked and unchecked scope of every tool.
- **Verdicts, not vibes.** Exit code 0 = passes the checked scope, 1 =
conflicts with the checked scope, 2 = cannot adjudicate. Every applied rule
carries its SRD citation; boundary refusals do not invent citations.
- **Scope and provenance travel with the verdict.** Verdict schema 4.0 keeps
coverage_level, checked_scope, unchecked_scope, and assumptions on
every result and separately reports asserted/consumed/derived/missing facts,
the advisory rule_result, any scoped DM table_decision, and explicit
state_mutation. Every legal explanation says it is legal only within that
checked scope.
- **Judge, never simulate.** No dice, no narration, no owned game state. State comes in with the query; a verdict goes out. The kernel is a stateless pure function — embeddable in anyone's DM product, VTT, or agent.
- **State commits fail closed.** event.apply emits an idempotent transition
proposal bound to the exact evaluated state; transition.commit rejects a
stale/out-of-order proposal and returns the same semantic receipt on retry.
The agent-DM or host still performs the atomic state write. See