# ExecPlan Protocol

An ExecPlan is a living, self-contained execution document for complex work.

## When an ExecPlan is required

Create or update an ExecPlan when any of the following is true:

- the task has multiple deliverables or materially dependent stages;
- legal analysis and quantitative or coding work must be reconciled;
- the task is high-stakes and errors would be difficult to detect from the final prose alone;
- several source classes, jurisdictions, time periods, or datasets must be coordinated;
- implementation spans multiple files or requires migration, validation, and rollback thinking;
- subagents will be used;
- the user explicitly requests a plan.

Do not create an ExecPlan for a small, well-scoped answer or a trivial code edit.

## Required structure

Create the plan under `plans/<task-slug>.md` unless the task specifies another location.

```markdown
# <Task>

## Objective
## Deliverables
## Scope and Non-Scope
## Known Inputs
## Material Assumptions
## Questions That Could Change the Outcome
## Workstreams and Dependencies
## Source and Tool Plan
## Validation Plan
## Approval Boundaries
## Progress
- [ ] ...

## Decision Log
| Date/Stage | Decision | Basis | Consequence |

## Evidence Ledger
| Claim/Issue | Source or Test | Status | Notes |

## Risks and Failure Modes
## Results and Residual Uncertainty
```

## Operating rules

- Keep the plan current; do not use it as ceremonial documentation.
- Record material changes in the decision log.
- Mark completed steps only after validation.
- Split independent workstreams for subagents, but keep cross-cutting legal or methodological judgments with the main agent.
- End with a concise record of what was completed, validated, deferred, or left uncertain.