Common decision tasks
Teams usually reach for a decision service to do a handful of jobs: route a request to the right place, turn away what they do not handle, answer only when the answer is reliable, apply written rules, call the decision from any service, and keep a record. This section shows how to do each of those with Helixor, and says plainly which parts you can run today.
Tasks and where to start#
| Task | How you do it with Helixor | Status | Start here |
|---|---|---|---|
| Route a request to a team, a domain or an intent | A decision head picks one option from a fixed set and reports how sure it is. | Preview for admitted goals, and for certifying a head on your own examples | Route a request and reject what you do not handle |
| Reject requests you do not handle | An explicit out-of-scope option, plus an abstain gate when no option is clear. | Preview | Out of scope is an answer |
| Answer only when confident, and send the rest to a person | Every answer carries p_correct; below the goal's floor the service abstains and you queue the case. | Preview | Answer only when the decision is reliable |
| Decide eligibility: approve, decline naming the failed criterion, or hold for a person | One rule per criterion over typed facts, with borderline bands that hold rather than decline. | Available | Eligibility and qualification |
| Keep amounts inside limits that depend on context | A limit table written as rules, with over-limit tiers that go to the right person. | Available | Limits and thresholds |
| Route cases on their fields, and triage what does not fit | One rule per route; two routes or none go to a triage desk. | Available | Routing and triage |
| Guard text with pack rules in your own process | Rules over identifiers and phrases, compiled into a pack, evaluated in microseconds. | Available | Rules and Write your own decision pack |
| Call a decision from any service or language | Serve a pack over HTTP, or generate a typed client from its manifest. | Available | Expose a decision as an API |
| Keep an audit trail of every decision | Each decision names the rules that passed or failed and a receipt hash you can recompute. | Available | Receipts |
| Check a decision model before you trust it | Held-out accuracy, accuracy when it answers, coverage and calibration, measured before admission. | Preview | Certified MRL decision heads |
Two kinds of decision#
Some decisions are rules over facts: the same input always gives the same answer, and the rule that decided is named in the result. Others start from text and need a reading of it: which team should handle this message, which of six banking requests is this. Helixor keeps the two apart. Rules decide in the Decision Runtime; readings of text come from decision heads that report a probability and abstain when they are unsure. Probabilistic decisions explains which numbers are which.