Reading the conflict-analysis panel
Three read-only views of one decision table, a live shadowed-rule warning, uncovered-input gaps, and the stats that change which rule you'd write.
A decision table is one thing edited three ways: the table itself, a read-only flow diagram, and a read-only text view — all three projections of the same underlying logic, so an edit in the table shows up in the other two immediately. The table is where you work; the other two are where you check your own work in a different shape.
What the analysis badge is actually counting
Analysis runs continuously, not on demand — it recomputes on every edit you make. Two kinds of finding matter most:
- A shadowed rule. If reordering makes an earlier rule always win over a later one for the same inputs, the Studio warns the moment you make the move — naming which rule now shadows which, rather than leaving you to notice a rule that quietly stopped firing.
- A gap. An input combination no rule addresses at all. Left alone, that's a resident who asks a question and gets nothing back; each gap is listed so you can add a rule or a stated default before it ships.
The Flow and Text views are read-only on purpose. A half-parser that silently drops a condition it can't read is a real failure this design avoids — a read-only projection is honest about what it can show; a lossy editable one can quietly lose policy nobody notices.
Choosing a conflict policy
Set once per rule set, next to the three views: FirstMatch (the first matching rule, in priority order, wins) or AllMatch (every matching rule contributes). Most eligibility tables want FirstMatch; a table that's really several independent add-on decisions stacked together usually wants AllMatch.
Reading one rule as a sentence
Select a row and a plain-language rendering appears underneath it, alongside a fact panel with real, measured numbers: the fact's value distribution, and its null rate — how often the fact simply came back empty (a vendor that didn't answer, say). Neither number is visible from the schema, and both change the rule you'd actually write.
Check the null rate before writing a "no eligibility" default keyed on one fact. A rule that reads as "not eligible" 3% of the time can really be "the vendor didn't answer" 3% of the time — a very different problem with a very different fix.