Gate: Plan Validation

Position

After Plan, iteratively before Build

Purpose

Verify the plan is sound — and refine it until it is

When to use

High-cost builds, multi-person work, unfamiliar problem spaces, any time the plan feels vague

What is Plan Validation?

Plan Validation is not a one-way checkpoint. It is a refining loop between the Plan phase and execution.

Plan ←──── refine based on findings
  │                         ↑
  └──→ Plan Validation ─────┘
              │
              ↓ (when plan is validated)
           Build

You validate the plan, find gaps or ambiguities, go back to Plan to sharpen it, and validate again. Each iteration makes the plan more specific. A more specific plan produces better outcomes — fewer surprises during Build, less scope drift, clearer decisions under pressure.

The loop stops when the plan can answer all three validation questions without hesitation.

Why this loop exists

Most plans feel complete when they're written. They aren't. The act of writing a plan makes the author feel clarity that often isn't there — because the author fills in the gaps automatically, from context they carry in their head that isn't in the document.

The Plan Validation loop exists to surface those gaps before they become expensive.

A gap in the plan is cheap to fix at the Plan stage. The same gap discovered mid-Build means rework. Discovered post-Ship, it means a failed cycle.

Every pass through the loop answers a version of the same question: could someone with no prior context on this problem pick up this plan and produce the right result?

The three validation questions

Is the problem correctly stated? Is this the actual problem, or a symptom of something deeper? Is the audience named specifically?
Is the plan feasible? Can the goal be achieved within the stated constraints?
Is the plan specific enough to build from? Could someone who didn't write this plan execute it and produce the same result?

The third question is the one most plans fail. Vague plans produce inconsistent builds.

How to run Plan Validation

Solo

Take a break from the plan (minimum a few hours — fresh eyes matter)
Answer the three validation questions in writing, not just in your head
For every "yes but..." answer, go back to Plan and sharpen that section
Repeat until all three are a clean "yes"

With another person

Share the Plan Brief without explaining it verbally
Ask them to answer: What problem is being solved, and for whom? What does done look like? What would they cut if scope had to be reduced by 50%?
Where their answers differ from yours, the plan is ambiguous — go back and fix it
This is not a review of their opinion. It is a test of plan clarity.

With AI

Here is my Plan Brief: [paste brief]

Act as a critical reviewer. Answer these questions honestly:
1. Is the problem correctly stated, or is this a symptom of a deeper issue?
2. Is the audience specific enough to make design decisions from?
3. Is this plan feasible given the stated constraints?
4. Which success criteria are ambiguous or unmeasurable?
5. What would you cut if scope had to be reduced by 50%?
6. What is the single biggest risk to this plan that is not currently acknowledged?

The refinement loop in practice

The loop typically runs 1–3 times:

First pass — catches obvious gaps: vague goals, missing constraints, audience not named, success criteria not measurable.
Second pass — catches structural issues: the goal is stated but not the right goal; the constraints conflict; the success criteria are measurable but don't actually test the goal.
Third pass (if needed) — catches alignment gaps in multi-person work: two people reading the same plan would make different decisions. Forces explicit choices.

After three passes, if the plan still has major gaps, consider whether the problem is understood well enough to plan at all — and use the Research gate before continuing.

How to know when the loop is done

The loop exits when three things are true:

The plan is executable without clarifying questions. If an AI or a person handed this brief could start building immediately — without asking "what do you mean by X?" — the plan is ready.
The success criteria are falsifiable. Each criterion has a clear pass/fail test. "It works well" is not falsifiable. "The page loads in under 2 seconds on a 4G connection" is.
The audience is named, not implied. Not "users" or "developers" — the specific type of person this is built for, with the specific context that makes this matter to them.

What "refining" actually means

Going back to Plan is not failure. It is the loop working as intended. Typical refinements:

Replacing vague goals with specific, measurable ones
Naming the audience more precisely
Adding a constraint that was assumed but not written
Splitting a success criterion that was doing too much work into two separate, cleaner ones
Removing scope that the validation revealed as speculative

Each refinement is a decision made explicitly — in writing — rather than implicitly during Build. That is the point.

Plan Validation output

## Plan Validation Log

**Pass:** [1 / 2 / 3]
**Reviewed by:** [Name, "Self", or "AI-assisted"]
**Date:** [Date]

**Is the problem correctly stated?**
[Yes / No / Partial — with explanation]

**Is the audience specific?**
[Yes / No / Partial — with explanation]

**Is the plan feasible?**
[Yes / No / Partial — with explanation]

**Is the plan specific enough to build from?**
[Yes / No / Partial — with explanation]

**Gaps found:**
- [Gap 1]
- [Gap 2]

**Changes made to Plan Brief:**
- [Change 1]
- [Change 2]

**Decision:**
- [ ] Ready to Build
- [ ] Needs another validation pass

Plan Validation checklist

Plan Brief reviewed after a break, not immediately after writing it
All three validation questions answered in writing
Audience is specific — not "users" or "everyone"
Success criteria are measurable and falsifiable
Plan has been handed to someone else (or AI) to test clarity
All gaps found have been addressed in the Plan Brief
Plan Brief is more specific after this pass than before it
Decision to proceed to Build (or run another pass) is explicit

Posición

Después de Planificar, de forma iterativa antes de Construir

Propósito

Verificar que el plan es sólido — y refinarlo hasta que lo sea

Cuándo usar

Construcciones costosas, trabajo con varias personas, espacios de problemas desconocidos, cualquier momento en que el plan se sienta vago

¿Qué es la Validación del Plan?

La Validación del Plan no es un punto de control unidireccional. Es un ciclo de refinamiento entre la fase de Planificar y la ejecución.

Plan ←──── refine based on findings
  │                         ↑
  └──→ Plan Validation ─────┘
              │
              ↓ (when plan is validated)
           Build

Validas el plan, encuentras brechas o ambigüedades, vuelves a Planificar para afinarlo, y vuelves a validar. Cada iteración hace el plan más específico. Un plan más específico produce mejores resultados — menos sorpresas durante Construir, menos desvío del alcance, decisiones más claras bajo presión.

El ciclo se detiene cuando el plan puede responder las tres preguntas de validación sin dudas.

Por qué existe este ciclo

La mayoría de los planes se sienten completos cuando se escriben. No lo están. El acto de escribir un plan hace que el autor sienta una claridad que a menudo no existe — porque el autor llena los vacíos automáticamente, desde el contexto que lleva en su cabeza pero que no está en el documento.

El ciclo de Validación del Plan existe para sacar a la superficie esas brechas antes de que se vuelvan costosas.

Una brecha en el plan es barata de corregir en la etapa de Planificar. La misma brecha descubierta a mitad de Construir significa rehacer trabajo. Descubierta después de Lanzar, significa un ciclo fallido.

Cada pasada por el ciclo responde una versión de la misma pregunta: ¿podría alguien sin contexto previo sobre este problema tomar este plan y producir el resultado correcto?

Las tres preguntas de validación

¿El problema está correctamente planteado? ¿Es este el problema real, o un síntoma de algo más profundo? ¿Se nombra específicamente a la audiencia?
¿El plan es factible? ¿Puede lograrse el objetivo dentro de las restricciones establecidas?
¿El plan es lo suficientemente específico para construir a partir de él? ¿Podría alguien que no escribió este plan ejecutarlo y producir el mismo resultado?

La tercera pregunta es la que la mayoría de los planes falla. Los planes vagos producen construcciones inconsistentes.

Cómo ejecutar la Validación del Plan

Solo

Tómate un descanso del plan (mínimo unas pocas horas — los ojos frescos importan)
Responde las tres preguntas de validación por escrito, no solo en tu cabeza
Para cada respuesta "sí pero...", vuelve a Planificar y afina esa sección
Repite hasta que las tres sean un "sí" limpio

Con otra persona

Comparte el Plan Brief sin explicarlo verbalmente
Pídele que responda: ¿Qué problema se está resolviendo y para quién? ¿Cómo se ve el resultado? ¿Qué cortarían si el alcance tuviera que reducirse un 50%?
Donde sus respuestas difieran de las tuyas, el plan es ambiguo — vuelve y corrígelo
Esto no es una revisión de su opinión. Es una prueba de la claridad del plan.

Con IA

Here is my Plan Brief: [paste brief]

Act as a critical reviewer. Answer these questions honestly:
1. Is the problem correctly stated, or is this a symptom of a deeper issue?
2. Is the audience specific enough to make design decisions from?
3. Is this plan feasible given the stated constraints?
4. Which success criteria are ambiguous or unmeasurable?
5. What would you cut if scope had to be reduced by 50%?
6. What is the single biggest risk to this plan that is not currently acknowledged?

El ciclo de refinamiento en la práctica

El ciclo generalmente se ejecuta 1–3 veces:

Primera pasada — detecta brechas obvias: objetivos vagos, restricciones faltantes, audiencia no nombrada, criterios de éxito no medibles.
Segunda pasada — detecta problemas estructurales: el objetivo está planteado pero no es el correcto; las restricciones entran en conflicto; los criterios de éxito son medibles pero no prueban realmente el objetivo.
Tercera pasada (si es necesario) — detecta brechas de alineación en trabajo con varias personas: dos personas leyendo el mismo plan tomarían decisiones diferentes. Fuerza elecciones explícitas.

Después de tres pasadas, si el plan aún tiene brechas importantes, considera si el problema se entiende lo suficiente para planificar — y usa la compuerta de Investigación antes de continuar.

Cómo saber cuándo el ciclo ha terminado

El ciclo sale cuando tres cosas son verdad:

El plan es ejecutable sin preguntas de aclaración. Si una IA o una persona que recibe este brief pudiera empezar a construir de inmediato — sin preguntar "¿qué quieres decir con X?" — el plan está listo.
Los criterios de éxito son falsificables. Cada criterio tiene una prueba clara de pasa/falla. "Funciona bien" no es falsificable. "La página carga en menos de 2 segundos en una conexión 4G" sí lo es.
La audiencia está nombrada, no implícita. No "usuarios" o "desarrolladores" — el tipo específico de persona para quien se construye, con el contexto específico que hace que esto importe para ellos.

Qué significa realmente "refinar"

Volver a Planificar no es un fracaso. Es el ciclo funcionando como se diseñó. Refinamientos típicos:

Reemplazar objetivos vagos por objetivos específicos y medibles
Nombrar la audiencia con más precisión
Agregar una restricción que se asumía pero no estaba escrita
Dividir un criterio de éxito que hacía demasiado trabajo en dos criterios separados y más claros
Eliminar alcance que la validación reveló como especulativo

Cada refinamiento es una decisión tomada explícitamente — por escrito — en lugar de implícitamente durante Construir. Ese es el punto.

Resultado de la Validación del Plan

## Plan Validation Log

**Pass:** [1 / 2 / 3]
**Reviewed by:** [Name, "Self", or "AI-assisted"]
**Date:** [Date]

**Is the problem correctly stated?**
[Yes / No / Partial — with explanation]

**Is the audience specific?**
[Yes / No / Partial — with explanation]

**Is the plan feasible?**
[Yes / No / Partial — with explanation]

**Is the plan specific enough to build from?**
[Yes / No / Partial — with explanation]

**Gaps found:**
- [Gap 1]
- [Gap 2]

**Changes made to Plan Brief:**
- [Change 1]
- [Change 2]

**Decision:**
- [ ] Ready to Build
- [ ] Needs another validation pass

Lista de verificación de Validación del Plan

Plan Brief revisado después de un descanso, no inmediatamente después de escribirlo
Las tres preguntas de validación respondidas por escrito
La audiencia es específica — no "usuarios" o "todos"
Los criterios de éxito son medibles y falsificables
El plan fue entregado a otra persona (o IA) para probar su claridad
Todas las brechas encontradas han sido abordadas en el Plan Brief
El Plan Brief es más específico después de esta pasada que antes
La decisión de proceder a Construir (o hacer otra pasada) es explícita