A decision, not a guess: eligibility rules a registrar edits directly

"Am I eligible for the sibling discount?" sounds like the kind of question a language model could just answer from context — it read the policy, it can reason about two enrolled siblings, why not let it decide? Because a model that reasons its way to an eligibility answer is a model guessing, however confidently it phrases the guess, and a university registrar's discount policy is not the place to find that out the hard way.

A named question, not a prompt

Eligibility here is a rule: a named question, answered at a declared decision point, by a table the registrar edits directly — not a paragraph of code, and not a prompt. The table is compiled and tested before it's ever published, the same discipline a tax rule or a discount policy gets anywhere else on this platform.

What comes back

Asked about the sibling discount, the answer is a decision — eligible, based on two enrolled siblings — with its own reason attached. The model didn't decide it and it didn't write it; it chose to surface the decision and phrase the sentence around it. A rule condition that can't be evaluated cleanly doesn't produce a hopeful guess either — it fails closed, the same rule that governs every other decision point on this platform.

Why a near-miss has to explain itself

A rule that says only "not eligible" is a rule a registrar's staff has to re-derive by hand every time a student appeals. A rule engine built to say "age was 63, needed 65" instead turns every refusal into something a person can act on immediately, without opening a policy document to check.

What the registrar controls

The registrar owns the table, not the platform team. A policy change — a new age threshold, an added discount tier — is an edit to a decision table and a republish, tested against the same golden cases every time, never a support ticket asking for a code change.