Tmpl Rule 003 Rule Governance Register

Trường kiểm soát	Giá trị
Artifact ID	TMPL-RULE-003
Tên tệp được kiểm soát	/03-templates/TMPL-RULE-003-rule-governance-register.md
Tiêu đề artifact	Tmpl Rule 003 Rule Governance Register
Status	IN_REVIEW
Version	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Phân loại artifact	Controlled template: mẫu được kiểm soát cho đăng ký quản trị quy tắc nghiệp vụ
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Phạm vi dữ liệu	Chỉ dữ liệu tổng hợp. Tên tổ chức, vai trò, quy trình, mã, ngày, số lượng và giá trị VND trong artifact là dữ liệu giả lập phục vụ học tập.
Baseline reference	Chưa có baseline reference tại v0.9.0. IN_REVIEW không đồng nghĩa BASELINED.
Approval reference	Chưa có approval reference. Metadata, Owner, nội dung mẫu hoặc trạng thái review không tạo phê duyệt ngầm định.

Owner duy trì định danh, đường dẫn, trạng thái, phiên bản, ngày cập nhật và lịch sử thay đổi. Owner không có thẩm quyền tự xác nhận quy tắc Nova Foods là đúng cho vận hành thực, không xác lập baseline, không ghi nhận approval, không diễn giải pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc compliance.

Ranh giới dữ liệu mô phỏng áp dụng vì corpus Nova Foods là học liệu. Không dùng artifact này làm bằng chứng cấu hình ERP, chính sách doanh nghiệp, quyết định vận hành, hồ sơ kiểm toán, kết luận tuân thủ hoặc chỉ dẫn production. Mọi nội dung có thể liên quan pháp luật Việt Nam, kế toán, thuế, dữ liệu cá nhân, hóa đơn hoặc an toàn thực phẩm phải giữ nhãn Verification required cho đến khi vai trò có thẩm quyền kiểm tra nguồn chính thức hiện hành.

Version	Ngày	Thay đổi	Trạng thái kiểm soát
v0.9.0	2026-08-07	Khởi tạo /03-templates/TMPL-RULE-003-rule-governance-register.md; thiết lập metadata, Owner, ranh giới dữ liệu tổng hợp và trạng thái IN_REVIEW.	Chưa baseline; chưa có approval.

1. Tier 1 ? Metadata, Purpose, and Governance

Mục đích, phạm vi sử dụng và thẩm quyền

Template này quản trị một business rule (quy tắc nghiệp vụ): phát biểu kiểm soát được về điều kiện, hành vi, ngoại lệ hoặc ràng buộc mà ERP Nova Foods mô phỏng phải tuân theo. Mục đích là ghi một rule thành record có thể đọc, kiểm tra, truy vết và chuyển giao; không biến mô tả mơ hồ thành giả định kỹ thuật. Lý do: một rule tác động dữ liệu, quy trình, màn hình hoặc kiểm thử cần cùng một nguồn tham chiếu, tránh BA, Dev và QA hiểu khác nhau. Nova Foods Trading & Manufacturing là case học tập mô phỏng; mọi dữ liệu là tổng hợp.

Nội dung	Quy định sử dụng
Dùng khi	Có rule ảnh hưởng quyết định nghiệp vụ, trạng thái chứng từ, tính hợp lệ dữ liệu, phân quyền, tính giá, tồn kho, truy xuất lô, hóa đơn, giao diện, tích hợp hoặc tiêu chí kiểm thử.
Dùng khi	Cần liên kết rule với requirement, quy trình, data field, acceptance criteria, test case, rủi ro hoặc nguồn chứng cứ.
Không dùng khi	Nội dung chỉ là yêu cầu chức năng riêng lẻ, thiết kế API, cấu hình ERP, hướng dẫn thao tác, quyết định kiến trúc hoặc test case. Liên kết tới artifact phù hợp thay vì tạo rule trùng lặp.
Không dùng khi	Chưa phân biệt được fact, giả định dự án, quy định pháp lý, chính sách nội bộ và rule cần hệ thống thực thi. Làm rõ phân loại trước.
Không dùng khi	Nội dung đòi hỏi kết luận pháp lý, thuế, kế toán, an toàn thực phẩm, bảo mật hoặc vận hành thực. Gắn Verification required và chuyển đúng chủ sở hữu thẩm quyền.

Owner quản trị template là Principal IT Business Analyst / Technical Curriculum Author. Owner giữ cấu trúc record, định danh, traceability và lịch sử thay đổi; không được tự xác nhận rule Nova Foods là đúng, đã baseline, đã phê duyệt, compliant hoặc sẵn sàng production. Người tiêu thụ gồm BA để phân tích tác động; Business Owner để xác nhận ý định nghiệp vụ; Architect và Dev để đánh giá cách thực thi; QA để lập test basis; Data Owner để kiểm tra dữ liệu; Legal, Accounting, Compliance, Security hoặc Food-Safety Owner khi rule chạm miền chuyên môn tương ứng.

Trước khi lập record, người soạn phải có: vấn đề nghiệp vụ xác định được; nguồn hoặc giả định được phân loại; phạm vi quy trình; đối tượng dữ liệu bị ảnh hưởng; vai trò quyết định; và ít nhất một liên kết canonical. Liên kết quản trị phải giữ nguyên ID và đường dẫn nguồn: 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, và CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Các artifact hạ nguồn gồm requirement, process model, data dictionary entry, acceptance criteria, test case và traceability record; chúng tham chiếu rule, không tự viết lại rule thành nguồn chân lý mới.

Tình huống	Thẩm quyền và xử lý
Rule chỉ cần chuẩn hóa câu chữ, ID hoặc liên kết	Owner xử lý quản trị, giữ lịch sử thay đổi.
Rule thay đổi quyết định bán hàng, mua hàng, kho, sản xuất hoặc tài chính mô phỏng	Escalate Business Owner; Owner không tự chọn chính sách.
Rule dẫn chiếu luật, hóa đơn, kế toán, dữ liệu cá nhân hoặc an toàn thực phẩm	Escalate Legal Owner và domain owner phù hợp. Chỉ dùng nguồn chính thức đã xác minh; phần chưa xác minh ghi Verification required.
Rule ảnh hưởng phân quyền, dữ liệu nhạy cảm, API hoặc kiểm soát bảo mật	Escalate Security Owner và Architect.
Rule không có chứng cứ, mâu thuẫn nguồn canonical hoặc trùng rule khác	Dừng hoàn thiện record; mở vấn đề truy vết theo TRACEABILITY_ID_REGISTRY.

Authority nghĩa là quyền ra quyết định có trách nhiệm, không phải quyền sửa tài liệu. Escalation nghĩa là chuyển vấn đề cùng chứng cứ, tác động và câu hỏi quyết định tới vai trò có authority. Cầu nối suy luận: CANONICAL_BUSINESS_RULES xác định catalog rule là nguồn canonical đang IN_REVIEW; vì chưa có baseline hoặc approval reference, template chỉ được ghi nhận, phân tích và truy vết nội dung mô phỏng, không được tuyên bố hiệu lực vận hành.

Ánh xạ Manifest, Định danh Canonical, Chapter, Nguồn và Kiểm soát Thay đổi

Template này có định danh manifest TMPL-RULE-003, tên tệp kiểm soát /03-templates/TMPL-RULE-003-rule-governance-register.md. TMPL-RULE-003 là khóa nhận diện duy nhất trong corpus, không phải mã quy tắc nghiệp vụ. Khóa này phân biệt template quản trị rule với từng rule Nova Foods được ghi trong Tier 3. Mọi liên kết, lịch sử thay đổi, checklist QA và tham chiếu chéo phải giữ nguyên ID và đường dẫn này; không đổi thành tên dịch, tên rút gọn, bản sao xuất PDF hoặc tên file cục bộ.

Hạng mục ánh xạ	Giá trị canonical	Cách dùng bắt buộc	Ranh giới
Template identity	TMPL-RULE-003	Ghi tại metadata, traceability link, change request và QA evidence liên quan template.	Không dùng làm ID cho business rule.
Controlled file	/03-templates/TMPL-RULE-003-rule-governance-register.md	Nguồn kiểm soát của cấu trúc bốn tier.	Bản sao hoặc bản xuất không thay thế tệp này.
Manifest nguồn	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Kiểm tra template đã được đăng ký, phạm vi dự kiến và dependency quản trị.	Manifest là planning artifact; không tạo baseline hoặc approval.
Registry định danh	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra cú pháp, tính duy nhất và loại ID của rule, requirement, test, data hoặc source link.	Không tự tạo ID ngoài quy ước registry.
Catalog rule	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Đối chiếu rule canonical, trạng thái và liên kết nghiệp vụ khi catalog có mục tương ứng.	Không suy diễn rule chưa được catalog ghi nhận.
Data dictionary	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kiểm tra tên dữ liệu, định nghĩa logic và phân loại dữ liệu khi rule dùng dữ liệu.	Không biến tên trường mô phỏng thành thiết kế triển khai.
Chapter authority	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	Xác định chapter dạy business rule, traceability, requirement và testing liên quan.	Không tự thêm chapter, đổi thứ tự học hoặc đổi filename chapter.

Ánh xạ chapter tồn tại để learner biết rule không đứng một mình. Rule cần bối cảnh quy trình, yêu cầu, dữ liệu, kiểm thử và nguồn. Bằng chứng là CHAPTER_MANIFEST là manifest có thẩm quyền cho 26 handbook chapter, còn TRACEABILITY_ID_REGISTRY quản lý liên kết định danh giữa artifact. Vì vậy, mỗi record Tier 3 phải nêu ít nhất chapter nguồn kiến thức và chapter nhận đầu ra nếu manifest đã đăng ký liên kết đó. Nếu manifest chưa chỉ rõ chapter hoặc dependency, ghi Verification required trong trường traceability; không bịa chapter, không tạo liên kết ngầm.

Loại thông tin trong Rule Governance Register	Nguồn canonical phải kiểm tra	Tiêu chí quyết định
Cấu trúc template, tier và filename	TEMPLATE_MANIFEST	Dùng khi ID, phạm vi và tệp khớp manifest.
Rule ID và traceability ID	TRACEABILITY_ID_REGISTRY	Dùng khi ID đúng loại, duy nhất và có liên kết nguồn-đích rõ.
Nội dung rule Nova Foods	CANONICAL_BUSINESS_RULES	Chỉ gọi là canonical khi catalog ghi nhận đúng ID và nội dung tương ứng.
Thuật ngữ, thuộc tính, thực thể dữ liệu	CANONICAL_DATA_DICTIONARY	Dùng tên canonical; khác biệt phải được giải quyết trước khi hoàn tất record.
Kỹ thuật BA và thuật ngữ quản trị yêu cầu	BABOK Guide Version 3	Dùng cho thuật ngữ và reasoning BA; không bịa số trang hoặc điều khoản.
Chất lượng requirement	ISO/IEC/IEEE 29148:2018	Dùng abstract và trạng thái thư mục chính thức; điều khoản chính xác cần kiểm tra licensed text.
Test basis, test condition, kỹ thuật black-box	ISTQB CTFL Syllabus v4.0.1	Dùng khi rule tạo testable condition hoặc acceptance evidence.
Nghĩa vụ pháp lý, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm	URL chính thức trong 00_SOURCE_MAP	Chỉ mô tả nguồn và nhu cầu xác minh; legal, accounting hoặc domain owner phải xác minh nội dung áp dụng.

Nguồn được phân loại theo ranh giới sử dụng. BABOK, ISO/IEC/IEEE 29148 và ISTQB hỗ trợ phương pháp BA, chất lượng requirement và testing; chúng không tự chứng minh Nova Foods tuân thủ pháp luật hay vận hành ERP thực tế. Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm là nguồn pháp lý chính thức trong source seed. Tuy vậy, template không được chuyển nội dung chưa xác minh thành nghĩa vụ bắt buộc. Mọi rule suy ra từ các nguồn này phải gắn nhãn Verification required, chỉ rõ legal, accounting hoặc domain owner cần xác minh, và giữ URL nguồn trong traceability.

Thay đổi có kiểm soát nghĩa là thay đổi ID, tên file, cấu trúc tier, liên kết chapter, phân loại nguồn hoặc liên kết rule không được sửa im lặng. Lý do: các thành phần này là điểm nối giữa manifest, registry, catalog và evidence; sửa một điểm có thể làm hỏng traceability nhiều artifact. Thay đổi phải ghi nguyên nhân, phạm vi ảnh hưởng, artifact bị ảnh hưởng, ID trước và sau nếu có, nguồn cần kiểm tra lại, người có thẩm quyền cần escalation và trạng thái xác minh. IN_REVIEW tại v0.9.0 không phải BASELINED, không phải APPROVED, không chứng minh compliance, không xác nhận Nova Foods đã áp dụng rule nào.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Tên tổ chức, rule ID, quy trình, dữ liệu, tiền tệ VND và ví dụ trong template đều là dữ liệu tổng hợp. Không dùng record của template làm quyết định vận hành, diễn giải pháp lý, hạch toán, cấu hình ERP hoặc chứng cứ production. Khi nguồn canonical mâu thuẫn, ID chưa đăng ký, hoặc thay đổi có thể ảnh hưởng pháp lý, kế toán, bảo mật, kiến trúc hay vận hành, dừng cập nhật nội dung kết luận và escalation đến vai trò có thẩm quyền; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì gói traceability và lịch sử thay đổi.

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

Sao chép nguyên khối mẫu dưới đây khi lập một Rule Governance Register record. Thay mọi chuỗi trong dấu ngoặc nhọn bằng giá trị cụ thể. Tier 2 chỉ là cấu trúc tái sử dụng; không được coi placeholder là dữ liệu Nova Foods, quyết định nghiệp vụ, phê duyệt, baseline hoặc bằng chứng.

Trường	Giá trị cần điền	Hướng dẫn điền và kiểm tra
Rule Record ID	<canonical-rule-record-id>	Dùng ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Không tự tạo biến thể, đổi tiền tố hoặc tái sử dụng ID đã có.
Rule ID	<canonical-business-rule-id>	Dùng đúng ID canonical từ /01-curriculum/CANONICAL_BUSINESS_RULES.md. Một record quản trị chỉ quản lý một Rule ID.
Tên rule	<tên-rule-ngắn-gọn-theo-dạng-chủ-thể-hành-động-điều-kiện>	Viết rõ đối tượng, hành vi và điều kiện. Không dùng tên mơ hồ như Kiểm tra đơn hàng.
Trạng thái record	<IN_REVIEW|DRAFT|PROPOSED|VERIFICATION_REQUIRED|RETIRED>	Chọn một giá trị. Không dùng APPROVED hoặc BASELINED nếu artifact kiểm soát chưa ghi tham chiếu phê duyệt hoặc baseline.
Phiên bản record	<vX.Y.Z>	Theo Semantic Versioning: thay đổi lớn tăng X, thay đổi tương thích tăng Y, sửa nhỏ tăng Z. Không ghi ngày thay phiên bản.
Ngày cập nhật	<YYYY-MM-DD>	Dùng lịch ISO 8601, diễn giải theo Asia/Ho_Chi_Minh.
Owner quản trị	<vai-trò-owner>	Ghi vai trò, không ghi cá nhân nếu chưa có dữ liệu được phép. Owner duy trì record; không tự xác nhận legal, accounting, security hoặc approval.
Miền nghiệp vụ	<Sales|Procurement|Inventory|Production|Finance|Quality|Master Data|Integration|Security|khác>	Chọn miền chịu tác động chính. Nếu nhiều miền, chọn miền chính và nêu miền phụ tại trường phạm vi ảnh hưởng.
Loại rule	<Validation|Derivation|Authorization|Calculation|Workflow|Retention|Compliance|Data Quality|Integration>	Validation kiểm tra hợp lệ; Derivation suy ra dữ liệu; Authorization kiểm soát quyền; Calculation tính giá trị; Workflow điều khiển luồng.
Mức độ	<Critical|High|Medium|Low>	Critical khi vi phạm có thể gây mất dữ liệu, rủi ro an toàn, tài chính hoặc tuân thủ. Phải nêu lý do tại trường rủi ro.
Phạm vi áp dụng	<quy-trình-module-đối-tượng-dữ-liệu-kênh-áp-dụng>	Nêu rõ áp dụng cho ai, dữ liệu nào, thời điểm nào và không áp dụng cho đâu. Không suy diễn phạm vi từ tên rule.
Mô tả nghiệp vụ	<mô-tả-rule-đầy-đủ>	Viết theo dạng: khi <điều kiện kích hoạt>, hệ thống hoặc vai trò <hành vi bắt buộc>, để <mục tiêu nghiệp vụ>.
Điều kiện kích hoạt	<sự-kiện-hoặc-trạng-thái-kích-hoạt>	Phải kiểm tra được qua dữ liệu, sự kiện hoặc trạng thái. Không dùng cụm chủ quan như khi cần thiết.
Đầu vào	<danh-sách-trường-dữ-liệu-sự-kiện-hoặc-chứng-từ-đầu-vào>	Liệt kê tên logic của từng đầu vào và nguồn tạo dữ liệu. Không ghi secret, token, mật khẩu hoặc khóa API.
Logic quyết định	<nếu-điều-kiện-thì-kết-quả;-nếu-không-thì-kết-quả-khác>	Mỗi nhánh phải có điều kiện và kết quả rõ. Không để khoảng trống giữa điều kiện hợp lệ và không hợp lệ.
Kết quả thành công	<trạng-thái-thông-báo-hoặc-thao-tác-khi-thỏa-rule>	Nêu kết quả quan sát được, ví dụ trạng thái được phép chuyển hoặc giá trị được lưu.
Kết quả vi phạm	<thông-báo-từ-chối-chặn-luồng-hoặc-tạo-công-việc>	Nêu hành vi hệ thống và người nhận xử lý. Thông báo không được tiết lộ dữ liệu nhạy cảm.
Ngoại lệ được phép	<không-có-hoặc-điều-kiện-ngoại-lệ-vai-trò-thẩm-quyền-hết-hạn>	Ghi Không có nếu không tồn tại. Nếu có, phải nêu điều kiện, người có thẩm quyền, thời hạn và dấu vết cần lưu.
Rủi ro nếu rule sai hoặc bị bỏ qua	<rủi-ro-nghiệp-vụ-dữ-liệu-bảo-mật-tài-chính-hoặc-tuân-thủ>	Nối rủi ro với logic rule: <điều kiện không được kiểm soát> gây <hậu quả>. Không khẳng định vi phạm pháp luật khi chưa xác minh.
Phân loại nguồn	<Primary official|Primary normative|Project assumption|Secondary guidance|Verification required>	Chọn một phân loại cho cơ sở chính. Verification required bắt buộc khi nội dung pháp lý, kế toán, thuế, an toàn thực phẩm hoặc privacy chưa được owner có thẩm quyền xác minh.
Cơ sở lý do	<nguồn-hoặc-giả-định> — <sự-kiện-trong-nguồn> — <lý-do-suy-ra-rule>	Phải tạo cầu nối evidence/reasoning: nguồn nói gì, phạm vi nào, vì sao hỗ trợ rule. Không bịa điều khoản, trang, trích dẫn hoặc phát biểu của nguồn.
Quyết định cần xác nhận	<không-có-hoặc-quyết-định-cụ-thể-cần-owner-xác-nhận>	Dùng khi logic chưa đủ cơ sở. Nêu vai trò cần quyết định, không gán quyết định cho Nova Foods mô phỏng.
Vai trò chịu trách nhiệm nghiệp vụ	<Business Owner role>	Ghi vai trò chịu trách nhiệm về ý nghĩa nghiệp vụ. Không ghi Owner quản trị artifact thay cho Business Owner.
Vai trò xác minh chuyên môn	<Legal Owner|Accounting Owner|Security|Architect|QA Reviewer|Domain Owner|không-áp-dụng>	Chọn mọi vai trò bắt buộc theo rủi ro. không-áp-dụng chỉ hợp lệ khi đã nêu lý do tại cơ sở lý do.
Phân loại dữ liệu	<Public|Internal|Confidential|Personal Data|Sensitive Personal Data|không-áp-dụng>	Chọn mức cao nhất trong dữ liệu đầu vào hoặc đầu ra. Nội dung liên quan dữ liệu cá nhân phải giữ Verification required đến khi Legal Owner xác minh.
Tham chiếu secret an toàn	<không-áp-dụng-hoặc-secret-reference-pattern>	Chỉ ghi tham chiếu như <vault://<environment>/<secret-name>> hoặc <ENV_VAR_NAME>. Cấm ghi mật khẩu, token, private key, connection string đầy đủ, dữ liệu định danh cá nhân.
Giả định dự án	<không-có-hoặc-giả-định-được-đánh-nhãn>	Mỗi giả định phải nêu giới hạn: <giả định> chỉ dùng cho case study mô phỏng, cần xác minh trước production.
Điều kiện không áp dụng	<không-có-hoặc-phạm-vi-loại-trừ>	Nêu rõ loại giao dịch, trạng thái hoặc kênh bị loại trừ. Không dùng loại trừ để né xử lý lỗi.
Tiêu chí hoàn tất record	<điều-kiện-đầy-đủ-của-record>	Tối thiểu: ID canonical hợp lệ, logic đủ nhánh, ngoại lệ rõ, nguồn phân loại, lý do có cầu nối và vai trò xác minh được chỉ định.

Mẫu nội dung rule

Rule Record ID: <canonical-rule-record-id>
Rule ID: <canonical-business-rule-id>
Tên rule: <tên-rule-ngắn-gọn>
Trạng thái / phiên bản / ngày: <status> / <vX.Y.Z> / <YYYY-MM-DD Asia/Ho_Chi_Minh>
Mô tả: Khi <điều-kiện-kích-hoạt>, <hệ-thống-hoặc-vai-trò> phải <hành-vi>, để <mục-tiêu>.
Logic quyết định: Nếu <điều-kiện-đúng> thì <kết-quả-thành-công>; nếu <điều-kiện-sai> thì <kết-quả-vi-phạm>.
Ngoại lệ: <không-có-hoặc-ngoại-lệ-đầy-đủ-điều-kiện-thẩm-quyền-thời-hạn>.
Cơ sở lý do: <nguồn-hoặc-giả-định> — <evidence> — <reasoning bridge>.
Giới hạn: <phạm-vi-không-áp-dụng, verification required, hoặc-escalation-condition>.

Biểu mẫu hồ sơ quy tắc và theo dõi quản trị

Sao chép toàn bộ khối này cho mỗi quy tắc. <...> là chỗ điền mô tả; không giữ placeholder khi chuyển sang Tier 3. Nova Foods là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. IN_REVIEW không phải phê duyệt, baseline, xác nhận tuân thủ, hay quyền dùng production.

Trường	Giá trị cần điền
Template ID	TMPL-RULE-003
Tên tệp kiểm soát	/03-templates/TMPL-RULE-003-rule-governance-register.md
Rule ID canonical	<RULE-ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md>
Tên quy tắc	<câu ngắn, nêu đối tượng và điều kiện>
Trạng thái hồ sơ	<DRAFT \| IN_REVIEW \| BASELINED \| RETIRED>
Phiên bản	<vX.Y.Z>
Ngày cập nhật	<YYYY-MM-DD>
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; VND
Owner quản trị	<vai trò chịu trách nhiệm duy trì hồ sơ, không tự cấp approval>
Business Owner	<vai trò quyết định nghiệp vụ; ghi “Chưa chỉ định” nếu chưa có>
Phân loại quy tắc	<Business Rule \| Validation Rule \| Calculation Rule \| Authorization Rule \| Compliance-related Rule>
Case áp dụng	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Phạm vi áp dụng	<quy trình, đối tượng, tổ chức hoặc giao dịch chịu tác động>
Ngoài phạm vi	<ranh giới rõ; nội dung không bị quy tắc chi phối>
Mức độ ảnh hưởng	<Low \| Medium \| High \| Critical>
Trạng thái xác minh	<Project assumption \| Verification required \| Source verified within stated boundary>

Thành phần quy tắc	Nội dung cần điền
Phát biểu quy tắc	<Mệnh đề kiểm tra được: Khi [điều kiện], hệ thống hoặc người dùng phải [kết quả].>
Lý do nghiệp vụ	<vấn đề, rủi ro hoặc mục tiêu mà quy tắc xử lý>
Cầu nối bằng chứng và suy luận	<Nguồn/quan sát nói gì>; vì vậy <suy luận giới hạn>; do đó cần <quy tắc>. Không biến suy luận thành trích dẫn nguồn.
Đối tượng dữ liệu	<entity, trường dữ liệu, chứng từ hoặc sự kiện>
Sự kiện kích hoạt	<tạo, sửa, duyệt, xuất, đồng bộ, hủy hoặc thời điểm khác>
Điều kiện đầu vào	<điều kiện đúng trước khi kiểm tra>
Logic quyết định	<IF điều kiện THEN kết quả ELSE kết quả>
Kết quả khi đạt	<cho phép, tính toán, ghi nhận, chuyển trạng thái>
Kết quả khi không đạt	<chặn, cảnh báo, chuyển ngoại lệ, ghi log>
Thông báo người dùng	<mã thông báo và câu tiếng Việt không lộ bí mật>
Tác động dữ liệu	<tạo/sửa/không sửa trường nào; lịch sử nào phải giữ>
Tác động tích hợp	<API, batch, báo cáo hoặc “Không có”>
Tiêu chí chấp nhận	<Given/When/Then hoặc điều kiện kiểm thử quan sát được>

Điểm quyết định	Điều kiện	Kết quả bắt buộc	Vai trò quyết định	Bằng chứng quyết định
<DEC-01>	<điều kiện>	<kết quả>	<vai trò>	<liên kết Evidence ID hoặc “Chưa có — Verification required”>
<DEC-02>	<điều kiện>	<kết quả>	<vai trò>	<liên kết Evidence ID hoặc “Chưa có — Verification required”>
<DEC-03>	<điều kiện>	<kết quả>	<vai trò>	<liên kết Evidence ID hoặc “Chưa có — Verification required”>

Không xóa dòng quyết định. Nếu chỉ có một nhánh nghiệp vụ, điền <Không áp dụng; lý do: quy tắc không có nhánh quyết định thứ hai> vào các dòng còn lại. Quyết định liên quan pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật phải giữ Verification required đến khi owner có thẩm quyền xác minh.

Exception ID	Điều kiện ngoại lệ	Có được phép bỏ qua quy tắc?	Người có thẩm quyền	Xử lý bắt buộc	Nhật ký/bằng chứng cần giữ	Trạng thái
<EXC-01>	<điều kiện khác quy tắc chuẩn>	<Có \| Không>	<vai trò>	<chặn, phê duyệt ngoại lệ, sửa dữ liệu hoặc escalation>	<mã giao dịch, thời điểm, người xử lý, lý do>	<Open \| Resolved \| Rejected>
<EXC-02>	<điều kiện khác quy tắc chuẩn>	<Có \| Không>	<vai trò>	<xử lý>	<bằng chứng>	<Open \| Resolved \| Rejected>
<EXC-03>	<điều kiện khác quy tắc chuẩn>	<Có \| Không>	<vai trò>	<xử lý>	<bằng chứng>	<Open \| Resolved \| Rejected>

Không dùng ngoại lệ để né kiểm soát bắt buộc. Nếu không có ngoại lệ đã biết, mỗi dòng vẫn điền <Chưa xác định; cần phân tích trong review>; không ghi là quy tắc không có rủi ro.

Evidence ID	Loại bằng chứng	Nguồn hoặc vị trí	Phân loại nguồn	Nội dung chứng minh	Ngày truy cập/ghi nhận	Trạng thái xác minh
<EVD-01>	<văn bản pháp lý \| chuẩn \| quyết định nghiệp vụ \| mẫu dữ liệu \| kết quả kiểm thử>	<URL chính thức hoặc đường dẫn artifact canonical>	<Primary \| Secondary \| Project assumption>	<fact được chứng minh, không chép suy luận>	<YYYY-MM-DD>	<Verified \| Verification required>
<EVD-02>	<loại>	<nguồn/vị trí>	<phân loại>	<fact>	<YYYY-MM-DD>	<trạng thái>
<EVD-03>	<loại>	<nguồn/vị trí>	<phân loại>	<fact>	<YYYY-MM-DD>	<trạng thái>

URL nguồn chính thức được giữ nguyên. Không ghi số trang, điều khoản hoặc câu trích dẫn nếu chưa kiểm tra văn bản có giấy phép. Nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân và an toàn thực phẩm không được suy diễn thành nghĩa vụ Nova Foods nếu chưa có xác minh owner phù hợp.

Traceability ID	Loại liên kết	Artifact canonical	Mục tiêu liên kết	Quan hệ	Trạng thái
<TRC-01>	<Source \| Requirement \| Process \| Data \| Test \| Risk>	</đường-dẫn-canonical>	<ID mục tiêu canonical>	<derives from \| constrains \| verified by \| impacts>	<Valid \| Broken \| Verification required>
<TRC-02>	<loại>	</đường-dẫn-canonical>	<ID>	<quan hệ>	<trạng thái>
<TRC-03>	<loại>	</đường-dẫn-canonical>	<ID>	<quan hệ>	<trạng thái>

Liên kết phải dùng ID và filename canonical, gồm /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, hoặc artifact đã đăng ký khác. Không tạo ID mới trong hồ sơ nếu registry chưa ghi nhận.

Thành phần bí mật hoặc dữ liệu nhạy cảm	Cách tham chiếu an toàn	Giá trị cấm ghi trong hồ sơ	Kiểm soát cần xác minh
<API key, mật khẩu, token, khóa riêng, dữ liệu cá nhân hoặc “Không có”>	<secret-manager://<vault>/<reference>; hoặc <ID tham chiếu hệ thống quản lý bí mật>>	<giá trị bí mật thật, token, mật khẩu, số định danh cá nhân>	<Security Owner xác minh quyền truy cập, luân chuyển và nhật ký>

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	Tác động traceability
<vX.Y.Z>	<YYYY-MM-DD>	<vai trò hoặc tên mô phỏng>	<Created \| Updated \| Clarified \| Retired>	<thay đổi cụ thể>	<Evidence ID hoặc Project assumption>	<TRC-ID bị thêm, sửa hoặc kiểm tra>
<vX.Y.Z>	<YYYY-MM-DD>	<vai trò hoặc tên mô phỏng>	<loại>	<thay đổi>	<bằng chứng>	<tác động>

Loại review/sign-off	Vai trò cần tham gia	Kết quả	Ngày	Bằng chứng hoặc tham chiếu	Điều kiện đóng
Business review	<Business Owner>	<Pending \| Accepted with comments \| Rework required>	<YYYY-MM-DD hoặc Chưa ghi nhận>	<review record ID hoặc Chưa ghi nhận>	<mọi comment được xử lý hoặc escalation>
BA quality review	<Senior BA hoặc BA Reviewer>	<Pending \| Passed \| Rework required>	<YYYY-MM-DD hoặc Chưa ghi nhận>	<review record ID hoặc Chưa ghi nhận>	<logic, exception, evidence, traceability đầy đủ>
Technical review	<Architect hoặc Technical Owner>	<Not required \| Pending \| Passed \| Rework required>	<YYYY-MM-DD hoặc Chưa ghi nhận>	<review record ID hoặc Chưa ghi nhận>	<tác động kỹ thuật được xác minh>
Legal/compliance review	<Legal/Compliance Owner>	<Not required \| Verification required \| Pending \| Passed>	<YYYY-MM-DD hoặc Chưa ghi nhận>	<review record ID hoặc Chưa ghi nhận>	<chỉ áp dụng khi quy tắc tạo diễn giải pháp lý/compliance>
Accounting review	<Accounting Owner>	<Not required \| Verification required \| Pending \| Passed>	<YYYY-MM-DD hoặc Chưa ghi nhận>	<review record ID hoặc Chưa ghi nhận>	<chỉ áp dụng khi quy tắc ảnh hưởng ghi nhận kế toán, thuế hoặc chứng từ>
Sign-off/Baseline	<vai trò có thẩm quyền>	<Chưa ghi nhận \| Rejected \| Approved>	<YYYY-MM-DD hoặc Chưa ghi nhận>	<approval/baseline reference hoặc Chưa ghi nhận>	<không suy diễn từ trạng thái IN_REVIEW>

Hướng dẫn điền trường, giá trị hợp lệ, kiểm tra và tham chiếu bí mật

Dùng Tier 2 để tạo bản nháp có cấu trúc. Mọi chuỗi trong dấu <...> là hướng dẫn phải thay bằng dữ liệu cụ thể trước khi dùng ở Tier 3. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. IN_REVIEW nghĩa là đang xem xét, không phải đã phê duyệt, baseline hay sẵn sàng production.

Nhóm trường	Trường mẫu cần điền	Hướng dẫn và giá trị hợp lệ	Quy tắc kiểm tra
Nhận diện	<RULE-ID theo registry>	Dùng đúng ID đã đăng ký trong TRACEABILITY_ID_REGISTRY; không tự tạo biến thể.	Bắt buộc; khớp ký tự tuyệt đối với registry.
Nhận diện	<Tên quy tắc ngắn, duy nhất>	Viết dạng chủ thể + nghĩa vụ/kết quả, ví dụ cấu trúc: <Đối tượng> phải <hành động> khi <điều kiện>.	Bắt buộc; không chứa từ mơ hồ như “phù hợp”, “kịp thời”, “hợp lý” nếu không có tiêu chí đo.
Phân loại	<Loại quy tắc>	Chọn một: BUSINESS_RULE, VALIDATION_RULE, CALCULATION_RULE, AUTHORIZATION_RULE, INTEGRATION_RULE, SECURITY_RULE, COMPLIANCE_RULE.	Bắt buộc; chọn một giá trị. Nếu gồm nhiều loại, tách thành nhiều rule liên kết.
Phân loại	<Nguồn quy tắc>	Chọn một: PROJECT_ASSUMPTION, STAKEHOLDER_INPUT, POLICY_REFERENCE, LEGAL_REFERENCE, ACCOUNTING_REFERENCE, SECURITY_REFERENCE, SYSTEM_CONSTRAINT.	Bắt buộc; LEGAL_REFERENCE, ACCOUNTING_REFERENCE, SECURITY_REFERENCE cần owner chuyên môn xác minh.
Nội dung	<Phát biểu quy tắc kiểm thử được>	Nêu điều kiện, hành động, kết quả và giới hạn. “Kiểm thử được” nghĩa là tester xác định được đạt hay không đạt bằng dữ liệu đầu vào và kết quả quan sát.	Bắt buộc; phải có ít nhất một điều kiện hoặc sự kiện kích hoạt và một kết quả xác định.
Phạm vi	<Quy trình/module/đối tượng áp dụng>	Nêu ranh giới rõ, như <Sales Order>, <Lot Traceability>, <Vendor Invoice>. Không ghi toàn ERP nếu chỉ áp dụng một luồng.	Bắt buộc; khớp thuật ngữ canonical của corpus khi đã có.
Dữ liệu	<Trường dữ liệu bị ảnh hưởng>	Ghi <Entity.Field> và kiểu logic nếu biết, ví dụ cấu trúc <SalesOrder.requestedDeliveryDate : date>.	Bắt buộc khi rule đọc, tính, ghi hoặc kiểm tra dữ liệu.
Quyết định	<Kết quả khi đạt> và <Kết quả khi không đạt>	Chọn hành vi: ALLOW, BLOCK, WARNING, ROUTE_FOR_APPROVAL, LOG_AND_CONTINUE. Nêu thông báo nghiệp vụ và trạng thái sau xử lý.	Bắt buộc; WARNING không được dùng nếu sai dữ liệu gây mất tiền, lộ dữ liệu hoặc mất truy xuất.
Ngoại lệ	<Có ngoại lệ: YES/NO>	Chọn YES hoặc NO. Nếu YES, điền toàn bộ trường ngoại lệ bên dưới. Nếu NO, ghi <Không áp dụng; không có ngoại lệ được xác định tại trạng thái IN_REVIEW>.	Bắt buộc; không để trống.
Bằng chứng	<Evidence-ID hoặc URL nguồn>	Ghi ID/đường dẫn artifact nguồn, URL chính thức, biên bản quyết định, mẫu dữ liệu tổng hợp hoặc test case. URL pháp lý chỉ là nguồn tham chiếu, không tự biến thành diễn giải pháp lý.	Bắt buộc; phải truy cập được hoặc có ID controlled artifact.
Truy vết	<ID requirement/use case/data element/test case liên quan>	Liên kết bằng ID canonical, giữ nguyên ký tự và tiền tố.	Bắt buộc; không dùng mô tả tự do thay ID khi ID đã tồn tại.
Quản trị	<Rule status>	Chọn một: DRAFT, IN_REVIEW, APPROVED, RETIRED. Tại corpus hiện hành, dùng IN_REVIEW trừ khi artifact controlled ghi rõ trạng thái khác.	Bắt buộc; không ghi APPROVED khi không có approval reference.
Bảo mật	<Phân loại dữ liệu>	Chọn một: PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED, NOT_APPLICABLE.	Bắt buộc; RESTRICTED kích hoạt tham chiếu bí mật an toàn.

Điều kiện và quyết định. Điền bảng sau khi rule có nhánh xử lý. Mỗi hàng là một điều kiện độc lập hoặc tổ hợp điều kiện được viết rõ. Không gộp các trường hợp cho kết quả khác nhau vào một hàng.

<Điều kiện ID>	<Dữ liệu đầu vào/nguồn>	<Toán tử và ngưỡng hoặc tập giá trị>	<Kết quả quyết định>	<Lý do và bằng chứng>
<COND-01>	<Entity.Field>	<=, =, !=, IN, NOT IN, IS NULL, khoảng ngày, công thức>	<ALLOW/BLOCK/WARNING/ROUTE_FOR_APPROVAL/LOG_AND_CONTINUE>	<Liên kết Evidence-ID; giải thích dữ liệu nào chứng minh điều kiện>
<COND-02>	<Entity.Field>	<Điều kiện đầy đủ>	<Kết quả đầy đủ>	<Liên kết Evidence-ID; giải thích>
<DEFAULT-01>	<Trường hợp không khớp COND-01 hoặc COND-02>	<Mặc định>	<Kết quả mặc định>	<Lý do không để hệ thống tự suy đoán>

Phần ngoại lệ, chỉ điền khi <Có ngoại lệ: YES>. Ngoại lệ là đường xử lý cho trường hợp cố ý không áp dụng kết quả chuẩn. Ngoại lệ không được xóa rule chuẩn, không được cấp quyền vô hạn, và phải có thời hạn.

Trường ngoại lệ	Giá trị mẫu cần điền	Quy tắc kiểm tra
<EXCEPTION-ID>	<ID duy nhất theo quy ước registry>	Bắt buộc; một ngoại lệ một ID.
<Điều kiện kích hoạt>	<Tình huống cụ thể, dữ liệu chứng minh>	Bắt buộc; không dùng “trường hợp đặc biệt”.
<Người/role có thẩm quyền>	<Business Owner/Accounting Owner/Legal Owner/Security Owner/role đã đăng ký>	Bắt buộc; BA không tự cấp ngoại lệ.
<Hiệu lực từ>	<YYYY-MM-DDThh:mm:ss+07:00>	Bắt buộc; dùng Asia/Ho_Chi_Minh.
<Hết hạn lúc>	<YYYY-MM-DDThh:mm:ss+07:00>	Bắt buộc; phải sau hiệu lực từ.
<Kiểm soát bù>	<Phê duyệt, log, đối soát, giới hạn quyền hoặc kiểm tra bổ sung>	Bắt buộc; phải giảm rủi ro do ngoại lệ tạo ra.
<Bằng chứng phê duyệt>	<Approval reference hoặc trạng thái chưa có>	Không được tuyên bố phê duyệt nếu chưa có tham chiếu ghi nhận.

Tham chiếu bí mật an toàn. Không điền mật khẩu, API key, access token, private key, chuỗi kết nối đầy đủ, số định danh cá nhân, dữ liệu thanh toán hoặc dữ liệu RESTRICTED vào rule register. Dùng mẫu <secret://<vault-name>/<path>#<version-or-alias>>, ví dụ cấu trúc <secret://<approved-vault>/<integration>/<service-account>#<approved-version>>. Ghi owner, mục đích, quyền tối thiểu và ngày rà soát; không ghi giá trị bí mật.

Trường	Giá trị mẫu cần điền	Kiểm tra
<Secret reference>	<secret://<approved-vault>/<path>#<version-or-alias>>	Chỉ chứa tham chiếu, không chứa secret.
<Secret purpose>	<Xác thực hệ thống nào cho luồng nào>	Bắt buộc nếu có secret reference.
<Access role>	<Role tối thiểu cần đọc hoặc sử dụng secret>	Không dùng tài khoản dùng chung nếu chưa có Security Owner xác minh.
<Security evidence>	<Security requirement ID hoặc Evidence-ID>	Bắt buộc; tham chiếu OWASP chỉ là good practice, không phải xác nhận tuân thủ.
<Rotation/review condition>	<Sự kiện hoặc chu kỳ do Security Owner xác minh>	Ghi Verification required nếu chưa có chính sách được xác minh.

Kiểm tra trước khi chuyển Tier 3. Mỗi placeholder phải được thay bằng dữ liệu Nova Foods tổng hợp cụ thể. Mỗi suy luận phải nối được từ <Evidence-ID> tới điều kiện và kết quả rule. Rule có nguồn LEGAL_REFERENCE, ACCOUNTING_REFERENCE hoặc SECURITY_REFERENCE phải giữ nhãn Verification required cho đến khi đúng owner chuyên môn xác minh. Không dùng template này để khẳng định nghĩa vụ pháp lý, kế toán, bảo mật hay quyết định production.

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

Bối cảnh: Nova Foods Trading & Manufacturing là case study mô phỏng; mọi người, giao dịch, mã và giá trị dưới đây là dữ liệu tổng hợp. Rule register ghi quy tắc nghiệp vụ có kiểm soát: điều kiện, kết quả, ngoại lệ, trạng thái và thẩm quyền quyết định. Nó không phải cấu hình ERP production hay kết luận pháp lý.

Trường core	Giá trị đã điền
Rule ID	RULE-NF-INV-001
Tên quy tắc	Chỉ cho phép nhập kho lô nguyên liệu có đủ kết quả kiểm tra chất lượng đạt
Domain	Inventory Management / Quality Management
Quy trình	Nhận nguyên liệu mua ngoài, kiểm tra chất lượng, quyết định nhập kho
Phạm vi tổ chức	Nova Foods Trading & Manufacturing — mô phỏng
Status	IN_REVIEW
Version	v0.9.0
Ngày hiệu lực mô phỏng	2026-08-10
Timezone	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; VND
Loại quy tắc	Validation rule — quy tắc xác thực dữ liệu trước khi hệ thống đổi trạng thái giao dịch
Phân loại nguồn	PROJECT_ASSUMPTION; FOOD_SAFETY_REFERENCE
Nguồn tham chiếu	Luật An toàn thực phẩm, Luật 55/2010/QH12; dùng cho bối cảnh truy xuất nguồn gốc và kiểm soát chất lượng. Diễn giải chi tiết pháp lý: Verification required.
Owner nghiệp vụ giả lập	Nguyễn Minh An — Quality Manager, Nova Foods mô phỏng
Owner hệ thống giả lập	Trần Gia Huy — ERP Product Owner, Nova Foods mô phỏng
Quyền quyết định	Quality Manager giả lập quyết định kết quả kiểm tra lô; ERP Product Owner giả lập quyết định áp dụng rule vào backlog. Không có phê duyệt được ghi nhận.

Sự kiện mô phỏng: Ngày 2026-08-07 09:15:00, nhân viên nhận hàng Phạm Thu Hà tạo phiếu nhận GRN-NF-20260807-014 cho 500 kg bột mì nguyên liệu RM-FLOUR-01, lô nhà cung cấp SUPLOT-HT-260807-03. Nhà cung cấp mô phỏng là SUP-NF-014 Hưng Thịnh Ingredients. Đơn giá là 18.500 VND/kg; giá trị trước thuế của dòng nhận là 9.250.000 VND. Hệ thống tạo lô nội bộ LOT-NF-RM-20260807-014 với trạng thái QUALITY_HOLD, nghĩa là bị giữ chờ kiểm tra và chưa được dùng cho sản xuất.

Thực trạng mô phỏng: ERP hiện cho phép nhân viên kho đổi trạng thái lô từ QUALITY_HOLD sang AVAILABLE khi phiếu nhận đã có số lượng dương. Điều kiện này chỉ chứng minh hàng đã được ghi nhận vật lý; không chứng minh chất lượng đạt. Bằng chứng là giao dịch GRN-NF-20260807-014 có số lượng 500 kg nhưng kết quả kiểm tra QC-NF-20260807-031 chưa hoàn tất tại thời điểm nhận.

Nhu cầu gốc: Bộ phận Sản xuất cần chỉ nhìn thấy nguyên liệu được phép cấp phát. Bộ phận Quality cần quyền chặn lô không đạt trước khi lô ảnh hưởng Production Order. Suy luận: nếu AVAILABLE chỉ phụ thuộc số lượng nhận, lô chưa kiểm tra có thể được cấp phát; vì vậy trạng thái khả dụng phải phụ thuộc kết quả kiểm tra chất lượng.

Dữ liệu rule	Giá trị đã điền
Đối tượng chính	InventoryLot
Khóa nghiệp vụ	LOT-NF-RM-20260807-014
Giao dịch kích hoạt	Hoàn tất hoặc cập nhật QC-NF-20260807-031
Điều kiện đầu vào	received_quantity_kg > 0, quality_inspection_id có giá trị, quality_result thuộc tập giá trị cho phép
Tập giá trị kết quả kiểm tra	PASS, FAIL, PENDING, NOT_REQUIRED
Điều kiện đạt	quality_result = PASS
Kết quả khi đạt	Đổi inventory_lot_status từ QUALITY_HOLD sang AVAILABLE; cho phép cấp phát vào lệnh sản xuất
Kết quả khi không đạt	Giữ hoặc đổi trạng thái sang QUARANTINED; chặn cấp phát, xuất kho sản xuất và bán
Điều kiện lỗi	Không có quality_inspection_id, hoặc quality_result = PENDING, hoặc quality_result = FAIL nhưng người dùng yêu cầu AVAILABLE
Thông báo lỗi	Không thể chuyển lô LOT-NF-RM-20260807-014 sang AVAILABLE. Kết quả kiểm tra chất lượng phải là PASS.
Hành động hệ thống	Từ chối cập nhật trạng thái; lưu mã lỗi ERR-QA-LOT-001; không tạo giao dịch cấp phát
Hành động người dùng	Quality Inspector hoàn tất kiểm tra; Quality Manager giả lập xác nhận quyết định khi kết quả là FAIL
Hậu quả nếu rule sai	Lô chưa đạt có thể vào sản xuất; truy xuất lô và xử lý thu hồi mô phỏng bị sai lệch; tồn kho khả dụng không phản ánh trạng thái kiểm soát thực tế.

Payload giao dịch mô phỏng	Giá trị
goods_receipt_id	GRN-NF-20260807-014
inventory_lot_id	LOT-NF-RM-20260807-014
item_id	RM-FLOUR-01
supplier_id	SUP-NF-014
supplier_lot_no	SUPLOT-HT-260807-03
received_quantity_kg	500
unit_price_vnd	18500
receipt_value_vnd	9250000
quality_inspection_id	QC-NF-20260807-031
quality_result	PENDING
inventory_lot_status	QUALITY_HOLD
requested_status	AVAILABLE
transaction_time	2026-08-07T09:15:00+07:00
created_by	USR-NF-WH-012 — Phạm Thu Hà, Warehouse Receiver mô phỏng

Lựa chọn	Mô tả	Đánh giá theo tiêu chí kiểm soát chất lượng, khả năng truy vết, rủi ro vận hành	Kết quả
OPT-001	Cho phép AVAILABLE ngay khi nhận hàng	Nhanh nhưng không chặn lô PENDING; truy vết không ngăn được sử dụng sai	Không chọn
OPT-002	Chỉ Quality Manager đổi trạng thái thủ công cho mọi lô	Kiểm soát cao nhưng tạo thao tác lặp lại cho lô PASS; dễ chậm cấp phát	Không chọn
OPT-003	ERP tự đổi sang AVAILABLE khi kết quả là PASS; chặn mọi kết quả khác	Đủ kiểm soát, có trạng thái rõ, giảm thao tác thủ công, giữ được truy vết giao dịch	Khuyến nghị mô phỏng

Quyết định mô phỏng: Chọn OPT-003. Cơ sở: kết quả PASS là dữ liệu quyết định trực tiếp cho phép dùng lô; PENDING và FAIL không đáp ứng điều kiện an toàn vận hành đã giả định. Quyết định này thuộc Quality Manager và ERP Product Owner giả lập; trạng thái hiện tại là IN_REVIEW, không phải phê duyệt hay baseline.

Chuyển trạng thái	Điều kiện	Người hoặc hệ thống thực hiện	Kết quả
RECEIVED sang QUALITY_HOLD	Phiếu nhận có số lượng lớn hơn 0 kg	ERP	Lô chờ kiểm tra
QUALITY_HOLD sang AVAILABLE	quality_result = PASS	ERP sau khi nhận kết quả kiểm tra	Lô được phép cấp phát
QUALITY_HOLD sang QUARANTINED	quality_result = FAIL	ERP; Quality Manager xử lý nghiệp vụ tiếp theo	Lô bị chặn sử dụng
QUALITY_HOLD giữ nguyên	quality_result = PENDING hoặc thiếu kết quả	ERP	Lô tiếp tục bị chặn
QUARANTINED sang AVAILABLE	Không được rule này cho phép	Không áp dụng	Cần rule thay đổi trạng thái riêng, có thẩm quyền Quality Manager giả lập

Ngoại lệ mô phỏng: Mặt hàng RM-SALT-01 có thể mang quality_result = NOT_REQUIRED nếu item master đã được Quality Manager giả lập gắn cờ quality_inspection_required = false. Ngoại lệ không áp dụng cho RM-FLOUR-01, vì item master mô phỏng của mặt hàng này có quality_inspection_required = true. Lý do: rule phải dựa trên thuộc tính kiểm soát của từng mặt hàng, không dựa vào lựa chọn tự do của nhân viên nhận hàng.

Bản ghi quy tắc hoàn chỉnh — Nova Foods mô phỏng

Nova Foods Trading & Manufacturing là case học liệu mô phỏng; toàn bộ người dùng, giao dịch, mã lô và giá trị dưới đây là dữ liệu tổng hợp, dùng VND và múi giờ Asia/Ho_Chi_Minh.

Trường lõi	Giá trị hoàn chỉnh
Rule ID	BR-WH-LOT-001
Tên quy tắc	Chặn nhập kho thành phẩm khi thiếu mã lô hoặc ngày hết hạn
Loại quy tắc	Business Rule — quy tắc nghiệp vụ, xác định điều kiện hệ thống phải áp dụng nhất quán
Miền nghiệp vụ	Kho thành phẩm và truy xuất lô
Quy trình	Nhận thành phẩm từ lệnh sản xuất vào kho thành phẩm
Trạng thái quản trị	IN_REVIEW
Phiên bản	v0.9.0
Ngày ghi nhận	2026-08-07
Chủ sở hữu nội dung đề xuất	Nguyễn Minh Khoa, Warehouse Process Lead — nhân sự mô phỏng
Thẩm quyền quyết định	Business Owner kho và Quality Owner mô phỏng; Principal IT Business Analyst chỉ ghi nhận, không phê duyệt
Phân loại nguồn	Project assumption — giả định dự án mô phỏng
Mức độ rủi ro	Cao; sai dữ liệu lô làm đứt truy xuất và có thể xuất nhầm hàng không đủ thông tin
Đối tượng áp dụng	Phiếu nhập kho thành phẩm có receipt_type = PRODUCTION_RECEIPT
Đối tượng không áp dụng	Nhập kho bao bì, nguyên liệu, vật tư phụ, điều chỉnh tồn kho không tạo lô mới
Ngày hiệu lực mô phỏng	2026-09-01 00:00:00+07:00
Hệ quả nếu áp dụng sai	Chặn nhầm gây chậm nhập kho; không chặn gây tồn kho thành phẩm không thể truy xuất theo lô

Sự kiện nghiệp vụ: Nhân viên kho Lê Quốc Bình tạo phiếu nhập GRN-FG-2026-000184 từ lệnh sản xuất MO-2026-00871 cho thành phẩm FG-NF-CHILI-250, tên “Tương ớt Nova 250 g”. Số lượng nhận là 4.800 chai, đơn giá thành mô phỏng 18.500 VND/chai, tổng giá trị 88.800.000 VND. Kho nhận là WH-FG-HCM-01. Vì đây là thành phẩm đóng chai cần quản lý truy xuất, bản ghi phải có mã lô và ngày hết hạn.

Thực tế quan sát	Bằng chứng và cầu nối suy luận	Nhu cầu nền
Màn hình nhận hàng hiện cho lưu phiếu khi lot_code rỗng.	Phiếu mô phỏng GRN-FG-2026-000183 đã được lưu ngày 2026-08-06 với lot_code = null; kho không thể lọc tồn theo lô.	Bắt buộc mã lô trước khi tăng tồn khả dụng.
Màn hình nhận hàng hiện cho ngày hết hạn bằng hoặc trước ngày nhận.	Dòng mô phỏng có expiry_date = 2026-08-05, trong khi receipt_date = 2026-08-06; dữ liệu này không hỗ trợ quyết định xuất hàng an toàn.	Ngày hết hạn phải sau ngày nhận kho.
Nhân viên kho cần biết lỗi nào phải sửa.	Chỉ báo lỗi chung “Không lưu được” không chỉ ra trường sai.	Trả lỗi theo từng trường, có mã lỗi ổn định để test và hỗ trợ vận hành.

Quy tắc quyết định: Hệ thống chỉ chuyển phiếu từ DRAFT sang POSTED khi mọi dòng thành phẩm thuộc phạm vi có lot_code không rỗng, expiry_date tồn tại và expiry_date > receipt_date. Nếu bất kỳ dòng nào vi phạm, hệ thống giữ phiếu ở DRAFT, không tạo tăng tồn kho, không tạo bút toán giá vốn mô phỏng và trả lỗi cho đúng dòng.

Điều kiện kiểm tra	Kết quả	Mã lỗi	Trạng thái phiếu
lot_code có giá trị, expiry_date có giá trị, ngày hết hạn sau ngày nhận	Cho phép ghi sổ phiếu	Không có lỗi	POSTED
lot_code rỗng hoặc chỉ có khoảng trắng	Từ chối ghi sổ	ERR-LOT-001	DRAFT
expiry_date rỗng	Từ chối ghi sổ	ERR-LOT-002	DRAFT
expiry_date bằng hoặc trước receipt_date	Từ chối ghi sổ	ERR-LOT-003	DRAFT
Người dùng sửa đủ dữ liệu rồi gửi lại	Kiểm tra lại toàn bộ dòng	Theo kết quả kiểm tra mới	POSTED hoặc DRAFT

Phương án đã xét: Phương án A cho phép lưu rồi yêu cầu kho bổ sung lô sau. Phương án này giảm chặn thao tác trước mắt nhưng tạo tồn khả dụng thiếu dữ liệu truy xuất. Phương án B chặn ghi sổ đến khi đủ dữ liệu. Phương án này bảo vệ tính đầy đủ dữ liệu trước khi tồn kho có thể dùng. Tiêu chí chọn gồm khả năng truy xuất, tránh xuất nhầm hàng, thông báo lỗi rõ và không tạo điều chỉnh hồi tố. Khuyến nghị là phương án B. Quyết định vẫn chờ Business Owner kho và Quality Owner mô phỏng xem xét.

Payload kiểm tra mô phỏng:

{
  "receipt_id": "GRN-FG-2026-000184",
  "receipt_type": "PRODUCTION_RECEIPT",
  "receipt_date": "2026-08-07",
  "warehouse_id": "WH-FG-HCM-01",
  "currency_code": "VND",
  "lines": [
    {
      "line_no": 1,
      "item_id": "FG-NF-CHILI-250",
      "item_name": "Tương ớt Nova 250 g",
      "quantity": 4800,
      "uom": "BOTTLE",
      "unit_cost_vnd": 18500,
      "lot_code": "NFCH250-260807-A",
      "expiry_date": "2027-08-06"
    }
  ]
}

Payload trên đạt điều kiện: mã lô có giá trị; ngày hết hạn 2027-08-06 sau ngày nhận 2026-08-07; phiếu được phép chuyển DRAFT sang POSTED. Đây là kết quả mô phỏng, không xác nhận cấu hình ERP thực tế, tuân thủ pháp lý, kế toán hay an toàn thực phẩm.

Hồ sơ quyết định quy tắc — NOVA-RULE-003

Trường	Giá trị hoàn chỉnh
Rule ID	NOVA-RULE-003
Tên quy tắc	Chặn xác nhận đơn bán khi tổng công nợ quá hạn của khách hàng vượt hạn mức tín dụng
Artifact	/03-templates/TMPL-RULE-003-rule-governance-register.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày ghi nhận	2026-08-07
Múi giờ, locale, tiền tệ	Asia/Ho_Chi_Minh; vi-VN; VND
Phạm vi	Nova Foods Trading & Manufacturing, mô phỏng giáo dục; toàn bộ dữ liệu, vai trò, giao dịch là tổng hợp
Quy trình bị ảnh hưởng	Bán hàng B2B: tạo đơn bán, kiểm tra tín dụng, xác nhận đơn, giữ đơn, giải phóng đơn
Phân loại nguồn	PROJECT_ASSUMPTION cho ngưỡng tín dụng và luồng ERP mô phỏng; VERIFICATION_REQUIRED cho mọi diễn giải kế toán, pháp lý, thu hồi công nợ hoặc chính sách tín dụng production
Nguồn truy vết	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; TRACEABILITY_ID_REGISTRY; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md

Sự kiện quan sát được. Ngày 2026-08-07, nhân viên kinh doanh Lê Minh Khoa tạo đơn SO-NF-20260807-0148 cho khách hàng mô phỏng CUS-NF-00127 — Công ty TNHH Phân phối An Phúc. Đơn có giá trị trước thuế 86.400.000 VND, VAT mô phỏng 8.640.000 VND, tổng thanh toán 95.040.000 VND. Khách hàng có hạn mức tín dụng được ghi trong hồ sơ mô phỏng là 300.000.000 VND, công nợ chưa đến hạn 132.000.000 VND, công nợ quá hạn 214.000.000 VND. Ba hóa đơn quá hạn gồm AR-NF-20260601-0031 giá trị còn lại 72.000.000 VND, quá hạn 37 ngày; AR-NF-20260612-0088 giá trị còn lại 68.000.000 VND, quá hạn 26 ngày; AR-NF-20260620-0114 giá trị còn lại 74.000.000 VND, quá hạn 18 ngày.

Hành vi hiện tại. ERP mô phỏng chỉ so sánh tổng phơi nhiễm tín dụng với hạn mức: 132.000.000 + 214.000.000 + 95.040.000 = 441.040.000 VND, vượt hạn mức 141.040.000 VND. Tuy vậy, nhân viên vẫn có thể chọn trạng thái CONFIRMED bằng quyền bán hàng vì chưa có kiểm soát riêng cho công nợ quá hạn. Hệ thống không tạo bản ghi giữ đơn, không nêu lý do chặn, không gửi yêu cầu xem xét cho Credit Controller. Suy luận: dữ liệu công nợ quá hạn đã tồn tại nhưng không tham gia quyết định xác nhận; bằng chứng là đơn SO-NF-20260807-0148 có thể chuyển sang CONFIRMED dù 214.000.000 VND đã quá hạn.

Nhu cầu nền tảng. Tín dụng bán hàng là khoản Nova Foods cho khách nhận hàng trước, thanh toán sau. Công nợ quá hạn cho thấy khách chưa thanh toán đến ngày cam kết. Vì đơn mới tăng số tiền cần thu, ERP phải ngăn việc xác nhận tự động khi tổng công nợ quá hạn vượt ngưỡng kiểm soát. Mục tiêu không phải kết luận khách hàng mất khả năng thanh toán; mục tiêu là buộc người có thẩm quyền xem xét rủi ro trước khi cam kết giao hàng.

Phương án	Cách xử lý đơn SO-NF-20260807-0148	Lợi ích	Điểm yếu
OPT-01 Không chặn	Cho phép CONFIRMED	Không làm chậm bán hàng	Bỏ qua tín hiệu quá hạn 214.000.000 VND; không có kiểm soát trước giao hàng
OPT-02 Chỉ cảnh báo	Hiện cảnh báo, vẫn cho xác nhận	Có thông tin cho Sales	Cảnh báo không ngăn quyền xác nhận; rủi ro vẫn phụ thuộc hành vi từng người
OPT-03 Giữ đơn theo ngưỡng	Chuyển ON_CREDIT_HOLD; chỉ Credit Controller giải phóng sau quyết định có ghi nhận	Tạo kiểm soát nhất quán, có dấu vết, vẫn cho phép ngoại lệ có thẩm quyền	Có thể chậm xác nhận nếu dữ liệu công nợ đồng bộ chậm

Tiêu chí quyết định	Trọng số	OPT-01	OPT-02	OPT-03	Lý do chấm
Ngăn xác nhận khi vượt rủi ro quá hạn	40%	1	2	5	Chỉ OPT-03 ngăn chuyển trạng thái trước quyết định tín dụng
Truy vết người và lý do ngoại lệ	25%	1	2	5	OPT-03 cần bản ghi giữ và giải phóng
Ít ảnh hưởng đơn hợp lệ	20%	5	4	4	OPT-03 chỉ kích hoạt trên ngưỡng xác định
Khả năng kiểm thử ERP	15%	2	3	5	Trạng thái, ngưỡng, quyền và kết quả có thể kiểm thử rõ
Điểm có trọng số	100%	2,20/5	2,60/5	4,80/5	OPT-03 cao nhất

Khuyến nghị ghi nhận. Chọn OPT-03 làm đề xuất cho NOVA-RULE-003: ERP đặt đơn ở trạng thái ON_CREDIT_HOLD khi overdue_receivable_vnd > 200.000.000 VND tại thời điểm người dùng yêu cầu xác nhận đơn. Với SO-NF-20260807-0148, 214.000.000 VND > 200.000.000 VND; hệ thống không được chuyển sang CONFIRMED, phải tạo lý do giữ OVERDUE_RECEIVABLE_THRESHOLD_EXCEEDED, rồi định tuyến tới vai trò Credit Controller.

Thành phần quyết định	Giá trị
Người đề xuất	Nguyễn Thảo Vy, Senior BA mô phỏng
Thẩm quyền quyết định nghiệp vụ	Business Owner — Sales & Finance
Thẩm quyền xác nhận khả năng cấu hình	ERP Solution Architect
Thẩm quyền xác nhận tác động ghi nhận công nợ	Accounting Owner
Thẩm quyền kiểm tra quy tắc và trạng thái	QA Lead
Giới hạn Senior BA	Ghi nhận sự kiện, phân tích phương án, duy trì truy vết; không tự xác nhận ngưỡng tín dụng, không tự cấp ngoại lệ, không xác nhận kế toán hoặc production
Trạng thái quyết định	IN_REVIEW; chưa có baseline reference; chưa có approval reference

Hậu quả nếu quy tắc sai. Nếu ngưỡng quá cao hoặc không chặn, Nova Foods mô phỏng có thể xác nhận đơn cho khách đã có công nợ quá hạn lớn, tăng phơi nhiễm thu hồi tiền và tạo giao hàng không qua kiểm soát tín dụng. Nếu ngưỡng quá thấp hoặc chặn nhầm, đơn hợp lệ bị giữ, làm chậm doanh thu, giao hàng và quan hệ khách hàng. Nếu Credit Controller có thể giải phóng nhưng không lưu lý do, tổ chức không truy được ai đã chấp nhận rủi ro và vì sao. Vì vậy, 200.000.000 VND là PROJECT_ASSUMPTION, không phải chính sách tín dụng thực tế; Business Owner và Finance phải xác minh trước mọi sử dụng ngoài học liệu mô phỏng.

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

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. Sự kiện đang xét: người dùng yêu cầu xác nhận đơn bán SO-NF-20260807-0148; tại thời điểm kiểm tra, overdue_receivable_vnd = 214.000.000 VND, lớn hơn ngưỡng giả định 200.000.000 VND. Vì điều kiện so sánh đúng, hệ thống phải giữ đơn ở ON_CREDIT_HOLD, không chuyển CONFIRMED, và chuyển việc xem xét sang Credit Controller.

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

ID ngoại lệ	Điều kiện kích hoạt	Hành vi bắt buộc của hệ thống mô phỏng	Trạng thái kết quả	Bằng chứng cần lưu	Chủ thể xử lý
EXC-NF-CR-001	214.000.000 VND > 200.000.000 VND khi xác nhận SO-NF-20260807-0148	Chặn xác nhận; tạo lý do OVERDUE_RECEIVABLE_THRESHOLD_EXCEEDED; không tạo lệnh giao hàng	ON_CREDIT_HOLD	Mã đơn, giá trị công nợ quá hạn, ngưỡng, thời điểm kiểm tra, người yêu cầu	Credit Controller
EXC-NF-CR-002	Không lấy được số dư công nợ quá hạn từ nguồn dữ liệu mô phỏng	Không giả định giá trị bằng 0 VND; chặn xác nhận để tránh bỏ qua kiểm soát tín dụng	ON_CREDIT_HOLD	Lỗi truy xuất, mã đơn, thời điểm, nguồn dữ liệu lỗi	Credit Controller và ERP Support
EXC-NF-CR-003	Giá trị overdue_receivable_vnd âm, rỗng, không phải số nguyên VND, hoặc vượt giới hạn kiểu dữ liệu	Từ chối kết quả kiểm tra; không xác nhận đơn; ghi lỗi kiểm tra dữ liệu	ON_CREDIT_HOLD	Giá trị nhận được, quy tắc kiểm tra lỗi, mã đơn, thời điểm	Data Steward và ERP Support
EXC-NF-CR-004	Người dùng không có vai trò Credit Controller cố giải phóng giữ tín dụng	Không đổi trạng thái; không tạo ngoại lệ tín dụng	ON_CREDIT_HOLD	ID người dùng mô phỏng, vai trò, hành động bị từ chối, thời điểm	Security Administrator
EXC-NF-CR-005	Credit Controller đề nghị giải phóng đơn nhưng không có lý do và tham chiếu quyết định	Không cho chuyển ON_CREDIT_HOLD sang CONFIRMED	ON_CREDIT_HOLD	Thiếu lý do, thiếu tham chiếu quyết định, mã đơn, thời điểm	Credit Controller
EXC-NF-CR-006	Có hai yêu cầu xác nhận đồng thời cho cùng SO-NF-20260807-0148	Chỉ một yêu cầu được xử lý; yêu cầu còn lại nhận kết quả trạng thái hiện hành, không tạo hai bản ghi giữ	ON_CREDIT_HOLD	Mã tương quan yêu cầu, thời điểm, kết quả chống xử lý trùng	ERP Solution Architect xác minh thiết kế

Đường đi âm cần được hiểu từ nguyên tắc đầu vào không tin cậy: số công nợ, quyền người dùng và kết quả gọi dữ liệu có thể sai hoặc thiếu. Khi dữ liệu không đủ để chứng minh đơn an toàn, hệ thống mô phỏng không được tự xác nhận đơn. Đây là kiểm soát rủi ro nghiệp vụ trong case học liệu, không phải kết luận rằng Nova Foods thực có chính sách tín dụng như vậy.

4.2. Bằng chứng tham chiếu

Mã bằng chứng	Nội dung bằng chứng tổng hợp	Nguồn hoặc vị trí kiểm soát	Phân loại nguồn	Kết luận dùng trong case
EVD-NF-CR-001	Bản ghi đơn SO-NF-20260807-0148; khách hàng CUS-NF-0042; trạng thái trước kiểm tra PENDING_CONFIRMATION	Hồ sơ tình huống Tier 3 của TMPL-RULE-003	Dữ liệu mô phỏng	Có đối tượng cần xác nhận
EVD-NF-CR-002	Số công nợ quá hạn tổng hợp 214.000.000 VND tại thời điểm yêu cầu xác nhận	Hồ sơ tình huống Tier 3 của TMPL-RULE-003	Dữ liệu mô phỏng	Vượt ngưỡng giả định
EVD-NF-CR-003	Ngưỡng 200.000.000 VND; trạng thái chặn ON_CREDIT_HOLD; lý do OVERDUE_RECEIVABLE_THRESHOLD_EXCEEDED	Nội dung quy tắc đang IN_REVIEW trong TMPL-RULE-003	Project assumption	Dùng để minh họa quyết định chặn
EVD-NF-CR-004	Ranh giới BA: không tự phê duyệt ngưỡng, ngoại lệ, kế toán hoặc production	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Senior BA chỉ duy trì phân tích và truy vết
EVD-NF-CR-005	Trạng thái IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa baseline, chưa approval	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Không diễn giải case là chính sách đã phê duyệt
EVD-NF-CR-006	Thuật ngữ kiểm thử đường đi âm và kiểm thử hộp đen	ISTQB CTFL Syllabus v4.0.1, https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Primary testing syllabus	Dùng thuật ngữ kiểm thử; không suy diễn quy tắc tín dụng từ nguồn này

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

ID	Nội dung	Cầu nối lý do	Phân loại	Vai trò xác minh	Trạng thái
ASM-NF-CR-001	Ngưỡng giữ tín dụng là 200.000.000 VND	Case cần một giá trị so sánh xác định; không có nguồn chính sách Nova Foods thực trong corpus	PROJECT_ASSUMPTION	Business Owner — Sales & Finance	VERIFICATION_REQUIRED
ASM-NF-CR-002	overdue_receivable_vnd là tổng công nợ đã quá hạn của khách tại thời điểm xác nhận đơn	Quy tắc chỉ hoạt động nếu định nghĩa số liệu ổn định; định nghĩa kế toán chi tiết chưa được xác nhận	PROJECT_ASSUMPTION	Accounting Owner	VERIFICATION_REQUIRED
ASM-NF-CR-003	Giữ tín dụng ngăn tạo lệnh giao hàng cho đơn bị chặn	Nếu vẫn giao hàng, kiểm soát xác nhận đơn không giảm rủi ro tín dụng	PROJECT_ASSUMPTION	ERP Solution Architect và Business Owner — Sales & Finance	VERIFICATION_REQUIRED
ASM-NF-CR-004	Chỉ Credit Controller được đề xuất giải phóng giữ tín dụng	Phân tách vai trò giảm nguy cơ người tạo đơn tự bỏ qua chặn	PROJECT_ASSUMPTION	Security Administrator và Business Owner — Sales & Finance	VERIFICATION_REQUIRED
VR-NF-CR-001	Cần xác minh cách tính “quá hạn”, gồm hóa đơn tranh chấp, tiền đang đối soát và bù trừ công nợ	Các trường hợp này có thể đổi số dư so sánh và đổi kết quả chặn	VERIFICATION_REQUIRED	Accounting Owner	Chưa có xác nhận
VR-NF-CR-002	Cần xác minh quy trình cấp ngoại lệ tín dụng, thời hạn hiệu lực và người chịu trách nhiệm	Không có nguồn canonical cho phép tự giải phóng đơn bị giữ	VERIFICATION_REQUIRED	Business Owner — Sales & Finance	Chưa có xác nhận
VR-NF-CR-003	Cần xác minh nhật ký cần lưu và thời gian lưu giữ	Nhật ký có thể chứa dữ liệu cá nhân hoặc dữ liệu tài chính; yêu cầu pháp lý không được tự suy diễn	VERIFICATION_REQUIRED	Legal/Privacy Owner, Accounting Owner, Security Administrator	Chưa có xác nhận

4.4. Bản ghi escalation

ID escalation	Vấn đề	Bằng chứng và lý do escalation	Gửi tới	Hành động được phép khi chờ	Trạng thái
ESC-NF-CR-001	Ngưỡng 200.000.000 VND chưa có chính sách nguồn	ASM-NF-CR-001 là giả định; giá trị này tác động trực tiếp việc chặn doanh thu và rủi ro công nợ	Business Owner — Sales & Finance	Giữ nhãn PROJECT_ASSUMPTION; không gọi là policy; không dùng cho production	OPEN
ESC-NF-CR-002	Định nghĩa và nguồn số công nợ quá hạn chưa được xác nhận	ASM-NF-CR-002 và VR-NF-CR-001; đây là dữ liệu có tác động kế toán	Accounting Owner	Dùng dữ liệu tổng hợp chỉ để minh họa; không diễn giải là số liệu sổ cái	OPEN
ESC-NF-CR-003	Cơ chế chặn giao hàng và chống xử lý đồng thời chưa được xác nhận khả năng cấu hình	EXC-NF-CR-003 và EXC-NF-CR-006 cần quyết định thiết kế ERP	ERP Solution Architect	Không khẳng định hệ thống ERP nào hỗ trợ trạng thái hoặc khóa xử lý này	OPEN
ESC-NF-CR-004	Quyền giải phóng giữ tín dụng và nhật ký truy cập chưa được xác nhận	EXC-NF-CR-004, ASM-NF-CR-004, VR-NF-CR-003 liên quan quyền truy cập và dữ liệu tài chính	Security Administrator, Legal/Privacy Owner	Không cấp quyền mô phỏng thành quyền production; không khẳng định tuân thủ pháp luật	OPEN

Không có escalation nào là phê duyệt, baseline, quyết định nghiệp vụ, xác nhận kế toán, xác nhận pháp lý hoặc cho phép triển khai production.

Ma trận truy vết đầu-cuối cho quy tắc chặn xuất kho vượt tồn khả dụng

Phạm vi mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND. Ma trận truy vết (traceability matrix) nối nhu cầu đến kiểm thử để Senior BA chứng minh mỗi quyết định có nguồn, mỗi yêu cầu có quy tắc, mỗi kiểm thử có đối tượng kiểm tra. Các ID dưới đây là liên kết học liệu ở trạng thái IN_REVIEW, phiên bản v0.9.0; không phải baseline, approval, cấu hình ERP hay cam kết vận hành.

Thứ tự truy vết	ID	Loại	Nội dung đầy đủ	Liên kết trước	Liên kết sau	Cầu nối bằng chứng và lý do
1	NEED-NF-INV-001	NEED — nhu cầu	Nhân viên kho Nova Foods cần ngăn xác nhận xuất kho khi số lượng xuất lớn hơn tồn khả dụng của cùng kho và cùng mã hàng.	Không có; điểm bắt đầu nhu cầu mô phỏng.	REQ-NF-INV-001	Nhu cầu tồn tại vì xuất vượt số lượng có thể giao vượt khả năng cấp phát. Đây là vấn đề nghiệp vụ mô phỏng, không phải kết luận kế toán, pháp lý hay vận hành thực.
2	REQ-NF-INV-001	REQ — yêu cầu	ERP phải từ chối xác nhận phiếu xuất kho nếu soLuongXuat > soLuongTonKhaDung tại thời điểm kiểm tra. Hệ thống phải giữ phiếu ở trạng thái DRAFT và hiển thị lỗi tiếng Việt.	NEED-NF-INV-001	BR-NF-INV-001, AC-NF-INV-001, DATA-NF-INV-001, API-NF-INV-001	Yêu cầu biến nhu cầu thành hành vi hệ thống quan sát được: điều kiện từ chối, trạng thái sau từ chối, thông báo cho người dùng.
3	BR-NF-INV-001	BR — business rule, quy tắc nghiệp vụ	Chỉ được xác nhận xuất kho khi soLuongXuat nhỏ hơn hoặc bằng soLuongTonKhaDung. soLuongTonKhaDung = soLuongTonThucTe - soLuongDaGiuCho; không được cho phép giá trị âm.	REQ-NF-INV-001	AC-NF-INV-001, DATA-NF-INV-001, TC-NF-INV-001 đến TC-NF-INV-003	Quy tắc cho công thức quyết định nhất quán. Giá trị tồn và giữ chỗ là dữ liệu logic mô phỏng; cách hạch toán tồn kho cần Accounting Owner xác minh nếu chuyển sang phạm vi thực tế.
4	AC-NF-INV-001	AC — acceptance criterion, tiêu chí chấp nhận	Với kho KHO-HCM-01, hàng SP-NUOC-TAO-330, tồn thực tế 120, đã giữ chỗ 20, khi nhập số lượng xuất 100, hệ thống xác nhận phiếu xuất thành công.	REQ-NF-INV-001, BR-NF-INV-001	TC-NF-INV-001	120 - 20 = 100; số lượng xuất bằng tồn khả dụng nên đạt điều kiện <=.
5	AC-NF-INV-002	AC — tiêu chí chấp nhận	Với kho KHO-HCM-01, hàng SP-NUOC-TAO-330, tồn thực tế 120, đã giữ chỗ 20, khi nhập số lượng xuất 101, hệ thống từ chối xác nhận, giữ phiếu DRAFT, hiển thị Số lượng xuất 101 vượt tồn khả dụng 100.	REQ-NF-INV-001, BR-NF-INV-001	TC-NF-INV-002	120 - 20 = 100; 101 > 100 nên phải từ chối. Nội dung lỗi giúp người dùng biết dữ liệu cần sửa mà không tự ý giảm số lượng.
6	AC-NF-INV-003	AC — tiêu chí chấp nhận	Với kho KHO-HCM-01, hàng SP-NUOC-TAO-330, tồn thực tế 120, đã giữ chỗ 20, khi nhập số lượng xuất 0 hoặc -1, hệ thống từ chối trước kiểm tra tồn khả dụng và hiển thị Số lượng xuất phải lớn hơn 0.	REQ-NF-INV-001, BR-NF-INV-001	TC-NF-INV-003	Điều kiện tồn khả dụng không thay thế kiểm tra miền giá trị đầu vào. Số lượng không dương không đại diện nghiệp vụ xuất kho trong kịch bản mô phỏng này.
7	DATA-NF-INV-001	DATA — dữ liệu logic	Thực thể InventoryBalance gồm warehouseId, productId, onHandQuantity, reservedQuantity, availableQuantity. availableQuantity là giá trị dẫn xuất từ onHandQuantity - reservedQuantity.	BR-NF-INV-001	API-NF-INV-001, TC-NF-INV-001 đến TC-NF-INV-003	Dữ liệu phải phân biệt tồn thực tế và số đã giữ chỗ; nếu gộp hai giá trị, hệ thống không chứng minh được cơ sở tính tồn khả dụng. Tham chiếu định hướng: CANONICAL_DATA_DICTIONARY, trạng thái IN_REVIEW.
8	API-NF-INV-001	API — giao diện lập trình ứng dụng	POST /api/v1/warehouse-issues/validate-availability nhận warehouseId, productId, quantity; trả eligible, availableQuantity, message. API chỉ kiểm tra khả dụng, không xác nhận xuất kho.	REQ-NF-INV-001, DATA-NF-INV-001	TC-NF-INV-001 đến TC-NF-INV-003	Tách kiểm tra khỏi xác nhận giúp giao diện biết kết quả trước thao tác cuối. Đây là thiết kế minh họa; hợp đồng API chưa là OpenAPI baseline. OAS 3.1.1 chỉ là nguồn thuật ngữ và mô tả HTTP API.
9	TC-NF-INV-001	TC — test case, ca kiểm thử	Gửi KHO-HCM-01, SP-NUOC-TAO-330, quantity: 100; chuẩn bị tồn thực tế 120, giữ chỗ 20; mong đợi eligible: true, availableQuantity: 100.	AC-NF-INV-001, DATA-NF-INV-001, API-NF-INV-001	Không có; kiểm thử đầu cuối đường hợp lệ.	Ca kiểm thử xác nhận biên bằng đúng tồn khả dụng, nơi sai toán tử < thay vì <= sẽ lộ ra.
10	TC-NF-INV-002	TC — ca kiểm thử	Gửi KHO-HCM-01, SP-NUOC-TAO-330, quantity: 101; chuẩn bị tồn thực tế 120, giữ chỗ 20; mong đợi eligible: false, availableQuantity: 100, thông báo vượt tồn khả dụng.	AC-NF-INV-002, DATA-NF-INV-001, API-NF-INV-001	DEF-NF-INV-001 nếu kết quả sai.	Ca kiểm thử xác nhận nhánh từ chối ngay trên giá trị lớn hơn biên một đơn vị; đây là kỹ thuật kiểm thử giá trị biên theo thuật ngữ ISTQB CTFL.
11	TC-NF-INV-003	TC — ca kiểm thử	Gửi lần lượt quantity: 0 và quantity: -1 với cùng kho, hàng; mong đợi mỗi lần eligible: false và thông báo số lượng phải lớn hơn 0.	AC-NF-INV-003, API-NF-INV-001	DEF-NF-INV-002 nếu API chấp nhận giá trị không dương.	Ca kiểm thử bảo vệ ranh giới tin cậy của API. Kiểm tra tồn không đủ nếu đầu vào số lượng đã vô nghĩa.
12	DEF-NF-INV-001	DEF — defect, lỗi	Chỉ tạo khi TC-NF-INV-002 nhận eligible: true, hoặc phiếu được xác nhận với quantity: 101. Mức độ dự kiến: High, vì phá vỡ BR-NF-INV-001.	TC-NF-INV-002	REQ-NF-INV-001, BR-NF-INV-001, TC-NF-INV-002	Chưa có lỗi được ghi nhận tại v0.9.0; hàng này định nghĩa đường truy vết nếu lỗi xuất hiện, không khẳng định lỗi đã tồn tại.
13	DEF-NF-INV-002	DEF — lỗi	Chỉ tạo khi TC-NF-INV-003 nhận eligible: true cho 0 hoặc -1. Mức độ dự kiến: Medium, vì vi phạm kiểm tra dữ liệu đầu vào.	TC-NF-INV-003	REQ-NF-INV-001, AC-NF-INV-003, TC-NF-INV-003	Chưa có lỗi được ghi nhận tại v0.9.0; không gán nguyên nhân kỹ thuật trước khi có bằng chứng chạy kiểm thử.
14	CR-NF-INV-001	CR — change request, yêu cầu thay đổi	Chỉ tạo nếu Business Owner yêu cầu cho phép xuất vượt tồn khả dụng theo quy trình được phê duyệt riêng. CR phải đánh giá lại NEED-NF-INV-001, REQ-NF-INV-001, BR-NF-INV-001, toàn bộ AC và TC liên quan.	NEED-NF-INV-001 đến TC-NF-INV-003	Không có; chờ yêu cầu thay đổi hợp lệ.	Thay đổi chính sách xuất vượt tồn không phải sửa lỗi tự động. Nó đổi quy tắc nghiệp vụ, cần Business Owner và các owner chuyên môn liên quan quyết định.

Kiểm tra toàn vẹn truy vết	Kết quả tại IN_REVIEW	Lý do
Mỗi REQ có NEED nguồn	Đạt	REQ-NF-INV-001 liên kết NEED-NF-INV-001.
Mỗi BR có REQ áp dụng	Đạt	BR-NF-INV-001 cụ thể hóa điều kiện của REQ-NF-INV-001.
Mỗi AC có BR hoặc REQ làm cơ sở	Đạt	AC-NF-INV-001 đến AC-NF-INV-003 kiểm tra đường hợp lệ, vượt biên và đầu vào không hợp lệ.
Mỗi TC có AC làm oracle kiểm thử	Đạt	TC-NF-INV-001 đến TC-NF-INV-003 có kết quả mong đợi đo được.
DEF và CR có đường quay lại nguồn tác động	Đạt có điều kiện	Chưa phát sinh DEF hoặc CR; ID chỉ giữ đường liên kết dự kiến, không tạo baseline hay xác nhận lỗi.
Nguồn canonical bị diễn giải thành baseline	Không đạt nếu xảy ra	TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều IN_REVIEW; chỉ dùng làm ranh giới định danh và thuật ngữ.

Bảng quyết định hoàn chỉnh — Quy tắc mở xuất kho đơn bán mô phỏng

Bảng quyết định (decision table) biến điều kiện nghiệp vụ thành tổ hợp đầu vào và kết quả xác định. Dùng cho cùng bản ghi quy tắc TMPL-RULE-003, tình huống Nova Foods Trading & Manufacturing mô phỏng: ERP chỉ mở yêu cầu xuất kho cho đơn bán khi đơn còn hạn mức tín dụng và đã giữ đủ tồn kho. Đây là giả định dự án giáo dục, không phải chính sách tín dụng, kế toán, pháp lý hay cấu hình ERP thật.

Trường dữ liệu logic	Kiểu	Giá trị dùng trong bảng	Ý nghĩa
creditLimitAvailable	Boolean	true, false	Khách hàng còn hạn mức tín dụng theo dữ liệu mô phỏng.
salesOrderWithinCredit	Boolean	true, false	Giá trị đơn bán không vượt hạn mức còn lại theo dữ liệu mô phỏng.
inventoryFullyAllocated	Boolean	true, false	Mọi dòng hàng của đơn đã được giữ đủ số lượng tại kho mô phỏng.
warehouseReleaseStatus	Enum	RELEASED, ON_HOLD	Trạng thái ERP trả về cho yêu cầu xuất kho.
holdReasonCode	Enum hoặc null	CREDIT_UNAVAILABLE, CREDIT_EXCEEDED, STOCK_UNALLOCATED, MULTIPLE_BLOCKERS, null	Lý do giữ đơn; chỉ dùng dữ liệu tổng hợp.

Quy tắc quyết định	creditLimitAvailable	salesOrderWithinCredit	inventoryFullyAllocated	warehouseReleaseStatus	holdReasonCode	Dữ liệu đơn bán tổng hợp
R01	true	true	true	RELEASED	null	SO-SIM-260807-001, khách CUS-SIM-001, giá trị 18.000.000 VND, hàng SKU-SIM-NUOC-01, số lượng 120
R02	true	true	false	ON_HOLD	STOCK_UNALLOCATED	SO-SIM-260807-002, khách CUS-SIM-002, giá trị 12.500.000 VND, hàng SKU-SIM-NUOC-02, số lượng 90
R03	true	false	true	ON_HOLD	CREDIT_EXCEEDED	SO-SIM-260807-003, khách CUS-SIM-003, giá trị 45.000.000 VND, hàng SKU-SIM-NUOC-03, số lượng 300
R04	true	false	false	ON_HOLD	MULTIPLE_BLOCKERS	SO-SIM-260807-004, khách CUS-SIM-004, giá trị 64.000.000 VND, hàng SKU-SIM-NUOC-04, số lượng 500
R05	false	true	true	ON_HOLD	CREDIT_UNAVAILABLE	SO-SIM-260807-005, khách CUS-SIM-005, giá trị 9.600.000 VND, hàng SKU-SIM-NUOC-05, số lượng 80
R06	false	true	false	ON_HOLD	MULTIPLE_BLOCKERS	SO-SIM-260807-006, khách CUS-SIM-006, giá trị 21.000.000 VND, hàng SKU-SIM-NUOC-06, số lượng 150
R07	false	false	true	ON_HOLD	MULTIPLE_BLOCKERS	SO-SIM-260807-007, khách CUS-SIM-007, giá trị 38.400.000 VND, hàng SKU-SIM-NUOC-07, số lượng 240
R08	false	false	false	ON_HOLD	MULTIPLE_BLOCKERS	SO-SIM-260807-008, khách CUS-SIM-008, giá trị 72.000.000 VND, hàng SKU-SIM-NUOC-08, số lượng 600

RELEASED chỉ xuất hiện tại R01 vì cả ba điều kiện kiểm soát đều đúng. Các hàng còn lại giữ đơn để ERP không tạo yêu cầu xuất kho khi còn ít nhất một điều kiện chưa đạt. MULTIPLE_BLOCKERS dùng khi có từ hai điều kiện sai; lý do này giúp người xử lý thấy đủ điểm chặn thay vì sửa một điểm rồi gặp điểm chặn khác. Phân loại nguồn cho toàn bộ điều kiện, mã trạng thái, khách hàng, SKU và số tiền trong bảng là project assumption — synthetic data only.

5. Tier 4 ? Senior BA Quality Gate

Senior BA Quality Gate là cổng kiểm tra trước baseline: Senior Business Analyst rà soát rule record để xác định nội dung đủ rõ cho review có thẩm quyền, nhưng không tự tạo baseline, approval, kết luận pháp lý, kế toán, bảo mật hoặc production readiness. Checklist áp dụng cho Tier 3 Nova Foods Trading & Manufacturing, là case mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

Kết quả	Tiêu chí quyết định	Hành động bắt buộc
PASS	Có bằng chứng kiểm tra được; không có mâu thuẫn; đúng boundary thẩm quyền.	Ghi kết quả và chuyển sang mục kiểm tra kế tiếp.
FAIL	Thiếu, sai, mơ hồ, mâu thuẫn hoặc chưa test được; lỗi không buộc dừng toàn bộ review.	Trả về người soạn sửa record, giữ trạng thái IN_REVIEW.
STOP	Thiếu nguồn canonical, sai ID, nguồn không đủ thẩm quyền bị diễn đạt thành bắt buộc, hoặc có rủi ro legal/accounting/security chưa được chủ thể có thẩm quyền xác minh.	Dừng pre-baseline review; không đưa rule vào baseline hoặc cấu hình ERP.
ESCALATE	Quyết định vượt quyền Senior BA hoặc có xung đột giữa nguồn, owner, boundary hay tác động liên miền.	Lập gói vấn đề, giữ traceability, chuyển đúng vai trò; không tự kết luận thay vai trò đó.

ID kiểm tra	Nội dung Senior BA kiểm tra	PASS khi	FAIL khi	STOP hoặc ESCALATE khi
QG-RULE-001	Tính đầy đủ	Rule có ID, tên, mục tiêu, trigger, điều kiện, quyết định, kết quả, ngoại lệ, owner, phạm vi và liên kết truy vết. Mỗi trường trả lời được câu hỏi “ai làm gì, khi nào, theo dữ liệu nào, cho kết quả nào”.	Thiếu trường hoặc dùng mô tả không xác định được hành vi.	STOP nếu thiếu canonical ID hoặc record không xác định được rule nào đang được kiểm tra.
QG-RULE-002	Tính nhất quán	Điều kiện, bảng quyết định, trạng thái, reason code, ví dụ và kết quả không mâu thuẫn nhau. Một tổ hợp đầu vào chỉ dẫn tới một kết quả xác định.	Cùng đầu vào cho hai kết quả khác nhau, hoặc mô tả nói khác bảng quyết định.	STOP nếu mâu thuẫn làm ERP có thể phát hành giao dịch trái kiểm soát.
QG-RULE-003	Tính kiểm thử được	Mỗi điều kiện có dữ liệu vào, bước thực hiện và kết quả mong đợi quan sát được. Biên đúng/sai và ngoại lệ có thể viết thành test case.	Dùng từ như “hợp lý”, “đủ tốt”, “nhanh” mà không có tiêu chí đo hoặc quyết định rõ.	FAIL; ESCALATE cho Business Owner khi cần định nghĩa ngưỡng nghiệp vụ. Thuật ngữ testability là khả năng kiểm thử: người kiểm thử có thể chứng minh kết quả đúng hoặc sai từ bằng chứng quan sát được.
QG-RULE-004	Traceability	Mỗi assertion liên kết tới nguồn, assumption, requirement, data field, decision table hoặc test basis bằng ID canonical. Liên kết dùng đúng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các artifact này là nguồn canonical được chỉ định.	Có liên kết tên tự do, ID biến thể, hoặc không truy ngược được từ kết quả về lý do.	STOP nếu ID không đăng ký, nguồn canonical bị thay bằng bản sao, hoặc traceability đứt tại quyết định có rủi ro cao.
QG-RULE-005	Thẩm quyền nguồn	Nguồn được phân loại rõ: primary source, project assumption, hoặc Verification required. Suy luận luôn nêu cầu nối từ bằng chứng đến rule.	Trích nguồn nhưng không nói nguồn chứng minh phần nào, hoặc trình bày assumption như nghĩa vụ bắt buộc.	ESCALATE Legal, Accounting, Security, Compliance hoặc Business Owner theo miền. STOP nếu nguồn không đủ thẩm quyền lại được dùng để quyết định bắt buộc.
QG-RULE-006	Ownership	Có owner chịu trách nhiệm nghiệp vụ, người thực thi, người nhận escalation và giới hạn thẩm quyền từng vai trò. Owner của artifact không bị gán thành người phê duyệt rule.	Chỉ ghi tên đội nhóm chung chung hoặc không có đường xử lý khi rule bị chặn.	ESCALATE nếu nhiều owner mâu thuẫn hoặc không ai có quyền quyết định ngoại lệ.
QG-RULE-007	Boundary bảo mật và riêng tư	Rule xác định dữ liệu nhạy cảm, quyền xem/sửa, kênh truyền, log và hành vi khi không đủ quyền. Chỉ tham chiếu OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023 như good practice, không gọi là luật Việt Nam.	Có dữ liệu cá nhân hoặc thông tin tín dụng nhưng không nêu kiểm soát truy cập hay minimization.	STOP nếu rule có thể tiết lộ dữ liệu không được phép. ESCALATE Security Owner và Legal/Privacy Owner nếu phát sinh dữ liệu cá nhân hoặc nghĩa vụ theo Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP; yêu cầu pháp lý phải mang nhãn Verification required cho đến khi vai trò có thẩm quyền xác minh.
QG-RULE-008	Boundary pháp lý, kế toán, thuế	Rule tách rõ logic ERP mô phỏng với diễn giải pháp lý, hóa đơn, chứng từ, hạch toán và thuế. Nội dung ngoài nguồn xác minh ghi project assumption hoặc Verification required.	Rule tự khẳng định bút toán, thuế, hóa đơn hoặc tuân thủ mà không có xác minh thẩm quyền.	STOP nếu rule tạo hoặc thay đổi nghĩa vụ pháp lý/kế toán. ESCALATE Accounting Owner và Legal Owner; tham chiếu Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP không thay thế kết luận chuyên môn.
QG-RULE-009	Tác động thay đổi	Record nêu đối tượng bị ảnh hưởng: quy trình, trạng thái, API, dữ liệu, báo cáo, phân quyền, test case và tài liệu liên quan. Mỗi tác động có hành động kiểm tra.	Chỉ sửa rule text mà không xét đầu ra, dữ liệu hoặc test đã liên kết.	ESCALATE Architect khi ảnh hưởng integration, API hoặc kiến trúc; ESCALATE QA Owner khi thay đổi làm vô hiệu test basis; STOP nếu chưa xác định được phạm vi tác động của thay đổi rủi ro cao.
QG-RULE-010	Ranh giới case mô phỏng	Nova Foods được ghi đúng là simulated educational case study; toàn bộ khách hàng, SKU, số tiền VND, trạng thái và giao dịch là synthetic data only.	Nội dung ám chỉ Nova Foods là doanh nghiệp thật, cấu hình ERP thật hoặc đã tuân thủ thực tế.	STOP nếu record tạo tuyên bố vận hành, compliance, approval hoặc production authority không có căn cứ.

Quy tắc tổng hợp: chỉ ghi PASS cho checklist khi mọi hàng kiểm tra là PASS. Một FAIL giữ rule ở IN_REVIEW. Một STOP dừng review pre-baseline cho rule liên quan. ESCALATE không phải approval: Senior BA chỉ chuyển gói gồm rule ID, bằng chứng, xung đột, tác động và câu hỏi quyết định đến đúng owner có thẩm quyền.

Phạm vi kiểm tra chất lượng Senior BA

Checklist Senior BA kiểm tra rule record trước baseline. “Hoàn chỉnh” nghĩa là mỗi trường bắt buộc có giá trị, quyết định và ngoại lệ xác định. “Nhất quán” nghĩa là ID, thuật ngữ, dữ liệu, trạng thái và liên kết không mâu thuẫn nguồn canonical. “Kiểm thử được” nghĩa là tester tạo được dữ liệu đầu vào, hành động, kết quả mong đợi và trường hợp biên. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Mã kiểm tra	Phạm vi	Điều kiện đạt	Dấu hiệu không đạt và tác động
QG-CMP-01	Hoàn chỉnh	Rule có ID canonical, tên, mục đích, trigger, điều kiện, hành động, đầu ra, ngoại lệ, owner, nguồn và liên kết truy vết.	Thiếu bất kỳ trường nào làm người đọc tự suy diễn; không đủ điều kiện baseline.
QG-CON-02	Nhất quán	ID và thuật ngữ khớp CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY, CANONICAL_DATA_DICTIONARY; VND, vi-VN, Asia/Ho_Chi_Minh dùng thống nhất.	Một ID có hai nghĩa, một trường có hai kiểu dữ liệu, hoặc đơn vị tiền tệ/múi giờ khác nhau tạo lỗi tích hợp và báo cáo.
QG-TST-03	Kiểm thử được	Mỗi điều kiện chuyển thành ca kiểm thử hộp đen: dữ liệu hợp lệ, không hợp lệ và biên; kết quả mong đợi đo được.	Chỉ ghi “hệ thống kiểm tra” mà không nêu điều kiện, thông báo hoặc kết quả lưu vết.
QG-TRC-04	Truy vết	Rule liên kết ngược tới nhu cầu, nguồn hoặc giả định; liên kết xuôi tới requirement, acceptance criteria, dữ liệu và test case khi các artifact đó tồn tại.	Liên kết chỉ nêu tên tài liệu, không nêu ID hoặc đường dẫn canonical; không chứng minh được lý do tồn tại rule.
QG-SRC-05	Thẩm quyền nguồn	Nguồn được phân loại rõ: primary source, project assumption, hoặc Verification required. Nguồn pháp lý chỉ tạo nghĩa vụ sau xác nhận Legal Owner phù hợp.	Gán chuẩn, luật, thông lệ OWASP hoặc diễn giải nội bộ thành quy định Nova Foods đã hiệu lực.
QG-OWN-06	Ownership	Owner nghiệp vụ chịu trách nhiệm nội dung rule; owner hệ thống chịu trách nhiệm khả năng triển khai; BA giữ truy vết, không thay quyền quyết định.	Gán Principal IT Business Analyst / Technical Curriculum Author làm người phê duyệt nghiệp vụ, pháp lý, kế toán hoặc production.
QG-BND-07	Bảo mật, riêng tư, pháp lý, kế toán	Rule xác định dữ liệu cá nhân, dữ liệu tài chính, dữ liệu an toàn thực phẩm, quyền truy cập và nơi cần xác minh chuyên môn.	Thu thập, hiển thị, sửa hoặc lưu dữ liệu nhạy cảm mà không có boundary, owner và trạng thái xác minh.
QG-CHG-08	Tác động thay đổi	Rule nêu artifact, dữ liệu, giao diện, API, báo cáo, phân quyền và test bị ảnh hưởng khi điều kiện hoặc ngưỡng đổi.	Sửa rule mà không rà liên kết downstream; tạo lệch giữa rule, test và cấu hình ERP.

Áp dụng cho completed Nova Foods example. Record Tier 3 phải được đối chiếu từng dòng trên, không dùng trạng thái IN_REVIEW làm bằng chứng đạt. Nếu rule dùng ngưỡng tiền tệ VND, bằng chứng phải chỉ ra giá trị tổng hợp, phép so sánh, cách làm tròn nếu có, và kết quả khi bằng, nhỏ hơn, lớn hơn ngưỡng. Lý do: ba quan hệ này có thể sinh ba quyết định khác nhau; tester không thể suy ra từ mô tả chung.

Mã kiểm tra	Kết quả ghi nhận cho Nova Foods mô phỏng	Cơ sở bằng chứng hoặc suy luận	Hành động còn mở
QG-CMP-01	Cần kiểm tra theo record hoàn chỉnh	Tier 3 được yêu cầu điền đủ trường, quyết định, ngoại lệ và traceability; section này không tạo lại record.	Đối chiếu từng trường Tier 3 trước baseline.
QG-CON-02	Cần kiểm tra	ID và đường dẫn canonical phải khớp /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	So khớp chuỗi ID nguyên dạng, không đổi tên dịch thuật.
QG-TST-03	Cần kiểm tra	ISTQB CTFL Syllabus v4.0.1 là nguồn primary cho thuật ngữ kiểm thử; không có test evidence được cung cấp trong section này.	Lập ca kiểm thử từ điều kiện, ngoại lệ và kết quả mong đợi của Tier 3.
QG-TRC-04	Cần kiểm tra	CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY là nguồn canonical theo dependency.	Xác nhận liên kết ngược/xuôi có ID và đường dẫn.
QG-SRC-05	Verification required	Luật, nghị định, kế toán, hóa đơn và an toàn thực phẩm trong source seed chỉ dùng trong boundary nêu sẵn; nội dung suy diễn cần owner có thẩm quyền xác minh.	Gắn source classification cho từng nguồn của rule.
QG-OWN-06	Đạt về boundary tài liệu	Upstream artifacts xác định Principal IT Business Analyst / Technical Curriculum Author không có quyền approval, legal, accounting hoặc production.	Chỉ định Business Owner, Legal Owner, Accounting Owner, Security Owner khi rule chạm phạm vi đó.
QG-BND-07	Verification required	Source seed nêu Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán và nguồn an toàn thực phẩm; không có kết luận áp dụng cụ thể cho Nova Foods mô phỏng.	Ghi rõ loại dữ liệu và chuyển xác minh cho owner chuyên môn.
QG-CHG-08	Cần kiểm tra	Thay đổi rule có thể ảnh hưởng dữ liệu, test và artifact liên kết; traceability là cơ chế phát hiện tác động.	Lập impact record trước mọi thay đổi sau này.

Áp dụng cổng chất lượng cho bản ghi Nova Foods đã hoàn chỉnh

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Đối tượng review: bản ghi Tier 3 trong /03-templates/TMPL-RULE-003-rule-governance-register.md; trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Review này ghi nhận bằng chứng và khoảng trống; không tạo baseline, approval, xác nhận tuân thủ, hay quyền dùng production.

Mục kiểm	Bằng chứng kiểm tại bản ghi Nova Foods	Kết quả	Phát hiện và quyết định
Đủ nội dung	Bản ghi Tier 3 có mục đích, điều kiện kích hoạt, xử lý, kết quả, ngoại lệ, owner, nguồn và liên kết truy vết.	PASS	Không có trường nghiệp vụ trống trong bản ghi mô phỏng.
Nhất quán quản trị	Metadata dùng IN_REVIEW, v0.9.0, 2026-08-07; khớp /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md.	PASS	Không diễn giải IN_REVIEW thành APPROVED hoặc BASELINED.
Khả năng kiểm thử	Điều kiện, hành vi hệ thống, kết quả mong đợi và ngoại lệ trong Tier 3 được viết theo dạng có thể tạo dữ liệu vào, thao tác và kết quả quan sát. Thuật ngữ test basis là tập đầu vào làm căn cứ thiết kế kiểm thử.	PASS	Có thể lập test case hộp đen theo thuật ngữ ISTQB CTFL Syllabus v4.0.1.
Truy vết	Liên kết quản trị giữ nguyên tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, /01-curriculum/TEMPLATE_MANIFEST.md.	PASS	Liên kết chứng minh nơi kiểm soát artifact, không chứng minh rule đúng cho ERP thật.
Thẩm quyền nguồn	BABOK Guide Version 3 dùng cho thuật ngữ BA; ISTQB CTFL Syllabus v4.0.1 dùng cho thuật ngữ test; nguồn luật chỉ được nêu theo URL chính thức trong source seed.	PASS có điều kiện	Nguồn chuẩn hỗ trợ phương pháp review. Không có trích dẫn điều, khoản, hay diễn giải luật chưa được kiểm chứng văn bản cấp phép.
Owner và quyền quyết định	Owner ghi là Principal IT Business Analyst / Technical Curriculum Author; giới hạn thẩm quyền khớp artifact upstream.	PASS	Owner duy trì artifact và traceability; không thay Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA.
Bảo mật và riêng tư	Bản ghi chưa có bằng chứng phân loại dữ liệu, ma trận quyền, thời hạn lưu giữ, cơ chế che dữ liệu hoặc xác minh Security Owner. OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 chỉ là chuẩn thực hành ngành.	ESCALATE	Gửi Security Owner xác định dữ liệu cá nhân, quyền truy cập và kiểm soát phù hợp. Không gọi OWASP là luật Việt Nam.
Pháp lý và kế toán	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP chỉ là nguồn pháp lý cần đối chiếu theo thẩm quyền.	STOP	Dừng mọi diễn đạt coi rule là nghĩa vụ pháp lý, thuế, hóa đơn hoặc hạch toán cho đến khi Legal Owner và Accounting Owner xác minh văn bản hiện hành, phạm vi áp dụng và diễn giải.
Ảnh hưởng thay đổi	Chưa có baseline reference hoặc approval reference tại v0.9.0; thay đổi rule có thể ảnh hưởng catalog rule, data dictionary, test basis và artifact liên kết.	STOP	Không được phát hành baseline hoặc dùng làm cấu hình ERP. Mọi sửa đổi phải giữ ID, version history và traceability.

Kết luận ghi nhận: STOP — AUTHORITY VERIFICATION REQUIRED. Phần mô tả và truy vết của case mô phỏng đạt mức review nội bộ; ranh giới security/privacy/legal/accounting chưa có xác minh từ owner có thẩm quyền. Không có approval được ghi nhận.

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

Kiểm tra liên tệp bảo đảm một quy tắc chỉ có một nguồn chuẩn, gọi là canonical (nguồn duy nhất được phép làm căn cứ). Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Kết quả dưới đây kiểm tra tính khớp quản trị của TMPL-RULE-003, không xác nhận quy tắc nghiệp vụ, pháp lý, kế toán, bảo mật hoặc cấu hình ERP thực tế.

Hạng mục kiểm tra	Nguồn kiểm tra canonical	Tiêu chí đối chiếu	Kết quả tại IN_REVIEW v0.9.0	Ranh giới quyết định
Manifest template	/01-curriculum/TEMPLATE_MANIFEST.md — TEMPLATE_MANIFEST	Tên template, đường dẫn /03-templates/TMPL-RULE-003-rule-governance-register.md, trạng thái, version, locale và case study không mâu thuẫn manifest.	PARTIAL CHECK: metadata corpus khớp IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND, Nova Foods mô phỏng. Trích đoạn nguồn không chứa dòng đăng ký riêng của TMPL-RULE-003; không được suy diễn template đã được manifest xác nhận.	Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận liên kết và sai khác metadata.
Registry ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY	ID artifact và các ID rule, requirement, data, test phải giữ nguyên chuỗi đã đăng ký; không tạo biến thể dịch thuật hoặc ID mới.	PASS cho ID artifact TMPL-RULE-003 trong phạm vi tệp này. NOT EVIDENCED cho ID bản ghi rule cụ thể vì micro-batch không nhận danh sách ID registry đầy đủ. Không tạo BR-NF-*, REQ-NF-*, DD-NF-* hoặc TC-NF-* mới.	Registry là nguồn chuẩn của định danh; template không cấp phát ID.
Catalog rule canonical	/01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES	Rule trong register phải tham chiếu catalog bằng ID nguyên dạng; nội dung, ngoại lệ, owner và trạng thái không được sao chép rồi thành nguồn mới.	PASS cho nguyên tắc nguồn chuẩn: catalog rule có thẩm quyền nội dung rule hơn template. NOT EVIDENCED cho khớp từng rule vì không có bản ghi rule hoàn chỉnh trong đầu vào micro-batch.	Business Owner xác nhận ý nghĩa nghiệp vụ; Legal Owner, Accounting Owner, Security và Architect xác nhận phần thuộc chuyên môn.
Từ điển dữ liệu canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY	Mỗi trường dữ liệu nhắc trong rule phải dùng tên logic, định nghĩa, kiểu và phân loại từ điển dữ liệu; template không tự định nghĩa lại dữ liệu.	PARTIAL CHECK: ID và đường dẫn canonical được giữ nguyên. Không có trường dữ liệu Nova Foods cụ thể trong micro-batch để đối chiếu từng dòng.	Data dictionary là nguồn chuẩn cho định nghĩa dữ liệu; không suy diễn schema triển khai.
Chapter liên quan	/01-curriculum/CHAPTER_MANIFEST.md — CHAPTER_MANIFEST; /01-curriculum/01_CURRICULUM_ARCHITECTURE.md — 01_CURRICULUM_ARCHITECTURE	Rule governance phải hỗ trợ chuỗi học requirement, acceptance criteria, traceability và test basis; không biến template thành quyết định vận hành.	PASS: mục đích register là kiểm soát truy vết và phù hợp ranh giới curriculum. Không có bằng chứng để gọi bất kỳ chapter nào đã baseline hoặc approved.	Manifest chapter kiểm soát cấu trúc curriculum; không phê duyệt nội dung rule.
Template liên quan	/03-templates/ theo TEMPLATE_MANIFEST	Không trùng nguồn chân lý với template requirement, data, traceability hoặc test; liên kết chỉ dùng ID canonical.	PASS về quy tắc: TMPL-RULE-003 là register quản trị rule, không thay catalog rule, data dictionary hay registry ID.	Template khác không được sửa ngữ nghĩa rule qua bản sao cục bộ.
Consumer hạ nguồn	Artifact test basis, acceptance criteria, traceability và delivery thuộc corpus	Consumer chỉ đọc ID rule, version, trạng thái và liên kết canonical; không dùng nội dung IN_REVIEW làm cấu hình, test pass criterion cuối cùng hoặc bằng chứng tuân thủ.	PASS về boundary. IN_REVIEW không phải BASELINED, APPROVED, production-ready hoặc user-approved.	QA xác nhận test; Business Owner xác nhận nghiệp vụ; không consumer nào tự nâng trạng thái.

Quy tắc đối chiếu bắt buộc: khi cùng một ID có hai mô tả khác nhau, catalog canonical thắng bản sao trong template; khi ID hoặc đường dẫn khác nhau, dừng liên kết thay vì tự sửa; khi rule nhắc dữ liệu chưa có định nghĩa canonical, không tự thêm trường dữ liệu. Lý do: ID giữ truy vết, còn nguồn canonical giữ một nghĩa kiểm soát cho mỗi đối tượng.

Không diễn giải nguồn BABOK Guide, ISO/IEC/IEEE 29148, BPMN, UML, ISTQB, OpenAPI, WCAG hoặc OWASP thành quy tắc Nova Foods. 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ỉ được tham chiếu theo ranh giới nguồn đã xác minh; template không tạo kết luận pháp lý, kế toán, thuế, an toàn thực phẩm hay compliance.

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

Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Danh sách này đầy đủ trong phạm vi TMPL-RULE-003 tại v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh. “Vấn đề mở” là điểm chặn quyết định; “giả định dự án” là điều tạm dùng để thiết kế học liệu; “cần xác minh” là nội dung không được nâng thành quy tắc bắt buộc trước khi role có thẩm quyền kiểm tra nguồn.

ID mục	Loại	ID/tệp bị ảnh hưởng	Nội dung và cầu nối bằng chứng	Owner xử lý	Ảnh hưởng	Hành động kế tiếp
ISS-RULE-003-01	Vấn đề mở	TMPL-RULE-003; CANONICAL_BUSINESS_RULES; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog quy tắc canonical đang IN_REVIEW, chưa có baseline hay approval reference. Vì rule register chỉ được tham chiếu rule canonical đã nhận diện nguồn, không thể ghi rule Nova Foods là bắt buộc hoặc đã phê duyệt.	Business Owner cho nội dung nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author giữ traceability.	Cao. Rule có thể bị hiểu sai thành chỉ dẫn ERP thực tế.	Business Owner xác định rule mô phỏng nào đủ nội dung để review; BA ghi nguồn, trạng thái, rationale và decision record trước khi liên kết từ template.
ASM-RULE-003-01	Giả định dự án	TMPL-RULE-003; TRACEABILITY_ID_REGISTRY; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giả định mỗi rule register dùng ID đã đăng ký trong TRACEABILITY_ID_REGISTRY. Cầu nối: registry là nguồn canonical cho định danh; ID tự đặt trong template làm đứt truy vết liên artifact.	Principal IT Business Analyst / Technical Curriculum Author.	Trung bình. Có thể tạo ID trùng hoặc liên kết sai.	Chỉ dùng ID có trong registry khi điền Tier 3; nếu thiếu ID, lập yêu cầu đăng ký ID, không dùng ID tạm như rule canonical.
VRF-RULE-003-01	Cần xác minh	TMPL-RULE-003; CANONICAL_DATA_DICTIONARY; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên field, kiểu dữ liệu, mã trạng thái, đơn vị tính và giá trị VND chưa được dùng như data specification triển khai. Cầu nối: data dictionary là nguồn canonical logic, nhưng đang IN_REVIEW; template không được tự xác nhận schema ERP.	Data Owner; Architect xác minh tác động kỹ thuật.	Cao. Rule có thể dùng field không tồn tại hoặc sai nghĩa dữ liệu.	Đối chiếu từng data element của rule với dictionary; ghi mismatch thành issue riêng; chỉ mô tả dữ liệu tổng hợp sau khi Data Owner xác minh nghĩa logic.
VRF-RULE-003-02	Cần xác minh	TMPL-RULE-003; CANONICAL_BUSINESS_RULES; Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP	Bất kỳ rule về dữ liệu cá nhân, phân quyền, lưu giữ hoặc chia sẻ dữ liệu cần Legal Owner và Security xác minh. Cầu nối: nguồn luật là official legal source, nhưng seed cấm suy diễn yêu cầu hệ thống khi chưa có kiểm tra pháp lý; OWASP ASVS không phải luật Việt Nam.	Legal Owner; Security Owner.	Cao. Rủi ro diễn giải pháp lý hoặc bảo mật sai.	Gắn phân loại Verification required; Legal Owner xác minh nghĩa vụ áp dụng; Security Owner xác minh control kỹ thuật; không ghi compliance hoặc production-ready.
VRF-RULE-003-03	Cần xác minh	TMPL-RULE-003; CANONICAL_BUSINESS_RULES; Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP	Bất kỳ rule về sổ kế toán, hóa đơn, chứng từ, thuế hoặc thời điểm hạch toán cần xác minh hiện hành. Cầu nối: hai nguồn là nguồn pháp lý official, nhưng seed yêu cầu Accounting/Legal kiểm tra diễn giải và amendment trước khi dùng production.	Accounting Owner; Legal Owner.	Cao. Sai rule tài chính hoặc hóa đơn.	Giữ ví dụ Nova Foods ở mức dữ liệu tổng hợp; Accounting Owner xác nhận diễn giải; Legal Owner kiểm tra amendment; ghi decision reference khi có.
VRF-RULE-003-04	Cần xác minh	TMPL-RULE-003; CANONICAL_BUSINESS_RULES; Luật 55/2010/QH12	Bất kỳ rule về lot, hạn dùng, truy xuất hoặc thu hồi thực phẩm cần Domain Owner và Legal Owner xác minh. Cầu nối: luật cung cấp bối cảnh an toàn thực phẩm; seed không cho phép biến bối cảnh này thành quy trình Nova Foods thực tế.	Food Safety Domain Owner; Legal Owner.	Cao. Rủi ro hiểu nhầm rule mô phỏng là control vận hành.	Xác định phạm vi học liệu; Domain Owner xác minh thuật ngữ và luồng nghiệp vụ; Legal Owner xác minh giới hạn pháp lý; giữ nhãn mô phỏng đến khi có ghi nhận quyết định.
ASM-RULE-003-02	Giả định dự án	TMPL-RULE-003; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; /01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/TEMPLATE_MANIFEST.md	Giả định downstream consumer chỉ dùng register làm test basis, learning artifact và traceability reference, không dùng để cấu hình ERP. Cầu nối: cả manifest xác định corpus là controlled planning artifact, IN_REVIEW, không production authority.	Principal IT Business Analyst / Technical Curriculum Author; QA Reviewer kiểm tra cách dùng.	Trung bình. Downstream có thể nâng nhầm status của rule.	Mỗi consumer phải giữ nguyên IN_REVIEW, v0.9.0, mô phỏng và dữ liệu tổng hợp; QA Reviewer chặn cụm từ APPROVED, BASELINED, compliant hoặc production-ready nếu chưa có reference kiểm soát.

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

Bàn giao có kiểm soát là chuyển gói thông tin để vai trò nhận tiếp tục xem xét, không phải phê duyệt hay chuyển trạng thái. Bản ghi này giữ IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND; Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Lý do: các artifact nguồn đều nêu IN_REVIEW không phải BASELINED, APPROVED, tuân thủ, sẵn sàng production hay chấp thuận người dùng.

Thành phần bàn giao	Bên gửi	Bên nhận theo thẩm quyền	Nội dung phải giữ nguyên	Kết quả hợp lệ
/03-templates/TMPL-RULE-003-rule-governance-register.md	Principal IT Business Analyst / Technical Curriculum Author	Reviewer phù hợp phạm vi rule	Status, Version, ngày, ID rule, liên kết traceability, nhãn nguồn và nhãn xác minh	Nhận để review; không suy ra approval
Quy tắc nghiệp vụ	Principal IT Business Analyst / Technical Curriculum Author	Business Owner	Nội dung mô phỏng, quyết định, ngoại lệ, tác động nghiệp vụ	Xác nhận nghiệp vụ chỉ khi Business Owner ghi nhận riêng
Nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân	Principal IT Business Analyst / Technical Curriculum Author	Legal Owner, Accounting Owner, Compliance Owner hoặc Domain Owner tương ứng	Nguồn chính thức, giới hạn sử dụng nguồn, nhãn Verification required hoặc Project assumption	Ý kiến chuyên môn có tham chiếu; không tự đổi thành nghĩa vụ ERP
Thiết kế kỹ thuật, API, bảo mật, dữ liệu triển khai	Principal IT Business Analyst / Technical Curriculum Author	Architect, Security Owner, Data Owner	Rule ID, dữ liệu logic, ràng buộc và traceability	Quyết định kỹ thuật thuộc vai trò nhận, không thuộc template
Test basis và kiểm tra chất lượng	Principal IT Business Analyst / Technical Curriculum Author	QA Reviewer	Rule ID, điều kiện, ngoại lệ, bằng chứng nguồn	Review testability; không xác nhận production quality

Mọi thay đổi phải bắt đầu bằng bản ghi thay đổi có: nguyên nhân, artifact nguồn, ID bị ảnh hưởng, nội dung trước và sau, người đề xuất, vai trò cần review, thời điểm theo Asia/Ho_Chi_Minh, và kết quả chưa phê duyệt. Không sửa im lặng rule, ID, filename, đường dẫn canonical, source classification hoặc liên kết truy vết. Điều này giữ khả năng lần ngược từ template về nguồn kiểm soát.

Loại thay đổi	Phải lan truyền đến	Ranh giới quyết định
Đổi định danh hoặc quy ước ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, mọi liên kết dùng ID đó	Registry là nguồn canonical; Owner chỉ điều phối
Đổi nội dung rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md và artifact tham chiếu rule	Business Owner quyết định nghiệp vụ; chuyên gia khác quyết định phần thuộc thẩm quyền
Đổi định nghĩa dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md và rule dùng thuộc tính đó	Data Owner và Architect xử lý tác động dữ liệu/kỹ thuật
Đổi phạm vi hoặc vị trí template	/01-curriculum/TEMPLATE_MANIFEST.md	Template manifest kiểm soát danh mục; không tạo rule mới
Đổi cấu trúc học liệu liên chương	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Curriculum Owner xử lý cấu trúc; không xác nhận vận hành Nova Foods
Đổi phân loại hoặc diễn giải nguồn	/00-research/00_SOURCE_MAP.md	Không suy diễn điều khoản chưa xác minh; Legal, Accounting hoặc Domain Owner xác minh khi cần

Không được lan truyền thay đổi bằng cách sao chép nội dung thành nguồn chân lý thứ hai. Artifact nhận phải lưu liên kết về artifact canonical thay vì viết lại rule dưới dạng khác nghĩa. Nếu thay đổi tác động từ hai thẩm quyền trở lên, hoặc có thể bị hiểu là quyết định pháp lý, kế toán, bảo mật, kiến trúc hay vận hành thật, phải dừng cập nhật nội dung kết luận và chuyển gói vấn đề cho các Owner tương ứng. Principal IT Business Analyst / Technical Curriculum Author giữ traceability và trạng thái review, không thay thế kết luận chuyên môn.

Điều kiện đóng bàn giao: gói có đủ artifact ID, filename, version, status, liên kết canonical, phạm vi mô phỏng và người nhận theo thẩm quyền. Điều kiện này chỉ xác nhận bàn giao thông tin. IN_REVIEW giữ nguyên cho đến khi artifact kiểm soát có tham chiếu baseline hoặc approval được ghi nhận minh bạch bởi vai trò có thẩm quyền.