Una municipalidad

Carla Ferreyra entra a la oficina de atención al vecino un lunes a las nueve y diez, con una carpeta bajo el brazo. Quiere abrir una tienda de bicicletas en la esquina de su barrio.

La empleada no le pregunta qué vende ni cuánto invierte. Le pide su documento, el plano del local y el certificado de zonificación.

¿Por qué esos tres papeles y no otros? Porque una ordenanza, la 142 de micromovilidad, exige que toda licencia para un comercio de vehículos livianos acredite esos requisitos.

Carla no lo sabe, pero acaba de tocar el primer eslabón de una cadena que va de una norma a un trámite, y de ese trámite a cada requisito. Reconstruir esa cadena, y poder responder años después bajo qué artículo se le pidió cada cosa, es el examen de este capítulo.

En los dominios anteriores mandaba lo que ocurría: una venta, un viaje, una transferencia. El hecho mandaba.

Una municipalidad trae otra tensión. Aquí lo que sucede no se sostiene sin la regla que le da pie.

Una licencia no se emite por voluntad de un funcionario. Se emite porque una ordenanza fija los requisitos y alguien verificó que se cumplían.

Una multa no se aplica al capricho del inspector. Se aplica porque un artículo la habilita y el conductor hizo lo que ese artículo describe. Y una resolución no revoca una multa por gusto: la revoca porque un recurso fue declarado fundado.

El «porque» del Estado tiene siempre dos caras a la vez. Una cara fáctica, qué ocurrió en el mundo, y una cara normativa, qué regla lo autoriza.

Un sistema municipal serio tiene que registrar las dos y responder por separado a dos preguntas que suenan iguales y no lo son:

WQuestions separa esas dos caras con un reparto que ya conoces. Como vimos al hablar del «por qué», no existe un eje «por qué»: el porqué se reparte en cuatro cables.

Dos hacen aquí todo el trabajo. causado_por apunta a la causa fáctica. justificado_por apunta a la norma.

Conviven sin pisarse. Y lo decisivo: permiten reconstruir cualquier acto del Estado hacia atrás, hasta su fundamento legal, con un par de saltos.

El barrio en siete coordenadas

El primer trabajo de quien modela un dominio es repartir sus entidades en las coordenadas correctas. Una municipalidad es generosa en variedad: tiene personas, papeles, territorio, fechas, montos y estados, y todos caben con naturalidad en los siete ejes.

Las decisiones que más se ejercitan aquí ya están todas sobre la mesa. Vale la pena nombrarlas, porque este dominio las pone a trabajar juntas.

D7: las dos relaciones del «por qué» funcionando en paralelo, una fáctica y una normativa. D4: cada acto administrativo con identidad propia. D6: los estados de un expediente cambian en el tiempo y se preservan. Y D8: el lexicon admite roles propios del dominio sin tocar el catálogo.

Las ordenanzas viven en el grafo

El punto de partida sorprende a quien viene del mundo relacional: una ordenanza no es un PDF en una carpeta. Es una entidad.

Vive en O con sus atributos (número, fecha de publicación, autoridad que la dictó, materia que regula), y sus artículos cuelgan de ella por parte_de. La misma relación que une una línea con su venta en el spa, o una pieza con su ensamblaje en un ERP.

Tomemos la ordenanza 142, sobre micromovilidad (scooters, bicicletas y comercios afines), que será nuestro hilo conductor. La municipalidad la dictó, fija una fecha de publicación y, como toda norma, entra en vigor más tarde: a los treinta días, tal como la propia ordenanza dispone.

(ordenanza_142) ∈ O
  instancia_de     : ordenanza_municipal       # K · qué clase de norma es
  numero           : 142                        # N · su número
  emitida_por      : municipalidad_lomas        # Q · qué agente la dictó
  materia          : micromovilidad             # K · sobre qué regula
  fecha_publicacion: 2026-02-10                 # T · cuándo se publicó
  entra_en_vigor   : 2026-03-12                 # T · a los 30 días
  estatus_factual  : vigente                    # K · su estado

Cada artículo es un objeto en O por derecho propio, atado a su ordenanza y, esto es lo interesante, capaz de habilitar trámites y exigir requisitos.

El artículo 4 habilita la licencia para comercios de vehículos livianos. El artículo 7 habilita la sanción por estacionar un vehículo de reparto en zona prohibida.

(art_4_ord_142, parte_de,      ordenanza_142)        # O→O · es parte de la norma
(art_4_ord_142, habilita,      tramite_licencia_micromov)  # qué trámite autoriza
(art_4_ord_142, exige,         requisito_zonificacion)     # qué requisito impone
(art_4_ord_142, exige,         requisito_plano_local)

(art_7_ord_142, parte_de,      ordenanza_142)
(art_7_ord_142, habilita,      sancion_estacionamiento)    # qué sanción autoriza
(art_7_ord_142, monto_base,    320)                        # N · multa, en USD

Fíjate en lo que acabamos de construir sin darnos cuenta. Un artículo que habilita un trámite y que exige unos requisitos. Eso ya es, en germen, una cadena normativa.

Y las cadenas, aquí, no se declaran en una tabla aparte. Salen de encadenar cables del eje M.

La cadena normativa

Aquí está el corazón del capítulo. Cuando Carla pide su licencia, la empleada no inventa los requisitos. Los lee de la cadena que va de la norma al trámite, y del trámite a cada requisito.

Esa cadena es un camino en el grafo, y cada flecha es un cable de M con su firma y su color de eje.

Conviene leer la misma estructura como una tripleta, que es como el modelo la guarda. El eslabón clave (el que ata el acto a la norma) se lee así:

El territorio, jerarquía de lugares

Antes de seguir los trámites de Carla hace falta ubicarlos. Una municipalidad gestiona territorio, y el territorio se anida: la ciudad contiene distritos, los distritos barrios, los barrios manzanas, las manzanas lotes.

Cada uno es un punto en L, y la jerarquía se arma con un rol de dominio, dentro_de:

(distrito_norte, dentro_de, ciudad_capital)    # L→L
(barrio_lomas,   dentro_de, distrito_norte)
(manzana_19,     dentro_de, barrio_lomas)
(lote_19,        dentro_de, manzana_19)         # aquí abrirá Carla su tienda

La cadena territorial se recorre subiendo. «¿Dónde queda exactamente el lote 19?» se responde siguiendo dentro_de hacia arriba: lote_19 → manzana_19 → barrio_lomas → distrito_norte → ciudad_capital. Un solo recorrido, ni un JOIN.

Y el mismo lote es a la vez el lugar de la futura tienda y el tema de los trámites que la habilitan. Una entidad territorial que se cruza con la cadena normativa.

El trámite, paso a paso, como situaciones encadenadas

Volvamos a Carla. Su licencia no es un instante. Es un proceso de tres actos encadenados, y cada uno es una situación en O con su agente, su momento, su lugar y su resultado.

1. Solicitud. Carla, en nombre de su comercio, solicita la licencia indicando el lote donde quiere operar.
2. Inspección. Un inspector municipal visita el local y certifica que cumple los requisitos que la norma exige.
3. Emisión. La municipalidad emite la licencia, válida por un año, fundada en el artículo.

Los tres actos se enlazan con cables del «por qué». La inspección está motivado_por la solicitud. La emisión está motivado_por la solicitud y la inspección, porque ese cable admite varios valores. Y la emisión cierra con el cable decisivo, justificado_por, apuntando a la norma.

En el prototipo, armar la emisión no exige escribir las tripletas a mano. Una llamada consulta el lexicon, desambigua el verbo, crea la situación y enchufa los cables validando cada uno.

licencia = ingest_situation(u, lex, "emitir",
    roles={
        "agente":         municipalidad_lomas,
        "tipo_emitido":   category("licencia_funcionamiento"),
        "beneficiario":   comercio_carla,
        "lugar_de":       lote_19,
        "momento":        at("2026-04-06T16:00"),
        "justificado_por": art_4_ord_142,        # ← la base legal
    },
    extra={
        "valido_desde": at("2026-04-10T00:00"),
        "valido_hasta": at("2027-04-09T23:59"),  # un año
    },
    sit_id="licencia_carla_07",
)
u.assert_fact(licencia, "motivado_por", solicitud_carla)   # multi-valor
u.assert_fact(licencia, "motivado_por", inspeccion_carla)

Lo notable es la nitidez con que el grafo responde dos preguntas que un sistema clásico mezcla.

«¿Bajo qué norma se emitió la licencia de Carla?» es un salto por justificado_por: el artículo 4. Y «¿qué motivó la emisión?» devuelve dos respuestas, la solicitud y la inspección, porque ese cable admite varias.

Dos preguntas distintas, dos cables distintos, dos respuestas limpias.

Mientras tanto, el estado de la solicitud cambia con el tiempo, y esos cambios se guardan en vez de pisarse.

La solicitud estuvo en_revision entre el 6 de marzo y el 6 de abril, y quedó aprobada desde entonces. Los dos hechos conviven, y «¿en qué estado estaba el 20 de marzo?» tiene una respuesta exacta.

(solicitud_carla, estatus_factual, en_revision)   ⟦2026-03-06 … 2026-04-06⟧
(solicitud_carla, estatus_factual, aprobada)      ⟦2026-04-06 … ∞⟧
# ↑ dos hechos vigentes en rangos distintos; ninguno borra al otro (D6)

Una denuncia abre un expediente

Pasa un mes. Bruno Salazar, vecino de la misma manzana, denuncia que la tienda de Carla recibe repartos a deshora y bloquea la vereda con cajas.

La denuncia es, otra vez, una situación. Tiene un agente (Bruno), un paciente (el comercio denunciado) y un tema que recoge el hecho concreto que se reporta: el bloqueo de la vereda.

denuncia = ingest_situation(u, lex, "denunciar",
    roles={
        "agente":   bruno,
        "tema":     hecho_bloqueo_vereda,     # el bloqueo reificado
        "paciente": comercio_carla,
        "lugar_de": lote_19,
        "momento":  at("2026-05-18T09:30"),
    },
    sit_id="denuncia_bruno_03",
)

La denuncia dispara un expediente administrativo, otra entidad en O, que agrupa por parte_de todas las diligencias que el municipio haga para procesarla.

La inspección que el inspector hace cuatro días después es parte_de el expediente. Y si luego se suman citación, descargo y resolución, todas viven dentro del mismo.

(expediente_2026_214) ∈ O
  instancia_de  : expediente_administrativo
  motivado_por  : denuncia_bruno_03           # nació de la denuncia

(insp_verificacion, parte_de, expediente_2026_214)   # una diligencia
(citacion_carla,    parte_de, expediente_2026_214)   # otra diligencia

El expediente como contenedor no es un patrón nuevo. Es el mismo que reúne un viaje de taxi con sus etapas, o una transferencia con sus pasos. Una situación superior que junta sus actos menores. «¿Qué diligencias hubo en este expediente?» es un salto por parte_de.

El caso paradigmático: la multa con doble «por qué»

Y ahora la escena que justifica el capítulo entero.

Mientras la denuncia sigue su curso, pasa algo en la avenida. Iván Cardozo, conductor del furgón de reparto de la tienda, estaciona en zona prohibida sobre la avenida del Parque un martes a las dos y media. Tres minutos después, una inspectora le aplica una multa de 320 dólares.

El modelo registra la cadena entera. La infracción es una situación con su tema (el furgón), su lugar, su momento y su tipo.

Y la multa es otra situación con su agente, su paciente, su monto y, esto es lo crucial, dos relaciones del «por qué» a la vez:

multa = ingest_situation(u, lex, "multar",
    roles={
        "agente":          inspectora_transito,
        "paciente":        ivan,
        "monto":           n(320, "USD"),
        "lugar_de":        av_del_parque,
        "momento":         at("2026-06-09T14:33"),
        "causado_por":     infraccion_furgon,    # ← CAUSA FÁCTICA  (D7)
        "justificado_por": art_7_ord_142,        # ← AUTORIDAD NORMATIVA (D7)
    },
    sit_id="multa_ivan_88",
)

Esta forma solo es posible porque el «por qué» está partido en cuatro.

La multa es causada por la infracción: sin el furgón mal estacionado no habría razón para sancionar. Y es justificada por el artículo 7: sin él, la inspectora no tendría base legal.

Las dos afirmaciones son ciertas a la vez y dicen cosas distintas. En tripletas, el doble fundamento se lee de un golpe:

(multa_ivan_88, causado_por,     infraccion_furgon)   # M(O→O) · el hecho
(multa_ivan_88, justificado_por, art_7_ord_142)       # M(O→O) · la norma
# ↑ mismo «por qué», dos cables: uno mira al mundo, otro mira a la ley

El recurso, y un acto que no se borra

Iván no está de acuerdo. Sostiene que la señalización de la zona estaba tapada por un árbol y no era visible. El 16 de junio presenta un recurso de reconsideración, que se modela como una situación nueva apuntando a la multa que impugna:

(recurso_ivan_01) ∈ O
  instancia_de : recurso_reconsideracion
  agente       : ivan                          # Q · quién recurre
  tema         : multa_ivan_88                 # O · la multa que impugna
  motivado_por : alegato_senalizacion          # por qué recurre
  momento      : 2026-06-16T11:00              # T

Tres semanas más tarde el alcalde resuelve. Declara el recurso fundado: la señalización, en efecto, no era visible. La multa queda sin efecto.

La resolución es, como todo lo demás, una situación. Lleva su propia justificación normativa (el artículo que faculta a resolver recursos) y trae dos consecuencias en paralelo:

resolucion = ingest_situation(u, lex, "resolver",
    roles={
        "agente":          alcalde_lomas,
        "tema":            recurso_ivan_01,
        "conclusion":      category("fundado"),
        "momento":         at("2026-07-07T17:00"),
        "justificado_por": art_15_proc_admin,   # base legal de la resolución
    },
    sit_id="resolucion_ivan_01",
)
u.assert_fact(resolucion, "rectifica", multa_ivan_88)        # trazabilidad
u.assert_fact(multa_ivan_88, "estatus_factual", u.ind("revocada"),
              valid_from=at("2026-07-07T17:00"))             # vigencia (D6)

Dos cosas pasan a la vez. La resolución rectifica la multa, dejando por escrito que este acto modificó aquel otro. Y el estado de la multa pasa a revocada desde el instante exacto de la resolución.

Pero la multa no se borra. Sigue en el grafo, sigue consultable, sigue en el historial de Iván. Lo único que cambió es su validez de hoy.

Por eso podemos seguir respondiendo con exactitud. «¿Estaba esa multa vigente el 1 de julio?» Sí. «¿Y el 10 de julio?» No, ya estaba revocada.

Esta es la diferencia práctica entre un grafo de hechos y una tabla que se sobrescribe.

En la tabla, cuando la multa se revoca alguien actualiza la fila (estado = 'revocada') y la verdad anterior desaparece. Si meses después un tribunal pregunta qué decía esa multa el día en que se aplicó, la respuesta honesta es «ya no se sabe».

En WQuestions los dos hechos conviven con sus rangos de vigencia. El acto original queda intacto, con su monto, su fundamento y su fecha. El acto que lo revoca también. La auditoría no desentierra un fósil: lee un registro que nunca se mutiló.

Cómo se reconstruye un acto del Estado

Reunamos todo en una sola pregunta, la que de verdad importa a un órgano de control: «dame todo lo que sostiene esta multa». Con los cables que ya tendimos, la respuesta son unos pocos saltos, no un proyecto de minería de datos.

El trámite de punta a punta, como máquina de estados

Hasta aquí miramos el trámite de Carla por fuera: tres actos enlazados y una licencia al final. Pero quien atiende la ventanilla lo vive por dentro.

Y por dentro un trámite no es un acto. Es una secuencia de situaciones encadenadas que avanza paso a paso, a veces retrocede y solo a veces llega.

Para verlo de cerca seguimos a otra vecina, María Gonzales, la misma cuya identidad resolvimos al hablar de reconocer a una persona una sola vez. María abre su propio trámite de licencia para un taller de bicicletas en el lote contiguo.

El trámite de María es una entidad en O, un contenedor que nace el día que ella presenta su solicitud. Pero lo interesante no es el contenedor. Son sus pasos.

Cada paso (solicitud, revisión de requisitos, observación, subsanación, aprobación, emisión) es una situación con cuatro datos que un sistema clásico deja implícitos o repartidos. Su estado, en qué punto está. Su responsable, qué agente lo tiene en la mano. Su plazo, cuántos días hay para resolverlo. Y su fecha, cuándo ocurrió de verdad.

Darle identidad propia a cada paso es lo que vuelve el trámite auditable minuto a minuto.

Los pasos no flotan sueltos. Dos cables del eje M les dan estructura. Cada paso es parte_de el trámite, la misma relación que une un artículo con su ordenanza. Y cada paso precede al siguiente, dibujando el orden sin inventar ninguna tabla.

El resultado es una máquina de estados grabada en el grafo. Una cadena que se recorre hacia adelante para saber qué falta, o hacia atrás para reconstruir lo que pasó.

Veamos dos pasos como tripletas, para fijar la forma. La revisión es parte_de el trámite, la observación precede a la subsanación, y cada una carga su responsable, su plazo y su fecha sin aplastarlos en un comentario:

(paso_revision_04) ∈ O
  instancia_de   : paso_tramite
  parte_de       : tramite_maria_lic_04        # O→O · pertenece al trámite
  responsable    : oficina_licencias          # Q · quién lo tiene en la mano
  plazo_dias     : 10                          # N · días para resolver
  momento        : 2026-04-22T09:00            # T · cuándo se inició
  estatus_factual: en_revision                 # K · su estado

(paso_observacion_04, parte_de, tramite_maria_lic_04)
(paso_observacion_04, precede,  paso_subsanacion_04)   # M(O→O) · el orden
(paso_subsanacion_04, responsable, maria_g)               # Q · ahora la pelota es de María
(paso_subsanacion_04, plazo_dias,  5)                  # N · 5 días para subsanar

Fíjate en un detalle que lo cambia todo para la atención al vecino. Cuando se emite una observación, el responsable del paso siguiente deja de ser una oficina y pasa a ser María. El grafo sabe en todo momento de quién es la pelota.

Y «¿qué trámites esperan algo del ciudadano y cuáles esperan algo de la municipalidad?» deja de ser un reporte artesanal. Es una proyección por el responsable del paso vigente.

De un trámite a la demora de todos

Recorrimos el trámite de María paso a paso. Pero al alcalde nadie le pregunta por tramite_maria_lic_04. Le preguntan por la demora.

Cuántos días tarda de media una licencia de micromovilidad desde la solicitud hasta la emisión. Qué paso es el cuello de botella. Si el «una sola vez» de verdad recortó los tiempos este año.

Cada trámite ya cargó su momento de inicio y su fecha de cierre, paso por paso. El indicador de gestión es promediar esa diferencia sobre todos los trámites del mismo tipo.

# Días promedio de resolución de un tipo de trámite ya emitido — el SLA se mira por tipo
promedio(u, "dias_resolucion", Pattern(fixed={"estatus_factual": u.ind("emitida")},
                                       type_constraint=u.ind("tramite_licencia_micromov")))

El expediente, contenedor que todo lo agrupa

El trámite encadena los pasos. El expediente los guarda.

Conviene no confundirlos. El trámite es el procedimiento, la máquina de estados. El expediente es el legajo: la carpeta única, citable y foliada que reúne todo lo que el procedimiento generó. Cada paso, sí, pero también cada documento, cada notificación y cada dictamen.

Ya vimos un expediente nacer de una denuncia. Aquí lo miramos como pieza de archivo.

El expediente de María es una entidad en O con su número de foja, la oficina que lo custodia y su fecha de apertura. Todo lo demás cuelga de él por parte_de, la misma relación de siempre.

La diferencia entre «un paso del trámite» y «un documento del expediente» no pide cables nuevos. Basta la clase de cada pieza en K.

(expediente_2026_337) ∈ O
  instancia_de  : expediente_administrativo
  numero_foja   : "2026-337"                   # su cita oficial, citable
  custodiado_por: oficina_licencias            # Q · qué oficina lo guarda
  abierto_el    : 2026-04-20                    # T
  agrupa_a      : tramite_maria_lic_04          # O→O · el procedimiento que contiene

# todo cuelga del mismo expediente por parte_de — pasos y documentos juntos:
(paso_revision_04,    parte_de, expediente_2026_337)   # una situación
(paso_observacion_04, parte_de, expediente_2026_337)   # otra situación
(doc_plano_local,     parte_de, expediente_2026_337)   # un documento
(doc_cert_zonif,      parte_de, expediente_2026_337)   # otro documento
(notif_observacion,   parte_de, expediente_2026_337)   # una notificación

La auditoría que antes era un proyecto se vuelve una pregunta. «Dame el expediente completo, en orden» trae todo lo que es parte_de el expediente, ordenado por su cable momento.

Y como nada se sobrescribe, el legajo que se lee hoy es el mismo que existió en cada instante del pasado. El expediente no es una foto del estado actual. Es la película entera.

# El expediente entero, foliado y en orden cronológico: una proyección.
piezas = u.project(parte_de=expediente_2026_337)        # pasos + documentos + notificaciones
legajo = sorted(piezas, key=lambda p: u.get(p, "momento"))
# → cada pieza con su clase (K), su autor (Q) y su fecha (T). Nada quedó fuera.

Interoperabilidad entre oficinas y el principio «una sola vez»

Llegamos al problema que de verdad sufre el ciudadano.

El trámite de María no lo procesa una sola oficina. Atención al vecino recibe la solicitud, zonificación verifica el uso del suelo, rentas comprueba que no haya deudas, licencias decide.

En casi todos los municipios reales, cada oficina es una isla con su propia base de datos. Y el pegamento que las une es el ciudadano.

Es María quien lleva el certificado de zonificación de una ventanilla a otra. Quien vuelve a presentar su documento en cada oficina. Quien pide la constancia de no adeudo y la camina por el pasillo.

El ciudadano es el integrador. Y es un integrador caro, lento y falible.

Ese principio no se sostiene con buena voluntad. Se sostiene sobre la identidad resuelta.

Si las cuatro oficinas reconocen a la misma María (no cuatro registros parecidos, sino una sola entidad en Q a la que todas apuntan), el certificado de zonificación que ella entregó en una oficina queda visible para las otras sin más trámite.

Es reconocer a una persona una sola vez, llevado del expediente clínico al mostrador municipal. La misma idea, otro dominio.

En tripletas la diferencia se ve. El documento de zonificación es una sola entidad: parte_de el expediente de María, presentado_por María, verificado_por la oficina de zonificación.

Cuando licencias necesita ese documento, no lo vuelve a pedir. Lo encuentra colgando de la misma María y del mismo expediente. La identidad compartida en Q es el eje sobre el que gira todo.

(doc_cert_zonif) ∈ O
  instancia_de   : certificado_zonificacion
  presentado_por : maria_g                         # Q · la MISMA maria_g que todas ven
  verificado_por : oficina_zonificacion         # Q · quién lo dio por bueno
  parte_de       : expediente_2026_337          # O→O · vive en el expediente
  vigente_hasta  : 2027-04-19                    # T · su caducidad

# La oficina de licencias NO vuelve a pedirlo: lo consulta donde ya está.
(paso_revision_04, usa_documento, doc_cert_zonif)   # M(O→O) · lo reutiliza

Falta un actor invisible y decisivo: el tiempo. Coordinarse no solo evita pedir dos veces lo mismo. También obliga a respetar plazos.

Cada paso tiene su plazo_dias. Y la ley administrativa dice que si el plazo vence sin que la oficina responda, el silencio produce por sí mismo un efecto jurídico. En muchos procedimientos, silencio positivo: la solicitud se da por aprobada. En otros, silencio negativo: se da por denegada y se habilita el recurso.

Es el silencio administrativo.

Aquí brilla una idea que ya vimos con los estados derivados de reglas: un plazo que vence no necesita que nadie pulse un botón.

La fecha límite es un dato en T. Una regla la compara con el reloj y, al cruzarla, hace nacer un estado nuevo. El tiempo deja de ser un valor pasivo y se vuelve un agente: dispara hechos.

(paso_revision_04, vence_el, 2026-05-02T23:59)        # T · derivado de fecha + plazo

# Si el reloj cruza vence_el sin resolución, una regla hace nacer el estado:
(paso_revision_04, estatus_factual, vencido_por_silencio)  ⟦2026-05-03 … ∞⟧
(paso_revision_04, efecto_silencio, aprobacion_tacita)     # K · el efecto jurídico
# ↑ ningún funcionario lo tecleó: lo disparó el vencimiento del plazo (regla de vigencia)

Cerremos el círculo con una tabla de los seis pasos del trámite de María, tal como el grafo los guarda: cada uno con su estado, su responsable, su plazo y su fecha.

No hace falta más para reconstruir el procedimiento entero, ni para saber en cualquier instante qué está esperando y a quién le toca actuar.

Es la promesa del capítulo llevada del acto suelto al procedimiento completo. Nada se borra, todo deja rastro, y el ciudadano deja de ser el integrador.

María ya no camina papeles entre islas. Las oficinas se entienden entre sí porque reconocen, una sola vez, a la misma María.

El lexicon municipal

Para que la empleada de la ventanilla no tenga que aprender jerga de bases de datos, cargamos el lexicon con las palabras del gobierno local.

El lexicon es el traductor del que habló la Parte IV: pasa el vocabulario humano a los roles del catálogo y decide qué significa cada palabra según su compañía.

Un dialecto municipal recoge las muchas formas de nombrar a una persona. Según el trámite, la misma es «vecino», «solicitante», «denunciante» o «infractor». Todas apuntan a un solo rol.

lex.register_domain_dialect("municipalidad_lomas", {
    "vecino":       "agente",        # quien denuncia o consulta
    "solicitante":  "agente",        # quien pide una licencia
    "denunciante":  "agente",        # quien presenta una denuncia
    "infractor":    "paciente",      # quien recibe la sanción
    "ordenanza":    "ordenanza_municipal",
    "papeleta":     "sancion_transito",
    "expediente":   "expediente_administrativo",
})

Gracias a eso, un funcionario puede escribir «multa al furgón de reparto por estacionar en zona prohibida, según el artículo 7». El grafo lo traduce a sus identificadores, con su causado_por y su justificado_por en su sitio, sin que nadie en la oficina sepa que esas etiquetas existen.

El antes y el después

Antes, en SQL. Un esquema municipal típico reparte la información en tablas como tramites, pasos_tramite, ordenanzas, multas y ciudadanos. Se juntan con JOIN.

Pero hay una pregunta que el esquema casi nunca modela: ¿qué norma autoriza cada paso?

El vínculo normativo, si existe, vive en una columna observaciones de texto libre, o en una clave foránea al encabezado de la ordenanza, sin decir qué artículo concreto habilita la acción.

Cuando el auditor pregunta bajo qué artículo se declaró fundado un recurso, hay que rastrear código, leer comentarios y cruzar a mano tablas que nunca se diseñaron para responder eso juntas.

-- Antes: la multa guarda el «motivo» como texto, y la ordenanza
-- como una FK al encabezado. El artículo exacto se pierde.
CREATE TABLE multas (
  id        INTEGER PRIMARY KEY,
  infractor INT,
  monto     NUMERIC,
  motivo    TEXT,             -- «estacionar en zona prohibida, art.7» (¡texto!)
  ordenanza_id INT            -- apunta al encabezado, no al artículo
);
-- «¿Bajo qué artículo se aplicó?»  →  no hay columna que lo responda.
-- «¿Qué la causó, separado de su fundamento legal?»  →  ambos viven en 'motivo'.

Después, en WQuestions. La misma información es un solo grafo de hechos. Cada acto (solicitud, inspección, emisión, multa, resolución) es una situación que lleva sus propios cables del «por qué»: causado_por a la causa fáctica, justificado_por al artículo que lo habilita.

La trazabilidad normativa no es código a mano ni un JOIN extra. Es un salto.

Cualquier auditor, tribunal o periodista responde «¿qué norma autorizó este acto?» con la misma consulta que responde «¿quién lo ejecutó?» y «¿cuándo?».

En un gobierno local, ningún acto se borra. Cada uno deja rastro de su causa, su fundamento legal, su resultado y su eventual revocación. Eso no es una función añadida: es lo que queda cuando dejas de sobrescribir filas y empiezas a acumular hechos.La lección de la municipalidad

El veredicto del dominio público

El dominio municipal pone a trabajar D7 en su forma más exigente. Cada acto del Estado tiene un fundamento factual y uno normativo, y el modelo los guarda como dos relaciones distintas.

«¿Por qué se aplicó esta multa?» tiene dos respuestas válidas según qué «porque» se pida, y el modelo sabe cuál es cuál. Repasemos lo que quedó probado.

Y la conclusión va más allá de una alcaldía. Las jerarquías territoriales en L, los expedientes que juntan varias diligencias y los recursos que rectifican actos sin borrarlos reaparecen en todo el sector público: sanitario, judicial, tributario, ambiental.

Lo que probamos aquí no es solo que el modelo absorbe una municipalidad. Es que una familia entera de aplicaciones de gobierno encaja con el mismo motor, sin extensiones y sin proyectos de integración entre módulos que nunca se diseñaron para hablarse.

El gobierno local nos exigió tomarnos en serio el «por qué». El próximo dominio nos exigirá tomarnos en serio el mundo físico.

Una operación minera, donde las magnitudes se miden en toneladas y leyes de mineral, los sensores son agentes que reportan sin descanso, y la trazabilidad ya no es cosa de auditores sino de seguridad y de ley.