Proof

Receipts, not promises.

Buyer‑observed proof of pre‑action control: deterministic replay, pinned versions, stable reason codes.

Offline Pinned versions Stable reason codes PASS / FAIL / HOLD
What makes this different Buyer‑observed Deterministic replay

Block real actions until a valid Permit + receipts verify. Missing / stale / unverifiable → HOLD (fail closed).

Where Proof fits

Trust Center shows the live public state. Controls explains the mechanism. Proof is the replayable appendix for buyer-run verification, acceptance scenes, and audit questions.

Claim lineageReplayable appendix trace

Trace each appendix claim to the public state bundle.

Use lineage when a reviewer needs to understand which state object, evidence manifest, and receipt chain support a deeper appendix claim.

State
Evidence
Receipt
Focused lineageAppendix trace

Reason · Best route ·
Trace claim lineage Download manifest Open verifier Read replay spec
Download Ticket Pack (Attach 1 ZIP) Verify offline (30s)
2‑minute verify Website release integrity Canonical PROD rail

Download the canonical PROD Evidence Bundle, unzip, then run:

python3 public_verify_site_release_v50_4.py --evidence-bundle MVG_SiteRelease_Evidence_Bundle_MVG-SITE-PROD-20260227.3.zip --trust-mode prod

Expected output: GO. UI is display‑only; authoritative state is the signed status artifact: MVG_SITE_RELEASE_STATUS_LATEST.json (signature). Need a compatibility rail? Use the demo appendix path, not the front-door authority.

Offline verifiers Download sample Conformance Pack Trust Center

Non‑guarantee: This proof verifies integrity + pins + deterministic replayability. It does not guarantee semantic correctness or universal safety.

What buyers can independently verify (offline replay)

Portable artifacts Security / Legal can validate without interviews or screenshots.

IntegritySHA‑256

Manifest + SHA256SUMS

Every file digest is pinned and independently re‑computed in‑browser.

SignaturesEd25519

Signed registry snapshots

DSSE required; optional COSE_Sign1 + JWS equivalence in Auditor Mode.

DeterminismReplay

PASS / FAIL / HOLD reproduction

Reason codes are resolved under pinned semantics; decisions are re‑derived deterministically.

What to ask in an audit

10 questions that should have concrete, replayable answers.

1) Determinism boundary?

Expected: Missing / stale / unverifiable inputs → HOLD (fail closed). Pins are explicit.

2) Check ↔ action TOCTOU?

Expected: Permit‑before‑action at real control points. Gate blocks until permit verifies.

3) Policy drift prevention?

Expected: Pinned registries + snapshot IDs. Reason codes resolve under pinned semantics.

4) Unit of evidence?

Expected: Portable Evidence Pack + Conformance Report JSON (machine‑ingestable).

5) Revocation & TTL?

Expected: Revocation overrides allow. Expiry enforced. Receipts show deterministic reasons.

6) Loopback/proxy bypass?

Expected: Action surfaces are declared. Bypass attempts deterministically DENY.

7) Trust anchoring?

Expected: Signed snapshots (DSSE; optional COSE/JWS). Witness/transparency are auditable knobs.

8) Offline verification?

Expected: /verify runs fully offline (no uploads, no network calls).

9) GRC export?

Expected: Export report JSON + signed report for audit trails (demo signing).

10) Acceptance tests?

Expected: Buyer‑run tests reproduce PASS/FAIL/HOLD outcomes under pinned versions.

The ask Security present

30‑minute technical deep dive

Reply with (1) your highest‑risk action surface (egress / device I/O / dispatch), and (2) who consumes evidence (Security / audit / GRC). We’ll map the control points + acceptance tests.

Contact security@ Verify procurement kit