Skip to content

Same answer. Different evidence.

Two providers returned BACKUP. One left the exact model named in the accepted terms, plus enough evidence to rerun the promised input-to-output relation; the other left only its own process claim. After both provider processes stop, a local verifier applies the buyer's rule to the retained records.

Experimental source-only demonstration.

Buyer rule

Accept the result only if retained model and input reproduce the returned bytes and every effect in the supplied receiver record has a matching receipt.

Compare and recheck the provider transactions

DimensionOpaqueRecheckable
Returned answerBACKUPBACKUP
Retained modelUNAVAILABLEAVAILABLE
Local recheckNOT RUNNOT RUN
Buyer decisionNOT COMPUTEDNOT COMPUTED
What this check cannot tell you

This demonstration uses synthetic records and project-authored checkers. It does not establish what model a provider actually ran, whether the answer is true, whether the action log is complete, or whether money moved.

Technical evidence

The profile uses one closed synthetic task and team-controlled roles, evidence, keys, receiver records, witness roots, policies, and settlement reports. Reproduction establishes a retained model-input-output relation, not which model the provider historically ran, answer truth, model quality, or family identity. Coverage is relative to the supplied receiver record and does not establish its completeness. The result does not establish payment execution, custody, collectibility, production clearing, organizational independence, representative adoption, or worldly truth. Python, Node, and browser agreement is project-authored corroboration rather than external implementation evidence.

What the supplied evidence supports

The retained model reproduces one computational relation, so the supplied buyer policy accepts that provider's result. This does not establish which model the provider historically ran, whether BACKUP is true, whether the receiver recorded every effect, or whether funds moved.