Boundry Verify

What it is

The Boundry Substrate runs work under governance: a request is admitted or refused, compiled into a plan, sealed, executed and recorded, and every step leaves a signed record. The work itself may come from a non-deterministic system such as an AI model. The execution that governs it is deterministic.

Boundry Verify is the tool for checking those records. It is a local MCP server that Claude Desktop runs on your computer. It has seven read-only tools. It cannot execute, sign or write anything, so the tool you check with has no power over what it checks. It opens no network connection.

One key signs everything, and you hold it. The determinism shown here is for the governed path, on the workloads in the kit, across the platforms named. Nothing on this page claims more than that.

Requirements

Claude Desktop, with extensions enabled.
Python 3.12 or newer on your computer. Check with python3 --version. The Python that ships with macOS is older. Boundry Verify refuses to run on it and names the version it found, instead of running with parts missing. Install a current Python from python.org or your package manager.
Nothing else. The connector uses only Python's standard library.

Install and configure

Install Boundry Verify from Claude Desktop's extensions directory, or open the .mcpb file with Claude Desktop.
Optionally, set Folders the connector may read. If you leave it empty, the connector reads its two packaged folders of synthetic records and nothing else. To add your own folders, list them separated by : on macOS and Linux. Each entry is a path, or label=path if you want answers to name the folder by label.
Name the folders you mean. Do not give it your whole home directory.

Whatever the connector reads is returned to Claude as part of your conversation. Read the privacy policy before you point it at anything that is not synthetic.

Try it

The package ships an evaluation kit: signed exports of governed runs of synthetic workloads on two platforms, plus three copies tampered with on purpose. Ask Claude, for example:

“Use Boundry Verify to compare runs calculation-m2 and calculation-linux-aarch64, global scope.” Expected: EQUIVALENT. It lists every field that differs, which should be timestamps only.
“Compare calculation-m2 with calculation-m2--forged-hash.” Expected: DIVERGENT.
“Check the plan identity of transformation-linux-aarch64.” Expected: HOLDS.
“Explain record transformation-m2.” Expected: the lineage from intent to output, link by link.

The seven tools

Tool	What it does
`verify_record`	Checks one sealed record with an independent verifier: ATTESTED, REFUTED, ALTERED or UNATTESTED. UNATTESTED describes a gap in the reader, never a finding against the record.
`get_envelope`	Reads one envelope.
`query_envelopes`	Lists envelopes within a declared scope.
`chain_status`	Reports what the reader can see of a folder. Each figure names the check that produced it, and each figure it could not take is named as not taken.
`explain_record`	Renders one record's provenance from the files read during the call.
`check_plan_identity`	Recomputes a sealed plan's identifier from its six inputs, and checks its seal.
`compare_runs`	Checks two runs against their own records, then compares them field by field: EQUIVALENT, DIVERGENT or UNREACHABLE. This is a comparison of hashes, not re-execution.

Every tool requires a tenant scope (global or per_tenant). Leaving it out is refused, not treated as permission to see everything.

What you can establish

E1 · A plan's identifier is a deterministic function of its inputs

The identifier is derived from six inputs and recomputes offline. It does not identify the plan body: the seal's content hash identifies the body. The two answer different questions, and we measured cases where one identifier carried two different bodies.

E2 · The same governed request gives byte-identical results on two platforms

Runs on macOS arm64 and Linux aarch64, made by different reviewers on different machines, produced identical outputs, plan bodies, results and signatures. Only the wall-clock timestamps, and the hashes taken over them, differ. This covers a calculation, a transformation chain and a refused request.

E3 · Tampering after the fact is detected

Recorded hashes are compared with stored bytes: a changed byte and a forged hash are DIVERGENT, and a lost output is UNREACHABLE. This is detection, not re-execution.

E4 · A refusal is itself a signed record

An inadmissible request is refused, and the refusal is sealed with its reason.

E5 · No model is loaded or called in governed operation

The kit ships the result of the programme's conduct-line check, together with the digest of the instrument that produced it. The check's source does not ship, so this item is a result, not a re-runnable check.

E6 · Every link from intent to output is hash-bound

Intent, plan, seal, execution, output and closure: every link recomputes offline. The submitted intent ships beside each run.

Check the package yourself

From the unpacked extension's folder:

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

The checks use only the standard library. Expect 0 failures and 0 skipped. The package README names the check that holds each claim.

Known limits

One key and synthetic data. This demonstrates the mechanism; it is not a multi-party trust system.
E2 covers the governed path, on three workloads, on two platforms.
E5 ships a result, not a re-runnable check.
One malformed file makes a declared folder unreadable, and the connector states the reason. Hard-linked files are refused, including legitimate ones.
It does not make your conversation private.

Support

Questions, problems and security reports: verify@boundry.tech. If your measurement disagrees with this page, your measurement wins, and we want to hear about it.