The two feedback loops
solveOS is a cycle, not a line. Two distinct feedback loops make the framework perpetual — and explain why it works.
solveOS contains two distinct feedback loops that make the framework a cycle — not a one-time process.
Both loops exist to do one thing: reduce the cost of being wrong.
Loop 1 — Plan → Validate Plan → Plan (refine)
┌──────────────────────────────┐
↓ │
Plan ──→ [Plan Validation] ──────┘
│
↓ (when plan is ready)
BuildBefore you build anything, the plan must be good enough to build from. The Plan Validation gate runs a structured check and, if gaps are found, sends you back to Plan to sharpen it. This loop runs until the plan can be executed without guesswork — typically 1–3 passes.
Why it exists
Vague plans produce vague builds. Fixing ambiguity before execution is 10x cheaper than fixing it after. Every pass through this loop produces a more specific, more executable plan.
When it exits
The plan answers all validation questions without hesitation — the problem is correctly stated, the audience is specific, the goal is feasible, and someone else could execute it and produce the same result.
Typical runs: 1–3 passes.
See full Plan Validation gate documentation →
Loop 2 — Ship → Review → Plan (continue building)
Plan → Build → Ship
│
↓
[Review]
│
↓
Plan → Build → Ship
│
↓
...Shipping something is not the end of the work — it is the beginning of knowing. The Review gate measures what happened after shipping, reflects on the cycle, and produces the inputs for the next Plan. This is what makes solveOS a continuous building process, not a one-time delivery.
Why it exists
The real world tells you things your plan couldn't predict. User behavior, unexpected failures, assumptions that turned out wrong — all of this surfaces only after shipping. Without a review loop, the same mistakes repeat.
When it exits
Never — the loop is perpetual. It stops only when the problem is no longer worth solving. After reviewing, you always start a new Plan — informed by what the previous cycle taught.
See full Review gate documentation →
The full picture
┌──────────────────────────────────────────────────────────────┐
↓ │
Plan ←──── refine ←── [Plan Validation] ←── Plan (loop 1) │
│ │ │
│ (ready to build) │
↓ ↓ │
Plan ──→ Build ──→ [Build Validation] ──→ Ship ──→ [Review] ─────┘
(loop 2)Loop 1 runs before execution begins — it protects the build.
Loop 2 runs after the result is live — it informs the next cycle.
What these loops prevent
Loop 1 prevents
- Building the wrong thing
- Wasted execution effort
- Expensive mid-build corrections
- Ambiguous success criteria discovered during Build
Loop 2 prevents
- Repeating the same mistakes
- Disconnected cycles
- Assumptions never tested against reality
- Building more of the wrong thing
Los dos ciclos de retroalimentación
solveOS es un ciclo, no una línea. Dos ciclos de retroalimentación distintos hacen que el framework sea perpetuo — y explican por qué funciona.
solveOS contiene dos ciclos de retroalimentación distintos que hacen del framework un ciclo — no un proceso de una sola vez.
Ambos ciclos existen para hacer una sola cosa: reducir el costo de estar equivocado.
Ciclo 1 — Plan → Validar Plan → Plan (refinar)
┌──────────────────────────────┐
↓ │
Plan ──→ [Plan Validation] ──────┘
│
↓ (cuando el plan está listo)
BuildAntes de construir cualquier cosa, el plan debe ser lo suficientemente bueno para construir a partir de él. El gate Plan Validation ejecuta una verificación estructurada y, si se encuentran vacíos, te envía de vuelta a Plan para afinarlo. Este ciclo se ejecuta hasta que el plan pueda ejecutarse sin suposiciones — típicamente 1–3 pasadas.
Por qué existe
Los planes vagos producen builds vagos. Corregir la ambigüedad antes de la ejecución es 10 veces más barato que corregirla después. Cada pasada por este ciclo produce un plan más específico y más ejecutable.
Cuándo sale
El plan responde todas las preguntas de validación sin dudas — el problema está correctamente enunciado, la audiencia es específica, el objetivo es factible y otra persona podría ejecutarlo y producir el mismo resultado.
Pasadas típicas: 1–3.
Ver documentación completa del gate Plan Validation →
Ciclo 2 — Ship → Review → Plan (continuar construyendo)
Plan → Build → Ship
│
↓
[Review]
│
↓
Plan → Build → Ship
│
↓
...Entregar algo no es el fin del trabajo — es el comienzo del conocimiento. El gate Review mide lo ocurrido después de la entrega, reflexiona sobre el ciclo y produce los insumos para el siguiente Plan. Esto es lo que hace de solveOS un proceso de construcción continua, no una entrega única.
Por qué existe
El mundo real te dice cosas que tu plan no podía predecir. El comportamiento de los usuarios, fallos inesperados, supuestos que resultaron incorrectos — todo esto solo surge después de entregar. Sin un ciclo de revisión, los mismos errores se repiten.
Cuándo sale
Nunca — el ciclo es perpetuo. Se detiene solo cuando el problema ya no vale la pena resolver. Después de revisar, siempre se inicia un nuevo Plan — informado por lo que enseñó el ciclo anterior.
Ver documentación completa del gate Review →
El panorama completo
┌──────────────────────────────────────────────────────────────┐
↓ │
Plan ←──── refinar ←── [Plan Validation] ←── Plan (ciclo 1) │
│ │ │
│ (listo para construir) │
↓ ↓ │
Plan ──→ Build ──→ [Build Validation] ──→ Ship ──→ [Review] ─────┘
(ciclo 2)El Ciclo 1 se ejecuta antes de que comience la ejecución — protege el build.
El Ciclo 2 se ejecuta después de que el resultado está en vivo — informa el siguiente ciclo.
Qué previenen estos ciclos
El Ciclo 1 previene
- Construir lo incorrecto
- Esfuerzo de ejecución desperdiciado
- Correcciones costosas a mitad del build
- Criterios de éxito ambiguos descubiertos durante el Build
El Ciclo 2 previene
- Repetir los mismos errores
- Ciclos desconectados
- Supuestos nunca probados contra la realidad
- Construir más de lo incorrecto