Building your first eligibility rule
A decision table your team edits directly — four views of one document, and analysis that runs continuously rather than on a button you have to remember to press.
A rule in Kav answers one specific, named question — "is this resident eligible for the sibling discount," not a general trigger — and it's stored as a real, typed decision table your team edits directly. Nothing about it is generated code, and nothing about editing it requires writing any.
One document, four views
Whatever you see on screen — a spreadsheet-like table, a flow diagram, plain text, or the workbench — is a projection of the exact same underlying rule set. Edit a cell in the table and the flow view reflects it on the next render; there's no separate copy to keep in sync, because there isn't a second copy at all.
- Table — the most direct way to build most rules: one row per rule, one column per fact it checks, and the outcome it produces.
- Flow and text — read-only, useful for reviewing what you just built.
- Workbench — where you send the draft to be evaluated against real or hypothetical inputs.
Analysis runs while you type, not when you remember to check
Every keystroke re-runs analysis over the draft. If reordering two rules would make one silently shadow another, that's shown immediately, with your hand still on the control that caused it — not discovered later when a resident gets an answer nobody expected.
Use the plain-language panel beside a rule when you're not sure it says what you meant. It restates the row as a sentence, which is often the fastest way to catch a condition that's technically correct but not what you intended.
Building the table
- Add a rule row, and name the fact columns it depends on (age, enrollment count, whatever the decision actually turns on).
- Fill in the condition per fact, and the outcome the row produces when every condition matches.
- Set a priority where two rules could both match the same input — the compiler orders conditions cheapest-first automatically, but which rule wins when more than one applies is something you decide, not something inferred.
A rule returns a decision. It never sends anything itself — the orchestrator applies the effect, which is what keeps consent, quiet hours, confirmation and audit all still in the path even for a decision made by a table rather than by code.
Once the table looks right, move to the testing guide before publishing — save is unconditional, but publish is where the gates are.