Different checks answer different questions
Structural checks establish whether output can be processed: required fields exist, values have the expected types and identifiers use supported formats. Business checks test relationships and constraints: a supplier exists in the authorized workspace, line totals reconcile under an explicit rounding rule, or a selected product belongs to the allowed catalog.
Action confirmation is a separate stage. Even a fully checked candidate may fail to persist because a permission changed or a request timed out. Recording pre-action verification and post-action observations independently lets a caller distinguish a rejected candidate from a valid candidate with an unresolved write.
| Layer | Example | Does not establish |
|---|---|---|
| Structure | Invoice total is a valid decimal | The total agrees with the document |
| Business rule | Line amounts reconcile with the total | The invoice is authorized for payment |
| Destination observation | Draft record contains expected values | All future downstream work has completed |
Make the verifier itself reviewable
Each verifier should have a defined input, version, result vocabulary and evidence requirements. A failed comparison should name the field and expected relationship without exposing unnecessary document contents. A check that cannot obtain its reference data should report that limitation rather than turning an unavailable lookup into a pass.
Prefer deterministic checks for exact constraints. Where a judgment requires human interpretation, define a review outcome and supply the relevant evidence. A model’s confidence estimate can be a routing signal, but it should not replace arithmetic, authorization or a read-back from the system of record.
State the limits of a successful verification
A passed verifier proves only its stated condition over the observations it received. It does not prove that the source document is genuine, that every business policy was modeled or that an external record will remain unchanged. Those distinctions belong in the result shown to operators, especially for tasks involving financial or operational decisions.
Before enabling a consequential write, agree the rules, test representative failure cases and name an owner for changes to the verification policy. Review exceptions with the people responsible for resolving them. A rule that passes technically but contradicts the organization’s operating policy needs correction before the workflow expands.
Missing a detail or found a problem?
Send a documentation question →