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), extendido con una clasificación de clases específica de GitCover.

Estructura

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

Base temporal: GMT/UTC (regla normativa)

Los sellos de tiempo de 48 bits de todas las V7GUID y uuidV7 deben generarse e interpretarse siempre sobre la base GMT/UTC (desplazamiento 0) - nunca sobre la base de una zona horaria local (CEST, CET, etc.):

Justificación:

• Neutralidad de zona horaria: Un sello de tiempo basado en UTC es interpretable de forma inequívoca a nivel mundial. Los cambios de hora local (cambio de hora de verano, fronteras de zonas horarias) no distorsionan la ordenabilidad ni la comparabilidad.
• Convertibilidad: Cualquier aplicación puede convertir el sello de tiempo UTC a la zona horaria local del usuario en cualquier momento - en particular las aplicaciones que deben llevar una marca temporal (p. ej. registro de horas de empleados, justificación de tiempo de trabajo, seguimiento de plazos). El camino inverso (tiempo local como base) conduce a ambigüedades (cambio de hora de verano: 03:00 CEST = 01:00 UTC existe dos veces).
• Conformidad GoBD: La oportunidad temporal y la trazabilidad (§ 146 AO) requieren una base temporal inmutable e inequívoca. UTC es la única base que garantiza esta propiedad de forma sistémica.
• Coherencia con RFC 9562: El estándar UUIDv7 define el sello de tiempo como milisegundos de la época Unix (UTC); cualquier generación que se desvíe de esto viola el estándar.

Regla de reconocimiento: Al decodificar una 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 de V7GUID (jerarquía de 6 niveles en bits de GUID, rangos de bits fijos, búsqueda O(1), referencias entre repos) es parte de la solicitud de patente 10 2025 003 091.6. La asignación de bits canónica (desplazamientos/anchos/rangos de valores exactos por segmento) se gestiona normativamente en la especificación de protocolo specs/v7guid/ - ver allí 00_gesamtkarte.md. GCBoK representa esta norma; en caso de desviaciones, prevalece la especificación.

Class-Identifier - Registro de segmentos

El Class-Identifier de GitCover (el segmento class de la V7GUID) se construye de forma determinista a partir de una jerarquía empresarial 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 de identificación extendidos. El siguiente registro enumera todos los segmentos agrupados con su valor máximo posible y constituye la referencia vinculante para la interoperabilidad entre repos de GitCover.

Jerarquía empresarial (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.

Campos de identificación extendidos de la V7GUID (tipificación de cumplimiento)

Además de la jerarquía de 6 niveles, la V7GUID lleva cuatro campos de identificación adicionales asignables de forma determinista. Son ayudas de categorización/clasificación y tipifican aspectos adicionales de cumplimiento de una evidencia. Son explícitamente identificadores de instancia de objeto - qué objeto concreto se refiere lo indica únicamente el Object ID (el uuidv7 puro) del identificador dual. Muchos objetos comparten el mismo valor de campo de identificación.

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

De este modo, un único identificador codifica multidimensionalmente qué, dónde, por medio de qué, a través de qué punto de control y en qué variación se generó una evidencia - 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 a 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 en el repo .gitcover del TOP (intercambio vía GCEP/GCUCB). Para los campos de identificación extendidos se aplican diccionarios propios (repository_ids.json, processtype_ids.json, gateway_ids.json, variant_ids.json); el valor más alto se reserva como Custom/TenantDefined. Los códigos no asignados permanecen libres para una asignación global futura. Referencia normativa: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Registro central de tenants

La TenantId de una entidad legal de GitCover no se deriva de un rango de números asignado, sino que se genera de forma determinista a partir de los primeros 48 bits (sello de tiempo en milisegundos) de la UUIDv7, que se crea en el primer momento de creación del directorio TOP del tenant. El identificador de tenant es, por tanto, ligado al tiempo, ordenable e inequívoco sin una base de datos de secuencias centralizada - siempre que no se creen dos tenants en el mismo instante de milisegundos.

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 momento explícitamente predefinido - por ejemplo, la fecha de fundación de la entidad legal o una fecha de referencia elegida de cualquier otra manera (ver CustomEpoch/Timestamp en TenantContext). De este modo, el identificador de tenant puede vincularse a una fecha de relevancia profesional; la inequívocidad se mantiene siempre que el punto de tiempo en milisegundos elegido no colisione entre tenants (otro motivo para el registro voluntario).

Dado que los repos de GitCover se refieren entre sí mediante recorridos de others.json (resolución entre repos de rutas físicas y lógicas), un identificador de tenant debe ser resoluble de forma inequívoca en un 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 del sello de tiempo de 48 bits, no existe un rango de números "público" ni "privado" - la distinción reside únicamente en la gestión en el registro.
• Voluntariedad. El registro es opcional. Quien necesite interoperabilidad entre repos y ausencia de colisiones para recorridos de others.json registra su tenant públicamente.
• Inmutabilidad. Un identificador de tenant registrado es final y estable; no se reutiliza tras la disolución (estado ARCHIVED).

Instancia canónica del registro: El registro operativo de tenants se gestiona en la raíz del tenant correspondiente bajo .gitcover/access/TENANT_GUID_REGISTER.md (nombre corto · entidad legal · UUIDv7 · sello de tiempo · estado). Es la lista determinante de tenants registrados.

Cadenas de evidencias (Evidence Chains)

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

1. Evidencia B1 - V7GUID: ...-PERSON-..., SHA256: 3f2a1c..., prev: -
2. Evidencia B2 - V7GUID: ...-INVOICE-..., SHA256: 7d4e2f..., prev: