Transparency log • Preview • Procurement-grade

Append-only release log.
Inclusion proofs you can replay.

A transparency primitive for consequential AI operations: releases are explicit, artifacts are pinned, and review is offline‑verifiable. When signatures are missing, reviewers must HOLD (fail‑closed).

Dots are release entries. New entries append; old ones are not silently rewritten.
Line is the inclusion path. Proofs are replayable offline (deterministic).
Root is published per rail (DSSE). Missing signatures ⇒ HOLD (fail‑closed).

How reviewers use it

Start with the signed DEMO rail (one-shot GO). Production stays fail‑closed until operator-held keys sign publication.

Step 1OpenSigned

Read the feed

Use the site‑release feed as the authoritative index of public artifacts (manifest + headchain + evidence bundle pointers).

Step 2VerifyOffline

Verify headchain + manifest

Run the offline verifier to confirm continuity, freshness windows, and strict integrity (SRI + critical assets). Any mismatch ⇒ HOLD.

Step 3AttachTicket

Attach to procurement

Attach a single input (DSSE) or the full ticket pack bundle to your review ticket system (Jira/ServiceNow).

Machine‑readable artifacts

Advanced reviewers can directly inspect the underlying receipts. These are the controlling sources; pages are explainers.

Example inclusion proof object (preview schema)

For preview, a proof object is a small JSON blob containing a leaf hash, sibling path, and a signed root. (Exact signing key + witness threshold depend on rail.)

{
  "schema_id": "mvg.transparency.inclusion_proof@1",
  "proof_version": "1.0.0",
  "rail": "DEMO",
  "leaf": {
    "site_release_id": "MVG-SITE-DEMO-20260218.1",
    "leaf_sha256": "sha256_of_canonical_leaf_payload"
  },
  "path": [
    "sibling_sha256_0",
    "sibling_sha256_1"
  ],
  "root": {
    "root_sha256": "merkle_root_sha256",
    "root_sig": "detached_signature_or_dsse_envelope"
  }
}