Tmpl Rule 002 Decision Table

1. Tier 1 ? Metadata, Purpose, and Governance

Trường kiểm soát	Giá trị chuẩn	Diễn giải kiểm soát
Artifact ID	TMPL-RULE-002	Định danh canonical duy nhất của template bảng quyết định. Mọi liên kết nội bộ phải giữ nguyên chuỗi ID này để phân biệt với catalog quy tắc, registry truy vết và các template khác.
Tên tệp được kiểm soát	/03-templates/TMPL-RULE-002-decision-table.md	Đây là đường dẫn canonical của artifact. Bản sao, bản xuất hoặc nội dung được trích dẫn không thay thế tệp được kiểm soát.
Tiêu đề artifact	Tmpl Rule 002 Decision Table	Tên hiển thị chính thức của template trong corpus học liệu IT Business Analyst.
Phân loại artifact	Controlled four-tier template	Đây là template được kiểm soát theo bốn tầng: Tier 1 quản trị, Tier 2 mẫu trống, Tier 3 tình huống Nova Foods đã điền đầy đủ và Tier 4 kiểm tra chất lượng Senior BA.
Status	IN_REVIEW	Artifact đang được xem xét có kiểm soát. Trạng thái này không có nghĩa là APPROVED, BASELINED, sẵn sàng production, tuân thủ pháp lý hoặc đã được người dùng chấp thuận.
Version	v0.9.0	Phiên bản hiện hành của artifact tại thời điểm ghi nhận. Mọi thay đổi nội dung hoặc metadata sau phiên bản này phải được ghi thành phiên bản và lịch sử thay đổi mới, không được sửa im lặng.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Owner chịu trách nhiệm duy trì định danh, đường dẫn, trạng thái, phiên bản, metadata và lịch sử thay đổi của template; Owner không tự xác lập baseline, approval, quy tắc vận hành thực tế hoặc quyền triển khai ERP.
Last updated date	2026-08-07	Ngày cập nhật gần nhất, được diễn giải theo múi giờ quản trị Asia/Ho_Chi_Minh.
Locale và bối cảnh	vi-VN; Việt Nam; Asia/Ho_Chi_Minh; VND	Nội dung được viết bằng tiếng Việt cho bối cảnh học tập tại Việt Nam. Mọi giá trị tiền tệ trong tình huống minh họa, nếu xuất hiện ở các tầng sau, là VND mô phỏng.
Case-study boundary	Nova Foods Trading & Manufacturing — mô phỏng giáo dục	Nova Foods là tổ chức giả lập phục vụ đào tạo BA. Tên vai trò, quy trình, dữ liệu, quyết định và mã tham chiếu của Nova Foods chỉ có giá trị minh họa học tập.
Simulated-data boundary	Chỉ sử dụng dữ liệu tổng hợp	Không sử dụng dữ liệu cá nhân, khách hàng, nhân viên, nhà cung cấp, tài chính, vận hành hoặc cấu hình ERP thực tế. Dữ liệu tổng hợp không chứng minh sự tồn tại, hoạt động hoặc tuân thủ của bất kỳ doanh nghiệp thực tế nào.
Baseline reference	Chưa có baseline reference tại v0.9.0	Sự tồn tại của template và trạng thái IN_REVIEW không tạo baseline ngầm định.
Approval reference	Chưa có approval reference tại v0.9.0	Không có phê duyệt ngầm định từ Owner, metadata, nội dung review hoặc việc template được lưu trong corpus.

Lịch sử thay đổi

Version	Ngày	Người ghi nhận	Thay đổi được ghi nhận	Trạng thái sau thay đổi
v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo artifact TMPL-RULE-002 tại /03-templates/TMPL-RULE-002-decision-table.md; thiết lập metadata quản trị, ranh giới dữ liệu tổng hợp và trạng thái xem xét.	IN_REVIEW

Ranh giới kiểm soát: Metadata này chỉ xác định danh tính và trạng thái quản trị của học liệu. Nó không xác nhận tính đúng đắn của quy tắc nghiệp vụ, không thay thế thẩm quyền Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect hoặc QA, và không cho phép sử dụng nội dung template cho production.

Mục đích, điều kiện sử dụng và thẩm quyền quyết định

TMPL-RULE-002 là template bảng quyết định (decision table), tức kỹ thuật biểu diễn các tổ hợp điều kiện đầu vào và hành động hoặc kết quả tương ứng theo từng dòng quy tắc. Mục đích là làm rõ một quy tắc nghiệp vụ có nhiều điều kiện, tránh mô tả bằng văn xuôi dẫn đến bỏ sót tổ hợp hoặc diễn giải khác nhau giữa nghiệp vụ, phát triển và kiểm thử. Lý do sử dụng bảng là mỗi dòng buộc người soạn xác định rõ điều kiện, giá trị điều kiện, kết quả, ngoại lệ và liên kết truy vết; vì vậy reviewer có thể kiểm tra tính đầy đủ theo tổ hợp thay vì suy đoán từ câu chữ.

Nội dung	Quy định sử dụng
Khi sử dụng	Dùng khi một quyết định có từ hai điều kiện trở lên, khi cùng một điều kiện có nhiều trạng thái, khi kết quả thay đổi theo ngưỡng, vai trò, trạng thái chứng từ hoặc phân loại dữ liệu, hoặc khi cần chuyển quy tắc thành test case kiểm thử hộp đen (black-box testing), nghĩa là kiểm thử theo đầu vào và đầu ra mà không cần biết mã nguồn.
Ví dụ phù hợp	Trong case study Nova Foods mô phỏng, dùng bảng khi cần xác định kết quả xử lý một yêu cầu ERP dựa trên đồng thời trạng thái đơn hàng, hạn mức phê duyệt và loại khách hàng. Ví dụ này chỉ minh họa phương pháp; không xác nhận quy tắc vận hành thực tế của Nova Foods.
Khi không sử dụng	Không dùng làm thay thế cho sơ đồ quy trình khi trọng tâm là thứ tự hoạt động, nhánh luồng và vai trò thực hiện; không dùng thay từ điển dữ liệu khi trọng tâm là định nghĩa trường; không dùng để ghi yêu cầu giao diện đơn lẻ; không dùng để tự kết luận nghĩa vụ pháp lý, thuế, kế toán, an toàn thực phẩm, bảo mật hoặc quyền production.
Tiêu chí chọn công cụ khác	Nếu câu hỏi cần trả lời là “ai làm gì trước và sau”, dùng mô hình quy trình phù hợp. Nếu câu hỏi là “trường dữ liệu này có kiểu, định dạng và ý nghĩa gì”, dùng CANONICAL_DATA_DICTIONARY. Nếu câu hỏi là “quy tắc nào là nguồn chân lý được quản trị”, đối chiếu CANONICAL_BUSINESS_RULES trước khi lập bảng.
Ranh giới dữ liệu	Chỉ được điền dữ liệu tổng hợp cho Nova Foods Trading & Manufacturing, theo bối cảnh vi-VN, Asia/Ho_Chi_Minh và tiền tệ mô phỏng VND. Không nhập dữ liệu cá nhân, dữ liệu khách hàng thật, cấu hình ERP thật hoặc thông tin nội bộ chưa được phép công bố.

Owner của template là Principal IT Business Analyst / Technical Curriculum Author. Owner chịu trách nhiệm duy trì cấu trúc template, tính nhất quán thuật ngữ, định danh, phiên bản, liên kết truy vết và ranh giới dữ liệu mô phỏng. Owner không có thẩm quyền tự xác nhận một dòng quyết định là đúng cho vận hành, tự baseline, ghi nhận phê duyệt, diễn giải luật, xác nhận hạch toán, chấp thuận kiến trúc hoặc cho phép triển khai production. Lý do là việc duy trì học liệu và việc quyết định hiệu lực nghiệp vụ là hai trách nhiệm khác nhau; tách chúng giúp tránh biến một tài liệu đang IN_REVIEW thành cam kết vận hành ngầm định.

Nhóm sử dụng	Nhu cầu đầu ra từ bảng quyết định	Điều kiện sử dụng
Business Analyst	Phân rã quy tắc thành điều kiện, hành động, ngoại lệ và liên kết nguồn.	Phải phân biệt rõ fact, giả định dự án và nội dung cần xác minh.
Business Owner hoặc Process Owner	Rà soát ý nghĩa nghiệp vụ và tác động của từng kết quả quyết định.	Chỉ vai trò có thẩm quyền mới xác nhận quyết định nghiệp vụ cho bối cảnh thực tế.
Solution Architect hoặc Technical Architect	Đánh giá khả năng triển khai và điểm tích hợp, không tự thay đổi ý nghĩa nghiệp vụ.	Cần có rule, dữ liệu và ngoại lệ được mô tả đủ rõ.
Developer	Chuyển các dòng đã được kiểm soát thành logic cấu hình hoặc mã.	Không được suy diễn dòng thiếu hoặc coi template IN_REVIEW là đặc tả triển khai đã chốt.
QA/Test Analyst	Tạo điều kiện kiểm thử, dữ liệu kiểm thử tổng hợp và kết quả mong đợi cho từng dòng.	Phải giữ liên kết từ test về dòng quyết định và nguồn rule.
Legal, Accounting, Security hoặc Compliance Owner	Xem xét khi quyết định chạm tới lĩnh vực chuyên môn tương ứng.	Kết luận chuyên môn phải do đúng vai trò có thẩm quyền ghi nhận trong artifact kiểm soát phù hợp.

Điều kiện tiên quyết trước khi lập một bảng là phải có vấn đề quyết định được mô tả rõ, danh sách điều kiện có thể quan sát, tập kết quả có thể kiểm tra, nguồn hoặc giả định của từng điều kiện, và định danh truy vết hợp lệ theo TRACEABILITY_ID_REGISTRY. Nếu điều kiện phụ thuộc định nghĩa dữ liệu, người soạn phải đối chiếu CANONICAL_DATA_DICTIONARY; nếu phụ thuộc quy tắc nguồn, phải đối chiếu CANONICAL_BUSINESS_RULES. Cầu nối lập luận là bảng chỉ đáng tin khi mỗi ô có nguồn hoặc nhãn giả định: không có nguồn thì không thể phân biệt “điều kiện bắt buộc” với “cách hiểu của người soạn”.

Các đầu ra hạ nguồn của template gồm: yêu cầu nghiệp vụ hoặc chức năng có liên kết đến dòng quyết định; acceptance criteria mô tả kết quả kiểm chứng được; test basis và test case hộp đen; ma trận truy vết; và, khi được vai trò có thẩm quyền xem xét riêng, đặc tả cấu hình hoặc kỹ thuật. Việc tạo đầu ra hạ nguồn không tự động nâng trạng thái của TMPL-RULE-002, không tạo baseline và không chứng minh nội dung sẵn sàng production.

Tình huống	Thẩm quyền xử lý	Hành động escalation
Không xác định được Business Owner của quy tắc	Owner template duy trì hồ sơ vấn đề, không tự chọn kết quả.	Chuyển vấn đề tới Business Owner hoặc Process Owner được chỉ định; giữ các dòng liên quan ở trạng thái cần xác minh.
Điều kiện hoặc hành động có hàm ý pháp lý, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật	Owner template không diễn giải thay chuyên gia.	Chuyển tới Legal Owner, Accounting Owner, Security Owner, Compliance Owner hoặc domain owner tương ứng; ghi rõ “Verification required” cho đến khi có kết luận được ghi nhận.
Rule xung đột với CANONICAL_BUSINESS_RULES, định nghĩa xung đột với CANONICAL_DATA_DICTIONARY, hoặc ID không khớp TRACEABILITY_ID_REGISTRY	Owner template bảo toàn xung đột và không sửa im lặng.	Dừng sử dụng dòng xung đột cho đặc tả hoặc kiểm thử; báo cáo tới Owner của artifact canonical và Principal IT Business Analyst / Technical Curriculum Author để điều phối thay đổi có truy vết.
Quyết định không khả thi về kiến trúc, tích hợp, hiệu năng hoặc phân quyền	Architect đánh giá tính khả thi kỹ thuật; Business Owner giữ quyền quyết định nghiệp vụ.	Escalate đồng thời tới Business Owner và Architect vì thay đổi kỹ thuật có thể làm thay đổi lựa chọn nghiệp vụ.
Có đề xuất đưa bảng vào cấu hình ERP hoặc production	Template không cấp quyền triển khai.	Chuyển theo quy trình change control của dự án thực tế; chỉ sử dụng sau khi có baseline, phê duyệt và kiểm soát triển khai được ghi nhận ngoài phạm vi học liệu này.

Ánh xạ định danh manifest, nguồn và nghĩa vụ kiểm soát thay đổi

Thành phần ánh xạ	Giá trị canonical phải giữ nguyên	Cơ sở và cách dùng
Template artifact ID	TMPL-RULE-002	Đây là định danh của template Decision Table. Mọi liên kết traceability, lịch sử thay đổi và tham chiếu chéo phải dùng nguyên chuỗi này để tránh tạo nhầm một template quy tắc khác.
Tệp được kiểm soát	/03-templates/TMPL-RULE-002-decision-table.md	Đường dẫn này là vị trí nhận diện của artifact trong corpus. Bản sao, bản xuất hoặc nội dung được dán vào tài liệu khác không thay thế tệp kiểm soát.
Manifest quản lý template	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Manifest là nguồn quản trị cho danh mục template dự kiến, metadata và ranh giới sử dụng template. Sự hiện diện của TMPL-RULE-002 trong cấu trúc học liệu không đồng nghĩa template đã được baseline hoặc được phê duyệt sử dụng vận hành.
Manifest chương học	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	Template phục vụ chuỗi học của các chapter đã được manifest quản lý. Không gán số chapter, tên chapter hoặc quan hệ dependency cụ thể nếu quan hệ đó chưa được ghi nhận trong manifest; việc tự gán sẽ phá vỡ nguồn chân lý về cấu trúc curriculum.
Kiến trúc curriculum	01_CURRICULUM_ARCHITECTURE tại /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Artifact này xác định logic liên kết giữa học liệu, requirement, business rule, traceability và test basis. Decision table được dùng để biểu diễn quyết định có điều kiện, không thay thế requirement, process model hoặc test evidence.
Registry định danh	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mã rule, requirement, data, interface, test và risk được ghi trong Tier 3 phải tuân theo registry. Nếu ID chưa được registry xác định hoặc xung đột, giữ nguyên vấn đề và escalation; không tự tạo ID để hoàn tất bảng.
Catalog rule canonical	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Decision table diễn giải logic quyết định của một rule trong phạm vi học liệu; catalog rule là nguồn canonical cho nhận diện và quản trị rule. Khi nội dung bảng khác catalog, catalog không tự bị thay thế bởi bảng.
Từ điển dữ liệu canonical	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên trường, ý nghĩa dữ liệu, kiểu dữ liệu và phân loại dữ liệu dùng trong điều kiện hoặc hành động phải đối chiếu từ điển dữ liệu. Một nhãn cột trong bảng không được tự tạo ra định nghĩa dữ liệu mới.
Source map	00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	Source map kiểm soát nguồn tham khảo và ranh giới sử dụng. Template chỉ được diễn giải nguồn theo phân loại và giới hạn an toàn đã ghi nhận, không suy rộng thành trích dẫn điều khoản, nghĩa vụ pháp lý hoặc xác nhận tuân thủ.

Quy tắc liên kết chapter: TMPL-RULE-002 là template dùng xuyên chuỗi học, vì bảng quyết định có thể chuyển logic điều kiện–hành động thành đầu vào cho requirement, acceptance criteria và kiểm thử hộp đen. Tuy nhiên, CHAPTER_MANIFEST là nguồn duy nhất được phép xác định chapter nào yêu cầu hoặc phụ thuộc template này. Lý do là kiến trúc curriculum phải duy trì một nguồn chân lý; việc suy đoán chapter từ tên template có thể tạo dependency không tồn tại.

Nhóm nguồn	Nguồn đã xác minh	Phân loại sử dụng trong template	Ranh giới bắt buộc
Phân tích nghiệp vụ	BABOK Guide, IIBA, Version 3	Nguồn thuật ngữ và thực hành BA; hỗ trợ giải thích business rule, stakeholder và traceability.	Không tạo số trang, điều khoản hoặc trích dẫn nguyên văn không có trong nguồn đã truy cập.
Kỹ thuật requirement	ISO/IEC/IEEE 29148:2018, Edition 2	Nguồn tham khảo về kỹ nghệ requirements và chất lượng mô tả requirement.	Chỉ dùng abstract và trạng thái thư mục chính thức; xác minh văn bản được cấp phép trước khi nêu clause chính xác.
Kiểm thử	ISTQB CTFL Syllabus v4.0.1	Nguồn chính cho thuật ngữ kiểm thử và kỹ thuật hộp đen; decision table testing là ngữ cảnh phù hợp.	Không biến một ví dụ học liệu thành test case production hoặc bằng chứng chất lượng hệ thống.
Pháp luật Việt Nam	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP, Luật 55/2010/QH12	Nguồn pháp lý chính thức có thể kích hoạt nhãn rủi ro hoặc nhu cầu xác minh đối với dữ liệu cá nhân, kế toán, hóa đơn và an toàn thực phẩm.	Mọi rule suy ra cho Nova Foods phải ghi Verification required hoặc project assumption cho đến khi Legal Owner, Accounting Owner hoặc domain owner có thẩm quyền xác minh.
Chuẩn kỹ thuật và good practice	BPMN 2.0.2, UML 2.5.1, OpenAPI Specification 3.1.1, WCAG 2.2, OWASP ASVS 5.0.0, OWASP API Security Top 10 2023	Nguồn notation, API, accessibility và security awareness khi decision table liên quan giao diện, tích hợp hoặc kiểm soát truy cập.	Không gọi sơ đồ activity là BPMN; không trình bày OWASP là luật Việt Nam; không tuyên bố Nova Foods compliant hoặc production-ready.

Nghĩa vụ change control: mọi thay đổi làm đổi TMPL-RULE-002, đường dẫn tệp, quan hệ với manifest, ID traceability, tên dữ liệu canonical, logic rule, nguồn hoặc nhãn xác minh phải được ghi nhận như một thay đổi có truy vết tại artifact kiểm soát liên quan. Không được sửa im lặng để làm bảng “khớp” với tài liệu khác. Nếu thay đổi chỉ thuộc cách trình bày nhưng không đổi ý nghĩa quyết định, vẫn phải giữ định danh và kiểm tra rằng điều kiện, hành động, ngoại lệ và liên kết không bị đổi ngữ nghĩa. Nếu thay đổi làm phát sinh nghĩa vụ pháp lý, kế toán, thuế, bảo mật, kiến trúc hoặc vận hành, dừng việc diễn giải thành rule bắt buộc và chuyển vấn đề đến vai trò có thẩm quyền; template chỉ ghi nhận bằng chứng, xung đột và trạng thái Verification required.

Nova Foods Trading & Manufacturing trong template này là case study mô phỏng giáo dục; mọi tên, mã, tình huống và giá trị tiền tệ VND ở các tier sau là dữ liệu tổng hợp. Ánh xạ quản trị ở trên không xác nhận cấu hình ERP thực tế, không tạo baseline, không ghi nhận approval và không cho phép sử dụng bảng cho production.

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

Khối này là mẫu trắng để sao chép và điền sau; Nova Foods trong corpus này là mô phỏng giáo dục, chỉ dùng synthetic data (dữ liệu tổng hợp). Trong mẫu này, placeholder (ô giữ chỗ) phải luôn được viết bằng dấu ngoặc nhọn kép theo dạng <Mô tả rõ ràng của giá trị cần điền>, không dùng <value> chung chung vì người học mới phải nhìn là hiểu ngay phải thay gì. Mỗi trường chỉ nhận một ý nghĩa duy nhất; nếu một trường phụ thuộc trường khác thì ghi rõ điều kiện ngay trong ô hướng dẫn, để tránh hiểu sai từ đầu.

Nhóm trường	Giá trị trắng cần sao chép	Hướng dẫn điền bắt buộc
Định danh tài liệu	<ARTIFACT_ID_CANONICAL>	Điền đúng mã định danh đã đăng ký của template; không tự đổi sang tên rút gọn, không thêm tiền tố hậu tố mới.
Tên tệp	<DUONG_DAN_CANONICAL_CUA_TEP_MD>	Điền đúng đường dẫn canonical của file đang kiểm soát; đây là khóa truy vết chứ không phải nhãn trình bày.
Tiêu đề tài liệu	<TIEU_DE_CANONICAL_DAY_DU>	Ghi nguyên tiêu đề đã chuẩn hóa, giữ đúng dấu, chữ hoa, và phạm vi của tài liệu.
Trạng thái	<IN_REVIEW>	Chỉ ghi trạng thái đã được quản trị quy định; mẫu trắng không tự suy ra là đã phê duyệt.
Phiên bản	<v0.9.0>	Giữ đúng phiên bản frozen contract của đợt biên soạn này; không tự nâng phiên bản trong mẫu trắng.
Ngày cập nhật	<2026-08-07>	Điền theo định dạng YYYY-MM-DD; nếu cần giờ thì dùng múi giờ Asia/Ho_Chi_Minh.
Locale	<vi-VN>	Ghi đúng locale áp dụng cho nội dung tiếng Việt chuẩn Việt Nam; không trộn sang locale khác nếu chưa có chỉ dẫn.
Múi giờ	<Asia/Ho_Chi_Minh>	Dùng để ghi thời điểm review, sign-off, và dấu thời gian của các dòng kiểm soát.
Đơn vị tiền tệ	<VND>	Chỉ ghi đơn vị tiền tệ mô phỏng đã chốt; không tự suy đoán sang đơn vị khác.
Phạm vi case study	<Nova Foods Trading & Manufacturing — mô phỏng giáo dục>	Luôn nhắc rõ tính mô phỏng để tránh hiểu lầm đây là dữ liệu thật hoặc quy trình production.
Nguồn dữ liệu	<synthetic data only>	Chỉ dùng dữ liệu tổng hợp; nếu trường nào chưa xác minh được thì đánh dấu theo quy ước kiểm soát, không tự bịa giá trị.
Ghi chú an toàn bí mật	<SECRET_REF:ten-tham-chieu-an-toan>	Nếu cần tham chiếu bí mật, chỉ ghi mã tham chiếu an toàn, không ghi secret thật, mật khẩu, token, khóa API hoặc dữ liệu nhạy cảm.

Quy ước điền mẫu trắng

Mỗi ô giữ chỗ phải mô tả được đối tượng, loại giá trị, và nếu cần thì định dạng. Ví dụ, <Ngay phat hanh theo YYYY-MM-DD> là đạt vì người điền biết phải đưa ngày theo chuẩn nào; còn <ngay> là không đạt vì quá mơ hồ. Khi một trường có ràng buộc, hãy viết thẳng ràng buộc trong hướng dẫn, ví dụ: <Danh sách mã nguồn được ngăn cách bằng dấu chấm phẩy> hoặc <Tên vai trò có thẩm quyền; chỉ chọn 1 giá trị>. Cách làm này giúp template trắng vẫn dùng được ngay mà không cần suy đoán ngầm.

Mẫu tham chiếu an toàn cho thông tin nhạy cảm

Nếu nội dung cần nhắc đến tài liệu mật, khóa truy cập, hoặc cấu hình hạn chế, chỉ dùng mẫu <SECRET_REF:ma-tham-chieu-phi-nhay-cam> hoặc <SAFE_REF:ma-tham-chieu-noi-bo>. Không ghi trực tiếp bí mật thật trong template trắng, không mô tả đủ để suy ra bí mật, và không biến mẫu trắng thành kho lưu trữ dữ liệu nhạy cảm. Nếu trường đó không áp dụng cho bài học hiện tại, vẫn phải giữ ô giữ chỗ và ghi rõ “không áp dụng” chỉ khi phần sau của tài liệu cho phép điều kiện đó.

Kiểm tra hợp lệ ở mức trường

Trước khi sang các phần chi tiết khác, kiểm tra ba điểm: một là mọi ô đều có dấu < > rõ ràng; hai là tên placeholder đủ mô tả để người mới hiểu; ba là không có giá trị thật nào lọt vào mẫu trắng khi tài liệu vẫn ở trạng thái IN_REVIEW. Đây là nền tảng để các phần sau của template có thể điền đồng nhất, không đứt traceability (khả năng truy vết) và không làm lẫn giữa khung mẫu với dữ liệu đã hoàn tất.

Khung bảng quyết định, ngoại lệ, bằng chứng và kiểm soát

Dùng toàn bộ bảng dưới đây khi tạo một decision table (bảng quyết định): công cụ biểu diễn điều kiện đầu vào, hành động đầu ra và quy tắc xử lý theo từng tổ hợp hợp lệ. Mọi dữ liệu Nova Foods trong Tier 3 là mô phỏng giáo dục, dữ liệu tổng hợp. Tier 2 chỉ giữ placeholder mô tả; không được điền dữ liệu vận hành thật, bí mật, phê duyệt hoặc baseline.

Trường kiểm soát	Giá trị Tier 2 phải điền	Quy tắc hợp lệ
Decision Table ID	<RULE-ID canonical từ TRACEABILITY_ID_REGISTRY>	Bắt buộc. Giữ nguyên ID đã đăng ký; không tự tạo biến thể.
Tên bảng quyết định	<Tên ngắn nêu đối tượng và kết quả quyết định>	Bắt buộc; nêu rõ quyết định, không dùng tên chung như “Quy tắc mới”.
Artifact chứa bảng	/03-templates/TMPL-RULE-002-decision-table.md	Bắt buộc; giữ nguyên đường dẫn canonical.
Status	IN_REVIEW	Chỉ chọn DRAFT, IN_REVIEW, BASELINED, RETIRED; không dùng BASELINED khi chưa có tham chiếu baseline.
Version	v0.9.0	Bắt buộc; theo định dạng v<major>.<minor>.<patch>.
Ngày cập nhật	2026-08-07	Bắt buộc; định dạng YYYY-MM-DD, múi giờ Asia/Ho_Chi_Minh.
Locale và tiền tệ	vi-VN / VND	Bắt buộc khi bảng có dữ liệu ngày, số hoặc tiền.
Phạm vi quyết định	<Sự kiện kích hoạt, đối tượng nghiệp vụ, kết quả cần quyết định>	Bắt buộc; không suy diễn thành cấu hình ERP hoặc nghĩa vụ pháp lý.
Ngoài phạm vi	<Quyết định, hệ thống, vai trò hoặc giai đoạn không xử lý>	Bắt buộc; ngăn rule bị dùng vượt ranh giới.
Owner soạn thảo	<Vai trò chịu trách nhiệm duy trì nội dung>	Ghi vai trò, không ghi là người đã phê duyệt.
Phân loại dữ liệu	<PUBLIC hoặc INTERNAL hoặc CONFIDENTIAL hoặc RESTRICTED>	Chọn một giá trị. Nếu CONFIDENTIAL hoặc RESTRICTED, không ghi bí mật trực tiếp.

Điều kiện ID	Điều kiện nghiệp vụ	Kiểu dữ liệu	Giá trị cho phép hoặc phép so sánh	Nguồn dữ liệu logic	Bắt buộc	Kiểm tra hợp lệ
<COND-01>	<Điều kiện đầu vào thứ nhất>	<Boolean hoặc Enum hoặc Number hoặc Date hoặc Text>	<TRUE/FALSE; danh sách enum; toán tử; khoảng giá trị>	<Entity.field từ CANONICAL_DATA_DICTIONARY>	<Có/Không>	<Quy tắc định dạng, null, miền giá trị>
<COND-02>	<Điều kiện đầu vào thứ hai>	<Boolean hoặc Enum hoặc Number hoặc Date hoặc Text>	<TRUE/FALSE; danh sách enum; toán tử; khoảng giá trị>	<Entity.field từ CANONICAL_DATA_DICTIONARY>	<Có/Không>	<Quy tắc định dạng, null, miền giá trị>
<COND-03>	<Điều kiện đầu vào thứ ba hoặc ghi Không áp dụng theo phạm vi>	<Boolean hoặc Enum hoặc Number hoặc Date hoặc Text>	<TRUE/FALSE; danh sách enum; toán tử; khoảng giá trị>	<Entity.field hoặc Không áp dụng>	<Có/Không>	<Quy tắc định dạng, null, miền giá trị>

Hành động ID	Kết quả hoặc hành động hệ thống	Loại hành động	Giá trị đầu ra hoặc trạng thái	Vai trò nhận tác động	Kiểm tra hợp lệ
<ACT-01>	<Hành động khi rule khớp>	<Cho phép hoặc Chặn hoặc Tính toán hoặc Gán trạng thái hoặc Yêu cầu review>	<Giá trị, trạng thái hoặc công thức mô tả>	<Vai trò hoặc hệ thống nhận kết quả>	<Điều kiện đầu ra phải xác định được>
<ACT-02>	<Hành động bổ sung hoặc ghi Không áp dụng theo phạm vi>	<Cho phép hoặc Chặn hoặc Tính toán hoặc Gán trạng thái hoặc Yêu cầu review>	<Giá trị, trạng thái hoặc công thức mô tả>	<Vai trò hoặc hệ thống nhận kết quả>	<Không mâu thuẫn ACT-01>

Rule ID	COND-01	COND-02	COND-03	ACT-01	ACT-02	Kết quả mong đợi	Độ ưu tiên	Kiểm tra đầy đủ
<RULE-ROW-01>	<Giá trị hoặc Y: không quan trọng>	<Giá trị hoặc Y: không quan trọng>	<Giá trị hoặc Y: không quan trọng>	<Có/Không>	<Có/Không>	<Mô tả kết quả quan sát được>	<Số nguyên dương, 1 là cao nhất>	<Không trùng tổ hợp với dòng khác>
<RULE-ROW-02>	<Giá trị hoặc Y: không quan trọng>	<Giá trị hoặc Y: không quan trọng>	<Giá trị hoặc Y: không quan trọng>	<Có/Không>	<Có/Không>	<Mô tả kết quả quan sát được>	<Số nguyên dương, 1 là cao nhất>	<Không trùng tổ hợp với dòng khác>
<RULE-ROW-03>	<Giá trị hoặc Y: không quan trọng>	<Giá trị hoặc Y: không quan trọng>	<Giá trị hoặc Y: không quan trọng>	<Có/Không>	<Có/Không>	<Mô tả kết quả quan sát được>	<Số nguyên dương, 1 là cao nhất>	<Bao phủ trường hợp còn lại hoặc ghi lý do không bao phủ>

Y nghĩa là “không quan trọng” cho rule đó. Chỉ dùng Y khi thay đổi điều kiện không làm thay đổi kết quả. Nếu hai dòng cùng khớp một tổ hợp đầu vào, độ ưu tiên phải khác nhau và phải giải thích vì sao dòng ưu tiên cao hơn thắng; nếu không, bảng có xung đột và không đủ điều kiện review.

Exception ID	Điều kiện kích hoạt ngoại lệ	Rule ID bị ảnh hưởng	Cách xử lý	Người hoặc vai trò xử lý	Bằng chứng cần lưu	Trạng thái kết thúc
<EXC-01>	<Dữ liệu thiếu, sai định dạng, xung đột hoặc vượt ngưỡng>	<RULE-ROW-ID>	<Chặn, chuyển review, trả lỗi hoặc xử lý thủ công>	<Vai trò có thẩm quyền>	<EVID-ID hoặc SAFE_REF>	<RESOLVED hoặc ESCALATED hoặc REJECTED>
<EXC-02>	<Ngoại lệ thứ hai hoặc ghi Không áp dụng theo phạm vi>	<RULE-ROW-ID hoặc Không áp dụng>	<Chặn, chuyển review, trả lỗi hoặc xử lý thủ công>	<Vai trò có thẩm quyền hoặc Không áp dụng>	<EVID-ID hoặc SAFE_REF hoặc Không áp dụng>	<RESOLVED hoặc ESCALATED hoặc REJECTED hoặc Không áp dụng>

Evidence ID	Loại bằng chứng	Mô tả bằng chứng	Nguồn và phân loại	Liên kết an toàn	Rule hoặc exception hỗ trợ	Trạng thái xác minh
<EVID-01>	<Yêu cầu nghiệp vụ hoặc nguồn chính thức hoặc kết quả test hoặc biên bản review>	<Nội dung chứng minh điều kiện hoặc hành động>	<PRIMARY hoặc DERIVED hoặc ASSUMPTION hoặc VERIFICATION_REQUIRED>	<URL chính thức hoặc SAFE_REF:ma-tham-chieu-noi-bo>	<RULE-ROW-ID hoặc EXC-ID>	<UNVERIFIED hoặc VERIFIED hoặc SUPERSEDED>
<EVID-02>	<Yêu cầu nghiệp vụ hoặc nguồn chính thức hoặc kết quả test hoặc biên bản review>	<Nội dung chứng minh điều kiện hoặc hành động>	<PRIMARY hoặc DERIVED hoặc ASSUMPTION hoặc VERIFICATION_REQUIRED>	<URL chính thức hoặc SAFE_REF:ma-tham-chieu-noi-bo>	<RULE-ROW-ID hoặc EXC-ID>	<UNVERIFIED hoặc VERIFIED hoặc SUPERSEDED>

Không dùng URL giả, trích dẫn bịa đặt, secret, token, mật khẩu hoặc dữ liệu cá nhân trong cột liên kết. Với tài liệu hạn chế, dùng <SAFE_REF:ma-tham-chieu-noi-bo>; mã này chỉ định vị tài liệu đã được kiểm soát, không chứa nội dung bí mật.

Trace ID	Artefact nguồn hoặc đích	Loại liên kết	ID liên quan	Cầu nối lý do và bằng chứng	Trạng thái
<TRACE-01>	<Đường dẫn canonical nguồn>	<Derives from hoặc Constrains hoặc Validates hoặc Implements>	<REQ-ID, RULE-ID, EVID-ID hoặc TEST-ID canonical>	<Nêu dữ kiện nguồn, suy luận và phần bảng bị tác động>	<OPEN hoặc IN_REVIEW hoặc CONFIRMED>
<TRACE-02>	<Đường dẫn canonical đích>	<Derives from hoặc Constrains hoặc Validates hoặc Implements>	<REQ-ID, RULE-ID, EVID-ID hoặc TEST-ID canonical>	<Nêu dữ kiện nguồn, suy luận và phần bảng bị tác động>	<OPEN hoặc IN_REVIEW hoặc CONFIRMED>

Phiên bản	Ngày	Người ghi nhận	Loại thay đổi	Mô tả thay đổi	Lý do và bằng chứng	Baseline reference
v0.9.0	2026-08-07	<Vai trò ghi nhận thay đổi>	<Khởi tạo hoặc Sửa rule hoặc Sửa evidence hoặc Sửa traceability>	<Mô tả thay đổi kiểm tra được>	<EVID-ID hoặc TRACE-ID>	Chưa có baseline reference
<vX.Y.Z>	<YYYY-MM-DD>	<Vai trò ghi nhận thay đổi>	<Khởi tạo hoặc Sửa rule hoặc Sửa evidence hoặc Sửa traceability>	<Mô tả thay đổi kiểm tra được>	<EVID-ID hoặc TRACE-ID>	<Baseline ID hoặc Chưa có baseline reference>

Hoạt động review hoặc sign-off	Vai trò bắt buộc	Người thực hiện	Ngày	Quyết định	Nhận xét hoặc bằng chứng	Tham chiếu phê duyệt
Soạn thảo	<Business Analyst hoặc vai trò được chỉ định>	<Tên hoặc định danh vai trò>	<YYYY-MM-DD>	<SUBMITTED hoặc NOT_STARTED>	<TRACE-ID hoặc EVID-ID>	Chưa có approval reference
Review nghiệp vụ	<Business Owner hoặc Subject Matter Expert>	<Tên hoặc định danh vai trò>	<YYYY-MM-DD hoặc Chưa thực hiện>	<PENDING hoặc ACCEPTED hoặc REWORK_REQUIRED>	<Nhận xét hoặc SAFE_REF>	Chưa có approval reference hoặc <APPROVAL-ID>
Review kỹ thuật	<Solution Architect hoặc Technical Lead>	<Tên hoặc định danh vai trò>	<YYYY-MM-DD hoặc Chưa thực hiện>	<PENDING hoặc ACCEPTED hoặc REWORK_REQUIRED>	<Nhận xét hoặc SAFE_REF>	Chưa có approval reference hoặc <APPROVAL-ID>
Review kiểm thử	<QA Lead hoặc Test Analyst>	<Tên hoặc định danh vai trò>	<YYYY-MM-DD hoặc Chưa thực hiện>	<PENDING hoặc ACCEPTED hoặc REWORK_REQUIRED>	<Nhận xét hoặc TEST-ID>	Chưa có approval reference hoặc <APPROVAL-ID>
Sign-off thẩm quyền	<Vai trò có thẩm quyền theo phạm vi>	<Tên hoặc định danh vai trò>	<YYYY-MM-DD hoặc Chưa thực hiện>	<PENDING hoặc APPROVED hoặc REJECTED>	<Bằng chứng quyết định hoặc SAFE_REF>	<APPROVAL-ID hoặc Chưa có approval reference>

Không ghi APPROVED, BASELINED hoặc sign-off hoàn tất nếu chưa có bằng chứng tham chiếu kiểm tra được. IN_REVIEW chỉ cho biết tài liệu đang được xem xét; không xác nhận Nova Foods mô phỏng đã chấp thuận, tuân thủ hay sẵn sàng production.

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

Các hướng dẫn dưới đây áp dụng cho mọi trường của bản mẫu Tier 2. Người lập điền giá trị bên trong dấu ngoặc nhọn góc, ví dụ <RULE-ID theo registry canonical>, rồi thay toàn bộ placeholder trước khi chuyển tài liệu sang Tier 3. Không dùng placeholder để che một quyết định chưa có căn cứ: nếu chưa xác định được giá trị, ghi rõ <Verification required — nêu vai trò có thẩm quyền và câu hỏi cần xác minh>.

Nhóm trường	Placeholder bắt buộc và hướng dẫn điền	Giá trị hợp lệ	Quy tắc kiểm tra
Định danh quy tắc	<RULE-ID theo TRACEABILITY_ID_REGISTRY>	ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không tự tạo biến thể ID, không dùng ID của requirement, test case hoặc interface thay cho Rule ID.
Tên quy tắc	<Tên ngắn, động từ nghiệp vụ + đối tượng + điều kiện>	Một câu, rõ kết quả quyết định; ví dụ cấu trúc: “Xác định khi <điều kiện>”	Không chứa từ mơ hồ như “phù hợp”, “hợp lý”, “kịp thời” nếu không có tiêu chí đo được.
Loại quyết định	<Loại: Eligibility \| Calculation \| Routing \| Validation \| Authorization \| Classification>	Chỉ một giá trị trong danh sách	Nếu một rule vừa tính toán vừa định tuyến, tách thành hai rule liên kết để mỗi bảng quyết định chỉ có một kết quả chính.
Phạm vi	<Quy trình, sự kiện kích hoạt, đối tượng dữ liệu và ranh giới không áp dụng>	Mô tả nghiệp vụ có thể kiểm tra	Phải nêu cả “áp dụng khi” và “không áp dụng khi”; không suy diễn phạm vi từ tên quy tắc.
Điều kiện đầu vào	<Tên trường logic>, <toán tử>, <giá trị hoặc tập giá trị>	Toán tử: =, ≠, >, ≥, <, ≤, IN, NOT IN, IS NULL, IS NOT NULL	Mỗi điều kiện phải truy được tới trường logic trong CANONICAL_DATA_DICTIONARY hoặc ghi Verification required nếu chưa có định nghĩa canonical.
Giá trị điều kiện	<Giá trị enum hoặc ngưỡng có đơn vị>	Enum đã định nghĩa; số có đơn vị; ngày theo YYYY-MM-DD; tiền theo VND	Không trộn chuỗi mô tả với mã enum. Ngưỡng tiền phải nêu VND, nguồn quyết định và chủ thể có thẩm quyền xác minh.
Hành động/kết quả	<Hành động hệ thống hoặc trạng thái đầu ra>	ALLOW, BLOCK, ROUTE, CALCULATE, FLAG, REQUIRE_REVIEW hoặc hành động được định nghĩa rõ	Một cột hành động phải cho kết quả xác định. REQUIRE_REVIEW phải kèm hàng đợi, vai trò xử lý và điều kiện kết thúc review.
Ưu tiên hàng quyết định	<Số nguyên dương duy nhất>	1 là ưu tiên cao nhất; các số nguyên tăng dần	Không được trùng ưu tiên. Nếu áp dụng chiến lược “first hit” (hàng khớp đầu tiên thắng), thứ tự hàng là một phần của rule và phải được kiểm tra.
Chính sách khớp	<FIRST_HIT \| ALL_MATCHES \| UNIQUE_MATCH_REQUIRED>	Chỉ một giá trị trong danh sách	FIRST_HIT: phải có thứ tự ưu tiên. ALL_MATCHES: phải xác định cách gộp hành động. UNIQUE_MATCH_REQUIRED: không được có hai hàng cùng khớp; nếu có, trả lỗi kiểm soát.
Ngoại lệ	<Mã ngoại lệ> — <điều kiện> — <xử lý> — <vai trò nhận việc>	Mỗi ngoại lệ có mã duy nhất trong phạm vi rule	Ngoại lệ không được mâu thuẫn với hành động chuẩn. Nếu ngoại lệ liên quan pháp lý, thuế, kế toán, dữ liệu cá nhân hoặc an toàn thực phẩm, gắn nhãn Verification required và chỉ rõ Legal, Accounting, Compliance hoặc domain owner phù hợp.
Dữ liệu cá nhân hoặc nhạy cảm	<Không áp dụng> hoặc <Loại dữ liệu và mục đích xử lý>	Không áp dụng, Dữ liệu cá nhân, Dữ liệu nhạy cảm theo phân loại dự án	Không tự kết luận tuân thủ pháp luật. Khi có dữ liệu cá nhân, chỉ ghi nhu cầu kiểm tra với Legal/Privacy Owner dựa trên nguồn pháp lý chính thức được quản trị.
Tham chiếu bí mật	<SECRET-REF:<vault-alias>/<secret-name>> hoặc <Không áp dụng>	Chỉ định danh tham chiếu an toàn, không chứa secret thật	Cấm ghi mật khẩu, token, API key, chuỗi kết nối, private key hoặc dữ liệu xác thực vào bảng, ví dụ, ảnh chụp hay lịch sử thay đổi. vault-alias không được tiết lộ URL nội bộ hoặc định danh tài khoản thực.
Trạng thái xác minh	<DRAFT \| IN_REVIEW \| Verification required>	Chỉ một giá trị trong danh sách	Với corpus hiện hành, không ghi APPROVED, BASELINED, production-ready hoặc tương đương nếu không có tham chiếu kiểm soát được ghi nhận.
Lý do và cầu nối suy luận	<Bằng chứng đầu vào> → <diễn giải> → <quyết định trong bảng>	Chuỗi ba phần có thể truy vết	Không biến giả định thành sự thật. Nếu bằng chứng chỉ là giả định dự án, phải ghi rõ Project assumption và vai trò cần xác minh.

Quy tắc cho bảng điều kiện. Mỗi cột điều kiện biểu diễn đúng một biến quyết định, ví dụ <Trạng thái đơn hàng>, <Tổng giá trị đơn hàng VND>, hoặc <Loại khách hàng>. Dùng Y, N chỉ khi điều kiện là nhị phân và định nghĩa của Y/N được ghi rõ; dùng - chỉ với nghĩa “không xét điều kiện này ở hàng này”, không phải “chưa biết”. Một hàng có - vẫn phải cho ra hành động xác định theo chính sách khớp đã chọn.

Quy tắc cho phần có điều kiện. Chỉ thêm mục <Công thức tính> khi loại quyết định là Calculation; công thức phải nêu đầu vào, đơn vị, quy tắc làm tròn và kết quả khi đầu vào thiếu. Chỉ thêm mục <Định tuyến xử lý> khi hành động là ROUTE hoặc REQUIRE_REVIEW; mục này phải nêu vai trò nhận, hàng đợi hoặc kênh logic, thời hạn mục tiêu nếu đó là giả định dự án, và điều kiện đóng xử lý. Chỉ thêm mục <Kiểm soát truy cập> khi rule phụ thuộc quyền; mô tả vai trò logic như <Role-Code> thay vì tên người dùng, email hoặc tài khoản thật.

Mẫu kiểm tra an toàn trước khi dùng lại. Người lập xác nhận: <Tất cả enum đã được định nghĩa>, <Tất cả ngưỡng có đơn vị VND hoặc đơn vị phù hợp>, <Không có hai hàng mâu thuẫn theo chính sách khớp>, <Mọi ngoại lệ có xử lý và vai trò nhận việc>, <Không có secret hoặc dữ liệu cá nhân thật>, và <Mọi nội dung cần thẩm quyền chuyên môn được gắn Verification required>. Nova Foods Trading & Manufacturing trong tài liệu này là case mô phỏng giáo dục; mọi dữ liệu sử dụng phải là dữ liệu tổng hợp.

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

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, không phải cấu hình ERP, giao dịch, khách hàng hoặc quyết định vận hành thật.

Trường	Giá trị đã điền
Artifact ID	TMPL-RULE-002
Tên artifact	Tmpl Rule 002 Decision Table
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày ghi nhận	2026-08-07
Locale và múi giờ	vi-VN, Asia/Ho_Chi_Minh
Đơn vị tiền tệ	VND
Rule ID	BR-SO-002
Tên rule	Quyết định trạng thái duyệt đơn bán vượt hạn mức tín dụng
Quy trình	Order-to-Cash, từ tạo đơn bán đến xác nhận giao hàng
Điểm kích hoạt	ERP nhận yêu cầu xác nhận đơn bán SO-NF-20260807-0142
Mục tiêu	Ngăn xác nhận đơn khi công nợ sau đơn vượt hạn mức tín dụng được cấp cho khách hàng
Đối tượng quyết định	Đơn bán nội địa của khách hàng mua chịu
Chủ thể mô phỏng	Khách hàng CUS-NF-0187 — Công ty TNHH Phân phối An Phúc; nhân viên bán hàng EMP-NF-0041 — Lê Minh Khôi; Credit Controller ROLE-CREDIT-CONTROLLER; Sales Manager ROLE-SALES-MANAGER
Nguồn sự kiện	SIMULATED_TRANSACTION
Phân loại dữ liệu	INTERNAL-SIMULATED; không chứa dữ liệu cá nhân thật
Phạm vi loại trừ	Đơn tiền mặt, đơn xuất khẩu, đơn đã hủy, đơn trả hàng và điều chỉnh công nợ thủ công

Sự kiện mô phỏng. Lúc 2026-08-07T10:15:00+07:00, Lê Minh Khôi gửi xác nhận đơn SO-NF-20260807-0142 cho Công ty TNHH Phân phối An Phúc. Đơn gồm 480 thùng SKU-NF-CP500-12, đơn giá chưa VAT 385.000 VND/thùng, chiết khấu thương mại 3%, VAT mô phỏng 8%. Tổng tiền thanh toán là 193.881.600 VND. Thuế suất là PROJECT_ASSUMPTION; Accounting Owner và Legal Owner phải xác minh trước khi dùng ngoài học liệu.

Dữ kiện đầu vào. Hạn mức tín dụng khách hàng là 500.000.000 VND; công nợ đã ghi nhận nhưng chưa thanh toán là 342.500.000 VND; giá trị đơn đang chờ xác nhận là 179.520.000 VND trước VAT. Giá trị phơi nhiễm tín dụng sau đơn là 522.020.000 VND, tính bằng 342.500.000 + 179.520.000. ERP so sánh giá trị này với hạn mức vì rủi ro tín dụng phát sinh từ khoản phải thu chưa thanh toán và cam kết bán chịu mới, không từ VAT đầu ra. Cách tính này là PROJECT_ASSUMPTION.

Trường payload	Giá trị
salesOrderId	SO-NF-20260807-0142
customerId	CUS-NF-0187
orderType	DOMESTIC_CREDIT
orderStatusBeforeDecision	PENDING_CREDIT_CHECK
currencyCode	VND
outstandingReceivableVnd	342500000
creditLimitVnd	500000000
orderNetAmountVnd	179520000
creditExposureAfterOrderVnd	522020000
creditBlockFlag	N
requestedByEmployeeId	EMP-NF-0041
sourceClassification	SIMULATED_TRANSACTION

Bảng quyết định. Y nghĩa điều kiện đúng; N nghĩa điều kiện sai; - nghĩa điều kiện không xét. Chính sách khớp là FIRST_MATCH: ERP xét từ R01 đến R04 và chạy hành động của hàng đúng đầu tiên. Thứ tự này cần thiết vì đơn đã bị khóa tín dụng phải giữ khóa, dù số tiền đơn có thể nằm trong hạn mức.

Điều kiện hoặc hành động	R01	R02	R03	R04
Loại đơn là DOMESTIC_CREDIT	Y	Y	Y	N
creditBlockFlag là Y	Y	N	N	-
creditExposureAfterOrderVnd lớn hơn creditLimitVnd	-	Y	N	-
Đặt orderStatusAfterDecision là CREDIT_BLOCKED	Y	Y	N	N
Đặt orderStatusAfterDecision là CREDIT_APPROVED	N	N	Y	N
Gửi hàng đợi CREDIT_REVIEW_QUEUE	Y	Y	N	N
Cho phép tạo phiếu xuất kho	N	N	Y	N
Lý do kết quả	CUSTOMER_CREDIT_BLOCK	CREDIT_LIMIT_EXCEEDED	CREDIT_CHECK_PASSED	ORDER_TYPE_OUT_OF_SCOPE

Kết quả cho giao dịch mô phỏng. R02 khớp vì đơn là DOMESTIC_CREDIT, khách hàng chưa bị khóa tín dụng, và 522.020.000 VND lớn hơn hạn mức 500.000.000 VND. ERP đặt trạng thái đơn thành CREDIT_BLOCKED, đặt creditBlockFlag thành Y, chặn tạo phiếu xuất kho, rồi gửi bản ghi vào CREDIT_REVIEW_QUEUE. Không tự động hủy đơn vì vượt hạn mức là tình huống cần xem xét tín dụng, không phải bằng chứng đơn không hợp lệ.

Trường kết quả	Giá trị
decisionRuleId	BR-SO-002
matchedRuleRow	R02
orderStatusAfterDecision	CREDIT_BLOCKED
creditBlockFlag	Y
fulfillmentReleaseAllowed	N
reviewQueueCode	CREDIT_REVIEW_QUEUE
decisionReasonCode	CREDIT_LIMIT_EXCEEDED
decisionTimestamp	2026-08-07T10:15:03+07:00
resultSourceClassification	SIMULATED_RULE_EXECUTION

Hồ sơ hoàn chỉnh — Bảng quyết định phê duyệt chiết khấu đơn bán

Trường lõi	Giá trị đã điền
Artifact ID	TMPL-RULE-002
Tên hồ sơ quyết định	DT-NF-SO-DISCOUNT-001 — Phê duyệt chiết khấu đơn bán nội địa
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày hiệu lực mô phỏng	2026-08-07
Bối cảnh	Nova Foods Trading & Manufacturing là case study mô phỏng; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp.
Quy trình áp dụng	Tạo đơn bán hàng nội địa B2B trong ERP Nova Foods.
Đối tượng quyết định	Đề nghị chiết khấu thương mại theo dòng hàng trên đơn bán SO-NF-20260807-0142.
Tác nhân tạo đề nghị	NV-SALES-017 — Trần Minh Khoa, Sales Executive.
Khách hàng	CUS-NF-00128 — Công ty TNHH Phân phối An Phúc, nhóm khách hàng WHOLESALE-A.
Mặt hàng	FG-NF-00241 — Nước ép cam 1L thùng 12 chai.
Số lượng	480 thùng.
Đơn giá niêm yết	420.000 VND/thùng, chưa bao gồm thuế.
Giá trị hàng trước chiết khấu	201.600.000 VND.
Chiết khấu đề nghị	7%, tương đương 14.112.000 VND.
Giá trị hàng sau chiết khấu	187.488.000 VND, chưa bao gồm thuế.
Nhu cầu gốc	Sales cần chốt đơn giao ngày 2026-08-10; khách hàng yêu cầu chiết khấu vì mua vượt ngưỡng 400 thùng.
Hành vi hiện tại	ERP chỉ cho lưu tỷ lệ chiết khấu; chưa tự xác định cấp phê duyệt theo tỷ lệ và giá trị tiền.
Vấn đề	Nếu Sales tự áp dụng 7%, biên lợi nhuận mô phỏng có thể thấp hơn mức quản trị nội bộ; nếu chờ xử lý thủ công, đơn có thể trễ lịch giao.
Nhu cầu nền	ERP phải xác định đúng trạng thái đơn, người có quyền phê duyệt hoặc từ chối, và lý do quyết định có thể kiểm tra.
Phân loại nguồn	PROJECT_ASSUMPTION — quy tắc đào tạo mô phỏng Nova Foods; không phải chính sách thương mại thực tế, quy định kế toán, thuế hoặc pháp lý.
Thẩm quyền quyết định mô phỏng	NV-SM-003 — Lê Hoài Nam, Sales Manager, quyết định đề nghị không vượt 8% và không vượt 20.000.000 VND.
Hệ quả nếu quyết sai	Phê duyệt thiếu kiểm soát gây giảm doanh thu mô phỏng; từ chối sai gây mất cơ hội bán; áp dụng sai trạng thái gây xuất hàng khi chưa đủ thẩm quyền.

Cơ sở suy luận. Điều kiện phải xét đồng thời tỷ lệ và giá trị chiết khấu. Cùng một tỷ lệ có tác động tiền khác nhau giữa đơn nhỏ và đơn lớn. Đơn này có 7% và 14.112.000 VND; cả hai nằm trong ngưỡng Sales Manager, nên bảng quyết định phải trả về trạng thái chờ Sales Manager thay vì tự động áp dụng.

Mã điều kiện/kết quả	Nội dung	Giá trị đơn SO-NF-20260807-0142
C01	Khách hàng thuộc nhóm WHOLESALE-A	Có
C02	Số lượng từ 400 thùng trở lên	Có, 480 thùng
C03	Tỷ lệ chiết khấu từ 0% đến 5%	Không, 7%
C04	Tỷ lệ chiết khấu trên 5% đến 8%	Có, 7%
C05	Giá trị chiết khấu không vượt 20.000.000 VND	Có, 14.112.000 VND
C06	Tỷ lệ chiết khấu trên 8%	Không
C07	Giá trị chiết khấu vượt 20.000.000 VND	Không
A01	Áp dụng tự động	Không
A02	Chuyển chờ Sales Manager	Có
A03	Chuyển chờ Commercial Director	Không
A04	Từ chối và khóa giá chiết khấu bằng 0%	Không

Quy tắc	C01	C02	C03	C04	C05	C06	C07	Quyết định ERP	Trạng thái kết quả	Người xử lý
R01	Có	Có	Có	Không	Có	Không	Không	Áp dụng chiết khấu đề nghị	DISCOUNT_AUTO_APPROVED	Hệ thống
R02	Có	Có	Không	Có	Có	Không	Không	Tạo yêu cầu phê duyệt	PENDING_SALES_MANAGER	NV-SM-003
R03	Có	Có	Không	Có	Không	Không	Có	Tạo yêu cầu phê duyệt cấp cao	PENDING_COMMERCIAL_DIRECTOR	NV-CD-001 — Nguyễn Bảo Vy
R04	Có	Có	Không	Không	Có	Có	Không	Tạo yêu cầu phê duyệt cấp cao	PENDING_COMMERCIAL_DIRECTOR	NV-CD-001
R05	Có	Có	Không	Không	Không	Có	Có	Tạo yêu cầu phê duyệt cấp cao	PENDING_COMMERCIAL_DIRECTOR	NV-CD-001
R06	Không	Không	Không	Không	Không	Không	Không	Từ chối chiết khấu	DISCOUNT_REJECTED	Hệ thống
R07	Có	Không	Không	Không	Không	Không	Không	Từ chối chiết khấu	DISCOUNT_REJECTED	Hệ thống
R08	Không	Có	Không	Không	Không	Không	Không	Từ chối chiết khấu	DISCOUNT_REJECTED	Hệ thống

Tiêu chí lựa chọn	Phương án 1: Sales tự áp dụng	Phương án 2: Một cấp duyệt mọi trường hợp	Phương án 3: Quyết định theo ngưỡng tỷ lệ và tiền
Kiểm soát thẩm quyền	Thấp	Trung bình	Cao
Tốc độ xử lý đơn nhỏ	Cao	Thấp	Cao
Phản ánh tác động tiền	Không	Có nhưng không phân loại	Có
Khả năng kiểm thử theo bảng	Thấp	Trung bình	Cao
Kết quả	Không chọn	Không chọn	Chọn

Quyết định mô phỏng: chọn Phương án 3. Ràng buộc 7% và 14.112.000 VND thỏa R02; ERP tạo yêu cầu DAR-NF-20260807-0081, giữ đơn ở PENDING_SALES_MANAGER, không cho tạo phiếu xuất kho.

Payload quyết định mô phỏng

Trường dữ liệu	Giá trị
decisionRequestId	DAR-NF-20260807-0081
salesOrderId	SO-NF-20260807-0142
customerId	CUS-NF-00128
requesterEmployeeId	NV-SALES-017
discountPercent	7.00
discountAmountVnd	14112000
evaluatedRuleId	R02
decisionStatus	PENDING_SALES_MANAGER
assignedApproverEmployeeId	NV-SM-003
createdAt	2026-08-07T14:20:00+07:00
currencyCode	VND
sourceClassification	PROJECT_ASSUMPTION

Hồ sơ quyết định hoàn chỉnh: chặn xuất bán khi vượt hạn mức công nợ

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là tổng hợp. Ngày ghi nhận 2026-08-07, múi giờ Asia/Ho_Chi_Minh, locale vi-VN, tiền tệ VND. Quyết định table là bảng liệt kê tổ hợp điều kiện đầu vào và hành động hệ thống tương ứng.

Trường	Giá trị hoàn chỉnh
Mã hồ sơ quyết định	NF-ERP-DT-CR-001
Quy trình	Sales Order Release — mở chặn đơn bán để xuất kho
Giao dịch mô phỏng	Đơn bán SO-20260807-0184; khách hàng CUS-000184; Công ty TNHH Thực phẩm An Phú
Giá trị đơn	185.000.000 VND
Công nợ chưa thanh toán trước đơn	342.000.000 VND
Hạn mức công nợ đang cấu hình	500.000.000 VND
Tổng phơi nhiễm sau đơn	527.000.000 VND
Hóa đơn quá hạn	INV-20260701-0098, quá hạn 12 ngày, số dư 42.000.000 VND
Vai trò gửi đơn	Nhân viên kinh doanh Lê Minh Khoa, USR-SAL-014
Vai trò phê duyệt ngoại lệ	Credit Manager Trần Ngọc Mai, USR-CRM-003
Trạng thái hiện tại mô phỏng	ERP cho phép nhân viên kinh doanh tự bỏ cờ chặn tín dụng trước khi tạo phiếu xuất kho
Phân loại nguồn cho hiện trạng	Quan sát quy trình mô phỏng SIM-OBS-20260807-01
Nhu cầu gốc	Chỉ vai trò có thẩm quyền tín dụng được mở chặn; ERP phải lưu lý do, người quyết định, thời điểm và giá trị phơi nhiễm.
Hậu quả nếu sai	Xuất hàng vượt kiểm soát gây rủi ro không thu hồi 185.000.000 VND; chặn sai làm chậm giao hàng, giảm độ tin cậy dữ liệu công nợ và tạo tranh chấp trách nhiệm.

Cầu nối lập luận: 342.000.000 + 185.000.000 = 527.000.000 VND, lớn hơn hạn mức 500.000.000 VND là 27.000.000 VND. Đồng thời còn hóa đơn quá hạn 12 ngày. Hai sự kiện là dữ kiện giao dịch mô phỏng; vì vậy đơn không được tự động chuyển sang trạng thái sẵn sàng xuất kho.

Phương án	Mô tả	Đánh giá theo tiêu chí	Kết quả
OPT-01	Giữ quyền bỏ chặn cho nhân viên kinh doanh	Nhanh nhưng không phân tách nhiệm vụ; không kiểm soát xung đột lợi ích	Không chọn
OPT-02	ERP tự chặn mọi đơn vượt hạn mức hoặc có nợ quá hạn; Credit Manager quyết định ngoại lệ	Kiểm soát tốt, có phân tách nhiệm vụ, có dấu vết quyết định, xử lý được ngoại lệ hợp lệ	Khuyến nghị
OPT-03	ERP tự từ chối vĩnh viễn mọi đơn vi phạm	Kiểm soát cao nhưng không đáp ứng tình huống khách hàng đã có bằng chứng thanh toán hợp lệ	Không chọn

Tiêu chí quyết định	Ngưỡng áp dụng	OPT-01	OPT-02	OPT-03
Phân tách nhiệm vụ	Người tạo đơn không tự mở chặn	Không đạt	Đạt	Đạt
Dấu vết kiểm toán	Lưu người, thời điểm, lý do	Không đạt	Đạt	Đạt
Xử lý ngoại lệ có kiểm soát	Có quyết định của Credit Manager	Không đạt	Đạt	Không đạt
Tránh chậm giao hàng không cần thiết	Có luồng xem xét ngoại lệ	Đạt	Đạt	Không đạt

Điều kiện	Quyết định ERP	Trạng thái đơn	Người có thể hành động tiếp
Phơi nhiễm sau đơn không vượt hạn mức; không có hóa đơn quá hạn	Tự mở chặn tín dụng	READY_FOR_FULFILLMENT	Nhân viên kho theo quyền được cấp
Phơi nhiễm sau đơn vượt hạn mức; không có hóa đơn quá hạn	Chặn tín dụng	CREDIT_HOLD	Credit Manager
Phơi nhiễm không vượt hạn mức; có ít nhất một hóa đơn quá hạn	Chặn tín dụng	CREDIT_HOLD	Credit Manager
Phơi nhiễm sau đơn vượt hạn mức; có ít nhất một hóa đơn quá hạn	Chặn tín dụng	CREDIT_HOLD	Credit Manager
Credit Manager chấp nhận ngoại lệ, có lý do và thời hạn hiệu lực	Mở chặn một lần cho đơn cụ thể	READY_FOR_FULFILLMENT	Nhân viên kho theo quyền được cấp
Credit Manager từ chối ngoại lệ	Giữ chặn	CREDIT_HOLD	Nhân viên kinh doanh trao đổi khách hàng

Khuyến nghị: chọn OPT-02. Credit Manager Trần Ngọc Mai là người có thẩm quyền quyết định ngoại lệ trong case mô phỏng; Principal IT Business Analyst chỉ ghi nhận quyết định và không thay thế thẩm quyền tín dụng. Quyết định chưa là phê duyệt, baseline, quy định vận hành thật, diễn giải kế toán hoặc kết luận pháp lý.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi khách hàng, số tiền, người dùng và giao dịch dưới đây là dữ liệu tổng hợp. Ngoại lệ là trường hợp không đi theo kết quả tự động của bảng quyết định nhưng vẫn phải có kiểm soát, lý do, người có thẩm quyền và dấu vết kiểm toán.

4.1 Ngoại lệ và đường đi âm

ID ngoại lệ	Tình huống đầu vào	Kết quả tự động	Xử lý ngoại lệ được phép	Kiểm soát bắt buộc	Kết quả cuối
EXC-CR-001	Đơn SO-NF-20260807-0142 của CUS-NF-0042 có phơi nhiễm sau đơn 128.500.000 VND, vượt hạn mức 120.000.000 VND; không có hóa đơn quá hạn	CREDIT_HOLD	Credit Manager có thể mở chặn một lần cho đúng đơn này	Ghi lý do, thời hạn hiệu lực, người quyết định, thời điểm Asia/Ho_Chi_Minh; người tạo đơn không tự mở chặn	READY_FOR_FULFILLMENT khi ngoại lệ còn hiệu lực
EXC-CR-002	Đơn có ít nhất một hóa đơn quá hạn, dù phơi nhiễm sau đơn không vượt hạn mức	CREDIT_HOLD	Credit Manager xem xét ngoại lệ từng đơn	Không được sửa ngày đến hạn hoặc số dư hóa đơn để né điều kiện; lưu lý do nghiệp vụ mô phỏng	Chỉ mở chặn khi có quyết định ngoại lệ còn hiệu lực
EXC-CR-003	Credit Manager từ chối ngoại lệ cho SO-NF-20260807-0142	CREDIT_HOLD	Không có mở chặn thay thế bởi Sales hoặc Warehouse	Lưu người từ chối, thời điểm, lý do từ chối; giữ nguyên trạng thái chặn	CREDIT_HOLD
EXC-CR-004	Ngoại lệ đã hết hiệu lực trước khi kho xác nhận xử lý đơn	Không dùng kết quả mở chặn cũ	ERP đánh giá lại bảng quyết định với dữ liệu hiện thời	Không cho phép dùng lại quyết định hết hạn; ghi log đánh giá lại	CREDIT_HOLD nếu vẫn vượt điều kiện
EXC-CR-005	Thiếu hạn mức tín dụng, số dư phải thu, hoặc trạng thái quá hạn từ nguồn dữ liệu mô phỏng	Không thể đánh giá an toàn	Chặn đơn để tránh mở chặn sai	Hiển thị lỗi dữ liệu; không coi giá trị thiếu là 0 VND; chuyển xử lý dữ liệu	CREDIT_HOLD

Đường đi âm kiểm tra hành vi khi điều kiện không đủ hoặc quyền không đúng. Mục tiêu không phải làm đơn đi tiếp, mà ngăn ERP phát hành lệnh kho dựa trên dữ liệu thiếu, dữ liệu quá hạn hoặc quyết định không hợp lệ.

ID đường đi âm	Bước kích hoạt	Dữ liệu tổng hợp	Hành vi phải có	Hành vi không được có
NEG-CR-001	Sales tạo đơn vượt hạn mức	CUS-NF-0042; hạn mức 120.000.000 VND; phơi nhiễm sau đơn 128.500.000 VND	Đặt CREDIT_HOLD; không tạo quyền xử lý kho	Tự đổi đơn thành READY_FOR_FULFILLMENT
NEG-CR-002	Sales cố mở chặn đơn do mình tạo	User sales.nguyen.minh; đơn SO-NF-20260807-0142	Từ chối thao tác; ghi audit log quyền bị từ chối	Cho Sales ghi đè quyết định tín dụng
NEG-CR-003	Credit Manager mở chặn nhưng không nhập lý do	User credit.tran.ngoc.mai; lý do rỗng	Từ chối lưu ngoại lệ	Tạo ngoại lệ không có lý do
NEG-CR-004	Credit Manager nhập thời hạn hiệu lực trước thời điểm quyết định	Hiệu lực 2026-08-07 08:00; quyết định 2026-08-07 09:15	Từ chối lưu vì thời hạn không hợp lệ	Mở chặn bằng quyết định đã hết hạn
NEG-CR-005	Warehouse cố xác nhận xử lý đơn đang CREDIT_HOLD	User warehouse.le.quang; đơn bị chặn	Từ chối xác nhận; nêu trạng thái cần xử lý là CREDIT_HOLD	Tạo phiếu xuất kho hoặc giảm tồn kho

4.2 Bằng chứng tham chiếu

Bằng chứng là nguồn hoặc artifact dùng để giải thích vì sao điều kiện, kiểm soát hoặc điểm chưa rõ tồn tại. Bằng chứng không biến nội dung mô phỏng thành baseline, phê duyệt, nghĩa vụ pháp lý hoặc cấu hình production.

Mẫu bằng chứng tham chiếu dưới đây là template hoàn chỉnh có thể sao chép. Người lập phải ghi ID duy nhất, loại nguồn, tham chiếu truy cập được, mô tả đầy đủ, quyết định hoặc kiểm soát được hỗ trợ, ranh giới sử dụng, owner và trạng thái kiểm tra. Không dùng bằng chứng thiếu mô tả, thiếu nguồn hoặc vượt ranh giới sử dụng để suy ra thẩm quyền, phê duyệt hay quy tắc vận hành.

Evidence ID	Loại bằng chứng	Tham chiếu chính xác	Mô tả bằng chứng	Dùng cho quyết định, điều kiện hoặc kiểm soát nào	Ranh giới sử dụng và hệ quả nếu vượt ranh giới	Owner nguồn hoặc owner xác minh	Trạng thái
EVD-<DOMAIN>-<NNN>	Artifact nội bộ, nguồn chuẩn, policy, biên bản, log, dữ liệu kiểm thử hoặc nguồn khác có thể xác định	Đường dẫn, URL, tên tài liệu, phiên bản hoặc định danh bản ghi có thể truy cập	Nêu nội dung fact được dùng; không ghi kết luận không có trong nguồn	ID rule, requirement, condition, exception, test hoặc escalation được bằng chứng hỗ trợ	Nêu phạm vi được phép; nêu rõ bằng chứng không được dùng để suy ra điều gì	Vai trò hoặc nhóm chịu trách nhiệm về nguồn, hoặc vai trò xác minh	IN_REVIEW, Verification required, Open, hoặc trạng thái đã được kiểm soát

ID bằng chứng	Phân loại nguồn	Tham chiếu chính xác	Dùng cho	Ranh giới sử dụng
EVD-CR-001	Artifact nội bộ mô phỏng	/03-templates/TMPL-RULE-002-decision-table.md, Tier 3 Core Record	Điều kiện phơi nhiễm, hóa đơn quá hạn, trạng thái CREDIT_HOLD và READY_FOR_FULFILLMENT	Chỉ là case học liệu Nova Foods tổng hợp
EVD-CR-002	Artifact quản trị canonical đang lập kế hoạch	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Quy tắc phải giữ liên kết canonical khi được thiết lập	IN_REVIEW; chưa baseline, chưa là quy tắc vận hành
EVD-CR-003	Artifact quản trị canonical đang lập kế hoạch	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Quy ước ID, owner và escalation	Không tự cấp thẩm quyền tín dụng hoặc phê duyệt
EVD-CR-004	Nguồn chuẩn kiểm thử	ISTQB CTFL Syllabus v4.0.1, https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Thuật ngữ đường đi âm và kiểm thử hộp đen	Không chứng minh rule tín dụng Nova Foods
EVD-CR-005	Nguồn BA	BABOK Guide Version 3, https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Thuật ngữ quản lý yêu cầu, stakeholder và traceability	Không viện dẫn số trang hoặc điều khoản chưa kiểm tra

4.3 Giả định và mục cần xác minh

Giả định dự án là điều tạm dùng để hoàn chỉnh case học liệu khi chưa có bằng chứng đủ thẩm quyền. Verification required nghĩa là phải được vai trò đúng thẩm quyền kiểm tra trước khi dùng cho quyết định thực tế.

ID	Loại	Nội dung	Cầu nối bằng chứng và suy luận	Owner xác minh	Trạng thái
ASM-CR-001	Giả định dự án	Phơi nhiễm tín dụng bằng tổng số dư phải thu chưa thanh toán cộng giá trị đơn chưa giao, tính bằng VND	EVD-CR-001 cần một giá trị so sánh hạn mức; công thức này được chọn cho case mô phỏng để bảng quyết định có đầu vào xác định	Business Owner và Accounting Owner	Verification required
ASM-CR-002	Giả định dự án	Một hóa đơn được xem là quá hạn khi ngày đến hạn sớm hơn ngày đánh giá	EVD-CR-001 yêu cầu điều kiện “có hóa đơn quá hạn”; chưa có policy Nova Foods đã xác minh định nghĩa khác	Credit Manager và Accounting Owner	Verification required
ASM-CR-003	Giả định dự án	Credit Manager là vai trò duy nhất quyết định ngoại lệ tín dụng	Ma trận lựa chọn của Core Record chọn OPT-02 để phân tách nhiệm vụ; chưa có ma trận quyền thực tế	Business Owner và Security Owner	Verification required
VR-CR-001	Cần xác minh	Hạn mức 120.000.000 VND của CUS-NF-0042 chỉ là test data, không phải hạn mức khách hàng thật	Dữ liệu Nova Foods bị giới hạn là tổng hợp theo metadata corpus	Business Owner	Open
VR-CR-002	Cần xác minh	Thời hạn tối đa của ngoại lệ tín dụng chưa được xác định	EXC-CR-001 cần thời hạn để ngăn mở chặn vô hạn; chưa có policy được cung cấp	Credit Manager và Business Owner	Open
VR-CR-003	Cần xác minh	Trường audit log, thời gian lưu và quyền truy cập log chưa là thiết kế bảo mật	NEG-CR-002 đến NEG-CR-005 yêu cầu dấu vết; chi tiết kỹ thuật cần kiến trúc và bảo mật xác nhận	Security Owner và Architect	Open

4.4 Bản ghi escalation

Escalation là chuyển vấn đề đến vai trò có thẩm quyền khi BA không được phép tự quyết. Principal IT Business Analyst chỉ đóng gói bằng chứng, tác động và liên kết; không thay Credit Manager, Accounting Owner, Security Owner hoặc Business Owner kết luận.

ID escalation	Vấn đề	Kích hoạt	Người nhận	Gói bằng chứng	Quyết định cần có	Trạng thái
ESC-CR-001	Chưa có chính sách xác định thời hạn ngoại lệ	VR-CR-002 còn Open	Credit Manager, Business Owner	EXC-CR-001, EXC-CR-004, ASM-CR-003	Xác định thời hạn, điều kiện gia hạn và quyền thu hồi ngoại lệ	Open
ESC-CR-002	Công thức phơi nhiễm có thể ảnh hưởng hạch toán hoặc báo cáo công nợ	ASM-CR-001 chưa được Accounting Owner xác minh	Accounting Owner, Business Owner	ASM-CR-001, NEG-CR-001, EVD-CR-001	Xác nhận thành phần số dư và thời điểm chốt dữ liệu	Open
ESC-CR-003	Audit log và phân quyền mở chặn có tác động bảo mật	VR-CR-003 còn Open	Security Owner, Architect	NEG-CR-002 đến NEG-CR-005, EVD-CR-003	Xác định quyền tối thiểu, trường log và cơ chế chống sửa log	Open

Ma trận truy vết đầu-cuối cho quy tắc chiết khấu đơn bán Nova Foods

Truy vết đầu-cuối nối nhu cầu nghiệp vụ đến kiểm thử để chứng minh mỗi quyết định có lý do, có dữ liệu thực thi và có cách phát hiện lỗi. Case Nova Foods là mô phỏng giáo dục, dùng dữ liệu tổng hợp. Các ID dưới đây là liên kết case trong /03-templates/TMPL-RULE-002-decision-table.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, approval, cấu hình ERP hay quy định vận hành thật.

Chuỗi	ID case	Loại	Nội dung đầy đủ	Cầu nối bằng chứng và suy luận	Nguồn/phân loại
1	NEED-NF-SALES-001	NEED — nhu cầu	Nhân viên bán hàng cần ERP xác định mức chiết khấu thương mại nhất quán cho đơn bán nội địa theo hạng khách hàng và tổng tiền hàng trước thuế.	Nếu người dùng tự tính chiết khấu, cùng điều kiện có thể ra kết quả khác nhau. Cần quy tắc quyết định tập trung trong ERP.	Mô phỏng giáo dục; project assumption.
2	REQ-NF-SALES-014	REQ — yêu cầu	ERP phải tính discountRate cho đơn có salesChannel = DOMESTIC, dựa trên customerTier và grossMerchandiseAmountVND, trước VAT.	NEED yêu cầu tính nhất quán. REQ biến nhu cầu thành hành vi hệ thống đo được: đầu vào, phạm vi, đầu ra.	Suy ra từ NEED-NF-SALES-001; chưa baseline.
3	BR-NF-SALES-006	BR — business rule, quy tắc nghiệp vụ	Khách GOLD nhận 5% khi tổng tiền hàng từ 50,000,000 VND; khách SILVER nhận 3% khi tổng tiền hàng từ 30,000,000 VND; mọi trường hợp còn lại nhận 0%. Không cộng dồn hai mức.	REQ cần một kết quả duy nhất. Ngưỡng theo từng hạng loại bỏ diễn giải “gần đạt ngưỡng” và cấm cộng dồn. Giá trị tiền là giả định dự án, chưa phải chính sách Nova Foods thật.	/01-curriculum/CANONICAL_BUSINESS_RULES.md; trạng thái artifact IN_REVIEW; nội dung case là project assumption.
4	AC-NF-SALES-014-01	AC — acceptance criterion, tiêu chí chấp nhận	Với DOMESTIC, GOLD, 50,000,000 VND, hệ thống trả discountRate = 0.05 và discountAmountVND = 2,500,000.	Đây là biên dưới của nhánh GOLD; kiểm tra toán tử “từ” được hiểu là >=, không phải >.	Dẫn xuất kiểm thử từ BR-NF-SALES-006; chưa xác nhận QA.
5	AC-NF-SALES-014-02	AC	Với DOMESTIC, SILVER, 29,999,999 VND, hệ thống trả discountRate = 0 và discountAmountVND = 0.	Đây là giá trị ngay dưới ngưỡng SILVER; phát hiện lỗi áp sai ngưỡng hoặc làm tròn tăng chiết khấu.	Dẫn xuất kiểm thử từ BR-NF-SALES-006; chưa xác nhận QA.
6	AC-NF-SALES-014-03	AC	Với EXPORT, GOLD, 80,000,000 VND, quy tắc này không áp dụng; hệ thống trả mã kết quả RULE_NOT_APPLICABLE.	REQ giới hạn salesChannel = DOMESTIC. Không được suy luận chiết khấu xuất khẩu từ rule nội địa.	Dẫn xuất từ REQ-NF-SALES-014; project assumption về mã kết quả.
7	DATA-NF-SO-021	DATA — dữ liệu logic	salesChannel: mã kênh bán, giá trị case DOMESTIC hoặc EXPORT, bắt buộc.	AC-03 cần phân biệt phạm vi rule; thiếu trường này không thể xác định rule có áp dụng.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; cấu trúc case chưa baseline.
8	DATA-NF-CUSTOMER-008	DATA	customerTier: hạng khách hàng, giá trị case GOLD, SILVER, STANDARD, bắt buộc.	BR phân nhánh theo hạng khách hàng; dữ liệu không hợp lệ không được tự ánh xạ sang hạng khác.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; cấu trúc case chưa baseline.
9	DATA-NF-SO-022	DATA	grossMerchandiseAmountVND: tổng tiền hàng trước VAT, số nguyên VND không âm, bắt buộc.	BR dùng ngưỡng VND trước VAT. Trường tiền sau VAT sẽ cho kết quả khác, nên không thay thế được.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; project assumption.
10	API-NF-PRICING-003	API — giao diện lập trình ứng dụng	POST /pricing/discount-evaluations nhận salesChannel, customerTier, grossMerchandiseAmountVND; trả ruleId, discountRate, discountAmountVND, evaluationStatus.	REQ cần điểm thực thi có đầu vào và đầu ra kiểm chứng được. Tên endpoint, payload và trạng thái là thiết kế mô phỏng, không phải API Nova Foods thật.	OpenAPI Specification OAS 3.1.1: nguồn chuẩn cho mô tả HTTP API; không xác nhận thiết kế case.
11	TC-NF-PRICING-041	TC — test case, ca kiểm thử	Gửi DOMESTIC/GOLD/50000000; kỳ vọng BR-NF-SALES-006, tỷ lệ 0.05, số tiền 2500000, trạng thái APPLIED.	Thực thi trực tiếp AC-NF-SALES-014-01; bao phủ biên đủ điều kiện GOLD.	Dẫn xuất từ AC-NF-SALES-014-01; thuật ngữ kiểm thử tham chiếu ISTQB CTFL v4.0.1.
12	TC-NF-PRICING-042	TC	Gửi DOMESTIC/SILVER/29999999; kỳ vọng BR-NF-SALES-006, tỷ lệ 0, số tiền 0, trạng thái APPLIED.	Thực thi trực tiếp AC-NF-SALES-014-02; bao phủ biên không đủ điều kiện SILVER.	Dẫn xuất từ AC-NF-SALES-014-02; chưa chạy test.
13	TC-NF-PRICING-043	TC	Gửi EXPORT/GOLD/80000000; kỳ vọng ruleId = BR-NF-SALES-006, trạng thái RULE_NOT_APPLICABLE, tỷ lệ 0, số tiền 0.	Thực thi trực tiếp AC-NF-SALES-014-03; chứng minh rule không lan sang kênh ngoài phạm vi.	Dẫn xuất từ AC-NF-SALES-014-03; chưa chạy test.
14	DEF-NF-PRICING-007	DEF — defect, lỗi	Không có lỗi được ghi nhận tại IN_REVIEW. DEF-NF-PRICING-007 chưa được tạo vì chưa có kết quả chạy test, bằng chứng tái hiện, mức độ ảnh hưởng hay quyết định triage.	DEF chỉ tồn tại sau quan sát lỗi có bằng chứng. Tạo DEF trước sẽ bịa lịch sử chất lượng.	Không áp dụng tại thời điểm 2026-08-07.
15	CR-NF-PRICING-004	CR — change request, yêu cầu thay đổi	Không có yêu cầu thay đổi được ghi nhận tại IN_REVIEW. CR-NF-PRICING-004 chưa được tạo vì chưa có baseline để so sánh và chưa có thay đổi được ủy quyền.	CR cần chênh lệch so với phạm vi hoặc baseline đã kiểm soát. Corpus hiện chưa có baseline reference.	Không áp dụng tại thời điểm 2026-08-07.

Kiểm tra liên kết	Kết quả case	Tiêu chí quyết định
NEED đến REQ	Đủ	REQ-NF-SALES-014 chuyển nhu cầu nhất quán thành hành vi ERP có đầu vào và đầu ra.
REQ đến BR	Đủ	BR-NF-SALES-006 định nghĩa ngưỡng, hạng, phạm vi kênh và quy tắc không cộng dồn.
BR đến AC	Đủ	Ba AC bao phủ biên đạt ngưỡng, dưới ngưỡng, ngoài phạm vi.
AC đến DATA/API	Đủ	Mỗi điều kiện AC có trường dữ liệu và điểm gọi API tương ứng.
AC đến TC	Đủ	Mỗi AC có đúng một TC mô phỏng để kiểm tra kết quả quan sát được.
TC đến DEF/CR	Chưa kích hoạt	Chưa có chạy test, defect, baseline hoặc change request; không tạo bản ghi giả.

Bảng quyết định hoàn chỉnh — mở chặn đơn bán theo hạn mức tín dụng

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã khách hàng, số tiền và quyết định dưới đây dùng dữ liệu tổng hợp VND. Bảng quyết định (decision table) biến tổ hợp điều kiện thành một kết quả duy nhất, giúp BA, developer và QA cùng kiểm tra một luật mà không tự diễn giải khác nhau. Phạm vi bảng: ERP xét mở chặn tín dụng trước khi phát hành đơn bán SO-NF-260807-001.

Điều kiện / hành động	R1	R2	R3	R4	R5	R6	R7	R8
C1. Khách hàng có trạng thái ACTIVE	Có	Có	Có	Có	Không	Không	Không	Không
C2. Khách hàng không có công nợ quá hạn	Có	Có	Không	Không	Có	Có	Không	Không
C3. Công_nợ_hiện_tại + Giá_trị_đơn ≤ Hạn_mức_tín_dụng	Có	Không	Có	Không	Có	Không	Có	Không
A1. Cho phép trạng thái đơn CREDIT_RELEASED	Có	Không	Không	Không	Không	Không	Không	Không
A2. Đặt trạng thái đơn CREDIT_BLOCKED	Không	Có	Có	Có	Có	Có	Có	Có
A3. Ghi mã lý do chặn	Không	LIMIT_EXCEEDED	OVERDUE_DEBT	OVERDUE_DEBT	CUSTOMER_INACTIVE	CUSTOMER_INACTIVE	CUSTOMER_INACTIVE	CUSTOMER_INACTIVE

Điều kiện C3 dùng số tiền trước thuế, vì mục tiêu luật mô phỏng là kiểm soát tổng dư nợ thương mại so với hạn mức đã gán cho khách hàng. Khi nhiều điều kiện không đạt, mã lý do ưu tiên theo thứ tự CUSTOMER_INACTIVE, rồi OVERDUE_DEBT, rồi LIMIT_EXCEEDED; lý do: khách hàng không hoạt động ngăn mọi giao dịch trước, công nợ quá hạn ngăn cấp thêm tín dụng, còn vượt hạn mức chỉ xét khi hai điều kiện trước đạt.

Bộ dữ liệu kiểm tra tổng hợp	Khách hàng	Trạng thái	Công nợ quá hạn	Công nợ hiện tại	Giá trị đơn SO-NF-260807-001	Hạn mức tín dụng	Rule áp dụng	Kết quả mong đợi
DT-RULE-002-01	CUS-NF-001	ACTIVE	0 VND	75.000.000 VND	20.000.000 VND	100.000.000 VND	R1	CREDIT_RELEASED
DT-RULE-002-02	CUS-NF-002	ACTIVE	0 VND	85.000.000 VND	20.000.000 VND	100.000.000 VND	R2	CREDIT_BLOCKED; LIMIT_EXCEEDED
DT-RULE-002-03	CUS-NF-003	ACTIVE	5.000.000 VND	40.000.000 VND	20.000.000 VND	100.000.000 VND	R3	CREDIT_BLOCKED; OVERDUE_DEBT
DT-RULE-002-04	CUS-NF-004	ACTIVE	5.000.000 VND	90.000.000 VND	20.000.000 VND	100.000.000 VND	R4	CREDIT_BLOCKED; OVERDUE_DEBT
DT-RULE-002-05	CUS-NF-005	INACTIVE	0 VND	75.000.000 VND	20.000.000 VND	100.000.000 VND	R5	CREDIT_BLOCKED; CUSTOMER_INACTIVE
DT-RULE-002-06	CUS-NF-006	INACTIVE	0 VND	85.000.000 VND	20.000.000 VND	100.000.000 VND	R6	CREDIT_BLOCKED; CUSTOMER_INACTIVE
DT-RULE-002-07	CUS-NF-007	INACTIVE	5.000.000 VND	40.000.000 VND	20.000.000 VND	100.000.000 VND	R7	CREDIT_BLOCKED; CUSTOMER_INACTIVE
DT-RULE-002-08	CUS-NF-008	INACTIVE	5.000.000 VND	90.000.000 VND	20.000.000 VND	100.000.000 VND	R8	CREDIT_BLOCKED; CUSTOMER_INACTIVE

DT-RULE-002-01 kiểm tra biên hợp lệ: 75.000.000 + 20.000.000 = 95.000.000 VND, không vượt 100.000.000 VND. DT-RULE-002-02 kiểm tra biên không hợp lệ: 85.000.000 + 20.000.000 = 105.000.000 VND, vượt hạn mức 5.000.000 VND. Bảng này là nội dung mô phỏng IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải cấu hình ERP, baseline, phê duyệt tín dụng, kết luận kế toán hay quyết định vận hành thực tế.

5. Tier 4 ? Senior BA Quality Gate

Quality Gate là cổng kiểm soát trước baseline: Senior BA kiểm tra decision table có đủ để đội phát triển và kiểm thử diễn giải cùng một quyết định hay không. Kết quả PASS nghĩa là mục kiểm tra đạt trong phạm vi review, không tạo baseline, phê duyệt, kết luận pháp lý, kế toán, bảo mật hay quyền dùng production. FAIL nghĩa là có sai lệch cần sửa. STOP nghĩa là không được tiếp tục review chi tiết hoặc chuyển giao. ESCALATE nghĩa là chuyển vấn đề kèm bằng chứng cho vai trò có thẩm quyền.

ID kiểm tra	Hạng mục và tiêu chí PASS	FAIL khi	STOP khi	ESCALATE đến
QG-RULE-002-01	Tính đầy đủ: mọi tổ hợp điều kiện trong phạm vi rule có một kết quả rõ; điều kiện, hành động, mã lỗi và ngoại lệ đều có ID.	Thiếu tổ hợp, thiếu kết quả, hoặc một ô quyết định không xác định.	Không xác định được phạm vi rule hoặc thiếu bảng quyết định Tier 3.	Business Owner để xác nhận phạm vi nghiệp vụ.
QG-RULE-002-02	Tính nhất quán: cùng đầu vào phải cho cùng đầu ra; thứ tự ưu tiên giữa CUSTOMER_INACTIVE, OVERDUE_DEBT, LIMIT_EXCEEDED không mâu thuẫn.	Hai rule cùng điều kiện nhưng trả kết quả khác.	Mâu thuẫn làm thay đổi việc cho phép hay chặn đơn hàng.	Business Owner; Architect nếu cần quy tắc ưu tiên hệ thống.
QG-RULE-002-03	Tính kiểm thử được: mỗi rule có dữ liệu kiểm thử cụ thể, kết quả kỳ vọng, biên so sánh và mã rule liên kết.	Không tạo được test case độc lập từ rule.	Không biết toán tử so sánh, đơn vị tiền tệ, hoặc cách tính dư nợ.	QA Owner; Business Owner.
QG-RULE-002-04	Traceability: mỗi quyết định liên kết ngược đến nguồn, rule ID và artifact canonical; liên kết không dùng tên tự do thay ID.	ID sai, đứt liên kết, hoặc trỏ sang bản sao không kiểm soát.	Canonical ID hoặc source classification chưa xác định.	Principal IT Business Analyst / Technical Curriculum Author.
QG-RULE-002-05	Thẩm quyền nguồn: nguồn nghiệp vụ được phân loại rõ; chuẩn chỉ dùng trong safe use boundary; giả định được gắn project assumption hoặc Verification required.	Diễn đạt giả định như fact, luật, cấu hình ERP hoặc nghĩa vụ bắt buộc.	Rule dựa vào diễn giải pháp lý, kế toán, thuế, an toàn thực phẩm chưa được vai trò có thẩm quyền xác minh.	Legal Owner, Accounting Owner, Compliance Owner hoặc Food-safety Domain Owner.
QG-RULE-002-06	Ownership: owner của rule, owner dữ liệu đầu vào, owner xử lý ngoại lệ và owner thay đổi được phân biệt.	Một vai trò bị gán quyền quyết định ngoài thẩm quyền.	Không có vai trò chịu trách nhiệm khi CREDIT_BLOCKED.	Business Owner; Credit Control Owner.
QG-RULE-002-07	Ranh giới bảo mật và riêng tư: rule chỉ dùng dữ liệu cần thiết; không tiết lộ dữ liệu cá nhân, bí mật tín dụng hoặc thông tin xác thực trong bảng, test data, log hay mã lỗi.	Test data chứa dữ liệu thật, mã lỗi làm lộ dư nợ chi tiết cho vai trò không phù hợp, hoặc thiếu phân loại truy cập.	Có yêu cầu xử lý dữ liệu cá nhân hoặc chia sẻ dữ liệu tín dụng nhưng chưa xác định quyền truy cập và mục đích xử lý.	Security Owner; Privacy/Legal Owner.
QG-RULE-002-08	Ranh giới pháp lý và kế toán: decision table phân biệt chặn tín dụng vận hành với ghi nhận kế toán, thuế, hóa đơn và nghĩa vụ pháp lý.	Rule tự suy ra bút toán, thuế, hóa đơn hoặc tuân thủ pháp lý.	Kết quả rule có thể tạo, sửa, hủy chứng từ kế toán hoặc hóa đơn mà chưa có xác nhận chuyên môn.	Accounting Owner; Legal Owner.
QG-RULE-002-09	Tác động thay đổi: thay đổi điều kiện, ngưỡng, mã trạng thái hoặc kết quả phải nêu artifact, test, tích hợp và vai trò bị ảnh hưởng.	Chỉ sửa decision table nhưng không đánh giá test case, API, UI, báo cáo hoặc quyền truy cập liên quan.	Thay đổi có thể làm sai lịch sử quyết định, dữ liệu đã ghi nhận hoặc luồng đơn hàng đang xử lý.	Architect; QA Owner; Business Owner; Accounting Owner khi có tác động sổ sách.
QG-RULE-002-10	Kiểm soát mô phỏng: Nova Foods được ghi rõ là mô phỏng giáo dục; mọi khách hàng, hạn mức và số tiền là dữ liệu tổng hợp bằng VND.	Nội dung ám chỉ dữ liệu thật, khách hàng thật, cấu hình ERP thật hoặc quyết định vận hành thật.	Phát hiện dữ liệu thật, dữ liệu cá nhân thật hoặc thông tin production.	Principal IT Business Analyst / Technical Curriculum Author; Security Owner; Privacy/Legal Owner.

Quy tắc quyết định review: chỉ ghi PASS khi có bằng chứng ngay trong artifact hoặc liên kết canonical kiểm chứng được. Một FAIL không thuộc ranh giới thẩm quyền cho phép trả lại để sửa. Một STOP hoặc ESCALATE chặn kết luận sẵn sàng baseline cho decision table đến khi vai trò đúng thẩm quyền ghi nhận kết quả trong artifact kiểm soát. Checklist này áp dụng cho Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.

Danh sách kiểm tra chất lượng Senior BA cho bản Nova Foods đã điền

Quality gate là cổng kiểm tra trước baseline: chỉ cho phép chuyển tiếp khi mỗi quyết định có nội dung đủ, kiểm chứng được, truy được nguồn và đúng thẩm quyền. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, trạng thái tài liệu vẫn IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Hạng mục	PASS	FAIL	STOP / escalation	Áp dụng vào ví dụ Nova Foods và cầu nối bằng chứng
Tính đầy đủ	Mỗi điều kiện, hành động, ngoại lệ, kết quả và liên kết truy vết trong bảng quyết định có giá trị cụ thể.	Một hàng quyết định thiếu kết quả, thiếu ngoại lệ, hoặc thiếu liên kết.	STOP nếu thiếu hàng làm thay đổi kết quả nghiệp vụ. Escalate Business Owner.	PASS có điều kiện: kiểm tra mục 3 phải xác nhận mọi hàng đã điền; mục 4 phải có bằng chứng cho từng hàng. Nếu một hàng không truy được, đổi thành FAIL.
Tính nhất quán	Điều kiện cùng dữ liệu phải cho cùng kết quả; thuật ngữ, đơn vị VND, locale vi-VN, thời gian Asia/Ho_Chi_Minh không mâu thuẫn.	Hai hàng cùng tổ hợp điều kiện nhưng hành động khác nhau; một thuật ngữ có hai nghĩa.	STOP nếu mâu thuẫn tạo hai quyết định ERP khác nhau. Escalate Business Owner và Architect.	Đối chiếu mục 3 với /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Hai artifact là nguồn canonical kế hoạch; không suy diễn cấu hình ERP thực.
Khả năng kiểm thử	Mỗi hàng chuyển thành ít nhất một test case hộp đen. Black-box testing là kiểm thử theo đầu vào và đầu ra, không dựa mã nguồn.	Không xác định được đầu vào, kết quả mong đợi, hoặc điều kiện biên.	STOP nếu rule không thể tạo test basis. Escalate QA Owner và Business Owner.	PASS có điều kiện: mỗi hàng mục 3 phải nêu điều kiện đầu vào, hành động kỳ vọng và ngoại lệ; mục 4 phải nối hàng đó với test basis, không tự tạo expected result ngoài rule.
Truy vết	Mỗi quyết định nối được từ nguồn đến rule, bảng quyết định, requirement hoặc test basis.	Liên kết dùng tên tự do, ID biến thể, hoặc không xác định artifact nguồn.	STOP nếu không truy được quyết định có ảnh hưởng tiền, dữ liệu cá nhân, hóa đơn hoặc truy xuất thực phẩm. Escalate Principal IT Business Analyst / Technical Curriculum Author để lập gói vấn đề.	Kiểm tra ID và đường dẫn giữ nguyên registry: /01-curriculum/TRACEABILITY_ID_REGISTRY.md. TMPL-RULE-002 không thay thế rule nguồn; template chỉ ghi và kiểm tra quyết định.
Thẩm quyền nguồn	Nguồn phân loại đúng: luật, chuẩn, hướng dẫn, giả định dự án, hoặc dữ liệu mô phỏng.	Gọi OWASP là luật Việt Nam; gọi source overview là điều khoản chuẩn; gọi giả định là nghĩa vụ bắt buộc.	STOP nếu rule pháp lý, kế toán hoặc an toàn thực phẩm không có xác minh từ owner có thẩm quyền.	Mục 4 phải giữ URL nguồn chính thức và nhãn Verification required cho diễn giải chưa xác minh. Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 không tự tạo rule ERP.
Ownership	Mỗi quyết định có owner nghiệp vụ; mỗi xác minh chuyên môn có owner đúng miền.	Principal IT Business Analyst / Technical Curriculum Author bị ghi là người phê duyệt pháp lý, kế toán, bảo mật hoặc vận hành.	STOP nếu một người tự quyết ngoài thẩm quyền. Escalate Legal Owner, Accounting Owner, Security Owner, Architect, QA Owner hoặc Business Owner theo miền.	PASS có điều kiện: Owner tài liệu duy trì traceability; không có approval, baseline, legal sign-off hoặc production authorization được suy ra từ mục 3 hoặc mục 4.
Bảo mật, riêng tư, pháp lý, kế toán	Rule nêu loại dữ liệu, quyền truy cập, ranh giới xử lý và owner xác minh. Dữ liệu tổng hợp không chứa dữ liệu cá nhân thật.	Hiển thị dữ liệu định danh cá nhân không cần thiết; tự kết luận tuân thủ; tự diễn giải bút toán, thuế hoặc hóa đơn.	STOP nếu quyết định xử lý dữ liệu cá nhân, chứng từ kế toán, hóa đơn hoặc hồ sơ truy xuất thực phẩm chưa được owner miền xác minh.	Ví dụ Nova Foods chỉ dùng dữ liệu tổng hợp. OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 là good practice bảo mật, không phải luật. Mọi yêu cầu phát sinh từ luật phải giữ nhãn Verification required.
Tác động thay đổi	Mỗi thay đổi điều kiện hoặc hành động xác định artifact, test, dữ liệu, giao diện, tích hợp và owner bị ảnh hưởng.	Chỉ sửa bảng nhưng không xem xét test basis, traceability hoặc dữ liệu liên quan.	STOP nếu thay đổi làm đổi quyết định tài chính, quyền dữ liệu, chứng từ hoặc truy xuất mà không có impact assessment. Escalate Change Owner và owner miền bị ảnh hưởng.	Khi sửa mục 3, phải rà mục 4, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và test basis liên kết. Giữ IN_REVIEW; không gọi thay đổi là baseline.

Kết quả ghi nhận: ví dụ Nova Foods trong TMPL-RULE-002 chỉ đạt trạng thái kiểm tra có điều kiện khi bằng chứng ở mục 3 và mục 4 xác nhận từng hàng theo bảng trên. Không có kết luận phê duyệt, baseline, tuân thủ pháp lý, xác nhận kế toán, xác nhận bảo mật hoặc quyền dùng production.

Áp dụng Quality Gate cho ví dụ Nova Foods đã hoàn thiện

Ví dụ Tier 3 trong /03-templates/TMPL-RULE-002-decision-table.md thuộc Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Kết quả dưới đây là ghi nhận review trước baseline, không phải phê duyệt, không xác nhận quy tắc vận hành ERP thực tế.

Mã kiểm tra	Hạng mục áp dụng	Bằng chứng và cầu nối suy luận	Kết quả	Hành động
QG-001	Đủ cấu trúc quyết định	Core Record, Evidence and Traceability, điều kiện, hành động, ngoại lệ và liên kết nguồn đều có trong ví dụ Tier 3. Mỗi kết quả quyết định phải có dòng điều kiện tương ứng; bảng đã thể hiện đủ quan hệ này.	PASS	Giữ cấu trúc hiện có.
QG-002	Nhất quán định danh và trạng thái	Tệp dùng đúng đường dẫn /03-templates/TMPL-RULE-002-decision-table.md; corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07. Không có bằng chứng baseline hoặc approval trong dependency.	PASS	Không gắn nhãn BASELINED, APPROVED hoặc production-ready.
QG-003	Khả năng kiểm thử	Mỗi tổ hợp điều kiện trong decision table phải dẫn tới một hành động quan sát được. Ví dụ Tier 3 có điều kiện đầu vào, kết quả và ngoại lệ đủ để tạo test case hộp đen (black-box testing: kiểm thử theo đầu vào và đầu ra, không cần biết mã nguồn).	PASS	QA tạo tối thiểu một test case cho mỗi dòng quyết định và một test case cho mỗi ngoại lệ.
QG-004	Traceability	Ví dụ liên kết về CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Các artifact này là nguồn kiểm soát kế hoạch, không phải bằng chứng quy tắc Nova Foods đã được xác nhận.	PASS có điều kiện	Giữ nguyên ID canonical; không thay liên kết bằng tên tự do hoặc tài liệu không kiểm soát.
QG-005	Thẩm quyền nguồn	Nguồn CANONICAL_BUSINESS_RULES có trạng thái IN_REVIEW; Owner của catalog không có quyền xác nhận quy tắc vận hành, pháp lý, kế toán hoặc production. Vì vậy nội dung Tier 3 chỉ đủ cho học liệu mô phỏng.	STOP	Không baseline decision table như quy tắc ERP. Escalate Business Owner nếu muốn xác nhận quy tắc nghiệp vụ thực tế.
QG-006	Ownership	Principal IT Business Analyst / Technical Curriculum Author sở hữu tính toàn vẹn template và traceability. Vai trò này không thay Business Owner, Accounting Owner, Legal Owner, Security, Architect hoặc QA.	PASS có ranh giới	Ghi rõ owner artifact không phải người phê chuẩn nội dung quyết định.
QG-007	Bảo mật và riêng tư	Ví dụ chỉ dùng dữ liệu tổng hợp Nova Foods. Không ghi dữ liệu cá nhân, thông tin xác thực, số tài khoản, địa chỉ cá nhân hoặc dữ liệu khách hàng thật.	PASS	Nếu dòng quyết định sau này dùng dữ liệu cá nhân, Security và Legal Owner phải xác định mục đích, quyền truy cập, lưu giữ và biện pháp bảo vệ.
QG-008	Pháp lý, kế toán, thuế	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 chỉ là nguồn ranh giới. Tier 3 không được diễn giải thành nghĩa vụ pháp lý, hạch toán hay hóa đơn thực tế vì chưa có xác minh theo văn bản hiện hành và vai trò có thẩm quyền.	STOP	Escalate Legal Owner và Accounting Owner trước mọi dùng quyết định cho dữ liệu thật, hóa đơn, ghi sổ hoặc xử lý dữ liệu cá nhân.
QG-009	Tác động thay đổi	Thay đổi điều kiện, thứ tự ưu tiên, hành động hoặc ngoại lệ có thể làm lệch test case, rule catalog, data dictionary và traceability registry. Đây là tác động liên artifact, không phải sửa cục bộ.	FAIL	Mở change record trước khi sửa; rà soát các liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY và test basis.
QG-010	Kết luận sẵn sàng	Chất lượng cấu trúc, khả năng kiểm thử và liên kết học liệu đạt mức review. Thẩm quyền nguồn và ranh giới pháp lý/kế toán chưa được xác minh cho vận hành thực tế; thay đổi chưa có change record.	STOP — PRE-BASELINE REWORK REQUIRED	Chỉ chuyển tiếp khi các STOP và FAIL có bằng chứng xử lý từ vai trò đúng thẩm quyền.

Ghi nhận findings: Ví dụ Nova Foods đủ dùng để dạy cách đọc và kiểm tra decision table. Ví dụ chưa đủ căn cứ để baseline, phê duyệt, cấu hình ERP hoặc vận hành production. Hai điểm chặn là xác nhận nguồn nghiệp vụ và xác minh ranh giới pháp lý/kế toán; một điểm phải sửa là kiểm soát tác động thay đổi liên artifact.

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

Kiểm tra liên tệp là đối chiếu cùng một thông tin giữa các nguồn kiểm soát để phát hiện mâu thuẫn trước handoff. Mâu thuẫn gồm: ID khác nhau cho cùng đối tượng; cùng ID nhưng nghĩa khác nhau; filename hoặc status khác canonical; rule dùng dữ liệu chưa có định nghĩa; hoặc consumer hạ nguồn diễn giải decision table thành cấu hình ERP hay nghĩa vụ thực tế. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Check ID	Đối tượng đối chiếu	Bằng chứng nguồn	Tiêu chí kiểm tra	Kết quả tại v0.9.0	Xử lý khi mâu thuẫn
CFC-001	Manifest template và tệp này	/01-curriculum/TEMPLATE_MANIFEST.md; /03-templates/TMPL-RULE-002-decision-table.md	Template phải giữ ID TMPL-RULE-002, filename đúng, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.	PASS có điều kiện: metadata corpus thống nhất; không có bằng chứng baseline hoặc approval.	Dừng dùng tệp như bản chuẩn; sửa manifest hoặc metadata bằng change record, không sửa im lặng.
CFC-002	Chapter manifest và phạm vi học	/01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Decision table phải là học liệu hỗ trợ phân tích rule, không thay thế requirement, test basis, BPMN, cấu hình ERP hoặc quyết định vận hành.	PASS: mục đích template là phân tích quyết định; ranh giới curriculum cấm suy diễn rule vận hành thực.	Escalate Principal IT Business Analyst / Technical Curriculum Author khi chapter consumer gán hiệu lực nghiệp vụ cho bảng.
CFC-003	ID traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mọi ID rule, data, requirement, test và trace link dùng trong Tier 3 phải tồn tại registry, giữ nguyên chuỗi và loại ID.	Verification required: compact dependency xác nhận registry là canonical nhưng không cung cấp từng dòng đăng ký cho ID dùng bởi TMPL-RULE-002.	Không tạo ID mới tại template. Đối chiếu registry đầy đủ trước baseline hoặc test handoff.
CFC-004	Rule canonical	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Mỗi điều kiện, thứ tự ưu tiên, action, exception trong decision table phải khớp rule canonical; bảng không được tự tạo rule mới.	Verification required: catalog có authority boundary rõ, nhưng dữ liệu dòng rule đầy đủ không nằm trong seed.	Đánh dấu bảng là review material; Business Owner xác nhận nghĩa nghiệp vụ, Legal/Accounting xác minh khi rule chạm phạm vi chuyên môn.
CFC-005	Data dictionary canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên trường, kiểu dữ liệu, giá trị mã, trạng thái và đơn vị VND phải khớp từ điển dữ liệu logic; condition không được dựa trên field không định nghĩa.	Verification required: artifact ID và filename canonical đã xác nhận; định nghĩa field chi tiết chưa có trong seed.	Không chuyển condition thành API field, DB column hoặc ERP configuration. Đối chiếu dictionary đầy đủ trước downstream mapping.
CFC-006	Source boundary	/00-research/00_SOURCE_MAP.md; verified primary-source seed	BABOK, ISO/IEC/IEEE 29148, ISTQB là nguồn thuật ngữ/phương pháp. Nguồn luật Việt Nam chỉ là ranh giới; không được biến thành kết luận pháp lý, thuế, kế toán, hóa đơn hay an toàn thực phẩm.	PASS: template giữ phạm vi giáo dục.	Dừng khi rule được trình bày như nghĩa vụ pháp lý hoặc cấu hình tuân thủ; chuyển Legal Owner, Accounting Owner hoặc domain owner.
CFC-007	Consumer hạ nguồn	Rule catalog, data dictionary, traceability registry, test basis và tài liệu API/UI khi được tạo	Consumer phải dùng decision table làm đầu vào truy vết, không coi Tier 3 là authority cao hơn canonical artifacts. Test phải kiểm tra rule đã truy vết; API/UI không tự đổi condition hay priority.	FAIL có kiểm soát: consumer cụ thể và mapping liên kết chưa có trong compact dependency.	Không xác nhận end-to-end traceability. Lập ma trận mapping trước khi dùng cho test, API, UI, migration hoặc cấu hình ERP.

Quy tắc quyết định khi đối chiếu: manifest quyết định file nào thuộc corpus; registry quyết định ID nào hợp lệ; CANONICAL_BUSINESS_RULES quyết định nghĩa rule; CANONICAL_DATA_DICTIONARY quyết định nghĩa dữ liệu. Decision table chỉ trình bày tổ hợp điều kiện và kết quả để review, không nâng thẩm quyền của chính nó. Nếu hai artifact không khớp, không chọn bản “có vẻ mới hơn”; giữ IN_REVIEW, bảo toàn cả hai bằng chứng và chuyển vấn đề cho owner đúng phạm vi.

Kết quả handoff của check này: TMPL-RULE-002 phù hợp dùng để review phương pháp decision table trong corpus Nova Foods mô phỏng. Chưa đủ bằng chứng để gọi nội dung là baseline, approved, compliant, production-ready, ERP configuration hoặc quy tắc vận hành thực tế.

Danh sách vấn đề mở, giả định dự án và mục cần xác minh

Danh sách này chỉ áp dụng cho TMPL-RULE-002, Nova Foods Trading & Manufacturing mô phỏng giáo dục, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. “Vấn đề mở” là điểm chưa thể chốt vì thiếu quyết định có thẩm quyền. “Giả định dự án” là điều tạm dùng để soạn học liệu, không phải quy tắc vận hành. “Cần xác minh” là nội dung phải đối chiếu nguồn hoặc chủ thể có thẩm quyền trước khi dùng ngoài mục đích giáo dục.

Loại	Nội dung cần quản lý	ID/tệp bị ảnh hưởng	Owner xử lý	Tác động nếu chưa xử lý	Hành động tiếp theo
Vấn đề mở	Chưa có bản nội dung đã được ghi nhận trong CANONICAL_BUSINESS_RULES; bảng quyết định không được tự tạo quy tắc Nova Foods mới. Bằng chứng: artifact này là plan IN_REVIEW, chưa baseline và chưa approval.	TMPL-RULE-002; CANONICAL_BUSINESS_RULES; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Business Owner xác nhận nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author giữ truy vết	Điều kiện, kết quả hoặc ngoại lệ trong bảng có thể bị hiểu sai thành quyết định vận hành ERP.	Chỉ liên kết rule ID đã tồn tại trong catalog khi catalog có nội dung được review; nếu chưa có, giữ bảng ở mức mẫu học liệu.
Vấn đề mở	Chưa có thuộc tính dữ liệu logic đã được ghi nhận trong CANONICAL_DATA_DICTIONARY; không được suy diễn trường dữ liệu, kiểu dữ liệu, giá trị mã hay nguồn hệ thống.	TMPL-RULE-002; CANONICAL_DATA_DICTIONARY; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Data Owner hoặc Architect; Principal IT Business Analyst / Technical Curriculum Author điều phối	Bảng quyết định có thể dùng dữ liệu không tồn tại hoặc mâu thuẫn định nghĩa canonical.	Đối chiếu từng input, output và exception của bảng với data dictionary sau khi có bản review; ghi nhận sai khác thành vấn đề mới.
Vấn đề mở	Chưa có đăng ký cụ thể cho ID rule, decision table, requirement, test case hoặc API payload thuộc tình huống Nova Foods. Bằng chứng: TRACEABILITY_ID_REGISTRY là registry plan ở IN_REVIEW.	TMPL-RULE-002; TRACEABILITY_ID_REGISTRY; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author; ID Registry Owner	Traceability, tức khả năng truy ngược từ quyết định đến nguồn và kiểm thử, có thể đứt hoặc trùng ID.	Chỉ dùng ID được registry cấp; không tự đổi, tái sử dụng hoặc dịch ID canonical.
Giả định dự án	Mọi tổ chức, sản phẩm, khách hàng, lô hàng, hóa đơn, số tiền và quyết định Nova Foods trong template là tổng hợp; VND chỉ là đơn vị tiền tệ mô phỏng.	TMPL-RULE-002; CHAPTER_MANIFEST; TEMPLATE_MANIFEST	Principal IT Business Analyst / Technical Curriculum Author	Người học có thể nhầm ví dụ với dữ liệu doanh nghiệp thật hoặc cấu hình production.	Giữ nhãn “mô phỏng giáo dục, dữ liệu tổng hợp” tại mọi case Tier 3 và không nạp dữ liệu thật.
Cần xác minh	Điều kiện bảng liên quan dữ liệu cá nhân phải được Legal Owner hoặc Privacy Owner xác minh theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Nguồn pháp lý tồn tại, nhưng không có diễn giải điều khoản cụ thể trong seed.	TMPL-RULE-002; 00_SOURCE_MAP; /00-research/00_SOURCE_MAP.md	Legal Owner hoặc Privacy Owner	Gắn nghĩa vụ pháp lý sai, hoặc mô tả kiểm soát dữ liệu như đã tuân thủ.	Lập câu hỏi pháp lý, đối chiếu văn bản hiện hành, ghi nguồn và kết luận có thẩm quyền trước khi biến thành rule bắt buộc.
Cần xác minh	Điều kiện về hóa đơn, kế toán, thuế hoặc lưu chứng từ cần Accounting Owner và Legal Owner xác minh. Nghị định 123/2020/NĐ-CP có ghi cảnh báo phải kiểm tra sửa đổi sau này; Luật Kế toán không thay thế diễn giải kế toán có thẩm quyền.	TMPL-RULE-002; 00_SOURCE_MAP; CANONICAL_BUSINESS_RULES	Accounting Owner; Legal Owner	Sai điều kiện quyết định có thể tạo số liệu, chứng từ hoặc hướng dẫn đào tạo sai.	Không ghi ngưỡng, thuế suất, thời hạn, định khoản hoặc điều kiện hóa đơn như fact; xác minh nguồn hiện hành trước.
Cần xác minh	Điều kiện truy xuất nguồn gốc, thu hồi hoặc an toàn thực phẩm cần Food Safety Owner và Legal Owner xác minh. Luật 55/2010/QH12 chỉ là bối cảnh nguồn; seed yêu cầu xác minh domain và pháp lý.	TMPL-RULE-002; 00_SOURCE_MAP; CANONICAL_BUSINESS_RULES	Food Safety Owner; Legal Owner	Quy tắc có thể bị hiểu là quy trình thu hồi hoặc tuân thủ thực tế.	Chỉ dùng ví dụ tổng hợp; chuyển mọi rule bắt buộc sang trạng thái cần xác minh cho đến khi có kết luận có thẩm quyền.
Cần xác minh	Quyết định có ảnh hưởng API, phân quyền, hiển thị dữ liệu hoặc kiểm thử cần Architect, Security Owner và QA Reviewer xác minh. OpenAPI 3.1.1, OWASP ASVS 5.0.0, OWASP API Security Top 10 2023 và ISTQB CTFL v4.0.1 là nguồn tham chiếu, không tự tạo kiến trúc hay compliance.	TMPL-RULE-002; 00_SOURCE_MAP; TRACEABILITY_ID_REGISTRY	Architect; Security Owner; QA Reviewer	Rule có thể mâu thuẫn thiết kế kỹ thuật, tạo lộ dữ liệu hoặc không có test basis.	Gắn rule với acceptance criteria và test case đã đăng ký; escalation ngay nếu một điều kiện đồng thời cần quyết định nghiệp vụ, bảo mật và kiến trúc.

Không có mục nào trong bảng này được đóng bằng việc Owner của artifact tự quyết. Chỉ vai trò nêu tại từng dòng mới xác nhận nội dung thuộc thẩm quyền; Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận, duy trì liên kết và bảo toàn trạng thái IN_REVIEW.

Quy tắc bàn giao cuối và lan truyền thay đổi

/03-templates/TMPL-RULE-002-decision-table.md được bàn giao ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, locale vi-VN, tiền tệ mô phỏng VND. Nova Foods Trading & Manufacturing là case học liệu mô phỏng; mọi dữ liệu là dữ liệu tổng hợp. IN_REVIEW nghĩa là nội dung còn chờ xem xét có kiểm soát, không nghĩa là APPROVED, BASELINED, sẵn sàng production, đúng pháp lý, đúng kế toán, hoặc đã được người dùng chấp thuận.

Bàn giao (handoff) là chuyển gói artifact có định danh, trạng thái, phạm vi và liên kết truy vết rõ cho vai trò nhận. Gói bàn giao phải giữ nguyên filename /03-templates/TMPL-RULE-002-decision-table.md, Template ID TMPL-RULE-002, status, version, ngày và mọi ID đã dùng trong bảng quyết định. Không đổi tên tệp, dịch ID, tái sử dụng ID cho nội dung khác, hoặc chép bảng sang artifact khác rồi gọi bản chép là nguồn canonical.

Thành phần bàn giao	Nội dung bắt buộc	Lý do kiểm soát
Artifact chính	/03-templates/TMPL-RULE-002-decision-table.md; TMPL-RULE-002; IN_REVIEW; v0.9.0	Người nhận xác định đúng bản đang xem xét, không nhầm với bản xuất hay bản sao.
Nguồn định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; TRACEABILITY_ID_REGISTRY	Registry là nguồn kiểm soát ID; template không tự cấp, đổi hoặc giải thích lại ID.
Nguồn quy tắc	/01-curriculum/CANONICAL_BUSINESS_RULES.md; CANONICAL_BUSINESS_RULES	Decision table biểu diễn điều kiện và kết quả của rule; không tự trở thành nguồn tạo rule nghiệp vụ.
Nguồn dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; CANONICAL_DATA_DICTIONARY	Tên trường, miền giá trị, kiểu dữ liệu và ý nghĩa dữ liệu phải giữ nhất quán với từ điển canonical.
Nguồn phạm vi template	/01-curriculum/TEMPLATE_MANIFEST.md; TEMPLATE_MANIFEST	Manifest kiểm soát template dự kiến và metadata; không cấp approval nội dung.
Nguồn cấu trúc học liệu	/01-curriculum/CHAPTER_MANIFEST.md; CHAPTER_MANIFEST	Chapter/template liên quan chỉ dùng template theo dependency đã định, không suy diễn quy tắc vận hành Nova Foods.

Thay đổi (change propagation) là cập nhật có truy vết tại mọi artifact bị ảnh hưởng sau khi nguồn canonical đổi. Thay đổi phải bắt đầu tại nguồn có thẩm quyền: đổi ID bắt đầu tại TRACEABILITY_ID_REGISTRY; đổi ý nghĩa rule bắt đầu tại CANONICAL_BUSINESS_RULES; đổi định nghĩa dữ liệu bắt đầu tại CANONICAL_DATA_DICTIONARY; đổi phạm vi hoặc filename template bắt đầu tại TEMPLATE_MANIFEST. Không sửa riêng TMPL-RULE-002 để tạo khác biệt với nguồn canonical. Cầu nối suy luận là: bảng quyết định dùng ID rule và dữ liệu canonical; khi nguồn đó đổi, điều kiện, action, exception và traceability của bảng có thể mất đúng nghĩa cũ.

Loại thay đổi nguồn	Lan truyền bắt buộc đến TMPL-RULE-002	Điều kiện giữ trạng thái
ID rule, ID dữ liệu, ID traceability đổi	Cập nhật mọi liên kết ID đúng chuỗi registry; kiểm tra không còn ID cũ trong bảng và traceability.	Giữ IN_REVIEW; không gọi bản cập nhật là baseline.
Điều kiện, action, thứ tự ưu tiên, exception của rule đổi	So sánh từng hàng quyết định với rule canonical; sửa hàng bị ảnh hưởng; ghi lý do và phạm vi tác động.	Chỉ Business Owner xác nhận ý nghĩa nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author chỉ điều phối tài liệu.
Kiểu dữ liệu, miền giá trị, định nghĩa trường đổi	Kiểm tra lại giá trị điều kiện trong decision table; không dùng giá trị ngoài miền dữ liệu canonical.	Cần Data Owner hoặc Architect xử lý khi thay đổi chạm mô hình dữ liệu hay tích hợp.
Diễn giải pháp lý, thuế, kế toán, riêng tư, an toàn thực phẩm đổi	Gắn nhãn Verification required hoặc project assumption nếu chưa có xác minh hiện hành; không biến thành nghĩa vụ bắt buộc.	Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner quyết định nội dung chuyên môn thuộc phạm vi mình.
Cấu trúc template hoặc dependency đổi	Đồng bộ link từ manifest và chapter/template liên quan; giữ nguyên ID canonical nếu registry chưa đổi.	Template Manifest Owner điều phối metadata; không tự phê duyệt nội dung nghiệp vụ.

Mỗi yêu cầu đổi phải có: nguồn khởi phát, ID bị ảnh hưởng, mô tả trước/sau, lý do, artifact nhận lan truyền, người chịu trách nhiệm xem xét, ngày theo Asia/Ho_Chi_Minh, và trạng thái xử lý. Nếu thiếu một thành phần, thay đổi chưa đủ gói bàn giao và không được diễn giải là thay đổi có hiệu lực. Bản cũ phải còn truy vết; không sửa im lặng làm mất quan hệ giữa v0.9.0 và nội dung trước đổi.

Principal IT Business Analyst / Technical Curriculum Author giữ vai trò điều phối traceability, version và tính nhất quán artifact. Vai trò này không có quyền tự xác nhận rule Nova Foods, baseline, approval, compliance, diễn giải pháp luật, quyết định kế toán/thuế, kiến trúc, bảo mật, vận hành hoặc production. Khi thay đổi đồng thời chạm nghiệp vụ và pháp lý, hoặc nghiệp vụ và dữ liệu/kiến trúc, phải escalation tới từng owner có thẩm quyền; không chọn một owner thay cho owner còn lại. Chỉ khi artifact kiểm soát ghi minh bạch tham chiếu baseline hoặc approval hợp lệ mới được dùng các từ “đã baseline” hoặc “đã phê duyệt”; trước thời điểm đó, TMPL-RULE-002 vẫn là học liệu mô phỏng IN_REVIEW.