Principio rector de la ontología: todo lo que el OS ejecuta debe ser tan direccionable y gobernable como todo lo que el OS escribe. La capa de documentos ya tenía BMF (TIPO-ENTIDAD-Proyecto-Nombre-vNN) y los agentes ya tenían carriles de invocación; a la capa de software le faltaba identidad de catálogo. CP-XX-BMF-OntologiaSoftware-v01 la define tratando cada pieza como un XAsset sobre la misma espina BMF.

Dos ejes ortogonales. Identidad de catálogo (asset_id, ej. SKL-EL-Sys-IBHealth-v02) para registry, gobernanza, versión y procedencia; y handle de invocación (/sk-ibhealth) para el usuario. La Nomenclatura de Invocación gobierna el eje 2; esta ontología gobierna el eje 1.

Cuatro TIPOs de software: MKT marketplace (repo git contenedor) · PLG plugin (bundle distribuible) · SKL skill (unidad auto-disparable) · CMD comando (invocación explícita). MKT/PLG no llevan dominio; SKL/CMD sí. Dos atributos gobernados en frontmatter: funcion (vocab cerrado de 6 — Forge produce activos · Gov mantiene el sistema · Flow ritmo diario · Lens analiza solo-lectura · Mind carga contexto · Ultra súper asistente compuesto) y dominio (dgen·sales·prod·ops·kz·pub·gov·sys·doc·hr, extensible con ratificación L3).

Portafolio de marketplaces como estados de confianza, no como contenedores: MKT-EL-WORXOS (producto, shippable a cliente, /wx-) · MKT-EL-Interno (plomería del equipo, /sk-) · MKT-EL-Biblioteca (externos curados y auditados, /z-) · Cuarentena (banda de entrada, no instalable). Regla dura: el equipo nunca instala directo de un repo público — solo de la Biblioteca curada (patrón golden repo / pull-through cache, estilo Artifactory-Nexus).

Ciclo de procedencia — la madurez es legible en la ENTIDAD del asset ID: crudo (upstream, en Cuarentena, sin auditar) → curado (Z, carril /z-, auditado pero "no es nuestro todavía") → forjado (EL, carriles /sh- /ux- /sk- /wx-, reconstruido con cognición + harness + gobernanza WORX). Consistente con el UpgradePipeline: upgrade ≠ migración — pasar de Z a EL es creación de valor, no re-aliasar.

Sello de auditoría como dato, no como promesa. Todo SKL/PLG lleva hoja de procedencia en frontmatter (mini-SBOM estilo SLSA): origen · fuente · licencia · madurez · estado · permisos{escribe,red,borra} · auditoria{fecha,por,veredicto,version_auditada}. La compuerta para subir a Biblioteca exige los 5 criterios: estructura válida · seguridad (sin código malicioso, sin red no declarada, sin exfiltración) · sin rutas muertas ni hardcode de sesión · licencia compatible registrada · reclasificación a SKL-Z-<Dom>-<Nombre> con procedencia completa. Sin los 5, no sube.

Cinco patrones adoptados de cadenas de suministro maduras: (1) yank/deprecate de npm-crates.io — estado: yanked + auto-update la retira sola; resuelve la clase entera de bugs "skill vieja que revive" (caso Reinventaverse). (2) Manifiesto de permisos por skill, menor privilegio por defecto, verificado en la auditoría — cierra el control de acceso cliente vs interno. (3) Canales de madurez opt-in estilo Debian: stable (solo forjado) o edge (incluye curado reciente). (4) Firma + log de transparencia (Sigstore/cosign) — da verificación de integridad y alerta si la sync mutila un archivo. (5) CODEOWNERS por dominio — la tripleta aplicada al código y automatizada en el gate.

Estado de las fuentes (ratificación diferida): CP-XX-BMF-OntologiaSoftware-v01 está en Propuesta canónica pendiente de ratificación L3 de Victor, con 5 decisiones abiertas (§9: ratificar los 6 tipos de funcion y el vocab de dominio; confirmar ENTIDAD Z; set inicial de marketplaces; si sk-skillaudit es skill nueva o módulo de sk-ibhealth; prioridad de adopción de los 5 patrones — recomendado yank y permisos primero). PLAN-XX-BMF-EcosistemaSkills-v02 está en Draft, pero sus decisiones §9 sí fueron ratificadas por Victor el 11-jul (3 carriles, sintaxis, construir el validador, benchmark). N1/N2 son pedagógicos y estables; al ratificarse la ontología conviene revisar drift.

Nota de vocabulario (drift entre las dos fuentes): el PLAN usa dominios dg·mx·px·tx·gov y la ontología usa dgen·sales·prod·ops·kz·pub·gov·sys·doc·hr. Son dos listas distintas para el mismo atributo. Queda marcado como NEXT de reconciliación en el paquete final — la página presenta la del PLAN en N2 (es la ratificada y la que el equipo usa hoy) y la de la ontología en N3.

Nodo del grafo: no existe nodo propio para esta página en ARQ-EL-Ecosistema-ModeloGrafo-v01 v01.3 (27 nodos). Es una decisión de diseño abierta —si la capa de software merece nodo en el grafo de portafolio— y se deja a criterio de JC/Victor en la revisión general, sin crearlo unilateralmente.

Referencia completa: CP-XX-BMF-OntologiaSoftware-v01 · PLAN-XX-BMF-EcosistemaSkills-v02 · MI-XX-BMF-EcosistemaSkills-Benchmark-v01 · WikiX Ontologia-Agentica · Registro-Agentico.

MatriX