Eje 2: Conceptos

V7GUID - GUID de versión 7

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 (basado en tiempo, ordenable), ampliado con una clasificación de clases específica de GitCover.

Estructura

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

Base temporal: GMT/UTC (regla normativa)

Las marcas de tiempo de 48 bits de todos los V7GUID y uuidV7 deben generarse e interpretarse siempre sobre la base de GMT/UTC (offset 0) — nunca sobre la base de una zona horaria local (CEST, CET, etc.):

Justificación:

• Neutral respecto a la zona horaria: Una marca de tiempo basada en UTC es interpretable de forma inequívoca en todo el mundo. Los indicadores horarios locales (cambios de horario de verano, límites de zonas horarias) no distorsionan la ordenabilidad ni la comparabilidad.
• Convertibilidad: Cualquier app puede convertir la marca de tiempo UTC en cualquier momento a la zona horaria local del usuario — en particular las apps que deben llevar una marca temporal (p. ej. registro de tiempos para empleados, comprobantes de tiempo de trabajo, seguimiento de plazos). El camino inverso (hora local como base) conduce a ambigüedades (cambio de 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 unívoca. UTC es la única base que garantiza esta propiedad de forma sistémica.
• Consistencia con RFC 9562: El estándar UUIDv7 define la marca de tiempo como milisegundos Unix-Epoch (UTC); cualquier generación que difiera 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 app, nunca en la base del identificador.

Norma e implementación: El principio V7GUID (jerarquía de 6 niveles en bits GUID, rangos de bits fijos, búsqueda O(1), referencias cross-repo) es 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 lleva de forma normativa en la especificación de 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 valores por nivel) y se asigna globalmente mediante un diccionario normativo en el repo .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 repos 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.

Jerarquía de negocio como ontología

Los seis diccionarios (Entity hasta 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 «factura electrónica» (ProcessType 13) significa lo mismo en cada repo, cada esquema y cada política.

La ontología está realizada en GitCover de forma nativa de Git — no como una base de datos de grafos en una plataforma:

Microsoft describe su capa semántica como «governed, self-service knowledge graph», que proporciona a los agentes «shared context» — el mismo espacio de problemas (contexto de agentes, términos uniformes), pero resuelto de forma ligada a la plataforma. GitCover lo resuelve de forma nativa de repo: La ontología es el acervo normativo en el repo de Git, no un servicio de un proveedor. Detalles sobre la delimitación: Glosario («Ontología») 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 de cumplimiento adicionales de un comprobante. No son explícitamente identificadores de instancia de objeto — qué objeto concreto se designa lo dice ú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.

Así, un único identificador codifica de forma multidimensional qué, dónde, mediante qué, a través de qué punto de control y en qué variante surgió un comprobante — 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 globales y se coordinan exclusivamente mediante los diccionarios en el repo .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 en cada caso está reservado como Custom/TenantDefined. Los códigos no asignados permanecen libres para una asignación global posterior. Referencia normativa: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Registro central de tenants

La 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 (marca de tiempo en milisegundos) del 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 unívoco sin una base de datos de secuencia central — siempre que no surjan dos tenants en el mismo instante en milisegundos.

Fuente temporal de libre elección: La marca 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 el UUIDv7 a partir de un momento explícitamente predeterminado — por ejemplo, la fecha de constitución de la entidad jurídica o una fecha de referencia elegida arbitrariamente de otro modo (cf. CustomEpoch/Timestamp en el TenantContext). Así, el identificador de tenant puede vincularse a una fecha relevante desde el punto de vista funcional; 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 repos de GitCover se referencian entre sí mediante travesías others.json (resolución cross-repo de rutas físicas y lógicas), un identificador de tenant debe poder resolverse de forma unívoca en el uso entre repos. Por eso existe un registro central y voluntario.

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

• No hay rangos de números reservados. Dado que la TenantId surge de la marca de tiempo de 48 bits, no existe ni un rango de números «público» ni uno «privado» — la distinción reside únicamente en la inclusión en el registro.
• Voluntariedad. El registro es opcional. Quien necesite interoperabilidad entre repos y ausencia de colisiones para travesías 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 lleva en el respectivo tenant root bajo .gitcover/access/TENANT_GUID_REGISTER.md (nombre corto · entidad jurídica · UUIDv7 · marca de tiempo · estado). Es la lista determinante de tenants registrados.

Cadenas de comprobantes (Evidence Chains)

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

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

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

Esquema de metadatos (.v7g.md)

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 V7GUID

Los comprobantes que existen como archivo binario (PDF, DOCX, EML, imagen) no pueden llevar metadatos internamente en Git. Se insertan en la cadena de comprobantes mediante un sidecar V7GUID (*.v7g.md junto al original): el sidecar contiene al menos el sha256 del original, así como el DocID (uuidv7, identificador de instancia) y el v7guid categorizado (contexto). El proceso y la asignación de DocID a partir de la marca de tiempo del archivo se describen en Eje 5: Procedimientos; para el registro de tenant correspondiente, véase Registro central de tenants arriba.

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

Junto a la catalogación por 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 independiente — no como sidecar del Referenced-Doc. Conceptualmente:

• Mutable Doc con artefactos JSON inmutables (esquema gcpn-container-2.4, autocontenido): referenced_doc, actor, retention se describen una sola vez; árbol mediante parents[]/children[]/documents[]; otras referencias se realizan mediante 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 hash.
• Complementar en lugar de crear de nuevo: Cada nuevo paso del proceso establece el flag, incrusta el nuevo artefacto y actualiza summary; los artefactos JSON ya incrustados permanecen sin cambios (inmutables). La historia del contenedor reside, a prueba de auditoría, en la historia de Git del repo.
• JSON siempre incrustado (MD-Fence) — sin archivos .json independientes en el árbol del repo (evitar hinchazón).
• Función de índice GCDMS: En el DMS opcionalmente acoplado, el contenedor sirve como índice para la navegación de procesos hacia los documentos individuales — en lugar de n8n o motores de workflow similares.

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

GCPN como protocolo — el Act 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 capacidad de prueba: cada Act se describe de forma determinista — el estado anterior es demostrable mediante la cadena SHA-256 (sidecars, Referenced-Doc), el estado posterior mediante la expresión de flags y el artefacto incrustado. La historia de Git del contenedor proporciona la cronología. Procedimiento y verificación: Eje 3 (GCPN) y Firma digital (DS02–DS05).

Cryptographic Evidence Chain

La Cryptographic Evidence Chain combina tres primitivas criptográficas:

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

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

Recovery-Fallback: Al final solo quedan repos de 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 de Git (o git bundle/exportación ZIP). Contiene: artefactos de código, registros/diccionarios .gitcover/ (JSON/JSONL), llaveros GPG (.gitcover/keys/), cadenas de comprobantes V7GUID. No se requiere base de datos, ni servidor web, ni servicios en ejecución. La forense es el repo de Git — los paquetes de verificación HTML son solo derivados de presentación (véase Procedimientos: Audit-Readiness).

Bifurcación determinista

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

• Repositorios de 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 aptas para auditoría — sin mantenimiento manual posterior.

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