____12DS — Lược đồ gcpn-container-1.0: Tổng quan

Yếu tố kích hoạt S6

Vụ việc ký số thực sự đầu tiên (ký GVB) ban đầu tạo ra các tệp .json độc lập trong thư mục res/ — một cách làm việc làm phình to Git-repo (phát hiện của AP: "điều này làm phình to Git-repo một cách không cần thiết"). Phát hiện này dẫn đến việc điều chỉnh: Tất cả artifact JSON trong MỘT Container-Doc (.gcpn.md, phần mở rộng vĩnh viễn), và bản thân container trở thành JSON-Schema chuẩn tắc — gcpn-container-1.0.

Tổng quan về lược đồ

{
  "$schema": "https://gitcover.org/schemas/gcpn-container-1.0.schema.json",
  "container_id": "GCPN-SIG-YYMMDD-NNN",
  "uuidV7": "<deterministisch aus ts + doc-sha256>",
  "kind": "signature-process",
  "tenant": { … },
  "referenced_doc": { … },
  "actor": { … },
  "attendees": [ … ],
  "persons": { … },
  "retention": { … },
  "signature": { … },
  "events": { … },
  "summary": { … },
  "prev_container": null,
  "next_container": null,
  "sidecar": "<Referenced-Doc>.gcpn.md.v7g.md"
}

Tính duy nhất của artifact (kết luận AP1)

Mỗi thực thể được mô tả đúng một lần:

Những quy tắc rút ra từ phát hiện

1. JSON luôn được nhúng (MD-Fence trong container) — không có tệp .json độc lập trong cây repo (tránh phình to).
2. Bổ sung thay vì tạo mới: Mỗi bước quy trình mới đặt một flag, nhúng artifact mới vào, cập nhật summary — các artifact JSON đã nhúng từ trước vẫn giữ nguyên immutable.
3. An toàn sửa đổi nhờ Git: Lịch sử container nằm trong lịch sử Git của repo (Commit-Hash = bằng chứng toàn vẹn).
4. Doc mutable, artifact JSON immutable: Container-MD có thể chỉnh sửa (phát triển cùng vụ việc); nội dung JSON là bất biến — thay đổi = artifact mới với SHA mới.
5. Commit chỉ do E1 thực hiện (NO-AUTO-COMMIT).

Tài liệu nguồn được lập danh mục qua lược đồ Sidecar

Một „Ur-Doc-Schema" riêng biệt là không cần thiết: Lược đồ v7g-sidecar-1.0 (.v7g.md) chính là JSON-Schema thực sự cho một Ur-/Quell-Document số — nó lập danh mục tài liệu nguồn qua sha256 (ID tài liệu, nhận diện mọi lúc mọi nơi, kể cả khi di chuyển), locations (lịch sử UNC), v7g_taxonomy (lớp) và obsolescence/ Retention. Container (referenced_doc) tham chiếu đến nó — hai tầng lược đồ, không dư thừa: Sidecar = lập danh mục tài liệu nguồn, Container = vụ việc/quy trình.

Hai định danh dùng để làm gì — V7GUID là Doc-Type-Register, uuidV7 là Ref-Doc-UID

Điều này cũng làm rõ hơn mục đích sử dụng riêng của từng định danh:

Sự phức tạp (hai định danh thay vì một) thoạt nhìn có vẻ như vậy lại chính là đòn bẩy cho việc tuân thủ dựa trên Git-repo không bị Vendor Lock-In: Mọi thứ đều có thể suy ra từ các repo (xác định một cách tất định) — không chỉ các trạng thái của doc (chuỗi SHA-256, biểu thức Flags), mà còn cả lịch sử và các thay đổi (lịch sử Git của container: những bước nào được bổ sung vào lúc nào; lịch sử sidecar: các hồ sơ phân loại kèm dấu thời gian). Không có hệ thống độc quyền nào lưu trữ trạng thái — bản thân repo chính là trạng thái, và bất kỳ kiểm toán viên nào cũng có thể lặp lại phép suy ra đó bằng các công cụ mở.

Xác minh không dư thừa

Thủ tục xác minh (DS04) vẫn được giữ nguyên — nó làm việc với manifest trong container: sha256sum của từng artifact đối chiếu với events.flags_set[].sha256 hoặc referenced_doc.sha256; chuỗi qua chain_valid; Facsimile-SHA đối chiếu với bảng trong SIGNATURE_BLOCK.md.

Biên bản kết quả nghiên cứu (AP)

---

Đã tạo: 260913 | Phần III, Bài ____12DS | Chuỗi: digital-signage