One product, four parts
Admission, Compare, an audit ledger and an enforcement hook: one stack that runs in your environment.
The four parts, in order
-
Admission and provenance
Checks each model's licence and provenance before anyone can use it.
-
Compare
Runs your own tasks against each candidate and scores the results.
-
The tamper-evident ledger
Records every request and decision in a chain that shows any tampering.
-
The enforcement hook
Decides who may use which model, on every request.
Capability status
Every public capability, with its status and evidence. In build and Claimed mean not available today; Shipped and Demonstrated mean the named evidence supports it. A hosted route carries provenance by host attestation, not verified; hosted routes are in build.
| Capability | Status | Evidence |
|---|---|---|
| CapabilityAdmission gate | StatusShipped | Evidencetools/ |
| CapabilityProvenance artefact | StatusShipped | Evidencetools/ |
| CapabilityLicence evidence | StatusShipped | Evidencetools/ |
| CapabilityCompare | StatusDemonstrated | Evidencesite/ |
| CapabilityHash-chained audit ledger | StatusShipped | Evidenceservices/ |
| CapabilityEnforcement hook | StatusShipped | Evidenceservices/ |
| CapabilityIdentity proxy and virtual keys | StatusShipped | Evidenceservices/ |
| CapabilityFederation to a commercial identity provider | StatusIn build | Evidencedocs/ |
| CapabilitySeverability: no phone-home, no kill switch | StatusShipped | Evidenceservices/ |
| CapabilityModel serving behind an OpenAI-compatible endpoint | StatusDemonstrated | Evidencedocs/ |
| CapabilityRetrieval | StatusDemonstrated | Evidenceservices/ |
| CapabilityDeployment pipeline | StatusDemonstrated | Evidencetools/ |
| CapabilityWeights verified by digest and signature | StatusDemonstrated | Evidencetools/ |
| CapabilityHosted provider and frontier API routes | StatusIn build | Evidencedocs/ |
| CapabilityExport screening | StatusClaimed | Evidencedocs/ |
| CapabilityPer-environment load and SLO evidence | StatusDemonstrated | Evidencecompare- |
See it working
Three screens from the working product. The full flow walks every screen in order.
1. Admit
The candidates that did not pass, each beside the gate's own reason: a missing licence file, a clause that restricts use, an indemnity buried in a usage policy.
Rig capture: why the gate refused, not whether an admitted model suits your work.
2. Prove
A refused request shows its reason to the person who made it, and the same reason sits in the ledger with the policy revision that decided it.
One refusal on the capture laptop; other refusal reasons are not shown.
3. The catalogue
The first screen after sign-in. Every record shows the licence, content digest, hardware fit and provenance recorded at admission.
The catalogue is not a digest check on deployed weights.
About these captures
Taken on a single capture laptop to show the flows. Performance and scale are measured in your pilot, on your hardware and your data. The models shown are the ones admitted there, not a recommendation. Sign-in uses a local identity stub; commercial federation is in build.
The Compare screens sit on the headline metric. For the rest, book a walkthrough: we drive the flows and answer your questions live.
The request path
Every request passes the same checks, in order, and nothing reaches the model without a decision.
- 01 Admission state Only admitted models are reachable.
- 02 Resolve the caller The identity proxy signs the caller in; their key reaches only admitted models.
- 03 Decide Policy allows or denies, and a deny carries its reason.
- 04 Serve The Agent Router forwards to the model and streams the answer back.
- 05 Record The ledger records the request before the answer, and cannot be skipped.
If the policy engine is unreachable, the answer is deny: an outage, never an open door.
The audit ledger and its chain
Every request and decision becomes a row with content hashes (not content), token counts, the model digest and the policy revision. Rows link to each other, so removing or editing one is detectable.
| Mechanism | What it prevents |
|---|---|
| MechanismCanonical payload and per-row hash | What it preventsAn edited field changing the meaning of a row without changing its hash |
| MechanismA row lock on a single chain head | What it preventsTwo concurrent writers forking the chain |
| MechanismInsert and select only, plus triggers on update, delete and truncate | What it preventsQuiet rewriting, and the truncate case that row triggers never see |
| MechanismA write-ahead buffer, synced before the answer | What it preventsTraffic served without a record. If the sink is down the buffer retains; if the buffer cannot persist, requests fail rather than proceed unlogged. |
| MechanismA signed head exported outside the ledger | What it preventsRewriting history before the anchor, even with the privilege to rebuild the chain. The anchor records the head watermark too, because one anchor alone cannot see rows deleted after it was taken. |
Governance as code
Policy is Rego in your own Git repository. The deploy pipeline stamps each bundle with its commit SHA, so every audit row cites the exact rules in force. A policy change is a deploy: a commit, a stage and a test run.
If the policy engine is unavailable, requests are denied and an alert fires. Every entitlement rule has a unit test, and a mutation harness checks the suite catches each deny gate being removed. Policy decides entitlement, not content; rate limits and budgets are the adopted substrate's.
Policy decision an example, not a live record
{
"allow": false,
"deny_reasons": ["model_not_entitled"],
"policy_revision": "6c2a1f0"
}
Where it fits
Heliast governs the models you run, in your environment. Your coding tools point at an OpenAI-compatible endpoint inside it and keep working, and routing comes from a substrate we adopt, so what you pay for is admission, comparison and evidence.