Skip to content

Verification

import guarantees from ‘@data/halis/guarantees.json’;

A claim you cannot check is a slogan. Halis’s guarantees are pinned in a machine-checked ledger, and the verification estate is the machinery that checks them.

{guarantees.count} rows, each with an enforcement mechanism, an anchor in the source tree, and negative probes that must fail exactly as expected:

{guarantees.ids.map((id) => \${id}``).join(’, ’)}

The published bug-bounty scope is that same ledger: a bounty claim maps onto exactly one ledger row, and the reporter names the row.

make guarantee-report re-derives the ledger and renders it. hls-guarantee verify re-demonstrates the whole ledger against the live compiler, and refuses to write a report from a violated ledger.

The compiler is written in Halis, so it must compile itself — and land on exactly the same result. See the bootstrap law.

The interpreter, the native build and the WebAssembly backend must produce identical bytes on the same program. The differential suites run on every pull request, and they compare halt classes, not just output — a program that halts for a different reason in a different backend is a failure.

Performance, resident set size, compile time and binary size are recorded per commit. A regression without a written sanction fails the gate.

Two third-party audit kits exist: the standing engagement kit and the final-audit kit that pins the frozen surface, the snapshot manifest and the guarantee ledger. Each evidence pass is labelled with its independence, and the closure seal is enforced by make finalaudit-gate.

make release-acceptance judges the tree as a legal state of the release line, and hls-lts status reads the clock of the opened line. A tag push without a matching release record is refused by the pipeline.