Evidence and report model

The report model binds an operation to its evidence, policy, findings, and evaluator. Original signed artifacts remain attached to their source identities. Wire-format availability is tracked with implementation status.

Required concepts

Evidence classifications

An issuer assertion, a signed observation, an RPC observation, a cryptographic inclusion proof, a validated chain state, and a reproduced calculation are different classes. Keep those labels intact. One valid inclusion proof does not, alone, establish that its chain is canonical or sufficiently confirmed.

Use integer strings for financial amounts with an explicit network and asset contract. Avoid floating-point money. Preserve original bytes and signatures when normalization is necessary for evaluation.

Serialization and signing

Choose reviewed signing and canonicalization mechanisms during implementation; pin their versions and publish conformance vectors. Do not treat arbitrary JSON.stringify behavior as a universal cross-language standard. Domain separation, algorithm selection, duplicate keys, numeric ranges, and unknown critical fields require explicit rules.

An unrecognized profile must not silently pass. Resource limits apply to document size, nesting, evidence downloads, redirects, and parsing time. A receipt's embedded URL or text never authorizes fetching secrets, installing tools, or changing agent policy.

<!-- p21-source-payment-v08 -->

Resolution, registration and ownership are separate

Receipts distinguish source extraction, element registration, deterministic derivation, token deployment/mint validity, and current ownership or balance. Verification of one never implies the others. Checking first-valid registration requires the relevant historical index and activation rules; an inscription inclusion proof alone does not prove that no earlier conflicting element exists.

Pin the inscription's content digest, source profile, upstream revision, network, source block hash and height, canonical encoding, operation, parameters, input commitment and output. Include evidence scope and limitations. A missing source or unsupported pattern is INDETERMINATE, not a fabricated valid result. Indexer observations remain distinct from independently replayed protocol state. A raw Bitcoin-field fallback cannot silently satisfy an unperformed DMT registry check.

Payment evidence and exactly-once accounting

An invoice binds caller, request digest, idempotency key, exact network and asset identity, merchant recipient, integer atomic amount, service-credit entitlement, expiry and settlement policy. A payment adapter checks an executed transfer event and its destination, amount, deployment identity, canonical block, confirmations, index coverage and supported rule revision. A transaction ID, mempool observation, inscription creation or wallet balance screenshot is not payment settlement.

Store event uniqueness using network, asset deployment, transaction and operation/inscription identity. Bind invoice ownership to the caller through the invoice contract rather than accepting any submitted transaction hash. Use atomic ledger transactions and unique constraints for settlement crediting, job reservation, consumption and release. Network retries and webhook replay never create another credit or charge. Missing evidence, lagging/conflicting indexers and reorganizations remain pending or require review. Define a compensating journal and operator-loss policy for a deep reorganization; do not silently debit another customer payment.

[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559

<!-- p21-enforcement-v10 -->

Authorization and consumer-decision artifacts

The v0.10 specification adds three machine-readable draft artifacts: an action authorization, a consumer decision receipt, and equivocation evidence. They are separate from the ordinary evidence report.

An action authorization binds requestDigest, policyDigest, actionDigest, action profile, network, nonce, validity window and signer identity. The action digest is computed over profile-defined canonical action bytes. Immediately before a protected action is signed or invoked, the execution gate recomputes that digest and rejects any mismatch, expiry or nonce replay.

A consumer decision receipt binds the proof/request/action, the consumer identity, the acceptance-policy digest and version, ACCEPT | REJECT | REVIEW, deterministic reason codes, evidence snapshot, decision time and signature. Decision consistency is not self-declared by the consumer. It is derived by an independent evaluator as CONSISTENT, CONTRADICTORY or UNRESOLVED.

Equivocation evidence consists of two valid, incompatible signed decisions for the same committed proof/policy/decision context. P21 reports the cryptographic contradiction; reputation systems may consume that evidence separately.