/01-curriculum/TRACEABILITY_ID_REGISTRY.md — Canonical Identifier Registry Plan

H1 Title + Artifact Governance Metadata + Scope Boundary

Metadata quản trị artifact

Trường kiểm soát	Giá trị chuẩn	Diễn giải áp dụng
Artifact ID	TRACEABILITY_ID_REGISTRY	Định danh quản trị duy nhất của registry trong corpus Nova Foods; dùng nguyên dạng này khi liên kết metadata hoặc kiểm tra tính nhất quán giữa các artifact.
Đường dẫn tệp được kiểm soát	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Đường dẫn canonical của artifact. Bản sao, tên rút gọn hoặc tệp xuất khác không thay thế artifact được kiểm soát này.
Status	IN_REVIEW	Artifact đang ở trạng thái xem xét có kiểm soát và có thể thay đổi theo truy vết. Trạng thái này không đồng nghĩa với APPROVED, BASELINED, production-ready, compliant hoặc được người dùng chấp thuận.
Version	v0.9.0	Phiên bản kế hoạch đang được xem xét tại thời điểm ghi nhận metadata.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Owner chịu trách nhiệm duy trì tính toàn vẹn của metadata, định danh artifact, trạng thái, phiên bản và liên kết quản trị của registry. Owner rà soát, cập nhật và ghi nhận thay đổi trong artifact; kết quả là thông tin quản trị và truy vết được giữ nhất quán. Owner không tự thiết lập baseline, không ghi nhận approval và không xác nhận yêu cầu nghiệp vụ hoặc hiệu lực vận hành.
Last updated date	2026-08-07	Ngày cập nhật được diễn giải theo múi giờ quản trị của corpus.
Timezone	Asia/Ho_Chi_Minh	Múi giờ chuẩn để ghi nhận thời điểm thay đổi, review và các bằng chứng quản trị liên quan artifact.
Locale	vi-VN	Locale áp dụng cho nội dung; bối cảnh là Việt Nam và đơn vị tiền tệ mô phỏng của case study là VND.
Case-study reference	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp	Tên Nova Foods chỉ xác định bối cảnh học tập. Không suy diễn đây là hệ thống ERP, tổ chức, giao dịch, cấu hình hoặc dữ liệu thực tế.
Artifact classification	Controlled planning artifact for canonical identifier governance across the Nova Foods ERP corpus	Artifact lập kế hoạch có kiểm soát, dùng để quản trị nhận diện canonical trong corpus; không phải specification triển khai, tài liệu production hay bằng chứng tuân thủ.
Baseline reference	Chưa có baseline reference tại v0.9.0.	Không được gọi registry, metadata, ID hoặc nội dung đang review là baseline khi chưa có tham chiếu baseline được ghi nhận rõ ràng trong artifact kiểm soát phù hợp.
Approval reference	Chưa có approval reference tại v0.9.0.	Sự tồn tại của metadata, việc Owner duy trì artifact hoặc trạng thái IN_REVIEW không tạo approval ngầm định từ Business Owner, QA Reviewer, Legal Owner, Accounting Owner, Architect hoặc bất kỳ vai trò nào khác.

Metadata này xác định danh tính quản trị của /01-curriculum/TRACEABILITY_ID_REGISTRY.md tại 2026-08-07 trong Asia/Ho_Chi_Minh. Owner là Principal IT Business Analyst / Technical Curriculum Author và là vai trò duy trì các trường metadata, trạng thái, phiên bản cùng liên kết quản trị; Owner không có thẩm quyền tự tạo baseline hoặc approval. Mọi trường trên phải được giữ nhất quán khi artifact được tham chiếu bởi CHAPTER_MANIFEST, TEMPLATE_MANIFEST hoặc các artifact Nova Foods liên quan; nếu có xung đột, trạng thái hiện hành vẫn là IN_REVIEW và không được tự suy diễn một quyết định baseline hay approval.

Lịch sử thay đổi khởi tạo

Metadata lịch sử thay đổi

Trường metadata	Giá trị
Artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
Phiên bản khởi tạo	v0.9.0
Ngày ghi nhận khởi tạo	2026-08-07
Múi giờ ghi nhận	Asia/Ho_Chi_Minh
Trạng thái artifact	IN_REVIEW
Người ghi nhận	Principal IT Business Analyst / Technical Curriculum Author
Loại bản ghi	Khởi tạo lịch sử thay đổi
Phạm vi thay đổi	Tạo record lịch sử thay đổi đầu tiên trong giai đoạn lập kế hoạch trước khi soạn nội dung registry
Tác động kiểm soát	Xác định điểm xuất phát có truy vết; không xác lập baseline, không ghi nhận approval, không xác nhận danh sách ID đã hoàn chỉnh và không cấp quyền sử dụng cho production
Quy tắc bảo toàn record	Không sửa đè, xóa hoặc thay đổi ý nghĩa kiểm soát của dòng v0.9.0; mỗi thay đổi tiếp theo phải thêm dòng mới
Yêu cầu metadata cho dòng tiếp theo	Ghi đủ phiên bản, ngày ghi nhận, trạng thái thực tế, người ghi nhận, mô tả thay đổi và tác động kiểm soát
Yêu cầu xác minh bổ sung	Với thay đổi liên quan đến pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật, giữ nhãn Verification required hoặc Project assumption khi chưa có xác minh từ nguồn và vai trò có thẩm quyền

Bản ghi thay đổi

Phiên bản	Ngày ghi nhận	Trạng thái	Người ghi nhận	Nội dung thay đổi	Tác động kiểm soát
v0.9.0	2026-08-07	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo record lịch sử thay đổi đầu tiên cho /01-curriculum/TRACEABILITY_ID_REGISTRY.md trong giai đoạn lập kế hoạch trước khi soạn nội dung registry.	Record này xác định điểm xuất phát có truy vết của artifact; không xác lập baseline, không ghi nhận approval, không xác nhận danh sách ID đã hoàn chỉnh và không cấp quyền sử dụng cho production.

Bản ghi v0.9.0 là bản ghi khởi tạo duy nhất tại thời điểm 2026-08-07, được quản trị theo múi giờ Asia/Ho_Chi_Minh. IN_REVIEW chỉ cho biết artifact đang được kiểm soát để xem xét và có thể được sửa đổi có truy vết. Trạng thái này không tương đương APPROVED, BASELINED, compliant, production-ready hoặc user-approved.

Các thay đổi phát sinh sau bản ghi trên phải được bổ sung thành một dòng mới trong lịch sử thay đổi; không được sửa đè, xóa hoặc thay đổi ý nghĩa kiểm soát của dòng v0.9.0. Người ghi nhận mỗi thay đổi phải ghi đủ phiên bản, ngày ghi nhận, trạng thái thực tế, người ghi nhận, mô tả thay đổi và tác động kiểm soát. Các trường này giúp phân biệt rõ thay đổi quản trị với việc phê duyệt hoặc thiết lập baseline; chúng không tự tạo ra approval, baseline, xác nhận tính đầy đủ của danh sách ID hoặc quyền sử dụng cho production.

Nếu một thay đổi có liên quan đến nội dung cần xác minh về pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật, người ghi nhận phải giữ nhãn Verification required hoặc Project assumption khi chưa có xác minh từ nguồn và vai trò có thẩm quyền. Lịch sử thay đổi vẫn giữ trạng thái IN_REVIEW cho đến khi có quyết định được ghi nhận theo quy trình kiểm soát thay đổi; không được suy diễn trạng thái này thành APPROVED hoặc BASELINED.

Mục đích của Registry: Nguồn Chuẩn Duy Nhất cho Quản trị Định danh

TRACEABILITY_ID_REGISTRY.md là nguồn chuẩn duy nhất để thiết lập và duy trì quản trị định danh trong toàn bộ corpus Nova Foods Trading & Manufacturing. Registry bảo đảm mỗi đối tượng cần được nhận diện và liên kết truy vết có một mã chuẩn, được dùng nhất quán giữa handbook chapter, template, manifest, bảng quy tắc, từ điển dữ liệu, yêu cầu, kiểm thử và các artifact lập kế hoạch liên quan.

Một định danh chỉ được coi là canonical khi được ghi nhận trong registry này. Artifact khác có thể tham chiếu hoặc hiển thị định danh đã đăng ký, nhưng không được tự coi là nguồn quyết định về sự tồn tại, ý nghĩa quản trị, trạng thái sử dụng hoặc quan hệ truy vết của ID đó. Khi xuất hiện khác biệt giữa một ID trong artifact tiêu thụ và record tương ứng trong registry, record của registry là căn cứ để phát hiện và đưa xung đột vào quy trình kiểm soát thay đổi.

Mục tiêu quản trị	Cách registry phục vụ mục tiêu	Kết quả kiểm soát mong đợi
Nhận diện nhất quán	Duy trì một điểm tham chiếu chung cho các mã được dùng xuyên corpus.	Một đối tượng truy vết không bị gọi bằng nhiều mã cạnh tranh.
Liên kết truy vết	Cung cấp nền tảng nhận diện ổn định để artifact này tham chiếu chính xác artifact khác.	Có thể kiểm tra đường liên kết giữa nội dung lập kế hoạch, yêu cầu, quy tắc, dữ liệu, kiểm thử và chapter.
Phòng ngừa trùng lặp	Là điểm kiểm tra trước khi một mã mới được đưa vào artifact kiểm soát.	Không vô tình dùng lại một mã cho hai đối tượng khác nhau trong corpus.
Bảo toàn lịch sử	Giữ nhận diện có kiểm soát khi nội dung được điều chỉnh qua các phiên bản.	Thay đổi nội dung không làm mất khả năng đối chiếu record cũ và mới.
Hỗ trợ review	Cho reviewer một nơi xác định để kiểm tra tính hợp lệ của tham chiếu ID.	Review tập trung vào bằng chứng định danh thay vì suy đoán từ tên gọi tự do.

Registry này phục vụ corpus đang ở trạng thái lập kế hoạch IN_REVIEW, không phải một tuyên bố rằng mọi ID đã được phê duyệt, chốt baseline hoặc sẵn sàng cho áp dụng thực tế. Trong bối cảnh Nova Foods là case study giáo dục dùng dữ liệu tổng hợp, ID là công cụ kiểm soát tính nhất quán của artifact và truy vết học tập. Một ID không tự xác nhận tính đúng đắn của nội dung được gắn mã, không thay thế đánh giá chuyên môn, và không tạo quyền quyết định cho Owner hoặc người sử dụng artifact.

Ranh giới phạm vi: Registry chỉ quản trị định danh

/01-curriculum/TRACEABILITY_ID_REGISTRY.md chỉ là nguồn chuẩn để quản trị định danh trong corpus Nova Foods Trading & Manufacturing: xác định tên ID, tiền tố, cấu trúc, miền áp dụng, tính duy nhất, trạng thái cấp phát và quan hệ truy vết giữa các artifact. Registry trả lời câu hỏi “một đối tượng đã được nhận diện bằng ID nào và ID đó được phép tham chiếu ra sao”, không trả lời câu hỏi “Nova Foods phải vận hành như thế nào”.

Phạm vi Registry được phép quản trị	Ngoài phạm vi Registry, phải thuộc artifact có thẩm quyền phù hợp
Cú pháp, tiền tố, mã miền, quy tắc viết hoa/thường và tính duy nhất của ID.	Yêu cầu nghiệp vụ, nhu cầu stakeholder, mục tiêu kinh doanh, ưu tiên và tiêu chí thành công.
Việc một ID đại diện cho artifact, requirement, business rule, data element, test case, quyết định, giả định hoặc rủi ro.	Nội dung, điều kiện, ngoại lệ, tính đúng đắn hoặc mức ưu tiên của requirement và business rule.
Liên kết định danh giữa các artifact để truy vết; ví dụ một requirement ID liên kết với rule ID hoặc test-case ID.	Ngữ nghĩa dữ liệu, kiểu dữ liệu, độ dài, giá trị hợp lệ, nguồn dữ liệu, quyền sở hữu dữ liệu và mapping dữ liệu.
Trạng thái quản trị của ID như dự kiến cấp phát, đã cấp phát, ngừng dùng hoặc được thay thế, theo quy tắc registry.	Nội dung chapter, mục tiêu học tập, ví dụ hướng dẫn, cách giải thích nghiệp vụ hoặc kết luận đào tạo.
Phát hiện xung đột định danh, tái sử dụng ID và tham chiếu đến ID chưa được đăng ký.	Phê duyệt, baseline, quyết định kiến trúc, xác nhận kiểm thử, xác nhận tuân thủ, hoặc cho phép production.

Quy tắc diễn giải bắt buộc

1. Một ID hợp lệ không làm nội dung mang ID đó trở thành đúng, đầy đủ, được phê duyệt hoặc đã baseline. Ví dụ, việc đăng ký BR-INV-001 chỉ xác nhận đây là một định danh business rule được quản trị; không xác nhận quy tắc về tồn kho mà ID này tham chiếu là phù hợp với Nova Foods.
2. Registry không được viết lại, diễn giải, hợp nhất hoặc sửa nội dung của business requirement, business rule, định nghĩa dữ liệu hay chapter. Khi nội dung nguồn thay đổi nhưng ID vẫn giữ, artifact nguồn phải kiểm soát thay đổi nội dung theo quản trị riêng của nó.
3. Registry không được dùng để suy ra nghĩa pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật. Các nội dung chưa được xác minh phải tiếp tục mang nhãn Verification required hoặc Project assumption tại artifact nội dung phù hợp.
4. ID và liên kết trong registry chỉ phục vụ corpus mô phỏng giáo dục Nova Foods Trading & Manufacturing với dữ liệu tổng hợp. Chúng không chứng minh sự tồn tại của ERP thực tế, dữ liệu vận hành thực, cấu hình production hoặc quyết định của doanh nghiệp thực.
5. Khi có mâu thuẫn giữa định danh registry và nội dung artifact nguồn, registry chỉ xử lý xung đột nhận diện hoặc tham chiếu; chủ sở hữu artifact nguồn và vai trò có thẩm quyền phải quyết định nội dung nghiệp vụ, dữ liệu hoặc chapter.

Cơ sở nguồn đã xác minh và giới hạn sử dụng trong quản trị định danh

Registry này chỉ sử dụng các nguồn hạt giống đã xác minh dưới đây làm bối cảnh quản trị khi đặt, mô tả hoặc kiểm tra định danh trong corpus Nova Foods. Việc tham chiếu nguồn không chuyển nội dung nguồn thành quy tắc nghiệp vụ, nghĩa vụ pháp lý, tiêu chí tuân thủ, hoặc phê duyệt cho bất kỳ ID nào. Không suy diễn số điều, khoản, trang, câu chữ, yêu cầu chi tiết hoặc trích dẫn nguyên văn khi nội dung đó chưa được kiểm tra trực tiếp từ văn bản có thẩm quyền.

Nhóm nguồn đã xác minh	Nguồn	Vai trò bối cảnh được phép cho registry	Giới hạn bắt buộc
Phân tích nghiệp vụ và yêu cầu	BABOK Guide v3; ISO/IEC/IEEE 29148:2018	Hỗ trợ dùng thuật ngữ quản trị yêu cầu, stakeholder, traceability và cấu trúc artifact ở mức khái niệm.	Không tuyên bố ID, cấu trúc ID hoặc liên kết traceability tuân thủ một điều khoản cụ thể nếu chưa đối chiếu văn bản được cấp phép.
Mô hình hóa	OMG BPMN 2.0.2; OMG UML 2.5.1	Phân biệt nguồn chuẩn cho ký pháp BPMN và ngữ nghĩa UML khi ID được liên kết với artifact mô hình.	Registry không xác nhận một sơ đồ là BPMN hoặc UML chỉ vì ID có tiền tố liên quan mô hình.
Kiểm thử, API, accessibility và security	ISTQB CTFL v4.0.1; OAS 3.1.1; WCAG 2.2; OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Làm rõ nguồn tham khảo phù hợp khi định danh test, API, accessibility hoặc security artifact.	Không biến tiền tố ID thành bằng chứng đáp ứng tiêu chuẩn; OWASP không phải pháp luật Việt Nam.
Pháp lý Việt Nam và nghiệp vụ có điều kiện pháp lý	Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP; Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP; Luật 55/2010/QH12	Cảnh báo rằng các artifact có ID liên quan dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc có thể cần nguồn chính thức và vai trò có thẩm quyền xác minh.	Không diễn giải nghĩa vụ pháp lý, không xác nhận compliance, không suy đoán hiệu lực của sửa đổi sau ngày truy cập 2026-08-07. Nội dung chưa xác minh phải mang nhãn Verification required hoặc Project assumption.

Quy tắc diễn giải nguồn: nguồn hạt giống xác nhận phạm vi tham khảo, không xác nhận nội dung chi tiết của artifact được gắn ID. Ví dụ, một định danh liên kết đến test case có thể dùng thuật ngữ kiểm thử nhất quán với ISTQB CTFL, nhưng bản thân liên kết đó không chứng minh test case đầy đủ, đã thực thi hoặc được chấp thuận. Tương tự, một ID liên kết artifact về dữ liệu cá nhân chỉ định vị artifact để truy vết; nó không thay thế xác minh của Legal/Compliance Owner.

Tất cả ví dụ, tên miền nghiệp vụ và định danh Nova Foods Trading & Manufacturing trong corpus là dữ liệu tổng hợp cho mục đích giáo dục. Registry không sử dụng nguồn hạt giống để khẳng định cấu hình ERP thực tế, quyết định vận hành thực tế, hay hiệu lực production.

Allowed Domain Codes, Meanings, Freeze Rules, and Initial Reservations

Mã miền (domain code) là phân đoạn xác định năng lực nghiệp vụ hoặc năng lực nền tảng chịu trách nhiệm chính cho một định danh trong corpus Nova Foods Trading & Manufacturing. Mã miền không phải tên bảng dữ liệu, tên màn hình, loại artifact, vai trò người dùng hoặc trạng thái quy trình. Danh mục dưới đây là từ vựng miền chuẩn được dùng cho /01-curriculum/TRACEABILITY_ID_REGISTRY.md tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07.

Mã miền chuẩn	Nghĩa chuẩn một dòng	Phạm vi nghiệp vụ chính
CRM	Quản lý quan hệ khách hàng và thông tin tương tác với khách hàng.	Hồ sơ khách hàng, liên hệ, cơ hội, tương tác và chăm sóc khách hàng.
SALES	Quản lý hoạt động bán hàng từ nhu cầu thương mại đến đơn bán.	Báo giá bán, đơn hàng bán, cam kết bán hàng và điều kiện thực hiện bán.
PRICE	Quản lý cấu trúc, điều kiện và hiệu lực của giá thương mại.	Bảng giá, mức giá, chiết khấu, khuyến mại và điều kiện áp dụng giá.
PROC	Quản lý hoạt động tìm nguồn, mua hàng và quan hệ giao dịch với nhà cung cấp.	Yêu cầu mua, đơn mua, xác nhận mua và điều kiện mua hàng.
INV	Quản lý số lượng, trạng thái và vị trí tồn kho của hàng hóa hoặc nguyên vật liệu.	Nhập, xuất, chuyển, kiểm kê, giữ hàng và số dư tồn kho.
MFG	Quản lý lập kế hoạch và thực hiện sản xuất thành phẩm hoặc bán thành phẩm.	Công thức, lệnh sản xuất, tiêu hao nguyên liệu, sản lượng và hoàn thành sản xuất.
QMS	Quản lý chất lượng sản phẩm, nguyên liệu và hoạt động kiểm soát chất lượng trong mô phỏng.	Tiêu chuẩn chất lượng, kiểm tra, kết quả kiểm tra, không phù hợp và quyết định chất lượng.
LOG	Quản lý vận chuyển, giao nhận và luồng phân phối vật lý ngoài phạm vi số dư tồn kho.	Kế hoạch giao hàng, chuyến giao, điểm giao nhận và xác nhận giao nhận.
FIN	Quản lý hoạt động tài chính vận hành không phải ghi nhận sổ kế toán.	Ngân quỹ, kế hoạch tài chính, dòng tiền, thanh toán và đối soát tài chính nghiệp vụ.
ACCT	Quản lý ghi nhận, phân loại và đối chiếu kế toán.	Bút toán, sổ cái, kỳ kế toán, tài khoản kế toán và đối chiếu kế toán.
BI	Quản lý phân tích, chỉ số và sản phẩm báo cáo phục vụ quyết định.	Báo cáo, dashboard, chỉ số, mô hình phân tích và dữ liệu trình bày.
SEC	Quản lý kiểm soát an ninh thông tin và quyền truy cập hệ thống.	Danh tính, xác thực, phân quyền, nhật ký bảo mật và sự kiện kiểm soát truy cập.
INT	Quản lý giao tiếp có cấu trúc giữa ERP và hệ thống hoặc dịch vụ khác.	API, thông điệp, sự kiện tích hợp, ánh xạ giao diện và xử lý lỗi tích hợp.
DATA	Quản lý cấu trúc, chất lượng, vòng đời và quản trị dữ liệu dùng chung.	Dữ liệu chủ, mô hình dữ liệu, quy tắc chất lượng dữ liệu, chuyển đổi và lưu giữ dữ liệu.
HR	Quản lý thông tin và quy trình nguồn nhân lực với tư cách miền nghiệp vụ.	Hồ sơ nhân sự mô phỏng, cơ cấu tổ chức nhân sự, vị trí công việc và dữ liệu lao động nghiệp vụ.

QMS, LOG và HR là các miền hỗ trợ cần thiết để mô tả nhất quán bối cảnh doanh nghiệp thực phẩm sản xuất và thương mại trong case study. Chúng được giữ tách biệt khỏi MFG, INV, SEC và DATA vì lần lượt đại diện cho quản lý chất lượng, vận hành giao nhận và nghiệp vụ nhân sự, thay vì sản xuất, tồn kho, kiểm soát truy cập hoặc quản trị dữ liệu dùng chung.

Danh mục này chỉ xác định nghĩa chuẩn của mã miền cho dữ liệu tổng hợp phục vụ giáo dục Nova Foods. Việc một định danh mang mã QMS, ACCT, SEC hoặc miền khác không tự xác nhận chất lượng, tính tuân thủ, diễn giải pháp lý, hạch toán hợp lệ, phê duyệt hoặc khả năng sử dụng production.

Từ điển nghĩa chuẩn của mã miền

Mã miền biểu thị chủ thể chịu trách nhiệm nghiệp vụ chính của đối tượng được định danh, không phải tên màn hình, tên đội dự án, công nghệ hay bước xử lý tạm thời. Bảng dưới đây là bảng định nghĩa có thẩm quyền duy nhất cho toàn bộ Registry. Mỗi mã có đúng một nghĩa chuẩn để các requirement, business rule, data object, interface, test artifact và evidence của case study Nova Foods Trading & Manufacturing cùng sử dụng một ngữ nghĩa. Các bảng quy tắc, bảng dải số dành trước, ví dụ, regex và kiểm tra liên tệp phải dùng đúng mã và đúng nghĩa trong bảng này; không được tạo mã thay thế hoặc diễn giải khác.

Mã miền	Nghĩa chuẩn một dòng
CRM	Quản lý thông tin, tương tác, phân khúc và quan hệ trước hoặc trong vòng đời chăm sóc khách hàng.
SALES	Quản lý hoạt động bán hàng, báo giá bán, đơn bán, cam kết giao hàng và điều kiện thương mại với khách hàng.
PRICE	Quản lý cấu trúc giá, bảng giá, chiết khấu, khuyến mại và quy tắc xác định giá áp dụng.
PROC	Quản lý nhu cầu mua, yêu cầu mua, lựa chọn nhà cung cấp, đơn mua và điều kiện mua hàng.
INV	Quản lý số lượng, trạng thái, vị trí, điều chuyển và kiểm kê tồn kho hàng hóa hoặc nguyên vật liệu.
MFG	Quản lý kế hoạch, công thức, lệnh, tiêu hao và ghi nhận thực hiện sản xuất hoặc đóng gói.
FIN	Quản lý lập kế hoạch tài chính, ngân sách, dòng tiền, công nợ và phân tích tài chính quản trị.
ACCT	Quản lý ghi nhận kế toán, bút toán, sổ cái, đối soát và chứng từ kế toán.
BI	Quản lý mô hình phân tích, chỉ số, báo cáo quản trị, dashboard và khai thác dữ liệu phục vụ quyết định.
SEC	Quản lý định danh truy cập, phân quyền, xác thực, nhật ký an ninh và kiểm soát bảo mật hệ thống.
INT	Quản lý hợp đồng giao tiếp, thông điệp, ánh xạ và vận hành trao đổi dữ liệu giữa các hệ thống.
DATA	Quản lý dữ liệu chủ dùng chung, chất lượng dữ liệu, quyền sở hữu dữ liệu và quy tắc quản trị dữ liệu.
LOG	Quản lý lập kế hoạch vận chuyển, giao nhận, tuyến giao, bàn giao hàng và bằng chứng logistics.
QMS	Quản lý kiểm tra chất lượng, tiêu chí chấp nhận, kết quả kiểm nghiệm, không phù hợp và quyết định chất lượng đối với hàng hóa.
HR	Quản lý thông tin nhân sự, cơ cấu nhân sự, hồ sơ người lao động, năng lực và các hoạt động nghiệp vụ nhân sự.

QMS là mã canonical duy nhất cho miền quản lý chất lượng. Mã QA không được dùng làm mã miền thay thế, bí danh hoặc biến thể của QMS, vì hai mã khác nhau sẽ tạo ra hai cách phân loại và có thể gây trùng hoặc đứt chuỗi truy vết. Mọi bảng dải số dành trước, danh sách mã miền được phép, quy tắc cấp ID, regex, ví dụ và kiểm tra liên tệp phải ghi QMS, không ghi QA. HR là mã miền được định nghĩa chính thức và cũng phải xuất hiện trong mọi bảng quy tắc hoặc dải số dành trước có liệt kê mã miền; nếu bảng liên quan thiếu HR, việc kiểm tra phải thất bại và không được cấp ID thuộc HR cho đến khi bảng đó được cập nhật qua kiểm soát thay đổi.

CRM bao phủ quan hệ khách hàng nhưng không bao gồm giao dịch chốt bán; giao dịch đó thuộc SALES. FIN phục vụ quản trị tài chính và công nợ, trong khi ghi sổ kế toán thuộc ACCT. INV kiểm soát tồn kho vật lý và trạng thái kho, còn LOG kiểm soát hành trình giao nhận bên ngoài hoặc giữa các điểm vận hành. QMS xác định chất lượng và kết quả kiểm tra; MFG chịu trách nhiệm thực hiện công đoạn tạo ra sản phẩm. DATA quản trị đối tượng dữ liệu dùng chung, còn BI sử dụng dữ liệu đã được cung cấp để phân tích và trình bày thông tin quản trị. HR quản trị đối tượng và quy trình nhân sự; không dùng DATA hoặc mã miền khác để thay thế trách nhiệm nghiệp vụ chính của nhân sự.

Quy tắc đóng băng và kiểm soát thay đổi mã miền

Tập mã miền được phép là từ vựng định danh được kiểm soát của /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, mỗi mã miền đã được đăng ký chỉ được sử dụng với một nghĩa nghiệp vụ chuẩn duy nhất. Mã không phải nhãn thuận tiện để nhóm nội dung theo ý người soạn; nó là thành phần mang nghĩa để hệ thống, người học và hoạt động truy vết phân biệt nguồn gốc trách nhiệm của identifier Nova Foods.

Quy tắc kiểm soát	Yêu cầu bắt buộc	Hành vi không được phép
Đóng băng nghĩa	Nghĩa canonical của một mã miền được giữ ổn định sau khi được đăng ký. Các identifier đã cấp tiếp tục được diễn giải theo nghĩa tại thời điểm cấp.	Đổi nghĩa INV từ tồn kho sang hóa đơn, hoặc diễn giải SEC vừa là bảo mật vừa là tổ chức bán hàng.
Không tái sử dụng	Mã miền đã bị ngừng dùng, thay thế hoặc dành riêng vẫn không được tái cấp cho một nghĩa mới.	Dùng lại mã cũ để biểu thị quy trình, đơn vị tổ chức hoặc công nghệ khác.
Không đổi ngầm định	Tài liệu, template, backlog, test artifact hoặc ví dụ mới không được tự đổi nghĩa mã chỉ bằng cách dùng mã đó trong ngữ cảnh khác.	Đặt identifier mới có mã miền hiện hữu nhưng mô tả thuộc miền khác để tránh tạo đề xuất thay đổi.
Thay đổi có kiểm soát	Mọi đề xuất thêm mã, đổi nghĩa, hợp nhất nghĩa, tách nghĩa hoặc ngừng dùng mã phải đi qua change control trước khi áp dụng vào identifier mới.	Sửa trực tiếp danh sách mã, đổi mã trong artifact đã phát hành, hoặc suy luận rằng IN_REVIEW cho phép thay đổi không ghi nhận.
Bảo toàn truy vết	Change control phải đánh giá tác động đến identifier hiện có, quan hệ traceability, regex, template và ví dụ phụ thuộc.	Xóa hoặc viết lại identifier lịch sử chỉ để làm cho danh mục mã mới “đẹp hơn”.

Một yêu cầu thay đổi mã miền phải được ghi nhận trong artifact kiểm soát phù hợp và tối thiểu nêu: mã bị ảnh hưởng; nghĩa canonical hiện tại; nghĩa hoặc mã đề xuất; lý do nghiệp vụ; các identifier, tệp và liên kết traceability bị tác động; phương án tương thích ngược; và vai trò cần review. Việc ghi nhận đề xuất không làm thay đổi từ vựng đang hiệu lực trong registry này. Chỉ một thay đổi đã được xử lý theo cơ chế change control của corpus mới có thể cập nhật quy tắc cấp identifier về sau; IN_REVIEW không tương đương baseline, approval hoặc quyền tự repurpose mã miền.

Khi phát hiện một mã hiện có không còn diễn đạt đúng phạm vi cần dùng, người soạn phải giữ nguyên nghĩa cũ của mã đó và lập đề xuất mã mới hoặc điều chỉnh có truy vết. Không được dùng alias, viết tắt gần giống hoặc biến thể chữ hoa/chữ thường để lách quy tắc đóng băng. Mọi ví dụ Nova Foods trong registry vẫn là mô phỏng giáo dục, dùng dữ liệu tổng hợp, và không xác nhận cấu hình ERP, quyết định vận hành hay sự chấp thuận của bất kỳ người dùng hoặc owner nào.

Dải số được dành trước theo mã miền

Dải dưới đây áp dụng cho thành phần số thứ tự 6 chữ số của mọi họ định danh có mang mã miền. Dải dành trước là không gian số được giữ lại cho một mục đích kiểm soát xác định; việc ghi nhận dải không đồng nghĩa đã cấp phát định danh, đã tạo dữ liệu, đã baseline hoặc đã được phê duyệt. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, Nova Foods chỉ sử dụng dữ liệu tổng hợp.

Mã miền	Dải dành trước ban đầu	Mục đích giữ chỗ bắt buộc	Dải không được dùng như số thông thường
CRM	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
SALES	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
PRICE	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
PROC	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
INV	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
MFG	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
FIN	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
ACCT	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
BI	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
SEC	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
INT	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999
DATA	700000–799999; 900000–949999; 950000–999999	Mẫu đào tạo tổng hợp; kiểm thử; xử lý ngoại lệ được kiểm soát.	700000–999999

Dải số	Phân loại dành trước	Ranh giới sử dụng
700000–799999	Ví dụ, bài tập và kịch bản Nova Foods tổng hợp	Chỉ dùng cho nội dung học tập, dữ liệu minh họa hoặc fixture tổng hợp; không được trình bày là dữ liệu vận hành thực tế.
900000–949999	Kiểm thử và xác minh kỹ thuật	Chỉ dùng cho test case, dữ liệu kiểm thử, kiểm tra tích hợp hoặc bằng chứng kiểm thử tổng hợp.
950000–999999	Ngoại lệ kiểm soát, chuyển đổi hoặc khôi phục cần ghi nhận riêng	Không được dùng làm số tuần tự mặc định; mục đích cụ thể phải được ghi nhận trong artifact kiểm soát phù hợp trước khi sử dụng.

Các số từ 000001–699999 không phải là dải dành trước theo kế hoạch khởi tạo này. Việc một số nằm ngoài dải dành trước không tự xác nhận rằng số đó hợp lệ, đã được cấp, duy nhất, hay có thể dùng cho một artifact cụ thể. Không thiết lập dải dành trước riêng bổ sung cho bất kỳ mã miền nào tại v0.9.0; tránh tạo các vùng số có ý nghĩa khác nhau giữa các miền khi chưa có thay đổi được kiểm soát.

Quy tắc ngăn chặn chồng lấn ngữ nghĩa giữa mã miền

Mỗi mã miền chỉ biểu thị một phạm vi nghiệp vụ chủ đạo trong Nova Foods Trading & Manufacturing. Khi một đối tượng, yêu cầu hoặc liên kết có liên quan nhiều phạm vi, người lập định danh phải chọn mã theo đối tượng chịu trách nhiệm nghiệp vụ trực tiếp và quyết định nghiệp vụ mà artifact đang mô tả, không theo màn hình ERP, phòng ban gửi yêu cầu, hay hệ thống kỹ thuật đang lưu dữ liệu. Không được tạo mã mới chỉ để phản ánh biến thể thuật ngữ, giai đoạn quy trình hoặc tên module.

Cặp mã dễ nhầm	Ranh giới bắt buộc, không được chồng lấn
CRM / SALES	CRM dùng cho quản lý quan hệ, khách hàng tiềm năng, tương tác và cơ hội trước hoặc độc lập với giao dịch bán. SALES dùng cho báo giá bán, đơn bán, giao hàng bán, hoàn trả bán và thực hiện cam kết bán hàng. Không dùng CRM cho đơn bán chỉ vì khách hàng được quản lý trong CRM.
SALES / PRICE	SALES sở hữu giao dịch bán và điều kiện áp dụng trên từng giao dịch. PRICE sở hữu chính sách giá, bảng giá, chiết khấu, khuyến mại và quy tắc xác định giá dùng lại. Không tạo mã SALES cho một quy tắc giá dùng chung; không tạo mã PRICE cho đơn bán cụ thể.
PROC / INV	PROC sở hữu nhu cầu mua, yêu cầu mua, đơn mua, nhận mua và quan hệ với nhà cung cấp. INV sở hữu số lượng, vị trí, trạng thái và biến động tồn kho sau khi hàng đã được ghi nhận. Một lần nhận hàng có thể liên kết cả hai miền, nhưng định danh của chứng từ nhận thuộc PROC; định danh của bút toán hoặc sự kiện cập nhật tồn thuộc INV.
INV / MFG	INV quản lý tồn kho vật tư, bán thành phẩm và thành phẩm tại kho. MFG quản lý công thức, lệnh sản xuất, công đoạn, tiêu hao và kết quả sản xuất. Không dùng MFG cho điều chuyển kho; không dùng INV cho quy tắc thực hiện công đoạn sản xuất.
FIN / ACCT	FIN dùng cho kế hoạch, dòng tiền, phải thu, phải trả, thanh toán và quản trị tài chính vận hành. ACCT dùng cho sổ cái, định khoản, kỳ kế toán, tài khoản và ghi nhận kế toán. Một khoản thanh toán thuộc FIN; bút toán phản ánh khoản thanh toán thuộc ACCT. Diễn giải hạch toán cụ thể là Verification required khi chưa được vai trò có thẩm quyền xác minh.
BI / DATA	BI dùng cho báo cáo, dashboard, chỉ số và phân tích phục vụ quyết định. DATA dùng cho định nghĩa dữ liệu, chất lượng dữ liệu, dữ liệu chủ, ánh xạ, chuyển đổi và quản trị vòng đời dữ liệu. Không dùng BI cho quy tắc làm sạch dữ liệu; không dùng DATA cho chỉ số đã công bố trên dashboard.
SEC / INT	SEC dùng cho danh tính, xác thực, phân quyền, nhật ký an ninh và kiểm soát truy cập. INT dùng cho hợp đồng tích hợp, API, sự kiện, trao đổi tệp và kết nối giữa các hệ thống. API có cơ chế xác thực vẫn thuộc INT; yêu cầu về quyền gọi API thuộc SEC.
DATA / mọi miền nghiệp vụ	DATA không thay thế miền sở hữu nghĩa nghiệp vụ. Ví dụ, định nghĩa thuộc tính “hạn dùng” thuộc DATA, nhưng quy tắc sử dụng hạn dùng trong xuất kho thuộc INV hoặc trong sản xuất thuộc MFG, tùy quyết định nghiệp vụ được mô tả.

Áp dụng kiểm tra chọn miền theo thứ tự sau:

1. Xác định danh từ nghiệp vụ chính: khách hàng tiềm năng, đơn bán, bảng giá, đơn mua, tồn kho, lệnh sản xuất, khoản thanh toán, bút toán, báo cáo, quyền truy cập, API hoặc cấu trúc dữ liệu.
2. Xác định quyết định mà artifact kiểm soát: quản lý quan hệ, thực hiện bán, xác định giá, mua hàng, vận hành kho, sản xuất, quản trị tài chính, ghi nhận kế toán, phân tích, bảo mật, tích hợp hoặc quản trị dữ liệu.
3. Gán đúng một mã miền chủ đạo. Các miền liên quan khác phải được thể hiện bằng liên kết truy vết, không bằng cách ghép, nhân bản hoặc đổi nghĩa mã miền.
4. Nếu hai mã vẫn có vẻ cùng phù hợp, chọn mã của quyết định tạo ra hoặc thay đổi trạng thái nghiệp vụ; mã còn lại chỉ là quan hệ phụ thuộc. Nếu không xác định được quyết định chủ đạo, không tự đặt mã mới và phải đưa vấn đề vào quy trình kiểm soát thay đổi.

Các biến thể và mã gần giống sau bị cấm vì tạo trùng nghĩa hoặc làm mờ ranh giới canonical: SALE, SLS, SELL, PRC, PRICING, PUR, PURCH, PURCHASE, STOCK, WH, WAREHOUSE, MANUF, PROD, GL, ACC, ACCOUNTING, REPORT, RPT, ANL, ANALYTICS, SECURITY, AUTH, API, INTEG, INTEGRATION, MDM, MASTERDATA, DWH, DB, DAT. Không được dùng mã ghép như SALES-PRICE, PROC-INV, FIN-ACCT hoặc SEC-INT để né quyết định chọn miền; quan hệ liên miền phải được quản lý bằng traceability giữa các định danh canonical.

Ví dụ lựa chọn mã miền cho định danh Nova Foods

Các ví dụ dưới đây minh họa cách chọn mã miền theo đối tượng hoặc quyết định nghiệp vụ mà định danh đang tham chiếu, không theo màn hình đang hiển thị, phòng ban tạo yêu cầu, hay hệ thống kỹ thuật lưu trữ. Chuỗi tại cột “Mẫu tham chiếu” chỉ là dữ liệu tổng hợp phục vụ đào tạo, không phải ID đã được cấp, baseline hoặc cấu hình ERP thực tế.

Tình huống Nova Foods mô phỏng	Mã miền chọn đúng	Mẫu tham chiếu minh họa	Lý do chọn
Yêu cầu cập nhật địa chỉ giao hàng của khách hàng tổng hợp	CRM	REF-CRM-CUSTOMER-001	Đối tượng chính là hồ sơ và quan hệ khách hàng; không chọn SALES chỉ vì địa chỉ được dùng khi đặt hàng.
Quy tắc kiểm tra hạn mức trước khi xác nhận đơn bán	SALES	REF-SALES-ORDER-001	Quy tắc điều phối vòng đời đơn bán thuộc nghiệp vụ bán hàng; phần công nợ liên quan có thể được liên kết sang FIN, nhưng không thay thế mã miền chính.
Chính sách giá theo kênh phân phối cho sản phẩm mô phỏng	PRICE	REF-PRICE-POLICY-001	Nội dung quyết định giá, chiết khấu hoặc điều kiện áp giá; không chọn SALES vì chính sách có thể được áp dụng cho nhiều đơn bán.
Yêu cầu phê duyệt nhà cung cấp nguyên liệu	PROC	REF-PROC-SUPPLIER-001	Đối tượng là nguồn cung và quy trình mua; không chọn INV dù nguyên liệu sẽ được nhập kho sau đó.
Quy tắc chặn xuất kho khi lô không đủ điều kiện phân bổ	INV	REF-INV-LOT-001	Quyết định tác động trực tiếp đến số lượng, vị trí, trạng thái hoặc phân bổ tồn kho.
Công thức sản xuất cho một mẻ thực phẩm mô phỏng	MFG	REF-MFG-BATCH-001	Đối tượng là hoạt động sản xuất, cấu phần mẻ, công đoạn hoặc năng lực sản xuất; không chọn INV chỉ vì vật tư bị tiêu hao.
Quy tắc tính giá vốn hoặc phân bổ chi phí nội bộ mô phỏng	FIN	REF-FIN-COST-001	Nội dung thuộc quản trị tài chính, chi phí hoặc kết quả tài chính; không dùng ACCT khi chưa phải định khoản hoặc chứng từ sổ cái.
Yêu cầu tạo bút toán cho giao dịch đã xác định	ACCT	REF-ACCT-JOURNAL-001	Đối tượng là định khoản, tài khoản kế toán, kỳ ghi sổ hoặc chứng từ kế toán; diễn giải kế toán thực tế cần Verification required từ vai trò có thẩm quyền.
Báo cáo xu hướng doanh thu theo kênh và tháng	BI	REF-BI-REPORT-001	Mục tiêu chính là chỉ số, mô hình phân tích, báo cáo hoặc dashboard; không chọn SALES vì dữ liệu bán hàng là nguồn phân tích, không phải đối tượng quản trị của định danh.
Yêu cầu kiểm soát quyền xem giá vốn	SEC	REF-SEC-ACCESS-001	Quyết định trung tâm là xác thực, phân quyền, nhật ký bảo mật hoặc kiểm soát truy cập.
Đặc tả trao đổi đơn hàng với nền tảng bên ngoài mô phỏng	INT	REF-INT-ORDER-001	Đối tượng là hợp đồng giao tiếp, ánh xạ, sự kiện hoặc lỗi tích hợp giữa các hệ thống.
Quy tắc chuẩn hóa mã đơn vị tính trong dữ liệu dùng chung	DATA	REF-DATA-UOM-001	Nội dung tập trung vào định nghĩa, chất lượng, cấu trúc, nguồn gốc hoặc quản trị dữ liệu; không chọn miền nghiệp vụ sử dụng dữ liệu đó.

Quy tắc quyết định nhanh: xác định danh từ trung tâm của yêu cầu trước, rồi chọn miền sở hữu vòng đời hoặc chính sách của danh từ đó. Ví dụ, “API trả tồn kho” chọn INT khi định danh mô tả hợp đồng API; chọn INV khi định danh mô tả quy tắc số dư tồn kho mà API sử dụng. Khi một nội dung có nhiều miền, định danh chính phải phản ánh đối tượng được thay đổi; các miền còn lại được ghi nhận như liên kết truy vết, không tạo mã miền thứ hai cho cùng một ý nghĩa.

Mẫu mã miền bị loại trừ và các biến thể gần giống không được đưa vào registry

Để tránh một khái niệm nghiệp vụ có nhiều nhãn định danh, registry không được tạo mã miền mới chỉ vì khác cách viết, số ít/số nhiều, dạng viết tắt nội bộ, tên màn hình, tên đội nhóm hoặc tên công nghệ. Mã bị loại trừ phải bị từ chối tại bước đề xuất; không được giữ như alias, mã tạm, mã migration hoặc mã ví dụ trong artifact Nova Foods.

Mẫu hoặc mã bị loại trừ	Dễ nhầm với	Lý do loại trừ bắt buộc
CR, CUST, CUSTOMER, CUSTM, CRM01	CRM	Rút gọn, đổi nghĩa sang đối tượng khách hàng, hoặc thêm số phiên bản vào mã miền làm mất tính chuẩn hóa.
SAL, SLS, ORDER, SO, SALES01	SALES	Viết tắt theo đội bán hàng, loại chứng từ hoặc thêm hậu tố số không phải mã miền canonical.
PRC, PRICING, RATE, DISC, PRICE01	PRICE	Phân mảnh cùng phạm vi giá, bảng giá, chiết khấu và điều kiện định giá thành nhiều nhãn gần nghĩa.
PUR, PURCH, BUY, PO, PROC01	PROC	Đồng nhất sai giữa hoạt động mua sắm, vai trò người mua và chứng từ đơn mua hàng.
STOCK, WH, WMS, WAREHOUSE, INV01	INV	Tên kho, công nghệ quản lý kho hoặc trạng thái tồn kho không được trở thành mã miền độc lập.
MANUF, PROD, PRODUCTION, MRP, MFG01	MFG	Tên đầy đủ, từ viết tắt công nghệ hoặc khái niệm kế hoạch vật tư không được dùng thay mã sản xuất.
FINANCE, FNC, CASH, TREASURY, FIN01	FIN	Phạm vi tài chính không được tách bằng tên phòng ban, dòng tiền hoặc chức năng ngân quỹ.
ACCOUNTING, ACC, GL, LEDGER, ACCT01	ACCT	Thuật ngữ sổ cái hoặc cách viết tắt không thống nhất có thể bị hiểu là miền khác với kế toán.
ANALYTICS, REPORT, RPT, DWH, BI01	BI	Báo cáo, kho dữ liệu và phân tích là cách triển khai hoặc đầu ra; không tạo biến thể mã miền.
SECURITY, AUTH, IAM, CYBER, SEC01	SEC	Cơ chế xác thực hay tên chuyên ngành bảo mật không thay thế mã miền bảo mật chuẩn.
INTEGRATION, API, ESB, IF, INT01	INT	Giao thức, nền tảng hoặc loại interface không được dùng làm mã miền cạnh tranh.
DAT, DB, DATABASE, MDM, DATA01	DATA	Công nghệ lưu trữ và quản trị dữ liệu chủ không phải mã miền mới.
Mã ghép như CRM-SALES, FIN-ACCT, INV-MFG, DATA-BI	Hai miền chuẩn	Một mã miền chỉ biểu đạt một phạm vi; quan hệ liên miền phải được thể hiện bằng liên kết traceability, không bằng mã ghép.
Mã có tiền tố hoặc hậu tố tổ chức như NF-CRM, VN-SALES, ERP-INV	Mã miền chuẩn	NF, VN, ERP là ngữ cảnh tổ chức, quốc gia hoặc nền tảng; chúng không làm thay đổi nghĩa miền.
Mã theo công nghệ như SAP, SQL, API, WEB, MOB	Mã miền nghiệp vụ	Registry miền phân loại phạm vi nghiệp vụ và kiểm soát, không phân loại sản phẩm, kiến trúc hay kênh giao diện.
Mã theo trạng thái như DRAFT, TEST, UAT, PROD, ARCHIVE	Mã miền nghiệp vụ	Trạng thái vòng đời không được mã hóa thành miền; việc này gây nhầm lẫn giữa loại đối tượng và tình trạng đối tượng.
Mã dạng tự do có dấu, khoảng trắng hoặc ký tự phân cách như BÁN HÀNG, GIÁ BÁN, KHO-HÀNG, FIN/ACCT	Mã miền chuẩn	Không bảo đảm đối sánh máy, dễ phát sinh nhiều cách biểu diễn cùng một mã và không phù hợp làm token canonical.

Quy tắc quyết định loại trừ: nếu mã đề xuất chỉ khác mã chuẩn bởi viết tắt, dịch ngôn ngữ, số thứ tự, tên công nghệ, tên chứng từ, tên bộ phận hoặc ghép hai phạm vi đã có, mã đó phải bị loại. Nếu người đề xuất cho rằng phạm vi thực sự khác biệt, họ phải chứng minh rằng mã mới không trùng nghĩa với bất kỳ miền canonical nào; khi chưa có thay đổi được kiểm soát, không được đưa mã đó vào /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Identifier Families, Syntax Patterns, Regex Rules, and Examples

Danh mục family định danh canonical

Mỗi định danh trong corpus Nova Foods phải thuộc đúng một identifier family dưới đây. Family biểu đạt bản chất của đối tượng được quản trị, không biểu đạt trạng thái, vai trò, công nghệ, môi trường hay mức độ ưu tiên. Danh mục này áp dụng cho corpus mô phỏng giáo dục Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND, tại trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Family canonical	Tên đối tượng được định danh	Mục đích quản trị	Artifact chứa hoặc quản lý đối tượng
NEED	Business need	Ghi nhận nhu cầu, vấn đề hoặc cơ hội nghiệp vụ ở mức mục tiêu trước khi phân rã thành requirement.	Business needs register, problem statement, scope artifact
REQ-FUNC	Functional requirement	Ghi nhận hành vi hoặc năng lực hệ thống phải cung cấp cho quy trình Nova Foods.	SRS, backlog requirement, functional specification
REQ-NFR	Non-functional requirement	Ghi nhận thuộc tính chất lượng hoặc ràng buộc phi chức năng như hiệu năng, bảo mật, khả dụng hoặc accessibility.	SRS, quality-requirement register, architecture input
BR	Business rule	Ghi nhận quy tắc nghiệp vụ, điều kiện quyết định, công thức hoặc ràng buộc vận hành có thể ảnh hưởng nhiều requirement.	Canonical business-rule register, process specification
AC	Acceptance criterion	Ghi nhận điều kiện quan sát và kiểm tra được để đánh giá một requirement hoặc user story.	Acceptance-criteria register, backlog, test basis
UC	Use case	Ghi nhận mục tiêu tác nhân, luồng chính và ngoại lệ tương tác với hệ thống.	Use-case specification, functional analysis artifact
PROC	Business process	Ghi nhận quy trình nghiệp vụ được mô hình hóa hoặc mô tả, ví dụ quy trình tiếp nhận đơn hàng hoặc kiểm tra lô hàng.	Process catalog, BPMN model index, procedure specification
API	API contract	Ghi nhận hợp đồng giao tiếp dịch vụ hoặc endpoint tích hợp ở mức được quản trị.	OpenAPI description, integration specification, API catalog
DATA	Data entity or data element	Ghi nhận thực thể dữ liệu, thuộc tính dữ liệu hoặc khái niệm dữ liệu có định nghĩa canonical.	Canonical data dictionary, logical data model
INT	Integration flow	Ghi nhận luồng tích hợp giữa các boundary hệ thống hoặc dịch vụ, không thay thế định danh API.	Integration catalog, interface design specification
TC	Test case	Ghi nhận test case có test basis, điều kiện đầu vào, bước kiểm tra và kết quả mong đợi.	Test-case specification, QA repository
DEF	Defect	Ghi nhận sai lệch quan sát được giữa kết quả thực tế và kết quả mong đợi hoặc yêu cầu áp dụng.	Defect register, test execution record
CR	Change request	Ghi nhận đề nghị thay đổi có kiểm soát đối với scope, requirement, rule, dữ liệu, thiết kế hoặc artifact.	Change-request register, change-control artifact
RISK	Risk	Ghi nhận sự kiện không chắc chắn có thể tác động mục tiêu, phạm vi, chất lượng, tiến độ hoặc dữ liệu mô phỏng.	Risk register, project-control artifact
ASSUMP	Project assumption	Ghi nhận giả định dự án chưa được xác minh nhưng đang được dùng để định hình nội dung mô phỏng hoặc phân tích.	Assumption register, planning artifact
DEC	Decision record	Ghi nhận quyết định đã được ghi nhận cùng phạm vi, lựa chọn, lý do và vai trò chịu trách nhiệm.	Decision log, architecture or business decision record
SRC	Source record	Ghi nhận nguồn tham chiếu dùng cho yêu cầu, rule, dữ liệu hoặc quyết định; giữ phân loại nguồn và URL khi có.	Source register, reference catalog
ART	Controlled artifact	Ghi nhận artifact có đường dẫn được kiểm soát trong corpus nhưng không phải một requirement, rule, test case hoặc đối tượng chuyên biệt khác.	Artifact register, manifest, controlled-document metadata
CH	Handbook chapter	Ghi nhận một chapter trong tập 26 handbook chapter đã được quản lý bởi /01-curriculum/CHAPTER_MANIFEST.md.	Chapter manifest, chapter metadata

Nguyên tắc phân loại family

1. NEED trả lời vì sao cần thay đổi; REQ-FUNC và REQ-NFR trả lời hệ thống phải làm gì hoặc phải đạt đặc tính gì. Không dùng NEED thay cho requirement có thể kiểm tra.
2. BR là quy tắc nghiệp vụ độc lập có thể được nhiều REQ-FUNC, AC hoặc TC tham chiếu. Không gán BR cho một mô tả màn hình, endpoint hoặc lỗi kiểm thử.
3. AC là điều kiện đánh giá requirement; TC là kịch bản kiểm thử thực hiện dựa trên test basis. Hai family này không thay thế nhau.
4. API định danh hợp đồng API; INT định danh luồng tích hợp. Một luồng INT có thể sử dụng nhiều API, nhưng vẫn là hai loại đối tượng khác nhau.
5. DATA chỉ định danh khái niệm dữ liệu được quản trị, không định danh bản ghi giao dịch, khách hàng, nhân viên, lô hàng hoặc dữ liệu vận hành thực tế. Mọi dữ liệu Nova Foods trong corpus là dữ liệu tổng hợp.
6. DEF chỉ dùng khi có sai lệch được ghi nhận; không dùng để đặt tên rủi ro, giả định, cải tiến hoặc yêu cầu mới. Các trường hợp này lần lượt thuộc RISK, ASSUMP hoặc CR.
7. SRC giữ nhận diện nguồn, không tạo diễn giải pháp lý, kế toán, thuế, dữ liệu cá nhân, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc. Nội dung chưa được xác minh từ nguồn có thẩm quyền phải giữ nhãn Verification required hoặc Project assumption.
8. ART chỉ dùng cho artifact được kiểm soát nhưng không có family chuyên biệt trong bảng. Không dùng ART để thay thế CH, SRC, CR, DEC hoặc các đối tượng chuyên môn đã có family riêng.
9. CH chỉ áp dụng cho 26 handbook chapter trong biên 00-foundations.md đến 25-ai-assisted-ba-workflow.md; không dùng cho template, registry, manifest hoặc tài liệu phụ trợ.

Danh mục trên là inventory family đầy đủ cho phạm vi registry ở v0.9.0. Việc tạo family mới, đổi nghĩa family, hoặc dùng family ngoài danh mục này là thay đổi kiểm soát đối với /01-curriculum/TRACEABILITY_ID_REGISTRY.md; trạng thái IN_REVIEW không xác lập baseline, approval, xác nhận yêu cầu Nova Foods hay quyền sử dụng production.

Cú pháp định danh chuẩn theo từng họ

Định danh canonical phải biểu đạt loại đối tượng trước, miền nghiệp vụ thứ hai và số phân biệt thứ ba để người đọc nhận biết bản chất record mà không suy diễn nội dung nghiệp vụ từ số thứ tự. Token <DOMAIN> chỉ được thay bằng mã miền đã cho phép và đóng băng tại section 2; không tự tạo mã miền mới trong artifact Nova Foods. Token <NNNN> là vị trí số thứ tự cố định của record trong họ và miền tương ứng.

Họ định danh	Đối tượng được nhận diện	Cú pháp canonical
NEED	Nhu cầu hoặc vấn đề nghiệp vụ	NEED-<DOMAIN>-<NNNN>
REQ-FUNC	Yêu cầu chức năng	REQ-FUNC-<DOMAIN>-<NNNN>
REQ-NFR	Yêu cầu phi chức năng	REQ-NFR-<DOMAIN>-<NNNN>
BR	Quy tắc nghiệp vụ	BR-<DOMAIN>-<NNNN>
AC	Tiêu chí chấp nhận có thể quan sát	AC-<DOMAIN>-<NNNN>
API	Hợp đồng hoặc năng lực API được quản lý	API-<DOMAIN>-<NNNN>
DATA	Đối tượng dữ liệu, thuộc tính dữ liệu, tập dữ liệu hoặc quy tắc dữ liệu được đăng ký	DATA-<DOMAIN>-<NNNN>
TC	Test case	TC-<DOMAIN>-<NNNN>
DEF	Defect được ghi nhận trong phạm vi mô phỏng	DEF-<DOMAIN>-<NNNN>
CR	Change request có kiểm soát	CR-<DOMAIN>-<NNNN>
UC	Use case nghiệp vụ hoặc hệ thống	UC-<DOMAIN>-<NNNN>
PROC	Quy trình hoặc quy trình con được mô hình hóa	PROC-<DOMAIN>-<NNNN>
UI	Màn hình, thành phần giao diện hoặc giao dịch UI được đặc tả	UI-<DOMAIN>-<NNNN>
INT	Điểm tích hợp ngoài API được quản lý riêng	INT-<DOMAIN>-<NNNN>
MAP	Ánh xạ dữ liệu giữa nguồn và đích	MAP-<DOMAIN>-<NNNN>
MIG	Hạng mục chuyển đổi hoặc nạp dữ liệu	MIG-<DOMAIN>-<NNNN>
RISK	Rủi ro dự án, nghiệp vụ hoặc chất lượng	RISK-<DOMAIN>-<NNNN>
ASSUMP	Giả định dự án cần được theo dõi	ASSUMP-<DOMAIN>-<NNNN>
ISSUE	Vấn đề chưa được giải quyết cần định tuyến	ISSUE-<DOMAIN>-<NNNN>
DEC	Quyết định được ghi nhận bởi vai trò có thẩm quyền	DEC-<DOMAIN>-<NNNN>
SRC	Bản ghi nguồn tham chiếu trong corpus	SRC-<DOMAIN>-<NNNN>

Dấu gạch nối (-) là dấu phân tách duy nhất giữa các token; không chèn khoảng trắng, dấu gạch dưới, ngày tháng, tên người, tên tệp hoặc trạng thái như IN_REVIEW vào định danh. Định danh không mang version: version và trạng thái thuộc metadata của artifact, còn quan hệ giữa requirement, rule, API, dữ liệu, acceptance criterion và test case phải được ghi bằng liên kết truy vết riêng. Cú pháp này áp dụng cho corpus Nova Foods Trading & Manufacturing ở trạng thái IN_REVIEW, phiên bản v0.9.0, với dữ liệu tổng hợp; nó không xác lập baseline, approval hoặc hiệu lực vận hành.

Biểu thức regex chuẩn cho từng họ định danh

Các biểu thức dưới đây kiểm tra toàn bộ chuỗi định danh bằng neo đầu ^ và neo cuối $. Token miền dùng lớp cú pháp [A-Z][A-Z0-9]{1,7}; tính hợp lệ về danh mục mã miền được phép phải được đối chiếu bổ sung với danh mục đã đóng băng tại section 2, không được suy ra chỉ từ regex. Mã số dùng [0-9]{3} để kiểm tra đúng ba chữ số ở tầng cú pháp.

Họ định danh	Regex chuẩn	Mục đích kiểm tra cú pháp
NEED	^NEED-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Nhu cầu nghiệp vụ hoặc stakeholder need theo miền.
REQ-FUNC	^REQ-FUNC-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Yêu cầu chức năng theo miền.
REQ-NFR	^REQ-NFR-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Yêu cầu phi chức năng theo miền.
BR	^BR-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Business rule theo miền nghiệp vụ Nova Foods.
AC	^AC-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Acceptance criterion theo miền.
API	^API-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Hợp đồng hoặc bề mặt API theo miền tích hợp.
DATA	^DATA-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Đối tượng dữ liệu, trường dữ liệu hoặc quy tắc dữ liệu theo miền.
TC	^TC-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Test case theo miền kiểm thử.
DEF	^DEF-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Defect được ghi nhận trong phạm vi mô phỏng.
CR	^CR-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Change request theo miền chịu tác động.
UC	^UC-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Use case theo miền.
UI	^UI-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Thành phần, màn hình hoặc đặc tả giao diện theo miền.
INT	^INT-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Điểm tích hợp hoặc giao diện hệ thống không đồng nhất với API.
RISK	^RISK-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Rủi ro dự án, phân tích hoặc triển khai theo miền.
DEC	^DEC-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Bản ghi quyết định cần truy vết theo miền; không tự biểu thị phê duyệt.
ASSUMP	^ASSUMP-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Project assumption cần được tách biệt khỏi requirement hoặc business rule đã xác minh.
VRFY	^VRFY-[A-Z][A-Z0-9]{1,7}-[0-9]{3}$	Điểm Verification required, dùng để theo dõi nội dung còn cần xác minh từ nguồn hoặc vai trò có thẩm quyền.

Quy tắc áp dụng regex: Regex chỉ chấp nhận chữ hoa ASCII, chữ số trong token miền sau ký tự chữ cái đầu tiên, và dấu gạch nối ASCII - tại vị trí quy định. Không chấp nhận khoảng trắng, dấu gạch dưới _, dấu gạch ngang Unicode, ký tự tiếng Việt có dấu, tiền tố không thuộc danh mục họ, hoặc số thứ tự không đủ ba chữ số. Việc chuỗi khớp regex không xác nhận tính duy nhất, hiệu lực nghiệp vụ, baseline, approval, compliance hay mức sẵn sàng production; các kiểm soát đó thuộc quy tắc quản trị và đối chiếu traceability riêng.

Ví dụ định danh hợp lệ theo từng họ

Các ví dụ dưới đây dùng mã miền nghiệp vụ đã được đăng ký cho corpus Nova Foods: SALES, PROC, INV, MFG, QA, FIN, MDM, INT, SEC và RPT. Mọi số thứ tự trong ví dụ là dữ liệu tổng hợp phục vụ đào tạo, không đại diện cho giao dịch, cấu hình hoặc quyết định vận hành thực tế của Nova Foods.

Họ định danh	Ví dụ hợp lệ	Diễn giải ví dụ trong corpus Nova Foods
NEED	NEED-SALES-001	Nhu cầu nghiệp vụ thuộc miền bán hàng, ví dụ theo dõi tình trạng xử lý đơn hàng mô phỏng.
REQ-FUNC	REQ-FUNC-PROC-001	Yêu cầu chức năng thuộc miền mua hàng, ví dụ ghi nhận yêu cầu mua nguyên liệu mô phỏng.
REQ-NFR	REQ-NFR-SEC-001	Yêu cầu phi chức năng thuộc miền bảo mật, ví dụ yêu cầu kiểm soát truy cập được mô tả để review.
BR	BR-INV-001	Quy tắc nghiệp vụ thuộc miền tồn kho, ví dụ quy tắc kiểm tra trạng thái lô hàng trong case study.
AC	AC-SALES-001	Tiêu chí chấp nhận cho một hành vi bán hàng có thể quan sát và kiểm thử.
API	API-INT-001	Định danh hợp đồng hoặc endpoint API tích hợp mô phỏng giữa ERP và hệ thống ngoài phạm vi corpus.
DATA	DATA-MDM-001	Định nghĩa dữ liệu chủ, ví dụ thuộc tính mã nguyên liệu trong dữ liệu tổng hợp.
TC	TC-QA-001	Test case thuộc miền chất lượng, dùng để kiểm tra một điều kiện đầu ra xác định.
DEF	DEF-MFG-001	Khuyết tật được ghi nhận trong bối cảnh kiểm thử quy trình sản xuất mô phỏng.
CR	CR-FIN-001	Yêu cầu thay đổi tác động đến miền tài chính; không hàm ý thay đổi đã được phê duyệt.
UC	UC-PROC-001	Use case mô tả tương tác nghiệp vụ mua hàng trong phạm vi đào tạo.
UI	UI-INV-001	Thành phần giao diện người dùng cho thao tác tồn kho mô phỏng.
BPMN	BPMN-MFG-001	Mô hình quy trình BPMN cho luồng sản xuất; chỉ dùng khi artifact thực sự sử dụng ký pháp BPMN.
RISK	RISK-SEC-001	Rủi ro cần theo dõi liên quan đến miền bảo mật.
ASSUMP	ASSUMP-RPT-001	Giả định dự án liên quan đến báo cáo; không được diễn giải là fact hoặc quyết định đã xác nhận.
ISSUE	ISSUE-INT-001	Vấn đề mở liên quan đến tích hợp cần được phân tích hoặc phân công xử lý.
DEC	DEC-MDM-001	Bản ghi quyết định dự kiến về dữ liệu chủ; chỉ có hiệu lực khi artifact quyết định ghi nhận đúng thẩm quyền và trạng thái thực tế.

Ví dụ hợp lệ phải giữ nguyên thứ tự token: mã họ định danh, tiếp theo là mã miền, rồi số thứ tự ba chữ số. Với hai họ có tiền tố kép, REQ-FUNC và REQ-NFR, toàn bộ tiền tố kép là mã họ duy nhất; FUNC và NFR không phải mã miền. Ví dụ, REQ-FUNC-PROC-001 thuộc miền PROC, còn REQ-FUNC-001 không cung cấp mã miền nên không phải ví dụ hợp lệ.

Các giá trị sau không được dùng làm ví dụ chuẩn: NEED-SALES-1 vì số thứ tự không có ba chữ số; BR-INVENTORY-001 vì INVENTORY không phải mã miền đã đăng ký; REQ-FUNC-SEC-01 vì số thứ tự chỉ có hai chữ số; API-INT-000 vì 000 không là số phân bổ; TC-QA-001-V2 vì thêm token phiên bản vào định danh; và data-mdm-001 vì dùng chữ thường thay cho dạng chữ hoa chuẩn. Phiên bản artifact, trạng thái review, ngày hiệu lực, tên tệp và liên kết traceability phải được lưu ở trường metadata hoặc trường quan hệ phù hợp, không được ghép vào các ví dụ định danh này.

Quy tắc định dạng số thứ tự, đệm số và vị trí token

Mỗi định danh truy vết trong corpus Nova Foods sử dụng cấu trúc token theo thứ tự cố định: FAMILY-DOMAIN-SEQUENCE. FAMILY nhận diện loại bản ghi; DOMAIN là mã miền nghiệp vụ đã được cho phép; SEQUENCE là số thứ tự bốn chữ số. Dấu gạch nối ASCII (-) là ký tự phân tách duy nhất. Không chèn khoảng trắng, dấu gạch dưới, dấu chấm, ký tự tiếng Việt có dấu, ngày tháng, tên người tạo, version, trạng thái hoặc tên tệp vào định danh.

Thành phần	Vị trí bắt buộc	Quy tắc định dạng	Không được dùng
FAMILY	Token đầu tiên	Chữ hoa ASCII; giữ nguyên mã family canonical, kể cả family hai phần như REQ-FUNC và REQ-NFR.	Đảo thành FUNC-REQ; viết thường như req-func; tự rút gọn thành RF.
DOMAIN	Sau FAMILY, trước số thứ tự	Một mã domain canonical đã được đăng ký; chữ hoa ASCII; không chứa khoảng trắng hay mô tả tự do.	Tên module tự đặt, tên phòng ban, tên khách hàng, mã dự án hoặc mã quốc gia.
SEQUENCE	Token cuối cùng	Chính xác bốn chữ số thập phân, đệm số 0 bên trái; bắt đầu từ 0001.	1, 01, 001, 0000, 10000, số âm hoặc ký tự chữ.

Các family nhiều từ phải được đọc là một tiền tố không tách rời. Vì vậy, mẫu trình bày của REQ-FUNC là REQ-FUNC-{DOMAIN}-0001, trong đó REQ-FUNC đứng trọn vẹn trước mã domain; không được đặt domain vào giữa REQ và FUNC. Cùng nguyên tắc này áp dụng cho REQ-NFR-{DOMAIN}-0001. Family một token dùng mẫu tương ứng: NEED-{DOMAIN}-0001, BR-{DOMAIN}-0001, AC-{DOMAIN}-0001, API-{DOMAIN}-0001, DATA-{DOMAIN}-0001, TC-{DOMAIN}-0001, DEF-{DOMAIN}-0001 và CR-{DOMAIN}-0001.

Quy tắc số thứ tự	Áp dụng bắt buộc
Đệm số	Luôn ghi đủ bốn vị trí: 0001, 0042, 0105, 9999. Đệm số bảo đảm sắp xếp văn bản cùng thứ tự với sắp xếp số.
Thứ tự tăng	Số thứ tự được ghi theo chuỗi tăng dần trong phạm vi family và domain tương ứng; không dùng số kiểu 1.1, 02A, 0001a hoặc hậu tố nhánh.
Không mang ngữ nghĩa thời gian	Không nhúng năm, tháng, ngày, sprint hoặc release vào SEQUENCE; ví dụ 2026-08-07 không phải số thứ tự hợp lệ.
Không mang ngữ nghĩa trạng thái	Không gắn DRAFT, IN_REVIEW, APPROVED, OLD, NEW hoặc version như v0.9.0 vào ID. Trạng thái và version thuộc metadata artifact, không thuộc token định danh.
Không thay token bằng tên tệp	Không thêm đuôi .md, đường dẫn như /01-curriculum/, hoặc tên artifact vào ID. ID có thể xuất hiện trong tệp nhưng không trở thành tên tệp.
Dấu phân tách	Giữa mọi token chỉ có một dấu -; không có dấu --, dấu /, dấu _, dấu : hay khoảng trắng.

Các ví dụ sau minh họa lỗi về định dạng, không phải bản ghi được cấp phát:

Chuỗi không hợp lệ	Lý do thất bại
REQ-FUNC-{DOMAIN}-1	SEQUENCE không có bốn chữ số.
REQ-{DOMAIN}-FUNC-0001	Token của family REQ-FUNC bị tách và đặt sai thứ tự.
BR-{DOMAIN}-0000	0000 không phải số thứ tự khởi đầu hợp lệ.
TC_{DOMAIN}_0001	Dùng dấu gạch dưới thay cho dấu gạch nối ASCII.
API-{DOMAIN}-0001-v0.9.0	Chèn version vào sau số thứ tự, làm thay đổi cấu trúc ba thành phần.
DATA-{DOMAIN}-2026-0001	Chèn token năm không được phép giữa domain và số thứ tự.
need-{DOMAIN}-0001	Family viết thường, không đúng chữ hoa canonical.
CR-{DOMAIN}-10000	Số thứ tự có năm chữ số, vượt khuôn dạng bốn chữ số.

Ký hiệu {DOMAIN} trong các mẫu trên chỉ là chỗ giữ chỗ khi soạn tài liệu. Khi ghi vào artifact Nova Foods, chỗ giữ chỗ phải được thay bằng đúng một mã domain canonical đã đăng ký; không được để nguyên dấu ngoặc nhọn trong định danh thực tế.

Ràng buộc sử dụng ID theo họ định danh và loại artifact

Một ID chỉ được cấp phát và sở hữu chính bởi loại artifact được nêu trong cột “Được phép là bản ghi chủ”. Artifact khác chỉ được ghi ID đó như tham chiếu; không được tạo bản ghi trùng, đổi tiền tố, hoặc dùng ID của họ khác để thay thế nội dung chuyên môn. Ma trận này áp dụng cho corpus Nova Foods Trading & Manufacturing mô phỏng giáo dục, dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0.

Họ ID	Được phép là bản ghi chủ trong	Không được dùng làm bản ghi chủ trong	Ràng buộc cấp artifact
NEED	Business need register, problem statement, mục tiêu hoặc outcome nghiệp vụ	SRS/FRD chi tiết, API specification, test case, defect log, change request	Mỗi NEED mô tả nhu cầu hoặc kết quả nghiệp vụ ở cấp vấn đề; không dùng để ghi hành vi hệ thống chi tiết.
REQ-FUNC	Requirement specification, use-case specification, functional backlog được kiểm soát	Business rule catalog, data dictionary, API contract, test execution log	Chỉ dùng cho yêu cầu về hành vi hệ thống có thể triển khai; không dùng cho mục tiêu kinh doanh, SLA, bảo mật hoặc quy tắc nghiệp vụ độc lập.
REQ-NFR	Non-functional requirement specification, quality attribute register	BPMN process model, data dictionary, defect log, change request	Chỉ dùng cho thuộc tính chất lượng hoặc ràng buộc vận hành như hiệu năng, bảo mật, khả dụng, accessibility; không dùng để thay cho REQ-FUNC hoặc BR.
BR	/01-curriculum/CANONICAL_BUSINESS_RULES.md, business rule catalog	API specification, test case, change request, wireframe	Chỉ cấp cho quy tắc nghiệp vụ có thể tồn tại độc lập với một màn hình, API hoặc test case; nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm phải giữ nhãn Verification required khi chưa được xác minh phù hợp.
AC	Acceptance-criteria register, requirement/backlog item có cấu trúc tiêu chí chấp nhận	Business need register, API contract, data dictionary, defect log	AC xác định kết quả quan sát được để đánh giá một requirement hoặc rule; không được dùng như requirement độc lập hoặc bản ghi kết quả test thực tế.
API	OpenAPI description, interface contract, integration specification	Business rule catalog, data dictionary, test execution log, change request	Chỉ định danh endpoint hoặc interface contract; không dùng cho tên bảng dữ liệu, process step hoặc quy tắc tính toán nghiệp vụ.
DATA	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, logical data model, data mapping specification	Requirement register, API operation register, defect log, change request	Chỉ cấp cho entity, attribute, code set hoặc data element theo phạm vi dictionary; không mặc định xác nhận schema production hay dữ liệu thực.
TC	Test case specification, test suite/catalog	Requirement specification, business rule catalog, API contract, defect log	TC là thiết kế kiểm thử có bước, dữ liệu kiểm thử tổng hợp và expected result; không phải requirement, acceptance criterion hoặc bằng chứng test pass/fail.
DEF	Defect register, test incident record	Requirement register, business rule catalog, change request, data dictionary	Chỉ dùng khi ghi nhận sai lệch quan sát được giữa actual result và expected result hoặc baseline/phiên bản kiểm thử được chỉ rõ; không dùng để ghi yêu cầu thay đổi chưa có lỗi.
CR	Change request register, controlled change proposal	Requirement specification gốc, defect log, API contract, data dictionary	Chỉ định danh đề nghị thay đổi có phạm vi và tác động cần đánh giá; CR không tự sửa, thay thế hoặc phê duyệt NEED, REQ-FUNC, BR, DATA hay artifact khác.

Quy tắc áp dụng bắt buộc

1. Một artifact có thể chứa nhiều họ ID nếu đóng vai trò tổng hợp hoặc truy vết, nhưng chỉ được sở hữu những ID thuộc loại artifact của chính nó. Ví dụ, test case có thể tham chiếu REQ-FUNC, REQ-NFR, BR và AC, nhưng chỉ cấp phát TC.
2. Không được dùng TC để đánh số acceptance criterion, dùng API để định danh data field, hoặc dùng DEF để thay cho change request. Khác biệt về loại công việc quyết định họ ID, không phải vị trí lưu trữ tệp.
3. Requirement specification không được tự tạo BR mới trong phần mô tả yêu cầu. Nếu phát hiện quy tắc nghiệp vụ mới, tác giả phải tạo hoặc đề nghị tạo bản ghi trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; requirement chỉ tham chiếu BR đã được đăng ký.
4. Data mapping hoặc OpenAPI description có thể tham chiếu DATA, nhưng không được đổi nghĩa, tên chuẩn hoặc ownership của data element ngoài /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
5. ID xuất hiện trong ví dụ học tập, sơ đồ, bảng minh họa hoặc test data vẫn phải tuân thủ đúng họ ID; dữ liệu và ngữ cảnh Nova Foods chỉ là mô phỏng giáo dục, không xác nhận cấu hình ERP, quyết định vận hành, baseline hoặc approval.

Ví dụ định danh không hợp lệ và lý do từ chối

Các chuỗi dưới đây phải bị từ chối tại bước kiểm tra định dạng. Việc một chuỗi có vẻ dễ đọc, mô tả đúng nghiệp vụ Nova Foods, hoặc xuất hiện trong tài liệu nháp không làm chuỗi đó trở thành định danh hợp lệ. {DOMAIN}, {NNNN} và các biến tương tự chỉ là ký hiệu mô tả trong tài liệu; không được xuất hiện trong ID được ghi vào artifact.

ID không hợp lệ	Lỗi phát hiện	Lý do từ chối cụ thể
need-ORD-0001	Sai chữ hoa/thường	Token họ ID phải viết hoa tuyệt đối. need không tương đương NEED; cho phép chữ thường sẽ làm sai đối chiếu máy và tạo bản ghi trùng thị giác.
NEED-{DOMAIN}-0001	Placeholder chưa được thay thế	{DOMAIN} không phải domain code được phép. ID thực tế phải chứa mã domain đã đăng ký, không chứa biến mẫu.
NEED-ORD-1	Thiếu đệm số	Số thứ tự phải giữ đủ độ dài chuẩn. 1 không tương đương 0001, vì định dạng không ổn định làm sai sắp xếp và truy vết.
REQFUNC-ORD-0001	Sai token họ	REQFUNC gộp sai token của họ REQ-FUNC; dấu gạch nối nội bộ của tên họ là thành phần bắt buộc.
REQ-FUNC-ORD-00001	Sai độ dài số thứ tự	Phần số có năm chữ số thay vì độ dài chuẩn của family. Không được tự mở rộng padding chỉ vì số hiện tại tăng.
REQ-NFR-ORD-00A1	Ký tự không phải chữ số	Token đánh số chỉ chấp nhận chữ số ASCII; ký tự A làm ID không thể được kiểm tra theo quy tắc định danh.
BR-ORD-0001-V2	Thừa token phiên bản	Version thuộc metadata artifact hoặc record thay đổi, không được gắn vào canonical ID. Hậu tố -V2 tạo một chuỗi mới không thuộc family BR.
AC--0001	Domain trống	Hai dấu gạch nối liên tiếp cho thấy token domain bị thiếu; không thể xác định phạm vi nghiệp vụ của acceptance criterion.
API-ORD-0001	Khoảng trắng cuối chuỗi	Khoảng trắng là ký tự không hợp lệ. Chuỗi phải được lưu và đối chiếu chính xác, không tự động cắt khoảng trắng để tránh sửa âm thầm dữ liệu nguồn.
DATA-ord-0001	Domain code sai kiểu chữ	Domain code phải dùng đúng chữ hoa canonical. ord không được chuẩn hóa ngầm thành ORD.
TC-ORD-0000	Số thứ tự không hợp lệ	0000 là giá trị đệm, không phải số thứ tự được cấp phát. ID kiểm thử phải mang số dương trong dải được phép.
DEF-ORD-01	Thiếu chữ số đệm	01 không đạt độ dài số thứ tự bắt buộc; không được suy đoán rằng đây là 0001.
CR-ORD-0001-DRAFT	Trộn trạng thái vào ID	DRAFT là trạng thái quản trị, không phải token của canonical ID. Tại IN_REVIEW, trạng thái của artifact không thay đổi cấu trúc ID.
REQ-FUNC-ORD_0001	Dùng dấu phân cách sai	Dấu gạch dưới không thay thế dấu gạch nối. Thay đổi ký tự phân cách phá vỡ đối chiếu với biểu thức kiểm tra của family.
API-ORD-0001/GET	Chèn phương thức kỹ thuật	HTTP method là thuộc tính của mô tả API, không phải thành phần ID. Dấu / cũng không thuộc bộ ký tự được phép.
DATA-VND-0001	Dùng mã tiền tệ làm domain	VND là đơn vị tiền tệ mô phỏng của corpus, không tự động là domain code. Token domain chỉ hợp lệ khi thuộc danh mục domain codes đã đóng băng.
TC-REQ-FUNC-ORD-0001	Ghép lồng hai family	Test case không được nhúng toàn bộ ID requirement vào chuỗi ID của chính nó. Quan hệ giữa TC và REQ-FUNC phải được lưu bằng liên kết truy vết, không bằng nối token.
DEF-ORD-0001.xlsx	Gắn phần mở rộng tệp	Định danh artifact không phải filename. Phần mở rộng làm ID không còn khớp family DEF; filename được quản trị ở trường riêng.
BR-ORD-0001 (Inventory)	Gắn nhãn diễn giải	Mô tả nghiệp vụ phải nằm trong tiêu đề hoặc trường mô tả, không nằm trong ID. Dấu cách và ngoặc làm chuỗi không còn canonical.
AC-ORD-0001.0	Dùng phân số hoặc phiên bản số	Dấu chấm và hậu tố .0 không được phép; không dùng ID để biểu diễn revision, mức ưu tiên hoặc trạng thái hoàn thành.

Quy tắc xử lý lỗi: công cụ hoặc người soạn phải ghi nhận nguyên văn chuỗi bị từ chối và lý do từ chối; không được tự sửa thành một ID khác, tự suy ra domain code, tự thêm số đệm, hoặc bỏ token dư. Bản ghi chỉ được tạo sau khi người lập artifact cung cấp một canonical ID khớp hoàn toàn với family áp dụng và danh mục domain codes đã được kiểm soát.

Allocation Authority, Lifecycle States, Uniqueness Rules, and Supersession Behavior

Thẩm quyền phân bổ định danh

Trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md, quyền ghi nhận và cấp chuỗi định danh canonical thuộc về Registry Custodian: Principal IT Business Analyst / Technical Curriculum Author. Đây là thẩm quyền quản trị registry, không phải thẩm quyền phê duyệt nghiệp vụ, xác nhận yêu cầu Nova Foods, thiết kế kỹ thuật, kiểm thử, pháp lý, kế toán, thuế hoặc cho phép production. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, việc cấp ID chỉ tạo record có kiểm soát cho corpus mô phỏng giáo dục dùng dữ liệu tổng hợp.

Family định danh	Bên khởi tạo yêu cầu cấp ID	Bên xác định đúng domain và ý nghĩa	Bên có quyền ghi ID vào registry	Ranh giới thẩm quyền
REQ-FUNC-{DOMAIN}-{NNNN}	Business Analyst hoặc tác giả chapter	Business Owner đối với ngữ cảnh nghiệp vụ mô phỏng; Business Analyst đối chiếu phạm vi	Registry Custodian	Không xác nhận requirement đã được Business Owner phê duyệt.
BR-{DOMAIN}-{NNNN}	Business Analyst	Business Owner; Legal, Accounting hoặc Compliance Owner khi quy tắc chạm phạm vi chuyên môn tương ứng	Registry Custodian	Không được diễn giải hoặc xác nhận nghĩa vụ pháp lý, kế toán, thuế hay compliance. Nội dung chưa xác minh giữ nhãn Verification required hoặc Project assumption.
AC-{DOMAIN}-{NNNN}	Business Analyst hoặc QA Reviewer	Business Analyst và QA Reviewer xác định kết quả có thể quan sát, kiểm tra	Registry Custodian	Cấp ID không xác nhận acceptance criterion đã được chấp thuận hoặc đã đạt kiểm thử.
TC-{DOMAIN}-{NNNN}	QA Reviewer hoặc Business Analyst	QA Reviewer xác định test basis và phạm vi test	Registry Custodian	Không xác nhận test execution, test pass, chất lượng hệ thống hoặc readiness.
DEF-{DOMAIN}-{NNNN}	Business Analyst, Data Analyst hoặc tác giả data artifact	Data Owner hoặc Business Owner đối với nghĩa dữ liệu mô phỏng	Registry Custodian	Không xác nhận data model, dữ liệu thực tế, quyền xử lý dữ liệu cá nhân hoặc cấu hình ERP production.
API-{DOMAIN}-{NNNN}	Technical Architect hoặc Business Analyst	Technical Architect xác định ranh giới dịch vụ và domain kỹ thuật	Registry Custodian	Không xác nhận API contract, bảo mật, triển khai hoặc tương thích production.
Các family đã đăng ký khác trong registry	Chủ sở hữu artifact đề nghị	Vai trò chịu trách nhiệm chuyên môn của artifact xác định nghĩa và domain	Registry Custodian	Không được tự tạo family, domain code hoặc mẫu cú pháp ngoài registry đã kiểm soát.

Quy tắc phân quyền và quyết định cấp ID

1. Người khởi tạo chỉ được đề nghị ID sau khi xác định family phù hợp, domain code hợp lệ, tiêu đề artifact và mục đích sử dụng trong corpus Nova Foods.
2. Vai trò chuyên môn xác nhận ý nghĩa dự kiến của artifact trong phạm vi mô phỏng; xác nhận này không phải approval, baseline hoặc cam kết triển khai.
3. Registry Custodian kiểm tra chuỗi đề nghị khớp syntax family, không mâu thuẫn với record registry hiện có và dùng đúng domain code đã đóng băng trước khi ghi nhận.
4. Registry Custodian không được tự suy đoán domain, tự đổi loại artifact, tự cấp ID thay cho yêu cầu thiếu thông tin, hoặc dùng quyền quản trị registry để thay thế quyết định của Business Owner, Technical Architect, QA Reviewer, Legal Owner, Accounting Owner hoặc Compliance Owner.
5. Nếu một đề nghị đồng thời liên quan nghiệp vụ, API, dữ liệu và kiểm thử, mỗi artifact phải do vai trò chuyên môn tương ứng xác định; Registry Custodian chỉ điều phối việc ghi nhận các ID riêng biệt, không gộp chúng thành một ID đa mục đích.
6. Mọi yêu cầu cấp ID phải nêu tối thiểu: family, domain code, tiêu đề ngắn, artifact hoặc filename dự kiến nếu đã có, người đề nghị, vai trò xác định nghĩa và ngày ghi nhận theo Asia/Ho_Chi_Minh.

Tình huống quyết định	Quyết định phân quyền bắt buộc
Business Analyst đề nghị REQ-FUNC-ORD-0001 cho một yêu cầu xử lý đơn hàng mô phỏng	Business Owner xác định phạm vi nghiệp vụ mô phỏng; Registry Custodian kiểm tra và ghi ID nếu hợp lệ.
Technical Architect đề nghị ID cho mô tả endpoint đơn hàng	Technical Architect xác định API thuộc domain; Registry Custodian chỉ cấp ID thuộc family API, không chuyển nó thành REQ-FUNC hoặc TC.
QA Reviewer cần ID cho kiểm thử của requirement đã có	QA Reviewer đề nghị một TC độc lập; Registry Custodian không nhúng ID requirement vào chuỗi test case.
Người soạn yêu cầu một ID cho “quy định hóa đơn bắt buộc” nhưng không có xác minh nguồn hiện hành	Registry Custodian không xác nhận nội dung là nghĩa vụ. Nếu artifact vẫn cần được lập kế hoạch, nội dung phải được định tuyến đúng owner và giữ nhãn Verification required; quyền cấp ID không tạo kết luận pháp lý.
Người đề nghị dùng domain code không có trong danh mục đóng băng	Registry Custodian từ chối ghi nhận chuỗi đó; chỉ vai trò có thẩm quyền quản trị registry theo change control mới được đề xuất thay đổi danh mục domain code.

Mô hình trạng thái vòng đời của định danh

Trạng thái vòng đời áp dụng cho bản ghi định danh trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md, không đồng nhất với Status: IN_REVIEW của artifact registry hay của các artifact Nova Foods được tham chiếu. Một định danh có thể ở trạng thái ACTIVE trong khi artifact chứa nó vẫn IN_REVIEW; điều này chỉ cho biết định danh đã sẵn sàng được tham chiếu nhất quán trong corpus, không tạo baseline, approval hoặc xác nhận sẵn sàng production.

Trạng thái	Ý nghĩa vận hành	Được tham chiếu trong artifact mới	Điều kiện tối thiểu để vào trạng thái
PROPOSED	Định danh đang được đề xuất để review; ý nghĩa, phạm vi hoặc đối tượng áp dụng chưa đủ ổn định để sử dụng chính thức.	Không. Chỉ được xuất hiện trong nội dung review ghi rõ là đề xuất.	Có mô tả mục đích sơ bộ và liên hệ với một đối tượng dự kiến trong corpus.
RESERVED	Định danh được giữ chỗ cho một đối tượng hoặc phạm vi đã xác định, nhưng đối tượng chưa đủ điều kiện sử dụng tham chiếu rộng rãi.	Không, trừ artifact lập kế hoạch ghi rõ trạng thái RESERVED.	Đã xác định ý nghĩa dự kiến, phạm vi sử dụng và tránh xung đột với định danh đang tồn tại.
ACTIVE	Định danh là giá trị hiện hành để liên kết artifact, requirement, rule, dữ liệu mẫu hoặc đối tượng thuộc đúng family đã đăng ký.	Có. Các artifact mới phải dùng đúng định danh ACTIVE tương ứng.	Bản ghi có cú pháp hợp lệ, ý nghĩa xác định và phạm vi sử dụng rõ ràng.
DEPRECATED	Định danh vẫn nhận diện cùng một đối tượng hoặc khái niệm lịch sử, nhưng không còn được chọn cho nội dung mới.	Không cho mục đích tạo mới; được giữ trong nội dung lịch sử hoặc khi cần giải thích tương thích.	Có lý do ngừng sử dụng được ghi nhận; đối tượng chưa bị thay thế hoàn toàn hoặc cần duy trì khả năng đọc tài liệu cũ.
SUPERSEDED	Định danh cũ đã được thay bằng một định danh khác cho cùng dòng đối tượng quản trị, do thay đổi có kiểm soát về cấu trúc hoặc cách định danh.	Không cho nội dung mới, ngoại trừ khi ghi nhận quan hệ thay thế.	Đã xác định định danh thay thế và quan hệ thay thế không làm mất nhận diện lịch sử của định danh cũ.
RETIRED	Định danh kết thúc vòng đời sử dụng; đối tượng không còn thuộc phạm vi vận hành hoặc lập kế hoạch hiện hành.	Không. Chỉ được giữ trong record lịch sử.	Không còn nhu cầu quản trị đối tượng như một thực thể hiện hành và không có chuyển đổi còn mở.

Chuyển đổi	Kết quả	Quy tắc
PROPOSED → RESERVED	Giữ chỗ định danh	Chỉ xảy ra khi ý nghĩa dự kiến đã đủ rõ để phân biệt với các định danh khác.
PROPOSED → ACTIVE	Kích hoạt trực tiếp	Được phép khi không cần giai đoạn giữ chỗ và thông tin đăng ký đã hoàn chỉnh.
RESERVED → ACTIVE	Bắt đầu sử dụng chính thức trong corpus	Không được đổi ý nghĩa đã giữ chỗ thành đối tượng khác trong lúc chuyển trạng thái.
ACTIVE → DEPRECATED	Ngừng chọn cho nội dung mới	Định danh vẫn tồn tại để đọc và hiểu artifact đã sử dụng nó.
ACTIVE → SUPERSEDED	Chuyển sang định danh thay thế	Chỉ dùng khi có định danh kế nhiệm xác định; không dùng để che giấu lỗi hoặc xóa lịch sử.
DEPRECATED → RETIRED	Kết thúc duy trì sử dụng hiện hành	Chỉ áp dụng khi không còn nhu cầu tương thích hoặc tham chiếu vận hành đang mở.
SUPERSEDED → RETIRED	Kết thúc trạng thái thay thế lịch sử	Chỉ áp dụng sau khi nhu cầu giữ trạng thái SUPERSEDED không còn, nhưng record lịch sử vẫn phải được bảo toàn theo quy tắc registry.

Các chuyển đổi sau bị cấm: RETIRED → ACTIVE, SUPERSEDED → ACTIVE, và mọi chuyển đổi làm thay đổi đối tượng mà định danh vốn biểu thị. Ví dụ, một định danh đã từng biểu thị một business rule về kiểm soát lô hàng không được chuyển sang biểu thị một API endpoint, một trường dữ liệu, hoặc một rule khác có nội dung nghiệp vụ khác. Nếu nội dung thay đổi đến mức đối tượng không còn cùng mục đích, cùng phạm vi hoặc cùng tiêu chí kiểm tra, phải xem đó là đối tượng mới thay vì khôi phục hay tái kích hoạt định danh cũ.

Ví dụ hợp lệ: một định danh ở PROPOSED được chuyển sang RESERVED khi nội dung curriculum xác định rõ artifact dự kiến nhưng chưa hoàn tất drafting; sau đó chuyển sang ACTIVE khi artifact có thể dùng định danh đó nhất quán. Ví dụ không hợp lệ: chuyển một định danh DEPRECATED thành ACTIVE để tiết kiệm số thứ tự cho một requirement mới. Việc này phá vỡ ý nghĩa lịch sử và làm sai lệch khả năng đọc corpus Nova Foods mô phỏng.

Quy tắc duy nhất theo Corpus, Phiên bản, Loại Artifact và Thời gian

Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07 theo Asia/Ho_Chi_Minh, mỗi định danh canonical trong corpus Nova Foods phải biểu đạt một và chỉ một đối tượng quản trị xác định. Đối tượng có thể là artifact, requirement, business rule, data element, test asset hoặc thực thể khác đã được đăng ký đúng family; chuỗi ID không được dùng như nhãn hiển thị có thể thay đổi tùy ý.

Chiều kiểm tra	Quy tắc duy nhất bắt buộc	Hệ quả kiểm soát
Toàn corpus	Giá trị đầy đủ của canonical ID là duy nhất trong toàn bộ corpus IT BUSINESS ANALYST — ZERO TO DELIVERY READY, không chỉ duy nhất trong một thư mục hoặc một tệp.	Không được tạo ID trùng cho hai đối tượng, dù chúng thuộc các chapter, template hoặc artifact khác nhau.
Identifier family	Một canonical ID chỉ thuộc một family đã đăng ký; family là một phần của ý nghĩa và không được suy đoán lại từ tên tệp.	Cùng chuỗi ID không được xuất hiện với hai loại family khác nhau.
Loại artifact	ID của artifact được kiểm soát khác với ID của nội dung nằm trong artifact đó. Ví dụ, ID artifact không thay thế cho ID requirement hoặc business rule.	Không dùng một ID để đồng thời định danh tệp và một requirement, rule, trường dữ liệu hoặc test case.
Phiên bản	Canonical ID giữ nguyên qua các phiên bản của cùng một đối tượng có cùng ý nghĩa quản trị; version là thuộc tính của record/artifact, không phải lý do tạo ID thứ hai.	Không tạo thêm ID chỉ vì artifact đổi từ v0.9.0 sang phiên bản sau.
Thời gian	Sau khi đã được ghi nhận trong registry, một ID tiếp tục bị bảo lưu trong lịch sử corpus, kể cả khi đối tượng không còn là lựa chọn hiện hành.	Khoảng số, hậu tố hoặc chuỗi ID đã từng dùng không trở thành “trống” để cấp lại ở thời điểm sau.
Tên tệp và đường dẫn	Tên tệp, đường dẫn và canonical ID là các thuộc tính riêng. Đường dẫn có thể chứa ID khi quy ước family yêu cầu, nhưng không được dùng đường dẫn để suy ra quyền tạo hoặc thay đổi ID.	Việc một tệp được di chuyển trong corpus không cho phép tái dùng ID cũ cho tệp khác.
Chữ hoa/thường và ký tự	So sánh uniqueness thực hiện trên chuỗi canonical đúng nguyên dạng đã đăng ký, đồng thời kiểm tra xung đột sau khi chuẩn hóa chữ hoa/thường và khoảng trắng ở biên.	Không được tạo hai ID chỉ khác chữ hoa/thường, khoảng trắng đầu/cuối hoặc biến thể trình bày có thể bị công cụ coi là cùng giá trị.

Tiêu chí quyết định: giữ nguyên ID khi đối tượng vẫn có cùng phạm vi, cùng ý nghĩa và cùng đối tượng được quản trị; tạo ID mới khi thay đổi làm cho người đọc registry không thể kết luận rằng record mới và record cũ là cùng một đối tượng. Quy tắc này áp dụng cho dữ liệu mô phỏng của Nova Foods Trading & Manufacturing; không xác nhận cấu hình ERP thực tế hay dữ liệu production.

Tình huống	Kết quả đúng	Lý do uniqueness
Một record đã có canonical ID trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; nội dung mô tả được làm rõ nhưng đối tượng quản trị không đổi.	Giữ canonical ID hiện có, ghi nhận thay đổi ở version phù hợp.	Một đối tượng không được nhân bản thành nhiều ID chỉ do chỉnh lý diễn đạt.
Hai artifact khác nhau cùng muốn dùng một canonical ID vì cùng nói về “quản lý tồn kho”.	Chỉ một đối tượng được giữ ID đó; đối tượng còn lại phải dùng ID khác đúng family.	Cùng chủ đề không làm hai đối tượng trở thành một đối tượng quản trị.
Một ID trước đây gắn với rule về lô hàng tổng hợp, sau đó được đề xuất gắn cho trường dữ liệu tổng hợp về hạn dùng.	Không được phép.	Khác loại artifact và khác ý nghĩa; ID không được tái gán theo thời gian.
Một ID được nhập là abc-001 trong một file và ABC-001 trong file khác.	Không được phép cho đến khi xử lý thành một canonical record duy nhất hoặc một ID mới hợp lệ.	Tránh xung đột giữa công cụ, liên kết và hoạt động tìm kiếm không phân biệt hoa/thường.

Khấu hao định danh, thay thế định danh và lưu giữ truy vết lịch sử

Khấu hao (deprecation) chỉ thông báo rằng một định danh không nên được dùng cho nội dung mới; định danh vẫn giữ nguyên nghĩa lịch sử và vẫn phải được truy xuất. Thay thế (supersession) xảy ra khi một định danh mới tiếp quản phạm vi cần dùng trong tương lai từ một định danh cũ. Hai cơ chế này không được xóa, ghi đè, hoặc làm thay đổi bằng chứng rằng định danh cũ đã từng tồn tại trong corpus Nova Foods.

Tình huống	Xử lý bắt buộc trong registry	Hệ quả đối với định danh cũ
Nội dung vẫn đúng nhưng không còn được khuyến nghị cho tài liệu mới	Đánh dấu định danh là DEPRECATED; ghi lý do, ngày ghi nhận và hướng dẫn tham chiếu thay thế nếu có.	Giữ nguyên ID, tên tại thời điểm ghi nhận, loại artifact, đường dẫn đã đăng ký, version lịch sử và liên kết truy vết.
Nội dung được thay bằng một artifact hoặc requirement có phạm vi kế thừa được xác định	Tạo record định danh mới; liên kết record cũ với record mới bằng quan hệ superseded_by. Record mới phải liên kết ngược bằng supersedes.	Chuyển record cũ sang SUPERSEDED; không xóa record, không tái dùng ID và không chuyển các liên kết lịch sử sang ID mới.
Artifact không còn thuộc phạm vi corpus nhưng cần được kiểm toán lịch sử	Ghi lý do loại bỏ khỏi sử dụng hiện hành và trạng thái phù hợp; giữ record trong registry lịch sử.	Không được cấp lại cho artifact, requirement, rule, test case hoặc tài liệu khác.
Phát hiện ID cũ được tham chiếu trong artifact đã phát hành nội bộ của corpus	Giữ tham chiếu cũ như bằng chứng lịch sử; bổ sung liên kết tới ID thay thế tại registry hoặc tại phiên bản cập nhật của artifact khi phù hợp.	Không sửa ngầm ID cũ trong lịch sử phiên bản để tạo cảm giác rằng ID mới đã tồn tại từ trước.

Mỗi record DEPRECATED hoặc SUPERSEDED phải lưu tối thiểu các trường sau để tái dựng lịch sử: ID cũ; trạng thái trước và sau thay đổi; ngày ghi nhận theo Asia/Ho_Chi_Minh; version registry ghi nhận thay đổi; lý do cụ thể; ID kế nhiệm nếu có; đường dẫn artifact tại thời điểm thay đổi; các ID traceability đang liên kết; và người ghi nhận theo vai trò quản trị. Nếu chưa có ID kế nhiệm, trường kế nhiệm ghi Không có; không được suy diễn một định danh thay thế.

Quy tắc bảo toàn lịch sử	Diễn giải áp dụng
Không ghi đè nghĩa lịch sử	Mô tả ban đầu, phân loại nguồn và phạm vi đã ghi của ID cũ phải được giữ trong record lịch sử. Bản mô tả hiện hành có thể bổ sung lý do khấu hao hoặc thay thế, nhưng không được viết lại để thay đổi ý nghĩa quá khứ.
Không chuyển dịch liên kết quá khứ	Liên kết từ artifact phiên bản cũ đến ID cũ vẫn là liên kết hợp lệ của phiên bản đó. ID mới chỉ được dùng bởi artifact hoặc phiên bản được cập nhật sau khi quan hệ thay thế được ghi nhận.
Không biến khấu hao thành xóa bỏ	DEPRECATED không đồng nghĩa với không hợp lệ, không tồn tại hoặc được phép tái cấp. ID vẫn có thể được đọc trong các artifact lịch sử và phục vụ audit truy vết.
Thay thế phải rõ phạm vi	Quan hệ supersedes chỉ hợp lệ khi record mới nêu rõ phạm vi nào được kế thừa. Không được gộp nhiều ID cũ vào một ID mới nếu không thể xác định từng liên kết kế thừa.
Không suy diễn hiệu lực nghiệp vụ	Việc ghi nhận khấu hao hoặc thay thế tại IN_REVIEW, v0.9.0 không là approval, baseline, xác nhận yêu cầu Nova Foods hoặc quyết định triển khai production.

Ví dụ hợp lệ: CHAPTER_MANIFEST tiếp tục được giữ làm ID lịch sử cho /01-curriculum/CHAPTER_MANIFEST.md; nếu một artifact kế nhiệm được đăng ký cho phạm vi quản trị khác, record mới phải có ID riêng và ghi rõ supersedes: CHAPTER_MANIFEST chỉ khi phạm vi kế thừa được xác định. Record CHAPTER_MANIFEST vẫn lưu đường dẫn, trạng thái IN_REVIEW, version v0.9.0 và ngày 2026-08-07 đã ghi nhận.

Ví dụ không hợp lệ: xóa TEMPLATE_MANIFEST khỏi registry rồi dùng lại ID này cho một artifact có mục đích khác; hoặc sửa trực tiếp các liên kết lịch sử để khiến các artifact cũ dường như đã luôn tham chiếu đến ID kế nhiệm. Cả hai hành vi làm mất chuỗi bằng chứng, phá vỡ khả năng đối chiếu theo thời gian và bị cấm trong corpus mô phỏng Nova Foods.

Cấm tái sử dụng định danh khác nghĩa

Một định danh đã xuất hiện trong corpus Nova Foods, dù chỉ trong bản nháp IN_REVIEW, phải được coi là gắn vĩnh viễn với một nghĩa nghiệp vụ, một đối tượng được quản trị và một bối cảnh phân loại đã ghi nhận. Tái sử dụng không chỉ là cấp lại chuỗi ký tự giống nhau; việc giữ nguyên ID nhưng thay đối tượng, mục đích, phạm vi, chủ sở hữu nghiệp vụ hoặc liên kết nguồn cũng là tái sử dụng khác nghĩa và bị cấm.

Trường hợp	Quy tắc cấm tái sử dụng	Lý do kiểm soát
ID từng gắn với requirement	Không gắn ID đó cho requirement mới, kể cả requirement cũ bị loại bỏ khỏi bản đang soạn.	Liên kết tới acceptance criterion, test case, decision hoặc artifact lịch sử có thể bị hiểu sai.
ID từng gắn với business rule	Không dùng lại cho quy tắc khác, kể cả khi hai quy tắc có tên gần giống hoặc cùng domain Nova Foods.	Một rule có thể được tham chiếu bởi quy trình, dữ liệu, kiểm thử và tài liệu đào tạo.
ID từng gắn với data element	Không cấp lại cho trường dữ liệu khác khi data element cũ không còn dùng.	Làm sai lịch sử mapping, data validation và mô tả dữ liệu.
ID từng gắn với process, use case hoặc test artifact	Không đổi đối tượng nghiệp vụ rồi giữ ID cũ để “tiết kiệm số”.	ID phải bảo toàn khả năng phân biệt evidence theo thời gian.
ID bị gõ sai, tạo nhầm hoặc xuất hiện trong commit/draft	Không tái cấp cho nghĩa mới sau khi đã được ghi trong artifact được kiểm soát, bảng traceability hoặc lịch sử thay đổi.	Bản sao cục bộ, liên kết cũ hoặc bản review có thể còn tồn tại.
ID thuộc artifact đã xóa khỏi phạm vi	Không trả ID về kho số trống.	Xóa tệp không xóa lịch sử tham chiếu của corpus.

Việc cho rằng hai đối tượng “tương đương” không đủ điều kiện dùng lại ID. Kiểm tra nghĩa phải so sánh tối thiểu: loại đối tượng, domain, mục tiêu nghiệp vụ, phạm vi áp dụng, điều kiện kích hoạt, dữ liệu liên quan và các liên kết traceability đã tồn tại. Nếu bất kỳ thành phần nào thay đổi làm người đọc có thể hiểu ID đang chỉ một đối tượng khác, phải cấp ID mới theo family và cú pháp đã đăng ký; ID cũ vẫn chỉ được giữ để truy vết đối tượng ban đầu.

Ví dụ mô phỏng	Kết luận	Căn cứ
Một ID rule đã mô tả kiểm tra hạn dùng cho lô nguyên liệu được đề nghị dùng lại cho kiểm tra hạn dùng thành phẩm.	Không được phép.	Nguyên liệu và thành phẩm là hai đối tượng nghiệp vụ khác nhau, có traceability và ngữ cảnh vận hành khác nhau.
Một ID requirement đã bị loại khỏi nội dung draft được đề nghị cấp cho requirement về cảnh báo tồn kho thấp.	Không được phép.	Việc bị loại không làm ID trở thành số chưa từng được sử dụng.
Một ID data element từng biểu diễn ngày sản xuất được đề nghị dùng cho ngày hết hạn vì cùng kiểu dữ liệu ngày.	Không được phép.	Kiểu dữ liệu không xác định nghĩa dữ liệu; hai khái niệm có mục đích và quy tắc kiểm tra khác nhau.
Phát hiện một ID đã được ghi nhầm trong bảng nháp nhưng chưa có nội dung đối tượng đi kèm.	Không tự tái cấp.	Phải giữ record sự cố định danh và xử lý theo kiểm soát thay đổi của registry; không suy đoán ID là chưa sử dụng.

Không được dùng cách đổi tên hiển thị, sửa mô tả ngắn, chuyển tệp, đổi chapter hoặc thay đổi người sở hữu để che giấu việc tái sử dụng khác nghĩa. Tại v0.9.0, IN_REVIEW, quy tắc này là kiểm soát kế hoạch cho corpus mô phỏng Nova Foods Trading & Manufacturing, chỉ dùng dữ liệu tổng hợp; nó không xác nhận baseline, approval hoặc hiệu lực production.

Quy tắc cấm đổi tên định danh và tiêu chí cấp định danh mới khi artifact thay đổi tên

Định danh canonical là khóa nhận diện bền vững của một đối tượng truy vết, không phải nhãn trình bày có thể biên tập. Vì vậy, không được sửa chuỗi ID để làm cho ID “đẹp hơn”, khớp với tiêu đề mới, phản ánh cấu trúc thư mục mới hoặc thay thế thuật ngữ cũ. Ví dụ, CHAPTER_MANIFEST và TEMPLATE_MANIFEST phải giữ nguyên token ID đã đăng ký, kể cả khi tiêu đề hiển thị, mô tả hoặc vị trí tham chiếu của artifact được điều chỉnh.

Một artifact chỉ được giữ ID hiện hữu sau khi đổi tên nếu mục tiêu quản trị, phạm vi nội dung, loại artifact, đối tượng chịu trách nhiệm và ý nghĩa truy vết vẫn là cùng một đối tượng. Nếu thay đổi tên che giấu sự thay đổi về ý nghĩa, phạm vi quyết định, đối tượng nghiệp vụ hoặc loại deliverable, artifact mới phải nhận ID mới; artifact cũ được giữ nguyên như bằng chứng lịch sử và liên kết traceability không bị viết đè.

Tình huống đổi tên hoặc thay đổi	Có giữ ID hiện hữu?	Quy tắc bắt buộc
Sửa lỗi chính tả, chuẩn hóa viết hoa, hoặc dịch tiêu đề mà không đổi nội dung được quản trị	Có	Giữ ID, đường dẫn được kiểm soát và các liên kết traceability; ghi nhận thay đổi theo kiểm soát artifact áp dụng.
Làm rõ tiêu đề từ “Manifest Template” thành “Planned Template Manifest” trong khi vẫn quản lý cùng danh mục template	Có	TEMPLATE_MANIFEST vẫn là ID canonical; không tạo biến thể như TEMPLATE-MANIFEST-V2 chỉ vì tiêu đề được viết lại.
Đổi tên tệp chỉ để phù hợp quy ước thư mục, nhưng nội dung, phạm vi và quan hệ truy vết không đổi	Chỉ khi đường dẫn mới đã được kiểm soát	Không đổi ID. Tham chiếu cũ phải được cập nhật có truy vết; không được âm thầm để một ID trỏ đến hai tệp đang cùng hiệu lực.
Mở rộng một manifest thành tài liệu vừa quản lý template vừa quy định kiến trúc ERP	Không	Phải tạo artifact mới với ID mới, vì loại quyết định và phạm vi đã đổi; manifest cũ không được đổi tên để hấp thụ nội dung kiến trúc.
Tách một artifact thành hai artifact có mục đích độc lập	Không	Mỗi artifact hậu nhiệm nhận ID riêng; ID cũ vẫn giữ cho artifact lịch sử hoặc bản ghi quan hệ thay thế.
Gộp hai artifact có ID khác nhau thành một artifact mới	Không	Cấp một ID mới cho artifact gộp; không chọn một ID cũ rồi đổi tên để đại diện cho cả hai nghĩa trước đó.
Dùng lại ID của artifact đã không còn được soạn thảo cho một nội dung khác	Không	Cấm tuyệt đối. ID không bao giờ được gán lại cho nghĩa, phạm vi, tệp hoặc đối tượng Nova Foods khác.
Đổi tên để chuyển một giả định mô phỏng thành yêu cầu đã xác nhận	Không	Phải tạo artifact hoặc record mới có ID mới và giữ nhãn nguồn phù hợp; đổi tên không được biến Project assumption thành nội dung đã xác minh.

Kiểm tra quyết định trước khi đổi tên: người soạn phải trả lời đồng thời bốn câu hỏi: (1) đối tượng được quản lý có còn là cùng một đối tượng không; (2) mục đích và phạm vi có giữ nguyên không; (3) các liên kết inbound và outbound có còn diễn đạt cùng ý nghĩa không; và (4) nguồn, phân loại nguồn, giả định và nhãn Verification required có giữ nguyên hiệu lực không. Nếu bất kỳ câu trả lời nào là “không”, việc xử lý đúng là cấp ID mới thay vì đổi tên artifact cũ.

Ví dụ	Kết quả đúng	Kết quả bị cấm
Đổi tiêu đề /01-curriculum/CHAPTER_MANIFEST.md để làm rõ đây là manifest cho 26 handbook chapter, trong khi tập chapter và mục đích quản trị không đổi	Giữ CHAPTER_MANIFEST; duy trì filename canonical nếu không có thay đổi đường dẫn được kiểm soát.	Đổi ID thành HANDBOOK_CHAPTER_CATALOG chỉ để khớp tiêu đề mới.
Một tài liệu ban đầu chỉ lập kế hoạch template, sau đó được đề xuất bổ sung quy tắc thiết kế API	Giữ TEMPLATE_MANIFEST trong phạm vi template; tạo artifact mới, ID mới cho nội dung API nếu được đăng ký.	Đổi tên TEMPLATE_MANIFEST thành một manifest kiến trúc tổng quát và coi các trace link template cũ là trace link kiến trúc.
Một artifact yêu cầu riêng về truy xuất lô được tách thành yêu cầu truy xuất lô và yêu cầu quản lý hạn dùng	Giữ ID artifact ban đầu như record lịch sử; cấp hai ID mới cho hai đối tượng độc lập và liên kết rõ quan hệ tách.	Giữ một ID cũ cho yêu cầu hạn dùng rồi dùng lại ID đó cho yêu cầu truy xuất lô mới.

Không được dùng version, trạng thái IN_REVIEW, ngày 2026-08-07, hoặc việc thay đổi filename làm lý do đổi canonical ID. Các thuộc tính đó mô tả bản ghi quản trị tại thời điểm nhất định; chúng không thay thế danh tính bất biến của artifact.

Ví dụ chuyển trạng thái vòng đời được phép và bị cấm

Các ví dụ dưới đây minh họa cách ghi nhận trạng thái cho identifier đã có trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Chúng chỉ áp dụng cho corpus Nova Foods Trading & Manufacturing mô phỏng giáo dục, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07; không là baseline, approval hoặc xác nhận áp dụng production.

Tình huống	Identifier và trạng thái trước	Thao tác đề xuất	Kết quả hợp lệ	Đánh giá
Dự thảo yêu cầu mới về chặn xuất kho lô hết hạn	REQ-INV-014 — PROPOSED	Hoàn thiện mô tả, phạm vi và liên kết tới artifact dự kiến	REQ-INV-014 chuyển PROPOSED → RESERVED; số ID và nghĩa vụ nghiệp vụ chưa đổi	Được phép
Đề cương học phần đã được đưa vào tập artifact đang soạn	CH-12 — RESERVED	Bắt đầu sử dụng ID trong đúng chapter đã đăng ký	CH-12 chuyển RESERVED → ACTIVE; không tạo ID thứ hai cho cùng chapter	Được phép
Quy tắc tính giá trị tồn kho được thay bằng quy tắc có phạm vi khác	BR-INV-006 — ACTIVE	Giữ BR-INV-006 cho quy tắc cũ; tạo BR-INV-019 cho quy tắc mới; ghi liên hệ thay thế	BR-INV-006 chuyển ACTIVE → SUPERSEDED; BR-INV-019 trở thành ACTIVE	Được phép
Artifact không còn được dùng trong hướng dẫn hiện hành nhưng vẫn cần tham chiếu lịch sử	UC-ORD-003 — ACTIVE	Ngừng dùng cho nội dung mới, không có artifact thay thế trực tiếp	UC-ORD-003 chuyển ACTIVE → DEPRECATED; record, liên kết cũ và lịch sử vẫn được giữ	Được phép
Mã mẫu cũ bị rút khỏi corpus vì trùng lặp và không còn quan hệ tham chiếu cần duy trì	TMPL-QA-004 — RESERVED	Đóng mục đăng ký trước khi template được dùng	TMPL-QA-004 chuyển RESERVED → RETIRED; ID không được cấp lại	Được phép
Dùng lại ID yêu cầu cũ cho nghĩa vụ khác	REQ-INV-014 — DEPRECATED	Gán lại ID cho yêu cầu mới về kiểm kê kho	Không có chuyển trạng thái hợp lệ; yêu cầu mới phải nhận ID mới	Bị cấm
Đổi tên tệp /01-curriculum/CHAPTER_MANIFEST.md thành tài liệu có mục đích khác nhưng giữ CHAPTER_MANIFEST	CHAPTER_MANIFEST — ACTIVE	Thay đổi bản chất từ manifest chapter sang sổ quyết định	Không được đổi nghĩa identifier; artifact mới phải có identifier và filename canonical riêng	Bị cấm
Sửa nội dung diễn đạt của requirement nhưng không đổi chủ thể, kết quả, phạm vi hoặc liên kết nghiệp vụ	REQ-ORD-021 — ACTIVE	Chỉnh lỗi chính tả hoặc làm rõ câu chữ	Giữ REQ-ORD-021 ở ACTIVE; lịch sử phiên bản ghi nhận thay đổi biên tập	Được phép
Mở rộng requirement từ “tạo đơn hàng bán” sang đồng thời “tạo đơn hàng, lập hóa đơn và hạch toán”	REQ-ORD-021 — ACTIVE	Mở rộng đáng kể trách nhiệm và kết quả kiểm chứng	Không đổi tên để che giấu thay đổi nghĩa; giữ ID cũ cho nghĩa cũ hoặc chuyển SUPERSEDED, rồi tạo ID mới cho phạm vi mở rộng	Bị cấm nếu giữ nguyên ID cho nghĩa mới
Khôi phục ID đã retired để tránh thiếu số thứ tự	TC-INV-008 — RETIRED	Cấp lại cho test case mới về truy xuất lô	Không có chuyển trạng thái hợp lệ; test case mới phải nhận ID chưa từng được gán nghĩa	Bị cấm

Tiêu chí quyết định: được giữ identifier khi thay đổi chỉ là biên tập hoặc làm rõ mà không thay đổi ý nghĩa quản trị, đối tượng áp dụng, kết quả mong đợi, phạm vi nghiệp vụ hoặc quan hệ truy vết. Phải tạo identifier mới khi một trong các yếu tố đó đổi, kể cả khi tên hiển thị gần giống. Identifier DEPRECATED, SUPERSEDED và RETIRED vẫn là bằng chứng lịch sử; chúng không trở thành vùng số trống để tái phân bổ.

Cross-Artifact Relationship Rules, Traceability Links, and Reserved Range Governance

Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, quan hệ truy vết xác định lý do nghiệp vụ, nhu cầu cần đáp ứng, điều kiện có thể quan sát để đánh giá, và kiểm thử tạo bằng chứng. Quan hệ không làm thay đổi identifier của artifact nguồn hoặc artifact đích. Mọi ví dụ Nova Foods dưới đây là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Quan hệ bắt buộc	Artifact nguồn	Artifact đích	Bội số tối thiểu	Quy tắc ngữ nghĩa
derives-from	Business Need (BN)	Requirement (REQ)	Mỗi REQ phải liên kết ít nhất một BN; một BN có thể có nhiều REQ	REQ diễn đạt năng lực hoặc kết quả cần có để đáp ứng business need; không dùng liên kết này để thay thế quyết định ưu tiên hoặc phê duyệt.
is-accepted-by	Requirement (REQ)	Acceptance Criterion (AC)	Mỗi REQ có ít nhất một AC; mỗi AC thuộc đúng một REQ	AC phải mô tả điều kiện quan sát được, đầu vào hoặc bối cảnh, và kết quả mong đợi để xác định requirement được đáp ứng trong phạm vi mô phỏng.
is-verified-by	Acceptance Criterion (AC)	Test Case (TC)	Mỗi AC có ít nhất một TC; một TC có thể kiểm tra nhiều AC khi cùng tiền điều kiện và kết quả kỳ vọng	TC phải kiểm tra được kết quả của AC; không được chỉ liên kết tới requirement ở mức tổng quát mà thiếu AC là test basis.

Quy tắc tạo và đọc chuỗi truy vết

1. Chuỗi tối thiểu là BN → REQ → AC → TC. Mỗi mũi tên phải được ghi bằng identifier đầy đủ của hai đầu mối, loại quan hệ và trạng thái liên kết.
2. BN trả lời câu hỏi “vì sao Nova Foods cần thay đổi”; REQ trả lời “hệ thống hoặc quy trình mô phỏng cần làm gì”; AC trả lời “điều kiện nào chứng minh requirement được đáp ứng”; TC trả lời “kiểm tra điều kiện đó bằng bước và kết quả nào”.
3. Một AC không được tự tạo phạm vi nghiệp vụ mới vượt ngoài REQ cha. Nếu phát hiện điều kiện cần kiểm tra nhưng không suy ra từ REQ, phải tạo hoặc điều chỉnh requirement theo kiểm soát thay đổi phù hợp trước khi liên kết test.
4. Một TC có thể tái sử dụng cho nhiều AC chỉ khi từng AC có kết quả kỳ vọng được kiểm tra trực tiếp bởi cùng tập bước kiểm thử. Việc cùng thuộc module, cùng màn hình hoặc cùng chủ đề không đủ điều kiện tái sử dụng.
5. Liên kết phải dùng identifier canonical, không dùng tiêu đề tự do, số thứ tự dòng, tên màn hình hoặc đường dẫn tạm làm khóa truy vết.

Ví dụ quan hệ	Đánh giá	Lý do
BN-ORD-001 derives-from → REQ-ORD-021; REQ-ORD-021 is-accepted-by → AC-ORD-021-01; AC-ORD-021-01 is-verified-by → TC-ORD-021-01	Đúng	Chuỗi phân biệt rõ mục tiêu nghiệp vụ, requirement, điều kiện chấp nhận và test case.
REQ-ORD-021 is-accepted-by → AC-ORD-021-01; AC-ORD-021-01 is-verified-by → TC-INV-008	Chỉ hợp lệ khi có bằng chứng phạm vi	TC-INV-008 chỉ được dùng nếu bước kiểm thử và kết quả kỳ vọng thực sự kiểm tra AC-ORD-021-01; tiền tố khác không tự làm liên kết sai hoặc đúng.
BN-ORD-001 is-verified-by → TC-ORD-021-01 nhưng không có REQ và AC trung gian	Sai	Test case không cung cấp acceptance basis có thể quan sát cho business need; chuỗi không chứng minh requirement nào được đáp ứng.
REQ-ORD-021 is-verified-by → TC-ORD-021-01 nhưng không có AC	Sai	Thiếu điều kiện chấp nhận làm test basis; không thể xác định đầy đủ kết quả nào của requirement đang được kiểm tra.
AC-ORD-021-01 nêu thêm yêu cầu lập hóa đơn khi REQ-ORD-021 chỉ giới hạn tạo đơn hàng	Sai	Acceptance criterion đã mở rộng nghĩa của requirement; nội dung lập hóa đơn cần requirement riêng và chuỗi truy vết riêng.

Ràng buộc chất lượng truy vết: không chấp nhận liên kết rỗng, liên kết một chiều không có identifier đích, hoặc quan hệ mà tên loại không phản ánh đúng ngữ nghĩa trên. Khi một REQ có nhiều AC, tập AC phải bao phủ các kết quả nghiệp vụ quan trọng, ngoại lệ và giới hạn đã nêu trong requirement; khi một AC có nhiều TC, từng test case phải thể hiện phần điều kiện, dữ liệu hoặc biến thể mà nó kiểm tra. Các quan hệ này phục vụ kiểm soát nội dung của corpus Nova Foods, không phải bằng chứng phê duyệt người dùng, xác nhận compliance hoặc sẵn sàng production.

Quy tắc liên kết truy vết giữa chapter, template, registry và QA artifact

Liên kết truy vết phải được ghi bằng định danh chuẩn đã đăng ký, không dùng tiêu đề tự do, số dòng, liên kết đến bản sao cục bộ hoặc mô tả như “yêu cầu phía trên”. Mục tiêu là cho phép một reviewer đi từ nội dung học tập trong chapter đến template áp dụng, nguồn định danh canonical và bằng chứng QA mà không suy diễn quan hệ.

Artifact nguồn	Artifact đích được phép	Loại liên kết bắt buộc	Nội dung tối thiểu phải ghi
Chapter file thuộc danh mục /01-curriculum/CHAPTER_MANIFEST.md	Template file thuộc danh mục /01-curriculum/TEMPLATE_MANIFEST.md	uses-template	Đường dẫn template được kiểm soát, Template ID đã đăng ký và mục đích sử dụng trong chapter.
Chapter file	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	uses-identifier-rule	Identifier family áp dụng, ID cụ thể nếu đã được cấp, và quy tắc cú pháp được tham chiếu.
Template file	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	allocates-or-validates-identifier	Trường ID của template, family ID được phép nhận và điều kiện kiểm tra định dạng.
Chapter file hoặc template file	QA artifact	verified-by hoặc reviewed-by	ID của nội dung được kiểm tra, expected result có thể quan sát, QA artifact ID và loại evidence cần lưu.
QA artifact	Chapter file, template file hoặc canonical registry	test-basis	Đường dẫn nguồn được kiểm tra, version đang kiểm tra, ID requirement/rule/criterion liên quan và trạng thái thực tế của evidence.
/01-curriculum/CHAPTER_MANIFEST.md	Chapter file trong phạm vi manifest	catalogues	Filename đúng như manifest, Chapter ID nếu đã được manifest đăng ký, và vị trí chapter trong tập 00 đến 25.
/01-curriculum/TEMPLATE_MANIFEST.md	Template file trong phạm vi manifest	catalogues	Filename đúng như manifest, Template ID đã đăng ký, mục đích template và dependency được manifest chỉ định.

Quy tắc ghi liên kết

1. /01-curriculum/TRACEABILITY_ID_REGISTRY.md là nguồn kiểm soát cho quy tắc định danh; chapter, template và QA artifact chỉ được tham chiếu hoặc sử dụng family/ID đã đăng ký. Một artifact không được tự tạo ID mới rồi coi đó là canonical chỉ vì ID đã xuất hiện trong nội dung.
2. /01-curriculum/CHAPTER_MANIFEST.md là nguồn kiểm soát danh mục chapter và filename chapter. Liên kết từ QA artifact đến chapter phải dùng đúng đường dẫn file đã được manifest kiểm soát, không dùng tên hiển thị rút gọn hoặc tên file tự dịch.
3. /01-curriculum/TEMPLATE_MANIFEST.md là nguồn kiểm soát danh mục template dự kiến. Khi chapter hướng dẫn learner sử dụng template, chapter phải nêu rõ template nào là đầu vào; không được thay thế bằng một biểu mẫu có tên tương tự nhưng không có trong manifest.
4. QA artifact phải xác định test basis là nội dung cụ thể: ID, đường dẫn artifact, version và tiêu chí kết quả. Liên kết chỉ ghi “đã kiểm tra chapter” không đủ vì không xác định được đối tượng, điều kiện hay evidence.
5. Mỗi liên kết phải có hướng và ngữ nghĩa rõ ràng. uses-template không đồng nghĩa verified-by; catalogues không đồng nghĩa approves; reviewed-by không đồng nghĩa BASELINED hoặc APPROVED.
6. URL nguồn bên ngoài chỉ được giữ ở artifact nguồn hoặc bảng tham chiếu phù hợp; không được biến URL thành thay thế cho ID nội bộ. Với nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật chưa được xác minh đầy đủ, artifact liên kết phải giữ nhãn Verification required hoặc Project assumption.
7. Mọi ví dụ Nova Foods Trading & Manufacturing trong chapter, template hoặc QA artifact chỉ dùng dữ liệu tổng hợp. Liên kết traceability chứng minh quan hệ tài liệu trong corpus giáo dục, không chứng minh cấu hình ERP thực tế, kết quả kiểm thử production hay sự chấp thuận của người dùng.

Tình huống	Liên kết đúng	Liên kết không đúng	Lý do
Chapter hướng dẫn lập requirement	Chapter tham chiếu template đã được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md, đồng thời nêu family ID theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Chapter tự chèn một “Requirement Form” không có filename, Template ID hoặc nguồn manifest.	Không thể kiểm tra template nào là bản được kiểm soát và ID nào áp dụng.
QA kiểm tra một trường ID trong template	QA artifact ghi test basis gồm đường dẫn template, trường ID, family ID theo registry và expected result định dạng hợp lệ.	QA artifact ghi “ID đúng” mà không nêu template, family hoặc kết quả mong đợi.	Evidence không tái lập được và không xác định được quy tắc đã kiểm tra.
Kiểm tra tính nhất quán chapter-template	QA artifact liên kết tới chapter file, template file và registry như ba nguồn riêng biệt.	QA artifact chỉ liên kết tới chapter rồi suy ra template và quy tắc ID từ nội dung diễn giải.	Nguồn danh mục template và nguồn quy tắc định danh bị mất khỏi chuỗi truy vết.

Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, các liên kết trên là liên kết quản trị đang được xem xét. Chúng không xác nhận baseline, approval, tính đúng chuyên môn, tuân thủ pháp luật hoặc mức sẵn sàng production của bất kỳ chapter, template, canonical registry hay QA artifact nào.

Quản trị dải số dự phòng theo miền và họ định danh

Dải dự phòng là tập số hậu tố được khóa cho một mục đích xác định nhưng chưa được cấp ID cho artifact cụ thể. Việc dự phòng ngăn các nhóm soạn thảo dùng cùng một số cho các lớp artifact khác nhau, đồng thời giữ chỗ cho mở rộng có kiểm soát. Tại IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, mọi dải dưới đây áp dụng cho corpus Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh.

Miền/họ ID	Dải vận hành thông thường	Dải dự phòng có kiểm soát	Dải không được dùng	Quy tắc quản trị dải
BN — Business Need	001–699	700–899	900–999	700–899 chỉ mở khi phát sinh nhóm nhu cầu nghiệp vụ mới ngoài phạm vi đang lập kế hoạch; 900–999 dành cho xử lý xung đột registry, không được cấp trong drafting.
BR — Business Rule	001–699	700–899	900–999	Không dùng số BR để biểu thị requirement, acceptance criterion hoặc test case, dù nội dung cùng chủ đề.
FR — Functional Requirement	001–699	700–899	900–999	Dải dự phòng phục vụ chức năng Nova Foods chưa được phân rã; không được dùng để hợp thức hóa requirement chưa rõ owner hoặc chưa rõ phạm vi.
NFR — Non-functional Requirement	001–699	700–899	900–999	Mỗi số chỉ đại diện một requirement phi chức năng riêng; không tái sử dụng số của FR, kể cả khi cùng capability.
AC — Acceptance Criterion	001–699	700–899	900–999	Dải AC độc lập với FR và NFR; không tạo ID ghép bằng cách sao chép số hậu tố của requirement.
TC — Test Case	001–699	700–899	900–999	Dải dự phòng dành cho test case được lập kế hoạch nhưng chưa đủ test basis; không được dùng làm mã lỗi, mã defect hoặc mã evidence.
DM — Data Model / Data Dictionary item	001–699	700–899	900–999	Dùng cho thực thể, thuộc tính hoặc cấu trúc dữ liệu theo quy tắc cú pháp đã đăng ký; không dùng làm mã lô, mã hàng hóa hoặc dữ liệu ERP mô phỏng.
API — API contract item	001–699	700–899	900–999	Không dùng số API làm version OpenAPI, HTTP status code, endpoint path hoặc mã tích hợp.
CH — Handbook chapter	00–25	26–99	100–999	00–25 bị giới hạn bởi 26 tệp trong /01-curriculum/CHAPTER_MANIFEST.md, từ 00-foundations.md đến 25-ai-assisted-ba-workflow.md; dải 26–99 không tự cho phép tạo chapter thứ 27.
TMPL — Template artifact	001–699	700–899	900–999	Chỉ dùng cho template được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md; không cấp số template cho chapter hoặc canonical registry.
CR — Change Record	001–699	700–899	900–999	Mỗi record thay đổi nhận một số không tái sử dụng; số đã hủy hoặc nhập nhầm vẫn phải được giữ lại trong registry với trạng thái phù hợp.
QA — QA artifact/evidence item	001–699	700–899	900–999	Không dùng dải này thay cho TC; QA chỉ định danh artifact QA độc lập, không định danh bước kiểm thử.

Quy tắc cấp và bảo vệ dải số

1. Hậu tố số có độ dài ba chữ số cho mọi họ trừ CH, vì CH sử dụng chỉ mục hai chữ số đã bị ràng buộc bởi bộ tên tệp chapter. Ví dụ hợp lệ về hình thức: FR-042, AC-042, TC-042; ba ID này khác nhau vì khác tiền tố, nhưng không được suy luận rằng chúng có quan hệ nội dung chỉ từ cùng hậu tố.
2. Một số trong dải vận hành chỉ được ghi vào canonical registry sau khi kiểm tra rằng cặp {tiền tố, hậu tố} chưa tồn tại, chưa bị hủy và chưa nằm trong dải dự phòng hoặc dải không được dùng.
3. Dải 700–899 không phải kho số dùng tự do. Người duy trì registry phải ghi lý do mở dải, họ ID, số đầu và số cuối được mở, tác động đến khả năng mở rộng và reference đến change record trước khi cấp bất kỳ số nào trong dải này.
4. Dải 900–999 là vùng cách ly quản trị. Không artifact nghiệp vụ, kỹ thuật, QA, chapter hoặc template nào được mang ID thuộc vùng này. Nếu phát hiện ID thuộc vùng này trong bản nháp, phải coi đó là lỗi registry và thay bằng số hợp lệ mới; không đổi nghĩa của ID bị lỗi để giữ số.
5. Số đã được cấp không được chuyển từ họ này sang họ khác. Ví dụ, BR-118 không thể được đổi thành FR-118 chỉ để đồng bộ đánh số; BR-118 phải giữ lịch sử riêng, còn FR-118 chỉ được tạo nếu chưa tồn tại trong họ FR.
6. Không dùng dải ID kiểm soát làm dữ liệu nghiệp vụ Nova Foods. Các giá trị như mã sản phẩm, mã nhà cung cấp, số đơn hàng, mã lô, mã kho, số hóa đơn hoặc số tiền VND mô phỏng phải thuộc mô hình dữ liệu và quy tắc dữ liệu riêng, không thuộc registry này.
7. Khi một dải thông thường đạt số cuối 699, việc mở dải dự phòng phải được ghi nhận trước khi tạo ID tiếp theo. Không được quay lại số đã hủy, dùng lại số của artifact đã thay thế, hoặc tự tạo tiền tố mới để tránh kiểm soát dải.

Quy tắc ngăn va chạm định danh giữa các lớp artifact được kiểm soát

Mỗi định danh canonical trong corpus Nova Foods phải nhận diện một bản ghi thuộc đúng một lớp artifact. Va chạm không chỉ là hai chuỗi ký tự giống nhau; va chạm cũng xảy ra khi một ID được dùng lại với ý nghĩa, loại đối tượng, nguồn quản trị hoặc vòng đời khác. Quy tắc này áp dụng tại IN_REVIEW, v0.9.0, ngày 2026-08-07, cho dữ liệu mô phỏng giáo dục của Nova Foods Trading & Manufacturing.

Lớp artifact được kiểm soát	Phạm vi định danh riêng	Không được dùng chung ID với
Business need	Nhu cầu, mục tiêu hoặc vấn đề nghiệp vụ cần giải quyết	Requirement, business rule, acceptance criterion, test case và change record
Requirement	Yêu cầu chức năng, phi chức năng hoặc ràng buộc được quản lý	Business need, rule, data element, API operation, test case và chapter
Business rule	Quy tắc nghiệp vụ canonical trong CANONICAL_BUSINESS_RULES.md	Requirement, acceptance criterion, test case, data entity và change record
Acceptance criterion	Điều kiện quan sát hoặc kiểm tra được cho một requirement	Requirement, business rule, test case và QA evidence
Test case và QA evidence	Kịch bản kiểm thử hoặc bằng chứng kiểm tra	Acceptance criterion, requirement, business rule, API operation và chapter
Data model và data dictionary	Entity, attribute, code set hoặc data definition canonical trong CANONICAL_DATA_DICTIONARY.md	Requirement, business rule, API operation, test case và filename chapter
API artifact	API, operation, schema hoặc contract API	Data element, requirement, business rule, test case và change record
Handbook chapter và template	Artifact đào tạo được nhận diện bằng filename/Artifact ID đã đăng ký	Canonical requirement, rule, test, data hoặc API ID
Change record	Bản ghi thay đổi có kiểm soát	ID của đối tượng bị thay đổi; change record không thay thế đối tượng gốc

Quy tắc bắt buộc

1. Chỉ TRACEABILITY_ID_REGISTRY.md được quyền xác lập hoặc giữ chỗ một ID canonical. Một artifact khác có thể tham chiếu ID đã đăng ký nhưng không được tự tạo biến thể, đổi tiền tố, bỏ tiền tố hoặc tái sử dụng số thứ tự.
2. Cặp khóa kiểm soát tối thiểu là artifact class + canonical ID, nhưng chuỗi canonical ID vẫn phải duy nhất trên toàn corpus. Vì vậy, một chuỗi đã thuộc lớp business rule không được cấp lại cho requirement, test case hoặc bất kỳ lớp nào khác.
3. Artifact ID của manifest như CHAPTER_MANIFEST và TEMPLATE_MANIFEST là định danh artifact quản trị; chúng không được dùng làm requirement ID, rule ID, test ID, API ID hoặc data ID.
4. Filename được kiểm soát, gồm /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md, là khóa định vị tệp. Không được dùng filename, tên không phần mở rộng, hoặc chỉ mục chapter làm canonical ID cho đối tượng nghiệp vụ hay kỹ thuật.
5. Không được tạo “ID tiện dụng” trong bảng, sơ đồ, ví dụ đào tạo hoặc tên test nếu chuỗi đó có thể bị hiểu là ID canonical. Khi cần minh họa chưa đăng ký, phải dùng mô tả văn bản như “requirement đang dự kiến” thay vì một mã có hình thức như mã chính thức.
6. Đổi loại artifact không được thực hiện bằng cách giữ nguyên ID. Ví dụ, nếu một nội dung ban đầu được quản lý là business need nhưng sau đó được tách thành requirement, business need giữ ID riêng; requirement nhận ID riêng theo family đã đăng ký. Việc đổi tên tệp, đổi tiêu đề hoặc đổi owner không làm thay đổi lớp ID.
7. Các hậu tố phiên bản như v0.9.0, trạng thái như IN_REVIEW, ngày 2026-08-07 và nhãn Project assumption hoặc Verification required là metadata, không phải phần mở rộng hợp lệ để tạo một ID mới. Không được coi một-ID-v0.9.0 là đối tượng khác với một-ID nếu ID gốc đã tồn tại.
8. Khi phát hiện trùng chuỗi, trùng ý nghĩa hoặc trùng đối tượng giữa hai lớp, người soạn phải dừng việc cấp mới, giữ nguyên bản ghi có trước trong registry và ghi nhận xung đột để xử lý theo kiểm soát thay đổi. Không được tự xóa, đổi số, hoặc chuyển ID đã xuất hiện trong artifact được kiểm soát.
9. Kiểm tra va chạm phải so sánh không phân biệt cách trình bày có thể gây nhầm lẫn: khác chữ hoa/chữ thường, khoảng trắng thừa, dấu gạch nối thay thế, tiền tố bị rút gọn và ID được chép vào filename hoặc nhãn sơ đồ. Mục tiêu là bảo đảm một người đọc hoặc công cụ truy vết không thể ánh xạ cùng một chuỗi sang hai đối tượng khác nhau.
10. Tên Nova Foods trong ví dụ, như tên sản phẩm, lô hàng hoặc quy trình mô phỏng, không tự trở thành ID canonical. Chúng chỉ được dùng làm dữ liệu tổng hợp khi không trùng với định danh đã đăng ký và không suy diễn cấu hình ERP thực tế.

Ví dụ quan hệ liên artifact đúng và không đúng

Ví dụ dưới đây minh họa cách đọc liên kết truy vết trong corpus Nova Foods Trading & Manufacturing. Mọi ID được nêu theo lớp định danh chỉ hợp lệ khi đã có bản ghi tương ứng trong canonical registry; không được tạo ID mới chỉ để làm cho liên kết có vẻ đầy đủ. Case study chỉ dùng dữ liệu tổng hợp, Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07.

Tình huống	Quan hệ đúng	Quan hệ không đúng	Lý do kiểm soát
Business need đến requirement	Một business need đã đăng ký được liên kết tới một hoặc nhiều requirement diễn giải phạm vi, kết quả mong đợi hoặc ràng buộc có thể kiểm tra.	Gắn trực tiếp business need vào test case mà không có requirement trung gian.	Test case cần test basis cụ thể; business need thường quá khái quát để xác định điều kiện kiểm thử.
Requirement đến acceptance criterion	Một requirement có liên kết tới một hoặc nhiều acceptance criterion quan sát được, chẳng hạn kết quả xử lý lô hàng, cảnh báo hạn dùng, hoặc điều kiện từ chối dữ liệu đầu vào trong mô phỏng Nova Foods.	Acceptance criterion chỉ ghi “hệ thống hoạt động đúng” hoặc liên kết tới requirement thuộc chủ đề không liên quan.	Tiêu chí không quan sát được hoặc sai ngữ cảnh không thể chứng minh requirement đã được đáp ứng.
Acceptance criterion đến test case	Mỗi acceptance criterion có ít nhất một test case tham chiếu chính xác ID acceptance criterion đó và nêu dữ liệu tổng hợp, bước thực hiện, kết quả mong đợi.	Một test case kiểm tra tạo đơn bán hàng nhưng được dùng làm bằng chứng duy nhất cho acceptance criterion về truy xuất lô nguyên liệu.	Đối tượng kiểm tra, hành vi và evidence không cùng phạm vi. Liên kết tồn tại về hình thức nhưng không có giá trị truy vết.
Business rule đến requirement	Requirement về kiểm soát tồn kho có thể tham chiếu business rule đã đăng ký trong CANONICAL_BUSINESS_RULES.md khi rule là nguồn ràng buộc nghiệp vụ của requirement.	Sao chép nội dung rule vào requirement rồi bỏ ID business rule hoặc tham chiếu một rule chưa có trong canonical registry.	Mất nguồn chuẩn, tạo nguy cơ hai bản diễn giải khác nhau của cùng một quy tắc.
Data element đến API	Trường API mô phỏng có thể tham chiếu data element đã đăng ký trong CANONICAL_DATA_DICTIONARY.md; mô tả API không tự đổi nghĩa, kiểu dữ liệu hoặc miền giá trị của data element.	Một API dùng cùng tên trường nhưng tự định nghĩa khác nghĩa với data dictionary, ví dụ cùng biểu thị mã lô nhưng một nơi coi là mã duy nhất toàn cục và nơi khác coi là mã tùy ý.	Trùng tên không chứng minh cùng ngữ nghĩa; mâu thuẫn sẽ làm sai mapping và kiểm thử tích hợp.
Chapter đến canonical registry	Nội dung tại 00-foundations.md có thể dẫn chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md để hướng dẫn người học tra quy tắc ID chuẩn.	Chapter tự công bố một quy tắc đặt ID khác với registry hoặc dùng filename biến thể không có trong CHAPTER_MANIFEST.md.	Chapter là nơi sử dụng và giải thích; registry và manifest là nguồn kiểm soát định danh, không được bị thay thế bởi bản sao cục bộ.
Template đến manifest	Template được lập kế hoạch phải tham chiếu /01-curriculum/TEMPLATE_MANIFEST.md và, khi áp dụng cho chapter, đối chiếu /01-curriculum/CHAPTER_MANIFEST.md.	Một template ghi liên kết đến chapter không thuộc danh mục manifest hoặc tự đổi đường dẫn tệp đã kiểm soát.	Quan hệ phải nối các artifact đã được nhận diện; đường dẫn suy đoán tạo artifact “mồ côi” ngoài phạm vi corpus.
QA artifact đến nguồn kiểm tra	QA artifact liên kết test case với acceptance criterion, requirement và evidence tương ứng; mỗi liên kết phải trỏ đến ID nguồn có tồn tại.	QA artifact chỉ ghi “đã kiểm tra” mà không nêu test basis, hoặc trỏ tới một tiêu đề văn bản thay vì ID canonical.	Không thể tái kiểm tra, đánh giá tác động hoặc phân biệt kết quả kiểm thử với nhận xét không cấu trúc.

Mẫu đánh giá nhanh: một quan hệ được xem là đúng khi người rà soát có thể trả lời đồng thời ba câu hỏi: (1) hai đầu liên kết có phải artifact hoặc ID đã đăng ký không; (2) quan hệ có diễn tả đúng hướng nghiệp vụ hoặc kỹ thuật không; và (3) đầu đích có đủ chi tiết để kiểm tra hoặc tra cứu mà không phải suy đoán không. Nếu bất kỳ câu trả lời nào là “không”, liên kết phải được ghi nhận là không hợp lệ trong phạm vi review; không được suy diễn approval, baseline, tuân thủ pháp lý hoặc mức sẵn sàng production từ việc liên kết đã được tạo.

Ràng buộc quan hệ giữa mục đã có baseline và mục bản nháp

Một liên kết truy vết chỉ ổn định khi xác định được hai đầu liên kết, phiên bản áp dụng và trạng thái kiểm soát của từng đầu. Vì vậy, quan hệ có mục đã có baseline không được bị thay đổi ngầm bởi nội dung IN_REVIEW; ngược lại, quan hệ giữa các mục bản nháp chỉ là đề xuất để review và chưa là bằng chứng hoàn tất, chấp thuận hoặc sẵn sàng sử dụng.

Tại ngày 2026-08-07, phiên bản v0.9.0, các artifact nguồn đã biết gồm /01-curriculum/CHAPTER_MANIFEST.md (CHAPTER_MANIFEST) và /01-curriculum/TEMPLATE_MANIFEST.md (TEMPLATE_MANIFEST) đều có trạng thái IN_REVIEW và chưa có baseline reference. Do đó, mọi liên kết được lập từ hai artifact này tại thời điểm hiện tại phải được phân loại là liên kết bản nháp.

Tình trạng đầu nguồn	Tình trạng đầu đích	Ràng buộc quan hệ bắt buộc	Diễn giải kiểm soát
Bản nháp	Bản nháp	Được phép tạo liên kết đề xuất nếu mỗi đầu liên kết giữ ID, đường dẫn tệp và phiên bản đang review.	Liên kết chỉ phục vụ phân tích, drafting hoặc review; không chứng minh coverage, hoàn tất kiểm thử hay hiệu lực nghiệp vụ.
Bản nháp	Đã có baseline	Được phép tham chiếu mục đã baseline theo đúng ID và baseline reference của đầu đích.	Bản nháp không được sửa nội dung, diễn giải lại, thay thế hoặc tuyên bố đã kế thừa hiệu lực của mục baseline.
Đã có baseline	Bản nháp	Không được dùng bản nháp làm mục tiêu chính thức để thỏa mãn, xác minh, thay thế hoặc đóng một quan hệ của mục baseline.	Nếu cần đề xuất thay thế, phải giữ nguyên quan hệ baseline hiện hành và ghi nhận bản nháp là ứng viên thay đổi tách biệt.
Đã có baseline	Đã có baseline	Chỉ hợp lệ khi cả hai đầu nêu rõ ID, phiên bản hoặc baseline reference tương ứng và loại quan hệ không mâu thuẫn.	Không được trỏ tới “phiên bản mới nhất” không xác định, vì điều đó làm thay đổi ý nghĩa liên kết khi tài liệu được cập nhật.

Mỗi quan hệ liên quan đến baseline phải có tối thiểu các trường kiểm soát sau: source artifact ID, source version hoặc baseline reference, target artifact ID, target version hoặc baseline reference, relationship status và relationship purpose. Nếu thiếu một trong các trường này, liên kết không đủ điều kiện để được diễn giải là liên kết baseline.

Quy tắc	Áp dụng bắt buộc
Bất biến của đầu baseline	Không sửa ID, filename, phiên bản tham chiếu hoặc ý nghĩa quan hệ đã được ghi nhận cho mục baseline bằng cách sửa một artifact IN_REVIEW.
Tách biệt đề xuất thay đổi	Bản nháp có thể nêu quan hệ dự kiến mới, nhưng phải tách khỏi quan hệ baseline hiện hữu; không được ghi đè, xóa hoặc gắn nhãn thay thế cho liên kết baseline khi chưa có bằng chứng kiểm soát phù hợp.
Không suy diễn baseline	IN_REVIEW, tồn tại ID, có filename cố định, hoặc có liên kết tới CHAPTER_MANIFEST hay TEMPLATE_MANIFEST không tạo baseline reference.
Đồng bộ trạng thái	Một chuỗi truy vết chỉ được gọi là chuỗi baseline khi mọi liên kết dùng để chứng minh chuỗi đó đều tham chiếu các đầu đã có baseline reference tương ứng. Một đầu là bản nháp làm toàn bộ chuỗi ở mức đề xuất.
Không dùng bản nháp làm bằng chứng cuối	QA artifact, kết quả kiểm tra, tiêu chí chấp nhận hoặc nội dung chapter bản nháp không được được viện dẫn như bằng chứng đóng quan hệ của mục đã baseline.

Ví dụ đúng: Một nội dung bản nháp trong /01-curriculum/TEMPLATE_MANIFEST.md có thể tham chiếu CHAPTER_MANIFEST để xác định dependency lập kế hoạch, với trạng thái quan hệ là draft/proposed; liên kết này không tuyên bố CHAPTER_MANIFEST hoặc template đã baseline.

Ví dụ không đúng: Ghi rằng một mục trong TEMPLATE_MANIFEST “thay thế” quan hệ đã baseline của CHAPTER_MANIFEST chỉ vì mục template có phiên bản v0.9.0 hoặc đang IN_REVIEW. Cách ghi này sai vì không có baseline reference, không xác định được phiên bản baseline bị tác động, và biến đề xuất review thành thay đổi có hiệu lực.

Khi chưa có baseline reference được ghi nhận, corpus Nova Foods Trading & Manufacturing chỉ được xem là kế hoạch có kiểm soát cho mục đích giáo dục, sử dụng dữ liệu tổng hợp. Không liên kết nào trong trạng thái này được diễn giải là phê duyệt người dùng, xác nhận requirement, cam kết triển khai ERP hoặc bằng chứng phù hợp pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hay production.

Validation Procedure, Change-Control Procedure, Cross-File Checks, Self-Review, Open Issues, and Escalation

Quy trình xác thực định danh registry

Quy trình này kiểm tra một record định danh trước khi record đó được dùng làm liên kết truy vết trong corpus Nova Foods Trading & Manufacturing. Mục tiêu là chứng minh record tuân thủ quy tắc đã đăng ký về cú pháp, tính duy nhất, họ định danh và mã miền; quy trình không tạo baseline, không ghi nhận approval và không xác nhận yêu cầu nghiệp vụ hay cấu hình ERP.

Đầu vào bắt buộc: bản TRACEABILITY_ID_REGISTRY.md đang kiểm soát, record định danh cần kiểm tra, quy tắc cú pháp/regex của họ định danh tương ứng, và danh mục mã miền đã được phép. Việc kiểm tra thực hiện trên dữ liệu mô phỏng giáo dục, theo locale vi-VN, múi giờ Asia/Ho_Chi_Minh, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Thứ tự	Kiểm tra	Cách thực hiện và tiêu chí đạt	Kết quả lỗi phải ghi nhận
1	Tính hiện diện và chuẩn hóa	Xác nhận ID không rỗng, không chứa khoảng trắng đầu/cuối, ký tự điều khiển, xuống dòng hoặc ký tự phân cách không được phép. Giữ nguyên chữ hoa/chữ thường theo quy tắc của họ ID; không tự sửa ID trong khi kiểm tra.	SYNTAX_INVALID nếu thiếu giá trị hoặc chứa ký tự không hợp lệ.
2	Cú pháp và regex	Đối chiếu toàn bộ chuỗi ID với regex đã đăng ký cho đúng họ định danh. Kiểm tra tiền tố, dấu phân cách, số lượng phân đoạn, độ dài từng phân đoạn và quy tắc số thứ tự. Một khớp từng phần không đạt.	SYNTAX_INVALID nếu ID không khớp chính xác regex của họ đã khai báo.
3	Tư cách thành viên họ ID	Xác định tiền tố và cấu trúc ID có thuộc đúng một họ định danh trong registry hay không. Họ được chọn phải cho phép loại artifact hoặc quan hệ truy vết mà record biểu diễn.	FAMILY_UNKNOWN nếu không thuộc họ nào; FAMILY_MISMATCH nếu thuộc cấu trúc của họ khác với loại record khai báo.
4	Đúng mã miền	Tách mã miền từ vị trí được quy định trong ID, sau đó đối chiếu với danh mục mã miền được phép và nghĩa đã đóng băng của mã đó. Mã miền phải phù hợp với phạm vi nội dung của record, không chỉ hợp lệ về mặt ký tự.	DOMAIN_INVALID nếu mã chưa được đăng ký hoặc bị khóa; DOMAIN_MISMATCH nếu mã hợp lệ nhưng sai phạm vi nghiệp vụ/kỹ thuật.
5	Tính duy nhất	So sánh chuỗi ID đã chuẩn hóa với toàn bộ record đang hoạt động, reserved hoặc retired trong registry. Không được cấp lại ID retired, không được dùng một ID cho hai đối tượng khác nhau, và không được coi khác biệt chữ hoa/chữ thường là ID mới nếu họ ID quy định không phân biệt hoa thường.	DUPLICATE_ID nếu chuỗi đã tồn tại; REUSE_PROHIBITED nếu ID thuộc trạng thái không được cấp lại.
6	Nhất quán nội bộ record	Kiểm tra ID, tên họ, mã miền, mô tả, loại artifact và trạng thái lifecycle không mâu thuẫn nhau. Ví dụ, record khai báo thuộc một họ nhưng mô tả lại là đối tượng của họ khác là không đạt.	RECORD_INCONSISTENT nếu các trường cùng record diễn giải khác nhau.
7	Kết luận kiểm tra	Chỉ gắn kết quả PASS khi không có lỗi ở bước 1–6. Nếu có ít nhất một lỗi, kết quả là FAIL; record không được dùng để tạo liên kết truy vết mới cho đến khi lỗi được xử lý và kiểm tra lại.	Danh sách mã lỗi, ID được kiểm tra, thời điểm kiểm tra và người thực hiện kiểm tra.

Quy tắc quyết định và bằng chứng kiểm tra

Điều kiện phát hiện	Quyết định bắt buộc	Bằng chứng tối thiểu
ID khớp regex, duy nhất, đúng một họ và mã miền đúng phạm vi	PASS ở mức kiểm tra registry.	ID, họ ID, mã miền, phiên bản registry được kiểm tra, kết quả từng bước và thời điểm theo Asia/Ho_Chi_Minh.
ID hợp lệ về regex nhưng mã miền không có trong danh mục được phép	FAIL; không tự tạo mã miền thay thế.	Giá trị mã miền đã đối chiếu, danh mục mã miền dùng để kiểm tra và lỗi DOMAIN_INVALID.
ID trùng chuỗi với record tồn tại nhưng mô tả khác	FAIL; coi là xung đột định danh, không đổi mô tả để hợp thức hóa.	Hai record xung đột, trạng thái lifecycle của từng record và lỗi DUPLICATE_ID.
ID có tiền tố chưa được nhận diện hoặc khớp nhiều quy tắc họ	FAIL; không suy luận họ gần đúng.	Chuỗi ID, các quy tắc đã đối chiếu và lỗi FAMILY_UNKNOWN hoặc FAMILY_MISMATCH.
Không đủ dữ liệu để xác định phạm vi mã miền	FAIL ở mức kiểm tra phạm vi; giữ record trong phạm vi xem xét.	Mô tả thiếu, trường chưa nhất quán và lỗi DOMAIN_MISMATCH hoặc RECORD_INCONSISTENT.

Kết quả kiểm tra chỉ xác nhận tính toàn vẹn định danh theo registry tại thời điểm kiểm tra. Với IN_REVIEW và v0.9.0, kết quả PASS không đồng nghĩa ID đã được phê duyệt, đã baseline, đã được Business Owner xác nhận, hoặc đủ điều kiện sử dụng cho production.

Thủ tục kiểm soát thay đổi định danh

Mọi đề nghị thay đổi định danh trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md phải được xử lý như một thay đổi có truy vết, áp dụng cho trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh. Không được sửa đè ID đã công bố trong bản ghi lịch sử, tự đổi tên tệp được kiểm soát, hoặc dùng lại ID đã bị thay thế. Việc tồn tại của đề nghị, bản ghi review hoặc cập nhật dự thảo không tạo approval, baseline hay quyền sử dụng production.

Bước	Vai trò thực hiện	Đầu vào và nội dung bắt buộc	Kết quả kiểm soát
1. Đề xuất	Người phát hiện xung đột hoặc Owner artifact	Tạo bản ghi đề nghị thay đổi, nêu ID hiện tại, ID đề xuất, loại thay đổi, lý do, artifact bị ảnh hưởng, nguồn khởi phát, tác động traceability và phương án giữ liên kết lịch sử.	Đề nghị có tham chiếu duy nhất trong change log; chưa làm thay đổi registry.
2. Phân loại tác động	Principal IT Business Analyst / Technical Curriculum Author	Phân loại: sửa lỗi trình bày; đổi ID chưa được tham chiếu; thay thế ID đã có liên kết; đổi domain code; đổi tên tệp hoặc Artifact ID; thay đổi có liên quan pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật.	Xác định phạm vi review và các vai trò có thẩm quyền cần tham gia.
3. Rà soát đề xuất	Reviewer phù hợp với loại tác động	Đối chiếu lý do thay đổi với mục đích định danh, quyền sở hữu artifact, nguồn canonical và ranh giới dữ liệu tổng hợp của Nova Foods Trading & Manufacturing. Với nội dung chưa xác minh, giữ nhãn Verification required hoặc Project assumption.	Ý kiến review được ghi rõ là chấp nhận, yêu cầu sửa, hoặc không chấp nhận; không suy diễn approval từ ý kiến kỹ thuật.
4. Quyết định có thẩm quyền	Vai trò được phân công đúng phạm vi quyết định	Xem xét tác động đến định danh hiện hữu, liên kết ngược, lịch sử thay đổi và khả năng duy trì ID cũ làm tham chiếu superseded khi cần.	Quyết định phải ghi người quyết định, ngày, phạm vi, điều kiện hiệu lực và lý do. Nếu chưa có record quyết định, đề nghị vẫn ở trạng thái đang xem xét.
5. Cập nhật có kiểm soát	Owner artifact hoặc người được giao	Cập nhật registry và các artifact bị ảnh hưởng theo đúng quyết định; thêm lịch sử thay đổi mới, không thay thế record v0.9.0. ID cũ phải được giữ dưới dạng tham chiếu lịch sử khi đã từng được dùng.	Bản cập nhật dự thảo có dấu vết từ ID cũ đến ID mới hoặc đến quyết định không thay đổi.
6. Lan truyền	Owner của từng artifact đích	Lan truyền thay đổi sang các tham chiếu đã được quyết định là bị ảnh hưởng, gồm manifest, template, business rule, data dictionary, ma trận năng lực hoặc artifact khác có liên kết trực tiếp.	Mỗi cập nhật đích ghi tham chiếu về bản ghi thay đổi; không tự mở rộng phạm vi sang nội dung nghiệp vụ hoặc cấu hình ERP.
7. Đóng bản ghi thay đổi	Principal IT Business Analyst / Technical Curriculum Author	Ghi kết quả lan truyền, các artifact chưa thể cập nhật, nhãn xác minh còn giữ lại và trạng thái thực tế của thay đổi.	Bản ghi được đóng về mặt hành chính hoặc giữ mở nếu còn phụ thuộc; việc đóng không tự xác nhận baseline hay approval corpus.

Quy tắc quyết định bắt buộc

1. Sửa lỗi chính tả của nhãn hiển thị không được làm đổi canonical ID.
2. Nếu một ID đã được tham chiếu bởi artifact khác, không được xóa hoặc tái phân bổ cho đối tượng mới; phải duy trì liên kết superseded-by hoặc quan hệ lịch sử tương đương được registry quy định.
3. Đổi Artifact ID, domain code, tên tệp được kiểm soát hoặc cấu trúc family là thay đổi tác động cao; chỉ được lan truyền khi có quyết định được ghi nhận bởi vai trò có thẩm quyền.
4. Ví dụ Nova Foods chỉ là dữ liệu tổng hợp phục vụ giáo dục. Thay đổi ID không được biến ví dụ thành yêu cầu vận hành, cam kết pháp lý, quyết định kế toán hoặc cấu hình production.
5. Khi đề nghị thay đổi liên quan nội dung pháp lý, hóa đơn, kế toán, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật, bản ghi phải nêu rõ nguồn phân loại và giữ Verification required cho đến khi vai trò có thẩm quyền xác minh.

Đối chiếu liên tệp bắt buộc trước khi dùng định danh trong corpus

Đối chiếu liên tệp xác nhận rằng một định danh đã được ghi trong registry có đúng chủ thể, đường dẫn, phạm vi và quan hệ truy vết với artifact nguồn hay không. Đây là kiểm tra nhất quán của dữ liệu kế hoạch, không phải hoạt động phê duyệt, thiết lập baseline hoặc xác nhận nội dung Nova Foods sẵn sàng vận hành. Mọi đối chiếu áp dụng cho trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, bối cảnh vi-VN và dữ liệu mô phỏng bằng VND.

Tệp đối chiếu bắt buộc	Đối tượng phải so khớp với registry	Điều kiện đạt	Xử lý khi không khớp
/01-curriculum/CHAPTER_MANIFEST.md	Chapter ID, tên tệp chapter, thứ tự danh mục, phạm vi chapter và liên kết artifact dự kiến	Mỗi ID chapter trong registry phải trỏ đến đúng một chapter thuộc tập 26 tệp từ 00-foundations.md đến 25-ai-assisted-ba-workflow.md; tên tệp và đường dẫn phải giữ nguyên như manifest	Không tạo ID chapter mới, không đổi tên tệp và không suy diễn chapter thứ 27. Ghi nhận xung đột để xử lý theo kiểm soát thay đổi của registry
/01-curriculum/TEMPLATE_MANIFEST.md	Template ID, đường dẫn template, mục đích template, chapter liên quan và dependency đầu vào	Mỗi template ID phải tồn tại trong danh mục template dự kiến hoặc được đánh dấu là chưa được phép sử dụng; liên kết chapter phải dùng đúng chapter ID đã đăng ký	Không dùng template ID chưa có bản ghi tương ứng; không thay thế template bằng filename gần giống hoặc ID tự đặt
/01-curriculum/CANONICAL_BUSINESS_RULES.md	Business-rule ID, thuật ngữ nghiệp vụ Nova Foods, rule-to-requirement link và nhãn nguồn	ID rule được tham chiếu phải tồn tại đúng một lần; diễn đạt rule không bị registry biến thành yêu cầu mới, quyết định nghiệp vụ mới hoặc diễn giải pháp lý	Giữ nguyên ranh giới nguồn. Nội dung về pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc chưa xác minh phải mang nhãn Verification required hoặc Project assumption
/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Data-element ID, tên dữ liệu, định nghĩa, kiểu hoặc đơn vị biểu diễn, phân loại dữ liệu và quan hệ với rule	Một data-element ID chỉ ánh xạ tới một định nghĩa canonical; registry chỉ tham chiếu định danh, không sửa nghĩa dữ liệu hoặc tự bổ sung thuộc tính	Chặn liên kết nếu cùng một ID có hai nghĩa, nếu tên dữ liệu không khớp, hoặc nếu ví dụ bị hiểu là dữ liệu thực; chỉ dùng dữ liệu tổng hợp của Nova Foods
/01-curriculum/COMPETENCY_COVERAGE_MATRIX.md	Competency ID, phạm vi năng lực, chapter hoặc template dùng để tạo bằng chứng học tập	Mỗi competency ID liên kết từ registry phải tồn tại trong matrix và không bị dùng để chứng minh năng lực ngoài phạm vi được matrix mô tả	Loại bỏ liên kết không có competency tương ứng; không coi liên kết kế hoạch là bằng chứng người học đã đạt năng lực hoặc đã được đánh giá

Quy trình đối chiếu tối thiểu thực hiện theo thứ tự sau:

1. Đọc bản ghi canonical trong registry, gồm loại định danh, ID, artifact đích và quan hệ dự kiến.
2. Tra cứu chính xác chuỗi ID trong tệp nguồn tương ứng; so sánh theo ký tự, không chuẩn hóa âm thầm chữ hoa, chữ thường, dấu gạch nối, số thứ tự hoặc filename.
3. Xác nhận quan hệ một-đối-một khi registry quy định một chủ thể duy nhất; một ID không được đồng thời chỉ tới hai chapter, hai template, hai rule hoặc hai data element khác nhau.
4. Kiểm tra liên kết chéo có giữ đúng chiều nghĩa: chapter và template có thể tham chiếu rule, data element hoặc competency; registry không được dùng liên kết đó để sửa nội dung canonical của các artifact nguồn.
5. Lập kết quả đối chiếu theo ba trạng thái: MATCH khi mọi giá trị trùng khớp; MISMATCH khi ID tồn tại nhưng thuộc tính hoặc quan hệ khác nhau; MISSING khi không tìm thấy bản ghi nguồn. Chỉ MATCH được dùng làm liên kết dự kiến trong nội dung soạn thảo.

Ví dụ, nếu một template đăng ký liên kết tới một business-rule ID, phép kiểm phải xác nhận đồng thời ID đó có mặt trong /01-curriculum/CANONICAL_BUSINESS_RULES.md, tên rule không bị thay bằng thuật ngữ khác trong template, và data-element ID mà rule sử dụng có bản ghi tương ứng trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Nếu bất kỳ mắt xích nào là MISMATCH hoặc MISSING, liên kết không được diễn đạt như quan hệ canonical hợp lệ. Việc phát hiện sai lệch chỉ là bằng chứng cần hiệu chỉnh dữ liệu kế hoạch; không xác nhận approval, baseline, compliance hay production readiness.

Danh sách tự rà soát về đầy đủ, nhất quán và không chồng lấp

Áp dụng cho /01-curriculum/TRACEABILITY_ID_REGISTRY.md tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh. Người soạn tự rà soát trước khi chuyển artifact sang hoạt động review; việc hoàn thành checklist chỉ là bằng chứng tự kiểm tra, không xác lập baseline, approval hoặc tính sẵn sàng production.

Nhóm kiểm tra	Mục tự rà soát bắt buộc	Tiêu chí đạt
Đầy đủ phạm vi	Đã có quy tắc cho mọi nhóm định danh được registry quản lý.	Mỗi family có mã family, ý nghĩa, cấu trúc định danh, phạm vi dùng và ranh giới không dùng; không có family được nhắc đến nhưng chưa được định nghĩa.
Đầy đủ metadata	Đã bảo toàn nhận diện quản trị của artifact.	Đường dẫn /01-curriculum/TRACEABILITY_ID_REGISTRY.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND và giới hạn dữ liệu tổng hợp Nova Foods được ghi nhất quán.
Nhất quán cú pháp	Mỗi ví dụ ID tuân theo pattern của chính family đó.	Thành phần phân cách, chữ hoa/chữ thường, độ dài số thứ tự, domain code và tiền tố không mâu thuẫn giữa bảng định nghĩa, regex và ví dụ.
Nhất quán ngữ nghĩa	Một ID chỉ biểu diễn một loại đối tượng quản trị.	Không dùng cùng một family cho đồng thời business rule, data element, requirement, test evidence, template hoặc chapter; ý nghĩa của tiền tố không đổi theo ngữ cảnh.
Không trùng lặp	Không có hai family cùng cấp phát cho cùng một không gian định danh.	Không có tiền tố hoặc dải số khiến một chuỗi hợp lệ thuộc từ hai family trở lên; ID đã dành riêng không được tái dùng cho mục đích khác.
Không chồng lấp domain	Domain code phản ánh đúng miền nghiệp vụ được công bố.	Một domain code không có hai nghĩa; các miền như bán hàng, tồn kho, sản xuất, chất lượng và tài chính không bị gộp chỉ vì cùng xuất hiện trong scenario Nova Foods.
Ranh giới traceability	Liên kết traceability dùng đúng loại đầu mút.	Quan hệ nguồn–đích phân biệt rõ artifact, chapter, template, rule và data dictionary entry; liên kết không biến một tham chiếu thành bằng chứng phê duyệt hoặc xác nhận nghiệp vụ.
Nguồn và nhãn	Nội dung nhạy cảm giữ đúng phân loại nguồn.	Nội dung pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật chưa được xác minh vẫn mang nhãn Verification required hoặc Project assumption.
Ví dụ mô phỏng	Ví dụ không vượt ranh giới case study.	Chỉ dùng Nova Foods Trading & Manufacturing với dữ liệu tổng hợp; không chứa dữ liệu cá nhân, khách hàng thật, giao dịch thật hoặc suy diễn cấu hình ERP production.
Tính đọc được	Thuật ngữ, bảng và quy tắc có thể được áp dụng lặp lại.	Mỗi quy tắc có điều kiện áp dụng và kết quả mong đợi rõ ràng; không dùng diễn đạt mơ hồ làm thay đổi cách cấp phát hoặc diễn giải ID.

Kết luận tự rà soát bắt buộc: chỉ ghi nhận artifact là sẵn sàng cho bước review khi tất cả mục trên có kết quả đạt hoặc khi điểm chưa đạt được giữ nguyên như vấn đề đang mở với ranh giới tác động rõ ràng. Không được che giấu xung đột bằng cách đổi tên ID cục bộ, tạo alias không đăng ký hoặc diễn giải lại domain code.

Sổ vấn đề mở về mã miền và họ định danh

Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, registry không được suy diễn mã miền mới, tiền tố mới hoặc họ định danh mới từ tên chapter, tên template hay ví dụ Nova Foods. Một vấn đề chỉ được coi là mở khi thiếu quyết định nguồn, thiếu ranh giới ngữ nghĩa, hoặc chưa xác định được artifact đích quản lý định danh. Việc ghi nhận dưới đây không tạo reservation, không cấp ID và không xác lập baseline.

Mã theo dõi nội bộ	Vấn đề chưa giải quyết	Ranh giới quyết định cần có	Tác động nếu chưa được làm rõ	Trạng thái nhãn
OPEN-DOM-01	Phân biệt mã miền cho quy tắc nghiệp vụ curriculum với mã miền cho quy tắc vận hành ERP mô phỏng Nova Foods.	Xác định liệu hai loại rule có dùng chung hay tách biệt domain code; quyết định phải bảo toàn khả năng truy vết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md.	Không được tạo tiền tố rule mới hoặc gán lại ID rule hiện hữu theo suy đoán.	Project assumption
OPEN-DOM-02	Xác định phạm vi mã miền cho dữ liệu master, dữ liệu giao dịch và dữ liệu tham chiếu trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Cần định nghĩa ranh giới dựa trên mục đích dữ liệu và quan hệ dữ liệu, không dựa riêng vào tên bảng hoặc tên màn hình ERP.	Ví dụ dữ liệu phải giữ là dữ liệu tổng hợp; không đăng ký family mới cho entity chưa có nguồn canonical.	Project assumption
OPEN-FAM-01	Có cần family định danh riêng cho giả định, điểm cần xác minh và vấn đề mở hay chỉ dùng cơ chế quản trị của artifact chứa chúng.	Cần xác định owner artifact, cấu trúc traceability và quy tắc liên kết trước khi cấp prefix.	Các nhãn Project assumption và Verification required vẫn là nhãn trạng thái nội dung, không mặc nhiên là canonical ID family.	Verification required
OPEN-FAM-02	Có cần family riêng cho bằng chứng kiểm thử hoặc chỉ liên kết tới artifact kiểm thử được lập kế hoạch trong template.	Cần đối chiếu phạm vi với /01-curriculum/TEMPLATE_MANIFEST.md và mục tiêu năng lực trong /01-curriculum/COMPETENCY_COVERAGE_MATRIX.md.	Không dùng ID requirement, business rule hoặc data element để thay thế ID test evidence.	Project assumption
OPEN-DOM-03	Xác định việc tách domain code cho nội dung pháp lý, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc và bảo mật.	Chỉ có thể quyết định khi phân loại nguồn và phạm vi áp dụng được xác minh; không dùng domain code để ngụ ý tuân thủ.	Không tạo family hay mã miền mang nghĩa compliance, legal, accounting hoặc production authority từ nguồn seed.	Verification required

Quy tắc đóng vấn đề mở: mỗi vấn đề chỉ được chuyển thành quyết định registry khi có mô tả phạm vi đơn nghĩa, artifact nguồn được nêu rõ, đánh giá không chồng lấp với domain code hoặc family hiện có, và tác động đến các artifact liên quan được ghi nhận. Cho đến thời điểm đó, mọi ví dụ Nova Foods Trading & Manufacturing chỉ là mô phỏng giáo dục bằng dữ liệu tổng hợp, không đại diện cho cấu hình ERP thực tế hoặc quyết định vận hành thực tế.

Nhu cầu Escalation theo Vai trò Rà soát

Escalation là việc chuyển một vấn đề định danh vượt quá thẩm quyền duy trì registry của Principal IT Business Analyst / Technical Curriculum Author đến vai trò có chuyên môn hoặc quyền quyết định phù hợp. Tại IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, escalation chỉ yêu cầu rà soát và ghi nhận kết quả có truy vết; không tự tạo baseline, approval, xác nhận tuân thủ hoặc quyền sử dụng production. Mọi ví dụ Nova Foods Trading & Manufacturing vẫn là mô phỏng giáo dục với dữ liệu tổng hợp.

Vai trò cần rà soát	Bắt buộc escalation khi	Quyết định hoặc xác nhận cần có	Bằng chứng tối thiểu trong gói escalation
Senior BA	Một ID, domain code hoặc quan hệ traceability làm thay đổi phạm vi requirement, cách phân rã nghiệp vụ, owner của quy tắc, hoặc tạo chồng lấn giữa requirement, business rule, data element và acceptance criterion.	Xác định ranh giới nghiệp vụ, loại artifact đúng, quan hệ truy vết cần duy trì và giả định cần gắn nhãn.	ID bị ảnh hưởng; mô tả xung đột; artifact nguồn; tác động đến CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md hoặc curriculum.
Architect	Định danh cần phản ánh service, API, event, integration, dữ liệu dùng chung, component hoặc ranh giới hệ thống; hoặc một family ID có thể gây xung đột namespace kỹ thuật.	Xác nhận ranh giới kiến trúc, ownership kỹ thuật, quy ước định danh và tác động tích hợp.	ID/family đề xuất; sơ đồ hoặc mô tả interface; tham chiếu OpenAPI hoặc kiến trúc nếu có; các namespace có nguy cơ trùng.
QA Reviewer	ID được dùng để truy vết test basis, acceptance criterion, defect, test case hoặc evidence nhưng không thể kiểm thử, không quan sát được, hoặc tạo quan hệ nhiều nghĩa.	Xác định điều kiện kiểm thử, evidence cần có và quan hệ requirement/rule đến kiểm thử.	ID nguồn; expected result; điều kiện biên và ngoại lệ; test artifact dự kiến; lý do không thể xác minh nếu còn tồn tại.
Business Owner	Domain code, family hoặc quan hệ ID biểu diễn quy trình Nova Foods như đơn hàng, tồn kho, lô hàng, hạn dùng, sản xuất, giao nhận hoặc ngoại lệ vận hành mà chưa có chủ sở hữu nghiệp vụ rõ ràng.	Làm rõ ý nghĩa nghiệp vụ, quyền quyết định, ưu tiên và ngoại lệ được phép mô phỏng.	Scenario Nova Foods bị ảnh hưởng; giả định hiện tại; phương án lựa chọn; câu hỏi quyết định đơn nghĩa; tác động học liệu.
Legal	ID hoặc metadata liên kết đến dữ liệu cá nhân, nghĩa vụ pháp lý, lưu giữ chứng từ, an toàn thực phẩm, truy xuất nguồn gốc, chia sẻ dữ liệu hoặc tuyên bố tuân thủ.	Xác minh diễn giải pháp lý và nguồn chính thức áp dụng; quyết định nội dung phải giữ nhãn Verification required hay Project assumption.	Nội dung dự kiến; URL nguồn chính thức; ngày truy cập 2026-08-07; phạm vi Việt Nam; câu hỏi pháp lý cụ thể.
Accounting	Family ID liên quan chứng từ kế toán, hóa đơn, bút toán, kỳ kế toán, doanh thu, giá vốn, thuế hoặc đối soát tài chính.	Xác nhận cách diễn giải nghiệp vụ-kế toán trong phạm vi học liệu; không suy diễn cấu hình ERP hoặc nghĩa vụ thuế thực tế.	ID/family; luồng chứng từ mô phỏng; giả định hạch toán; tác động tới VND; điểm cần đối chiếu Luật Kế toán hoặc quy định hóa đơn.
Security	ID, domain code hoặc liên kết traceability làm lộ cấu trúc quyền truy cập, danh tính, secret, log, API endpoint, dữ liệu nhạy cảm hoặc yêu cầu kiểm soát bảo mật.	Xác định phân loại thông tin, hạn chế hiển thị, yêu cầu bảo vệ và cách tham chiếu an toàn trong corpus.	Thành phần bị ảnh hưởng; loại dữ liệu; đường truyền hoặc quyền truy cập mô phỏng; rủi ro; tham chiếu OWASP ASVS hoặc OWASP API Security Top 10 khi phù hợp.

Quy tắc kích hoạt chung: phải escalation ngay khi một đề xuất đồng thời thuộc từ hai vai trò trở lên, khi nguồn canonical mâu thuẫn với cách hiểu của artifact, hoặc khi việc chọn ID có thể bị diễn giải thành quyết định pháp lý, kế toán, kiến trúc, bảo mật hay vận hành thực tế. Principal IT Business Analyst / Technical Curriculum Author có trách nhiệm lập gói vấn đề và bảo toàn traceability, nhưng không thay thế kết luận chuyên môn của các vai trò trên.