Eje 3: Componentes

Visión general

El GCBoK define seis componentes principales del stack de GitCover:

GCDMS - GitCover Document Management System

Sistema de gestión de evidencias y documentos basado en contenedores .v7g.md y sus metadatos. Toolchain: v7g-pack, v7g-verify, v7g-sign, v7g-export.

GCPN - GitCover PrimaNota

Mecanismo de metadatos para la formación de cadenas de prueba a prueba de revisiones (predecesor/sucesor) para documentos comerciales. El término histórico PrimaNota designa una clave de ordenación que asigna a un hecho comercial - p. ej., un asiento de la contabilidad por partida doble o un proceso de registro de varias partes (cuenta por cobrar, IVA, centro de coste/distribución por portador de costes) - una clave única para la pertenencia conjunta. 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 realiza de forma no cronológica: un documento registrado posteriormente puede insertarse como predecesor (Predecessor-Insert) en una cadena existente - decisivo para GoBD Rz. 80 (verificación progresiva y retrógrada). Los campos Match-Key (número de pedido, deudor, importe bruto, etc.) permiten una asociación automática de cadenas sin asignación manual.

El formato de contenedor .v7g.md combina metadatos legibles por humanos (YAML + Markdown) con datos comerciales procesables por máquina (JSON incrustado) y se almacena en repositorios Git, cuyo commit-hash 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, OSCAL-Assessment-Results.

Contenedor de firma GCPN (.gcpn.md) — acompañamiento del proceso en lugar de archivos individuales

Para procesos de firma, GCPN se concreta como un Prozess-Ur-Doc independiente: un archivo .gcpn.md junto al Referenced-Doc (convención de nomenclatura <Referenced-Doc-Basisname>.gcpn.md) acompaña el proceso de creación y firma — no es el sidecar del Referenced-Doc, sino el contenedor de proceso.

Concepción esencial:

• Doc mutable, artefactos JSON inmutables: el MD del contenedor se amplía con cada nuevo paso del proceso; los artefactos JSON ya incrustados (esquema gcpn-container-1.0: referenced_doc, actor, retention descritos una sola vez cada uno; events como Flags-Enum con máscara de bits events_result, p. ej. 11 = offered + accepted + sign; summary) permanecen inalterados.
• Seguridad frente a revisiones mediante Git: el historial del contenedor (qué pasos se añadieron y cuándo) reside en el historial Git del repositorio — el commit-hash sirve como prueba criptográfica de integridad.
• Sin JSON-Bloat: los artefactos JSON están siempre incrustados (MD-Fence) — ningún archivo .json independiente en el árbol del repositorio.
• Función de índice del GCDMS: en el DMS acoplado opcionalmente, el contenedor sirve como índice — navegación del proceso hacia los documentos individuales y hacia la descripción del proceso, en lugar de n8n o motores de flujo de trabajo similares.
• Transición a inmutable: un Referenced-Doc firmado se vuelve a partir de entonces inmutable; el contenedor permanece mutable y sigue documentando el proceso (historial Git = prueba).

Primera utilización: firma GVB con firma facsimilar (parte I de la Firma digital, DS02–DS05).

Protección de modelo de utilidad: Az 20 2026 000 272.7 - en vigor. Objeto protegido: estructura de datos de contenedor para la gestión de documentos comerciales basada en UUIDv7 y a prueba de revisiones, con encadenamiento dinámico Predecessor/Successor. Solicitud de patente presentada (47 reivindicaciones).

GCUCB - GitCover Unified Context Bus

Bus de contexto para la coordinación de runtime entre agentes de IA, validadores de políticas y sistemas de auditoría — con direccionamiento V7GUID determinista de los objetos de contexto. GCUCB aborda el problema de la sobrecarga de coordinación de los flujos de trabajo de agentes de varios niveles (costes de serialización y de tokens de 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 de guardrails determinista: la verificación de políticas surge del conjunto de reglas, no de la ingeniería de prompts.

La situación de los derechos de protección (modelo de utilidad, presentación en la DPMA 260909) está asegurada; las características concretas de arquitectura y de procedimiento están descritas en la documentación de la solicitud y aquí solo se presentan de forma general hasta su publicación.

Delimitación

Contexto de mercado: „Ontology" no es GCUCB

Actualmente el mercado aborda la misma problemática fundamental — los agentes necesitan un contexto empresarial consistente y legible por máquina — bajo el término „Ontology": Microsoft, por ejemplo, ofrece con „Fabric IQ" (Preview) un „governed, self-service knowledge graph" como capa semántica que los agentes consumen como „shared context layer" (Entity types, Relationships, GQL-Graph, OneLake-Bindings). Esto 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 de acceso: objetos de contexto tipados, direccionamiento determinista mediante V7GUID, acoplamiento de evidencia y Policy en tiempo de ejecución. La separación clara de términos es deliberada: una ontología describe qué significan los términos (en GitCover: los diccionarios L1–L6, véase Conceptos: la jerarquía empresarial como ontología); GCUCB determina cómo acceden a ella en tiempo de ejecución los agentes, los validadores y los 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 cuando vive de forma Git-nativa en el repo.

GCEP - GitCover Exchange Protocol

Protocolo de intercambio de instancia a instancia entre repositorios Git en soportes distintos. Semánticamente determinado por catálogos OSCAL y hooks/callbacks definidos por OPA.

Vía IETF prevista (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:

La combinación es de gran relevancia para la gestión: el agente trabaja a alta velocidad mediante ACP/MCP; GCEP garantiza en el nivel de repositorio subyacente que las rutas de commit y de sincronización permanezcan consistentes.

Advisory Locks en la era de la IA

Los agentes de IA autónomos generan accesos de escritura con alta frecuencia. Sin un protocolo de bloqueo a nivel de Git, dos agentes que actúen en paralelo - o un agente y un empleado administrativo humano - pueden modificar los mismos repositorios simultáneamente y generar estados inconsistentes (Race Conditions).

Un agente de IA puede consultar por adelantado el estado de bloqueo de GCEP ("¿Está este repositorio bloqueado para otro establecimiento?") y ajustar su planificación en consecuencia - en lugar de bloquearse de forma rígida.

GCAL - GitCover Advisory Lock

Mecanismo de Distributed Lock 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.

GCSYNC - GitCover Sync

Canal outbound desde GitCover hacia otros sistemas de almacenamiento de datos. Proporciona datos para sistemas RAG, servidores MCP y Nextcloud Shares.

Véase también: derechos de protección y estado de patentes en Derechos de protección. Reconocimiento de investigación en Proyecto de investigación.