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 Source Shares.
Use this page when you read to understand why a Terminal read is proof-bearing and how V26 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 are the replayable evidence contracts behind Source Shares
V26 carries proof-family canon for inference synthesis, prompt completeness, static code analysis, verification decisions, selection and materialization, authorization and sensitive flow, settlement source-to-shares, disclosure boundary, and proof contract closure.
Each family has members, theorem IDs, replay step IDs, witness artifact paths, artifact bindings, and fail-closed conditions. The product hides most of that detail until the user needs an exact read.
Why this matters
The docs read enough proof vocabulary that users understand why a green result is stronger than a UI success state.
- 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.
Projection and redaction keep proof useful without leaking private source
Public, reviewer, buyer, and internal projections can expose different proof views while preserving a single underlying artifact set.
Docs and product copy must never imply that public proofs contain licensed source by default. Bounded-public proof is a separate projection from private proof payloads.
Why this matters
A Source Share market only works if value is measurable without casually disclosing the source that gives it value.
Generated appendices and proof artifacts are part of the system
V26 generated evidence includes spec-family reports, canonical input reports, gate checkpoints, proof appendices, application composition proof, conversations continuity, persistence/schema totality, retained package admissibility, and later 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 repository moves from launch-mode demonstration state toward production readiness.
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 Source Shares 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.
- Deferred boundaries stay explicit: V35 documents Exchange and Conversations usage while deeper product depth remains future-canon work.