Estado 2 · Decisiones · Tres Estados · Arquitectura, diseño e I+D aplicada

Un catálogo no decide. Un token puede declarar que el suelo principal es mineral, mate y continuo; un componente puede resolver correctamente un módulo de almacenaje de 600 mm; una regla puede exigir que el recorrido de acceso quede libre. Ninguno de los tres responde a la pregunta que un proyecto hace cada día: de todo lo que está permitido, ¿qué toca aquí?

Ésa es la pregunta del Estado 2. Y su respuesta no es un dibujo: es una decisión con rastro.

Lo que el sistema no puede resolver solo

El Estado 1 entrega un espacio de soluciones aceptables. Normalmente es grande. Dentro de él caben opciones que cumplen todas las reglas y que sin embargo son muy distintas entre sí: una gana superficie útil, otra gana luz compartida, otra gana plazo de suministro, otra gana facilidad de mantenimiento dentro de diez años.

Elegir entre ellas exige algo que ninguna regla contiene: contexto.

INTENCIÓN        qué intentamos conseguir
   +
CONTEXTO         geometría · presupuesto · uso · habitantes · plazo
   +
REGLAS           lo que está permitido
   ↓
DECISIÓN         lo que hacemos aquí

Planta arquitectónica con un gran espacio central rectangular etiquetado Espacio Servido y volúmenes laterales más pequeños etiquetados Espacio Servidor que alojan instalaciones, escaleras y conductos. — № 051 La distinción servido y servidor de Louis Kahn. Lo que se habita descansa sobre una infraestructura que lo hace posible y que Kahn se negó a esconder. La capa de decisión es exactamente eso: servidora, invisible en el resultado y determinante en él. Aquí tampoco se oculta. Cf. Kahn, Richards Medical Research Building, 1957–1965. Transposición editorial.

El Decision Trace

Si el Estado 2 produce un único artefacto reconocible, es éste. No es un informe de cumplimiento: es la explicación de una elección.

DECISIÓN
Módulo de almacenaje B

POR QUÉ
✓ cabe en 600 mm
✓ mantiene libre el recorrido de acceso
✓ usa material.wood.primary
✓ entrega dentro del plazo de obra

DESCARTADO
Módulo A
× plazo de suministro: 11 semanas

EXCEPCIÓN
ninguna

CONFIANZA
alta

COSTE DE DESHACER
medio · fixable

Casi ningún estudio entrega esto hoy. Se entregan planos, mediciones y renders —el resultado— pero no el razonamiento, que se queda en la cabeza de quien lo tuvo y en una cadena de correos. Cuando dos años después hay que sustituir una pieza, nadie recuerda si aquel material se eligió por tacto, por precio o porque era lo único disponible aquella primavera.

El Decision Trace convierte conocimiento tácito en propiedad intelectual acumulativa. Es lo que permite que el proyecto siguiente empiece más arriba.

Tres evaluaciones, no una

Aquí está la parte que un motor de reglas, por sí solo, no puede darte. Un resultado atraviesa tres filtros distintos, y sólo el primero es automático.

Filtro	Pregunta	Quién responde	Salida
Hard	¿Es válido?	máquina	cumple / no cumple
Soft	¿Es mejor?	comparación bajo criterios declarados	orden de preferencia
Juicio	¿Merece existir?	persona	decisión

Un sistema puede verificar que una propuesta usa componentes existentes, respeta el contrato, cabe en los metros disponibles y no viola ninguna política, y aun así producir algo mediocre. Tres formulaciones que deberían quedarse:

Cumplir no es ser bueno. Optimizar no es tener criterio. Generar no es diseñar.

Por eso el estudio publica también su métrica más incómoda: cuántas propuestas válidas rechaza una persona. Si ese número es siempre cero, probablemente se ha confundido validación con diseño.

Puntuar no es demostrar

Un comparador de escenarios es útil y honesto mientras no pretenda ser más de lo que es.

Escenario A        87 % de preferencias satisfechas
                   almacenaje alto · espacio social medio

Escenario B        92 % de preferencias satisfechas
                   almacenaje medio · espacio social alto

Decisión: B
Motivo: el cliente prioriza recibir invitados
        sobre almacenaje máximo.

Ese 92 % no es una medida científica de calidad. Es una comparación interna contra un conjunto de reglas declaradas. Dice qué preferencias satisface una opción según el sistema que hemos escrito, no si el lugar será bueno. Presentarlo de otro modo sería falsa objetividad, que es el riesgo intelectual más serio de todo este planteamiento: convertir «calma», «calidez» o «belleza» en números y creerse los números.

Por eso el corpus separa explícitamente hechos, normas, heurísticas y preferencias, y por eso cada pieza declara su procedencia.

Qué puede hacer aquí un agente

Tres cosas, y las tres son útiles: interpretar un brief y extraer de él restricciones; proponer alternativas dentro del catálogo; explicar por qué una opción cumple o falla.

Una cuarta cosa no debería poder hacer: declarar unilateralmente que su propia solución cumple las reglas. La verificación tiene que vivir fuera de quien propone. Una instrucción como «quiero dormitorios tranquilos, cálidos y con poco ruido visual» puede convertirse con ayuda de un modelo en una propuesta estructurada, pero esa propuesta debe hacerse visible y aceptarse a mano antes de entrar en el sistema:

Dormitorio en calma · v0.3   (propuesta del agente)

densidad visual      → baja
contraste            → bajo/medio
almacenaje expuesto  → bajo
privacidad           → alta

[Aceptar]  [Editar]

A partir de ahí trabaja el motor determinista con reglas versionadas. El principio, dicho corto: la IA puede proponer una regla; la IA no debería ser la regla.

La interfaz no dice sí o no

Un sistema honesto no tiene un botón verde grande que diga «CUMPLE». Tiene cinco estados, porque la realidad de un proyecto tiene cinco estados:

✓  cumple
!  requiere decisión
×  viola una restricción
?  información insuficiente
↺  excepción documentada

Los dos últimos son los que más se parecen a trabajar de verdad. Un sistema que no sabe decir «no tengo datos suficientes» acabará inventándolos, y un sistema que no sabe registrar una excepción obligará a la gente a saltárselo sin dejar rastro.

Y para un proyecto con implicaciones legales, el resumen honesto no es un sello de conformidad sino un reparto de responsabilidad:

REGLAS DE SISTEMA       21 / 21
REGLAS DE PROYECTO      14 / 15
REQUISITOS DE INFO       8 / 8
REVISIÓN NORMATIVA      requerida
FIRMA PROFESIONAL       pendiente

Eso convierte la incertidumbre en parte del sistema en lugar de esconderla. El desarrollo completo está en Límites.

Grafo de red mostrando nodos numerados interconectados con líneas, representando dependencias y genealogía de componentes. — № 061 Grafo de dependencias. Cada nodo es una pieza; cada arista, una decisión que arrastra a otra. Cuando se sustituye un material o se mueve un tabique, esto es lo que dice qué más se mueve con él. No es decorativo: es el mapa de impacto.

Qué se lleva de aquí al proyecto siguiente

Una decisión bien documentada produce, con el tiempo, una regla. Ése es el bucle que convierte un estudio en un sistema: el cliente paga por resolver su espacio, y el estudio conserva el aprendizaje generalizable. Las decisiones documentadas son la materia prima del Rulebook, no al revés.

Pero sólo una decisión que se repite en varios proyectos merece ascender a regla del sistema. Las demás se quedan donde nacieron, que es su sitio. Un núcleo pequeño con una capa local explícita envejece mucho mejor que un sistema que pretende haberlo previsto todo.

Revisión · Septiembre 2026 · Continúa en Estado 3 · Expresión