Two strands on the Helixor Decision Engine. One verified answer.
The DNA Index | Strand One
The rules, constraints, and consequences your business runs on, captured once as machine-readable facts.
Your policy logic stops living buried in code and people's heads. It becomes an asset you can inspect, version, and trust.
The DNA Index | Strand Two
Every execution path, satisfaction bound, and proof chain: the space where an answer is supported, or refused.
When a regulator asks how you decided, the full reasoning is already mapped. Audits take seconds, not months.
The Execution Model
The Helixor Decision Engine. Two strands, one engine. It executes decisions instead of sampling them. It does not guess.
On high-stakes calls, "probably right" is a liability. The Helixor Decision Engine returns answers it can prove, or it returns none at all.
The Neurosymbolic Engine
The model proposes. Helixor decides.
LLMs and neural models read messy input and propose what it means. The symbolic core checks those proposals against your rules, so a model's output never becomes a decision just because a model produced it.
How Helixor works with LLMs →Tensor Architecture
Low-rank tensors wired together by constraints, so satisfaction propagates through the network instead of being searched for.
Regulations are interdependent. Change one rule and the impact ripples to every downstream decision automatically.
The Execution Engine
Every answer ships with its proof. An auditor, regulator, or customer can verify the complete reasoning in seconds.
Helixor loads a versioned decision pack into your application's memory. Codons extract typed state, rules pass or fail, and you get back one action from the pack's closed set, with a remedy and a receipt hash you can log.
Operational decisions such as eligibility, limits, routing and release don't need a remote service or a language model. The same input and pack version produce the same action every time. Nothing is sampled, no model tokens are spent, and every result reports tokens_spent and egress_bytes so you can prove it.
Construct the engine once at startup; evaluate() is the one call you make on every payload.
from helixor_runtime import HelixorEngine
engine = HelixorEngine()
result = engine.evaluate(
"Customer renewal card: 4111-1111-1111-1111, contact billing@acme.corp."
)
print(result.action)
print(result.invariants_passed)
print(result.remedy.clean_text)
print(result.receipt_hash)A playbook is a YAML file describing one decision: its codons, rules and the closed set of actions it may return.
The playbook compiles into an encrypted .hxpack with a stable pack_id and version, bound to your license and promoted like any build artifact.
Codons turn raw input into typed facts, and can validate what they find (a Luhn checksum on a card number, for example).
Each rule is a condition on state with a severity. Fatal blocks; warning allows after repair. The first fatal match decides, otherwise the first warning.
The runtime only returns an action the pack declared, so you can branch exhaustively. The remedy is the minimal change that satisfies the rules.
receipt_hash fingerprints the pack, action, fired rules and a SHA-256 of the input. Keep the input's hash and you can recompute it later.
Every payload passes through deterministic verification barriers in microseconds before executing downstream actions.
Incoming prompts and tabular payloads are evaluated locally in memory. High-performance SIMD regex codons and Luhn checksum validation scrub PAN, SSN, and ePHI in sub-1µs with 0 bytes leaving the process boundary.
Business policies, regulatory boundaries, and risk thresholds are represented as algebraic intervals. Contradictions and edge violations are caught instantaneously without probabilistic hallucinations.
When data is missing or ambiguous, Helixor refuses to guess. Instead of making risky stochastic assumptions, it triggers automated counterfactual recourse to find the minimal required user intervention.
Every decision produces a SHA-256 Merkle audit token recording rule version, inputs, constraint bounds, and execution latency. Receipts can be stored in immutable audit logs to satisfy SEC, OCC, and HIPAA examiners.
Why modern enterprise AI architects are choosing compiled in-process execution over cloud-hosted decision models.
Transmitting raw customer data over the public internet to third-party shared servers.
Links directly into your application process. Evaluates in local memory, optimized for GPUs.
In-Process Decision Engine vs Cloud-Hosted System One Models vs Frontier LLMs
| Architectural Feature | Helixor Decision Engine | Hosted System One (Jev) | Cloud LLMs (OpenAI/Claude) |
|---|---|---|---|
| Deployment Boundary | ✓ 100% In-Process (Host RAM) | Multi-tenant Cloud Endpoint | Multi-tenant Cloud API |
| Data Egress | ✓ 0 Bytes (Never leaves host) | ✗ Unredacted data sent to SaaS | ✗ Unredacted prompt over internet |
| P99 Latency | ✓ ~25 µs typical | 70 ms to 500 ms (Cloud network lag) | 1,500 ms to 3,500 ms |
| Throughput | ✓ > 35k ops/sec on GPU | Rate-limited SaaS endpoints | Strict RPM/TPM cloud quotas |
| Hallucination Defense | ✓ Epistemic Honest Abstention | Rigid schema parameter output | Plausible hallucinations |
| Reasoning Model | ✓ Deterministic Algebraic Intervals | ✗ Soft Neural Classifiers | ✗ Probabilistic Next-Token Predictor |
| Auditability & Proof | ✓ Cryptographic Merkle Receipt (SHA-256) | Opaque proprietary cloud logs | Non-deterministic output logs |
| CISO Security Audit | ✓ Fast-Track in 24 Hours (In-VPC) | ✗ 6 to 9 month vendor review (VRA) | ✗ 6 to 9 month enterprise review |
| Economics | ✓ Flat Capacity ($0 overage fees) | Metered cloud API usage | Metered token tax ($5 to $15/M tokens) |
The runtime always decides locally. The five patterns differ only in who calls it, over what transport, and whether any request may leave the perimeter.
The decision runs in the caller's own process. Use it when the caller is Python and the decision is on its hot path.
Listens on loopback only, so nothing outside the pod can reach it. REST, SSE and WebSocket on 127.0.0.1:18734, from any language.
One pack version for many services. Callers authenticate at the gateway; each replica accepts traffic only through its own authenticating proxy.
Everything the runtime needs crosses the gap once: packs and a license verified offline. Nothing inside calls out.
The local runtime decides every request. Only the cases your rule selects go to hosted reasoning, and only as redacted text.
The embedded runtime always returns an action. Hosted reasoning can abstain when evidence doesn't support an answer, so a person decides. Act only on an answer; an error is not an answer.
Decide on model output as it streams, or on a whole file overnight, with the same pack and the same receipts.
Streaming. A card number or SSN can arrive split across chunks, and each piece looks clean on its own. A streaming session holds a small look-ahead window (28 characters by default) and only releases text that ends at a safe delimiter, so a value is never leaked one piece at a time. The concatenated output equals evaluating the complete text.
Batch. There is no separate batch API: a loop over evaluate() is the batch API. Evaluate per field rather than per record, so you redact just the field that fired, and write the receipt to an append-only audit log. Scale with one engine per worker process.
from helixor_runtime import StreamBlockedError
try:
for text in engine.stream_filter(model_stream(), lookahead_chars=28):
send_to_client(text)
except StreamBlockedError as blocked:
abort_response(blocked.action, blocked.reason)See and shape the vocabulary your decisions run on, and connect live data to it without copying it.
Classes such as Customer or Policy, the typed relations between them, and the chains that derive facts nobody stated. Admit data in open mode for discovery, or closed mode to reject unknown terms.
Map SQL, REST, Google Sheets or the Query Gateway onto ontology classes. Views store only definitions, so there's no ETL copy to secure, and policies target ontology attributes, not source columns.