Tres decisiones que aplican a tu sistema
El detalle está abajo; esto es lo transferible aunque tu producto no se parezca en nada:
- El origen del dato es metadato de primera clase. Cada eje de la nota declara si es dato real o estimación por confirmar, y la confianza baja cuando depende de lo que no está en abierto. Tu design system agéntico necesita lo mismo: que cada valor diga de dónde viene.
- El sistema sabe para qué NO sirve. «Sirve para priorizar zonas y descartar, no para firmar» está escrito en el producto. Un límite declarado vale más que una promesa amplia: es lo que deja delegar sin miedo.
- El asistente que reconoce lo que no sabe. El RAG de /preguntar responde solo con datos verificados del índice, cita las zonas y admite sus huecos. La negativa codificada es una feature, no un fallo.
00. Aviso al lector
Este documento es un expediente breve: la lectura del sistema de habitalocal a fecha de agosto de 2026, apoyada en lo que el propio producto publica (su metodología, sus zonas, su asistente) y en su operación desde dentro. La lectura completa, con las decisiones de arquitectura y lo descartado, llegará tras la clase abierta del 10 de septiembre.
Sin caso de éxito. La pregunta del producto es modesta y afilada: ¿ese local puede ser vivienda? Lo interesante para este archivo es cómo responde sin mentir.
01. La decisión que cambia todo
Cada local recibe una nota que resume si la operación merece avanzar, observar con cautela o descartarse. Hasta aquí, un scoring como tantos. La decisión que lo separa del montón: cada eje declara su origen. El margen frente a obra se calcula con precio €/m² real (Idealista) e IPV del INE: dato. La viabilidad urbanística depende del PGOU concreto: estimación, «confírmalo en el ayuntamiento». El riesgo de estatutos: estimación, «requiere lectura legal».
La confianza de cada eje baja cuando depende de datos que no están en abierto. El sistema no esconde esa asimetría: la publica. Y remata con el límite de uso escrito en su metodología: sirve para priorizar y descartar, no para firmar.
Para un design system agéntico esta es la lección entera en miniatura: un agente puede consumir con seguridad un sistema que declara la calidad de cada dato; no puede consumir con seguridad uno que presenta igual lo medido y lo supuesto.
02. Los cinco filtros, en orden de mortalidad
La nota se compone de cinco factores, y el producto es explícito sobre cuál mata más operaciones:
- Viabilidad urbanística (PGOU, uso residencial en parcela y planta): «el filtro que más operaciones tumba». Estimado.
- Luz natural y ventilación (huecos a fachada o patio): sin luz no hay habitación legal. Estimado por tipología de zona.
- Ratio útil/construido: qué fracción queda como vivienda tras tabiques, instalaciones y patios. Estimado por tipología.
- Riesgo de estatutos: probabilidad de que la comunidad bloquee el cambio de uso. Estimado, requiere lectura legal.
- Margen frente a obra: precio de vivienda menos precio de local menos coste de obra. «El número que decide la rentabilidad». Dato real.
Nótese la estructura: los cuatro primeros filtran (pueden matar la operación), el quinto decide (la rentabilidad). Un pipeline de veredicto con roles distintos por regla, no una media difusa.
03. Madrid: cuando una estimación asciende a dato
El eje urbanístico nace como estimación en todas las ciudades. En Madrid ya no: el sistema cruza el censo de locales con 163.000 licencias urbanísticas concedidas desde 2015, las inspecciones y los datos de seguridad ciudadana para medir la fricción regulatoria barrio a barrio.
El patrón transferible: el sistema define el eje una vez y mejora su fuente ciudad a ciudad, sin cambiar el contrato. «El resto de ciudades llegará con el mismo método»: la regla es estable, la evidencia es incremental. Así se escala un sistema de veredictos sin reescribirlo.
04. El asistente acotado: /preguntar
El asistente de habitalocal lleva su contrato en la propia interfaz: «Responde solo con datos verificados del índice; cita las zonas y reconoce lo que no sabe». Es un RAG con refusal explícito: sin acceso al índice no hay respuesta, y la cita de zonas es parte del formato de salida, no cortesía.
Que el límite esté impreso encima del cajetín de la pregunta hace dos trabajos: gobierna las expectativas del humano y describe, con precisión técnica, el guardarraíl del agente. La misma frase sirve de copy y de especificación.
05. La familia: un motor, cuatro dominios
El pie del site lo declara: habitalocal es «un índice de Palmo a Palmo, inteligencia territorial española», junto a LORS (la costa puntuada), repueblo (qué pueblo repoblar) y La Vigencia (inteligencia regulatoria). Cuatro productos, un mismo esqueleto: catálogo estructurado, índice con metodología pública, ficha regular y asistente acotado.
Eso es un design system agéntico de productos, no de componentes: las reglas se construyen una vez y cada dominio nuevo hereda la maquinaria. El expediente de repueblo cuenta la otra mitad de esta historia: qué pasa cuando el motor se clona.
06. Lo que un DS lead se lleva de aquí
- Un campo
origen: dato | estimaciónen tus tokens y reglas vale más que cien páginas de documentación aspiracional. - Los límites de uso («no sirve para firmar») pertenecen al sistema, no al disclaimer legal. Escríbelos donde el consumidor decide.
- El refusal del asistente se especifica como formato de salida: qué cita, cuándo calla.
- Escala por evidencia, no por reescritura: contrato estable, fuentes que mejoran.