architectural-proposals

Start with a problem statement citing specific evidence, then describe the proposed architecture with technical specifics. Document what changes and what stays the same, frame key decisions with recommendations, list risks with mitigations, and define explicit v1 scope.

Required sections are Problem Statement, Proposed Architecture, What Changes, What Stays the Same, Key Decisions Needed, Risks and Mitigations, and Scope. Optional sections include Implementation Plan, Success Criteria, Open Questions, and an Appendix of alternatives considered.

Document each risk with a specific failure mode, likelihood rated Low/Medium/High, impact rated Low/Medium/High, and concrete measurable mitigations. Avoid percentages and vague mitigations; every risk should have an actionable response such as an integration test or fallback mechanism.

Restructure waves when a proposal invalidates existing assumptions or introduces a new foundation. Acknowledge the shift explicitly, cascade impacts to downstream waves, identify work that can proceed in parallel, and document new blocking dependencies.

Common anti-patterns include solution-first thinking without a problem statement, vague architecture without technical specifics, ignoring impact on existing milestones, missing risk analysis, unbounded scope, and unsubstantiated claims without evidence.