Ahora: Metaobjeto / MCO
El contrato o runtime son Metaobjetos. Asumen rol MCO sólo respecto de una evaluación que puede resolver Medidas directamente desde ellos.
Este caso comienza donde termina el caso de Delivery: HU-101 origina un producto de software. Desde ahí MOPRO observa por separado la definición contractual, su realización operacional y el resultado del producto, manteniendo lineage entre perspectivas sin convertirlas en una sola jerarquía.
Backlog → Theme → Initiative → Epic → HU pertenece al caso de Delivery. Aquí sólo conservamos el origen necesario para seguir la continuidad operacional.
El HTML original aporta el caso empírico, pero varios nombres pertenecían a una etapa conceptual anterior. La adaptación no los promueve al kernel actual de MOPRO.
El contrato o runtime son Metaobjetos. Asumen rol MCO sólo respecto de una evaluación que puede resolver Medidas directamente desde ellos.
La perspectiva emerge de su posición, Alcance de Observación, Cognición y Habilidades; no es una clase raíz separada.
MOPRO-Framework declara semántica; el Perfil de Métricas y pesos vive en Cognición; los Resultados actuales viven en Identidad.
Gateway, ambiente, registry, runtime y fuentes se conectan mediante relaciones como realized-by, deployed-as, exposes, depends-on o evidences.
OpenAPI rules, RMM mapping, conformance y promotion son semánticas del caso; no nuevos tipos universales del Framework.
La snapshot persiste una Identidad evaluada cuando una condición válida de Lifecycle o del contexto lo habilita.
Los arquetipos del Framework siguen siendo cuatro; Desarrollo y Plataforma son actores concretos dentro de Tecnología e Ingeniería. Delivery aparece sólo como procedencia del caso anterior.
Origina HU-101 y conserva su lineage hacia intención y entrega. Su detalle vive en el caso HU-101.
Materializa API-SESSION-SEARCH y SVC-SEARCH aplicando estándares, NFR y guardrails acordados con Arquitectura.
Observa OAS-SESSION-SEARCH, define Habilidades de contrato, reglas de promoción y Perfil de Métricas.
Observa SVC-SEARCH, ambientes, gateway, dependencias y evidencia operacional que sostienen el producto.
Observa API-SESSION-SEARCH mediante señales de contrato, runtime y métricas de valor/adopción, sin asumir causalidad automática.
Architecture / Governance evalúa el contrato directamente. El estado del contrato no implica por sí solo que exista una realización saludable en PROD.
La misma superficie métrica puede evaluarse en cada estado; cambia el expected requerido para avanzar.
Plataforma no necesita convertir Gateway, Registry o Prometheus en tipos especiales. Son Metaobjetos conectados al runtime mediante Relations y contexto.
En este caso es configuración contextual: expected/SLO + source + query/reference + observation window + freshness. Prometheus o Datadog son adapters, no conceptos de MOPRO-Framework.
La promoción requiere readiness del ambiente y señales frescas; no depende sólo del estado contractual.
La relación entre contrato y runtime se evalúa como una Habilidad / Función de Evaluación del caso: la versión contractual esperada debe coincidir con la realización observada en el ambiente.
Expected contract v1.0.2 · observed runtime v1.0.2 · GW-DEV.
Expected contract v1.0.3 · observed runtime v1.0.2 · promoción denegada.
Expected contract v1.0.4 · observed runtime v1.0.4 · GW-CONFERENCE-PROD.
CONTRACT_RUNTIME_DRIFT. Esto puede bloquear promoción aunque cada perspectiva tenga resultados altos por separado.El caso es especialmente útil porque recorre de punta a punta las Facultades ya definidas por el Runtime.
Inspecciona OpenAPI, runtime, gateway, ambiente y fuentes operacionales.
Aplica Skills y Funciones de Evaluación de contrato, readiness y conformance.
Calcula Métricas Estándar y Score contextual cuando el Perfil lo define.
Guarda una Snapshot calificada cuando evaluación, promoción o regla temporal lo habilita.
Resuelve Registry, Gateway, telemetría, contract source y relaciones entre Metaobjetos.
Proyecta resultados hacia Arquitectura, Plataforma y Business sin prescribir un dashboard específico.
Coverage, Compliance, Adherence, Maturity y Adoption conservan significado estable. Score es una síntesis contextual cuando el Perfil la define. Gap y Trend son vistas temporales derivadas, no nuevas Métricas Estándar.
Qué parte del universo requerido pudo observarse/evaluarse.
Qué parte de lo observado cumple requisitos obligatorios.
Qué tan alineado está con estándares o prácticas esperadas.
Progreso respecto de un modelo objetivo; Richardson es una referencia contextual del caso.
Qué parte incorporó efectivamente el comportamiento/práctica esperada.
Síntesis definida por el Perfil de Métricas del actor; no reemplaza los resultados base.
La fuente usa etiquetas visibles v1.0→v1.4 y revisiones contractuales v1.0.0→v1.0.4. La adaptación conserva ambas convenciones y usa los valores finales del bloque E2E para la vista consolidada.
Compliance 57% · Adherence 66.03% · 7 findings · Review→Approved DENIED.
Compliance 68% · Adherence 74% · 5 findings · gate aún denegado.
Compliance 81% · Adherence 82% · DEV→QA PASS.
Compliance 88% · Adherence 89% · QA→PROD DENIED.
Compliance 94% · Adherence 93% · QA→PROD PASS · 1 finding.
Published · Compliance 94% · Adherence 93% · RMM L2 contextual · 1 finding.
READY · critical service availability 99.97% · conformance PASS.
Lead time 16.5→9.2 días · Cost index 100→78 · target adoption 80%.
El caso aporta patrones útiles. Se clasifican dentro de las distinciones existentes antes de decidir si alguno merece formalización futura.
| Nombre en la fuente | Lectura MOPRO actual | Estado |
|---|---|---|
| Expected Scope Resolver | Función de Evaluación / Skill que resuelve qué observaciones requiere el contexto. | Caso; no primitive. |
| Governance Context Binding | Relations + referencias contextuales en Cognición: producto, origen, owner, dominio. | Caso. |
| Operational Evidence Binding | Configuración de Integración + Observación: SLO, source, query, window, freshness. | Caso. |
| API Runtime Binding | Vista compuesta de Relations entre producto, contrato, runtime, ambiente y execution target. | Caso. |
| Control Set | Paquete versionado de Skills / Funciones de Evaluación del dominio API. | Caso. |
| Finding | Metaobjeto/resultante trazable a una evaluación; útil para Comunicación y remediación. | Caso; schema por definir. |
| Snapshot Policy | Regla contextual en Cognición que determina cuándo una Identidad válida se snapshot. | Caso. |
| Baseline Definition | Referencia contextual que selecciona snapshot/ventana comparable. | Caso. |
Desde Delivery puedes continuar hacia API Governance; desde un resultado operacional puedes volver al HU de origen y luego a su intención.
This case starts where the Delivery case ends: HU-101 originates a software product. From there MOPRO observes the contract definition, its operational realization, and the product outcome separately, preserving lineage across perspectives without forcing them into one hierarchy.
Backlog → Theme → Initiative → Epic → User Story belongs to the Delivery case. Here we only retain the origin required to continue operational continuity.
The original HTML contributes the empirical case, but several names belong to an earlier conceptual stage. The adaptation does not promote them into the current MOPRO kernel.
Contract and runtime are Meta-Objects. They assume the MCO role only for an evaluation that can resolve Measures directly from them.
Perspective emerges from position, Observation Scope, Cognition, and Skills; it is not a separate root class.
MOPRO-Framework declares semantics; Metric Profile and weights live in Cognition; current Results live in Identity.
Gateway, environment, registry, runtime, and sources connect through Relations such as realized-by, deployed-as, exposes, depends-on, or evidences.
OpenAPI rules, RMM mapping, conformance, and promotion are case semantics, not new universal Framework types.
A Snapshot persists evaluated Identity when a valid Lifecycle or contextual condition enables it.
The Framework still has four archetypes; Development and Platform are concrete actors within Technology & Engineering. Delivery is shown only as provenance from the prior case.
Originates HU-101 and preserves lineage to intent and delivery. Its details live in the HU-101 case.
Materializes API-SESSION-SEARCH and SVC-SEARCH using standards, NFRs, and guardrails agreed with Architecture.
Observes OAS-SESSION-SEARCH and defines contract Skills, promotion rules, and Metric Profile.
Observes SVC-SEARCH, environments, gateway, dependencies, and operational evidence supporting the product.
Observes API-SESSION-SEARCH using contract, runtime, and value/adoption signals without assuming automatic causality.
Architecture / Governance evaluates the contract directly. Contract state alone does not imply that a healthy realization exists in PROD.
The same metric surface can be evaluated at every state; the expected threshold required to advance changes.
Platform does not need Gateway, Registry, or Prometheus to become special types. They are Meta-Objects connected to runtime through Relations and context.
In this case it is contextual configuration: expected/SLO + source + query/reference + observation window + freshness. Prometheus or Datadog are adapters, not MOPRO-Framework concepts.
Promotion requires environment readiness and fresh signals; it does not depend only on contract state.
The contract/runtime relation is evaluated as a case Skill / Evaluation Function: the expected contract version must match the realization observed in the environment.
Expected contract v1.0.2 · observed runtime v1.0.2 · GW-DEV.
Expected contract v1.0.3 · observed runtime v1.0.2 · promotion denied.
Expected contract v1.0.4 · observed runtime v1.0.4 · GW-CONFERENCE-PROD.
CONTRACT_RUNTIME_DRIFT. This can block promotion even when each perspective scores highly on its own.The case is especially useful because it traverses the Runtime Faculties already defined end to end.
Inspects OpenAPI, runtime, gateway, environment, and operational sources.
Applies contract, readiness, and conformance Skills and Evaluation Functions.
Calculates Standard Metrics and contextual Score when the Profile defines it.
Persists a qualified Snapshot when evaluation, promotion, or a temporal rule enables it.
Resolves Registry, Gateway, telemetry, contract source, and Relations among Meta-Objects.
Projects results to Architecture, Platform, and Business without prescribing a specific dashboard.
Coverage, Compliance, Adherence, Maturity, and Adoption keep stable meaning. Score is a contextual synthesis when the Profile defines it. Gap and Trend are derived temporal views, not new Standard Metrics.
How much of the required universe could be observed/evaluated.
How much of what was observed satisfies mandatory requirements.
How aligned the observed reality is with expected standards or practices.
Progress against a target model; Richardson is a contextual reference in this case.
How much of the applicable population actually incorporated the expected behavior/practice.
Synthesis defined by the actor Metric Profile; it does not replace the base results.
The source uses visible labels v1.0→v1.4 and contract revisions v1.0.0→v1.0.4. The adaptation preserves both conventions and uses values from the final E2E block for the consolidated view.
Compliance 57% · Adherence 66.03% · 7 findings · Review→Approved DENIED.
Compliance 68% · Adherence 74% · 5 findings · gate still denied.
Compliance 81% · Adherence 82% · DEV→QA PASS.
Compliance 88% · Adherence 89% · QA→PROD DENIED.
Compliance 94% · Adherence 93% · QA→PROD PASS · 1 finding.
Published · Compliance 94% · Adherence 93% · contextual RMM L2 · 1 finding.
READY · critical service availability 99.97% · conformance PASS.
Lead time 16.5→9.2 days · Cost index 100→78 · adoption target 80%.
The case contributes useful patterns. They are classified within existing distinctions before deciding whether any deserve future formalization.
| Name in source | Current MOPRO reading | Status |
|---|---|---|
| Expected Scope Resolver | Evaluation Function / Skill resolving which observations are required by context. | Case; not primitive. |
| Governance Context Binding | Relations + contextual Cognition references: product, origin, owner, domain. | Case. |
| Operational Evidence Binding | Integration + Observation configuration: SLO, source, query, window, freshness. | Case. |
| API Runtime Binding | Composite Relation view among product, contract, runtime, environment, and execution target. | Case. |
| Control Set | Versioned package of API-domain Skills / Evaluation Functions. | Case. |
| Finding | Meta-Object/result traceable to an evaluation; useful for Communication and remediation. | Case; schema TBD. |
| Snapshot Policy | Contextual Cognition rule determining when valid Identity is captured. | Case. |
| Baseline Definition | Contextual reference selecting a comparable snapshot/window. | Case. |
From Delivery you can continue into API Governance; from an operational result you can walk back to the originating User Story and intent.