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 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 bằng một cách phân loại lớp (class) đặ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 tất định và có thể sắp xếp trong một chuỗi chứng từ. Cho phép tái dựng theo thời gian/phiên bản (GoBD: tính đúng thời gian - Zeitgerechtheit) mà không cần cơ sở dữ liệu tuần tự tập trung.

Nền tảng thời gian: GMT/UTC (quy tắc mang tính quy phạm)

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

Cơ sở lý luận:

• Trung lập 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 dấu hiệu 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à khả năng so sánh.
• Khả năng quy đổi: Mọi ứng dụng đề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à các ứng dụng phải duy trì dấu mốc thời gian (ví dụ: chấm công cho nhân viên, chứng nhận thời gian 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) dẫn đến sự mơ hồ (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 đúng thời gian (Zeitgerechtheit) và khả năng truy vết (§ 146 AO) đòi hỏi một nền thời gian bất biến và duy nhất. UTC là nền tảng duy nhất đảm bảo đặc tính này một cách mang tính hệ thống.
• Nhất quán với RFC 9562: Tiêu 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 điều này đều vi phạm tiêu chuẩn.

Quy tắc nhận diện: 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 ứng dụng, không bao giờ ở tầng nền định danh.

Chuẩn mự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 dải bit cố định, tra cứu O(1), tham chiếu chéo giữa các repo) là một 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/dải giá trị chính xác của từng segment) được quy định mang tính quy phạm trong đặc tả giao thức specs/v7guid/ - xem tại đó 00_gesamtkarte.md. GCBoK trình bày chuẩn mực này; khi có sai khác thì đặc tả được á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 tất định từ một hệ thống phân cấp nghiệp vụ (Business-Hierarchy) sáu cấp. Mỗi cấp có độ rộng 4 bit (dải giá trị 0–15, tức 16 giá trị có thể có cho mỗi cấp) và được gán giá trị toàn cục thông qua một dictionary mang tính quy phạm trong repo .gitcover của thư mục TOP. Ngoài ra, V7GUID còn mang một số trường định danh 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 của chúng và tạo thành tài liệu tham chiếu ràng buộc cho khả năng tương tác giữa các repo GitCover.

Hệ thống phân cấp nghiệp vụ (phân loại tất định)

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

Các trường định danh mở rộng của V7GUID (phân loại tuân thủ)

Ngoài hệ thống phân cấp 6 cấp, V7GUID còn mang bốn trường định danh khác có thể được gán giá trị một cách tất định. Chúng là các trợ giúp phân loại/xếp loại và phân loại thêm các khía cạnh tuân thủ bổ sung 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 đề cập chỉ do Object ID (chính là uuidv7 thuần túy) của định danh kép chỉ ra. Nhiều đối tượng dùng chung cùng một giá trị trường định danh.

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 thức (Ausprägungsklasse), 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, thông qua cái gì, qua điểm kiểm soát nào và ở dạng thức nào của việc một chứng từ được tạo ra - có thể kiểm tra trực tiếp từ GUID (O(1), không cần truy vấn cơ sở dữ liệu). Ví dụ về 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 theo nguyên tắc 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 phối hợp thông qua các dictionary trong repo .gitcover của TOP (trao đổi qua GCEP/GCUCB). Đối với các trường định danh 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 trường được dành riêng làm Custom/TenantDefined. Các mã chưa được gán vẫn được giữ trống cho việc cấp phát toàn cục sau này. Tài liệu tham chiếu quy phạm: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Sổ đăng ký Tenant tập trung

TenantId của một pháp nhân GitCover không được suy ra từ một dải số đã được cấp phát, mà được xác định tất yếu từ 48 bit đầu tiên (dấu thời gian mili giây) của UUIDv7 được tạo ra khi thiết lập thư mục TOP của tenant lần đầu tiên. Nhờ vậy, định danh tenant gắn với thời gian, có thể sắp xếp và là duy nhất mà không cần cơ sở dữ liệu tuần tự tập trung - miễn là không có hai tenant nào được tạo ra 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 thiết lập thực tế. Thay vì dùng 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ể gắn với một ngày có ý nghĩa nghiệp vụ; tính duy nhất vẫn được giữ nguyên miễn là thời điểm mili giây đã chọn không 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 thông qua các phép duyệt others.json (phân giải 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 được sử dụng chéo repo. Vì vậy, tồn tại một sổ đăng ký tập trung, 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" hay "riêng" - 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 chéo 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ực thể sổ đăng ký chuẩn tắc: Sổ đăng ký tenant vận hành được quản lý tại gốc tenant tương ứng dưới đường dẫn .gitcover/access/TENANT_GUID_REGISTER.md (tên ngắn · pháp nhân · UUIDv7 · dấu thời gian · trạng thái). Đây là danh sách có giá trị tham chiếu chính thức về các tenant đã đăng ký.

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

Một chuỗi chứng từ xâu chuỗi các artefact tuân thủ với nhau thông 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ờ đó được neo bằng mật mã và chống giả mạo.

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à các 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 đặt 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 (ngữ 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 tiếp cận; việc đăng ký tenant liên quan xem Sổ đăng ký Tenant tập trung ở 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. Chữ ký GPG - Danh tính của tác nhân (Ai đã quyết định?)
3. V7GUID - Địa chỉ hóa tất định (Cái gì và Khi nào)

Nhờ đó tạo 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 tuân thủ an toàn 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 bản xuất git bundle/ZIP). Bên trong chứa: các code-artifact, các registry/dictionary .gitcover/ (JSON/JSONL), các GPG-keyring (.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 dịch vụ đang chạy. Điều tra pháp y chính là Git-repo — các gói HTML dành cho kiểm toán viên chỉ là sản phẩm phái sinh để trình bày (xem Các cách tiếp cận: Audit-Readiness).

Phân nhánh tất định

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

• Git-Repositories đóng vai trò các kỳ tuân thủ (ví dụ: FY2026)
• Các lớp V7GUID đóng vai trò các loại tài liệu (INVOICE, PAYMENT, PERSON)
• OPA-Policies đóng vai trò các Pre-Receive-Hooks (xác thực trước commit)

tạo ra các cấu trúc tuân thủ có thể tái lập và đủ điều kiện kiểm toán - mà 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 hơn trong Trục 4: Kỹ thuật.