Software and SaaS
Software products decide on every request: is this tenant entitled to this action, has it hit its limit, may this model feature see this input, where does this ticket go, is this account abusing the service. Helixor makes those decisions in the request path with one versioned policy across every service, and improves them from outcomes through a gated loop.
The situation#
Request-path decisions are usually re-implemented in each service and each language, and the copies drift. When a customer asks why an action was refused, or a trust-and-safety reviewer asks why an account was not stopped sooner, nobody can replay the exact decision. Model-backed features add a new decision on every call: what the model may see, and what may come back.
Helixor puts the decision in a pack that every service calls, in process or through a loopback sidecar, with a receipt per decision. Outcomes such as upgrades, support contacts, confirmed abuse and reviewer overrides feed the learning loop. Ambiguous abuse and support cases go to reasoning, which abstains to a person when unsure.
Decisions that fit#
| Decision | Platform parts | Learning loop learns from | Status |
|---|---|---|---|
| Entitlements and usage limits: allow, soft-limit, hard-limit or upsell, by plan, feature and usage | Core in the request path, outcome memory, learning loop | Support contacts about limits, limit overrides granted by staff, upgrades | Planned |
| AI feature guards: what a model may see and what may come back | Core before the call and on the response stream | Blocks that reviewers release, outputs users flag | Available |
| Support routing: queue, priority and tier | Core, reasoning for unclear tickets, solvers for queue load | Reassignments, escalations, time to resolution | Planned |
| Abuse and trust-and-safety escalation: allow, throttle, hold or escalate an account or action | Core for stated thresholds, outcome memory weighting confirmed abuse, reasoning and human review for the ambiguous remainder | Confirmed abuse, reversed actions, reviewer decisions | Planned |
| Cases no policy covers in support or trust and safety | Reasoning with abstention, human review | Reviewer decisions on escalated cases | Preview |
Rows marked Planned depend on a pack you author with your plans, thresholds and routes. The data-protection pack that ships today also scrubs logs and keeps your customers' identifiers out of model prompts.
Recommended deployment#
- Python services: the core in process, pattern 1, one engine per worker process.
- Polyglot services: a loopback sidecar, pattern 2, so every language calls the same pack version.
- A platform team that owns the policy: a shared decision service with egress denied, pattern 3.
- Trust-and-safety escalation and the learning loop: hybrid, pattern 5.
See Deployment patterns, Reliability and Operational excellence.
Golden set and outcomes to capture#
- Golden set: a table of plan, feature and usage combinations with the expected outcome; past abuse cases with the correct action; tickets with their correct queue. Run it in CI before any pack is promoted.
- Outcomes: upgrades and churn after limit decisions, confirmed abuse and false positives, ticket resolution times.
- Overrides: staff limit grants, reversed trust-and-safety actions, ticket reassignments, with a reason.
- Linkage: the receipt, pack version, tenant and request ID on every decision. Never log the input itself.
Honest limits#
- Entitlement, routing and abuse policy must be authored as packs; domain packs are Planned in the catalog.
- Behavioral abuse detection over raw event sequences is a job for a trained model. Feed its score to the core as a fact and let the pack decide the action.
- Pack changes take effect on restart; hot reload is Planned. The decision service's own authentication is one shared token over plain HTTP; put an authenticating proxy with TLS in front of it.
- The learning loop, reasoning and solvers run on the hosted Helixor platform and are in Preview.
Next steps#
- Guard one AI feature today
Work through the model gateway tutorial.
- Write one entitlement rule
Use the Playbooks format, with the plan table as its golden set.
- Pilot
Follow Evaluating fit.