Constraints-First Execution
When to use
Use at the beginning of a new implementation, automation, or research workflow, especially when an agent could overbuild or assume unstated permissions.
Required inputs
Goal, owner-authorized actions, prohibited actions, existing system capabilities, success evidence, resource budget, and any external approval boundaries. Unknown authority is not implicit permission.
Procedure
- Write a short contract: objective, in-scope deliverable, non-goals, reversible actions, immutable constraints, and verified completion evidence.
- Question whether each requirement is actually necessary for the user's goal. Do not silently delete explicit user requirements.
- Remove optional work that does not improve the named acceptance criteria. Keep required safety and quality controls.
- Simplify the proposed architecture before optimizing it. Prefer existing tools and direct workflows over new frameworks.
- Order remaining tasks by dependency and evidence gates. Identify the next smallest reversible unit that proves progress.
- Only after this sequence consider acceleration, parallelization, or automation. Estimate cost and complexity of each addition.
- Make approval questions explicit and bounded. If authorization is unclear for a material change, preserve a proposal instead of executing it.
Stop or escalate
Stop before access escalation, paid commitments outside budget, irreversible effects, frozen methodology changes, or actions outside explicit permission. Never treat speed goals as overriding safeguards.
Deliverable
A brief requirements-to-actions table with must, may, must-not, owners, dependencies, and evidence needed to call each unit complete. Use the contract template when traceability matters.
Acceptance
Every proposed task has a named reason and an evidence condition; no new dependency or abstraction is justified solely by possible future needs.