El caso simula una sola realidad operacional recorrida desde tres perspectivas. Negocio navega desde el Backlog hacia la Historia de Usuario; Agilidad parte desde la HU y recupera su contexto hacia arriba; Infraestructura observa el servicio que la materializa y sus objetos operacionales. La continuidad se conserva mediante Hierarchy y Relations, sin duplicar los objetos.
El objetivo no es explicar nuevamente todo el framework, sino aterrizarlo sobre una historia concreta y mostrar la continuidad entre objetos y perspectivas.
La simulación conserva el árbol completo de Conference Planning. HU-102 y HU-103 no se desarrollan en detalle aquí, pero permanecen visibles para que el Observation Scope tenga contexto real.
Una Lista de Trabajo, un Tema, dos Iniciativas, dos Épicas y tres Historias de Usuario. El foco del caso es HU-101, no el universo completo.
Selecciona una perspectiva. El panel inferior muestra el punto de entrada, los tipos de objeto disponibles, el objeto inicialmente seleccionado y hasta dónde puede navegar ese Actor dentro de este caso.
Parte desde la Historia de Usuario y navega hacia su contexto superior.
Negocio y Agilidad comparten la misma jerarquía con sentidos de navegación distintos. La transición hacia Infraestructura ocurre mediante una Relation: HU-101 se materializa en SVC-SEARCH, que pasa a ser el objeto operacional observado.
Distinción: `BACKLOG → … → HU` es Hierarchy. `HU-101 → SVC-SEARCH` es Relation. El segundo enlace conserva procedencia sin afirmar que un Service sea un nivel inferior del Backlog.
Recuperamos el objeto referencial y las Measures que ya habíamos usado, para que el caso vuelva a estar aterrizado sobre una historia real dentro de la simulación.
La versión activa y observada es V4 · Lista · L3. Esta es la instancia sobre la que el runtime ejecuta la evaluación.
Version history no es Snapshot history. V4 es la versión activa y la instancia observada en este caso.
Cuando el Lifecycle satisface la condición definida, el runtime puede persistir un Lifecycle-qualified Snapshot de la Identity evaluada.
Los valores de V4 acompañan a la métrica que representan. La composición conserva la estructura anidada que usamos en la simulación original.
La Historia de Usuario es el objeto foco. Desde ella, la Agilitadora puede recuperar Épica, Iniciativa, Tema y Backlog para entender contexto, propagación y concentración de brechas sin duplicar ningún objeto.
La navegación parte en la unidad mínima directamente evaluada y asciende por la misma jerarquía que Negocio recorre en sentido contrario.
El objeto no se duplica: HU-101 conserva su Identity y Standard Metrics; Agilidad agrega su Cognition/Skills para responder una pregunta distinta sobre el mismo Meta-Object.
El Product Owner parte por BACKLOG-01 y desagrega hasta encontrar la Historia de Usuario que explica un resultado, riesgo o prioridad. HU-101 sigue siendo el mismo objeto que observa Agilidad.
El scope no cambia de estructura: cambia el punto de entrada, la pregunta y el perfil de evaluación.
El Service no es un hijo jerárquico de la HU. Se enlaza mediante `realized-by`, pasa a ser el MCO de esta perspectiva y abre un nuevo Observation Scope operacional: Runtime Component, Dependency, Monitoring Asset y Operational Policy.
Realiza búsqueda y filtrado de sesiones. En la simulación está vinculado a HU-101 y conserva trazabilidad hacia EPIC-01, INIT-01, THEME-01 y BACKLOG-01.
Continuidad visible: MON-SEARCH observa la operación de SVC-SEARCH y está enlazado tanto al Service como a HU-101. La herramienta puede recorrer desde la telemetría hacia la historia que originó esa realización operacional.
La semántica proviene del Meta-Object, Actor, Cognition y Skills. El runtime proporciona la capacidad común de ejecutar la observación.
La tabla resume qué objetos son directamente observables, cuáles son contexto y cuáles aparecen por Relation. El punto clave es que HU-101 y SVC-SEARCH permanecen enlazados a través de Agilidad, Negocio e Infraestructura.
| Objeto | Agilidad | Negocio | Infraestructura | Conexión |
|---|---|---|---|---|
| BACKLOG-01 | scope superior | entry point | lineage disponible | Hierarchy |
| THEME-01 | contexto | drill-down | lineage disponible | Hierarchy |
| INIT-01 | contexto | drill-down | lineage disponible | Hierarchy |
| EPIC-01 | contexto inmediato | drill-down | lineage disponible | Hierarchy |
| HU-101 | objeto foco · MCO | objeto alcanzable | origin relation | Hierarchy + realized-by |
| SVC-SEARCH | sucesor relacionado | realización de HU-101 | objeto foco · MCO | realized-by |
| RT-API-PROD | — | — | Runtime Component | operational scope |
| MON-SEARCH | trazable a HU-101 | evidencia operacional | Monitoring Asset | linked-to Service + HU |
| DEP-DB / POL-SLO | — | — | supporting objects | operational scope |
Resultado del caso: una observación de MON-SEARCH puede mantener contexto hacia SVC-SEARCH y HU-101; desde HU-101 puede recuperarse EPIC-01 → INIT-01 → THEME-01 → BACKLOG-01. No es una sola jerarquía: es continuidad semántica entre jerarquía y relaciones.
El caso demuestra cómo una cadena organizacional puede ser observada sin perder ni la autonomía de cada Actor ni la relación entre los objetos.