Build PAA / Task Lifecycle
Govern a task over time
Bound the task, observe the work, establish fitness, govern the result, and keep evaluating. The same loop applies after every promotion, demotion, or replacement.
01
Bound
Define one task with observable input, output, scope, and termination. If the boundary is too broad to evaluate, split the work before assigning authority to it.
See the task-boundary governance model.
Declare acceptable outcomes, disqualifying failures, the evaluator set, and current oversight. Identify which costs matter and how economics will inform the decision. These operating requirements accompany the task declaration; they are not new schema fields.
- A maximum cost per accepted result or budget per set of tasks.
- A task-specific evaluator-to-worker cost ratio.
- Relative improvement against the current configuration.
- Measurement only, with no hard economic gate.
Choose the policy before collecting comparison evidence. PAA requires no universal dollar threshold.
02
Observe and evaluate
Record the existing workflow, then judge defined properties of each execution. Keep the subject, boundary references, evaluator identity, verdict, and timing together so the result remains attributable.
The implementation also records worker, evaluator, review, and escalation costs where
available, plus latency or throughput when economically relevant. Economic measurements
accompany judgments; they do not replace evaluators. In the current contract, the
consumer's payload_schema can type this detail in payload.
Runtime eligibility logic does not read it.
03
Establish fitness
A single passing verdict is an anecdote. Promotion uses a declared window of evidence, frozen with the cases included and excluded. Record why each excluded case did not qualify.
Establish behavioral qualification before comparing economic fitness. Two configurations may both qualify, with one costing less per accepted outcome. A proposed oversight level may be behaviorally viable yet economically unattractive. Lower cost cannot make a behaviorally unqualified configuration eligible for autonomy.
Compare costs and accepted outcomes from the same configuration, population, and window. Preserve failed-attempt costs and identify unavailable measurements. Establishing fitness can qualify a replacement at the current authority without requiring promotion.
04
Govern
- No change
- The current configuration and authority remain justified.
- Configuration change
- A replacement satisfies the same task bar more efficiently. The operator records the choice; authority stays unchanged.
- Autonomy change
- Evidence establishes eligibility for a different oversight position, and a separate governance decision changes authority.
Passing the rule makes a change eligible. A motion proposes the exact scoped move, the declared actor or automatic rule resolves it, and the event stream records the result.
Apply one position change at a time unless the decision explicitly justifies a larger move.
Operators or consumer policies may consider economic evidence in that decision. The current runtime governs authority transitions; it does not run evaluators, calculate costs, choose models, or apply economic eligibility thresholds.
05
Continue governing
Evaluation continues after oversight changes. Later failures can trigger demotion, and an operator can restore review immediately after a confirmed high-stakes failure.
Keep measuring operating costs as review, retries, and workload change. A cost increase can prompt a configuration review; it does not automatically trigger runtime demotion.
Autonomy tracks authority, evaluator maturity tracks judgment, and worker capability tracks the system doing the work. Change one, collect evidence for the new state, then make the next governance claim. Read the three-lane rationale.