Eje 3: Componentes
Visión general
El GCBoK define seis componentes centrales del stack de GitCover:
GCDMS - GitCover Document Management System
Sistema de gestión de evidencias y documentos para repositorios Git. El almacenamiento sigue la familia de extensiones .gc.*: sidecar genérico <artefacto>.<orig-ext>.gc.md, contenedor de expediente .gcpn.md, artefacto de firma .gcsig.md, artefacto de datos .gc.json. Herramientas: gc-dms (registro: scan, validate, pack, verify, check), gc-sidecar (creación de sidecars), gc-docsign (GCSIG/firma), gc-v7guid (clases e identidades).
El registro del DMS es un directorio, no un almacén: los originales permanecen en su ubicación de almacenamiento; el registro conserva para cada documento el SHA-256, el object_id y las storage_locations con procedencia. El object_id es el docUid del sidecar (no una segunda identidad); stored_by_pgid es la acción de ingesta registrada del DMS (p. ej., pgid 183), stored_by_user_id es el uuidV7 de la persona. La acción generadora (produced_by_pgid, p. ej., 180 para la factura) figura por separado en el conjunto de metadatos de factura/GCPN. Catálogo del registro: GCUV/TOP/compliance/process_gateways.json; valores normativos: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.
Identidades (no confundir): docUid (instancia), sha256 (ancla de contenido), V7GUID (clase) y GCPN-docUid (expediente) son cuatro ejes separados. Solo el docUid del documento —procedente del sidecar base o, en el caso de un sidecar integrado, de source.v7g_docUid en el .gcsig.md— se convierte en el object_id del documento; un docUid de GCSIG sigue siendo un artefacto de firma (subject.sha = SHA del documento), un docUid de GCPN sigue siendo un expediente. La detección está guiada por el contenido (instancia de esquema JSON embebida), no por la extensión.
Orden (determinista): documents[] se ordena por sha256; storage_locations[] por source_root_id, unc_path (null al final), original_path y stored_at_utc. La serialización mantiene estable el orden de las claves. Los filtros temporales y la ordenación se realizan mediante el docUid de instancia uuidV7, no mediante el V7GUID de clase.
GCPN - GitCover PrimaNota
Mecanismo de metadatos para formar cadenas de evidencia auditables (predecesor/sucesor) de documentos de negocio. El término histórico PrimaNota designa una clave de ordenación que asigna a una operación de negocio —p. ej., un asiento de la contabilidad por partida doble o una operación contable de varias partes (cuenta por cobrar, IVA, centro de costes/distribución por centro de costes)— una clave única de pertenencia. GCPN traslada este principio a una base UUIDv7: cada documento recibe un identificador ordenado temporalmente (RFC 9562) y se encadena mediante referencias predecessor/successor con sus documentos predecesores y sucesores.
El encadenamiento se produce de forma no cronológica: un documento registrado más tarde puede insertarse como predecesor (predecessor insert) en una cadena existente, algo decisivo para GoBD Rz. 80 (prueba progresiva y retroactiva). Los campos de clave de coincidencia (número de pedido, deudor, importe bruto, etc.) permiten la asociación automática de cadenas sin asignación manual.
El formato .gc.md separa la parte legible por personas, arriba (título, tablas, prosa), del artefacto de datos, abajo (bloque de código JSON); para el transporte de datos, debe preferirse JSON a YAML (JSON-First). El archivo reside en repositorios Git, cuyo hash de commit sirve como prueba criptográfica de integridad.
Ámbitos de aplicación más allá de la contabilidad: registros de actividades de tratamiento del RGPD (Art. 30), cadenas de incidentes NIS2, decisiones de arquitectura MADR, ciclo de vida de tokens OIDC/OAuth, resultados de evaluación OSCAL.
Contenedor de firma GCPN (.gcpn.md) — acompañamiento del expediente en lugar de archivos individuales
Para los expedientes de firma, GCPN se concreta como un documento original del proceso independiente: un archivo .gcpn.md junto al documento referenciado (convención de nombres <Referenced-Doc-Basisname>.gcpn.md) acompaña al proceso de creación y firma; no es el sidecar del documento referenciado, sino el contenedor del proceso. No se requiere un .gcpn.md.gc.md separado: el contenedor lleva su propio GCPN-docUid y es a la vez el índice del expediente.
Concepción esencial:
- Documento mutable, artefactos JSON inmutables: el MD del contenedor se amplía para cada nuevo paso del proceso; los artefactos JSON ya embebidos (esquema
gcpn-container-2.7, autocontenido y apto para árbol:referenced_doc,actor,retentiondescritos una vez cada uno;eventscomo enum de flags con máscara de bitsevents_resultyenum_refa la colección inmutable; árbol medianteparents[]/children[]/documents[];summary—los artefactos JSON embebidos permanecen sin cambios). - Seguridad de auditoría mediante Git: el historial del contenedor (qué pasos se añadieron y cuándo) reside en el historial Git del repositorio; el hash de commit sirve como prueba criptográfica de integridad.
- Sin exceso de JSON: los artefactos JSON están siempre embebidos (bloque MD), no hay archivos
.jsonindependientes en el árbol del repositorio. - Función de índice del GCDMS: en el DMS conectado opcionalmente, el contenedor sirve como índice: navegación del proceso hacia los documentos individuales y la descripción del proceso, en lugar de n8n u otros motores de flujo de trabajo similares.
- Transición a inmutable: un documento referenciado firmado pasa después a ser inmutable; el contenedor permanece mutable y sigue documentando el proceso (historial Git = prueba).
Primer uso: firma de GVB con firma facsímil (Parte I de Firma digital, DS02–DS05).
Protección como modelo de utilidad: Az 20 2026 000 272.7 - en vigor. Objeto protegido: estructura de datos de contenedor para la gestión de documentos de negocio basada en UUIDv7 y segura para auditoría, con encadenamiento dinámico predecessor/successor. Solicitud de patente presentada (47 reivindicaciones).
GCUCB - GitCover Unified Context Bus
Bus de contexto para la coordinación en tiempo de ejecución entre agentes de IA, validadores de políticas y sistemas de auditoría, con direccionamiento determinista mediante V7GUID de los objetos de contexto. GCUCB aborda el problema de la sobrecarga de coordinación en flujos de trabajo de agentes de varias etapas (costes de serialización y de tokens en la transferencia de contexto) mediante un bus tipado y directamente direccionable, en lugar de capas intermedias basadas en texto.
OPA/Rego actúa como capa determinista de guardrails: la verificación de políticas nace del conjunto de reglas, no de la ingeniería de prompts.
La situación de propiedad industrial (modelo de utilidad, presentación ante la DPMA 260909) está anclada; las características concretas de arquitectura y procedimiento se describen en la documentación de solicitud y aquí, hasta la publicación, solo se presentan de forma general.
Delimitación
| Componente | Capa | Delimitación respecto a GCUCB |
|---|---|---|
| GCEP | Persistencia (Git a Git) | Instancia a instancia; GCUCB = bus en tiempo de ejecución |
| GCSYNC | Outbound (Git -> RAG) | Canal externo; GCUCB = bus interno |
| GCPN | Lógica de encadenamiento | Cadenas de evidencia (predecesor/sucesor); GCUCB = transporte/acceso |
Contexto de mercado: «Ontology» no es GCUCB
El mercado aborda actualmente la misma problemática de fondo —los agentes necesitan un contexto empresarial consistente y legible por máquina— bajo el término «Ontology»: Microsoft, por ejemplo, ofrece con «Fabric IQ» (versión preliminar) un «governed, self-service knowledge graph» como capa semántica que los agentes consumen como «shared context layer» (tipos de entidad, relaciones, grafo GQL, vinculaciones a OneLake). Eso es una capa de datos y semántica, no una arquitectura de transporte en tiempo de ejecución.
GCUCB aborda la misma problemática en el nivel de transporte y acceso: objetos de contexto tipados, direccionamiento determinista mediante V7GUID, acoplamiento de evidencia y políticas en tiempo de ejecución. La separación conceptual clara es deliberada: una ontología describe qué significan los términos (en GitCover: los diccionarios L1–L6, véase Conceptos: jerarquía de negocio como ontología); GCUCB determina cómo acceden a ella en tiempo de ejecución los agentes, validadores y sistemas de auditoría. Ambos niveles se complementan: GCUCB no es un producto de ontología, y la ontología no necesita un grafo de plataforma si vive de forma nativa en Git dentro del repositorio.
GCEP - GitCover Exchange Protocol
Protocolo de intercambio instancia a instancia entre repositorios Git en soportes distintos. Determinado semánticamente por catálogos OSCAL y hooks/callbacks definidos por OPA.
Se prevé un track en el IETF (I-D, forma corta: gcep). Solicitud de patente: 10 2025 003 359.1.
Niveles de protocolo: ACP, MCP y GCEP
GCEP no debe confundirse con los protocolos de agentes de IA. Los tres resuelven problemas distintos en niveles distintos:
(z. B. VS Code)"] -->|"Agent Client Protocol (ACP)"| B["Logik-Ebene / KI-Agent"] B -->|"Model Context Protocol (MCP)"| C["Infrastruktur- & Daten-Ebene"] C -->|"GitCover Exchange Protocol (GCEP)
mit Advisory Locks"| D["Verteilte Git-Server / VCS"] style A fill:#bbdefb style B fill:#c8e6c9 style C fill:#ffe0b2 style D fill:#f8bbd0
| Nivel | Protocolo | Dirección | Propósito |
|---|---|---|---|
| Puente de UI | ACP (Agent Client Protocol) | UI ↔ Agente | Conecta la interfaz de usuario (p. ej., VS Code) con la lógica del agente |
| Puente de contexto de IA | MCP (Model Context Protocol) | Agente ↔ Datos | Acceso estructurado del agente a fuentes de datos (documentos, herramientas) |
| Nivel de repositorio | GCEP | Servidor ↔ Servidor | Replicación, sincronización y aseguramiento del estado entre instancias Git físicas |
La combinación es muy relevante para la dirección: el agente trabaja mediante ACP/MCP a alta velocidad; GCEP garantiza en el nivel subyacente del repositorio que las rutas de commit y sincronización permanezcan consistentes.
Advisory Locks en la era de la IA
Los agentes de IA autónomos generan escrituras a alta frecuencia. Sin un protocolo de bloqueo a nivel de Git, dos agentes que actúan en paralelo —o un agente y una persona responsable— pueden modificar los mismos repositorios al mismo tiempo y generar estados inconsistentes (condiciones de carrera).
| Aspecto | Advisory Lock | Mandatory Lock |
|---|---|---|
| Mecanismo de acción | Los procesos comprueban el estado del bloqueo voluntariamente antes de escribir | El sistema operativo impone el bloqueo de forma estricta |
| Comportamiento ante timeout | El agente puede reaccionar estratégicamente: posponer un subobjetivo, emitir una notificación en la UI | A menudo estados del sistema bloqueados (deadlocks) |
| Idoneidad para agentes de IA | Alta: el agente consulta el estado del bloqueo de antemano (p. ej., mediante un servidor Git MCP) | Baja: bloquea la pipeline del agente |
Un agente de IA puede consultar de antemano el estado de bloqueo de GCEP («¿Está este repositorio bloqueado para otra sede?») y ajustar su planificación en consecuencia, en lugar de bloquearse de forma estricta.
GCAL - GitCover Advisory Lock
Mecanismo de bloqueo distribuido entre repositorios Git, análogo al PostgreSQL Advisory Lock, pero a nivel de repositorio. Requisito para GCEP: antes de que dos instancias intercambien datos, un lock debe garantizar una entrega atómica.
Las acciones y reglas OPA se identifican mediante uuidV7 (join GCAL/GCEP); los Gates/UUIDs de política registrados se encuentran en GCUV/TOP/compliance/{gates.json,policies/registry.json}. rule_text es solo la visualización; las clases/tipos se gestionan mediante catálogos V7GUID.
GCSYNC - GitCover Sync
Canal de salida desde GitCover hacia otros sistemas de almacenamiento de datos. Proporciona datos para sistemas RAG, servidores MCP y Nextcloud Shares.
Véase también: situación de propiedad industrial y estado de patentes en Derechos de protección. Reconocimiento de investigación en Proyectos de investigación.