Trục 3: Các thành phần

Tổng quan

GCBoK định nghĩa sáu thành phần cốt lõi của GitCover-Stack:

GCDMS - GitCover Document Management System

Hệ thống quản lý bằng chứng và tài liệu dựa trên các container .v7g.md và metadata của chúng. Toolchain: v7g-pack, v7g-verify, v7g-sign, v7g-export.

GCPN - GitCover PrimaNota

Cơ chế metadata để hình thành các chuỗi bằng chứng chống sửa đổi (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 nghiệp vụ kinh doanh - ví dụ một bút toán của kế toán kép hoặc một giao dịch hạch toán gồm nhiều phần (khoả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 key duy nhất để xác định sự thuộc về nhau. GCPN chuyển nguyên tắc này sang nền tảng UUIDv7: Mỗi tài liệu nhận một Identifier sắp theo thời gian (RFC 9562) và được nối chuỗi với các tài liệu tiền nhiệm và kế nhiệm của nó thông qua các tham chiếu Predecessor/Successor.

Việc nối chuỗi diễn ra không theo trình tự 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ó với vai trò tiền nhiệm (Predecessor-Insert) - yếu tố quyết định cho GoBD Rz. 80 (kiểm tra tiến triển và hồi tố). Các trường Match-Key (số đơn hàng, khách hàng nợ, số tiền brutto, 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 container .v7g.md kết hợp metadata mà con người có thể đọc (YAML + Markdown) với dữ liệu kinh doanh mà máy có thể xử lý (JSON nhúng) và được lưu trữ trong các Git-Repository, trong đó Commit-Hash đóng vai trò là bằng chứng toàn vẹn bằng mật mã.

Các lĩnh vực ứng dụng vượt ra ngoài kế toán: danh mục xử lý dữ liệu DSGVO (Art. 30), chuỗi sự cố NIS2, các quyết định kiến trúc MADR, vòng đời token OIDC/OAuth, OSCAL-Assessment-Results.

Container chữ ký GCPN (`.gcpn.md`) — đồng hành quy trình thay vì các tệp đơn 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 nằm cạnh Referenced-Doc (quy ước đặt tên <Referenced-Doc-Basisname>.gcpn.md) đồng hành cùng quy trình hình thành và ký duyệt — nó không phải là sidecar của Referenced-Doc, mà là container quy trình.

Quan niệm thiết kế cốt lõi:

Doc mutable, các JSON artifact immutable: Container-MD được bổ sung cho mỗi bước quy trình mới; các JSON artifact đã được nhúng (Schema gcpn-container-1.0: referenced_doc, actor, retention mỗi cái được mô tả một lần; events dưới dạng Flags-Enum với bitmask events_result, ví dụ 11 = offered + accepted + sign; summary) giữ nguyên không đổi.
Chống sửa đổi nhờ Git: Lịch sử của container (những bước nào được bổ sung khi nào) nằm trong lịch sử Git của repo — Commit-Hash đóng vai trò là bằng chứng toàn vẹn bằng mật mã.
Không JSON-Bloat: Các JSON artifact luôn được nhúng (MD-Fence) — không có tệp .json độc lập trong cây repo.
Chức năng Index của GCDMS: Trong DMS được gắn nối tùy chọn, container đóng vai trò Index — điều hướng quy trình đến các Doc đơn lẻ và đến mô tả quy trình, thay vì n8n hoặc các Workflow-Engine tương tự.
Chuyển tiếp immutable: Một Referenced-Doc đã ký sau đó trở thành immutable; container vẫn mutable và tiếp tục ghi lại quy trình (lịch sử Git = bằng chứng).

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

Bảo hộ Gebrauchsmuster: 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 container dùng cho quản lý tài liệu kinh doanh dựa trên UUIDv7, chống sửa đổi, với nối chuỗi Predecessor/Successor động. Đơn đăng ký sáng chế đã được nộp (47 yêu cầu bảo hộ).

GCUCB - GitCover Unified Context Bus

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

OPA/Rego đóng vai trò là tầng guardrail tất định: việc kiểm tra chính sách được tạo ra từ bộ quy tắc, không phải từ Prompt-Engineering.

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

Phân định

Thành phần	Tầng	Phân định với GCUCB
GCEP	Lưu trữ bền vững (Git-to-Git)	Giữa các instance; GCUCB = Runtime-Bus
GCSYNC	Outbound (Git -> RAG)	Kênh bên ngoài; GCUCB = bus nội bộ
GCPN	Logic nối chuỗi	Chuỗi bằng chứng (tiền nhiệm/kế nhiệm); GCUCB = Truyền tải/Truy cập

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

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

GCUCB giải quyết chính vấn đề đó ở tầng truyền vận và truy cập: các đối tượng ngữ cảnh được định kiểu, việc đánh địa chỉ V7GUID mang tính tất định, và sự ghép nối giữa bằng chứng và Policy tại thời gian chạy. Việc phân tách thuật ngữ rõ ràng này là có chủ đích: Một ontology mô tả ý nghĩa của các thuật ngữ (trong GitCover: các L1–L6-Dictionaries, xem Khái niệm: Phân cấp doanh nghiệp như một ontology); GCUCB quy định cách các Agent, các validator và các hệ thống kiểm toán truy cập vào nó tại thời gian chạy. Hai tầng này bổ sung cho nhau — GCUCB không phải là một sản phẩm ontology, và ontology không cần một đồ thị nền tảng khi nó sống Git-native ngay trong repo.

GCEP - GitCover Exchange Protocol

Giao thức trao đổi giữa các instance giữa các Git-Repo trên các nền tảng khác nhau. Ngữ nghĩa được xác định bởi các catalog OSCAL và các Hook/Callback do OPA định nghĩa.

IETF-Track đã được lên kế hoạch (I-D, dạng ngắn: gcep). Đơn đăng ký sáng chế: 10 2025 003 359.1.

Các tầng giao thức: ACP, MCP và GCEP

GCEP không được nhầm lẫn với các giao thức của AI agent. Cả ba giải quyết các vấn đề khác nhau trên các tầng 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

Tầng	Giao thức	Hướng	Mục đích
Cầu 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 của agent
Cầu ngữ cảnh AI	MCP (Model Context Protocol)	Agent ↔ Dữ liệu	Truy cập có cấu trúc của agent vào các nguồn dữ liệu (tài liệu, Tools)
Tầng Repository	GCEP	Server ↔ Server	Nhân bản, đồng bộ hóa và bảo đảm trạng thái giữa các Git-Instance vật lý

Sự kết hợp này có ý nghĩa rất cao đối với cấp quản lý: Agent làm việc qua ACP/MCP với tốc độ cao; GCEP bảo đảm ở tầng Repository bên dưới rằng các đường Commit và đồng bộ hóa luôn nhất quán.

Các Advisory Lock trong kỷ nguyên AI

Các AI agent tự chủ tạo ra các thao tác ghi với tần suất cao. Nếu không có giao thức khóa ở tầng Git, hai agent hoạt động song song - hoặc một agent và một nhân viên nghiệp vụ - có thể đồng thời sửa đổi cùng các Repository và tạo ra các trạng thái không nhất quán (Race Conditions).

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 một cách tự nguyện trước khi ghi	Hệ điều hành ép buộc khóa một cách cứng rắn
Hành vi khi Timeout	Agent có thể phản ứng một cách chiến lược: dời Subgoal, phát thông báo UI	Thường là các trạng thái hệ thống chết (Deadlock)
Mức phù hợp với AI agent	Cao - agent truy vấn trước trạng thái khóa (ví dụ qua một MCP-Git-Server)	Thấp - chặn pipeline của agent

Một AI agent có thể truy vấn trước trạng thái khóa GCEP ("Repository này có bị khóa đối với một cơ sở kinh doanh khác không?") và điều chỉnh kế hoạch của mình tương ứng - thay vì bị chặn cứng.

GCAL - GitCover Advisory Lock

Cơ chế Distributed Lock giữa các Git-Repo - tương tự PostgreSQL Advisory Lock, nhưng ở tầng Repo. Điều kiện tiên quyết cho GCEP: Trước khi hai instance trao đổi dữ liệu, một Lock phải bảo đảm việc chuyển giao nguyên tử.

GCSYNC - GitCover Sync

Kênh Outbound từ GitCover ra ngoài tới các hệ thống lưu trữ dữ liệu khác. Cung cấp dữ liệu cho các 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.