A local control plane you can replay

Want to see it before installing anything? Take the guided walkthrough. It walks a compiled workflow and verifies a real signed evidence bundle in your tab, no download, no account.

Try it now (Beta)

After installing, Helm opens your dashboard itself. This jumps straight to the install steps below.

Seven steps, end to end

This is the whole path, one step at a time: install, pair, connect, run, journal, seal, verify. On Windows it is a download and a double-click; on macOS and Linux you mark the file executable from a terminal first. Everything after that is a button in the browser. Source, releases, and issues all live in the public repo, and the technical design document describes how each piece is built.

Steps described here are in the shipped 2026.7.25 build unless a step says otherwise.

Runs on your machine, not ours

The Helm hub is a small daemon you install. Its browser interface talks to it over a padlocked loopback link on your own computer, and the hub calls your services directly. Nothing routes through an AINumbers server, so there is no involuntary egress to a cloud you do not control.

Three terms, one ladder: a tool is one calculator. A workflow is a named composition of tool steps. A pack is a workflow packaged to run in Helm: the same deterministic steps plus a signed manifest, declared inputs, sample data, and any review gates. A pack adds deployability, not new logic.

A pack runs from two surfaces off one kernel. The hub runs it with a journal behind it. The 2026.8.2 build adds the second surface, helm check, which recomputes a single pack against a file you hand it from the command line, with no daemon running and nothing uploaded. The arithmetic is identical either way, because both routes dispatch the same pinned kernel rather than a reimplementation of it.

Signed logs say what happened. Helm re-computes it.

Each run flows through a trigger, a connector fetch, a deterministic kernel, and an evidence bundle. The kernel is pinned by the digest of its own file, not by a version label, and its inputs and identity stamp into a hash. Feed the same inputs back through the same kernel and the same hash appears, so the recorded work can be reproduced on demand rather than taken on faith.

The same property is what lets a reviewer check somebody else's number. helm check <pack> <file> takes a JSON extract holding the inputs and, optionally, the figure the producer asserted. It recomputes the pack's kernel and reports whether the two agree. There is no prior run to look up and no daemon to start, so the file can come from a counterparty, an outsourced administrator, or a folder somebody emailed you.

The answer is an exit code, so the check belongs in a script rather than on a screen. Agreement and disagreement get separate codes, and a file that asserted nothing gets a third, so a silent pass can never be read as a check that passed. Four packs are registered: bordereau recompute, securitisation waterfall recompute, a securitisation Article 5 evidence record, and a government payment programme assurance record covering onboarding identity, migration completeness, and operator exit. The first two carry an asserted figure to disagree with. The other two each assemble a duty and evidence record rather than recomputing a figure against a report, so they are packs you can run but not targets you can check.

Five precise labels, each with a boundary

A single "verified" badge hides more than it shows. Helm classifies every claim with exactly one of five labels, and each one states plainly what it does and does not assert. A connector reporting a value is not a statement that the value is true.

The labels do the same work for a one-shot helm check. A matching recomputation earns kernel_verified and nothing stronger: the pack's kernel reproduced the asserted figure from the inputs in that file. Whether those inputs described the world correctly is a separate question, and no label in Helm claims to answer it.

Your journal, your machine, timestamped by authorities we do not control

Entries chain left to right with running-hash links, so the record shows completeness alongside membership. Alter one entry in the middle and every downstream link breaks. Checkpoints summarize journal state and are signed on their own; timestamping one with an outside authority over RFC 3161 or OpenTimestamps is a separate, optional act.

Anchoring is off by default and opt-in. The 2026.7.25 build never called an authority: the client existed, but nothing invoked it when a checkpoint was written. The wiring landed after that release and ships switched off, because it is the one step in Helm that sends a hash off your machine.

Compliance-scenario packs, not an empty canvas

Helm opens on a gallery of pre-wired workflow packs, each with sample data and one Run button. Five ship today: reg-reporting reconciliation, an EMIR field check, a sanctions pre-screen, trade letter-of-credit compliance, and crypto travel-rule batch conformance. Each is deep-linkable, so a link opens straight into that pack.

A governed step inside the workflow you already have

Point your existing orchestrator, including Power Automate, at Helm with a webhook. It hands off one step, Helm runs it under governance, and returns the result with a reference to the evidence. The push route that receives that call is on the loopback interface, so the caller has to be something already running on your machine.

The inbound webhook connector was declared in the 2026.7.25 build but had no route behind it. The route landed afterwards, so this path is in the source and not in any released binary yet.

Email it. Verify offline, with no network.

An evidence bundle is a self-contained archive. Drop it into a verifier and it checks signatures, running hashes, and anchors with zero network access. Signatures use Ed25519 alongside post-quantum ML-DSA-44. A tampered copy of the same bundle fails a verification row in plain view. The verifier itself ships inside every bundle, so a colleague can be emailed the archive, open it, and see the same checks with nothing to install.

A helm check run produces one of these too. Pass --out and the recomputation is written as a check-result bundle carrying the inputs, the kernel identity, the recomputed figure, and the asserted figure it was compared against. The reviewer keeps evidence of the check, not just a number they remember running, and the person whose file was checked can verify the same bundle offline without taking the reviewer's word for it.

A full bundle covers the whole journal, which is more than a counterparty needs to answer one question: did this particular run happen. Exporting a single run scopes the archive down to that run's sealed objects and the smallest checkpoint that already covers it, so the same signature and running-hash checks apply to a file that is smaller because it was asked a smaller question.

End-user-computing controls, not a workaround to flag

End-user-computing controls apply to any spreadsheet or script that touches a regulatory number. Helm produces the artifacts those controls call for: a one-click EUC-register entry per workflow, a per-kernel validation card for model-risk review under SR 11-7 or SS1/23, and an itemized network-behavior doc for egress allowlisting. The register entries and validation cards are generated on demand and downloadable as JSON or HTML.

Your evidence outlives the vendor, by construction

Every evidence bundle carries a runnable verifier inside itself, and every check it performs, signatures, running hashes, anchor proofs, runs from that file alone. No server we operate is in the loop. That is not a commitment we are making about how long we will be around to keep it; it is a property of how the bundle is built. A bundle you already hold today stays checkable by anyone, on any machine, with nothing installed and no account to sign into, whether or not the people who built Helm are still reachable.

The journal it comes from lives on your machine too, as files on your own disk, not in a cloud we operate. There is no license check that phones out and no step in verification that depends on us continuing to run anything.