One artifact. Three different decisions.

Protocol design note · 7 September 2026

“Verified” is easy to print on a website. It is much harder to use precisely. Did we verify a signature? A calculation? A transaction's inclusion? A policy condition? Or the authority to take the next action?

Proof21's proposed consumer interface separates these questions deliberately. A single green result that hides the distinctions would be a poor foundation for autonomous financial workflows.

1. Verify the artifact

The first layer asks whether the artifact is intact and correctly bound under accepted key assumptions. It checks the structure, signatures, issuer, operation references, and supported encoding rules.

That can establish what an issuer signed. It does not independently establish that every signed statement is true. Existing record protocols such as PEAC make this issuer-reported evidence boundary explicit. [1]

A receiving system also needs a policy for key discovery, rotation, and revocation. An offline check against a supplied key is not evidence that the key is still accepted now.

2. Evaluate the named claim

The next layer applies a particular policy to a defined evidence set. It might compare a payout's recipient and amount with the instruction, or reproduce a DMT derivation from its referenced field and rules.

The output is scoped: pass, fail, or indeterminate, with reasons. It must not turn one passing predicate into a blanket claim about an agent's safety, investment performance, or the completeness of an entire process trace.

Evidence types matter here. A signed assertion, RPC observation, inclusion proof, and independently validated state are not interchangeable. Wrapping them in a common report should preserve the differences.

3. Apply local acceptance

The consumer then decides whether that result is enough for its next action. A low-value monitoring job and a high-value financial commitment may have different requirements for sources, finality, signers, freshness, and human approval.

This is why P21 does not replace every wallet or platform guardrail. The recipient retains authority. A report is evidence to consider under that authority, not a new permission grant.

Simple outside; explicit inside

The intended developer experience can still be compact. One SDK can carry a request, preserve original evidence, produce findings, and expose a consumer verifier. Simplicity should come from a consistent interface, not from removing uncertainty.

The first implementation milestone is two independent processes completing the loop: one produces a report, the other reproduces a supported check and rejects altered evidence. The current documentation describes that target; a released SDK is not yet available.

An authentic failure is useful evidence

Suppose a producer signs a report saying that a synthetic payout used the wrong recipient. An independent consumer establishes that the report has not changed and that the signature verifies under the supplied, accepted key. The integrity result can be positive while the payout evaluation is FAIL. A policy can then accept the report as useful evidence while refusing to authorize the payout-related next step. Those are three coherent outcomes, not a contradiction.

Conversely, an intact report may contain a producer's unsupported claim of success. The evaluator must not borrow certainty from the signature. The W3C Verifiable Credentials data model is a useful primary reference for distinguishing verification of credential mechanisms from the relying party's trust decisions; Proof21 does not claim that its draft artifact format is automatically a W3C credential. [2]

This separation also improves error messages. “Unsupported evidence profile” tells a consumer to obtain a compatible implementation or different evidence. “Recipient mismatch” describes a supported comparison that failed. “Issuer not accepted by local policy” concerns authority and trust. Collapsing all three into “invalid” can make remediation harder and encourage unsafe retries.

Bytes must be settled before signatures

Two JSON objects can look equivalent to a reader and still have different encodings. A signature needs a precisely specified message, not a screenshot or the reader's interpretation. RFC 8785 defines JSON Canonicalization Scheme rules, including constraints on data and deterministic serialization. It is a relevant design reference, not a substitute for selecting and testing the exact serialization profile used by an implementation. [3]

For a financial profile, large monetary quantities should remain decimal strings representing integer atomic units rather than values casually converted through floating-point arithmetic. The accepted schema must define the type and reject ambiguity. It should also bind the network, exact asset, operation identifier, policy version, instruction digest, and result digest inside the authenticated context rather than leaving important labels outside it.

A parser should reject unsupported versions and duplicate or conflicting fields under its documented rules. Bound input sizes before expensive work. Use established cryptographic libraries and their test vectors rather than asking an LLM to invent signature verification. RFC 8032 provides the EdDSA reference and test vectors; selecting Ed25519 does not by itself establish key ownership, revocation status, or permission to act. [4]

Acceptance belongs to a named consumer policy

Imagine two consumers receiving the same report. A monitoring dashboard permits a clearly labeled, stale observation for retrospective analysis. A treasury controller requires current evidence, a specific issuer, a sufficient confirmation condition, and human approval. It is reasonable for the dashboard to display the report while the controller refuses the transaction-related action.

The report should not silently select the weaker policy on the controller's behalf. Record which policy was evaluated, whether its prerequisites were met, and which next action was actually authorized. A later policy update must not rewrite the historical meaning of a prior decision. Keep the original version available for replay and record a new decision when reassessment is required.

For a pilot, have a producer and consumer run as separate processes with separate configuration. Test an authentic negative report, altered evidence, the wrong operation identifier, an unknown version, missing observations, and an unaccepted issuer. The educational offline demo already offers synthetic examples of limited integrity and policy checks. It is not a claim that dynamic key discovery, every evidence adapter, or a production acceptance service exists.

Frequently asked questions

Can signature verification pass while a payment check fails?

Yes. A correctly signed report can faithfully describe a failed payment predicate. Integrity concerns the authenticated artifact; evaluation concerns the named claim and evidence. The interface should display both results explicitly.

Does an accepted report authorize an agent to spend?

Not by itself. A consumer can accept a report for storage or review without granting authority to transfer funds. Action permissions belong to the application's explicit authorization policy and controls.

Can every evidence type be reduced to one trust score?

Doing so would hide important differences. A signed assertion, an RPC observation, and independently validated state support different claims. A common envelope should retain the original evidence type, provenance, limitations, and unresolved questions.