Trục 3: Thành phần

Tổng quan

GCBoK định nghĩa sáu thành phần cốt lõi của ngăn xếp GitCover:

graph TD GCAL["GCAL - Advisory Lock"] GCEP["GCEP - Exchange Protocol"] GCSYNC["GCSYNC - Sync (Outbound)"] GCUCB["GCUCB - Unified Context Bus"] GCPN["GCPN - PrimaNota"] GCDMS["GCDMS"] GCAL -->|"Lock-Koordination"| GCEP GCEP -.->|"OSCAL/OPA Hooks"| OPA["OPA Policy Engine"] GCSYNC -->|"Outbound"| RAG["RAG / MCP"] GCUCB -->|"Guardrails"| OPA

GCDMS - GitCover Document Management System

Hệ thống quản lý tài liệu và bằng chứng cho các kho Git. Việc lưu trữ tuân theo họ phần mở rộng .gc.*: sidecar tổng quát <artefakt>.<orig-ext>.gc.md, vùng chứa quy trình .gcpn.md, tạo tác chữ ký .gcsig.md, tạo tác dữ liệu .gc.json. Công cụ: gc-dms (registry: scan, validate, pack, verify, check), gc-sidecar (tạo sidecar), gc-docsign (GCSIG/chữ ký), gc-v7guid (lớp và danh tính).

Registry DMS là một danh mục, không phải kho lưu trữ: Các bản gốc vẫn ở vị trí lưu trữ của chúng; registry ghi lại cho mỗi tài liệu SHA-256, object_id và storage_locations cùng nguồn gốc. object_id là docUid của sidecar (không phải danh tính thứ hai); stored_by_pgid là hành động ingest DMS đã đăng ký (ví dụ pgid 183), stored_by_user_id là uuidV7 của người. Hành động tạo ra (produced_by_pgid, ví dụ 180 cho hóa đơn) được ghi riêng trong bộ siêu dữ liệu hóa đơn/GCPN. Danh mục registry: GCUV/TOP/compliance/process_gateways.json; giá trị chuẩn tắc: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

Danh tính (không nhầm lẫn): docUid (thực thể), sha256 (neo nội dung), V7GUID (lớp) và GCPN-docUid (quy trình) là bốn trục riêng biệt. Chỉ docUid của tài liệu — từ sidecar cơ sở hoặc với sidecar tích hợp từ source.v7g_docUid trong .gcsig.md — trở thành object_id của tài liệu; docUid của GCSIG vẫn là tạo tác chữ ký (subject.sha = SHA tài liệu), docUid của GCPN vẫn là quy trình. Việc nhận diện dựa trên nội dung (thực thể JSON Schema được nhúng), không dựa trên phần mở rộng.

Thứ tự (tất định): documents[] được sắp xếp theo sha256; storage_locations[] theo source_root_id, unc_path (null cuối cùng), original_path và stored_at_utc. Việc tuần tự hóa giữ thứ tự khóa ổn định. Bộ lọc thời gian và sắp xếp chạy qua docUid thực thể uuidV7, không qua V7GUID của lớp.

GCPN - GitCover PrimaNota

Cơ chế siêu dữ liệu để tạo chuỗi bằng chứng có thể kiểm toán (tiền nhiệm/kế nhiệm) cho tài liệu kinh doanh. Thuật ngữ lịch sử PrimaNota chỉ một khóa sắp xếp gán cho một vụ việc kinh doanh - ví dụ một bút toán của kế toán kép hoặc một quy trình ghi sổ nhiều phần (phải thu, thuế giá trị gia tăng, phân bổ trung tâm chi phí/đối tượng chi phí) - một khóa duy nhất cho sự thuộc về nhau. GCPN chuyển nguyên tắc này sang cơ sở UUIDv7: Mỗi tài liệu nhận một định danh có thứ tự thời gian (RFC 9562) và được liên kết với các tài liệu tiền nhiệm và kế nhiệm thông qua tham chiếu predecessor/successor.

Việc liên kết diễn ra phi thời gian: Một tài liệu được ghi nhận muộn hơn có thể được chèn vào một chuỗi hiện có như tiền nhiệm (predecessor-insert) - quyết định cho GoBD Rz. 80 (kiểm tra tiến và lùi). Các trường khóa khớp (số đơn hàng, con nợ, tổng số tiền gộp, v.v.) cho phép liên kết chuỗi tự động mà không cần gán thủ công.

Định dạng .gc.md tách phần dành cho người đọc ở trên (tiêu đề, bảng, văn xuôi) khỏi tạo tác dữ liệu ở dưới (JSON code fence); JSON được ưu tiên hơn YAML làm vật mang dữ liệu (JSON-first). Tệp nằm trong các kho Git mà hash commit của chúng đóng vai trò bằng chứng toàn vẹn mật mã.

Lĩnh vực ứng dụng ngoài kế toán: sổ đăng ký xử lý DSGVO (Art. 30), chuỗi sự cố NIS2, quyết định kiến trúc MADR, vòng đời token OIDC/OAuth, kết quả đánh giá OSCAL.

Container chữ ký GCPN (.gcpn.md) — đồng hành quy trình thay vì tệp riêng lẻ

Đối với các quy trình chữ ký, GCPN cụ thể hóa thành một Prozess-Ur-Doc độc lập: Một tệp .gcpn.md bên cạnh Referenced-Doc (quy ước đặt tên <Referenced-Doc-Basisname>.gcpn.md) đồng hành với quy trình hình thành và ký — nó không phải sidecar của Referenced-Doc, mà là vùng chứa quy trình. Một .gcpn.md.gc.md riêng biệt không còn cần thiết: Vùng chứa mang docUid GCPN riêng của nó và đồng thời là chỉ mục của quy trình.

Thiết kế chính:

Lần sử dụng đầu tiên: ký GVB với chữ ký facsimile (Phần I của Ký số, DS02–DS05).

Bảo hộ mẫu hữu ích: Az 20 2026 000 272.7 - có hiệu lực. Đối tượng được bảo hộ: cấu trúc dữ liệu vùng chứa để quản lý tài liệu kinh doanh dựa trên UUIDv7, có thể kiểm toán, với liên kết predecessor/successor động. Đơn đăng ký bằng sáng chế đã được nộp (47 điểm yêu cầu).

GCUCB - GitCover Unified Context Bus

Bus ngữ cảnh cho phối hợp runtime giữa các tác nhân AI, trình xác thực chính sách và hệ thống kiểm toán — với địa chỉ hóa V7GUID tất định của các đối tượng ngữ cảnh. GCUCB giải quyết vấn đề chi phí phối hợp của các workflow tác nhân nhiều bước (chi phí tuần tự hóa và token khi chuyển giao ngữ cảnh) bằng một bus có kiểu, có thể địa chỉ hóa trực tiếp thay vì các lớp trung gian dựa trên văn bản.

OPA/Rego hoạt động như một lớp guardrail tất định: việc kiểm tra chính sách hình thành từ bộ quy tắc, không phải từ prompt engineering.

Tình trạng bảo hộ (mẫu hữu ích, đơn nộp DPMA 260909) đã được neo; các đặc điểm kiến trúc và phương pháp cụ thể được mô tả trong hồ sơ đăng ký và ở đây chỉ được trình bày ở dạng tổng quát cho đến khi công bố.

Phân biệt

Thành phần Lớp Phân biệt với GCUCB
GCEP Lưu trữ (Git-to-Git) Thực thể-đến-thực thể; GCUCB = bus runtime
GCSYNC Outbound (Git -> RAG) Kênh bên ngoài; GCUCB = bus nội bộ
GCPN Logic liên kết Chuỗi bằng chứng (tiền nhiệm/kế nhiệm); GCUCB = vận chuyển/truy cập

Bối cảnh thị trường: „Ontology" không phải GCUCB

Hiện nay thị trường giải quyết cùng vấn đề cơ bản — các tác nhân cần ngữ cảnh doanh nghiệp nhất quán, đọc được bằng máy — dưới thuật ngữ „Ontology": Microsoft chẳng hạn cung cấp với „Fabric IQ" (Preview) một „governed, self-service knowledge graph" như lớp ngữ nghĩa mà các tác nhân tiêu thụ như „shared context layer" (Entity types, Relationships, GQL-Graph, OneLake-Bindings). Đó là một lớp dữ liệu và ngữ nghĩa, không phải kiến trúc vận chuyển runtime.

GCUCB tấn công cùng vấn đề ở cấp độ vận chuyển và truy cập: các đối tượng ngữ cảnh có kiểu, địa chỉ hóa V7GUID tất định, liên kết bằng chứng và chính sách tại runtime. Việc tách thuật ngữ rõ ràng là có chủ đích: Một ontology mô tả các thuật ngữ có nghĩa là gì (tại GitCover: các từ điển L1–L6, xem Khái niệm: Phân cấp nghiệp vụ như ontology); GCUCB xác định cách các tác nhân, trình xác thực và hệ thống kiểm toán truy cập chúng tại runtime. Cả hai cấp độ bổ sung cho nhau — GCUCB không phải sản phẩm ontology, và ontology không cần đồ thị nền tảng nếu nó sống Git-native trong kho.

GCEP - GitCover Exchange Protocol

Giao thức trao đổi thực thể-đến-thực thể giữa các kho Git trên các vật mang khác nhau. Được xác định về ngữ nghĩa bởi các danh mục OSCAL và hook/callback do OPA định nghĩa.

Dự kiến theo IETF-Track (I-D, dạng viết tắt: gcep). Đơn đăng ký bằng sáng chế: 10 2025 003 359.1.

Các cấp độ giao thức: ACP, MCP và GCEP

Không được nhầm GCEP với các giao thức tác nhân AI. Cả ba giải quyết các vấn đề khác nhau ở các cấp độ khác nhau:

graph TD A["Präsentations-Ebene / UI
(z. B. VS Code)"] -->|"Agent Client Protocol (ACP)"| B["Logik-Ebene / KI-Agent"] B -->|"Model Context Protocol (MCP)"| C["Infrastruktur- & Daten-Ebene"] C -->|"GitCover Exchange Protocol (GCEP)
mit Advisory Locks"| D["Verteilte Git-Server / VCS"] style A fill:#bbdefb style B fill:#c8e6c9 style C fill:#ffe0b2 style D fill:#f8bbd0
Cấp độ Giao thức Hướng Mục đích
Cầu nối UI ACP (Agent Client Protocol) UI ↔ Agent Kết nối giao diện người dùng (ví dụ VS Code) với logic tác nhân
Cầu nối ngữ cảnh AI MCP (Model Context Protocol) Agent ↔ Dữ liệu Truy cập có cấu trúc của tác nhân vào nguồn dữ liệu (tài liệu, công cụ)
Cấp kho lưu trữ GCEP Server ↔ Server Sao chép, đồng bộ hóa và bảo đảm trạng thái giữa các thực thể Git vật lý

Sự kết hợp này rất quan trọng đối với quản lý: Tác nhân làm việc qua ACP/MCP với tốc độ cao; GCEP bảo đảm ở cấp kho lưu trữ bên dưới rằng các đường commit và đồng bộ hóa vẫn nhất quán.

Advisory Lock trong thời đại AI

Các tác nhân AI tự trị tạo ra các truy cập ghi với tần suất cao. Không có giao thức khóa ở cấp Git, hai tác nhân hoạt động song song - hoặc một tác nhân và một nhân viên xử lý của con người - có thể sửa đổi đồng thời cùng các kho và tạo ra trạng thái không nhất quán (race condition).

Khía cạnh Advisory Lock Mandatory Lock
Cơ chế tác động Các tiến trình kiểm tra trạng thái khóa tự nguyện trước khi ghi Hệ điều hành cưỡng chế khóa cứng
Hành vi khi timeout Tác nhân có thể phản ứng chiến lược: hoãn mục tiêu con, phát thông báo UI Thường là trạng thái hệ thống chết (deadlock)
Tính phù hợp cho tác nhân AI Cao - tác nhân hỏi trước trạng thái khóa (ví dụ qua một MCP-Git-Server) Thấp - chặn pipeline tác nhân

Một tác nhân AI có thể hỏi trước trạng thái khóa GCEP ("Kho này có bị khóa cho một cơ sở vận hành khác không?") và điều chỉnh kế hoạch tương ứng - thay vì chặn cứng.

GCAL - GitCover Advisory Lock

Cơ chế khóa phân tán giữa các kho Git - tương tự PostgreSQL Advisory Lock, nhưng ở cấp kho. Điều kiện tiên quyết cho GCEP: Trước khi hai thực thể trao đổi dữ liệu, một khóa phải bảo đảm bàn giao nguyên tử.

Các action và quy tắc OPA được định danh qua uuidV7 (join GCAL-/GCEP); các gate/UUID chính sách đã đăng ký nằm trong GCUV/TOP/compliance/{gates.json,policies/registry.json}. rule_text chỉ là hiển thị; các lớp/kiểu chạy qua danh mục V7GUID.

GCSYNC - GitCover Sync

Kênh outbound từ GitCover ra các hệ thống lưu trữ dữ liệu khác. Cung cấp dữ liệu cho hệ thống RAG, MCP-Server và Nextcloud Shares.

Xem thêm: Quyền bảo hộ và trạng thái bằng sáng chế trong Quyền bảo hộ. Công nhận nghiên cứu trong Dự án nghiên cứu.