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 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 after you have fixed the verification scope and evidence rule.