Choose the right kind of check
| Check type | Appropriate use | Limit |
|---|---|---|
| Schema validation | Required fields, types, permitted values | A valid shape can still contain incorrect facts. |
| Deterministic computation | Totals, tax arithmetic, unit conversion | The rounding and tolerance policy must be defined. |
| Authoritative lookup | Supplier identity, PO and receipt matching | Missing or stale source data limits the conclusion. |
| Rubric-based assessment | A bounded qualitative judgment | It should remain distinguishable from a factual system check. |
| Effect confirmation | Read-back of a saved business record | It establishes the stated record condition, not every downstream consequence. |
Return more than a boolean
Distinguish pass, fail, and unavailable. A failed arithmetic check establishes a mismatch. An unavailable receipt lookup establishes that the check could not be completed. Those cases need different recovery paths.
Each check should include its version, evaluated rule, relevant source references, observation time, and a concise reason. Sensitive source content should not be copied into a receipt merely to make it look comprehensive.
{
"sample": true,
"check": "invoice.totals_reconcile",
"verifier_version": "sample-v1",
"status": "passed",
"policy_ref": "sample_rounding_policy",
"evidence_refs": ["sample_invoice_lines"]
}Arithmetic still needs a business policy
Define how quantities, unit prices, discounts, tax, and currency precision interact. Line-level rounding and invoice-level rounding can produce different totals. A verifier must apply the selected policy consistently and record it, rather than introducing an undocumented tolerance.
A stronger model may correct an extraction mistake after a failed check. It must not change the verifier, tolerance, or source value to manufacture a pass. Retry history should preserve the original mismatch and explain the revised candidate.
Verify against the state that matters
A supplier or purchase order can change between lookup and write. The integration design should define acceptable freshness and, where supported, compare source versions or recheck critical preconditions before committing. The receipt needs to identify the state used for the decision.
Verification is deliberately bounded. A matching invoice and receipt do not prove that the physical goods were satisfactory, that the supplier is legitimate in every context, or that the bill was paid. The contract should state the exact business claim it can establish.
Missing a detail or found a problem?
Send a documentation question →