NGHỊ ĐỊNH 36-01 — XÂY DỰNG BẢN QUAN HỆ NGỮ NGHĨA

(Semantic Relationship Infrastructure Decree — DRAFT)

v1.2 DRAFT | S170 (2026-04-06) | PHẦN 1: THÔNG QUA Council Vòng 2: Gemini 9.3/10 + GPT 9.2/10 → THÔNG QUA — vá 5 điểm nhỏ + OR compliance Council Vòng 1: Gemini 8.5/10 + GPT 8.7/10 → Bổ sung MT8+MT9, hiệu chỉnh MT3+MT4+MT6 Desktop review S170: 13 NT ✅ (NT-06 Assembly path bổ sung) | 6 CQ ✅ | §XII ✅ Thuộc: Điều 36 — Luật Collection v5.0 (GP5, MT5) Phục vụ: Đ38 (SQL hoá văn bản) → Đ39 (Knowledge Graph) Tuân thủ: OR v7.54, Mục XII Công thức soạn luật

PHẦN 1 — MỤC TIÊU

Vấn đề thực tế

Hệ thống Incomex quản lý hàng ngàn thực thể đã khai sinh (Birth Registry, Đ0-G), mỗi thực thể có mã, có tên chuẩn. Tuy nhiên:

Con người không nhớ chính xác. Khi viết văn bản, chat, hay nhập liệu — người dùng viết "NV thử việc", "lương CB", "Xn", "NĐ"... thay vì dùng đúng tên chuẩn trong hệ thống. Hệ thống hiện tại không nhận ra đây là cùng một thứ.
Agent tạo trùng mà không biết. Khi xử lý dữ liệu mới, Agent không có cách tra cứu nhanh xem khái niệm đã tồn tại hay chưa → tạo mới → trùng lắp tích tụ. Birth Registry chặn trùng tên chính xác, nhưng "Doanh thu" và "Revenue" vẫn lọt qua vì tên khác nhau.
Quan hệ ngữ nghĩa không được ghi nhận. "Doanh thu" bao hàm "Doanh thu thuần", "Hoàn thành" đồng nghĩa "Done" — những quan hệ này tồn tại trong đầu người dùng, chưa ai ghi vào PG. Không có bản ghi → Đ38 không binding được → Đ39 không xây Graph được.
Đ38 bị chặn. Muốn SQL hoá văn bản, mỗi đoạn văn bản phải mapping về đúng thực thể PG. Không có hạ tầng nhận diện + mapping → Đ38 chỉ trên giấy. Không có Đ38 → Đ39 phải xây Graph từ text thô → chậm, sai, tốn token.
Ngôn ngữ viết lại đa ngữ (Code-Switching). Trong thực tế doanh nghiệp Việt Nam, người dùng viết pha trộn: "update cái report cho anh", "check lại DB đi", "KH confirm đơn hàng rồi". Mở rộng: doanh nghiệp có đối tác Nhật viết "工場 production line", "製品 spec を confirm". Hệ thống Entity Linking truyền thống (đơn ngữ) KHÔNG nhận diện được — "update" ≠ "cập nhật" trong mắt fuzzy matching tiếng Việt, "confirm" ≠ "xác nhận" trong mắt pg_trgm. Nếu không giải quyết → alias dictionary bị phân mảnh theo ngôn ngữ → Knowledge Graph có nodes trùng lặp xuyên ngôn ngữ mà không biết.

Kỹ thuật chuẩn ngành: Code-Switching NLP (phát hiện + xử lý text đa ngữ trong cùng câu), Cross-Lingual Embeddings (XLM-RoBERTa — embedding đa ngữ trong cùng không gian vector, "Revenue" và "Doanh thu" gần nhau dù khác ngôn ngữ), Multilingual Entity Linking (link entities xuyên ngôn ngữ về cùng canonical), Language Detection per-token (không phải per-document — mỗi từ trong câu có thể khác ngôn ngữ).

Ảnh hưởng: MT1 (linking phải nhận diện xuyên ngôn ngữ), MT3 (pipeline cần bước detect language per-token trước normalize), MT5 (bootstrap alias phải sinh cả tên Việt + Anh + viết tắt), MT8 (merge governance phải biết "Revenue" = "Doanh thu" = "DT"), Đ39 (Knowledge Graph nodes phải language-agnostic).

Giải pháp nền tảng: Qdrant embedding (XLM-R hoặc multilingual-e5) đã xử lý xuyên ngôn ngữ ở tầng semantic. PG pg_trgm xử lý ở tầng ký tự (fuzzy). Kết hợp: tầng PG bắt viết tắt + lỗi đánh máy, tầng Qdrant bắt xuyên ngôn ngữ. Pipeline (MT3) tầng 2+3 song song = bao phủ cả hai.

MT1 — Nhận diện khái niệm từ ngôn ngữ tự nhiên về đúng thực thể trong hệ thống

Khi gặp bất kỳ khái niệm nào từ văn bản, chat, hoặc dữ liệu nhập — hệ thống phải trả lời được: đây là cái gì?

Đã có trong hệ thống → trỏ về đúng thực thể đã khai sinh
Tên khác nhưng cùng một thứ → aliases nhận diện, trỏ về đúng chỗ
Viết tắt mơ hồ ("NĐ" = nghị định hay nghiệp đoàn?) → đánh dấu, hỏi đúng người viết
Hoàn toàn mới → khai sinh trước, rồi mới dùng

Kỹ thuật chuẩn ngành: Entity Linking + Canonicalization (NLP) — bài toán đã giải, không phát minh mới. Canonicalization = chọn 1 tên chuẩn (canonical name) cho mỗi khái niệm, mọi tên khác trỏ về đó. PG pg_trgm (fuzzy matching) + fuzzystrmatch / levenshtein (đếm lỗi đánh máy) + unaccent (bỏ dấu) + Full Text Search + ltree (phân cấp khái niệm) + Qdrant (embedding ngữ nghĩa).

Phục vụ Đ38: Đây là bước tiên quyết để Agent chia thẻ văn bản và tự binding vào PG.

MT2 — Ghi nhận quan hệ ngữ nghĩa giữa các thực thể

Bổ sung lớp quan hệ mà PG hiện không biết:

Đồng nghĩa: "Hoàn thành" = "Done" = "Completed"
Bao hàm: "Doanh thu" bao hàm "Doanh thu thuần"
Mâu thuẫn: "Miễn phí" mâu thuẫn "Có phí"
Viết tắt/tên khác: "NV" = "Nhân viên", "KH" = "Khách hàng"

PG đã có quan hệ cứng (FK, trigger, dependency) qua universal_edges. NĐ này bổ sung quan hệ mềm — thứ chỉ con người biết nhưng chưa ai ghi lại.

Hiệu lực thời gian (Council Vòng 2): Mỗi alias và relation có effective_from, effective_to (nullable = vĩnh viễn), revision (version counter). Alias/relation hết hiệu lực không bị XOÁ — chuyển effective_to = ngày kết thúc, giữ lại cho audit trail và temporal reasoning (Đ39). Revision mới thay thế revision cũ trong pipeline nhưng cả hai đều tồn tại trong PG.

Phục vụ Đ39: entity_relations (quan hệ mềm, tĩnh) là 1 trong 2 nguồn dữ liệu cho Knowledge Graph. Nguồn còn lại là Đ38 output (quan hệ động từ văn bản).

MT3 — Pipeline xử lý đầu vào cho Đ38 và Đ39

Xây dựng pipeline chuẩn hoá dữ liệu đầu vào, từ hỗn độn thành trật tự, trước khi Đ38 chia thẻ và Đ39 xây Graph:

5 bước chuẩn ngành (NLP pipeline — phân nhánh theo confidence):

Normalize + Blocking — chuẩn hoá chuỗi (bỏ dấu, viết thường, mở viết tắt từ abbreviation_dict) + thu hẹp candidate set theo domain/scope. PG native (unaccent, citext, generated columns). Bước rẻ nhất, chạy trước mọi thứ.
NER (Named Entity Recognition) — AI nhận diện thực thể trong văn bản: đâu là người, quy trình, chính sách, con số... Langroid agent thực hiện.
Entity Linking — mapping thực thể vừa nhận diện → tra Birth Registry + aliases → binding vào đúng chỗ PG.
Relation Extraction — AI phát hiện mối quan hệ giữa các thực thể trong cùng ngữ cảnh: "nhân viên thử việc hưởng 85% lương cơ bản" → 3 thực thể + 1 quan hệ có binding.

Bổ sung: Coreference Resolution — AI nhận ra "anh ấy" = "giám đốc" ở câu trước, "NV" = "nhân viên".

Phân tầng xử lý — phân nhánh theo confidence, không tuyến tính:

Tầng	Ai làm	Khi nào	Chi phí
0. Normalize + Blocking	PG (`unaccent`, `citext`, generated columns)	Mọi INSERT, trước mọi thứ	Free
1. Trùng chính xác + alias exact	PG (UNIQUE, constraint, lookup)	Realtime	Free
2. Gần đúng (trigram + levenshtein + FTS)	PG (`pg_trgm` + `fuzzystrmatch` + `ts_rank_cd`)	Realtime, index	Free
3. Ngữ nghĩa (embedding similarity)	Qdrant	Song song với tầng 2 — cả hai trả scored candidates	Thấp
4. Rerank + Disambiguate + Relation Extraction	Langroid agent	Chỉ khi tầng 1-3 chưa chắc chắn	Có token

Council feedback: Tầng 2 (PG fuzzy) và tầng 3 (Qdrant) chạy song song — cả hai trả danh sách ứng viên có điểm → tầng 4 (Agent) rerank/decide nếu cần. Trigram có thể bỏ sót cái embedding tìm thấy và ngược lại.

Kho càng chín → tầng 0+1 xử lý hết → tầng 2-4 gần như không phải làm gì.

MT4 — Phân loại mức tin cậy, provenance, và 3 vùng dữ liệu

3 vùng dữ liệu bắt buộc (NT-09: không chắc = sai):

Approved — đã duyệt, chính thức, DOT và Agent được dùng làm cơ sở
Candidate — mới phát hiện hoặc chưa đủ tin cậy, chờ duyệt hoặc tự cải thiện
Quarantine — nghi sai, mâu thuẫn, hoặc bị flag → cách ly khỏi pipeline chính

Không tách 3 vùng = trộn tri thức chuẩn với tri thức nghi ngờ → hệ thống mất tin cậy.

Tách 2 loại điểm (không gộp):

match_score: Điểm kỹ thuật (trigram 0.85, levenshtein 2, embedding cosine 0.92) — máy tính toán
approval_state: Trạng thái quản trị (approved / candidate / quarantine) — người hoặc quy trình quyết định

Điểm kỹ thuật cao không tự động = approved. Ngưỡng chuyển vùng = PG config table, không hardcode.

3 mức tin cậy cho Entity Linking:

Chắc chắn — PG match chính xác hoặc alias đã approved → auto binding → vào vùng approved
Mơ hồ — nhiều ứng viên, hoặc viết tắt đa nghĩa → vào vùng candidate → pending_review
Cần hỏi lại — không tìm thấy, hoặc hoàn toàn mới → truy vết nguồn → hỏi đúng người → escalate nếu cần

Provenance per annotation (phục vụ Đ39 A8):

Mỗi kết quả Entity Linking phải ghi đầy đủ:

extraction_method: exact match / trigram / levenshtein / embedding / AI NER
match_score: điểm kỹ thuật (số)
confidence: mức tin cậy sau calibration (số, đã hiệu chuẩn — xem MT9)
resolved_by: DOT (auto) / Agent (AI) / người duyệt (human)
timestamp: thời điểm nhận diện
source_context: từ VB nào, đoạn nào, câu nào

Lưu trữ: JSONB canonical runtime (tối ưu truy vấn) + cột nóng tách riêng để index (doc_id, entity_id, confidence, status). Mapping ra W3C Web Annotation + PROV-O ở lớp export khi cần liên thông.

Retention & Archive policy (Council Vòng 2): Candidate không được duyệt sau N ngày → auto-archive (không xoá). Quarantine items → review hoặc archive sau M ngày. Annotation log + disambiguation_log → partition theo thời gian (MT PG#16), retention tier: hot (30 ngày) → warm (1 năm) → cold (archive). Ngưỡng N, M = PG config table.

Không bao giờ đoán. Không chắc = candidate. Mâu thuẫn = quarantine.

MT5 — Bootstrapping: khởi tạo bộ nhận diện từ PG schema hiện có

Không bắt đầu từ bộ từ điển rỗng. Hệ thống đã có 33 species, hàng trăm bảng, FK, triggers, status values — đây chính là ontology sẵn có. Nghiên cứu mới nhất (2025) chứng minh: Knowledge Graph xây từ database schema có chất lượng tương đương xây từ text, mà rẻ hơn nhiều lần.

Agent quét PG metadata (tên bảng, tên cột, FK, species, status values, workflow steps, trigger conditions...) → tự sinh batch khái niệm + aliases + quan hệ đầu tiên → toàn bộ batch = status: draft → người duyệt batch → approved mới chính thức. Không auto-approve batch bootstrap (NT-09: không chắc = sai).

Điều kiện tiên quyết — Species semantic_concept: Thêm species mới = thay đổi ontology (TBox) = phải qua quy trình: Đề xuất → APR (Đ32) → Council duyệt (Đ37) → khai sinh (Đ0-G). Nguyên tắc vàng Đ39: "AI được đề xuất, không được tự ban hành tri thức chuẩn."

Pháp trị semantic_concept (Council Vòng 2): Species semantic_concept là ngoại lệ hẹp, CẤM dùng làm bãi chứa "chưa biết để đâu". Chỉ tạo semantic_concept khi: (a) chưa có entity chuẩn phù hợp trong Birth Registry, VÀ (b) khái niệm đó thực sự cần tồn tại độc lập. Nếu đã có entity chuẩn → alias/relation PHẢI trỏ về entity đó, không được tạo concept mới. Mỗi semantic_concept phải qua APR + Council + Birth — không có ngoại lệ.

Kỹ thuật chuẩn ngành: Ontology Learning from Relational Databases — đã chứng minh, có tool sẵn.

Lợi ích: Agent bắt đầu Entity Linking ngay lập tức thay vì chờ khai tay từng khái niệm. Bootstrap 1 lần, sau đó chỉ bổ sung dần.

MT6 — Active Learning: hệ thống tự cải thiện có đo lường

Mỗi lần người duyệt giải quyết mơ hồ (ví dụ: "NĐ" trong ngữ cảnh pháp lý = "Nghị định"), hệ thống ghi nhận: ngữ cảnh nào → kết quả nào. Lần sau gặp "NĐ" trong ngữ cảnh tương tự → tự chọn đúng, không hỏi lại.

Hệ Active Learning hoàn chỉnh (không chỉ log):

disambiguation_log: Ghi quyết định duyệt + Top 3 candidates + lý do chọn (phục vụ RLHF MT7)
Review queue: Case mơ hồ xếp ưu tiên — case ảnh hưởng nhiều VB ưu tiên cao hơn case hiếm gặp
Hard negatives: Học từ case dễ nhầm nhất, không chỉ case đúng
Domain-aware: Cùng alias nhưng domain khác = nghĩa khác. Hệ thống học theo domain
Decay / Revalidation: Quyết định cũ cần kiểm tra lại nếu ngữ cảnh thay đổi
Gold set: Tập mẫu chuẩn → benchmark định kỳ → đo hệ thống có thực sự học không (liên kết MT9)

Kỹ thuật chuẩn ngành: Active Learning / Human-in-the-Loop + Hard Negative Mining + Weak Supervision.

Nguyên tắc: Kho càng chín → mơ hồ càng ít → người càng ít phải duyệt → nhưng phải đo được sự cải thiện (MT9).

MT7 — Tổ chức dữ liệu kết quả để hệ thống học được

Mọi outcome (case study, báo cáo rút kinh nghiệm, chấm điểm thưởng/phạt) phải được Semantic Annotation + Entity Linking — gắn ngữ nghĩa vào từng khái niệm, link ngược vào quyết định/hành động dẫn đến kết quả đó.

Vấn đề thực tế: Rút kinh nghiệm xong cất tủ, lần sau không ai tìm ra. Chấm điểm tốt/tồi nhưng không ghi "điểm này gắn vào hành động nào" → hệ thống không biết thưởng/phạt ai → vô nghĩa.

2 kỹ thuật chuẩn ngành:

Case-Based Reasoning (CBR): Mỗi case study có cấu trúc: bối cảnh → vấn đề → hành động → kết quả → bài học. Tất cả khái niệm được Entity Linking. Khi gặp vấn đề mới → Agent tra case cũ có bối cảnh tương tự → đưa bài học ra.
RLHF (Reinforcement Learning from Human Feedback): Kết quả tốt → tăng trọng số cho chuỗi quyết định liên quan. Kết quả tồi → giảm. PG đã có universal_edges.weight + confidence + Đ39 C9 guardrails.

Phục vụ Đ39: B5 (Case Study Transfer) + C9 (Self-Learning Loop) + C13 (Negative Knowledge).

MT8 — Identity Resolution + Merge Governance + Namespace

MT1 giải quyết "link về đúng thực thể" lúc đọc. MT8 giải quyết quản trị thực thể khi phát hiện trùng, cần gộp, cần tách:

Merge: 2 concept thực ra là 1 → gộp, chọn canonical nào sống (survivorship rule), alias cũ trỏ về canonical mới
Split: 1 concept thực ra là 2 → tách, tạo canonical mới, phân lại aliases
Canonical reassignment: Thay đổi tên chuẩn khi tên cũ không còn phù hợp
Namespace / Scope: Cùng 1 từ viết tắt nhưng nghĩa khác ở domain khác — "NĐ" trong pháp lý = "Nghị định", trong tổ chức = "Nghiệp đoàn". Alias phải gắn domain/scope để giải quyết đa nghĩa (polysemy)
Ai duyệt: Merge/split = thay đổi ontology → APR (Đ32). AI đề xuất, người chốt.

Hiệu lực thời gian (Council Vòng 2): Merge/split/reassignment tạo revision mới cho mọi alias và relation bị ảnh hưởng. Revision cũ giữ nguyên với effective_to = thời điểm thay đổi. Toàn bộ lịch sử truy vấn được qua revision chain — phục vụ temporal reasoning Đ39.

Kỹ thuật chuẩn ngành: Entity Resolution, Record Linkage, Survivorship Rules — phần sâu hơn của MDM.

Không có MT8 → MT1 chỉ giải quyết lúc đọc, SSOT dần rối.

MT9 — Evaluation & Calibration: đo lường chất lượng liên tục

Không có đo lường → "AI có vẻ đúng" mà không biết thực sự đúng bao nhiêu.

Các chỉ số bắt buộc:

Precision / Recall: Entity Linking đúng bao nhiêu %, bỏ sót bao nhiêu %
Ambiguity rate: Tỷ lệ mơ hồ — giảm dần theo thời gian = hệ thống đang học
Override rate: Tỷ lệ người sửa lại kết quả AI — giảm dần = AI đang cải thiện
False merge / False link rate: Tỷ lệ gộp sai, link sai — phải gần 0
Stale alias rate: Tỷ lệ alias cũ không còn hợp lệ

Gold set: Tập mẫu chuẩn (vài trăm case đã duyệt chắc chắn) → benchmark monthly → so sánh kết quả tự động vs gold set → biết hệ thống đang tốt lên hay xấu đi.

Confidence calibration: Điểm kỹ thuật (match_score) ≠ xác suất đúng. Cần hiệu chuẩn: score 0.8 phải thực sự đúng ~80%, không phải "AI nói 0.8 nhưng thực tế chỉ đúng 50%".

Kỹ thuật chuẩn ngành: Gold Set Management, Confidence Calibration, Weak Supervision.

Phục vụ: Mọi MT khác — không đo = không biết hệ thống có hoạt động không.

TÓM TẮT 9 MỤC TIÊU

MT	Mục tiêu	Phục vụ
MT1	Nhận diện khái niệm → đúng thực thể PG (Entity Linking + Canonicalization)	Đ38 binding
MT2	Ghi nhận quan hệ ngữ nghĩa mềm (đồng nghĩa, bao hàm, mâu thuẫn) + hiệu lực thời gian	Đ39 graph edges
MT3	Pipeline NLP 5 bước, phân nhánh theo confidence (Normalize→NER→Linking→Relation)	Đ38 + Đ39
MT4	3 mức tin cậy + provenance + 3 vùng dữ liệu + retention policy	Chất lượng + Đ39 A8
MT5	Bootstrap từ PG schema hiện có (Ontology Learning from RDB) + pháp trị semantic_concept	Khởi tạo nhanh
MT6	Active Learning hoàn chỉnh (review queue + gold set + hard negatives + domain-aware)	Vòng lặp cải tiến
MT7	Tổ chức outcome/case study để hệ thống học được (CBR + RLHF)	Đ39 B5+C9+C13
MT8	Identity Resolution + Merge Governance + Namespace/Scope + temporal revision chain	Quản trị SSOT
MT9	Evaluation & Calibration — đo lường chất lượng liên tục (gold set + precision/recall)	Tất cả MT

NGUYÊN TẮC XUYÊN SUỐT

Kỹ thuật chuẩn ngành (không phát minh): Entity Linking, Canonicalization, NER, Relation Extraction, Coreference Resolution, Text Normalization, MDM, CDM, Entity Resolution, Record Linkage, Survivorship Rules, CBR, RLHF, Active Learning, Hard Negative Mining, Weak Supervision, Confidence Calibration, Gold Set Management, SKOS, Ontology Learning from RDB.

PG native first — "vắt cạn PG" (17 tính năng):

pg_trgm — fuzzy matching trigram, GIN index
fuzzystrmatch / levenshtein — edit distance
unaccent — bỏ dấu tiếng Việt
citext — so sánh không phân biệt hoa thường. Áp dụng ngay từ đầu cho mọi cột Name/Alias (Council Vòng 2 Gemini)
Full Text Search (tsvector/tsquery) + ts_rank_cd — tìm kiếm + xếp hạng
ltree — phân cấp taxonomy approved. Ontology mềm dùng entity_relations + Recursive CTE
JSONB + JSONPath (jsonpath) — lưu annotation, DOT query trực tiếp
Expression indexes — index trên unaccent(lower(name)) giảm chi phí runtime
Generated columns — tự tính search_vector
Materialized Views — tra cứu Entity Linking gộp sẵn
Partial indexes — WHERE status = 'approved', nhỏ + nhanh
Recursive CTE — duyệt quan hệ nhiều tầng
LISTEN/NOTIFY — pipeline nhẹ thay polling
DEFERRABLE constraints — batch bootstrap/import
Window functions / DISTINCT ON — xếp hạng candidate trong SQL
Partitioning theo thời gian — annotation/provenance/log phình dần
pg_stat_statements — giám sát hiệu năng query fuzzy/trgm

Kiến trúc:

Qdrant — embedding similarity, song song với PG fuzzy
Langroid agent — NER, Relation Extraction, Coreference, rerank. Chỉ ăn phần khó
Birth Registry = SSOT — mọi khái niệm khai sinh trước khi dùng
3 vùng dữ liệu — approved / candidate / quarantine. Không trộn
Tách match_score (kỹ thuật) vs approval_state (quản trị)
JSONB runtime + cột nóng tách riêng + W3C export layer
Bootstrap batch = draft, không auto-approve (NT-09)
Namespace/Scope cho alias đa nghĩa

Assembly path (NT-06, NT-08): Mọi dữ liệu NĐ-36-01 tạo ra (aliases, relations, disambiguation results) khi cần hiển thị UI PHẢI đi qua Assembly: PG → Directus collection → Nuxt component. Không bypass. NĐ-36-01 xây tầng PG; Directus collection mapping và Nuxt UI sẽ được thiết kế trong quy trình triển khai (Phần 5).

Concurrency & Locking (Council Vòng 2): Mọi thao tác disambiguation và merge/split PHẢI có advisory lock hoặc cơ chế serialisation tương đương. Lý do: 2 agent cùng duyệt 1 ambiguity case, hoặc 1 bên approve trong khi bên kia quarantine — race condition phá SSOT. PG pg_advisory_xact_lock(entity_id) là lựa chọn native, không cần thêm extension.

Scope/ACL tối thiểu (Council Vòng 2): Annotation và disambiguation case chạm dữ liệu nhạy cảm phải có scope filtering theo domain/role. Review queue phân quyền: agent chỉ thấy case thuộc domain được giao. Chi tiết ACL implementation thuộc Đ39 C8, NĐ-36-01 chỉ đảm bảo cấu trúc dữ liệu hỗ trợ lọc scope.

Ranh giới sở hữu:

NĐ-36-01: alias, relation, abbreviation_dict, disambiguation_log, normalization/linking infrastructure, provenance chuẩn, temporal versioning, concurrency control
Đ38: semantic annotation VB, binding runtime, annotation lifecycle, binding table
Đ39: tiêu thụ 2 nguồn (entity_relations + Đ38 output), trust, decision logic, ACL chi tiết

PHÂN PHA TRIỂN KHAI — SƠ BỘ (Council Vòng 2 đồng thuận, chi tiết tại Phần 5)

Pha	Tên	MT chính	Mục tiêu
A	NĐ-36-01 Core MVP	MT1, MT5, MT4	Từ điển alias cơ bản + 3 vùng + provenance tối thiểu + review queue cơ bản
B	Chất lượng + Pipeline	MT3, MT9	Pipeline song song + Gold set + đo precision/recall
C	Governance MVP	MT8 (merge/split/namespace), MT2 (temporal)	Merge governance sớm — không để SSOT méo. Versioning alias/relation
D	Đ38 Binding MVP	(thuộc Đ38)	Semantic annotation runtime, binding VB→entity, JSONB+cột nóng
E	Tự học nâng cao	MT6, MT7	Full active learning, benchmark monthly, RLHF data prep, CBR

Lưu ý: GPT đề xuất đẩy MT8 lên sớm (Pha C trước Pha D) — cả hai reviewer đồng ý merge governance không được đợi quá muộn.

NĐ-36-01 v1.2 DRAFT | Phần 1: 9 Mục tiêu | Council Vòng 2: Gemini 9.3 + GPT 9.2 — THÔNG QUA Tiếp theo: Phần 2 — Giải pháp (GP + QT + DOT + phân pha chi tiết)