Axis 2: Concepts

V7GUID - Version-7-GUID

V7GUID (also: Categorized UUIDv7 Identifier) is a categorization scheme for identifiers in GitCover artifacts, based on RFC-4122-compliant UUID Version 7 (time-based, sortable), extended by a GitCover-specific class classification.

Structure

Purpose: Deterministic, sortable linking of records in a record chain. Enables temporal/versioned reconstructability (GoBD: timeliness) without a central sequence database.

Time Base: GMT/UTC (normative rule)

The 48-bit timestamps of all V7GUIDs and uuidV7s must be generated and interpreted always on the basis of GMT/UTC (offset 0) - never on the basis of a local time zone (CEST, CET, etc.):

Rationale:

• Time-zone-neutral: A UTC-based timestamp is unambiguously interpretable worldwide. Local time markers (daylight saving time changes, time zone boundaries) do not distort sortability and comparability.
• Convertibility: Any app can convert the UTC timestamp into the user's local time zone at any time - especially apps that must maintain a time mark (e.g., employee time tracking, working time records, deadline tracking). The reverse approach (local time as the basis) leads to ambiguities (daylight saving time changeover: 03:00 CEST = 01:00 UTC exists twice).
• GoBD compliance: Timeliness and traceability (§ 146 AO) require an immutable, unambiguous time base. UTC is the only basis that systemically guarantees this property.
• Consistency with RFC 9562: The UUIDv7 standard defines the timestamp as Unix epoch milliseconds (UTC); any generation deviating from this violates the standard.

Detection rule: When decoding a V7GUID/uuidV7, the extracted 48-bit value must always be read as UTC. Display/further processing in local time takes place exclusively in the app's presentation layer, never in the identifier base.

Norm & implementation: The V7GUID principle (6-level hierarchy in GUID bits, fixed bit ranges, O(1) lookup, cross-repo references) is part of the patent application 10 2025 003 091.6. The canonical bit assignment (exact offsets/widths/value ranges per segment) is normatively maintained in the protocol specification specs/v7guid/ - see 00_gesamtkarte.md there. GCBoK represents this norm; in the event of deviations, the specification prevails.

Class Identifier - Segment Register

The GitCover Class Identifier (the class segment of the V7GUID) is built deterministically from a six-level business hierarchy. Each level is 4 bits wide (value range 0–15, i.e., 16 possible values per level) and is assigned globally via a normative dictionary in the .gitcover repo of the TOP directory. In addition, the V7GUID carries several extended attribute fields. The following register lists all segments grouped with their respective maximum possible value and constitutes the binding reference for interoperability between GitCover repos.

Business Hierarchy (deterministic classification)

The classification string notation combines the six levels into L1_L2_L3_L4_L5_L6 - e.g., 1_14_12_14_13_1 (portfolio price position). The value range 16⁶ = 16.777.216 covers all deterministic classifications.

Extended Attribute Fields of the V7GUID (Compliance Typing)

In addition to the 6-level hierarchy, the V7GUID carries four further deterministically assignable attribute fields. They are categorization/classification aids and characterize additional compliance aspects of a record. They are expressly not object instance identifiers - which concrete object is meant is indicated solely by the Object ID (the pure uuidv7) of the dual identifier. Many objects share the same attribute field value.

Note: VariantId was formerly named InstanceId; the name was changed because the field types a variant class, not an object instance.

A single identifier thus encodes multidimensionally what, where, by what means, via which control point, and in which variant a record was created - verifiable directly from the GUID (O(1), without a database query). Example of a validated e-invoice: 1_14_12_14_13_1 + RepositoryId 3 (DMS) + ProcessTypeId 12 (EN16931 validation) + GatewayId 220 (four-eyes approval) + VariantId 10 (10-year retention).

Assignment: The 4-bit levels L1–L6 are globally canonical and are coordinated exclusively via the dictionaries in the TOP .gitcover repo (exchange via GCEP/GCUCB). Separate dictionaries apply to the extended attribute fields (repository_ids.json, processtype_ids.json, gateway_ids.json, variant_ids.json); the highest value in each case is reserved as Custom/TenantDefined. Unassigned codes remain free for later global assignment. Normative reference: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Central Tenant Register

The TenantId of a GitCover legal entity is not derived from an assigned number range, but deterministically from the first 48 bits (millisecond timestamp) of the UUIDv7 that is generated during the initial creation of the tenant's TOP directory. The tenant identifier is therefore time-bound, sortable, and unique without a central sequence database - as long as no two tenants come into existence at the same millisecond point in time.

Freely selectable time source: The 48-bit timestamp does not have to be the actual creation time. Instead of the system time (DateTime.Now), each tenant can generate the UUIDv7 from an explicitly specified point in time - for example, the founding date of the legal entity or any other freely chosen reference date (cf. CustomEpoch/timestamp in the TenantContext). This allows the tenant identifier to be tied to a business-relevant date; uniqueness is preserved as long as the chosen millisecond point in time does not collide across tenants (a further reason for voluntary registration).

Because GitCover repos reference one another via others.json traversals (cross-repo resolution of physical and logical paths), a tenant identifier must be uniquely resolvable when used across repos. For this reason, a central, voluntary register exists.

Registration Model (voluntary, without number ranges)

• No reserved number ranges. Since the TenantId is derived from the 48-bit timestamp, there is neither a "public" nor a "private" number range - the distinction lies solely in maintenance in the register.
• Voluntariness. Registration is optional. Anyone who requires cross-repo interoperability and collision freedom for others.json traversals registers their tenant publicly.
• Immutability. A registered tenant identifier is final and stable; no re-use after dissolution (status ARCHIVED).

Canonical register instance: The operational tenant register is maintained in the respective tenant root under .gitcover/access/TENANT_GUID_REGISTER.md (short name · legal entity · UUIDv7 · timestamp · status). It is the authoritative list of registered tenants.

Record Chains (Evidence Chains)

A record chain concatenates compliance artifacts via prev-hash references:

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

Each record references the SHA-256 hash of its predecessor. The entire chain is thus cryptographically anchored and tamper-proof.

Metadata Schema (.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"

Binary Originals and V7GUID Sidecars

Records that exist as binary files (PDF, DOCX, EML, image) cannot carry metadata within Git. They are attached to the record chain via a V7GUID sidecar (*.v7g.md next to the original): The sidecar contains at least the sha256 of the original as well as the DocID (uuidv7, instance identifier) and the categorized v7guid (context). The process and the assignment of the DocID from the file timestamp are described in Axis 5: Procedures; for the associated tenant registration, see Central Tenant Register above.

Cryptographic Evidence Chain

The Cryptographic Evidence Chain combines three cryptographic primitives:

1. Git commit hash - Immutability of the repository state
2. GPG signature - Identity of the actor (Who decided?)
3. V7GUID - Deterministic addressing (What and When)

The result is a chain that is both cryptographically anchored and chronologically sortable - the foundation for audit-proof compliance evidence.

Recovery fallback: In the end, only Git repos remain In the event of a disaster, infrastructure loss, or an audit 10 years later, the last functional set of artifacts is the Git repository itself (or git bundle/ZIP export). Contained within: code artifacts, .gitcover/ registries/dictionaries (JSON/JSONL), GPG keyrings (.gitcover/keys/), V7GUID record chains. No database, no web server, no running services required. The forensics is the Git repo — HTML auditor packages are only presentation derivatives (see Procedures: Audit Readiness).

Deterministic Branching

Deterministic branching makes it possible to bind record chains to Git repository structures. Through the combination of:

• Git repositories as compliance periods (e.g., FY2026)
• V7GUID classes as document types (INVOICE, PAYMENT, PERSON)
• OPA policies as pre-receive hooks (validation before commit)

reproducible, audit-ready compliance structures emerge - without manual maintenance.

See also: The technical primitives (GPG, uuidV7, OSCAL) are explored in depth in Axis 4: Techniques.