Academy

When no single model is enough: the primary and verifier pattern

Sometimes a task has two critical demands that no single model satisfies at once. The answer isn't to accept a weak model; it's to combine two.

The Felesh team 4 min

Sometimes you hit a task with two critical demands — for example, producing an output while guaranteeing zero errors — and no single model satisfies both constraints. The easy temptation is to pick the best available model and accept a compromise on quality. A better approach is to combine two models in a pipeline.

The basic idea

The pattern is simple. A primary model produces the initial output, and a verifier model evaluates it to catch errors the primary missed. Each model handles the task it is best suited for. This division of labour creates a composite system that meets strict requirements, even when no individual model can.

A draft checked against its clauseA supplier contract, section 4.2, sets the late fee at 1.5 percent a month after a 30-day grace period. The primary drafts two fields from it: late fee 1.5 percent a month, and grace 30 days. The verifier checks each field against section 4.2 and ticks both. Only then is the approved output written.terms from a supplier contract§4.2 “Late fee 1.5% a month after 30 days.”primarydrafts each fieldlate fee 1.5% a monthgrace 30 daysverifierchecks each against §4.2late fee matchesgrace matchesapproved: late fee 1.5% a month, grace 30 days
The primary drafts each term, and the verifier checks every field against the clause before anything is approved.

The key rule: the verifier must genuinely be capable

Ignoring the decisive rule of this pattern breaks the implementation: the verifier must be genuinely capable on the exact axis it checks. If the verifier is weak at detecting errors, it provides nothing more than a worthless stamp of approval.

A second, less obvious rule applies: the primary must not be so weak that the verifier cannot distinguish subtle errors from total failure. A strong verifier cannot salvage a thoroughly broken output; it can only catch edge-case errors in an otherwise sound one. The primary should sit only one band below the demand, not two. Combining a capable primary with a strict verifier yields a critical-level result; combining a weak primary with that same verifier fails.

Three pairings checked against one clauseThe same clause, a late fee of 1.5 percent a month. Row one: a capable primary drafts 1.9 percent, and a strict verifier sees the mismatch with 1.5 percent, so the error is caught and sent back. Row two: a weak primary leaves the late fee with no value, every field fails, and nothing usable is left. Row three: the same 1.9 percent draft passes a weak verifier, which approves it without really checking: a stamp, not a check.primary draftverifierresultcapable primarylate fee 1.9%/mostrict1.9% ≠ 1.5%caught, sent backweak primarylate fee: nonestrictboth differfails: unusablecapable primarylate fee 1.9%/moweakpasses 1.9%approved: a stamp
Pair a capable primary with a strict verifier and the subtle error is caught; a weak primary or a weak verifier fails the clause.

Three shapes of pipeline

This pattern has three common implementations, each with different economics:

  • Sequential: The primary produces, then the verifier approves or rejects. All traffic passes through both, meaning cost and latency equal the sum of the two models. This is the simplest and most reliable architecture.
  • Tiered fallback: The verifier runs only on a flagged subset of outputs, such as low-confidence or suspicious cases. Cost is significantly lower because the verifier processes only a fraction of the traffic.
  • Parallel arbitration: Both models run independently, and a deterministic rule arbitrates between their outputs. This incurs the highest cost and maximum latency, but is necessary when strictly independent evaluations are required.
Three pipeline shapes carrying one clauseOne clause, section 4.2, travels through three pipeline shapes. Sequential: the primary drafts it, then the verifier checks it, then it is approved. Tiered fallback: the primary drafts it and a flag marks it as suspicious; only flagged clauses reach the verifier, and unflagged clauses skip it. Parallel arbitration: the primary and the verifier both read the clause, and a rule picks the output.sequentialclause §4.2primaryverifierapprovedtiered fallbackclause §4.2primaryflagged?verifierapprovedunflagged: skipparallel arbitrationclause §4.2primaryverifierruleapproved
Sequential sends every clause through both models, tiered sends only the flagged ones to the verifier, and parallel runs both and lets a rule decide.

Choosing between these three is an engineering trade-off governed by task sensitivity, latency budgets, and cost constraints.

When not to reach for this pattern

This pattern is not free. Two models introduce greater latency, higher costs, and more operational complexity. It is justified only when no single model can meet the requirements. If one model can handle the task, use it — it will be simpler, cheaper, and have fewer failure points. Reserve this pipeline for scenarios where the pool of single-model candidates is genuinely empty.

An honest caveat

Combining a primary and a verifier does not provide an absolute guarantee; it only sharply reduces the probability of error. You must still measure in practice whether the paired system reaches your target quality threshold. The pattern is a useful architectural tool, but it does not replace rigorous evaluation.