Builder section

Build

Start with one task. Define what success looks like, run the system that performs it, and measure the results. Those measurements become the evidence used to decide how much human oversight the task should receive.

PAA makes each part of that loop explicit so changes in autonomy can be explained, reproduced, and reversed.

PAA records the task boundary in a task declaration. It calls the system doing the work the worker. It calls the mechanisms judging that work evaluators.

This is the canonical builder entry point. Journey, Framework, Evaluators, Grading, and Improvement are stages in this sequence, not competing ways into the site.

The implementation model

What work are we governing?
Define one task and its boundary.
What performs the work?
Run the worker without changing the boundary.
How do we know whether it is good?
Use evaluators to judge the properties that matter.
What do we keep?
Record evaluation results as evidence.
How does oversight change?
Use the governance lifecycle after enough evidence has accumulated.
  1. Start here One task walked end to end. Start here if you are new to PAA and want the whole shape before any field name.
  2. Architecture The four linked artifacts and three independent dimensions. Start here if you need the parts of a declaration and how they connect.
  3. Task lifecycle Bound, instrument, evaluate, gate, accumulate, promote, demote. Start here if your task is bounded and you need the general move-set.
  4. Evaluators The evaluator identity, proxy versus ground truth, authority, placement, succession. Start here if you are deciding how the work gets judged, and under what authority.
  5. Evidence and labels The common verdict stream, and what makes it training-ready. Start here if verdicts are accumulating and you need them to be admissible.
  6. Improvement Better worker, same boundary, same bar, no inherited autonomy. Start here if the boundary holds and the thing behind it needs to get better.
  7. Patterns Domain recipes showing how the primitives compose. Start here if you want a worked recipe in your domain rather than the primitives alone.

Advanced path

If your task already emits evaluator verdicts, begin with Grading, continue to Improvement, inspect the research grounding, and finish at the normative schema.

Not a step

The task schema (paa-task/0.2.1-draft) is the executable declaration contract, linked from every step above that names a field. It is reference material rather than a stage of the work, so it lives under Reference and not in this sequence. The same is true of the reference implementations: read them beside a step, not instead of one.