# Human-in-the-Loop Workflow

**Status:** Approved target-state baseline  
**Narrow mandatory gates earlier; generic activation:** I3.

## Target State

Human involvement is a configurable policy outcome, not hard-coded scattered prompts.

```text
proposed Decision/action/lifecycle transition
  -> PolicyEvaluation
       allowed autonomously -> continue
       resolver authority -> resolver Decision -> re-evaluate
       Approval required -> create Attention + Approval request
       denied -> blocked with reason
  -> user receives in-app/external notification
  -> user reviews concise context/recommendation/evidence/consequence
  -> approve / deny / choose / modify / defer where permitted
  -> revalidate target revision/policy
  -> continue or remain blocked
```

## Attention Item

User-facing attention state references exact Project/Plan/Task/Run/ChangeSet/Deployment/etc., reason/policy rule, recommendation, consequence, evidence, deadline/expiry if relevant and allowed actions.

The same item is visible in Overview/Project and relevant primitive page; notification channels are projections, not separate decision state.

## Autonomy Control

The 0–100 autonomy control maps to concrete editable policy presets. Examples of policy categories:

- architecture;
- implementation mismatch;
- test change/removal;
- security/privacy finding;
- merge;
- staging/production;
- deployment rollback;
- budget/cost;
- custom hook/predicate.

A user can tune categories independently. `100` means maximum configured oversight; `0` means delegate all legitimately delegable decisions/actions, not bypass owner intent or security authorization.

## Owner / Resolver / Policy Boundaries

OwnerRequired product/business choices remain owner decisions unless the owner has explicitly encoded a default/policy that genuinely resolves them. Resolver models may make technical Decisions only inside configured authority. PolicyRequired actions remain explicit when policy demands them.

## Staleness

Approval/choice binds to exact target revision and policy. If candidate/Plan/Deployment materially changes while waiting, item becomes stale and must be re-presented/re-evaluated rather than silently using old consent.

## Failure / Recovery

Notification failure does not lose attention item. Browser/session loss does not lose pending Approval. Duplicate approve calls are idempotent. Expired/revoked permissions fail closed.

## Increment Realization

I1 uses narrow merge/security gates. I2 uses OwnerRequired/PolicyRequired Planning decisions. I3 activates generic policy editor/attention/Approval routing. I5/I6/I8 deepen CI/deployment/incident policies.

## Acceptance

Users can configure where they want control, see one clear reason/action when intervention is needed, and leave unrelated work progressing where dependencies allow.