/nexus

Autonomy Quality Protocol — deliverable quality for autonomous runs

Purpose: The shared discipline for maximizing deliverable quality when Nexus executes without a human in the loop — the autonomous counterpart of reference/dialogue-protocol.md. Dialogue recipes elicit intent from the user; autonomous runs must derive intent from artifacts, track every decision made in the user's absence, prove the deliverable against the derived contract with evidence, and finish it — every criterion the contract claims is carried to done or accounted for as a typed residual. Quality here is not a final check — it is contracted before execution, guarded during it, and independently verified at the end.

Read when: any AUTORUN/AUTORUN_FULL chain at CLASSIFY (Q1–Q3), AGGREGATE (Q7–Q8), and VERIFY/DELIVER (Q9–Q19); §0 and Q20–Q22 apply throughout; §8 (Q23–Q26) before every spawn and every side-effecting step. Applies to all non-dialogue recipes (apex, enact, converge, kaizen, feature, bug, reproduction family, quality-max family, …) and to the autonomous phases of dialogue recipes (spec's spawned agents, delve's EXCAVATE). Cites — never re-derives — reference/evaluator-loop-protocol.md, reference/handoff-validation.md, reference/guardrails.md, reference/quality-iteration.md, reference/recipe-contract.md §2.

0. Stance — the disposition the rules encode

Q1–Q22 are mechanical; the disposition behind them is not, and it is the part that decays first on a long autonomous run. State it once, keep it for the whole run:

Do not compromise the goal to make the run easier. Do not abandon a task because the part that is left is the hard part. Do not forget, at step nine of a twelve-step chain, what finishing was supposed to mean.

Where a rule and this disposition point the same way, follow the rule; where the rules are silent — and on a real run they often are — the disposition decides. It cashes out as three concrete behaviors, specified as Q20–Q22 in §7: the bar is never quietly lowered to meet the output, an alternative is actually tried before BLOCKED is claimed, and the difficult core is built before the easy polish.

What it is not. Persistence is not stubbornness, and this section never overrides a stop rule:

• Repeating a failing approach is not perseverance — two identical failures ⇒ stop and diagnose, then try a different approach. Thrash is giving up while looking busy.
• Burning budget past marginal value is Q13's failure mode, not its virtue. Exiting at diminishing-returns with an honest residual gap is finishing.
• Grinding past an Ask First gate, a Q6 escalation, or an L3/L4 guardrail is not determination — it is an unreviewed gamble. The disposition raises effort, never permission.

1. Intent Contract (Q1–Q3) — quality is defined before execution

Contract Lint — run before EXECUTE, not after. Q1 says what the contract must contain; this is the mechanical check that it does. Seven conditions, all cheap:

1. The goal is non-empty and names an outcome, not an internal action ("expired sessions cannot be reused", not "fix the auth module").
2. Every acceptance criterion has an oracle — a command, a file check, a rubric, or a named human reviewer. A criterion with no oracle cannot be auto-verified; either decompose it until it can be, or route it to human review explicitly.
3. Non-goals are stated (Q2), and prohibited outcomes are stated or explicitly none.
4. Any high-risk or irreversible step names its rollback, or declares the irreversibility explicitly.
5. Required evidence matches what VERIFY will actually check — no criterion demanding evidence the chain never produces.
6. A budget and a termination condition exist, covering success, escalate, and abort — not success alone.
7. In-scope paths and the chain's authorized side effects do not contradict each other.

Lint does not certify that the contract is right — only that it is not missing a part. It is the cheapest gate in the protocol; skipping it moves the same failures to DELIVER.

2. Decision Ledger (Q4–Q6) — the autonomous Assumption Ledger

Every load-bearing decision made without the user — library/API/design picks, trade-off calls, and especially interpretation decisions (an ambiguity in the request resolved by choice) — is recorded:

| ID | Decision | Alternatives rejected | Why | Reversibility | Class |
|----|----------|----------------------|-----|---------------|-------|
| DEC-1 | retry via exponential backoff | fixed-interval | matches repo's retry conventions | low-cost | design |
| DEC-2 | "notifications" read as in-app only | +email | request silent; email needs infra | medium | interpretation |

3. Drift control (Q7–Q8) — quality guarded mid-run

4. Independent verification (Q9–Q11) — self-review is not review

5. Quality budget & completion honesty (Q12a, Q12–Q14)

6. Acceptance Provenance (Q15) — D16's autonomous analog

At DELIVER, classify every intent-contract criterion:

A criterion that vanishes between the intent contract and the final report is the autonomous equivalent of a silent assumption — the report must account for all of them, and dropped without a Ledger entry is scope creep in reverse.

Prohibited outcomes are classified on their own axis, in the same section. Success criteria and prohibited outcomes fail differently and cannot share a verdict: an AC is met by producing something, a prohibition is held by nothing having happened, which no amount of AC evidence demonstrates.

A prohibited outcome may never be dropped: descoping work is a DEC-n (Q4), but descoping a prohibition is the user's call, not the run's. none declared at Q1 is a valid whole section — an empty one is an incomplete report.

7. Completion Integrity (Q16–Q22) — "done" means nothing was quietly left behind

Q13's best-so-far exit and Q11's deferral branch are honest only when the deferral itself is disciplined. Without that discipline the Follow-ups section becomes the run's disposal chute: in-scope work reclassified as "future work", artifacts shipped with TODO markers and stub bodies, and a SUCCESS status over a skeleton. quell already solves this for one recipe with its disposition ledger (reference/quell-recipe.md §3–§4, "nothing is silently dropped"); Q16–Q19 generalize that mechanism to every autonomous run and every recipe.

Q17 deferral classes (the complete set):

Not classes — these are the phrasings that hide unfinished work, and each one means "go finish it": for brevity · left as an exercise · can be added later · beyond the scope of this response · the pattern is the same for the rest · wire this up when convenient · similar changes needed in the other N files.

Persistence rules (Q20–Q22) — §0's disposition, made checkable

Q16–Q19 catch work that was left visibly undone. Q20–Q22 catch the quieter version: the run that reaches SUCCESS by making success cheaper.

8. Authority & effect discipline (Q23–Q26) — what a step may do is granted, not derived

Q1–Q22 govern what the run produces. Q23–Q26 govern what it is allowed to cause. The distinction matters because a chain widens its effect surface far more quietly than it widens its scope: the platform hands every spawned agent the hub's own tool permissions, so a step that only needed to read three files runs with the authority to write, delete, publish, and spawn.

What the approver is shown. An approval request that states only the action buys a click, not a decision. Show, in this order: the diff or concrete effect; the target and what else it touches; the evidence it rests on and what is still unresolved; the cost, deadline, and reversibility; the alternatives, including doing nothing; and the scope and expiry of the approval being given. The two most often omitted — the unresolved part and the do-nothing option — are the two that make an approval a judgment rather than a formality.

Approval fatigue is a failure mode, not a user problem. A gate that fires on every low-risk action trains the approver to clear it unread, which removes the control while leaving its appearance. When a gate fires often and is approved nearly always, that is evidence the gate is mis-placed: batch the routine cases under a stated policy and escalate only the deviations. Volume of approvals is not a safety metric; approvals that changed an outcome is.

Certainty is the second axis of the gate. Ask First triggers on the kind of action. Confidence in the classification is independent of it, and the two combine:

The bottom-right cell is a prohibition, not a stricter gate: an unresolved classification plus an irreversible effect is not something an approval makes safe, because the approver is being asked to ratify a guess.

Separation of duties, where it binds. For an irreversible effect, an effect outside the run's stated scope, or a change to a control itself, the approver is someone other than the producer — and an owner does not unilaterally approve an exception to a control they own. Self-approval of one's own exception is the shortest path around every rule above it. Where no second party is available, the run stops at T2 prepare and says so; that is a PARTIAL with a named blocker, not a failure.

Grant dimensions. "Narrowest grant" (Q23a) is unenforceable until the grant has axes; a per-tool allow/deny list is too coarse, because the same tool at different arguments carries different effect. State a grant on the seven axes below, naming only the ones the step's criteria actually need — an unnamed axis is denied, not unlimited.

Four consequences worth stating explicitly:

• Budget is a safety control, not a cost control. Caps bound loops, tool abuse, injected-instruction blast radius, and cascading failure — the same caps that bound the bill. Tier them, because a cap at one level does not bound the level above it: per step · per job/run · per tool · per session · per user or tenant · per day/month · one emergency global cap. The last is the only backstop that crosses sessions, and it is the one most often missing. On exhaustion, return partial output, the unfinished steps, and the resume condition (Q17 typed residual) rather than failing bare.
• Shrink the tool, not just the grant. A narrow capability (get_open_invoices(customer_id, limit)) enforces authorization, range, audit, and idempotency at the tool boundary; a general one (execute_sql, http_request, bare shell) pushes all of that into a prompt, where it is a request rather than a control. Prefer granting a narrow tool over constraining a broad one.
• A secret is a credential the task needs, not knowledge the model should see. The failing path is secret value → prompt → model → tool argument → log, and every hop after the first is permanent: traces, summaries, and downstream calls all retain it. The tool resolves the credential internally and the model holds only an opaque reference — charge_card(payment_method_id), never charge_card(card_number, cvv). A redaction placeholder must not be reversible to the original.
• Read-only is not automatically safe. Read grants still aggregate, infer, and exfiltrate across sources — individually-permitted facts compose into sensitive relationships. A read grant carries destination, quantity, purpose, field, row, tenant, and retention like any other, and secrets pulled into context live in the trace, the summary, and any downstream spawn.

Delegation record. On chains that fan out ≥ 3 spawns or nest a feature-lead layer (Core Rule #9), the grant per spawn is journaled with the step: from · to · allowed · denied · redelegation · expires_with. It costs one line and is the only way an aggregated SUCCESS can be audited back to who was allowed to do what. Where the platform distinguishes them, record the acting identities separately — actor_user · actor_agent · purpose · session · policy in the token claims or policy context — so an audit can tell who an effect was caused for from what caused it. Agent identity is not user identity: running an agent on the end user's credential inherits the user's full permission set, which is always wider than the task and is the widest grant in the system. Use a dedicated identity with delegated short-lived tokens, audience restriction, and resource scoping.

Budget is divided, not lent. A parent that spawns three children and passes each the same ceiling has authorized three times its own limit, and a feature-lead layer multiplies it again per level. Allocate a share to each child, keep a reserve at the parent, and record the split alongside the grant. State the ceiling on every dimension that can run away, not just tokens: wall_time · model_calls · tool_calls · side_effects · monetary · human_interrupts — a run bounded on tokens alone can still burn an hour, fire forty tool calls, or interrupt the user six times.

Three properties travel with a delegation.

1. Capability does not inherit. A child receives what it was explicitly granted, never what the parent holds. redelegation: false is the default, and a child cannot grant onward what it was not given.
2. Cancellation propagates downward. Cancelling or aborting a parent cancels its children; a child that keeps running after its parent stopped is producing effects nobody is waiting for and nobody will check.
3. Ownership transfers explicitly. After a handoff, exactly one party owns the final answer, the cancellation, and the approval. Record the transfer — an unowned in-flight task is the state where every party assumes another is watching it.

Failure Modes Prevented

Wiring

• All autonomous chains (Recipe or ad-hoc CLASSIFY output): §0 for the whole run, Q1–Q3 at CLASSIFY/PLAN, Q4–Q6 + Q21–Q24 during EXECUTE, Q7–Q8 + Q20 at AGGREGATE, Q9–Q19 at VERIFY/DELIVER. Enforced at the Workflow level — individual recipe references cite this protocol instead of re-deriving it, adding only recipe-specific specializations (e.g. reproduction recipes' parity oracles already satisfy Q3/Q10 via _common/DIFFERENTIAL_PARITY.md; acceptance's G1–G10 subsume Q11).
• NEXUS_COMPLETE / NEXUS_COMPLETE_FULL (reference/output-formats.md): the Decision Ledger (interpretation entries first), the per-criterion Acceptance Provenance table, and the Residual Ledger (Q18, with the Q19 sweep line) are part of the final report — omit each section only when genuinely empty, and an empty Residual Ledger still reports the sweep as scanned, 0 hits.
• Spawn prompts inherit Q16–Q17 as the Completion bound field of the Agent Spawn Template (reference/hub-authoring.md): a spawned agent finishes its slice or returns PARTIAL with a typed residual — it never returns a stub as SUCCESS. Q23 rides the same template as the Authority field (narrowest grant, redelegation: false by default) and Q1's prohibited outcomes as Prohibited outcomes. The hub owns Q18–Q19; a step never self-certifies its own completion sweep (Q9).
• Dialogue recipes (spec, delve): the dialogue itself follows reference/dialogue-protocol.md; their spawned autonomous work (EXPAND fan-outs, EXCAVATE lenses, Quality-Gate reviews) follows this protocol. The two ledgers are siblings: ASSUME-n tracks what the user didn't decide; DEC-n tracks what the run decided alone.

This protocol governs the hub's conduct of the run — spawn prompts inherit only the pieces a step needs (its slice of the contract, Q10 evidence duty in the output envelope), never the whole protocol.