The rules kernel decides what the model is allowed to conclude

Abstention is a result, not a failure

Every engine result reaches a consuming system through one shared envelope with five outcomes: supported, illegal, unsupported, decision_required and invalid_input. They are not interchangeable, and the last three are the ones that make the first two worth anything.

unsupported means the component has no semantics for this and declines to invent one — the consuming system must fall back to sourced prose and lower its confidence, not paper over the gap. decision_required means a person has to choose something before the engine can continue, and the envelope carries the options without ranking them. invalid_input is a malformed document, which is a data problem and never a ruling. Every envelope also carries its own coverage limits and states, in the artifact itself, that it is unofficial and changes no game state.

Four systems, deliberately different authority

Deck coach analyses a deck and teaches its game plan, with no win-rate or tier claims. Rule consult explains an interaction with dated sources and explicit assumptions, and never replaces a Head Judge. Player 2 Agent proposes decisions during human-operated physical practice: the human owns hidden information, legality, resolution and every state update. A fourth system, Match Analyst, is fully specified and deliberately not routed until its activation gates pass.

Rule Consult and Player 2 Agent both consume the shared envelope today, each against six stated conditions — the artifact accepts it, the runner produces it, the validator refuses an overstated one, the interface renders every outcome, the regressions cover a supported case and an abstaining one, and the authority boundary survives. Deck Coach has the contract for card-behaviour coverage but does not consume the envelope yet.

In Player 2 Agent the envelope changes how much verification a human owes before confirming, and nothing else. An engine outcome that did not clear the proposal raises that burden; attaching no check at all raises it too, because nothing was narrowed. A rejection the engine is confident about can still be overridden by a person against an official source, provided they record what they checked.

Where derivation stops working

Above the kernel sits a knowledge layer that is derived rather than executed: deckbuilding methodology, play procedure, and a roster of all 46 Legends written from card text and game mechanics rather than summarised from other people’s guides. That makes the entries cheap to regenerate and, on their own, unproven, so all 46 were checked against established play. That audit predates the kernel — at the time this layer was the whole project. Three entries needed no changes. The rest each had at least one thing to fix, most often a default-Champion assumption that ran backwards or an archetype label real coverage does not use.

The most useful row in that log is not a Legend at all but a failure in the ban-list substitution routine. That routine reads what a banned card does inside a specific deck, then looks for a legal card doing the same job. A ramp build of Master Yi lost Obelisk of Power; the routine offered Startipped Peak — same domain, same currency, entirely legal. What it dropped was the condition. Obelisk of Power hands a rune to every player unconditionally; the replacement pays out only to whoever holds the point, and this build concedes the early board on purpose in order to ramp, so the swap would have funded the opponent. The same swap into a differently built Master Yi deck would have been right. A player outside the project found this, not an internal check.

Auditing the extraction step turned up a quieter class of error: the deduplication keyed on domain alone, so wherever a Legend had a third champion print sharing a domain with a known one, that print was never shown to the derivation at all. At least 8 Legends were affected, and only three surfaced through ordinary research — the other five came out by reading the extraction script against the card data. Both corrections went into the process rather than into the individual entries, on the rule that a mistake which repeats is a defect in the method.

The shape of the result is consistent across all 46: derivation from card faces holds up, and the moment the question becomes what a particular deck is actually trying to do, or what is mechanically legal right now, it stops holding. The kernel above is what that conclusion bought. The mechanical layer could not be derived and could not be left to read plausibly, so it had to be executed — which is why a project that started as a knowledge base ended up writing a rules kernel it owns.

What it does not claim

There is no complete card-effect engine, no full state machine, no self-play data and no trained policy. The kernel covers timing and permission and a bounded set of effects; everything outside that returns unsupported rather than a guess. Anything with an expiry date — ban lists, errata — is looked up at query time and never baked into a prompt. The card data bundled with the repository is a snapshot taken on 2026-08-16 and is not guaranteed to be reproducible from scratch.

All four systems sit in the preparation phase: construction, knowledge, practice, review. None of them plays the game. That is why an authoritative rules engine, including an official digital client should one ship, would strengthen this rather than replace it — such an engine serves play, and this serves preparation. It is built for research and educational use, and using it during an event is against tournament rules.

None of this is Riftbound-specific

The method is a bounded kernel under a clause-tied conformance suite, and the most conspicuous place it is missing is Magic: The Gathering. XMage and Forge have implemented Magic for two decades and neither carries one, so neither can separate “illegal” from “not modelled” — the distinction anything learning from them depends on. That gap is old news: in 2016 Google DeepMind published Latent Predictor Networks for Code Generation, whose benchmark task was reading a card’s printed text and emitting the code that implements it. It drew its Magic targets from XMage and got 4.8% of cards exactly right, against a BLEU score of 61.4. The code looked a great deal like the code it should have been. Plausible and correct are different properties, and only one of them runs.

Beyond Magic, the last few years have produced more Western trading card games than any decade since the nineties — Flesh and Blood, Star Wars: Unlimited, Disney Lorcana, Sorcery: Contested Realm, Altered, Grand Archive. They differ enormously in how much the opponent may act on your turn, which is the axis that decides how hard any of them is to model, and for none of them have we found a public rules kernel with a conformance suite. A second game is the real test of whether this generalises, and the first one to get a suite makes every one after it cheaper. That is why the verification method ships under AGPL-3.0 alongside the code: if only Riftbound benefits, this is a tool; if the method travels, it is research.

Where it runs

Riftbound Chronicle is its first production user. 7 of the deck guides on the site have their play analysis generated from this knowledge base — each carries an “AI analysis, for reference” badge and a link to the methodology, and the decklists themselves come from overseas sources. The remaining guides are translations of overseas coverage or written by hand, labelled as such. Problems hit while writing guides go back into the skill.

The repository also ships three install-free demo pages, one per routed system, and an offline bridge that turns a pasted Rift Atlas deck URL into deck-coach input without scraping anything. Licence is AGPL-3.0. It is not affiliated with Riot Games.