Testing a rule before you publish it

Saving a rule set draft is unconditional — it's allowed to be incomplete, because a draft is where you think out loud. Publishing is the opposite: it's blocked until a specific, visible set of conditions clears, and every one of them is named next to the publish button before you ever click it.

What actually blocks a publish

Analysis errors. The same continuous analysis that runs while you edit the table — a shadowed rule, a conflict the stated policy can't resolve.
Failing tests. Golden cases your team wrote against this rule set that no longer pass.
An uncovered input space with no default. If some combination of facts matches no rule at all and there's no default outcome, that's a resident who asks a question and gets nothing back — and it's caught here rather than in production.
An un-run impact preview. You have to have actually looked at what this change would do before it's allowed to ship, not merely have the option to.
A stated reason. The one purely procedural gate: publishing requires you to say, in words, why.

Running the preview

In the Workbench, run your draft against real or representative inputs before you publish. This is the same evaluator production runs on — never a separate reimplementation that could quietly disagree with it — so what you see here is what a resident would actually get.

Build a small set of golden cases as you go, not just at the end: the case that should be eligible, the case that clearly shouldn't be, and the edge right at the boundary (the applicant who's exactly at the age cutoff, say). That last one is the case a shadowed-rule bug usually hides behind.

Reading the diff

Before you publish, the Studio shows exactly what changed against the version that was live when you opened the page — which rule was added or removed, which cell's condition changed, which outcome changed, and any priority or enabled/disabled flips. This is the same diff view the workbench's history tab uses elsewhere, so what you're confirming at publish time is stated in the same language you'd use to review it after the fact.

A rule that can't be evaluated for some input never "just passes." Every unresolvable condition fails closed — it doesn't match — which is the platform-wide rule that a missing entitlement, an unclear identity, or an ambiguous fact should deny rather than guess. Your uncovered-input check exists precisely so you catch that case yourself, on purpose, rather than residents discovering it as a blank answer.