> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. # Choose verification and read its evidence ## Start with what the result must prove Ask your agent what decision the result must support and which items the check must cover. For a fictional 40-invoice batch, a coverage check asks whether all 40 invoices have an outcome. A quality review asks whether the extracted values are correct. Choose both when the decision needs both. > **Conceptual task brief:** Decide whether every accepted row is structurally complete and represented. Check schema validity and coverage for the frozen population; preserve disagreements and abstentions. Return each stage as `passed`, `failed`, `not_run`, or `not_applicable` with its evidence. Accept only when the required stages pass for the declared population; do not call `quality_evaluated` proved by a digest or receipt. No single check proves everything. Lithi returns the agreed check results and evidence. Your agent reviews failures, disagreements and abstentions before deciding what to accept. Common checks include schema validation, coverage, deterministic rules, sampled review, full review under its declared method, and a rubric with versioned criteria. Integrity checks whether the declared bytes or artifact can be trusted. Schema checks shape and types. Grounding checks whether claims point to the permitted source. Coverage checks whether the expected population is represented. Semantic quality asks whether the accepted content is correct for the decision; it needs its own review. Your agent names the decision and reviews the returned evidence. The Kit prepares the selected checks, and participating Macs process the bounded request under the operation and policy you chose. The selected verification settings and supported integration map that brief to the permitted checks and returned evidence. They do not create a broad `verified` claim or replace task-specific quality review. The kit reports named result levels rather than a bare `verified` flag: `descriptor_matched`, `transfer_authorised`, `bytes_verified`, `decryption_authenticated`, `schema_validated`, `coverage_reconciled`, and `destination_committed`. Each level has its own evidence and does not imply the next one. Each stage is `passed`, `failed`, `not_run`, or `not_applicable`; unreadable or unexecuted work remains `not_run`. `destination_committed` is a local destination commit and read-back check. The kit leaves `quality_evaluated` outside its scope and records it as `not_run`; a digest, receipt or successful file check cannot establish that a model answer is correct. Apply a task-specific evaluation when semantic quality is part of your decision. A receipt or digest authenticates its declared evidence boundary. It does not prove that every token was handled or that the model answer is semantically correct. Treat each level as a checkpoint. If `bytes_verified` passes but `schema_validated` is `not_run`, the agent has integrity evidence and no schema evidence. If `coverage_reconciled` fails, keep the missing or disputed items visible and stop before treating the result as complete. A later level cannot repair an earlier failed or skipped check. ## Bind the policy before approval Choose the verification mode, rate, or rubric before requesting the final quote. The quote and job bind the applicable verification policy, so you can interpret the result against the same rules later. When approval is required, approve the complete signed quote through its digest, including the verification policy and exact charge terms; approval does not repeat for each physical attempt within that policy. Changing the rubric, rate, threshold or required evidence changes the reviewed intent. ## Version rubrics instead of editing history A rubric should define: - the decision being scored; - allowed labels or scores; - required evidence; - treatment of missing information; - abstention conditions; - version identity. Calibrate a new version separately. Do not rewrite an old rubric under the same identity after results already depend on it. ## Read evidence by scope Ask: 1. What population was eligible for this check? 2. What population was actually checked? 3. Which method ran? 4. Which items failed, abstained or disagreed? 5. What evidence is attached to those outcomes? A valid receipt or digest can authenticate the declared evidence boundary. It does not turn a model judgment into business truth without further review. ## Preserve disagreements and abstentions Do not force every item into an accepted answer. A disagreement can be the right evidence that two checks did not converge. An abstention can be the right result when the available information does not support the requested judgment. Resolve the underlying evidence or leave the exception explicit. For example, if a three-item classification returns two labels and an abstention, reconcile all three IDs before reviewing the labels against their source. The abstention accounts for the third item, but it is not a label or proof of semantic quality. Your agent can supply missing permitted evidence for a separately reviewed request, or keep that item unresolved. ## Use the result before changing the system Read [Result exceptions](/docs/compute/results/exceptions) before acting on accepted output. For architecture-level verification and acceptance rules, use the Execution and Security Papers. For a bounded application of the policy, continue with [First test](/docs/compute/first-test) after you have fixed the verification scope and evidence rule.