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 pequeña tienda de bicicletas en la esquina de su barrio. La empleada que la atiende no le pregunta, de entrada, 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 de funcionamiento de 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 uno de sus requisitos. 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 de esta parte, lo predominante era lo que ocurría: una venta, un viaje, una transferencia. El hecho mandaba. Una municipalidad introduce una tensión distinta. Aquí, lo que sucede no se sostiene sin la regla que le da pie. Una licencia de funcionamiento 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 de tránsito no se aplica al capricho del inspector: se aplica porque un artículo la habilita y el conductor cometió el supuesto que ese artículo describe. Una resolución no revoca una multa por gusto: la revoca porque un recurso ciudadano fue declarado fundado conforme al procedimiento.

En todos esos casos, el «porque» del Estado tiene dos caras al mismo tiempo: 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 poder responder por separado a dos preguntas que suenan iguales pero no lo son:

WQuestions separa esas dos caras con precisión quirúrgica, y lo hace con un reparto que ya conoces. Como argumentó el capítulo sobre el «por qué», no existe un eje «por qué»: el porqué se divide en cuatro cables distintos. Dos de ellos hacen aquí todo el trabajo: causado_por apunta a la causa fáctica, y 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 en el grafo.

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 de diseño que más se ejercitan aquí ya están todas sobre la mesa, enunciadas en capítulos previos. Vale la pena nombrarlas, porque este dominio las pone a trabajar juntas: D7, las dos relaciones del «por qué» operando en paralelo (una fáctica, una normativa); D4, cada acto administrativo reificado como una situación con identidad propia; D6, los estados de un expediente que cambian en el tiempo y se preservan; y D8, la política liberal del lexicon, que admite roles específicos del dominio sin tocar el catálogo canónico.

Las ordenanzas viven en el grafo

El punto de partida, y el más sorprendente para quien viene del mundo relacional, es este: una ordenanza no es un PDF guardado 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, exactamente 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, vinculado a su ordenanza y —esto es lo que vuelve la estructura interesante— capaz de habilitar trámites y exigir requisitos. El artículo 4 habilita la licencia de funcionamiento 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. Tenemos un artículo que habilita un trámite y que exige unos requisitos. Eso es ya, en germen, una cadena normativa. Y las cadenas, en este modelo, no se declaran en una tabla aparte: emergen 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 arista 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 establece 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 recursivamente. La pregunta «¿dónde queda exactamente el lote 19?» se responde siguiendo dentro_de hacia arriba: lote_19 → manzana_19 → barrio_lomas → distrito_norte → ciudad_capital, en un solo recorrido y sin un solo JOIN. Y, como veremos, el mismo lote es a la vez el lugar de la futura tienda y el tema de los trámites que la habilitan: una misma entidad territorial 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 administrativos encadenados, y cada uno (fiel a la idea de reificar lo que merece identidad propia) 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 tanto la solicitud como la inspección (porque motivado_por 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 redactar 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?» se resuelve con un único salto siguiendo justificado_por: el artículo 4. Y «¿qué motivó la emisión?» devuelve dos respuestas (la solicitud y la inspección) porque el cable es multi-valor. Dos preguntas distintas, dos cables distintos, dos respuestas limpias.

Mientras tanto, el estado de la solicitud cambia con el tiempo, y esos cambios se preservan en lugar de sobrescribirse, fieles a la regla de vigencia. La solicitud estuvo en_revision entre el 6 de marzo y el 6 de abril, y quedó aprobada desde entonces. Ambos hechos conviven, y la pregunta «¿en qué estado estaba la solicitud 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 reifica el hecho específico 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 realice para procesarla. La inspección de verificación que el inspector hace cuatro días después es parte_de el expediente; y si más tarde se suman citación, descargo y resolución, todas viven dentro del mismo expediente.

(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 entidad articuladora no es un patrón nuevo: es el mismo que reúne un viaje de taxi con sus etapas, o una transferencia bancaria con sus pasos. Una situación superior que junta todos sus actos secundarios. La pregunta «¿qué diligencias hubo en este expediente?» es una proyección directa 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, ocurre algo en la avenida. El conductor del furgón de reparto de la tienda, Iván Cardozo, estaciona en zona prohibida sobre la avenida del Parque un martes a las dos y media de la tarde. Tres minutos después, una inspectora de tránsito le aplica una multa de 320 dólares.

El modelo registra la cadena entera. La infracción se reifica como una situación con su tema (el furgón), su lugar, su momento y su tipo categórico. Y la multa se reifica como 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 es la forma del modelo que solo la cuádruple partición del «por qué» hace posible. 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 para hacerlo). Las dos afirmaciones son verdaderas a la vez y dicen cosas distintas. Visto como 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), lo que deja la multa sin efecto. La resolución es, como todo lo demás, una situación; lleva su propia justificación normativa (el artículo del procedimiento administrativo que faculta a resolver recursos) y dos consecuencias ocurren 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 al unísono. La resolución rectifica la multa (trazabilidad explícita: este acto modificó aquel acto), y el estado de la multa cambia a revocada desde el instante exacto de la resolución. Pero —y aquí está la promesa— la multa no se borra. Sigue en el grafo, sigue siendo consultable, sigue formando parte del historial de Iván. Lo único que cambió es su validez vigente. Gracias a la regla de vigencia, todavía podemos responder con exactitud: «¿estaba esa multa vigente el 1 de julio?» —sí— y «¿y el 10 de julio?» —no, ya revocada—.

Cómo se reconstruye un acto del Estado

Reunamos lo construido en una sola pregunta, la que de verdad le importa a un órgano de control: «Dame todo lo que sostiene esta multa.» Con los cables que ya tendimos, la respuesta es un puñado de saltos de grafo, 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 trabaja en 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 seguiremos a otro vecino, Juan (el mismo Juan cuya identidad resolvimos al hablar del principio de reconocer a una persona una sola vez), que abre su propio trámite de licencia para un taller de bicicletas en el lote contiguo.

El trámite de Juan es una entidad en O, un contenedor con identidad propia que nace el día que él 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) se reifica como una situación con cuatro datos que un sistema clásico suele dejar 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 tiene para resolverlo) y su fecha (cuándo ocurrió de verdad). Reificar cada paso (fiel a la idea de dar identidad propia a lo que merece ser interrogado después) 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 relación de composición que ya une un artículo con su ordenanza) y cada paso precede al siguiente, dibujando el orden temporal sin inventar tabla alguna. El resultado es, literalmente, una máquina de estados grabada en el grafo: una cadena que se puede recorrer hacia adelante para saber qué falta, o hacia atrás para reconstruir todo lo que ocurrió.

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_juan_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_juan_lic_04)
(paso_observacion_04, precede,  paso_subsanacion_04)   # M(O→O) · el orden
(paso_subsanacion_04, responsable, juan)               # Q · ahora la pelota es de Juan
(paso_subsanacion_04, plazo_dias,  5)                  # N · 5 días para subsanar

Repara en un detalle que cambia todo para la atención al vecino: cuando una observación se emite, el responsable del paso siguiente deja de ser una oficina y pasa a ser Juan. El grafo sabe, en todo momento, de quién es la pelota. La pregunta «¿qué trámites están esperando algo del ciudadano y cuáles esperan algo de la municipalidad?» deja de ser un reporte artesanal y se vuelve una proyección por el rol responsable del paso vigente.

De un trámite a la demora de todos

Recorrimos el trámite de Juan paso a paso. Pero al alcalde nadie le pregunta por tramite_juan_lic_04: le preguntan por la demora. Cuántos días, en promedio, tarda 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 de un 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. Es el segundo contenedor reificado del capítulo, y conviene no confundirlo con el trámite: el trámite es el procedimiento (la máquina de estados), mientras que 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 central de archivo.

El expediente de Juan es una entidad en O con un número de foja (su cita oficial), una oficina que lo custodia y una fecha de apertura. Todo lo demás cuelga de él por parte_de, exactamente la misma relación de composición que ya conocemos. La diferencia entre «un paso del trámite» y «un documento del expediente» no exige 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_juan_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» es la proyección de todo lo que es parte_de el expediente, ordenado por su cable momento. Y como nada se sobrescribe (fiel a la regla de vigencia), 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 Juan no lo procesa una sola oficina: la atención al vecino recibe la solicitud, la oficina de zonificación verifica el uso del suelo, la de rentas comprueba que no haya deudas, y la de 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 Juan 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 al mismo Juan (no cuatro registros parecidos, sino una única entidad en Q a la que todas apuntan), entonces el certificado de zonificación que Juan entregó en una oficina es, sin más trámite, visible para las otras. Es el principio de reconocer a una persona una sola vez, llevado del expediente clínico al mostrador municipal: la misma idea, otro dominio.

En tripletas, la diferencia es elocuente. El documento de zonificación es una sola entidad, parte_de el expediente de Juan, presentado_por Juan y verificado_por la oficina de zonificación. Cuando la oficina de licencias necesita ese documento, no lo vuelve a pedir: lo encuentra colgando del mismo Juan 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 : juan                         # Q · el MISMO juan 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 pero decisivo: el tiempo. La interoperabilidad no solo evita pedir dos veces lo mismo; también obliga a respetar plazos. Cada paso tiene su plazo_dias, y la ley administrativa establece que, si el plazo vence sin que la oficina responda, el silencio produce un efecto jurídico por sí mismo: en muchos procedimientos, silencio positivo (la solicitud se da por aprobada) y en otros, silencio negativo (se da por denegada, habilitando el recurso). Es el silencio administrativo.

Aquí brilla una idea que ya vimos al hablar de los estados derivados por reglas: un plazo que vence no necesita que nadie pulse un botón. La fecha límite es un dato en T, y una regla de vigencia compara esa fecha 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 que resume los seis pasos del trámite de Juan tal como el grafo los guarda: cada uno con su estado, su responsable (de quién es la pelota), 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 misma promesa del capítulo, llevada del acto aislado al procedimiento completo: nada se borra, todo deja rastro, y el ciudadano deja de ser el integrador. Juan ya no camina papeles entre islas; las oficinas se reconocen entre sí porque reconocen, una sola vez, al mismo Juan.

El lexicon municipal

Para que la empleada de la ventanilla no tenga que aprender jerga de bases de datos, configuramos el lexicon con las palabras del gobierno local. El lexicon es el compilador del que habló la Parte IV: traduce el vocabulario humano a los roles canónicos y resuelve la polisemia. Un dialecto municipal mapea las muchas maneras de nombrar a una persona (según el trámite, la misma persona es «vecino», «solicitante», «denunciante» o «infractor») a un único rol canónico.

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 esto, un funcionario puede escribirle al sistema «multa al furgón de reparto por estacionar en zona prohibida, según el artículo 7» y el grafo lo traduce a sus identificadores internos (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 ensamblan 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 que apunta al encabezado de la ordenanza, sin distinguir 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, tal como lo modeló este capítulo. Cada acto (solicitud, inspección, emisión, multa, resolución) es una situación reificada 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 recorrido de un solo 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. Esa promesa no es una funcionalidad 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 preserva como dos relaciones distintas, consultables por separado. La pregunta «¿por qué se aplicó esta multa?» tiene dos respuestas válidas según qué «porque» se pida, y el modelo distingue cuál es cuál. Repasemos lo que quedó probado.

Y la conclusión va más allá de una sola alcaldía. Las jerarquías territoriales en L, los expedientes que articulan múltiples diligencias y los recursos que rectifican actos sin borrarlos son patrones que 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, 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 un asunto de auditores sino de seguridad y de ley.