COUNCIL REVIEW VÒNG 1 — DESCRIPTION GOVERNANCE PACKAGE FIX 27

Thời điểm: 2026-04-22
Agent: Incomex Hội đồng AI (GPT)
Phạm vi: review dự thảo knowledge/current-state/reports/du-thao-description-governance-package-fix27.md
Verdict: APPROVE WITH CHANGES
Điểm: 8.3/10

1. Đánh giá tổng thể

Dự thảo đi đúng hướng lớn: tách rõ quy cách (Đ3) / enforcement tại birth (Đ4) / DOT-specific contract (Đ35) / giám sát (Đ43), phù hợp Đ37 §4.12 về SSOT nội dung luật. Gói sửa này đóng được lỗ hổng bản chất đang vi phạm NT14: luật hiện hành nói “description bắt buộc” nhưng chưa đủ cụ thể để agent tự viết auto-gen mà không hỏi lại.

Tuy nhiên, bản hiện tại chưa đạt APPROVE FINAL vì còn 5 điểm cần vá để đạt NT14 hoàn toàn:

Timing provenance PROV-DOT chưa đủ chặt: dự thảo nói “qua Đ24 entity_labels sau INSERT, hoặc inline nếu entity_labels trigger có” → agent vẫn phải đoán cách gán label.
Cross-table placeholder chưa có contract thực thi rõ cho collection_registry (species_code từ species_collection_map, source_database từ meta_catalog) → chưa đủ “thực thi được ngay”.
Không có nơi giữ mô tả cơ bản sau khi mô tả chi tiết ghi đè cùng cột description → mất thông tin tối thiểu/hard guarantee để audit/debug.
H11b phụ thuộc label PROV-DOT nhưng chưa định nghĩa DOT/trigger nào đảm bảo label đó luôn được gán đúng thời điểm.
Nguy cơ drift giữa Phụ lục Đ3, dot_config, và Đ43 §9.2.1 nếu template/mapping thay đổi mà không có một nguồn machine-readable duy nhất.

2. Rà soát 14 NT

NT1 — PASS/WARN

PASS về hướng thiết kế: template runtime sống trong dot_config (desc_template_<table>, desc_template_default) là SSOT vận hành, đúng tinh thần Constitution NT1 + NT4, và Đ3 §2.6 draft đã chốt điểm này.
WARN: Phụ lục Đ3 cũng lưu cùng nội dung template ở dạng bảng văn bản. Nếu phụ lục chỉ là tài liệu hóa còn PG là runtime SSOT thì ổn. Nhưng cần viết cứng: dot_config = SSOT máy chạy; Phụ lục Đ3 = documentation mirror. Nếu không sẽ có 2 nguồn template song song.

NT2 — WARN

Đ4 amend đã đưa auto-gen vào birth guard, tức đi đúng hướng “100% tự động”.
Nhưng chưa đạt 100% vì 2 chỗ còn cần agent tự quyết: (a) provenance PROV-DOT gán bằng trigger nào; (b) placeholder cross-table resolve ra sao.
Kết luận: đạt ~85%, chưa đủ chữ “100%” theo Constitution NT2.

NT4 — PASS/WARN

PASS: đổi template bằng UPDATE dot_config, 0 sửa code — đúng NT4.
WARN: fallback override desc_template_<table>_<composition_level> mới chỉ xuất hiện trong phụ lục, nhưng Đ4 function chưa mô tả lookup order tương ứng. Nếu muốn support thật, phải viết lookup chain rõ trong luật hoặc phụ lục triển khai: table+level -> table -> default.

NT9 — PASS

Template NULL → không gen, để guard warn/block như cũ là fail-safe đúng.
Đây là lựa chọn an toàn hơn so với sinh chuỗi giả hoặc nuốt lỗi. Phù hợp Constitution NT9 và pattern fail-fast của Đ43 rev 4/5/6.

NT12 — PASS/WARN

PASS: dual-trigger đã đủ hình thức: birth auto-gen/guard là trigger chính, H11a/H11b là trigger phụ theo chu kỳ.
WARN: H11b phụ thuộc PROV-DOT. Nếu provenance label không được gán atomically, vòng phụ sẽ báo sai mức. Cần chốt cơ chế gán nhãn trong cùng transaction hoặc cùng statement chain.

NT13 — WARN

Template/mode/threshold sống ở PG là đúng hướng PG-driven.
Nhưng logic resolve placeholder cross-table hiện còn ẩn trong “custom function” chưa có spec dữ liệu PG nào dẫn đường (ví dụ placeholder _species_code map qua bảng nào, khóa join nào). Chỗ này vẫn còn “code-driven by inference”, chưa đạt PG-driven hoàn toàn.

NT14 — WARN (trọng tâm)

Sau amend, agent gần như có thể viết mã auto-gen không hỏi lại, nhưng chưa hoàn toàn. Thiếu 4 mẩu thông tin vận hành quan trọng:

Placeholder nào lấy trực tiếp từ to_jsonb(NEW), placeholder nào là computed/cross-table.
Lookup chain template chính xác có hay không có composition_level override.
Cơ chế gán PROV-DOT là BEFORE/AFTER trigger, do function nào, join theo entity_code hay key khác.
Rule update/backfill cho row cũ “description ngắn quá” có được auto-gen lại không, hay chỉ NULL/rỗng.

=> NT14 chưa pass hoàn toàn. Đây là lý do chính không thể APPROVE FINAL ở vòng 1.

3. Rà soát SSOT theo Đ37 §4.12

Điểm mạnh — PASS

Đ3 sở hữu khái niệm 2 mức mô tả + template notion.
Đ4 sở hữu enforcement tại birth.
Đ35 sở hữu contract DOT-specific.
Đ43 sở hữu giám sát H11a/H11b. => Phân vai như vậy phù hợp Đ37 §4.12.

Chồng chéo cần chỉnh — WARN

Đ3 §2.5/§2.6 vs Đ43 §9.2.1
- Đ43 hiện đã có mapping bảng → entity type → format. Dự thảo sửa đúng khi nói Đ43 chỉ mapping operational.
- Nhưng nếu để bảng Đ43 vẫn ghi “Format description” khá chi tiết, agent có thể đọc nhầm Đ43 là nơi định nghĩa quy cách. Cần hạ wording tại Đ43 §9.2.1 xuống đúng mức “routing/mapping only”.
Đ35 §4.1.1 vs Đ3 §2.6
- DOT template cụ thể đặt ở dot_config.desc_template_dot_tools là đúng.
- Nhưng Đ35 hiện vẫn chứa contract 3 phần + ví dụ + min length. Đây là nội dung DOT-specific nên vẫn ổn; không phải chồng chéo xấu, miễn Đ35 không tự thành nơi quản template runtime thứ hai.

Viện dẫn liên luật — WARN

Dự thảo đã có block viện dẫn khá tốt, nhưng để đạt Đ37 §4.14 thật sạch cần 2 vá nhỏ:

Trong từng amend section nên có inline ref ngay tại từng câu rule vận hành chứ không chỉ gom ở block “Viện dẫn”.
Phụ lục Đ3 mới cũng nên có header block phụ thuộc: Đ0-B, Đ24, Đ29, Đ43.

4. Khả thi kỹ thuật

`fn_render_description_template()`

Đề xuất khả thi, nhưng cần chốt 4 edge cases trong luật/phụ lục triển khai:

NULL → draft đã nêu render (chưa có) — tốt.
Placeholder không tồn tại → draft cũng đã nêu render (chưa có) — tốt.
Nested JSONB → chưa nói rõ có hỗ trợ {a.b} hay chỉ {a}. Khuyến nghị vòng 1: cấm nested path, chỉ hỗ trợ key phẳng để giữ deterministic.
Special chars / dấu {} trong dữ liệu → nên dùng replace text thuần, không regex động trên giá trị để tránh escape bug.

Khuyến nghị viết cứng spec tối thiểu:

Chỉ hỗ trợ placeholder pattern [A-Za-z0-9_]+
Không hỗ trợ nested path ở v1
Key không có trong row_data hay computed context → (chưa có)
Giá trị text được chèn nguyên văn, không eval regex

Performance birth guard

Với lookup 1-2 key dot_config + render chuỗi ngắn, overhead cho INSERT đơn lẻ là chấp nhận được.
Nhưng cách draft hiện tại dùng 2 SELECT dot_config mỗi row. Nếu INSERT nhiều row, vẫn ổn ở quy mô governance hiện tại nhưng nên tối ưu bằng 1 helper function fn_get_desc_template(TG_TABLE_NAME, composition_level) hoặc cache theo transaction nếu sau này tăng scale.
Không thấy blocker lớn về performance ở quy mô hiện tại.

H11b phụ thuộc `PROV-DOT`

Đây là blocker kỹ thuật chính.

Đ24 có facet FAC-PROV + PROV-DOT, nhưng không có trong dự thảo câu nào định nghĩa trigger/DOT gán nhãn này một cách tất định.
Nếu label được gán AFTER INSERT ở entity_labels, còn H11b scan theo cron thì về lý thuyết eventually consistent vẫn được. Nhưng muốn NT14 pass, luật phải nêu rõ ai gán và khi nào.
Khuyến nghị: tạo 1 helper/trigger rõ tên, ví dụ fn_assign_description_provenance(entity_code, 'PROV-DOT'), gọi trong cùng transaction ngay sau khi set NEW.description hoặc ở AFTER INSERT trigger companion được Đ22 HC-TRIGGER kiểm tra coverage.

JOIN cross-table cho `collection_registry`

Đây là điểm yếu nhất về thực thi được ngay.

Template collection_registry dùng species_code từ species_collection_map và source_database từ meta_catalog là computed fields không có sẵn trong NEW.
Birth trigger có quyền JOIN, nên về mặt PG thì làm được.
Nhưng draft chưa chỉ ra function nào build “computed context”, join key là collection_name, và khi join miss thì trả gì.

Khuyến nghị cứng:

Tách thành 2 bước: row_data := to_jsonb(NEW) + context_data := fn_description_context_<table>(NEW) hoặc generic fn_description_context(TG_TABLE_NAME, to_jsonb(NEW)).
Với collection_registry: join species_collection_map.collection_name = NEW.collection_name lấy primary species; join meta_catalog theo code = NEW.code hoặc khóa chuẩn luật hiện hành xác nhận được. Nếu chưa có khóa chuẩn cho source_database, không nên dùng placeholder này ở vòng enact hiện tại.
Nếu không chốt được join key chuẩn, nên bỏ source_database khỏi template v1 để tránh vi phạm NT9/NT14.

5. Scale

500 entity types tương lai

Template per table vẫn scale ở mức khá nếu số bảng không bùng nổ quá lớn.
Nhưng dự thảo đã tự mở cửa đúng hướng: desc_template_<table>_<composition_level> override. Đây là nền cho scale tốt hơn theo Đ0-B.
Khuyến nghị kiến trúc dài hạn: fallback chain 3 tầng
1. desc_template_<table>_<composition_level>
2. desc_template_<table>
3. desc_template_level_<composition_level>
4. desc_template_default

Hiện draft mới có table+level → table → default. Thiếu level_default, nên scale 500 entity types vẫn hơi thô.

Template language

Đ3 hiện yêu cầu C4: tiếng Việt có dấu cho description chi tiết.
Với mô tả cơ bản auto-gen, nên viết cứng trong Đ3 hoặc phụ lục: mặc định tiếng Việt có dấu; cho phép giữ nguyên thuật ngữ kỹ thuật/enum/code tiếng Anh.
Nếu không, sau này có thể nảy sinh template nửa Anh nửa Việt thiếu chuẩn.

6. Kẽ hở và rủi ro

Ghi đè mô tả chi tiết lên mô tả cơ bản

Có rủi ro mất “baseline guarantee”. Khi AI/người ghi đè cùng cột description, hệ thống mất dấu mô tả tối thiểu ban đầu để audit/debug.
Khuyến nghị mạnh: thêm extra_metadata.description_basic hoặc description_basic_snapshot để giữ bản gốc. Không nhất thiết tạo cột mới toàn hệ thống; có thể chuẩn hóa nơi lưu trong JSONB nơi nào đã có extra_metadata.
Nếu chưa có nơi lưu chuẩn, nên ít nhất yêu cầu lưu vào admin_fallback_log/audit khi overwrite hàng loạt. Nhưng phương án JSONB tốt hơn.

Ai gán label PROV-DOT? Trigger nào? Timing?

Hiện draft mơ hồ: “qua Đ24 entity_labels sau INSERT, hoặc inline nếu entity_labels trigger có”. Đây là lỗ hổng thực thi.
Race condition có thật nếu logic báo cáo H11b đọc trước khi label được gán, hoặc label fail mà description vẫn có.
Cần một rule duy nhất: description auto-gen thành công => provenance gán trong cùng transaction bằng cơ chế X.

Entity cũ có description tạm rất ngắn

Draft chỉ nói NULL/rỗng mới auto-gen. Vậy các row có “abc”, “test”, “ngắn quá” sẽ không được cứu bởi auto-gen.
Đ3/Đ4 hiện có C2/C3 cho birth guard, nhưng retrofit/backfill cần rule riêng.
Khuyến nghị: backfill batch cho legacy nên coi NULL OR btrim='' OR length < threshold OR gaming regex là “candidate for basic regen”, trừ khi provenance là PROV-HUMAN và operator chọn preserve.

Drift giữa Đ43 §9.2.1 và Đ3 phụ lục

Dự thảo đã giảm drift bằng câu “Đ43 chỉ mapping operational”. Nhưng vẫn còn nếu Đ43 liệt kê bảng-format theo cách chi tiết quá.
Khuyến nghị: Đ43 §9.2.1 chỉ giữ source_table -> entity_type và viện dẫn format về Đ3/Đ35, không ghi lại text format chi tiết nữa.

7. Đề xuất sửa (patches)

P1 — Chốt SSOT template một dòng

Thêm vào Đ3 §2.6:

dot_config là runtime SSOT duy nhất cho template mô tả cơ bản. Phụ lục Đ3 chỉ là documentation mirror, không phải nguồn thực thi.

P2 — Chốt fallback chain đầy đủ

Viết cứng lookup order trong Đ4 hoặc phụ lục triển khai:

desc_template_<table>_<composition_level>
desc_template_<table>
desc_template_level_<composition_level>
desc_template_default
NULL → fail-safe, guard xử lý như hiện tại

P3 — Chốt contract `fn_render_description_template()`

Bổ sung spec:

chỉ placeholder phẳng [A-Za-z0-9_]+
không nested JSON path ở v1
key thiếu/NULL → (chưa có)
không eval regex theo giá trị

P4 — Tách computed context khỏi `NEW`

Bổ sung helper rõ ràng:

fn_description_context(p_table text, p_row jsonb) returns jsonb
direct columns lấy từ to_jsonb(NEW)
cross-table/computed placeholders lấy từ function này

P5 — Chốt provenance atomically

Bổ sung 1 rule duy nhất:

Auto-gen thành công trong birth flow → gán PROV-DOT trong cùng transaction bằng trigger/function companion chuẩn hóa.
H11b chỉ được dựa vào label này sau khi luật đã quy định cơ chế gán rõ tên.

P6 — Giữ bản mô tả cơ bản khi bị overwrite

Bổ sung rule lưu snapshot mô tả cơ bản vào extra_metadata.description_basic (nơi bảng có JSONB) hoặc cơ chế audit chuẩn tương đương. Không nên để baseline biến mất hoàn toàn.

P7 — Thu hẹp Đ43 §9.2.1

Rút bảng này về vai trò routing/mapping; bỏ mọi text format chi tiết có thể drift với Đ3/Đ35.

P8 — Rule legacy backfill rõ hơn

Ở lộ trình bước 5, thay “entity NULL description” bằng:

NULL/rỗng/ngắn dưới threshold/gaming → candidate regen mô tả cơ bản
mặc định không ghi đè PROV-HUMAN; PROV-AI cân nhắc theo config/flag campaign

8. Kết luận ngắn

Dự thảo đúng hướng và đáng tiếp tục. Nếu vá P1–P8, đặc biệt P4–P6, gói này có thể lên APPROVE FINAL ở vòng 2 vì sẽ đóng được lỗ NT14 một cách thực sự, không chỉ trên giấy.