Council Vòng 3 — GPT — Điều 39 v2.2

Tài liệu đã đọc

knowledge/dev/architecture/dieu39-knowledge-graph-law-draft.md (revision 5, FULL TEXT)
knowledge/dev/laws/constitution.md
knowledge/dev/architecture/dieu38-normative-document-law-draft.md
knowledge/dev/ssot/operating-rules.md

Kết luận ngắn

Điều 39 v2.2 không thấy xung đột hiến pháp nghiêm trọng và về hướng kiến trúc là đúng. Tuy nhiên, ở góc nhìn chiến lược dài hạn, có 8 điểm scale-risk, 6 cơ chế thông minh hóa nên ghi rõ, và 4 chỗ ranh giới liên luật cần siết câu chữ/guardrail để tránh drift khi triển khai lớn.

Phán quyết: BAN HÀNH, kèm 1 phụ lục TD chiến lược cho scale lớn.

CÂU 1 — RỦI RO KHI QUY MÔ LỚN LÊN

1. 36 DOT chạy cron trên 1 VPS khi entity >10M, edges >100M

Vấn đề: 10 quy trình dual-trigger + 36 DOT hiện hợp cho SME, nhưng khi data vượt ngưỡng lớn, cron kiểu full-scan sẽ chết vì I/O và lock contention, không phải vì CPU thuần. COMPLETENESS, TIMELINESS, ORPHAN, PROVENANCE-AUDIT, EVICT-SCAN là nhóm dễ phình nhất.

Mitigation:

Sửa ngay ở luật/TD: mọi DOT-KG phải mặc định hỗ trợ incremental mode (watermark theo updated_at, last_seen_id, last_snapshot_at), không được thiết kế full-scan là default.
Phase 2: partition/logical sharding cho universal_edges, kg_quality_log, kg_evolution_snapshots.
Phase 3: tách lịch chạy theo priority tiers: realtime / hourly / daily / weekly / monthly. Không để “cron daily quét tất”.

2. Trust Score trên 100M+ edges

Vấn đề: nếu trust được tính động trên từng query, graph traversal sẽ đắt. Nếu trust được recompute batch toàn bảng, nightly jobs sẽ nặng và dễ stale.

Mitigation:

Sửa ngay: tách trust thành 2 lớp: base_trust_score lưu sẵn trên edge, còn query_adjusted_trust chỉ tính cục bộ theo context.
Phase 2: materialized views / edge score snapshots theo source_type hoặc graph zone.
Phase 3: chỉ recompute edge bị ảnh hưởng bởi source/threshold thay đổi, không recompute toàn đồ thị.

3. Self-Learning weekly khi data mới hàng triệu row/ngày

Vấn đề: vòng I (SELF-SCORE → SELF-LEARN) nếu ăn toàn bộ outcomes sẽ vừa chậm vừa dễ noise. RLKGF trên SME stack rất dễ bị “learning from dirty feedback”.

Mitigation:

Sửa ngay: self-learning chỉ chạy trên curated feedback windows hoặc sampled gold-set, không ăn toàn bộ raw outcomes.
Giữ C9 nhưng ghi rõ: champion/challenger dùng sampled evaluation, không dùng toàn bộ traffic thô.
Phase 3: stratified sampling + decay theo recency + feedback quality tiers.

4. Scaffold Graph khi văn bản quy phạm >500

Vấn đề: nếu mỗi văn bản enacted đều rebuild scaffold diện rộng, chi phí invalidate/rebuild sẽ tăng mạnh. Dễ dẫn tới “graph khung đúng nhưng rebuild mãi”.

Mitigation:

Sửa ngay: scaffold phải hỗ trợ module-level rebuild, không rebuild toàn graph khi 1 văn bản đổi.
Phase 2: maintain scaffold_dependency_map từ Điều 38 → graph modules.
Phase 3: chỉ invalidate subgraph liên quan đến section/binding đổi.

5. Priority Graph cho 10.000 nhân viên × mỗi người 1 tree

Vấn đề: HTN 3-4 cấp là đúng, nhưng số lượng tree cá nhân sẽ phình rất nhanh. Nếu lưu full tree materialized cho từng người, storage + recompute sẽ rất đắt.

Mitigation:

Sửa ngay: tách priority_template và instantiated_priority_tree. Chỉ materialize khi có context cụ thể hoặc active cycle.
Phase 3: cache ngắn hạn + garbage collection tree cũ/inactive.
Giữ nguyên luật: Priority Graph là alignment engine, không phải lưu vĩnh viễn mọi decomposition.

6. Context Projection khi master graph quá lớn

Vấn đề: subgraph projection có thể vẫn nặng nếu filter chỉ dựa species/labels/hop distance. Khi graph lớn, hop distance 2-3 đã đủ bùng nổ.

Mitigation:

Sửa ngay: thêm nguyên tắc projection phải có budget: max nodes, max edges, max hops, max expansion time.
Phase 2: priority-based edge pruning theo trust + role + recency.
Phase 3: precomputed role-scoped subgraphs cho use case lặp lại.

7. Qdrant embedding sync khi entity tăng rất mạnh

Vấn đề: vector sidecar hiện đúng hướng, nhưng khi millions/day updates, sync PG→Qdrant sẽ thành bottleneck và eventual consistency gap tăng.

Mitigation:

Sửa ngay: mọi DOT-KG-SIMILARITY phải hỗ trợ queue/backpressure và trạng thái embedding_status per entity.
Phase 2: batch upsert by collection/domain, không upsert lẻ từng row.
Phase 3: selective embeddings cho entity types thật sự cần semantic retrieval, không vector hóa tất cả.

8. Log và snapshot phình nhanh

Vấn đề: kg_quality_log, kg_weight_snapshots, kg_evolution_snapshots, provenance JSONB sẽ lớn nhanh hơn cả graph core.

Mitigation:

Sửa ngay: luật nên ghi rõ retention tiers: hot / warm / archive.
Phase 1-2: partition theo tháng/quý, archive định kỳ.
Phase 3: aggregate snapshot thay vì raw snapshot vô hạn.

Kết luận Câu 1

Không thấy điểm “gãy chắc chắn” ở v2.2 nếu còn ở quy mô SME. Nhưng nếu nhìn tới 10M+ entities / 100M+ edges, 4 thứ phải được ghi TD chiến lược ngay bây giờ:

incremental-by-default
projection budget
module-level scaffold rebuild
retention + partition strategy

CÂU 2 — LÀM THẾ NÀO ĐỂ HỆ THỐNG THÔNG MINH LÊN THEO THỜI GIAN?

Ngoài C9 và C10, tôi đề xuất 6 cơ chế đã có tiền lệ ngành:

1. What-if / Counterfactual Simulation

Chuẩn tham chiếu: decision intelligence, causal inference, scenario planning.

Ý nghĩa: trước khi AI đề xuất hành động A, hệ thống mô phỏng “nếu A vs B” trên Priority/Context Graph.

Đề xuất:

Nên bổ sung vào Điều 39 phase sau. Hiện đã có TD what-if ở §13, tôi đồng ý giữ ở Phase 3, chưa cần nâng lên core law ngay.

2. Active Learning / Human Querying

Chuẩn tham chiếu: active learning, uncertainty sampling.

Ý nghĩa: khi edge/decision nằm ở vùng trust thấp nhưng impact cao, hệ thống chủ động hỏi người đúng câu hỏi tối thiểu để học nhanh hơn.

Đề xuất:

Nên bổ sung vào C10 hoặc quy trình J như một mode của Conversational Acquisition, không cần tạo bài toán riêng ngay.

3. Ontology Expansion Recommendation

Chuẩn tham chiếu: ontology learning, schema evolution.

Ý nghĩa: hệ thống tự đề xuất mở rộng ontology khi thấy các proposal lặp đi lặp lại cùng pattern.

Đề xuất:

Đã chạm ở C6, nhưng nên ghi rõ hơn ở full text: AI chỉ đề xuất ontology delta, không được tự merge.
Không cần bài toán mới, chỉ cần sharpen C6.

4. Cross-Domain Transfer Learning giữa các KG con

Chuẩn tham chiếu: transfer learning, multi-domain knowledge transfer.

Ý nghĩa: tri thức từ KG nhân sự, khách hàng, vận hành có thể chia sẻ pattern trừu tượng như “signal decay”, “anti-pattern”, “escalation”.

Đề xuất:

Nên để Phase 4, không đưa vào lõi v2.2. SME chưa cần sớm, nhưng nên ghi vào roadmap như blind spot tích cực.

5. Outcome-Calibrated Trust / Decision Calibration

Chuẩn tham chiếu: calibration learning, confidence calibration.

Ý nghĩa: không chỉ học weights, mà học xem trust_score có phản ánh đúng outcome không. Ví dụ trust 0.9 mà outcome fail liên tục thì phải hiệu chỉnh hệ thống chấm điểm.

Đề xuất:

Nên bổ sung vào C9 hoặc quy trình I ngay ở mức câu chữ, vì đây là cách để hệ thống “thông minh hơn” chứ không chỉ “nhiều tri thức hơn”.

6. Negative Knowledge Consolidation

Chuẩn tham chiếu: anti-pattern mining, failure memory, exception mining.

Ý nghĩa: hệ thống dần giỏi hơn nhờ nhớ những cái KHÔNG nên làm, chứ không chỉ nhớ pattern thành công.

Đề xuất:

Đã có C13, đây là điểm rất mạnh của v2.2. Nên giữ và ưu tiên sớm hơn visualization đẹp.

Kết luận Câu 2

Điều 39 v2.2 đã có nền tảng tốt để “thông minh lên theo thời gian”. Tôi chỉ khuyên bổ sung rõ hơn 2 cơ chế trong full text/TD gần:

Active learning trong C10
Outcome calibration trong C9

CÂU 3 — RÀ SOÁT XUNG ĐỘT VỚI HIẾN PHÁP VÀ CÁC ĐIỀU KHÁC

Tổng quan

Không phát hiện xung đột hiến pháp trực diện. Điều 39 v2.2 nhìn chung tuân thủ đúng NT1-NT11 và bám khá sát các Điều 34, 35, 36, 37, 38.

Nhưng có 4 chỗ cần siết ranh giới để tránh drift sau này.

3.1 Với Đ34 (Workflow)

Rà soát: Điều 39 đã viết rõ Priority Graph ≠ workflow engine, đây là đúng.

Nguy cơ còn lại: Goal→Sub-goals→Actions rất dễ bị đội triển khai kéo sang orchestration thật.

Đề xuất:

Sửa nhẹ trong Điều 39 hoặc Đ34: thêm 1 câu cứng: Priority Graph chỉ sinh đề xuất thứ tự ưu tiên và decomposition, không sinh state transitions hay execution routing. Execution routing thuộc Đ34.

3.2 Với Đ35 (DOT Governance)

Rà soát: 36 DOT-KG mới về nguyên tắc phù hợp. Nhưng số lượng DOT tăng mạnh → nguy cơ drift về naming/domain/ownership.

Nguy cơ: nếu không có taxonomy domain rõ cho KG DOT, Điều 35 sẽ thành nơi “đăng ký cho đủ”, không quản trị thật.

Đề xuất:

Ghi TD hoặc sửa ngay ở rollout plan: toàn bộ DOT-KG phải có domain family riêng, naming convention và ownership map trong Điều 35 / dot_domains.
Không phải xung đột, mà là phụ thuộc governance phải được làm thật.

3.3 Với Đ36 (Collection Protocol)

Rà soát: 9+ config tables mới (kg_signal_config, kg_thresholds, kg_constraint_config, kg_acl_config, kg_auto_approve_rules, kg_source_authority, kg_priority_templates, kg_weight_snapshots, kg_model_versions) về bản chất phù hợp config-driven.

Nguy cơ: vài bảng là “settings singleton”, vài bảng là “append-only logs”, vài bảng là “templates”. Nếu không phân loại đúng theo Đ36/Đ29, sau này governance_role và protocol có thể lệch.

Đề xuất:

Không cần sửa Điều 39, nhưng triển khai phải bắt buộc đi qua Đ36 đầy đủ cho từng bảng, nhất là singleton vs append-only vs governed/observed.

3.4 Với Đ37 (Tổ chức)

Rà soát: Điều 39 phụ thuộc Đ37 là hợp lý, nhưng trong full text tôi chưa thấy nêu rõ cơ quan chủ quản KG là ai trong governance_registry.

Nguy cơ: có luật KG nhưng cơ quan thực thi/owner mơ hồ → quay lại lỗi “luật có nhưng không ai chịu trách nhiệm”.

Đề xuất:

Sửa ngay hoặc rollout note: đăng ký 1 cơ quan KG rõ trong Đ37, ví dụ Knowledge Graph System / KG Governance Agency, cùng quan hệ với Điều 35/38/31.

3.5 Với Đ38 (Văn bản quy phạm)

Rà soát: Scaffold Graph đọc từ Đ38 là đúng hướng và là một trong những điểm mạnh nhất của v2.2.

Nguy cơ: nếu binding của Đ38 chưa đủ structured hoặc raw-text migration còn dang dở, scaffold sẽ mang chất lượng không đồng đều.

Đề xuất:

Không sửa Điều 39 lõi, nhưng phải ghi rõ: chất lượng Scaffold Graph phụ thuộc mức chuẩn hóa sections/binding trong Đ38. Luật đúng, nhưng rollout phải lấy văn bản chuẩn hóa làm ưu tiên đầu.

3.6 Với Đ32 (Phê duyệt)

Rà soát: Bottom-up proposals qua APR là đúng.

Nguy cơ: proposal volume lớn từ C6/C10/C13 có thể làm APR thành nghẽn cổ chai.

Đề xuất:

TD Phase sau: thêm proposal triage / dedupe / priority scoring trước khi vào APR chính thức.
Không xung đột, nhưng sẽ thành vấn đề vận hành khi scale.

3.7 Với NT1 (SSOT)

Rà soát: Điều 39 cố giữ Species = ontology, universal_edges = relations, không tạo ontology bảng trùng. Đây là đúng.

Nguy cơ duy nhất: 9+ config tables + quality logs + projections có thể bị lạm dụng thành “SSOT phụ” nếu nhóm triển khai bắt đầu encode ontology/rules rải rác ở nhiều bảng.

Đề xuất:

Sửa câu chữ nhẹ: ontology chuẩn chỉ có trong species/relation types/scaffold đã duyệt; config tables chỉ điều khiển behavior, không được sinh ontology song song.

3.8 Với NT11 (Khai tối thiểu)

Rà soát: Điều 39 khá ý thức NT11. Tuy nhiên 9+ config tables mới là chỗ dễ trượt.

Nguy cơ: tạo quá nhiều config table “để sau này dùng” mà chưa chứng minh cần thiết.

Đề xuất:

Hiện tại chưa thấy bảng nào thừa rõ rệt, nhưng 2 bảng kg_weight_snapshots và kg_model_versions chỉ nên tạo khi C9 triển khai thật, không nhất thiết bootstrap ngày đầu.
Đây là điểm rollout, không phải lỗi luật.

KẾT LUẬN CUỐI

1. Rủi ro scale lớn nhất

full-scan DOT
trust recompute toàn đồ thị
self-learning học từ dữ liệu bẩn
scaffold rebuild diện rộng
projection không có budget
log/snapshot phình nhanh

2. Cơ chế thông minh hóa nên ghi rõ thêm

active learning
outcome calibration
what-if simulation (đã có TD, giữ phase sau)

3. Xung đột hiến pháp / liên luật

Không phát hiện xung đột nghiêm trọng. Nhưng nên siết 4 ranh giới:

Priority ≠ orchestration (Đ34)
DOT-KG family phải được quản trị chặt trong Đ35
KG agency phải được đăng ký rõ trong Đ37
ontology chuẩn không được trôi sang config tables (NT1/NT11)

Phán quyết

BAN HÀNH.

Nhưng tôi đề nghị đính kèm 1 phụ lục hoặc TD chiến lược sau ban hành gồm 6 mục:

incremental processing default
projection budgets
scaffold module rebuild
trust materialization strategy
retention/partition strategy
active-learning + outcome-calibration roadmap