Eje 2: Conceptos

V7GUID - Version-7-GUID

V7GUID (también: Categorized UUIDv7 Identifier) es un esquema de categorización para identificadores en artefactos de GitCover, basado en UUID versión 7 compatible con RFC 4122 (basada en tiempo, ordenable), ampliado con una clasificación de clases específica de GitCover.

Estructura

Propósito: Vinculación determinista y ordenable de justificantes en una cadena de justificantes. Permite la reconstruibilidad temporal/versionada (GoBD: adecuación temporal) sin una base de datos de secuencias central.

Base temporal: GMT/UTC (regla normativa)

Los sellos de tiempo de 48 bits de todos los V7GUID y uuidV7 deben generarse e interpretarse siempre sobre la base GMT/UTC (offset 0), nunca sobre la base de una zona horaria local (MESZ, MEZ, etc.):

Justificación:

• Neutral respecto a la zona horaria: Un sello de tiempo basado en UTC puede interpretarse de forma única en todo el mundo. Las marcas temporales locales (cambios de horario de verano, límites de zonas horarias) no distorsionan la ordenabilidad ni la comparabilidad.
• Convertibilidad: Cualquier aplicación puede convertir el sello de tiempo UTC en cualquier momento a la zona horaria local del usuario, en particular las aplicaciones que deben llevar una marca temporal (p. ej., registro horario de empleados, comprobantes de tiempo de trabajo, seguimiento de plazos). El camino inverso (tiempo local como base) genera ambigüedades (cambio al horario de verano: 03:00 CEST = 01:00 UTC existe dos veces).
• Conformidad con GoBD: La adecuación temporal y la trazabilidad (§ 146 AO) requieren una base temporal inmutable y única. UTC es la única base que garantiza esta propiedad de forma sistémica.
• Consistencia con RFC 9562: El estándar UUIDv7 define el sello de tiempo como milisegundos desde la época Unix (UTC); cualquier generación que se desvíe de ello infringe el estándar.

Regla de reconocimiento: Al decodificar un V7GUID/uuidV7, el valor de 48 bits extraído debe leerse siempre como UTC. La visualización/procesamiento posterior en hora local se realiza exclusivamente en la capa de presentación de la aplicación, nunca en la base del identificador.

Norma e implementación: El principio V7GUID (jerarquía de 6 niveles en los bits del GUID, rangos de bits fijos, búsqueda O(1), referencias entre repos) forma parte de la solicitud de patente 10 2025 003 091.6. La asignación canónica de bits (offsets/anchos/rangos de valores exactos por segmento) se documenta de forma normativa en la especificación del protocolo specs/v7guid/; véase allí 00_gesamtkarte.md. GCBoK representa esta norma; en caso de divergencias, prevalece la especificación.

Class-Identifier - Registro de segmentos

El Class-Identifier de GitCover (el segmento class del V7GUID) se construye de forma determinista a partir de una jerarquía de negocio de seis niveles. Cada nivel tiene 4 bits de ancho (rango de valores 0–15, es decir, 16 posibles expresiones por nivel) y se asigna globalmente mediante un diccionario normativo en el repositorio .gitcover del directorio TOP. Además, el V7GUID lleva varios campos identificadores ampliados. El siguiente registro enumera todos los segmentos agrupados con su respectivo valor máximo posible y constituye la referencia vinculante para la interoperabilidad entre repositorios de GitCover.

Jerarquía de negocio (clasificación determinista)

La notación de cadena de clasificación combina los seis niveles en L1_L2_L3_L4_L5_L6, p. ej., 1_14_12_14_13_1 (posición de precio de Portfolio). El rango de valores 16⁶ = 16.777.216 cubre todas las clasificaciones deterministas.

La jerarquía de negocio como ontología

Los seis diccionarios (de Entity a Instance) forman juntos la ontología de GitCover: un vocabulario compartido y legible por máquina de la organización: entidades (p. ej., Business Entity, Business Partner), sus relaciones, reglas y clasificaciones. Así, personas, validadores y agentes de IA hablan el mismo idioma: un término como «ERechnung» (ProcessType 13) significa lo mismo en cada repositorio, cada esquema y cada política.

En GitCover, la ontología está implementada de forma nativa en Git, no como una base de datos de grafos en una plataforma:

Microsoft describe su capa semántica como un «governed, self-service knowledge graph» que proporciona a los agentes «shared context»: el mismo espacio de problema (contexto para agentes, términos uniformes), pero resuelto con dependencia de plataforma. GitCover lo resuelve de forma nativa en el repositorio: la ontología es el acervo normativo en el repositorio Git, no un servicio de un proveedor. Detalles sobre la delimitación: Glosario («Ontologie») y Componentes: GCUCB, contexto de mercado.

Campos identificadores ampliados del V7GUID (tipificación de cumplimiento)

Además de la jerarquía de 6 niveles, el V7GUID lleva seis campos identificadores más que pueden asignarse de forma determinista. Son ayudas de categorización/clasificación y tipifican aspectos adicionales de cumplimiento de un justificante. No son, en absoluto, identificadores de instancia de objeto: qué objeto concreto se quiere decir lo indica únicamente el Object ID (el uuidv7 puro) del identificador dual. Muchos objetos comparten el mismo valor de campo identificador.

Nota: VariantId se llamaba antes InstanceId; el nombre se cambió porque el campo tipifica una clase de variante, no una instancia de objeto. GatewayId/VariantId se redujeron con ADR-002 de 16/14 a 8/6 bits para dejar espacio a status y kind; véase specs/v7guid/ADR-002_layout_v2_kind.md.

Así, un único identificador codifica de forma multidimensional qué, dónde, mediante qué, a través de qué punto de control, en qué estado del ciclo de vida y en qué variante se originó un justificante, verificable directamente desde el GUID (O(1), sin consulta a base de datos). Ejemplo de una factura electrónica verificada: 1_14_12_14_13_1 + RepositoryId 3 (DMS) + ProcessTypeId 12 (verificación EN16931) + GatewayId 220 (aprobación de cuatro ojos) + VariantId 10 (conservación de 10 años).

Asignación: Los niveles de 4 bits L1–L6 son canónicos a nivel global y se coordinan exclusivamente mediante los diccionarios del repositorio .gitcover de TOP (intercambio vía GCEP/GCUCB). Para los campos identificadores ampliados rigen diccionarios propios (repository_ids.json, processtype_ids.json, gateway_ids.json, variant_ids.json); el valor más alto de cada uno está reservado como Custom/TenantDefined. Los códigos no asignados quedan libres para una asignación global posterior. Referencia normativa: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Gateway de proceso (pgid) y registro de acciones (261026)

El GatewayId de 8 bits tipifica el punto de control. La identidad completa del gateway de proceso (pgid) es una clase V7GUID compuesta por repository_id + gateway_id (+ época de clase), generada con gc-v7guid class; no es una UUID aleatoria ni se deriva del SHA del documento.

Registro (en dos niveles): OSS/TOP/.gitcover/dictionaries/gateway_ids.json (valores de 8 bits) y <Tenant>/TOP/compliance/process_gateways.json (process_key, uuidV7 = pgid, repository_id, gateway_id). El bloque GCUV 180–189 es provisional hasta la asignación OSS: 180 creación de factura, 181 PDF, 182 verificación, 183 ingesta en DMS, 184 libros, 185 OP.

Separación de roles: produced_by_pgid es la acción productora (p. ej., gc-billing invoice); stored_by_pgid es la acción almacenadora (gc-dms scan --apply). El registro DMS almacena la factura, no la genera. El object_id del DMS es el docUid del sidecar, no una nueva UUID de registro.

Justificante: GCUV/TOP/compliance/{PROCESS_GATEWAYS.md,process_gateways.json}; informe de verificación AFJD/FY2026/reports/261026_pruefung_rechnungsausgang_afjd-ada.md § 8.5.

Registro central de tenants

El TenantId de una entidad jurídica de GitCover no se deriva de un rango de números asignado, sino de forma determinista a partir de los primeros 48 bits (sello de tiempo en milisegundos) de la UUIDv7 que se genera al crear por primera vez el directorio TOP del tenant. El identificador de tenant queda así vinculado al tiempo, es ordenable y único sin una base de datos de secuencias central, siempre que no se creen dos tenants en el mismo instante de milisegundo.

Fuente de tiempo libremente elegible: El sello de tiempo de 48 bits no tiene que ser el momento real de creación. En lugar de la hora del sistema (DateTime.Now), cada tenant puede generar la UUIDv7 a partir de un instante especificado explícitamente, por ejemplo, la fecha de constitución de la entidad jurídica o cualquier otra fecha de referencia elegida (cf. CustomEpoch/timestamp en el TenantContext). Así, el identificador de tenant puede vincularse a una fecha relevante desde el punto de vista profesional; la unicidad se mantiene siempre que el instante en milisegundos elegido no colisione entre tenants (otra razón para el registro voluntario).

Dado que los repositorios de GitCover se referencian entre sí mediante travesías de others.json (resolución entre repos de rutas físicas y lógicas), un identificador de tenant debe poder resolverse de forma única cuando se usa entre repositorios. Por ello existe un registro central y voluntario.

Modelo de registro (voluntario, sin rangos de números)

• No hay rangos de números reservados. Dado que el TenantId surge del sello de tiempo de 48 bits, no existe ni un círculo de números «público» ni «privado»; la distinción radica únicamente en la inclusión en el registro.
• Voluntariedad. El registro es opcional. Quien necesite interoperabilidad entre repositorios y ausencia de colisiones para travesías de others.json, registra su tenant públicamente.
• Inmutabilidad. Un identificador de tenant registrado es final y estable; no se reutiliza tras su disolución (estado ARCHIVED).

Instancia canónica del registro: El registro operativo de tenants se mantiene en el root de cada tenant bajo .gitcover/access/TENANT_GUID_REGISTER.md (nombre corto · entidad jurídica · UUIDv7 · sello de tiempo · estado). Es la lista determinante de tenants registrados.

Cadenas de justificantes (Evidence Chains)

Una cadena de justificantes encadena artefactos de cumplimiento mediante referencias prev-hash:

1. Justificante B1 - V7GUID: ...-PERSON-..., SHA256: 3f2a1c..., prev: -
2. Justificante B2 - V7GUID: ...-INVOICE-..., SHA256: 7d4e2f..., prev: 3f2a1c...
3. Justificante B3 - V7GUID: ...-PAYMENT-..., SHA256: 1b8f90..., prev: 7d4e2f...

Cada justificante referencia el hash SHA-256 de su predecesor. Toda la cadena queda así anclada criptográficamente y protegida contra manipulación.

Esquema de metadatos (artefacto de datos .gc.md)

El artefacto de datos aparece como bloque JSON al final del documento (primero legible por humanos, datos al final):

{
  "docUid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "v7guid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "class": "INVOICE",
  "sha256": "7d4e2f...",
  "prev_sha256": "3f2a1c...",
  "gpg_fingerprint": "ABCD1234...",
  "timestamp_iso": "2026-06-14T11:18:00+02:00",
  "gobd_periode": "FY2026"
}

Originales binarios y sidecars de GitCover

Los justificantes que existen como archivo binario (PDF, DOCX, EML, imagen) no pueden llevar metadatos dentro de Git. Se enganchan a la cadena de justificantes mediante un sidecar de GitCover (*.gc.md junto al original): el sidecar contiene como mínimo el sha256 del original, así como el DocID (uuidv7, identificador de instancia) y el v7guid categorizado (contexto). El proceso y la asignación del DocID a partir del sello de tiempo del archivo se describen en Eje 5: Procedimientos; para el registro de tenant correspondiente, véase Registro central de tenants arriba. Para la delimitación vale lo siguiente: docUid (instancia), sha256 (contenido), V7GUID (clase) y GCPN-docUid (expediente) son ejes separados; solo el docUid del documento se convierte en el object_id del DMS.

Detección de metadatos y variantes companion

La detección de metadatos de documentos está impulsada por el contenido, no por la extensión. Un documento original tiene metadatos si una instancia de esquema JSON incrustada los describe:

1. Sidecar base <artefakt>.<orig-ext>.gc.md: la instancia lleva docUid (instancia de documento), sha256 (ancla de contenido), v7guid (clase) y locations; el docUid es el object_id del documento.
2. Variante companion *.gcsig.md con bloque source integrado: el GCSIG es un artefacto de firma con su propio docUid; la instancia de documento figura en source.v7g_docUid, el ancla de contenido en subject.sha. El DMS adopta source.v7g_docUid como object_id del documento y registra el docUid del GCSIG solo como GCSIG:<docUid> en las referencias de metadatos.

A lo largo de la vida de un documento o expediente, los meta-documentos pueden cambiar su rol y, con ello, su perfil, de forma análoga a las variantes OOD (sobrecarga/polimorfismo): la base del sidecar (.gc.md) pasa a ser un artefacto de firma (.gcsig.md con source); GCPN (.gcpn.md) sigue siendo el expediente y se complementa de forma aditiva mediante documents[]/children[]/relations[]; los anclas GCAL (GCPN bajo .gitcover/gcal/<uuidV7>.gcpn.md) siguen siendo anclas de proceso. Un cambio de nombre no altera la identidad del meta-documento (docUid/expediente permanecen), pero sí el SHA-256 del archivo; una transformación del proceso puede renombrar o crear de nuevo y fusionar los datos existentes. Lo decisivo es la identidad del contenido, no el nombre del archivo.

Contenedor de expediente (.gcpn.md) — nivel de proceso de la cadena de justificantes

Junto a la catalogación mediante sidecar aparece el contenedor GCPN para expedientes de varias etapas (p. ej., la creación y firma de un GVB): un .gcpn.md junto al Referenced-Doc (<Referenced-Doc-Basisname>.gcpn.md), que acompaña al proceso como documento original de proceso autónomo, no como sidecar del Referenced-Doc. Conceptualmente:

• Documento mutable con artefactos JSON inmutables (esquema gcpn-container-2.7, self-contained): referenced_doc, actor, retention se describen una sola vez cada uno; árbol mediante parents[]/children[]/documents[]; las demás referencias pasan por SHA-256 o actor_ref — sin redundancia interna.
• Eventos como enum de flags con resultado: offered(1), accepted(2), denied(4), sign(8), withdraw(16) — los pasos recorridos dan como resultado la máscara de bits events_result (p. ej., 11 = offered + accepted + sign) con confirmación chain_valid del encadenamiento de hashes.
• Complementar en lugar de crear de nuevo: Cada nuevo paso del proceso establece el flag, incorpora el nuevo artefacto y actualiza summary; los artefactos JSON ya incorporados permanecen sin cambios (inmutables). El historial del contenedor reside, a prueba de auditoría, en la historia de Git del repositorio.
• JSON siempre incorporado (bloque MD) — sin archivos .json independientes en el árbol del repositorio (evitar bloat).
• Función de índice de GCDMS: En el DMS opcionalmente conectado, el contenedor sirve como índice para la navegación de procesos hacia los documentos individuales — en lugar de n8n u otros motores de workflow similares.

Un Referenced-Doc firmado pasa después a ser inmutable (GoBD: inmutabilidad); el contenedor permanece mutable y sigue documentando el proceso; la historia de Git es la prueba.

GCPN de archivo único — seguimiento progresivo/retrógrado de justificantes (AO, 261026)

Para facturas y otros justificantes, el GCPN se convierte en un contenedor de archivo único: un .gcpn.md lleva documents[] (XML como documento original, PDF como vista), el workflow create→pdf→present→accept→sign→register, events, properties.values y relations (contrato/justificantes de costes). XML/PDF siguen siendo artefactos separados; se elimina un .gc.md separado: el GCPN contiene docUid, SHA-256, ruta y título.

Así, el GCPN es el único punto de fusión para la UI y el tooling; la SAGA (creación, presentación, aceptación, firma, registro) reside por completo en el contenedor. Referencia normativa: specs/v7guid/70_belegkreise-dokumentenzuordnung.de.md § «Ein-Datei-GCPN».

Regla de promoción: Un .gc.md existente puede enriquecerse en el GCPN; los artefactos JSON del sidecar se incorporan (GCPN = superconjunto, .gc.md = subconjunto). Después, el .gc.md separado es redundante y puede eliminarse del sistema de archivos; la historia de Git aporta la trazabilidad (GoBD), el GCPN sigue siendo la SSoT.

Gates/OPA: workflow.gates[].id es una uuidV7 de la acción/método (join GCAL/GCEP), workflow.gates[].rule la policy_uuid de la identidad OPA/regla; ambas están registradas (GCUV/TOP/compliance/gates.json o policies/registry.json). rule_text es solo la visualización; las clases/tipos pasan por los catálogos V7GUID.

Immutable Collections: Las definiciones inmutables (ENUM/UNION/Flags) se encuentran en OSS/TOP/.gitcover/dictionaries/immutable_collections.json y se cargan una vez durante la inicialización del sistema. El GCPN las referencia mediante events.enum_ref (uuidV7) en lugar de repetirlas; el esquema 2.7 hace que enum_definition sea opcional (legacy). Los flags resultan de los catálogos OSCAL para GoBD/AO (perfil gcpn-compliance-profile.yaml; AO §146, GoBD Rz. 146/147); el anclaje de gobernanza figura en el registro.

Identidad de factura: properties.values.invoice_id es la uuidV7 del Invoice Identifier; invoice_no es solo texto y no un criterio de ordenación. Seller/Buyer se referencian mediante su Party-uuidV7 (creditor/vendor o debitor/customer), no mediante nombres reales (PII).

GCPN como protocolo — el acto como transición de estado

Un GCPN es una forma de protocolo. En el GCBoK, con Compliance como tema principal, se habla a menudo de juntas de socios con resoluciones, que se resumen en un GVB:

Esta doble interpretación (protocolo + transición de estado) es el núcleo de la demostrabilidad: cada acto se describe de forma determinista; el estado anterior puede demostrarse mediante la cadena SHA-256 (sidecars, Referenced-Doc), y el estado posterior mediante la expresión de flags y el artefacto incorporado. La historia de Git del contenedor proporciona la cronología. Procedimiento y verificación: Eje 3 (GCPN) y Firma digital (DS02–DS05).

Cadena de evidencia criptográfica

La cadena de evidencia criptográfica combina tres primitivas criptográficas:

1. Hash de commit de Git - inmutabilidad del estado del repositorio
2. Firma GPG - identidad del actor (¿quién decidió?)
3. V7GUID - direccionamiento determinista (qué y cuándo)

Así surge una cadena que está tanto criptográficamente anclada como ordenable temporalmente: la base para pruebas de cumplimiento a prueba de auditoría.

Recovery-Fallback: al final solo quedan repositorios Git En caso de catástrofe, pérdida de infraestructura o auditoría 10 años después, el último conjunto de artefactos funcional es el propio repositorio Git (o git bundle/exportación ZIP). Contiene: artefactos de código, registros/diccionarios de .gitcover/ (JSON/JSONL), llaveros GPG (.gitcover/keys/), cadenas de justificantes V7GUID. No se requieren bases de datos, servidores web ni servicios en ejecución. La forense es el repositorio Git; los paquetes de verificación HTML son solo derivados de presentación (véase Procedimientos: Audit-Readiness).

Ramificación determinista

La ramificación determinista permite vincular cadenas de justificantes a estructuras de repositorios Git. Mediante la combinación de:

• Repositorios Git como periodos de cumplimiento (p. ej., FY2026)
• Clases V7GUID como tipos de documento (INVOICE, PAYMENT, PERSON)
• Políticas OPA como hooks pre-receive (validación antes del commit)

surgen estructuras de cumplimiento reproducibles y auditables, sin mantenimiento manual posterior.

Véase también: Las primitivas técnicas (GPG, uuidV7, OSCAL) se profundizan en Eje 4: Técnicas.