Software products make decisions on nearly every request: is this user allowed to do this, is this input safe to send to a model, should this account be throttled. Helixor puts one versioned policy behind every service, so the answer doesn't depend on which microservice asked.
These are examples, not a complete list. A decision usually fits when it has written criteria, pulls from several systems, happens often, and someone may later ask why it went the way it did. Pick one to jump to it.
Plans, add-ons, trials, grandfathered contracts and usage limits get encoded in if-statements spread across services. Sales promises an exception, someone hardcodes it, and nobody can say for sure what a given customer is entitled to.
Entitlement rules live in one pack. Every request comes back allow, soft limit (with a warning), hard limit, or upsell, in microseconds and in-process. A contract exception is a rule with an owner and an expiry, not a special case buried in code.
{
"tenant": "t_48213",
"request_id": "req_9f31c2",
"receipt": "hx_proof_e7a0c31b58d94f2a6b1e0c77",
"pack": "billing.entitlements v31",
"action": "soft_limit",
"rules": ["ENT-API-CALLS-90PCT"],
"input_sha256": "6f1b...0d29",
"logged_at": "2026-09-28T17:30:02Z"
}Product teams are adding model calls everywhere. Each team decides on its own what can go into a prompt and what can come back out, and customer data ends up in places nobody intended.
Every model call passes through the same pack first. Personal data is redacted before the call, blocked content never leaves, and responses are checked on the way back, including as they stream. The result carries egress_bytes and tokens_spent for the guard itself (both zero) so you can show where data did and didn't go.
Abuse signals come from rate limits, payment risk, content reports and account age. Moderators work a queue that mixes the obvious with the genuinely hard.
Helixor handles the clear cases (allow, throttle, hold) under written policy and sends the unclear ones to hosted reasoning, which can abstain and hand the case to a person. Moderators spend their time on the cases that need judgment.
Batch jobs, model inference and background work have to run somewhere. Teams place them by hand or with simple bin packing, then discover a European tenant's job ran in a US region, or that GPUs sat idle in one cluster while jobs queued in another.
Residency rules, tenant quotas and SLAs go into the pack. The solver places each batch of work across clusters to cut cost and queue time, and re-places it when capacity changes. Every placement is checked by the decision core before it runs, so a residency rule can't be traded for a cheaper price. The pack holds the hard rules and the goal. The solver searches for the best plan that satisfies every hard rule, working from the same typed state the decision core uses. If no plan can satisfy them all, it tells you so instead of quietly breaking one. The solvers are built for GPUs, and that's where large plans solve fastest. Solvers are in Preview today.
| Decision | What Helixor decides |
|---|---|
| Support routing | Queue, priority and tier for each ticket. |
| Feature rollout gates | Decide who gets a feature flag based on plan, region and risk. |
| Workload | Pattern |
|---|---|
| Python services | In-process |
| Polyglot stacks | Loopback sidecar, one pack version across languages |
| Central policy | Shared decision service with restricted egress |
| Unclear cases | Hybrid escalation with human review |
Capture the receipt, pack version, tenant and request ID on every decision, never the raw input. Before promoting a policy change, build a golden set of expected outcomes across plan and feature combinations and make the new version reproduce it.
Go deeper on helixor.dev: Industry guide ↗ • Deployment patterns ↗ • Core concepts ↗ • Receipts ↗
Bring a written policy and a handful of past cases. We'll turn it into a pack and run it next to your current process so you can compare.