PAA Progressive Autonomy Architecture earned / scoped / revocable

Canonical framework

Framework

A PAA task declaration is five orientation groups: boundary, evidence log, evaluator, promotion rule, and demotion. Each group owns the commitments that belong to it — oracle and position policy inside evaluator, fallback inside demotion.

This page holds the model and an illustrative rendering in one scroll, so the concept and the serialized example cannot drift apart. For the founding argument behind this model, see Manifesto.

The task model

A PAA task is a bounded unit of work governed by five orientation groups and eight commitments. The five groups provide the stable top-level reading order; the nested commitments encode ownership relationships that a flat list would obscure.

The boundary (typed input, typed output) defines the observable unit — nothing is a PAA task until it has one. The evidence log is the append-only record of inputs, proposals, verdicts, gate decisions, outcomes, and review results. The evaluator is the verdict-producing mechanism defined by four choices: the target (what gets evaluated), the technique (what produces the verdict), the oracle (what the verdict is checked against), and the position policy (how the gate behaves at each spectrum region). Oracle and position policy belong to the evaluator because they are properties of the verdict producer, not independent contract primitives.

The promotion rule reads the evidence log and raises autonomy when an aggregate signal holds above a threshold across an evidence window. The demotion group owns two commitments: the rule (what breach fires demotion) and the fallback implementation (what the task lands on). Fallback is the target of demotion — it belongs inside demotion, not at the top level.

A task's current spectrum region is runtime state, not a contract commitment. The contract declares policies and rules; a task's position on the spectrum at any moment is the outcome of those rules applied to the evidence log.

A PAA task pairs a boundary and evidence log with an evaluator that owns the oracle and position policy, a promotion rule, and a demotion group that owns the fallback implementation.

Five orientation groups

The top-level reading order. Each group owns the commitments that belong to it.

Boundary

Typed input in, typed output out. A task is not eligible for the spectrum until its boundary is observable.

Evidence log

The recorded trail of input, proposal, verdict, and outcome that funds every promotion and demotion decision.

Evaluator

Target, technique, oracle, and position policy: what gets evaluated, what produces the verdict, what the verdict is checked against, and how the gate behaves at each spectrum region. Oracle and position policy are properties of the evaluator, not peers.

Promotion rule

The evidence threshold that moves a task toward more autonomy. Promotion without evidence is a guess, not a promotion.

Demotion

The trigger rule and the fallback implementation: what breach causes demotion, and what the task lands on. Fallback is the target of demotion, not a separate top-level contract field.

Nested commitments

Three commitments are nested inside their parent group. Ownership is the rule: each lives where it belongs, not where it is easiest to display.

Evaluator →

Oracle

What the verdict is checked against — an invariant, a reference, a rubric, human gold, or a downstream result. Owned by the evaluator because the oracle is how you know whether your evaluator is right.

Evaluator →

Position policy

How the gate behaves at each spectrum region: blocking (approve before execution), async (review after), or offline (periodic checks). Declared as a policy by region, not as a single current runtime position.

Demotion →

Fallback implementation

The safe lower-autonomy path the task runs when the gate blocks or demotion fires. Owned by demotion because it is the destination of a demotion, not an independent primitive.

Task declaration rendering

The YAML illustrates the model

Two examples from different domains carry the same five-group shape. The YAML is illustrative and non-normative — conformance is meeting the eight commitments, not matching one field-name rendering.

Task contract

refund_approval

A compact task declaration for a selective autonomy classifier.

Boundary
Input: refund_request. Output: decision.
Evidence log
request, proposal, verdict, decision, chargeback_signal, complaint_signal, review
Evaluator
Target
output
Technique
escalation_classifier
Oracle
human_gold
Position policy
hitl
blocking — approve each decision before it executes
hotl
async — review batch after execution
autonomous
offline — periodic spot checks
Promotion rule
Metric: recall_on_should_escalate. Threshold: >= target. Window: rolling_N_cases.
Demotion
Rule
Condition: chargebacks_or_complaints_exceed_bound. Window: 1.
Fallback
human_review
refund_approval YAML example
task: refund_approval
boundary:
  input: refund_request
  output: decision            # approve | escalate
evidence_log:
  - request
  - proposal
  - verdict
  - decision
  - chargeback_signal
  - complaint_signal
  - review
evaluator:
  target: output
  technique: escalation_classifier
  oracle: human_gold          # labeled escalation decisions
  position_policy:
    hitl: blocking            # approve each decision before it executes
    hotl: async               # review batch after execution
    autonomous: offline       # periodic spot checks
promotion_rule:
  metric: recall_on_should_escalate
  threshold: ">= target"
  window: rolling_N_cases
demotion:
  rule:
    condition: chargebacks_or_complaints_exceed_bound
    window: 1                 # point demotion
  fallback: human_review

Task contract

pr_review

Full contract example for the review flow.

Boundary
Input: pull_request_diff. Output: review_verdict.
Evidence log
diff, context, findings, comments, verdict, follow_up_state, outcome
Evaluator
Target
output
Technique
stacked_deterministic_checks + reviewer_model
Oracle
merged_pr_outcomes + regression_findings + reviewer_confirmations
Position policy
hitl
blocking — before the merge queue advances
hotl
async — review can trail the merge
autonomous
offline — sample reviews
Promotion rule
Metric: repeatable_correctness_low_false_negative. Threshold: >= target. Window: rolling_N_reviews.
Demotion
Rule
Condition: missed_issue OR policy_drift OR regression. Window: 1.
Fallback
human_review_with_request_changes
pr_review YAML example
task: pr_review
boundary:
  input: pull_request_diff
  output: review_verdict      # approve | request_changes | follow_up
evidence_log:
  - diff
  - context
  - findings
  - comments
  - verdict
  - follow_up_state
  - outcome
evaluator:
  target: output
  technique: stacked_deterministic_checks + reviewer_model
  oracle: merged_pr_outcomes + regression_findings + reviewer_confirmations
  position_policy:
    hitl: blocking            # before the merge queue advances
    hotl: async               # review can trail the merge
    autonomous: offline       # sample reviews
promotion_rule:
  metric: repeatable_correctness_low_false_negative
  threshold: ">= target"
  window: rolling_N_reviews
demotion:
  rule:
    condition: missed_issue OR policy_drift OR regression
    window: 1
  fallback: human_review_with_request_changes

Agent-facing summary

A condensed reference for agents and other automated readers indexing this site. Machine-readable versions of the same map live at /llms.txt and /llms-full.txt.

What PAA is. A vendor-neutral architecture for moving an agentic task from full human review toward monitored autonomy. It turns a task into a task contract: a typed boundary, an evaluator that decides what is allowed, and explicit rules for earning or losing autonomy. Autonomy is earned, scoped, and revocable.

What PAA is not. Not a one-shot autonomous demo, and not a system that treats a model's self-reported confidence as a gate. Not a maximum-autonomy mandate — many tasks should stay partially governed permanently. The goal is appropriate autonomy: the level that fits the evidence, the risk, and the domain.

The full contract, at a glance

Five orientation groups, eight commitments. Each commitment lives in the group that owns it.

Boundary

Typed input in, typed output out. A task is not eligible for the spectrum until its boundary is observable.

Evidence log

The recorded trail of input, proposal, verdict, and outcome that funds every promotion and demotion decision.

Evaluator

Target, technique, oracle, and position policy: what gets evaluated, what produces the verdict, what the verdict is checked against, and how the gate behaves at each spectrum region. Oracle and position policy are properties of the evaluator, not peers.

Promotion rule

The evidence threshold that moves a task toward more autonomy. Promotion without evidence is a guess, not a promotion.

Demotion

The trigger rule and the fallback implementation: what breach causes demotion, and what the task lands on. Fallback is the target of demotion, not a separate top-level contract field.

Evaluator →

Oracle

What the verdict is checked against — an invariant, a reference, a rubric, human gold, or a downstream result. Owned by the evaluator because the oracle is how you know whether your evaluator is right.

Evaluator →

Position policy

How the gate behaves at each spectrum region: blocking (approve before execution), async (review after), or offline (periodic checks). Declared as a policy by region, not as a single current runtime position.

Demotion →

Fallback implementation

The safe lower-autonomy path the task runs when the gate blocks or demotion fires. Owned by demotion because it is the destination of a demotion, not an independent primitive.

Canonical flows and use cases