implementation-layering

• product features,
• internal tools,
• research workflows,
• infrastructure changes,
• process automation,
• data pipelines,
• agentic or human-in-the-loop systems.

• target name, capability name, feature name, or workflow name,
• existing requirements, specs, issues, PRDs, ADRs, README sections, or roadmap notes,
• existing implementation files or tests,
• known constraints such as budget, timeline, team size, safety, compliance, reliability, or pilot needs.

1. docs/{target-name}/implementation-layering.md when a target-specific docs folder exists,
2. docs/implementation-layering.md when project-level docs exist,
3. implementation-layering.md at the project root when no docs folder exists.

• lets the team start with the smallest useful proof,
• avoids mixing pilot, scale, fallback, and polish into the POC,
• makes deferrals explicit rather than accidental,
• makes promotion decisions evidence-based,
• balances working length against value delivered,
• can be understood by both implementation agents and human reviewers.

• calling a layer "POC" while including production-scale concerns,
• creating layers that are just task buckets without decision questions,
• advancing to scale before repeatability is proven,
• making layer boundaries by component ownership alone,
• deferring verification until the final layer,
• adding a layer when it does not unlock a new decision.

## Implementation Layering Result

- Target: <target-name>
- Artifact: <path>
- Mode: created | updated
- Layer count: <n>
- Recommended next layer: <L0/L1/...>
- Boundary heuristic: applied
- Key decision unlocked by L0: <decision>
- Major deferred scope: <summary>
- Validation: <checks performed or not run>