Trục 2: Các khái niệm

V7GUID - Version-7-GUID

V7GUID (còn gọi là: Categorized UUIDv7 Identifier) là một lược đồ phân loại cho các định danh trong các artefact của GitCover, dựa trên UUID Version 7 tương thích RFC-4122 (dựa trên thời gian, có thể sắp xếp), được mở rộng thêm một phân loại lớp đặc thù của GitCover.

Cấu trúc

Mục đích: Liên kết các chứng từ một cách xác định, có thể sắp xếp trong một chuỗi chứng từ. Cho phép khả năng tái dựng theo thời gian/theo phiên bản (GoBD: tính kịp thời về thời gian) mà không cần cơ sở dữ liệu trình tự trung tâm.

Nền tảng thời gian: GMT/UTC (quy tắc chuẩn tắc)

Dấu thời gian 48 bit của tất cả các V7GUID và uuidV7 phải được tạo và diễn giải luôn trên nền GMT/UTC (Offset 0) - không bao giờ trên nền một múi giờ địa phương (MESZ, MEZ v.v.):

Cơ sở lý luận:

• Trung tính múi giờ: Dấu thời gian dựa trên UTC có thể được diễn giải một cách duy nhất trên toàn thế giới. Các mốc thời gian địa phương (chuyển đổi giờ mùa hè, ranh giới múi giờ) không làm sai lệch khả năng sắp xếp và so sánh.
• Khả năng quy đổi: Mọi App đều có thể quy đổi dấu thời gian UTC sang múi giờ địa phương của người dùng bất cứ lúc nào - đặc biệt là những App phải duy trì mốc thời gian (ví dụ: chấm công cho nhân viên, chứng nhận giờ làm việc, theo dõi thời hạn). Con đường ngược lại (dùng giờ địa phương làm nền tảng) dẫn đến nhập nhằng (chuyển đổi giờ mùa hè: 03:00 CEST = 01:00 UTC tồn tại hai lần).
• Tuân thủ GoBD: Tính kịp thời về thời gian và khả năng truy vết (§ 146 AO) đòi hỏi một nền tảng thời gian bất biến và duy nhất. UTC là nền tảng duy nhất bảo đảm một cách hệ thống tính chất này.
• Nhất quán với RFC 9562: Chuẩn UUIDv7 định nghĩa dấu thời gian là số mili giây kể từ Unix-Epoch (UTC); mọi cách tạo nào lệch khỏi đó đều vi phạm chuẩn.

Quy tắc nhận biết: Khi giải mã một V7GUID/uuidV7, giá trị 48 bit được trích xuất phải luôn được đọc là UTC. Việc hiển thị/xử lý tiếp theo theo giờ địa phương chỉ diễn ra ở tầng trình diễn của App, không bao giờ ở nền tảng định danh.

Chuẩn tắc & Triển khai: Nguyên tắc V7GUID (hệ thống phân cấp 6 cấp trong các bit GUID, các vùng bit cố định, tra cứu O(1), tham chiếu chéo giữa các repo) là một bộ phận của đơn đăng ký sáng chế 10 2025 003 091.6. Cách gán bit chuẩn tắc (offset/độ rộng/vùng giá trị chính xác của từng segment) được quy định chuẩn tắc trong đặc tả giao thức specs/v7guid/ - xem 00_gesamtkarte.md tại đó. GCBoK trình bày chuẩn tắc này; khi có sai khác thì đặc tả có giá trị áp dụng.

Class-Identifier - Sổ đăng ký segment

Class-Identifier của GitCover (segment class của V7GUID) được xây dựng một cách xác định từ một Business-Hierarchie sáu cấp. Mỗi cấp rộng 4 bit (vùng giá trị 0–15, tức 16 dạng biểu hiện có thể cho mỗi cấp) và được gán giá trị toàn cục thông qua một dictionary chuẩn tắc trong repo .gitcover của thư mục TOP. Ngoài ra, V7GUID còn mang nhiều trường đặc trưng mở rộng. Sổ đăng ký dưới đây liệt kê tất cả các segment được nhóm lại cùng với giá trị lớn nhất có thể tương ứng và tạo thành tài liệu tham chiếu có tính ràng buộc cho khả năng tương tác giữa các repo GitCover.

Business-Hierarchie (phân loại xác định)

Ký hiệu chuỗi Classification kết hợp sáu cấp thành L1_L2_L3_L4_L5_L6 - ví dụ: 1_14_12_14_13_1 (Portfolio-Preisposition). Vùng giá trị 16⁶ = 16.777.216 bao phủ tất cả các phân loại xác định.

Các trường đặc trưng mở rộng của V7GUID (phân loại Compliance)

Ngoài hệ thống phân cấp 6 cấp, V7GUID còn mang bốn trường đặc trưng khác có thể gán giá trị một cách xác định. Chúng là các trình hỗ trợ phân loại/xếp loại và phân loại thêm các khía cạnh Compliance của một chứng từ. Chúng rõ ràng không phải là các định danh thể hiện đối tượng - đối tượng cụ thể nào được nhắc đến chỉ do Object ID (chính là uuidv7 thuần túy) của định danh kép quyết định. Nhiều đối tượng dùng chung cùng một giá trị trường đặc trưng.

Lưu ý: VariantId trước đây tên là InstanceId; tên đã được đổi vì trường này phân loại một lớp dạng cụ thể, chứ không phải một thể hiện đối tượng.

Như vậy, một định danh duy nhất mã hóa đa chiều cái gì, ở đâu, bằng gì, qua điểm kiểm soát nào và ở dạng cụ thể nào mà một chứng từ đã phát sinh - kiểm tra được trực tiếp từ GUID (O(1), không cần truy vấn cơ sở dữ liệu). Ví dụ một hóa đơn điện tử (E-Rechnung) đã được kiểm tra: 1_14_12_14_13_1 + RepositoryId 3 (DMS) + ProcessTypeId 12 (kiểm tra EN16931) + GatewayId 220 (phê duyệt bốn mắt) + VariantId 10 (lưu trữ 10 năm).

Cách gán giá trị: Các cấp 4 bit L1–L6 là chuẩn tắc toàn cục và chỉ được điều phối thông qua các Dictionary trong repo .gitcover của TOP (trao đổi qua GCEP/GCUCB). Đối với các trường đặc trưng mở rộng, áp dụng các Dictionary riêng (repository_ids.json, processtype_ids.json, gateway_ids.json, variant_ids.json); giá trị cao nhất trong mỗi dictionary được dành riêng làm Custom/TenantDefined. Các mã chưa được gán vẫn để trống cho việc cấp phát toàn cục sau này. Tài liệu tham chiếu chuẩn tắc: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Sổ đăng ký Tenant trung tâm

TenantId của một pháp nhân GitCover không được suy ra từ một dải số đã cấp phát, mà được xác định từ 48 bit đầu tiên (dấu thời gian mili giây) của UUIDv7 được tạo ra khi lần đầu tiên lập thư mục TOP của Tenant. Nhờ vậy, định danh Tenant gắn với thời điểm, có thể sắp xếp và là duy nhất mà không cần cơ sở dữ liệu trình tự trung tâm - miễn là không có hai Tenant nào phát sinh tại cùng một thời điểm mili giây.

Nguồn thời gian có thể chọn tự do: Dấu thời gian 48 bit không nhất thiết phải là thời điểm lập thực tế. Thay vì giờ hệ thống (DateTime.Now), mỗi Tenant có thể tạo UUIDv7 từ một thời điểm được chỉ định rõ ràng - chẳng hạn ngày thành lập của pháp nhân hoặc một ngày tham chiếu khác được chọn tùy ý (xem CustomEpoch/Timestamp trong TenantContext). Nhờ đó, định danh Tenant có thể được gắn với một ngày có ý nghĩa nghiệp vụ; tính duy nhất vẫn được bảo toàn, miễn là thời điểm mili giây đã chọn không bị xung đột giữa các Tenant (một lý do nữa cho việc đăng ký tự nguyện).

Vì các repo GitCover tham chiếu lẫn nhau qua các phép duyệt others.json (giải quyết chéo repo các đường dẫn vật lý và logic), một định danh Tenant phải có thể được phân giải một cách duy nhất khi sử dụng xuyên repo. Vì vậy mà tồn tại một sổ đăng ký trung tâm, tự nguyện.

Mô hình đăng ký (tự nguyện, không có dải số)

• Không có dải số dành riêng. Vì TenantId phát sinh từ dấu thời gian 48 bit, không tồn tại dải số „công khai" cũng như „riêng tư" - sự phân biệt chỉ nằm ở việc quản lý trong sổ đăng ký.
• Tính tự nguyện. Việc đăng ký là tùy chọn. Ai cần khả năng tương tác xuyên repo và tính không xung đột cho các phép duyệt others.json thì đăng ký Tenant của mình công khai.
• Tính bất biến. Một định danh Tenant đã đăng ký là cuối cùng và ổn định; không tái sử dụng sau khi giải thể (trạng thái ARCHIVED).

Thể hiện sổ đăng ký chuẩn tắc: Sổ đăng ký Tenant vận hành được quản lý tại tenant root tương ứng dưới .gitcover/access/TENANT_GUID_REGISTER.md (tên viết tắt · pháp nhân · UUIDv7 · dấu thời gian · trạng thái). Đây là danh sách có giá trị quyết định về các Tenant đã đăng ký.

Chuỗi chứng từ (Evidence Chains)

Một chuỗi chứng từ nối các artefact Compliance với nhau qua các tham chiếu prev-hash:

1. Chứng từ B1 - V7GUID: ...-PERSON-..., SHA256: 3f2a1c..., prev: -
2. Chứng từ B2 - V7GUID: ...-INVOICE-..., SHA256: 7d4e2f..., prev: 3f2a1c...
3. Chứng từ B3 - V7GUID: ...-PAYMENT-..., SHA256: 1b8f90..., prev: 7d4e2f...

Mỗi chứng từ tham chiếu đến hash SHA-256 của chứng từ đứng trước nó. Toàn bộ chuỗi nhờ vậy được neo bằng mật mã và chống được thao túng.

Lược đồ siêu dữ liệu (.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"

Bản gốc nhị phân và V7GUID-Sidecar

Các chứng từ tồn tại dưới dạng tệp nhị phân (PDF, DOCX, EML, hình ảnh) không thể mang siêu dữ liệu bên trong Git. Chúng được gắn vào chuỗi chứng từ thông qua một V7GUID-Sidecar (*.v7g.md nằm cạnh bản gốc): Sidecar ghi ít nhất sha256 của bản gốc cũng như DocID (uuidv7, định danh thể hiện) và v7guid đã phân loại (bối cảnh). Quy trình và việc cấp DocID từ dấu thời gian của tệp được mô tả trong Trục 5: Các cách thức thực hiện; việc đăng ký Tenant liên quan xem Sổ đăng ký Tenant trung tâm ở trên.

Cryptographic Evidence Chain

Cryptographic Evidence Chain kết hợp ba nguyên thủy mật mã:

1. Git-Commit-Hash - Tính bất biến của trạng thái repository
2. GPG-Signatur - Danh tính của tác nhân (Ai đã quyết định?)
3. V7GUID - Địa chỉ hóa xác định (Cái gì và Khi nào)

Nhờ đó hình thành một chuỗi vừa được neo bằng mật mã vừa có thể sắp xếp theo thời gian - nền tảng cho các bằng chứng Compliance an toàn trước kiểm toán.

Recovery-Fallback: Cuối cùng chỉ còn lại các Git-repo Khi xảy ra thảm họa, mất hạ tầng hoặc kiểm toán 10 năm sau, bộ artefact cuối cùng còn hoạt động được chính là Git-repository (hoặc xuất git bundle/ZIP). Bên trong chứa: Code-Artifacts, các registry/dictionary .gitcover/ (JSON/JSONL), các GPG-Keyrings (.gitcover/keys/), các chuỗi chứng từ V7GUID. Không cần cơ sở dữ liệu, không cần webserver, không cần các service đang chạy. Điều tra pháp y chính là Git-repo — các gói kiểm tra HTML chỉ là các sản phẩm phái sinh để trình bày (xem Các cách thức thực hiện: Audit-Readiness).

Phân nhánh xác định

Phân nhánh xác định cho phép gắn các chuỗi chứng từ vào các cấu trúc Git-repository. Thông qua sự kết hợp của:

• Git-Repositories làm các kỳ Compliance (ví dụ: FY2026)
• V7GUID-Klassen làm các loại tài liệu (INVOICE, PAYMENT, PERSON)
• OPA-Policies làm các pre-receive-hook (xác thực trước commit)

hình thành các cấu trúc Compliance có thể tái tạo, đủ khả năng kiểm toán - không cần bảo trì bổ sung thủ công.

Xem thêm: Các nguyên thủy kỹ thuật (GPG, uuidV7, OSCAL) được đi sâu trong Trục 4: Kỹ thuật.