Works now

Run the proof yourself.

G‑14 turns high-consequence AI action into a signed proof packet. Download this one, run the verifier on your machine, and see it accept governed robot-action records while rejecting fake, tampered, or incomplete evidence.

No dashboard trust. No sales call. No "take our word for it." The artifact leaves G‑14 and still verifies.

Download proof pack Run the verifier Request production evaluation

5 allowed packets pass6 bad packets fail1 verifier included

Independent verifierReady

Local result

PASS5 governed actions verified. 6 attack cases rejected.

Robot action requestSigned proof packetVerifier receipt

{"negative_packets_failed_as_expected": 6, "positive_packets_verified": 5, "status": "pass"}

Try it now

Upload the proof pack and run the hosted verifier.

This form calls the same public verifier endpoint documented for the AMR proof-pack release. The hosted verifier is deliberately pinned to this proof artifact and deletes the upload after the request.

Verifier resultREADY

Select the downloaded proof pack to get a live verifier receipt here.

Specific action proof

How this shows whether the AI followed what it was allowed to do.

A verifier result is only useful if it connects to a real action. In this proof pack, each case ties one autonomous mobile robot action to the policy decision, the evidence available at the time, and the dispatch outcome that actually happened.

In plain English: PASS does not mean the AI was allowed to do anything. It means this packet proves the action followed the allowed path for that specific case: send it, hold it, release it, block it, or fail closed.

What did the AI try to do?

The packet names the specific action request: robot, site, zone, requested command, task ID, and permit ID.

What was it allowed to do?

The packet includes the permit decision and the rule path: allow, hold for review, block, or fail closed into a safe state.

What actually happened?

The packet includes dispatch records showing whether the command was sent, suppressed, released by an operator, blocked, or moved into safe state.

Did anyone alter the story?

The verifier checks signatures, section hashes, cross-view transcript roots, replay protection, and signer-topology evidence before it accepts the packet.

Allowed case

01_immediate_allow

Request: AMR-12 requested `pause` in warehouse-east / zone-g3.
Allowed boundary: This reversible medium-criticality action required no operator review.
Observed outcome: The permit decision was `allow`, and the dispatch record shows the command was sent.
What PASS means here: The verifier pass means the signed packet consistently shows this action was inside the allowed boundary.

Held then released case

02_hold_release

Request: AMR-12 requested `zone_authorize` for zone-g3.
Allowed boundary: The high-criticality action required zone and egress clearance, camera and safety-scan evidence, and operator review.
Observed outcome: The runtime first suppressed dispatch, then released it only after operator-demo-1 allowed the action.
What PASS means here: The verifier pass means the AI did not simply proceed. It held until the required review path produced a release.

Held then blocked case

03_hold_block

Request: AMR-12 requested `zone_authorize` for the same bounded zone.
Allowed boundary: The required clearance and evidence were missing, risk was above threshold, and operator review was required.
Observed outcome: The runtime suppressed dispatch and kept it suppressed after the operator blocked release.
What PASS means here: The verifier pass means the packet proves the action was not allowed through when the rule path said block.

Why this matters

Logs ask people to trust the system being questioned. This does not.

A normal robot log says an action happened. A G‑14 proof packet lets a buyer check whether the governed action record holds together after it leaves the vendor.

The robot action had a permit

The packet shows the action path was governed before the autonomous mobile robot acted.

The proof survived export

The record can leave G‑14 and still be checked without asking our dashboard what happened.

Tampering is visible

If the signed body is changed, the verifier rejects it instead of trusting a polished audit trail.

Missing evidence is visible

If required evidence is absent, the verifier tells the reviewer what failed.

Five-minute proof path

From download to verifier result.

Buyers get proof under their own control: a local verifier result that accepts valid governed-action records and rejects broken evidence.

1 min

Download the artifact

Save the proof pack zip. It contains signed passing packets, rejected failure cases, checksums, key material, and the verifier.

1 min

Pin what you received

Compare the published SHA-256 and run the internal checksum ledger so the files cannot quietly change underneath the test.

3 min

Check the action proof

Run the verifier. It must accept the governed AMR actions and reject the fake, broken, or incomplete packets.

Linux / WSL commands

Run the complete offline verifier path.

The offline wheelhouse includes the runtime verifier and Linux/WSL-compatible dependency wheels for this proof-pack release.

sha256sum g14-amr-customer-proof-pack-v0-20260425.zip
unzip g14-amr-customer-proof-pack-v0-20260425.zip -d g14-amr-customer-proof-pack-v0-20260425
cd g14-amr-customer-proof-pack-v0-20260425
sha256sum -c SHA256SUMS.txt
python -m venv .venv
. .venv/bin/activate
pip install --no-index --find-links verifier-wheelhouse agent-control-runtime
python tools/verify_pack.py

Expected final output

If the download and verifier are intact, the final command returns this.

{"negative_packets_failed_as_expected": 6, "positive_packets_verified": 5, "status": "pass"}

What is inside

The proof pack contains both the success path and the attacks.

The artifact is small enough to inspect, but it is not a toy path. It includes signed success cases, negative failures, a public keyset, a checksum ledger, and the verifier wheel needed to reproduce the result.

Included

It leaves our system

The proof packet is a downloadable artifact with evidence that survives beyond screenshots, dashboard views, or vendor-controlled logs.

Included

You run the verifier

The bundle includes the verifier needed to check the packet locally on a prepared Linux or WSL workstation.

Included

Bad evidence gets rejected

The same test pack includes broken packets so buyers can see the verifier catch tampering and missing evidence.

Release ledger

Pin the artifact before you run it.

These digests are published so a reviewer can confirm the outer download, the internal checksum ledger, the manifest, and the verifier wheel before evaluating packet behavior.

Zip file: g14-amr-customer-proof-pack-v0-20260425.zip · 5.0 MB · generated April 25, 2026
Zip SHA-256: b00b2ce5298e2795b7453fbaa8558ab6b7a472423375cdabd5d3478ab7495a55
Internal checksum ledger: 12a23990ef763a81a2321ffca5cc517f074437a522f7ecb2d0b397ee4ec3f06e
Manifest SHA-256: 5c081add96628e40162fb7d533f876e18fe838e697993e2735b00a13af9c5af3
Verifier wheel SHA-256: 5484586aa341cd835cba9e4302366e7dcf662d8084710bdd2e9d74cb9abf1f47

Manifest JSON Internal SHA256SUMS Public proof-pack index README_VERIFY

Non-Linux systems

Use the same runtime verifier wheel and let pip resolve platform dependencies.

The runtime verifier wheel is pure Python. If the bundled Linux dependency wheels do not match your platform, install the verifier wheel online so pip can select the right platform wheel for cryptography.

python -m venv .venv
. .venv/bin/activate
pip install verifier-wheelhouse/agent_control_runtime-0.1.0-py3-none-any.whl
python tools/verify_pack.py

Expected corpus behavior

The verifier has to accept success and reject the named failures.

A proof system that only shows happy paths is not enough. The public pack includes the failure cases a serious reviewer expects to see.

Passing packet set

01_immediate_allowImmediate allowed AMR actionpass

02_hold_releaseHeld action released by operator authoritypass

03_hold_blockHeld action blocked before releasepass

04_timeout_safe_stateTimeout path that settles into safe statepass

07_replay_seed_allowReplay-seeded allow path used to prove rejection behaviorpass

Negative corpus

f4_unsigned_packetUnsigned packetfail

f4_tampered_signed_bodyTampered signed bodyfail

f5_missing_cross_viewMissing cross-view evidencefail

f5_missing_inclusion_proofsMissing inclusion prooffail

f6_realized_support_shared_domainSigner support not independentfail

f6_product_signature_key_not_declaredSignature key absent from topologyfail

Failure reasons

Every negative case has a plain-language reason and a verifier check.

A customer does not have to decode internal vocabulary to understand why a proof packet failed. The formal check is still exposed for engineering review.

Unsigned packet

The packet has no product signature, so the verifier cannot accept it as a G‑14-issued proof packet.

f4_unsigned_packetproduct_signature_present

Tampered signed body

The body no longer matches the signed section hashes, so the verifier rejects the altered evidence.

f4_tampered_signed_bodysection_hash:evidence_bundle, packet_body_hash, product_signature_valid

Missing cross-view evidence

The packet omits the cross-view block required to bind disclosed views to a shared execution transcript.

f5_missing_cross_viewcross_view_present

Missing inclusion proof

The packet declares a cross-view root but lacks the inclusion proof for disclosed runtime metadata.

f5_missing_inclusion_proofscross_view_path:$.runtime_metadata:proof_present

Signer support not independent

The realized signer support shares a compromise domain, so the claimed signer-independence precondition is not discharged.

f6_realized_support_shared_domainindcert_field_support:2:realized_support_mutually_independent

Signature key absent from topology

The product signature key is absent from the signer-topology certificate, so the verifier cannot connect the signature to the claimed trust topology.

f6_product_signature_key_not_declaredsigner_topology_product_signature_key_declared

Claim boundary

Real proof, clearly bounded.

This artifact proves the verifier path. A production evaluation binds the same proof discipline to the buyer's own action class, policy, evidence boundary, and environment controls.

What this proves

The runtime can export signed AMR proof packets with a public verification keyset.
A clean local verifier run accepts the positive corpus and rejects the negative corpus.
The downloadable artifact is checksum-pinned and reproducible after extraction.

What it does not prove

It is not a certification, production customer attestation, or SOC report.
It does not claim an external deployment has discharged every F5 or F6 assumption.
It does not require the buyer to trust a dashboard screenshot to inspect the evidence object.

Allowed claim

This artifact is generated by the Agent Control Runtime AMR proof-pack pipeline and can be verified locally.

Allowed claim

The verifier accepts five signed positive cases and rejects six named F4/F5/F6 negative cases.

Required boundary

This is not a certification, customer deployment attestation, SOC report, or claim that any external production environment has been assessed.

Evaluation path

A verified packet turns skepticism into a production question.

After a buyer verifies the packet, the next conversation becomes the governed action class, policy, evidence boundary, and deployment environment.

Before this

Packet library

Focused proof artifacts give technical buyers something they can inspect before deeper diligence.

Open Packet library

Current step

AMR proof packet test

Download the signed packet pack, verify the checksum, and run the included verifier locally.

You are here

Next step

Request access

If the artifact verifies and the problem is real, move into production evaluation.

Open Request access

Download proof pack Request evaluation