technical-visionlisted

# Technical vision A technical vision is the shared picture of where the architecture is going and why, so that a hundred independent decisions pull in the same direction instead of scattering. It is not a roadmap (no dates, no deliverables) and not a fantasy (it sequences reachable steps); it is the coherence that lets teams decide locally and still converge. ## Method 1. **State the destination and the why.** The target architecture in a few Container-level diagrams (see architecture-diagrams) and the forces driving it (scaling limits hit, team boundaries, a strategic capability the current shape cannot support): the *why* is what lets people apply the vision to situations it did not anticipate. A destination without a rationale gets cargo-culted or ignored. 2. **Anchor in current reality, honestly.** Describe the system as it actually is (the real diagram, not the aspirational one: see architecture-diagrams' honesty rule), including the debt and the ugly parts; a vision that pretends the starting point is clean produces a plan that does not survive contact with the codebase (see tech-debt-register). 3. **Sequence the path as principles, not a Gantt chart.** The order of movement (what must come first, what unlocks what) and the migration strategy (strangler-fig for the big moves: see strangler-fig), expressed as direction and next steps, not dated commitments. This is the difference from a roadmap (see roadmap-com