> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Estudio de caso: el ecosistema Orkestron **Especificación del Meta-Universo** **ID del documento:** MU-V2-ECO-010 **Título:** Estudio de caso: el ecosistema Orkestron como Meta-Universo en funcionamiento **Clase de documento:** informativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** ninguna **Referencias informativas:** [Known-Implementations](Known-Implementations.md), [Registered-Meta-Models](Registered-Meta-Models.md), [Meta-Model-Composition](../02-architecture/Meta-Model-Composition.md), [Extension-Model](../02-architecture/Extension-Model.md), [AI-Agent-Guide](../07-guides/AI-Agent-Guide.md), [Case-Study-Axiacracy-MOS](Case-Study-Axiacracy-MOS.md) **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este estudio de caso documenta un ecosistema real y en funcionamiento de meta-modelos y productos, el **ecosistema Orkestron**, como ilustración trabajada de los conceptos del Meta-Universo en uso productivo. Existe por dos razones: 1. **Evidencia.** El estándar debería poder señalar al menos un lugar donde sus conceptos (Universo, Dimensión, espacio de nombres, objeto, proyección, evento, paquete semántico, federación) no sean hipotéticos, sino que sostengan productos vivos. 2. **Retroalimentación.** Varias partes de esta especificación (la capa de composición, el registro de modelos externos, la orientación para agentes de IA) tomaron forma a partir de problemas encontrados primero dentro de este ecosistema. Registrar la correspondencia mantiene honesto ese linaje. Este documento es informativo. Nada de lo que contiene se exige para la conformidad, y listar aquí el ecosistema no implica certificación (véase [Known-Implementations](Known-Implementations.md)). Para un segundo estudio de caso, de mayor escala (toda una comunidad política modelada como una sola Dimensión del Meta-Universo), véase [Estudio de caso: la axiacracia y el Meta-Orchestrator State](Case-Study-Axiacracy-MOS.md). --- # 2. El ecosistema de un vistazo Orkestron es un ecosistema para **agentes de IA que hacen trabajo profesional**, organizado en cuatro superficies: | Superficie | Papel | Lectura desde el Meta-Universo | |---------|------|-----------------------| | **orkestron.ai** | La fachada: explica el servicio | La autodescripción pública del Universo | | **orkestron.dev** | Lado del proveedor: estándares, normas, panel del proveedor, entornos de ejecución de agentes | La capa constitucional y arquitectónica del Universo | | **orkestro.net** | Mercado: mecánica de los acuerdos, panel del cliente | Superficie de federación: donde partes independientes transaccionan sobre semántica compartida | | **Entorno de agentes** (Agent Hub, PA-service) | Donde los agentes ejecutan de verdad | Instanciación de objetos y generación de eventos | Alrededor de estas superficies vive una familia de especificaciones abiertas de meta-modelos, y en torno a ellas una flota de productos concretos (una plataforma de eventos, escaparates de realm, sitios de aterrizaje, una guía con IA). Cada producto lleva su propio modelo de producto estructurado; las especificaciones definen qué es un modelo así. --- # 3. La familia de meta-modelos Cuatro especificaciones forman la columna semántica. Cada una ocupa un nivel distinto y, juntas, ilustran en la práctica la estratificación del Meta-Universo (de M1 a M4). ## 3.1 AISMM: un producto como modelo de contexto completo **AISMM (AI-driven Software Meta-Model)**, publicado en [orkestron-ai/software-meta-model](https://github.com/orkestron-ai/software-meta-model) (v3.1, Apache-2.0), modela **un solo producto de software** como un sistema completo: por qué existe, qué valor crea, cómo se diseña, se especifica, se implementa, se opera, se controla y se cambia. Los modelos son nativos de Git, legibles por humanos y por máquinas, con identidades UUID estables y un fichero de registro por modelo. Lectura desde el Meta-Universo: - AISMM es un **meta-modelo de dominio** (M2) para el dominio "producto de software". - Un modelo de producto AISMM es un **espacio de nombres**: un conjunto gobernado de definiciones de objeto y de sus instancias (funcionalidades, decisiones, componentes, versiones). - El fichero de registro (`aismm.registry.json`) hace las veces de autodescripción legible por máquina del espacio de nombres, el patrón que este estándar generaliza como índices de especificación y manifiestos de paquete. ## 3.2 PLMM: el paisaje como federación por encima de AISMM **PLMM (Product Landscape Meta-Model)**, publicado en [orkestron-ai/product-landscape-meta-model](https://github.com/orkestron-ai/product-landscape-meta-model) (v0.1, Apache-2.0), modela el **portafolio entre productos**: registro, grafo de dependencias e integraciones, capacidades compartidas, propiedad y gobernanza, en once capas. Lectura desde el Meta-Universo: - PLMM es un **meta-modelo con forma de federación**: no absorbe los modelos de producto, los **referencia**. Cada producto conserva su modelo AISMM soberano; PLMM guarda las relaciones. - Es exactamente la postura del Meta-Universo sobre la federación: soberanía de las partes, capa conectiva para el conjunto. Donde MUFP federa *entre organizaciones*, PLMM aplica la misma disciplina *dentro* de una. ## 3.3 BKM: el conocimiento como paquete distribuible **BKM (Base Knowledge Model)** (v0.4, privado en el momento de escribir esto) define cómo se empaqueta el **conocimiento de una profesión** para que un agente de IA pueda cargarlo como competencia nuclear. Existen paquetes para las profesiones de analista y de gestión de eventos (este último con 179 entidades). Lectura desde el Meta-Universo: - Un paquete BKM es un **paquete semántico**: conocimiento versionado, distribuible e importable, con conformidad declarada. - La arquitectura de agente que lo consume separa tres contextos: **núcleo del agente** (el paquete BKM portátil), **contexto de rol** (identidad y alcance ante cada empleador) y **contexto de tarea** (el encargo concreto). Es una instancia viva de los conceptos de contexto y perspectiva: un mismo cuerpo de conocimiento, proyectado de forma distinta según rol y tarea, sin copiarlo. ## 3.4 Contratos: semántica ejecutable de una misión La especificación **software-agents-contracts** define contrato, protocolo y entregable: la ejecución regulada de una misión atómica por parte de un agente. Lectura desde el Meta-Universo: - Un contrato es aquí un **contrato semántico ejecutable** en el sentido de este estándar: un acuerdo cuyo significado es lo bastante preciso como para conducir la ejecución y la verificación, no solo para documentarlas. --- # 4. Tabla de correspondencias | Concepto del Meta-Universo | Realización en Orkestron | |-----------------------|------------------------| | Universo | El ecosistema Orkestron como jurisdicción semántica soberana | | Dimensión | Una superficie o un contexto de gestión importante (mercado, lado del proveedor, una familia de productos) | | Espacio de nombres | El modelo AISMM de un producto; un paquete BKM; una capa de PLMM | | Objeto | Una funcionalidad, una decisión, un componente, un agente, una misión, un acuerdo | | Proyección | La vista de solo lectura de un escaparate de realm; un panel de proveedor; un panel de cliente | | Evento | Una misión ejecutada, un acuerdo cerrado, una versión publicada, una entrada de historial | | Paquete semántico | Un paquete BKM de profesión; un estándar externo importado | | Contrato de federación | El contrato de token de la API de realm; un acuerdo del mercado | | Confianza | Historial y rango del agente (APM); políticas de control con rampas de autonomía | --- # 5. La federación en la práctica: los realms La ilustración productiva más clara de proyección y federación es el patrón de **realm** de la plataforma de eventos del ecosistema. Un realm es una porción acotada de los datos de la plataforma (eventos, personas organizadoras) expuesta a través de una **API de realm** autenticada por token. Sitios escaparate independientes, cada uno con su marca, sus idiomas y su voz editorial, consumen un realm como **proyección de solo lectura**: - La plataforma sigue siendo **soberana**: le pertenecen los datos, su esquema y su ciclo de vida. - Cada escaparate tiene un **contrato** (el token y la superficie de la API), no una copia de las tripas de la plataforma. - Los datos cruzan la frontera **como proyecciones**, bajo demanda, en el contexto de presentación de quien consume. - Varios escaparates nacionales funcionan así en producción, cada uno consumidor distinto de la misma fuente soberana. Es la promesa central de MUFP en miniatura: *interoperabilidad sin absorción*. El patrón estaba en marcha antes de que este estándar lo formalizara, y sobrevivió a su replicación entre consumidores precisamente porque la frontera de soberanía nunca se difuminó. --- # 6. Composición y estándares externos en la práctica AISMM v3.1 incluye una **capa de vinculación externa**: un modelo de producto no reformula los estándares públicos, se vincula a ellos. En la práctica del ecosistema, los modelos se vinculan a identificadores y vocabularios como ISO 3166, LEI, ESCO, tipos de schema.org y W3C ORG. Trabajar con vinculaciones reales sacó a la luz las preguntas que este estándar responde ahora de forma normativa: - *¿Cuándo es un concepto externo un campo, un modelo anidado o una referencia?* Lo responde [Meta-Model-Composition](../02-architecture/Meta-Model-Composition.md) (ARCH-016). - *¿A qué estándar debo vincularme para un concepto dado?* Lo responden el [registro de modelos externos](External-Models-Registry.md) (1180 estándares catalogados con sus roles de composición) y el [catálogo de conectores](Connector-Catalogue.md). --- # 7. Lecciones que el estándar tomó de este ecosistema 1. **Los ficheros de registro se pagan solos.** Todo modelo que se publicó con un registro legible por máquina sobrevivió a los cambios de herramientas; todo modelo sin él acabó necesitando reconstrucción. De ahí el énfasis en índices de especificación, manifiestos de paquete y huellas. 2. **La soberanía es una propiedad operativa, no un eslogan.** El patrón de realm funciona porque la frontera la imponen un contrato y un token, no la costumbre. Los conceptos de federación de este estándar están escritos para poder imponerse igual. 3. **El conocimiento quiere ser un paquete.** Separar el conocimiento portátil (BKM) del contexto de rol y de tarea convirtió agentes de un solo uso en especialistas reutilizables. El concepto de paquete semántico generaliza esto. 4. **Federar dentro de una organización sigue siendo federar.** PLMM mostró que referenciar modelos soberanos gana a fusionarlos incluso cuando una sola entidad jurídica lo posee todo. La absorción genera obsolescencia; la referencia genera responsabilidad. 5. **Un modelo que los agentes de IA no pueden recorrer no se mantendrá.** Todo artefacto de la familia está diseñado para que lo lean primero los agentes y por igual las personas; eso guio la orientación para IA de [AI-Agent-Guide](../07-guides/AI-Agent-Guide.md). --- # 8. Estado y referencias - Custodia del ecosistema: Orkestron.AI (también custodio de la implementación de referencia de esta especificación). - Repositorios públicos: [software-meta-model](https://github.com/orkestron-ai/software-meta-model), [product-landscape-meta-model](https://github.com/orkestron-ai/product-landscape-meta-model). - El estándar en sí se publica de forma neutral respecto de proveedores en [ver.cy](https://ver.cy), con las fuentes en [ver-cy/meta-universe](https://github.com/ver-cy/meta-universe); Orkestron aparece en este documento estrictamente como una implementación conocida. Madurez, en el vocabulario de [Known-Implementations](Known-Implementations.md) §7: **producción** (superficies y federación de realms), **implementación de referencia** (AISMM), **experimental** (PLMM, BKM, contratos).