Use cases

Helixor is built for operational decisions that repeat at volume and have a definable notion of "correct". This page describes eight decision types: which parts of the platform each one uses, which outcomes feed its learning loop, and its status.

How to read this page#

Every decision type uses the same parts in different proportions:

The status of a decision type is the status of the least mature part it depends on. Domain policy, such as your eligibility criteria or limit tables, is a decision pack you author; running your own codons and invariants in a compiled pack is Planned, as are catalog domain packs. See Choosing an approach for how the learning loop works.

At a glance#

Eligibility and qualification#

Planned

Problem. Applications, requests and claims must be tested against stated criteria. The same facts must get the same answer, a declined case must be explained by the criterion that failed, and the criteria must improve as outcomes arrive without drifting.

How the platform handles it. Codons extract the applicant's facts into typed state. Invariants express each criterion, and the closed action set gives approve, refer or decline. The core decides in process and emits a receipt. Borderline cases go to reasoning, which answers or abstains to a person. Counterfactual analysis states what would have to change for a different outcome.

What feeds the learning loop. Downstream outcomes of approved cases, reversals on appeal, and reviewer overrides of refer decisions. The loop separates bad input data from criteria that are genuinely wrong, and proposes criterion changes only for the latter.

Example. A program approves an application because every criterion holds, and records the pack version and receipt. Months later, a pattern of overrides on one criterion is classified as a policy defect, and a revised threshold passes the regression gate with no change to past correct decisions.

Limits and thresholds#

Planned

Problem. Amounts, quantities and rates must stay inside limits that depend on context: product, channel, customer tier, time of day. Limits set too tight create manual work; too loose, they create losses.

How the platform handles it. The core binds the value and its context and compares them with the limit table in the pack, on the hot path, with no network call. Requests over the limit refer or block. Outcome memory tracks how often each limit is overridden and how those overrides turned out.

What feeds the learning loop. Overrides of refer decisions and their eventual outcomes, and losses on permitted cases. Threshold changes are proposed from those gaps and admitted only after the gate.

Example. A refund above the channel limit is referred instead of paid, and the result names the limit rule and the amount that would have passed. When supervisors consistently approve one category of referred refunds that later prove sound, the loop proposes a category-specific limit for review.

Routing and triage#

Planned

Problem. Cases, tickets, claims and requests must reach the right team, queue or path the first time. Misroutes cost handling time and delay the customer.

How the platform handles it. Invariants over typed facts choose one route from a closed set. Cases the rules cannot place go to reasoning, and abstentions go to a triage desk. Where capacity matters, solvers balance the load across queues.

What feeds the learning loop. Reassignments, meaning cases moved to another queue after routing, and their resolution outcomes.

Example. A servicing request is routed to the hardship team because two stated conditions hold, and the receipt records which ones. A cluster of reassignments from one queue is classified as a policy defect, and a new routing condition is proposed.

Allocation and scheduling#

Preview

Problem. Limited capacity, such as staff, rooms, vehicles, inventory or inspection slots, must be assigned under hard constraints and soft preferences. Plans must be feasible, and it must be clear why they look the way they do.

How the platform handles it. Solvers optimize assignments over the same typed state the core uses. Hard constraints are never violated, and soft preferences are traded off by an explicit objective. When no feasible plan exists, the result says so instead of returning a plan that breaks a rule.

What feeds the learning loop. Manual edits to published plans, unfilled or overbooked slots, and missed service levels.

Example. A weekly roster is produced that meets every coverage and rest rule, and the plan reports which preferences it could not honor. Planners' repeated manual swaps on one team are fed back as overrides, and a changed preference weight is proposed.

Adverse-outcome explanation#

Preview

Problem. When a decision goes against someone, they and your reviewers ask two questions: why, and what would have changed it. A generated rationale does not answer either reliably.

How the platform handles it. The core names the rules that fired and carries a remedy: the smallest change to the input that would make it pass. The first shipped pack already does this for the data it protects. Counterfactual analysis over domain decisions, such as "the nearest income or amount that would have qualified", runs in the hosted platform.

What feeds the learning loop. Nothing directly. Explanations are derived from the decision itself, so they always match the pack version that decided.

Example. A declined request comes back with the failing criterion and the nearest input that would have passed. A reviewer can check the explanation by re-running the same input against the same pack version.

Exception handling and escalation#

Preview

Problem. Every policy meets cases it was not written for. Guessing at them is risky; sending all of them to people is slow.

How the platform handles it. The core decides what policy settles and marks the rest. Those cases go to reasoning with only the evidence you choose to release. Reasoning returns answer, abstain or refuse, with a correctness estimate and a proof reference. Abstentions go to human review, and the local receipt and hosted proof are stored together. See Hosted escalation.

What feeds the learning loop. Human decisions on escalated cases. When people keep resolving the same kind of exception the same way, the loop proposes making it policy.

Example. An order with an unusual combination of options is escalated, and reasoning abstains because the evidence does not settle it. The reviewer's decision is recorded as an override, and after several similar cases a new exception rule is proposed and gated.

Data-release and egress guards#

Available

Problem. Records, logs, exports and messages leave controlled systems through many exits. Each exit needs the same release decision, applied the same way, with a record.

How the platform handles it. The core evaluates each field at the exit and permits, repairs or withholds it, with a receipt. The data-protection pack that ships today is the first pack of this type. It covers Social Security numbers, card numbers, health record IDs, email addresses, phone numbers and IPv4 addresses, and you can add regex block and redact rules for your own identifiers.

What feeds the learning loop. Reviewer overrides of blocks and any incident found downstream, where you choose to report them.

Example. A nightly export withholds a notes field containing a card number and writes an audit row with the receipt. The same pack version runs in every pipeline, so the release rule is identical everywhere.

See Batch processing and the audit pipeline tutorial.

Guarding AI features#

Available

Problem. Features built on language models need a deterministic decision before the model call (what may it see?) and after it (what may reach the user, and what may the feature act on?).

How the platform handles it. The core evaluates each prompt before the call and streams each response through a session that halts on a fatal rule. Because the core is deterministic and local, it adds no model tokens and gives the same answer every time. Checking actions the model proposes, such as a refund or a status change, against your own policy before they execute uses a pack you author, which is Planned.

What feeds the learning loop. Blocked prompts that reviewers release, and model outputs that users or reviewers flag.

Example. A support assistant's draft reply is checked as it streams and stopped before a repeated account identifier reaches the customer. The receipt ties the stop to the rule and pack version.

See Streaming, the model gateway tutorial and Deployment patterns.