Introduction to Altitude-Gated Design

AI can design your entire system in a single session. It will produce diagrams, component definitions, API contracts, database schemas, and deployment topology without pausing to ask whether any of it was right at the level above.

This is the problem the Altitude-Gated Design Protocol exists to solve.

What "premature resolution" costs

In conventional architecture and consulting work, understanding a system happens in passes. You leave a discovery session with a feel for the landscape. You return the next day and focus on specific areas. A week later you are deep in one subsystem while other areas remain sketchy. That uneven, progressive deepening is not sloppy — it is how genuine understanding forms. Each level of abstraction needs to stabilize before the next level can be meaningfully explored.

AI removes those pauses. It can move from intent statement to component diagram in minutes, if you let it. The result looks thorough — it is detailed, it is internally consistent, it references the right vocabulary — but it was never validated at the levels between vision and implementation. You end up with detailed component designs for a decomposition that was never tested against the capability map. You end up with API contracts that reflect implementation assumptions rather than system requirements. You have hung drywall before the foundation cured.

The cost is not paid immediately. The work looks complete and feels complete. The cost surfaces during implementation, when an engineer discovers the component boundary does not align with the actual data flow, or during launch, when a stakeholder asks a question about a design choice that nobody present can answer, or a year later when the team has to modify the system and discovers the design never reflected their intent at all.

The five altitudes

The Altitude-Gated Design Protocol organizes design work across five defined levels. Each altitude has a specific focus, a deliverable artifact, and a gate condition that must be met before descending to the next level.

Altitude	The question	The artifact	The gate
50,000 ft — Vision	What is this system and why does it exist?	Vision statement (1 page, no technical terms)	Can you explain this to a non-technical stakeholder without clarifying questions?
30,000 ft — Capabilities	What can this system do?	Capability map (business terms only)	Does the capability map cover the full vision — no more, no less?
10,000 ft — Architecture	How is the system organized to deliver those capabilities?	Architecture overview and structural decisions	Do the component boundaries align with the capability map?
5,000 ft — Design	How do the components work internally?	Component designs, data models, API contracts, DDDs	Does each component's design trace to the architecture?
1,000 ft — Implementation	Does the code express the design?	Working software, tests, configuration	Does the implementation align with the documented design?

Each altitude is a distinct mode of thinking. Vision altitude is about problems, stakeholders, and success criteria. Capability altitude is about what the system can do in business terms — not how. Architecture altitude is about structure and boundaries — which components exist and how they relate. Design altitude is about how the components work internally. Implementation altitude is code.

These are not just abstraction levels — they are different conversations with different vocabularies, different stakeholders, and different failure modes if they collapse into each other.

What each altitude actually looks like

50,000 ft. At vision altitude, no technology is named. No components are identified. No integration points are discussed. The conversation is in plain language and answers three questions: what problem is being solved, for whom, and what does success look like? The artifact is short — a page, maybe less — written so that someone outside the project can read it and understand the system's purpose without asking clarifying questions.

If the vision document uses technical terms, it has descended below vision altitude. Send it back.

30,000 ft. At capability altitude, you are still in the problem domain, not the solution domain. "Manages customer orders" is a capability. "Has an OrderService with CRUD endpoints" is not. The capability map is the full set of things the system can do, organized by business function. It should trace cleanly to the vision — every capability should serve the vision, and every aspect of the vision should be covered by at least one capability.

The test: can a business stakeholder read the capability map and recognize their problem space in it?

10,000 ft. Architecture altitude is where components, boundaries, integration points, and major technology choices appear. Design decisions become relevant here — but only decisions that affect the overall shape of the system. "Monolith or microservices" is an architecture-altitude question. "Which ORM" is not. The architecture overview should include a diagram showing component relationships and system boundaries, and structural Design Decision Documents for the choices that shaped those boundaries.

The gate test: can every capability in the capability map be delivered by an identifiable component or set of components? Are there components that don't map to any capability?

5,000 ft. Design altitude is where internal component behavior is specified. Data models, API contracts, workflow definitions, state machines, error-handling strategies — these live here. Each component gets its own design document, and components can be designed in any order. You do not need to design all of them before implementing any of them; component design can proceed in parallel with implementation once the architecture is stable.

1,000 ft. Implementation altitude is code. At this level, the AI assistant has the full documentation corpus to work from — vision, capabilities, architecture, and component design — and can generate implementations that align with documented intent rather than best-guessing from a chat prompt.

The gate check

Before descending from one altitude to the next, the gate condition is evaluated as a joint review. The AI partner reads the current artifact against the gate question and identifies gaps, inconsistencies, or elements that do not trace cleanly to the artifact above. The human collaborator reviews that assessment and makes the call.

The human can always override. If the AI reports the gate has not yet passed but the collaborator has context the AI lacks — a stakeholder conversation, a pending decision, a deliberate choice to defer — the human can declare the gate passed and descend. The reverse also holds: if the AI reports the gate passed but something feels unstable, the session stays at the current altitude.

What "passing" looks like in practice: the artifact for the current altitude exists, is internally consistent, traces cleanly to the artifact above it, and could be reviewed by someone who was not in the session. A passed gate is a documented state, not a verbal agreement.

The Deferred Details pattern

Real design conversations do not respect altitude boundaries. A capability discussion will surface a database constraint someone knows about. A vision session will trigger a question about a third-party API. A stakeholder will mention a performance requirement in the middle of a component design conversation.

These details are valuable. They should not be ignored or lost.

The Deferred Details pattern handles this: when a detail surfaces that belongs at a lower altitude, acknowledge it, record it in a Deferred Details section with a destination altitude, and return the conversation to the current altitude.

Deferred Details

Detail	Source	Destination Altitude
Must integrate with SAP for order data	Stakeholder, vision session	10,000 ft — Architecture
We use OAuth 2.0 for everything	Enterprise Architect, vision session	5,000 ft — Design
The current system handles 10K orders/day	Stakeholder, capability session	5,000 ft — Design

When the team descends to a lower altitude, the deferred details for that altitude become inputs for the session — pre-captured context that does not need to be re-discovered.

The discipline here is in not acting on the detail while at the current altitude. Knowing that a SAP integration is required is relevant at architecture altitude. Designing the SAP integration during the vision session is premature resolution.

Using the protocol today — no special tooling required

The altitude-gated design protocol is a conversational discipline, not a software feature. You can activate it in any AI-assisted design session with a simple directive at the start of the conversation.

Add this to your AI-Assistant of choice config or paste it at the top of a session before design work begins:

## Design Session Protocol

This session uses the Altitude-Gated Design Protocol. The current design
altitude is [50,000 / 30,000 / 10,000 / 5,000 / 1,000] ft.

Rules for this session:
- Do not introduce concepts, components, or details that belong at a
  lower altitude than the current session altitude.
- If I mention something that belongs at a lower altitude, acknowledge it,
  add it to the Deferred Details section, and keep the conversation at
  the current altitude.
- Do not descend to the next altitude until I explicitly signal readiness.
- When I say "descend" or "next altitude," transition to the next level
  and incorporate any deferred details tagged for that altitude.

Declare the current altitude before beginning. Hold the session at that altitude until the gate condition is met. Descend deliberately.

That is the entire protocol. The rest is structure — artifact conventions, gate check procedures, vocabulary for each altitude — that makes it more reliable across sessions and more durable when you are not the one running every conversation.

What a realistic session flow looks like

A project with non-trivial scope might spend:

• Session 1 — Vision (50K): 30–60 minutes. Produces a one-page vision statement. The gate is whether a non-technical stakeholder can read it and recognize their problem.
• Session 2 — Capabilities (30K): 1–2 hours. Produces a capability map. The gate is whether every capability traces to the vision and every aspect of the vision is covered.
• Session 3+ — Architecture (10K): 2–4 hours across one or more conversations. Produces an architecture overview and structural decision documents. The gate is whether component boundaries align with the capability map.
• Sessions N+1... — Design (5K): One session per major component, in any order. Gate checks are component-local.
• Ongoing — Implementation (1K): Continuous, directed by the documented corpus.

The sessions do not need to be contiguous or back-to-back. Because each altitude produces a documented artifact, the design state persists across session gaps. You can pause at any altitude, return later, and pick up from the current artifact rather than from memory.

This is not a linear sequence that must complete before any implementation begins. Architecture can stabilize while some components are still being designed. Well-understood components can enter implementation while others are still in design. The protocol gates descent — it does not mandate a waterfall.

Ascending when necessary

The protocol is not one-directional. Design work at 5,000 ft sometimes reveals that an architecture decision at 10,000 ft was wrong. Work at 10,000 ft sometimes surfaces a capability gap that was invisible at 30,000 ft. These are not failures — they are how design works.

When this happens:

1. Document the finding at the current altitude
2. Explicitly ascend to the altitude where the issue lives
3. Revise the artifact at that altitude
4. Validate the gate condition again
5. Re-descend through any affected intermediate altitudes

The discipline is in making the ascent explicit rather than quietly patching the lower-altitude artifact while leaving the upper levels in a state that no longer matches. A component design that contradicts the architecture is not a component design problem — it is an architecture problem that surfaced at the component level.

What this changes about AI-assisted design

Human designers working without AI pace themselves naturally — breaks, sleep, hallway conversations. Those pauses create implicit altitude gates. A senior engineer who goes home after a vision conversation and returns the next day to start capability mapping is unconsciously running the protocol.

AI removes that pacing. Given the chance, it will generate a complete vision-to-implementation design in a single sitting. The architecture that emerges is internally consistent; it was also never validated at any intermediate level. The result is technically thorough documentation that carries none of the genuine understanding that slower, paced design work produces.

The altitude protocol reintroduces the deliberate pacing that produces robust designs — not because the AI needs it, but because the human holding the design intent needs the space to validate understanding at each level before committing to the next. The gates exist for the designer, not the AI.

The practical result: design artifacts that reflect genuinely validated intent at every level of abstraction. When someone asks "why is the system this shape?" six months into implementation, there is an artifact for each altitude that answers the question, and each artifact traces to the ones above it. The chain is visible.

The honest limit

The altitude protocol does not guarantee good designs. It guarantees that the design was validated at each level of abstraction before the next level was committed to — which is not the same thing. You can run a perfect altitude-gated session and still get the capability map wrong, or choose the wrong architecture given the right capabilities, or design a component that misses the point of the system.

What the protocol prevents is the specific failure mode where those errors are invisible because the design never passed through the altitude where they would have been caught. A capability-map error that would have been obvious at 30,000 ft is invisible at 5,000 ft, because the component design looks correct relative to the architecture even if the architecture is wrong relative to the capabilities. You find this class of error at the altitude it belongs to, or you find it in production.

The protocol gives you the checkpoint. What you do at the checkpoint is still the design work.

Frequently Asked Questions

This looks like a formalization of "start abstract, get concrete." What does the altitude protocol add over good engineering judgment?

The protocol is what good engineering judgment looks like when working with an AI assistant. A senior engineer working alone has implicit gates — sleep, reflection, the moment of switching contexts. An AI assistant has none of those. Given an opening, it will proceed from problem statement to database schema in a single session, producing output that looks internally consistent while never having been validated at vision, capability, or architecture altitude. The protocol enforces the gates experienced engineers apply implicitly, and it produces shareable artifacts at each altitude — so the judgment doesn't live in one person's head but in the design state persisting between sessions.

The gate conditions feel subjective. What does "passing" actually look like in practice?

A passed gate is a documented artifact, not a verbal agreement. For the 50K gate: someone who was not in the session can read the vision document and explain the system's purpose and audience. For the 30K gate: map every capability to the vision and every aspect of the vision to at least one capability — gaps and stranded items are the objective signal. For the 10K gate: point to a component for every capability and a capability for every component. The subjectivity is real at 50K, where "can a non-technical stakeholder understand it?" requires a judgment call. The protocol accepts that tradeoff. The alternative is no checkpoint at all.

I'm a small team or solo. Do I need all five altitudes?

The altitudes scale with scope, not with team size. A solo developer on a small project might spend 20 minutes at vision, 30 at capabilities, and an hour at architecture — and the artifacts might fit on a single page each. What doesn't scale down is the order. Designing at 5K before 10K is stable is the failure mode regardless of team size. The question isn't "how many altitudes?" It's "does each altitude reflect genuine understanding before descending?"

What happens when altitude boundaries blur — when a capabilities question surfaces an architecture constraint?

Use the Deferred Details pattern: acknowledge the lower-altitude detail, capture it with a destination altitude tag, and return the conversation to the current altitude. "We use OAuth 2.0 for everything" is an architecture detail that surfaced in a vision session. Don't design the auth flow during the vision session; record it as a deferred detail tagged for 10K. When the session descends to architecture, the deferred details become inputs. The discipline is in not resolving the detail at the wrong altitude — acting on it prematurely is how you end up with authentication decisions made before the capability map exists.

What happens when a stakeholder pushes to skip straight to implementation?

This is the most common point of failure for the protocol in real work. The most effective response is to run a fast 50K session anyway — 30 minutes, capture the vision, then show them what you captured: "Here's what I understood you to need. Is this the problem?" Almost always, reading their own problem back to them in structured form surfaces corrections and clarifications that would have produced a wrong architecture. The session is short enough not to feel like overhead. What feels like overhead is the word "session." Call it "making sure I understand the problem before we design the solution."