Target
What layer the evaluator inspects: input, process, output, or outcome.
Start at the cheapest layer that catches the failure. Move deeper only when needed.
Evaluator primitive
Evaluators are the primitive of progressive autonomy
An evaluator is the verdict-producing mechanism specified by four choices: target, technique, oracle, and position policy. This page is the canonical reference for evaluator internals.
Use this page to understand what a complete evaluator declaration looks like, how each of the four choices works, and how evaluators progress through the maturity curve. For reusable patterns built on these evaluators, see Flows. For the illustrative declaration rendering, see Framework.
An unvalidated evaluator is not a gate. It is a guess with a UI.
PAA separates capability from authority. A model may be capable of producing an action, but the system still needs an evaluator to decide whether that action is allowed.
The evaluator is four choices
Each evaluator declaration commits to all four choices. Target and technique define the mechanism. Oracle defines what the verdict is measured against. Position policy declares where the evaluator runs per spectrum region.
Technique
What produces the verdict: rule, metric, classifier, judge, or human.
Paired with target, technique completes the evaluator mechanism.
Oracle
What the verdict is measured against: invariant, label, rubric, or downstream result.
The oracle is a property of this evaluator, not a universal truth source. It can change as the evaluator matures.
Position policy
A map from spectrum region to where the evaluator runs: blocking, monitoring, or offline.
The policy is fixed in the declaration. Which region the task is currently in changes at runtime.
Target
Evaluate at the cheapest layer that actually catches the failure.
| Layer | Question | Cost | Note |
|---|---|---|---|
| Input | Was the right context present and well-formed before acting? | Cheapest | Catches structural failures before work starts. |
| Process | Were the present inputs used correctly during generation? | Hard / often sealed | Usually inferred from output and outcome. |
| Output | Is the produced artifact good against some standard? | Needs an oracle | The default eval layer. |
| Outcome | Did it work downstream? | Truest, most lagged | Noisy and delayed, but the real numerator. |
Technique catalog
Ordered by cost, cheapest first.
| Technique | Examples | Cost / latency | Best use |
|---|---|---|---|
| Deterministic / rule-based | Schema, types, bounds, regex, allow/deny lists, assertions | Zero | Structural correctness and hard invariants |
| Reference-based metrics | Exact match, F1, numeric tolerance, tests against a reference | Cheap | Knowable-correct tasks with gold labels |
| Learned classifier | Logreg, SVM, small net on embeddings, SetFit, ModernBERT | Cheap inference | The mature high-volume evaluator |
| LLM-as-judge | A model scores output against a rubric, with or without a reference | Expensive / latent | Bootstrap labels before distilling to cheaper evaluators |
| Human evaluation | Expert raters or reviewers | Highest | Ground truth for ambiguous or high-stakes cases |
Oracle
The oracle is what the evaluator's verdict is measured against. It is a property of this evaluator — not a universal truth source — and the relationship only has meaning for a specific verdict producer. Without an oracle, a verdict is just a number with confidence styling.
Oracle quality changes as the evaluator matures. A cold-start evaluator may use human gold labels as its oracle. A mature evaluator may graduate to automated downstream outcome signals once enough evidence has accumulated. The oracle is the part of the evaluator that earns trust over time.
Common oracle forms: invariants and assertions (deterministic), reference labels (human gold or benchmark), rubrics (LLM judge), downstream results (outcome signals).
Position policy
Position is a policy declared in the evaluator contract, not a single static value. The policy maps each spectrum region to where the evaluator runs. The task's current region changes at runtime; the policy is fixed.
| Spectrum region | Evaluator runs as | Timing | Effect |
|---|---|---|---|
| hitl | Blocking gate | Before execution | Halts the write until the verdict clears. |
| hotl | Async monitor | After execution | Watches outputs and triggers demotion or alert. |
| autonomous | Offline evidence | Batch / aggregate | Measures whether the task has earned more autonomy. |
Evaluator economics
The evaluator must cost less than the action it guards.
| Principle | Rule | Implication |
|---|---|---|
| Evaluator economics | The evaluator must cost less than the action it guards. | If the evaluator is more expensive than the task, the economics fail. |
| Cost curve | Expensive at cold start, cheap at volume. | A reviewer-heavy phase can fund itself because the volume is still low. |
| Distillation | Move from judge to classifier once labels exist. | The accumulated review stream pays for the cheaper evaluator you will need later. |
| Boundary discipline | Instrument from the start. | The data must already be there when the evaluator needs to get cheaper. |
Maturity curve
As the evaluator matures, oracle quality improves, technique reliability rises, and position policy suitability widens. The task climbs the autonomy curve because the evaluator has earned that trust.
| Stage | Evaluator setup | Autonomy level | Meaning |
|---|---|---|---|
| Cold start | Human plus LLM judge; oracle is human gold labels; position policy is blocking | Low autonomy | Expensive but affordable because volume is low. |
| Growing evidence | Distilled classifier begins to replace the judge; oracle shifts toward automated labels; position policy can loosen | Rising autonomy | Review labels turn into training data. |
| Mature volume | Cheap classifier on the hot path; oracle validated against downstream outcomes; position policy allows monitoring | High autonomy | Technique is reliable, oracle is proven; position policy reflects earned trust. |
| Regression | Fallback to the more expensive evaluator or human; position policy tightens | Demotion | Agreement or calibration drift exceeded the bar. |
Metric choice
Optimize according to failure cost, not preference.
| Failure profile | Metric to favor | Why |
|---|---|---|
| Rare, high-cost failures | Recall | Misses are catastrophic, so escalate liberally. |
| Common, low-cost failures | Precision and throughput | False escalations become the expensive error. |
| Bootstrap labels | Human agreement | Use the judge to create the training set, not to pretend the evaluator is already proven. |
How an evaluator gets promoted and demoted
The evaluator itself runs the same loop as the task it governs. It starts eligible when instrumented and paired with a human gold oracle, gets promoted when a cheaper technique clears agreement above the bar, sees its position policy loosen as trust accumulates, and is demoted when oracle agreement or calibration drifts past the threshold.
That recursion is the whole architecture. The task and the evaluator are both moving, each on its own clock, each measured against the one above it.