Tmpl Rule 001 Business Rule Catalog

1. Tier 1 ? Metadata, Purpose, and Governance

Metadata quản trị artifact

Trường kiểm soát	Giá trị kiểm soát
Artifact ID	TMPL-RULE-001
Tên tệp được kiểm soát	/03-templates/TMPL-RULE-001-business-rule-catalog.md
Tiêu đề artifact	Tmpl Rule 001 Business Rule Catalog
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Ngày cập nhật gần nhất	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale và bối cảnh	vi-VN; Việt Nam; đơn vị tiền tệ mô phỏng VND
Phân loại artifact	Controlled four-tier template — mẫu có kiểm soát bốn tầng cho Business Rule Catalog (danh mục quy tắc nghiệp vụ).
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục.
Trạng thái baseline	Chưa có baseline reference tại v0.9.0. IN_REVIEW chỉ cho biết tài liệu đang được xem xét có kiểm soát, không có nghĩa là đã chốt.
Trạng thái phê duyệt	Chưa có approval reference được ghi nhận. Sự tồn tại của tài liệu, metadata, nội dung mẫu hoặc vai trò Owner không tạo ra phê duyệt ngầm định.
Thẩm quyền Owner	Owner duy trì định danh, đường dẫn, trạng thái, phiên bản và lịch sử thay đổi của artifact; Owner không tự xác nhận quy tắc Nova Foods là đúng cho vận hành thực tế, không xác lập baseline và không cấp quyền triển khai production.
Ranh giới dữ liệu	Chỉ dùng dữ liệu tổng hợp (synthetic data), tức dữ liệu được tạo cho mục đích học tập và không đại diện cho khách hàng, nhà cung cấp, nhân sự, giao dịch, cấu hình hay quyết định thực tế của bất kỳ tổ chức nào.

Lịch sử thay đổi

Lịch sử này là bản ghi kiểm soát thay đổi của artifact. Mỗi thay đổi phải nêu rõ người ghi nhận, ngày hiệu lực ghi nhận, nội dung thay đổi, lý do, artifact chịu tác động và trạng thái sau thay đổi. Bản ghi không phải bằng chứng approval, baseline hoặc xác nhận nội dung rule vận hành.

Change ID	Phiên bản	Ngày	Người ghi nhận	Thay đổi được ghi nhận	Lý do và tác động	Artifact hoặc liên kết cần kiểm tra	Trạng thái sau thay đổi
TMPL-RULE-001-CHG-001	v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo metadata quản trị cho TMPL-RULE-001 tại /03-templates/TMPL-RULE-001-business-rule-catalog.md; thiết lập phạm vi Nova Foods là mô phỏng giáo dục; thiết lập yêu cầu chỉ sử dụng dữ liệu tổng hợp; tạo lịch sử thay đổi có kiểm soát cho artifact.	Xác lập nhận diện, phạm vi sử dụng, ranh giới dữ liệu, trách nhiệm Owner và khả năng truy vết thay đổi trước khi template được sử dụng trong corpus. Tác động là artifact ở trạng thái xem xét; không tạo rule vận hành, không thay đổi policy thực tế và không tạo phê duyệt.	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md; TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md; CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md.	IN_REVIEW

Khi có thay đổi tiếp theo, Owner phải thêm một dòng mới thay vì sửa im lặng dòng lịch sử đã ghi. Dòng mới phải giữ nguyên artifact ID, filename, phiên bản áp dụng, người ghi nhận, thay đổi, lý do, tác động, liên kết cần kiểm tra và trạng thái sau thay đổi. Nếu thay đổi ảnh hưởng rule, nguồn, ID, phân loại nguồn, chapter consumer, dữ liệu, quyết định nghiệp vụ, bảo mật, pháp lý, kế toán hoặc traceability, Owner phải ghi rõ vai trò có thẩm quyền cần xem xét. Không được ghi approval, baseline hoặc production authorization nếu không có approval reference hoặc baseline reference được kiểm soát.

Ranh giới mô phỏng bắt buộc: Mọi tên quy tắc, mã, giá trị tiền tệ, ngày tháng, vai trò, luồng xử lý và liên kết truy vết Nova Foods xuất hiện trong artifact này chỉ là nội dung học liệu tổng hợp. Chúng không chứng minh rằng Nova Foods là doanh nghiệp có thật, đang sử dụng ERP, đã áp dụng quy tắc tương ứng, tuân thủ pháp luật, hoặc đã nhận phê duyệt từ người dùng hay bất kỳ vai trò có thẩm quyền nào.

Mục đích, điều kiện sử dụng và thẩm quyền của Business Rule Catalog

Business Rule Catalog là danh mục có kiểm soát để ghi nhận và quản lý business rule (quy tắc nghiệp vụ), nghĩa là mệnh đề xác định điều doanh nghiệp phải, được phép, không được phép hoặc phải tính như thế nào trong một bối cảnh nghiệp vụ. Artifact TMPL-RULE-001 giúp người học tách quy tắc khỏi yêu cầu giao diện, giải pháp kỹ thuật và kịch bản kiểm thử: một quy tắc trả lời “điều gì chi phối quyết định nghiệp vụ”, còn các artifact khác mới mô tả hệ thống thực hiện, dữ liệu lưu trữ hoặc cách kiểm tra quy tắc đó.

Nội dung quản trị	Quy định áp dụng
Mục đích	Chuẩn hóa cách tạo, mô tả, phân loại, liên kết nguồn, ghi nhận ngoại lệ và truy vết quy tắc nghiệp vụ trong case study Nova Foods Trading & Manufacturing.
Khi sử dụng	Dùng khi một quyết định, điều kiện, phép tính, ngưỡng, quyền xử lý, trạng thái hoặc ngoại lệ cần được diễn đạt nhất quán và có thể liên kết đến requirement, dữ liệu, acceptance criteria hoặc test case. Ví dụ học liệu: điều kiện chặn tạo đơn bán khi khách hàng vượt hạn mức tín dụng mô phỏng.
Khi không sử dụng	Không dùng thay cho quyết định vận hành thực tế, cấu hình ERP, hợp đồng, chính sách nhân sự, ý kiến pháp lý, diễn giải kế toán hoặc phê duyệt triển khai. Không ghi một mô tả màn hình đơn thuần thành rule nếu không có quyết định nghiệp vụ chi phối; ví dụ “nút Lưu có màu xanh” là yêu cầu giao diện, không phải quy tắc nghiệp vụ.
Owner	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc template, định danh, version, traceability và ranh giới dữ liệu mô phỏng. Owner không được tự xác nhận nội dung rule là đúng cho vận hành Nova Foods, không thiết lập baseline và không ghi nhận approval không có bằng chứng kiểm soát.
Người tiêu thụ	Business Analyst dùng để làm rõ logic; Business Owner dùng để xem xét ý nghĩa nghiệp vụ; Solution Architect và Developer dùng để đánh giá tác động giải pháp; QA dùng làm test basis, tức căn cứ tạo và đánh giá kiểm thử; Data Analyst dùng để đối chiếu dữ liệu logic; Legal, Accounting, Security hoặc Compliance Owner chỉ xem xét các rule thuộc thẩm quyền chuyên môn tương ứng.
Điều kiện tiên quyết	Phải có vấn đề nghiệp vụ được mô tả, phạm vi quy trình xác định, thuật ngữ đủ rõ, chủ thể chịu tác động và nguồn hoặc giả định được phân loại minh bạch. Nếu rule có liên quan pháp lý, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc, phải gắn nhãn Verification required cho đến khi vai trò có thẩm quyền xác minh từ nguồn chính thức hiện hành.
Artifact đầu ra liên quan	Rule đã được mô tả có thể làm đầu vào cho requirement, acceptance criteria, data dictionary, process model, API hoặc integration specification, test scenario, test case và traceability matrix. Liên kết này chỉ biểu thị quan hệ học liệu; không xác nhận thiết kế, cấu hình hay hành vi production.

Nguyên tắc quyết định: chỉ lập bản ghi rule khi có thể chỉ ra chuỗi lý do “nguồn hoặc giả định → quyết định nghiệp vụ → hành vi mong đợi”. Nếu chuỗi này đứt, người soạn phải ghi rõ đó là giả định dự án mô phỏng thay vì trình bày như nghĩa vụ đã được xác nhận. Cách làm này phù hợp với ranh giới của CANONICAL_BUSINESS_RULES: catalog canonical là nơi kiểm soát định danh và trạng thái rule ở cấp corpus, còn TMPL-RULE-001 là khuôn mẫu học tập để cấu trúc bản ghi rule; template không thay thế catalog canonical.

Tình huống	Thẩm quyền xử lý	Hành động bắt buộc
Rule chỉ làm rõ logic học liệu, không ảnh hưởng lĩnh vực chuyên môn bị kiểm soát	Principal IT Business Analyst / Technical Curriculum Author	Soạn bản ghi, giữ liên kết đến nguồn hoặc giả định, và duy trì trạng thái xem xét.
Rule thay đổi chính sách bán hàng, giá, hạn mức, phê duyệt hoặc ngoại lệ vận hành mô phỏng	Business Owner	Escalate để Business Owner xác nhận ý nghĩa nghiệp vụ; không diễn đạt là quyết định đã được phê duyệt khi chưa có tham chiếu kiểm soát.
Rule có hệ quả kiến trúc, phân quyền, tích hợp, bảo mật hoặc hiệu năng	Solution Architect hoặc Security Owner	Escalate kèm tác động, dữ liệu liên quan, rủi ro và traceability link; BA không tự chọn giải pháp kỹ thuật.
Rule liên quan thuế, hóa đơn, hạch toán, lưu trữ chứng từ hoặc báo cáo tài chính	Accounting Owner và khi cần Legal Owner	Gắn Verification required; không suy diễn nghĩa vụ từ học liệu hoặc nguồn tóm tắt.
Rule liên quan dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc thu hồi	Legal/Compliance Owner và Domain Owner phù hợp	Escalate trước khi biến nội dung thành điều kiện bắt buộc; nguồn pháp lý chỉ là căn cứ cần xác minh, không tự tạo kết luận tuân thủ.
Nguồn, ID hoặc cách hiểu mâu thuẫn	Principal IT Business Analyst / Technical Curriculum Author điều phối	Dừng việc khẳng định rule, lập gói vấn đề với nguồn mâu thuẫn và chuyển đúng vai trò có thẩm quyền.

Template này phải giữ nhất quán với TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md, registry TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md, catalog CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md và các chapter được kiểm soát trong /01-curriculum/CHAPTER_MANIFEST.md. Mọi thay đổi làm ảnh hưởng ID, filename, nguồn, phân loại nguồn, quan hệ truy vết hoặc ranh giới thẩm quyền phải được ghi nhận theo change control của corpus; trạng thái IN_REVIEW của TMPL-RULE-001 không phải baseline, không phải approval và không cấp quyền sử dụng production.

Bản đồ định danh, liên kết manifest và nghĩa vụ kiểm soát thay đổi

Template này có định danh chính tắc (canonical ID, tức mã được dùng nguyên dạng tại mọi liên kết để tránh nhầm lẫn) là TMPL-RULE-001, với tệp được kiểm soát là /03-templates/TMPL-RULE-001-business-rule-catalog.md. Chuỗi định danh và tên tệp được suy ra trực tiếp từ đường dẫn được yêu cầu; vì vậy không được thay bằng tên dịch, mã tự đặt như BUSINESS-RULE-TEMPLATE-01, hoặc bản sao không kiểm soát. Template là một artifact thuộc thư viện template, không phải catalog quy tắc Nova Foods đang có hiệu lực.

Hạng mục liên kết	Giá trị canonical phải dùng	Vai trò trong kiểm soát	Ranh giới diễn giải
Template identity	TMPL-RULE-001	Nhận diện duy nhất template Business Rule Catalog trong liên kết, review và kiểm tra chéo.	Không phải ID của một business rule riêng lẻ.
Tệp template	/03-templates/TMPL-RULE-001-business-rule-catalog.md	Nguồn kiểm soát cho cấu trúc bốn tầng của template.	Bản export hoặc bản sao học tập không thay thế tệp này.
Manifest template	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Nguồn đối chiếu việc template được lập kế hoạch trong corpus.	Manifest là planning artifact; không xác nhận template đã baseline hoặc được phê duyệt.
Registry định danh	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nguồn kiểm tra quy tắc đặt, dùng và không tái sử dụng ID traceability.	Không tự tạo ID mới khi registry chưa ghi nhận hoặc có xung đột.
Catalog quy tắc canonical	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Đích liên kết của các rule record đã được quản trị ở cấp catalog.	Template không thay thế catalog và không biến nội dung minh họa thành quy tắc vận hành thực tế.
Từ điển dữ liệu canonical	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Đối chiếu thuật ngữ dữ liệu, trường dữ liệu và thực thể logic được rule sử dụng.	Không được suy ra data model triển khai hoặc cấu hình ERP từ liên kết này.
Kiến trúc curriculum	01_CURRICULUM_ARCHITECTURE tại /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Đối chiếu vị trí học liệu, dependency và chuỗi học.	Không phải nguồn phê duyệt nội dung quy tắc.
Manifest chapter	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	Nguồn xác định chapter nào được phép tham chiếu template.	Không gán số chapter, tên chapter hoặc dependency chưa được manifest ghi nhận.
Bản đồ nguồn	00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	Nguồn kiểm soát phân loại và ranh giới sử dụng nguồn.	Không thay thế văn bản được cấp phép, tư vấn pháp lý, kế toán hoặc quyết định vận hành.

Liên kết chapter phải đi từ CHAPTER_MANIFEST: một chapter chỉ được ghi là consumer hoặc upstream/downstream của TMPL-RULE-001 khi manifest có entry tương ứng. Lý do là manifest được xác định là nguồn authoritative cho 26 chapter, còn việc tự gán chapter trong template sẽ tạo hai nguồn chân lý và làm đứt traceability. Khi entry chapter chưa thể xác minh từ manifest, template chỉ ghi nhận liên kết ở cấp artifact như bảng trên, không bịa mã chapter hay tên bài học.

Nguồn tham chiếu trong template phải được phân loại trước khi dùng. BABOK Guide là nguồn nghề BA cho thuật ngữ và hoạt động phân tích; ISO/IEC/IEEE 29148 chỉ được dùng theo abstract và trạng thái thư mục công khai nếu chưa kiểm tra văn bản có cấp phép; ISTQB CTFL Syllabus v4.0.1 hỗ trợ thuật ngữ và kỹ thuật kiểm thử; còn luật, nghị định Việt Nam và nguồn OWASP chỉ là nguồn pháp lý hoặc good practice theo đúng ranh giới trong 00_SOURCE_MAP. Vì nội dung Nova Foods là mô phỏng giáo dục dùng dữ liệu tổng hợp, mọi rule liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải mang nhãn Verification required hoặc project assumption nếu chưa có xác minh từ vai trò có thẩm quyền và nguồn hiện hành.

Thay đổi đối với TMPL-RULE-001 phải được đánh giá theo chuỗi tác động: xác định phần thay đổi, kiểm tra TEMPLATE_MANIFEST về phạm vi template, kiểm tra TRACEABILITY_ID_REGISTRY về ID, đối chiếu CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY nếu thay đổi ảnh hưởng liên kết, rồi cập nhật lịch sử thay đổi của chính artifact. Không được sửa im lặng canonical ID, filename, phân loại nguồn, liên kết chapter hoặc nhãn xác minh. Nếu thay đổi đòi hỏi kết luận pháp lý, kế toán, bảo mật, kiến trúc hoặc quyết định nghiệp vụ Nova Foods, phải chuyển vấn đề đến vai trò có thẩm quyền; việc duy trì traceability không thay thế kết luận đó.

2. Tier 2 ? Blank Copy-Paste-Ready Template

Khối dưới đây là mẫu trống duy nhất có thể sao chép cho từng business rule (quy tắc nghiệp vụ). Mỗi cặp dấu góc phải được thay bằng thông tin đã xác minh; không giữ placeholder khi chuyển sang Tier 3, trừ placeholder chỉ trạng thái chưa xác minh hoặc giả định mô phỏng theo hướng dẫn bên dưới.

Mẫu thuộc artifact TMPL-RULE-001, tệp /03-templates/TMPL-RULE-001-business-rule-catalog.md, trạng thái hiện hành IN_REVIEW, phiên bản v0.9.0, ngày cập nhật 2026-08-07, locale vi-VN, timezone Asia/Ho_Chi_Minh, currency VND. Nội dung áp dụng cho corpus Nova Foods mô phỏng, chỉ dùng dữ liệu tổng hợp, không phải quy định vận hành ERP thực tế. Không dùng mẫu này để xác nhận phê duyệt, baseline, production readiness, nghĩa vụ pháp lý, thuế, kế toán, an toàn thực phẩm hoặc bảo vệ dữ liệu khi chưa có nguồn và thẩm quyền xác minh phù hợp.

2.1. Nhận diện bản ghi quy tắc

Trường	Giá trị cần điền	Hướng dẫn điền
Rule ID	<mã quy tắc canonical, ví dụ BR-NF-<số thứ tự>>	Dùng một mã duy nhất theo TRACEABILITY_ID_REGISTRY. Không tự đổi mã đã được đăng ký. ID phải duy nhất trong catalog, viết hoa, không chứa khoảng trắng và phải đối chiếu với /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Rule name	<tên ngắn, mô tả đúng kết quả hoặc ràng buộc>	Dùng danh từ hoặc câu ngắn, tránh tên chung như “Quy tắc mới”. Một bản ghi chỉ mô tả một quy tắc.
Rule type	<Validation \| Calculation \| Eligibility \| Routing \| Control \| Data integrity \| Other>	Chọn đúng một giá trị phản ánh chức năng chính. Nếu cần nhiều loại, ghi lý do, nêu loại phụ trong ghi chú và đánh dấu cần xem xét phân loại.
Business domain	<Sales \| Purchasing \| Inventory \| Manufacturing \| Finance \| Quality \| Master data \| Security \| Other>	Chọn miền nghiệp vụ chịu tác động chính. Không dùng trường này để kết luận pháp lý hoặc kế toán.
Scope	<phạm vi tổ chức, quy trình, giao dịch hoặc đối tượng áp dụng>	Nêu rõ điểm bắt đầu, điểm kết thúc, phòng ban, quy trình, đối tượng hoặc giao dịch thuộc phạm vi. Không mở rộng sang quy trình chưa có bằng chứng.
Out of scope	<trường hợp, đối tượng hoặc giao dịch không áp dụng>	Ghi rõ loại trừ để tránh hiểu nhầm. Nếu không có loại trừ đã xác minh, ghi <N/A — chưa xác định trường hợp loại trừ>.
Rule statement	<Nếu <điều kiện>, thì <hệ thống hoặc người dùng phải thực hiện kết quả>; ngược lại <kết quả>>	Viết thành câu kiểm chứng được, có chủ thể, điều kiện, hành động, đối tượng và kết quả. Không dùng từ mơ hồ như “hợp lý”, “nhanh” hoặc “đúng quy định” nếu chưa định nghĩa.
Business rationale	<lý do nghiệp vụ và vấn đề mà quy tắc xử lý>	Giải thích mối nối từ vấn đề hoặc mục tiêu đến quy tắc. Nếu là suy luận học liệu, ghi rõ Project assumption và giới hạn sử dụng.
Assumptions	<giả định dự án và giới hạn>	Chỉ ghi giả định dự án. Không trình bày giả định như sự thật vận hành Nova Foods.
Constraints	<điều kiện cứng giới hạn áp dụng hoặc thực thi>	Nêu ràng buộc dữ liệu, quy trình, thẩm quyền hoặc hệ thống đã biết. Không tự đặt hạn mức, tỷ lệ thuế hoặc công thức kế toán.
Trigger	<sự kiện kích hoạt: tạo, sửa, gửi duyệt, xác nhận, hủy hoặc sự kiện khác>	Chọn một sự kiện cụ thể. Nếu có nhiều trigger, ghi từng trigger thành dòng riêng trong bản đầy đủ.
Check condition	<mệnh đề dữ liệu hoặc trạng thái phải được đánh giá>	Nêu dữ liệu đầu vào, toán tử hoặc trạng thái kiểm tra. Tránh “thông thường”, “khi cần” hoặc điều kiện không kiểm thử được.
Decision	<kết quả khi điều kiện đúng và kết quả khi điều kiện sai>	Nêu rõ nhánh quyết định, người hoặc hệ thống ra quyết định và hậu quả nghiệp vụ của từng nhánh.
Actor	<vai trò thực hiện hoặc chịu trách nhiệm: người dùng, hệ thống, quản trị viên hoặc vai trò khác>	Ghi vai trò, không ghi tên cá nhân thật. Phân biệt vai trò thực hiện, owner nội dung, reviewer và người có thẩm quyền sign-off.
Input data	<danh sách trường dữ liệu đầu vào và định dạng mong đợi>	Mỗi trường phải có tên, kiểu dữ liệu, đơn vị và điều kiện bắt buộc nếu biết. Dữ liệu tiền tệ ghi đơn vị VND.
Output or system action	<kết quả, thông báo, trạng thái hoặc thao tác hệ thống>	Mô tả điều quan sát được sau khi áp dụng quy tắc. Không bịa tên màn hình, API hoặc cấu hình ERP chưa có nguồn.
User action	<hành động người dùng phải thực hiện, nếu có>	Nêu vai trò, hành động, đối tượng và kết quả cần đạt. Nếu rule không yêu cầu hành động người dùng, ghi <N/A — rule không yêu cầu hành động người dùng>.
Expected outcome	<kết quả nghiệp vụ và kiểm soát mong đợi>	Nêu outcome có thể quan sát hoặc kiểm tra. Ghi rõ hậu quả khi rule không được thực hiện nếu đã biết.
Error message	<ERROR_MESSAGE_VI> hoặc <N/A — rule không tạo lỗi>	Nếu có lỗi, thông báo phải chỉ rõ dữ liệu cần sửa. Không chứa bí mật, thông tin cá nhân thật hoặc khẳng định tuân thủ chưa được xác minh.
Exception	<tên, điều kiện và mô tả ngoại lệ>	Nêu ngoại lệ khác luồng chuẩn thế nào. Nếu không có ngoại lệ đã xác minh, ghi <N/A — chưa xác định ngoại lệ>.
Exception handling	<xử lý thay thế, người xử lý và kết quả>	Mô tả xử lý tạm thời hoặc chính thức. Nêu rõ đối tượng, hành động, outcome và bằng chứng cần lưu nếu có.
Escalation path	<vai trò hoặc nhóm nhận escalation khi vượt thẩm quyền>	Ghi vai trò hoặc nhóm, không ghi tên cá nhân thật. Nếu chưa xác minh, ghi <Verification required — xác minh vai trò nhận escalation>.
Recovery rule	<điều kiện và hành động quay lại luồng chuẩn>	Nêu điều kiện khôi phục và outcome. Nếu không có luồng khôi phục, ghi <N/A — không có quy tắc khôi phục được xác minh>.
Priority	<Critical \| High \| Medium \| Low>	Chọn theo hậu quả nếu quy tắc không được thực hiện. Nếu chưa đủ căn cứ, ghi Verification required.
Applicability	<Applicable \| Not applicable \| Conditional \| Verification required>	Chọn một giá trị và giải thích ngắn tại Applicability rationale.
Applicability rationale	<lý do áp dụng, không áp dụng hoặc áp dụng có điều kiện>	Không xóa khối điều kiện để che khoảng trống thông tin. Nêu điều kiện, phạm vi và hậu quả khi điều kiện không thỏa.
Mandatory level	<Mandatory \| Conditional \| Informative>	Mandatory chỉ dùng khi có căn cứ đủ rõ. Nội dung pháp lý, thuế, kế toán, an toàn thực phẩm hoặc bảo vệ dữ liệu chưa xác minh phải ghi Verification required.
Source classification	<Primary official source \| Professional guidance \| Project assumption \| Verification required>	Phân loại theo ranh giới nguồn của /00-research/00_SOURCE_MAP.md. Không gọi good practice là nghĩa vụ pháp lý, không nâng giả định dự án thành yêu cầu bắt buộc.
Source reference	<tài liệu hoặc nguồn làm căn cứ>	Ghi tài liệu hoặc nguồn chính đã kiểm tra. Nếu chưa có nguồn, ghi <Verification required — nguồn hoặc vai trò cần xác minh>.
Evidence	<loại bằng chứng, mã bằng chứng, vị trí lưu, nguồn gốc và nội dung chứng minh>	Ví dụ loại bằng chứng: tài liệu, log, ảnh chụp màn hình, ticket. Dùng ID duy nhất, vị trí lưu an toàn và mô tả bằng chứng chứng minh điều gì.
Traceability link	<liên kết đến requirement, test, rule, control hoặc tài liệu liên quan>	Dùng ID canonical của tài liệu liên quan. Nêu quan hệ: dẫn xuất, xác minh, phụ thuộc hoặc tham chiếu.
Owner role	<vai trò chịu trách nhiệm duy trì nội dung quy tắc>	Đây là trách nhiệm nội dung, không đồng nghĩa với phê duyệt hoặc quyền triển khai.
Version and change history	<phiên bản, ngày thay đổi, vai trò ghi nhận, nội dung, lý do và tác động>	Ghi phiên bản theo dạng v<major>.<minor>.<patch>. Mọi thay đổi phải có lịch sử; không sửa âm thầm ý nghĩa phiên bản cũ.
Review status	<Draft \| In review \| Needs clarification \| Rejected \| Accepted for learning use>	Trạng thái phải phản ánh việc xem xét hiện tại. Không dùng Approved, BASELINED hoặc PRODUCTION_READY nếu chưa có tham chiếu quản trị tương ứng.
Review and sign-off record	<vai trò reviewer, ngày review, kết quả; vai trò sign-off, ngày sign-off, ghi chú nếu có>	Sign-off chỉ ghi khi có thẩm quyền phù hợp và bằng chứng tương ứng. Owner không tự động có quyền sign-off.

2.2. Cấu trúc mô tả quy tắc để sao chép

### <Rule ID> — <Rule name>

- **Loại quy tắc:** <Rule type>
- **Miền nghiệp vụ:** <Business domain>
- **Phạm vi:** <Scope>
- **Không áp dụng:** <Out of scope>
- **Kích hoạt:** <Trigger>
- **Điều kiện kiểm tra:** <Check condition>
- **Quyết định:** <Decision>
- **Vai trò liên quan:** <Actor>
- **Mức độ ưu tiên:** <Priority>
- **Khả năng áp dụng:** <Applicability>
- **Lý do khả năng áp dụng:** <Applicability rationale>
- **Mức độ bắt buộc:** <Mandatory level>
- **Tuyên bố quy tắc:** <Rule statement>
- **Lý do nghiệp vụ:** <Business rationale>
- **Giả định:** <Assumptions>
- **Ràng buộc:** <Constraints>
- **Dữ liệu đầu vào:** <Input data>
- **Hành động hoặc kết quả hệ thống:** <Output or system action>
- **Hành động người dùng:** <User action>
- **Kết quả mong đợi:** <Expected outcome>
- **Thông báo lỗi:** <Error message>
- **Ngoại lệ:** <Exception>
- **Xử lý ngoại lệ:** <Exception handling>
- **Đường leo thang:** <Escalation path>
- **Quy tắc khôi phục:** <Recovery rule>
- **Vai trò Owner:** <Owner role>
- **Phân loại nguồn:** <Source classification>
- **Nguồn tham chiếu:** <Source reference>
- **Bằng chứng:** <Evidence>
- **Liên kết truy vết:** <Traceability link>
- **Phiên bản và lịch sử thay đổi:** <Version and change history>
- **Trạng thái xem xét:** <Review status>
- **Review và sign-off:** <Review and sign-off record>

Khi điền mẫu, phải bảo toàn tên tệp, ID canonical và nhãn nguồn đã đăng ký. Nếu chưa xác minh được một trường, điền <Verification required — mô tả chính xác điều cần xác minh> thay vì suy đoán. Nếu nội dung chỉ phục vụ bài học mô phỏng, dùng <Project assumption — nêu giả định và giới hạn>. Nếu một mục không áp dụng, ghi <N/A — nêu lý do không áp dụng>; không xóa dòng, không để trống không giải thích.

Hướng dẫn cấp trường, giá trị hợp lệ, kiểm tra và điều kiện áp dụng

Các placeholder trong /03-templates/TMPL-RULE-001-business-rule-catalog.md phải được thay bằng dữ liệu có căn cứ; không được suy đoán để làm đầy mẫu. Mọi nội dung Nova Foods trong bản điền sau này vẫn phải được đánh dấu là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

Trường hoặc nhóm trường	Giá trị hợp lệ	Quy tắc kiểm tra
Artifact ID	TMPL-RULE-001	Phải khớp chính xác với định danh của template; không dịch, rút gọn hoặc tự tạo biến thể.
Tên tệp	/03-templates/TMPL-RULE-001-business-rule-catalog.md	Phải giữ nguyên đường dẫn canonical; không thay bằng tên bản sao hoặc tên xuất bản.
Status	IN_REVIEW, DRAFT, RETIRED	Ở bản mẫu hiện hành dùng IN_REVIEW; không dùng APPROVED, BASELINED hoặc PRODUCTION_READY nếu chưa có tham chiếu quản trị tương ứng.
Version	Chuỗi theo dạng v<major>.<minor>.<patch>	Bản hiện hành là v0.9.0; mọi thay đổi phải ghi lịch sử thay đổi, không sửa âm thầm ý nghĩa phiên bản cũ.
Ngày cập nhật	Ngày ISO YYYY-MM-DD	Phải là ngày hợp lệ theo Asia/Ho_Chi_Minh; bản hiện hành dùng 2026-08-07.
Locale, Timezone, Currency	vi-VN, Asia/Ho_Chi_Minh, VND	Không thay đổi các giá trị corpus mặc định nếu chưa có quyết định phạm vi được truy vết.
Rule ID	<RULE-<DOMAIN>-<NNN>>	ID phải duy nhất trong catalog, viết hoa, không chứa khoảng trắng; phải được đối chiếu với /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Loại quy tắc	Validation, Calculation, Decision, Authorization, Sequencing, Traceability	Chọn một giá trị phản ánh chức năng chính; nếu có từ hai loại, ghi loại chính và mô tả loại phụ trong ghi chú.
Mức độ bắt buộc	Mandatory, Conditional, Informative	Mandatory chỉ dùng khi có căn cứ đủ rõ; nội dung pháp lý, thuế, kế toán, an toàn thực phẩm hoặc bảo vệ dữ liệu chưa xác minh phải ghi Verification required.
Nguồn phân loại	Primary source, Secondary source, Project assumption, Verification required	Primary source chỉ dùng cho nguồn chính thức đã kiểm tra; không nâng cấp giả định dự án thành yêu cầu bắt buộc.
Điều kiện kích hoạt	Mô tả điều kiện kiểm tra được	Phải nêu sự kiện, trạng thái hoặc dữ liệu đầu vào làm phát sinh rule; tránh các từ mơ hồ như “thông thường” hoặc “khi cần”.
Thông báo lỗi	<ERROR_MESSAGE_VI> hoặc <N/A — rule không tạo lỗi>	Nếu có lỗi, thông báo phải chỉ rõ dữ liệu cần sửa; không chứa bí mật, thông tin cá nhân thật hoặc lời khẳng định tuân thủ chưa được xác minh.

Quy tắc định dạng và xác thực giá trị

• Trường văn bản phải nêu chủ thể, hành động, điều kiện và kết quả. Cấu trúc khuyến nghị: “Khi <điều kiện>, hệ thống phải <hành động> để đạt <kết quả kiểm soát>”. Nếu chưa đủ căn cứ, giữ <CẦN XÁC MINH — nguồn hoặc vai trò xác minh>.
• Trường số tiền phải ghi đơn vị VND, không dùng dấu phân cách gây nhầm lẫn giữa locale; giá trị âm chỉ hợp lệ khi nghiệp vụ cho phép và phải có lý do. Không tự đặt hạn mức, tỷ lệ thuế hoặc công thức kế toán nếu chưa có nguồn hoặc chủ sở hữu chuyên môn xác minh.
• Trường ngày và thời điểm phải dùng YYYY-MM-DD hoặc YYYY-MM-DDTHH:mm:ss+07:00. Không dùng ngày tương đối như “hôm nay”, “cuối tháng” nếu không kèm quy tắc tính cụ thể.
• Trường boolean chỉ nhận Yes hoặc No. Không dùng đồng thời Có/Không, Y/N, True/False trong cùng catalog.
• Trường danh sách nhiều giá trị phải phân tách bằng dấu phẩy và dùng đúng bộ giá trị đã khai báo. Giá trị ngoài danh sách phải bị từ chối hoặc chuyển thành <CẦN XÁC MINH — giá trị chưa được đăng ký>.
• Rule chưa đủ điều kiện sử dụng trong bài tập nếu thiếu Rule ID, điều kiện kích hoạt, kết quả mong đợi, nguồn phân loại hoặc người có trách nhiệm xác minh. Đây là kiểm tra chất lượng template, không phải phê duyệt nội dung nghiệp vụ.
• Nếu quyết định liên quan nhiều vai trò, phải ghi từng vai trò, hành động, thẩm quyền và outcome riêng. Không suy diễn quyền phê duyệt từ vai trò owner.
• Bằng chứng phải nêu loại bằng chứng, ID, vị trí lưu, nguồn gốc, nội dung được chứng minh và liên kết truy vết. Không ghi dữ liệu bí mật hoặc dữ liệu định danh thật vào bằng chứng, log hoặc Traceability link.

Khối điều kiện áp dụng

Chỉ giữ các khối điều kiện phù hợp với rule và phải ghi rõ lý do ở trường Applicability rationale. Không được xóa khối để che khuất khoảng trống thông tin.

Khối điều kiện	Khi nào bắt buộc giữ	Nội dung tối thiểu
<CONDITIONAL — Calculation>	Rule có công thức, làm tròn, tổng hợp hoặc quy đổi tiền	Đầu vào, công thức, đơn vị, quy tắc làm tròn và người xác minh nghiệp vụ.
<CONDITIONAL — Authorization>	Rule giới hạn vai trò, quyền hoặc phê duyệt	Vai trò yêu cầu, hành động bị giới hạn, điều kiện từ chối và tham chiếu bảo mật phù hợp.
<CONDITIONAL — Exception>	Có tình huống ngoại lệ khác luồng chuẩn	Điều kiện ngoại lệ, xử lý thay thế, người nhận escalation và tác động truy vết.
<CONDITIONAL — Personal or Sensitive Data>	Trường có thể chứa dữ liệu cá nhân, thông tin xác thực hoặc dữ liệu nhạy cảm	Mục đích sử dụng, phạm vi hiển thị, thời hạn lưu giữ cần xác minh và chủ sở hữu pháp lý hoặc bảo mật.
<CONDITIONAL — External Integration>	Rule phụ thuộc API, hệ thống hoặc dịch vụ bên ngoài	Hệ thống nguồn/đích, mã phản hồi mong đợi, xử lý timeout và liên kết đặc tả; không mô tả PlantUML activity diagram là BPMN.

Mẫu tham chiếu bí mật an toàn

Không ghi mật khẩu, token, khóa API, chuỗi kết nối, dữ liệu định danh thật hoặc giá trị bí mật trực tiếp vào template, bằng chứng, log hay trường Traceability link. Chỉ dùng tham chiếu đến kho bí mật giả lập hoặc tên biến môi trường, theo mẫu sau:

Trường hợp	Mẫu được phép	Mẫu không được phép
Tên biến môi trường	<SECRET_REF:ENV:NOVA_ERP_API_TOKEN>	<TOKEN:abc123>
Khóa kho bí mật	<SECRET_REF:VAULT:kv/nova-foods/sandbox/erp-api>	password=... hoặc giá trị mật khẩu thật
Tham chiếu cấu hình mô phỏng	<CONFIG_REF:SIMULATED:NOVA-ERP-ENDPOINT>	URL production hoặc endpoint chưa được kiểm soát
Bằng chứng log	<REDACTED_SECRET_REF:LOG-<EVIDENCE-ID>>	Sao chép toàn bộ header Authorization, cookie hoặc payload chứa bí mật

Mỗi tham chiếu bí mật phải có chủ sở hữu kỹ thuật, mục đích sử dụng và phạm vi môi trường tại các trường tương ứng. Nếu chưa xác định được kho tham chiếu an toàn, ghi <N/A — chưa phát sinh secret reference> hoặc <CẦN XÁC MINH — chưa được phép ghi giá trị bí mật>, tuyệt đối không thay bằng dữ liệu thật.

3. Tier 3 ? Fully Completed Nova Foods Case: Core Record

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; toàn bộ tên người, mã giao dịch, số tiền và dữ liệu dưới đây là dữ liệu tổng hợp. Bản ghi minh họa quy tắc nghiệp vụ kiểm soát xác nhận đơn bán hàng khi tổng dư nợ và giá trị đơn đang mở vượt hạn mức tín dụng nội bộ mô phỏng.

Trường core record	Giá trị đã điền
Template ID	TMPL-RULE-001
Rule ID	BR-NF-ORD-001
Tên quy tắc	Chặn xác nhận đơn bán hàng vượt hạn mức tín dụng khách hàng
Miền nghiệp vụ	Order-to-Cash (từ đơn bán hàng đến thu tiền)
Phân hệ ERP	Sales Order Management và Accounts Receivable
Trạng thái bản ghi	IN_REVIEW
Phiên bản	v0.9.0
Ngày ghi nhận	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; VND
Chủ sở hữu nghiệp vụ mô phỏng	Trần Minh Khôi — Credit Control Lead, Nova Foods
Người lập mô phỏng	Lê Anh Thư — IT Business Analyst, Nova Foods
Phạm vi áp dụng	Đơn bán hàng nội địa có trạng thái DRAFT hoặc PENDING_CREDIT_REVIEW
Ngoài phạm vi	Đơn hàng xuất khẩu, đơn hàng mẫu không thu tiền, phiếu điều chỉnh công nợ và giao dịch đã hủy
Tần suất kích hoạt	Mỗi lần người dùng yêu cầu xác nhận đơn bán hàng hoặc sửa tổng giá trị đơn chưa xác nhận
Đối tượng bị kiểm soát	Khách hàng, hạn mức tín dụng, dư nợ phải thu, đơn bán hàng đang mở, trạng thái phê duyệt tín dụng

Bối cảnh giao dịch mô phỏng

Thành phần	Giá trị tổng hợp
Khách hàng	CUS-NF-000184 — Công ty TNHH Phân phối An Khang
Đơn bán hàng	SO-NF-20260807-0142
Ngày tạo đơn	2026-08-07 09:18:24
Người tạo đơn	Nguyễn Quốc Duy — Sales Executive
Kho xuất dự kiến	WH-HCM-01 — Kho Thành phẩm Bình Tân
Điều khoản thanh toán mô phỏng	NET30 — thanh toán trong 30 ngày kể từ ngày hóa đơn
Hạn mức tín dụng khách hàng	300.000.000 VND
Dư nợ phải thu đã ghi nhận	210.000.000 VND
Giá trị đơn bán hàng đang mở khác	55.000.000 VND
Giá trị đơn SO-NF-20260807-0142	42.900.000 VND
Tổng mức phơi nhiễm tín dụng sau xác nhận	307.900.000 VND
Phần vượt hạn mức	7.900.000 VND
Trạng thái đơn trước khi đánh giá	DRAFT
Trạng thái đơn sau khi đánh giá tự động	PENDING_CREDIT_REVIEW
Kết quả xử lý	Không cho chuyển đơn sang CONFIRMED; tạo yêu cầu rà soát tín dụng CRR-NF-20260807-0031

Actor là Nguyễn Quốc Duy trong vai trò Sales Executive. Actor yêu cầu xác nhận SO-NF-20260807-0142. Hệ thống kiểm tra khách hàng CUS-NF-000184, công nợ phải thu, giá trị đơn đang mở khác, giá trị đơn hiện tại và hạn mức tín dụng tại thời điểm yêu cầu. Outcome là đơn chuyển từ DRAFT sang PENDING_CREDIT_REVIEW; hệ thống không xác nhận đơn và không mở luồng giao hàng.

Dữ liệu dòng đơn hàng mô phỏng

Dòng	Mã hàng	Tên hàng mô phỏng	Số lượng	Đơn giá chưa gồm thuế	Thành tiền
1	FG-NF-CHILI-500G	Tương ớt Nova 500 g	600 chai	31.500 VND	18.900.000 VND
2	FG-NF-SOY-750ML	Nước tương Nova 750 ml	400 chai	28.000 VND	11.200.000 VND
3	FG-NF-FISH-500ML	Nước mắm Nova 500 ml	300 chai	42.000 VND	12.600.000 VND
4	SVC-NF-DEL-HCM	Phí giao hàng nội thành	1 lần	200.000 VND	200.000 VND
		Tổng giá trị đơn			42.900.000 VND

Nội dung quy tắc đã điền

Quy tắc: Hệ thống chỉ cho phép chuyển đơn bán hàng nội địa sang trạng thái CONFIRMED khi tổng của Dư nợ phải thu đã ghi nhận + Giá trị đơn bán hàng đang mở khác + Giá trị đơn đang xác nhận không lớn hơn Hạn mức tín dụng khách hàng tại thời điểm kiểm tra.

Biểu thức kiểm tra: 210.000.000 + 55.000.000 + 42.900.000 = 307.900.000 VND.

Kết luận: 307.900.000 VND lớn hơn hạn mức 300.000.000 VND. Chênh lệch là 7.900.000 VND. Hệ thống phải gắn trạng thái PENDING_CREDIT_REVIEW, khóa thao tác xác nhận của Sales Executive đối với đơn này, tạo yêu cầu CRR-NF-20260807-0031, và chuyển yêu cầu cho Credit Control Lead mô phỏng rà soát.

Authority: Credit Control Lead mô phỏng có thẩm quyền xử lý yêu cầu rà soát tín dụng của case. Thẩm quyền này chỉ là mô hình vai trò học liệu; không xác nhận ma trận ủy quyền, chính sách tín dụng, quyền kế toán hay thẩm quyền pháp lý thực tế của Nova Foods.

Artifact được tạo: CRR-NF-20260807-0031 là bằng chứng yêu cầu rà soát tín dụng cho SO-NF-20260807-0142. Artifact phải liên kết Rule ID, đơn bán hàng, khách hàng, các giá trị đầu vào, kết quả tính, trạng thái trước và sau kiểm tra, lý do chặn, vai trò xử lý và thời điểm tạo theo Asia/Ho_Chi_Minh.

Trade-off: Chặn tự động làm chậm xác nhận đơn cần ngoại lệ. Không chặn tự động làm tăng nguy cơ đơn đi tiếp trước khi người có thẩm quyền đánh giá mức phơi nhiễm tín dụng. Case chọn chặn xác nhận vì kiểm soát công nợ cần xảy ra trước giao hàng.

Consequence: Nếu hệ thống xác nhận sai, đơn có thể đi tiếp dù mức phơi nhiễm cao hơn hạn mức mô phỏng 7.900.000 VND. Nếu hệ thống chặn sai đơn không vượt hạn mức, Sales Executive có thể chịu chậm trễ bán hàng không cần thiết. Vì vậy, hệ thống phải dùng đúng ba thành phần tiền tệ cùng khách hàng và cùng thời điểm kiểm tra.

Thông điệp hiển thị mô phỏng: Không thể xác nhận SO-NF-20260807-0142. Mức phơi nhiễm tín dụng 307.900.000 VND vượt hạn mức 300.000.000 VND là 7.900.000 VND. Yêu cầu Credit Control rà soát CRR-NF-20260807-0031.

Nguồn và phân loại nguồn của bản ghi

Mã nguồn	Phân loại nguồn	Nội dung được sử dụng	Ranh giới sử dụng
SRC-NF-SIM-ORD-001	SIMULATED_TRANSACTION	Dữ liệu đơn SO-NF-20260807-0142, khách hàng, dòng hàng, giá trị tiền và trạng thái đơn	Dữ liệu tổng hợp phục vụ học liệu; không phải giao dịch ERP thực tế.
SRC-NF-SIM-CRD-001	PROJECT_ASSUMPTION	Hạn mức 300.000.000 VND, phương pháp cộng dư nợ và đơn mở, luồng rà soát tín dụng	Giả định dự án mô phỏng; cần Business Owner và Accounting Owner xác minh trước khi dùng cho vận hành thực tế.
SRC-NF-SIM-ROLE-001	SIMULATED_ROLE_MODEL	Vai trò Sales Executive và Credit Control Lead; quyền tạo đơn và rà soát tín dụng	Không xác nhận cơ cấu tổ chức, phân quyền hay ma trận ủy quyền thực tế của Nova Foods.
SRC-LAW-ACC-001	OFFICIAL_LEGAL_CONTEXT	Luật Kế toán 88/2015/QH13 được nhận diện là bối cảnh cần tham vấn khi thiết kế xử lý số liệu công nợ	Không diễn giải luật thành công thức hạn mức, bút toán, nghĩa vụ thuế hoặc cấu hình ERP; cần Accounting Owner hoặc Legal Owner xác minh.

Bản ghi BR-NF-ORD-001 vẫn ở trạng thái IN_REVIEW; nội dung mô phỏng không xác nhận hạn mức tín dụng thực tế, không tạo phê duyệt và không cho phép triển khai production.

3.1 Bản ghi lõi đã điền đầy đủ cho quy tắc nghiệp vụ Nova Foods mô phỏng

Bản ghi này là lõi danh mục quy tắc nghiệp vụ cho tình huống Nova Foods mô phỏng. Bản ghi dùng dữ liệu tổng hợp theo vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. “Business rule” là điều kiện hệ thống phải kiểm tra trước khi cho phép hành vi nghiệp vụ xảy ra. Mọi định danh, số chứng từ, ngày tháng và giá trị tiền trong case là synthetic data; không được diễn giải là dữ liệu vận hành thực tế.

Trường lõi	Giá trị hoàn chỉnh
Artifact ID	CANONICAL_BUSINESS_RULES
File kiểm soát	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Rule ID	BR-NF-ORD-001
Rule name	Kiểm tra hạn mức tín dụng trước khi xác nhận đơn bán hàng
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Status	IN_REVIEW
Version	v0.9.0
Last updated date	2026-08-07
Locale	vi-VN
Timezone	Asia/Ho_Chi_Minh
Currency	VND
Trigger event	Người dùng bấm xác nhận đơn bán hàng SO-NF-20260807-0142
Trigger actor	Sales Executive mô phỏng, mã vai trò ROLE-SE-01
Đối tượng bị kiểm tra	Khách hàng CUS-NF-000184 và toàn bộ công nợ mở liên quan
Current behavior hiện tại	Hệ thống cho phép ghi nhận đơn nháp nhưng dừng ở bước xác nhận nếu tổng dư nợ sau đơn vượt hạn mức mô phỏng
Underlying need	Nova Foods mô phỏng cần tránh phát sinh đơn vượt khả năng thu hồi trong khi vẫn giữ luồng bán hàng có kiểm soát
Business rule statement	Nếu tổng công nợ mở hiện có cộng với giá trị đơn mới lớn hơn hạn mức tín dụng đã được gán cho khách hàng thì hệ thống phải chuyển đơn sang trạng thái chờ rà soát tín dụng thay vì xác nhận tự động
Decision criteria	Hạn mức tín dụng, dư nợ phải thu đã ghi nhận, giá trị đơn bán hàng đang mở khác, giá trị đơn đang xác nhận, trạng thái đơn và phạm vi áp dụng
Recommendation	Chặn xác nhận tự động và tạo yêu cầu duyệt tín dụng thủ công
Decision authority	Credit Control Lead mô phỏng, mã vai trò ROLE-CC-01; không phải thẩm quyền pháp lý hay kế toán thực tế
Consequence if wrong	Nếu kiểm tra sai, hệ thống có thể cho phép vượt hạn mức hoặc chặn nhầm đơn hợp lệ, gây rủi ro công nợ, chậm giao hàng và sai lệch vận hành mô phỏng
Rule scope	Đơn bán hàng nội địa, thanh toán công nợ sau, khách hàng B2B mô phỏng
Rule boundary	Không áp dụng cho đơn tiền mặt, đơn xuất khẩu, đơn hàng mẫu không thu tiền, phiếu điều chỉnh công nợ, giao dịch đã hủy hoặc khách hàng chưa được gán hạn mức
Project assumption	Hạn mức 300.000.000 VND là giả định dự án, cần xác minh bởi Business Owner và Accounting Owner nếu dùng ngoài mô phỏng
Verification required	Cách tính công nợ mở, điều kiện miễn trừ và quy tắc duyệt ngoại lệ cần xác minh trước khi triển khai thực tế

Thành phần dữ liệu	Giá trị synthetic	Ghi chú kiểm soát
Sales order ID	SO-NF-20260807-0142	Đơn bán hàng mô phỏng
Customer ID	CUS-NF-000184	Khách hàng B2B mô phỏng
Customer name	Công ty TNHH Phân phối An Khang	Tên tổng hợp, không đại diện pháp nhân thật
Open receivables before order	210.000.000 VND	Dư nợ phải thu đã ghi nhận tại thời điểm kiểm tra
Other open sales orders	55.000.000 VND	Giá trị đơn bán hàng đang mở khác của cùng khách hàng
Order amount	42.900.000 VND	Giá trị đơn đang xác nhận
Credit limit	300.000.000 VND	Hạn mức mô phỏng
Calculated exposure after order	307.900.000 VND	210.000.000 + 55.000.000 + 42.900.000
Result of rule check	FAIL	Vượt hạn mức 7.900.000 VND
Required next state	PENDING_CREDIT_REVIEW	Trạng thái chờ rà soát tín dụng
Allowed next state	DRAFT hoặc PENDING_CREDIT_REVIEW	Sales Executive có thể sửa đơn ở DRAFT; hệ thống chuyển sang PENDING_CREDIT_REVIEW khi kiểm tra thất bại
Disallowed next state	CONFIRMED	Không được xác nhận tự động
Exception code	CRR-NF-20260807-0031	Mã yêu cầu rà soát tín dụng mô phỏng
Exception handling	Tạo yêu cầu rà soát tín dụng, khóa xác nhận tự động và chuyển case cho Credit Control Lead mô phỏng
Audit note	Ghi nhận lý do chặn: mức phơi nhiễm 307.900.000 VND vượt hạn mức 300.000.000 VND là 7.900.000 VND

Payload logic	Giá trị hoàn chỉnh
payload.orderId	SO-NF-20260807-0142
payload.customerId	CUS-NF-000184
payload.orderDate	2026-08-07
payload.orderAmount	42900000
payload.currency	VND
payload.openReceivablesAmount	210000000
payload.otherOpenSalesOrdersAmount	55000000
payload.creditLimitAmount	300000000
payload.exposureAfterOrder	307900000
payload.overLimitAmount	7900000
payload.ruleId	BR-NF-ORD-001
payload.decision	REJECT_CONFIRMATION
payload.nextState	PENDING_CREDIT_REVIEW
payload.reviewRequestId	CRR-NF-20260807-0031
payload.decisionReason	EXPOSURE_AFTER_ORDER_EXCEEDS_CREDIT_LIMIT

Bảng trạng thái	Trạng thái hiện có	Điều kiện vào	Điều kiện ra	Ý nghĩa nghiệp vụ
DRAFT	Đang soạn đơn	Người dùng tạo đơn mới hoặc sửa đơn chưa xác nhận	Gửi kiểm tra tín dụng, tiếp tục sửa đơn hoặc hủy đơn	Chưa cam kết bán hàng
PENDING_CREDIT_REVIEW	Chờ rà soát tín dụng	Quy tắc BR-NF-ORD-001 thất bại	Credit Control Lead mô phỏng xử lý yêu cầu theo quy trình mô phỏng hoặc người dùng sửa đơn để kiểm tra lại	Tạm dừng xác nhận tự động
CONFIRMED	Đã xác nhận	Quy tắc đạt và người dùng có quyền	Giao hàng hoặc lập chứng từ tiếp theo	Đơn hợp lệ để đi tiếp
CANCELLED	Hủy đơn	Người dùng hoặc nghiệp vụ hủy	Không đi tiếp	Đơn không còn hiệu lực

Quyết định nghiệp vụ	Lựa chọn 1	Lựa chọn 2	Lựa chọn 3	Tiêu chí chọn
Xử lý khi vượt hạn mức	Tự động xác nhận rồi theo dõi sau	Chặn xác nhận và chờ rà soát tín dụng	Tự động giảm số lượng hoặc giá trị đơn	Bảo vệ công nợ, rõ trách nhiệm, không tự sửa cam kết thương mại
Quyết định cho case này	Không chọn	Chọn	Không chọn	Vì 307.900.000 VND lớn hơn 300.000.000 VND, đơn phải dừng ở PENDING_CREDIT_REVIEW

Bản ghi lõi đã có danh tính quy tắc, actor, trigger, dữ kiện đầu vào, phép tính, kết quả, trạng thái, artifact ngoại lệ, thẩm quyền xử lý, trade-off và consequence. Các thành phần này làm rule kiểm thử được và truy vết được. Nếu thiếu dữ kiện công nợ, đơn mới, hạn mức, phép so sánh hoặc trạng thái kết quả, rule không đủ để cấu hình, kiểm thử hay huấn luyện BA.

Phân tích quyết định cho quy tắc kiểm tra hạn mức tín dụng

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp. Quy tắc áp dụng cho đơn bán SO-NF-20260807-0142 của khách hàng mô phỏng CUS-NF-000184 — Công ty TNHH Phân phối An Khang, lập lúc 2026-08-07 09:18:24 theo Asia/Ho_Chi_Minh. Mục đích là ngăn xác nhận đơn làm tổng mức phơi nhiễm tín dụng vượt mức rủi ro doanh nghiệp mô phỏng đã thiết lập.

Nội dung cần làm rõ	Dữ kiện hoàn chỉnh	Phân loại nguồn	Cầu nối suy luận
Sự thật nghiệp vụ	Dư nợ phải thu đã ghi nhận là 210.000.000 VND; giá trị đơn bán hàng đang mở khác là 55.000.000 VND; giá trị đơn mới là 42.900.000 VND; hạn mức tín dụng là 300.000.000 VND.	Dữ liệu giao dịch mô phỏng và project assumption	Tổng mức phơi nhiễm sau đơn = 210.000.000 + 55.000.000 + 42.900.000 = 307.900.000 VND.
Hành vi kiểm soát	Sales Executive yêu cầu xác nhận đơn. ERP phải kiểm tra tại thời điểm xác nhận, không dựa vào đánh giá thủ công ngoài hệ thống.	Nhu cầu nghiệp vụ mô phỏng	Kiểm tra tại điểm xác nhận dùng một công thức, lưu một kết quả và chặn đơn trước luồng giao hàng.
Nhu cầu gốc	Kiểm soát cần bảo vệ công nợ trước khi phát sinh nghĩa vụ giao hàng, đồng thời chỉ rõ ai xử lý ngoại lệ.	Nhu cầu nghiệp vụ mô phỏng	Trạng thái PENDING_CREDIT_REVIEW dừng xác nhận tự động và chuyển trách nhiệm xử lý cho vai trò tín dụng mô phỏng.
Kết quả áp dụng	307.900.000 VND > 300.000.000 VND; phần vượt là 7.900.000 VND.	Phép tính từ dữ liệu mô phỏng	Điều kiện vượt hạn mức đúng. Đơn không đủ điều kiện chuyển thẳng sang CONFIRMED.
Artifact kết quả	CRR-NF-20260807-0031 lưu yêu cầu rà soát cho đơn, khách hàng, đầu vào, phép tính, kết quả và lý do chặn.	Artifact mô phỏng do quy tắc tạo	Credit Control Lead mô phỏng có dữ liệu cần thiết để rà soát; Sales Executive có mã tham chiếu để theo dõi.

Phương án	Mô tả	Đánh giá theo tiêu chí	Kết luận
A	Tự động xác nhận đơn, sau đó gửi báo cáo theo dõi công nợ.	Nhanh cho bán hàng nhưng không phòng ngừa rủi ro trước giao hàng; trách nhiệm ngoại lệ không rõ tại điểm quyết định.	Không khuyến nghị.
B	Đưa đơn vào PENDING_CREDIT_REVIEW; Credit Control Lead mô phỏng rà soát yêu cầu CRR-NF-20260807-0031.	Có kiểm soát trước giao hàng, lưu trách nhiệm quyết định, giữ nguyên giá trị đơn và tạo traceability.	Khuyến nghị cho case mô phỏng.
C	Tự động giảm giá trị đơn xuống phần hạn mức còn lại.	Hệ thống tự thay đổi cam kết thương mại mà không có quyết định từ khách hàng hoặc bộ phận kinh doanh.	Không chọn.

Tiêu chí quyết định: bảo vệ công nợ trước giao hàng; xác định actor chịu trách nhiệm ngoại lệ; không tự thay đổi giá trị đơn; cung cấp trạng thái rõ cho Sales Executive; lưu artifact truy vết được.

Khuyến nghị và thẩm quyền quyết định: Case chọn phương án B. Credit Control Lead mô phỏng xử lý yêu cầu rà soát tín dụng. Business Owner mô phỏng xác nhận mức chấp nhận rủi ro của chính sách tín dụng. Accounting Owner mô phỏng xác minh cách tính công nợ mở nếu rule dùng ngoài học liệu. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận khuyến nghị và truy vết; không có thẩm quyền phê duyệt chính sách, quyết định kế toán hoặc cho phép triển khai production. Trạng thái IN_REVIEW nghĩa là chưa có quyết định phê duyệt.

Nếu chọn sai hành vi và xác nhận đơn vượt hạn mức, Nova Foods mô phỏng có thể giao hàng khi tổng mức phơi nhiễm là 307.900.000 VND, cao hơn mức giả định 300.000.000 VND. Hậu quả là tăng rủi ro thu hồi công nợ và làm mờ trách nhiệm phê duyệt. Nếu hệ thống chặn đơn không vượt hạn mức, doanh nghiệp mô phỏng tạo chậm trễ bán hàng không cần thiết. Điều kiện bắt buộc là so sánh chính xác tổng dư nợ phải thu đã ghi nhận + giá trị đơn bán hàng đang mở khác + giá trị đơn đang xác nhận với hạn mức được gán cho cùng khách hàng tại thời điểm xác nhận.

4. Tier 3 ? Fully Completed Nova Foods Case: Evidence and Traceability

Trong ca mô phỏng Nova Foods, logic kiểm soát tín dụng của đơn SO-NF-2026-0807-014 phải được đọc từ nguyên tắc gốc: tổng công nợ mở cộng giá trị đơn mới nếu vượt hạn mức thì hệ thống không được cho luồng giao hàng tiếp tục. Từ nguyên tắc đó suy ra rằng mọi đường đi “xấu” đều phải được ghi nhận rõ: dữ liệu đầu vào thiếu, trạng thái đơn không hợp lệ, hạn mức không xác định, số tiền bị làm tròn sai, hoặc người dùng cố sửa số liệu sau khi đã có dấu hiệu vượt ngưỡng. Vì đây là dữ liệu tổng hợp cho mục đích giáo dục, các bằng chứng bên dưới chỉ đóng vai trò traceability cho corpus, không phải xác nhận vận hành production.

4.1 Bảng ngoại lệ và đường đi âm tính cho cùng kịch bản

Mã ngoại lệ	Đường đi âm tính	Dấu hiệu kích hoạt	Hành vi mong đợi của hệ thống	Lý do nghiệp vụ
EX-CR-001	customer_credit_limit rỗng	Đơn SO-NF-2026-0807-014 có công nợ mở nhưng không có hạn mức đã gán	Dừng xác nhận, trả trạng thái NEED_CREDIT_LIMIT_VERIFICATION	Không có mẫu số thì không thể so sánh vượt hay không vượt; quyết định phải chuyển sang bước kiểm tra dữ liệu
EX-CR-002	open_ar_balance âm hoặc khác 0 nhưng không có chứng từ đối soát	Số công nợ mở không khớp sổ phụ mô phỏng	Chặn tự động duyệt và ghi cờ VERIFICATION_REQUIRED	Dữ liệu đầu vào sai làm hỏng kết quả so sánh hạn mức
EX-CR-003	Làm tròn tiền sai đơn vị	Chênh lệch giữa 26.499.999 VND và 26.500.000 VND bị xử lý thành cùng một ngưỡng	Bắt buộc dùng so sánh số nguyên theo VND, không làm tròn trước khi so sánh	Với tiền tệ VND, một đơn vị có thể đổi kết quả kiểm soát
EX-CR-004	Người dùng sửa giá trị đơn sau khi đã qua bước kiểm tra	order_total_amount thay đổi nhưng cờ kiểm tra cũ vẫn còn	Tạo lại kiểm tra tín dụng và ghi dấu kiểm tra cũ là hết hiệu lực	Kết quả kiểm soát phải bám theo dữ liệu hiện hành, không bám theo bản cũ
EX-CR-005	Trạng thái đơn không cho phép xác nhận	Đơn còn ở DRAFT hoặc đã CANCELLED nhưng được đưa vào luồng kiểm tra giao hàng	Từ chối, ghi lý do INVALID_ORDER_STATE	Một quy tắc kiểm soát chỉ có nghĩa khi đối tượng ở trạng thái hợp lệ
EX-CR-006	Cố tình bỏ qua bước phê duyệt ngoại lệ	Hệ thống hoặc người dùng cố chuyển sang giao hàng dù đã vượt hạn mức	Khóa hành động giao hàng, mở bản ghi escalated case	Vượt hạn mức là tình huống cần người có thẩm quyền quyết định, không phải tự động bỏ qua

4.2 Bảng tham chiếu bằng chứng cho cùng kịch bản

Mã bằng chứng	Tên tài liệu/artefact	Nguồn phân loại	Nội dung được dùng làm bằng chứng	Kết nối traceability
EV-AR-014-01	03-templates/TMPL-RULE-001-business-rule-catalog.md	Artefact template được kiểm soát	Cấu trúc catalog quy tắc cho phép gắn rule, exception, AC và traceability vào cùng một dòng logic	Liên kết từ BR sang AC và sang test basis
EV-SRC-001	00-research/00_SOURCE_MAP.md	Nguồn nền tảng đã kiểm soát	Xác định case Nova Foods là mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, timezone Asia/Ho_Chi_Minh	Bảo đảm mọi suy luận chỉ dùng trong corpus mô phỏng
EV-DATA-014-01	Bản ghi tổng hợp SO-NF-2026-0807-014	Dữ liệu mô phỏng nội bộ	Giá trị đơn 26.500.000 VND, công nợ mở trước đó 300.000.000 VND, hạn mức gán 300.000.000 VND	Chứng minh phép so sánh vượt hạn mức bằng số học
EV-REQ-014-01	Yêu cầu nghiệp vụ mô phỏng cho kiểm soát tín dụng	Nguồn nội bộ trong corpus	Đơn vượt hạn mức không được xác nhận giao hàng tự động	Là đầu ra mong đợi của rule
EV-TC-014-01	Test case tổng hợp cho đường đi âm tính	Nguồn kiểm thử mô phỏng	Bước kiểm tra phải tạo trạng thái chặn và nêu lý do rõ ràng	Chứng minh rule có thể kiểm thử
EV-ESC-014-01	Bản ghi escalated case mô phỏng	Nguồn điều phối nội bộ	Chuyển sang vai trò có thẩm quyền khi vượt ngưỡng	Chứng minh ngoại lệ không bị xử lý ngầm

4.3 Giả định, mục cần xác minh và ranh giới sử dụng

Loại	Nội dung	Cách diễn giải đúng	Trạng thái kiểm soát
Giả định dự án	Giá trị tiền tệ dùng so sánh là số nguyên VND, không dùng ngoại tệ và không làm tròn trước khi kiểm soát	Đây là giả định mô hình để test logic, không phải quy định kế toán chính thức	Chỉ dùng trong corpus mô phỏng
Giả định dự án	open_ar_balance đại diện cho công nợ mở tại thời điểm kiểm tra	Đây là mô hình logic phục vụ traceability, không thay thế sổ kế toán thực	Cần đối chiếu với owner kế toán nếu dùng ngoài học liệu
Verification required	Cách tính công nợ mở có bao gồm đơn đang chờ xác nhận hay không	Phải xác minh với Accounting Owner hoặc role được ủy quyền	Chưa được kết luận trong v0.9.0
Verification required	Tác động của quy định hóa đơn, chứng từ và kế toán lên thời điểm ghi nhận công nợ	Phải đối chiếu Luật Kế toán và Nghị định 123/2020/NĐ-CP bản hiện hành	Không suy diễn thành nghĩa vụ production nếu chưa xác minh
Verification required	Cách xử lý đồng thời nhiều ngoại lệ trong cùng một đơn	Phải xác minh với Business Owner mô phỏng và QA	Không tự gộp nếu chưa có quy tắc đã ghi nhận
Verification required	Có cần giữ lịch sử mọi lần thay đổi hạn mức hay chỉ trạng thái cuối	Cần xác minh với data governance owner	Không được tự ý xóa dấu vết kiểm tra

4.4 Bản ghi escalation cho ngoại lệ vượt hạn mức của cùng kịch bản

Trường	Giá trị
Escalation ID	ESC-CR-014-2026-08-07
Đối tượng	Đơn bán hàng SO-NF-2026-0807-014
Trigger	Tổng công nợ mở 300.000.000 VND cộng giá trị đơn mới 26.500.000 VND làm vượt hạn mức 300.000.000 VND
Lý do escalation	Hành vi vượt ngưỡng không thể tự duyệt vì tạo thêm rủi ro công nợ và đòi hỏi quyết định có thẩm quyền
Vai trò nhận	Credit Controller mô phỏng trước, sau đó Business Owner mô phỏng nếu cần chấp nhận ngoại lệ chính sách
Kết quả mong đợi	Đơn ở trạng thái chặn giao hàng, có lý do rõ ràng, và chờ quyết định thủ công
Bằng chứng kèm theo	EV-DATA-014-01, EV-TC-014-01, EV-ESC-014-01
Trạng thái kiểm soát	IN_REVIEW; chưa baseline, chưa suy ra approval, chưa được xem là chấp thuận vận hành

4.5 Kết luận traceability cho micro-batch này

Từ dữ kiện mô phỏng đã nêu, mọi đường đi âm tính đều quay về cùng một nguyên tắc: nếu dữ liệu không đủ, không nhất quán, hoặc vượt hạn mức thì hệ thống phải dừng tự động và chuyển sang xác minh hoặc escalation. Điều này giữ cho chuỗi NEED → REQ → BR → AC → DATA/API → TC → DEF/CR không bị đứt tại điểm kiểm soát tín dụng của Nova Foods mô phỏng. Các mục pháp lý, kế toán và vận hành còn đánh dấu Verification required vì chưa có xác minh chính thức trong corpus này; do đó chúng chỉ là ranh giới kiểm soát học liệu, không phải cam kết production.

Ma trận truy vết đầu-cuối cho quy tắc hạn mức tín dụng của Nova Foods mô phỏng

Chuỗi truy vết (traceability, tức khả năng lần ngược từ nhu cầu đến kiểm thử và phát hiện) dưới đây dùng dữ liệu tổng hợp בלבד cho cùng một kịch bản: đơn bán hàng mô phỏng có tổng giá trị 326.500.000 VND, trong khi hạn mức tín dụng mô phỏng của khách hàng là 300.000.000 VND. Các ID là liên kết của case trong template /03-templates/TMPL-RULE-001-business-rule-catalog.md; IN_REVIEW không được hiểu là baseline hoặc phê duyệt.

Họ ID	ID canonical của case	Nội dung được truy vết	Cầu nối bằng chứng và suy luận	Nguồn hoặc tệp liên quan	Trạng thái
NEED	NEED-014	Ngăn Nova Foods mô phỏng giải phóng đơn hàng khi tổng công nợ sau đơn vượt hạn mức tín dụng được cấu hình.	Dữ kiện đầu vào là tổng giá trị sau đơn 326.500.000 VND lớn hơn 300.000.000 VND; vì vậy nhu cầu kiểm soát là chặn tự động, không tự suy ra quyền ngoại lệ.	Dữ liệu tổng hợp của case; /01-curriculum/CANONICAL_BUSINESS_RULES.md	IN_REVIEW
REQ	REQ-014	ERP phải tính tổng nghĩa vụ tín dụng sau đơn, so sánh với hạn mức và trả kết quả BLOCKED_CREDIT_LIMIT khi vượt ngưỡng.	REQ-014 cụ thể hóa NEED-014 thành hành vi có thể kiểm thử: có đầu vào, phép so sánh và trạng thái đầu ra; không thêm điều kiện pháp lý hoặc kế toán chưa được xác minh.	/03-templates/TMPL-RULE-001-business-rule-catalog.md; dữ liệu tổng hợp	IN_REVIEW
BR	BR-014	Nếu credit_exposure_after_order > credit_limit, hệ thống không cho phép chuyển đơn sang trạng thái giải phóng giao hàng; phải ghi lý do chặn và chuyển xử lý thủ công.	326.500.000 > 300.000.000, nên điều kiện đúng và nhánh chặn được kích hoạt. Quy tắc chỉ mô tả logic nghiệp vụ mô phỏng, không phải chính sách vận hành thực tế.	/01-curriculum/CANONICAL_BUSINESS_RULES.md	IN_REVIEW
AC	AC-014-01	Với khách hàng mô phỏng CUST-NF-014, hạn mức 300.000.000 VND và tổng sau đơn 326.500.000 VND, hệ thống giữ đơn ở CREDIT_BLOCKED, hiển thị lý do vượt hạn mức và không tạo lệnh giải phóng giao hàng.	Tiêu chí chấp nhận (acceptance criterion, điều kiện để xác nhận kết quả) kiểm tra trực tiếp ba hệ quả của BR-014: trạng thái, thông báo và không phát sinh hành động giao hàng.	/03-templates/TMPL-RULE-001-business-rule-catalog.md; EV-TC-014-01	IN_REVIEW
DATA/API	DATA-014-01	Trường tổng hợp: customer_id=CUST-NF-014, credit_limit=300000000, open_receivable=280000000, order_total=46500000, credit_exposure_after_order=326500000, currency=VND.	Phép tính 280.000.000 + 46.500.000 = 326.500.000; giá trị này là đầu vào đủ để kiểm tra điều kiện của BR-014.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; dữ liệu tổng hợp	IN_REVIEW
DATA/API	API-014-01	API mô phỏng POST /simulated/order-credit-check nhận DATA-014-01 và trả decision=BLOCK, reason_code=CREDIT_LIMIT_EXCEEDED, release_delivery=false.	Payload trả về phải phản ánh cùng một quyết định với BR-014 và cung cấp đủ trường để AC-014-01 kiểm tra; đây là mô tả API giáo dục, không phải endpoint production.	Đặc tả tổng hợp trong template; nguồn tham chiếu thuật ngữ là OpenAPI Specification 3.1.1	IN_REVIEW
TC	TC-014-01	Kiểm thử hộp đen (black-box test, kiểm tra qua đầu vào và đầu ra mà không dựa vào mã nguồn) với DATA-014-01.	Kết quả mong đợi: HTTP 200, decision=BLOCK, reason_code=CREDIT_LIMIT_EXCEEDED, release_delivery=false, trạng thái đơn CREDIT_BLOCKED; kết quả được liên kết với AC-014-01.	EV-TC-014-01; dữ liệu tổng hợp	IN_REVIEW
DEF	DEF-014-01	Phát hiện mô phỏng: bản triển khai giả định trả decision=ALLOW dù 326.500.000 VND vượt 300.000.000 VND.	Sai khác giữa kết quả quan sát và AC-014-01 chứng minh lỗi nằm trên đường BR-014 → API-014-01 → TC-014-01; không được coi đây là lỗi production đã xác nhận.	EV-TC-014-01; ghi nhận lỗi tổng hợp	IN_REVIEW
CR	CR-014-01	Chưa tạo yêu cầu thay đổi; cần sửa logic kiểm tra trước khi xem xét phát hành bản sửa mô phỏng.	DEF-014-01 chỉ là phát hiện kiểm thử; việc chuyển thành change request (yêu cầu thay đổi) cần quyết định của vai trò có thẩm quyền, nên không tự tạo trạng thái hoặc phê duyệt.	EV-ESC-014-01; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	NOT_CREATED — Verification required

Kết luận kiểm tra: đường truy vết đầy đủ là NEED-014 → REQ-014 → BR-014 → AC-014-01 → DATA-014-01/API-014-01 → TC-014-01 → DEF-014-01; CR-014-01 chỉ được ghi nhận là chưa tạo vì chưa có quyết định thay đổi có thẩm quyền. EV-TC-014-01 là bằng chứng kiểm thử và EV-ESC-014-01 là tham chiếu escalation đã có trong case; cả hai đều thuộc dữ liệu tổng hợp Nova Foods mô phỏng, không tạo baseline, approval hoặc kết luận sử dụng production.

Bảng quyết định hoàn chỉnh — Quy tắc phân bổ lô theo hạn dùng cho đơn bán mô phỏng

Bảng quyết định (decision table) biểu diễn đầy đủ tổ hợp điều kiện và kết quả của quy tắc BR-NF-INV-001 — Chỉ phân bổ lô hàng sẵn sàng và còn hạn dùng tối thiểu. Trong Nova Foods Trading & Manufacturing mô phỏng, bảng này là bằng chứng có cấu trúc để người phân tích, lập trình viên và kiểm thử viên cùng diễn giải một quy tắc mà không suy đoán từ câu văn tự do. Dữ liệu, mã đơn và mã lô dưới đây đều là dữ liệu tổng hợp; đây là Project assumption phục vụ học liệu, chưa là cấu hình ERP, baseline hoặc quyết định vận hành thực tế.

Thuộc tính kiểm soát	Giá trị
Rule ID	BR-NF-INV-001
Tên quy tắc	Chỉ phân bổ lô hàng sẵn sàng và còn hạn dùng tối thiểu
Ngữ cảnh nghiệp vụ	Phân bổ tồn kho lô cho đơn bán nội địa mô phỏng
Đơn vị thời gian	Ngày dương lịch theo Asia/Ho_Chi_Minh
Ngưỡng hạn dùng	07 ngày tại thời điểm hệ thống đánh giá phân bổ
Nguồn phân loại	PROJECT_ASSUMPTION — Nova Foods simulated educational case
Cầu nối suy luận	Lô không ở trạng thái sẵn sàng, không đủ số lượng, hoặc không còn tối thiểu 07 ngày hạn dùng không thể thỏa đồng thời mục tiêu giao hàng và kiểm soát chất lượng giả định; vì vậy kết quả phân bổ chỉ là ALLOW khi cả bốn điều kiện đều đúng.
Verification required	Business Owner và Quality Owner cần xác nhận ngưỡng 07 ngày, trạng thái lô hợp lệ và chính sách phân bổ trước bất kỳ áp dụng thực tế nào.

Điều kiện / Hành động	R01	R02	R03	R04	R05	R06	R07	R08	R09	R10	R11	R12	R13	R14	R15	R16
Đơn bán có trạng thái RELEASED?	Có	Có	Có	Có	Có	Có	Có	Có	Không	Không	Không	Không	Không	Không	Không	Không
Lô có trạng thái AVAILABLE?	Có	Có	Có	Có	Không	Không	Không	Không	Có	Có	Có	Có	Không	Không	Không	Không
Hạn dùng còn từ 07 ngày trở lên?	Có	Có	Không	Không	Có	Có	Không	Không	Có	Có	Không	Không	Có	Có	Không	Không
Số lượng khả dụng của lô đủ yêu cầu?	Có	Không	Có	Không	Có	Không	Có	Không	Có	Không	Có	Không	Có	Không	Có	Không
Kết quả phân bổ	ALLOW	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE	DO_NOT_ALLOCATE
Mã lý do quyết định	ALLOC-ELIGIBLE	ALLOC-INSUFFICIENT-QTY	ALLOC-EXPIRY-BELOW-MIN	ALLOC-EXPIRY-AND-QTY	ALLOC-LOT-NOT-AVAILABLE	ALLOC-LOT-AND-QTY	ALLOC-LOT-AND-EXPIRY	ALLOC-LOT-EXPIRY-QTY	ALLOC-ORDER-NOT-RELEASED	ALLOC-ORDER-AND-QTY	ALLOC-ORDER-AND-EXPIRY	ALLOC-ORDER-EXPIRY-QTY	ALLOC-ORDER-AND-LOT	ALLOC-ORDER-LOT-QTY	ALLOC-ORDER-LOT-EXPIRY	ALLOC-NO-ELIGIBLE-CONDITION

Bộ dữ liệu kiểm tra tổng hợp	Giá trị
Mã đơn bán	SO-NF-20260807-001
Trạng thái đơn	RELEASED
Mã hàng	FG-NF-TRA-500G
Tên hàng mô phỏng	Trà gạo lứt rang Nova 500 g
Số lượng yêu cầu	120 gói
Mã kho	WH-HCM-FG-01
Mã lô được đánh giá	LOT-NF-TRA-260801-A
Trạng thái lô	AVAILABLE
Số lượng khả dụng	180 gói
Ngày đánh giá	2026-08-07
Ngày hết hạn	2026-08-21
Số ngày hạn dùng còn lại	14 ngày
Quy tắc được kích hoạt	R01
Kết quả mong đợi	ALLOW với mã ALLOC-ELIGIBLE; hệ thống có thể giữ lại 120 gói từ LOT-NF-TRA-260801-A cho đơn SO-NF-20260807-001.

Bộ dữ liệu trên kích hoạt R01 vì bằng chứng tính toán là: đơn ở RELEASED; lô ở AVAILABLE; 2026-08-21 trừ 2026-08-07 bằng 14 ngày, lớn hơn ngưỡng giả định 07 ngày; và 180 gói khả dụng lớn hơn 120 gói yêu cầu. Bảng không suy diễn nghĩa vụ pháp lý, chất lượng thực tế hay phương pháp hạch toán; việc xác nhận các yếu tố đó vẫn thuộc vai trò có thẩm quyền.

5. Tier 4 ? Senior BA Quality Gate

Senior BA Quality Gate là cổng kiểm tra trước baseline, tức điểm kiểm soát mà Senior Business Analyst (BA cấp cao) dùng để xác định rule catalog đã đủ điều kiện chuyển sang bước xem xét có thẩm quyền hay chưa. Cổng này không phải phê duyệt, không xác nhận tuân thủ pháp lý, kế toán hoặc bảo mật, và không cho phép sử dụng production. Tại v0.9.0, trạng thái corpus và mọi artifact Nova Foods vẫn là IN_REVIEW; Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục với dữ liệu tổng hợp.

Quy ước kết quả: PASS nghĩa là tiêu chí có bằng chứng kiểm tra đầy đủ và không có mâu thuẫn đã biết; FAIL nghĩa là tiêu chí chưa đạt nhưng có thể sửa trong phạm vi BA kiểm soát; STOP nghĩa là phải dừng chuyển tiếp vì thiếu đầu vào trọng yếu, mâu thuẫn canonical hoặc vượt thẩm quyền; ESCALATE nghĩa là BA phải lập gói vấn đề cho đúng owner chuyên môn, đồng thời giữ nguyên nhãn Verification required cho đến khi có kết luận được ghi nhận trong artifact kiểm soát.

ID kiểm tra	Nhóm chất lượng	Câu hỏi kiểm tra từ nguyên tắc đầu tiên	Điều kiện PASS	Điều kiện FAIL	Điều kiện STOP	Tuyến escalation
QG-RULE-01	Tính đầy đủ	Rule có đủ điều kiện kích hoạt, dữ liệu đầu vào, logic quyết định, kết quả, ngoại lệ, thông báo và mã lý do không?	Mỗi thành phần được điền rõ, có thể đọc độc lập và không dùng placeholder ở Tier 3.	Thiếu diễn giải phụ, ví dụ không đủ hoặc nhãn trường chưa nhất quán.	Thiếu điều kiện, kết quả hoặc ngoại lệ khiến hệ thống không thể xác định hành vi.	Business Owner để làm rõ chính sách; BA cập nhật cấu trúc sau khi nhận đầu vào.
QG-RULE-02	Tính nhất quán	Các giá trị, tên trường, trạng thái, mã ID và thuật ngữ có khớp catalog canonical, data dictionary và traceability registry không?	Dùng đúng định danh canonical, cùng một khái niệm chỉ có một tên và không có xung đột logic.	Lỗi chính tả, định dạng hoặc diễn đạt chưa thống nhất nhưng không đổi nghĩa.	Một ID tham chiếu sai, một trạng thái mâu thuẫn, hoặc hai rule cho cùng đầu vào tạo hai kết quả khác nhau.	Principal IT Business Analyst / Technical Curriculum Author để điều phối; Business Owner hoặc Architect khi xung đột ảnh hưởng quyết định nghiệp vụ hoặc thiết kế.
QG-RULE-03	Khả năng kiểm thử	Một tester độc lập có thể tạo dữ liệu đầu vào, thực hiện bước kiểm tra và quan sát kết quả mong đợi không?	Có dữ liệu kiểm thử dương, âm và biên; kết quả quan sát được gồm quyết định, mã lý do hoặc thay đổi trạng thái.	Thiếu một ca biên nhưng logic và kết quả vẫn xác định.	Rule dùng từ mơ hồ như “phù hợp”, “đủ tốt”, “kịp thời” mà không có tiêu chí đo hoặc nguồn xác định ngưỡng.	QA/Test Lead về chiến lược kiểm thử; Business Owner về ngưỡng nghiệp vụ.
QG-RULE-04	Truy vết	Có thể lần từ rule đến nguồn, yêu cầu, dữ liệu, quyết định và test basis, rồi lần ngược từ các đối tượng đó về rule không?	Có liên kết ID hai chiều và mỗi liên kết nêu rõ vai trò: nguồn, dữ liệu, test basis hoặc tác động.	Một liên kết chưa có mô tả vai trò nhưng ID đích tồn tại.	Không xác định được nguồn của rule, hoặc rule không thể liên kết với test basis hay dữ liệu sử dụng.	Principal IT Business Analyst / Technical Curriculum Author để khôi phục traceability; Business Owner nếu thiếu nguồn quyết định.
QG-RULE-05	Thẩm quyền nguồn	Nguồn có đúng loại thẩm quyền cho kết luận đang được ghi không?	Chính sách nội bộ thuộc Business Owner; diễn giải kế toán thuộc Accounting Owner; kết luận pháp lý thuộc Legal Owner; kiểm soát kỹ thuật thuộc Security hoặc Architect.	Nguồn đáng tin nhưng chưa xác định rõ owner xác nhận.	Dùng tài liệu học thuật, good practice, hoặc luật chưa được owner chuyên môn xác minh để khẳng định nghĩa vụ vận hành bắt buộc.	Legal Owner, Accounting Owner, Security Owner, Architect hoặc Business Owner tùy bản chất kết luận.
QG-RULE-06	Ownership	Mỗi quyết định, dữ liệu tham chiếu, ngoại lệ và thay đổi rule có owner chịu trách nhiệm xác định không?	Owner và giới hạn thẩm quyền được ghi rõ; BA chỉ giữ vai trò phân tích, điều phối và truy vết.	Owner đã biết nhưng chưa có điểm liên hệ hoặc cơ chế phản hồi.	Không có owner, hoặc BA bị yêu cầu tự quyết thay vai trò pháp lý, kế toán, bảo mật hay vận hành.	Sponsor hoặc Business Owner để chỉ định owner có thẩm quyền.
QG-RULE-07	Bảo mật và quyền riêng tư	Rule có làm lộ, thu thập, lưu giữ, truyền hoặc hiển thị dữ liệu cá nhân hay dữ liệu nhạy cảm không?	Phân loại dữ liệu, nguyên tắc truy cập và nhu cầu xác minh được nêu; không khẳng định tuân thủ nếu chưa có Security/Legal review.	Có dấu hiệu dữ liệu cần phân loại nhưng phạm vi dữ liệu chưa hoàn chỉnh.	Rule yêu cầu xử lý dữ liệu cá nhân hoặc thay đổi quyền truy cập mà chưa có đánh giá Security và Legal.	Security Owner và Legal Owner; tham chiếu Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP chỉ trong phạm vi cần xác minh chính thức.
QG-RULE-08	Ranh giới pháp lý, kế toán và an toàn thực phẩm	Rule có bị diễn giải thành nghĩa vụ pháp lý, hạch toán, hóa đơn, thuế, truy xuất hoặc thu hồi thực tế không?	Nội dung chỉ mô tả giả định dự án hoặc yêu cầu đã được owner có thẩm quyền xác nhận; giới hạn được ghi rõ.	Cần bổ sung nhãn project assumption hoặc Verification required.	Rule tự kết luận cách hạch toán, nghĩa vụ hóa đơn, tuân thủ dữ liệu cá nhân hoặc nghĩa vụ an toàn thực phẩm.	Legal Owner, Accounting Owner và domain owner an toàn thực phẩm tương ứng.
QG-RULE-09	Tác động thay đổi	Nếu thay đổi ngưỡng, trạng thái, trường dữ liệu hoặc ngoại lệ, các artifact và kiểm thử bị ảnh hưởng có được xác định không?	Có danh sách tác động tối thiểu đến rule liên quan, data dictionary, requirement, API hoặc UI nếu có, test case và traceability.	Chưa phân loại mức độ tác động nhưng đã biết phạm vi artifact bị ảnh hưởng.	Thay đổi làm đứt liên kết, đổi ý nghĩa dữ liệu, đổi quyền truy cập hoặc tạo mâu thuẫn với rule khác mà chưa có phân tích tác động.	Architect cho tác động kỹ thuật; QA/Test Lead cho hồi quy; Business Owner cho tác động chính sách.

Quy tắc tổng hợp quyết định: chỉ được ghi nhận READY_FOR_NEXT_REVIEW khi tất cả mục bắt buộc đạt PASS, hoặc các FAIL còn lại chỉ là lỗi trình bày đã có hành động sửa trong cùng phạm vi BA và không làm thay đổi ý nghĩa rule. Chỉ một kết quả STOP đã đủ để ngăn rule chuyển sang bước baseline. Một kết quả ESCALATE không được bị chuyển thành PASS bằng suy đoán của BA; hồ sơ rule phải giữ rõ câu hỏi, bằng chứng hiện có, owner cần kết luận và tác động nếu chưa được giải quyết.

5.x Tiêu chí Senior BA cho 8 trụ kiểm tra: đầy đủ, nhất quán, kiểm thử được, truy vết được, thẩm quyền nguồn, sở hữu, ranh giới bảo mật/pháp lý/kế toán và tác động thay đổi

Trong /03-templates/TMPL-RULE-001-business-rule-catalog.md, mục quality gate này dùng để chặn sai lệch trước baseline cho case Nova Foods mô phỏng; dữ liệu chỉ là synthetic data, không phải dữ liệu vận hành thật. Ở đây, checklist là danh sách kiểm tra có điều kiện đạt/không đạt, còn testable là “kiểm thử được” theo nghĩa một rule phải chuyển thành test case hoặc tiêu chí kiểm thử quan sát được; traceability là truy vết liên kết giữa rule, nguồn, yêu cầu, dữ liệu và kiểm thử; source authority là mức thẩm quyền của nguồn; ownership là chủ thể chịu trách nhiệm nội dung; change impact là phạm vi bị ảnh hưởng khi rule đổi. Cách chấm phải dựa trên bằng chứng từ các artifact đã có trong corpus, không suy diễn vượt nguồn.

Trụ kiểm tra	Câu hỏi Senior BA cần hỏi	PASS	FAIL	STOP / ESCALATE	Bằng chứng tối thiểu cần giữ
Đầy đủ	Rule đã nêu đủ điều kiện kích hoạt, ngoại lệ, kết quả mong đợi, đối tượng áp dụng và phạm vi không?	Có thể đọc một lần để hiểu khi nào rule chạy và khi nào không chạy.	Thiếu một thành phần làm người đọc không thể tạo test hoặc không hiểu phạm vi.	STOP nếu thiếu làm rule không thể dùng làm basis cho thiết kế, kiểm thử hoặc đào tạo.	Rule text, trường dữ liệu, exception, điều kiện đầu vào/đầu ra.
Nhất quán	Rule có mâu thuẫn với catalog quy tắc khác, data dictionary, API contract hoặc màn hình UI không?	Thuật ngữ, trạng thái, mã và đơn vị đo khớp giữa các artifact.	Có chỗ dùng cùng một khái niệm nhưng định nghĩa khác nhau.	ESCALATE nếu mâu thuẫn vượt quyền BA, ví dụ khác nghĩa với quy định pháp lý hoặc logic kế toán.	Cross-reference tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, API/UI spec nếu có.
Kiểm thử được	Có thể viết test case cho rule bằng dữ liệu đầu vào xác định không?	Có input, expected output, nhãn lỗi và điều kiện biên đủ rõ để thiết kế test.	Rule chỉ mô tả ý định chung, không thể biến thành test.	STOP nếu rule không đo được hoặc không có cách xác minh quan sát được.	Test condition, expected result, boundary value, negative case.
Truy vết được	Có thể lần từ rule về nguồn và từ rule sang test case, requirement, dữ liệu không?	Mỗi rule có ID ổn định và link tới nguồn xác minh hợp lệ.	ID thay đổi tùy đoạn văn hoặc thiếu link ngược.	STOP nếu không còn biết rule này đến từ đâu hoặc ai chịu trách nhiệm.	Rule ID, source ID, filename, upstream/downstream trace links.
Thẩm quyền nguồn	Nguồn nào là nguồn chân lý cho rule này?	Nguồn được xếp đúng mức: tiêu chuẩn, luật, chính sách nội bộ hoặc giả định dự án.	Dùng nguồn tham khảo như thể là luật bắt buộc hoặc ngược lại.	ESCALATE khi nguồn chính thức cần legal/accounting/owner xác nhận; không tự nâng cấp good practice thành nghĩa vụ pháp lý.	Trích dẫn nguồn theo nhóm: BABOK, ISO/IEC/IEEE 29148, ISTQB, OpenAPI, WCAG, OWASP, luật Việt Nam.
Ownership	Ai chịu trách nhiệm duy trì rule và ai có quyền quyết định nội dung?	Có owner rõ ràng và giới hạn quyền rõ ràng.	Không biết ai sửa, ai duyệt, ai giải thích.	ESCALATE nếu cần Business Owner, Legal Owner, Accounting Owner, Security hoặc Domain Owner; BA không tự thay thế.	Metadata owner, trách nhiệm, giới hạn thẩm quyền, change log.
Bảo mật / riêng tư / pháp lý / kế toán	Rule có đụng tới dữ liệu cá nhân, chứng từ, hóa đơn, kiểm toán, thuế hoặc bảo mật không?	Các ranh giới được ghi là project assumption hoặc Verification required khi chưa xác minh chính thức.	Viết như thể đã tuân thủ luật hoặc đã được pháp chế chấp thuận.	STOP với nội dung có thể vi phạm bảo mật hoặc quyền riêng tư; ESCALATE khi cần legal/accounting/security review.	Nhãn phân loại dữ liệu, phạm vi truy cập, luật tham chiếu, owner cần xác nhận.
Tác động thay đổi	Nếu rule đổi, phần nào phải đổi theo?	Có danh sách tác động tới rule liên quan, test, data dictionary, API/UI, traceability.	Thay rule nhưng không biết ảnh hưởng đến đâu.	STOP nếu thay đổi phá vỡ traceability hoặc tạo xung đột chuỗi học; ESCALATE nếu ảnh hưởng liên phòng ban.	Impact note, dependent artifacts, regression scope, change reason.

Nguồn dùng cho trụ kiểm tra này chỉ nằm trong ranh giới đã xác minh của corpus: BABOK để dùng thuật ngữ BA, ISO/IEC/IEEE 29148 để bám nguyên tắc yêu cầu, ISTQB để bám tư duy kiểm thử, OpenAPI/WCAG/OWASP khi có API, khả năng truy cập hoặc bảo mật, và luật Việt Nam chỉ khi cần đánh dấu ranh giới pháp lý. Với Nova Foods mô phỏng, mọi suy luận về pháp lý, kế toán, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật phải ghi rõ là Verification required nếu chưa có văn bản chính thức trong corpus; không được chuyển giả định thành nghĩa vụ bắt buộc.

Nếu một rule đạt PASS ở đầy đủ, nhất quán và kiểm thử được nhưng FAIL ở thẩm quyền nguồn hoặc ranh giới pháp lý, kết luận vẫn không thể xem là sẵn sàng baseline vì nguồn chưa đủ thẩm quyền. Nếu rule có thể kiểm thử nhưng không truy vết được, chất lượng vẫn chưa đạt vì test không chứng minh được nguồn gốc yêu cầu. Nếu rule có tác động thay đổi nhưng chưa có danh sách ảnh hưởng, Senior BA phải dừng ở mức ghi nhận rủi ro thay đổi, không được suy diễn rằng “ít ảnh hưởng” khi chưa có bằng chứng.

Áp dụng Quality Gate cho ví dụ Nova Foods đã hoàn tất ở Tier 3

Đối tượng được rà soát là ví dụ quy tắc nghiệp vụ Nova Foods tại Tier 3 và Tier 3 Evidence and Traceability của tệp /03-templates/TMPL-RULE-001-business-rule-catalog.md. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu được hiểu là dữ liệu tổng hợp, dùng locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND. Kết quả dưới đây là ghi nhận review tại 2026-08-07, trạng thái corpus IN_REVIEW, phiên bản v0.9.0; không phải baseline, phê duyệt, xác nhận tuân thủ hoặc cho phép dùng production.

Hạng mục quality gate đã áp dụng	Bằng chứng/logic đối chiếu	Kết quả	Phát hiện và xử lý ghi nhận
Tính đầy đủ	Tier 3 được mô tả là bản ghi đã điền đầy đủ; tuy nhiên gói đầu vào của micro-batch không cung cấp nội dung từng trường, ngoại lệ, quyết định và liên kết của bản ghi đó để đối chiếu độc lập.	STOP	Không thể xác nhận từng trường bắt buộc đã được điền mà không suy diễn nội dung. Giữ trạng thái review; Principal IT Business Analyst / Technical Curriculum Author cần cung cấp bản ghi Tier 3 nguyên vẹn để rà soát trường-đến-trường.
Tính nhất quán	Các artifact quản trị đều xác định IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND và Nova Foods là mô phỏng.	PASS có điều kiện	Metadata cấp corpus nhất quán. Điều kiện còn lại là bản ghi Tier 3 không được tự gọi là APPROVED, BASELINED, tuân thủ pháp luật hay cấu hình ERP production.
Khả năng kiểm thử	Một business rule chỉ kiểm thử được khi có điều kiện kích hoạt, dữ liệu đầu vào, xử lý, kết quả mong đợi, ngoại lệ và tiêu chí quan sát được.	STOP	Không có test basis của ví dụ Tier 3 trong đầu vào hiện tại, nên không chứng minh được khả năng viết test case black-box. Không được kết luận rule “testable” chỉ từ tên template.
Truy vết	Các nguồn canonical đã biết gồm CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY và source map /00-research/00_SOURCE_MAP.md.	FAIL	Không thấy liên kết cụ thể từ bản ghi Tier 3 tới ID rule canonical, ID dữ liệu, nguồn, assumption hoặc điểm cần xác minh. Đây là đứt traceability: phải bổ sung liên kết có định danh canonical trước khi đưa bản ghi qua gate.
Thẩm quyền nguồn	BABOK Guide, ISO/IEC/IEEE 29148, ISTQB CTFL và các nguồn pháp lý được phân loại rõ giới hạn sử dụng. Các nguồn pháp lý chỉ là nguồn chính thức để xác minh, không tự tạo diễn giải nghiệp vụ.	PASS có điều kiện	Không có bằng chứng rằng ví dụ Tier 3 đã gán đúng source classification cho từng kết luận. Nếu rule chứa nghĩa vụ pháp lý, kế toán, hóa đơn, dữ liệu cá nhân hoặc an toàn thực phẩm, kết quả phải chuyển thành Verification required, không diễn đạt thành nghĩa vụ đã được xác nhận.
Ownership và quyền quyết định	Owner của artifact là Principal IT Business Analyst / Technical Curriculum Author, với giới hạn rõ: không thay Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA.	FAIL	Chưa có bằng chứng bản ghi Tier 3 chỉ rõ owner nghiệp vụ của rule và owner xác minh cho phần chuyên môn bị ảnh hưởng. Cần escalation theo đúng vai trò; BA chỉ điều phối gói vấn đề và truy vết, không tự thay thế kết luận chuyên môn.
Ranh giới bảo mật, quyền riêng tư và pháp lý	Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý hiện hành được nêu trong source seed; OWASP ASVS và OWASP API Security Top 10 là good practice, không phải luật Việt Nam.	STOP	Không có nội dung Tier 3 để xác định rule có xử lý dữ liệu cá nhân, phân quyền, nhật ký truy cập hoặc trao đổi API hay không. Không được mặc định “không ảnh hưởng”. Nếu có dữ liệu cá nhân hoặc kiểm soát truy cập, phải escalation Legal/Privacy Owner và Security Owner.
Ranh giới kế toán, hóa đơn và chứng từ	Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP là nguồn chính thức được liệt kê; source seed yêu cầu kiểm tra sửa đổi trước production use.	STOP	Không có bằng chứng xác định ví dụ Tier 3 có tác động đến ghi nhận doanh thu, giá vốn, thuế, hóa đơn hoặc chứng từ. Nếu rule tạo, sửa, khóa hoặc đảo trạng thái chứng từ, Accounting Owner và Legal Owner phải xác minh; không được dùng giả định học liệu làm diễn giải kế toán.
Tác động thay đổi	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY là các nguồn kiểm soát liên quan; thay đổi rule có thể lan sang dữ liệu, test basis và artifact phụ thuộc.	FAIL	Chưa có impact analysis chỉ rõ đối tượng chịu ảnh hưởng, loại thay đổi, rủi ro, liên kết kiểm thử và quyết định xử lý. Không được chuyển trạng thái review khi chưa biết thay đổi có làm lệch catalog rule, data dictionary hoặc registry hay không.

Kết luận ghi nhận: ví dụ Nova Foods Tier 3 chưa vượt qua Senior BA Quality Gate ở phạm vi bằng chứng hiện có. Các điểm STOP và FAIL ngăn việc gọi bản ghi là baseline-ready hoặc approved. Cầu nối lập luận là: metadata corpus chỉ chứng minh bối cảnh quản trị; nó không cung cấp nội dung rule, nguồn gốc từng quyết định, owner chuyên môn, test basis hay phân tích tác động của bản ghi Tier 3. Vì vậy, kết quả trung thực là giữ IN_REVIEW, bảo toàn các ID và đường dẫn canonical hiện có, đồng thời chuyển các ranh giới pháp lý, kế toán, bảo mật và quyền riêng tư đến đúng owner có thẩm quyền khi nội dung rule cho thấy chúng bị tác động.

6. Cross-File Checks, Open Issues, and Escalation

6.1 Kiểm tra chéo nguồn kiểm soát và mâu thuẫn

Kiểm tra chéo (cross-file check) là đối chiếu cùng một thông tin giữa các artifact được kiểm soát để phát hiện hai loại lỗi: mâu thuẫn trực tiếp, khi hai nguồn canonical nêu hai giá trị hoặc ý nghĩa không thể cùng đúng; và thiếu bằng chứng liên kết, khi artifact hiện tại không có đủ dữ liệu để chứng minh nó đang dùng đúng ID, rule, dữ liệu hoặc dependency. Kiểm tra này chỉ xác nhận tính nhất quán của học liệu Nova Foods Trading & Manufacturing mô phỏng, dùng dữ liệu tổng hợp; không xác nhận cấu hình ERP thật, tuân thủ pháp luật, quyết định kế toán hay quyền sử dụng production.

Điểm kiểm tra	Nguồn đối chiếu bắt buộc	Tiêu chí kiểm tra	Kết quả từ bằng chứng hiện có	Kết luận kiểm soát
Danh tính template	/01-curriculum/TEMPLATE_MANIFEST.md; /03-templates/TMPL-RULE-001-business-rule-catalog.md	Tên tệp, mục đích template, trạng thái, phiên bản và phạm vi phải không xung đột manifest.	Tệp hiện hành được xác định là TMPL-RULE-001 và thuộc thư viện template; toàn corpus được cung cấp sử dụng IN_REVIEW, v0.9.0, ngày 2026-08-07.	Không có mâu thuẫn trực tiếp được xác định trong dữ liệu đầu vào; không được suy diễn template đã được baseline hoặc approved.
Danh tính và cú pháp ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mọi ID rule, data element, requirement, test hoặc traceability link trong Tier 3 phải tồn tại, đúng tiền tố và không tái sử dụng cho đối tượng khác.	Bằng chứng hiện có chỉ xác nhận TRACEABILITY_ID_REGISTRY là nguồn canonical của định danh; không cung cấp danh sách bản ghi ID để đối chiếu từng dòng Tier 3.	Chưa đủ bằng chứng để xác nhận tính hợp lệ của bất kỳ ID bản ghi Tier 3 nào; không được tự tạo hoặc đổi tên ID nhằm làm đầy catalog.
Nguồn chân lý của rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nội dung, điều kiện, ngoại lệ, owner và trạng thái của business rule phải khớp catalog canonical; template không trở thành nguồn rule độc lập.	CANONICAL_BUSINESS_RULES được xác định là catalog canonical và đang IN_REVIEW; nội dung rule cụ thể không có trong phạm vi bằng chứng được cung cấp.	Không phát hiện mâu thuẫn câu chữ cụ thể vì chưa có bản ghi rule để so sánh; mọi rule trong template phải được xem là bản ghi review, không phải quy định vận hành Nova Foods.
Nguồn chân lý dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên logic, định nghĩa, kiểu dữ liệu, miền giá trị, đơn vị VND, phân loại dữ liệu và quan hệ dữ liệu phải khớp data dictionary canonical.	CANONICAL_DATA_DICTIONARY được xác định là artifact canonical; phần dữ liệu trích dẫn không chứa định nghĩa trường cụ thể.	Không được kết luận field, mã trạng thái, định dạng tiền tệ hoặc dữ liệu cá nhân là đúng chỉ dựa trên template.
Liên kết curriculum và chapter	/01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Template phải hỗ trợ chuỗi học từ requirement, business rule, data, acceptance criteria, traceability đến test basis; không thay thế handbook chapter.	Curriculum architecture yêu cầu chuỗi traceability và cấm tạo nguồn chân lý trùng lặp; chapter manifest là nguồn kiểm soát cấu trúc chapter.	Không có mâu thuẫn quản trị được xác định. Template chỉ là công cụ ghi nhận có kiểm soát, không phải chapter, requirement specification hay test plan.
Liên kết nguồn nghiên cứu	/00-research/00_SOURCE_MAP.md	Khi rule viện dẫn chuẩn, pháp luật hoặc good practice, nguồn phải giữ đúng phân loại và ranh giới sử dụng.	Source map phân biệt nguồn normative, nguồn pháp lý chính thức và good practice; đồng thời cấm suy diễn điều khoản chưa xác minh.	Không được ghi OWASP là luật Việt Nam, không được gọi PlantUML là BPMN, và không được biến nguồn học liệu thành nghĩa vụ pháp lý hoặc kế toán.
Downstream consumer, tức đối tượng tiêu thụ ở bước sau	Catalog rule, data dictionary, requirement/acceptance criteria, test basis, QA artifact và tài liệu thiết kế phụ thuộc	Rule thay đổi phải giữ được liên kết đến dữ liệu, kiểm thử và artifact phụ thuộc; consumer không được tự diễn giải lại rule.	Senior BA Quality Gate trước đó ghi nhận thiếu impact analysis cho thay đổi có thể lan sang CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY.	Kết quả là FAIL cho khả năng chứng minh tác động thay đổi, không phải là bằng chứng rằng một rule cụ thể đã sai. Trạng thái tổng thể phải giữ IN_REVIEW.

6.2 Quy tắc xác định mâu thuẫn

Một mâu thuẫn được xác định khi cùng một ID có từ hai giá trị canonical khác nhau, khi một rule trong template trái với CANONICAL_BUSINESS_RULES, khi một data element trái với CANONICAL_DATA_DICTIONARY, hoặc khi filename, artifact ID, status hay version trái với manifest tương ứng. Nếu chỉ thiếu bản ghi nguồn để so sánh, kết quả đúng là không đủ bằng chứng xác minh, không được ghi là “khớp”, “đã phê duyệt” hoặc “không có vấn đề”.

Thứ tự ưu tiên khi đối chiếu là: manifest quản lý danh mục và đường dẫn; TRACEABILITY_ID_REGISTRY quản lý định danh; CANONICAL_BUSINESS_RULES quản lý nội dung rule; CANONICAL_DATA_DICTIONARY quản lý định nghĩa dữ liệu; artifact downstream chỉ sử dụng liên kết đến các nguồn này. Lý do là mỗi nguồn có một phạm vi thẩm quyền riêng; dùng template để ghi đè catalog canonical sẽ tạo hai nguồn chân lý và làm đứt traceability.

6.3 Kết quả kiểm tra của micro-batch

Từ bằng chứng đầu vào, không có mâu thuẫn trực tiếp nào được chứng minh giữa metadata quản trị của corpus: các artifact được nêu đều sử dụng trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, bối cảnh Việt Nam, tiền tệ mô phỏng VND và Nova Foods là case study mô phỏng với dữ liệu tổng hợp. Tuy nhiên, không có dữ liệu bản ghi cụ thể của registry, catalog rule hoặc data dictionary để xác nhận từng ID và từng trường Tier 3. Vì thiếu bằng chứng đối chiếu cấp bản ghi, template này không được diễn giải là đã nhất quán hoàn toàn với các nguồn canonical hoặc sẵn sàng chuyển sang baseline.

6.4 Sổ theo dõi vấn đề mở, giả định dự án và hạng mục cần xác minh

Sổ theo dõi này chỉ tổng hợp các điểm chưa thể kết luận từ bằng chứng đầu vào của corpus tại ngày 2026-08-07. “Vấn đề mở” là chênh lệch thông tin cần được xử lý trước khi có thể dùng nội dung làm cơ sở kiểm soát; “giả định dự án” là điều tạm dùng để minh họa học liệu nhưng không phải quyết định vận hành; “cần xác minh” là nội dung đòi hỏi bằng chứng từ nguồn canonical hoặc vai trò có thẩm quyền. Nova Foods Trading & Manufacturing là case study mô phỏng, mọi dữ liệu nêu dưới đây chỉ là dữ liệu tổng hợp.

ID theo dõi	Phân loại	ID/tệp bị ảnh hưởng	Chủ sở hữu xử lý	Tác động nếu chưa xử lý	Cầu nối bằng chứng và lý do	Hành động tiếp theo
OI-TMPL-RULE-001-01	Vấn đề mở	TMPL-RULE-001; /03-templates/TMPL-RULE-001-business-rule-catalog.md; TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	Không thể xác nhận các ID quy tắc tại Tier 3 đã tồn tại, đúng loại và không trùng lặp; nguy cơ tạo liên kết truy vết không hợp lệ.	Đầu vào xác nhận TRACEABILITY_ID_REGISTRY là nguồn quản lý định danh, nhưng không cung cấp bản ghi đăng ký cụ thể cho rule của template này.	Đối chiếu từng ID rule được điền trong Tier 3 với /01-curriculum/TRACEABILITY_ID_REGISTRY.md; nếu chưa có bản ghi, lập yêu cầu đăng ký ID, không tự tạo hoặc đổi ID trong template.
VR-TMPL-RULE-001-02	Cần xác minh	TMPL-RULE-001; CANONICAL_BUSINESS_RULES; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Business Owner cho nội dung nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author điều phối traceability	Không thể kết luận rule được mô tả là quy tắc nghiệp vụ canonical, đúng điều kiện áp dụng hoặc đủ ngoại lệ.	CANONICAL_BUSINESS_RULES được xác định là nguồn chân lý cho nội dung rule; source seed chỉ cung cấp metadata và ranh giới thẩm quyền, không cung cấp bản ghi rule Nova Foods cụ thể.	So sánh tên, điều kiện, kết quả, ngoại lệ và nguồn của từng rule Tier 3 với catalog canonical; chỉ ghi nhận khác biệt như issue, không sửa nội dung canonical bằng template.
VR-TMPL-RULE-001-03	Cần xác minh	TMPL-RULE-001; CANONICAL_DATA_DICTIONARY; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Data Owner hoặc Architect cho định nghĩa logic; Principal IT Business Analyst / Technical Curriculum Author điều phối	Trường dữ liệu, kiểu dữ liệu, đơn vị VND, trạng thái hoặc giá trị tham chiếu trong rule có thể không đồng nhất với từ điển dữ liệu logic.	CANONICAL_DATA_DICTIONARY là nguồn canonical cho định nghĩa dữ liệu, nhưng đầu vào không có danh mục trường và giá trị hợp lệ cấp bản ghi.	Xác minh từng data element được rule sử dụng với từ điển dữ liệu; ghi rõ ID dữ liệu canonical sau khi có bằng chứng, không suy diễn schema ERP hoặc cấu hình production.
PA-TMPL-RULE-001-04	Giả định dự án	TMPL-RULE-001; Nova Foods Trading & Manufacturing	Principal IT Business Analyst / Technical Curriculum Author	Ví dụ có thể bị hiểu sai là chính sách đang vận hành, cấu hình ERP thực tế hoặc cam kết của doanh nghiệp có thật.	CHAPTER_MANIFEST, TEMPLATE_MANIFEST và các artifact canonical đều xác định Nova Foods là mô phỏng giáo dục, dùng dữ liệu tổng hợp; không có baseline hoặc approval.	Duy trì nhãn “mô phỏng giáo dục, dữ liệu tổng hợp” tại mọi ví dụ và payload Tier 3; loại bỏ hoặc chuyển thành issue mọi diễn đạt khẳng định vận hành thực tế.
VR-TMPL-RULE-001-05	Cần xác minh	TMPL-RULE-001; quy tắc có yếu tố thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất	Legal Owner, Accounting Owner, Compliance Owner hoặc Food-safety Domain Owner theo nội dung; không thay thế bởi template Owner	Một rule minh họa có thể bị hiểu nhầm là nghĩa vụ pháp lý, diễn giải kế toán hoặc điều kiện tuân thủ đã được xác nhận.	Source seed quy định mọi chi tiết thuế, kế toán, pháp lý, quyền riêng tư, an toàn thực phẩm và truy xuất chưa đối chiếu văn bản chính thức hiện hành phải được gắn nhãn cần xác minh hoặc giả định dự án.	Gắn Verification required cho rule thuộc các miền này; chuyển gói câu hỏi, nguồn chính thức và tác động cho đúng owner thẩm quyền; chỉ cập nhật trạng thái sau khi có tham chiếu kiểm soát được ghi nhận.
OI-TMPL-RULE-001-06	Vấn đề mở	TMPL-RULE-001; các chapter, template và consumer downstream chưa được liệt kê trong đầu vào	Principal IT Business Analyst / Technical Curriculum Author	Chưa thể chứng minh rule catalog được sử dụng nhất quán bởi requirement, acceptance criteria, test basis hoặc tài liệu downstream.	Curriculum architecture yêu cầu chuỗi từ requirement đến traceability và test basis, nhưng đầu vào không cung cấp danh sách consumer cấp bản ghi của TMPL-RULE-001.	Lập danh sách consumer bằng liên kết artifact thực tế; với mỗi consumer, kiểm tra ID rule được tham chiếu thay vì sao chép nội dung rule; ghi nhận liên kết thiếu thành issue riêng nếu phát hiện.
OI-TMPL-RULE-001-07	Vấn đề mở	TMPL-RULE-001; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; toàn bộ artifact nêu trong bảng	Principal IT Business Analyst / Technical Curriculum Author	Không được phép mô tả catalog là baseline, approved, compliant, production-ready hoặc user-approved; việc handoff chỉ là bàn giao để review có kiểm soát.	Tất cả metadata đầu vào đều có Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07 và nêu rõ chưa có baseline reference hoặc approval reference.	Giữ nguyên IN_REVIEW và v0.9.0; mọi thay đổi phải ghi lịch sử thay đổi, giữ nguyên ID/đường dẫn canonical và gửi review cho owner có thẩm quyền tương ứng; không tự đóng issue bằng suy luận của người soạn template.

Quy tắc bàn giao cuối và lan truyền thay đổi có kiểm soát

Bàn giao (handoff) là việc chuyển một gói thông tin có thể truy vết từ người soạn sang người hoặc artifact tiêu thụ tiếp theo; bàn giao không phải là phê duyệt, baseline hay cho phép triển khai. Với /03-templates/TMPL-RULE-001-business-rule-catalog.md, gói bàn giao phải giữ Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, locale vi-VN và bối cảnh Nova Foods Trading & Manufacturing là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp và VND. Lý do là các artifact nguồn /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md đều xác định rõ IN_REVIEW không đồng nghĩa APPROVED, BASELINED, compliant hoặc production-ready.

Thành phần bàn giao	Nội dung phải được giữ nguyên hoặc kèm theo	Người nhận sử dụng được phép	Điều không được suy diễn
Artifact chính	/03-templates/TMPL-RULE-001-business-rule-catalog.md; tiêu đề Tmpl Rule 001 Business Rule Catalog; trạng thái IN_REVIEW; phiên bản v0.9.0	Người biên soạn chapter, template liên quan, QA reviewer và Technical Curriculum Author	Không được suy diễn template đã được baseline hoặc được người dùng phê duyệt
Định danh và liên kết	Canonical ID, ID quy tắc, ID dữ liệu, ID yêu cầu, ID test hoặc ID traceability xuất hiện trong record phải giữ đúng chuỗi đã đăng ký	Người quản trị traceability đối chiếu với TRACEABILITY_ID_REGISTRY	Không được tự đổi tên, tái sử dụng ID hoặc tạo ID thay thế chỉ để “khớp” nội dung
Nguồn chân lý	Liên kết đến CANONICAL_BUSINESS_RULES cho nội dung rule và CANONICAL_DATA_DICTIONARY cho định nghĩa dữ liệu	Người tiêu thụ xác định nơi cần đọc chi tiết	Không được coi bản sao trong template là nguồn canonical thay thế
Ranh giới nguồn	Nhãn nguồn, phân loại nguồn và nhãn Project assumption hoặc Verification required còn hiệu lực	Business Analyst, QA và chuyên gia được giao review	Không được nâng giả định thành nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc cấu hình ERP
Dữ liệu Nova Foods	Tên, ví dụ, giá trị và tình huống đều là synthetic data của case mô phỏng	Learner và người soạn học liệu	Không được sử dụng làm bằng chứng về doanh nghiệp thật, quyết định vận hành thật hoặc tuân thủ thực tế

Quy tắc lan truyền thay đổi (change propagation) được áp dụng từ nguyên tắc “một thay đổi phải đi theo toàn bộ liên kết chịu ảnh hưởng”. Khi một rule record trong catalog thay đổi về điều kiện, hành động, ngoại lệ, mức ưu tiên, dữ liệu đầu vào hoặc liên kết truy vết, người đề xuất phải lập bản ghi thay đổi nêu rõ ID bị ảnh hưởng, lý do, nguồn bằng chứng, phạm vi artifact nhận thay đổi và nhãn xác minh còn tồn tại. Suy luận kiểm soát là: rule thay đổi có thể làm thay đổi cách diễn giải dữ liệu, yêu cầu, acceptance criteria hoặc test basis; vì vậy chỉ sửa một bản sao cục bộ sẽ làm đứt traceability và tạo hai nguồn chân lý.

Loại thay đổi phát hiện	Artifact phải được thông báo để đánh giá ảnh hưởng	Hành động lan truyền bắt buộc	Ranh giới thẩm quyền
Thay đổi định danh hoặc trạng thái của rule	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, artifact đang tham chiếu rule	Giữ ID cũ nếu chỉ sửa nội dung; chỉ đánh giá cấp ID mới theo quy tắc registry; cập nhật liên kết hai chiều	Principal IT Business Analyst / Technical Curriculum Author quản trị liên kết, không tự xác nhận rule nghiệp vụ
Thay đổi tên, ý nghĩa, kiểu, miền giá trị hoặc phân loại dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md và mọi record rule dùng dữ liệu đó	Đánh giá lại điều kiện rule, thông báo lỗi, ví dụ Nova Foods mô phỏng và test data tổng hợp	Data Owner hoặc Architect xác nhận phần thuộc mô hình dữ liệu; không chuyển thành quyết định triển khai
Thay đổi logic có tác động nghiệp vụ	CANONICAL_BUSINESS_RULES, chapter/template tiêu thụ và test basis liên quan	Gắn nhãn ảnh hưởng, cập nhật traceability, yêu cầu Business Owner review nội dung nghiệp vụ	Business Owner mới có thể xác nhận ý nghĩa nghiệp vụ; không có approval ngầm định
Thay đổi có hàm ý pháp lý, kế toán, thuế, riêng tư, bảo mật hoặc an toàn thực phẩm	Source map liên quan và artifact tiêu thụ	Giữ hoặc thêm Verification required; chuyển gói bằng chứng tới đúng chuyên gia	Legal Owner, Accounting Owner, Security Owner hoặc domain owner đưa kết luận chuyên môn; template owner không thay thế họ
Thay đổi chỉ về trình bày, không đổi ý nghĩa hay liên kết	Chính tệp /03-templates/TMPL-RULE-001-business-rule-catalog.md	Ghi nhận lịch sử thay đổi và xác nhận không tác động ID, logic, dữ liệu hay nguồn	Không được dùng nhãn “minor” để che thay đổi logic

Mọi thay đổi được nhận sau bàn giao phải quay về nguồn canonical trước khi cập nhật template. Nếu phát hiện đề xuất chỉ tồn tại trong một chapter, một bản xuất hoặc một template nhưng chưa có căn cứ trong CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc TRACEABILITY_ID_REGISTRY, đề xuất đó chỉ được ghi nhận là nội dung cần đánh giá; không được chép thành rule canonical. Nếu thay đổi tạo mâu thuẫn giữa các nguồn canonical, việc lan truyền phải dừng tại điểm mâu thuẫn để bảo toàn bằng chứng; người điều phối chuẩn bị gói ảnh hưởng nhưng không tự chọn cách hiểu thắng thế.

Bàn giao cuối của micro-batch này hoàn tất khi người nhận có thể xác định đúng tệp nguồn, ID được giữ nguyên, trạng thái IN_REVIEW, các artifact phải đánh giá ảnh hưởng và vai trò có thẩm quyền cho từng loại quyết định. Việc hoàn tất bàn giao chỉ xác nhận tính sẵn sàng để review có kiểm soát; không xác nhận chất lượng nghiệp vụ cuối cùng, không tạo baseline, không ghi nhận approval và không cấp quyền sử dụng cho production.