Trục 2: Khái niệm

V7GUID - GUID phiên bản 7

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 tạo tác GitCover, dựa trên UUID phiên bản 7 tương thích RFC 4122 (dựa trên thời gian, có thể sắp xếp), được mở rộng bằng một phân loại lớp đặc thù GitCover.

Cấu trúc

Phân đoạn	Bits	Phạm vi	Ý nghĩa
timestamp_ms	48	Cơ sở RFC 4122 UUIDv7	Mili giây kể từ Unix Epoch (có thể sắp xếp)
version	4	Cơ sở RFC 4122 UUIDv7	Cố định: 0111 (UUIDv7)
rand_a	12	Cơ sở RFC 4122 UUIDv7	Vectơ tất định cho các từ điển Tenant/Doc/Class/Action của GitCover (được định nghĩa trong repo `.gitcover` của TOP)
variant	2	Cơ sở RFC 4122 UUIDv7	Cố định: 10 (RFC 4122)
repository_id	12	Phần mở rộng GitCover	Phạm vi Repo/Tenant (từ `rand_a` của RFC)
class (L1–L6 + các trường định danh mở rộng)	62	Phần mở rộng GitCover	Tải trọng GitCover được gán tất định (hệ thống phân cấp 6 cấp + các trường định danh mở rộng để phân loại tuân thủ, từ `rand_b` của RFC)

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 khả năng tái dựng theo thời gian/phiên bản (GoBD: tính đúng thời điểm) mà không cần cơ sở dữ liệu tuần tự trung tâm.

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ả V7GUID và uuidV7 phải luôn được tạo và diễn giải trên cơ sở GMT/UTC (độ lệch 0) - không bao giờ trên cơ sở múi giờ địa phương (MESZ, MEZ, v.v.):

flowchart LR GEN["Generierung
uuidV7 / V7GUID"] -->|"48-Bit-Timestamp
immer UTC (GMT+0)"| GUID["GUID
zeitzone-neutral"] GUID -->|"lesbar als
ISO-8601 UTC"| APP["App / Verwendung"] APP -->|"lokale Umrechnung
z.B. Europe/Berlin (MESZ)"| UI["Zeitmarke in App
z.B. Zeiterfassung Mitarbeiter"] style GEN fill:#c8e6c9 style GUID fill:#bbdefb style APP fill:#ffe0b2 style UI fill:#f8bbd0

Lý do:

Trung tính múi giờ: Dấu thời gian dựa trên UTC có thể được diễn giải 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à so sánh.
Khả năng quy đổi: Mọi ứng dụng 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 thời gian (ví dụ: chấm công nhân viên, bằng chứng giờ làm việc, theo dõi thời hạn). Chiều ngược lại (lấy giờ địa phương làm cơ sở) 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 đúng thời điểm 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 thuộc tính này.
Nhất quán với RFC 9562: Tiêu chuẩn UUIDv7 định nghĩa dấu thời gian là mili giây Unix Epoch (UTC); mọi cách tạo lệch khỏi đó đều vi phạm tiêu 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 luôn phải được đọc là UTC. Việc hiển thị/xử lý tiếp theo trong giờ địa phương chỉ diễn ra ở lớp trình bày của ứng dụng, không bao giờ ở cơ sở định danh.

Chuẩn & triển khai: Nguyên lý 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 repo) là một phần của đơn đăng ký sáng chế 10 2025 003 091.6. Cách gán bit kinh điển (độ lệch/độ rộng/phạm vi giá trị chính xác theo từng phân đoạn) được ghi theo chuẩn tắc trong đặc tả giao thức specs/v7guid/ - xem 00_gesamtkarte.md tại đó. GCBoK thể hiện chuẩn này; trong trường hợp có sai lệch, đặc tả được áp dụng.

Class-Identifier - Sổ đăng ký phân đoạn

Class-Identifier của GitCover (phân đoạn class của V7GUID) được xây dựng tất định từ một hệ thống phân cấp nghiệp vụ sáu cấp. Mỗi cấp rộng 4 bit (phạm vi giá trị 0–15, tức 16 khả năng biểu hiện cho mỗi cấp) và được gán toàn cục thông qua một từ điển chuẩn tắc trong repo .gitcover của thư mục TOP. Ngoài ra, V7GUID mang nhiều trường định danh mở rộng. Sổ đăng ký sau liệt kê tất cả các phân đoạn được nhóm theo giá trị lớn nhất có thể tương ứng và tạo thành 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)

#	Phân đoạn	Bits	Giá trị tối đa	Từ điển	Ý nghĩa
L1	Entity	4	15	`entities.json`	Thực thể nghiệp vụ (ví dụ: `1` BusinessEntities, `2` BusinessPartners)
L2	Department	4	15	`departments.json`	Bộ phận/lĩnh vực (ví dụ: `14` Portfolio, `9` IT) — đóng vai trò neo đơn vị tổ chức cho trách nhiệm PII hai tầng (tenant pháp lý + PMO/Bộ phận về mặt tổ chức, xem Kỹ thuật: Git là IdP
L3	Category	4	15	`categories.json`	Danh mục (ví dụ: `12` Service, `14` DocSigning; `15` = Sentinel `Custom`/`TenantDefined`)
L4	SubCategory	4	15	`subcategories.json`	Danh mục con (ví dụ: `14` Leistung, `13` Preisposition)
L5	ProcessType	4	15	`processtypes.json`	Loại quy trình (ví dụ: `13` ERechnung, `14` Gobd, `11` Agentic; `15` = Sentinel `Custom`/`TenantDefined`)
L6	Instance	4	15	`instances.json`	Thể hiện (ví dụ: `1` Default, `2` Primary)

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

Hệ thống phân cấp nghiệp vụ như một bản thể học

Sáu từ điển (từ Entity đến Instance) cùng nhau tạo thành bản thể học GitCover: một từ vựng dùng chung, máy đọc được của tổ chức — các thực thể (ví dụ: Business Entity, Business Partner), quan hệ, quy tắc và phân loại của chúng. Nhờ đó, con người, trình xác thực và tác tử AI nói cùng một ngôn ngữ: một thuật ngữ như „ERechnung" (ProcessType 13) có cùng ý nghĩa trong mọi repo, mọi lược đồ và mọi chính sách.

Bản thể học tại GitCover được hiện thực theo cách Git-native — không phải dưới dạng cơ sở dữ liệu đồ thị trong một nền tảng:

Đặc điểm	Bản thể học GitCover	Bản thể học nền tảng (ví dụ: Microsoft „Fabric IQ", tại đó „Ontology" là mục xem trước)
Nơi lưu trữ	Các từ điển JSON được phiên bản hóa trong repo `.gitcover` (L1–L6) + lược đồ JSON	Đồ thị trung tâm trong nền tảng (OneLake, bề mặt truy vấn GQL)
Khả năng truy vết	Chính lịch sử Git („Pháp chứng = repo Git"); mỗi thay đổi là một commit	Lineage trong nội bộ nền tảng; không thể tái tạo bên ngoài
Quyền truy cập của kiểm toán viên	Mọi kiểm toán viên tái tạo ngữ nghĩa bằng các công cụ mở (Git, `jq`, trình xác thực lược đồ JSON) — No Vendor Lock-In	Quyền truy cập gắn với tài khoản nền tảng
Thẩm quyền thay đổi	Quản trị thông qua review/merge trong repo	Mô hình vai trò của nền tảng

Microsoft mô tả lớp ngữ nghĩa của mình là „governed, self-service knowledge graph", cung cấp cho các tác tử „shared context" — cùng một không gian vấn đề (ngữ cảnh tác tử, thuật ngữ thống nhất), nhưng được giải quyết gắn với nền tảng. GitCover giải quyết nó theo cách repo-native: Bản thể học là nội dung chuẩn trong repo Git, không phải một dịch vụ tại nhà cung cấp. Chi tiết về sự phân biệt: Thuật ngữ („Ontologie") và Thành phần: GCUCB, bối cảnh thị trường.

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 sáu trường định danh mở rộng khác có thể được gán tất định. Chúng là công cụ hỗ trợ phân loại/xếp loại và định kiểu các khía cạnh tuân thủ bổ sung của một chứng từ. Chúng dứt khoát không phải là định danh thực thể đối tượng - đối tượng cụ thể nào được ám chỉ chỉ được cho biết bởi Object ID (uuidv7 thuần) của định danh kép. Nhiều đối tượng chia sẻ cùng một giá trị trường định danh.

Phân đoạn	Bits	Giá trị tối đa (`Custom`)	Câu hỏi	Chiều tuân thủ
RepositoryId	12	4.095	Ở đâu?	Phạm vi repo/dữ liệu (TOP + tối đa 4.095 repo mỗi tenant); tách biệt tenant/PII
ProcessTypeId	8	255	Bằng cách nào?	Thủ tục đã tạo ra chứng từ (GoBD, EN16931, AI-Act)
GatewayId	8	255	Điểm kiểm soát?	Điểm bàn giao/phê duyệt (chuỗi chứng từ, tách biệt chức năng)
Status	8	255	Những giai đoạn nào?	Bitmask vòng đời (đã lên kế hoạch/đã phê duyệt/đã phát triển/…; bộ lọc O(1))
Kind	8	255	Loại nào?	Loại hoạt động/biện pháp (F&E, Routine, xử lý hồ sơ đơn hàng …)
VariantId	6	63	Biểu hiện?	Ngữ cảnh pháp lý (lưu trữ §147 AO, mức bảo vệ DSGVO, IFRS/HGB)

Lưu ý: VariantId trước đây có tên là InstanceId; tên đã được thay đổi vì trường này định kiểu một lớp biểu hiện, không phải một thể hiện đối tượng. GatewayId/VariantId đã được thu nhỏ với ADR-002 từ 16/14 xuống 8/6 bit để tạo 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ách nào, qua điểm kiểm soát nào, ở trạng thái vòng đời nào và ở biểu hiện nào một chứng từ đã hình thành - 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ử đã đượ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: Các cấp 4 bit L1–L6 mang tính kinh điển toàn cục và chỉ được điều phối thông qua các từ điển 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 từ điển riêng (repository_ids.json, processtype_ids.json, gateway_ids.json, variant_ids.json); giá trị cao nhất tương ứ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. Tham chiếu chuẩn tắc: specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Cổng quy trình (pgid) và Sổ đăng ký hành động (261026)

GatewayId 8 bit định kiểu điểm kiểm soát. Danh tính cổng quy trình (pgid) đầy đủ là một lớp V7GUID gồm repository_id + gateway_id (+ kỷ nguyên lớp), được tạo bằng gc-v7guid class — không phải UUID ngẫu nhiên và không được suy ra từ SHA của tài liệu.

Sổ đăng ký (hai tầng): OSS/TOP/.gitcover/dictionaries/gateway_ids.json (giá trị 8 bit) và <Tenant>/TOP/compliance/process_gateways.json (process_key, uuidV7 = pgid, repository_id, gateway_id). Khối GCUV 180–189 là tạm thời cho đến khi phân bổ OSS: 180 tạo hóa đơn, 181 PDF, 182 Verify, 183 DMS-Ingest, 184 Books, 185 OP.

Tách biệt vai trò: produced_by_pgid là hành động tạo ra (ví dụ: gc-billing invoice); stored_by_pgid là hành động lưu trữ (gc-dms scan --apply). Sổ đăng ký DMS lưu hóa đơn, nó không tạo ra hóa đơn. object_id của DMS là docUid của sidecar, không phải một UUID sổ đăng ký mới.

Chứng từ: GCUV/TOP/compliance/{PROCESS_GATEWAYS.md,process_gateways.json}; báo cáo kiểm tra AFJD/FY2026/reports/261026_pruefung_rechnungsausgang_afjd-ada.md § 8.5.

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à 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 khi lần đầu tạo thư mục TOP của tenant. Do đó, đị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 tuần tự trung tâm - miễn là không có hai tenant nào hình thành trong cùng một thời điểm mili giây.

Nguồn thời gian có thể tự chọn: 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ì thời gian 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 được chọn khác tùy ý (xem CustomEpoch/timestamp trong TenantContext). Như vậy, định danh tenant có thể được gắn với một ngày có ý nghĩa chuyên môn; tính duy nhất vẫn được giữ 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 khác cho việc đăng ký tự nguyện).

Vì các repo GitCover tham chiếu lẫn nhau qua các traverse others.json (giải quyết đường dẫn vật lý và logic xuyên repo), nên một định danh tenant khi được sử dụng xuyên repo phải có thể được giải quyết duy nhất. Do đó 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ố)

Trạng thái	Ý nghĩa	Khả năng tương tác
Đã đăng ký công khai	Tenant-UUIDv7 được ghi trong sổ đăng ký trung tâm (tên ngắn, pháp nhân, dấu thời gian, trạng thái)	Có thể giải quyết không xung đột; có hiệu lực cho các traverse `others.json` giữa các repo
Riêng tư / chưa đăng ký	Tenant-UUIDv7 tồn tại cục bộ nhưng không được ghi trong sổ đăng ký	Được phép cho sử dụng nội bộ; rủi ro xung đột khi traverse xuyên repo (không có bảo vệ xung đột, không có giải quyết được đảm bảo)

Không có dải số được dành riêng. Vì TenantId hình thành từ dấu thời gian 48 bit, không có dải số „công khai" cũng như „riêng tư" - sự phân biệt chỉ nằm ở việc ghi trong sổ đăng ký.
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à không xung đột cho các traverse 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ý kinh điển: Sổ đăng ký tenant vận hành được ghi trong gốc tenant tương ứng tại .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ó thẩm quyền của 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 tạo tác tuân thủ thông qua các tham chiếu prev-hash:

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

Mỗi chứng từ tham chiếu mã băm SHA-256 của chứng từ trước đó. Do đó, toàn bộ chuỗi được neo bằng mật mã và chống sửa đổi.

Lược đồ siêu dữ liệu (tạo tác dữ liệu `.gc.md`)

Tạo tác dữ liệu nằm dưới dạng JSON fence ở cuối tài liệu (phần người đọc được trước, dữ liệu sau cùng):

{
  "docUid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "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à sidecar GitCover

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 đưa vào chuỗi chứng từ thông qua một sidecar GitCover (*.gc.md bên cạnh bản gốc): Sidecar mang ít nhất sha256 của bản gốc cũng như DocID (uuidv7, định danh thể hiện) và v7guid đã được phân loại (ngữ cảnh). Quy trình và việc cấp DocID từ dấu thời gian tệp được mô tả trong Trục 5: Các phương pháp; việc đăng ký tenant liên quan xem Sổ đăng ký tenant trung tâm ở trên. Để phân biệt: docUid (thể hiện), sha256 (nội dung), V7GUID (lớp) và GCPN-docUid (quy trình) là các trục riêng biệt; chỉ docUid của tài liệu trở thành object_id của DMS.

Nhận biết siêu dữ liệu và các biến thể companion

Việc nhận biết siêu dữ liệu tài liệu do nội dung điều khiển, không do phần mở rộng. Một Ur-Doc có siêu dữ liệu khi một thể hiện lược đồ JSON được nhúng mô tả chúng:

Sidecar cơ sở <artefakt>.<orig-ext>.gc.md: Thể hiện mang docUid (thể hiện tài liệu), sha256 (neo nội dung), v7guid (lớp) và locations; docUid là object_id của tài liệu.
Biến thể companion *.gcsig.md với khối source được tích hợp: GCSIG là một tạo tác chữ ký có docUid riêng; thể hiện tài liệu nằm trong source.v7g_docUid, neo nội dung trong subject.sha. DMS tiếp nhận source.v7g_docUid làm object_id của tài liệu và chỉ mang docUid của GCSIG dưới dạng GCSIG:<docUid> trong các tham chiếu siêu dữ liệu.

Trong vòng đời của một tài liệu hoặc quy trình, các siêu tài liệu có thể thay đổi vai trò và do đó thay đổi hồ sơ của chúng — tương tự các biến thể OOD (overload/đa hình): cơ sở sidecar (.gc.md) chuyển thành một tạo tác chữ ký (.gcsig.md với source); GCPN (.gcpn.md) vẫn là quy trình và được bổ sung gia tăng qua documents[]/children[]/relations[]; neo GCAL (GCPN dưới .gitcover/gcal/<uuidV7>.gcpn.md) vẫn là neo quy trình. Việc đổi tên không thay đổi danh tính của siêu tài liệu (docUid/quy trình vẫn giữ nguyên), nhưng thay đổi SHA-256 của tệp; một chuyển đổi quy trình được phép đổi tên hoặc tạo mới và hợp nhất dữ liệu hiện có. Điều quyết định là danh tính nội dung, không phải tên tệp.

Vùng chứa quy trình (`.gcpn.md`) — cấp quy trình của chuỗi chứng từ

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

Doc có thể thay đổi với các tạo tác JSON bất biến (lược đồ gcpn-container-2.7, self-contained): referenced_doc, actor, retention được mô tả mỗi thứ một lần; cây thông qua parents[]/children[]/documents[]; 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.
Sự kiện dưới dạng enum cờ có kết quả: offered(1), accepted(2), denied(4), sign(8), withdraw(16) — các bước đã trải qua tạo thành bitmask events_result (ví dụ: 11 = offered + accepted + sign) với xác nhận chain_valid của việc nối chuỗi băm.
Bổ sung thay vì tạo mới: Mỗi bước quy trình mới đặt cờ, nhúng tạo tác mới và cập nhật summary; các tạo tác JSON đã được nhúng vẫn không thay đổi (bất biến). Lịch sử vùng chứa nằm 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 phình to).
Chức năng chỉ mục GCDMS: Trong DMS được gắn tùy chọn, vùng chứa đóng vai trò chỉ mục để điều hướng quy trình đến các tài liệu riêng lẻ — thay cho n8n hoặc các workflow engine tương tự.

Sau đó, một Referenced-Doc đã ký trở thành bất biến (GoBD: tính không thể thay đổi); vùng chứa vẫn có thể thay đổi và tiếp tục ghi lại quy trình — lịch sử Git là bằng chứng.

GCPN một tệp — theo dõi chứng từ lũy tiến/hồi quy (AO, 261026)

Đối với hóa đơn và các chứng từ khác, GCPN trở thành vùng chứa một tệp: một .gcpn.md mang documents[] (XML là Ur-Doc, PDF là chế độ xem), workflow create→pdf→present→accept→sign→register, events, properties.values và relations (hợp đồng/chứng từ chi phí). XML/PDF vẫn là các tạo tác riêng biệt; một .gc.md riêng bị loại bỏ — GCPN quản lý docUid, SHA-256, đường dẫn và tiêu đề.

Hướng	Bắt đầu	Cạnh	Đích	AO/GoBD
Lũy tiến	GCPN (`docUid`)	`documents[]`/`relations[]`	XML, PDF, hợp đồng, chứng từ	Rz. 147
Hồi quy	Chứng từ (`docUid` trong DMS)	`SidecarIndex` → GCPN	GCPN → `relations[]`	Rz. 146

Do đó, GCPN là điểm hội tụ duy nhất cho UI và tooling; SAGA (tạo, trình bày, chấp nhận, chữ ký, đăng ký) nằm hoàn toàn trong vùng chứa. Tham chiếu chuẩn tắc: specs/v7guid/70_belegkreise-dokumentenzuordnung.de.md § „Ein-Datei-GCPN".

Quy tắc thăng cấp: Một .gc.md hiện có có thể được làm phong phú vào GCPN; các tạo tác JSON sidecar được nhúng (GCPN = tập cha, .gc.md = tập con). Sau đó, .gc.md riêng là dư thừa và có thể bị xóa khỏi hệ thống tệp; lịch sử Git mang khả năng truy vết (GoBD), GCPN vẫn là SSoT.

Gates/OPA: workflow.gates[].id là một uuidV7 của hành động/phương thức (GCAL-/GCEP-Join), workflow.gates[].rule là policy_uuid của danh tính OPA/quy tắc; cả hai đều được đăng ký (GCUV/TOP/compliance/gates.json hoặc policies/registry.json). rule_text chỉ là hiển thị; các lớp/kiểu chạy qua các danh mục V7GUID.

Bộ sưu tập bất biến: Các định nghĩa bất biến (ENUM/UNION/Flags) nằm trong OSS/TOP/.gitcover/dictionaries/immutable_collections.json và được tải một lần khi khởi tạo hệ thống. GCPN tham chiếu chúng qua events.enum_ref (uuidV7) thay vì lặp lại; lược đồ 2.7 làm cho enum_definition thành tùy chọn (legacy). Các cờ bắt nguồn từ các danh mục OSCAL cho GoBD/AO (hồ sơ gcpn-compliance-profile.yaml; AO §146, GoBD Rz. 146/147) — việc neo quản trị nằm trong sổ đăng ký.

Danh tính hóa đơn: properties.values.invoice_id là uuidV7 của Invoice Identifier; invoice_no chỉ là văn bản và không phải tiêu chí sắp xếp. Seller/Buyer được tham chiếu qua Party-uuidV7 của họ (creditor/vendor hoặc debitor/customer), không qua tên thật (PII).

GCPN như biên bản — Act như chuyển 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, người ta thường nói về các cuộc họp cổ đông với các nghị quyết, được tổng hợp trong một GVB:

Thuật ngữ	Nghĩa biên bản	Nghĩa trạng thái
GVB	biên bản của cuộc họp (tài liệu tổng hợp)	có thể chứa nhiều Act (nghị quyết)
Act	nghị quyết riêng lẻ	mô tả sự thay đổi giữa hai trạng thái (trước → sau)
GCPN	biên bản quy trình cho vụ việc (hình thành, ký kết)	ghi lại các chuyển trạng thái an toàn để kiểm toán (sự kiện dưới dạng cờ, `referenced_doc.status`, bitmask `events_result`)

Cách hiểu kép này (biên bản + chuyển trạng thái) là cốt lõi của khả năng chứng minh: mỗi Act được mô tả 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 cờ và tạo tác được nhúng. Lịch sử Git của vùng chứa cung cấp niên đại. Quy trình và xác minh: Trục 3 (GCPN) và Ký số (DS02–DS05).

Chuỗi bằng chứng mật mã

Chuỗi bằng chứng mật mã kết hợp ba nguyên thủy mật mã:

Git-Commit-Hash - tính bất biến của trạng thái repository
Chữ ký GPG - danh tính của tác nhân (Ai đã quyết định?)
V7GUID - định địa chỉ tất định (Cái gì và Khi nào)

Do đó 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 tuân thủ an toàn để kiểm toán.

Phương án dự phòng khôi phục: Cuối cùng chỉ còn lại các repo Git Trong trường hợp thảm họa, mất hạ tầng hoặc kiểm toán 10 năm sau, bộ tạo tác cuối cùng còn hoạt động được chính là repo Git (hoặc git bundle/xuất ZIP). Trong đó có: Code-Artifacts, các sổ đăng ký/từ điển trong .gitcover/ (JSON/JSONL), các keyring GPG (.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 dịch vụ đang chạy. Pháp chứng là repo Git — các gói kiểm tra HTML chỉ là dẫn xuất trình bày (xem Các phương pháp: 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 repo Git. Thông qua sự kết hợp của:

Repo Git như các kỳ tuân thủ (ví dụ: FY2026)
Các lớp V7GUID như các loại tài liệu (INVOICE, PAYMENT, PERSON)
Chính sách OPA như các pre-receive hook (xác thực trước commit)

tạo ra các cấu trúc tuân thủ có thể tái tạo, có khả năng kiểm toán - không cần bảo trì thủ công.

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