H56 — General-Purpose Agent Runtime Governance Kernel

H56 turns structured environment evidence into a traceable candidate verdict: four deterministic cores compute it, and a Nemotron model only chooses which registered scenario to evaluate.

Comment

Inspiration

Most "agent governance" work stops at policy text: a document states what an agent may do, and everyone hopes the runtime honours it. Nothing in the running system can show, for one specific request, which facts were accepted, which state was derived from them, which capability constraint failed, and which layer decided.

We had been building general-purpose OS governance primitives for our own multi-agent runtime — fact identity, append-only history, deterministic state derivation, capability contracts. The hackathon pushed us to do the part that is usually skipped: make the computation itself inspectable, and let a real cloud model take part in it without letting the model become the authority.

What it does

H56 exposes reusable governance mechanisms through one representative domain: environment qualification and controlled task admission.

A caller submits structured environment evidence. The kernel runs a fixed chain — K0 (canonical fact identity and append-only history), K1 (deterministic state snapshot from a fixed version context), C1 (immutable capability definitions and declared constraints), C2 (context-bound feasibility projection) — and returns one of five outcomes:

Input situation Computed outcome
Inconsistent evidence fields input rejected at its gate
Container or integrity constraints violated INFEASIBLE
Required supporting evidence absent NEED_MORE_EVIDENCE
External prerequisite unknown DEFER
Applicable constraints satisfied FEASIBLE (candidate only)

Every accepted assessment stores its evidence identity, reason codes, source binding and a native-call trace with 22 named calls (K0 6, K1 4, C1 6, C2 6). A separate reassessment path creates a new assessment bound to an intact parent record instead of overwriting it.

FEASIBLE is a candidate qualification, never an execution permission. That separation is the whole point: qualification says "the evidence supports feasibility", authority says "you may act", and in H56 they are produced by different layers.

How we built it

  • A byte-locked offline core. A 139-member computation manifest is asserted on every load: member count, a pinned public source-lock digest, per-file digest re-read from disk, total size ceiling. The same closure is recoverable from the public repository with a verification pass.
  • Two operator surfaces. A CLI (demo.py) and a loopback-only UI (ui/serve.py). The UI runs a real subprocess and reads the records it produced; it is not a recording. It binds to loopback, checks exact origin, requires a per-service token, and restricts the run body.
  • A controlled model adapter. Provider origin is pinned, redirects are not followed, request and response bytes are retained separately from credentials, and API keys are stripped from the kernel child environment.
  • A stage-B driver. It checks model identity, catalogue provenance, explicit request scope, budget and operator authorization; reserves the declared maximum cost before sending; reconciles actual usage afterwards. Price evidence is classified — a cost computed from usage and published rates is not a billing receipt, and we label it that way.
  • Evidence-bound execution. For file-bound runs the driver hashes the plan bytes, reparses those same bytes, compares normalised content, and executes the reparsed object.

How the model takes part

The model does not supply trusted evidence and does not return the verdict. Its only job is to read the user's intent and pick one scenario from a registered catalogue. The adapter then validates the response and maps the choice onto a controlled input-construction path; the original deterministic cores do the actual assessment.

That constraint is enforced, not documented:

  • Five response keys only (decision, scenario_id, clarification_question, reason, confidence). Invalid keys, duplicate JSON keys, invalid field relationships and any authority claim are rejected.
  • NOT_APPLICABLE and NEED_CLARIFICATION are legal terminal answers that do not launch the kernel at all — zero computation, recorded as such.
  • Expected outcomes and CLI exits stay in test data and are never placed in the prompt.

NVIDIA Nemotron and Nebius Token Factory in practice

Recorded runs on Nebius Token Factory used nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B:

  • R1 selected S-C01; the primary assessment returned FEASIBLE.
  • R5 selected S-A01; the primary assessment returned INFEASIBLE.
  • R7 returned NOT_APPLICABLE; the adapter completed and the kernel was not launched — the honest "nothing to compute" path.

R1 and R5/R7 were separate execution batches and are labelled as such. Assessment inputs are synthetic fixtures; the model responses are real cloud inference responses. Each selected primary assessment recorded 22 native-call trace entries.

One concrete cross-provider check: for the same frozen input, the assessment artifact produced from the Nebius run is byte-identical to the one produced earlier through a different provider. That is the property we actually wanted from a model-agnostic boundary — swapping the model changes the routing decision, not the computation.

Token Factory also shaped the engineering work: because each call was cheap and fast, we could iterate the contract around the call (response schema, rejection rules, budget reservation, price-evidence classes) rather than optimising prompts. The bottleneck was never inference cost; it was making "who is allowed to call, and what may the answer be used for" explicit and checkable.

Challenges we ran into

  • Keeping the model out of the trust path. The tempting shortcut is to let the model return the verdict. We kept the five-key contract, and deliberately made two of its answers terminate without any kernel call.
  • Making a "null" honest. For an out-of-scope intent the kernel is never invoked, so native_calls is null. Early drafts described that as "0 calls"; that would have been a measured claim we never made.
  • Byte-level identity across a public release. Path length limits, line-ending conversion and archive round-trips all silently mutate bytes. The fix was a manifest that asserts membership, digests and size on every load, plus a verification pass on the clone.
  • Metrics that survive scrutiny. The extended regression run contains 56 rows representing 26 byte-distinct inputs — 30 rows repeat existing inputs. We report it that way everywhere, including inside the product UI, instead of claiming 56 independent capabilities.
  • A deviating model decision we did not paper over. In one recorded batch the model answered NEED_CLARIFICATION where the plan expected a scenario selection, with confidence 0.4. The adapter accepted it as a legal terminal answer and the kernel did not start. We recorded it as a documented deviation rather than editing the intent or the expectation to make the run look clean.

Accomplishments that we're proud of

  • A governance kernel where every verdict is traceable to 22 named native calls, with digests, statuses and reason codes.
  • Real Nemotron inference on Token Factory driving a real deterministic assessment — including one path where the correct behaviour is to compute nothing.
  • A public repository that reconstructs the byte-locked computation closure and verifies it, with an OSI licence and a README that states the limits instead of hiding them.
  • An honestly reported capability surface: six distinct offline inputs, four computational outcome classes, and an explicit statement that two of them are FEASIBLE.

What we learned

  • Inference cost is no longer the scarce resource; authorisation and traceability are. A cheap model that can only choose from a catalogue is more useful than an expensive one whose output has to be trusted.
  • A model's disagreement with the plan is data, not noise. It belongs in the record with its confidence, not in a silently retried request.
  • Governance primitives are only credible when the numbers survive an audit: rows vs. distinct inputs, declared vs. machine-readable prices, candidate vs. granted authority.

What's next for H56 — General-Purpose Agent Runtime Governance Kernel

  • An explicit execution-authority layer — delegation, time bounds, revocation — so a candidate qualification can be promoted to a scoped, auditable permission.
  • Treating cross-provider agreement on a frozen input as an admission condition for new model versions.
  • More domain asset sets (beyond environment qualification) to prove the cores are genuinely general-purpose.
  • Reproducible packaging so a judge can go from clone to a verified closure in one command.

Built With

Share this project:

Updates

Submission history