Council Review — GPT — Vòng 2 CONFIRM: Entity Enrichment Master v2

• Ngày: 2026-04-23
• Reviewer: Incomex Hội đồng AI (GPT)
• File review thực tế: knowledge/current-state/reports/du-thao-entity-enrichment-master-fix30.md
• Lưu ý phiên bản: user nêu revision 2, nhưng Agent Data hiện trả về revision 3. Review này bám theo bản hiện đang lưu trong Agent Data (source of truth).

---

ĐIỂM: 8.9/10 VERDICT: APPROVE FINAL

XÁC NHẬN TỔNG QUAN

Bản v2/v3 hiện tại đã áp đúng phần lớn tinh thần phản biện vòng 1. 9 patch trọng yếu đều đã được đưa vào đúng chỗ kiến trúc: schema, trigger, sync scope, health checks, clarification phạm vi, và chỉ số triển khai. Không thấy patch nào bị “méo ý” theo hướng làm yếu governance; ngược lại, bản mới chặt hơn đáng kể ở NT1/NT9/NT12/NT14.

Điểm còn cần ghi chú chỉ là 2 lưu ý hậu phê duyệt, chưa đến mức blocker:

1. source_table đang mô tả CHECK subquery rồi ghi chú “PG không hỗ trợ → triển khai bằng trigger”. Cần enact thật bằng trigger, không để đội triển khai copy nguyên CHECK spec rồi lỗi syntax.
2. Fail-safe seed bằng EXCEPTION WHEN OTHERS chấp nhận được cho birth path, nhưng phải đi kèm guard vận hành để không biến lỗi hàng loạt thành trạng thái “có WARNING nhưng bị bỏ quên”.

---

1. PATCHES ÁP ĐÚNG Ý VÒNG 1 CHƯA? CÓ BỊ MÉO KHÔNG?

P1 — Trigger field-level diff

Xác nhận: Áp đúng ý và là patch quan trọng nhất. Bản mới chỉ reset approved khi đổi 4 field nghiệp vụ: description, jurisdiction, enrichment_notes, provenance. Điều này đóng đúng bug vòng 1: DOT cập nhật synced_at không còn làm approved rơi về no nữa.

Không bị méo. Đây là bản sửa chuẩn nhất so với vòng 1.

P2 — +created_at, +approved_at, +approved_by

Xác nhận: Áp đúng ý. Audit duyệt đã từ mức “có state nhưng thiếu dấu vết” nâng lên mức có thể truy vết tối thiểu. Chưa nối Đ32 ngay nhưng defer sang phase 2 là hợp lý.

P3 — Snapshot readonly cho composition_level + governance_role

Xác nhận: Áp gần đúng hoàn toàn. Bản v2 đã ghi rõ đây là SNAPSHOT cache, SSOT nằm ở bảng gốc, và agent không được update trực tiếp. Đây là đúng tinh thần NT1.

Điểm lưu ý nhỏ: hiện mới thể hiện bằng văn bản/spec + CHECK enum; chưa thấy trigger/permission cụ thể để chặn update trực tiếp. Nhưng vì đây là draft kiến trúc chứ chưa phải migration chi tiết, mức này đủ để approve final.

P4 — source_table verify trigger

Xác nhận: Áp đúng ý, không méo. Bản draft đã tự nhận ra CHECK subquery chỉ là spec và triển khai thật phải dùng trigger fn_verify_source_table(). Đây là cách xử lý honest và đúng NT14 hơn việc giả vờ CHECK chạy được.

P5 — DOT sync whitelist

Xác nhận: Áp rất đúng ý. Bản mới ghi cực rõ: DOT chỉ được sync description + provenance label, có diff guard, chỉ set synced_at sau khi write thành công, cấm mở rộng scope ngầm. Patch này đóng đúng lo ngại vòng 1 về boundary ownership.

P6 — 3 check-code Đ22 riêng

Xác nhận: Áp đúng ý. Tách HC-ENRICH-SEED, HC-ENRICH-DRIFT, HC-ENRICH-STALE là tốt hơn 1 check gộp; khớp tinh thần Đ22 §1.1 về matching key rõ ràng và auto-close/reopen chính xác hơn.

P7 — Scope clarification

Xác nhận: Áp đúng ý. Câu chữ mới đã giải mâu thuẫn vòng 1: mọi entity có row master để quản trị tối thiểu, nhưng enrichment AI chỉ áp cho thực thể kiến trúc theo Đ3 §2.5.

P8 — 4 index cụ thể

Xác nhận: Áp đúng tinh thần NT14. Thậm chí bản draft đang có 5 index, tức là còn rõ hơn yêu cầu tối thiểu. Đây là cải thiện thực thi thật, không phải vá câu chữ.

P9 — Fail-safe birth EXCEPTION WHEN OTHERS

Xác nhận: Áp đúng hướng Gemini patch, nhưng là điểm cần soi kỹ nhất. Nó giải quyết mâu thuẫn giữa “entity birth không được chết theo companion path” và “master seed nên có 100% coverage”. Tôi đánh giá patch này chấp nhận được, nhưng phải được khóa bởi H11/Đ22 scan mạnh và escalation rõ.

Kết luận mục 1: 9 patch áp đúng, không thấy patch nào bị méo thành hình thức. Patch mạnh nhất là P1, P5, P6. Patch nhạy cảm nhất là P9 nhưng vẫn trong vùng chấp nhận được.

---

2. FIELD-LEVEL TRIGGER (★ P1) — LOGIC IS DISTINCT FROM ĐÚNG CHƯA? EDGE CASE NÀO BỎ SÓT?

Đánh giá

Dùng IS DISTINCT FROM là đúng kỹ thuật PostgreSQL cho bài toán này, vì nó xử lý được cả NULL khác/giống một cách tường minh. So với !=, đây là lựa chọn đúng hơn hẳn.

Các case đã xử lý đúng

• NULL → 'abc' ở description/jurisdiction/notes → reset approved: đúng
• 'abc' → NULL → reset approved: đúng
• 'abc' → 'abc' → không reset: đúng
• update synced_at đơn thuần → không reset: đúng
• update approved='yes', set approved_at/by → không reset: đúng

Edge cases còn lại

E1 — whitespace-only change Hiện trigger so trực tiếp raw value. Nếu description đổi từ "ABC" thành "ABC " thì vẫn reset approved. Về governance, tôi thấy chấp nhận được: đã đổi nội dung lưu trữ thì review lại không sai. Không cần thêm btrim() vào trigger vì có thể tạo side-effect khó đoán giữa stored value và review semantics.

E2 — snapshot fields đổi do trigger nội bộ Bản draft cố ý không reset khi species_code, composition_level, governance_role, name, name_en đổi. Tôi đồng ý với quyết định này vì đó là snapshot/cache từ bảng gốc, không phải nội dung enrichment do reviewer phê duyệt. Nếu reset approved vì các field này đổi thì sẽ gây review churn giả.

E3 — đổi provenance có nên reset không? Hiện có reset. Tôi đồng ý vì PROV-AI ↔ PROV-HUMAN là thay đổi nghĩa quản trị, không chỉ metadata phụ. Cho review lại là đúng.

E4 — thao tác approve đồng thời với nội dung đổi trong cùng UPDATE Nếu có 1 câu UPDATE vừa đổi description vừa set approved='yes', trigger sẽ reset về no. Tôi xem đây là đúng fail-safe, không phải bug. Approval phải là bước sau khi nội dung đã ổn định.

Kết luận mục 2

Logic hiện tại đúng, IS DISTINCT FROM dùng chuẩn, không thấy edge case nào còn đủ nặng để chặn triển khai.

---

3. FAIL-SAFE EXCEPTION (★ Gemini P3) — CÓ RỦI RO NUỐT LỖI QUAN TRỌNG KHÔNG?

Đánh giá

Có rủi ro, nhưng đã được đặt đúng chỗ để chấp nhận.

Vì sao patch này hợp lý

Nếu companion trigger seed master làm fail toàn bộ birth transaction, hệ thống sẽ vi phạm ưu tiên lớn hơn: sinh entity chính thức bị chết theo một đường phụ. Với triết lý hiện tại của Đ4 companion trigger, cho entity sinh trước rồi để Đ22/H11 phát hiện “thiếu master row” là hợp lý hơn.

Rủi ro thật sự

EXCEPTION WHEN OTHERS có thể gom mọi lỗi vào 1 WARNING chung:

• bug schema mới,
• FK sai,
• permission lỗi,
• deadlock/timeout,
• code typo.

Nếu chỉ WARNING mà không có metric/escalation, hệ thống có thể âm thầm đẻ ra nhiều entity thiếu master row trước khi ai nhìn thấy.

Tại sao tôi vẫn approve

Vì bản v2 đã gắn cơ chế bù:

• HC-ENRICH-SEED = CRITICAL khi entity có mà master thiếu row
• Hệ thống Đ22 có pattern issue lifecycle + auto-detect
• Draft đã nêu rõ đây là fail-safe có chủ đích, không phải nuốt lỗi để bỏ qua

Điều kiện vận hành bắt buộc sau enact

Tôi khuyến nghị ghi thêm trong triển khai chi tiết:

1. WARNING seed fail phải có marker source cố định để grep/count được.
2. HC-ENRICH-SEED nên chạy sớm sau deploy/backfill, không phải chu kỳ quá dài.
3. Nếu số lượng seed fail vượt ngưỡng nhỏ trong 1 chu kỳ, nên escalate CRITICAL batch-level.

Kết luận mục 3

Có rủi ro nuốt lỗi ở tầng log local, nhưng không còn là blocker kiến trúc vì đã có Đ22 scan bù. Chấp nhận được.

---

4. 3 CHECK-CODE MỚI (★ P6) — THRESHOLD 1H/7 NGÀY HỢP LÝ?

Đánh giá từng ngưỡng

HC-ENRICH-SEED

Không cần threshold dài; đây là CRITICAL ngay khi phát hiện. Đúng.

HC-ENRICH-DRIFT / sync trễ

User nêu mốc 1h; draft hiện chỉ ghi “approved='yes' nhưng synced_at < updated_at” là WARNING, chưa thấy chốt rõ số giờ trong nội dung file. Với debounce 5 phút, 1 giờ là hợp lý cho single VPS: đủ rộng để tránh false positive do burst/cycle delay, đủ ngắn để bắt sync kẹt thật.

Tôi ủng hộ 1h làm threshold enact chính thức, vì:

• 5 phút là debounce kỹ thuật,
• 1h là vận hành bất thường rõ ràng,
• 24h heartbeat là verify ceiling, không phải SLA sync bình thường.

HC-ENRICH-STALE

approved='no' > 7 ngày = WARNING là hợp lý cho backlog review. Dưới 7 ngày thường vẫn là công việc đang làm; trên 7 ngày mới phản ánh bị bỏ quên.

Kết luận mục 4

• 1h cho DRIFT: hợp lý, nên ghi thẳng vào draft/enact text để đạt NT14.
• 7 ngày cho STALE: hợp lý.
• Không thấy ngưỡng nào quá gắt hay quá lỏng.

---

5. CÒN BLOCKER NÀO CHẶN TRIỂN KHAI KHÔNG?

Kết luận

Không còn blocker cấp Council chặn triển khai.

Những gì đã đủ để qua gate

• SSOT metadata enrichment rõ ràng, không còn update thẳng entity
• approved gate đã sửa đúng bug lớn nhất
• sync scope rõ, không lấn ranh entity owner
• health-check tách check-code hợp lý
• scope enrichment vs scope row-master đã làm rõ, không còn xung đột với Đ3 §2.5
• chỉ số phase 1 đủ cụ thể để agent triển khai không cần hỏi lại

Những gì chỉ còn là “ghi chú triển khai”, chưa phải blocker

1. Chốt rõ trong migration thật: source_table verify bằng trigger, không copy CHECK subquery giả.
2. Ghi explicit threshold HC-ENRICH-DRIFT = 1 hour vào luật/draft, vì hiện file chưa đóng con số này dù user prompt đã nêu.
3. Với snapshot readonly fields, phase migration nên có guard thực tế (trigger/permission) để cấm agent update trực tiếp.

Ba điểm này là minor enact notes, không cần vòng 3.

---

NHẬN XÉT TỔNG THỂ

Bản v2 hiện tại đã chuyển từ “ý tưởng đúng nhưng cơ chế còn hở” sang “thiết kế đủ chặt để ban hành và triển khai pilot”. Patch vòng 1 đã được hấp thụ đúng tinh thần, đặc biệt là P1 field-level diff, P5 sync whitelist, P6 check-code tách riêng, và P7 clarification scope. Điểm nhạy cảm nhất là fail-safe birth, nhưng do đã có Đ22 scan bù và severity đúng, nó không còn là lý do để giữ lại.

Tôi chấm 8.9/10 và APPROVE FINAL.