PEVG: Planner, Executor, Verifier, Generator. Four Contracts That Make a Failure Attributable to One Role

Abstract

No trademark is claimed on PEVG, on the name of any of the four roles, or on anything else in this document. The construct is offered for use, teaching, assessment, extension and criticism by anyone, with attribution, under CC BY 4.0. A mark on a design pattern suppresses the citation the pattern needs in order to spread, and the defensibility of the name rests on a dated publication record rather than on a symbol. An agent that plans a task, calls the tools, checks the result and writes the answer in one undifferentiated step cannot be reasoned about part by part. When it fails there is no seam to open. The failure is attributed to the agent, which is another way of saying it is not attributed at all, and the remedy applied is usually a change to the prompt, which is another way of saying nobody knows which part was wrong. PEVG separates that agent into four roles with four declared contracts. A planner decomposes the task into ordered steps with explicit dependencies and performs no tool actions. An executor performs tool actions under an enumerated capability contract and is the only role with authority outside the workflow; it must not decide whether its own result is correct. A verifier decides what may be believed, and can accept, reject with a class, or abstain. A generator produces the response from what survived, and asserts nothing the verifier did not pass, which forbids more than restating a rejected claim: it also forbids presenting an unverified claim with the same confidence as a verified one. The separation is not modularity for its own sake. It exists so that a failure lands somewhere specific, so that each role can be measured on its own, and so that side effects are confined to one role. Four contracts produce four classes of error rather than one, and four classes can be counted separately, which is the precondition for improving any of them. The specification's substantive contribution is the two-boundary distinction, which is what implementations most often get wrong. The verifier holds the epistemic boundary, on what may be believed. It does not thereby hold the operational boundary, on what may be disclosed or acted upon. A claim can be true, correctly verified, and still forbidden to leave the system, because disclosure is governed by classification, authorization and policy rather than by correctness, and verifying harder does not help when the constraint is not epistemic. Attaching the output boundary at the verifier looks like avoiding duplication and is a single clause performing two functions: a verifier tuned to reject fewer true claims will, by the same movement, refuse fewer disclosures. Nobody decides to relax the disclosure policy; it relaxes because it is attached to something else that is being tuned. An implementation must therefore place a policy-enforcement point at the workflow output in addition to the verifier, and record the two decisions separately. Further sections state what a verifier can and cannot establish, including why self-verification is structurally uninformative rather than merely weaker, and why abstention must be a distinct outcome carried downstream. A final section states the separation's application beyond agent workflows, to arrangements in which some roles are held by people, where the contracts and prohibitions are unchanged and three other things are not. This specification is the depth treatment of pattern AP-1 of A Pattern Language for Production LLM Platforms, which is the canonical statement and governs where the two disagree. No implementation unconnected to the author has been evaluated, the two-boundary requirement rests on an argument rather than on measurement, and the specification states what would falsify it. It is a specification, not a certification scheme.