El Runtime implementa Facultades genéricas para observar, evaluar, calcular, snapshotr, integrar y comunicar la realidad descrita por el Framework. La semántica y el estado permanecen en los Metaobjetos.
El Framework declara que una Facultad existe y qué contrato cumple; el Runtime la implementa y ejecuta.
Metamodelo, conceptos, relaciones, Métricas Estándar y contratos de Facultades.
Identidad, Cognición, Habilidades, Lifecycle, Jerarquía, Relaciones y Etiquetas.
Observación, Evaluación, Cálculo, Snapshot, Integración y Comunicación.
El mismo flujo puede operar sobre un MCO o sobre un Metaobjeto superior que resuelva resultados desde sucesores.
MOPRO-Runtime no debe codificar semántica rígida de Jira, Kubernetes, API u otros dominios.
No se agregan Facultades no presentes en las fuentes auditadas.
Leer / inspeccionar realidad evaluable.
Ejecutar Funciones de Evaluación sobre sí mismo u otros Metaobjetos.
Aplicar fórmulas y producir resultados.
Persistir una Identidad evaluada cuando el Lifecycle la habilita.
Conectar fuentes, objetos y sistemas.
Dejar disponibles los resultados.
Una Snapshot relevante aparece sólo cuando el Lifecycle habilita snapshotr la Identidad evaluada.
Contenido inicial; no califica todavía.
La versión evoluciona y puede evaluarse.
Mejora su Identidad, aún dentro del ciclo.
La condición válida habilita la Snapshot.
Integration y Communication siguen siendo Facultades distintas. La estrategia siguiente formaliza un contrato propuesto de Runtime: no obliga a usar Kafka, APIs, Kubernetes ni una herramienta específica, y tampoco convierte “real-time” en una propiedad universal de MOPRO.
Proposed Runtime Contract · v9Kafka, Pub/Sub, event bus o webhook cuando la realidad llega como evento.
Jira, GitLab, Datadog, Backstage u otros sistemas consultables por API.
Kubernetes API, Prometheus, bases de datos u otras fuentes de estado consultable.
OpenAPI, AsyncAPI, Git, Registry o archivos versionados tratados como realidad observable.
sourceRef
subjectRef
relation/context
selector | query | artifactRef
observationWindow
freshnessPolicysubjectRef
measureRef
value
observedAt
evidenceRef
provenanceEl adapter traduce una fuente existente al contrato genérico de Observation. La semántica de Jira, Kubernetes o Datadog no entra al kernel.
No prescribe dashboard, API, Backstage, Looker, Grafana u otra interfaz concreta. Expone resultados ya evaluados a la proyección que corresponda.
Un webhook, Kafka o Pub/Sub puede disparar observación cuando cambia un contrato o un work item. Event-driven es una estrategia de primera clase, no la topología obligatoria del Runtime.
contract.changed / issue.updated
→ Integration
→ Observation
→ Evaluation + Calculation
→ Identity
→ Lifecycle-qualified SnapshotCuando la realidad es estado consultable, Integration ejecuta una query y normaliza la evidencia al mismo contrato de Observation.
Prometheus query / Kubernetes API
→ Integration
→ Observation Result
→ Measures
→ Metric ResultsUn contrato puede observarse como artifact dentro del pipeline sin que el transporte se convierta en parte del Framework.
OpenAPI artifact + commit SHA
→ Integration
→ Observation
→ Contract Skills
→ EvaluationLa misma Faculty puede leer APIs stateless cuando no existe o no conviene un stream de eventos.
API request
→ sourceRef + subjectRef
→ Observation Result
→ provenance + observedAtLo que permanece TBD es el mecanismo formal de extensión —plugins, SDK, SPI o packaging de adapters—, no la Faculty de Integration ni sus patrones de entrada.
MOPRO-Runtime materializes the Framework as an operational governance engine: it observes existing reality, executes evaluation and calculation, preserves valid states, and communicates results without requiring Jira, GitLab, Kubernetes, observability, or contract systems to be rewritten.
The Framework declares that a Faculty exists and the contract it fulfills; the Runtime implements and executes it.
Metamodel, concepts, relations, Standard Metrics, and Faculty contracts.
Identity, Cognition, Skills, Lifecycle, Hierarchy, Relations, and Tags.
Observation, Evaluation, Calculation, Snapshot, Integration, and Communication.
The same flow can operate on an MCO or on a higher Meta-Object that resolves results from successors.
MOPRO-Runtime must not hard-code semantics for Jira, Kubernetes, APIs, or other domains.
No Faculties absent from the audited sources are added.
Read / inspect evaluable reality.
Execute Evaluation Functions on self or other Meta-Objects.
Apply formulas and produce results.
Persist an evaluated Identity when Lifecycle enables it.
Connect sources, objects, and systems.
Make results available.
A relevant Snapshot appears only when Lifecycle enables capture of the evaluated Identity.
Initial content; not yet qualified.
The version evolves and can be evaluated.
Its Identity improves while still within the cycle.
The valid condition enables the Snapshot.
Integration and Communication remain distinct Faculties. The strategy below formalizes a proposed Runtime contract: it does not require Kafka, APIs, Kubernetes, or any specific tool, and it does not make “real-time” a universal MOPRO property.
Proposed Runtime Contract · v9Kafka, Pub/Sub, event bus, or webhook when reality arrives as an event.
Jira, GitLab, Datadog, Backstage, or other systems exposed through APIs.
Kubernetes API, Prometheus, databases, or other queryable state sources.
OpenAPI, AsyncAPI, Git, Registry, or versioned files treated as observable reality.
sourceRef
subjectRef
relation/context
selector | query | artifactRef
observationWindow
freshnessPolicysubjectRef
measureRef
value
observedAt
evidenceRef
provenanceThe adapter translates an existing source into the generic Observation contract. Jira, Kubernetes, or Datadog semantics do not enter the kernel.
It does not prescribe a dashboard, API, Backstage, Looker, Grafana, or any concrete interface. It exposes evaluated results to the appropriate projection.
A webhook, Kafka, or Pub/Sub event can trigger observation when a contract or work item changes. Event-driven is a first-class strategy, not the mandatory Runtime topology.
contract.changed / issue.updated
→ Integration
→ Observation
→ Evaluation + Calculation
→ Identity
→ Lifecycle-qualified SnapshotWhen reality is queryable state, Integration executes a query and normalizes evidence into the same Observation contract.
Prometheus query / Kubernetes API
→ Integration
→ Observation Result
→ Measures
→ Metric ResultsA contract can be observed as an artifact in the pipeline without making transport part of the Framework.
OpenAPI artifact + commit SHA
→ Integration
→ Observation
→ Contract Skills
→ EvaluationThe same Faculty can read stateless APIs when an event stream does not exist or is not appropriate.
API request
→ sourceRef + subjectRef
→ Observation Result
→ provenance + observedAtWhat remains TBD is the formal extension mechanism —plugins, SDKs, SPIs, or adapter packaging—, not the Integration Faculty or its input patterns.