DS01 — Yêu cầu về Textform và việc đánh giá chứng cứ tự do

Tình huống khởi phát S1

Cổ đông duy nhất (placeholder E1 với tư cách doanh nhân, tổ chức ORG-1) thông qua một nghị quyết cổ đông (GVB) — chẳng hạn như phê duyệt một khoản bồi thường chi phí. Điều lệ yêu cầu việc thông qua nghị quyết bằng Textform. E1 hỏi: Tôi có thể làm điều đó trong Git-Repo không — và một nghị quyết mà người kiểm tra sau này công nhận là "được lập bằng Textform" thì trông như thế nào?

Điều mà § 126b BGB yêu cầu

§ 126b BGB (Textform): "Nếu luật không quy định hình thức văn bản viết, mà quy định Textform, thì Textform có thể được thay thế bằng bất kỳ hình thức truyền tải điện tử phù hợp nào, miễn là (1) người mà tài liệu dành cho có thể truy cập tài liệu thông qua địa chỉ do người nhận chỉ định, (2) tài liệu được tạo khả năng tiếp cận cho người khác và phù hợp để hiển thị dưới dạng nguyên văn trên màn hình, và (3) người đưa ra tài liệu đã ghi rõ ràng tài liệu là do mình xuất phát nhằm bảo vệ các lợi ích mà người đó đại diện."

Ba điều kiện tiên quyết, ba cách diễn giải theo GitCover:

§ 126b BGB	Diễn giải GitCover
(1) Truy cập qua địa chỉ của người nhận	Tenant-Repo (Gitea) chính là địa chỉ; người nhận (cổ đông, GF) có quyền truy cập đọc
(2) Có thể tiếp cận, hiển thị được nguyên văn	Markdown-Doc chính là nguyên văn — `cat`, Typora, bất kỳ trình duyệt nào cũng hiển thị được nó
(3) Gán nguồn gốc ("được ghi rõ ràng là do mình xuất phát")	Signatur-Doc gán tài liệu một cách nhận biết được cho người ký: Tên + vai trò + tham chiếu Facsimile trong một JSON-Artefakt được neo bằng SHA-256 (DS02)

Điểm (3) không yêu cầu một chữ ký đủ điều kiện. Nó yêu cầu một việc gán nguồn gốc rõ ràng: Người nhận phải có thể nhận ra ai là người đưa ra tài liệu. Chính tại đây, Signatur-Doc (DS02) và Signatur-Vorgang (DS03) bắt đầu phát huy tác dụng.

Đánh giá chứng cứ tự do (§ 286 ZPO)

Dưới góc độ luật tố tụng dân sự, văn bản Textform không phải là một sự kiện cần được chứng minh theo hình thức nghiêm ngặt — nó thuộc diện đánh giá chứng cứ tự do. Tòa án đánh giá xem các phương tiện chứng cứ hiện có có "hình thành sự tin tưởng theo niềm tin tự do" hay không. Điều đó có nghĩa là:

Không có hình thức cứng nhắc nào được coi là "đủ" — chỉ có những bằng chứng thuyết phục ở mức độ nhiều hay ít.
Một quy trình được ghi nhận liền mạch, có thể kiểm chứng lại (ai đã đưa ra tài liệu vào lúc nào, bằng khóa nào/hình ảnh nào, tính toàn vẹn đã có thể được xác minh ra sao) thuyết phục hơn một "biên lai chữ ký" đơn lẻ.
Ngược lại: Một ảnh chụp màn hình duy nhất về chữ ký email hầu như không thuyết phục; còn một bộ Artefakt dựa trên SHA-256 và đã được phân loại thì có.

GitCover chuyển hóa điều đó thành một chuỗi thân thiện với việc đánh giá chứng cứ:

Tính toàn vẹn: SHA-256 của tài liệu nguồn, của Signatur-Doc, của Sidecar.
Gán nguồn gốc: Signatur-Doc xác định người ký (tên, vai trò, tham chiếu khóa/hình ảnh) và liên kết qua SHA-256 với tài liệu nguồn.
Trật tự thời gian: dấu thời gian uuidV7 trong mỗi Artefakt (RFC 9562).
Phân loại danh mục: V7GUID-Class-Taxonomy trong Sidecar; người kiểm tra có thể nhận biết loại Artefakt mà không cần kiến thức ngữ cảnh.
Khả năng kiểm chứng lại: Lịch sử Git không phải là phương tiện chứng cứ duy nhất — chuỗi này cũng có thể được kiểm tra mà không cần Git (bằng jq, sha256sum, bất kỳ trình soạn thảo nào).

§ 371a ZPO — văn bản tư với hình thức điện tử

§ 371a ZPO: "Văn bản tư với hình thức điện tử có giá trị chứng cứ như văn bản tư với hình thức văn bản viết, nếu người phát hành kèm theo tên của mình và báo hiệu việc đưa ra tuyên bố dưới hình thức điện tử, hoặc nếu chúng được trang bị một chữ ký điện tử đủ điều kiện hoặc một con dấu chứng thực tương đương."

Ba nhận xét cho cách tiếp cận GitCover:

Kèm tên + báo hiệu hình thức là đủ — Signatur-Doc (DS02) làm chính xác điều đó: Tên/vai trò của người ký + báo hiệu hình thức rõ ràng ("việc đưa ra tuyên bố dưới hình thức điện tử").
QES là phương án dự phòng chắc chắn — nếu một hợp đồng cần có giá trị chứng cứ như văn bản tư với QES, thì tiêu chuẩn FES sẽ gắn vào (Phần II). Tuy vậy, nền tảng Textform vẫn luôn là cấp độ Repo.
Giá trị chứng cứ nằm ở chuỗi — không nằm ở một đặc điểm đơn lẻ. DS04 trình bày quy trình xác minh đầy đủ.

Lỗi phổ biến nhất: Chữ ký email

Tình huống thực tế mà GitCover muốn tránh:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR A["PDF gedruckt"] --> B["Handschrift
unterschrieben"] B --> C["Gescannt"] C --> D["Per Mail
gesendet"] D --> E["Mail-Verzeichnis
im Postfach"] E --> F["Prüfung: Wo ist die
Original-Unterschrift?"] style F fill:#f3d9d9,stroke:#8b2635

Các điểm đứt gãy trong chuỗi chứng cứ: Không có SHA-256, không có dấu thời gian, không có gán vai trò, không có khả năng kiểm chứng lại — "bản gốc" di chuyển qua lại giữa máy in, máy quét và trình khách email. Một GitCover-Doc tránh điều đó ở chỗ mỗi bước đều là một Artefakt trong Repo.

Tóm tắt

§ 126b BGB yêu cầu truy cập + nguyên văn + gán nguồn gốc — MD-Doc + Signatur-Doc đáp ứng điều đó theo cách Git thuần túy.
Với đánh giá chứng cứ tự do, chuỗi liền mạch (SHA-256 + thời gian + vai trò + phân loại danh mục) thuyết phục hơn một "biên lai chữ ký" bên ngoài.
§ 371a ZPO xác nhận: kèm tên + báo hiệu hình thức là đủ để có giá trị chứng cứ của văn bản tư; QES là phương án dự phòng chắc chắn, không phải điều kiện bắt buộc đối với Textform.
Bài viết tiếp theo (DS02) định nghĩa Signatur-Doc dưới dạng JSON-Schema.

Đã tạo: 260913 | Phần I, bài viết DS01 | Chuỗi bài: digital-signage