Pedí tres dormitorios. El sistema respondió que no sabía.

Construimos un motor espacial pequeño.

Recibe unas pocas decisiones (uso, dormitorios, necesidades y material) y devuelve una distribución de ochenta metros cuadrados. No pretende diseñar cualquier vivienda. Solo compone una familia demostrativa con un catálogo cerrado.

Le pedí tres dormitorios.

El esquema de entrada acepta el número. El motor solo sabe resolver uno o dos.

Su respuesta incluye un estado explícito: unsupported_program.

En castellano: este programa todavía no está incluido en la demostración.

Ésa es, probablemente, la decisión más importante que toma todo el motor.

Un sistema también se diseña por lo que se niega a afirmar

Cuando enseñamos un prototipo generativo solemos elegir el caso que funciona. Introducimos una petición compatible, aparece una composición razonable y la interfaz produce esa sensación peligrosa de que el sistema “entiende”.

Yo quería probar lo contrario.

El catálogo del motor declara de antemano sus límites:

• es una familia demostrativa, no un optimizador general;
• no valida normativa, estructura ni instalaciones;
• no contiene precios, proveedores ni resultados de uso verificados;
• la plantilla disponible admite uno o dos dormitorios.

Ante la petición de tres, el motor conserva la solicitud original, resuelve una geometría de dos dormitorios como referencia y marca la salida como no soportada.

Eso permite explicar el límite sin fingir que la petición es imposible. “No lo resuelvo” y “no se puede hacer” son afirmaciones muy diferentes.

Hay una decisión de producto escondida aquí: una negativa debe viajar con más autoridad que el resultado visual.

El fallback también puede engañar

El motor no se limita a devolver un error. Para tres dormitorios genera la escena conocida de dos y añade:

• requestedBedrooms: 3;
• resolvedBedrooms: 2;
• status: unsupported_program;
• una explicación de que la demo solo incluye uno y dos dormitorios.

Es una buena salida para depurar o comparar. Pero abre otro riesgo.

Si la interfaz ignora status y solo dibuja scene, la persona verá una planta pulida de dos dormitorios después de haber pedido tres. El límite estará escrito en los datos y ausente en la experiencia.

Entonces el sistema habrá dicho “no sé” por dentro y “aquí lo tienes” por fuera.

Esto demuestra por qué una regla no está terminada cuando existe en un archivo. Tiene que gobernar todas las capas que expresan la decisión.

La regla completa sería algo así:

Si el programa solicitado no está soportado, conservar la petición y explicar el límite. Se puede mostrar una referencia solo si se identifica como referencia, nunca como respuesta. Ninguna acción posterior puede tratarla como documentación de proyecto.

Después hay que verificar no solo el objeto JSON, sino la pantalla, el PDF y cualquier agente que consuma la salida.

Lo Peix: un caso construido que todavía no demuestra el método

Tres Estados contiene también la lectura de Lo Peix, un apartamento que sí existe, está construido y se usa.

Eso podría convertirse fácilmente en un caso de éxito. Bastaría con ordenar unas fotografías, asignar reglas a decisiones pasadas y concluir que el método funciona.

El propio caso se niega a hacerlo.

La codificación es retrospectiva: el espacio se diseñó antes de que esta metodología estuviera formalizada. La auditoría publicada registra seis reglas espaciales candidatas, tres decisiones leídas a posteriori, dos tokens materiales, un componente espacial y cinco patrones.

También registra cero observaciones posteriores al uso.

Ese cero importa más que los demás números.

Lo Peix demuestra que un espacio construido puede leerse como un sistema de decisiones. No demuestra que escribir esas reglas antes produzca un proyecto mejor. Para demostrarlo haría falta aplicarlas de forma prospectiva, con cliente, presupuesto, restricciones y evaluación posterior.

Una fotografía terminada no puede sustituir esa prueba.

Dos negativas, la misma disciplina

El motor espacial dice:

Tres dormitorios no están soportados.

El caso de Lo Peix dice:

Este edificio no demuestra todavía que el método mejore el resultado.

Una negativa es técnica. La otra es epistemológica. Las dos protegen la misma cosa: la distancia entre lo que el sistema puede producir y lo que estamos autorizados a concluir.

En productos con agentes, esa distancia se cierra demasiado deprisa. El modelo produce una respuesta fluida, el render parece terminado y el equipo confunde presentación con validez.

Cuanto mejor es la expresión, más importante es declarar la autoridad.

No es lo mismo:

• una posibilidad generada;
• un concepto que cumple unas reglas ilustrativas;
• una solución validada contra normativa;
• un proyecto construible;
• un resultado que ya ha funcionado en uso.

El motor actual solo tiene autoridad para la segunda categoría.

“Si siempre pones límites, el producto parecerá débil”

Puede parecerlo.

También puede evitar que una demostración se venda como una capacidad.

Un producto no gana confianza afirmando que resuelve todo. La gana respondiendo de manera estable dentro de su perímetro y deteniéndose de manera inteligible fuera de él.

La alternativa a una negativa no es necesariamente una solución. A menudo es una alucinación con buenos materiales.

Eso no significa llenar cada pantalla de descargos. Significa diseñar salidas distintas para estados distintos:

• soportado: mostrar la composición y las reglas aplicadas;
• parcial: mostrar qué parte se resolvió y qué queda pendiente;
• no soportado: no permitir que el resultado parezca una respuesta;
• requiere autoridad externa: derivar a normativa, técnico o decisión humana;
• sin evidencia: decirlo y conservar la pregunta.

La negativa bien diseñada no termina la conversación. La orienta.

Lo que esta prueba sí demuestra

Demuestra que podemos codificar un límite y devolverlo junto al resultado.

También encuentra un riesgo: el fallback visual puede imponerse al estado si el consumidor no respeta el contrato.

Demuestra que podemos mirar un proyecto construido y extraer decisiones. No demuestra que la extracción retrospectiva valide el método.

Y deja dos siguientes pasos muy concretos:

1. probar que todas las superficies bloquean o degradan correctamente una salida unsupported_program;
2. aplicar las reglas de Tres Estados antes de diseñar un proyecto real y observar qué cambia después de usarlo.

No necesito que el motor parezca más inteligente.

Necesito que sea exacto sobre la inteligencia que todavía no tiene.

En el Instituto de Diseño Agéntico trabajamos ese tipo de autoridad: qué puede proponer un agente, qué puede validar una regla y en qué punto debe aparecer una persona. Diseñar el “no” es parte del sistema, no su mensaje de error.

---

Nota de verificación editorial

Revisión realizada el 14 de septiembre de 2026 sobre Tres Estados, revisión a6d25a9. El comportamiento descrito está en packages/spatial-engine/src/schema.mjs y core.mjs; los límites del caso están en src/content/casos/lo-peix.mdx. El motor devuelve una geometría de referencia aun cuando marca el programa como no soportado: este texto no afirma que la interfaz actual la presente incorrectamente, identifica el riesgo contractual que debe probarse.