Complete verification
Full replay, evidence classes and the current operator trust boundary.
Verification compares submitted scientific output with actual complete replay of the declared model and task. It is a numerical integrity process with explicit scope and operator trust. A chain transaction cannot substitute for the replay.
Required complete work#
The verifier checks the job's graph, model, parameter profile, evaluator and backgrounds before admitting the replay. It executes the required extent and compares the original numerical records under the frozen contract.
All required backgrounds must complete for a scientific vote. A missing background, an interrupted native process or an unavailable model cannot be treated as proof that a candidate's science is invalid.
The response record, task identity and archive commitments preserve the original bytes. Display samples can help explain a result, but verification uses the required complete scope rather than only the visible samples.
Outcomes and faults#
| Outcome | Meaning | Appropriate treatment |
|---|---|---|
| VALID | Complete required replay agrees with the candidate | Count under the authorized verification policy |
| INVALID_RESULT | Complete replay establishes a numerical or contract mismatch | Record the scientific rejection and evidence |
| LOCAL_MODEL_ERROR | The verifier's local model is unavailable or wrong | Repair/fence the local setup; no scientific negative vote |
| RETRYABLE_INFRA_ERROR | An execution or transport dependency failed | Persist, retry and retain the original candidate |
The documented acceptance included a fresh complete replay of deliberately corrupted response bytes. It returned INVALID_RESULT after actual execution, which is stronger evidence than manufacturing an invalid result from an infrastructure failure.
User participation and task policy#
FBW users participate in validation voluntarily. Membership can evolve as users join or leave; each task records the admission rules, required evidence and decision policy that apply to that task.
A participating validator maintains the registered complete model, executes every required background and signs a report bound to the task and result. Reports are checked for identity, numerical agreement and task eligibility before acceptance. See Feature availability for the current participation path.
Evidence classes#
| Evidence | What it can establish |
|---|---|
| Frozen source/parameter hashes | Which numerical inputs and rules are declared |
| Native/WASM/NumPy agreement | Reproduction across tested implementations |
| Complete authorized replay | Agreement for the declared candidate and required backgrounds |
| Finalized Solana receipt | The exact recorded financial action on the specified cluster |
| Licensed external observation evaluation | Predictive performance within the defined scientific evaluation |
Computational reproducibility describes agreement within the registered model. Evaluation against biology uses separately licensed observations, declared calibration and held-out evaluation protocols.
Verification costs and compensation#
Replay consumes actual compute, storage and transport. A verification-service contract can reserve a finite budget and may compensate a correct rejection when its frozen terms say so. Thread count, runtime and reported throughput are not independent compensation units.
Archive retention and financial settlement have their own obligations. Scientific terminal states do not stop accepted financial reconciliation, and closing a temporary Result does not erase permanent payment uniqueness.
See feature availability for release scope and pending acceptance.