Evidence discipline
Record and present reproducible proof status.
Keel evidence is recorded on independent axes: retrieval and integrity, observation source, verifier trust class, and availability. Browser reproduction and deployment receipts are additional evidence records, not steps on one ladder.
Proof and status model
Status records should be structured enough to reproduce, not merely persuasive copy.
Claim
One precise proposition such as decoded bytes match, presentation is current, route is immutable, supply policy is bounded, module bytes reproduce, or a deployment exists at an address.
{
"claim": "decoded bytes match",
"status": "bytes-verified",
"environment": "local-browser",
"evidenceDigest": "sha256:…",
"limitation": "not a live deployment check"
}Evidence
Source path, test command/result, manifest/receipt digest, chain/network/block, contract/code identity, transaction, browser build, verifier route, timestamp, and critic verdict support that one claim.
Limitation
Unqueried chain families, trusted RPC, missing adapter, unavailable carrier, local-only browser, absent deployment record, pending critic, or unsupported operation stay beside the claim.
Independent evidence axes
Each axis answers a different question. Passing one axis never promotes or fills in another.
Retrieval and integrity
Record whether a source is only declared, whether the decoded bytes match the exact length and digest, and whether those bytes are bound to the inspected object, registry, revision, viewer, collection, token, and active presentation.
- Declared means a manifest or registry names a source; it is not yet verified.
- Bytes verified means the retrieved, decoded bytes match the committed length and digest.
- Registry-bound means those exact bytes and identifiers match the exact state and revision inspected.
Observation source
Name how state was observed: local scenario or mockup, a pinned trusted RPC response, or a chain receipt and re-read. An observation describes the source of the evidence; it does not choose the verifier trust class for an anchor.
Verifier trust class
An anchor route declares native, optimistic, attested, or client verification. Record the exact verifier route and version. Native checks same-chain state; attested depends on the named signer or service policy; client depends on the local verifier. The repositories define an optimistic extension point, but no concrete optimistic adapter is currently claimed here.
Availability
Record whether a usable carrier was observed and when. A matching hash, CID, portable root, registry binding, or anchor proves no present availability by itself. Replication and monitoring improve availability without changing object identity.
Browser reproduction
A loaded browser can reproduce an exact named fixture, build, viewport, and assertion set. That proves the described local or mockup browser behavior; it does not prove a public deployment or an unqueried chain.
Deployment record and fresh read
A repository record may name network, address, code identity, block, and transaction. Preserve that as a recorded deployment. Only a fresh independent chain re-read can establish current code, configuration, roles, and observable state.
Reads, writes, and authority
Proof state is generated by several actors with bounded roles.
Verifier reads
Read the exact manifest, bytes, current registry/presentation, code identity, verifier route, proof payload, chain block, and status record needed for the claim.
Evidence writers
Builders write local receipts, publishers write objects/anchors, contracts emit events, indexers project events, attestors sign scoped reports, browser tests write screenshots/results, and independent critics judge promotion.
Promotion authority
No worker approves its own work. A stronger public status requires the independent role and evidence defined for that gate.
Failure and security boundaries
Unknown and failed are useful results.
Unknown stays unknown
Absent supply, burn, cap, upgrade, or mint-authority evidence is not zero and is not automatically green or red.
Availability is separate
A matching hash, CID, or anchor can be correct while every carrier is unavailable. Replication contributes availability without changing authenticity.
Integrity is separate from safety
Exact hostile code can still attack the host if the sandbox, bridge, capabilities, and wallet boundary are wrong.
Local is separate from live
Source, unit tests, local chain, mockup, browser harness, testnet record, fresh testnet read, mainnet, and public deployment are separate evidence scopes.
Ethereum and Tezos evidence
Parity is a checklist, not a shared adjective.
Ethereum
Foundry suites, generated ABIs, module deployment JSON, SDK adapter tests, and Studio EVM browser paths are distinct evidence sources. A deployment JSON is not a fresh RPC verification.
Tezos
SmartPy scenarios, shared vectors, Octez mockup operations, interactive ZIP/browser checks, and any remote Shadownet operation are separate. Current package documentation withholds release approval.
SDK and Studio surfaces
Proof presentation derives labels from evidence instead of trusting arbitrary flags.
SDK
Verification shell, source verification, collection verification, module assurance, build receipts, wallet-plan verification, and proof presentation provide machine-checkable inputs.
Studio
Trust, collection, object, artifact, module, preservation, anchor, and system views should show claim, evidence, environment, status, limitation, and reproduction path without horizontal comparison tables.
Exact evidence sources
These are the principal executable lanes named by the current repositories.
Module assurance
Source/output/recipe/receipt/catalog tamper drills and public reproduction.
Trusted runtime
Host bridge, capabilities, sandbox clamp, frozen datasets, module review, adversarial boundary, and browser behavior.
Contracts and chains
Focused Foundry modules, Tezos SmartPy scenarios, Octez mockup gate, and repository deployment records.