03 / Protocol And ProofProofs

Understand Bitcode proofs, witnesses, and replay

Proof docs explain the families, witness artifacts, replay steps, projection rules, generated appendices, and fail-closed posture behind AssetPacks.

Use this page when you read to understand why product readback is proof-bearing and how canon prevents stale or missing evidence from becoming product truth.

After reading

You can name the proof families and explain why witness artifacts, replay, and projection boundaries matter.

Proof families

01

Proof families are the replayable evidence contracts behind AssetPacks

Protocol carries proof families for synthesis, analysis, verification, selection, authorization, settlement, disclosure, and contract closure — each with witnesses and fail-closed conditions.

Each family has members, theorem IDs, replay steps, and witness artifact bindings. Product surfaces hide most of that detail until an operator needs an exact audit. Settlement and delivery never rest on a UI success state alone.

Why this matters

Operators need enough proof vocabulary to understand why proof readback is stronger than a button result.

  • Families explain what kind of claim was proven.
  • Witness artifacts explain what evidence backs the claim.
  • Replay steps explain how the claim can be checked again.

Disclosure

02

Projection keeps proof useful without leaking private source

Public, reviewer, buyer, and internal projections can expose different proof views while preserving one underlying artifact set.

Docs and product copy must never imply that public proofs contain licensed source by default. Measurements and needs-fits scores can be visible while protected IP stays withheld until rights transfer.

Why this matters

An AssetPack market only works if value is measurable without casually disclosing the source that gives it value.

Generated evidence

03

Generated appendices and proof artifacts are part of the system

Generated evidence includes version reports, gate checkpoints, proof appendices, composition proof, persistence totality, and closure witnesses.

When evidence is stale, missing, or inconsistent, Bitcode must fail closed rather than letting product language outrun proof truth.

Why this matters

This keeps commercial claims auditable as the system moves from testnet launch posture toward production readiness.

Disclosure limits

04

Public docs expose guidance and proof posture, not protected source

Public Bitcode docs derive from the active Protocol, package-owned catalogs, route contracts, and source-safe generated artifacts. They can explain usage, measurements, event ids, proof roots, docs links, runbook links, redaction posture, testnet rollout readiness, fee boundaries, and settlement posture.

They must not reveal protected source payloads, raw protected prompts, secret values, provider tokens, wallet private material, or unpaid AssetPack source. Source-bearing AssetPack contents cross to the reader only after settlement and rights transfer.

Why this matters

This keeps the public product understandable while preserving the boundary that makes AssetPacks economically and operationally safe.

  • Allowed: usage guidance, route links, state labels, source-safe measurements, proof roots, dashboard/runbook ids, redacted incident posture, testnet rollout readiness, LocalStagingTelemetryDocumentationRehearsal evidence, and fee/right boundaries.
  • Interface docs may surface event ids, proof roots, docs links, runbook links, and redaction posture from TelemetryDocumentationInterfaceIntegration without revealing source-bearing payloads.
  • Local and staging-testnet rehearsal docs may surface documentation discovery, telemetry event emission, dashboard/runbook lookup, docs QA, incident drill, source-safe proof-root review, and blocked value-bearing mainnet posture.
  • Blocked: secrets, provider tokens, wallet private material, raw protected prompts, protected source payloads, and unpaid AssetPack source.
  • Docs QA fails closed when public docs, internal docs, route docs, interface docs, generated artifacts, proof posture, or workflow checks drift.
  • Compatibility boundaries stay explicit: /exchange redirects to /packs and does not create a parallel current product surface.

Interface preview

Learn with the same UI grammar used in the product

These embedded specimens reuse product card and explainer patterns so docs readers become familiar with Packs, Deposit, and Read before they operate against them.

Proof runtime

Proof families become readable product signals

Product routes keep dense proof detail available without forcing every reader to start in raw artifacts.

Witness

Artifact-bound

Replay

Step-bound

Projection

Disclosure-bound