Tmpl Ops 003 Support Readiness

Trường kiểm soát	Giá trị
Artifact ID	`TMPL-OPS-003`
Tên tệp được kiểm soát	`/03-templates/TMPL-OPS-003--support-readiness.md`
Tiêu đề artifact	`Tmpl Ops 003 Support Readiness`
Phân loại artifact	Four-tier controlled template; template sẵn sàng hỗ trợ 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 — mô phỏng giáo dục
Phạm vi dữ liệu	Chỉ dữ liệu tổng hợp. Không dùng dữ liệu cá nhân, khách hàng, nhân sự, nhà cung cấp, giao dịch hoặc cấu hình ERP thực.
Manifest identity	`TEMPLATE_MANIFEST` tại `/01-curriculum/TEMPLATE_MANIFEST.md`; định danh template giữ nguyên `TMPL-OPS-003`.
Cơ sở lập kế hoạch	`manifest-derived-from-terra-master-plan-v1`
Trạng thái baseline	Chưa có baseline reference tại `v0.9.0`. `IN_REVIEW` không có nghĩa `BASELINED`.
Trạng thái approval	Chưa có approval reference. Metadata, lịch sử thay đổi, Owner hoặc nội dung review không tạo approval ngầm định.

Metadata này là nguồn kiểm soát danh tính của artifact. TMPL-OPS-003 và đường dẫn /03-templates/TMPL-OPS-003--support-readiness.md phải được giữ nguyên khi liên kết, review, xuất bản nội bộ hoặc kiểm tra truy vết. Lý do: TEMPLATE_MANIFEST là manifest canonical cho template corpus; đổi ID hoặc tên tệp ngoài kiểm soát sẽ làm đứt liên kết với manifest và các artifact phụ thuộc.

Owner duy trì metadata, version, trạng thái và lịch sử thay đổi. Owner không tự xác lập baseline, không ghi nhận approval, không xác nhận yêu cầu Nova Foods cho vận hành thật, không diễn giải pháp lý, kế toán, thuế hoặc compliance, và không cho phép triển khai production. Lý do: các thẩm quyền này thuộc vai trò business, legal, accounting, security, compliance, architect hoặc QA có thẩm quyền.

Nova Foods Trading & Manufacturing trong artifact này là case study mô phỏng. Mọi tên người, mã ticket, thời điểm, số tiền VND, hệ thống, luồng hỗ trợ và bằng chứng ở Tier 3 chỉ là dữ liệu tổng hợp phục vụ học tập. Chúng không chứng minh doanh nghiệp có thật, không xác nhận cấu hình ERP thật, không xác nhận tuân thủ pháp luật, và không được dùng làm bằng chứng vận hành.

Version	Ngày	Thay đổi	Người ghi nhận	Kiểm soát
`v0.9.0`	`2026-08-07`	Khởi tạo artifact `TMPL-OPS-003`; thiết lập H1, định danh, trạng thái `IN_REVIEW`, metadata quản trị và ranh giới dữ liệu mô phỏng.	Principal IT Business Analyst / Technical Curriculum Author	Không baseline, không approval, không production authorization.

Mọi thay đổi sau v0.9.0 phải giữ nguyên Artifact ID, ghi version và ngày mới theo Asia/Ho_Chi_Minh, mô tả thay đổi cụ thể, và cập nhật liên kết TEMPLATE_MANIFEST khi thay đổi ảnh hưởng danh tính, cấu trúc hoặc phạm vi kiểm soát. Không được sửa im lặng lịch sử này.

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

Support Readiness là mức sẵn sàng để bộ phận hỗ trợ tiếp nhận, phân loại, xử lý và chuyển cấp sự cố sau khi thay đổi ERP được đưa vào phạm vi vận hành mô phỏng. Template TMPL-OPS-003 tạo một hồ sơ kiểm soát thống nhất: hỗ trợ biết hỗ trợ cái gì, dùng bằng chứng nào, ai quyết định khi vượt thẩm quyền. Nova Foods Trading & Manufacturing là case study giáo dục; mọi tên, tình huống, dữ liệu và quyết định trong template là dữ liệu tổng hợp, không phải cấu hình hay vận hành ERP thực tế.

Nội dung	Quy tắc áp dụng
Dùng khi	Có thay đổi Nova Foods mô phỏng cần bàn giao cho hỗ trợ, như quy trình nghiệp vụ, màn hình, báo cáo, tích hợp API, quyền truy cập hoặc luồng xử lý lỗi. Hồ sơ phải được lập trước khi diễn giải rằng hỗ trợ có thể tiếp nhận thay đổi.
Không dùng khi	Cần phê duyệt triển khai, xác nhận baseline, quyết định kiến trúc, xác nhận tuân thủ pháp lý, kết luận kế toán, hoặc cấp quyền production. Template không thay thế runbook vận hành thực, ticket hệ thống, kế hoạch kiểm thử hay quyết định Business Owner.
Owner	`Principal IT Business Analyst / Technical Curriculum Author` duy trì cấu trúc, định danh, phiên bản, liên kết truy vết và ranh giới dữ liệu mô phỏng của template. Owner không tự phê duyệt nội dung nghiệp vụ hoặc xác nhận sẵn sàng production.
Người dùng	BA dùng để đóng gói thông tin bàn giao; Service Desk hoặc Support dùng để hiểu điểm tiếp nhận; QA dùng để đối chiếu bằng chứng kiểm thử; Technical Architect và đội kỹ thuật dùng để xác định tuyến chuyển cấp; Business Owner dùng để xem phạm vi tác động nghiệp vụ.
Điều kiện đầu vào	Phải có phạm vi thay đổi xác định, liên kết requirement hoặc business rule nếu có, tiêu chí tiếp nhận, đầu mối hỗ trợ, tuyến escalation và bằng chứng kiểm thử phù hợp. Thiếu một đầu vào làm Support Readiness không đủ căn cứ để xác nhận khả năng hỗ trợ.
Đầu ra hạ nguồn	Hồ sơ hoàn chỉnh là đầu vào cho handover hỗ trợ mô phỏng, test basis cho kiểm tra vận hành, danh sách knowledge article cần soạn, ma trận escalation và kiểm tra traceability. Nó không tự tạo ticket, SLA, quyền hệ thống hay quyết định release.

Authority là thẩm quyền ra quyết định. Owner được sửa lỗi trình bày, bổ sung liên kết truy vết và ghi nhận thay đổi có kiểm soát. Owner phải chuyển cấp thay vì tự quyết khi nội dung làm đổi business rule, dữ liệu cá nhân, bảo mật, kiến trúc, kế toán, thuế, an toàn thực phẩm hoặc khả năng vận hành thực. Lý do: các lĩnh vực này cần chủ thể chuyên môn chịu trách nhiệm, còn IN_REVIEW tại v0.9.0 không phải APPROVED hay BASELINED.

Escalation là chuyển vấn đề đến vai trò có thẩm quyền khi tuyến hỗ trợ không thể xử lý an toàn. Chuyển Business Owner khi tác động quy trình hoặc ưu tiên nghiệp vụ chưa rõ; chuyển Technical Architect khi nguyên nhân thuộc tích hợp, hạ tầng hoặc thiết kế kỹ thuật; chuyển QA khi bằng chứng kiểm thử thiếu hoặc mâu thuẫn; chuyển Security khi có dữ liệu nhạy cảm, phân quyền hoặc nguy cơ API; chuyển Legal, Compliance hoặc Accounting Owner khi nội dung bị diễn giải thành nghĩa vụ pháp lý, tuân thủ hoặc kế toán. Khi nguồn canonical mâu thuẫn, giữ nguyên mâu thuẫn trong hồ sơ, liên kết nguồn liên quan và không tự tạo quy tắc Nova Foods.

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

Thành phần	Giá trị kiểm soát	Lý do và quy tắc dùng
Template ID canonical	`TMPL-OPS-003`	ID duy nhất của template Support Readiness. Giữ nguyên chuỗi này trong tên liên kết, ma trận truy vết, lịch sử thay đổi và artifact hạ nguồn. Không đổi thành biến thể dịch thuật hoặc ID cục bộ.
Tệp được kiểm soát	`/03-templates/TMPL-OPS-003--support-readiness.md`	Vị trí canonical của template. Bản sao, PDF xuất, nội dung trích dẫn hoặc tệp đổi tên không thay thế tệp này.
Manifest template	`/01-curriculum/TEMPLATE_MANIFEST.md` — `TEMPLATE_MANIFEST`	Manifest là nguồn xác định danh mục template, định danh, phạm vi và dependency đã đăng ký. Khi tệp, ID hoặc phạm vi mâu thuẫn manifest, dừng cập nhật nội dung và sửa mâu thuẫn tại nguồn quản trị có thẩm quyền.
Manifest chapter	`/01-curriculum/CHAPTER_MANIFEST.md` — `CHAPTER_MANIFEST`	Manifest này là nguồn canonical cho 26 handbook chapter. Template chỉ tham chiếu chapter đã được manifest đăng ký; không tự tạo chapter ID, tên chapter hoặc quan hệ học tập mới.
Registry truy vết	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md` — `TRACEABILITY_ID_REGISTRY`	Registry kiểm soát cấu trúc và tính duy nhất của ID truy vết. Mọi ID requirement, rule, data, test, risk hoặc evidence xuất hiện ở Tier 3 phải khớp registry khi registry đã đăng ký loại ID đó.
Catalog quy tắc	`/01-curriculum/CANONICAL_BUSINESS_RULES.md` — `CANONICAL_BUSINESS_RULES`	Quy tắc nghiệp vụ phải tham chiếu catalog này, không nhân bản thành nguồn chân lý thứ hai trong template.
Từ điển dữ liệu	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md` — `CANONICAL_DATA_DICTIONARY`	Trường dữ liệu, định nghĩa logic và ràng buộc dữ liệu phải giữ liên kết về từ điển canonical. Template không tự biến ví dụ Nova Foods thành mô hình dữ liệu triển khai.
Bản đồ nguồn	`/00-research/00_SOURCE_MAP.md` — `00_SOURCE_MAP`	Đây là nguồn quản trị cho phân loại, URL, phiên bản và ranh giới sử dụng nguồn ngoài. Không sao chép hoặc nâng cấp trạng thái nguồn khi chưa cập nhật Source Map.

Ánh xạ chapter: TMPL-OPS-003 phục vụ nội dung readiness hỗ trợ vận hành sau bàn giao trong chuỗi học BA. Liên kết chapter chỉ hợp lệ khi CHAPTER_MANIFEST ghi nhận rõ chapter ID và dependency tương ứng. Dữ liệu đầu vào hiện có không xác định chapter ID riêng cho template này; vì vậy không được suy diễn hoặc tạo ID chapter. Đây là kiểm soát chống đứt traceability: tên chủ đề giống nhau không đủ chứng minh quan hệ canonical.

Nhóm nguồn	Nguồn canonical	Phạm vi được phép trong template
BA và quản trị requirement	BABOK Guide Version 3	Thuật ngữ BA, nhiệm vụ, năng lực và reasoning. Không gán số trang hoặc điều khoản khi chưa kiểm tra văn bản được cấp phép.
Chất lượng và kiểm thử	ISTQB CTFL Syllabus v4.0.1	Thuật ngữ test basis, kỹ thuật kiểm thử hộp đen và readiness evidence.
API và kỹ thuật tích hợp	OpenAPI Specification OAS 3.1.1	Mô tả HTTP API và feature OAS. Không biến mô tả mẫu thành hợp đồng API production.
Bảo mật	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	Tham chiếu kiểm tra bảo mật và nhận thức rủi ro. Không diễn đạt là luật Việt Nam hoặc xác nhận tuân thủ.
Pháp lý Việt Nam	Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP; Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP; Luật 55/2010/QH12	Chỉ nêu bối cảnh cần kiểm tra. Mọi yêu cầu pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất phải mang nhãn Verification required nếu chưa được chủ thể có thẩm quyền xác minh trực tiếp.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi tên, vai trò, quy trình, ticket, số liệu VND, payload, bằng chứng và quyết định trong Tier 3 dùng dữ liệu tổng hợp. Suy luận này dựa trên ranh giới case study của TEMPLATE_MANIFEST, CHAPTER_MANIFEST và TRACEABILITY_ID_REGISTRY; không được diễn giải thành cấu hình ERP thật, xác nhận vận hành, compliance, baseline hoặc approval.

Nghĩa vụ change control: thay đổi TMPL-OPS-003, đường dẫn tệp, liên kết manifest, ID canonical, source classification hoặc traceability phải ghi version mới và change-history entry trong artifact kiểm soát. Không sửa im lặng nội dung đã phát hành để review. IN_REVIEW tại v0.9.0 không phải BASELINED, APPROVED, production-ready hoặc user-approved. Nếu thay đổi đụng chạm quy tắc nghiệp vụ, dữ liệu, kiến trúc, bảo mật, pháp lý, kế toán hoặc quyết định vận hành, Principal IT Business Analyst / Technical Curriculum Author giữ gói truy vết và escalation đến owner chuyên môn; không tự kết luận thay vai trò đó.

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

Cách dùng Tier 2: Sao chép toàn bộ mẫu này. Thay mọi giá trị trong dấu <...> bằng dữ liệu dự án đã kiểm tra. Không giữ placeholder khi chuyển sang Tier 3. Nova Foods Trading & Manufacturing chỉ là case study mô phỏng; dùng dữ liệu tổng hợp, không đưa bí mật, dữ liệu cá nhân thật hoặc quyết định production vào mẫu.

2.1. Thông tin hồ sơ hỗ trợ

Trường	Giá trị điền	Hướng dẫn và kiểm tra
Support Readiness ID	`<ID hồ sơ support readiness theo registry canonical>`	Bắt buộc. Giữ nguyên ID đã đăng ký; không tự tạo biến thể.
Tên giải pháp	`<tên module, dịch vụ hoặc thay đổi ERP>`	Bắt buộc. Nêu đối tượng được hỗ trợ, không nêu tên chương trình chung chung.
Artifact ID	`TMPL-OPS-003`	Bắt buộc. Không sửa.
Tệp kiểm soát	`/03-templates/TMPL-OPS-003--support-readiness.md`	Bắt buộc. Không đổi đường dẫn.
Trạng thái	`<IN_REVIEW hoặc trạng thái được phép theo governance>`	Bắt buộc. Không dùng `APPROVED` hoặc `BASELINED` nếu chưa có tham chiếu chính thức.
Phiên bản	`<vX.Y.Z>`	Bắt buộc. Theo semantic versioning: tăng version khi nội dung kiểm soát đổi.
Ngày cập nhật	`<YYYY-MM-DD>`	Bắt buộc. Dùng lịch Gregory.
Múi giờ	`Asia/Ho_Chi_Minh`	Bắt buộc. Không dùng viết tắt múi giờ mơ hồ.
Locale và tiền tệ	`vi-VN / VND`	Bắt buộc nếu hồ sơ có thông báo, số tiền, báo cáo hoặc dữ liệu nghiệp vụ.
Owner hồ sơ	`<họ tên hoặc vai trò chịu trách nhiệm duy trì hồ sơ>`	Bắt buộc. Owner duy trì hồ sơ, không tự cấp phê duyệt chuyên môn.
Phạm vi môi trường	`<DEV, SIT, UAT, Production-like hoặc môi trường mô phỏng>`	Bắt buộc. Chọn giá trị thực tế trong phạm vi dự án. Không gọi môi trường mô phỏng là production.
Phân loại dữ liệu	`<PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED hoặc taxonomy dự án>`	Bắt buộc. Nếu có dữ liệu cá nhân, tài chính hoặc bí mật kinh doanh, ghi `Verification required` và chuyển owner phù hợp kiểm tra.
Tuyên bố mô phỏng	`<Có/Không; mô tả nguồn dữ liệu>`	Bắt buộc. Nếu case study, ghi rõ “Mô phỏng giáo dục, dữ liệu tổng hợp”.

2.2. Mục tiêu, phạm vi và ranh giới hỗ trợ

Trường	Giá trị điền	Hướng dẫn và kiểm tra
Mục tiêu hỗ trợ	`<kết quả vận hành cần bảo vệ sau go-live>`	Bắt buộc. Viết theo kết quả đo được, ví dụ khả năng tiếp nhận và xử lý sự cố.
Lý do cần readiness	`<sự kiện hoặc rủi ro tạo nhu cầu chuẩn bị hỗ trợ>`	Bắt buộc. Nối lý do với tác động nghiệp vụ; không suy đoán không có nguồn.
Trong phạm vi	`<module, quy trình, giao diện, nhóm người dùng, địa điểm>`	Bắt buộc. Mỗi mục một dòng.
Ngoài phạm vi	`<thành phần không được đội hỗ trợ này xử lý>`	Bắt buộc. Nêu nơi chuyển tiếp nếu biết.
Điểm bắt đầu hỗ trợ	`<sự kiện kích hoạt, ngày giờ hoặc điều kiện>`	Bắt buộc. Ví dụ: sau khi release được triển khai vào môi trường xác định.
Điểm kết thúc hỗ trợ tăng cường	`<ngày giờ, ngưỡng ổn định hoặc điều kiện kết thúc>`	Bắt buộc nếu có hypercare. “Hypercare” là giai đoạn hỗ trợ tăng cường ngay sau triển khai.
Giả định dự án	`<ASSUMP-ID hoặc mô tả giả định>`	Bắt buộc. Ghi chủ sở hữu xác minh và hậu quả nếu giả định sai.
Ràng buộc	`<nguồn lực, giờ làm, công cụ, môi trường, quyền truy cập>`	Bắt buộc. Không biến ràng buộc thành cam kết chưa được xác nhận.

2.3. Danh mục dịch vụ và mô hình tier

Dịch vụ hoặc chức năng	Người dùng hoặc nhóm dùng	Tier 1 xử lý	Tier 2 xử lý	Tier 3 xử lý	Điều kiện chuyển cấp
`<tên dịch vụ/chức năng 01>`	`<vai trò người dùng>`	`<tiếp nhận, hướng dẫn chuẩn, reset không bí mật hoặc giá trị N/A>`	`<phân tích cấu hình, dữ liệu hoặc giá trị N/A>`	`<sửa lỗi mã nguồn, hạ tầng hoặc nhà cung cấp hoặc giá trị N/A>`	`<điều kiện cụ thể, thời hạn hoặc mã lỗi>`
`<tên dịch vụ/chức năng 02>`	`<vai trò người dùng>`	`<phạm vi Tier 1>`	`<phạm vi Tier 2>`	`<phạm vi Tier 3>`	`<điều kiện chuyển cấp>`
`<tên dịch vụ/chức năng 03>`	`<vai trò người dùng>`	`<phạm vi Tier 1>`	`<phạm vi Tier 2>`	`<phạm vi Tier 3>`	`<điều kiện chuyển cấp>`

Hướng dẫn tier: Tier 1 là tuyến tiếp nhận đầu tiên, xác minh thông tin và áp dụng hướng dẫn đã được kiểm soát. Tier 2 phân tích sâu về nghiệp vụ, cấu hình hoặc dữ liệu trong phạm vi được cấp quyền. Tier 3 xử lý mã nguồn, hạ tầng, tích hợp hoặc vendor. Mỗi dịch vụ phải có ít nhất một tuyến chịu trách nhiệm; nếu không có, ghi <chưa xác định — escalation đến <vai trò>>, không tự gán owner.

2.4. Liên hệ, lịch trực và kênh tiếp nhận

Loại liên hệ	Vai trò	Kênh an toàn	Khung giờ `Asia/Ho_Chi_Minh`	Điều kiện dùng	Người thay thế
Tiếp nhận sự cố	`<vai trò Service Desk hoặc tương đương>`	`<URL cổng ticket hoặc địa chỉ nhóm không chứa bí mật>`	`<HH:MM-HH:MM; ngày áp dụng>`	`<mọi incident hoặc điều kiện cụ thể>`	`<vai trò thay thế>`
Hỗ trợ nghiệp vụ	`<vai trò SME nghiệp vụ>`	`<kênh dự án được kiểm soát>`	`<khung giờ>`	`<câu hỏi quy trình hoặc dữ liệu nghiệp vụ>`	`<vai trò thay thế>`
Hỗ trợ kỹ thuật	`<vai trò ứng dụng/hạ tầng/tích hợp>`	`<kênh kỹ thuật được kiểm soát>`	`<khung giờ>`	`<lỗi kỹ thuật đủ điều kiện>`	`<vai trò thay thế>`
Escalation khẩn	`<incident manager hoặc vai trò trực>`	`<kênh khẩn được phê chuẩn>`	`<24x7 hoặc khung giờ>`	`<P1 hoặc điều kiện khẩn>`	`<vai trò thay thế>`

Mẫu tham chiếu bí mật an toàn: ghi <secret reference: <tên vault>/<tên secret>/<phiên bản hoặc alias>>; không ghi mật khẩu, API key, token, chuỗi kết nối, mã OTP, ảnh màn hình bí mật hoặc dữ liệu định danh cá nhân. Quyền truy cập phải được yêu cầu qua quy trình quản lý truy cập đã được kiểm soát.

2.5. Tiếp nhận, phân loại và cam kết xử lý

Trường	Giá trị điền	Hướng dẫn và kiểm tra
Công cụ ticket	`<tên công cụ và URL nội bộ nếu được phép>`	Bắt buộc. Ticket là bản ghi truy vết của yêu cầu hoặc sự cố.
Trường ticket tối thiểu	`<ID, người báo, thời điểm, dịch vụ, mô tả, tác động, mức ưu tiên, bằng chứng, owner>`	Bắt buộc. Không cho phép ticket thiếu tác động và người chịu trách nhiệm.
Mức ưu tiên cho phép	`<P1, P2, P3, P4 hoặc taxonomy dự án>`	Bắt buộc. Không dùng “khẩn” mà không có định nghĩa.
Tiêu chí P1	`<tác động, số người dùng, rủi ro an toàn, tài chính hoặc vận hành>`	Bắt buộc. Cần tiêu chí quan sát được.
Tiêu chí P2	`<tác động đáng kể nhưng có phương án tạm thời hoặc phạm vi hạn chế>`	Bắt buộc.
Tiêu chí P3	`<tác động trung bình, không chặn quy trình cốt lõi>`	Bắt buộc.
Tiêu chí P4	`<yêu cầu thông tin, cải tiến hoặc lỗi tác động thấp>`	Bắt buộc.
SLA phản hồi	`<thời gian phản hồi theo từng mức ưu tiên>`	“SLA” là cam kết mức dịch vụ. Ghi rõ giờ lịch hay giờ làm việc.
SLA khôi phục hoặc giải quyết	`<thời gian mục tiêu theo từng mức ưu tiên>`	Phân biệt khôi phục tạm thời với sửa triệt để.
Quy tắc đóng ticket	`<tiêu chí xác nhận, thời gian chờ, vai trò được đóng>`	Không đóng chỉ vì không thấy phản hồi nếu quy tắc chưa cho phép.

2.6. Quy trình xử lý sự cố và ngoại lệ

Bước	Hành động	Đầu vào bắt buộc	Đầu ra bắt buộc	Quy tắc quyết định
1. Ghi nhận	`<cách tạo hoặc cập nhật ticket>`	`<thông tin người báo và mô tả>`	`<ticket ID>`	`<khi thông tin thiếu, yêu cầu bổ sung hoặc phân loại tạm>`
2. Xác minh	`<kiểm tra khả năng tái hiện và phạm vi>`	`<bằng chứng không chứa bí mật>`	`<kết quả xác minh>`	`<không tái hiện được thì ghi điều kiện đã kiểm tra>`
3. Phân loại	`<gán dịch vụ, tác động, ưu tiên>`	`<tiêu chí ưu tiên>`	`<priority và owner>`	`<không đủ thẩm quyền thì escalation>`
4. Khắc phục	`<workaround hoặc sửa lỗi trong phạm vi>`	`<runbook hoặc hướng dẫn được kiểm soát>`	`<hành động và kết quả>`	`<không dùng thay đổi khẩn không được ủy quyền>`
5. Xác nhận	`<xác nhận dịch vụ hoặc người dùng>`	`<tiêu chí thành công>`	`<trạng thái phục hồi>`	`<không có xác nhận thì áp dụng quy tắc đóng ticket>`
6. Đóng và học lại	`<đóng ticket, cập nhật knowledge base nếu phù hợp>`	`<bản ghi đầy đủ>`	`<lý do đóng và bài học>`	`<sự cố lặp lại phải tạo liên kết problem record nếu quy trình có>`

Loại ngoại lệ	Điều kiện kích hoạt	Hành động bắt buộc	Owner quyết định	Giới hạn
Mất dữ liệu hoặc nghi mất dữ liệu	`<điều kiện phát hiện>`	`<dừng thao tác ghi, bảo toàn bằng chứng, escalation>`	`<vai trò có thẩm quyền>`	Không tự chạy script sửa dữ liệu.
Nghi ngờ lộ bí mật hoặc truy cập trái phép	`<dấu hiệu cụ thể>`	`<cô lập theo quy trình an ninh, escalation>`	`<Security owner>`	Không chép bí mật vào ticket.
Ảnh hưởng dữ liệu cá nhân	`<loại dữ liệu và phạm vi>`	`<gắn Verification required, escalation Legal/Privacy owner>`	`<Privacy hoặc Legal owner>`	Không tự kết luận nghĩa vụ pháp lý.
Ảnh hưởng kế toán, thuế hoặc hóa đơn	`<giao dịch, chứng từ hoặc báo cáo bị ảnh hưởng>`	`<dừng kết luận nghiệp vụ, escalation Accounting owner>`	`<Accounting owner>`	Không tự sửa bút toán hoặc diễn giải luật.
Ảnh hưởng an toàn thực phẩm hoặc truy xuất	`<lô hàng, chất lượng hoặc truy xuất bị ảnh hưởng>`	`<escalation domain owner và Legal owner khi cần>`	`<Food-safety/domain owner>`	Không tự xác nhận tuân thủ hoặc thu hồi.

2.7. Runbook, tri thức vận hành và đào tạo

Hạng mục	Giá trị điền	Hướng dẫn và kiểm tra
Runbook ID	`<ID tài liệu hướng dẫn vận hành>`	Bắt buộc cho dịch vụ có thao tác lặp lại hoặc rủi ro cao.
Tên runbook	`<tên thao tác, ví dụ kiểm tra hàng đợi tích hợp>`	Bắt buộc nếu có Runbook ID.
Vị trí kiểm soát	`<đường dẫn hoặc URL kho tài liệu được kiểm soát>`	Bắt buộc nếu có runbook. Không liên kết tệp cá nhân không kiểm soát.
Điều kiện áp dụng	`<mã lỗi, cảnh báo, sự kiện hoặc ngưỡng>`	Bắt buộc.
Điều kiện dừng	`<khi nào không tiếp tục thao tác>`	Bắt buộc. Nêu rõ điều kiện escalation.
Quyền cần có	`<vai trò quyền, không ghi tài khoản hay bí mật>`	Bắt buộc.
Knowledge base ID	`<ID bài tri thức hoặc N/A kèm lý do>`	“Knowledge base” là kho bài tri thức tái sử dụng.
Đào tạo Tier 1	`<nội dung, người học, cách kiểm tra hiểu biết>`	Bắt buộc.
Đào tạo Tier 2/Tier 3	`<nội dung, người học, cách kiểm tra hiểu biết>`	Bắt buộc nếu có Tier 2 hoặc Tier 3.
Khoảng trống tri thức	`<nội dung chưa đủ, owner, ngày cần hoàn tất>`	Không che giấu khoảng trống. Ghi escalation nếu chặn readiness.

2.8. Quyết định sẵn sàng hỗ trợ

Tiêu chí	Giá trị điền	Bằng chứng cần có	Kết quả
Tuyến hỗ trợ đã xác định	`<Có/Không/Không áp dụng>`	`<ID roster, nhóm trực hoặc tài liệu vai trò>`	`<PASS/FAIL/BLOCKED>`
Kênh ticket hoạt động	`<Có/Không/Không áp dụng>`	`<kết quả kiểm tra tạo ticket tổng hợp>`	`<PASS/FAIL/BLOCKED>`
Phân loại ưu tiên rõ	`<Có/Không>`	`<liên kết tiêu chí P1-P4>`	`<PASS/FAIL/BLOCKED>`
Runbook tối thiểu sẵn có	`<Có/Không/Không áp dụng>`	`<Runbook ID hoặc lý do N/A>`	`<PASS/FAIL/BLOCKED>`
Quyền hỗ trợ được kiểm tra	`<Có/Không/Không áp dụng>`	`<tham chiếu yêu cầu quyền hoặc kết quả kiểm tra không chứa bí mật>`	`<PASS/FAIL/BLOCKED>`
Escalation khẩn rõ	`<Có/Không>`	`<bảng liên hệ và điều kiện escalation>`	`<PASS/FAIL/BLOCKED>`
Rủi ro còn lại được ghi nhận	`<Có/Không>`	`<Risk ID hoặc mô tả rủi ro>`	`<PASS/FAIL/BLOCKED>`
Quyết định readiness	`<READY/READY_WITH_CONDITIONS/NOT_READY>`	`<lý do dựa trên các dòng tiêu chí>`	`<ngày và vai trò ghi nhận>`

Quy tắc quyết định: READY chỉ dùng khi mọi tiêu chí bắt buộc là PASS. READY_WITH_CONDITIONS chỉ dùng khi điều kiện, owner, hạn hoàn tất và rủi ro tạm chấp nhận được ghi rõ bởi vai trò có thẩm quyền. NOT_READY dùng khi có FAIL hoặc BLOCKED trên tiêu chí bắt buộc. Kết quả là đánh giá hỗ trợ, không phải approval, baseline, xác nhận compliance hay cho phép production.

Sổ theo dõi quyết định, ngoại lệ, bằng chứng, truy vết, phiên bản và review

Dùng khối này cho mọi bản ghi Support Readiness (mức sẵn sàng hỗ trợ). Mỗi dòng là một đối tượng kiểm soát riêng: quyết định, ngoại lệ, bằng chứng, liên kết truy vết, thay đổi phiên bản, vòng review hoặc sign-off. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ điền dữ liệu tổng hợp. IN_REVIEW nghĩa đang review, không phải phê duyệt, baseline, sẵn sàng production hay xác nhận tuân thủ.

Trường quyết định	Giá trị cần điền	Quy tắc kiểm tra
Decision ID	`<ID quyết định đã đăng ký trong TRACEABILITY_ID_REGISTRY>`	Bắt buộc. Giữ nguyên ID canonical; không tự tạo biến thể.
Chủ đề quyết định	`<một câu nêu việc cần chọn, ví dụ phạm vi hỗ trợ sau go-live>`	Bắt buộc. Nêu một việc, không gộp nhiều việc.
Phương án A	`<mô tả phương án A>`	Bắt buộc. Có thể thực hiện và kiểm tra được.
Phương án B	`<mô tả phương án B hoặc ghi Không có phương án B kèm lý do>`	Bắt buộc. Không để trống.
Tiêu chí chọn	`<chi phí, rủi ro, SLA, năng lực đội ngũ, tác động người dùng>`	Bắt buộc. Mỗi tiêu chí phải có bằng chứng hoặc giả định gắn kèm.
Quyết định đề xuất	`<A hoặc B hoặc Escalate>`	Chỉ dùng `A`, `B`, `Escalate`, `Không quyết định`.
Cầu nối lý do-bằng chứng	`<bằng chứng ID hoặc giả định ID>; <lý do phương án đáp ứng tiêu chí>`	Bắt buộc. Không kết luận nếu không có bằng chứng, giả định hoặc escalation.
Người có thẩm quyền quyết định	`<vai trò, không ghi tên cá nhân nếu chưa được cung cấp>`	Bắt buộc. BA không tự thay Business Owner, Architect, Security, Legal, Accounting hay QA.
Trạng thái	`<PROPOSED\|IN_REVIEW\|ESCALATED\|DECIDED\|REJECTED>`	Chỉ chọn giá trị cho phép. `DECIDED` cần tham chiếu quyết định được ghi nhận.
Ngày ghi nhận	`<YYYY-MM-DD>`	Bắt buộc. Dùng `Asia/Ho_Chi_Minh`.

Trường ngoại lệ	Giá trị cần điền	Quy tắc kiểm tra
Exception ID	`<ID ngoại lệ đã đăng ký trong TRACEABILITY_ID_REGISTRY>`	Bắt buộc. Không dùng ID của requirement, risk hoặc decision thay thế.
Nội dung không đáp ứng	`<điều kiện Support Readiness chưa đáp ứng>`	Bắt buộc. Nêu điều kiện đo được.
Phạm vi ảnh hưởng	`<quy trình, nhóm người dùng, hệ thống, dữ liệu hoặc môi trường mô phỏng>`	Bắt buộc. Không suy diễn production.
Lý do ngoại lệ	`<nguyên nhân có bằng chứng hoặc giả định>`	Bắt buộc. Gắn Evidence ID hoặc Assumption ID.
Mức độ	`<LOW\|MEDIUM\|HIGH\|CRITICAL>`	Bắt buộc. Tiêu chí xếp mức phải ghi ở trường lý do.
Kiểm soát tạm thời	`<biện pháp giảm rủi ro và người chịu trách nhiệm theo vai trò>`	Bắt buộc khi mức độ là `MEDIUM`, `HIGH` hoặc `CRITICAL`.
Điều kiện hết hiệu lực	`<sự kiện hoặc ngày kiểm tra lại>`	Bắt buộc. Không dùng ngày mơ hồ.
Hướng xử lý	`<ACCEPT_WITH_AUTHORITY\|REMEDIATE\|ESCALATE\|REJECT>`	Chỉ chọn giá trị cho phép. `ACCEPT_WITH_AUTHORITY` cần người có thẩm quyền ghi nhận.
Owner xử lý	`<vai trò chịu trách nhiệm>`	Bắt buộc.
Trạng thái	`<OPEN\|MONITORING\|RESOLVED\|EXPIRED\|ESCALATED>`	`RESOLVED` cần Evidence ID xác nhận.

Trường bằng chứng	Giá trị cần điền	Quy tắc kiểm tra
Evidence ID	`<ID bằng chứng đã đăng ký trong TRACEABILITY_ID_REGISTRY>`	Bắt buộc. Một Evidence ID chỉ trỏ một đối tượng bằng chứng.
Loại bằng chứng	`<DEMO\|TEST_RESULT\|RUNBOOK\|TRAINING_RECORD\|ACCESS_REVIEW\|INCIDENT_DRILL\|SOURCE_RECORD\|ASSUMPTION>`	Chỉ chọn giá trị cho phép. `ASSUMPTION` không chứng minh kiểm thử hay tuân thủ.
Mô tả	`<bằng chứng chứng minh điều gì, phạm vi nào>`	Bắt buộc. Phân biệt dữ kiện với suy luận.
Vị trí kiểm soát	`<đường dẫn tệp canonical hoặc URL chính thức>`	Bắt buộc. URL dùng ngày truy cập `2026-08-07` nếu là nguồn seed.
Phân loại nguồn	`<PRIMARY_OFFICIAL\|LICENSED_STANDARD\|PROJECT_ASSUMPTION\|SYNTHETIC_CASE_DATA\|INTERNAL_WORKING_ARTIFACT>`	Bắt buộc. Không gọi `PROJECT_ASSUMPTION` là quy định hay fact.
Ngày tạo hoặc truy cập	`<YYYY-MM-DD>`	Bắt buộc. Dùng `Asia/Ho_Chi_Minh` cho record nội bộ.
Người ghi nhận	`<vai trò>`	Bắt buộc.
Tính bí mật	`<PUBLIC\|INTERNAL\|CONFIDENTIAL\|SECRET_REFERENCE_ONLY>`	Chỉ chọn giá trị cho phép.
Tham chiếu bí mật an toàn	`<vault://tên-kho/đường-dẫn/phiên-bản hoặc Không áp dụng>`	Không ghi mật khẩu, token, API key, chuỗi kết nối, PII hoặc bí mật vào template.
Kết quả kiểm tra	`<PASS\|FAIL\|PARTIAL\|NOT_EXECUTED\|NOT_APPLICABLE>`	`PASS` hoặc `FAIL` phải nêu tiêu chí kiểm tra tại mô tả.

Trường truy vết	Giá trị cần điền	Quy tắc kiểm tra
Trace Link ID	`<ID liên kết đã đăng ký trong TRACEABILITY_ID_REGISTRY>`	Bắt buộc.
Nguồn	`<Artifact ID canonical>:<ID nguồn>`	Bắt buộc. Ví dụ định dạng: `<CANONICAL_BUSINESS_RULES>:<ID quy tắc canonical>`. Không tự bịa ID.
Đích	`<Artifact ID canonical>:<ID đích>`	Bắt buộc. Đích phải thuộc Support Readiness hoặc artifact liên quan.
Loại liên kết	`<DERIVED_FROM\|SATISFIED_BY\|VERIFIED_BY\|CONSTRAINED_BY\|EXCEPTION_TO\|REVIEWED_BY>`	Chỉ chọn giá trị cho phép.
Cầu nối suy luận	`<nguồn nói gì>; <đích phản ánh điều đó thế nào>`	Bắt buộc. Đây là lý do liên kết, không phải trích dẫn bịa đặt.
Trạng thái liên kết	`<VALID\|PENDING_VERIFICATION\|BROKEN\|RETIRED>`	`VALID` cần nguồn và đích tồn tại, đọc được, đúng ID.
Người kiểm tra	`<vai trò>`	Bắt buộc.
Ngày kiểm tra	`<YYYY-MM-DD>`	Bắt buộc.

Trường phiên bản và thay đổi	Giá trị cần điền	Quy tắc kiểm tra
Artifact ID	`TMPL-OPS-003`	Cố định. Không đổi.
Tên tệp	`/03-templates/TMPL-OPS-003--support-readiness.md`	Cố định. Không đổi.
Phiên bản trước	`<vX.Y.Z hoặc Chưa có phiên bản trước>`	Bắt buộc.
Phiên bản hiện hành	`<vX.Y.Z>`	Bắt buộc. Với bản hiện hành của corpus dùng `v0.9.0`.
Status	`<IN_REVIEW\|BASELINED\|RETIRED>`	Với bản hiện hành dùng `IN_REVIEW`. Không ghi `APPROVED` nếu không có approval reference.
Ngày thay đổi	`<YYYY-MM-DD>`	Bắt buộc.
Múi giờ	`Asia/Ho_Chi_Minh`	Cố định cho corpus.
Tóm tắt thay đổi	`<thay đổi gì, tác động bảng nào, ID nào>`	Bắt buộc. Không ghi thay đổi mơ hồ.
Lý do thay đổi	`<evidence ID, issue ID hoặc yêu cầu review>`	Bắt buộc.
Baseline reference	`<tham chiếu baseline được ghi nhận hoặc Chưa có baseline reference>`	Không suy diễn baseline từ version hay status.
Approval reference	`<tham chiếu approval được ghi nhận hoặc Chưa có approval reference>`	Không suy diễn approval từ review, chữ ký hay vai trò Owner.

Trường review và sign-off	Giá trị cần điền	Quy tắc kiểm tra
Review ID	`<ID review đã đăng ký trong TRACEABILITY_ID_REGISTRY>`	Bắt buộc.
Loại review	`<BA\|OPERATIONS\|SERVICE_DESK\|QA\|SECURITY\|ARCHITECTURE\|LEGAL\|ACCOUNTING\|FOOD_SAFETY>`	Chỉ chọn loại phù hợp phạm vi. Nội dung pháp lý, kế toán, an toàn thực phẩm cần vai trò có thẩm quyền.
Phạm vi review	`<bảng, Decision ID, Exception ID, Evidence ID hoặc Trace Link ID được review>`	Bắt buộc.
Reviewer role	`<vai trò reviewer>`	Bắt buộc. Không dùng Owner artifact thay cho reviewer độc lập khi cần phân tách trách nhiệm.
Kết quả review	`<ACCEPT\|ACCEPT_WITH_COMMENTS\|REWORK_REQUIRED\|ESCALATE\|NOT_REVIEWED>`	`ACCEPT` chỉ là kết quả review; không tự tạo approval.
Nhận xét hoặc lý do	`<nhận xét kiểm tra được; Evidence ID hoặc Issue ID liên quan>`	Bắt buộc. Không bịa trích dẫn, clause hoặc xác nhận người dùng.
Ngày review	`<YYYY-MM-DD>`	Bắt buộc.
Sign-off authority role	`<vai trò có thẩm quyền hoặc Không áp dụng tại IN_REVIEW>`	Chỉ điền khi quy trình quản trị có sign-off hợp lệ.
Sign-off status	`<NOT_REQUESTED\|PENDING\|RECORDED\|REJECTED\|NOT_APPLICABLE>`	Với `IN_REVIEW`, không ghi `RECORDED` nếu thiếu approval reference.
Sign-off reference	`<tham chiếu record được kiểm soát hoặc Chưa có approval reference>`	Bắt buộc.
Ngày sign-off	`<YYYY-MM-DD hoặc Không áp dụng tại IN_REVIEW>`	Không điền ngày giả định.

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

Dùng dấu giữ chỗ mô tả trong ngoặc nhọn góc, ví dụ <Tên hệ thống được hỗ trợ>. Dấu giữ chỗ chỉ được tồn tại ở Tier 2. Tier 3 phải thay toàn bộ bằng dữ liệu tổng hợp Nova Foods Trading & Manufacturing, không để trống trường bắt buộc. “Validation” là kiểm tra dữ liệu có đúng định dạng, phạm vi và quan hệ logic trước khi record được xem xét.

Trường mẫu	Hướng dẫn điền	Giá trị hợp lệ	Quy tắc kiểm tra
`<Mã hồ sơ hỗ trợ>`	Điền ID đã đăng ký trong nguồn canonical; không tự đặt ID gần giống.	`<ID canonical đã đăng ký>`	Phải khớp chính xác registry; không chứa khoảng trắng đầu-cuối.
`<Tên dịch vụ hoặc mô-đun ERP>`	Nêu dịch vụ người dùng cần hỗ trợ, không ghi tên người hoặc mật khẩu.	`<Tên mô-đun>`, `<Tên API>`, `<Tên báo cáo>`	Bắt buộc; tối đa 120 ký tự; phải nhất quán với phạm vi hồ sơ.
`<Mức hỗ trợ>`	Chọn tier xử lý đầu tiên. Tier 1 xử lý hướng dẫn chuẩn; Tier 2 phân tích cấu hình hoặc dữ liệu; Tier 3 xử lý lỗi kỹ thuật chuyên sâu hoặc nhà cung cấp.	`Tier 1`, `Tier 2`, `Tier 3`	Chọn đúng một giá trị. Nếu chọn `Tier 3`, phải điền `<Đơn vị escalation>`.
`<Mức độ ưu tiên>`	Xác định theo tác động và tính khẩn cấp, không theo cấp bậc người báo.	`P1`, `P2`, `P3`, `P4`	P1 phải có `<Tác động nghiêm trọng>`, `<Kênh liên lạc khẩn>`, `<Chủ sở hữu xử lý>`. P4 không được ghi thời gian phản hồi khẩn.
`<Tác động nghiệp vụ>`	Mô tả chức năng, nhóm bị ảnh hưởng, số lượng ước tính và hậu quả quan sát được.	`<Mô tả kiểm chứng được>`	Không dùng kết luận chưa có bằng chứng. Phải nêu nguồn quan sát như ticket, log đã che dữ liệu, hoặc báo cáo tổng hợp.
`<Dữ liệu cá nhân hoặc dữ liệu nhạy cảm liên quan>`	Chọn mức phân loại theo thông tin thực sự xuất hiện trong hồ sơ.	`Không có`, `Có - đã giảm thiểu`, `Có - cần escalation Security/Privacy`	Nếu chọn giá trị thứ ba, không chép dữ liệu nhạy cảm vào template; phải điền `<Tham chiếu sự cố an toàn>` và `<Vai trò nhận escalation>`. Yêu cầu pháp lý phải gắn nhãn `Verification required`.
`<Bằng chứng>`	Ghi tham chiếu có thể kiểm tra lại, không chép bí mật hoặc dữ liệu cá nhân.	`<URL nội bộ được phép>`, `<Mã ticket>`, `<Đường dẫn log đã che dữ liệu>`, `<Ảnh chụp đã che dữ liệu>`	Mỗi bằng chứng phải có nguồn, thời điểm `Asia/Ho_Chi_Minh`, người ghi nhận và kết quả kiểm tra. Không dùng bằng chứng không xác định nguồn.
`<Tham chiếu bí mật an toàn>`	Chỉ ghi định danh tham chiếu đến kho bí mật được phép. Không ghi secret, token, API key, mật khẩu, chuỗi kết nối hoặc cookie.	`<secret://vault-path#version>`, `<ID secret manager được phép>`	Không được chứa giá trị bí mật. Nếu cần quyền truy cập, ghi `<Vai trò được cấp quyền>` và quy trình yêu cầu quyền, không ghi thông tin đăng nhập.
`<Quyết định xử lý>`	Ghi quyết định có căn cứ: xử lý tại chỗ, escalation, chấp nhận rủi ro tạm thời, hoặc dừng.	`Xử lý tại Tier 1`, `Escalate Tier 2`, `Escalate Tier 3`, `Dừng và chờ quyết định có thẩm quyền`	Phải liên kết `<Bằng chứng>`, `<Lý do quyết định>` và `<Vai trò chịu trách nhiệm>`. Quyết định pháp lý, kế toán, an ninh hoặc sản xuất phải escalation đúng owner.
`<Ngoại lệ>`	Chỉ ghi điều kiện lệch quy trình chuẩn, thời hạn, phạm vi và người có thẩm quyền quyết định.	`Không có`, `<Ngoại lệ có kiểm soát>`	Nếu có ngoại lệ, bắt buộc điền `<Lý do>`, `<Rủi ro>`, `<Biện pháp giảm thiểu>`, `<Ngày hết hạn>` và `<Tham chiếu quyết định>`. `IN_REVIEW` không chứng minh ngoại lệ đã được chấp thuận.
`<Trạng thái hồ sơ>`	Phản ánh trạng thái hiện tại, không suy diễn approval.	`Draft`, `IN_REVIEW`, `Blocked`, `Closed`	Hồ sơ này dùng `IN_REVIEW` tại `v0.9.0`. Không dùng `Approved` hoặc `Baselined` khi thiếu tham chiếu kiểm soát tương ứng.
`<Phiên bản và lịch sử thay đổi>`	Ghi phiên bản, ngày, người thay đổi và nội dung thay đổi kiểm chứng được.	`<Phiên bản theo quy ước corpus>`, `<YYYY-MM-DD>`, `<Mô tả thay đổi>`	Ngày theo `Asia/Ho_Chi_Minh`; không sửa im lặng nội dung đã review.
`<Theo dõi review và sign-off>`	Ghi vai trò review, kết quả, ngày và tham chiếu quyết định. “Sign-off” là xác nhận chính thức của người có thẩm quyền, không phải việc đọc tài liệu.	`Chưa yêu cầu`, `Đang review`, `Cần escalation`, `Đã ghi nhận quyết định`	Không ghi tên người là đã phê duyệt nếu không có bằng chứng. Khi chưa có tham chiếu, ghi `<Chưa có tham chiếu quyết định>` thay vì suy diễn approval.

Điều kiện hiển thị: chỉ mở phần <Chi tiết escalation Tier 3> khi <Mức hỗ trợ> là Tier 3; chỉ mở phần <Sự cố dữ liệu nhạy cảm> khi trường phân loại dữ liệu yêu cầu escalation; chỉ mở phần <Ngoại lệ> khi giá trị ngoại lệ khác Không có. Mọi ví dụ Nova Foods ở Tier 3 phải là mô phỏng giáo dục, dữ liệu tổng hợp, dùng vi-VN, Asia/Ho_Chi_Minh và VND.

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.

Trường hồ sơ	Giá trị đã điền
Mã hồ sơ hỗ trợ	`SR-NF-2026-0047`
Artifact ID	`TMPL-OPS-003`
Tên artifact	`Support Readiness`
Tệp kiểm soát	`/03-templates/TMPL-OPS-003--support-readiness.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ờ	`Asia/Ho_Chi_Minh`
Locale và tiền tệ	`vi-VN`; `VND`
Hệ thống chịu ảnh hưởng	Nova Foods ERP mô phỏng, phân hệ Bán hàng và Kho
Môi trường	`UAT-NF-01` mô phỏng
Mức hỗ trợ	`Tier 2` — hỗ trợ chuyên môn ứng dụng, xử lý sau khi Tier 1 đã tái hiện và thu thập dữ liệu
Mức độ sự cố	`P2` — giao dịch xuất kho bị chặn, chưa có bằng chứng mất dữ liệu
Người lập hồ sơ	Lê Minh An, IT Business Analyst mô phỏng
Người báo lỗi	Trần Quốc Huy, Nhân viên điều phối kho mô phỏng
Nhóm nhận xử lý	`ERP-SALES-WMS` mô phỏng
Quyền quyết định nghiệp vụ	Phạm Gia Bảo, Sales Operations Manager mô phỏng
Quyền quyết định kỹ thuật	Nguyễn Thùy Linh, ERP Solution Architect mô phỏng
Quyền xác nhận dữ liệu kế toán	Vũ Khánh Vy, Accounting Owner mô phỏng
Phân loại nguồn	`SIMULATED_PROJECT_EVIDENCE` — bằng chứng dự án mô phỏng, không phải nguồn pháp lý, cấu hình production hay xác nhận vận hành thực tế

3.1 Bối cảnh và yêu cầu hỗ trợ

Ngày 2026-08-07 09:18:26 theo Asia/Ho_Chi_Minh, nhân viên kho báo không thể xác nhận xuất kho cho đơn bán SO-NF-260807-0142. “Support readiness” nghĩa là mức sẵn sàng của con người, quy trình, dữ liệu, quyền truy cập và bằng chứng để nhóm hỗ trợ tiếp nhận, tái hiện, phân loại và chuyển đúng sự cố. Hồ sơ này ghi tình trạng sẵn sàng cho một sự cố cụ thể, không chứng minh Nova Foods thật đang vận hành ERP.

Thành phần	Dữ liệu mô phỏng đã xác định
Khách hàng	`CUS-NF-00318` — Công ty TNHH Thực phẩm An Phú mô phỏng
Đơn bán	`SO-NF-260807-0142`
Kho xuất	`WH-HCM-01` — Kho Thành phẩm Hồ Chí Minh mô phỏng
Phiếu yêu cầu xuất	`PICK-NF-260807-0881`
Mã hàng	`FG-NF-CHA-500G` — Chả cá viên 500 g mô phỏng
Lô hàng	`LOT-CHA-260801-A`
Số lượng đặt	`240` gói
Số lượng đã giữ hàng	`240` gói
Đơn giá chưa thuế	`58.000 VND/gói`
Giá trị hàng chưa thuế	`13.920.000 VND`
Thuế suất hiển thị trên đơn	`8%` — dữ liệu mô phỏng; cần Accounting Owner xác minh trước mọi dùng thực tế
Tổng giá trị hiển thị	`15.033.600 VND`
Thời điểm cần giao mô phỏng	`2026-08-07 14:00:00`
Thông báo lỗi	`Inventory status HOLD does not allow shipment confirmation.`
Màn hình phát sinh	`Sales > Fulfillment > Shipment Confirmation`
Tài khoản thao tác	`huy.tran.wh01` mô phỏng
Vai trò truy cập	`Warehouse Dispatcher` mô phỏng

3.2 Sự kiện, sự thật và hành vi hiện tại

Sự thật là trạng thái tồn kho của lô LOT-CHA-260801-A hiển thị HOLD lúc xác nhận xuất kho. Bằng chứng là ảnh chụp mô phỏng EVD-NF-2026-0047-01 ghi đúng thông báo lỗi, cùng nhật ký mô phỏng LOG-NF-UAT-20260807-091826-447 ghi yêu cầu từ tài khoản huy.tran.wh01. Cầu nối suy luận: ERP chặn xác nhận xuất khi lô ở HOLD; cùng lô vẫn đang giữ đủ 240 gói cho đơn; vì vậy lỗi không phải thiếu tồn khả dụng mà là xung đột giữa giữ hàng và trạng thái chất lượng của lô.

Mốc thời gian	Sự kiện mô phỏng	Sự thật kiểm tra được	Phân loại nguồn
`2026-08-07 08:42:11`	Đơn `SO-NF-260807-0142` được tạo	Tổng tiền hiển thị `15.033.600 VND`; trạng thái `Confirmed`	`SIMULATED_TRANSACTION_RECORD`
`2026-08-07 08:44:03`	Hệ thống giữ `240` gói từ lô `LOT-CHA-260801-A`	Reservation ID `RSV-NF-260807-3229` có trạng thái `Active`	`SIMULATED_TRANSACTION_RECORD`
`2026-08-07 09:05:14`	Điều phối kho tạo yêu cầu xuất	`PICK-NF-260807-0881` có trạng thái `Released`	`SIMULATED_TRANSACTION_RECORD`
`2026-08-07 09:12:47`	Kiểm tra chất lượng đổi lô sang `HOLD`	Quality hold ID `QH-NF-260807-019` có lý do `Awaiting label verification`	`SIMULATED_TRANSACTION_RECORD`
`2026-08-07 09:18:26`	Xác nhận xuất bị từ chối	Lỗi `Inventory status HOLD does not allow shipment confirmation.`	`SIMULATED_SYSTEM_LOG`
`2026-08-07 09:26:40`	Tier 1 tái hiện lỗi trên `UAT-NF-01`	Lặp lại lỗi với cùng đơn, không sửa dữ liệu	`SIMULATED_SUPPORT_NOTE`

3.3 Nhu cầu gốc và phạm vi xử lý

Nhu cầu gốc là cho phép kho xử lý đơn đúng hạn mà không xuất lô đang bị kiểm tra nhãn. Không được hiểu nhu cầu này là “bỏ chặn mọi lô HOLD”. Lý do: HOLD là trạng thái kiểm soát chất lượng trong case mô phỏng; tự bỏ chặn có thể làm xuất hàng chưa được xác minh. Phạm vi hỗ trợ gồm phân loại lỗi, xác định chủ sở hữu quyết định, kiểm tra lô thay thế và ghi nhận quyết định. Phạm vi không gồm sửa quy tắc chất lượng, mở khóa trực tiếp dữ liệu hay thay đổi thuế, kế toán hoặc hóa đơn.

Hạng mục	Có trong phạm vi	Lý do
Tái hiện lỗi tại `UAT-NF-01`	Có	Xác nhận lỗi có thể lặp lại trước khi chuyển Tier 2
Kiểm tra tồn kho lô thay thế	Có	Xác định phương án giao hàng ít rủi ro hơn
Đổi lô giữ hàng trên đơn	Có điều kiện	Chỉ thực hiện sau quyết định của Sales Operations Manager và xác nhận chất lượng mô phỏng
Gỡ `HOLD` cho `LOT-CHA-260801-A`	Không	Thuộc quyết định chất lượng; nhóm hỗ trợ không có thẩm quyền
Sửa trực tiếp trạng thái trong DB	Không	Có nguy cơ phá vỡ kiểm soát dữ liệu và lịch sử giao dịch
Thay đổi thuế suất hoặc chứng từ	Không	Cần Accounting Owner và xác minh pháp lý/kế toán riêng

3.4 Đánh giá phương án và quyết định cần có

Mã	Phương án	Điều kiện đánh giá	Kết quả đánh giá	Hệ quả nếu chọn sai
`OPT-01`	Giữ đơn, chờ Quality Lead gỡ `HOLD`	Giao đúng hạn; không phá kiểm soát chất lượng; thời gian phản hồi	Không đạt thời hạn giao `14:00:00` nếu kiểm tra nhãn kéo dài quá `4` giờ	Đơn giao trễ; khách hàng có thể không nhận hàng theo lịch mô phỏng
`OPT-02`	Đổi reservation sang lô `LOT-CHA-260802-B`, còn `360` gói trạng thái `Released`	Đủ số lượng; cùng mã hàng; lô được phép xuất; có thẩm quyền nghiệp vụ và chất lượng	Đạt nếu Quality Lead mô phỏng xác nhận lô thay thế phù hợp và Sales Operations Manager quyết định đổi lô	Xuất sai lô hoặc sai điều kiện chất lượng nếu không xác nhận hai điều kiện
`OPT-03`	Gỡ `HOLD` trực tiếp cho lô hiện tại	Tính toàn vẹn trạng thái; phân quyền; khả năng kiểm toán	Loại. Không có bằng chứng nhãn đã được xác minh	Có thể xuất hàng đang bị kiểm soát; lịch sử quyết định không đáng tin

Khuyến nghị: chọn OPT-02. Bằng chứng: lô LOT-CHA-260802-B có 360 gói, lớn hơn nhu cầu 240 gói; trạng thái mô phỏng là Released; cùng mã FG-NF-CHA-500G. Cầu nối suy luận: đủ số lượng và cùng mã hàng giải quyết thiếu hụt do lô bị giữ, nhưng trạng thái chất lượng của lô thay thế vẫn phải được xác nhận trước khi đổi reservation.

Quyết định cần ghi nhận: Phạm Gia Bảo, Sales Operations Manager mô phỏng, có quyền quyết định ưu tiên giao hàng và đổi lô cho đơn. Nguyễn Thị Mai, Quality Lead mô phỏng, phải xác nhận lô LOT-CHA-260802-B đủ điều kiện xuất trong case. Hồ sơ đang IN_REVIEW; chưa có tham chiếu quyết định, không có approval hay baseline ngầm định.

3.5 Quy tắc xử lý và trạng thái hồ sơ

Mã quy tắc	Quy tắc mô phỏng	Áp dụng cho hồ sơ
`BR-SR-001`	Không xác nhận xuất kho khi lô được giữ có trạng thái `HOLD`.	Áp dụng; lỗi phát sinh đúng quy tắc.
`BR-SR-002`	Đổi lô giữ hàng chỉ được thực hiện khi mã hàng khớp, số lượng khả dụng đủ và lô thay thế không ở `HOLD`.	`LOT-CHA-260802-B` khớp mã, có `360` gói và trạng thái `Released`.
`BR-SR-003`	Không sửa trực tiếp trạng thái tồn kho để giải quyết lỗi hỗ trợ.	Áp dụng; `OPT-03` bị loại.
`BR-SR-004`	Sự cố có nguy cơ ảnh hưởng chất lượng hàng phải chuyển Quality Lead trước thao tác xuất.	Áp dụng; chờ xác nhận mô phỏng của Nguyễn Thị Mai.

Trạng thái	Thời điểm	Chủ thể	Ý nghĩa
`Logged`	`2026-08-07 09:18:26`	Trần Quốc Huy	Sự cố được báo với thông báo lỗi gốc.
`Reproduced`	`2026-08-07 09:26:40`	Tier 1 Support mô phỏng	Lỗi được tái hiện tại `UAT-NF-01`; không có thay đổi dữ liệu.
`Escalated to Tier 2`	`2026-08-07 09:34:12`	Lê Minh An	Cần kiểm tra xung đột reservation và quality hold.
`Pending Business and Quality Decision`	`2026-08-07 09:41:55`	Nhóm `ERP-SALES-WMS` mô phỏng	Chưa đổi lô, chưa gỡ `HOLD`, chưa xác nhận xuất.
`IN_REVIEW`	`2026-08-07 09:41:55`	Hồ sơ `SR-NF-2026-0047`	Đang xem xét; không phải trạng thái đã phê duyệt hoặc đã xử lý xong.

Hồ sơ hỗ trợ hoàn chỉnh — Nova Foods ERP mô phỏng

Nova Foods Trading & Manufacturing là case học liệu mô phỏng; mọi người, giao dịch, số tiền và dữ liệu dưới đây là tổng hợp. Hồ sơ này ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, locale vi-VN, tiền tệ VND. Không phải baseline, phê duyệt, cấu hình production, kết luận pháp lý hay kết luận kế toán.

Trường lõi	Giá trị đã điền
Support readiness ID	`SUP-READY-NF-003`
Artifact	`TMPL-OPS-003`
Tệp kiểm soát	`/03-templates/TMPL-OPS-003--support-readiness.md`
Hệ thống	Nova Foods ERP mô phỏng
Phân hệ ảnh hưởng	Bán hàng, Kho, Công nợ phải thu
Kịch bản	Nhân viên kho không xác nhận được xuất hàng cho đơn bán `SO-NF-260807-0148` vì ERP báo tồn khả dụng bằng `0` dù lô hàng còn tồn vật lý.
Khách hàng mô phỏng	`CUS-NF-00127 — Siêu thị An Phúc`
Kho xuất	`WH-HCM-01 — Kho Thành phẩm Bình Tân`
Mặt hàng	`FG-NF-CHILI-350 — Tương ớt Nova 350 g`
Lô hàng	`LOT-NF-260701-C350-02`
Số lượng yêu cầu	`240` chai
Đơn giá chưa gồm thuế	`28.500 VND/chai`
Giá trị hàng chưa gồm thuế	`6.840.000 VND`
Thuế suất hiển thị trong tình huống	`10%`
Tổng giá trị dự kiến	`7.524.000 VND`
Nguồn phân loại	`PROJECT_ASSUMPTION — simulated operational scenario`
Chủ sở hữu nghiệp vụ cần quyết định	`ROLE-NF-SALES-OPS-MANAGER`
Đầu mối hỗ trợ cấp 1	`ROLE-NF-SUPPORT-L1`
Đầu mối hỗ trợ cấp 2	`ROLE-NF-ERP-APPLICATION-ANALYST`
Đầu mối dữ liệu kho	`ROLE-NF-WMS-DATA-STEWARD`
Trạng thái hồ sơ	`IN_REVIEW`

Sự kiện khởi tạo. Ngày 2026-08-07 09:12:18 +07:00, USR-NF-WH-014 — Nguyễn Minh Khoa, nhân viên kho mô phỏng, mở yêu cầu INC-NF-260807-0031. Người dùng chọn lệnh xuất DO-NF-260807-0089; ERP trả mã INV-AVL-001 với thông điệp Available quantity is insufficient for item FG-NF-CHILI-350 in warehouse WH-HCM-01. Đây là fact vì mã lỗi, thời điểm, đơn hàng, kho và mặt hàng nằm trong payload sự cố. Không suy ra lỗi tích hợp khi chưa đối chiếu dữ liệu tồn.

Bản ghi tồn tại thời điểm lỗi	Số lượng chai	Trạng thái	Ý nghĩa hỗ trợ
Tồn vật lý do kho đếm lúc `09:18:00`	240	`COUNTED`	Hàng được kho xác nhận đang ở vị trí `BIN-HCM-A03-07`.
Tồn hệ thống	240	`ON_HAND`	ERP ghi nhận hàng đã nhập kho.
Đã giữ cho đơn khác	240	`RESERVED`	Toàn bộ tồn bị giữ bởi `SO-NF-260807-0142`.
Tồn khả dụng	0	`AVAILABLE`	ERP chặn xuất cho đơn `SO-NF-260807-0148`.
Số lượng cần xuất	240	`REQUESTED`	Đơn hiện tại cần toàn bộ số lượng.

Hành vi hiện tại. ERP tính AVAILABLE = ON_HAND - RESERVED. Với 240 - 240 = 0, hệ thống chặn xác nhận xuất. Hành vi này bảo vệ chống xuất vượt lượng chưa bị giữ. Underlying need, tức nhu cầu gốc sau triệu chứng: xác định giữ hàng RES-NF-260807-0194 còn hợp lệ hay đã trở thành dữ liệu cũ do đơn SO-NF-260807-0142 bị hủy trước khi kho xuất hàng.

Dữ liệu giữ hàng	Giá trị đã điền
Reservation ID	`RES-NF-260807-0194`
Đơn nguồn	`SO-NF-260807-0142`
Thời điểm tạo giữ hàng	`2026-08-07 08:41:03 +07:00`
Trạng thái đơn nguồn	`CANCELLED`
Thời điểm hủy đơn nguồn	`2026-08-07 08:58:44 +07:00`
Trạng thái giữ hàng hiện tại	`ACTIVE`
Lý do bất thường	Hủy đơn không chuyển `ACTIVE` thành `RELEASED`.
Phân loại nguyên nhân	`DEFECT_CANDIDATE — project assumption pending technical reproduction`

Quy tắc hỗ trợ áp dụng. Quy tắc BR-NF-INV-017 là quy tắc mô phỏng: khi đơn bán ở trạng thái CANCELLED, mọi reservation đang ACTIVE của đơn đó phải chuyển RELEASED trong cùng giao dịch nghiệp vụ; tồn khả dụng phải được tính lại trước lần kiểm tra xuất tiếp theo. Quy tắc tồn tại vì nếu giữ hàng vẫn hoạt động, ERP khóa hàng không còn phục vụ đơn hợp lệ; nếu giải phóng sai, ERP có thể phân bổ cùng tồn cho hai đơn.

Điều kiện	Hành động bắt buộc trong case mô phỏng	Trạng thái sau hành động
Đơn nguồn `CANCELLED`, reservation `ACTIVE`, chưa có phiếu xuất	L2 kiểm tra nhật ký giao dịch, chạy chức năng giải phóng reservation được cấp quyền	`RELEASED`
Đơn nguồn `CANCELLED`, reservation `ACTIVE`, đã có phiếu xuất	Không giải phóng tự động; khóa sự cố, chuyển quản lý vận hành bán hàng và quản lý kho	`ESCALATED`
Đơn nguồn không phải `CANCELLED`	Không thay đổi reservation	`NO_ACTION`
Tồn vật lý khác tồn hệ thống	Không sửa số lượng trong ERP qua màn hình hỗ trợ; mở đối soát kho	`INVENTORY_RECONCILIATION_REQUIRED`
Có hơn một reservation cùng lô cho các đơn mở	Không ưu tiên thủ công chỉ từ yêu cầu người dùng; chuyển chủ sở hữu nghiệp vụ quyết định phân bổ	`BUSINESS_DECISION_REQUIRED`

Các lựa chọn đã xét. Phương án OPT-01 là sửa trực tiếp tồn khả dụng từ 0 thành 240; loại bỏ vì che giấu reservation còn ACTIVE và có thể làm sai chuỗi kiểm soát tồn. Phương án OPT-02 là hủy rồi tạo lại đơn SO-NF-260807-0148; loại bỏ vì không sửa nguyên nhân tại reservation của đơn khác. Phương án OPT-03 là xác nhận trạng thái hủy, không có phiếu xuất, rồi giải phóng RES-NF-260807-0194; được khuyến nghị vì khôi phục dữ liệu theo quy tắc BR-NF-INV-017 mà không thay đổi số lượng tồn vật lý.

Tiêu chí quyết định	OPT-01 Sửa tồn khả dụng	OPT-02 Tạo lại đơn	OPT-03 Giải phóng reservation
Xử lý nguyên nhân	Không	Không	Có
Bảo toàn audit trail	Không đạt	Đạt một phần	Đạt
Rủi ro xuất trùng	Cao	Trung bình	Thấp sau kiểm tra
Tác động khách hàng	Có thể giao hàng sai	Chậm xử lý	Khôi phục khả năng xuất
Kết quả	Loại	Loại	Khuyến nghị có điều kiện

Quyết định ghi nhận. DEC-NF-SUP-0031 khuyến nghị chọn OPT-03. Authority, tức người có quyền quyết định, là ROLE-NF-SALES-OPS-MANAGER đối với ưu tiên đơn và ROLE-NF-ERP-APPLICATION-ANALYST đối với thao tác ứng dụng sau khi đủ điều kiện kỹ thuật. Chưa có approval được ghi nhận. Nếu quyết định sai và giải phóng một reservation đã gắn với phiếu xuất, cùng 240 chai có thể bị phân bổ hai lần; hậu quả mô phỏng gồm giao thiếu, sai hạch toán doanh thu và tăng công việc đối soát.

Payload sự cố hoàn chỉnh.

{
  "incidentId": "INC-NF-260807-0031",
  "reportedAt": "2026-08-07T09:12:18+07:00",
  "reporterId": "USR-NF-WH-014",
  "severity": "S2",
  "status": "IN_REVIEW",
  "module": "Inventory",
  "salesOrderId": "SO-NF-260807-0148",
  "deliveryOrderId": "DO-NF-260807-0089",
  "warehouseId": "WH-HCM-01",
  "itemId": "FG-NF-CHILI-350",
  "lotId": "LOT-NF-260701-C350-02",
  "requestedQuantity": 240,
  "onHandQuantity": 240,
  "reservedQuantity": 240,
  "availableQuantity": 0,
  "currency": "VND",
  "errorCode": "INV-AVL-001",
  "reservationId": "RES-NF-260807-0194",
  "reservationSourceOrderId": "SO-NF-260807-0142",
  "recommendedAction": "RELEASE_RESERVATION_AFTER_VALIDATION",
  "sourceClassification": "PROJECT_ASSUMPTION — synthetic data only"
}

Trạng thái xử lý. INC-NF-260807-0031 đi từ NEW sang TRIAGED lúc 2026-08-07 09:26:00 +07:00 vì L1 tái hiện được lỗi bằng cùng đơn, kho và mặt hàng. Trạng thái hiện tại là IN_REVIEW vì L2 chưa ghi nhận kết quả kiểm tra phiếu xuất của đơn nguồn. Không được chuyển RES-NF-260807-0194 sang RELEASED, không được xác nhận DO-NF-260807-0089, và không được đóng sự cố trước khi điều kiện trong BR-NF-INV-017 được kiểm tra đầy đủ.

Hồ sơ tình huống Nova Foods: sẵn sàng hỗ trợ lỗi chặn xuất kho theo hạn dùng

Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục; toàn bộ tên người, giao dịch, mã và số tiền là dữ liệu tổng hợp. Ngày ghi nhận 2026-08-07, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND, trạng thái hồ sơ IN_REVIEW, phiên bản v0.9.0. Tình huống kiểm tra mức sẵn sàng của bộ phận hỗ trợ khi ERP chặn phiếu xuất kho vì lô hàng có hạn dùng không đạt quy tắc cấu hình.

Trường lõi	Giá trị đã điền
Support readiness record ID	`SUP-READY-NF-20260807-001`
Đơn vị mô phỏng	Nova Foods Trading & Manufacturing
Quy trình bị ảnh hưởng	Xuất kho thành phẩm cho đơn bán hàng
Giao dịch ERP	`DO-NF-260807-0148`
Đơn bán hàng	`SO-NF-260807-0316`
Kho xuất	`WH-HCM-01`
Khách hàng mô phỏng	`CUS-NF-2048 — Công ty TNHH An Phúc Mart`
Mặt hàng	`FG-CHILI-250G — Tương ớt Nova 250g`
Lô hàng	`LOT-CHILI-260615-A`
Số lượng yêu cầu xuất	`1.200` chai
Đơn giá bán mô phỏng	`18.500 VND/chai`
Giá trị đơn dòng	`22.200.000 VND`
Hạn dùng lô	`2026-08-20`
Ngày giao yêu cầu	`2026-08-08`
Người báo lỗi mô phỏng	`USR-NF-WH-018 — Lê Minh Quân, Điều phối kho`
Kênh tiếp nhận	Cổng hỗ trợ nội bộ, ticket `INC-NF-260807-0091`
Mức ảnh hưởng đề xuất	`P2` — chặn giao một đơn hàng, chưa có bằng chứng ảnh hưởng diện rộng
Đích xử lý	Khôi phục quyết định xuất kho đúng quy tắc hoặc chuyển việc quyết định ngoại lệ đúng thẩm quyền

Sự thật ghi nhận. Lúc 14:20 ngày 2026-08-07, người dùng tạo giao dịch DO-NF-260807-0148. ERP trả trạng thái BLOCKED và thông báo Minimum remaining shelf life not met. Lô LOT-CHILI-260615-A còn 13 ngày đến hạn dùng tại ngày giao yêu cầu 2026-08-08. Người dùng không thể xác nhận xuất kho. Đây là sự thật quan sát từ ticket mô phỏng và dữ liệu giao dịch mô phỏng, phân loại nguồn SIMULATED_OPERATIONAL_RECORD; chưa phải bằng chứng cấu hình production hay kết luận tuân thủ an toàn thực phẩm.

Hành vi hiện tại. Quy tắc cấu hình mô phỏng tính số ngày hạn dùng còn lại theo expiry_date - requested_delivery_date. Nếu kết quả nhỏ hơn 15, hệ thống chặn xác nhận xuất kho; hệ thống không tự chọn lô thay thế và không cho Tier 1 sửa hạn dùng, số lượng hoặc trạng thái chặn. Hành vi này giảm nguy cơ người hỗ trợ tự vượt kiểm soát, nhưng gây chậm giao hàng khi có lô khác đủ điều kiện.

Nhu cầu gốc. Kho cần biết giao dịch bị chặn do dữ liệu lô, do ngày giao, hay do quy tắc; cần đường xử lý có kiểm soát trong ngày để tránh giao sai lô hoặc hủy đơn nhầm. Bộ phận hỗ trợ cần phân biệt incident (sự cố: dịch vụ hoặc giao dịch không đạt hành vi mong đợi) với service request (yêu cầu dịch vụ: yêu cầu thay đổi hoặc thực hiện thao tác được phép). Ticket này là incident ban đầu vì người báo chưa chứng minh quy tắc sai; yêu cầu bỏ chặn thủ công chỉ được tạo sau khi có quyết định nghiệp vụ.

Phương án	Điều kiện dùng	Lợi ích	Rủi ro hoặc hệ quả
`OPT-01` Chọn lô thay thế đủ 15 ngày	Kho còn lô cùng mặt hàng, số lượng đủ, dữ liệu lô hợp lệ	Giữ quy tắc; giao đúng kế hoạch	Có thể tăng chi phí picking hoặc làm lệch kế hoạch phân bổ
`OPT-02` Đổi ngày giao sang `2026-08-07`	Khách hàng và vận hành xác nhận giao sớm; dữ liệu logistics hỗ trợ	Lô còn `14` ngày, vẫn không đạt ngưỡng `15`; không giải quyết chặn	Nếu hiểu sai phép tính, đội hỗ trợ có thể xử lý nhầm
`OPT-03` Yêu cầu ngoại lệ hạn dùng	Business Owner xác nhận chấp nhận ngoại lệ; domain owner và Legal/Compliance Owner xác minh điều kiện áp dụng	Có đường quyết định minh bạch cho trường hợp đặc biệt	Không được suy diễn ngoại lệ từ ticket; có rủi ro chất lượng, hợp đồng, pháp lý hoặc uy tín
`OPT-04` Sửa quy tắc ngưỡng từ 15 xuống 13 ngày	Có phân tích tác động, kiểm thử, quyết định thay đổi đúng thẩm quyền	Có thể giảm chặn cho các lô tương tự	Có thể làm thay đổi kiểm soát hàng loạt; không phải xử lý incident tức thời

Tiêu chí quyết định. Ưu tiên OPT-01 khi tồn kho xác nhận lô thay thế có tối thiểu 1.200 chai và hạn dùng còn lại từ 15 ngày. Nếu không có lô thay thế, Tier 1 phải giữ trạng thái BLOCKED, ghi nhận tác động 22.200.000 VND là giá trị đơn dòng mô phỏng, rồi chuyển OPT-03 cho Business Owner. OPT-04 bị loại khỏi xử lý ticket vì thay đổi quy tắc tác động nhiều giao dịch, cần quy trình thay đổi và kiểm thử riêng.

Khuyến nghị và thẩm quyền quyết định. Khuyến nghị vận hành là OPT-01: kho kiểm tra lô thay thế, sau đó tạo giao dịch xuất kho mới theo lô đạt ngưỡng; Tier 1 chỉ hướng dẫn, đối chiếu dữ liệu và chuyển tuyến. Warehouse Supervisor có thẩm quyền xác nhận khả dụng lô. Sales Operations Lead có thẩm quyền xác nhận tác động lịch giao mô phỏng. Business Owner quyết định có yêu cầu ngoại lệ nghiệp vụ hay không. Legal/Compliance Owner và domain owner phải xác minh mọi điều kiện liên quan pháp lý, an toàn thực phẩm hoặc truy xuất trước khi dùng ngoại lệ. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì hồ sơ học liệu, không phê duyệt ngoại lệ, không xác nhận tuân thủ và không cho phép production.

Hệ quả nếu quyết định sai. Nếu bỏ chặn không có căn cứ, Nova Foods mô phỏng có thể giao lô không đáp ứng ngưỡng nội bộ, làm sai truy xuất và tạo rủi ro khiếu nại. Nếu giữ chặn khi có lô hợp lệ nhưng không kiểm tra, đơn hàng có thể trễ giao và ảnh hưởng doanh thu mô phỏng 22.200.000 VND. Nếu sửa quy tắc thay vì xử lý một giao dịch, các đơn hàng khác có thể bị tác động ngoài phạm vi ticket. Quy tắc hạn dùng trong tình huống này là PROJECT_ASSUMPTION; mọi áp dụng thực tế cần xác minh bởi Business Owner, domain owner, Legal/Compliance Owner và nguồn chính thức phù hợp.

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 mã, người dùng, đơn hàng, lô hàng và bằng chứng dưới đây là dữ liệu tổng hợp. Tình huống: Tier 1 nhận ticket hỗ trợ vì ERP chặn xuất kho cho đơn SO-NF-260807-0142, giá trị đơn dòng mô phỏng 22.200.000 VND. Lô được chọn LOT-NF-COC-260810-A không đạt ngưỡng hạn dùng nội bộ đang áp dụng cho tình huống. Chặn hệ thống là kết quả cần bảo toàn; Tier 1 không sửa quy tắc, không bỏ chặn thủ công, không xác nhận tuân thủ hay chất lượng lô.

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

Đường đi âm (negative path) là tình huống hệ thống hoặc người dùng không đạt điều kiện xử lý bình thường. Ghi nhận đường đi âm giúp Support không biến lỗi dữ liệu, lỗi quyền hoặc ngoại lệ nghiệp vụ thành lỗi phần mềm.

ID hồ sơ	Điều kiện kích hoạt	Hành vi kỳ vọng của ERP	Hành động Tier 1	Kết quả được phép	Kết quả không được phép
`EXC-SR-001`	Người dùng chọn `LOT-NF-COC-260810-A`; số ngày còn lại thấp hơn ngưỡng nội bộ mô phỏng	Chặn xác nhận xuất kho; hiển thị lý do chặn; không tạo giao dịch xuất kho	Đối chiếu đơn, lô, hạn dùng, ngày xử lý; hướng dẫn kiểm tra lô thay thế	Chuyển sang `OPT-01` nếu có lô đạt ngưỡng	Sửa hạn dùng, sửa ngưỡng, xác nhận xuất kho bằng tài khoản khác
`EXC-SR-002`	Không có lô thay thế đạt ngưỡng	Giữ đơn ở trạng thái chặn; không tự đổi lịch giao	Ghi nhận tác động `22.200.000 VND`; chuyển `OPT-03` cho Business Owner	Ticket giữ `BLOCKED` chờ quyết định có thẩm quyền	Đóng ticket với lý do “đã xử lý”
`EXC-SR-003`	Người dùng yêu cầu giảm ngưỡng cho riêng đơn `SO-NF-260807-0142`	Không có thao tác Tier 1 để đổi quy tắc	Từ chối thay đổi trực tiếp; lập escalation thay đổi nghiệp vụ	Chuyển `OPT-04` sang quy trình thay đổi riêng	Sửa rule dùng chung để xử lý một đơn
`EXC-SR-004`	Người dùng không có quyền xem chi tiết lô hoặc tạo giao dịch xuất kho	Từ chối truy cập hoặc thao tác theo quyền hiện có	Kiểm tra ID người dùng, vai trò được gán, thời điểm lỗi; chuyển quản trị quyền	Khôi phục đúng quyền sau xác minh của owner quyền	Cấp quyền rộng hơn phạm vi ticket
`EXC-SR-005`	Mã lô trên đơn không tìm thấy trong dữ liệu kho mô phỏng	Không cho xác nhận xuất kho với lô không tồn tại	Ghi nhận mã nhập, kho, thời điểm; chuyển Warehouse Supervisor kiểm tra dữ liệu nguồn	Sửa dữ liệu theo quyết định owner dữ liệu	Tự tạo lô hoặc thay mã lô không có căn cứ
`EXC-SR-006`	ERP cho phép xuất kho dù lô không đạt ngưỡng nội bộ mô phỏng	Ghi nhận là nghi ngờ lỗi chức năng hoặc cấu hình	Bảo toàn ảnh màn hình, thời điểm, dữ liệu tái hiện; chuyển nhóm ứng dụng	Mở hồ sơ lỗi để phân tích	Kết luận hệ thống lỗi trước khi tái hiện và review

4.2. Bằng chứng hỗ trợ đã ghi nhận

Bằng chứng là dữ liệu có thể kiểm tra lại, dùng để giải thích vì sao ticket được chặn, chuyển tuyến hoặc mở hồ sơ lỗi. Bằng chứng dưới đây chỉ chứng minh tình huống mô phỏng đã ghi nhận; không là bằng chứng vận hành thực, baseline hay phê duyệt.

ID bằng chứng	Loại	Nội dung tổng hợp đã ghi nhận	Nguồn/phân loại	Mục đích sử dụng	Hạn chế
`EVD-SR-001`	Ảnh màn hình mô phỏng	Màn hình xác nhận xuất kho của `SO-NF-260807-0142` hiển thị chặn cho `LOT-NF-COC-260810-A`	Dữ liệu tổng hợp Nova Foods mô phỏng	Chứng minh trạng thái chặn tại thời điểm hỗ trợ	Không xác nhận nguyên nhân kỹ thuật gốc
`EVD-SR-002`	Trích xuất dữ liệu mô phỏng	Đơn hàng, mã lô, kho xuất `WH-HCM-01`, giá trị đơn dòng `22.200.000 VND`	Dữ liệu tổng hợp Nova Foods mô phỏng	Đối chiếu ticket với giao dịch bị ảnh hưởng	Không là chứng từ kế toán hay hóa đơn
`EVD-SR-003`	Nhật ký thao tác mô phỏng	Tier 1 thử xác nhận xuất kho bằng người dùng có quyền hợp lệ; ERP tiếp tục chặn	Dữ liệu tổng hợp Nova Foods mô phỏng	Loại trừ nhập lại giao dịch sai một lần	Chưa thay thế kiểm thử kỹ thuật đầy đủ
`EVD-SR-004`	Danh sách tồn kho mô phỏng	Không tìm thấy lô thay thế đạt ngưỡng tại `WH-HCM-01` khi kiểm tra ticket	Dữ liệu tổng hợp Nova Foods mô phỏng	Cơ sở chuyển `OPT-03`	Tồn kho có thể thay đổi sau thời điểm kiểm tra
`EVD-SR-005`	Nguồn tham khảo	`Luật An toàn thực phẩm`, nguồn chính thức trong `/00-research/00_SOURCE_MAP.md`	Nguồn chính thức; chỉ dùng bối cảnh truy xuất/an toàn thực phẩm	Xác định cần domain owner và Legal/Compliance Owner khi ngoại lệ ảnh hưởng lô	Không suy diễn điều khoản, ngưỡng hạn dùng hay nghĩa vụ ERP
`EVD-SR-006`	Nguồn tham khảo	`ISO/IEC/IEEE 29148:2018`, URL chính thức trong `/00-research/00_SOURCE_MAP.md`	Nguồn chuẩn; chỉ dùng thuật ngữ yêu cầu và kiểm tra	Hỗ trợ cách ghi rõ điều kiện, kết quả, bằng chứng	Không viện dẫn điều khoản chưa kiểm tra licensed text

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

Giả định dự án là điều được dùng để mô phỏng luồng học liệu nhưng chưa được nguồn hoặc người có thẩm quyền xác nhận cho vận hành thực. Verification required nghĩa là phải có bằng chứng hoặc xác nhận từ đúng owner trước khi dùng làm quyết định thực tế.

ID	Nội dung	Cầu nối lý do/bằng chứng	Phân loại	Owner xác minh
`ASM-SR-001`	ERP chặn xuất kho khi lô không đạt ngưỡng hạn dùng nội bộ	`EVD-SR-001` và `EVD-SR-003` chỉ thể hiện hành vi mô phỏng; không có baseline cấu hình	`PROJECT_ASSUMPTION`	Business Owner, Warehouse Supervisor, Application Owner
`ASM-SR-002`	`LOT-NF-COC-260810-A` là lô liên quan đơn `SO-NF-260807-0142`	`EVD-SR-002` ghi liên kết dữ liệu tổng hợp	`PROJECT_ASSUMPTION`	Warehouse Supervisor
`VR-SR-001`	Ngưỡng hạn dùng phù hợp quy định, sản phẩm và quy trình thực tế	Nguồn pháp lý cung cấp bối cảnh, không cung cấp ngưỡng Nova Foods trong artifact này	`VERIFICATION_REQUIRED`	Domain Owner, Legal/Compliance Owner
`VR-SR-002`	Giá trị `22.200.000 VND` có ảnh hưởng kế toán, thuế hoặc hóa đơn	Giá trị chỉ là dữ liệu mô phỏng; `/00-research/00_SOURCE_MAP.md` yêu cầu xác minh chuyên môn kế toán/pháp lý	`VERIFICATION_REQUIRED`	Accounting Owner, Legal Owner
`VR-SR-003`	Vai trò người dùng đủ quyền xem lô và xác nhận xuất kho	`EXC-SR-004` cho thấy quyền là điều kiện riêng với nghiệp vụ	`VERIFICATION_REQUIRED`	Security Owner, Application Owner

4.4. Hồ sơ escalation

Escalation là chuyển vấn đề cho vai trò có thẩm quyền khi Tier 1 không được phép quyết định hoặc khi có rủi ro vượt phạm vi hỗ trợ. Chuyển tuyến không là phê duyệt ngoại lệ.

ID escalation	Kích hoạt	Gói thông tin bắt buộc	Người nhận	Quyết định cần có	Trạng thái
`ESC-SR-001`	Không có lô thay thế đạt ngưỡng theo `EXC-SR-002`	`EVD-SR-001` đến `EVD-SR-004`, tác động `22.200.000 VND`, trạng thái đơn, thời điểm kiểm tra	Business Owner; Sales Operations Lead; Warehouse Supervisor	Có tiếp tục giữ chặn, đổi lịch giao, hoặc chọn phương án nghiệp vụ được phép	`OPEN`
`ESC-SR-002`	Yêu cầu giảm ngưỡng hoặc đổi rule cho đơn đơn lẻ theo `EXC-SR-003`	Yêu cầu người dùng, đơn/lô bị ảnh hưởng, rule hiện quan sát, tác động các giao dịch khác chưa xác định	Business Owner; Application Owner; QA Owner	Có mở thay đổi riêng hay từ chối yêu cầu	`OPEN`
`ESC-SR-003`	Nghi ngờ ERP cho phép xuất kho trái điều kiện theo `EXC-SR-006`	Bước tái hiện, `EVD-SR-001`, `EVD-SR-003`, người dùng, thời điểm, môi trường mô phỏng	Application Owner; QA Owner; Security Owner khi liên quan quyền	Phân loại lỗi, cấu hình, quyền hoặc dữ liệu	`OPEN`
`ESC-SR-004`	Ngoại lệ có thể ảnh hưởng an toàn thực phẩm, truy xuất hoặc nghĩa vụ pháp lý	Mã lô, loại ngoại lệ, `EVD-SR-005`, quyết định nghiệp vụ đang chờ	Domain Owner; Legal/Compliance Owner	Xác minh điều kiện áp dụng trước mọi sử dụng thực tế	`OPEN`

Tier 1 đóng ticket chỉ khi có kết quả được ghi nhận từ đúng escalation hoặc khi lô thay thế đạt ngưỡng theo OPT-01. Không có approval, baseline, xác nhận pháp lý, xác nhận kế toán hoặc cho phép production tại IN_REVIEW v0.9.0.

Ma trận truy vết đầu-cuối cho tình huống hỗ trợ chặn đơn bán vượt tồn kho

Truy vết đầu-cuối là liên kết có kiểm soát từ nhu cầu đến kiểm thử và lỗi/thay đổi; mục đích là chứng minh mỗi kết quả có lý do nguồn. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu dưới đây là tổng hợp. Các liên kết đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, không phải baseline hay approval.

Family	ID	Nội dung đã hoàn tất	Liên kết trước	Liên kết sau	Bằng chứng và cầu nối suy luận
NEED	`NEED-NF-OPS-001`	Nhân viên hỗ trợ cần biết vì sao ERP chặn xác nhận đơn bán khi số lượng đặt vượt tồn kho khả dụng.	Nguồn học liệu mô phỏng Nova Foods	`REQ-NF-OPS-001`	Nhu cầu phát sinh vì màn hình chỉ báo “không đủ tồn” không chỉ rõ mã hàng, kho và số lượng thiếu; hỗ trợ không thể hướng dẫn xử lý nhất quán.
REQ	`REQ-NF-OPS-001`	ERP phải hiển thị mã hàng, kho xuất, tồn khả dụng, số lượng yêu cầu và lượng thiếu khi chặn xác nhận đơn bán.	`NEED-NF-OPS-001`	`BR-NF-INV-001`, `AC-NF-OPS-001`	Yêu cầu biến nhu cầu hỗ trợ thành thông tin hệ thống kiểm tra được; từng trường hiển thị trả lời trực tiếp câu hỏi “thiếu hàng nào, tại kho nào, thiếu bao nhiêu”.
BR	`BR-NF-INV-001`	Không xác nhận đơn bán khi `requestedQuantity > availableQuantity` tại kho xuất đã chọn.	`REQ-NF-OPS-001`	`AC-NF-OPS-001`, `DATA-NF-INV-001`, `TC-NF-OPS-001`	Đây là quy tắc nghiệp vụ mô phỏng. Dấu `>` cho phép xác nhận khi hai số bằng nhau; lý do là đơn không làm tồn khả dụng âm. Không suy diễn đây là quy tắc vận hành hay kế toán thực tế.
AC	`AC-NF-OPS-001`	Với hàng `NF-MI-500`, kho `KHO-HCM-01`, tồn khả dụng `120`, đơn yêu cầu `150`, hệ thống chặn xác nhận và hiện thiếu `30`.	`REQ-NF-OPS-001`, `BR-NF-INV-001`	`TC-NF-OPS-001`	Acceptance Criteria, tiêu chí chấp nhận, biến quy tắc thành kết quả quan sát được. `150 - 120 = 30`; số thiếu phải khớp dữ liệu đầu vào.
DATA	`DATA-NF-INV-001`	`SalesOrderLine.requestedQuantity` là số nguyên dương; `InventoryBalance.availableQuantity` là số nguyên không âm; đơn vị `EA`.	`BR-NF-INV-001`	`API-NF-OPS-001`, `TC-NF-OPS-001`	Kiểu và giới hạn dữ liệu bảo vệ phép so sánh. Số âm hoặc đơn vị khác `EA` làm kết quả thiếu không có nghĩa nghiệp vụ trong case này.
API	`API-NF-OPS-001`	`POST /api/v1/sales-orders/SO-NF-20260807-001/confirm` trả `409 Conflict` khi quy tắc chặn.	`DATA-NF-INV-001`, `AC-NF-OPS-001`	`TC-NF-OPS-001`	HTTP `409 Conflict` diễn đạt trạng thái đơn mâu thuẫn với tồn khả dụng. Đây là hợp đồng API mô phỏng, chưa là đặc tả OpenAPI đã baseline.
TC	`TC-NF-OPS-001`	Xác nhận đơn `SO-NF-20260807-001`: `NF-MI-500`, `KHO-HCM-01`, yêu cầu `150 EA`, khả dụng `120 EA`; mong đợi chặn, thiếu `30 EA`, trạng thái đơn giữ `DRAFT`.	`AC-NF-OPS-001`, `API-NF-OPS-001`	`DEF-NF-OPS-001` nếu lệch	Test case, ca kiểm thử, xác minh hành vi từ dữ liệu tổng hợp. Giữ `DRAFT` ngăn hệ thống ghi nhận xác nhận khi quy tắc chặn.
DEF	`DEF-NF-OPS-001`	Chưa ghi nhận lỗi mô phỏng tại thời điểm lập ma trận; ID được dành cho kết quả khi `TC-NF-OPS-001` thất bại.	`TC-NF-OPS-001`	`CR-NF-OPS-001` nếu cần đổi yêu cầu	Không tạo lỗi giả. Chỉ mở defect khi bằng chứng chạy test cho kết quả khác `409 Conflict`, thiếu `30 EA`, hoặc trạng thái khác `DRAFT`.
CR	`CR-NF-OPS-001`	Chưa ghi nhận yêu cầu thay đổi mô phỏng; ID được dành cho thay đổi phạm vi sau review.	`DEF-NF-OPS-001` hoặc yêu cầu nghiệp vụ mới	Liên kết ngược đến `NEED`, `REQ`, `BR`, `AC`, `DATA`, `API`, `TC` bị ảnh hưởng	Không tạo thay đổi giả. Nếu đổi công thức tồn khả dụng, phải đánh giá lại mọi liên kết; không sửa im lặng `BR-NF-INV-001`.

Kiểm tra liên kết	Kết quả `IN_REVIEW`	Tiêu chí
Bao phủ từ NEED đến TC	Đủ	Mỗi ID từ `NEED-NF-OPS-001` đến `TC-NF-OPS-001` có ít nhất một liên kết vào và ra, trừ điểm đầu và điểm cuối.
Defect và change request	Có đường xử lý, chưa có bản ghi thực tế	`DEF-NF-OPS-001` và `CR-NF-OPS-001` không chứng minh lỗi hoặc thay đổi đã tồn tại.
Baseline và approval	Không có	Theo `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`, trạng thái `IN_REVIEW` không được diễn giải là `BASELINED` hoặc được phê duyệt.
Thẩm quyền nghiệp vụ	Cần xác minh trước production	Quy tắc tồn kho, trạng thái đơn và mã HTTP là nội dung mô phỏng; Business Owner, Architect và QA Owner phải xác minh khi dùng ngoài học liệu.

Gói bằng chứng hỗ trợ cho ca mô phỏng Nova Foods

Nova Foods Trading & Manufacturing là ca học liệu mô phỏng; mọi mã, người dùng, số tiền, lô hàng và dữ liệu dưới đây là dữ liệu tổng hợp. Gói này mô tả dữ liệu cần lưu khi Nhân viên hỗ trợ Tier 1 tiếp nhận yêu cầu về đơn bán hàng SO-NF-260807-001, để Tier 2 có đủ ngữ cảnh tái tạo và phân loại vấn đề mà không dùng dữ liệu khách hàng thật. Payload là dữ liệu có cấu trúc gửi qua API; mỗi trường giúp trả lời một câu hỏi vận hành cụ thể: ai báo lỗi, lỗi ở đâu, xảy ra lúc nào, tác động gì và bằng chứng nào kèm theo.

TMPL-OPS-003--support-readiness — diagram 1

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Nhân viên bán hàng báo đơn SO-NF-260807-001 chưa tạo phiếu xuất]
    A --> B[Tier 1 ghi ticket SUP-NF-260807-001: người báo NVBH-018, kênh ERP Portal]
    B --> C[Tier 1 ghi tác động: chưa tạo phiếu xuất trước giờ giao mô phỏng 2026-08-07 14:00]
    C --> D[Tier 1 xác nhận nguồn: ERP mô phỏng Nova Foods]
    D --> E[Tier 1 tra cứu SO-NF-260807-001 trên ERP Portal]
    E --> F[Tier 1 ghi mã đơn, kho KHO-HCM-01, sản phẩm SP-NF-001, số lượng 120 chai và trạng thái]
    F --> G[Tier 1 đính kèm ảnh evidence/SUP-NF-260807-001-order-screen.png: chụp 09:18+07:00]
    G --> H[Tier 1 tạo payload: báo 09:20+07:00]
    H --> I{Ticket, payload và tệp bằng chứng đầy đủ, khớp nhau?}
    I -->|Không| J[Tier 1 bổ sung hoặc sửa dữ liệu thiếu, không khớp]
    J --> I
    I -->|Có| K[Tier 1 chuyển gói bằng chứng cho Tier 2]
    K --> L[Tier 2 có ngữ cảnh tái tạo và phân loại vấn đề]

Sơ đồ luồng hoạt động, không phải BPMN. BPMN là chuẩn ký pháp quy trình của OMG; sơ đồ này chỉ chỉ rõ thứ tự bàn giao bằng chứng hỗ trợ.

Trường bằng chứng	Giá trị tổng hợp	Mục đích kiểm tra
Mã ticket	`SUP-NF-260807-001`	Khóa liên kết gói hỗ trợ.
Kênh tiếp nhận	`ERP Portal`	Xác định điểm người dùng gặp vấn đề.
Người báo	`NVBH-018 — Lê Minh An`	Xác định người tái hiện được thao tác.
Thời điểm báo	`2026-08-07T09:20:00+07:00`	Đối chiếu nhật ký cùng múi giờ `Asia/Ho_Chi_Minh`.
Đối tượng ảnh hưởng	`SO-NF-260807-001`	Xác định đơn bán hàng cần tra cứu.
Kho xuất dự kiến	`KHO-HCM-01`	Giới hạn phạm vi kiểm tra tồn kho.
Sản phẩm	`SP-NF-001 — Nước ép xoài 1L`	Xác định dòng đơn bị ảnh hưởng.
Số lượng	`120 chai`	Đối chiếu số lượng đặt, giữ hàng và cấp phát.
Tác động nghiệp vụ	Đơn chưa chuyển sang bước tạo phiếu xuất trước giờ giao mô phỏng `2026-08-07 14:00`	Giúp ưu tiên xử lý theo tác động giao hàng, không kết luận mức ưu tiên.
Tệp bằng chứng	`evidence/SUP-NF-260807-001-order-screen.png`	Ảnh tổng hợp màn hình đơn; không chứa dữ liệu cá nhân thật.
Nguồn dữ liệu	ERP mô phỏng Nova Foods	Phân biệt dữ liệu học liệu với hệ thống production.

{
  "ticketId": "SUP-NF-260807-001",
  "reportedAt": "2026-08-07T09:20:00+07:00",
  "channel": "ERP Portal",
  "reporter": {
    "employeeId": "NVBH-018",
    "displayName": "Lê Minh An",
    "role": "Nhân viên bán hàng"
  },
  "affectedOrder": {
    "salesOrderId": "SO-NF-260807-001",
    "warehouseId": "KHO-HCM-01",
    "statusObserved": "Đã xác nhận",
    "fulfillmentStatusObserved": "Chưa tạo phiếu xuất",
    "lineItems": [
      {
        "productId": "SP-NF-001",
        "productName": "Nước ép xoài 1L",
        "orderedQuantity": 120,
        "unit": "chai",
        "unitPriceVnd": 32000,
        "lineTotalVnd": 3840000
      }
    ],
    "orderTotalVnd": 3840000,
    "currency": "VND"
  },
  "evidence": [
    {
      "evidenceId": "EVD-NF-260807-001",
      "fileName": "evidence/SUP-NF-260807-001-order-screen.png",
      "capturedAt": "2026-08-07T09:18:00+07:00",
      "description": "Màn hình đơn hiển thị trạng thái Đã xác nhận và Chưa tạo phiếu xuất"
    }
  ],
  "simulationOnly": true
}

Bộ dữ liệu kiểm tra	Giá trị nhập hoặc quan sát	Kết quả bằng chứng mong đợi
`TD-SUP-001`	Mở `SO-NF-260807-001`; kho `KHO-HCM-01`; sản phẩm `SP-NF-001`; số lượng `120`	Ticket ghi đúng một đơn, một kho, một dòng sản phẩm và số lượng `120 chai`.
`TD-SUP-002`	Đơn có tổng `3.840.000 VND`; đơn vị giá `32.000 VND`; số lượng `120`	Payload giữ `lineTotalVnd` và `orderTotalVnd` bằng `3840000`; phép kiểm tra `32000 × 120 = 3840000` đúng.
`TD-SUP-003`	Thời điểm ảnh `09:18`; thời điểm báo `09:20`; múi giờ `+07:00`	Payload giữ chuỗi thời gian ISO 8601 đầy đủ múi giờ; bằng chứng có trước báo lỗi hai phút.
`TD-SUP-004`	Tệp `evidence/SUP-NF-260807-001-order-screen.png`	Tên tệp khớp `evidence[0].fileName`; mô tả nêu đúng hai trạng thái quan sát.

SUP-NF-260807-001, EVD-NF-260807-001 và dữ liệu payload là định danh mô phỏng trong mẫu này, không phải baseline, approval, cấu hình ERP thật hoặc kết luận nguyên nhân lỗi.

5. Tier 4 ? Senior BA Quality Gate

Quality Gate là cổng kiểm soát chất lượng trước baseline: Senior BA kiểm tra artifact đủ để review có thẩm quyền, không tự phê duyệt, không biến IN_REVIEW thành BASELINED. Checklist dùng cho Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

ID kiểm tra	Nội dung và bằng chứng phải có	PASS	FAIL	STOP	Escalation
QG-SBA-001	Tính đầy đủ: mọi trường bắt buộc, luồng chính, ngoại lệ, quyết định, đầu vào, đầu ra và điều kiện lỗi được ghi.	Không còn trường trống trong Tier 3; từng ngoại lệ có xử lý.	Thiếu chi tiết nhưng chưa làm đổi phạm vi hoặc quyết định.	Thiếu luồng, ngoại lệ, owner hoặc dữ liệu làm ticket không thể xử lý.	Business Owner xác nhận phạm vi; Support Lead xác nhận khả năng tiếp nhận.
QG-SBA-002	Tính nhất quán: ID, tên, trạng thái, số lượng, tiền, đơn vị, thời gian và thuật ngữ khớp giữa các bảng, payload, ảnh bằng chứng.	Một giá trị có một nghĩa; phép tính và múi giờ khớp.	Sai trình bày, không đổi nghĩa dữ liệu.	Hai nguồn trong cùng artifact cho giá trị mâu thuẫn, như `orderTotalVnd` khác tổng dòng.	Owner artifact sửa nguồn gốc; Business Owner quyết định khi mâu thuẫn là nghiệp vụ.
QG-SBA-003	Khả năng kiểm thử: yêu cầu có điều kiện đầu vào, hành động, kết quả quan sát được và dữ liệu kiểm tra.	QA hoặc support có thể lặp lại kiểm tra không cần suy đoán.	Thiếu nhãn bộ dữ liệu nhưng vẫn suy ra được từ payload.	Không xác định được kết quả mong đợi hoặc tiêu chí đạt.	QA Reviewer xác định test basis; Business Owner làm rõ kết quả nghiệp vụ.
QG-SBA-004	Traceability là khả năng lần từ nội dung về nguồn và sang bằng chứng. Mỗi claim, quy tắc, dữ liệu và tệp evidence phải có ID hoặc liên kết canonical.	Liên kết giữ nguyên ID, filename và phân loại nguồn.	Liên kết định dạng sai nhưng vẫn truy được nguồn canonical.	Không truy được claim quan trọng về nguồn, rule hoặc evidence.	Principal IT Business Analyst / Technical Curriculum Author khôi phục liên kết; không tự tạo ID mới ngoài registry.
QG-SBA-005	Thẩm quyền nguồn: phân biệt nguồn chuẩn, nguồn pháp lý, project assumption và Verification required.	Claim chỉ dùng trong safe use boundary nguồn.	Cần làm rõ cách diễn đạt, chưa tạo nghĩa vụ.	Claim pháp lý, kế toán, thuế hoặc tuân thủ được viết như kết luận dù chưa có xác minh trực tiếp.	Legal Owner, Accounting Owner hoặc Compliance Owner xác minh; giữ nhãn `Verification required` đến khi có kết luận.
QG-SBA-006	Ownership là người chịu trách nhiệm quyết định hoặc thực hiện. Mỗi quyết định, escalation và cập nhật phải có role phù hợp.	Owner, reviewer và giới hạn thẩm quyền rõ.	Một nhiệm vụ vận hành chưa có role thực hiện.	Owner artifact tự quyết thay Business Owner, Architect, Legal, Accounting, Security hoặc QA.	Chuyển đúng role có thẩm quyền; Senior BA chỉ đóng gói vấn đề và bằng chứng.
QG-SBA-007	Ranh giới bảo mật và riêng tư: dữ liệu cá nhân, quyền truy cập, log, ảnh màn hình và API payload không lộ dữ liệu ngoài cần thiết.	Chỉ dữ liệu tổng hợp; tệp evidence có mục đích và hạn chế hiển thị rõ.	Cần che thêm trường không thiết yếu trước chia sẻ.	Có dữ liệu cá nhân thật, bí mật, token, mật khẩu hoặc dữ liệu truy cập production.	Security Owner và Privacy/Legal Owner đánh giá; dừng chia sẻ artifact chứa dữ liệu đó.
QG-SBA-008	Ranh giới pháp lý, kế toán và hóa đơn: tài liệu không diễn giải luật thành cấu hình ERP hay bút toán bắt buộc.	Nội dung chỉ nêu bối cảnh, assumption hoặc `Verification required` đúng nguồn.	Thiếu nhãn nguồn cho nhận định không quyết định.	Nội dung khẳng định nghĩa vụ pháp lý, thuế, hóa đơn, lưu trữ chứng từ hoặc hạch toán khi chưa có owner xác nhận.	Legal Owner và Accounting Owner quyết định; không baseline phần bị ảnh hưởng.
QG-SBA-009	Tác động thay đổi: thay đổi ID, trạng thái, rule, dữ liệu, API, evidence hoặc owner phải chỉ ra artifact và kiểm tra bị ảnh hưởng.	Có danh sách tác động và kiểm tra lại tương ứng.	Tác động nhỏ, giới hạn trong một lỗi trình bày.	Thay đổi làm đứt traceability, đổi nghĩa rule hoặc làm bằng chứng cũ không còn đúng.	Change Owner phối hợp Business Owner, Architect, QA và Support Lead; tạo đánh giá tác động trước sửa.
QG-SBA-010	Trạng thái quản trị: Status `IN_REVIEW`, Version `v0.9.0`, ngày `2026-08-07` phải được giữ đúng.	Không có câu chữ suy diễn approval, baseline, compliance hoặc production readiness.	Một nhãn trạng thái trình bày không thống nhất nhưng metadata canonical đúng.	Artifact gọi nội dung là approved hoặc baselined khi không có tham chiếu quản trị hợp lệ.	Owner artifact sửa trạng thái; người có thẩm quyền xem xét theo quy trình corpus.

Quy tắc quyết định: PASS khi bằng chứng đủ và không có điều kiện STOP. FAIL khi có lỗi sửa được nhưng chưa làm sai quyền quyết định; ghi nhận lỗi, sửa và kiểm tra lại trước khi chuyển tiếp. STOP khi thiếu nguồn authority, đứt traceability, có mâu thuẫn nghiệp vụ, có dữ liệu nhạy cảm, hoặc vượt ranh giới legal/accounting/security; không được baseline phần ảnh hưởng. Escalation phải chứa ID kiểm tra, artifact bị ảnh hưởng, bằng chứng hiện có, điều chưa biết, role cần quyết định và tác động nếu không xử lý.

Ma trận kiểm tra chất lượng Senior BA theo chín chiều kiểm soát

Quality Gate là cổng kiểm tra trước baseline: Senior BA xác minh tài liệu đủ để người khác hiểu, xây dựng và kiểm thử mà không tự bù quy tắc. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND. Kết quả kiểm tra không tạo baseline, approval, xác nhận tuân thủ hay quyền dùng production.

Chiều kiểm tra	Câu hỏi kiểm tra từ nguyên lý	Bằng chứng phải xem	Tiêu chí kết luận
Tính đầy đủ (completeness)	Mọi chức năng hỗ trợ có đủ mục tiêu, phạm vi, actor, điều kiện kích hoạt, luồng chính, ngoại lệ, dữ liệu vào-ra, SLA giả định và liên kết hỗ trợ chưa?	Core record Tier 3, evidence Tier 3, danh sách ngoại lệ, payload tổng hợp	Không còn trường trống, quy tắc ngầm, actor không định danh, hoặc ngoại lệ không có cách xử lý. Thiếu một đầu vào làm đội hỗ trợ phải đoán là lỗi đầy đủ.
Tính nhất quán (consistency)	Cùng khái niệm có giữ cùng tên, ID, giá trị trạng thái, đơn vị tiền `VND`, múi giờ `Asia/Ho_Chi_Minh` và ý nghĩa giữa các bảng không?	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`, `/01-curriculum/CANONICAL_BUSINESS_RULES.md`, `/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	ID, tên trường, trạng thái, owner, rule và trace link khớp nguồn canonical. Hai giá trị khác nhau cho cùng một khái niệm là mâu thuẫn, không phải chi tiết nhỏ.
Khả năng kiểm thử (testability)	Mỗi yêu cầu có điều kiện đầu vào, hành động, kết quả quan sát được và tiêu chí xác nhận hoặc từ chối không?	Acceptance criteria, ví dụ request/response, dữ liệu kiểm thử tổng hợp, luồng lỗi	Không dùng từ mơ hồ như “nhanh”, “đúng”, “an toàn” nếu thiếu thước đo hoặc kết quả quan sát. Ví dụ lỗi API phải nêu HTTP status, mã lỗi, dữ liệu nào bị từ chối và hành vi ghi log. Thuật ngữ kiểm thử black-box là kiểm thử theo đầu vào và đầu ra, không cần biết mã nguồn.
Truy vết (traceability)	Mỗi quyết định hỗ trợ truy ngược được về nguồn, rule, yêu cầu hoặc giả định; và xuôi được đến kiểm thử, owner, ảnh hưởng không?	Traceability link, registry ID, source map, test basis	Mỗi link dùng ID canonical, không dùng mô tả tự do thay ID. Link phải chỉ ra loại quan hệ: “dựa trên”, “ràng buộc bởi”, “kiểm thử”, hoặc “cần xác minh”. Không được tạo ID mới ngoài registry.
Thẩm quyền nguồn (source authority)	Nguồn có quyền chứng minh đúng loại kết luận đang viết không?	`/00-research/00_SOURCE_MAP.md`, URL nguồn chính thức, nhãn project assumption hoặc `Verification required`	BABOK Guide dùng cho thuật ngữ và thực hành BA; ISTQB CTFL dùng cho thuật ngữ kiểm thử; OAS 3.1.1 dùng cho mô tả HTTP API; OWASP là good practice, không phải luật Việt Nam. Nội dung pháp lý, kế toán, thuế, hóa đơn, an toàn thực phẩm chỉ dùng nguồn chính thức trong Source Map và vẫn cần owner có thẩm quyền xác minh diễn giải.
Ownership	Người chịu trách nhiệm duy trì, quyết định và xử lý sự cố có phân biệt rõ không?	Bảng owner, escalation contact theo vai trò, ranh giới quyền hạn	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability; không thay Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA. Một người “owner” nhưng không có quyền quyết định hoặc phản hồi là ownership không đủ.
Bảo mật, riêng tư, pháp lý, kế toán	Dữ liệu cá nhân, quyền truy cập, log, chứng từ, giao dịch và truy xuất thực phẩm có bị suy diễn vượt thẩm quyền không?	Phân loại dữ liệu, quyền truy cập mô phỏng, nguồn luật, nhãn xác minh	Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý riêng tư cần Legal Owner xác minh. Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP cần Accounting Owner hoặc Legal Owner xác minh. Luật 55/2010/QH12 chỉ tạo bối cảnh truy xuất/thu hồi; không tự tạo quy tắc ERP. Mọi kết luận chưa kiểm tra trực tiếp phải ghi `Verification required`.
Tác động thay đổi (change impact)	Nếu sửa rule, dữ liệu, API, quyền, SLA hoặc owner, artifact nào và kiểm thử nào đổi theo?	Change record, traceability link, data dictionary, API description, test evidence	Phải xác định tác động tối thiểu đến requirement, rule, dữ liệu, giao diện/API, role, tài liệu hỗ trợ và test basis. Không được sửa nội dung đã kiểm soát im lặng. Thay đổi không có impact record không đủ để đưa vào baseline.

Cầu nối suy luận: tài liệu hỗ trợ chỉ đáng tin khi câu trả lời vận hành có nguồn, có owner và có kiểm thử. Vì vậy, thiếu trace link không chỉ là lỗi tài liệu; nó làm đội hỗ trợ không chứng minh được vì sao phải xử lý theo cách đó. Tương tự, gọi một giả định pháp lý là rule bắt buộc sẽ vượt thẩm quyền nguồn, dù luồng ERP nghe hợp lý.

Ranh giới bắt buộc: /03-templates/TMPL-OPS-003--support-readiness.md chỉ tổng hợp bằng chứng cho case Nova Foods mô phỏng. Tệp này không thay thế /01-curriculum/CANONICAL_BUSINESS_RULES.md cho rule canonical, /01-curriculum/CANONICAL_DATA_DICTIONARY.md cho định nghĩa dữ liệu, /01-curriculum/TRACEABILITY_ID_REGISTRY.md cho ID, hay /00-research/00_SOURCE_MAP.md cho phân loại và giới hạn nguồn.

Áp dụng Quality Gate cho hồ sơ Tier 3 Nova Foods

Quality gate là điểm kiểm tra chặn trước baseline: chỉ phát hiện đủ bằng chứng và đúng thẩm quyền, không tạo phê duyệt. Case Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Lần ghi nhận: 2026-08-07; trạng thái giữ nguyên IN_REVIEW; phiên bản giữ nguyên v0.9.0.

Hạng mục kiểm tra	Bằng chứng và cầu nối suy luận	Kết quả	Ghi nhận cần xử lý
Đầy đủ hồ sơ	Tier 3 có Core Record và Evidence and Traceability theo cấu trúc tài liệu `/03-templates/TMPL-OPS-003--support-readiness.md`. Hai phần cùng cần để support readiness không chỉ là mô tả vận hành.	PASS có điều kiện	Giữ mọi trường Tier 3 đã điền; không thay bằng placeholder.
Nhất quán quản trị	`TEMPLATE_MANIFEST`, `CHAPTER_MANIFEST`, `TRACEABILITY_ID_REGISTRY`, `CANONICAL_BUSINESS_RULES` đều ghi `IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`; các artifact đều nói chưa có baseline và approval.	PASS	Không dùng từ “đã baseline”, “đã phê duyệt”, “production-ready”, hoặc “compliant”.
Khả năng kiểm thử	Testability là khả năng biến yêu cầu thành điều kiện kiểm tra có đầu vào, hành động và kết quả quan sát được. `ISTQB CTFL Syllabus v4.0.1` là nguồn thuật ngữ testing, nhưng không tự tạo test case Nova Foods.	FAIL	Tier 3 cần liên kết rõ test basis cho từng kiểm soát support có rủi ro. Không suy diễn expected result từ mô tả chung.
Truy vết	Traceability là liên kết kiểm tra được giữa claim, bằng chứng, nguồn và người chịu trách nhiệm. `TRACEABILITY_ID_REGISTRY` là nguồn canonical cho cách quản trị định danh.	PASS có điều kiện	Chỉ giữ liên kết ID đã có trong hồ sơ. ID không đăng ký hoặc biến thể tên file là lỗi chặn.
Thẩm quyền nguồn	`00_SOURCE_MAP` phân loại nguồn: BABOK cho BA; ISTQB cho testing; OWASP cho good practice; nguồn Chính phủ, Quốc hội cho văn bản pháp lý. Nguồn không thay thẩm quyền quyết định.	PASS	Không gán kết luận pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật cho Principal IT Business Analyst / Technical Curriculum Author.
Ownership	Owner của artifact là `Principal IT Business Analyst / Technical Curriculum Author`; nguồn upstream giới hạn Owner không được tự xác nhận legal, accounting, security, approval hoặc baseline.	FAIL	Thiếu bằng chứng reviewer có thẩm quyền cho các quyết định vượt phạm vi Owner.
Bảo mật và riêng tư	`OWASP ASVS 5.0.0` và OWASP API Security Top 10 2023 là chuẩn/good practice ngành; Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP cần Legal Owner xác minh khi chuyển thành requirement hệ thống.	STOP	Không thể kết luận yêu cầu dữ liệu cá nhân, quyền truy cập, lưu trữ hoặc API của Nova Foods hợp lệ. Escalate Legal Owner và Security Owner.
Kế toán, hóa đơn và pháp lý	Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP là nguồn pháp lý chính thức, nhưng seed yêu cầu Accounting Owner hoặc Legal Owner xác minh diễn giải và sửa đổi sau này.	STOP	Không thể coi logic hạch toán, chứng từ, hóa đơn, thuế hoặc lưu giữ chứng từ trong case là quy tắc vận hành. Escalate Accounting Owner và Legal Owner.
Tác động thay đổi	Change impact là ảnh hưởng của thay đổi lên yêu cầu, dữ liệu, kiểm thử, vận hành và nguồn. `v0.9.0` chưa có baseline reference, nên chưa có mốc hợp lệ để tính chênh lệch baseline.	FAIL	Chỉ lập tác động sau khi có thay đổi được ghi nhận và tham chiếu baseline hợp lệ. Không sửa im lặng liên kết Tier 3.

Kết luận ghi nhận: trạng thái quality gate là STOP — REVIEW AND ESCALATION REQUIRED. Lý do: thiếu xác minh thẩm quyền cho privacy, security, legal và accounting; thiếu test basis quan sát được; chưa có baseline reference để đánh giá tác động thay đổi. Không có approval, baseline, xác nhận tuân thủ, hoặc quyền dùng production được ghi nhận.

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

Cross-file check là đối chiếu cùng một thông tin giữa các tệp nguồn để phát hiện mâu thuẫn trước handoff. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, không xác nhận ERP, vận hành, tuân thủ hoặc quyết định doanh nghiệp thực.

Hạng mục đối chiếu	Nguồn kiểm tra	Bằng chứng và suy luận	Kết quả
Trạng thái, phiên bản, ngày, locale	`/01-curriculum/CHAPTER_MANIFEST.md`, `/01-curriculum/TEMPLATE_MANIFEST.md`, `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`, `/01-curriculum/CANONICAL_BUSINESS_RULES.md`, `/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Metadata nguồn đều nêu `IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, `vi-VN`, `Asia/Ho_Chi_Minh`; ngữ cảnh Việt Nam dùng `VND`.	PASS. Tệp này phải giữ nguyên các giá trị đó.
Baseline và approval	`CHAPTER_MANIFEST`, `TEMPLATE_MANIFEST`, `TRACEABILITY_ID_REGISTRY`, `CANONICAL_BUSINESS_RULES`	Các nguồn cùng nêu chưa có baseline reference và approval reference. `IN_REVIEW` không đồng nghĩa `BASELINED`, `APPROVED`, compliant hay production-ready.	PASS. Không ghi nhận approval ngầm định.
Định danh template và đường dẫn	`/03-templates/TMPL-OPS-003--support-readiness.md`, `TEMPLATE_MANIFEST`, `TRACEABILITY_ID_REGISTRY`	Tệp hiện hành dùng mã `TMPL-OPS-003` trong tên tệp. Trích đoạn `TEMPLATE_MANIFEST` và registry không cung cấp dòng đăng ký riêng của mã này. Không đủ bằng chứng để xác nhận mã, tên, consumer và dependency đã đăng ký canonical.	BLOCKED. Không đổi mã, không tạo biến thể mã, không tuyên bố đã đăng ký.
Quy tắc nghiệp vụ	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	Catalog là nguồn canonical cho business rule. Nguồn xác định Owner chỉ quản trị artifact, không xác nhận quy tắc Nova Foods cho vận hành thực. Section này không tạo, sửa, hay diễn giải rule.	PASS về ranh giới. Chưa thể kiểm tra từng rule vì không có tập rule liên kết với `TMPL-OPS-003`.
Từ điển dữ liệu	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Dictionary là nguồn canonical cho định nghĩa dữ liệu logic. Nội dung section không thêm field, giá trị miền, kiểu dữ liệu, retention hay mapping ERP.	PASS về ranh giới. Chưa thể kiểm tra field-level vì chưa có payload hoặc liên kết dictionary của template.
Chapter, template liên quan và consumer hạ nguồn	`CHAPTER_MANIFEST`, `TEMPLATE_MANIFEST`, `/02-handbook/`, `/03-templates/`, `/04-cheatsheets/`, `/05-glossary/`, `/06-qa/`	`CHAPTER_MANIFEST` và `TEMPLATE_MANIFEST` kiểm soát cấu trúc corpus; source seed yêu cầu không mâu thuẫn governance giữa các thư mục. Trích đoạn không liệt kê consumer cụ thể của `TMPL-OPS-003`.	BLOCKED. Không suy diễn consumer, test basis, checklist QA hoặc glossary entry.
Ranh giới nguồn pháp lý, kế toán, bảo mật, riêng tư, an toàn thực phẩm	`/00-research/00_SOURCE_MAP.md`	Source Map yêu cầu Legal Owner, Accounting Owner, Security Owner hoặc domain owner xác minh trước khi biến nguồn thành requirement hệ thống. Support readiness không được biến nguồn thành cam kết tuân thủ Nova Foods.	PASS. Mọi claim chuyên ngành vẫn giữ nhãn Verification required khi xuất hiện ở artifact khác.

Quy tắc kết luận: chỉ ghi PASS khi bằng chứng nguồn đủ cho đúng phạm vi kiểm tra; BLOCKED nghĩa là chưa đủ artifact hoặc liên kết để kết luận, không phải mâu thuẫn đã được giải quyết. Mọi sửa đổi mã TMPL-OPS-003, filename, rule link, data link hoặc consumer link phải được đối chiếu lại với manifest và registry canonical trước khi lan truyền sang handbook, cheatsheet, glossary hoặc QA. Status của tài liệu vẫn là IN_REVIEW; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết, không tự baseline, approval, xác nhận pháp lý, kế toán, bảo mật hoặc vận hành.

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

Sổ này chỉ ghi nội dung ảnh hưởng đến TMPL-OPS-003, Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND. “Vấn đề mở” là điểm mâu thuẫn hoặc thiếu 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 trình bày như kết luận có thẩm quyền trước khi đúng Owner kiểm tra. Trạng thái toàn bộ hồ sơ vẫn IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Loại	Mã ghi nhận	ID/tệp bị ảnh hưởng	Owner có thẩm quyền	Tác động	Hành động tiếp
Vấn đề mở	`OI-OPS-003-01`	`TMPL-OPS-003`; `TEMPLATE_MANIFEST`; `TRACEABILITY_ID_REGISTRY`	Principal IT Business Analyst / Technical Curriculum Author	Chưa có bằng chứng trong đầu vào rằng `TMPL-OPS-003` đã được đăng ký đầy đủ trong registry với liên kết consumer cụ thể. Dùng ID chưa đăng ký làm đứt truy vết.	Đối chiếu chuỗi `TMPL-OPS-003` trong `/01-curriculum/TEMPLATE_MANIFEST.md` và `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`; chỉ ghi liên kết đã tồn tại, không tự tạo approval hay baseline.
Vấn đề mở	`OI-OPS-003-02`	`TMPL-OPS-003`; `CHAPTER_MANIFEST`; `01_CURRICULUM_ARCHITECTURE`	Principal IT Business Analyst / Technical Curriculum Author	Chưa có evidence đủ chi tiết về chapter, template hoặc consumer nhận bàn giao support readiness. Không được suy diễn tên consumer hay trách nhiệm vận hành.	Xác minh dependency được manifest ghi nhận; nếu thiếu hoặc mâu thuẫn, giữ vấn đề mở và chuyển gói tác động cho Owner quản trị curriculum.
Giả định dự án	`PA-OPS-003-01`	`TMPL-OPS-003`; `CANONICAL_BUSINESS_RULES`; `CANONICAL_DATA_DICTIONARY`	Business Owner xác nhận nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author duy trì nhãn	Case Nova Foods dùng tên tổ chức, quy trình ERP, ID và dữ liệu tổng hợp cho học liệu. Suy luận này dựa trên metadata corpus nêu rõ “simulated educational case study” và “chỉ sử dụng dữ liệu tổng hợp”.	Giữ nhãn mô phỏng trong mọi bản sao và output; thay bằng dữ liệu thực chỉ khi có artifact, thẩm quyền và kiểm soát riêng.
Giả định dự án	`PA-OPS-003-02`	`TMPL-OPS-003`; `CANONICAL_DATA_DICTIONARY`	Business Owner; Accounting Owner	Giá trị tiền tệ minh họa dùng `VND`, locale `vi-VN`, thời điểm quản trị theo `Asia/Ho_Chi_Minh`. Đây là bối cảnh corpus, không xác nhận cấu hình ERP, lịch kế toán hoặc quy tắc làm tròn thực tế.	Chỉ dùng định dạng này cho case mô phỏng; yêu cầu Accounting Owner và Business Owner xác nhận trước khi chuyển thành yêu cầu hệ thống.
Cần xác minh	`VR-OPS-003-01`	`TMPL-OPS-003`; `CANONICAL_BUSINESS_RULES`	Legal Owner; Compliance Owner	Bất kỳ yêu cầu về dữ liệu cá nhân phải được kiểm tra theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Seed chỉ xác nhận nguồn và hiệu lực, không cung cấp diễn giải điều khoản cho Nova Foods.	Legal Owner xác minh văn bản hiện hành, phạm vi áp dụng và requirement dẫn xuất; ghi evidence nguồn chính thức trước khi gắn nhãn compliance.
Cần xác minh	`VR-OPS-003-02`	`TMPL-OPS-003`; `CANONICAL_BUSINESS_RULES`; `CANONICAL_DATA_DICTIONARY`	Accounting Owner; Legal Owner	Quy tắc kế toán, thuế, hóa đơn hoặc chứng từ không được suy ra từ Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP. Seed yêu cầu kiểm tra sửa đổi trước production use.	Accounting Owner và Legal Owner xác minh quy định hiện hành, cách diễn giải và tác động dữ liệu; không biến giả định học liệu thành rule bắt buộc.
Cần xác minh	`VR-OPS-003-03`	`TMPL-OPS-003`; `CANONICAL_BUSINESS_RULES`	Food-safety Domain Owner; Legal Owner	Traceability hoặc recall thực phẩm chỉ có ngữ cảnh từ Luật 55/2010/QH12. Không có evidence rằng quy trình mô phỏng Nova Foods đáp ứng nghĩa vụ thực tế.	Domain Owner và Legal Owner xác minh yêu cầu áp dụng; tách kết luận pháp lý khỏi ví dụ đào tạo.
Cần xác minh	`VR-OPS-003-04`	`TMPL-OPS-003`; `CANONICAL_DATA_DICTIONARY`	Security Owner; Solution Architect	Nếu support readiness chứa quyền truy cập, API, nhật ký hoặc dữ liệu nhạy cảm, OWASP ASVS 5.0.0 và OWASP API Security Top 10:2023 chỉ là chuẩn thực hành ngành, không phải luật Việt Nam hay bằng chứng tuân thủ.	Security Owner xác định kiểm soát cần thiết; Solution Architect xác nhận kiến trúc; ghi tiêu chí kiểm tra riêng trước production.

Không Owner nào trong bảng được suy diễn đã phê duyệt. Principal IT Business Analyst / Technical Curriculum Author chỉ điều phối, giữ ID và traceability; không thay Legal Owner, Accounting Owner, Security Owner, Solution Architect, Business Owner hoặc Food-safety Domain Owner ra quyết định.

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

Bàn giao có kiểm soát nghĩa là chuyển đủ liên kết để người nhận kiểm tra được nguồn, phạm vi và trạng thái; không phải chuyển quyền phê duyệt. Bản ghi này thuộc /03-templates/TMPL-OPS-003--support-readiness.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, bối cảnh vi-VN và VND. Nova Foods Trading & Manufacturing là case học liệu mô phỏng; mọi tên, ID và dữ liệu là tổng hợp. Không dùng bản ghi này làm hướng dẫn production, kết luận pháp lý, kế toán, an ninh, hay vận hành thực.

Hạng mục bàn giao	Nguồn kiểm soát phải giữ nguyên	Người nhận	Điều được phép làm	Điều không được suy diễn
Metadata template	`TMPL-OPS-003`; `/03-templates/TMPL-OPS-003--support-readiness.md`; `IN_REVIEW`; `v0.9.0`	Principal IT Business Analyst / Technical Curriculum Author	Rà soát, ghi nhận thay đổi, giữ lịch sử	Không gọi là `BASELINED`, `APPROVED`, production-ready hoặc user-approved
Danh mục template	`/01-curriculum/TEMPLATE_MANIFEST.md`; `TEMPLATE_MANIFEST`	Curriculum owner, template reviewer	Đối chiếu tên tệp, ID, phạm vi template	Không tạo template ID thay thế hay đổi tên tệp không qua kiểm soát
Định danh truy vết	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`; `TRACEABILITY_ID_REGISTRY`	BA, QA reviewer, Technical Architect khi cần	Kiểm tra ID và liên kết truy vết	Không cấp ID để ngầm quyết định pháp lý, kế toán, kiến trúc, bảo mật hay vận hành
Quy tắc nghiệp vụ	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`; `CANONICAL_BUSINESS_RULES`	Business Owner, Legal Owner, Accounting Owner khi áp dụng	Xem nguồn và đề xuất làm rõ	Không xác nhận rule mô phỏng là rule ERP thực
Dữ liệu logic	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`; `CANONICAL_DATA_DICTIONARY`	Data owner, Architect, Security	Đánh giá nghĩa dữ liệu và ảnh hưởng	Không coi dữ liệu tổng hợp là dữ liệu cá nhân hay cấu hình production

Mọi thay đổi phải bắt đầu bằng bản ghi thay đổi nêu rõ: artifact bị ảnh hưởng, ID giữ nguyên hoặc ID mới đã đăng ký, lý do, bằng chứng nguồn, ảnh hưởng liên file, owner xử lý, reviewer có thẩm quyền và thời điểm theo Asia/Ho_Chi_Minh. Thay đổi chỉ sửa cách trình bày vẫn phải giữ traceability. Thay đổi làm khác nghĩa rule, trường dữ liệu, quyền truy cập, tiêu chí hỗ trợ, SLA mô phỏng, hoặc diễn giải nguồn phải lan sang mọi artifact tham chiếu trước khi coi là nhất quán.

Loại thay đổi	Hành động lan truyền bắt buộc	Ranh giới thẩm quyền
Đổi ID, filename, đường dẫn canonical	Cập nhật registry, manifest và mọi liên kết đến ID/đường dẫn cũ; giữ lịch sử thay thế	Principal IT Business Analyst / Technical Curriculum Author duy trì truy vết; không tự phê duyệt
Đổi business rule hoặc quyết định nghiệp vụ	Cập nhật `CANONICAL_BUSINESS_RULES`, requirement, acceptance criteria, test basis và support readiness liên quan	Business Owner xác nhận nghiệp vụ; Legal hoặc Accounting Owner tham gia khi nội dung thuộc phạm vi họ
Đổi định nghĩa dữ liệu, phân loại dữ liệu hoặc retention	Cập nhật `CANONICAL_DATA_DICTIONARY`, traceability, test data và tài liệu hỗ trợ liên quan	Data owner, Security, Legal/Compliance hoặc Architect xác nhận theo phạm vi
Đổi API, tích hợp, quyền hoặc kiểm soát bảo mật	Cập nhật đặc tả kỹ thuật, test basis, runbook hỗ trợ và liên kết OWASP khi phù hợp	Technical Architect và Security có thẩm quyền; BA không tự kết luận an toàn
Đổi cách diễn giải luật, thuế, kế toán, hóa đơn, thực phẩm hoặc dữ liệu cá nhân	Gắn `Verification required`; giữ URL nguồn chính thức; dừng kết luận bắt buộc cho Nova Foods	Legal Owner, Accounting Owner, Compliance hoặc domain owner xác minh trực tiếp

Quy tắc chặn bàn giao: nếu thay đổi không có bằng chứng, chưa xác định owner có thẩm quyền, làm mâu thuẫn nguồn canonical, hoặc bị diễn đạt thành approval, phải giữ IN_REVIEW, không lan truyền như kết luận. Principal IT Business Analyst / Technical Curriculum Author lập gói escalation gồm ID bị ảnh hưởng, tệp nguồn, mô tả mâu thuẫn, tác động học liệu và câu hỏi cần quyết định. Vai trò này điều phối và bảo toàn truy vết; không thay Business Owner, Legal Owner, Accounting Owner, Security, Technical Architect, QA reviewer hay Compliance.

Bàn giao kết thúc khi người nhận có đủ tệp canonical, liên kết ID, trạng thái IN_REVIEW, nhãn dữ liệu tổng hợp và các ranh giới thẩm quyền trên. Việc nhận bàn giao chỉ xác nhận đã nhận thông tin để review; không xác nhận chất lượng chuyên môn, baseline, approval, tuân thủ hay quyền dùng production.