# Policy and Autonomy Domain

**Status:** Approved target-state baseline  
**Narrow gates:** I0/I1  
**Generic product activation:** I3.

## Target State

AWP can operate fully autonomously in potential but never by mandate. Concrete policy rules govern who/what may decide, approve, execute or escalate.

```text
System ceilings
  -> Project policy/autonomy preset
  -> Plan policy delta
  -> Task/Run narrowing
  -> PolicyEvaluation
       allowed
       denied
       requires Approval
       resolver decision allowed
       human attention required
```

The 0–100 autonomy UI is a preset/editor over rules, not a magic numeric permission engine.

## Core Primitives

### Policy

Versioned rule set over action/resource/context. Examples: architecture changes, test modification, security finding, merge, staging, production, custom hooks, budget/capability use.

### ResolverPolicy

Defines whether a higher-authority resolver model may make a genuinely technical/non-owner Decision when the normal agent cannot, and within what boundaries.

### PolicyEvaluation

Durable/explainable result for material progression: policy revision, context, rule(s), result and required next action.

## Invariants From Day 1

- policy cannot grant capability beyond System/security ceiling;
- `fully autonomous` never means bypass authentication/authorization/explicit owner-only business intent;
- owner-required decisions remain owner-required unless the owner explicitly configured a policy/delegation that legitimately defines the choice;
- PolicyRequired approvals cannot be bypassed by Simple mode or agent confidence;
- resolver model has decision authority only within configured rules;
- every block/escalation explains why and what can resolve it;
- policy revision used for an execution/gate is persisted.

## Human-in-the-Loop Model

Rules may match:

- primitive/action type;
- risk/category/severity;
- changed paths/capabilities;
- environment;
- confidence/novelty;
- security/test/spec changes;
- cost/budget;
- custom predicates/hooks.

Human attention item includes context, recommendation, consequence, allowed actions and expiry/revalidation behavior.

## Autonomy Presets

A numeric 0–100 control maps to editable default bundles, e.g. high autonomy vs high oversight. Advanced editor shows actual rules. User can override individual categories without losing preset comprehension.

## Increment Realization

| Increment | Policy realization |
|---|---|
| I0 | capability/security ceilings and internal authorization rules. |
| I1 | merge/publication/review mandatory gates. |
| I2 | Planning owner/delegated/policy participation and delivery recommendations. |
| I3 | full generic autonomy/HITL/Approval policy UI + custom hooks. |
| I5/I6/I8 | CI/deployment/resolver policy families. |
| I9 | org/tenant governance and enterprise presets. |

## Current Implementation State

Target spec; generic policy UX waits for I3.

## Deferred Realization

External generic policy engines are not baseline. Add only if concrete rule complexity or interoperability justifies adapter/provider boundary.

## Temporary Dogfood Behavior

I1 may hard-configure a small set of merge/security gates through the same Policy structures, without exposing full editor.

## Failure / Recovery

Unknown/invalid policy fails closed for privileged action. Policy changes re-evaluate waiting items before progression.

## UI Implications

Project Settings/HITL page shows preset level plus explicit categories/rules. Attention cards explain exact policy trigger and one primary action.

## Decisions / ADRs

Autonomy is configurable product policy; security authority remains architecture invariant.