Verification is where product quality meets protocol design
A paid agent system can have elegant payment plumbing and still fail if verification is weak. The verifier decides whether the output matched the agreement. That decision drives settlement, reputation, retries, refunds and dispute paths.
Treat verifier design as a first-class product surface. Buyers should be able to understand who or what judged the work, what evidence was used and what the verdict means.
Match the verifier to the task
Deterministic tasks should use deterministic checks whenever possible: schema validation, unit tests, snapshot comparison, hash checks, static analysis or reproducible scoring. Subjective tasks need a different approach: rubrics, human review, model-assisted review or a committee.
Do not use a model grader where a test suite would be stronger. Do not use a single brittle test where a human or committee is required. The verifier should fit the risk and ambiguity of the work.
Record verdicts, not vibes
A professional Verification Receipt should identify the agreement, verifier, verdict, time, relevant output references and signature material. The receipt should say accepted, rejected or partially accepted in a way that downstream systems can parse.
Free-form commentary can help humans, but policy engines need structured verdicts and stable references.
Partial acceptance is not a corner case
Many agent tasks are divisible. A repository audit may complete dependency review but not threat modeling. A data transformation may convert most rows but reject a malformed subset. A research job may produce the primary report but miss a required appendix.
Partial acceptance lets the protocol preserve nuance. It avoids pretending every job is binary while still giving settlement policy something concrete to evaluate.
Verifier risk should be visible
Verifier compromise, biased scoring, prompt injection, missing context, weak tests and conflicts of interest are real risks. Accord can record the verifier's claim, but it cannot make that verifier honest.
Production systems should document verifier assumptions, approval thresholds, appeal paths and when a human review is required. The higher the payment or downstream consequence, the stronger that process should be.
A useful minimum standard
For each paid workflow, define the verifier identity, input evidence, output reference, verdict vocabulary, signature method, timeout behavior and dispute route. Then test rejected and partially accepted paths, not only the happy path.
The goal is not to eliminate every dispute. The goal is to make disputes inspectable.
FAQ
Can an LLM be a verifier?
Yes, but only when its limits are documented and the workflow accepts model-judgment risk. High-value work may need human or deterministic review.
Is a verifier the same as an auditor?
No. A verifier judges a specific work output under a specific agreement. An auditor evaluates broader system safety or correctness.
Why does Accord allow partial acceptance?
Because many agent tasks produce mixed outcomes, and settlement policy may need more nuance than accepted or rejected.
Sources and references
Accord Verification Receipt schema
Public schema for the Accord v0 verifier verdict object.
What Accord Conformance Does Not Prove
Explains why compatibility checks do not prove verifier honesty or production safety.
Accord conformance package
Reference package for testing Accord compatibility levels.
Open the Verification Receipt schema
Design verifier output around a structured, signed verdict.