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 artifact 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 phân loại class đặc thù của GitCover.

Cấu trúc

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

Cơ sở 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 cơ sở GMT/UTC (Offset 0) - không bao giờ trên cơ sở một múi giờ địa phương (MESZ, MEZ v.v.):

Lý do:

• Trung lập múi giờ: Một 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ì dấu 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). Chiều ngược lại (dùng giờ địa phương làm cơ sở) dẫn đến sự nhập nhằng (chuyển giờ mùa hè: 03:00 CEST = 01:00 UTC tồn tại hai lần).
• Tuân thủ GoBD: Zeitgerechtheit và khả năng truy vết (§ 146 AO) đòi hỏi một cơ sở thời gian bất biến, duy nhất. UTC là cơ sở duy nhất đảm bảo một cách hệ thống đặc tính này.
• Tính 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 App, không bao giờ ở phần nền của định danh.

Chuẩn & Triển khai: Nguyên tắc V7GUID (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 Cross-Repo) là một phần của đơn đăng ký bằng sáng chế 10 2025 003 091.6. Cách gán bit chuẩn tắc (offset/độ rộng/khoảng giá trị chính xác của từng phân đoạn) được quy định mang tí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 này; khi có sai khác thì áp dụng đặc tả.

Class-Identifier - Bảng đăng ký phân đoạn

GitCover Class-Identifier (phân đoạn class của V7GUID) được cấu tạo một cách tất định từ một phân cấp kinh doanh (Business-Hierarchie) sáu cấp. Mỗi cấp rộng 4 bit (khoảng 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 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 định danh mở rộng. Bảng đăng ký sau đây liệt kê tất cả các phân đoạn theo nhóm cùng với giá trị lớn nhất có thể tương ứng của mỗi phân đoạn 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.

Business-Hierarchie (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 (Portfolio-Preisposition). Khoảng giá trị 16⁶ = 16.777.216 bao phủ tất cả các phân loại tất định.

Business-Hierarchie như một Ontologie

Sáu Dictionaries (từ Entity đến Instance) cùng nhau tạo thành GitCover-Ontologie: một bộ từ vựng đọc được bằng máy, dùng chung của tổ chức — các thực thể (ví dụ: Business Entity, Business Partner), các mối quan hệ, quy tắc và phân loại của chúng. Nhờ đó, con người, các validator và các AI agent nói cùng một ngôn ngữ: một thuật ngữ như „ERechnung" (ProcessType 13) đều mang cùng một ý nghĩa trong mọi Repo, mọi Schema và mọi Policy.

Tại GitCover, Ontologie được hiện thực hóa Git-nativ — không phải dưới dạng một cơ sở dữ liệu đồ thị trong một nền tảng:

Microsoft mô tả tầng ngữ nghĩa của mình là „governed, self-service knowledge graph", vốn cung cấp cho các agent „shared context" — cùng một không gian vấn đề (ngữ cảnh agent, các thuật ngữ thống nhất), nhưng được giải quyết theo cách gắn với nền tảng. GitCover giải quyết vấn đề này theo kiểu repo-nativ: Ontologie chính là bộ quy phạm trong Git-Repo, chứ không phải một dịch vụ tại một nhà cung cấp. Chi tiết về việc phân định: Bảng thuật ngữ („Ontologie") và Các thành phần: GCUCB, Bối cảnh thị trường.

Các trường dữ liệu đặc trưng mở rộng của V7GUID (Gán kiểu Compliance)

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

Lưu ý: VariantId trước đây có tên là InstanceId; tên đã được thay đổi vì trường này gán kiểu cho một lớp biến thể, chứ không phải một thực thể đối tượng. GatewayId/VariantId đã được thu hẹp từ 16/14 xuống 8/6 bit theo ADR-002 để chừa chỗ cho status và kind - xem specs/v7guid/ADR-002_layout_v2_kind.md.

Nhờ đó, một định danh duy nhất mã hóa đa chiều cái gì, ở đâu, bằng cái gì, qua điểm kiểm soát nào và ở biến thể nào mà một chứng từ đã được tạo ra - có thể kiểm chứng 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ử đã đượ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 (bảo quản 10 năm).

Gán giá trị: Các cấp 4-Bit L1–L6 mang tính chuẩn tắc toàn cầu và chỉ được điều phối thông qua các Dictionaries trong Repo .gitcover của TOP (trao đổi qua GCEP/GCUCB). Đối với các trường dữ liệu đặ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 của mỗi trường đượ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ầu sau này. Tham chiếu quy phạm: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

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

Bên cạnh phân cấp 6 cấp, V7GUID còn mang sáu trường định danh khác có thể gán giá trị một cách tất định. Chúng là các trường hỗ trợ phân loại/xếp loại và phân loại các khía cạnh Compliance bổ sung của một chứng từ. Chúng rõ ràng không phải là các định danh instance đối tượng - đối tượng cụ thể nào được nói đế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 định danh.

Lưu ý: VariantId trước đây có tên là InstanceId; tên đã được đổi vì trường này phân loại một lớp biểu hiện, không phải một instance đối tượng. GatewayId/VariantId đã được thu hẹp từ 16/14 xuống 8/6 bit theo ADR-002 để chừa chỗ cho status và kind - xem specs/v7guid/ADR-002_layout_v2_kind.md.

Nhờ đó, một định danh duy nhất mã hóa đa chiều cái gì, ở đâu, bằng cái gì, qua điểm kiểm soát nào và ở dạng biểu hiện nào mà một chứng từ đã phát sinh - 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ụ 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 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 để 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, mà được tạo một cách tất đị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 tạo thư mục TOP của Tenant. Nhờ vậy, định danh Tenant gắn với thời gian, có thể sắp xếp và duy nhất mà không cần cơ sở dữ liệu sequence tập trung - 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 tạo 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 - ví dụ như ngày thành lập của pháp nhân hoặc một ngày tham chiếu tùy ý khác (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 giữ nguyên miễn là thời điểm mili giây được 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 qua các phép duyệt others.json (phân giải Cross-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ự trữ. 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 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).

Instance 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 theo đườ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ị quyết định về các Tenant đã đăng ký.

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

Một chuỗi chứng từ liên kết các artifact 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ừ liền trước. Toàn bộ chuỗi nhờ đó được neo giữ 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à 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ừ 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 instance) 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 thức tiến hành; việc đăng ký Tenant liên quan xem Sổ đăng ký Tenant trung tâm ở trên.

Container giao dịch (.gcpn.md) — tầng quy trình của chuỗi chứng từ

Bên cạnh việc lập danh mục theo từng Sidecar, GCPN-Container được thêm vào cho các giao dịch nhiều bước (ví dụ: sự hình thành và ký một GVB): một tệp .gcpn.md đặt cạnh Referenced-Doc (<Referenced-Doc-Basisname>.gcpn.md), đồng hành cùng quy trình với tư cách là một Prozess-Ur-Doc độc lập — không phải với tư cách Sidecar của Referenced-Doc. Về mặt khái niệm:

• Doc mutable với các JSON-Artefact immutable (Schema gcpn-container-1.0): referenced_doc, actor, retention được mô tả mỗi thứ đúng một lần; các tham chiếu khác chạy qua SHA-256 hoặc actor_ref — không có dư thừa bên trong.
• Events dưới dạng Flags-Enum với kết quả: offered(1), accepted(2), denied(4), sign(8), withdraw(16) — các bước đã đi qua tạo thành bitmask events_result (ví dụ: 11 = offered + accepted + sign) với xác nhận chain_valid cho việc nối hash.
• Bổ sung thay vì tạo mới: Mỗi bước quy trình mới đặt flag, nhúng artifact mới vào và cập nhật summary; các JSON-Artefact đã nhúng từ trước giữ nguyên không đổi (immutable). Lịch sử của Container được lưu một cách an toàn kiểm toán trong lịch sử Git của repo.
• JSON luôn được nhúng (MD-Fence) — không có tệp .json độc lập trong cây repo (tránh Bloating).
• Chức năng chỉ mục của GCDMS: Trong DMS được gắn tùy chọn, Container đóng vai trò là chỉ mục để điều hướng quy trình đến các Doc riêng lẻ — thay vì n8n hoặc các Workflow-Engine tương tự.

Một Referenced-Doc đã ký sau đó trở thành immutable (GoBD: tính bất biến); Container vẫn là mutable và tiếp tục ghi lại quy trình — lịch sử Git chính là bằng chứng.

GCPN với tư cách là biên bản — Act với tư cách là chuyển đổi trạng thái

Một GCPN là một dạng biên bản. Trong GCBoK với Compliance là chủ đề chính, thường nói đến các cuộc họp thành viên với các nghị quyết được tổng hợp trong một GVB:

Cách hiểu kép này (biên bản + chuyển đổi trạng thái) là cốt lõi của khả năng chứng minh: Mỗi Act được mô tả một cách tất định — trạng thái trước có thể được chứng minh qua chuỗi SHA-256 (Sidecar, Referenced-Doc), trạng thái sau qua biểu thức Flags và artifact được nhúng. Lịch sử Git của Container cung cấp trình tự thời gian. Quy trình và xác minh: Trục 3 (GCPN) và Chuỗi bài viết digital-signage (DS02–DS05).

Cryptographic Evidence Chain

Cryptographic Evidence Chain kết hợp ba primitive 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 chủ thể hành động (Ai đã quyết định?)
3. V7GUID - Địa chỉ hóa tất định (Cái gì và Khi nào)

Nhờ đó hình thành một chuỗi vừa được neo giữ 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 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ộ artifact 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: Code-Artifacts, .gitcover/ Registries/Dictionaries (JSON/JSONL), GPG-Keyrings (.gitcover/keys/), 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 kiểm tra HTML dành cho kiểm toán viên chỉ là các sản phẩm phái sinh để trình bày (xem Các cách thức tiến hành: 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ác cấu trúc Git-Repository. Thông qua sự kết hợp của:

• Git-Repositories với vai trò là các kỳ Compliance (ví dụ: FY2026)
• Các lớp V7GUID với vai trò là các loại tài liệu (INVOICE, PAYMENT, PERSON)
• OPA-Policies với vai trò là 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 lập, đáp ứng được kiểm toán - không cần bảo trì bổ sung thủ công.

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