Eje 2: Conceptos

V7GUID - Version-7-GUID

V7GUID (también: Categorized UUIDv7 Identifier) es un esquema de categorización para identificadores en artefactos GitCover, basado en 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 (MESZ, MEZ, 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. Las horas locales (cambios de horario de verano, límites de zonas horarias) no distorsionan la ordenabilidad ni la comparabilidad.
• Convertibilidad: cualquier app puede convertir en cualquier momento la marca de tiempo UTC a la zona horaria local del usuario - en particular las apps que deben llevar 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) exigen 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 la época Unix (UTC); toda generación que se desvíe de ello viola el estándar.

Regla de detección: 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 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 los bits de la GUID, rangos de bits fijos, lookup 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 mantiene con carácter normativo en la especificación del protocolo specs/v7guid/ - véase allí 00_gesamtkarte.md. El 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) 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 valores posibles 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 caracterización 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 GitCover.

Jerarquía de negocio (clasificación determinista)

La notación Classification-String 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 (de Entity a Instance) forman en conjunto la GitCover-Ontología: un vocabulario compartido y legible por máquina de la organización — entidades (p. ej. Business Entity, Business Partner), sus relaciones, reglas y clasificaciones. Con ello, personas, validadores y agentes de IA hablan el mismo idioma: un término como „ERechnung" (ProcessType 13) significa lo mismo en cada repo, en cada esquema y en cada política.

En GitCover, la ontología está implementada de forma nativa en Git — no como 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 problemas (contexto de agentes, términos unificados), pero resuelto de forma ligada a la plataforma. GitCover lo resuelve de forma nativa en el repo: La ontología es el corpus normativo en el repositorio Git, no un servicio de un proveedor. Detalles sobre la delimitación: Glosario („Ontología") y Componentes: GCUCB, contexto de mercado.

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

Además de la jerarquía de 6 niveles, la V7GUID incorpora seis campos extendidos más, asignables de forma determinista. Son ayudantes de categorización/clasificación y tipifican aspectos de cumplimiento adicionales de un documento. Explícitamente no son identificadores de instancia de objeto - a qué objeto concreto se refiere lo dice únicamente el Object ID (el uuidv7 puro) del identificador dual. Muchos objetos comparten el mismo valor de campo.

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 de 16/14 a 8/6 bits con ADR-002 para dejar sitio 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 y en qué variante se originó un documento - verificable directamente a partir de la GUID (O(1), sin consulta a la 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 a través de los diccionarios del repo TOP-.gitcover (intercambio vía GCEP/GCUCB). Para los campos extendidos se aplican 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.

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

Además de la jerarquía de 6 niveles, la V7GUID lleva otros seis campos de caracterización 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 de caracterización.

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

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é modalidad se originó 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 (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 a través de los diccionarios del repo .gitcover de TOP (intercambio vía GCEP/GCUCB). Para los campos de caracterización 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 GitCover no se deriva de una serie numérica asignada, sino de forma determinista 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 - mientras no surjan dos Tenants en el mismo instante de milisegundos.

Fuente de tiempo de libre elección: 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 (cf. CustomEpoch/Timestamp en el TenantContext). Así, el identificador de Tenant puede vincularse a una fecha con relevancia de negocio; la unicidad se mantiene mientras el instante en milisegundos elegido no colisione entre Tenants (otro motivo para el registro voluntario).

Dado que los repos GitCover se referencian 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 unívoca en el uso entre repos. Por eso existe un registro central, voluntario.

Modelo de registro (voluntario, sin rangos de numeración)

• Sin rangos de numeración 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 radica únicamente en la constancia en el registro.
• Voluntariedad. El registro es opcional. Quien necesite interoperabilidad entre repos y ausencia de colisiones para los recorridos de 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 de Tenants operativo se mantiene en el Tenant-Root respectivo 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 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 se presentan 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 como mínimo 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; en cuanto al registro de Tenant correspondiente, véase Registro central de Tenants más arriba.

Contenedor de expedientes (.gcpn.md) — Nivel de proceso de la cadena de comprobantes

Junto a la catalogación por sidecar se añade el contenedor GCPN para expedientes de varias etapas (p. ej., la creación y firma de una GVB): un .gcpn.md junto al Referenced-Doc (<Referenced-Doc-Basisname>.gcpn.md) que acompaña al proceso como Prozess-Ur-Doc independiente — no como sidecar del Referenced-Doc. Conceptualmente:

• Doc mutable con artefactos JSON inmutables (esquema gcpn-container-1.0): referenced_doc, actor, retention se describen una sola vez; las demás 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 conforman la máscara de bits events_result (p. ej., 11 = offered + accepted + sign) con la confirmación chain_valid del encadenamiento de hashes.
• Ampliar en lugar de crear de nuevo: cada nuevo paso del proceso activa el flag, incrusta el nuevo artefacto y actualiza summary; los artefactos JSON ya incrustados permanecen inalterados (immutable). La historia del contenedor queda 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 el bloating).
• Función de índice GCDMS: en el DMS acoplado opcionalmente, 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 se convierte después en immutable (GoBD: inalterabilidad); el contenedor permanece mutable y sigue documentando el proceso — la historia de Git es la prueba.

GCPN como acta — el Act como transición de estado

Un GCPN es una forma de acta. En el GCBoK, con el compliance como tema principal, se habla a menudo de asambleas de socios con acuerdos que se resumen en un GVB:

Esta doble interpretación (acta + transición de estado) es el núcleo de la demostrabilidad: cada Act está descrito 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 decidió?)
3. V7GUID - Direccionamiento determinista (Qué y Cuándo)

Así se forma una cadena que está anclada criptográficamente y es ordenable temporalmente - la base para evidencias de cumplimiento a prueba de auditoría.

Recovery-Fallback: al final solo quedan los repos Git Ante una catástrofe, la 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). Incluye: artefactos de código, registros/diccionarios .gitcover/ (JSON/JSONL), keyrings 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 Git — los paquetes HTML para auditores 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)
• Policies de OPA como hooks de pre-receive (validación antes del commit)

se generan 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.