Boundry Verify

Some of the systems that now author work do not give the same answer twice. A record of what such a system did cannot be checked by asking it again.

If that system's output is also the action, the action inherits the problem. It can be logged, but the log is the only witness, and the operator holds it.

Execution governance, as this page uses the term, moves three things out of the author's hands and into a system that can be replayed and checked: the decision whether the work runs, the running of it, and the record of both.

The Boundry Substrate is such a system. It decides whether a submitted intent may run, runs it on a deterministic road, and leaves a signed record. Boundry Verify is how a reviewer checks that record.

The Boundry Substrate performs governed execution. It is not a store of records made elsewhere: the runs in the evaluation kit are the Substrate's own, made in fresh processes against fresh roots, on two platforms.

A run begins with a submitted intent. The README places no condition on what writes an intent; a person, a program or a model may author it. Whatever wrote it, it enters as a submitted intent, and everything after that happens on what the README calls the governed road, where no model is loaded or called (E5, a result the kit ships with its instruments' digests, not a check you re-run).

On the governed road, governance and execution are one process. The Substrate first decides admissibility: an inadmissible request is refused, and the refusal is itself a signed record with its reason. An admissible request becomes a sealed plan, whose identity is a deterministic function of its inputs (versions, intent hash, input hashes and pins), and the Substrate executes it, each link from intent to output hash-bound. The decision and the act are made by the same system in the same run, and both leave the same kind of record: a kernel export carrying the record's own signed payload bytes, its form hashes, the bodies it names, and the intent as submitted.

Records are tenant-scoped. A read with no declared tenant scope is refused, never widened, and the Substrate's own absent-scope refusal ships inside the verifier. One key signs everything, and you hold it.

The kit measures determinism: the same governed request, in fresh processes on macOS arm64 and Linux aarch64, by different people on different machines, produced byte-identical outputs, plan body, result and payload signatures; only wall-clock stamps, and hashes taken over them, differ (E2). The measurement matters less than what it makes possible.

Put the properties together and the verifier's shape is forced rather than chosen. A plan's identity recomputes from six inputs, so anyone who has them can recompute it (E1). Each link from intent to output is hash-bound, so it recomputes offline (E6). The payload is signed and one verifying key ships, so a signature checks without the signer present (the kit). Runs are deterministic, so a run is compared by hash rather than re-executed (E2, E3). And no model is loaded or called on the road, so there is nothing in the run whose behaviour would have to be trusted rather than recomputed (E5, a result the kit ships).

So a verifier needs the record, the intent as submitted, and a verifying key. That is exactly what each run in the kit ships. It needs no network, no database, no emitter, none of the Substrate's dependencies, and nothing that signs. Boundry Verify is built to that shape: seven read-only tools, standard library only, on your own machine.

Each question a reviewer asks then has a record behind it, not a log. The left column is the question; the middle is what the record holds for it, in the README's words; the right names the evidence item in the kit.

The first boundary is where governed operation begins; inside it, no model is loaded or called (E5, a result shipped in the kit). The second keeps the verifier independent of the thing it verifies: a separate package, on your machine, with nothing that signs.

Nothing above is done by Boundry Verify. The Substrate refuses, seals, runs and records. Boundry Verify reads the records the Substrate leaves and checks them, on your machine, with the Substrate nowhere in the picture: it attaches to no database, subscribes to no emitter, and contacts nothing.

Trusting a record should not require trusting the system that wrote it. The architecture above is what makes that possible; the verifier is built to be able to do no more than the architecture requires. It is a separate package: it reaches none of the Substrate's declared dependencies, and its own import chain is standard library only. It ships verifying keys and nothing that signs, so an evaluator verifies and does not re-sign. It has seven tools, all read-only, and there is no write tool and no disabled one.

The package ships evidence from real governed runs of the Boundry Substrate: one calculation, the smallest real transformation chain, and one refused request, each run independently on macOS arm64 and Linux aarch64, in fresh processes against fresh roots. Three tampered copies of one export sit beside them, and one verifying key. The inputs are synthetic.

Then run the package's own checks, from the unpacked package's folder:

python3 -I -B -m unittest discover -s server/boundry_connector -t server

They use only the standard library: no test framework to fetch, no network, no configuration. Expect 0 failures and 0 skipped. Running them does not alter the package; its tree digest is the same before and after. The README names the check that holds each of its claims.

Every claim this page makes about the system is one the README makes, and the README names the check that holds it. Some of the checks named there, as the README names them: