Reference behaviour checklist (Bizagi Modeler public docs)

Fuente: LILA_MODELER_ESTRUCTURA.md, sección 3 ("Checklist de paridad con Bizagi"; ahí «paridad» es el criterio interno de aceptación, no el posicionamiento público). Esta tabla es una copia de esa sección con una columna Estado añadida para seguimiento de implementación; el contenido de las columnas Capacidad/Bizagi/Lila/Hito es el mismo que en el documento de estructura, que sigue siendo la fuente de verdad — ante cualquier discrepancia entre este archivo y LILA_MODELER_ESTRUCTURA.md, gana el documento de estructura y este archivo se corrige para reflejarlo, nunca al revés.

Fuente de la comparación original: ayuda oficial de Bizagi (niveles 1–4, escenarios, elementos no soportados), verificada el 2026-09-03. Bizagi no expone "4 niveles" en el motor: son qué parámetros están rellenos. Lila no reproduce los niveles como concepto de producto; el motor degrada: sin recursos ⇒ capacidad infinita, sin calendario ⇒ 24×7. Bizagi Modeler se cita aquí solo como referencia técnica e inspiración: este documento no plantea paridad de producto ni una alternativa comercial, solo un criterio interno de validación numérica (#289).

Estado refleja el estado de implementación en el repositorio, no el de este documento. Se actualiza fila por fila conforme cada capacidad queda implementada y probada (ver la prueba de aceptación del hito correspondiente en la sección 7 de LILA_MODELER_ESTRUCTURA.md), y lleva entre paréntesis los tickets que la cierran.

El comportamiento de referencia numérico, es decir la validación contra las corridas publicadas por Bizagi Modeler, se comprueba en packages/engine/test/bizagi-parity.test.ts (LILA-044), que simula los cuatro ejemplos de examples/bizagi-levels y compara cada número que expected.json cita de la página oficial con tolerancia ±5 %. Lo que hoy no cuadra está en la sección Diferencias documentadas del final, con su causa y su número: ninguna de esas diferencias se ha cerrado ajustando un parámetro del escenario publicado.

Este archivo es una referencia técnica interna y conserva su nombre histórico (BIZAGI_PARITY.md, bizagi-parity.test.ts) por continuidad con el código y los tickets que lo citan; no implica una promesa pública de paridad con Bizagi Modeler.

Diferencias documentadas (LILA-044, corregidas en LILA-187)

packages/engine/test/bizagi-parity.test.ts simula examples/bizagi-levels/level-{1..4} tal cual están committeados y compara, con tolerancia ±5 %, cada número que su expected.json cita de la página oficial. Hasta LILA-187 el test tenía dos mitades —las réplicas publicadas, que no cuadraban, y la misma comparación sobre un fixture aparte con la topología del diagrama oficial— porque LILA-044 tenía prohibido tocar los ejemplos. LILA-187 llevó esa topología, las probabilidades del gateway y las llegadas constantes a los propios model.bpmn y scenario.json, así que la segunda mitad y su fixture desaparecieron: hoy hay una sola tabla.

Cada fila del test asegura de qué lado de la tolerancia está su número. Si una fila cambia de lado, el test se pone rojo y hay que actualizar el test y esta sección a la vez.

Resultado

Medido con 30 replicaciones en el test (los scenario.json publicados siguen en 1: las replicaciones son una técnica de medición del test, no un parámetro de los ejemplos).

Los niveles 1, 2 y 3 cuadran dentro del ±5 % salvo tres residuos documentados: D2 (nivel 1, rama Yellow contra la corrida única de Bizagi) y D5 y D6 (nivel 3). El nivel 4 cuadra desde LILA-164 en ciclo, utilización y costo de los seis recursos; le quedan dos residuos: las dos esperas de Arrive at patient place BA y —para las utilizaciones— la conversión de denominador, las dos mitades de lo que hoy es D7. Las diferencias vivas hoy son, por tanto, D2, D5, D6 y D7; D1, D3, D4 y D8 quedaron resueltas en LILA-186/187.

Las utilizaciones del nivel 4 son las convertidas al denominador de Bizagi. Sin convertir, Lila publica sobre su ventana de medida [warmup, t_stop] = 10 862 min: 44,75 % · 64,82 % · 46,18 % · 29,79 % · 22,24 % · 27,36 %, en el mismo orden. Son los mismos segundos ocupados divididos por otro denominador; la fórmula está en D7.

Causas

D1 — triggerCount sin interTriggerTimer (resuelta en LILA-186). Era un hueco del contrato de Lila, no un desajuste con Bizagi: R-ARR-1 solo generaba casos en un start con interTriggerTimer, así que el nivel 1 (max arrival count 1000 y ningún campo de tiempo, porque el nivel 1 no los habilita) salía con cero llegadas y el aviso W-START-SIN-LLEGADAS. R-ARR-1 dice ahora que triggerCount sin interTriggerTimer equivale al default constant 0, es decir N llegadas en t = 0, que es lo que hace Bizagi. El aviso queda para el start que no declara ninguno de los dos campos.

D2 — la rama del 30 % contra una corrida única de Bizagi. Los tres conteos publicados (483 + 315 + 202) son una sola corrida de 1000 tokens; el 315 se desvía por sí mismo un +5 % de su propia probabilidad configurada (30 %). Contra 1000 × p, que es lo que de verdad valida el nivel 1, las tres ramas cuadran (−0,23 %, −0,63 %, +1,52 %). Anotado además: level-1/expected.json etiquetaba los tres conteos como green/yellow/red al revés (corregido en LILA-187). La prosa de la página solo da la suma «(483+315+202)», pero la tabla de resultados que la acompaña (processvalidation42.png) los publica fila por fila: «Red Triage end 483 · Yellow Triage end 315 · Green Triage end 202». La corrida rota (processvalidation43.png) confirma la lectura: «Red Triage end 1006 · Yellow Triage end 311 · Green Triage end 186», y el 1006 solo puede ser la rama del Parallel Gateway sin convergencia.

D3 — la topología reconstruida de los niveles 2–4 no era la del diagrama oficial (resuelta en LILA-187). examples/bizagi-levels/level-{2,3,4}/model.bpmn reconstruía el «Emergency attendance process» como siete tareas en secuencia con un XOR de vehículo al final. El diagrama de la página (simulationexample2.png, el mismo proceso en los cuatro niveles), que es el que reproducen hoy los cuatro model.bpmn, es:

Recieve Emergency Report (4 min) → Classify Triage (5 min) → XOR "Triage type"
  ├ Red    50 % → AND ( Manage patient entry 11 min ‖ Pick up patient 20 min ) → Authorize Entry 4 min → fin
  ├ Yellow 30 % → Arrive at patient place QAV  7 min → fin
  └ Green  20 % → Arrive at patient place BA  10 min → fin

Consecuencias medidas: con la secuencia hay un solo camino de 51–54 min (contra 16 / 33 / 25 min publicados) y la enfermera consume 16 min por caso en vez de 10,5 (5 min siempre + 11 min solo en el 50 % Red), o sea 3,2 enfermeras de carga contra 2,1 — por eso satura al 99,9 % con tres, cuando Bizagi publica 69,75 %. Con la topología oficial los tres números del nivel 2 salen exactos y la utilización de los seis recursos del nivel 3 cuadra dentro del 4 %. Era una errata de la réplica (LILA-010), no del motor: LILA-187 la corrigió en model.bpmn y añadió al escenario las probabilidades del gateway Triage type publicadas en prosa en level_1_example.htm.

D4 — llegadas constantes y drenado (resuelta en LILA-187). La corrida publicada (processvalidation47.png) trae exactamente 2017 instancias iniciadas y 2017 completadas (10080 / 5 + 1), con Duration 030,00:00:00 en la cabecera del informe: 30 días de reloj para una semana de llegadas, o sea que Bizagi dejó drenar la corrida: imposible con un Poisson de media 5 min, y prueba de que el ejemplo usó el control de intervalo constante de 5 min, no la distribución exponencial que declara el escenario publicado. Además Bizagi drena la corrida (0 casos en vuelo) mientras el escenario publicado corta a la semana y deja casos en vuelo que, por LILA-036, no entran en las medias. Con interTriggerTimer constante de 300 s, triggerCount 2017 y sin duration (R-ARR-3: la corrida acaba al vaciarse el heap) —que es lo que declaran hoy los scenario.json de los niveles 2, 3 y 4— Lila reproduce las 2017 instancias y el denominador de utilización de Bizagi: callCenterAgent sale 39,91 % contra 39,91 % publicado.

D5 — el máximo del nivel 3 con 3 enfermeras (−5,3 %). Bizagi publica 35 min = los 33 min del camino Red más 2 min de espera de enfermera que en su corrida cayeron en el camino crítico. En la nuestra la espera máxima de Classify Triage es de segundos y el máximo se queda en los 33 min del camino puro. Es la cola de la distribución de un único máximo, no una diferencia de definición: la media cuadra al 0,74 % y la utilización al 0,14 %.

D6 — el caso saturado del nivel 3 (2 enfermeras), media +23,5 %. Con 2 enfermeras el sistema está por encima de su capacidad (ρ ≈ 1,05) y la cola crece durante toda la corrida, así que la media depende de la forma del transitorio, no del estado estacionario. Mínimo (+0,4 %), máximo (+1,3 %) y utilización (−0,13 %) cuadran; la media no, porque en Bizagi la razón media/máximo de la espera vale 0,40 y en Lila 0,49 — es decir, la cola de Bizagi crece sublinealmente y la de Lila linealmente, que es lo que produce una acumulación de trabajo constante desde t = 0. Sin la corrida original de Bizagi no se puede ir más allá; queda como el único residuo del nivel 3.

D7 — el nivel 4: resuelta la capacidad por turno (LILA-164), vivo el denominador de la utilización. Bizagi hace variar la plantilla por turno (2 / 2 / 1 agentes de call center, etc.) sin que el recurso deje de existir: los tres turnos cubren las 24 h y no hay tiempo cerrado.

Lo que cerró LILA-164. Hasta entonces SCENARIO_FORMAT.md v1 no admitía eso y la réplica lo modelaba con tres pools —uno por turno, cada uno con su calendar— seleccionados con selection: "or". El efecto colateral estaba medido: el calendario efectivo de la tarea pasaba a ser el del turno concedido (R-CAL-4), el trabajo se pausaba al cerrar el turno y aparecía una offHoursWait de 59,7 min por caso que bajo la semántica de Bizagi tiene que ser 0; el ciclo medio salía a 84,4 min (+232 %), y la utilización y el costo se publicaban por turno en vez de por rol. R-CAL-11 (resources[pool].capacity: [{ calendar, capacity }], docs/SEMANTICS.md § 12) es un solo pool por rol con la tabla «Resource | Morning shift | Day shift | Night shift» de la página tramo a tramo, y con ella:

• offHoursWait = 0 en las cuatro tareas con recurso por turno (la unión de los tres turnos es un 24×7): era el desvío entero;
• ciclo medio 1521,5 s contra los 1526 s publicados (−0,30 %);
• utilización y costo se reportan por rol, seis filas, las de Bizagi, y los doce números caen dentro del ±5 % (peor caso −2,60 %, Quick Attention Vehicle);
• Arrive at patient place BA vuelve a hacer cola (máx 970 s) porque la capacidad baja a 1 en el turno de tarde; con la capacidad fija del nivel 3 era exactamente 0.

Lo que sigue vivo: el denominador. En el nivel 4 Bizagi divide por la duración declarada del escenario (43 200 min = los 30 días del campo Duration del informe), no por el instante de fin de corrida (≈ 10 862 min) que sí usa en el nivel 3 y que es lo que fija R-CAL-9. Son 4,0× de diferencia. Es una decisión de contrato, no un bug, y Lila no cambia de denominador: mantiene [warmup, t_stop], que es la ventana en la que de verdad midió. La conversión es exacta sobre busyTime:

util_bizagi = busyTime / Σᵢ (capacityᵢ × openTimeᵢ sobre la duración declarada)
            = util_lila × ventana_lila / duración_declarada

y con los tres turnos de 8 h ese sumatorio vale (Σᵢ capacityᵢ / 3) × 43 200 min, que es literalmente la cuenta publicada: Call center agent 8068 min / ((2+2+1)/3 × 43 200 min) = 11,21 %, exacta al segundo decimal en los seis recursos contra calendaranalysis2.png.

Aplicada, las seis filas cuadran holgadamente (la tabla de arriba): −0,04 % · +0,54 % · +1,06 % · −2,60 % · +1,33 % · +0,98 %. La segunda forma —la regla de tres util_lila × ventana / duración declarada— es la versión de bolsillo y solo coincide del todo cuando la ventana cubre un número entero de periodos del patrón de turnos; aquí no lo cubre (la corrida se agota a los 10 862 min, 7,54 días) y el sesgo del corte a media franja llega al 1,8 % en quickAttentionVehicle, el rol cuyo turno de tarde vale el doble que los otros dos. El test comprueba las dos y acota esa diferencia al 3 %: es el error de la regla de tres, no del motor.

Residuo: las dos esperas de Arrive at patient place BA. Máximo 970 s contra 900 s publicados (+7,8 %) y media 33,5 s contra 44,4 s (−24,5 %). Son de una corrida única de Bizagi sobre un pool al 5,6 % de utilización, donde solo hay cola cuando dos casos coinciden en el turno de tarde (una sola ambulancia básica); el reparto por rama de esa corrida tampoco es el nuestro (Bizagi 403 instancias BA, Lila 409). Es ruido de la corrida de referencia, del mismo tipo que D2, y no se relaja la tolerancia por él.

Nota de mapeo (corregida en LILA-187). expected.json llamaba waitTimeSeconds a lo que la tabla de Bizagi titula «Min./Max./Avg. time» del proceso. Esa columna es tiempo de ciclo (procesamiento + espera), y su equivalente en Lila es process.cycleTime, no process.waitTime (que es solo resourceWait + offHoursWait y en el nivel 2, sin recursos, vale 0 por R-DEG-1). El campo se llama hoy cycleTimeSeconds en los cuatro expected.json.

D8 — los dos vehículos están cruzados en la tabla de requerimientos de la página (resuelta en LILA-187). La tabla «Activity | Resource | Quantity» del nivel 3 asigna «Arrive at patient place QAV → Basic ambulance» y «Arrive at patient place BA → Quick attention vehicle», y la réplica lo reproducía verbatim. Los carriles del diagrama y los resultados publicados dicen lo contrario: en resourcesanalysis3.png Quick Attention Vehicle sale al 21,40 %, que es 618 × 7 min / (2 × 10 108 min) — la tarea QAV — y Basic Ambulance al 19,44 % = 393 × 10 min / (2 × 10 108 min) — la tarea BA. Con esa lectura los seis denominadores dan el mismo instante de fin de corrida (10 108 min con 3 enfermeras, 10 591 con 2), lo que confirma a la vez la fórmula busy / (capacidad × t_fin) y el cruce.

Para la utilización el cruce solo intercambia dos etiquetas, porque los dos pools tienen capacidad 2. Para el costo no: los precios difieren (25 y 0,3 /h contra 18 y 0,22 /h), así que con el cruce la réplica cobraba la tarea QAV a 25/token en vez de 18 y la tarea BA a 18 en vez de 25 (medido entonces: +36,0 % y −25,1 %). LILA-187 puso en scenario.json la asignación que cuadra con los costos publicados, y los dos costos pasan a −2,08 % y +3,96 %.

Ver también: docs/es/COMING-FROM-BIZAGI.md (la guía de usuario para quien llega desde Bizagi Modeler: los cuatro niveles como pasos de Simular, el mapa pantalla por pantalla y estas diferencias en lenguaje llano).

Ver también: docs/RESULTS_FORMAT.md (definición de las columnas de salida mencionadas en "Salidas por elemento"/"Salidas por recurso"), docs/BPMN_EXTENSION.md (namespace lila: e ids), docs/DECISIONS.md (ADR que sustentan estas decisiones) y BACKLOG.md (desglose en tickets por hito).