PAA Progressive Autonomy Architecture earned / scoped / revocable
v0.1.0-draft · draft.active

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 prior-art basis of this model, see Grounding.

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

One canonical example carries the five-group shape. The YAML is illustrative and non-normative — conformance is meeting the eight commitments, not matching one field-name rendering. Threshold and window values are concrete illustrative figures; calibrate to your domain before use.

Task contract

refund_approval

A compact task declaration for a selective autonomy classifier.

Boundary
Typed input: refund_request. Typed 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: >= 0.97. Window: rolling_200_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: ">= 0.97"       # illustrative — calibrate to your domain
  window: rolling_200_cases   # illustrative — calibrate to your domain
demotion:
  rule:
    condition: chargebacks_or_complaints_exceed_bound
    window: 1                 # point demotion
  fallback: human_review

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.

Canonical flows and use cases