Estado 1 · Reglas

Un estudio de interiorismo convencional empieza dibujando. Recibe un brief, reúne referencias, propone una planta, la corrige, la documenta y la construye. El criterio existe —y a veces es excelente— pero vive en la cabeza de quien dibuja, se aplica de nuevo desde cero en cada encargo y desaparece cuando esa persona no está. El Estado 1 propone empezar antes: por escribir qué puede ocurrir.

Esto no convierte el interiorismo en una hoja de cálculo, y no significa que una máquina deba diseñar la casa. Significa retirar del diseñador las decisiones repetitivas o comprobables para reservar su atención a las que necesitan juicio. La frase que sostiene el estudio entero es ésta: no se sistematiza para que todos los espacios sean iguales; se sistematiza para no tener que reaprender las mismas buenas decisiones en cada proyecto.

Una regla no es un parámetro

Conviene separar cuatro cosas que se confunden a menudo, porque el diseño paramétrico lleva décadas ocupando este territorio y no es lo mismo.

Un parámetro dice cuánto. Un token da nombre estable a una decisión. Un componente encapsula decisiones relacionadas. Una regla determina cuándo son válidas.

La diferencia es que un parámetro optimiza y una regla delimita. El diseño generativo clásico busca la forma matemáticamente óptima bajo unas variables. Lo que aquí se persigue es otra cosa, más modesta y más difícil: hacer explícito el criterio con el que una práctica toma buenas decisiones, incluyendo los casos en los que la respuesta óptima no es la correcta.

Seis alcances: dónde actúa el criterio

El error más fácil sería escribir un reglas.yaml gigantesco donde todo convive al mismo nivel. Una regla debería vivir cerca de la decisión que gobierna, y declarar explícitamente sobre qué actúa.

Alcance	Pregunta que responde	En pantalla	En espacio
Token	¿Qué valores existen?	color.action.primary	acabado, especie de madera, temperatura lumínica
Componente	¿Qué puede hacer esta pieza?	Button	luminaria, puerta, módulo de almacenaje
Composición	¿Cómo se relacionan las piezas?	grupo de acciones	entrada + dejar + guardar
Flujo	¿Cómo se mueve una persona o una tarea?	confirmación de transferencia	llegar → dejar → cocinar → comer → descansar
Proyecto	¿Qué objetivo y restricciones gobiernan el conjunto?	producto financiero	vivienda de 45 m² con presupuesto cerrado
Contexto	¿Qué cambia por realidad externa?	usuario, riesgo, dispositivo	geometría, orientación, uso, habitantes, normativa

Hay una consecuencia práctica que este cuadro hace visible. La restricción «sólo puede haber una acción primaria en el mismo contexto de decisión» no pertenece realmente al botón: pertenece a su composición. El botón tiene la capacidad; la composición tiene la restricción. Meter reglas contextuales dentro de objetos que no poseen contexto suficiente para evaluarlas es una de las formas más comunes de construir un sistema que no puede razonar sobre sí mismo.

Lo mismo ocurre en materia. Un módulo de almacenaje sabe su profundidad y sus materiales admisibles. No sabe si invade el recorrido: eso lo sabe el patrón en el que se inserta.

Seis autoridades: quién puede cambiarla

Ésta es la parte que un design system digital casi nunca necesita y que en el espacio construido resulta obligatoria. No todas las reglas tienen la misma fuerza. Un sistema que no sepa cuál puede negociar es peligroso.

Autoridad	Ejemplo	¿Puede romperse?
Normativa	requisito aplicable de seguridad, accesibilidad o salubridad	No mediante criterio de diseño
Estándar	WCAG, IFC/IDS, un contrato de API	Sólo cambiando la conformidad declarada
Sistema	tipos de madera o encuentros admitidos	Mediante excepción gobernada
Proyecto	presupuesto máximo, elemento existente intocable	Sí, documentando el cambio
Experiencia	«desde la cama no debe dominar visualmente la cocina»	Sí; requiere juicio
Preferencia	lino antes que sintético cuando las prestaciones lo permitan	Sí

Una regla de proyecto no es un requisito normativo

Esto merece decirse sin rodeos, porque es el riesgo más caro de todo el planteamiento. Si un estudio publica sus reglas junto a requisitos legales sin distinguirlos, una recomendación propia acaba leyéndose como una comprobación de cumplimiento. No lo es.

Los valores normativos de dimensión, ventilación, accesibilidad o habitabilidad dependen de uso, tipo de intervención, territorio y versión de la norma. No deberían codificarse como conocimiento general del sistema: deberían cargarse de su jurisdicción con su fuente y su fecha, y conservar ambas. Y por encima de cualquier regla escrita aquí está el técnico legalmente responsable del proyecto. Lo que este corpus puede hacer es llegar antes y llegar mejor documentado. El alcance completo de esa frontera está en Límites.

Cinco severidades: qué pasa si no se cumple

• Hard — no puede incumplirse. El resultado se rechaza.
• Soft — aumenta o reduce calidad, pero puede sacrificarse.
• Policy — estándar interno del estudio o del cliente.
• Derivada — se calcula a partir de otras variables, no se escribe a mano.
• Excepción — incumplimiento consciente, documentado, con responsable y motivo.

La última categoría es la que distingue un sistema utilizable de uno que nadie usará. La arquitectura real está llena de excepciones razonables. El sistema no debe esconderlas ni fingir que no ocurrieron: debe convertirlas en decisiones explícitas con nombre y firma. Una regla que no admite excepción documentada acaba incumpliéndose en silencio, que es la única forma de incumplimiento que no deja aprendizaje.

Anatomía de una regla

Lo importante no es el formato. Es la estructura epistemológica: una regla tiene que poder explicar no sólo qué dice, sino por qué existe y quién puede cambiarla.

rule:
  id: entrance.storage.access
  version: 1.3

  alcance: composicion
  autoridad: experiencia
  severidad: soft

  intencion:
    "Que al llegar a casa se pueda soltar lo que se trae
     sin atravesar la zona privada."

  cuando:
    ocupacion: residencial

  exige:
    - "almacenaje de llegada alcanzable desde el umbral"

  prohibe:
    - "mueble fijo que bloquee el recorrido de acceso"

  prefiere:
    - "reducir superficie dedicada sólo a circular"

  excepcion:
    permitida: true
    exige_motivo: true

  verificacion:
    metodo: revision-geometrica
    evidencia: [planta, recorrido]

  reversibilidad: fixable

  procedencia:
    origen: brief-de-proyecto
    revisado: 2026-09-12

Léase en orden: intención → alcance → autoridad → condición → exige / prohíbe / prefiere → excepción → verificación → reversibilidad → procedencia. Una regla sin procedencia es una opinión con formato de norma. Escribir una preferencia en YAML no la convierte en una verdad.

⁂ Lámina pendiente /images/IMG_3960.JPG

Por dónde se empieza de verdad

No escribiendo cien reglas. Codificando hacia atrás un proyecto que ya existe, que es exactamente lo que hace el Caso 00 · Lo Peix: tomar lo construido y preguntarle qué decisiones se tomaron, qué alternativas se descartaron y por qué, qué fue local y qué merece repetirse.

El criterio de que una regla está bien escrita no es que suene rigurosa. Es éste:

¿Puede otra persona leer el sistema y producir una propuesta coherente sin preguntarte qué querías decir?

Si la respuesta es no, la regla todavía vive en tu cabeza y sólo ha cambiado de tipografía.

Revisión · Septiembre 2026 · Continúa en Estado 2 · Decisiones