Building a rules engine that AI can safely edit
Phil has spent a decade hand-translating tabletop rules on paper. Hero’s Rise is the attempt to hand that job to software without letting the software make things up.
Where this stands
As of August 2026 the Pathfinder 1e engine and the GM portal are built and under test, the AI harness is the next thing to build, and the validation site is collecting signups ahead of a launch that has not happened.
Phil has been running tabletop games for over a decade, mostly Pathfinder, with detours into D&D and whatever else caught his attention. Over those years he built a stack of handwritten conversions: a mechanic he liked from one game, redone in the math of the game his table was actually playing. Noah, the engineer at that table and the newest game master in the room, watched him do it and asked the obvious question. Why is this on paper?
Discovery
The tools that exist solve a different problem. Roll20 and Foundry are virtual tabletops, built for groups playing over video with maps and tokens. D&D Beyond manages characters for one publisher's catalog. All of them automate the rules as published. None of them can automate the rule your table invented last Tuesday, and Foundry's per-system plugins are walled off from each other by design, which is the exact wall Phil kept climbing over by hand.
In May they put up a small site to test the idea on strangers instead of friends. It has a waitlist, a survey, and a page of worked conversions Phil wrote out longhand so a visitor could judge the concept rather than a promise. The rules for that site were written down before it was built: no fake signup counters, no manufactured scarcity, no invented testimonials, no exit popups, and the what-we’re-hearing panel stays hidden until there are real responses behind the numbers. It is still up and still collecting signups.
By July the plan had changed shape. Mixing mechanics across game systems is still where this goes, but it now arrives through per-system engines built deep first, because a translation between two games is worthless if neither side's math is trustworthy. That set the hard constraint on everything after it. An AI improvising rules arithmetic at the table is worse than no tool at all, because a wrong number delivered confidently goes straight onto a player's character sheet.
Key Takeaway
The engine is the authority. It is ordinary deterministic TypeScript, and every number the table sees comes out of it. The AI never does table math; it writes code, proves that code with tests it wrote separately, and hands the game master a diff to approve or throw away.
What We Built
The first thing built was the engine, and there is no AI in it. It is pure TypeScript with no I/O and no framework dependencies, split into plan and apply. Plan takes an intent and the current state, consumes all the randomness, and emits events with the dice results already baked in. Apply is a pure function that folds an event into state. A session is therefore an append-only log that replays identically in a browser, on a server, in a test, or inside a sandbox.
Then the rules content, which is the part nobody wants to do. 623 spells, 162 feats and 355 traits are modeled as mechanics rather than stored as text. A pipeline classifies each entry, writes the module, and separately writes an oracle test from the source text alone, with no sight of the module it is checking. Every entry is cross-checked against two published sources with real citation URLs. The three test suites now run past 2,200 tests. When a batch fails, the working assumption is that the instructions were wrong rather than the entries, and that has held at roughly five prompt bugs for every genuine content defect.
A campaign is an instance: its own fork of the engine source, its house rules, its notes, and its event log. When the GM asks for a change in plain language, the request goes to an isolated microVM where a coding model edits that fork’s source, writes tests for the new behavior, and runs the entire regression suite. What comes back to the GM is a diff, the test results, and a preview. Approve, and the change compiles into a versioned bundle that takes effect at the next session boundary, never in the middle of a fight. Reject, and nothing moved. Rollback is a version pointer.
The GM portal is built and running against typed fixtures. Seven tabs cover the session, the shared log, the party, the compendium, house rulings, the translation bench, and scheduling. It is a React app on a NestJS API with Better Auth and Postgres behind it, and a Playwright test walks the whole login-to-session journey against real servers and a real database. Fixtures first was deliberate: settling the shape of every payload before the database arrives makes the database a swap instead of a rewrite.
The business model was decided before the code that depends on it. Engines, character sheets, dice and exports are MIT-licensed and self-hostable, so a campaign stays a folder you can take with you. The subscription buys hosting and the AI features. Rules content carries its own separate license from the first commit, OGL 1.0a for Pathfinder and the CC-BY 5.1 SRD for D&D, never the copyrighted books. Cost is instrumented per job from the first test session, because the price of an AI rule change is a real line item, and an open-weight coding model runs one for cents rather than dollars.
Looking Forward
The engine is deliberately ahead of everything else. The order from here is set by what a launch actually requires.
- Magic items and gear, then races and monsters. The remaining content types run through the same pipeline in the order the source registry sets.
- The harness prototype and a model bake-off. Open-weight coding models get run against real rule-change jobs and scored on tool-call reliability, test quality, and dollars per job. That benchmark then stays as a permanent eval, rerun whenever a model or an engine version changes.
- Instance persistence and the approval flow. Sandbox integration plus the diff-and-approve screen are what turn the harness from a script into a product.
- A D&D 5.1 SRD engine alongside Pathfinder 1e. Launch waits for both, since Pathfinder 1e on its own reaches only a small slice of the tables that would use this.
- A decision on session audio. Transcribing every player on a separate microphone costs roughly five times a single mixed track with speaker labels, and it is the largest line in the cost model.
None of this has been proven at a table other than the founders' own. That is the next real test, and the signups accumulating on the validation site are the argument for running it.
Building something where the math has to be right?
We build AI features that prove their work instead of asking you to trust them. Let's talk about yours.
Schedule a Conversation