> For the complete documentation index, see [llms.txt](https://docs.trueopen.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trueopen.ai/protocol/v1/tasks/verification.md).

# Verification Rules

Independent result checking, commit-reveal, verdict formation, and failure paths.

Verification checks whether the Worker's committed output satisfies the judgment rules frozen by the Task's Profile.

## Frozen execution context

Every Verifier evaluates the same Task-bound context:

* Input and output commitments
* Model and Profile version
* Manifest, tokenizer, and schema commitments
* Judgment-function and canonical-encoding versions
* Evidence schema
* Effective generation parameters recovered from the Worker's committed token opening
* Worker's signed inference receipt

A Verifier cannot substitute another Profile, tokenizer, runtime interpretation, or generation default.

The Worker commits separately to token IDs and per-token values. A Verifier checks both openings against the accepted receipt, then compares its own per-token values with the Worker's committed values. See [Data and evidence](/protocol/v1/data-and-evidence.md).

## Full-output verification

V1 verification evaluates all committed generated token positions using the Profile's defined prefill or teacher-forcing procedure. Normal verification does not sample a subset of output positions.

This keeps the verification target stable: the Worker commits to one result, and each selected Verifier independently evaluates the same complete committed output.

## Commit then reveal

Verification uses a commit-reveal sequence:

1. A selected Verifier computes its result and commits to the result payload with a private salt.
2. After the commit boundary, it reveals the result material and salt.
3. The chain verifies that the reveal matches the earlier commitment and the Task context.

This prevents a Verifier from waiting for another participant's visible answer and copying it into a valid late commitment.

A commit or reveal is accepted only for the selected operator, current round, expected Profile, active deadline, and current service authorization. Once accepted, the fact belongs to the stable operator even if its service key later changes.

## Verdict formation

Each valid result binds a typed metric summary, metric root, aggregate proof hash, evidence commitment, and Task context. The result does not supply its own verdict or work-unit count. The chain derives a sample verdict from the frozen thresholds and derives the count from `finite_count + missing_compared_count`. Results with inconsistent counts, invalid commitments, bad signatures, late submissions, or unmatched commits are excluded.

The summary is computed with integer arithmetic from the comparison leaves. Missing and non-finite leaves count as missing comparisons. If all leaves lack usable Worker values, the enabled comparisons take their defined worst values; missing Verifier values cannot be used to blame the Worker.

The protocol forms a verdict only from a sufficiently large consistent result cluster. A minority result is not rewritten to match the majority and does not receive the majority's payment eligibility.

If the required threshold is not reached, the round closes through the defined no-consensus or verification-unavailable path rather than inventing a verdict.

## Deadline behavior

Assignment, inference, commit, reveal, and round-close deadlines are expressed in block height. Missing actions are processed by deterministic protocol runners. Local wall clocks and service-side timeout observations do not create the failure fact.

Every deadline path must terminate or advance the Task. A missing transaction submitter cannot leave funds permanently locked; after prioritized submitter windows expire, self-rescue or deterministic runner paths apply the same state transition.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.trueopen.ai/protocol/v1/tasks/verification.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.