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 la UUID versión 7 compatible con RFC 4122 (basada en el 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: oportunidad temporal) sin una base de datos de secuencias centralizada.

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 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 unívoca en todo el mundo. Los tiempos locales (cambio de horario de verano, límites de zonas horarias) no distorsionan la ordenabilidad ni la comparabilidad.
• Convertibilidad: Cada app puede convertir la marca de tiempo UTC en cualquier momento a la zona horaria local del usuario - en particular las apps que deben mantener una marca de tiempo (p. ej., registro de tiempo de empleados, justificantes de tiempo de trabajo, seguimiento de plazos). El camino inverso (hora local como base) conduce a ambigüedades (cambio al horario de verano: 03:00 CEST = 01:00 UTC existe dos veces).
• Conformidad con GoBD: La oportunidad 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.
• Coherencia con RFC 9562: El estándar UUIDv7 define la marca de tiempo como milisegundos desde Unix-Epoch (UTC); toda generación que se desvíe de ello viola 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/el procesamiento posterior en hora local tiene lugar 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 los bits del GUID, rangos de bits fijos, búsqueda O(1), referencias cross-repo) 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 mantiene con carácter normativo en la especificación del protocolo specs/v7guid/ - véase allí 00_gesamtkarte.md. GCBoK representa esta norma; en caso de desviaciones rige la especificación.

Class-Identifier - Registro de segmentos

El Class-Identifier de GitCover (el segmento class de la V7GUID) está construido 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, la V7GUID lleva varios campos 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 (Portfolio-Preisposition). El rango de valores 16⁶ = 16.777.216 cubre todas las clasificaciones deterministas.

Campos ampliados de la V7GUID (tipificación de cumplimiento)

Además de la jerarquía de 6 niveles, la V7GUID lleva cuatro campos ampliados más asignables de forma determinista. Son auxiliares de categorización/clasificación y tipifican aspectos de cumplimiento adicionales de un comprobante. Expresamente no son identificadores de instancia de objeto - qué objeto concreto se entiende lo dice únicamente el Object ID (el uuidv7 puro) del identificador dual. Muchos objetos comparten el mismo valor de campo ampliado.

Nota: VariantId se llamaba antes InstanceId; el nombre se cambió porque el campo tipifica una clase de variante, no una instancia de objeto.

Con ello, 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 la 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 (retenció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 del repo .gitcover del TOP (intercambio vía GCEP/GCUCB). Para los campos 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.

Registro central de tenants

La TenantId de una entidad jurídica de GitCover no se deriva de una serie numérica asignada, sino de forma determinista a partir de los primeros 48 bits (marca de tiempo en milisegundos) de la UUIDv7 que se genera al crear por primera vez el directorio TOP del tenant. El identificador de tenant es así ligado al tiempo, ordenable y unívoco sin una base de datos de secuencias centralizada - siempre que no surjan dos tenants en el mismo instante de milisegundos.

Fuente de tiempo libremente elegible: La marca de tiempo de 48 bits no tiene por qué 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 momento explícitamente predefinido - por ejemplo, la fecha de fundación de la entidad jurídica o cualquier otra fecha de referencia elegida de forma distinta (véase CustomEpoch/Timestamp en el TenantContext). Así, el identificador de tenant puede vincularse a una fecha con relevancia funcional; la unicidad se mantiene mientras el instante de milisegundos elegido no colisione entre tenants (otra razón más para el registro voluntario).

Dado que los repos de GitCover se referencian entre sí mediante recorridos 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, voluntario.

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

• Sin rangos de números reservados. Dado que la TenantId surge de la marca de tiempo de 48 bits, no existe ni una serie numérica «pública» ni una «privada» - la distinción reside únicamente en la inscripción en el registro.
• Voluntariedad. El registro es opcional. Quien necesite interoperabilidad entre repos y ausencia de colisiones para los recorridos others.json registra su tenant públicamente.
• Inmutabilidad. Un identificador de tenant registrado es definitivo y estable; sin reutilización tras la disolución (estado ARCHIVED).

Instancia canónica del registro: El registro operativo de tenants se mantiene en la raíz de cada tenant bajo .gitcover/access/TENANT_GUID_REGISTER.md (nombre corto · entidad jurídica · UUIDv7 · marca de tiempo · estado). Es la lista autoritativa de los 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 a prueba de 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 incorporan a la cadena de comprobantes mediante un sidecar V7GUID (*.v7g.md junto al original): el sidecar contiene al menos el sha256 del original, así como la DocID (uuidv7, identificador de instancia) y la v7guid categorizada (contexto). El proceso y la asignación de la DocID a partir de la marca de tiempo del archivo se describen en Eje 5: Procedimientos; el registro de tenant correspondiente, véase Registro central de tenants más arriba.

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 decidió?)
3. V7GUID - Direccionamiento determinista (Qué y Cuándo)

Así se crea una cadena que está tanto anclada criptográficamente como ordenable en el tiempo - la base para justificantes de cumplimiento a prueba de auditoría.

Fallback de recuperación: al final solo quedan los repos de Git En caso de catástrofe, pérdida de infraestructura o una auditoría 10 años después, el último conjunto de artefactos funcional es el propio repositorio Git (o un git bundle/exportación ZIP). Esto incluye: 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. El análisis forense es el repo de 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 comprobantes 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 de 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.