Tmpl Ops 001 Operational Handover

Trường kiểm soát	Giá trị
Artifact ID	TMPL-OPS-001
Tên tệp được kiểm soát	/03-templates/TMPL-OPS-001--operational-handover.md
Tiêu đề artifact	Tmpl Ops 001 Operational Handover
Phân loại artifact	Controlled four-tier template cho bàn giao vận hành
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
Case study	Nova Foods Trading & Manufacturing — case study giáo dục mô phỏng
Ranh giới dữ liệu	Chỉ dùng dữ liệu tổng hợp. Tên người, đơn vị, mã giao dịch, số tiền, ngày vận hành, sự cố và bằng chứng trong template không đại diện dữ liệu thật, cấu hình ERP thật, khách hàng thật hoặc quyết định vận hành thật.
Trạng thái baseline	Chưa có baseline reference tại v0.9.0. IN_REVIEW không phải BASELINED.
Trạng thái approval	Chưa có approval reference tại v0.9.0. Metadata, version, Owner hoặc nội dung review không tạo approval ngầm định.
Giới hạn thẩm quyền Owner	Owner duy trì định danh, cấu trúc, metadata, lịch sử thay đổi và ranh giới dữ liệu mô phỏng. Owner không xác nhận bàn giao thực tế, không cấp quyền production, không xác nhận tuân thủ pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm.

Lịch sử thay đổi

Version	Ngày	Người ghi nhận	Thay đổi	Trạng thái
v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo artifact TMPL-OPS-001; thiết lập metadata quản trị, trạng thái xem xét và ranh giới Nova Foods mô phỏng.	IN_REVIEW

Quy tắc dữ liệu mô phỏng: mọi ví dụ Nova Foods trong bốn tier là dữ liệu tổng hợp phục vụ học tập. Không sao chép dữ liệu cá nhân, dữ liệu tài chính, nhật ký hệ thống, thông tin nhà cung cấp, thông tin khách hàng hoặc bằng chứng production từ tổ chức thật vào artifact này. Nếu cần đối chiếu luật, chuẩn hoặc quy trình thật, ghi nguồn và trạng thái Verification required; không biến đối chiếu đó thành xác nhận tuân thủ.

1. Tier 1 ? Metadata, Purpose, and Governance

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

Operational Handover là biên bản bàn giao vận hành có kiểm soát: ghi rõ phạm vi đã chuyển, người nhận trách nhiệm, bằng chứng đi kèm, rủi ro còn mở và đường leo thang. Mục đích là tránh giả định rằng đội nhận đã hiểu hoặc đã chấp nhận nội dung chỉ vì tài liệu tồn tại. Với Nova Foods Trading & Manufacturing, mọi ví dụ là mô phỏng giáo dục và dữ liệu tổng hợp; biên bản không là xác nhận cấu hình ERP thật, sẵn sàng production, tuân thủ pháp lý hay phê duyệt người dùng.

Nội dung	Quy định dùng
Dùng khi	Chuyển giao đầu ra BA, cấu hình mô phỏng, bộ yêu cầu, test basis, dữ liệu mẫu, hướng dẫn hỗ trợ, hoặc danh sách vấn đề từ nhóm tạo sang nhóm nhận trách nhiệm tiếp theo.
Không dùng khi	Muốn thay thế phê duyệt, baseline, nghiệm thu, quyết định go-live, sign-off pháp lý, kết luận kế toán, xác nhận an ninh, hoặc biên bản bàn giao tài sản thực tế. Các việc này cần artifact và người có thẩm quyền riêng.
Owner	Principal IT Business Analyst / Technical Curriculum Author. Owner giữ cấu trúc, ID, version, lịch sử thay đổi và traceability; không tự xác nhận nội dung nghiệp vụ hay cho phép triển khai production.
Consumers	Business Analyst, Product Owner, Project Manager, Solution Architect, QA, đội vận hành, Security, Legal/Compliance, Accounting Owner và domain owner. Mỗi người chỉ dùng phần thuộc thẩm quyền mình.
Điều kiện đầu vào	Có artifact nguồn xác định, phạm vi bàn giao, người gửi, người nhận, ngày giờ Asia/Ho_Chi_Minh, trạng thái từng hạng mục, bằng chứng truy vết và vấn đề mở. Thiếu một phần làm người nhận không kiểm được nội dung; phải ghi là ngoại lệ, không suy diễn hoàn tất.
Đầu ra hạ nguồn	Handover dùng làm đầu vào cho kế hoạch hỗ trợ, triage lỗi, test execution, release readiness, risk log, decision log và escalation package. Nó không tự tạo requirement, business rule, test result hay approval.

Quy tắc dùng. Dùng template khi trách nhiệm thay đổi chủ thể hoặc khi nhóm nhận cần bằng chứng để tiếp tục công việc. Không dùng cho trao đổi miệng ngắn, ghi chú cá nhân, hoặc thay thế source of truth. Lý do: handover kiểm soát trách nhiệm và bằng chứng tại thời điểm chuyển; requirement và quyết định vẫn phải truy về artifact canonical.

Điều kiện	Hành động bắt buộc	Cơ sở quyết định
Hạng mục có ID, nguồn, trạng thái và người nhận rõ	Ghi vào handover.	Người nhận kiểm độc lập được phạm vi và nguồn.
Hạng mục thiếu evidence, owner, hoặc tiêu chí hoàn tất	Ghi ngoại lệ và escalation.	Không đủ dữ kiện để tuyên bố bàn giao hoàn chỉnh.
Có yêu cầu pháp lý, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, hoặc bảo mật	Gắn Verification required; chuyển đúng Legal, Accounting, Compliance, Security hoặc domain owner.	Source seed chỉ cho phép dùng nguồn làm căn cứ học liệu; không cho phép tự diễn giải thành nghĩa vụ vận hành.
Có xung đột ID, filename, rule, data field, hoặc source classification	Dừng ghi nhận kết luận; đối chiếu artifact canonical.	Traceability sai làm người nhận dùng sai nguồn chân lý.

Thẩm quyền và leo thang. Owner được tạo, cập nhật, liên kết và kiểm tra đầy đủ record bàn giao. Owner không được gọi IN_REVIEW là APPROVED hoặc BASELINED, không ghi nhận user approval, không đóng rủi ro thuộc chuyên môn khác. Escalate tới Business Owner khi phạm vi hoặc ưu tiên nghiệp vụ đổi; Architect khi ảnh hưởng kiến trúc hoặc tích hợp; QA khi bằng chứng kiểm thử thiếu; Security khi có rủi ro truy cập hay dữ liệu; Legal/Compliance khi có diễn giải quy định; Accounting Owner khi có hạch toán, thuế hoặc chứng từ. Gói escalation phải giữ ID hạng mục, artifact nguồn, mô tả xung đột, tác động, bằng chứng hiện có và câu hỏi quyết định; không tự bịa quyết định Nova Foods.

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

Template này có định danh canonical TMPL-OPS-001 và tệp được kiểm soát /03-templates/TMPL-OPS-001--operational-handover.md. “Canonical” nghĩa là chuỗi ID và đường dẫn nguồn chuẩn duy nhất; bản sao, bản xuất hoặc tên dịch không được thay thế chúng. Ánh xạ này ngăn một bản handover vận hành bị liên kết nhầm với template khác, làm đứt truy vết từ nội dung học liệu đến manifest và registry.

Hạng mục ánh xạ	Giá trị canonical	Nguồn kiểm soát	Nghĩa vụ sử dụng
Template ID	TMPL-OPS-001	/01-curriculum/TEMPLATE_MANIFEST.md	Giữ nguyên ID trong metadata, liên kết truy vết, lịch sử thay đổi và QA.
Tệp template	/03-templates/TMPL-OPS-001--operational-handover.md	TEMPLATE_MANIFEST	Không đổi tên, di chuyển hoặc tạo biến thể ID khi chưa có thay đổi kiểm soát.
Danh mục template	TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Manifest là nguồn xác định template dự kiến, phạm vi và dependency cấp corpus.
Registry truy vết	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mọi ID yêu cầu, quy tắc, dữ liệu, test hoặc issue xuất hiện ở Tier 3 phải được kiểm tra đăng ký trước khi dùng.
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không tự tạo hoặc tuyên bố quy tắc Nova Foods là vận hành thực tế.
Dữ liệu logic	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Trường dữ liệu, định nghĩa và phân loại dữ liệu phải tham chiếu nguồn này khi được đăng ký.
Cấu trúc chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Chỉ liên kết chapter đã có entry canonical; không suy diễn chapter hỗ trợ khi manifest chưa ghi nhận.
Bản đồ nguồn	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Chỉ dùng nguồn đã phân loại và giữ nguyên ranh giới sử dụng của nguồn.

Liên kết chapter của TMPL-OPS-001 phải được xác định từ CHAPTER_MANIFEST, không từ tên template. Lý do: manifest là nguồn kiểm soát 26 chapter, còn tên “Operational Handover” chỉ mô tả mục tiêu học liệu. Tại v0.9.0, không ghi một chapter ID suy diễn vào template nếu entry liên kết chưa được manifest hoặc registry xác lập. Đây là kiểm soát chống traceability giả.

Nguồn chuyên môn chỉ được dùng theo phân loại trong 00_SOURCE_MAP. BABOK Guide Version 3 hỗ trợ thuật ngữ và thực hành BA; ISO/IEC/IEEE 29148:2018 hỗ trợ ngữ cảnh quản trị yêu cầu; ISTQB CTFL Syllabus v4.0.1 hỗ trợ thuật ngữ kiểm thử; BPMN 2.0.2 chỉ là nguồn chuẩn khi dùng ký pháp BPMN thực. Nguồn pháp lý Việt Nam, gồm Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm 55/2010/QH12, không tự tạo nghĩa vụ ERP trong template. Mọi diễn giải áp dụng phải gắn nhãn Verification required và cần Legal Owner, Accounting Owner hoặc domain owner xác minh.

Thay đổi ảnh hưởng TMPL-OPS-001, đường dẫn, ID, liên kết chapter, nguồn, quy tắc hoặc dữ liệu phải ghi vào lịch sử thay đổi của artifact và kiểm tra chéo với TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CHAPTER_MANIFEST cùng artifact canonical liên quan. Không sửa im lặng. IN_REVIEW tại v0.9.0 không phải baseline, approval, xác nhận người dùng, tuân thủ hay cho phép production. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, ID, tình huống và dữ liệu trong template chỉ là dữ liệu tổng hợp.

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

Dùng nguyên mẫu này để bàn giao vận hành (operational handover): chuyển thông tin, trách nhiệm, bằng chứng và điểm mở từ nhóm thay đổi sang nhóm vận hành. Thay mọi giá trị trong dấu <...> bằng dữ liệu của lần bàn giao. Không dùng mẫu này để ghi approval, baseline hoặc xác nhận production khi chưa có bằng chứng kiểm soát tương ứng.

2.1. Nhận diện bản bàn giao

Trường	Giá trị điền	Hướng dẫn điền
Handover ID	<ID bàn giao đã đăng ký trong TRACEABILITY_ID_REGISTRY>	Dùng ID canonical, không tự tạo biến thể.
Tên bàn giao	<tên thay đổi hoặc năng lực được bàn giao>	Nêu đối tượng vận hành, không dùng tên chương trình chung chung.
Artifact ID	TMPL-OPS-001	Giữ nguyên ID template này.
Tệp kiểm soát	/03-templates/TMPL-OPS-001--operational-handover.md	Giữ nguyên đường dẫn canonical.
Trạng thái hồ sơ	<DRAFT hoặc IN_REVIEW hoặc BASELINED hoặc SUPERSEDED>	Chỉ chọn trạng thái có bằng chứng quản trị.
Phiên bản	<phiên bản theo quy ước kiểm soát, ví dụ v0.9.0>	Tăng phiên bản khi nội dung bàn giao thay đổi.
Ngày cập nhật	<YYYY-MM-DD>	Ghi theo Asia/Ho_Chi_Minh.
Thời điểm bàn giao dự kiến	<YYYY-MM-DD HH:mm Asia/Ho_Chi_Minh>	Ghi thời điểm dự kiến, không suy diễn là thời điểm đã triển khai.
Locale và tiền tệ	vi-VN / Asia/Ho_Chi_Minh / VND	Giữ nguyên khi phạm vi là Nova Foods mô phỏng.
Bối cảnh tổ chức	<tên tổ chức hoặc case study>	Với Nova Foods, ghi rõ “Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp”.
Owner hồ sơ	<họ tên hoặc vai trò chịu trách nhiệm duy trì hồ sơ>	Owner quản lý hồ sơ, không tự thay thế thẩm quyền phê duyệt chuyên môn.
Phạm vi môi trường	<Development hoặc Test hoặc UAT hoặc Production hoặc môi trường khác>	Ghi môi trường thật sự được bàn giao; không suy diễn production.

2.2. Mục tiêu, phạm vi và kết quả bàn giao

Trường	Giá trị điền	Hướng dẫn điền
Mục tiêu vận hành	<mô tả kết quả vận hành cần duy trì>	Viết theo kết quả quan sát được.
Lý do bàn giao	<thay đổi, phát hành, chuyển trách nhiệm hoặc sự kiện kích hoạt>	Nêu nguyên nhân và nguồn chứng cứ.
Phạm vi bao gồm	<danh sách chức năng, quy trình, dữ liệu, giao diện hoặc báo cáo được bàn giao>	Mỗi mục xuống dòng riêng, gắn ID nếu đã có.
Ngoài phạm vi	<danh sách nội dung không được bàn giao>	Nêu rõ ranh giới để tránh vận hành suy diễn.
Kết quả mong đợi	<đầu ra, dịch vụ hoặc trạng thái hệ thống cần duy trì>	Không ghi lợi ích chưa được đo hoặc chưa xác minh.
Tiêu chí hoàn tất bàn giao	<điều kiện xác minh được để kết thúc bàn giao>	Chỉ ghi điều kiện; bằng chứng thuộc mục 2.8.
Giả định dự án	<giả định chưa được xác minh hoặc phụ thuộc vào quyết định khác>	Gắn nhãn “Project assumption”.
Điểm cần xác minh	<nội dung cần Legal Owner, Accounting Owner, Security, Architect, QA hoặc domain owner xác minh>	Gắn nhãn “Verification required” và nêu vai trò cần xác minh.

2.3. Mô tả vận hành thường ngày

Hoạt động vận hành	Tần suất	Người thực hiện	Đầu vào	Các bước thực hiện	Đầu ra mong đợi	Khi thất bại
<tên hoạt động 1>	<theo sự kiện hoặc hàng ngày hoặc hàng tuần hoặc hàng tháng>	<vai trò vận hành>	<dữ liệu, yêu cầu hoặc tín hiệu kích hoạt>	<bước 1; bước 2; bước 3>	<kết quả kiểm tra được>	<hành động an toàn đầu tiên và vai trò nhận escalation>
<tên hoạt động 2>	<tần suất>	<vai trò vận hành>	<đầu vào>	<các bước>	<đầu ra>	<xử lý khi thất bại>
<tên hoạt động 3>	<tần suất>	<vai trò vận hành>	<đầu vào>	<các bước>	<đầu ra>	<xử lý khi thất bại>

2.4. Dịch vụ, quy trình và thành phần được bàn giao

Loại thành phần	Tên hoặc ID canonical	Mục đích vận hành	Chủ sở hữu nghiệp vụ	Chủ sở hữu kỹ thuật	Phụ thuộc chính	Liên kết tài liệu
<quy trình hoặc dịch vụ hoặc báo cáo hoặc tích hợp hoặc dữ liệu>	<tên hoặc ID>	<mục đích>	<vai trò>	<vai trò>	<ID hoặc tên phụ thuộc>	<đường dẫn canonical hoặc URL nội bộ an toàn>
<quy trình hoặc dịch vụ hoặc báo cáo hoặc tích hợp hoặc dữ liệu>	<tên hoặc ID>	<mục đích>	<vai trò>	<vai trò>	<ID hoặc tên phụ thuộc>	<đường dẫn canonical hoặc URL nội bộ an toàn>
<quy trình hoặc dịch vụ hoặc báo cáo hoặc tích hợp hoặc dữ liệu>	<tên hoặc ID>	<mục đích>	<vai trò>	<vai trò>	<ID hoặc tên phụ thuộc>	<đường dẫn canonical hoặc URL nội bộ an toàn>

2.5. Liên hệ, trách nhiệm và escalation

Tình huống	Vai trò chịu trách nhiệm đầu tiên	Vai trò hỗ trợ	Kênh liên hệ	Mức ưu tiên	Điều kiện escalation	Người hoặc vai trò nhận escalation
<sự cố vận hành thường ngày>	<vai trò>	<vai trò>	<kênh không chứa bí mật>	<P1 hoặc P2 hoặc P3 hoặc P4 theo quy ước dự án>	<điều kiện kích hoạt>	<vai trò>
<nghi ngờ truy cập trái phép hoặc lộ dữ liệu>	<vai trò>	<vai trò>	<kênh xử lý sự cố bảo mật>	<mức ưu tiên>	<điều kiện kích hoạt>	<Security role>
<nghi ngờ sai lệch kế toán, thuế, hóa đơn hoặc chứng từ>	<vai trò>	<vai trò>	<kênh dự án>	<mức ưu tiên>	<điều kiện kích hoạt>	<Accounting Owner hoặc Legal Owner>
<nghi ngờ ảnh hưởng an toàn thực phẩm hoặc truy xuất nguồn gốc>	<vai trò>	<vai trò>	<kênh dự án>	<mức ưu tiên>	<điều kiện kích hoạt>	<domain owner hoặc Legal Owner>

2.6. Truy cập, cấu hình và tham chiếu bí mật

Không ghi mật khẩu, API key, access token, private key, chuỗi kết nối, dữ liệu cá nhân hoặc bí mật thương mại vào hồ sơ bàn giao.

Hạng mục truy cập hoặc cấu hình	Giá trị điền	Hướng dẫn điền
Hệ thống hoặc môi trường	<tên hệ thống và môi trường>	Không ghi URL chứa token.
Vai trò truy cập cần có	<tên role hoặc nhóm quyền>	Nêu quyền tối thiểu cần để vận hành.
Quy trình cấp hoặc thu hồi quyền	<đường dẫn ticket, quy trình IAM hoặc đầu mối có thẩm quyền>	Không ghi thông tin đăng nhập.
Tham chiếu bí mật an toàn	<secret manager path, vault reference hoặc ticket ID không lộ bí mật>	Ví dụ cấu trúc: <vault://<namespace>/<secret-name>>; không điền giá trị bí mật.
Chủ sở hữu bí mật	<vai trò sở hữu hoặc quản lý vòng đời bí mật>	Nêu vai trò, không nêu thông tin xác thực.
Ngày rà soát quyền tiếp theo	<YYYY-MM-DD>	Ghi theo Asia/Ho_Chi_Minh.
Rủi ro nếu mất quyền hoặc lộ quyền	<mô tả tác động và hành động escalation>	Chuyển Security role khi có nghi ngờ lộ lọt.

2.7. Phụ thuộc, rủi ro và ngoại lệ

ID	Loại	Mô tả	Bằng chứng hoặc lý do	Tác động vận hành	Chủ sở hữu	Hành động tiếp theo	Hạn xử lý
<ID đã đăng ký hoặc ID tham chiếu>	<Dependency hoặc Risk hoặc Issue hoặc Assumption hoặc Exception>	<mô tả cụ thể>	<liên kết artifact, ticket, log hoặc lý do>	<tác động>	<vai trò>	<hành động>	<YYYY-MM-DD hoặc điều kiện đóng>
<ID đã đăng ký hoặc ID tham chiếu>	<Dependency hoặc Risk hoặc Issue hoặc Assumption hoặc Exception>	<mô tả cụ thể>	<bằng chứng hoặc lý do>	<tác động>	<vai trò>	<hành động>	<YYYY-MM-DD hoặc điều kiện đóng>
<ID đã đăng ký hoặc ID tham chiếu>	<Dependency hoặc Risk hoặc Issue hoặc Assumption hoặc Exception>	<mô tả cụ thể>	<bằng chứng hoặc lý do>	<tác động>	<vai trò>	<hành động>	<YYYY-MM-DD hoặc điều kiện đóng>

2.8. Bằng chứng bàn giao

ID bằng chứng	Loại bằng chứng	Mô tả nội dung được chứng minh	Nguồn hoặc vị trí canonical	Người ghi nhận	Thời điểm ghi nhận	Kết quả
<ID bằng chứng>	<test result hoặc runbook hoặc monitoring record hoặc training record hoặc ticket hoặc log>	<điều kiện bàn giao mà bằng chứng hỗ trợ>	<đường dẫn hoặc URL kiểm soát>	<vai trò hoặc tên>	<YYYY-MM-DD HH:mm Asia/Ho_Chi_Minh>	<Pass hoặc Fail hoặc Pending review>
<ID bằng chứng>	<loại bằng chứng>	<nội dung được chứng minh>	<vị trí canonical>	<vai trò hoặc tên>	<YYYY-MM-DD HH:mm Asia/Ho_Chi_Minh>	<Pass hoặc Fail hoặc Pending review>
<ID bằng chứng>	<loại bằng chứng>	<nội dung được chứng minh>	<vị trí canonical>	<vai trò hoặc tên>	<YYYY-MM-DD HH:mm Asia/Ho_Chi_Minh>	<Pass hoặc Fail hoặc Pending review>

2.9. Traceability và nguồn đầu vào

Loại liên kết	ID hoặc nguồn canonical	Quan hệ với bàn giao	Lý do liên kết
Yêu cầu	<requirement ID canonical>	<được bàn giao hoặc bị ảnh hưởng hoặc ngoài phạm vi>	<bằng chứng cho phạm vi>
Quy tắc nghiệp vụ	<ID từ CANONICAL_BUSINESS_RULES hoặc Verification required>	<được áp dụng hoặc cần xác minh>	<lý do>
Dữ liệu	<ID từ CANONICAL_DATA_DICTIONARY hoặc Verification required>	<được sử dụng hoặc bị ảnh hưởng>	<lý do>
Kiểm thử	<test case ID hoặc test evidence ID>	<xác minh điều kiện vận hành>	<lý do>
Nguồn chuyên môn	<SRC-ID hoặc URL từ 00_SOURCE_MAP>	<tham chiếu thuật ngữ hoặc thực hành>	<lý do và ranh giới sử dụng>
Quyết định	<decision ID hoặc Verification required>	<ràng buộc vận hành>	<bằng chứng và chủ thể có thẩm quyền>

2.10. Lịch sử phiên bản

Phiên bản	Ngày	Người cập nhật	Thay đổi	Lý do thay đổi	Tham chiếu bằng chứng
<version>	<YYYY-MM-DD>	<vai trò hoặc tên>	<mô tả thay đổi>	<lý do>	<ID bằng chứng hoặc đường dẫn canonical>
<version>	<YYYY-MM-DD>	<vai trò hoặc tên>	<mô tả thay đổi>	<lý do>	<ID bằng chứng hoặc đường dẫn canonical>

2.11. Theo dõi review và sign-off

Sign-off là ghi nhận quyết định của người có thẩm quyền; không suy diễn từ việc tham dự họp, đọc tài liệu, cập nhật ticket hoặc điền tên vào bảng.

Vai trò review hoặc sign-off	Phạm vi xem xét	Quyết định	Bằng chứng quyết định	Ngày quyết định	Ghi chú hoặc điều kiện
<Business Owner hoặc đại diện được ủy quyền>	<phạm vi nghiệp vụ>	<Approved hoặc Rejected hoặc Conditional approval hoặc Pending review>	<approval reference hoặc decision record>	<YYYY-MM-DD hoặc chưa có>	<điều kiện hoặc lý do>
<Operations Owner>	<khả năng tiếp nhận vận hành>	<Approved hoặc Rejected hoặc Conditional approval hoặc Pending review>	<approval reference hoặc decision record>	<YYYY-MM-DD hoặc chưa có>	<điều kiện hoặc lý do>
<Technical Owner hoặc Architect>	<khả năng kỹ thuật, phụ thuộc và cấu hình>	<Approved hoặc Rejected hoặc Conditional approval hoặc Pending review>	<approval reference hoặc decision record>	<YYYY-MM-DD hoặc chưa có>	<điều kiện hoặc lý do>
<QA Owner>	<bằng chứng kiểm thử và điều kiện chất lượng>	<Approved hoặc Rejected hoặc Conditional approval hoặc Pending review>	<approval reference hoặc decision record>	<YYYY-MM-DD hoặc chưa có>	<điều kiện hoặc lý do>
<Legal Owner hoặc Accounting Owner hoặc Security role, khi áp dụng>	<phạm vi thuộc thẩm quyền chuyên môn>	<Approved hoặc Rejected hoặc Conditional approval hoặc Pending review>	<approval reference hoặc decision record>	<YYYY-MM-DD hoặc chưa có>	<điều kiện hoặc lý do>

Sổ bàn giao vận hành — mẫu trống có kiểm soát

Dùng mẫu này để chuyển trách nhiệm vận hành có truy vết. 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 không nghĩa là đã phê duyệt, baseline, tuân thủ hay sẵn sàng production.

Trường	Giá trị cần điền	Quy tắc kiểm tra
Handover ID	<mã bàn giao duy nhất, ví dụ OPS-HO-001>	Không trùng trong phạm vi artifact.
Tên bàn giao	<đối tượng, phạm vi và mốc chuyển giao>	Nêu việc chuyển giao, không nêu kết luận chưa có bằng chứng.
Trạng thái	<DRAFT hoặc IN_REVIEW hoặc BLOCKED hoặc READY_FOR_SIGN_OFF hoặc REJECTED>	Chỉ chọn một giá trị. Không dùng APPROVED nếu chưa có tham chiếu phê duyệt.
Phiên bản	<phiên bản theo dạng vX.Y.Z>	Tăng phiên bản khi nội dung kiểm soát đổi.
Ngày cập nhật	<YYYY-MM-DD>	Theo Asia/Ho_Chi_Minh.
Thời điểm bàn giao	<YYYY-MM-DDTHH:MM:SS+07:00>	Phải có múi giờ +07:00.
Đơn vị tiền tệ	<VND hoặc N/A>	Chỉ dùng VND cho giá trị tiền mô phỏng.
Môi trường	<DEV hoặc TEST hoặc UAT hoặc TRAINING hoặc PRODUCTION-NOT-APPLICABLE>	Case học liệu không xác nhận production.
Hệ thống hoặc thành phần	<tên ERP, module, giao diện hoặc quy trình>	Giữ đúng tên canonical đã đăng ký.
Owner gửi bàn giao	<vai trò, không ghi bí mật cá nhân>	Vai trò phải chịu trách nhiệm chuẩn bị gói bàn giao.
Owner nhận bàn giao	<vai trò nhận trách nhiệm vận hành>	Không suy diễn quyền phê duyệt từ vai trò.
Phạm vi	<nội dung được chuyển giao>	Bao gồm đối tượng, quy trình, dữ liệu, tích hợp bị ảnh hưởng.
Ngoài phạm vi	<nội dung không được chuyển giao>	Bắt buộc để ngăn người nhận tự suy diễn trách nhiệm.
Điều kiện kích hoạt	<sự kiện kích hoạt bàn giao>	Phải quan sát hoặc kiểm tra được.
Tiêu chí hoàn tất	<điều kiện đo được để kết thúc bàn giao>	Mỗi tiêu chí cần liên kết bằng chứng hoặc ngoại lệ.

ID quyết định	Quyết định cần ghi	Giá trị được phép	Bằng chứng và lý do	Người quyết định có thẩm quyền	Trạng thái
<DEC-HO-001>	<có chuyển trách nhiệm vận hành không>	<GO / NO_GO / CONDITIONAL_GO>	<ID bằng chứng>; <lý do liên kết bằng chứng với quyết định>	<Business Owner / Operations Owner / vai trò phù hợp>	<OPEN / CONFIRMED / ESCALATED>
<DEC-HO-002>	<có chấp nhận rủi ro còn lại không>	<ACCEPT / REJECT / DEFER>	<ID rủi ro hoặc bằng chứng>; <lý do>	<Risk Owner hoặc vai trò phù hợp>	<OPEN / CONFIRMED / ESCALATED>
<DEC-HO-003>	<có cần xác minh pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm không>	<YES / NO>	<nguồn hoặc dấu hiệu kích hoạt>; <lý do>	<Legal Owner / Accounting Owner / Security Owner / Domain Owner>	<OPEN / CONFIRMED / ESCALATED>

CONDITIONAL_GO chỉ hợp lệ khi mọi điều kiện, owner, hạn và cách kiểm chứng xuất hiện trong bảng ngoại lệ. YES ở quyết định xác minh chuyên môn bắt buộc tạo ngoại lệ ESCALATED; BA không thay chuyên gia kết luận.

ID ngoại lệ	Loại	Mô tả	Tác động	Kiểm soát tạm thời	Owner xử lý	Hạn xử lý	Trạng thái	Điều kiện đóng
<EXC-HO-001>	<DATA / PROCESS / INTEGRATION / SECURITY / LEGAL / ACCOUNTING / FOOD_SAFETY / ACCESS / OTHER>	<sai khác hoặc thiếu hụt cụ thể>	<LOW / MEDIUM / HIGH / CRITICAL>	<biện pháp giảm thiểu có thể thực hiện>	<vai trò có thẩm quyền>	<YYYY-MM-DD>	<OPEN / MITIGATED / ESCALATED / CLOSED>	<bằng chứng xác nhận điều kiện đã đạt>
<EXC-HO-002>	<DATA / PROCESS / INTEGRATION / SECURITY / LEGAL / ACCOUNTING / FOOD_SAFETY / ACCESS / OTHER>	<sai khác hoặc thiếu hụt cụ thể>	<LOW / MEDIUM / HIGH / CRITICAL>	<biện pháp giảm thiểu có thể thực hiện>	<vai trò có thẩm quyền>	<YYYY-MM-DD>	<OPEN / MITIGATED / ESCALATED / CLOSED>	<bằng chứng xác nhận điều kiện đã đạt>

Không ghi mật khẩu, token, khóa API, chuỗi kết nối, dữ liệu cá nhân hay dữ liệu sản xuất trong bằng chứng. Tham chiếu bí mật theo mẫu <SECRET-REF: kho-bí-mật/đường-dẫn; quyền-truy-cập: vai-trò; không-hiển-thị-giá-trị>.

ID bằng chứng	Loại bằng chứng	Mô tả kiểm tra được	Vị trí hoặc tham chiếu an toàn	Người tạo	Thời điểm	Kết quả	Phân loại thông tin
<EVD-HO-001>	<RUNBOOK / SCREENSHOT / LOG / TEST_RESULT / TRAINING_RECORD / CHANGE_RECORD / ACCESS_REVIEW / OTHER>	<điều bằng chứng chứng minh>	<đường dẫn kiểm soát hoặc SECRET-REF>	<vai trò hoặc mã người tạo tổng hợp>	<YYYY-MM-DDTHH:MM:SS+07:00>	<PASS / FAIL / PARTIAL / NOT_VERIFIED>	<PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED>
<EVD-HO-002>	<RUNBOOK / SCREENSHOT / LOG / TEST_RESULT / TRAINING_RECORD / CHANGE_RECORD / ACCESS_REVIEW / OTHER>	<điều bằng chứng chứng minh>	<đường dẫn kiểm soát hoặc SECRET-REF>	<vai trò hoặc mã người tạo tổng hợp>	<YYYY-MM-DDTHH:MM:SS+07:00>	<PASS / FAIL / PARTIAL / NOT_VERIFIED>	<PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED>

ID truy vết	Loại nguồn	ID hoặc đường dẫn canonical	Nội dung được liên kết	Cầu nối lý do
<TRC-HO-001>	<REQUIREMENT / BUSINESS_RULE / DATA_ITEM / TEST_CASE / RISK / CHANGE / SOURCE / TEMPLATE>	<ID canonical hoặc đường dẫn canonical>	<phần bàn giao chịu ảnh hưởng>	<nguồn yêu cầu nội dung này; bằng chứng xác nhận trạng thái hiện tại>
<TRC-HO-002>	<REQUIREMENT / BUSINESS_RULE / DATA_ITEM / TEST_CASE / RISK / CHANGE / SOURCE / TEMPLATE>	<ID canonical hoặc đường dẫn canonical>	<phần bàn giao chịu ảnh hưởng>	<nguồn yêu cầu nội dung này; bằng chứng xác nhận trạng thái hiện tại>

Nếu liên kết nguồn pháp lý, kế toán, thuế, bảo mật dữ liệu hoặc an toàn thực phẩm, ghi Verification required khi chưa có xác nhận từ owner chuyên môn. Không biến URL nguồn thành kết luận tuân thủ.

Phiên bản	Ngày	Người ghi nhận	Thay đổi	Lý do và bằng chứng	Trạng thái sau thay đổi
<vX.Y.Z>	<YYYY-MM-DD>	<vai trò>	<thay đổi cụ thể>	<ID EVD hoặc TRC>; <lý do>	<DRAFT / IN_REVIEW / BLOCKED / READY_FOR_SIGN_OFF / REJECTED>
<vX.Y.Z>	<YYYY-MM-DD>	<vai trò>	<thay đổi cụ thể>	<ID EVD hoặc TRC>; <lý do>	<DRAFT / IN_REVIEW / BLOCKED / READY_FOR_SIGN_OFF / REJECTED>

Vai trò review	Người hoặc mã định danh tổng hợp	Phạm vi review	Kết quả	Nhận xét hoặc ID ngoại lệ	Ngày review
<Operations Reviewer>	<vai trò hoặc mã>	<khả năng vận hành và runbook>	<ACCEPT / REWORK / ESCALATE>	<ID EXC hoặc lý do có bằng chứng>	<YYYY-MM-DD>
<QA Reviewer>	<vai trò hoặc mã>	<bằng chứng kiểm thử và tiêu chí hoàn tất>	<ACCEPT / REWORK / ESCALATE>	<ID EXC hoặc lý do có bằng chứng>	<YYYY-MM-DD>
<Security/Legal/Accounting/Domain Reviewer khi kích hoạt>	<vai trò hoặc mã>	<phạm vi chuyên môn được kích hoạt>	<ACCEPT / REWORK / ESCALATE / NOT_APPLICABLE>	<ID EXC hoặc lý do áp dụng>	<YYYY-MM-DD>

Vai trò sign-off	Quyết định	Điều kiện trước khi ký	Tham chiếu ghi nhận	Ngày	Chữ ký hoặc cơ chế xác thực
<Người có thẩm quyền bàn giao>	<SIGN / DECLINE>	<mọi ngoại lệ HIGH hoặc CRITICAL đã được xử lý hoặc chấp nhận bởi owner có thẩm quyền>	<ID DEC, EVD, EXC>	<YYYY-MM-DD>	<tham chiếu hệ thống ký hoặc mã xác thực>
<Người có thẩm quyền nhận bàn giao>	<SIGN / DECLINE>	<đã nhận đủ phạm vi, bằng chứng và trách nhiệm>	<ID DEC, EVD, EXC>	<YYYY-MM-DD>	<tham chiếu hệ thống ký hoặc mã xác thực>

Không điền SIGN khi còn EXC trạng thái OPEN hoặc ESCALATED mà chưa có quyết định chấp nhận rủi ro có thẩm quyền. Trường sign-off trống chỉ chứng minh chưa ghi nhận ký xác nhận; không chứng minh từ chối hay phê duyệt.

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

Tier 2 là mẫu trống để sao chép. Mỗi <...> là chỗ thay bằng dữ liệu cụ thể trước khi chuyển sang Tier 3. Không giữ placeholder trong bản case hoàn chỉnh. Nova Foods Trading & Manufacturing là case mô phỏng; 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 hoặc sẵn sàng production.

Nhóm trường	Placeholder bắt buộc	Hướng dẫn điền	Giá trị hợp lệ	Quy tắc kiểm tra
Định danh handover	<Mã-handover-duy-nhất>	Dùng ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Chuỗi ID canonical đã đăng ký.	Không tự tạo biến thể ID, không dùng lại ID của handover khác.
Tên bàn giao	<Tên-bàn-giao-mô-tả-rõ-phạm-vi>	Nêu đối tượng, phạm vi và mục đích tiếp nhận.	Văn bản tiếng Việt rõ nghĩa.	Không dùng tên mơ hồ như “Bàn giao hệ thống”.
Trạng thái	<Trạng-thái>	Ghi trạng thái kiểm soát hiện tại.	DRAFT, IN_REVIEW, BLOCKED, BASELINED, RETIRED.	Chỉ ghi BASELINED khi có baseline reference; chỉ ghi BLOCKED khi nêu blocker và owner xử lý.
Phiên bản	<Phiên-bản-semver-hoặc-quy-ước-được-kiểm-soát>	Ghi version của bản handover.	Ví dụ v0.9.0.	Version phải khớp lịch sử thay đổi; không sửa nội dung kiểm soát mà không tăng version phù hợp.
Thời điểm	<YYYY-MM-DD HH:mm Asia/Ho_Chi_Minh>	Ghi ngày giờ theo múi giờ corpus.	ISO date, Asia/Ho_Chi_Minh.	Không dùng giờ địa phương không nêu múi giờ.
Phạm vi	<Phạm-vi-được-bàn-giao>	Nêu phần được bàn giao và phần không thuộc bàn giao.	Danh sách cụ thể.	Mỗi mục phải kiểm chứng được bằng artifact, URL nội bộ hoặc evidence ID.
Môi trường	<Môi-trường>	Nêu bối cảnh kỹ thuật của nội dung bàn giao.	TRAINING, TEST, UAT, PRODUCTION khi có xác nhận kiểm soát.	Case mô phỏng mặc định không được suy diễn thành PRODUCTION.
Dữ liệu	<Phân-loại-dữ-liệu>	Nêu dữ liệu tổng hợp, dữ liệu cá nhân, bí mật kỹ thuật nếu có.	SYNTHETIC, PERSONAL_DATA, CONFIDENTIAL, SECRET_REFERENCE.	Nova Foods mô phỏng dùng SYNTHETIC trừ khi trường khác được owner có thẩm quyền xác nhận.
Người bàn giao	<Họ-tên-hoặc-vai-trò-người-bàn-giao>	Ghi vai trò chịu trách nhiệm cung cấp thông tin.	Vai trò hoặc định danh người được phép ghi nhận.	Vai trò ghi nhận không tự tạo approval.
Người tiếp nhận	<Họ-tên-hoặc-vai-trò-người-tiếp-nhận>	Ghi vai trò cần dùng nội dung bàn giao.	Vai trò nghiệp vụ, kỹ thuật, QA, vận hành phù hợp.	Không suy diễn người tiếp nhận đã đọc, đồng ý hoặc phê duyệt.
Chủ sở hữu quyết định	<Vai-trò-có-thẩm-quyền>	Ghi role quyết định cho từng điểm cần quyết định.	Business Owner, Architect, Security Owner, Legal Owner, Accounting Owner, QA Owner.	Không gán quyết định pháp lý, kế toán, bảo mật cho BA nếu chưa có thẩm quyền.

Trường quyết định hoặc ngoại lệ	Placeholder	Cách điền	Điều kiện áp dụng	Kiểm tra bắt buộc
Quyết định cần chốt	<Mô-tả-quyết-định>	Nêu câu hỏi quyết định, không viết kết luận giả định.	Có lựa chọn ảnh hưởng phạm vi, rủi ro, dữ liệu hoặc vận hành.	Phải có <Owner-quyết-định>, <Hạn-chót>, <Bằng-chứng-đầu-vào>.
Lựa chọn đề xuất	<Lựa-chọn-đề-xuất>	Nêu phương án và lý do.	Có từ hai phương án khả thi.	Lý do phải nối với evidence cụ thể; không dùng “theo yêu cầu” nếu không có nguồn.
Ngoại lệ	<Mã-ngoại-lệ>	Ghi tình huống lệch khỏi luồng chuẩn.	Có dữ liệu lỗi, thiếu quyền, tích hợp lỗi, hoặc rule chưa xác minh.	Phải nêu trigger, tác động, xử lý tạm thời, owner, điều kiện đóng.
Rủi ro	<Mã-rủi-ro>	Nêu nguyên nhân, hậu quả, kiểm soát.	Có khả năng gây mất dữ liệu, sai số, lộ dữ liệu hoặc gián đoạn.	Không ghi mức rủi ro mà không có tiêu chí chấm đã nêu.
Điểm mở	<Mã-open-item>	Ghi việc chưa giải quyết.	Thiếu evidence, thiếu quyết định, hoặc cần xác minh chuyên môn.	Không thay bằng TBD; phải có owner, ngày rà soát, tiêu chí đóng.
Escalation	<Vai-trò-nhận-escalation>	Chuyển vấn đề vượt thẩm quyền.	Liên quan đồng thời pháp lý, kế toán, bảo mật, kiến trúc hoặc vận hành thực.	Giữ nguyên evidence; không tự kết luận thay owner chuyên môn.

Loại evidence và traceability	Placeholder	Giá trị được chấp nhận	Quy tắc kiểm tra
Artifact nguồn	<Đường-dẫn-canonical>	Đường dẫn corpus, ví dụ /01-curriculum/CANONICAL_BUSINESS_RULES.md.	Phải là đường dẫn canonical, không phải tên tệp rút gọn.
ID truy vết	<ID-canonical>	ID đã đăng ký trong registry.	Không dùng ID tự đặt, ID gần giống, hoặc ID không có ngữ cảnh.
Phân loại nguồn	<Primary-source|Project-assumption|Verification-required>	Ghi ranh giới nguồn của từng claim.	Claim pháp lý, kế toán, thuế, an toàn thực phẩm, quyền riêng tư chưa xác minh trực tiếp phải là Verification-required hoặc Project-assumption.
Bằng chứng kiểm tra	<Evidence-ID-hoặc-vị-trí-kiểm-chứng>	Nêu test result, log đã che dữ liệu, ảnh chụp được kiểm soát, hoặc liên kết artifact.	Không dùng evidence chứa secret hoặc dữ liệu cá nhân không cần thiết.
Liên kết requirement/rule/data	<Requirement-ID>, <Rule-ID>, <Data-ID>	Liên kết đúng artifact nguồn.	Mỗi liên kết phải truy ngược được; không biến suy luận thành rule canonical.

Mẫu tham chiếu bí mật an toàn: ghi <Secret-reference: vault://<vault-name>/<secret-path>#<version>>, <Secret-owner-role>, <Access-request-channel> và <Rotation-or-review-date>. Không ghi mật khẩu, API key, token, private key, chuỗi kết nối, cookie phiên, mã OTP, dữ liệu định danh cá nhân hoặc ảnh chụp chứa các giá trị này. Nếu chưa có kho bí mật được xác nhận, ghi <Secret-reference: not-provided> và mở <Mã-open-item>; không thay bằng secret tạm.

Phần có điều kiện: chỉ điền bảng tích hợp khi <Có-tích-hợp: Có>; nêu hệ thống nguồn/đích, giao thức, dữ liệu trao đổi, lỗi và owner. Chỉ điền bảng dữ liệu cá nhân khi <Có-dữ-liệu-cá-nhân: Có>; gắn Verification-required cho yêu cầu pháp lý và chuyển Legal Owner hoặc Privacy Owner xác minh. Chỉ điền bảng đối soát tài chính khi <Có-tác-động-kế-toán-hoặc-thuế: Có>; Accounting Owner xác nhận diễn giải. Nếu giá trị là Không, ghi lý do dựa trên evidence, không để trống trường điều kiện.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Toàn bộ tên người, giao dịch, mã và giá trị dưới đây là dữ liệu tổng hợp; không mô tả doanh nghiệp, ERP hay quyết định vận hành thực.

Trường bàn giao	Giá trị hoàn chỉnh
Mã artifact	TMPL-OPS-001
Tên bản ghi bàn giao	Bàn giao vận hành xử lý lệch số lượng nhận kho cho đơn mua PO-NF-2026-0817
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày lập	2026-08-07
Múi giờ và locale	Asia/Ho_Chi_Minh; vi-VN; tiền tệ VND
Phạm vi hệ thống	NovaERP Procurement, Inventory và Accounts Payable, gọi tắt là AP, phân hệ công nợ phải trả
Người bàn giao	Lê Minh Khoa, BA mô phỏng
Nhóm nhận bàn giao	Nguyễn Thảo Vy, Inventory Operations Lead mô phỏng; Trần Quốc Huy, Application Support Analyst mô phỏng
Sự kiện vận hành	Ngày 2026-08-06 14:18, kho WH-HCM-RAW-01 nhận bột cacao từ nhà cung cấp mô phỏng SUP-NF-0042. Phiếu nhận hàng GRN-NF-2026-0817-01 ghi 480 kg, trong khi đơn mua ghi 500 kg.
Giá trị liên quan	Đơn giá mô phỏng 186.000 VND/kg; giá trị đơn mua 93.000.000 VND; giá trị nhận thực tế 89.280.000 VND; chênh lệch 3.720.000 VND, chưa gồm thuế.
Mức ưu tiên	P2; không dừng sản xuất tức thời, nhưng chặn đối soát hóa đơn vượt số lượng nhận.
Trạng thái nghiệp vụ hiện tại	GRN-NF-2026-0817-01 ở QUARANTINED_QUANTITY_VARIANCE; tồn kho khả dụng chưa tăng; hóa đơn nhà cung cấp chưa được ghép vào AP.
Kết quả bàn giao cần đạt	Nhóm vận hành xử lý chênh lệch, ghi quyết định có thẩm quyền, cập nhật trạng thái phiếu nhận và chỉ cho phép AP đối soát theo số lượng đã được xác nhận.

Bối cảnh, sự thật và nhu cầu

Sự thật quan sát được: nhân viên nhận hàng Phạm Gia Bảo đã quét mã lô LOT-COCOA-260806-A, cân thực tế 480 kg và xác nhận 24 bao, mỗi bao 20 kg. Đơn mua PO-NF-2026-0817 yêu cầu 25 bao. Chứng từ giao hàng mô phỏng DN-SUP0042-260806-19 cũng ghi 25 bao. Vì ba nguồn số lượng không khớp, hệ thống không được tự chọn 500 kg hoặc 480 kg làm số liệu thanh toán.

Hành vi hiện tại: NovaERP tạo phiếu nhận với số lượng cân thực tế 480 kg, tự gắn trạng thái cách ly số lượng và phát sự kiện inventory.receipt.quantity_variance.detected. AP chưa nhận bản ghi đủ điều kiện đối soát ba bên, tức so sánh đơn mua, phiếu nhận và hóa đơn. Đây là kiểm soát vận hành mô phỏng, không phải kết luận kế toán hay thuế.

Nhu cầu nền: kho cần biết có được đưa 480 kg vào tồn khả dụng hay không; mua hàng cần quyết định giao bù hoặc giảm giá trị đơn mua; AP cần tránh thanh toán 500 kg khi chỉ có 480 kg được xác nhận. Nếu xử lý sai, tồn kho, công nợ và chi phí nguyên liệu mô phỏng lệch 3.720.000 VND, đồng thời mất khả năng giải thích chênh lệch theo lô hàng.

Dữ liệu giao dịch và phân loại nguồn

Đối tượng	Mã	Giá trị	Phân loại nguồn	Cách dùng
Đơn mua	PO-NF-2026-0817	500 kg, 93.000.000 VND	Synthetic-operational-record	Nguồn yêu cầu mua đã phát hành trong case mô phỏng
Phiếu nhận hàng	GRN-NF-2026-0817-01	480 kg, 89.280.000 VND	Synthetic-operational-record	Nguồn số lượng cân thực tế
Chứng từ giao hàng	DN-SUP0042-260806-19	500 kg	Synthetic-external-document	Chứng từ do nhà cung cấp mô phỏng phát hành
Lô nguyên liệu	LOT-COCOA-260806-A	480 kg cách ly	Synthetic-operational-record	Khóa truy xuất nội bộ cho số hàng đã nhận
Sự kiện hệ thống	EVT-NF-2026-0806-014	quantityVarianceKg: 20	Synthetic-system-event	Bằng ghi nhận hệ thống phát hiện lệch
Quy tắc nghiệp vụ tham chiếu	CANONICAL_BUSINESS_RULES	Không gán quy tắc cụ thể	Controlled-corpus-source	Ranh giới nguồn canonical; case không tự tạo quy tắc canonical
Từ điển dữ liệu tham chiếu	CANONICAL_DATA_DICTIONARY	Không gán trường cụ thể	Controlled-corpus-source	Ranh giới định nghĩa dữ liệu logic
Registry định danh tham chiếu	TRACEABILITY_ID_REGISTRY	Không gán ID mới	Controlled-corpus-source	Ranh giới quản trị định danh corpus

Phương án xử lý và quyết định cần có

Phương án	Điều kiện chọn	Tác động	Không chọn tự động vì
A. Nhận 480 kg, chờ giao bù 20 kg	Nhà cung cấp xác nhận giao bù trước 2026-08-10 17:00	Tồn kho chỉ tăng sau kiểm tra chất lượng; PO giữ mở 20 kg	Cần xác nhận thương mại từ Procurement Lead
B. Nhận 480 kg, giảm số lượng PO còn 480 kg	Nhà cung cấp xác nhận không giao bù	Giá trị PO giảm còn 89.280.000 VND; AP chỉ đối soát 480 kg	Thay đổi cam kết mua, cần Procurement Lead quyết định
C. Từ chối toàn bộ 480 kg	Quality Control xác nhận lô không đạt	Không tăng tồn kho; mở quy trình trả hàng mô phỏng	Không có bằng chứng chất lượng không đạt trong bản ghi hiện tại

Khuyến nghị bàn giao: giữ phương án A ở trạng thái chờ xác nhận đến hạn 2026-08-10 17:00. Lý do: chứng từ giao hàng ghi 500 kg, còn bằng chứng cân ghi 480 kg; giao bù giải quyết thiếu 20 kg mà chưa sửa giá trị cam kết mua. Procurement Lead mô phỏng Nguyễn Hà Linh có thẩm quyền quyết định A hoặc B. Quality Control Lead mô phỏng Đỗ Anh Tuấn có thẩm quyền quyết định C khi có kết quả kiểm tra chất lượng. BA và Application Support chỉ ghi nhận, cấu hình trạng thái và bảo toàn dữ liệu; không quyết định thương mại hay chất lượng.

Quy tắc vận hành áp dụng cho case

Mã	Quy tắc đầy đủ	Trạng thái áp dụng
OPS-RULE-NF-001	Khi số lượng trên phiếu nhận khác số lượng đơn mua, phiếu nhận phải ở QUARANTINED_QUANTITY_VARIANCE cho đến khi người có thẩm quyền chọn giao bù, giảm PO hoặc từ chối hàng.	Quy tắc case mô phỏng
OPS-RULE-NF-002	AP không được tạo đối soát thanh toán cho số lượng lớn hơn số lượng nhận đã xác nhận cuối cùng.	Quy tắc case mô phỏng
OPS-RULE-NF-003	Mọi thay đổi số lượng phải giữ liên kết với PO-NF-2026-0817, GRN-NF-2026-0817-01 và LOT-COCOA-260806-A.	Quy tắc case mô phỏng
OPS-RULE-NF-004	Không diễn giải case này thành nghĩa vụ pháp lý, thuế, kế toán hoặc an toàn thực phẩm. Các diễn giải đó cần Legal Owner, Accounting Owner hoặc domain owner xác minh.	Verification-required

Payload bàn giao mô phỏng

{
  "handoverId": "OH-NF-2026-0807-001",
  "purchaseOrderId": "PO-NF-2026-0817",
  "goodsReceiptId": "GRN-NF-2026-0817-01",
  "lotId": "LOT-COCOA-260806-A",
  "orderedQuantityKg": 500,
  "receivedQuantityKg": 480,
  "varianceQuantityKg": 20,
  "unitPriceVnd": 186000,
  "varianceValueVnd": 3720000,
  "currentState": "QUARANTINED_QUANTITY_VARIANCE",
  "recommendedOption": "A_RECEIVE_480_AND_WAIT_FOR_20_KG_REPLACEMENT",
  "decisionOwnerRole": "Procurement Lead",
  "decisionDueAt": "2026-08-10T17:00:00+07:00",
  "caseClassification": "synthetic-educational-data"
}

Hồ sơ bàn giao vận hành đã điền — NF-OH-20260807-01

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ người, giao dịch, giá trị và dữ liệu dưới đây là dữ liệu tổng hợp. Hồ sơ bàn giao này ghi nhận chuyển giao vận hành chức năng phân bổ lô xuất kho từ đội Dự án ERP sang đội Vận hành Kho thành phẩm.

Trường lõi	Giá trị đã điền
Mã hồ sơ	NF-OH-20260807-01
Artifact	TMPL-OPS-001
Tên tệp	/03-templates/TMPL-OPS-001--operational-handover.md
Trạng thái hồ sơ	IN_REVIEW
Phiên bản	v0.9.0
Ngày lập	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN, VND
Phạm vi bàn giao	Phân bổ lô theo nguyên tắc FEFO cho đơn bán thành phẩm đóng gói
Đơn vị nhận vận hành	Kho thành phẩm Nova Foods
Vai trò bàn giao	ERP Functional Analyst, mô phỏng
Vai trò nhận bàn giao	Warehouse Operations Lead, mô phỏng
Quyết định cần ghi nhận	Dùng phân bổ lô tự động FEFO, có chặn xuất khi lô hết hạn hoặc bị giữ chất lượng
Thẩm quyền quyết định	Business Owner mô phỏng: Head of Supply Chain
Phân loại nguồn	Project assumption, dữ liệu mô phỏng; không phải cấu hình ERP production
Giá trị giao dịch minh họa	18.750.000 VND, chưa bao gồm thuế
Cảnh báo pháp lý	Verification required với diễn giải kế toán, thuế, an toàn thực phẩm và lưu vết lô trước dùng thực tế

Sự kiện vận hành: đơn bán SO-NF-260807-014 yêu cầu xuất 250 thùng sản phẩm TP-NF-CHILI-250G, đơn giá 75.000 VND/thùng, tổng tiền 18.750.000 VND. Kho WH-HCM-FG-01 có ba lô khả dụng. FEFO, viết tắt của First Expired, First Out, nghĩa là ưu tiên xuất lô có ngày hết hạn gần nhất còn hợp lệ. Nhu cầu nằm ở giảm nguy cơ tồn lô gần hết hạn. Bằng chứng suy luận: nếu nhân viên chọn lô theo vị trí kệ, lô hết hạn sớm có thể bị bỏ lại dù còn bán được.

Lô	Số lượng khả dụng	Ngày sản xuất	Ngày hết hạn	Trạng thái chất lượng	Kết quả phân bổ
LOT-NF-CH250-260401-A	120 thùng	2026-04-01	2026-10-01	RELEASED	Xuất 120 thùng
LOT-NF-CH250-260415-B	180 thùng	2026-04-15	2026-10-15	RELEASED	Xuất 130 thùng
LOT-NF-CH250-260501-C	90 thùng	2026-05-01	2026-11-01	QUALITY_HOLD	Không xuất

Quy tắc vận hành đã điền

Mã quy tắc cục bộ	Điều kiện	Hệ thống phải làm	Lý do và hậu quả nếu sai
NF-OH-R01	Lô có qualityStatus = RELEASED, expiryDate > 2026-08-07 và tồn khả dụng lớn hơn 0	Đưa lô vào danh sách phân bổ	Chỉ xuất hàng được phép bán; xuất lô bị giữ làm sai kiểm soát chất lượng.
NF-OH-R02	Có nhiều lô hợp lệ	Sắp xếp tăng dần theo expiryDate, rồi theo lotId	FEFO cần thứ tự xác định; không có quy tắc phụ làm kết quả phân bổ thay đổi giữa các lần xử lý.
NF-OH-R03	Số lượng yêu cầu 250 thùng	Phân bổ 120 thùng từ lô A, 130 thùng từ lô B	Tổng phân bổ phải bằng số lượng yêu cầu; thiếu hoặc vượt làm sai tồn kho và giao hàng.
NF-OH-R04	Lô QUALITY_HOLD	Không phân bổ, hiển thị lý do Lô đang giữ chất lượng	Không cho phép người vận hành bỏ qua trạng thái chất lượng.
NF-OH-R05	Tổng tồn hợp lệ nhỏ hơn số lượng yêu cầu	Chuyển đơn sang ALLOCATION_EXCEPTION; không tự thay lô hay giảm số lượng	Tự xử lý làm mất quyết định nghiệp vụ về giao thiếu hoặc điều phối kho.

Phương án và quyết định: phương án 1 cho nhân viên tự chọn lô; phương án 2 tự động FEFO nhưng cho phép ghi đè không kiểm soát; phương án 3 tự động FEFO và chỉ cho phép ngoại lệ qua trạng thái xử lý. Tiêu chí gồm giảm rủi ro hết hạn, kết quả lặp lại được, không xuất lô QUALITY_HOLD, và không tự đổi cam kết đơn hàng. Khuyến nghị chọn phương án 3. Quyết định thuộc Head of Supply Chain mô phỏng; hồ sơ vẫn IN_REVIEW, không ghi nhận phê duyệt.

Trạng thái giao dịch: DRAFT khi đơn mới tạo; ALLOCATED khi đủ 250 thùng được gán lô; PICK_CONFIRMED khi kho xác nhận lấy đủ hàng; SHIPPED khi xác nhận xuất kho; ALLOCATION_EXCEPTION khi không đủ lô hợp lệ. Giao dịch mẫu chuyển từ DRAFT sang ALLOCATED; chưa có xác nhận lấy hàng hay xuất kho.

{
  "allocationId": "ALC-NF-260807-014",
  "salesOrderId": "SO-NF-260807-014",
  "warehouseId": "WH-HCM-FG-01",
  "productId": "TP-NF-CHILI-250G",
  "requestedQuantity": 250,
  "uom": "THUNG",
  "currency": "VND",
  "unitPrice": 75000,
  "lineAmount": 18750000,
  "allocationMethod": "FEFO",
  "allocationStatus": "ALLOCATED",
  "allocatedLots": [
    {
      "lotId": "LOT-NF-CH250-260401-A",
      "quantity": 120,
      "qualityStatus": "RELEASED",
      "expiryDate": "2026-10-01"
    },
    {
      "lotId": "LOT-NF-CH250-260415-B",
      "quantity": 130,
      "qualityStatus": "RELEASED",
      "expiryDate": "2026-10-15"
    }
  ],
  "excludedLots": [
    {
      "lotId": "LOT-NF-CH250-260501-C",
      "quantity": 90,
      "qualityStatus": "QUALITY_HOLD",
      "exclusionReason": "Lô đang giữ chất lượng"
    }
  ],
  "recordedAt": "2026-08-07T14:30:00+07:00",
  "dataClassification": "SYNTHETIC_PROJECT_ASSUMPTION"
}

Hồ sơ quyết định bàn giao vận hành — Nova Foods mô phỏng

Nova Foods Trading & Manufacturing là case học liệu mô phỏng; toàn bộ người, giao dịch và số tiền dưới đây là dữ liệu tổng hợp. Bàn giao vận hành (operational handover) là chuyển trách nhiệm theo dõi, xử lý và phản hồi từ nhóm triển khai sang nhóm vận hành, không phải phê duyệt đưa ERP vào production.

Trường	Giá trị hoàn chỉnh
Mã hồ sơ bàn giao mô phỏng	OH-NF-20260807-001
Artifact	TMPL-OPS-001
Tệp kiểm soát	/03-templates/TMPL-OPS-001--operational-handover.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Thời điểm ghi nhận	2026-08-07 15:30:00 Asia/Ho_Chi_Minh
Phạm vi	Luồng tạo đơn bán hàng, giữ hàng tồn kho và xuất phiếu giao hàng cho kênh đại lý
Đơn vị mô phỏng	Nova Foods Trading & Manufacturing
Giao dịch tham chiếu mô phỏng	SO-NF-20260807-0142, tổng giá trị hàng 18.750.000 VND
Người lập hồ sơ mô phỏng	Lê Minh Anh — Business Analyst
Nhóm nhận bàn giao mô phỏng	ERP Operations L1
Phân loại dữ liệu	Synthetic educational data; không chứa dữ liệu cá nhân thật, hóa đơn thật hoặc dữ liệu production

Nội dung	Ghi nhận hoàn chỉnh	Phân loại nguồn
Sự kiện	Đại lý mô phỏng DL-NF-031 tạo đơn SO-NF-20260807-0142 lúc 2026-08-07 09:12:18. Đơn gồm 500 thùng NF-NUOCMAM-500ML, đơn giá 37.500 VND mỗi thùng.	Dữ liệu giao dịch mô phỏng
Hành vi hiện tại	ERP giảm tồn khả dụng ngay khi người dùng lưu đơn trạng thái Confirmed; hệ thống chưa tự trả tồn khi phiếu giao hàng bị hủy.	Quan sát cấu hình mô phỏng
Bằng chứng suy luận	Đơn giữ 500 thùng tại kho WH-HCM-01. Phiếu DN-NF-20260807-0088 bị hủy lúc 11:06:43, nhưng tồn khả dụng vẫn thấp hơn tồn vật lý 500 thùng. Vì lượng giữ không được giải phóng, đơn sau có thể bị từ chối sai dù kho còn hàng.	Dữ liệu giao dịch mô phỏng
Nhu cầu nền tảng	Vận hành cần biết ai xử lý, khi nào xử lý và trạng thái nào được phép giải phóng tồn. Không có quy tắc rõ, L1 có thể sửa tay tồn kho, làm mất dấu vết giữa đơn bán, phiếu giao và tồn kho.	Suy luận từ hành vi mô phỏng
Hậu quả nếu sai	Không giải phóng tồn làm mất cơ hội bán 500 thùng, tương đương 18.750.000 VND giá trị hàng theo đơn mô phỏng. Giải phóng khi phiếu chưa hủy có thể gây bán vượt tồn và giao thiếu hàng.	Tính toán từ dữ liệu mô phỏng

Phương án	Mô tả	Điểm mạnh	Rủi ro hoặc giới hạn
A	L1 điều chỉnh tồn kho thủ công sau mỗi phiếu giao bị hủy.	Xử lý nhanh từng sự cố.	Không nối được với giao dịch gốc; dễ điều chỉnh nhầm số lượng.
B	ERP tự giải phóng lượng giữ khi phiếu giao chuyển Cancelled; lưu mã đơn, mã phiếu, người thực hiện và thời điểm.	Nhất quán, có thể kiểm tra lại, giảm thao tác L1.	Cần kiểm thử trạng thái trước khi dùng ngoài case học liệu.
C	Giữ tồn đến cuối ngày, vận hành chạy đối soát hàng ngày.	Không cần thay đổi luồng ngay.	Tồn khả dụng sai trong ngày; đơn mới có thể bị chặn sai.

Tiêu chí quyết định	Trọng số	A	B	C	Lý do chấm
Đúng tồn khả dụng theo thời điểm	40%	2	5	2	B phản ứng cùng sự kiện hủy phiếu.
Dấu vết kiểm tra giao dịch	30%	1	5	3	B lưu liên kết đơn và phiếu giao.
Rủi ro thao tác thủ công	20%	1	5	3	B không yêu cầu sửa tồn tay.
Khả năng xử lý L1	10%	3	4	4	B cần cảnh báo rõ; C cần đối soát.
Tổng điểm có trọng số, thang 5	100%	1,7	4,9	2,5	B cao nhất.

Khuyến nghị: chọn phương án B cho phạm vi mô phỏng. Quy tắc đề xuất: khi DN-NF-20260807-0088 chuyển trạng thái Cancelled, ERP giải phóng đúng 500 thùng đã giữ cho SO-NF-20260807-0142; không tạo điều chỉnh tồn kho thủ công. Hệ thống phải ghi cancelled_at, cancelled_by, sales_order_id, delivery_note_id và released_quantity.

Thẩm quyền quyết định: Business Owner mô phỏng quyết định quy tắc vận hành; Solution Architect mô phỏng xác nhận cách đổi trạng thái; QA Owner mô phỏng xác nhận kiểm thử; Accounting Owner và Legal Owner chỉ tham gia nếu thay đổi chạm dữ liệu kế toán hoặc nghĩa vụ pháp lý. Principal IT Business Analyst / Technical Curriculum Author ghi nhận phân tích, không có quyền phê duyệt. Tại IN_REVIEW, khuyến nghị này chưa là baseline, chưa được phê duyệt và không được dùng cho production.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Tình huống giữ nguyên: đơn bán SO-NF-20260807-0142 đang giữ 500 thùng hàng; phiếu giao DN-NF-20260807-0088 bị hủy. “Negative path” là đường xử lý khi điều kiện mong đợi không đúng, nhằm ngăn giải phóng tồn sai hoặc ghi nhận giao dịch trùng.

ID ngoại lệ	Điều kiện phát hiện	Xử lý bắt buộc trong case	Kết quả mong đợi	Lý do và bằng chứng suy luận
EXC-NF-001	DN-NF-20260807-0088 không ở trạng thái Cancelled	Không giải phóng 500 thùng; trả trạng thái từ chối xử lý.	Tồn giữ nguyên.	Quy tắc đề xuất chỉ kích hoạt khi phiếu đã hủy; giải phóng trước khi hủy tạo rủi ro bán vượt tồn.
EXC-NF-002	Phiếu giao không liên kết SO-NF-20260807-0142	Chặn xử lý; ghi nhận lỗi liên kết.	Không thay đổi tồn của bất kỳ đơn nào.	Không có khóa liên kết thì không thể chứng minh 500 thùng thuộc đơn nào.
EXC-NF-003	released_quantity khác 500	Chặn cập nhật; chuyển L1 kiểm tra.	Không có điều chỉnh tồn.	Số lượng giải phóng phải khớp số lượng đã giữ trong tình huống mô phỏng.
EXC-NF-004	Sự kiện hủy được nhận lần hai cho cùng DN-NF-20260807-0088	Không giải phóng lần hai; ghi nhận sự kiện trùng.	Tổng lượng giải phóng vẫn là 500 thùng.	Hủy phiếu là sự kiện có thể gửi lại; xử lý lặp gây tăng tồn khả dụng sai.
EXC-NF-005	Không ghi được cancelled_at hoặc cancelled_by	Chặn hoàn tất hủy; chuyển lỗi kỹ thuật.	Không có kết quả “đã xử lý”.	Hai trường là bằng chứng thời điểm và người thực hiện; thiếu chúng làm mất khả năng kiểm tra.
EXC-NF-006	Có phát sinh dữ liệu kế toán, hóa đơn hoặc yêu cầu pháp lý ngoài phạm vi tình huống	Không tự suy diễn bút toán, thuế, hóa đơn hay nghĩa vụ tuân thủ.	Escalation đến chủ sở hữu thẩm quyền.	Nguồn pháp lý và kế toán chỉ cho phép dùng trong ranh giới xác minh; case chưa có baseline hay kết luận chuyên môn.

Bằng chứng tham chiếu

ID 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	Cách dùng
EVD-NF-001	Bản ghi trạng thái: DN-NF-20260807-0088, trạng thái trước hủy InDelivery, trạng thái sau hủy Cancelled, lượng giữ 500 thùng.	Case record trong /03-templates/TMPL-OPS-001--operational-handover.md	Dữ liệu mô phỏng nội bộ	Chứng minh điều kiện đầu vào của xử lý hủy.
EVD-NF-002	Bản ghi liên kết: sales_order_id=SO-NF-20260807-0142, delivery_note_id=DN-NF-20260807-0088, released_quantity=500.	Case record trong /03-templates/TMPL-OPS-001--operational-handover.md	Dữ liệu mô phỏng nội bộ	Đối chiếu đơn, phiếu giao và lượng giải phóng.
EVD-NF-003	Phân tích phương án B: giải phóng tồn cùng sự kiện hủy, lưu liên kết đơn và phiếu giao, không sửa tồn thủ công.	Section 3 của cùng tệp	Phân tích BA mô phỏng	Giải thích vì sao xử lý tự động được ưu tiên trong case.
EVD-NF-004	Thuật ngữ kiểm thử black-box và negative testing.	ISTQB CTFL Syllabus v4.0.1, https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Nguồn chuẩn kiểm thử	Dùng cho cách gọi và thiết kế kiểm thử; không xác nhận cấu hình ERP.
EVD-NF-005	Ranh giới về luật kế toán, hóa đơn, dữ liệu cá nhân và an toàn thực phẩm.	/00-research/00_SOURCE_MAP.md	Source map có kiểm soát	Xác định nội dung nào phải được chuyên gia xác minh trước khi dùng ngoài học liệu.

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

ID	Nội dung	Cầu nối suy luận	Trạng thái	Owner xác minh
ASM-NF-001	500 thùng là toàn bộ lượng đã giữ cho SO-NF-20260807-0142 qua DN-NF-20260807-0088.	Case record nêu đúng 500 thùng được giữ và cần giải phóng khi phiếu hủy.	Giả định dự án mô phỏng	Business Owner mô phỏng
ASM-NF-002	Hủy phiếu giao chưa tạo chứng từ kế toán hoặc hóa đơn trong phạm vi case.	Case chỉ mô tả giữ và giải phóng tồn; không có dữ liệu chứng từ.	Giả định dự án mô phỏng	Accounting Owner mô phỏng
VR-NF-001	Cần xác minh mô hình trạng thái hợp lệ của phiếu giao trước khi cấu hình ERP.	Case dùng Cancelled, nhưng chưa có baseline trạng thái hay đặc tả triển khai.	Verification required	Solution Architect mô phỏng
VR-NF-002	Cần xác minh quyền hủy phiếu và quyền xem dữ liệu người thao tác.	Trường cancelled_by tạo dấu vết người dùng; quyền truy cập là quyết định bảo mật.	Verification required	Security Owner mô phỏng
VR-NF-003	Cần xác minh tác động hóa đơn, kế toán, thuế và lưu vết theo quy định hiện hành nếu case mở rộng sang production.	Nguồn pháp lý được ghi nhận nhưng không có kết luận áp dụng cho Nova Foods mô phỏng.	Verification required	Legal Owner và Accounting Owner mô phỏng

Escalation records

ID escalation	Điều kiện kích hoạt	Người nhận	Gói thông tin phải gửi	Trạng thái
ESC-NF-001	released_quantity khác 500, thiếu liên kết đơn, hoặc xử lý hủy lặp.	L1 Support mô phỏng, QA Owner mô phỏng	SO-NF-20260807-0142, DN-NF-20260807-0088, trạng thái trước/sau, lượng giữ, lượng giải phóng, thời điểm lỗi.	Open for review
ESC-NF-002	Cần đổi quy tắc trạng thái, cơ chế chống xử lý lặp, hoặc cách cập nhật tồn.	Solution Architect mô phỏng, Business Owner mô phỏng	Mô tả ngoại lệ, EVD-NF-001 đến EVD-NF-003, ảnh hưởng tồn khả dụng, phương án xử lý.	Open for review
ESC-NF-003	Có tác động hóa đơn, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc.	Legal Owner, Accounting Owner, Compliance Owner mô phỏng	Phạm vi dữ liệu, sự kiện hủy, chứng từ bị ảnh hưởng, nguồn chính thức cần kiểm tra.	Open for review

Các escalation trên là bản ghi chuyển vấn đề, không là phê duyệt, baseline, kết luận pháp lý, kết luận kế toán, hoặc chỉ dẫn production.

Ma trận truy vết đầu-cuối cho bàn giao vận hành đơn giao hàng

Truy vết đầu-cuối liên kết nhu cầu với kiểm thử để người nhận bàn giao biết vì sao chức năng tồn tại, quy tắc nào chi phối, dữ liệu nào đi qua API, và kiểm tra nào chứng minh hành vi. Chuỗi dưới thuộc tình huống Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07. Đây là liên kết làm việc của hồ sơ Tier 3, không phải baseline, approval, cấu hình ERP thực, hay xác nhận tuân thủ.

Cấp truy vết	ID	Nội dung đã hoàn chỉnh	Cầu nối bằng chứng và suy luận	Liên kết xuôi
NEED — nhu cầu	NEED-NF-OPS-001	Nhân viên Kho cần bàn giao đơn giao hàng đã sẵn sàng xuất cho Bộ phận Vận tải, tránh giao nhầm đơn chưa hoàn tất kiểm tra tồn kho.	Nhu cầu phát sinh từ điểm bàn giao giữa Kho và Vận tải trong tình huống mô phỏng; nếu trạng thái sẵn sàng không rõ, người nhận không có căn cứ phân biệt đơn được phép xử lý.	REQ-NF-OPS-001
REQ — yêu cầu	REQ-NF-OPS-001	ERP phải cho phép người dùng vai trò Warehouse Supervisor tạo bản ghi bàn giao chỉ khi đơn giao hàng có trạng thái READY_FOR_HANDOVER; hệ thống phải ghi mã đơn, kho, thời điểm, người bàn giao và người nhận.	NEED-NF-OPS-001 cần một điểm kiểm soát trước bàn giao. Các trường ghi nhận tạo dấu vết vận hành tối thiểu để đối chiếu người, vật và thời điểm.	BR-NF-OPS-001, AC-NF-OPS-001, DATA-NF-OPS-001, API-NF-OPS-001
BR — quy tắc nghiệp vụ	BR-NF-OPS-001	Chỉ đơn có deliveryStatus = READY_FOR_HANDOVER mới được tạo bàn giao. Đơn có PICKING, ON_HOLD, CANCELLED hoặc HANDED_OVER phải bị từ chối. Một deliveryOrderId chỉ có một bản ghi bàn giao trạng thái CONFIRMED.	Quy tắc thu hẹp REQ thành điều kiện quyết định được kiểm thử. Trạng thái HANDED_OVER bị chặn vì tạo thêm bản ghi sẽ làm mơ hồ trách nhiệm bàn giao.	AC-NF-OPS-001, TC-NF-OPS-001, TC-NF-OPS-002, TC-NF-OPS-003
AC — tiêu chí chấp nhận	AC-NF-OPS-001	Với Warehouse Supervisor và đơn READY_FOR_HANDOVER, khi gửi đủ dữ liệu hợp lệ, hệ thống tạo bàn giao CONFIRMED, trả handoverId, và cập nhật đơn thành HANDED_OVER.	Tiêu chí biến REQ thành kết quả quan sát được: quyền hợp lệ, đầu vào hợp lệ, bản ghi tạo thành công, phản hồi có ID, trạng thái đơn đổi đúng.	TC-NF-OPS-001
AC — tiêu chí chấp nhận	AC-NF-OPS-002	Với đơn không phải READY_FOR_HANDOVER, khi gửi yêu cầu tạo bàn giao, hệ thống không tạo bản ghi, không đổi trạng thái đơn, trả lỗi nghiệp vụ DELIVERY_NOT_READY.	Tiêu chí kiểm tra đường âm của BR-NF-OPS-001; từ chối phải không gây thay đổi dữ liệu để tránh bàn giao sai.	TC-NF-OPS-002
AC — tiêu chí chấp nhận	AC-NF-OPS-003	Với đơn đã HANDED_OVER, khi gửi lại yêu cầu, hệ thống không tạo bản ghi thứ hai, không đổi dữ liệu cũ, trả lỗi HANDOVER_ALREADY_EXISTS.	Tiêu chí kiểm tra tính duy nhất trong BR-NF-OPS-001; lỗi xác định giúp vận hành phân biệt gửi lặp với lỗi kỹ thuật.	TC-NF-OPS-003
DATA — dữ liệu logic	DATA-NF-OPS-001	Thực thể OperationalHandover gồm handoverId, deliveryOrderId, warehouseCode, handoverAt, handedOverByUserId, receivedByUserId, status. handoverId duy nhất; deliveryOrderId bắt buộc; status nhận CONFIRMED trong tình huống này.	REQ yêu cầu lưu năm thông tin bàn giao; thêm handoverId để truy hồi bản ghi và status để biểu diễn kết quả nghiệp vụ. Kiểu dữ liệu vật lý chưa được xác định.	API-NF-OPS-001, TC-NF-OPS-001
API — giao diện lập trình ứng dụng	API-NF-OPS-001	POST /api/v1/operational-handovers nhận deliveryOrderId, warehouseCode, receivedByUserId; danh tính người bàn giao lấy từ phiên đăng nhập hợp lệ. Phản hồi thành công 201; lỗi nghiệp vụ dùng 409.	API phục vụ REQ tạo bàn giao. Không nhận handedOverByUserId từ máy khách vì danh tính phải gắn với phiên đã xác thực; đây là giả định thiết kế cần Architect và Security review.	TC-NF-OPS-001, TC-NF-OPS-002, TC-NF-OPS-003
TC — ca kiểm thử	TC-NF-OPS-001	Tạo bàn giao thành công cho đơn tổng hợp DO-NF-260807-001, trạng thái đầu vào READY_FOR_HANDOVER, kho WH-HCM-01, người nhận USR-TRANS-014. Kỳ vọng 201, có handoverId, đơn thành HANDED_OVER, một OperationalHandover CONFIRMED được lưu.	Kiểm thử phủ AC-NF-OPS-001, đồng thời xác minh trường bắt buộc của DATA-NF-OPS-001 và hợp đồng thành công của API-NF-OPS-001.	Không có DEF hoặc CR được ghi nhận tại v0.9.0.
TC — ca kiểm thử	TC-NF-OPS-002	Gửi tạo bàn giao cho đơn tổng hợp DO-NF-260807-002, trạng thái đầu vào ON_HOLD. Kỳ vọng 409, mã DELIVERY_NOT_READY, không có handoverId, đơn vẫn ON_HOLD, không có bản ghi bàn giao mới.	Kiểm thử phủ AC-NF-OPS-002 và nhánh từ chối của BR-NF-OPS-001; kiểm tra cả phản hồi và dữ liệu sau xử lý.	Không có DEF hoặc CR được ghi nhận tại v0.9.0.
TC — ca kiểm thử	TC-NF-OPS-003	Gửi lại tạo bàn giao cho đơn tổng hợp DO-NF-260807-003, đã có một bàn giao CONFIRMED, trạng thái đơn HANDED_OVER. Kỳ vọng 409, mã HANDOVER_ALREADY_EXISTS, số bản ghi bàn giao của đơn vẫn là một.	Kiểm thử phủ AC-NF-OPS-003 và điều kiện duy nhất của BR-NF-OPS-001; số lượng bản ghi là bằng chứng chống tạo trùng.	Không có DEF hoặc CR được ghi nhận tại v0.9.0.

DEF — lỗi phát hiện khi kiểm thử — và CR — yêu cầu thay đổi — chưa có bản ghi trong phạm vi tình huống này. Không tạo ID DEF hoặc CR giả để lấp ma trận. Nếu TC-NF-OPS-001 đến TC-NF-OPS-003 thất bại, ghi nhận DEF mới và liên kết ngược tới AC, BR, REQ bị ảnh hưởng; nếu thay đổi nhu cầu hoặc quy tắc, ghi nhận CR mới trước khi sửa liên kết hiện hữu.

Bảng quyết định bàn giao vận hành — Nova Foods mô phỏng

Bảng quyết định (decision table) biến điều kiện bàn giao thành kết quả nhất quán. Mỗi cột là một tổ hợp dữ liệu tổng hợp của Nova Foods; mỗi hàng là một điều kiện phải đọc đúng giá trị trước khi ghi kết quả. Bảng không tạo baseline, approval, cấu hình ERP thật, hay quyền đưa vào production.

Điều kiện kiểm tra	R1	R2	R3	R4	R5	R6
Bản phát hành có mã NF-ERP-REL-20260807-01	Có	Có	Có	Có	Có	Không
Môi trường đích ghi nhận UAT-NOVA-01	Có	Có	Có	Có	Không	Có
Gói triển khai có checksum sha256:8e5f2a91c0d44b76	Có	Có	Có	Không	Có	Có
Nhật ký sao lưu trước triển khai: NF-BKP-20260807-001	Có	Có	Không	Có	Có	Có
Kịch bản khôi phục dữ liệu tổng hợp chạy thành công	Có	Không	Có	Có	Có	Có
Tài khoản vận hành ops.nova.sim đăng nhập được theo vai trò mô phỏng	Có	Có	Có	Có	Có	Có
Báo cáo tồn kho mô phỏng khớp dữ liệu đầu vào	Có	Có	Có	Có	Có	Có
Kết quả bàn giao	Đủ điều kiện ghi nhận bàn giao có kiểm soát	Không bàn giao; cần kiểm tra khôi phục	Không bàn giao; cần tạo và kiểm tra sao lưu	Không bàn giao; cần kiểm tra toàn vẹn gói	Không bàn giao; cần xác nhận môi trường đích	Không bàn giao; cần xác nhận mã bản phát hành
Lý do	Mọi điều kiện kỹ thuật tối thiểu đều có dữ liệu khớp trong case mô phỏng.	Không thể suy luận khả năng phục hồi từ việc có bản sao lưu.	Không có bằng chứng dữ liệu đầu vào để phục hồi khi lỗi.	Không xác định được gói được kiểm tra có đúng gói dự kiến không.	Bằng chứng thuộc môi trường khác không chứng minh trạng thái UAT-NOVA-01.	Không truy nguyên được phạm vi thay đổi cần bàn giao.

Dữ liệu trên chỉ phục vụ Nova Foods Trading & Manufacturing mô phỏng, dùng VND và ngữ cảnh vi-VN, thời điểm 2026-08-07 theo Asia/Ho_Chi_Minh. Kết quả “đủ điều kiện ghi nhận bàn giao có kiểm soát” nghĩa là dữ liệu case thỏa bảng; không nghĩa là đã được phê duyệt, đã baseline, tuân thủ, hay sẵn sàng production.

5. Tier 4 ? Senior BA Quality Gate

Quality Gate là cổng kiểm tra chất lượng trước baseline: Senior BA xác nhận artifact đủ rõ để review tiếp, không xác nhận phê duyệt, tuân thủ, baseline hay sẵn sàng production. Mọi kiểm tra áp dụng cho Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

ID kiểm tra	Hạng mục	PASS	FAIL	STOP	Escalation
QG-001	Tính đầy đủ	Có mục tiêu, phạm vi, đầu vào, đầu ra, điều kiện bàn giao, ngoại lệ, bằng chứng và người chịu trách nhiệm cho từng việc bàn giao.	Thiếu trường nhưng chưa làm đổi nghĩa vụ, dữ liệu hay quyết định.	Thiếu điều kiện bàn giao, ngoại lệ xử lý lỗi, bằng chứng khôi phục, hoặc trách nhiệm chính. Không thể đánh giá vận hành an toàn.	Principal IT Business Analyst / Technical Curriculum Author ghi lỗi; Business Owner và Operations Owner xác định nội dung thiếu.
QG-002	Tính nhất quán	ID, tên tệp, môi trường, mã phát hành, checksum, vai trò, ngày giờ và kết quả khớp giữa các phần cùng artifact.	Có khác biệt trình bày không đổi giá trị kiểm soát, ví dụ khoảng trắng bảng.	Một ID trỏ hai đối tượng, checksum gắn sai gói, hoặc UAT-NOVA-01 bị thay bằng môi trường khác. Bằng chứng không còn cùng đối tượng.	Escalation tới Owner artifact và Technical Architect; dừng ghi nhận bàn giao.
QG-003	Khả năng kiểm thử	Mỗi điều kiện có dữ liệu đầu vào, bước kiểm tra, kết quả mong đợi, bằng chứng quan sát và tiêu chí đạt hoặc không đạt.	Bước kiểm tra cần viết rõ hơn nhưng vẫn xác định được kết quả mong đợi.	Không thể tái hiện kiểm tra, không có test basis, hoặc kết quả dùng từ chủ quan như “ổn”.	QA Owner xác nhận test basis và bằng chứng; Senior BA giữ trạng thái IN_REVIEW.
QG-004	Traceability	Mỗi quyết định và điều kiện bàn giao liên kết được tới ID nguồn, artifact nguồn, bằng chứng hoặc giả định có nhãn.	Liên kết tồn tại nhưng định dạng chưa đồng nhất.	Không truy được nguồn của điều kiện quyết định, hoặc liên kết trỏ artifact không canonical.	Owner TRACEABILITY_ID_REGISTRY kiểm tra ID; Principal IT Business Analyst / Technical Curriculum Author sửa liên kết, không tự tạo nguồn mới.
QG-005	Thẩm quyền nguồn	Thuật ngữ BA bám BABOK Guide Version 3; kiểm thử bám ISTQB CTFL Syllabus v4.0.1; API bám OAS 3.1.1 khi có API; BPMN chỉ dùng chuẩn BPMN 2.0.2.	Nguồn phù hợp nhưng chưa ghi rõ ranh giới sử dụng.	Diễn giải nguồn thứ cấp thành quy định bắt buộc, gọi sơ đồ activity là BPMN, hoặc nêu điều khoản pháp lý chưa kiểm tra văn bản chính thức.	Chuyển đúng chủ nguồn: Legal Owner, Accounting Owner, Security Owner, Domain Owner hoặc Technical Architect.
QG-006	Ownership	Mỗi việc có một vai trò chịu trách nhiệm thực hiện, một vai trò có thẩm quyền quyết định khi lỗi, và giới hạn rõ.	Hai vai trò cùng tham gia nhưng chưa phân tách thao tác và quyết định.	Owner artifact bị gán quyền phê duyệt, quyết định kế toán, pháp lý, bảo mật hoặc vận hành thực tế.	Business Owner phân vai; Owner artifact chỉ duy trì nội dung và traceability.
QG-007	Bảo mật và riêng tư	Dữ liệu case là tổng hợp; không có dữ liệu cá nhân thật, bí mật xác thực thật, URL nội bộ thật hoặc thông tin truy cập production. Quyền ops.nova.sim chỉ là tài khoản mô phỏng theo vai trò.	Có trường dữ liệu nhạy cảm mô phỏng nhưng chưa nêu hạn chế hiển thị.	Lộ mật khẩu, token, dữ liệu cá nhân thật, hoặc mô tả quyền vượt nhu cầu vận hành.	Security Owner đánh giá; Legal Owner kiểm tra nghĩa vụ liên quan Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Không coi OWASP là luật.
QG-008	Ranh giới pháp lý, kế toán, thuế và an toàn thực phẩm	Nội dung chỉ nêu “Verification required” hoặc “giả định dự án” khi chưa được vai trò có thẩm quyền xác minh trực tiếp.	Có tham chiếu luật chính thức nhưng chưa xác định người xác minh.	Artifact tự kết luận tuân thủ, hiệu lực hóa đơn, xử lý kế toán, thuế, truy xuất hoặc thu hồi thực tế.	Legal Owner, Accounting Owner và Food-safety Domain Owner xác minh theo nguồn chính thức; Senior BA không thay kết luận.
QG-009	Tác động thay đổi	Mỗi thay đổi nêu đối tượng bị ảnh hưởng, lý do, liên kết traceability, bằng chứng cần chạy lại và người quyết định.	Tác động chỉ ảnh hưởng định dạng, chưa ảnh hưởng dữ liệu hay điều kiện bàn giao.	Thay đổi mã phát hành, môi trường, checksum, quyền truy cập, dữ liệu hoặc điều kiện khôi phục mà không đánh giá lại bằng chứng.	Technical Architect, QA Owner, Operations Owner và Business Owner đánh giá theo phạm vi; giữ IN_REVIEW đến khi cập nhật xong.

Quy tắc quyết định: PASS khi toàn bộ điều kiện PASS. FAIL khi có lỗi sửa được nhưng không phá ranh giới kiểm soát; sửa xong phải chạy lại kiểm tra bị ảnh hưởng. STOP khi có ít nhất một điều kiện STOP; không ghi nhận bàn giao, không gọi nội dung là baseline hoặc approved. Escalation khi lỗi vượt thẩm quyền Senior BA, có xung đột nguồn canonical, hoặc một quyết định chạm đồng thời pháp lý, kế toán, bảo mật, kiến trúc hay vận hành.

Bằng chứng reasoning: checklist yêu cầu traceability vì artifact không thể được review đáng tin nếu điều kiện không truy về nguồn hoặc bằng chứng. Checklist yêu cầu STOP với dữ liệu nhạy cảm, khôi phục, checksum và môi trường vì các mục này quyết định khả năng kiểm tra đúng gói, đúng nơi, đúng dữ liệu mô phỏng. Checklist không tự kết luận luật, kế toán hay compliance vì các nguồn chính thức chỉ xác định ranh giới tham chiếu; kết luận cần vai trò có thẩm quyền.

Ma trận kiểm tra chất lượng Senior BA: chín chiều bắt buộc

Quality gate là cổng kiểm tra trước baseline: Senior BA xác minh handover đủ để đội nhận việc hiểu phải làm gì, kiểm tra được gì, ai chịu trách nhiệm gì và giới hạn nào không được tự suy diễn. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. IN_REVIEW, v0.9.0, ngày 2026-08-07 không nghĩa là baseline, phê duyệt, tuân thủ hay sẵn sàng production.

Chiều kiểm tra	Câu hỏi kiểm tra và bằng chứng tối thiểu	Tiêu chí đạt	Ranh giới phải giữ
Đầy đủ	Handover có mục tiêu, phạm vi, luồng xử lý, quy tắc, dữ liệu, ngoại lệ, acceptance criteria, rủi ro, phụ thuộc, đầu ra bàn giao và liên hệ owner không?	Mỗi mục có nội dung xác định; không dùng placeholder ở Tier 3; ngoại lệ có hành động và người xử lý.	Không điền suy đoán để che khoảng trống. Khoảng trống là finding.
Nhất quán	Tên Nova Foods, ID, trạng thái, phiên bản, ngày, tiền tệ, vai trò, quy tắc và số liệu có trùng khớp artifact canonical không?	Cùng một khái niệm dùng một tên, một ID, một giá trị trong toàn handover.	IN_REVIEW không được đổi thành APPROVED hoặc BASELINED.
Khả năng kiểm thử	Mỗi hành vi có điều kiện đầu vào, hành động, kết quả mong đợi và kết quả khi lỗi không?	QA tạo được test case black-box từ handover mà không hỏi lại tác giả về logic chính.	Không gọi test pass nếu thiếu test data, expected result hoặc xử lý lỗi.
Truy vết	Mỗi requirement, rule, dữ liệu, API, báo cáo và test basis có liên kết nguồn hoặc artifact canonical không?	Liên kết dùng nguyên dạng ID và đường dẫn canonical, gồm CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY khi áp dụng.	Bản sao, tên rút gọn, diễn giải miệng không thay nguồn canonical.
Thẩm quyền nguồn	Nguồn được phân loại là chuẩn, pháp lý, project assumption hay Verification required chưa?	Claim pháp lý, kế toán, an ninh, an toàn thực phẩm có nguồn chính thức và owner thẩm quyền kiểm tra.	BABOK, ISTQB, OWASP là nguồn nghề nghiệp hoặc good practice; không tự biến thành luật Việt Nam.
Ownership	Business Owner, Product Owner, Architect, QA, Security, Legal, Accounting và Principal IT Business Analyst / Technical Curriculum Author có trách nhiệm, quyền quyết định, điểm nhận bàn giao rõ không?	Mỗi quyết định có đúng owner; người ghi handover không tự nhận quyền phê duyệt chuyên môn.	Owner artifact chỉ quản trị nội dung; không thay Legal, Accounting, Security, Architect hoặc Business Owner.
Bảo mật, riêng tư, pháp lý	Dữ liệu cá nhân, bí mật kinh doanh, quyền truy cập, log, truyền API, lưu giữ và chia sẻ có phân loại và kiểm soát chưa?	Dữ liệu synthetic; không có PII thực; yêu cầu pháp lý gắn Verification required nếu chưa được Legal Owner xác minh.	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP cần Legal Owner xác minh khi chuyển thành yêu cầu hệ thống.
Kế toán	Giá trị VND, chứng từ, hạch toán, thuế, đối soát và kỳ khóa sổ có được Accounting Owner xác nhận phạm vi không?	Handover chỉ nêu rule đã có nguồn và owner phù hợp; giả định được gắn nhãn.	Không suy diễn bút toán, thuế hoặc tính hợp lệ hóa đơn từ case mô phỏng. Tham chiếu Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP cần kiểm tra chuyên môn hiện hành.
Ảnh hưởng thay đổi	Thay đổi requirement hoặc rule có chỉ rõ artifact, dữ liệu, API, báo cáo, test, đào tạo, quyền truy cập và owner bị ảnh hưởng không?	Có impact log với lý do, phạm vi, traceability link, người đánh giá và quyết định đang chờ.	Không sửa im lặng ID, rule hoặc nguồn canonical; chưa có baseline không nghĩa thay đổi không cần truy vết.

Áp dụng vào Tier 3 Nova Foods hoàn chỉnh	Kết quả ghi nhận	Cầu nối bằng chứng và suy luận
Đầy đủ	PASS WITH FINDING	Core record và Evidence and Traceability phải đầy đủ trường Tier 3, không placeholder. Finding: mọi yêu cầu pháp lý, kế toán, an toàn thực phẩm cần giữ nhãn Verification required cho đến khi đúng owner kiểm tra.
Nhất quán	PASS	Metadata corpus thống nhất: IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND; Nova Foods là mô phỏng, dữ liệu tổng hợp.
Khả năng kiểm thử	PASS WITH FINDING	Acceptance criteria chỉ đủ test khi nêu input, hành động, expected result và exception. Mọi tiêu chí diễn đạt “tuân thủ luật” không là expected result kiểm thử được nếu thiếu Legal Owner xác minh nghĩa vụ cụ thể.
Truy vết	PASS	Nguồn canonical được giữ nguyên ID và đường dẫn: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Thẩm quyền nguồn và ownership	FAIL — ESCALATION REQUIRED	Principal IT Business Analyst / Technical Curriculum Author không có quyền kết luận pháp lý, kế toán, bảo mật hoặc vận hành. Cần Legal Owner, Accounting Owner, Security và Business Owner xác minh phần thuộc quyền họ.
Bảo mật, riêng tư, pháp lý, kế toán	STOP cho mọi diễn giải triển khai	Bằng chứng nguồn chỉ cho phép dùng luật và chuẩn trong ranh giới đã nêu; chưa có xác nhận chuyên môn hiện hành cho yêu cầu production. Case vẫn dùng được cho học liệu mô phỏng, không dùng làm chỉ dẫn triển khai.
Ảnh hưởng thay đổi	PASS WITH FINDING	Bất kỳ sửa đổi rule, data field, API, vai trò hoặc kiểm soát dữ liệu phải rà lại traceability, test basis, quyền truy cập và artifact liên kết. Chưa có impact decision do đúng owner ghi nhận.

Áp dụng Quality Gate cho Nova Foods

Áp dụng trên bản hoàn chỉnh Tier 3 của TMPL-OPS-001 trong /03-templates/TMPL-OPS-001--operational-handover.md. Nova Foods Trading & Manufacturing là case học liệu mô phỏng; mọi dữ liệu là tổng hợp, không chứng minh vận hành ERP, tuân thủ hay phê duyệt thực tế. Kết quả dưới đây là ghi nhận review trước baseline, không phải approval.

Mã kiểm tra	Hạng mục	Bằng chứng và cầu nối suy luận	Kết quả	Hành động
QG-OPS-001	Đầy đủ	Core Record và Evidence and Traceability chứa mục bàn giao, owner, trạng thái, ngoại lệ, bằng chứng và liên kết truy vết. Một handover cần các phần này để bên nhận biết việc gì chuyển giao, ai chịu trách nhiệm và kiểm tra bằng gì.	PASS	Giữ cấu trúc hiện có.
QG-OPS-002	Nhất quán quản trị	TMPL-OPS-001, /03-templates/TMPL-OPS-001--operational-handover.md, IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND khớp contract corpus. IN_REVIEW không phải baseline hay approval theo TEMPLATE_MANIFEST và CHAPTER_MANIFEST.	PASS	Không đổi trạng thái.
QG-OPS-003	Khả năng kiểm thử	Handover có bằng chứng truy vết, nhưng test chỉ có giá trị khi mỗi kết quả mong đợi, dữ liệu đầu vào và tiêu chí pass/fail xác định được. Không được suy diễn test case production từ case mô phỏng.	PASS có giới hạn	QA reviewer phải xác nhận test basis trước baseline.
QG-OPS-004	Truy vết	Liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY giữ ranh giới nguồn canonical. BA không tự thay thế catalog bằng diễn giải trong handover.	PASS	Giữ nguyên canonical ID.
QG-OPS-005	Thẩm quyền nguồn	BABOK Guide dùng cho thuật ngữ BA; ISTQB CTFL dùng cho thuật ngữ kiểm thử; OWASP dùng cho good practice bảo mật. Các nguồn này không cấp thẩm quyền pháp lý, kế toán hay vận hành Nova Foods.	PASS	Không nâng nguồn good practice thành nghĩa vụ pháp lý.
QG-OPS-006	Ownership	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability. Vai trò này không có quyền xác nhận nghiệp vụ, kế toán, pháp lý, bảo mật, baseline hoặc production use.	PASS	Giữ phân tách trách nhiệm.
QG-OPS-007	Bảo mật và quyền riêng tư	Nếu payload hoặc bằng chứng handover chứa dữ liệu cá nhân, phải có Security Owner và Legal Owner kiểm tra theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Bản case hiện hành là dữ liệu tổng hợp, nhưng nhãn mô phỏng không thay thế kiểm tra khi tái sử dụng với dữ liệu thật.	STOP	Không dùng với dữ liệu cá nhân hay môi trường production trước khi có xác minh chuyên môn được ghi nhận.
QG-OPS-008	Kế toán, hóa đơn, thực phẩm	Luật Kế toán, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm là nguồn chính thức, nhưng artifact không có kết luận chuyên môn đã xác minh trực tiếp. Suy luận: không thể gọi mapping chứng từ, lưu giữ kế toán hoặc truy xuất thực phẩm là compliant.	STOP	Escalate Accounting Owner, Legal Owner và domain owner trước mọi baseline có claim thuộc các phạm vi này.
QG-OPS-009	Tác động thay đổi	Đổi business rule, trường dữ liệu, owner, quyền truy cập hoặc bằng chứng có thể làm lệch Core Record, Evidence and Traceability và artifact canonical liên quan. Vì các liên kết này là chuỗi kiểm soát, thay đổi không được sửa đơn lẻ.	FAIL	Lập change record, phân tích tác động tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, rồi review lại Quality Gate.

Kết luận review: Không đủ điều kiện đề xuất baseline. Hai điều kiện STOP chặn mọi diễn giải pháp lý, kế toán, quyền riêng tư, bảo mật hoặc vận hành thực tế. Một FAIL về tác động thay đổi cần được xử lý và kiểm tra lại; trạng thái artifact giữ IN_REVIEW.

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

6.1 Kiểm tra chéo nguồn kiểm soát

Kiểm tra chéo đối chiếu cùng một thông tin giữa nhiều artifact để phát hiện mâu thuẫn trước handoff. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, nguồn kiểm soát không phải bằng chứng approval hay baseline. Kết quả dưới đây chỉ xác nhận nhất quán metadata, định danh, phạm vi và ranh giới thẩm quyền tại v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND.

Check ID	Đối tượng đối chiếu	Bằng chứng và cầu nối suy luận	Kết quả
XFILE-OPS-001	/03-templates/TMPL-OPS-001--operational-handover.md với /01-curriculum/TEMPLATE_MANIFEST.md	Template Manifest quy định template library là controlled planning artifact, IN_REVIEW, v0.9.0, case Nova Foods mô phỏng, dữ liệu tổng hợp. Handover phải giữ cùng trạng thái và không diễn đạt như tài liệu vận hành production.	PASS có điều kiện
XFILE-OPS-002	Handover với /01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST là nguồn kiểm soát cấu trúc 26 chapter, không tạo baseline hay approval. Vì handover tham chiếu chapter và consumer downstream, mọi liên kết chapter chỉ là traceability đang review.	PASS có điều kiện
XFILE-OPS-003	Handover với /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Registry là nguồn canonical cho ID. Không có ID mới được tạo trong kiểm tra này. Các Artifact ID CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY giữ nguyên chính tả.	PASS
XFILE-OPS-004	Handover với /01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog rule xác định rule Nova Foods chưa phải quy định vận hành thực tế khi chưa có review, baseline hoặc approval được ghi nhận. Handover không được nâng rule mô phỏng thành quyết định Business Owner, Legal Owner, Accounting Owner, Security Owner hay Architect.	PASS có điều kiện
XFILE-OPS-005	Handover với /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Data dictionary là nguồn canonical cho nghĩa logic dữ liệu. Handover chỉ được lặp lại field, kiểu dữ liệu, mã và định nghĩa đã được đăng ký; không được tự đổi tên field hoặc suy ra schema triển khai.	PASS có điều kiện
XFILE-OPS-006	Handover với /00-research/00_SOURCE_MAP.md	Source Map phân loại BABOK, ISO/IEC/IEEE 29148, BPMN, UML, ISTQB, OpenAPI, WCAG, OWASP và nguồn pháp luật Việt Nam. Phân loại này giới hạn cách dùng nguồn; không cho phép bịa điều khoản, trích dẫn, kết luận pháp lý hoặc claim compliant.	PASS
XFILE-OPS-007	Handover với consumer downstream: QA, testing, delivery	Consumer downstream chỉ nhận Core Record, Evidence and Traceability, rule/data link và trạng thái review làm test basis hoặc review input. Vì IN_REVIEW không phải BASELINED hay APPROVED, consumer không được dùng artifact làm lệnh triển khai, cấu hình ERP, test sign-off hoặc production release.	PASS có điều kiện

6.2 Tiêu chí phát hiện mâu thuẫn

Mâu thuẫn tồn tại khi cùng một fact có hai giá trị khác nhau trong nguồn kiểm soát. Ví dụ: nếu handover ghi APPROVED nhưng TEMPLATE_MANIFEST ghi IN_REVIEW, metadata mâu thuẫn; nếu handover dùng ID khác TRACEABILITY_ID_REGISTRY, traceability bị đứt; nếu handover đổi nghĩa trường từ CANONICAL_DATA_DICTIONARY, dữ liệu có hai nguồn chân lý. Khi phát hiện, nguồn canonical thắng: manifest quyết định filename, phạm vi và trạng thái; registry quyết định ID; rule catalog quyết định mã rule; data dictionary quyết định nghĩa dữ liệu; Source Map quyết định phân loại và ranh giới nguồn.

Không có mâu thuẫn trực tiếp trong tập bằng chứng đã cung cấp cho kiểm tra này. Tuy vậy, kết quả không xác nhận tính đúng đắn nghiệp vụ, pháp lý, kế toán, an ninh, quyền riêng tư, an toàn thực phẩm hoặc khả năng vận hành ERP. Lý do: các artifact nguồn đều IN_REVIEW, chưa có baseline reference và chưa có approval reference.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Sổ này ghi đủ mục chưa thể đóng trong phạm vi bàn giao của TMPL-OPS-001. Lý do giữ mở: các artifact nguồn đều IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, chưa có baseline reference hoặc approval reference. Không mục nào dưới đây là quyết định vận hành, pháp lý, kế toán hay production.

Loại	Mã bị ảnh hưởng	Nội dung mở	Bằng chứng và cầu nối suy luận	Owner xử lý	Tác động	Hành động kế tiếp
Vấn đề mở	TMPL-OPS-001; TEMPLATE_MANIFEST	Chưa có tham chiếu baseline cho template operational handover.	TEMPLATE_MANIFEST ghi IN_REVIEW, v0.9.0, chưa có baseline reference. Vì handover chỉ chuyển giao nội dung được kiểm soát, template không thể được gọi là baseline.	Principal IT Business Analyst / Technical Curriculum Author	Người nhận có thể nhầm bản review là bản áp dụng chính thức.	Giữ nhãn IN_REVIEW; ghi baseline reference chỉ khi artifact kiểm soát có quyết định hợp lệ.
Vấn đề mở	TMPL-OPS-001; TRACEABILITY_ID_REGISTRY	Chưa có xác nhận rằng mọi ID liên kết trong handover đã được đăng ký đầy đủ cho bản dùng sau review.	Registry là nguồn canonical cho định danh, nhưng đang IN_REVIEW. Vì ID chưa được xác nhận ở trạng thái kiểm soát cao hơn, không suy diễn tính sẵn sàng triển khai.	Principal IT Business Analyst / Technical Curriculum Author	Liên kết traceability có thể sai, trùng hoặc trỏ tới artifact chưa được kiểm soát.	Đối chiếu từng ID handover với /01-curriculum/TRACEABILITY_ID_REGISTRY.md; escalation nếu ID thiếu, trùng hoặc đổi nghĩa.
Giả định dự án	TMPL-OPS-001; CANONICAL_BUSINESS_RULES	Nội dung handover chỉ tham chiếu quy tắc đã ghi trong catalog canonical; không tự tạo quy tắc Nova Foods.	CANONICAL_BUSINESS_RULES phân định catalog là nguồn canonical nhưng không xác nhận quy tắc đúng cho vận hành thực tế. Vì vậy template chỉ được dùng làm khung liên kết học liệu.	Business Owner xác nhận nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết	Nếu giả định sai, người học có thể xem ví dụ là policy ERP thật.	Mỗi rule được thêm phải giữ ID canonical, nguồn và trạng thái xác minh; chuyển Business Owner khi cần kết luận nghiệp vụ.
Giả định dự án	TMPL-OPS-001; CANONICAL_DATA_DICTIONARY	Trường dữ liệu, định dạng và ý nghĩa dữ liệu trong handover dùng từ điển dữ liệu logic, không phải schema ERP triển khai.	CANONICAL_DATA_DICTIONARY được mô tả là logical data dictionary plan. Suy ra nó chưa phải đặc tả database, API payload hay cấu hình production.	Data Owner; Architect xác nhận thiết kế kỹ thuật	Mapping sai có thể làm downstream consumer hiểu nhầm kiểu dữ liệu hoặc nguồn dữ liệu.	Gắn mỗi trường với ID từ điển dữ liệu; escalation Architect khi cần schema, interface hoặc mapping hệ thống.
Cần xác minh	TMPL-OPS-001; SRC-READY-010; SRC-READY-011	Mọi mô tả Nova Foods vẫn là mô phỏng, dữ liệu tổng hợp, không nêu doanh nghiệp thật hoặc xác nhận tuân thủ.	00_SOURCE_MAP.md quy định SRC-READY-010 và SRC-READY-011: không khẳng định Nova Foods có thật, áp dụng quy định cụ thể hoặc đạt tuân thủ.	Principal IT Business Analyst / Technical Curriculum Author	Claim sai phá vỡ ranh giới nguồn và có thể tạo hiểu nhầm pháp lý hoặc vận hành.	Review toàn bộ nội dung thêm mới; thay claim thực tế bằng nhãn mô phỏng hoặc chuyển chuyên gia có thẩm quyền xác minh.
Cần xác minh	TMPL-OPS-001; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Chi tiết thuế, kế toán, lao động, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc phải được owner chuyên môn xác minh trước khi dùng ngoài học liệu.	Verified primary-source seed nêu rõ các chi tiết chưa đối chiếu văn bản chính thức hiện hành phải gắn nhãn project assumption hoặc Verification required.	Legal Owner, Accounting Owner, Compliance Owner, Food-safety Domain Owner	Diễn giải sai luật hoặc nghĩa vụ kiểm soát.	Không chuyển thành requirement bắt buộc; lập gói câu hỏi gồm ID, nguồn chính thức, nội dung cần kết luận và mục đích sử dụng.
Cần xác minh	TMPL-OPS-001; TRACEABILITY_ID_REGISTRY	Kiểm soát bảo mật, quyền truy cập và API chỉ là phạm vi cần xác minh, không phải cam kết an ninh.	Registry yêu cầu escalation khi đề xuất có thể bị diễn giải thành quyết định bảo mật; OWASP ASVS và OWASP API Security Top 10 chỉ là chuẩn/good practice theo source seed.	Security Owner; Architect	Rủi ro lộ dữ liệu mô phỏng, gán sai quyền hoặc mô tả sai biện pháp bảo mật.	Ghi loại dữ liệu, thành phần ảnh hưởng và rủi ro; chuyển Security Owner xác nhận trước khi tạo control hoặc acceptance criterion.

Quy tắc đóng mục: chỉ Owner có thẩm quyền chuyên môn mới được kết luận nội dung thuộc phạm vi mình; Principal IT Business Analyst / Technical Curriculum Author chỉ cập nhật traceability, trạng thái và lịch sử thay đổi. Đến khi có bằng chứng kiểm soát hợp lệ, mọi mục giữ mở và TMPL-OPS-001 giữ IN_REVIEW, v0.9.0.

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 để bên nhận tiếp tục review, không phải phê duyệt, baseline hay cho phép dùng production. Gói bàn giao của /03-templates/TMPL-OPS-001--operational-handover.md giữ IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, 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: mọi artifact nguồn cùng xác định IN_REVIEW không đồng nghĩa APPROVED, BASELINED, tuân thủ hay chấp thuận người dùng.

Thành phần bàn giao	Nguồn kiểm soát	Bên nhận dùng để làm gì	Không được suy diễn thành
Danh tính template, trạng thái, version, đường dẫn	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Đối chiếu template đúng vị trí và trạng thái quản trị	Baseline hoặc approval
Danh tính liên kết và ID truy vết	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Giữ nguyên ID khi nối requirement, rule, dữ liệu, test và handover	Quyết định nghiệp vụ, pháp lý, kiến trúc hay bảo mật
Quy tắc nghiệp vụ canonical	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Kiểm tra nguồn của business rule, tức quy tắc quyết định nghiệp vụ	Quy tắc vận hành ERP thực tế đã xác nhận
Định nghĩa dữ liệu logic canonical	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kiểm tra nghĩa, kiểu dùng và liên kết dữ liệu	Thiết kế DB, API hay cấu hình production
Phạm vi chapter và template	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md; TEMPLATE_MANIFEST	Xác định artifact nào phải nhận ảnh hưởng	Quyền sửa ngoài phạm vi manifest
Nguồn chuẩn và ranh giới sử dụng	00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	Giữ phân loại nguồn, URL chính thức và nhãn xác minh	Trích dẫn điều khoản chưa kiểm tra trực tiếp

Quy tắc lan truyền thay đổi: thay đổi chỉ bắt đầu từ artifact nguồn có thẩm quyền cho loại thay đổi đó. Sửa tên, đường dẫn, status, version hoặc ID phải cập nhật nguồn registry hoặc manifest trước; template chỉ phản ánh lại tham chiếu đã được kiểm soát. Sửa nghĩa business rule phải quay về CANONICAL_BUSINESS_RULES; sửa nghĩa trường dữ liệu phải quay về CANONICAL_DATA_DICTIONARY. Không được sửa riêng bản sao trong template để tạo “nguồn chân lý” thứ hai. Mỗi thay đổi phải giữ ID cũ nếu nghĩa không đổi; nếu nghĩa đổi, tạo liên kết truy vết rõ giữa bản cũ và bản mới theo registry, rồi rà soát các artifact nhận ảnh hưởng.

Loại thay đổi	Artifact phải cập nhật trước	Artifact nhận ảnh hưởng tối thiểu	Thẩm quyền quyết định
Metadata, filename, dependency	CHAPTER_MANIFEST hoặc TEMPLATE_MANIFEST	Template, chapter, liên kết corpus liên quan	Principal IT Business Analyst / Technical Curriculum Author trong phạm vi biên tập
ID hoặc quan hệ truy vết	TRACEABILITY_ID_REGISTRY	Requirement, rule, data dictionary, test basis, handover liên quan	Owner registry duy trì; escalation khi nghĩa ID chạm quyết định chuyên môn
Quy tắc nghiệp vụ Nova Foods mô phỏng	CANONICAL_BUSINESS_RULES	Template và chapter tham chiếu rule	Business Owner xác nhận nghiệp vụ; Owner chỉ duy trì traceability
Dữ liệu, phân loại dữ liệu, quyền truy cập hoặc API	CANONICAL_DATA_DICTIONARY	Template, đặc tả liên quan, test basis	Architect, Security hoặc Data Owner theo phạm vi
Nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc dữ liệu cá nhân	Nguồn chính thức được ghi trong 00_SOURCE_MAP và artifact canonical liên quan	Mọi nội dung dẫn xuất	Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner có thẩm quyền

Bên bàn giao ghi nhận thay đổi, bằng chứng nguồn, artifact bị ảnh hưởng và người cần review; không tự cấp sign-off. Bên nhận chỉ dùng gói này làm đầu vào review và phải giữ nguyên nhãn Verification required hoặc project assumption khi chưa có xác nhận từ vai trò có thẩm quyền. Escalation, tức chuyển vấn đề lên người có quyền quyết định, là bắt buộc khi thay đổi có thể ảnh hưởng pháp lý, kế toán, bảo mật, kiến trúc, vận hành thực tế hoặc khi hai nguồn canonical mâu thuẫn. Cho đến khi có baseline reference và approval reference được ghi minh bạch trong artifact kiểm soát, mọi nội dung vẫn là học liệu Nova Foods mô phỏng ở trạng thái IN_REVIEW.