/01-curriculum/TEMPLATE_MANIFEST.md — Planned Template Manifest for IT BUSINESS ANALYST — ZERO TO DELIVERY READY

H1 Title, Artifact Governance Metadata, and Manifest Scope

Artifact Governance Metadata

Trường kiểm soát	Giá trị kiểm soát
Artifact ID	`TEMPLATE_MANIFEST`
Tên tệp được kiểm soát	`/01-curriculum/TEMPLATE_MANIFEST.md`
Tiêu đề artifact	`Planned Template Manifest for IT BUSINESS ANALYST — ZERO TO DELIVERY READY`
Status	`IN_REVIEW`
Version	`v0.9.0`
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm của Owner	Duy trì tính toàn vẹn quản trị của danh mục template dự kiến: metadata, version, trạng thái, lịch sử thay đổi, liên kết corpus và ranh giới sử dụng dữ liệu mô phỏng.
Giới hạn thẩm quyền Owner	Owner không tự thiết lập baseline, không ghi nhận approval, không xác nhận yêu cầu Nova Foods, không diễn giải pháp lý, không quyết định kế toán hoặc thuế, và không cho phép triển khai production.
Last updated date	`2026-08-07`
Múi giờ quản trị	`Asia/Ho_Chi_Minh`
Locale áp dụng	`vi-VN`; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng `VND`
Case-study reference	Nova Foods Trading & Manufacturing — simulated educational case study; chỉ sử dụng dữ liệu tổng hợp.
Phân loại artifact	Controlled planning artifact cho template manifest của corpus IT BUSINESS ANALYST — ZERO TO DELIVERY READY.
Baseline reference	Chưa có baseline reference tại `v0.9.0`. `IN_REVIEW` không được diễn giải là `BASELINED`.
Approval reference	Chưa có approval reference tại `v0.9.0`. Metadata, Owner và nội dung review không tạo approval ngầm định.

Metadata này xác định danh tính quản trị của /01-curriculum/TEMPLATE_MANIFEST.md tại ngày 2026-08-07. Status: IN_REVIEW nghĩa là nội dung đang được kiểm soát để xem xét và có thể thay đổi có truy vết. Trạng thái này không xác nhận template đã hoàn chỉnh, đúng chuyên môn, được người dùng chấp thuận, tuân thủ pháp luật, phù hợp hạch toán hoặc sẵn sàng cho production.

Phiên bản	Ngày ghi nhận	Trạng thái	Người ghi nhận	Nội dung thay đổi	Tác động kiểm soát
`v0.9.0`	`2026-08-07`	`IN_REVIEW`	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo metadata quản trị cho `TEMPLATE_MANIFEST`; thiết lập ownership, locale, múi giờ, tham chiếu case study Nova Foods và record lịch sử thay đổi đầu tiên.	Record khởi tạo cho planning artifact; không xác lập baseline, không ghi nhận approval và không xác nhận bất kỳ template nào đã được soạn, rà soát hoặc sẵn sàng sử dụng.

Mọi thay đổi tiếp theo đối với metadata phải bổ sung một dòng lịch sử mới, gồm phiên bản, ngày ghi nhận theo Asia/Ho_Chi_Minh, trạng thái thực tế, người ghi nhận, nội dung thay đổi và tác động kiểm soát. Không được sửa đè dòng v0.9.0. Khi thay đổi có liên quan đến dữ liệu cá nhân, kế toán, thuế, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật, nội dung chưa được xác minh từ nguồn có thẩm quyền phải giữ nhãn Verification required hoặc Project assumption; case study Nova Foods vẫn chỉ là mô phỏng giáo dục bằng dữ liệu tổng hợp.

Định danh Artifact và Tên tệp được kiểm soát

Thuộc tính định danh	Giá trị chuẩn	Quy tắc sử dụng bắt buộc
Artifact ID	`TEMPLATE_MANIFEST`	Là định danh logic duy nhất của manifest này trong corpus Nova Foods ERP. Dùng nguyên văn trong liên kết chéo, change history, traceability và kiểm tra nhất quán; không thêm tiền tố, hậu tố hoặc biến thể chữ hoa/thường.
Tên tệp được kiểm soát	`/01-curriculum/TEMPLATE_MANIFEST.md`	Là đường dẫn và tên tệp chuẩn duy nhất. Mọi tham chiếu phải giữ đủ dấu gạch chéo đầu đường dẫn, thư mục `01-curriculum`, chữ hoa của `TEMPLATE_MANIFEST` và phần mở rộng `.md`.
Tên hiển thị khi trích dẫn	`TEMPLATE_MANIFEST.md`	Chỉ dùng khi ngữ cảnh đã xác định rõ thư mục `/01-curriculum/`; không thay thế tên tệp được kiểm soát trong registry, dependency hoặc traceability.
Khóa nhận diện kết hợp	`TEMPLATE_MANIFEST` + `/01-curriculum/TEMPLATE_MANIFEST.md`	Hai giá trị phải luôn cùng tham chiếu đến một artifact. Nếu Artifact ID đúng nhưng đường dẫn khác, hoặc đường dẫn đúng nhưng ID khác, coi là mâu thuẫn định danh cần được sửa trước khi dùng liên kết.

Quy tắc đối chiếu: TEMPLATE_MANIFEST không được đổi thành TEMPLATE-MANIFEST, Template_Manifest, TEMPLATE_MANIFEST_V2 hoặc bất kỳ định danh dẫn xuất nào. Tương tự, /01-curriculum/TEMPLATE_MANIFEST.md không được tham chiếu bằng đường dẫn tương đối như TEMPLATE_MANIFEST.md khi cần xác định nguồn kiểm soát đầy đủ, và không được đổi tên thành dạng chữ thường hoặc thêm hậu tố phiên bản vào tên tệp. Phiên bản là thuộc tính quản trị riêng của artifact, không phải thành phần của Artifact ID hoặc filename.

Phạm vi lập kế hoạch được kiểm soát và ranh giới baseline

/01-curriculum/TEMPLATE_MANIFEST.md là controlled planning artifact dùng để quy hoạch các template dự kiến phục vụ corpus IT BUSINESS ANALYST — ZERO TO DELIVERY READY trong bối cảnh Nova Foods Trading & Manufacturing mô phỏng giáo dục. Phạm vi của manifest là xác định cấu trúc danh mục template, mục đích sử dụng dự kiến, quan hệ phụ thuộc, quy ước tham chiếu và điều kiện để một template được soạn thảo hoặc rà soát ở bước tiếp theo. Manifest không phải là nội dung hoàn chỉnh của từng template.

Khía cạnh	Trong phạm vi lập kế hoạch	Ranh giới không được suy diễn
Danh mục template	Lập kế hoạch các nhóm template BA, gồm discovery, process, requirements, rules, data, API, UX, NFR, integration, testing, UAT, change, release và operations.	Việc một nhóm template xuất hiện trong manifest không xác nhận template đã tồn tại, đã đầy đủ hoặc đã được kiểm thử sử dụng.
Quan hệ artifact	Xác định liên kết dự kiến giữa template với handbook chapter, canonical ID, business rule, data dictionary, traceability và evidence kiểm thử.	Liên kết dự kiến không tạo requirement, business rule, data definition hoặc test evidence mới.
Nova Foods	Dùng thuật ngữ, luồng nghiệp vụ và thực thể của Nova Foods chỉ để thiết kế bài tập và ngữ cảnh học tập có dữ liệu tổng hợp.	Không đại diện cho cấu hình ERP thực tế, dữ liệu khách hàng, chính sách nội bộ hay quyết định vận hành của bất kỳ tổ chức nào.
Baseline	Tại `IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, manifest là nội dung đang được xem xét trước drafting.	Không có baseline reference; không được gọi toàn bộ manifest, một mục template, ID, filename, bảng quy hoạch hoặc liên kết dự kiến là baseline.
Thay đổi	Có thể điều chỉnh có kiểm soát trong quá trình review để xử lý trùng lặp, thiếu traceability, xung đột naming hoặc lệch phạm vi.	Không được coi thay đổi trong review là thay đổi baseline; baseline chỉ có thể tồn tại khi được ghi nhận rõ trong artifact kiểm soát phù hợp.

Quy tắc diễn giải bắt buộc: IN_REVIEW biểu thị trạng thái xem xét của kế hoạch, không biểu thị tính ổn định cuối cùng của danh mục template. Một template chỉ được dùng như đầu vào drafting khi vẫn giữ đúng định danh, filename và phạm vi đã được kiểm soát; nếu phát hiện xung đột với nguồn canonical hoặc với biên mô phỏng Nova Foods, nội dung phải được đưa về trạng thái cần làm rõ thay vì tự tạo quy tắc, dữ liệu hoặc quyết định mới.

Giới hạn thẩm quyền của artifact lập kế hoạch

/01-curriculum/TEMPLATE_MANIFEST.md là controlled planning artifact dùng để lập kế hoạch danh mục, mục đích và quan hệ dự kiến của các template trong corpus IT BUSINESS ANALYST — ZERO TO DELIVERY READY. Artifact này không tự tạo hiệu lực quyết định ngoài phạm vi lập kế hoạch. Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, mọi nội dung chỉ là đề xuất có kiểm soát để review; không được diễn giải là đã được phê duyệt, đã chốt baseline, hoặc sẵn sàng áp dụng cho hệ thống thực tế.

Lĩnh vực hiệu lực	Artifact này được phép thực hiện	Artifact này không có thẩm quyền thực hiện
Lập kế hoạch template	Xác định template dự kiến cần có, mục tiêu học tập, loại artifact, quan hệ phụ thuộc và điểm dùng trong luồng BA.	Ban hành requirement, business rule, data definition, API contract, test result hoặc cấu hình ERP có hiệu lực thực thi.
Approval	Ghi rõ khi chưa có approval reference và định tuyến nội dung đến review phù hợp.	Xác nhận người dùng, Business Owner, Legal Owner, Accounting Owner, QA Reviewer hoặc bất kỳ vai trò nào đã chấp thuận. `IN_REVIEW` không phải `APPROVED`.
Baseline	Nêu ranh giới rằng nội dung đang được xem xét và có thể thay đổi có kiểm soát.	Gọi template, TMPL ID, filename, cấu trúc trường, ví dụ hoặc liên kết trong manifest là baseline. Không có baseline reference tại `v0.9.0`.
Pháp lý và compliance	Gắn nhãn `Verification required` hoặc `Project assumption` cho nội dung chưa được xác minh; định tuyến sang nguồn và vai trò có thẩm quyền.	Diễn giải, xác nhận tuân thủ, áp dụng ngoại lệ hoặc quyết định nghĩa vụ theo pháp luật về dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc, thuế hoặc lao động.
Kế toán và tài chính	Mô tả nhu cầu template phục vụ phân tích dữ liệu, quy trình hoặc kiểm soát dự kiến trong bài học.	Quyết định hạch toán, ghi nhận doanh thu, định giá tồn kho, nghĩa vụ thuế, chứng từ hợp lệ hoặc chính sách tài chính.
Production và vận hành	Hỗ trợ người học chuẩn bị artifact để review, kiểm thử và handoff trong bối cảnh mô phỏng.	Cho phép triển khai production, phê chuẩn release, xác nhận bảo mật, xác nhận chất lượng vận hành hoặc cho phép xử lý dữ liệu thực.

Quy tắc diễn giải bắt buộc: một approval, baseline, quyết định pháp lý, quyết định kế toán hoặc quyết định production chỉ có hiệu lực khi được ghi nhận rõ trong artifact kiểm soát phù hợp bởi vai trò có thẩm quyền đối với đúng phạm vi quyết định. Việc một template được liệt kê trong manifest không chứng minh template đó đã hoàn chỉnh, đã được sử dụng, đã được kiểm thử, hoặc phù hợp với một tổ chức thực tế.

Mọi ví dụ liên quan Nova Foods Trading & Manufacturing chỉ phục vụ mô phỏng giáo dục và sử dụng dữ liệu tổng hợp. Ví dụ về đơn hàng, lô hàng, tồn kho, hạn dùng, hóa đơn, khách hàng hoặc dữ liệu cá nhân không được dùng để suy ra quy tắc pháp lý, chính sách kế toán, cấu hình ERP hay quyết định vận hành cho Nova Foods hoặc bất kỳ doanh nghiệp nào.

Liên kết bắt buộc với ranh giới case study Nova Foods

/01-curriculum/TEMPLATE_MANIFEST.md chỉ lập kế hoạch cho các template được sử dụng trong case study Nova Foods Trading & Manufacturing. Nova Foods là bối cảnh đào tạo ERP mô phỏng tại Việt Nam, sử dụng hoàn toàn dữ liệu tổng hợp; không đại diện cho khách hàng, pháp nhân, hệ thống ERP, quy trình nội bộ, hợp đồng, hồ sơ nhân sự, giao dịch, chứng từ hay dữ liệu cá nhân của một tổ chức thực tế.

Thành phần được liên kết	Ranh giới áp dụng trong manifest	Không được suy diễn
Tên tổ chức	Dùng thống nhất tên `Nova Foods Trading & Manufacturing` trong tiêu đề template, scenario, ví dụ và traceability liên quan case study.	Nova Foods là pháp nhân thực, khách hàng thật hoặc đơn vị đã cung cấp thông tin.
Bối cảnh nghiệp vụ	Template có thể hướng dẫn phân tích các miền ERP mô phỏng như bán hàng, mua hàng, tồn kho, sản xuất, lô hàng, hạn dùng, chất lượng, truy xuất nguồn gốc và tài chính.	Quy trình mô phỏng là quy trình vận hành hiện hành, cấu hình đã triển khai hoặc quyết định nghiệp vụ của Nova Foods.
Dữ liệu	Mọi mã, tên người, địa chỉ, số lượng, giá trị `VND`, ngày tháng, lô hàng, đơn hàng, nhà cung cấp và khách hàng dùng trong template phải là dữ liệu tổng hợp phục vụ học tập.	Dữ liệu đó là dữ liệu thật, dữ liệu production, chứng từ hợp lệ hoặc bằng chứng kiểm toán.
Nội dung có tính quy định	Template được phép chứa trường ghi nhận nguồn, giả định và nhãn `Verification required` cho chủ đề pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc.	Một ví dụ template tạo thành nghĩa vụ pháp lý, cách hạch toán, kiểm soát tuân thủ hoặc chỉ dẫn production.
Liên kết corpus	Template phải giữ thuật ngữ và ranh giới Nova Foods nhất quán với `/01-curriculum/01_CURRICULUM_ARCHITECTURE.md` và `/01-curriculum/CHAPTER_MANIFEST.md`.	Manifest được quyền thay đổi độc lập thuật ngữ, thực thể hoặc phạm vi case study đã được kiểm soát ở artifact liên quan.

Quy tắc áp dụng: khi một template cần minh họa quyết định nghiệp vụ, chỉ được trình bày đó là Project assumption nếu chưa có xác minh phù hợp; khi nội dung có thể bị hiểu là yêu cầu bắt buộc theo pháp luật hoặc theo vận hành thực tế, phải ghi Verification required và định tuyến việc xác minh tới vai trò có thẩm quyền. Template manifest không mở rộng case study sang triển khai ERP thực tế, không cho phép nhập dữ liệu ngoài phạm vi mô phỏng, và không biến scenario đào tạo thành requirement đã được phê duyệt.

Template Catalog Architecture, TMPL Identifier Registry, and File-Naming Rules

Stable TMPL identifier pattern and registry rules

Mỗi template trong thư viện Nova Foods phải có một định danh duy nhất, dễ đọc bởi con người và ổn định cho liên kết nội bộ. Người quản trị registry cấp TMPL ID trước khi template được đưa vào thư viện; người soạn template dùng đúng ID đã cấp để liên kết trong manifest, traceability matrix và các artifact liên quan. Kết quả là mỗi template có một khóa tham chiếu ổn định, không phụ thuộc trạng thái review hoặc phiên bản nội dung.

Định danh template không mô tả trạng thái review, phiên bản tài liệu, tên người soạn hoặc quyết định triển khai; các thông tin đó thay đổi theo thời gian và không được đưa vào mã định danh. Tách các thông tin biến động khỏi ID giúp tránh đổi liên kết khi template được chỉnh sửa, nhưng yêu cầu owner cập nhật metadata và lịch sử thay đổi ở artifact quản trị tương ứng.

Mẫu định danh chuẩn:

TMPL-{DOMAIN}-{NNN}

Thành phần	Quy tắc	Ví dụ hợp lệ	Không hợp lệ
`TMPL`	Tiền tố cố định, viết hoa, xác định đây là template được quản trị trong corpus.	`TMPL-REQ-001`	`TEMPLATE-REQ-001`, `tmpl-req-001`
`{DOMAIN}`	Mã miền chức năng gồm 2–5 ký tự in hoa, được tạo một lần trong registry trước khi cấp ID đầu tiên.	`REQ`, `DATA`, `TEST`, `UAT`, `NFR`, `UATP`, `OPSH`	`REQUIREMENTS`, `data`, `01`, `UATPREP`, `OPSHND`
`{NNN}`	Số thứ tự ba chữ số từ `001` đến `999`, duy nhất trong cùng `{DOMAIN}`. Số được giữ nguyên sau khi cấp.	`TMPL-REQ-001`, `TMPL-UATP-001`, `TMPL-OPSH-001`	`TMPL-REQ-1`, `TMPL-REQ-0001`, `TMPL-UATP-01`

Registry phải ghi nhận domain hợp lệ trước khi owner cấp ID đầu tiên trong domain đó. Domain UATP đại diện cho nhóm chuẩn bị UAT; domain OPSH đại diện cho nhóm bàn giao vận hành. Người quản trị không dùng UATPREP hoặc OPSHND làm domain vì các mã này vượt quá giới hạn 2–5 ký tự.

Mỗi lần cấp ID, người quản trị ghi tối thiểu TMPL ID, domain, số thứ tự, tên template, filename được kiểm soát, owner và trạng thái review trong registry. Registry giữ nguyên ID đã cấp, kể cả khi template bị ngừng sử dụng; template thay thế phải nhận ID mới để bảo toàn lịch sử truy vết. Hệ quả là số thứ tự có thể bị khuyết, nhưng không được tái sử dụng cho artifact khác.

Người soạn kiểm tra ba điều trước khi tham chiếu ID: tiền tố là TMPL, domain dài 2–5 ký tự in hoa và số thứ tự có đúng ba chữ số. Quality gate từ chối bản ghi có domain ngoài registry, ID trùng trong cùng domain hoặc định dạng không khớp TMPL-{DOMAIN}-{NNN}. Cách kiểm tra này ưu tiên tính ổn định truy vết hơn việc lấp đầy tuần tự mọi số thứ tự.

Quy tắc cấp và bảo toàn TMPL identifier

Chỉ được tạo TMPL ID sau khi xác định template là một artifact tái sử dụng độc lập, có mục đích BA riêng và có cấu trúc đầu vào, nội dung cần điền hoặc đầu ra xác định được.
Một template chỉ có một TMPL ID; một TMPL ID chỉ đại diện cho một template. Không dùng cùng mã cho bản rút gọn, bản dịch, biến thể theo dự án hoặc bản thay đổi nội dung.
{DOMAIN} biểu thị miền nghiệp vụ hoặc kỹ năng chính của template, không biểu thị phòng ban Nova Foods, người sở hữu, sprint, năm, trạng thái hay mức độ ưu tiên.
{NNN} được cấp tăng dần trong từng miền tại thời điểm đăng ký. Khoảng số chưa dùng không được tự động lấp lại nếu việc lấp có thể gây nhầm lẫn với ID từng xuất hiện trong bản review, bản phát hành hoặc liên kết học tập.
Không được đổi TMPL-REQ-001 thành một mã khác chỉ vì template được mở rộng, chuyển vị trí trong curriculum, thay đổi tiêu đề, sửa cấu trúc trường hoặc cập nhật hướng dẫn sử dụng.
Không được tái sử dụng một mã đã từng được đăng ký, kể cả khi template tương ứng bị rút khỏi phạm vi, thay thế hoặc đánh dấu không sử dụng. Bản ghi cũ phải được giữ với trạng thái quản trị phù hợp để bảo toàn lịch sử.
Khi thay đổi làm template không còn cùng mục đích, đối tượng sử dụng hoặc đầu ra cốt lõi, phải tạo TMPL ID mới. Template cũ giữ mã cũ và được ghi nhận quan hệ thay thế trong registry.
Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, các mã được đăng ký là định danh kế hoạch có kiểm soát; chúng không phải baseline, không xác nhận approval và không xác nhận template đã sẵn sàng dùng cho delivery hoặc production.

Cấu trúc bản ghi TMPL identifier tối thiểu

Mỗi dòng đăng ký phải có đủ trường dưới đây để ngăn cấp trùng, đổi nghĩa mã hoặc suy diễn thẩm quyền từ ID.

Trường registry	Quy tắc ghi nhận
`TMPL ID`	Mã theo mẫu `TMPL-{DOMAIN}-{NNN}`; là khóa duy nhất và bất biến của template.
Tên template chuẩn	Tên mô tả mục đích artifact bằng tiếng Việt hoặc tên được kiểm soát trong corpus; không thay thế `TMPL ID`.
Mục đích cốt lõi	Một câu xác định vấn đề BA mà template hỗ trợ giải quyết.
Domain code	Giá trị `{DOMAIN}` đã dùng trong ID; phải nhất quán với registry.
Trạng thái đăng ký	`ACTIVE`, `RETIRED` hoặc `SUPERSEDED`; không dùng trạng thái này để suy ra approval hay baseline.
TMPL ID thay thế	Chỉ ghi khi template được thay thế; dùng `N/A` khi chưa có template thay thế.
Lý do cấp hoặc thay thế	Diễn giải ngắn gọn về nhu cầu tạo mới hoặc quan hệ thay thế, không ghi nhận quyết định chưa có thẩm quyền.
Ngày ghi nhận	Ngày theo định dạng `YYYY-MM-DD`, múi giờ quản trị `Asia/Ho_Chi_Minh`.
Người ghi nhận	Vai trò hoặc người duy trì registry; việc ghi nhận không đồng nghĩa phê duyệt nội dung template.

Ví dụ bản ghi hợp lệ trong trạng thái lập kế hoạch:

TMPL ID	Tên template chuẩn	Mục đích cốt lõi	Domain code	Trạng thái đăng ký	TMPL ID thay thế	Ngày ghi nhận
`TMPL-REQ-001`	Functional Requirement Specification	Ghi nhận requirement chức năng có thể kiểm tra cho scenario Nova Foods mô phỏng.	`REQ`	`ACTIVE`	`N/A`	`2026-08-07`
`TMPL-DATA-001`	Data Definition Record	Ghi nhận định nghĩa dữ liệu, nguồn, quy tắc xác minh và ràng buộc sử dụng dữ liệu tổng hợp.	`DATA`	`ACTIVE`	`N/A`	`2026-08-07`
`TMPL-TEST-001`	Test Case Specification	Cấu trúc hóa test case từ test basis đã xác định trong corpus đào tạo.	`TEST`	`ACTIVE`	`N/A`	`2026-08-07`

Nếu có mâu thuẫn giữa mã trong nội dung template và mã trong registry, bản ghi registry là điểm kiểm tra nhận diện cần được rà soát; không được tự sửa mã trong một artifact đơn lẻ để tạo ra hai định danh cho cùng một template.

Quy ước tên tệp chính xác cho từng template artifact

Mỗi template artifact phải có một đường dẫn tệp kiểm soát duy nhất, ghi trong cột Controlled File Path của catalog. Tên tệp là định danh kỹ thuật dùng cho liên kết nội bộ, kiểm tra tự động, lịch sử thay đổi và tham chiếu chéo; không dùng tiêu đề hiển thị thay thế tên tệp.

Thành phần	Quy ước bắt buộc	Ví dụ cú pháp
Thư mục lưu trữ	`/02-templates/`	`/02-templates/`
Tên tệp	`{TMPL_ID}--{english-kebab-slug}.md`	`TMPL-<DOMAIN>-<NNN>--<english-kebab-slug>.md`
Phân cách ID và slug	Chính xác hai dấu gạch ngang `--`	`TMPL-<DOMAIN>-<NNN>--<slug>.md`
Slug nghiệp vụ	Chữ thường ASCII, từ tiếng Anh mô tả mục đích artifact, phân cách bằng một dấu gạch ngang đơn `-`	`stakeholder-interview-guide`
Phần mở rộng	Chỉ dùng `.md` cho template nguồn có kiểm soát	`.md`
Tiền tố bị cấm	Không thêm `draft-`, `final-`, `new-`, `copy-`, `backup-`, tên cá nhân hoặc tên công cụ AI	Không dùng `draft-TMPL-<DOMAIN>-<NNN>--<slug>.md`
Thông tin bị cấm trong filename	Không đưa version, status, ngày, múi giờ, tiền tệ, tên reviewer hoặc trạng thái approval vào filename	Không dùng `TMPL-<DOMAIN>-<NNN>--<slug>-v0.9.0.md`

Mẫu đường dẫn chuẩn

/02-templates/TMPL-<DOMAIN>-<NNN>--<english-kebab-slug>.md

Quy ước này áp dụng cho template trống, template có hướng dẫn điền, template ví dụ Nova Foods và template kiểm soát chất lượng. Nội dung Nova Foods trong tệp chỉ là mô phỏng giáo dục với dữ liệu tổng hợp; tên tệp không được chứa tên cá nhân, dữ liệu khách hàng, mã lô thực tế, số hóa đơn, dữ liệu cá nhân hoặc thông tin có thể bị hiểu là production.

Tình huống	Cách đặt tên hợp lệ	Cách xử lý kiểm soát
Tạo template mới	Dùng đúng đường dẫn theo mẫu chuẩn sau khi catalog ghi nhận `TMPL_ID` và slug	Tạo một file `.md` duy nhất tại đường dẫn kiểm soát.
Sửa nội dung template	Giữ nguyên filename hiện có	Ghi nhận thay đổi trong metadata và change history của artifact, không tạo bản sao bằng tên tệp khác.
Đổi tiêu đề hiển thị	Giữ nguyên filename nếu mục đích artifact không đổi	Tiêu đề có thể được cập nhật có kiểm soát; filename không tự động thay đổi theo tiêu đề.
Cần thay đổi mục đích template	Không sửa slug hoặc đổi tên tệp để che lấp thay đổi phạm vi	Đánh giá như thay đổi kiểm soát; không dùng filename cũ cho artifact có mục đích khác.
Tạo bản xuất để review	Giữ template nguồn tại đường dẫn chuẩn; bản xuất không thay thế artifact nguồn	Bản xuất phải tham chiếu lại `Controlled File Path` của template nguồn.

Slug phải mô tả một mục đích nghiệp vụ hoặc BA duy nhất, không phải tên chương trình, trạng thái soạn thảo hay mô tả chung chung. Vì vậy, các slug như document, template, latest, review và nova-foods-file không hợp lệ do không xác định được chức năng artifact. Khi tiêu đề hiển thị bằng tiếng Việt, filename vẫn dùng slug tiếng Anh ASCII để tránh khác biệt mã hóa, lỗi liên kết giữa môi trường và biến thể dấu tiếng Việt.

Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, quy ước trên là planned naming convention cho thư viện template. Nó không xác lập baseline, approval, cấu hình ERP Nova Foods hoặc quyền đưa artifact vào production.

Taxonomy danh mục template và quy tắc sắp xếp

Danh mục template được tổ chức theo dòng chảy tạo bằng chứng của IT Business Analyst, không theo chức danh người viết hoặc công cụ sử dụng. Nguyên tắc đầu tiên là: template xuất hiện trước phải tạo đầu vào kiểm soát được cho template xuất hiện sau; vì vậy người học có thể đi từ hiểu vấn đề, mô hình hóa quy trình, xác định yêu cầu, thiết kế giao tiếp hệ thống, đến xác nhận chất lượng và bàn giao vận hành mà không tự suy diễn dữ liệu hoặc quy tắc.

Thứ tự taxonomy	Nhóm template	Mục đích trong chuỗi BA	Đầu vào logic	Đầu ra logic cho nhóm kế tiếp
01	Discovery	Ghi nhận bối cảnh, stakeholder, vấn đề, mục tiêu, phạm vi và giả định của Nova Foods.	Business context mô phỏng, nhu cầu học tập, stakeholder giả định.	Problem statement, scope boundary, stakeholder need, decision question.
02	Process	Mô tả luồng nghiệp vụ hiện tại hoặc mục tiêu, vai trò, sự kiện, điểm quyết định và ngoại lệ.	Discovery findings đã phân loại.	Process step, actor, trigger, exception, pain point và process requirement candidate.
03	Requirements	Chuyển nhu cầu và quy trình thành yêu cầu có thể đánh giá.	Scope, process, stakeholder need và constraint đã ghi nhận.	Functional requirement, non-functional requirement candidate, acceptance condition và dependency.
04	Business Rules	Tách quy tắc quyết định khỏi mô tả quy trình và yêu cầu để quản lý thay đổi độc lập.	Requirement candidate, process decision point và domain assumption.	Rule statement, condition, outcome, exception và rule-to-requirement linkage.
05	Data	Chuẩn hóa thực thể, thuộc tính, định nghĩa, giá trị hợp lệ và chất lượng dữ liệu.	Process, requirement và business rule liên quan dữ liệu.	Data definition, validation constraint, ownership và integration data mapping input.
06	API và Integration	Xác định hợp đồng trao đổi giữa ERP Nova Foods và hệ thống hoặc dịch vụ liên quan.	Functional requirement, data definition, event và business rule.	Interface contract candidate, request/response data, error scenario và integration test basis.
07	UX	Biến yêu cầu và quy tắc thành hành vi màn hình, trạng thái, thông báo và tiêu chí khả dụng.	User task, functional requirement, data validation và rule outcome.	Screen behavior, field rule, user journey và UX acceptance condition.
08	NFR	Ghi nhận thuộc tính chất lượng như hiệu năng, bảo mật, khả dụng, accessibility và auditability.	Risk, architecture constraint, interface hoặc user journey.	Measurable quality condition và verification approach.
09	Testing và Delivery Control	Chuẩn bị test basis, defect handling, UAT, change, release và operations handoff.	Requirement, rule, data, API, UX và NFR đã được liên kết.	Test evidence structure, release readiness input và operational knowledge input.

Quy tắc sắp xếp bắt buộc

Catalog luôn hiển thị nhóm theo thứ tự Discovery → Process → Requirements → Business Rules → Data → API và Integration → UX → NFR → Testing và Delivery Control. Thứ tự này là thứ tự điều hướng và học tập; không khẳng định các hoạt động dự án thực tế phải diễn ra tuần tự tuyệt đối.
Trong từng nhóm, template được sắp xếp theo mức độ từ khái quát đến chi tiết: context hoặc scope trước, mô hình hoặc phân tích kế tiếp, specification sau cùng, rồi mới đến template kiểm tra hoặc bàn giao của cùng phạm vi.
Khi một template phục vụ nhiều nhóm, nó chỉ có một vị trí chính dựa trên đầu ra quyết định mà nó kiểm soát. Ví dụ, template ghi quy tắc “chặn xuất kho khi lô hàng không đạt điều kiện mô phỏng” thuộc nhóm Business Rules, dù quy tắc đó được dùng bởi Process, UX và Testing.
Template không được đặt trong nhóm chỉ vì chứa từ khóa tương tự. Tiêu chí phân loại là loại bằng chứng chính: nhu cầu thuộc Discovery; luồng thuộc Process; điều kiện hệ thống phải đáp ứng thuộc Requirements; quyết định nghiệp vụ thuộc Business Rules; cấu trúc thông tin thuộc Data; trao đổi hệ thống thuộc API và Integration; tương tác người dùng thuộc UX; thuộc tính chất lượng thuộc NFR; bằng chứng xác nhận và chuyển giao thuộc Testing và Delivery Control.
Một template không được dùng để thay thế nguồn chân lý chuyên biệt. Template Process không trở thành nơi định nghĩa dữ liệu chuẩn; template API không trở thành nơi phê chuẩn business rule; template Testing không tạo mới requirement không có test basis.
Các nội dung liên quan pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật chỉ được xếp vào taxonomy theo loại artifact BA. Nếu chưa được đối chiếu bởi vai trò có thẩm quyền và nguồn chính thức phù hợp, nội dung phải giữ nhãn Verification required hoặc Project assumption; vị trí trong catalog không tạo hiệu lực tuân thủ.
Taxonomy này áp dụng cho template library của corpus Nova Foods Trading & Manufacturing dùng dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh và VND. Nó là cấu trúc lập kế hoạch tại IN_REVIEW, v0.9.0, ngày 2026-08-07; không là baseline, approval hoặc chỉ thị triển khai.

Bất biến định danh template sau khi được baseline

Tại ngày 2026-08-07, TEMPLATE_MANIFEST.md có trạng thái IN_REVIEW, phiên bản v0.9.0 và chưa có tham chiếu baseline. Vì vậy, các quy tắc dưới đây là kiểm soát bắt buộc khi một template entry được baseline hợp lệ trong tương lai; chúng không tuyên bố rằng bất kỳ TMPL nào hiện đã được baseline hoặc approved.

Một template identifier đã baseline là khóa nhận diện lịch sử của artifact. Khóa này phải tiếp tục chỉ đến cùng một loại template, cùng mục đích kiểm soát và cùng chuỗi bằng chứng thay đổi, kể cả khi nội dung template được sửa đổi qua các phiên bản sau.

Tình huống thay đổi	Có được đổi `TMPL` đã baseline?	Xử lý bắt buộc
Sửa lỗi chính tả, hướng dẫn điền, bảng biểu hoặc ví dụ dữ liệu tổng hợp	Không	Giữ nguyên `TMPL` hiện hữu; ghi nhận thay đổi theo cơ chế version và change history áp dụng.
Bổ sung trường, quy tắc kiểm tra hoặc phần hướng dẫn làm rõ nhưng mục đích template không đổi	Không	Duy trì `TMPL` hiện hữu; đánh giá tác động tới các artifact đang tham chiếu trước khi phát hành phiên bản mới.
Đổi tên hiển thị của template để dễ đọc	Không	Tên hiển thị có thể được điều chỉnh có kiểm soát nếu cần, nhưng `TMPL` và filename đã baseline không được đổi.
Đổi mục đích từ template discovery sang template requirements	Không	Giữ template cũ như một artifact lịch sử; tạo template mới với `TMPL` mới cho mục đích mới.
Tách một template đã baseline thành hai template độc lập	Không	Template gốc giữ `TMPL` và lịch sử của nó; mỗi template mới nhận `TMPL` mới, không kế thừa định danh gốc.
Gộp hai template đã baseline	Không	Không tạo một artifact mới bằng cách tái sử dụng một trong hai `TMPL` cũ; template hợp nhất phải nhận `TMPL` mới.
Ngừng sử dụng template	Không	Đánh dấu trạng thái ngừng sử dụng theo kiểm soát thay đổi áp dụng; giữ lại `TMPL`, filename, lịch sử và các liên kết lịch sử.
Xóa file bị thay thế	Không	Không tái phân bổ `TMPL` hoặc filename đã baseline cho template khác. Việc lưu trữ phải bảo toàn khả năng truy xuất lịch sử.

Quy tắc cấm tái sử dụng

Một TMPL đã baseline không được gán cho template mới, kể cả khi template cũ đã ngừng sử dụng, bị thay thế, được lưu trữ hoặc không còn nằm trong danh mục đang hoạt động.
Không được “sửa lại lịch sử” bằng cách đổi TMPL trong bản ghi baseline, đổi filename đã baseline, hoặc thay nội dung template cũ bằng một mục đích khác.
Không được dùng lại định danh đã hủy trong giai đoạn soạn thảo nếu định danh đó từng xuất hiện trong baseline hợp lệ. Khoảng trống số thứ tự là dấu vết quản trị hợp lệ, không phải lỗi cần lấp đầy.
Nếu phát hiện hai template cùng mang một TMPL, phải dừng việc tạo tham chiếu mới tới cả hai bản sao, xác định bản ghi được baseline trước, và mở thay đổi có kiểm soát để cấp TMPL mới cho artifact không phải bản ghi lịch sử.
Không suy diễn rằng một TMPL có thể đổi vì artifact đang ở IN_REVIEW. Chỉ định danh chưa từng baseline mới có thể được điều chỉnh trong quá trình review, với lịch sử thay đổi rõ ràng và không làm sai lệch các tham chiếu đã công bố trong corpus.
Quy tắc bất biến này chỉ bảo vệ nhận diện artifact; nó không tạo approval, không xác nhận nội dung template đúng nghiệp vụ, và không cho phép dùng template làm quyết định triển khai Nova Foods.

Trường Generation Batch và quy tắc tuần tự hóa lô tạo template

Mỗi entry template trong catalog phải có trường bắt buộc Generation Batch. Trường này xác định lô soạn tạo có kiểm soát để điều phối thứ tự drafting, self-review và kiểm tra tính đầy đủ của template library; nó không phải version, trạng thái phê duyệt, baseline, mức ưu tiên nghiệp vụ hoặc bằng chứng template đã hoàn thành.

Trường catalog	Giá trị bắt buộc	Quy tắc nhập
`Generation Batch`	`GB-01`, `GB-02`, `GB-03` theo mẫu `GB-{NN}`	`NN` là số thứ tự hai chữ số, bắt đầu từ `01`, tăng liên tục từng đơn vị trong phạm vi manifest.
`Batch Sequence`	Số nguyên dương tương ứng, ví dụ `1`, `2`, `3`	Dùng để kiểm tra máy và sắp xếp bảng; phải khớp với phần số của `Generation Batch`.
`Batch Purpose`	Mô tả ngắn mục đích lô	Chỉ mô tả lý do điều phối drafting, ví dụ “Thiết lập template đầu vào discovery”. Không diễn giải thành quyết định triển khai Nova Foods.
`Batch Entry Status`	`PLANNED`, `DRAFTING`, `REVIEW_READY`, hoặc `BLOCKED`	Là trạng thái điều phối của entry trong lô, độc lập với `Status: IN_REVIEW` của manifest. Không dùng `APPROVED` hoặc `BASELINED` khi không có bằng chứng kiểm soát tương ứng.

Quy tắc tuần tự:

Lô GB-01 là lô đầu tiên của manifest; không được có GB-00, số âm, số thập phân, hậu tố tự do hoặc hai entry có cùng tổ hợp Generation Batch và Batch Sequence nhưng được hiểu là hai lô khác nhau.
Một template chỉ thuộc đúng một Generation Batch tại một phiên bản manifest. Nếu cần thay đổi thứ tự drafting, phải cập nhật entry, lịch sử thay đổi và tác động kiểm soát; không được âm thầm chuyển template giữa các lô.
GB-(n+1) chỉ được chuyển sang DRAFTING khi các dependency nội bộ được ghi nhận cho lô trước đã có trạng thái REVIEW_READY hoặc khi entry bị phụ thuộc được đánh dấu BLOCKED kèm lý do, owner xử lý và tác động được nêu rõ. Quy tắc này ngăn lô sau tự suy diễn cấu trúc từ template chưa được review.
Khi một lô bị BLOCKED, các template không phụ thuộc vào điểm chặn có thể tiếp tục trong chính lô đó nếu phạm vi độc lập được chứng minh trong catalog. Template phụ thuộc không được tự tạo business rule, data definition, requirement hoặc quyết định Nova Foods để vượt qua điểm chặn.
Không được chèn một lô mới vào giữa các số đã công bố bằng định dạng như GB-02A. Lô phát sinh sau khi đã có GB-02 phải nhận số kế tiếp chưa dùng, ví dụ GB-03; thứ tự kế hoạch của các entry hiện hữu phải được ghi nhận lại có truy vết nếu bị ảnh hưởng.
Hoàn tất một lô chỉ xác nhận các điều kiện quản trị của lô đã được kiểm tra: mọi entry có trạng thái rõ ràng, không có entry thiếu batch, và các điểm chặn được ghi nhận. Hoàn tất lô không xác nhận chất lượng chuyên môn, tính đúng pháp lý, approval, baseline hay khả năng sử dụng production.

Ví dụ cấu trúc giá trị hợp lệ trong catalog:

Generation Batch	Batch Sequence	Batch Purpose	Batch Entry Status	Diễn giải kiểm soát
`GB-01`	1	Thiết lập các template cần cho đầu vào phân tích ban đầu	`PLANNED`	Lô đầu tiên được lập kế hoạch; chưa xác nhận template đã được soạn.
`GB-02`	2	Soạn các template phụ thuộc vào đầu ra phân tích đã được cấu trúc	`PLANNED`	Chỉ bắt đầu theo điều kiện dependency của lô trước.
`GB-03`	3	Hoàn thiện các template cần kiểm tra liên kết đầu ra	`BLOCKED`	Phải nêu nguyên nhân chặn tại entry liên quan; không suy diễn nội dung còn thiếu.

Tại v0.9.0, các batch là kế hoạch điều phối cho corpus Nova Foods Trading & Manufacturing sử dụng dữ liệu tổng hợp. Việc gán batch không thay đổi định danh template, không tạo quyền đổi tên artifact, và không thay thế kiểm soát thay đổi khi manifest được cập nhật.

Liên kết truy vết với `TRACEABILITY_ID_REGISTRY.md` và `CHAPTER_MANIFEST.md`

Mỗi entry template trong manifest phải có liên kết quản trị hai chiều tới /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CHAPTER_MANIFEST.md. Mục tiêu là chứng minh template thuộc corpus được kiểm soát, phục vụ chapter nào và sử dụng định danh truy vết nào mà không tự tạo nguồn chân lý mới.

Liên kết bắt buộc	Artifact nguồn chân lý	Nội dung phải đối chiếu	Quy tắc kiểm soát
Định danh truy vết	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	`TRACEABILITY_ID`, loại đối tượng, mô tả phạm vi và trạng thái đăng ký	Template chỉ tham chiếu ID đã tồn tại trong registry; không tự sinh, đổi nghĩa hoặc dùng lại ID từ registry.
Vị trí học tập	`/01-curriculum/CHAPTER_MANIFEST.md`	`CH-xx`, tên chapter, tệp chapter và vai trò đầu vào/đầu ra	Chapter được liên kết phải tồn tại trong manifest 26 chapter; không được suy diễn chapter ngoài tập `00-foundations.md` đến `25-ai-assisted-ba-workflow.md`.
Quan hệ sử dụng	Cả hai artifact	Template là đầu vào, đầu ra, bài thực hành, hoặc evidence dự kiến của chapter	Quan hệ phải được ghi rõ theo một vai trò duy nhất cho từng liên kết; nếu một template phục vụ nhiều chapter, ghi một dòng cho từng chapter.
Kiểm soát thay đổi	Cả hai artifact	Tác động khi ID traceability hoặc chapter thay đổi	Bất nhất liên kết là lỗi catalog cần review; không được âm thầm sửa tham chiếu trong một artifact đơn lẻ.

Bảng liên kết tối thiểu của mỗi entry template phải chứa các trường sau:

Trường	Giá trị ghi nhận
`Traceability registry reference`	Đường dẫn cố định `/01-curriculum/TRACEABILITY_ID_REGISTRY.md` và ID đã đăng ký tương ứng
`Chapter manifest reference`	Đường dẫn cố định `/01-curriculum/CHAPTER_MANIFEST.md` và `CH-xx` liên quan
`Learning-use relationship`	Một trong: `Input`, `Output`, `Practice`, `Assessment evidence`
`Consistency status`	`Matched`, `Mismatch` hoặc `Verification required`
`Review note`	Lý do cụ thể khi là `Mismatch` hoặc `Verification required`, không thay bằng suy đoán

Ví dụ về nguyên tắc diễn giải: khi template tham chiếu REQ-FUNC-SALES-012, manifest template phải đối chiếu ID này với registry trước khi dùng trong ví dụ, bài tập hoặc mapping chapter. Việc ID xuất hiện trong template không xác nhận đó là requirement Nova Foods đã được phê duyệt. Tương tự, việc template được nối với một CH-xx chỉ xác định vị trí dự kiến trong curriculum; không xác nhận chapter đã hoàn chỉnh, baselined, approved hoặc sẵn sàng production.

Tại v0.9.0, ngày 2026-08-07, cả liên kết registry và chapter manifest được sử dụng trong phạm vi planning artifact IN_REVIEW. Nếu registry chưa có record tương ứng, hoặc chapter manifest không chứng minh được chapter được tham chiếu, entry template phải mang Consistency status: Verification required và không được trình bày liên kết đó như một quan hệ đã xác nhận.

Discovery, Process, Requirements, Rules, Data, API, UX, NFR, and Integration Templates

Nhóm template Discovery và Business Need Capture

Discovery là hoạt động làm rõ vấn đề, cơ hội, mục tiêu, phạm vi quyết định và nguồn bằng chứng trước khi diễn giải thành yêu cầu. Business need không phải là giải pháp, cấu hình ERP, business rule, user story hay cam kết triển khai. Mọi nội dung Nova Foods bên dưới là mô phỏng giáo dục bằng dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Trường catalog	Giá trị kiểm soát
Template ID	`TMPL-DISC-001`
Tên tệp được kiểm soát	`/01-curriculum/templates/TMPL-DISC-001_DISCOVERY_AND_BUSINESS_NEED_CAPTURE.md`
Tên template	Discovery and Business Need Capture
Mục đích	Ghi nhận có cấu trúc vấn đề hoặc cơ hội nghiệp vụ, tác động hiện tại, kết quả mong đợi, stakeholder, giả định, giới hạn phạm vi, câu hỏi cần xác minh và bằng chứng nguồn. Template tạo testable business context; không tự tạo requirement được phê duyệt.
Dùng khi	Khởi động một chủ đề ERP Nova Foods; có tín hiệu về chậm trễ, lỗi dữ liệu, chi phí, rủi ro hoặc cơ hội cải thiện; cần thống nhất vấn đề trước workshop, phỏng vấn hoặc quan sát nghiệp vụ.
Không dùng khi	Mục tiêu là mô tả luồng xử lý chi tiết, đặc tả yêu cầu chức năng, quản trị business rule, định nghĩa dữ liệu, thiết kế API, thiết kế UX hoặc ghi nhận NFR. Các nội dung này thuộc template chuyên biệt và chỉ nhận discovery artifact làm đầu vào.
Owner	IT Business Analyst được phân công cho discovery. Owner duy trì tính đầy đủ và truy vết của artifact, không có thẩm quyền xác nhận quyết định vận hành, pháp lý, kế toán, compliance hoặc production.
Consumers	Business Owner, Subject Matter Expert, Solution Architect, Product Owner, QA Reviewer và nhóm curriculum.
Upstream artifacts	Problem statement do Business Owner cung cấp; ghi chú phỏng vấn hoặc workshop; dữ liệu quan sát tổng hợp; glossary được kiểm soát; `/01-curriculum/CHAPTER_MANIFEST.md`; `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`.
Downstream artifacts	Discovery summary đã review; decision log; phạm vi elicitation; danh sách stakeholder; input dự kiến cho process analysis và requirements specification.
Nguồn phương pháp	`BABOK Guide`, IIBA, Version 3, nguồn primary cho thuật ngữ và hoạt động business analysis. Không viện dẫn số trang hoặc điều khoản chưa được xác minh từ bản có giấy phép.
Quality gate	`QG-DISC-001` — chỉ đạt khi business need phân biệt rõ với solution, có evidence/source cho từng nhận định trọng yếu, có owner của quyết định nghiệp vụ, có giả định và câu hỏi mở được gắn nhãn, và không có phát biểu pháp lý hoặc vận hành được trình bày như đã được xác nhận khi chưa có bằng chứng phù hợp.

Bốn tầng nghĩa vụ của `TMPL-DISC-001`

Tầng	Nghĩa vụ bắt buộc	Điều kiện không đạt
Tier 1 — Nhận diện	Có `Template ID`, artifact title, status, version, ngày, owner, phạm vi Nova Foods và phân loại dữ liệu tổng hợp.	Thiếu metadata hoặc mô tả dữ liệu mô phỏng như dữ liệu vận hành thực tế.
Tier 2 — Nội dung tối thiểu	Có problem/opportunity statement, tác động hiện tại, desired outcome, stakeholder, in-scope, out-of-scope, assumption, constraint và câu hỏi cần xác minh.	Chỉ ghi giải pháp mong muốn, chẳng hạn “cần màn hình mới”, mà không xác định vấn đề và kết quả nghiệp vụ.
Tier 3 — Bằng chứng và truy vết	Mỗi nhận định trọng yếu nêu loại nguồn, ngày ghi nhận, người/cơ quan cung cấp và ID truy vết; nhận định chưa xác minh mang nhãn `Verification required` hoặc `Project assumption`.	Không thể phân biệt fact, assumption và nội dung cần xác minh; ID không đối chiếu được registry.
Tier 4 — Khả năng chuyển giao	Có tiêu chí kết quả quan sát được, ranh giới quyết định và danh sách artifact downstream dự kiến; không diễn giải discovery như approval hoặc baseline.	Downstream team phải suy đoán mục tiêu, phạm vi hoặc chủ thể quyết định.

Cấu trúc bắt buộc của bản hoàn thành

Phần	Nội dung phải ghi nhận	Quy tắc chất lượng
Business context	Đơn vị, quy trình cấp cao, thời điểm phát sinh và mục tiêu kinh doanh liên quan.	Không mô tả chi tiết workflow hoặc cơ chế hệ thống.
Problem or opportunity	Hiện trạng, ai bị ảnh hưởng, hậu quả và bằng chứng quan sát được.	Phân biệt symptom với nguyên nhân; nguyên nhân chưa xác minh phải ghi là giả thuyết.
Desired outcome	Kết quả nghiệp vụ đo được hoặc quan sát được, mốc đánh giá và owner đánh giá.	Không dùng solution làm outcome.
Scope boundary	In-scope, out-of-scope, constraint và dependency đã biết.	Không mở rộng sang cấu hình, giao diện hoặc tích hợp chưa được elicitation.
Stakeholder and decision rights	Vai trò, lợi ích, thông tin cần cung cấp và quyền quyết định dự kiến.	Vai trò cung cấp thông tin không tự động là approver.
Evidence register	ID nguồn, loại nguồn, ngày, tóm tắt fact, trạng thái xác minh.	Không dùng trích dẫn được gán cho cá nhân khi không có bản ghi nguồn.
Open questions	Câu hỏi đơn nghĩa, owner trả lời, artifact cần cập nhật và nhãn trạng thái.	Không dùng câu hỏi chung chung như “cần làm rõ thêm”.

Phạm vi completed example Nova Foods

Completed example của TMPL-DISC-001 chỉ mô phỏng discovery cho chủ đề đơn bán hàng kênh phân phối nội địa của Nova Foods Trading & Manufacturing. Ví dụ ghi nhận tín hiệu rằng nhân viên tổng hợp trạng thái đơn hàng từ nhiều bảng dữ liệu tổng hợp, làm chậm việc trả lời đại lý về tình trạng đơn. Desired outcome mô phỏng là: Business Owner có thể đối chiếu một danh sách trạng thái đơn theo ngày làm việc để đánh giá liệu thời gian tổng hợp thông tin có giảm hay không. Ví dụ không xác nhận nguyên nhân hệ thống, không yêu cầu màn hình, không định nghĩa field dữ liệu, không tạo SLA, không tạo business rule và không xác nhận thay đổi ERP.

Traceability ID	Loại liên kết	Giá trị tại `v0.9.0`	Trạng thái nhất quán
`TMPL-DISC-001`	Template registry ID	Entry template discovery hiện hành	`Verification required` — cần đối chiếu `/01-curriculum/TRACEABILITY_ID_REGISTRY.md` trước khi sử dụng như ID đã đăng ký.
`CH-08`	Learning-use relationship	`Practice` — dự kiến dùng để thực hành business analysis discovery.	`Verification required` — cần đối chiếu `/01-curriculum/CHAPTER_MANIFEST.md`; không suy diễn chapter đã hoàn chỉnh hoặc approved.
`REQ-FUNC-SALES-012`	Downstream reference boundary	Có thể chỉ được tạo tham chiếu sau khi discovery được chuyển thành requirement qua artifact chuyên biệt.	`Verification required` — sự xuất hiện của ID không xác nhận requirement Nova Foods đã được phê duyệt.

Quy tắc chặn chất lượng: QG-DISC-001 trả về STOP — REWORK REQUIRED nếu artifact chứa solution giả định như business need, thiếu nguồn cho tác động trọng yếu, dùng dữ liệu không phải dữ liệu tổng hợp, hoặc trình bày IN_REVIEW như baseline, approval hay quyết định triển khai.

Template phân tích quy trình và lập bản đồ workflow

Phân tích quy trình trả lời từ nguyên lý đầu tiên: ai thực hiện hoạt động nào, theo thứ tự nào, dùng đầu vào nào, tạo kết quả nào, và xử lý ngoại lệ nào. Workflow map chỉ mô hình hóa luồng thực hiện đã được mô tả; không tự tạo business rule, requirement, thiết kế API, mô hình dữ liệu hay quyết định vận hành. Khi cần ký pháp BPMN, chỉ sơ đồ tuân theo BPMN 2.0.2 mới được gọi là BPMN.

Trường quản trị	Giá trị
Status / Version / ngày	`IN_REVIEW` / `v0.9.0` / `2026-08-07`
Locale / múi giờ / tiền tệ	`vi-VN` / `Asia/Ho_Chi_Minh` / `VND`
Bối cảnh ví dụ	Nova Foods Trading & Manufacturing; mô phỏng giáo dục; chỉ dữ liệu tổng hợp
Phân loại nguồn ký pháp	Nguồn chính thức: OMG, BPMN 2.0.2 — https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/
Ranh giới nguồn	BPMN là nguồn chuẩn cho ký pháp BPMN; không suy diễn quy định pháp lý, chính sách Nova Foods thực tế hoặc approval từ sơ đồ.

Tier nghĩa vụ	Cách áp dụng cho mọi template bên dưới
Tier 1 — Bắt buộc	Phải hoàn thành trước quality gate: ID, phạm vi, owner, trigger, điểm kết thúc, bước, vai trò, ngoại lệ, artifact liên kết và nguồn bằng chứng.
Tier 2 — Có điều kiện	Phải hoàn thành khi có liên quan: gateway quyết định, timer, handoff liên phòng ban, hệ thống tham gia, kiểm soát lô/hạn dùng hoặc dữ liệu cá nhân. Nội dung chưa xác minh giữ nhãn `Verification required` hoặc `Project assumption`.
Tier 3 — Khuyến nghị	Nên ghi cycle time quan sát được, pain point, volume giả lập, rủi ro và cơ hội cải tiến để hỗ trợ ưu tiên hóa.
Tier 4 — Cấm	Không được gọi sơ đồ là BPMN nếu dùng ký pháp khác; không đưa giả định thành fact; không ghi approval ngầm định; không biến workflow thành hướng dẫn production.

Template ID và tệp được kiểm soát	Mục đích; dùng khi / không dùng khi	Owner; consumers	Upstream → downstream	Nghĩa vụ bốn tier	Phạm vi completed example Nova Foods	Traceability IDs	Quality gate
`TMPL-PROC-001` `/templates/TMPL-PROC-001-process-analysis.md`	Ghi nhận quy trình hiện tại hoặc quy trình mục tiêu theo bước, vai trò, trigger, output, điểm đau và ngoại lệ. Dùng khi cần hiểu biên nghiệp vụ trước khi đặc tả thay đổi. Không dùng thay cho business rule register, data dictionary, API contract hoặc test case.	Owner: IT Business Analyst. Consumers: Business Owner, Process Owner, Solution Architect, QA Reviewer, UX Designer.	Upstream: discovery notes, stakeholder map, scope statement, evidence log. Downstream: workflow map, requirement specification, rule register, backlog, test basis.	T1: process ID, tên, as-is/to-be, trigger, end state, role, step, input/output, evidence source. T2: exception, handoff, control point, system touchpoint. T3: pain point và chỉ số quan sát. T4: không suy đoán thời lượng hay quyền quyết định.	`PROC-SALES-001`: mô phỏng luồng “tiếp nhận đơn bán hàng đại lý” từ nhận yêu cầu mua đến chuyển đơn hợp lệ sang chuẩn bị xuất kho; bao gồm ngoại lệ thiếu tồn kho ở mức mô tả quy trình, không khẳng định chính sách phân bổ thực tế.	Process: `PROC-SALES-001`. Workflow dự kiến: `WF-SALES-001`. Requirement liên kết theo mẫu `REQ-FUNC-SALES-NNN` khi được tạo ở artifact phù hợp.	GO khi mọi bước có một role chịu trách nhiệm, trigger và end state không mơ hồ, mỗi ngoại lệ có điểm quay lại hoặc điểm dừng, và evidence/source classification được ghi. STOP khi lẫn as-is với to-be, thiếu owner bước, hoặc có quy tắc chưa xác minh nhưng được viết như sự thật.
`TMPL-WF-001` `/templates/TMPL-WF-001-workflow-map-bpmn.md`	Chuyển quy trình đã phân tích thành workflow trực quan để kiểm tra trình tự, trách nhiệm, gateway, message flow và ngoại lệ. Dùng khi nhiều vai trò hoặc hệ thống có handoff cần được nhìn thấy trên cùng một mô hình. Không dùng cho sơ đồ kiến trúc, sequence diagram API hoặc wireframe UX.	Owner: IT Business Analyst; BPMN notation review: Solution Architect hoặc BA có năng lực BPMN. Consumers: Process Owner, Developers, QA Reviewer, Operations Representative.	Upstream: `TMPL-PROC-001`, process evidence, scope boundary. Downstream: requirement specification, acceptance criteria, test scenarios, training/process communication material.	T1: workflow ID, mục tiêu, pool/lane, start event, end event, activity, sequence flow và legend. T2: exclusive/parallel gateway, message flow, boundary event, system lane khi thực sự xuất hiện. T3: chú thích pain point và giả định được gắn ID. T4: không dùng activity diagram rồi gắn nhãn BPMN; không thể hiện legal/compliance control như đã xác nhận nếu chưa có bằng chứng.	`WF-SALES-001`: BPMN 2.0.2 mô phỏng các lane `Sales Admin`, `ERP`, `Warehouse`; start event là đơn đại lý được ghi nhận, gateway kiểm tra khả năng đáp ứng, end event là đơn được chuyển xử lý hoặc được trả về để làm rõ. Giá trị tiền và tên đối tác, nếu cần minh họa, là dữ liệu tổng hợp VND.	Workflow: `WF-SALES-001`. Liên kết ngược: `PROC-SALES-001`. Gateway: `GW-SALES-001`. Exception: `EXC-SALES-001`.	GO khi mỗi flow có hướng đi rõ, gateway có câu hỏi quyết định và nhánh ra có điều kiện phân biệt, lane phản ánh trách nhiệm thay vì tên cá nhân, và sơ đồ khớp process analysis. STOP khi có dead-end không chủ ý, activity không có owner, gateway không có điều kiện, hoặc ký pháp được gọi BPMN nhưng không kiểm tra theo OMG BPMN 2.0.2.

Quy tắc liên kết tối thiểu: một PROC-{DOMAIN}-{NNN} có thể liên kết nhiều WF-{DOMAIN}-{NNN}, nhưng mỗi workflow phải tham chiếu đúng một quy trình cha. Mọi chênh lệch giữa narrative trong TMPL-PROC-001 và sơ đồ trong TMPL-WF-001 phải được ghi thành issue truy vết; không được âm thầm sửa một phía để tạo cảm giác nhất quán.

Templates thu thập và đặc tả yêu cầu

Hai template dưới đây tách riêng bằng chứng elicitation khỏi requirement có thể kiểm tra. Việc tách này ngăn BA biến một ghi chú trao đổi thành cam kết triển khai: phát biểu nguồn được ghi nhận, phân loại và truy vết trước; requirement chỉ được đặc tả khi phạm vi, hành vi, ngoại lệ và tiêu chí chấp nhận đã đủ rõ. Mọi ví dụ Nova Foods Trading & Manufacturing là mô phỏng giáo dục với dữ liệu tổng hợp, trạng thái quản trị IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

TMPL ID	Tệp được kiểm soát	Template	Mục đích
`TMPL-REQ-001`	`/02-templates/requirements/TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md`	Requirement Elicitation Log	Ghi nhận có cấu trúc nhu cầu, câu hỏi, phát hiện, giả định, xung đột và quyết định cần làm rõ từ hoạt động discovery.
`TMPL-REQ-002`	`/02-templates/requirements/TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md`	Requirement Specification	Đặc tả một requirement nguyên tử để business, delivery và QA cùng hiểu hành vi mong đợi và bằng chứng kiểm tra.

Trường quản trị	`TMPL-REQ-001` — Requirement Elicitation Log	`TMPL-REQ-002` — Requirement Specification
Khi sử dụng	Khi phỏng vấn, workshop, quan sát, phân tích tài liệu hoặc rà soát phản hồi tạo ra thông tin cần xác minh.	Khi một nhu cầu đủ rõ để được chuyển thành requirement có ID, phạm vi và acceptance criteria.
Không sử dụng	Không dùng làm biên bản phê duyệt, backlog đã cam kết, business rule chính thức, sơ đồ quy trình hoặc test case.	Không dùng để ghi nguyên văn toàn bộ cuộc họp, thay thế business rule, thiết kế API, mô hình dữ liệu, thiết kế UX hoặc xác nhận pháp lý.
Owner soạn và duy trì	IT Business Analyst.	IT Business Analyst; Technical Owner và Business Owner là reviewer theo phạm vi.
Consumers	Business Owner, Subject Matter Expert, Product Owner, BA, QA Reviewer.	Product Owner, Business Owner, Solution/Technical Owner, UX Owner, QA Reviewer, Delivery Team.
Upstream artifacts	Problem statement, stakeholder register, discovery notes, mục tiêu Nova Foods và evidence được phân loại nguồn.	Các mục đủ điều kiện trong `TMPL-REQ-001`, scope đã xác định và dependency đã ghi nhận.
Downstream artifacts	Requirement specification, decision log, open-issue register, risk/assumption record.	Acceptance criteria, traceability matrix, test basis, backlog item và các đặc tả chuyên biệt khi có nhu cầu.
Traceability IDs bắt buộc	`ELIC-{DOMAIN}-{NNN}`, `QST-{DOMAIN}-{NNN}`, `ASM-{DOMAIN}-{NNN}`, `ISS-{DOMAIN}-{NNN}`; liên kết requirement dự kiến bằng `REQ-{TYPE}-{DOMAIN}-{NNN}` khi đã tạo.	`REQ-{TYPE}-{DOMAIN}-{NNN}`; liên kết `ELIC-`, `ASM-`, `ISS-*`, `AC-{DOMAIN}-{NNN}` và test case dự kiến `TC-{DOMAIN}-{NNN}`.
Nova Foods completed-example scope	Nhật ký cho nhu cầu kiểm soát nhập đơn bán hàng: đại lý, đơn hàng, sản phẩm, số lượng đặt và trạng thái xử lý; không mô phỏng thuế, hạch toán hay nghĩa vụ pháp lý.	Một requirement minh họa `REQ-FUNC-SALES-012` về kiểm tra trường bắt buộc trước khi tạo đơn bán hàng mô phỏng; không xác nhận cấu hình ERP production.
Quality gate	Mỗi dòng có nguồn, ngày ghi nhận theo `Asia/Ho_Chi_Minh`, mức tin cậy, trạng thái xử lý và câu hỏi hoặc hành động kế tiếp.	Requirement nguyên tử, nhất quán, khả thi để kiểm tra, có acceptance criteria quan sát được và không mang ngôn ngữ approval.

Cấu trúc bắt buộc của `TMPL-REQ-001_REQUIREMENT_ELICITATION_LOG.md`

Trường	Quy tắc điền
Elicitation ID	Dùng duy nhất dạng `ELIC-{DOMAIN}-{NNN}`, ví dụ `ELIC-SALES-001`; không tái sử dụng ID khi nội dung thay đổi.
Nguồn và phân loại nguồn	Nêu artifact, workshop hoặc quan sát mô phỏng; phân loại là `Primary source`, `Secondary source`, `Project assumption` hoặc `Verification required`. Không gán phát biểu cho người không có bản ghi nguồn.
Phát hiện hoặc nhu cầu được nêu	Viết theo ngôn ngữ nguồn, phân biệt rõ fact, mong muốn và giả định.
Diễn giải BA	Chuẩn hóa thuật ngữ, chỉ ra điểm mơ hồ và không tự suy diễn hành vi hệ thống.
Câu hỏi làm rõ	Gán `QST-*`, nêu người cần trả lời và điều kiện đóng câu hỏi.
Xung đột hoặc ngoại lệ	Ghi `ISS-*` nếu hai nguồn mâu thuẫn hoặc chưa xác định chủ sở hữu quyết định.
Quyết định chuyển đặc tả	Chỉ dùng `Ready for specification` khi có nguồn, phạm vi và hành vi mong đợi đủ để soạn requirement; không đồng nghĩa approval.

Cấu trúc bắt buộc của `TMPL-REQ-002_REQUIREMENT_SPECIFICATION.md`

Trường	Quy tắc điền và ví dụ mô phỏng
Requirement ID và loại	`REQ-FUNC-SALES-012`; loại `Functional`. Không dùng một ID cho nhiều hành vi độc lập.
Tên requirement	“Kiểm tra dữ liệu bắt buộc khi tạo đơn bán hàng”. Tên nêu năng lực, không nêu giải pháp giao diện.
Statement	“Hệ thống phải chặn việc tạo đơn bán hàng khi thiếu mã đại lý, ngày đơn hàng hoặc ít nhất một dòng sản phẩm.”
Business rationale	Giảm đơn không đủ dữ liệu để tiếp tục xử lý bán hàng mô phỏng. Đây là mục tiêu học tập, không là chỉ tiêu vận hành đã được phê duyệt.
In scope / Out of scope	Trong phạm vi: kiểm tra trước thao tác tạo đơn. Ngoài phạm vi: giá bán, thuế, hạch toán, phê duyệt tín dụng và đồng bộ hệ thống khác.
Preconditions và trigger	Người dùng đã mở chức năng tạo đơn; trigger là thao tác chọn “Tạo đơn”.
Main outcome	Hệ thống tạo đơn khi tất cả trường bắt buộc hợp lệ theo requirement này.
Exception outcome	Hệ thống không tạo đơn và chỉ rõ trường còn thiếu; không suy diễn thông báo lỗi cụ thể nếu UX chưa được đặc tả.
Acceptance criteria	`AC-SALES-012-01`: thiếu mã đại lý thì không tạo đơn. `AC-SALES-012-02`: không có dòng sản phẩm thì không tạo đơn. `AC-SALES-012-03`: đủ ba điều kiện thì hệ thống cho phép tạo đơn.
Nguồn và liên kết	Liên kết `ELIC-SALES-001`; mọi `ASM-` hoặc `ISS-` chưa đóng phải hiển thị trong requirement.
Priority và rationale	Ghi giá trị ưu tiên cùng lý do nghiệp vụ; ưu tiên là đề xuất `IN_REVIEW`, không phải cam kết delivery.
Four-tier obligations	Áp dụng ma trận bên dưới cho từng trường và acceptance criterion.

Tier	Nghĩa vụ	Cách thể hiện trong requirement	Điều cấm
Tier 1 — Mandatory	Điều kiện tối thiểu để requirement có thể review và kiểm tra.	ID, statement, phạm vi, nguồn, owner, acceptance criteria, trạng thái và traceability hoàn chỉnh.	Không để requirement không có nguồn hoặc không có kết quả quan sát được.
Tier 2 — Conditional	Bắt buộc khi điều kiện đã xuất hiện.	Ghi exception, dependency, role, dữ liệu đầu vào hoặc giả định khi requirement có các yếu tố đó.	Không tạo trường giả định rằng điều kiện luôn đúng.
Tier 3 — Verification required	Nội dung cần xác minh bởi vai trò có thẩm quyền trước khi được dùng làm ràng buộc.	Đánh dấu rõ vấn đề, nguồn cần kiểm tra, owner xác minh và tác động nếu chưa xác minh.	Không chuyển nội dung chưa xác minh thành fact, rule hoặc compliance requirement.
Tier 4 — Project assumption	Giả định tạm để tiếp tục phân tích mô phỏng.	Ghi `ASM-*`, lý do, phạm vi tác động, ngày ghi nhận và điều kiện thay thế hoặc hủy giả định.	Không trình bày assumption như quyết định, approval hoặc hành vi production.

Quality gate chung: BA chỉ chuyển template sang review khi mọi ID hợp lệ, không có requirement gộp nhiều hành vi, mỗi acceptance criterion có thể quan sát bằng kiểm thử, nguồn được phân loại, và mọi mục Verification required hoặc Project assumption còn mở được liên kết tới ISS-* hoặc ASM-*. Nếu thiếu một điều kiện, trạng thái phải giữ IN_REVIEW; không được suy diễn approval, baseline hay sẵn sàng triển khai.

Business Rules Capture and Rule Governance Templates

Business rule là mệnh đề xác định, có thể kiểm tra về chính sách, giới hạn, cách tính, điều kiện quyết định hoặc ngoại lệ mà Nova Foods cần áp dụng trong kịch bản mô phỏng. Rule không thay thế requirement: requirement mô tả năng lực hệ thống cần cung cấp, còn rule xác định logic hoặc ràng buộc mà năng lực đó phải tuân thủ. Mọi nội dung về an toàn thực phẩm, truy xuất nguồn gốc, kế toán, hóa đơn, thuế hoặc dữ liệu cá nhân chỉ là Project assumption hoặc Verification required cho đến khi được vai trò có thẩm quyền xác minh theo nguồn chính thức.

TMPL ID và tệp được kiểm soát	Mục đích; dùng khi / không dùng khi	Owner; consumers	Upstream → downstream	Bốn tầng nghĩa vụ	Phạm vi completed example Nova Foods	Traceability IDs	Quality gate
`TMPL-RULE-001` — `/01-curriculum/templates/TMPL-RULE-001-business-rule-catalog.md`	Ghi nhận mỗi business rule như một đơn vị độc lập, có điều kiện áp dụng, kết quả, ngoại lệ, owner và trạng thái xác minh. Dùng khi một quyết định nghiệp vụ có thể ảnh hưởng nhiều requirement, màn hình, API hoặc test case. Không dùng khi nội dung chỉ là mô tả bước quy trình, tiêu chí thiết kế giao diện hoặc cấu hình kỹ thuật không có ý nghĩa nghiệp vụ độc lập.	Owner: Senior BA. Consumers: Business Owner, Domain Owner, Solution Architect, QA Reviewer, Developer, UAT Lead.	`BRD-`, `PROC-`, discovery note, glossary → `REQ-`, `AC-`, `TC-*`, API mapping, data definition, change request.	T1 Định danh: ID, tên, domain, version/status. T2 Logic: trigger, điều kiện, hành động/kết quả, ngoại lệ, ví dụ biên. T3 Governance: Business Owner, nguồn, phân loại `Project assumption` hoặc `Verification required`, ngày review. T4 Evidence: liên kết requirement, acceptance criterion và test evidence dự kiến.	Catalog hoàn chỉnh cho quy tắc phân bổ hàng tồn kho theo hạn dùng trong luồng bán hàng mô phỏng; dữ liệu lô, ngày hết hạn và số lượng đều tổng hợp.	`BR-INV-001`; `PROC-SALES-003`; `REQ-FUNC-SALES-012`; `AC-SALES-012-01`; `TC-SALES-012-01`.	Không có rule trùng ID; một rule chỉ có một phát biểu chuẩn; điều kiện và kết quả kiểm thử được; owner nghiệp vụ được chỉ định nhưng chưa được diễn giải là approval; mọi nghĩa vụ pháp lý còn nhãn xác minh phù hợp.
`TMPL-RULE-002` — `/01-curriculum/templates/TMPL-RULE-002-decision-table.md`	Chuyển tổ hợp điều kiện thành các cột quyết định nhằm phát hiện trường hợp thiếu, chồng lấn hoặc mâu thuẫn. Dùng khi kết quả phụ thuộc từ hai điều kiện nhị phân trở lên, như trạng thái lô và lượng tồn khả dụng. Không dùng khi chỉ có một điều kiện đơn giản; khi đó ghi trực tiếp trong `TMPL-RULE-001`.	Owner: Senior BA. Consumers: Domain Owner, QA Reviewer, Developer, UAT Lead.	`BR-`, `DATA-`, process exception → acceptance criteria, test design, implementation rule mapping.	T1 Định danh: Decision table ID và rule cha. T2 Logic: điều kiện, giá trị hợp lệ, hành động, thứ tự ưu tiên. T3 Governance: owner quyết định, giả định, conflict record. T4 Evidence: mỗi cột quyết định nối tối thiểu một test case.	Bảng quyết định cho phép hoặc chặn phân bổ lô hàng: lô còn hạn, lô bị khóa chất lượng, tồn khả dụng và yêu cầu số lượng. Việc “bị khóa chất lượng” là trạng thái mô phỏng, không suy ra quy định an toàn thực phẩm thực tế.	`DT-INV-001`; `BR-INV-001`; `DATA-LOT-004`; `AC-SALES-012-01`; `TC-SALES-012-01` đến `TC-SALES-012-04`.	Mọi tổ hợp điều kiện trong phạm vi đã khai báo có kết quả; không có hai cột cùng điều kiện nhưng khác hành động; trường hợp ngoài phạm vi được ghi rõ là exception hoặc rule mới, không bị suy đoán.
`TMPL-RULE-003` — `/01-curriculum/templates/TMPL-RULE-003-rule-governance-register.md`	Quản lý vòng đời rule, quan hệ thay thế, xung đột, tác động thay đổi và quyết định cần xác minh. Dùng khi rule mới, sửa, ngừng dùng hoặc mâu thuẫn với rule khác. Không dùng khi thay đổi chỉ sửa lỗi chính tả không đổi nghĩa logic; thay đổi đó ghi trong lịch sử phiên bản của artifact.	Owner: Senior BA. Consumers: Business Owner, Domain Owner, Legal/Compliance Owner khi phạm vi thuộc thẩm quyền, QA Reviewer, Release Manager.	`BR-`, issue log, feedback discovery → `CR-{DOMAIN}-{NNN}`, impact assessment, updated `REQ-`, `AC-`, `TC-`.	T1 Định danh: governance record, rule bị tác động, loại thay đổi. T2 Logic: so sánh trước/sau, effective-condition dự kiến, rule thay thế. T3 Governance: decision owner, source classification, trạng thái review, escalation route. T4 Evidence: liên kết impact assessment và retest scope.	Register cho thay đổi giả định từ “ưu tiên lô gần hết hạn” sang “chặn lô đã hết hạn”; không ghi nhận hiệu lực production, approval hay nghĩa vụ pháp lý.	`RG-INV-001`; `BR-INV-001`; `CR-INV-001`; `REQ-FUNC-SALES-012`; `TC-SALES-012-01`.	Mọi thay đổi logic có `CR-*` và phân tích tác động; rule bị thay thế vẫn giữ ID và trạng thái lịch sử; không đóng record là approved hoặc implemented khi artifact hiện hành là `IN_REVIEW`.

Cấu trúc bắt buộc của một record BR-*:

Trường	Quy tắc điền
Rule statement	Viết theo dạng “Nếu `<điều kiện>`, hệ thống hoặc người dùng phải `<kết quả>`”; không gộp nhiều quy tắc độc lập trong một câu.
Classification	Chọn một: policy, constraint, calculation, derivation, authorization, validation hoặc exception.
Source classification	Chọn `Business decision`, `Project assumption`, `Verification required` hoặc `Official source pending authorized interpretation`. Không gán nhãn “legal requirement” nếu chưa có xác minh phù hợp.
Ví dụ Nova Foods	`BR-INV-001`: “Nếu lô hàng có `ExpiryDate` trước ngày phân bổ, hệ thống chặn lô đó khỏi danh sách phân bổ.” Đây là quy tắc mô phỏng giáo dục; không xác nhận chính sách vận hành hoặc nghĩa vụ pháp lý của Nova Foods.
Testability	Nêu dữ liệu đầu vào, kết quả mong đợi, ngoại lệ và ID test dự kiến; không dùng các từ mơ hồ như “phù hợp”, “nhanh” hoặc “hợp lý” làm kết quả.

Nguồn phương pháp được phép tham chiếu cho thuật ngữ BA là BABOK Guide Version 3 theo ranh giới nguồn đã xác minh. Các quy tắc có ngữ cảnh truy xuất nguồn gốc hoặc an toàn thực phẩm chỉ được định tuyến tới Domain Owner và, khi được trình bày như nghĩa vụ pháp lý, tới Legal/Compliance Owner để Verification required; template không tạo diễn giải luật, cam kết tuân thủ hoặc approval.

Templates cho từ điển dữ liệu và định nghĩa mô hình dữ liệu

Phạm vi này chuẩn hóa cách BA mô tả ý nghĩa, cấu trúc, nguồn gốc, quy tắc sử dụng và quan hệ của dữ liệu trong ERP Nova Foods. Từ điển dữ liệu trả lời “mỗi trường có nghĩa gì và được kiểm soát ra sao”; mô hình dữ liệu trả lời “các thực thể liên hệ với nhau thế nào”. Hai artifact bổ trợ nhưng không thay thế nhau. Mọi ví dụ Nova Foods dưới đây là dữ liệu tổng hợp phục vụ đào tạo, không phải cấu hình production, hồ sơ khách hàng thật hoặc quyết định pháp lý.

Template ID	Tên template và filename được kiểm soát	Mục đích	Khi sử dụng	Khi không sử dụng	Owner	Consumers	Upstream artifacts	Downstream artifacts
`TMPL-DATA-001`	Data Dictionary Template — `/templates/TMPL-DATA-001-data-dictionary.md`	Định nghĩa nhất quán từng business term, entity, attribute, kiểu dữ liệu, đơn vị, miền giá trị, bắt buộc/tùy chọn, nguồn hệ thống và phân loại dữ liệu.	Khi discovery hoặc specification đã xác định dữ liệu cần thu thập, trao đổi, lưu trữ, tra cứu hoặc dùng trong báo cáo; trước khi chốt field-level requirement hoặc mapping.	Không dùng để thay thế process map, API contract, giao diện, database DDL hoặc quyết định pháp lý; không ghi “bắt buộc theo luật” nếu chưa có nguồn pháp lý hiện hành và Legal Owner xác minh.	BA phụ trách domain dữ liệu; Data Owner xác nhận ý nghĩa nghiệp vụ.	Product Owner, Solution Architect, Developer, QA, Data/Reporting Analyst, Security/Privacy Reviewer.	`TMPL-BIZ-001` business need; `TMPL-PROC-001` process model; requirement và rule có traceability; glossary Nova Foods.	`TMPL-DATA-002` data model; requirement chi tiết; API mapping; test basis; báo cáo và hướng dẫn migration.
`TMPL-DATA-002`	Conceptual and Logical Data Model Template — `/templates/TMPL-DATA-002-data-model.md`	Mô tả entity, relationship, cardinality, identifier, ownership và boundary dữ liệu ở mức conceptual/logical; làm rõ cấu trúc cần có trước khi thiết kế vật lý.	Khi có nhiều quy trình hoặc module cùng dùng một entity, khi cần phát hiện trùng lặp/thiếu dữ liệu, hoặc khi relationship ảnh hưởng đến requirement và traceability.	Không dùng để tuyên bố schema database, index, partition, technology hoặc physical performance đã được quyết định; không gọi sơ đồ PlantUML activity là BPMN. Khi dùng UML, phải ghi rõ notation và mức mô hình.	BA phối hợp Solution/Data Architect; Data Owner chịu trách nhiệm xác nhận semantics nghiệp vụ trong phạm vi được giao.	Solution Architect, Developer, Integration Analyst, QA, Reporting Analyst, Security/Privacy Reviewer.	`TMPL-DATA-001`; process/workflow artifacts; requirement; business rules; danh mục module ERP.	Logical field mapping, API/interface specification, migration mapping, test data design, NFR liên quan dữ liệu và traceability matrix.

Cấu trúc bắt buộc của `TMPL-DATA-001`

Mỗi dòng dữ liệu phải có đầy đủ các cột sau; không được dùng giá trị mơ hồ như “phù hợp”, “tùy hệ thống” hoặc “sẽ bổ sung”.

Trường	Quy tắc ghi nhận	Ví dụ Nova Foods tổng hợp
Data ID	ID ổn định, không tái sử dụng cho khái niệm khác	`DATA-ITEM-001`
Business term	Tên nghiệp vụ duy nhất, dùng thống nhất trong corpus	`Mã lô sản xuất`
Entity/attribute	Phân biệt entity với attribute	Entity `ProductionBatch`; attribute `batch_code`
Definition	Định nghĩa quan sát được, nêu rõ đối tượng và ranh giới	Mã nhận diện một lô sản xuất trong phạm vi mô phỏng Nova Foods
Data type/format	Nêu kiểu và format; không suy ra kiểu vật lý nếu chưa có quyết định kỹ thuật	`string`, tối đa 30 ký tự, chữ hoa và số theo giả định dự án
Requiredness	Chỉ ghi `Required`, `Optional`, hoặc `Conditional` kèm điều kiện	`Required` khi tạo `ProductionBatch`
Domain/value set	Liệt kê giá trị hoặc tham chiếu rule; không tự tạo mã pháp lý	`BATCH-YYYYMMDD-###` — `Project assumption`
Unit/currency	Bắt buộc với số đo và tiền tệ	Giá trị tiền dùng `VND`; khối lượng dùng `kg` nếu quy trình yêu cầu
Source/system of record	Chỉ rõ nơi phát sinh hoặc nơi được kiểm soát	`ERP Manufacturing` — phạm vi mô phỏng
Sensitivity/classification	Gắn nhãn dữ liệu cá nhân, tài chính, vận hành hoặc tổng hợp khi có căn cứ	`Operational synthetic data`
Quality rule	Nêu uniqueness, completeness, validity, consistency hoặc timeliness có thể kiểm tra	`batch_code` không trùng trong cùng phạm vi nhà máy
Traceability	Liên kết tới requirement/rule/process bằng ID đã tồn tại	`REQ-DATA-BATCH-001`; `BR-BATCH-001`; `PROC-MFG-001`
Verification/source note	Phân biệt nguồn chuẩn, giả định và nội dung cần xác minh	`Project assumption`; pháp lý liên quan: `Verification required`

Cấu trúc bắt buộc của `TMPL-DATA-002`

Mỗi mô hình phải ghi Model ID, phạm vi module/quy trình, mức mô hình (Conceptual hoặc Logical), entity, identifier, relationship, cardinality, optionality, ownership, source traceability và các giả định. Ví dụ tối thiểu trong corpus gồm Product, ProductionBatch, Warehouse, InventoryLot, SalesOrder và Customer; việc đưa entity vào ví dụ không xác nhận rằng Nova Foods thực tế sử dụng đúng cấu trúc này.

Relationship	Cardinality cần biểu diễn	Ý nghĩa kiểm tra
`Product` — `ProductionBatch`	Một `Product` có thể có nhiều `ProductionBatch`; mỗi batch gắn với một `Product` trong phạm vi mô phỏng	Phát hiện batch không có sản phẩm hoặc sản phẩm bị tạo trùng
`ProductionBatch` — `InventoryLot`	Một batch có thể sinh một hoặc nhiều lot tồn kho theo quy trình được mô phỏng	Phân biệt nguồn gốc sản xuất với đơn vị tồn kho
`Warehouse` — `InventoryLot`	Một warehouse chứa nhiều lot; mỗi lot phải có phạm vi lưu kho xác định	Làm cơ sở kiểm tra tồn kho và truy xuất
`SalesOrder` — `Product`	Một đơn hàng có một hoặc nhiều dòng hàng; mỗi dòng tham chiếu một product	Không gộp order header với order line thành một entity không kiểm soát

Four-tier obligations và quality gate

Tầng nghĩa vụ	Nghĩa vụ khi hoàn thành template
Tier 1 — nền tảng	Dùng đúng thuật ngữ, ID, filename, locale `vi-VN`, bối cảnh Việt Nam và dữ liệu tổng hợp; mọi field có định nghĩa, kiểu, nguồn và phạm vi rõ ràng.
Tier 2 — năng lực BA	Chứng minh mỗi field/entity phục vụ một process, requirement hoặc business rule; chỉ ra ambiguity, duplicate, missing owner và relationship chưa đủ bằng chứng.
Tier 3 — governance	Gắn traceability tới `REQ-`, `BR-`, `PROC-*`; phân loại nguồn thành `Verified primary source`, `Project assumption` hoặc `Verification required`; nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân và an toàn thực phẩm không được tự diễn giải.
Tier 4 — AI-assisted control	AI chỉ được đề xuất definition, candidate relationship hoặc anomaly; BA phải kiểm tra nguồn, tính nhất quán, dữ liệu tổng hợp và phạm vi thẩm quyền. Không coi output AI là approval, baseline hoặc xác nhận người dùng.

Quality gate: PASS chỉ khi không còn entity/attribute không có owner, definition, type, source, quality rule hoặc traceability; cardinality và optionality không mâu thuẫn với process; mọi giả định được gắn nhãn; tên trường không trùng nghĩa; ví dụ không chứa dữ liệu thật; và reviewer có thể lần từ Process/Requirement/Rule → Data Dictionary → Data Model → downstream artifact. Nếu thiếu một điều kiện, trạng thái là STOP — DATA MODEL REWORK REQUIRED, không tự lấp khoảng trống bằng dữ liệu hoặc quy tắc mới.

API Specification và Integration Mapping Templates

Hai template dưới đây là nguồn mô tả có kiểm soát cho giao diện HTTP và ánh xạ trao đổi giữa Nova Foods ERP với hệ thống ngoài. Chúng dùng dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải hợp đồng tích hợp đã phê duyệt, cấu hình production, hoặc xác nhận tuân thủ pháp lý.

TMPL ID / tệp kiểm soát	Mục đích và thời điểm dùng	Không dùng khi	Owner / Consumers	Upstream → Downstream
`TMPL-API-001` `/templates/TMPL-API-001_api-specification.md`	Chuẩn hoá mô tả một HTTP API: mục tiêu nghiệp vụ, resource, operation, request, response, schema, lỗi, xác thực, idempotency, version và ví dụ dữ liệu tổng hợp. Dùng khi một hệ thống cần công bố hoặc tiêu thụ API có ranh giới giao tiếp xác định.	Không thay thế tài liệu quyết định kiến trúc, data dictionary, business rule, runbook vận hành hoặc thỏa thuận pháp lý với đối tác. Không dùng để mô tả trao đổi tệp batch thuần túy.	Owner: IT Business Analyst phối hợp Solution Architect và API Owner. Consumers: Developer, QA, Integration Engineer, Security Reviewer, Product Owner.	`REQ-`, `BR-`, `DD-*`, process scenario, quyết định kiến trúc đã ghi nhận → OpenAPI contract, integration mapping, test basis, API test case, release checklist.
`TMPL-INT-001` `/templates/TMPL-INT-001_integration-mapping.md`	Ánh xạ end-to-end giữa nguồn và đích: trigger, direction, giao thức, trường dữ liệu, chuyển đổi, ownership, lỗi, retry, reconciliation và quan sát vận hành. Dùng cho API, event, file hoặc batch có ít nhất hai system boundary.	Không thay thế OpenAPI contract chi tiết cho HTTP endpoint; không dùng làm bảng mapping nội bộ một module ERP không qua system boundary.	Owner: IT Business Analyst phối hợp Integration Lead. Consumers: API Owner, Developer, QA, Operations, Data Steward, Business Owner.	`TMPL-API-001`, `DD-`, `BR-`, process flow, interface inventory → build mapping, test scenario, monitoring specification, reconciliation procedure, release evidence.

Template Bốn tầng nghĩa vụ phải hoàn thành

TMPL-API-001 Tier 1 — Nhận diện: ghi API-*, owner, provider, consumer, môi trường, version contract và trạng thái. Tier 2 — Nghiệp vụ: liên kết mục tiêu, REQ-*, BR-*, actor, precondition, outcome và exception. Tier 3 — Kỹ thuật: mô tả method, path, parameter, header, content type, schema, status code, authentication, pagination hoặc idempotency khi áp dụng; HTTP API dùng cấu trúc tương thích OpenAPI Specification OAS 3.1.1 là nguồn chuẩn kỹ thuật. Tier 4 — Assurance: nêu acceptance criteria quan sát được, negative case, correlation ID, lỗi xử lý, giới hạn kiểm thử và trace tới test artifact.

TMPL-INT-001 Tier 1 — Nhận diện: ghi INT-*, source system, target system, interface owner, direction, trigger và lịch chạy nếu có. Tier 2 — Ngữ nghĩa nghiệp vụ: mỗi mapping phải liên kết REQ-*, BR-*, DD-*; không tự đổi nghĩa đơn vị đo, tiền tệ VND, trạng thái đơn hàng hoặc mã lô. Tier 3 — Chuyển đổi kỹ thuật: xác định source field, target field, datatype, cardinality, transformation, default, validation, error route và khóa đối soát. Tier 4 — Assurance: xác định expected result, retry boundary, duplicate handling, reconciliation evidence, alert owner và test trace.

Nova Foods completed-example scope. TMPL-API-001 hoàn chỉnh minh hoạ endpoint tổng hợp POST /sales-orders để tiếp nhận đơn bán hàng từ kênh bán hàng mô phỏng vào Nova Foods ERP; ví dụ dùng salesOrderNo SO-SYN-20260807-001, khách hàng CUS-SYN-001, tiền tệ VND và không chứa dữ liệu cá nhân thật. TMPL-INT-001 hoàn chỉnh minh hoạ INT-SALES-001: ánh xạ đơn bán hàng từ Sales Channel mô phỏng sang ERP, gồm khóa ngoài, dòng hàng, số lượng, đơn giá, trạng thái tiếp nhận và correlation ID. Quy tắc hóa đơn, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất lô chỉ được ghi là Project assumption hoặc Verification required nếu chưa được xác minh từ nguồn chính thức và owner có thẩm quyền.

Traceability ID tối thiểu	Quy tắc liên kết
`API-SALES-001`	API identifier duy nhất; liên kết tới `TMPL-API-001`, `REQ-FUNC-`, `BR-`, `DD-*` và test case dự kiến.
`INT-SALES-001`	Interface identifier duy nhất; liên kết tới `API-SALES-001` khi giao tiếp là HTTP API, cùng các mapping row `MAP-INT-SALES-001-001` trở đi.
`MAP-INT-SALES-001-001`	Một dòng mapping cho một trường hoặc cấu trúc lồng; phải chỉ rõ nguồn, đích, quy tắc chuyển đổi và xử lý lỗi.
`AC-API-SALES-001-001`	Acceptance criterion kiểm thử được; không được thay bằng nhận định chủ quan như “API hoạt động tốt”.

Quality gate chung — GATE-API-INT-001: đạt khi mỗi endpoint hoặc interface có owner, consumer, mục đích nghiệp vụ, ID duy nhất, liên kết REQ-*/BR-*/DD-*, schema hoặc mapping đầy đủ, error path, dữ liệu ví dụ tổng hợp, expected result và trace tới kiểm thử. Dừng review nếu một field không có định nghĩa dữ liệu, source và target mâu thuẫn, quy tắc chuyển đổi không có owner, hoặc nội dung pháp lý/compliance được trình bày như kết luận mà thiếu xác minh phù hợp.

Danh mục template UX và yêu cầu phi chức năng

Hai template dưới đây chuyển nhu cầu trải nghiệm và các thuộc tính chất lượng thành yêu cầu có thể kiểm tra. Chúng không thay thế thiết kế giao diện chi tiết, quyết định kiến trúc, kiểm thử, đánh giá bảo mật, tư vấn pháp lý hoặc phê duyệt triển khai. Mọi dữ liệu Nova Foods là mô phỏng giáo dục, tổng hợp, theo vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND.

TMPL ID và tệp kiểm soát	Mục đích và thời điểm dùng	Không dùng khi	Owner; consumers	Upstream → downstream	Bốn tầng nghĩa vụ	Phạm vi completed example Nova Foods	Traceability IDs bắt buộc	Quality gate
`TMPL-UX-001` — `TMPL-UX-001_UX_REQUIREMENTS_SPECIFICATION.md`	Ghi nhận người dùng, mục tiêu tác vụ, luồng màn hình, trạng thái, nội dung hiển thị, lỗi, khả năng truy cập và acceptance criteria UX. Dùng khi requirement có điểm chạm người dùng như tạo đơn bán hàng, nhận hàng kho hoặc tra cứu lô hàng.	Không dùng để thay BPMN/UML, tạo mockup là nguồn chân lý duy nhất, định nghĩa rule nghiệp vụ, hoặc thay tài liệu kiến trúc giao diện.	Owner: IT Business Analyst. Consumers: UX/UI Designer, Business Owner, Solution Architect, QA Reviewer, Developer.	Upstream: business need, stakeholder map, process flow, requirement, business rule, data definition. → Downstream: wireframe/prototype, UI backlog, acceptance criteria, test case, accessibility evidence.	T1 bắt buộc: persona/role, task, trigger, happy path, exception, dữ liệu hiển thị, acceptance criteria và liên kết requirement. T2 bắt buộc khi áp dụng: quyền truy cập, thiết bị, ngôn ngữ, định dạng `vi-VN`, trạng thái loading/lỗi/rỗng và tiêu chí WCAG 2.2 được chọn. T3 cần xác minh: yêu cầu liên quan dữ liệu cá nhân phải gắn `Verification required` và Legal/Compliance Owner phù hợp. T4 không được suy diễn: không tuyên bố compliant, approved, production-ready hoặc tự tạo business rule từ wireframe.	Hoàn chỉnh một ví dụ màn hình Tra cứu tồn kho theo lô và hạn dùng cho vai trò Nhân viên Kinh doanh: nhập mã hàng, kho và ngày dự kiến giao; hiển thị số lượng khả dụng, mã lô, hạn dùng, trạng thái không có kết quả và thông báo khi không có quyền xem kho. Không xác nhận đây là quy trình thật của Nova Foods.	`UX-REQ-SALES-001`; `REQ-FUNC-SALES-012`; `BR-INV-001`; `DATA-ITEM-LOT-001`; `DATA-ITEM-EXPIRY-DATE-001`; `AC-UX-SALES-001`; `TC-UX-SALES-001`.	Đạt khi mỗi tác vụ có actor, precondition, input, expected result, exception và ID liên kết; mọi nội dung accessibility nêu rõ success criterion WCAG 2.2 hoặc giữ nhãn `Verification required`; QA Reviewer có thể tạo test case mà không suy đoán hành vi.
`TMPL-NFR-001` — `TMPL-NFR-001_NON_FUNCTIONAL_REQUIREMENTS.md`	Đặc tả thuộc tính chất lượng đo được: hiệu năng, khả dụng, bảo mật, riêng tư, khả năng truy cập, tương thích, quan sát vận hành, sao lưu/khôi phục và khả năng mở rộng. Dùng khi solution cần ràng buộc ngoài chức năng nghiệp vụ.	Không dùng để ghi yêu cầu chức năng, dùng từ mơ hồ như “nhanh”, “an toàn”, “dễ dùng”, hoặc khẳng định tuân thủ luật/chuẩn khi chưa có xác minh có thẩm quyền.	Owner: IT Business Analyst, phối hợp Solution Architect. Consumers: Security Lead, DevOps/Operations, Developer, QA Reviewer, Legal/Compliance Owner khi có dữ liệu cá nhân.	Upstream: business objective, risk, functional requirement, data classification, integration context, UX requirement. → Downstream: architecture decision, security design, capacity plan, monitoring specification, test plan, test case, release readiness evidence.	T1 bắt buộc: thuộc tính chất lượng, phạm vi, điều kiện đo, ngưỡng, phương pháp đo, expected result, owner và requirement ID. T2 bắt buộc khi áp dụng: RTO/RPO, audit log, phân quyền, mã hóa, rate limit, accessibility hoặc availability phải chỉ rõ bối cảnh và evidence. T3 cần xác minh: nghĩa vụ pháp lý về dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất phải gắn `Verification required`; không chuyển thành yêu cầu triển khai trước xác nhận của owner có thẩm quyền. T4 không được suy diễn: OWASP ASVS, OWASP API Security Top 10 và WCAG là nguồn tham chiếu chuyên môn, không tự là luật Việt Nam hoặc approval.	Hoàn chỉnh ví dụ cho chức năng tra cứu tồn kho theo lô: trong điều kiện tải mô phỏng đã định nghĩa, 95% yêu cầu hợp lệ trả kết quả trong không quá 3 giây; lỗi hệ thống trả mã tham chiếu; truy cập dữ liệu kho được ghi nhận audit event. Ngưỡng và tải là `Project assumption` phục vụ học tập, không phải cam kết SLA Nova Foods.	`NFR-PERF-INV-001`; `NFR-SEC-INV-001`; `NFR-OBS-INV-001`; `REQ-FUNC-SALES-012`; `DATA-ENTITY-INVENTORY-LOT`; `AC-NFR-INV-001`; `TC-NFR-INV-001`; `RISK-SEC-001`.	Đạt khi mọi NFR có metric, đơn vị, population/percentile hoặc điều kiện đo, môi trường, công cụ/evidence dự kiến, chủ thể chịu trách nhiệm và tiêu chí pass/fail; không còn tính từ không đo được; các tham chiếu WCAG 2.2, OWASP hoặc nguồn pháp lý giữ đúng phân loại nguồn và ranh giới sử dụng.

Quy tắc điền tối thiểu chung: mỗi template phải ghi Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, nguồn của từng quyết định, assumption hoặc Verification required. Một UX requirement phải liên kết tối thiểu tới một functional requirement; một NFR phải liên kết tối thiểu tới một phạm vi chức năng hoặc thành phần chịu tác động. Không được coi sự tồn tại của template, quality gate đạt, hoặc completed example là approval, baseline hay xác nhận sẵn sàng production.

Chuẩn trường bắt buộc cho mọi entry template trong lifecycle analysis

Mỗi entry trong catalog template phải là một đơn vị quản trị độc lập, dùng để quyết định đúng lúc cần tạo artifact nào, ai chịu trách nhiệm soạn, ai sử dụng kết quả và bằng chứng nào cho phép chuyển sang artifact kế tiếp. Entry chỉ mô tả template và điều kiện sử dụng template; không tự tạo requirement Nova Foods đã được phê duyệt, quyết định thiết kế, nghĩa vụ pháp lý hoặc xác nhận sẵn sàng production.

Trường bắt buộc	Nội dung phải ghi	Quy tắc hoàn thành và ranh giới
`Template ID`	ID `TMPL-...` đã có trong registry được kiểm soát.	Không tự đặt lại, tái sử dụng hoặc đổi nghĩa ID. Nếu ID chưa được registry cấp, entry không được phát hành như một template được quản lý.
`Filename`	Đường dẫn và tên tệp chính xác của template.	Phải tuân thủ quy tắc đặt tên tại section 2; filename là định danh kỹ thuật, không dùng tiêu đề thay thế filename.
`Purpose`	Vấn đề BA mà template giải quyết, quyết định mà nó làm rõ, và đầu ra tối thiểu tạo ra.	Viết theo kết quả quan sát được, ví dụ “ghi nhận điều kiện chấp nhận có thể kiểm thử”, không viết “làm rõ toàn bộ hệ thống”.
`When to use`	Trigger, giai đoạn lifecycle, độ phức tạp hoặc rủi ro khiến template cần thiết.	Nêu điều kiện dương tính cụ thể: có thay đổi quy trình, có dữ liệu trao đổi liên hệ thống, có quyết định nghiệp vụ cần truy vết.
`When not to use`	Trường hợp template không phù hợp hoặc bị thay bằng artifact hẹp hơn.	Ngăn tạo tài liệu dư thừa; không dùng template đầy đủ để ghi nhận một câu hỏi đơn lẻ, một lỗi, hoặc một quyết định kỹ thuật đã thuộc artifact khác.
`Owner`	Vai trò chịu trách nhiệm duy trì tính đầy đủ, nhất quán và version của nội dung template instance.	Owner không mặc nhiên là approver, Legal Owner, Accounting Owner, Business Owner hoặc người cho phép triển khai production.
`Consumers`	Vai trò hoặc nhóm sử dụng đầu ra để quyết định, thiết kế, kiểm thử, vận hành hoặc review.	Mỗi consumer phải gắn với cách sử dụng cụ thể, không ghi chung chung “các bên liên quan”.
`Upstream artifacts`	Artifact, ID hoặc nguồn đầu vào mà tác giả phải kiểm tra trước khi điền template.	Chỉ liên kết nguồn có phân loại rõ. Nguồn pháp lý, kế toán, thuế, dữ liệu cá nhân, hóa đơn và an toàn thực phẩm chưa được xác minh phải giữ nhãn `Verification required` hoặc `Project assumption`.
`Downstream artifacts`	Artifact dự kiến nhận đầu ra của template.	Downstream phải phản ánh luồng truy vết, không được suy diễn rằng artifact downstream đã tồn tại, đã baseline hoặc được phê duyệt.
`Four-tier obligations`	Nghĩa vụ điền nội dung theo bốn tầng bên dưới.	Không gộp bốn tầng thành một đoạn mô tả; mỗi tầng phải chỉ ra bằng chứng tối thiểu.
`Nova Foods completed-example scope`	Phạm vi ví dụ đã điền dự kiến cho Nova Foods Trading & Manufacturing.	Chỉ dùng dữ liệu tổng hợp, `vi-VN`, `Asia/Ho_Chi_Minh`, `VND`; mô tả scenario học tập, không mô tả cấu hình ERP production.
`Traceability IDs`	Các loại ID phải được liên kết trong instance template.	Chỉ tham chiếu ID đã được cấp bởi registry nguồn; ID không chứng minh approval hoặc baseline.
`Quality gate`	Điều kiện `GO` hoặc `STOP — REWORK REQUIRED`, evidence kiểm tra và vai trò review phù hợp.	Gate kiểm tra chất lượng artifact, không thay thế sign-off chuyên môn, pháp lý, bảo mật, kế toán hoặc vận hành.

Bốn tầng nghĩa vụ bắt buộc

Tầng	Nghĩa vụ	Bằng chứng tối thiểu trong template instance
Tầng 1 — Bắt buộc cấu trúc	Điền mọi trường core của template, định danh, phạm vi, owner, ngày và liên kết nguồn.	Không còn trường bắt buộc trống; ID, filename và artifact link có cú pháp nhất quán.
Tầng 2 — Bắt buộc phân tích	Diễn đạt vấn đề, quy tắc, dữ liệu, luồng hoặc điều kiện theo cách không mơ hồ đối với consumer.	Có trigger, kết quả mong đợi, ngoại lệ hoặc boundary khi nội dung có ngoại lệ.
Tầng 3 — Bắt buộc truy vết và kiểm thử	Liên kết nguồn đầu vào với đầu ra có thể review hoặc kiểm thử.	Có chuỗi ID phù hợp, chẳng hạn `REQ-...` → `AC-...` → `TC-...`; khi chưa có test case, nêu test artifact dự kiến thay vì tuyên bố đã kiểm thử.
Tầng 4 — Bắt buộc quản trị rủi ro	Nêu giả định, dependency, quyết định chờ xác minh và giới hạn thẩm quyền.	Nội dung liên quan pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật mang nhãn `Verification required` hoặc `Project assumption` nếu chưa được nguồn và vai trò có thẩm quyền xác minh.

Chuẩn traceability và quality gate dùng chung

Nhóm liên kết	Mục đích liên kết	Điều kiện quality gate
`BR-...`, `PROC-...`, `REQ-...`	Nối business need, quy trình, rule và requirement.	`GO` khi không có requirement mâu thuẫn rule hoặc bước quy trình đã ghi; `STOP — REWORK REQUIRED` khi một requirement không có nguồn nghiệp vụ hoặc ngoại lệ không có owner.
`DATA-...`, `API-...`, `INT-...`	Nối dữ liệu, hợp đồng giao diện và điểm tích hợp.	`GO` khi định nghĩa dữ liệu, chiều trao đổi, owner dữ liệu và xử lý lỗi có thể xác định; `STOP — REWORK REQUIRED` khi cùng một data element có hai nghĩa hoặc không rõ system of record.
`UX-...`, `NFR-...`, `AC-...`	Nối trải nghiệm, thuộc tính chất lượng và điều kiện chấp nhận.	`GO` khi kết quả quan sát hoặc đo lường được; `STOP — REWORK REQUIRED` khi dùng từ chủ quan như “nhanh”, “dễ dùng”, “an toàn” mà thiếu tiêu chí xác minh.
`RSK-...`, `ASM-...`, `DEC-...`	Nối rủi ro, giả định và quyết định còn mở.	`GO` khi mỗi mục có owner theo dõi và tác động được nêu; `STOP — REWORK REQUIRED` khi giả định bị trình bày như fact hoặc quyết định chưa xác minh bị dùng làm đầu vào bắt buộc.

Phạm vi ví dụ hoàn chỉnh Nova Foods: mỗi template entry chỉ yêu cầu lập kế hoạch cho một completed example ở mức giáo dục, có thể dùng một scenario xuyên suốt như tiếp nhận đơn bán hàng, kiểm tra tồn kho theo lô, hoặc trao đổi trạng thái đơn hàng giữa các hệ thống mô phỏng. Ví dụ phải phân biệt rõ dữ kiện mô phỏng với Project assumption và Verification required; không được suy ra nghĩa vụ từ Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, Nghị định về hóa đơn chứng từ, Luật An toàn thực phẩm hoặc nguồn chuyên ngành khi chưa có xác minh phù hợp. Trạng thái corpus hiện hành là IN_REVIEW, version v0.9.0, ngày 2026-08-07; mọi entry là nội dung lập kế hoạch có kiểm soát, không phải baseline hay approval.

Testing, Defect, UAT, Change, Release, and Operations Templates

Phạm vi micro-batch: Acceptance Criteria và Test-Case Mapping

Micro-batch này chỉ lập kế hoạch cho hai artifact dùng để chuyển requirement thành điều kiện chấp nhận có thể quan sát và liên kết điều kiện đó với test case. Không mở rộng sang test design, test data, defect log, UAT sign-off, change request, release hoặc operations artifact. Trạng thái corpus là IN_REVIEW, version v0.9.0, ngày 2026-08-07; toàn bộ ví dụ Nova Foods là dữ liệu tổng hợp phục vụ giáo dục, không phải requirement đã được phê duyệt hay cấu hình production.

TMPL ID	Tên template và tệp dự kiến	Mục đích kiểm soát	Owner	Consumers	Upstream artifacts	Downstream artifacts
`TMPL-AC-001`	Acceptance Criteria Record — `/02-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md`	Ghi nhận điều kiện chấp nhận cho từng requirement bằng precondition, hành động, kết quả quan sát được, phạm vi ngoại lệ và bằng chứng dự kiến.	Senior IT Business Analyst	QA Reviewer, Business Owner, Solution Analyst, người học	`REQ-FUNC-SALES-012`, business rule, process scenario, data definition và assumption liên quan	`TMPL-TCM-001`, test basis và quality review record
`TMPL-TCM-001`	Test-Case Mapping Matrix — `/02-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md`	Duy trì liên kết một-nhiều giữa business need, requirement, acceptance criterion và test-case ID; phát hiện requirement thiếu tiêu chí hoặc tiêu chí chưa có test case.	QA Reviewer phối hợp Senior IT Business Analyst	QA Reviewer, Business Owner, Solution Analyst, người học	Business need, `REQ-`, `AC-`, rule, scenario và phạm vi release học tập	Test execution evidence được tạo ở artifact testing phù hợp; không tự thay thế test case hoặc kết quả chạy test

Cấu trúc bắt buộc của `TMPL-AC-001`

Trường	Quy tắc điền	Ví dụ Nova Foods tổng hợp
`AC ID`	Dùng định dạng ổn định `AC-{DOMAIN}-{NNN}`; mỗi tiêu chí chỉ có một kết quả chấp nhận chính.	`AC-SALES-012-01`
`Requirement ID`	Phải trỏ tới requirement hiện hữu, không tạo ID thay thế trong acceptance criterion.	`REQ-FUNC-SALES-012`
Business need link	Ghi business need hoặc scenario nguồn; không suy ngược business need chỉ từ câu kiểm thử.	`BN-SALES-003` — tiếp nhận đơn bán hàng mô phỏng
Preconditions	Nêu dữ liệu, trạng thái và quyền cần có trước khi thực hiện; không dùng “hệ thống sẵn sàng” nếu chưa định nghĩa điều kiện.	Khách hàng `CUS-SYN-001`, sản phẩm `SKU-SYN-015`, tồn kho lô `LOT-SYN-20260807-01` đang ở trạng thái có thể phân bổ
Action	Mô tả hành động của actor hoặc hệ thống bằng động từ quan sát được.	Nhân viên bán hàng nhập đơn với số lượng `10`, chọn kho mô phỏng và gửi yêu cầu kiểm tra tồn kho
Expected result	Kết quả phải quan sát hoặc xác minh được, tránh từ chủ quan như “dễ”, “nhanh”, “đúng”.	Hệ thống hiển thị trạng thái `AVAILABLE` hoặc nêu rõ số lượng thiếu; không tạo xác nhận đơn nếu điều kiện phân bổ không đạt
Exception boundary	Nêu trường hợp không thuộc tiêu chí hoặc cần `Verification required`.	Quy tắc thuế, kế toán và điều kiện pháp lý của đơn hàng không được suy ra từ ví dụ này; cần vai trò có thẩm quyền xác minh
Evidence reference	Ghi loại bằng chứng cần thu thập, không điền bằng chứng chưa tồn tại.	Màn hình kết quả hoặc log mô phỏng tham chiếu `TC-SALES-012-01`
Source classification	Phân biệt `Verified source`, `Project assumption`, `Verification required` và `Synthetic example`.	Quy tắc phân bổ theo lô là `Project assumption`; dữ liệu mã khách hàng là `Synthetic example`
Quality gate	`GO` chỉ khi requirement, business need, expected result và owner đã liên kết rõ; nếu thiếu một thành phần thì `STOP — REWORK REQUIRED`.	Không đạt nếu tiêu chí chỉ ghi “đơn được xử lý thành công” mà không nêu trạng thái và điều kiện kiểm chứng

Cấu trúc bắt buộc của `TMPL-TCM-001`

Cột mapping	Quy tắc kiểm tra
`Business Need ID`	Không để trống; phải truy ngược được mục tiêu hoặc scenario nghiệp vụ.
`Requirement ID`	Một dòng chỉ tham chiếu requirement đã định danh; không dùng tên tự do làm khóa liên kết.
`Acceptance Criterion ID`	Phải tồn tại trong `TMPL-AC-001` và thuộc đúng requirement.
`Test Case ID`	Dùng ID test case được cấp trong phạm vi testing; mapping không tự tạo kết quả thực thi.
`Coverage status`	Chỉ dùng các giá trị kiểm soát: `MAPPED`, `UNMAPPED`, `CONFLICT`, `NOT APPLICABLE — JUSTIFICATION REQUIRED`.
`Evidence status`	Không đánh đồng mapping với bằng chứng chạy test; khi chưa có evidence phải ghi rõ `Evidence not yet recorded`.
`Gap / action owner`	Mọi `UNMAPPED` hoặc `CONFLICT` phải có owner và hành động xử lý; không đóng khoảng trống bằng giả định.
`Traceability note`	Ghi lý do liên kết hoặc lý do không áp dụng, đặc biệt khi một requirement có nhiều acceptance criterion.

Chuỗi traceability tối thiểu

BN-SALES-003 → REQ-FUNC-SALES-012 → AC-SALES-012-01 → TC-SALES-012-01

Chuỗi chỉ đạt GO khi mỗi mũi tên trỏ tới một ID tồn tại, không có hai nghĩa cho cùng một ID, acceptance criterion mô tả kết quả quan sát được và test case được liên kết đúng phạm vi. Nếu requirement không có acceptance criterion, hoặc acceptance criterion không có test-case mapping, trạng thái phải là STOP — REWORK REQUIRED; không được kết luận requirement đạt hoặc thất bại chỉ từ việc mapping đã được tạo.

Four-tier obligations áp dụng cho cả hai template

Tier	Nghĩa vụ bắt buộc
Tier 1 — Source and scope	Giữ nguyên ID, tên artifact, phân loại nguồn, locale `vi-VN`, bối cảnh Việt Nam, tiền tệ mô phỏng `VND` và nhãn dữ liệu tổng hợp.
Tier 2 — Traceability and quality	Liên kết đầy đủ business need → requirement → acceptance criterion → test case; kiểm tra tính duy nhất, tính ngược chiều và trạng thái gap.
Tier 3 — Reviewability	Nêu owner, consumers, precondition, expected result, ngoại lệ và loại evidence để người review có thể kiểm tra độc lập.
Tier 4 — Governance boundary	Không gọi nội dung là baseline, approval, user-approved, legal sign-off hoặc production-ready; mục chưa xác minh phải giữ `Project assumption` hoặc `Verification required` và được escalated cho đúng owner.

Generation batch: MB-04-ACCEPTANCE-TEST-MAPPING-001; artifact ở trạng thái kế hoạch IN_REVIEW, không có approval reference.

Danh mục template Thiết kế kiểm thử, Dữ liệu kiểm thử và Nhật ký lỗi

Ba template dưới đây tạo test basis có thể kiểm tra cho Nova Foods Trading & Manufacturing, chỉ dùng dữ liệu tổng hợp. Chúng không là bằng chứng baseline, phê duyệt UAT, chấp thuận triển khai hoặc xác nhận tuân thủ pháp lý. Thuật ngữ kiểm thử dùng theo phạm vi an toàn của ISTQB CTFL Syllabus v4.0.1; các yêu cầu liên quan dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc phải giữ nhãn Verification required khi chưa được vai trò có thẩm quyền xác minh.

Template ID	Tệp được kiểm soát	Mục đích và Owner	Consumers	Upstream artifacts	Downstream artifacts	Traceability IDs bắt buộc	Quality gate	Generation batch
`TMPL-TST-001`	`/04-validation-testing-and-change-templates/TMPL-TST-001_TEST_DESIGN.md`	Chuyển requirement, business rule và acceptance criterion thành điều kiện kiểm thử, kỹ thuật thiết kế, tập test case và expected result. Owner: QA Lead.	IT BA, QA Engineer, Developer, Technical Lead.	Business Need ID; `REQ-`; `BR-`; `AC-*`; data dictionary; API/UX/NFR specification khi có.	`TC-`; test execution evidence; `DEF-`; báo cáo chất lượng.	`BN-* → REQ-* → AC-* → TC-`; liên kết `BR-`, `DATA-`, `API-` hoặc `NFR-*` khi áp dụng.	Mỗi test condition có nguồn test basis, expected result quan sát được, kỹ thuật thiết kế và ít nhất một `TC-*`; không có test case không truy được về requirement hoặc rule.	`GEN-04-TEST-DATA-DEFECT-01`
`TMPL-TST-002`	`/04-validation-testing-and-change-templates/TMPL-TST-002_TEST_DATA.md`	Xác định dữ liệu đầu vào, dữ liệu nền, dữ liệu biên và cách làm mới dữ liệu cho test case. Owner: QA Lead phối hợp Data Steward.	QA Engineer, Developer, IT BA, môi trường kiểm thử administrator.	`TC-`; `DATA-`; `BR-*`; interface contract; phân loại dữ liệu.	Test execution evidence; `DEF-*`; data-reset record.	`TD-* → TC-`; tham chiếu `DATA-`, `BR-`, `REQ-`; mỗi tập dữ liệu phải có Test Data Set ID.	Không dùng dữ liệu thật; dữ liệu có định danh tổng hợp, giá trị biên, expected state và quy tắc reset; dữ liệu nhạy cảm giả lập phải được gắn phân loại.	`GEN-04-TEST-DATA-DEFECT-01`
`TMPL-TST-003`	`/04-validation-testing-and-change-templates/TMPL-TST-003_DEFECT_LOG.md`	Ghi nhận, tái hiện, phân loại, liên kết và theo dõi lỗi phát hiện trong kiểm thử. Owner: QA Lead.	Developer, IT BA, Technical Lead, QA Engineer, Product/Business Owner khi cần làm rõ nghiệp vụ.	`TC-`; test execution evidence; screenshot hoặc request/response đã che dữ liệu; `REQ-`; `AC-`; `BR-`.	Defect triage record; fix verification evidence; cập nhật test case hoặc requirement clarification khi có kiểm soát.	`DEF-* → TC-* → AC-* → REQ-* → BN-`; liên kết `BR-`, `TD-`, `DATA-` khi lỗi phụ thuộc rule hoặc data.	Lỗi phải tái hiện được hoặc được đánh dấu rõ là chưa tái hiện; có actual result, expected result, môi trường, severity, priority và quyết định triage có owner.	`GEN-04-TEST-DATA-DEFECT-01`

Bốn tầng nghĩa vụ áp dụng cho từng template

Tầng	Nghĩa vụ ghi trong `TMPL-TST-001`, `TMPL-TST-002`, `TMPL-TST-003`
Tier 1 — Bắt buộc để hợp lệ	Điền đầy đủ ID, Owner, ngày ghi nhận `Asia/Ho_Chi_Minh`, nguồn test basis, liên kết traceability và trạng thái `IN_REVIEW` tại version `v0.9.0`.
Tier 2 — Bắt buộc theo rủi ro	Bổ sung trường bảo mật, hiệu năng, tích hợp, phân quyền, dữ liệu biên, dữ liệu lỗi hoặc khôi phục khi `NFR-`, `API-`, phân loại dữ liệu hoặc rủi ro quy trình yêu cầu.
Tier 3 — Cần xác minh chuyên môn	Gắn `Verification required` cho diễn giải pháp lý, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc chưa được Legal Owner, Accounting Owner hoặc Domain Owner xác minh.
Tier 4 — Giả định mô phỏng giáo dục	Đánh dấu `Project assumption` cho quy trình, ngưỡng, mã lô, quyền người dùng, cấu hình ERP và dữ liệu Nova Foods được tạo để học tập; không diễn giải là cấu hình production.

Cấu trúc bắt buộc và ví dụ phạm vi hoàn chỉnh Nova Foods

Template	Trường bắt buộc	Ví dụ phạm vi hoàn chỉnh, dữ liệu tổng hợp
`TMPL-TST-001`	Test Design ID; mục tiêu; test basis; test condition; kỹ thuật; phạm vi; out-of-scope; rủi ro; `REQ-`; `AC-`; `BR-`; danh sách `TC-`; expected result; reviewer.	`TDS-SALES-012-001` kiểm tra việc tạo đơn bán hàng cho khách hàng tổng hợp `CUS-NF-001`. Test basis: `REQ-FUNC-SALES-012`, `AC-SALES-012-001`, `BR-SALES-004`. Điều kiện: số lượng đặt `0`, `1`, `999999`; kỹ thuật phân vùng tương đương và phân tích giá trị biên; tạo `TC-SALES-012-001` đến `TC-SALES-012-003`.
`TMPL-TST-002`	Test Data Set ID; `TC-*`; thực thể; trường dữ liệu; giá trị; phân loại; nguồn tạo; precondition; expected state; reset action; retention boundary; owner.	`TD-SALES-012-001` gồm `CustomerCode=CUS-NF-001`, `ItemCode=SKU-NF-001`, `OrderQty=1`, `UnitPrice=125000 VND`; trạng thái dữ liệu là `Synthetic/Internal`; precondition: khách hàng và hàng hóa đang hoạt động trong môi trường test; reset: xóa đơn tạo bởi test run và khôi phục tồn kho test về trạng thái trước chạy.
`TMPL-TST-003`	Defect ID; tiêu đề; môi trường; build; precondition; bước tái hiện; actual result; expected result; severity; priority; trạng thái; assignee; evidence location; liên kết `TC-`, `AC-`, `REQ-*`; kết quả retest.	`DEF-SALES-012-001`: tại môi trường `TEST`, khi chạy `TC-SALES-012-001`, hệ thống lưu đơn có `OrderQty=0`. Expected result theo `AC-SALES-012-001`: hệ thống từ chối lưu và hiển thị lỗi kiểm tra dữ liệu. Severity `High`, Priority `High`, liên kết `TD-SALES-012-001`, trạng thái khởi tạo `New`.

Quy tắc traceability tối thiểu: một business need BN-* được hiện thực hóa bởi REQ-*; requirement được kiểm chứng qua AC-*; mỗi acceptance criterion phải được tham chiếu bởi ít nhất một TC-*; test case sử dụng TD-* khi cần dữ liệu; lỗi DEF-* phải chỉ ra test case phát hiện lỗi và quay ngược được tới acceptance criterion, requirement và business need. Nếu thiếu một mắt xích, QA Lead đặt trạng thái quality gate là STOP — TRACEABILITY GAP; IT BA chỉ được làm rõ test basis, không tự xác nhận thay đổi requirement hay business rule.

Danh mục mẫu chuẩn bị UAT và theo dõi xác nhận UAT

UAT xác nhận mức đáp ứng nghiệp vụ trên cơ sở test basis đã truy vết; không tự tạo requirement mới, không thay thế kiểm thử hệ thống, không xác nhận tuân thủ pháp lý và không là bằng chứng sẵn sàng production. Thuật ngữ kiểm thử sử dụng tham chiếu nguồn chính ISTQB CTFL Syllabus v4.0.1; mọi dữ liệu Nova Foods là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Template ID và tệp được kiểm soát	Mục đích và completed-example scope Nova Foods	Owner; consumers	Upstream → downstream	Traceability IDs bắt buộc	Four-tier obligations	Quality gate	Generation batch
`TMPL-UAT-PREP-001` — `/01-curriculum/templates/TMPL-UAT-PREP-001_uat-preparation.md`	Lập kế hoạch UAT cho kịch bản tổng hợp “Sales Order đến xác nhận giao hàng”; ví dụ hoàn chỉnh chỉ bao gồm một đơn hàng mô phỏng, một vai trò Sales Admin và một vai trò Warehouse Supervisor.	Owner: UAT Coordinator. Consumers: Business Owner, BA, QA Lead, người thực hiện UAT.	`BUS-NEED-` → `REQ-` → `AC-` → `TC-` → kế hoạch UAT → evidence UAT và `TMPL-UAT-SIGN-002`.	`UAT-PREP-001`, `BUS-NEED-SALES-001`, `REQ-FUNC-SALES-012`, `AC-SALES-012-01`, `TC-UAT-SALES-012-01`.	T1: ID, phạm vi, người thực hiện, môi trường, entry/exit criteria, mapping phải có. T2: test data, hướng dẫn truy cập và lịch chạy phải có khi kịch bản cần chúng. T3: giả định môi trường hoặc lịch phải gắn nhãn `Project assumption`. T4: nội dung liên quan dữ liệu cá nhân, kế toán, hóa đơn hoặc an toàn thực phẩm phải gắn `Verification required` và chỉ rõ owner xác minh.	`GO FOR UAT` chỉ khi mọi `REQ-` trong phạm vi có ít nhất một `AC-` quan sát được và một `TC-*`; dữ liệu tổng hợp, quyền truy cập và expected result đã được kiểm tra khả dụng. Nếu thiếu một liên kết hoặc entry criterion, trạng thái là `STOP — UAT NOT READY`.	`BATCH-04-01`
`TMPL-UAT-SIGN-002` — `/01-curriculum/templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md`	Theo dõi kết quả và quyết định xác nhận UAT cho cùng phạm vi mô phỏng; ví dụ hoàn chỉnh ghi nhận từng test case đạt, không đạt hoặc bị chặn, không suy diễn approval từ việc chạy test.	Owner: UAT Coordinator. Consumers: Business Owner, BA, QA Lead, Release Manager.	Kế hoạch UAT và evidence thực thi → register xác nhận UAT → đầu vào quyết định release hoặc xử lý thay đổi theo artifact riêng.	`UAT-SIGN-002`, `UAT-EXEC-SALES-012-01`, `TC-UAT-SALES-012-01`, `AC-SALES-012-01`, `REQ-FUNC-SALES-012`.	T1: kết quả thực tế, expected result, evidence reference, người thực hiện, ngày giờ và trạng thái quyết định phải có. T2: lý do không đạt hoặc bị chặn phải có khi trạng thái khác `PASS`. T3: tiêu chí chấp nhận rủi ro chưa được xác nhận phải ghi `Project assumption`, không được đổi thành pass. T4: xác nhận có tác động pháp lý, kế toán, dữ liệu cá nhân hoặc vận hành phải là `Verification required`; UAT Coordinator không được tự xác nhận thay owner có thẩm quyền.	`UAT RECORD COMPLETE` chỉ khi mọi test case trong phạm vi có kết quả, evidence reference và liên kết ngược đến `AC-*`. `UAT SIGN-OFF READY FOR DECISION` chỉ là trạng thái hồ sơ sẵn sàng để vai trò có thẩm quyền quyết định; không phải approval đã ghi nhận.	`BATCH-04-01`

Cấu trúc tối thiểu của TMPL-UAT-PREP-001:

Trường	Quy tắc ghi nhận
UAT objective và phạm vi	Nêu business outcome có thể quan sát; liệt kê requirement trong phạm vi và loại trừ rõ kịch bản ngoài phạm vi.
Entry criteria	Xác định môi trường UAT, tài khoản vai trò, test data tổng hợp, test case đã review và xử lý dependency kỹ thuật cần thiết.
Traceability mapping	Mỗi dòng dùng chuỗi đầy đủ `BUS-NEED-* → REQ-* → AC-* → TC-*`; không chấp nhận mapping chỉ từ requirement thẳng đến kết quả UAT.
UAT participant matrix	Ghi tên vai trò, trách nhiệm thực thi hoặc quan sát, quyền truy cập cần thiết và người thay thế theo dự án.
Exit criteria	Xác định điều kiện hoàn tất hồ sơ UAT: toàn bộ test case có kết quả, evidence reference, trạng thái block được giải thích và quyết định còn mở được phân loại.
Evidence convention	Evidence phải là định danh hoặc liên kết đến ảnh chụp, export, log hoặc biên bản tổng hợp được kiểm soát; không dùng nhận xét miệng làm bằng chứng duy nhất.

Cấu trúc tối thiểu của TMPL-UAT-SIGN-002:

Trường theo dõi	Quy tắc quyết định
Kết quả từng test case	Chỉ dùng `PASS`, `FAIL`, `BLOCKED` hoặc `NOT RUN`; `PASS` yêu cầu actual result khớp expected result của `TC-*` và evidence reference.
Tác động nghiệp vụ	Mô tả tác động theo requirement và acceptance criterion, không gán mức độ nghiêm trọng kỹ thuật thay cho đánh giá nghiệp vụ.
Trạng thái xác nhận	Phân biệt `RECORD COMPLETE`, `AWAITING AUTHORIZED DECISION` và `DECISION RECORDED`; chỉ trạng thái cuối được dùng khi artifact kiểm soát ghi rõ vai trò có thẩm quyền, quyết định và thời điểm.
Ngoại lệ và vấn đề mở	`FAIL`, `BLOCKED` hoặc `NOT RUN` phải liên kết đến ID artifact quản lý phù hợp khi artifact đó tồn tại; register UAT chỉ ghi nhận tác động và không thay thế defect log hoặc change request.
Boundary thẩm quyền	Business Owner đánh giá mức đáp ứng nghiệp vụ trong phạm vi được giao; không xác nhận pháp lý, kế toán, bảo mật, production deployment hoặc baseline nếu không có quyết định riêng của owner có thẩm quyền.

Danh mục Template Change Request, Release Notes và Deployment Readiness

Các template dưới đây là artifact lập kế hoạch cho Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Chúng kế thừa trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không xác lập baseline, quyết định triển khai production hoặc xác nhận thẩm quyền chuyên môn.

TMPL ID và tệp được kiểm soát	Mục đích và Owner	Consumers	Upstream → downstream artifacts	Bốn tầng nghĩa vụ	Phạm vi completed-example Nova Foods	Traceability IDs bắt buộc	Quality gate	Generation batch
`TMPL-CR-001` `/02-template-library/change/TMPL-CR-001_change-request.md`	Ghi nhận, phân tích và kiểm soát đề xuất thay đổi đối với requirement, rule, data, API, UX, test basis hoặc release scope. Owner: IT Business Analyst.	Business Owner, Product Owner, Solution Architect, QA Lead, Release Manager, Legal/Compliance Owner khi có phạm vi thuộc thẩm quyền.	Business need, requirement, business rule, defect hoặc UAT finding → impact assessment, quyết định thay đổi được ghi nhận, requirement/test/release artifact được cập nhật có truy vết.	T1: trường bắt buộc và ID duy nhất. T2: phân tích tác động liên artifact. T3: evidence, quyết định và ngày hiệu lực được ghi nhận. T4: vấn đề pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc production phải định tuyến đúng owner có thẩm quyền.	`CR-SALES-001`: đề xuất đổi thông điệp lỗi khi đơn bán vượt hạn mức tín dụng mô phỏng; không thay đổi chính sách tín dụng thực tế.	`CR-SALES-001`; `BN-SALES-001`; `REQ-FUNC-SALES-012`; `AC-SALES-012-01`; `TC-SALES-012-01`; liên kết defect nếu có `DEF-SALES-001`.	`GO` khi có nguồn khởi tạo, mô tả thay đổi đơn nghĩa, impacted IDs, tác động phạm vi/rủi ro, owner quyết định phù hợp và đường cập nhật downstream. `STOP` khi thay đổi không có test basis hoặc tự suy diễn nghĩa vụ pháp lý.	`BATCH-04-03`
`TMPL-REL-001` `/02-template-library/release/TMPL-REL-001_release-notes.md`	Công bố nội dung một release theo thay đổi đã được ghi nhận; phân biệt chức năng mới, sửa lỗi, giới hạn biết trước và tác động vận hành. Owner: Release Manager.	Business Owner, Support Lead, QA Lead, IT Operations, người dùng nội bộ Nova Foods.	Change request, defect disposition, test summary, deployment readiness → thông báo release, hướng dẫn sử dụng bị ảnh hưởng, support intake.	T1: release ID, version, môi trường, thời điểm và phạm vi. T2: mỗi mục release liên kết CR/REQ/DEF. T3: nêu evidence kiểm thử và known limitation có ID. T4: không diễn giải release note là xác nhận compliance, kế toán hoặc pháp lý.	`REL-NF-0.9.0-RC1`: nêu thay đổi hiển thị cảnh báo vượt hạn mức tín dụng trong luồng tạo đơn mô phỏng.	`REL-NF-0.9.0-RC1`; `CR-SALES-001`; `REQ-FUNC-SALES-012`; `AC-SALES-012-01`; `TC-SALES-012-01`.	`GO` khi mọi mục có loại thay đổi, impacted ID, audience, hướng dẫn hành động và giới hạn rõ. `STOP` khi release note chứa thay đổi không truy được về CR, requirement hoặc defect.	`BATCH-04-03`
`TMPL-DEP-001` `/02-template-library/release/TMPL-DEP-001_deployment-readiness.md`	Kiểm tra tính sẵn sàng triển khai của một release theo evidence đã định danh; không thay thế runbook vận hành hoặc biên bản handover. Owner: Release Manager.	Solution Architect, QA Lead, IT Operations, Support Lead, Business Owner.	Release notes, test evidence, change records, rollback design, environment checklist → quyết định triển khai được ghi nhận, execution record, operational handover artifact.	T1: release/environment/window/owner/rollback contact. T2: liên kết scope với CR, REQ, AC, TC và release note. T3: evidence reference cho test, backup, rollback rehearsal và communication. T4: các điểm cần xác nhận về privacy, accounting, food safety hoặc security giữ nhãn `Verification required` cho owner chuyên trách.	`DEP-NF-0.9.0-RC1`: checklist cho môi trường UAT mô phỏng, không phải lịch triển khai production.	`DEP-NF-0.9.0-RC1`; `REL-NF-0.9.0-RC1`; `CR-SALES-001`; `REQ-FUNC-SALES-012`; `AC-SALES-012-01`; `TC-SALES-012-01`.	`GO` khi scope release khớp release note, test evidence đạt tiêu chí đã định, rollback có bước và owner, dependency/environment được kiểm tra. `STOP` khi có `FAIL`, `BLOCKED`, evidence thiếu, hoặc trách nhiệm quyết định chưa được định tuyến.	`BATCH-04-03`

Cấu trúc tối thiểu của TMPL-CR-001:

Trường	Quy tắc điền và kiểm soát
Change ID, ngày ghi nhận, requester, owner	Dùng đúng định dạng `CR-{DOMAIN}-{NNN}`; requester chỉ là nguồn đề xuất, không đồng nghĩa quyết định thay đổi.
Change trigger và phạm vi	Chọn một nguồn: business need, requirement clarification, defect, UAT finding, technical constraint hoặc compliance question; mô tả phần bị ảnh hưởng và phần không thay đổi.
Before/after state	Nêu hành vi hoặc nội dung trước thay đổi và sau thay đổi bằng kết quả quan sát được; không dùng nhận định mơ hồ như “tối ưu hơn”.
Impact assessment	Đánh giá requirement, rule, data, API, UX, acceptance criterion, test case, release scope, training và support artifact; mục không áp dụng phải ghi `NOT APPLICABLE` cùng lý do.
Decision record	Ghi trạng thái `OPEN`, `ANALYZED`, `DECISION RECORDED`, `IMPLEMENTED` hoặc `CLOSED WITHOUT IMPLEMENTATION`; chỉ dùng `DECISION RECORDED` khi artifact có quyết định, vai trò và thời điểm rõ ràng.
Verification boundary	Nội dung liên quan pháp luật, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật phải gắn `Verification required` hoặc `Project assumption` nếu chưa được owner chuyên trách xác minh.

Cấu trúc tối thiểu của TMPL-REL-001 và TMPL-DEP-001:

Template	Trường bắt buộc	Tiêu chí loại trừ
`TMPL-REL-001`	Release ID, version, phạm vi, danh sách thay đổi, defect fixed, known limitation, impacted audience, action required, traceability reference, phát hành owner.	Không liệt kê thay đổi chưa có ID nguồn; không gọi release là compliant, production-ready hoặc đã được chấp thuận chỉ dựa trên việc phát hành ghi chú.
`TMPL-DEP-001`	Release ID, target environment, deployment window, scope reconciliation, pre-deployment checks, evidence references, rollback trigger, rollback steps, communication plan, readiness decision record, unresolved risks.	Không thay thế test evidence bằng xác nhận miệng; không chuyển `FAIL` hoặc `BLOCKED` thành sẵn sàng chỉ bằng đánh giá chủ quan.

Chuỗi truy vết tối thiểu xuyên ba template là BN-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-01 → TC-SALES-012-01 → CR-SALES-001 → REL-NF-0.9.0-RC1 → DEP-NF-0.9.0-RC1. Chuỗi này là completed-example scope mô phỏng để dạy cách kiểm soát thay đổi và release; không xác nhận yêu cầu, hạn mức tín dụng, cấu hình ERP hoặc quyết định vận hành thực tế của Nova Foods.

TMPL-OPS-HANDOVER, TMPL-RUNBOOK, và TMPL-SUPPORT: bộ template bàn giao vận hành cho Nova Foods ERP

Trường kiểm soát	Giá trị
Nhóm template	Operational handover, runbook, support readiness
Bộ ID chuẩn	`TMPL-OPS-HND-01`, `TMPL-RUN-01`, `TMPL-SUP-01`
Tệp đích gợi ý	`/01-curriculum/templates/TMPL-OPS-HND-01.md`, `/01-curriculum/templates/TMPL-RUN-01.md`, `/01-curriculum/templates/TMPL-SUP-01.md`
Trạng thái corpus	`IN_REVIEW`
Version phát hành kế hoạch	`v0.9.0`
Generation batch	`MB-04-OPS-2026-08-07-01`
Owner	Principal IT Business Analyst / Technical Curriculum Author
Consumers	Business Owner, Solution Architect, QA Reviewer, Operations Lead, Service Desk Lead, Trainer, Security/Access Admin
Upstream artifacts	Requirement, acceptance criterion, test case, defect closure note, UAT evidence, deployment readiness note, training completion record
Downstream artifacts	Incident log, knowledge article, support roster, steady-state checklist, access audit note, hypercare log, operational KPI review
Source boundaries	Chỉ dùng dữ liệu tổng hợp Nova Foods; mọi số liệu sản xuất, SLA, số điện thoại, ca trực, hoặc ngưỡng cảnh báo phải được gắn `Project assumption` hoặc `Verification required` nếu chưa có xác minh chính thức

1) Mục đích nghiệp vụ và ranh giới sử dụng

Bộ template này dùng để chuyển một giải pháp đã được kiểm thử sang trạng thái vận hành có kiểm soát. “Bàn giao vận hành” không phải là phê duyệt triển khai, mà là gói thông tin giúp đội vận hành nhận đúng phạm vi, biết hệ thống làm gì, làm sao kiểm tra khỏe hay lỗi, ai xử lý khi có sự cố, và bằng chứng nào chứng minh giải pháp đủ điều kiện hỗ trợ. Với Nova Foods ERP, phạm vi chuẩn là mô phỏng giáo dục cho luồng tổng hợp như quản lý kho, bán hàng, mua hàng, kế toán nội bộ và truy xuất nghiệp vụ; không suy diễn sang quy trình sản xuất thật hay yêu cầu pháp lý chưa được xác minh.

2) Cấu trúc nội dung bắt buộc của từng template

Template	Trường bắt buộc	Mô tả đầu ra kiểm soát
`TMPL-OPS-HND-01`	Mục tiêu bàn giao, phạm vi, danh sách thành phần, trạng thái hệ thống, phụ thuộc, giới hạn đã biết, danh bạ liên hệ, tiêu chí nhận bàn giao, chữ ký xác nhận nhận bàn giao	Một biên bản bàn giao vận hành có thể đọc hiểu, đối chiếu và lưu vết
`TMPL-RUN-01`	Mục đích runbook, điều kiện tiên quyết, bước thao tác chuẩn, kiểm tra trước/sau thao tác, ngưỡng cảnh báo, hướng xử lý lỗi, nhánh escalation, bằng chứng cần lưu	Một hướng dẫn thao tác lặp lại được, giảm phụ thuộc vào trí nhớ cá nhân
`TMPL-SUP-01`	Mô hình hỗ trợ, phân tuyến L1/L2/L3, giờ hỗ trợ, nguyên tắc ưu tiên, điều kiện chuyển tuyến, danh mục quyền truy cập, tài liệu tham chiếu, tiêu chí sẵn sàng hỗ trợ	Một checklist chứng minh đội hỗ trợ có người, có quyền, có tài liệu và có kênh xử lý

3) Quy tắc traceability từ yêu cầu đến vận hành

Mã traceability	Chuỗi liên kết	Quy tắc kiểm soát
`TR-OPS-001`	`BR-NF-OPS-001` → `REQ-NF-OPS-014` → `AC-NF-OPS-014` → `TST-NF-OPS-014` → `OPS-HND-01`	Không được đưa vào bàn giao nếu chưa có acceptance criterion và test evidence tương ứng
`TR-OPS-002`	`BR-NF-SUP-002` → `REQ-NF-SUP-007` → `AC-NF-SUP-007` → `TST-NF-SUP-007` → `RUN-01`	Runbook phải phản ánh đúng hành vi đã được kiểm thử, không thêm thao tác chưa được xác nhận
`TR-OPS-003`	`BR-NF-SVC-003` → `REQ-NF-SVC-009` → `AC-NF-SVC-009` → `UAT-NF-SVC-009` → `SUP-01`	Support readiness chỉ hoàn tất khi có người nhận trách nhiệm, quyền truy cập và kênh escalation

4) Four-tier obligations cho người soạn và người dùng template

Tầng	Nghĩa vụ	Ví dụ áp dụng
Tier 1 — Bắt buộc	Điền đầy đủ owner, consumers, upstream/downstream artifacts, traceability ID, quality gate, generation batch	Không được bỏ trống trường liên hệ bàn giao hoặc tiêu chí nhận bàn giao
Tier 2 — Có điều kiện	Chỉ ghi ngưỡng, ca trực, SLA, thời gian phản hồi khi đã có xác minh hoặc được đánh dấu `Project assumption`	Nếu chưa có service owner xác nhận, không tự đặt “24/7”
Tier 3 — Verification required	Nội dung liên quan dữ liệu cá nhân, truy cập đặc quyền, lưu trữ log, retention, hoặc nghĩa vụ pháp lý phải được gắn nhãn xác minh	Danh mục quyền truy cập admin chỉ được chốt sau kiểm tra với owner phù hợp
Tier 4 — Cấm	Không được chép nguyên văn giả định thành chuẩn vận hành, không được biến runbook thành release note, không được dùng handover để hợp thức hóa baseline	Không đưa nội dung chưa kiểm chứng vào phần “đã sẵn sàng vận hành”

5) Quality gate cho bộ template này

Gate	Tiêu chí đạt	Tiêu chí không đạt
`QG-OPS-01`	Có đủ 3 template, mỗi template có owner, consumer, upstream/downstream, traceability ID, quality gate và generation batch	Chỉ có mô tả chung mà không có trường kiểm soát
`QG-OPS-02`	Có checklist nhận bàn giao, hướng dẫn thao tác, mô hình hỗ trợ rõ ràng, và bằng chứng có thể kiểm tra	Thiếu danh bạ hỗ trợ, thiếu bước khôi phục hoặc thiếu tiêu chí nhận bàn giao
`QG-OPS-03`	Nội dung Nova Foods chỉ là synthetic scope, không lẫn dữ liệu thật, không lẫn cam kết production	Có số liệu thật, tên người thật, hoặc điều khoản vận hành chưa được xác minh

6) Nova Foods completed-example scope

Bối cảnh mô phỏng: bàn giao module ERP “Quản lý tồn kho thành phẩm” sau UAT đã đạt, để đội vận hành tiếp nhận theo chế độ hỗ trợ nội bộ.
Bàn giao vận hành: ghi rõ kho nào thuộc phạm vi mô phỏng, danh mục báo cáo nào được hỗ trợ, danh bạ xử lý sự cố nào được dùng, và giới hạn nào không thuộc phạm vi hỗ trợ.
Runbook mẫu: mô tả thao tác kiểm tra tồn kho đầu ngày, đối chiếu giao dịch nhập/xuất, cách xác nhận dữ liệu hiển thị đúng, và nhánh xử lý khi số liệu không khớp.
Support readiness: xác nhận có người nhận ticket, có quyền xem màn hình, có tài liệu tra cứu, và có cơ chế chuyển tuyến khi lỗi vượt khả năng L1.

7) Quy tắc biên soạn bắt buộc

Mỗi template phải có một câu mở đầu nêu rõ “dùng cho mục đích vận hành sau bàn giao” để tránh nhầm với tài liệu thiết kế hoặc tài liệu kiểm thử. Người soạn phải ghi rõ actor sử dụng, action cần thực hiện, object được xử lý và outcome cần đạt.
Không được đưa yêu cầu chưa được kiểm chứng thành hướng dẫn thao tác chuẩn. Người soạn phải ghi rõ nguồn kiểm chứng, owner chịu trách nhiệm xác minh và consequence nếu hướng dẫn sai; nội dung chưa đủ bằng chứng không được trình bày như quy trình đã chấp thuận.
Nếu có nội dung liên quan dữ liệu cá nhân, nhật ký truy cập, lưu trữ bằng chứng hoặc phân quyền, phải gắn nhãn Verification required và chuyển sang owner phù hợp. Owner phải xác định phạm vi dữ liệu, quyền truy cập, artifact cần lưu và quyết định xử lý trước khi template được dùng trong vận hành.
Bàn giao vận hành chỉ hoàn tất khi có đủ traceability từ requirement và test evidence sang gói handover, không chỉ dựa trên cảm nhận đã xong. Người soạn phải liên kết requirement, acceptance criterion, test case hoặc test evidence, artifact bàn giao và người xác nhận; thiếu liên kết thì quality gate không đạt.
TMPL-OPS-HND-01, TMPL-RUN-01, TMPL-SUP-01 là định danh ổn định cho corpus này; không đổi tên tùy tiện trong cùng phiên bản v0.9.0. Các định danh này là stable TMPL identifier trong registry, còn tên tệp phải tuân thủ mẫu /02-templates/TMPL-{DOMAIN}-{NNN}--{english-kebab-slug}.md.
Tệp tương ứng phải dùng đúng thư mục, domain, số thứ tự ba chữ số và slug tiếng Anh dạng kebab-case. Không dùng /01-curriculum/templates/..., /02-template-library/..., dấu gạch dưới hoặc slug như _uat-preparation.md. Ví dụ hợp lệ:
Registry ID TMPL-OPS-HND-01 → /02-templates/TMPL-OPS-001--operational-handover.md
Registry ID TMPL-RUN-01 → /02-templates/TMPL-OPS-002--operations-runbook.md
Registry ID TMPL-SUP-01 → /02-templates/TMPL-OPS-003--support-readiness.md
Người soạn phải giữ mapping giữa stable TMPL identifier và filename trong registry. Đổi slug hoặc số thứ tự làm mất liên kết với artifact, traceability và consumer; mọi thay đổi phải giữ stable ID, ghi nhận owner, reason, affected artifact và consequence, đồng thời giữ trạng thái IN_REVIEW.

Ma trận truy vết Business Need → Requirement → Acceptance Criterion → Test Case

Template được lập kế hoạch: TMPL-VAL-TRACE-001
Tên tệp được kiểm soát: /04-validation-testing-and-change-templates/TMPL-VAL-TRACE-001_requirements-to-test-traceability-matrix.md
Trạng thái / phiên bản / ngày: IN_REVIEW / v0.9.0 / 2026-08-07
Phạm vi: Nova Foods Trading & Manufacturing là case study giáo dục; mọi dữ liệu, mã lô, khách hàng và kết quả kiểm thử là dữ liệu tổng hợp. Template này không xác nhận requirement, test result, UAT acceptance hoặc production readiness.

Ma trận là cơ chế chứng minh từ nguyên tắc đầu tiên rằng một kiểm thử không tồn tại độc lập: mỗi TC phải kiểm tra một kết quả quan sát được trong AC; mỗi AC phải làm rõ một requirement; mỗi requirement phải giải quyết một business need có owner và bối cảnh xác định. Không được suy diễn ngược rằng test case đã chạy đồng nghĩa business need đã được đáp ứng.

Thuộc tính quản trị	Quy định template
Owner	IT Business Analyst duy trì liên kết nghiệp vụ và requirement; Test Lead duy trì tính đầy đủ của test-case mapping.
Consumers	Business Owner, Product Owner, QA Reviewer, Test Analyst, UAT Coordinator, Release Manager và Support Lead.
Upstream artifacts	Business Need register, BRD hoặc backlog requirement, business rules, data dictionary, process model và acceptance-criteria artifact.
Downstream artifacts	Test design, test case, test execution evidence, defect log, UAT tracking, release-readiness assessment và operational handover.
Generation batch	`04-validation-testing-and-change-templates` — micro-batch `Traceability from business need to requirement to acceptance criterion to test case`.
Nguồn thuật ngữ kiểm thử	`ISTQB CTFL Syllabus v4.0.1` — primary testing syllabus; chỉ dùng cho thuật ngữ và kỹ thuật kiểm thử, không suy diễn approval hoặc nghĩa vụ pháp lý.
Quality gate	Không có requirement in-scope nào thiếu ít nhất một acceptance criterion kiểm thử được; không có test case nào thiếu `AC ID`; mọi liên kết phải truy ngược được đến `BN ID`.

Bốn tầng nghĩa vụ áp dụng cho từng dòng truy vết

Tầng	Nhãn	Cách dùng trong ma trận	Quy tắc kiểm soát
1	`Legal / Regulatory`	Chỉ dùng khi requirement có nguồn pháp lý hoặc quy định được định danh.	Phải ghi nguồn chính thức và `Verification required` nếu chưa được Legal Owner hoặc Compliance Owner xác minh.
2	`Contractual / Approved Policy`	Dùng cho cam kết hợp đồng hoặc chính sách đã có artifact kiểm soát phù hợp.	Không được gán nhãn này chỉ từ mô tả miệng, email không kiểm soát hoặc giả định đào tạo.
3	`Business / Operational`	Dùng cho mục tiêu, quy trình và quyết định vận hành Nova Foods mô phỏng.	Business Owner là vai trò cần xác nhận trong giai đoạn review; `IN_REVIEW` không phải xác nhận.
4	`Project Assumption / Verification required`	Dùng cho chi tiết chưa có nguồn xác minh, bao gồm điều kiện dữ liệu, ngưỡng vận hành hoặc kỳ vọng cấu hình ERP.	Phải nêu rõ giả định hoặc câu hỏi xác minh; không được chuyển thành mandatory rule khi chưa có bằng chứng.

Cấu trúc dòng bắt buộc

Cột	Nội dung tối thiểu	Quy tắc hợp lệ
`BN ID`	Định danh business need	Một business need có thể liên kết nhiều requirement.
`REQ ID`	Định danh requirement chức năng, phi chức năng hoặc business rule liên quan	Phải giữ nguyên canonical ID đã được đăng ký.
`AC ID`	Định danh acceptance criterion	Mỗi criterion mô tả một kết quả quan sát, điều kiện và kết quả mong đợi.
`TC ID`	Định danh test case	Mỗi test case phải tham chiếu tối thiểu một `AC ID`.
Điều kiện kiểm thử	Dữ liệu đầu vào, vai trò, precondition và event kích hoạt	Không ghi dữ liệu cá nhân thật hoặc dữ liệu production.
Kết quả mong đợi	Kết quả có thể quan sát và đối chiếu	Không dùng các cụm mơ hồ như “hoạt động đúng” hoặc “xử lý phù hợp”.
Tầng nghĩa vụ	Một trong bốn tầng ở trên	Phải nhất quán với nguồn và nhãn xác minh.
Evidence reference	Test execution record hoặc defect reference khi đã phát sinh	Để trống chỉ khi test chưa được thực thi; không được suy ra pass.

Ví dụ hoàn chỉnh trong phạm vi Nova Foods mô phỏng

BN ID	Business need	REQ ID	AC ID	TC ID	Điều kiện và kết quả mong đợi	Tầng nghĩa vụ	Trạng thái truy vết
`BN-SALES-012`	Nhân viên bán hàng cần biết đơn hàng nào không thể tiếp tục xử lý khi số lượng đặt vượt tồn kho khả dụng, nhằm tránh cam kết giao hàng không khả thi.	`REQ-FUNC-SALES-012`	`AC-SALES-012-01`	`TC-SALES-012-01`	Với mặt hàng mô phỏng `NF-RICE-01`, tồn kho khả dụng `100`, người dùng nhập số lượng `101`; hệ thống chặn xác nhận đơn hàng và hiển thị lý do vượt tồn kho khả dụng.	`Business / Operational`	Liên kết đầy đủ từ need đến test case; test execution evidence chưa được ghi nhận.
`BN-SALES-012`	Nhân viên bán hàng cần biết đơn hàng nào không thể tiếp tục xử lý khi số lượng đặt vượt tồn kho khả dụng, nhằm tránh cam kết giao hàng không khả thi.	`REQ-FUNC-SALES-012`	`AC-SALES-012-02`	`TC-SALES-012-02`	Với cùng mặt hàng, tồn kho khả dụng `100`, người dùng nhập số lượng `100`; hệ thống cho phép xác nhận đơn hàng và lưu số lượng đã đặt là `100`.	`Business / Operational`	Liên kết đầy đủ từ need đến test case; test execution evidence chưa được ghi nhận.

Quy tắc quyết định chất lượng: đánh dấu STOP — TRACEABILITY REWORK REQUIRED khi có một trong các điều kiện: REQ ID không có BN ID; AC ID không mô tả kết quả kiểm thử được; TC ID kiểm tra hành vi không thuộc acceptance criterion; kết quả mong đợi không phân biệt được pass và fail; hoặc nghĩa vụ Tier 1 bị gán mà không có nguồn chính thức và nhãn xác minh phù hợp. Chỉ khi các liên kết đầy đủ và có thể kiểm tra, dòng ma trận mới đạt điều kiện chuyển sang thiết kế hoặc thực thi kiểm thử; điều này vẫn không tạo baseline, approval hay xác nhận triển khai.

Ma trận quản trị cho template ánh xạ acceptance criteria, test case, test design và test data

Trong phần này, “traceability” phải đi theo chuỗi tối thiểu: business need → requirement → acceptance criterion → test case. Với Nova Foods, chuỗi này chỉ được dùng cho dữ liệu mô phỏng giáo dục; không được diễn giải thành phê duyệt triển khai hay baseline. Nguồn thuật ngữ kiểm thử ưu tiên theo ISTQB CTFL v4.0.1; khái niệm requirement và acceptance criterion tham chiếu ISO/IEC/IEEE 29148:2018 ở mức mô tả chung, không gán clause cụ thể khi chưa có licensed-text verification.

Template ID	Tệp đích	Owner	Consumers	Upstream artifacts	Downstream artifacts	Four-tier obligations	Nova Foods completed-example scope	Traceability IDs	Quality gate	Generation batch
`TMPL-ACM-001`	`/01-curriculum/templates/ACCEPTANCE_CRITERIA_MAPPING.md`	Senior IT Business Analyst	BA, QA, Product Owner, UAT Lead	Business need, requirement specification, business rule, process step	Test-case mapping, test design, UAT preparation	Tier 1: requirement/acceptance wording phải bám nguồn chính thức; Tier 2: quy ước viết AC của corpus; Tier 3: giả định nghiệp vụ Nova Foods; Tier 4: vấn đề chưa xác minh phải gắn `Verification required`	Dùng cho tình huống kiểm tra đơn bán hàng, tồn kho khả dụng, hạn dùng, và trạng thái xác nhận đơn ở mức mô phỏng	`BN-`, `REQ-`, `AC-*`	Mỗi AC phải quan sát được, kiểm chứng được, có điều kiện pass/fail rõ, không gộp hai hành vi khác nhau trong một dòng	`BATCH-04A`
`TMPL-TCM-001`	`/01-curriculum/templates/TEST_CASE_MAPPING.md`	QA Lead	QA, BA, UAT Lead, Dev Lead	Acceptance criteria mapping, requirement, business rule, risk note	Test design, test data, defect log, UAT evidence	Tier 1: test case phải phản ánh đúng AC; Tier 2: cấu trúc TC thống nhất; Tier 3: data giả lập Nova Foods; Tier 4: nếu cần diễn giải ngoài nguồn, ghi rõ `Verification required`	Dùng cho case đặt hàng vượt tồn kho, batch hàng cận hạn dùng, và kiểm tra phản hồi hệ thống theo trạng thái nghiệp vụ	`AC-`, `TC-`, `DEF-*`	Mỗi TC phải có precondition, steps, expected result, test oracle và khả năng map ngược về đúng AC	`BATCH-04A`
`TMPL-TDS-001`	`/01-curriculum/templates/TEST_DESIGN.md`	QA Lead	QA, BA, Dev, UAT Lead	Requirement, acceptance criteria, risk register, process flow	Test-case mapping, test data, defect log	Tier 1: kỹ thuật thiết kế test phù hợp loại kiểm thử; Tier 2: áp dụng mức chi tiết đủ để tái hiện; Tier 3: điều chỉnh theo quy trình Nova Foods; Tier 4: giả định rủi ro chưa xác minh phải tách riêng	Dùng để thiết kế nhóm test cho nghiệp vụ bán hàng, kiểm tra ràng buộc số lượng, trạng thái đơn, và hành vi dữ liệu đầu vào	`REQ-`, `AC-`, `TD-*`	Phải nêu test objective, coverage, priority, technique, boundary, negative path và dữ liệu cần thiết; không được nhầm test design với test execution record	`BATCH-04A`
`TMPL-TDT-001`	`/01-curriculum/templates/TEST_DATA.md`	Test Data Steward	QA, BA, UAT Lead, Dev, Support	Test design, data dictionary, business rule, masking rule	Test-case mapping, defect log, UAT pack	Tier 1: dữ liệu phải tối thiểu để chứng minh hành vi; Tier 2: chuẩn hóa trường dữ liệu; Tier 3: dữ liệu mô phỏng Nova Foods; Tier 4: dữ liệu liên quan cá nhân, tài chính, pháp lý phải đánh dấu `Verification required`	Dùng cho bộ dữ liệu đơn hàng, sản phẩm, kho, lô hàng, hạn dùng, và trạng thái phê duyệt giả lập	`TD-`, `TC-`, `AC-*`	Mỗi bộ data phải có mục tiêu, giá trị đầu vào, biến thể, expected result và quy tắc reset để tái chạy	`BATCH-04A`

Quy tắc quản trị bắt buộc 1. AC là tầng trung gian giữa requirement và test case; nếu một AC không chuyển hóa được thành test case kiểm chứng được thì AC đó chưa đạt chất lượng biên soạn. 2. TC chỉ được map một hoặc nhiều AC có cùng mục tiêu kiểm thử; không được gán TC cho requirement chung chung mà không có kết quả quan sát được. 3. TD phải phục vụ khả năng lặp lại, bao phủ biên và xử lý âm tính; dữ liệu “đẹp” nhưng không kiểm tra được điều kiện fail là dữ liệu chưa đủ. 4. TDS và TDT phải giữ đúng ranh giới nguồn: dữ liệu thực tế của Nova Foods không được đưa vào corpus này; chỉ dùng dữ liệu tổng hợp, đã ẩn danh, và có thể tái tạo. 5. Nếu một dòng ma trận liên quan đến quy định pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc, dòng đó phải gắn nhãn Verification required hoặc Project assumption; không được mặc định thành nghĩa vụ production. 6. Mỗi template trong ma trận phải duy trì traceability ID ổn định, không đổi tên tệp ngầm định, và không tự suy diễn sang các template UAT, change, release hoặc operations của các micro-batch sau.

Tiêu chí dừng chất lượng - Dừng và yêu cầu rà soát lại nếu thiếu một trong các cột: owner, consumers, upstream/downstream artifacts, four-tier obligations, Nova Foods completed-example scope, traceability IDs, quality gate, generation batch. - Dừng nếu BN/REQ/AC/TC không tạo thành chuỗi truy vết hợp lệ. - Dừng nếu một template kiểm thử được mô tả mà không chỉ rõ đầu ra quan sát được hoặc không thể phân biệt pass/fail. - Dừng nếu có bất kỳ nội dung nào khiến ma trận này bị hiểu nhầm là approval, baseline, hoặc hướng dẫn triển khai production.

Ma trận quản trị template Defect, UAT Preparation và UAT Sign-off Tracking

Ba template dưới đây quản lý bằng chứng ở giai đoạn xác nhận và chấp nhận giải pháp; chúng không tự tạo approval, baseline, quyết định triển khai production hoặc kết luận pháp lý. Mọi dữ liệu Nova Foods Trading & Manufacturing trong completed example là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND, trạng thái lập kế hoạch IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Template ID / filename được kiểm soát	Owner; consumers	Upstream artifacts → downstream artifacts	Nghĩa vụ bốn tầng	Phạm vi completed example Nova Foods	Traceability IDs bắt buộc	Quality gate	Generation batch
`TMPL-TEST-DEFECT-LOG` `/02-templates/testing/TMPL-TEST-DEFECT-LOG.md`	Owner: Test Lead. Consumers: QA Analyst, IT BA, Development Lead, Business Owner, Release Manager.	Test-case mapping, test design, test data, execution evidence, requirement/rule/data/API/NFR references → defect triage record, retest evidence, UAT preparation, change request khi cần kiểm soát thay đổi, release decision input.	T1: Defect ID, tiêu đề, môi trường, bước tái hiện, actual result, expected result, severity, priority, status và reporter bắt buộc có. T2: Mỗi defect liên kết ít nhất một test case và test basis ID; không suy đoán requirement. T3: Defect liên quan dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc phải gắn `Verification required` cho phần diễn giải chưa được owner có thẩm quyền xác minh. T4: Không dùng defect đã đóng làm bằng chứng UAT hoặc release nếu thiếu retest result và người ghi nhận.	Nhật ký tổng hợp cho lỗi kiểm tra luồng tạo đơn bán hàng Nova Foods; ví dụ sử dụng `REQ-FUNC-SALES-012` nếu test basis hợp lệ, không chứa khách hàng, nhân viên, lô hàng hoặc chứng từ thật.	`DEF-{DOMAIN}-{NNN}`; `TC-{DOMAIN}-{NNN}`; `REQ-{TYPE}-{DOMAIN}-{NNN}`; `BR-{DOMAIN}-{NNN}` khi áp dụng; `TD-{DOMAIN}-{NNN}`; `TDS-{DOMAIN}-{NNN}`; `EVD-{DOMAIN}-{NNN}`.	PASS: mỗi dòng có khả năng tái hiện, expected result truy được về test basis, trạng thái triage rõ, và closure có retest evidence. STOP: thiếu test basis, không phân biệt severity với priority, hoặc đóng lỗi khi chưa có kết quả retest.	`BATCH-04-02`
`TMPL-UAT-PREPARATION` `/02-templates/uat/TMPL-UAT-PREPARATION.md`	Owner: IT BA. Consumers: UAT Coordinator, Business Owner, Key User, Test Lead, Release Manager, Support Lead.	Business need, requirement, acceptance criterion, test-case mapping, defect status, test data readiness, environment readiness → UAT session plan, participant roster, scenario pack, UAT issue intake, UAT sign-off tracking.	T1: Mục tiêu UAT, scope in/out, môi trường, lịch, vai trò, entry criteria, exit criteria và kênh ghi nhận issue bắt buộc có. T2: Mỗi UAT scenario phải tham chiếu requirement, acceptance criterion và test case tương ứng; scenario không thay thế acceptance criterion. T3: Dữ liệu UAT phải là tổng hợp hoặc được đánh dấu theo phân loại dữ liệu và ràng buộc truy cập; diễn giải nghĩa vụ pháp lý giữ nhãn `Verification required` khi chưa xác minh. T4: Chỉ lập kế hoạch sẵn sàng UAT; không ghi nhận sign-off, không tuyên bố production-ready và không tự chấp nhận residual defect.	Gói chuẩn bị UAT tổng hợp cho quy trình kiểm tra tạo đơn bán hàng và xác nhận kết quả mong đợi theo requirement; người tham gia là vai trò mô phỏng, không là cá nhân thực.	`BN-{DOMAIN}-{NNN}`; `REQ-{TYPE}-{DOMAIN}-{NNN}`; `AC-{DOMAIN}-{NNN}`; `TC-{DOMAIN}-{NNN}`; `DEF-{DOMAIN}-{NNN}`; `UAT-{DOMAIN}-{NNN}`; `TDS-{DOMAIN}-{NNN}`; `ENV-{DOMAIN}-{NNN}`.	PASS: mọi scenario có chuỗi `BN → REQ → AC → TC`, entry criteria đo được, defect open được hiển thị theo trạng thái thực tế và owner của quyết định UAT được nêu rõ. STOP: thiếu acceptance criterion, thiếu dữ liệu/môi trường mô phỏng, hoặc dùng trạng thái `IN_REVIEW` như bằng chứng được chấp thuận.	`BATCH-04-02`
`TMPL-UAT-SIGN-OFF-TRACKING` `/02-templates/uat/TMPL-UAT-SIGN-OFF-TRACKING.md`	Owner: UAT Coordinator. Consumers: Business Owner, IT BA, Test Lead, Release Manager, Support Lead, Project Manager.	UAT preparation, UAT execution evidence, UAT issue register, defect log, scope/change records → decision tracking, release readiness input, operational handover input.	T1: Mỗi record có UAT ID, scope được đánh giá, kỳ kiểm thử, evidence reference, decision state, decision owner, ngày ghi nhận và residual issue list. T2: Decision state phải phân biệt rõ `Pending evidence`, `Ready for authorized decision`, `Not accepted`; template không tự ghi `Approved` nếu không có quyết định được ghi nhận bởi vai trò có thẩm quyền. T3: Residual issue liên quan dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc phải giữ nguồn tham chiếu và nhãn `Verification required` khi cần xác minh. T4: Sign-off tracking chỉ theo dõi bằng chứng và quyết định; không thay thế change request, release approval, legal/compliance sign-off hoặc production authorization.	Bảng theo dõi tổng hợp cho một đợt UAT của luồng đơn bán hàng Nova Foods, gồm kết quả scenario, defect tham chiếu và trạng thái quyết định chưa hoàn tất tại `IN_REVIEW`.	`UAT-{DOMAIN}-{NNN}`; `REQ-{TYPE}-{DOMAIN}-{NNN}`; `AC-{DOMAIN}-{NNN}`; `TC-{DOMAIN}-{NNN}`; `EVD-{DOMAIN}-{NNN}`; `DEF-{DOMAIN}-{NNN}`; `CR-{DOMAIN}-{NNN}` khi thay đổi scope hoặc requirement.	PASS: scope, evidence, residual issue và decision authority khớp nhau; không có kết luận chấp nhận ngoài evidence. STOP: thiếu evidence reference, trạng thái quyết định mơ hồ, residual defect không được nêu, hoặc claim approval không có record có thẩm quyền.	`BATCH-04-02`

Quy tắc liên kết tối thiểu: một issue ghi trong TMPL-TEST-DEFECT-LOG phải truy về TC và test basis; một scenario trong TMPL-UAT-PREPARATION phải duy trì chuỗi BN → REQ → AC → TC; một record trong TMPL-UAT-SIGN-OFF-TRACKING phải tham chiếu evidence UAT và mọi DEF còn mở. Khi chuỗi bị đứt, artifact giữ trạng thái cần làm rõ thay vì suy diễn business rule, kết quả kiểm thử hoặc quyết định chấp nhận.

Ma trận quản trị template Change Request, Release Notes và Deployment Readiness

Ba template dưới đây kiểm soát thay đổi sau khi requirement đã có test basis và trước khi đưa bản phát hành vào môi trường đích. Chúng là artifact lập kế hoạch của corpus Nova Foods, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, dùng dữ liệu tổng hợp trong bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND. Không hàng nào tạo baseline, approval, quyền triển khai production, diễn giải pháp lý hoặc cam kết vận hành.

Bốn tầng nghĩa vụ áp dụng: T1 — Cấu trúc: điền đủ trường bắt buộc và giữ định dạng/ID; T2 — Truy vết: liên kết được nhu cầu nghiệp vụ, requirement, acceptance criterion, test và thay đổi; T3 — Bằng chứng chuyên môn: có dữ liệu kiểm thử, đánh giá tác động hoặc kết quả kiểm tra phù hợp; T4 — Thẩm quyền quyết định: chỉ vai trò có thẩm quyền được ghi nhận trong artifact kiểm soát phù hợp mới được quyết định phạm vi thay đổi hay triển khai. Trường trống ở T4 không được suy diễn là đã chấp thuận.

Template ID và tệp được kiểm soát	Owner	Consumers	Upstream artifacts	Downstream artifacts	Nghĩa vụ T1–T4	Phạm vi completed example Nova Foods	Traceability IDs bắt buộc	Quality gate	Generation batch
`TMPL-CHANGE-REQUEST-001` — `/01-curriculum/templates/TMPL-CHANGE-REQUEST-001_change-request.md`	Change Control Coordinator; BA duy trì phân tích tác động	Business Owner, Product Owner, Solution Architect, QA Lead, Release Manager, Operations Lead	Business need, requirement, business rule, data/API/NFR specification; defect log hoặc UAT feedback khi là nguồn phát sinh thay đổi	Requirement cập nhật, acceptance criteria, test design/test case, release notes, deployment readiness, quyết định change control được ghi nhận riêng	T1: CR phải có `CR-{DOMAIN}-{NNN}`, loại thay đổi, lý do, phạm vi vào/ra, mức ưu tiên, tác động và trạng thái. T2: nối CR với ID nguồn và artifact bị tác động. T3: BA ghi rõ tác động nghiệp vụ, dữ liệu, tích hợp, UX, NFR, test và rollback ở mức phân tích; nội dung pháp lý/kế toán/an toàn thực phẩm chưa xác minh phải giữ `Verification required` hoặc `Project assumption`. T4: không ghi “approved” khi chưa có record quyết định của người có thẩm quyền.	Một CR mô phỏng điều chỉnh quy tắc chặn xuất kho lô có hạn dùng không đạt ngưỡng vận hành; chỉ mô tả thay đổi học tập, không suy ra nghĩa vụ pháp lý hay cấu hình ERP thực.	`CR-{DOMAIN}-{NNN}` → `BN-{DOMAIN}-{NNN}` → `REQ-{TYPE}-{DOMAIN}-{NNN}` → `AC-{DOMAIN}-{NNN}` → `TC-{DOMAIN}-{NNN}`; nếu phát sinh từ lỗi, thêm `DEF-{DOMAIN}-{NNN}`.	CR ready for control review: không thiếu nguồn phát sinh, phạm vi, tác động, lựa chọn xử lý, test impact hoặc owner quyết định; ID phải tham chiếu artifact tồn tại trong registry.	`BATCH-04-03`
`TMPL-RELEASE-NOTES-001` — `/01-curriculum/templates/TMPL-RELEASE-NOTES-001_release-notes.md`	Release Manager	Business Owner, end-user representative, Service Desk, Operations, QA, training/support team	Release scope đã được kiểm soát; CR được chọn; test summary; defect disposition; deployment readiness	Truyền thông phát hành, operational handover, runbook cập nhật, support readiness, post-release monitoring record	T1: nêu release ID, môi trường, thời điểm theo `Asia/Ho_Chi_Minh`, thay đổi có/không có, known limitations, hướng dẫn người dùng và đầu mối hỗ trợ. T2: mỗi thay đổi phải nối release với CR, requirement và test evidence liên quan. T3: mô tả tác động theo ngôn ngữ nghiệp vụ, không tuyên bố “không lỗi”, “compliant” hoặc “production-ready” nếu không có bằng chứng và thẩm quyền tương ứng. T4: trạng thái phát hành chỉ phản ánh record release decision được ghi nhận; Release Manager không thay thế thẩm quyền Business Owner hoặc Operations.	Một release note mô phỏng cho tính năng cảnh báo hạn dùng khi tạo phiếu xuất kho; gồm thay đổi thấy được, giới hạn mô phỏng và kênh Service Desk, không chứa dữ liệu khách hàng hoặc lô hàng thật.	`REL-{YYYYMMDD}-{NNN}` → `CR-{DOMAIN}-{NNN}` → `REQ-{TYPE}-{DOMAIN}-{NNN}` → `AC-{DOMAIN}-{NNN}` → `TC-{DOMAIN}-{NNN}`; tham chiếu `DEF-{DOMAIN}-{NNN}` cho known limitation còn mở.	Release communication ready: phạm vi release khớp release scope; thay đổi, giới hạn, ảnh hưởng vận hành và hướng dẫn hỗ trợ không mâu thuẫn với test summary hoặc deployment readiness; không có tuyên bố approval ngầm định.	`BATCH-04-03`
`TMPL-DEPLOYMENT-READINESS-001` — `/01-curriculum/templates/TMPL-DEPLOYMENT-READINESS-001_deployment-readiness.md`	Release Manager phối hợp Operations Lead và QA Lead	Deployment team, Operations, Service Desk, Business Owner, Solution Architect, Security/Compliance reviewer khi được phân công	Release scope; release notes draft; test summary; defect log; runbook draft; operational handover; CR tác động triển khai	Quyết định go/no-go được ghi nhận riêng, deployment execution record, rollback record, release notes phát hành, support readiness	T1: checklist phải có release/môi trường, phạm vi, dependency, migration/configuration, backup, rollback, monitoring, support contact và điều kiện dừng. T2: từng mục phải tham chiếu release, CR, test/defect hoặc runbook liên quan. T3: bằng chứng phải phân biệt “đã kiểm tra”, “chưa kiểm tra”, “không áp dụng”; mục privacy, accounting, food-safety, security chỉ được kết luận khi đúng owner có evidence, nếu không là `Verification required`. T4: checklist hoàn tất không tự tạo quyền deploy; go/no-go cần record quyết định của thẩm quyền được chỉ định.	Checklist mô phỏng triển khai cảnh báo hạn dùng cho môi trường đào tạo: kiểm tra dữ liệu tổng hợp, cấu hình ngưỡng giả định, phương án rollback cấu hình và theo dõi cảnh báo sau phát hành.	`REL-{YYYYMMDD}-{NNN}` → `CR-{DOMAIN}-{NNN}` → `REQ-{TYPE}-{DOMAIN}-{NNN}` → `AC-{DOMAIN}-{NNN}` → `TC-{DOMAIN}-{NNN}` → `DEF-{DOMAIN}-{NNN}` → `RUN-{DOMAIN}-{NNN}`.	Deployment readiness review: mọi mục critical có bằng chứng hoặc trạng thái dừng rõ; rollback khả thi trong phạm vi mô phỏng; defect severity/decision nhất quán; không còn liên kết hỏng giữa release, CR, test và runbook.	`BATCH-04-03`

Quy tắc liên kết tối thiểu: một thay đổi chỉ được đưa vào release scope khi CR chỉ ra requirement bị ảnh hưởng và requirement đó nối được tới AC và TC. Release notes chỉ truyền thông nội dung đã nằm trong release scope; deployment readiness chỉ kiểm tra điều kiện đưa scope đó vào môi trường. Nếu một liên kết thiếu, trạng thái áp dụng là STOP — traceability incomplete để bổ sung bằng chứng, không được thay bằng nhận định chủ quan hoặc xác nhận ngầm định.

Ma trận quản trị template Operational Handover, Runbook và Support Readiness

Ba template dưới đây kiểm soát bàn giao từ delivery sang vận hành cho case study Nova Foods Trading & Manufacturing. Chúng là artifact lập kế hoạch ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND; mọi dữ liệu ví dụ phải là dữ liệu tổng hợp. Không template nào tự tạo baseline, approval, production readiness, xác nhận tuân thủ pháp lý hoặc quyền triển khai.

Bốn tầng nghĩa vụ áp dụng trong từng dòng: T1 — Bắt buộc cấu trúc: trường, ID và liên kết tối thiểu phải hiện diện; T2 — Bắt buộc nội dung: thông tin phải cụ thể, kiểm chứng được và không mâu thuẫn nguồn; T3 — Điều kiện theo ngữ cảnh: chỉ bắt buộc khi phạm vi có thành phần, rủi ro hoặc tích hợp tương ứng; T4 — Xác minh/thẩm quyền: nội dung pháp lý, bảo mật, dữ liệu cá nhân, kế toán, an toàn thực phẩm và quyết định production phải được gắn Verification required hoặc Project assumption cho đến khi vai trò có thẩm quyền ghi nhận quyết định trong artifact phù hợp.

Template ID và tệp được kiểm soát	Owner; consumers	Artifact thượng nguồn → hạ nguồn	Nghĩa vụ bốn tầng	Phạm vi completed example Nova Foods	Traceability IDs bắt buộc	Quality gate	Generation batch
`TMPL-OPS-HANDOVER-001` `/templates/operations/TMPL-OPS-HANDOVER-001_operational-handover.md`	Owner: Service Transition Lead. Consumers: Operations Lead, Application Support Lead, L1/L2 Support, Release Manager, Product Owner, QA Lead.	Upstream: `REQ-`, `BR-`, `AC-`, `TC-`, `DEF-`, `CR-`, release notes, deployment-readiness record, architecture/integration specification đã được liên kết. Downstream: runbook, support-readiness assessment, service-support ticket catalogue, post-release review record.	T1: release identifier, phạm vi bàn giao, môi trường, owner nhận bàn giao, danh sách liên kết và trạng thái từng hạng mục. T2: mô tả rõ dịch vụ, luồng nghiệp vụ được hỗ trợ, điểm giám sát, kênh/escalation và bằng chứng bàn giao. T3: khi có API, job nền, tích hợp kho hoặc dữ liệu lô/hạn dùng, phải nêu dependency, lịch chạy, điểm lỗi và đầu mối xử lý. T4: không xác nhận quyền truy cập, retention, nghĩa vụ dữ liệu cá nhân, hóa đơn hoặc truy xuất thực phẩm nếu chưa có xác minh của security, legal hoặc domain owner.	Một bàn giao mô phỏng cho luồng tạo đơn bán hàng, phân bổ tồn kho theo lô và phát hành phiếu xuất kho; dùng mã đơn, lô, người dùng và endpoint tổng hợp. Không mô phỏng dữ liệu khách hàng thật, cấu hình production hoặc xác nhận sẵn sàng vận hành thực tế.	`BN-SALES-001` → `REQ-FUNC-SALES-012` → `AC-SALES-012-01` → `TC-SALES-012-01`; `REL-SALES-001`; `DEP-SALES-001`; `OPS-HO-SALES-001`.	GATE-OPS-HO-01: đạt khi mọi capability trong phạm vi release có owner vận hành nhận diện được, liên kết requirement-to-test evidence không đứt đoạn, dependency có đầu mối, và mọi khoảng trống thẩm quyền được gắn nhãn phù hợp. Dừng nếu thiếu owner nhận bàn giao, thiếu release ID hoặc có test/defect mở ảnh hưởng vận hành mà không được ghi nhận.	`BATCH-04-OPS-01`
`TMPL-OPS-RUNBOOK-001` `/templates/operations/TMPL-OPS-RUNBOOK-001_runbook.md`	Owner: Application Support Lead. Consumers: L1 Support, L2 Support, Operations Lead, on-call engineer, Service Desk, Release Manager.	Upstream: operational-handover record, deployment-readiness record, release notes, integration/API specification, known defect log, support-readiness assessment. Downstream: incident record, problem record, knowledge article, change request, post-incident review.	T1: service ID, version/release applicability, trigger, precondition, bước thao tác đánh số, expected result, rollback/escalation path và owner từng bước. T2: hướng dẫn phải tái lập được bởi support role đã xác định; phân biệt triệu chứng, nguyên nhân giả định, thao tác an toàn và evidence cần lưu. T3: khi có batch job, API timeout, đồng bộ tồn kho, lô/hạn dùng hoặc phân quyền, phải có bước kiểm tra tương ứng và ranh giới không tự sửa dữ liệu. T4: thao tác có thể tác động dữ liệu cá nhân, sổ sách, hóa đơn, truy xuất hoặc production phải ghi rõ `Verification required`; runbook không cấp quyền hay thay thế phê duyệt change.	Một runbook tổng hợp xử lý cảnh báo đồng bộ tồn kho thất bại giữa ERP và kho mô phỏng: kiểm tra mã correlation, xác định giao dịch lỗi, tạo incident và escalation. Không bao gồm mật khẩu, secret, IP thật, lệnh production hoặc quyết định điều chỉnh tồn kho.	`OPS-HO-SALES-001`; `RUN-INV-001`; `INT-WMS-001`; `DEF-INT-001`; `INC-INV-001`; `CR-OPS-001`.	GATE-RUN-01: đạt khi một L1 Support có thể xác định trigger, thực hiện bước không phá hủy, thu evidence và escalation đúng owner chỉ bằng runbook; liên kết tới handover và release còn hiệu lực phải tồn tại. Dừng nếu bước xử lý thiếu rollback/escalation, chứa secret, hoặc yêu cầu thay đổi dữ liệu không qua change control.	`BATCH-04-OPS-02`
`TMPL-OPS-SUPPORT-READINESS-001` `/templates/operations/TMPL-OPS-SUPPORT-READINESS-001_support-readiness.md`	Owner: Operations Lead. Consumers: Service Transition Lead, Application Support Lead, Release Manager, Product Owner, QA Lead, Service Desk Manager.	Upstream: operational-handover record, runbook, UAT sign-off tracking, defect log, deployment-readiness record, release notes, training/knowledge materials. Downstream: release go/no-go decision record, operational acceptance evidence, support backlog, change request, post-release review.	T1: release ID, checklist item ID, criterion, evidence reference, accountable owner, status và exception/escalation field. T2: readiness phải được đánh giá theo bằng chứng, không theo tuyên bố; nêu rõ coverage support hours, contact path, monitoring, known issues và knowledge transfer. T3: khi release có tích hợp, job định kỳ, dữ liệu lô/hạn dùng hoặc tác động giao dịch bán hàng, checklist phải kiểm tra runbook, alert ownership, reconciliation boundary và rollback communication. T4: mọi đánh giá liên quan tuân thủ pháp luật, security control, dữ liệu cá nhân, kế toán hoặc an toàn thực phẩm chỉ được ghi nhận là `Verification required` hoặc `Project assumption` nếu chưa có evidence từ owner có thẩm quyền.	Một assessment mô phỏng cho `REL-SALES-001`, kiểm tra khả năng hỗ trợ luồng đơn hàng, phân bổ lô, lỗi đồng bộ kho và escalation; trạng thái chỉ là bằng chứng lập kế hoạch, không phải quyết định go-live.	`REL-SALES-001`; `OPS-HO-SALES-001`; `RUN-INV-001`; `UAT-SALES-001`; `DEF-INT-001`; `DEP-SALES-001`; `SUP-READY-001`.	GATE-SUP-READY-01: đạt khi tất cả checklist `T1` và `T2` có evidence reference, mỗi exception có owner và đường escalation, runbook áp dụng đúng release, và defect ảnh hưởng support được liên kết. Dừng nếu không xác định được support owner, không có kênh incident, evidence không truy xuất được, hoặc exception pháp lý/bảo mật bị ghi như đã được xác nhận.	`BATCH-04-OPS-03`

Quy tắc nối chuỗi vận hành: mỗi dòng bàn giao hoặc readiness phải truy ngược được tối thiểu theo chuỗi BN-* → REQ-* → AC-* → TC-* → REL-* → OPS-HO-* → RUN-* hoặc SUP-READY-*. DEF-*, INC-* và CR-* không thay thế test evidence; chúng ghi nhận ngoại lệ, sự cố hoặc thay đổi phát sinh. Nếu một liên kết chưa tồn tại trong registry hoặc artifact nguồn chưa được kiểm soát, template phải ghi Verification required và quality gate phải dừng thay vì tự tạo bằng chứng.

AI-Assisted Governance, Four-Tier Obligations, and Completion Rules

Danh mục template cho quy trình BA có hỗ trợ AI

Các template dưới đây kiểm soát việc dùng AI như công cụ hỗ trợ phân tích, soạn nháp, kiểm tra nhất quán và tổng hợp nội dung trong corpus Nova Foods Trading & Manufacturing. AI không là Business Owner, Legal Owner, Accounting Owner, Security Owner, người phê duyệt, nguồn sự thật nghiệp vụ hoặc bằng chứng kiểm thử. Mọi dữ liệu Nova Foods trong template và completed example phải là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Template ID	Tên tệp được kiểm soát	Mục đích kiểm soát	Owner lập/duy trì	Consumer chính	Đầu ra được phép
`AI-GOV-001`	`/templates/ai-governance/AI-GOV-001_AI_ASSISTED_BA_WORKFLOW_LOG.md`	Ghi nhận một phiên làm việc BA có AI: mục tiêu, input được phép, prompt, output, kiểm tra của con người và artifact đích.	IT Business Analyst	Senior BA, QA Reviewer, Technical Lead	Nhật ký có truy vết cho draft, phân tích khoảng trống hoặc đề xuất câu hỏi làm rõ.
`AI-GOV-002`	`/templates/ai-governance/AI-GOV-002_AI_OUTPUT_REVIEW_RECORD.md`	Đánh giá độ đúng, tính đầy đủ, tính kiểm thử, ranh giới nguồn và rủi ro của output do AI tạo hoặc biến đổi.	Senior IT Business Analyst	QA Reviewer, Artifact Owner	Review record xác định nội dung được giữ, sửa, loại bỏ hoặc chuyển `Verification required`.
`AI-GOV-003`	`/templates/ai-governance/AI-GOV-003_PROMPT_AND_CONTEXT_REGISTER.md`	Quản lý prompt chuẩn, phạm vi context, mục đích sử dụng, giới hạn dữ liệu và artifact nguồn được phép đưa vào AI.	Principal IT Business Analyst / Technical Curriculum Author	IT Business Analyst, Technical Curriculum Author	Prompt đã chuẩn hóa để hỗ trợ tác vụ lặp lại, không thay thế phân tích nghiệp vụ.
`AI-GOV-004`	`/templates/ai-governance/AI-GOV-004_AI_TRACEABILITY_IMPACT_ASSESSMENT.md`	Đánh giá tác động của output AI tới chuỗi `BN-* → REQ-* → AC-* → TC-*` và các rule, data definition, API hoặc NFR liên quan.	IT Business Analyst	QA Reviewer, Technical Lead	Danh sách liên kết cần xác minh, impacted artifact và điều kiện không được hợp nhất output.
`AI-GOV-005`	`/templates/ai-governance/AI-GOV-005_AI_EXCEPTION_AND_ESCALATION_RECORD.md`	Ghi nhận trường hợp AI tạo nội dung mâu thuẫn, không truy nguyên được, chứa dữ liệu không được phép hoặc chạm ranh giới thẩm quyền.	Artifact Owner	Senior BA, Legal/Compliance Owner, Security Owner, Business Owner theo phạm vi	Exception record, quyết định phân luồng và escalation có bằng chứng.

Cấu trúc tối thiểu của các template AI governance

Template	Trường tối thiểu phải có	Ranh giới bắt buộc
`AI-GOV-001`	`AI Session ID`, ngày, người thực hiện, mục tiêu BA, artifact nguồn, loại dữ liệu input, công cụ AI, prompt reference, output reference, người kiểm tra, kết quả kiểm tra	Không ghi nhận output AI như fact nếu chưa đối chiếu artifact nguồn hoặc owner có thẩm quyền.
`AI-GOV-002`	`Review ID`, output reference, tiêu chí review, phát hiện, impacted ID, phân loại nguồn, hành động khắc phục, reviewer	Reviewer không được chuyển nội dung liên quan pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật thành kết luận xác nhận khi thiếu evidence có thẩm quyền.
`AI-GOV-003`	`Prompt ID`, mục tiêu, role mô phỏng, context được phép, context bị cấm, expected output, tiêu chí human review, version	Prompt không được yêu cầu AI bịa nguồn, bịa phát biểu người dùng, bịa điều khoản, suy đoán approval hoặc tạo dữ liệu production.
`AI-GOV-004`	`Impact Assessment ID`, output reference, ID nguồn, ID bị tác động, loại tác động, gap phát hiện, hành động xác minh, owner xác minh	AI không được tự tạo canonical ID, thay đổi nghĩa ID hiện có hoặc lấp khoảng trống traceability bằng liên kết không có artifact nguồn.
`AI-GOV-005`	`Exception ID`, thời điểm phát hiện, loại ngoại lệ, output reference, rủi ro, artifact bị ảnh hưởng, người nhận escalation, trạng thái xử lý	Exception record không phải approval, waiver, legal advice, security sign-off hoặc quyết định triển khai.

Chính sách sử dụng theo tác vụ BA

Tác vụ	Có thể dùng AI-assisted governance template khi	Không dùng AI để thay thế con người khi
Tổng hợp discovery note mô phỏng	Input chỉ gồm ghi chú tổng hợp được phép dùng; mục tiêu là tạo câu hỏi, nhóm chủ đề hoặc draft backlog.	Cần xác nhận ý định stakeholder, ưu tiên business, phạm vi quyết định hoặc cam kết delivery.
Soạn draft requirement, acceptance criterion hoặc test idea	Có requirement source, business rule source hoặc data definition source đã định danh; output được review bằng `AI-GOV-002`.	Chưa có source, có mâu thuẫn giữa nguồn, hoặc AI được yêu cầu tự suy luận rule Nova Foods.
Kiểm tra nhất quán	Cần phát hiện ID thiếu, thuật ngữ không nhất quán, liên kết traceability đứt hoặc acceptance criterion không quan sát được.	Kết quả kiểm tra được dùng như bằng chứng rằng requirement đúng, test đã pass hoặc solution sẵn sàng production.
Phân tích tài liệu pháp lý hoặc chuẩn bên ngoài	Chỉ để tạo danh sách câu hỏi xác minh và gắn nhãn `Verification required`; phải giữ URL nguồn chính thức khi có.	Cần diễn giải pháp lý, xác nhận compliance, xác định nghĩa vụ thuế/kế toán hoặc đưa ra quyết định an toàn thực phẩm.
Xử lý dữ liệu	Chỉ với dữ liệu tổng hợp Nova Foods và context đã được đăng ký trong `AI-GOV-003`.	Input chứa secret, token thật, thông tin định danh cá nhân, dữ liệu khách hàng thật, dữ liệu tài chính thật hoặc thông tin bảo mật không được phép chia sẻ.

Quy tắc vận hành và truy vết riêng cho AI-assisted use

Mỗi output AI được đưa vào artifact có kiểm soát phải có tham chiếu tối thiểu đến một AI-GOV-001 hoặc AI-GOV-002.
Mỗi fact nghiệp vụ, business rule, data definition, API contract, NFR hoặc acceptance criterion do AI đề xuất phải truy ngược về artifact nguồn đã định danh; nếu chưa truy được, nội dung chỉ được giữ dưới dạng câu hỏi phân tích hoặc nhãn Verification required.
Khi AI phát hiện hoặc đề xuất thay đổi cho một ID như BN-*, REQ-*, AC-*, BR-*, DATA-*, API-*, NFR-* hoặc TC-*, AI-GOV-004 phải ghi rõ ID nguồn, ID bị tác động và người chịu trách nhiệm xác minh. AI không có quyền cấp, đổi hoặc hủy canonical ID.
Prompt, context và output phải phân biệt rõ: nguồn đã kiểm chứng, project assumption, Verification required và nội dung AI đề xuất. Không được trộn các phân loại này trong cùng một kết luận.
Nếu output chứa mâu thuẫn với source, ngôn ngữ khẳng định approval, bằng chứng không truy xuất được, dữ liệu bị cấm hoặc kết luận vượt thẩm quyền, phải tạo AI-GOV-005 và dừng việc hợp nhất output vào artifact đích.
Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, các template AI governance là cấu phần lập kế hoạch có kiểm soát. Chúng không xác nhận AI output là đúng, không tạo baseline, không ghi nhận user approval và không cho phép sử dụng production.

Ma trận nghĩa vụ bốn tầng bắt buộc cho mọi template

Mọi template được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md phải tồn tại và được kiểm soát đồng thời ở đủ bốn tầng dưới đây. Bốn tầng là một đơn vị quản trị không thể tách rời: Tier 1 xác định template là gì và dùng để làm gì; Tier 2 cho người học và BA một cấu trúc điền thông tin; Tier 3 chứng minh cấu trúc đó có thể được hoàn thành nhất quán trong case Nova Foods; Tier 4 xác định cách Senior BA kiểm tra chất lượng trước khi template được coi là đủ điều kiện dùng làm đầu vào học tập hoặc delivery simulation. Không tầng nào tự thay thế tầng khác.

Tier	Tên bắt buộc	Mục tiêu từ nguyên lý đầu tiên	Nội dung tối thiểu phải có	Điều kiện đạt
Tier 1	Metadata & Purpose	Người dùng phải biết chính xác artifact nào đang được dùng, phạm vi quyết định nào nó hỗ trợ và không được dùng nó để kết luận điều gì.	`TMPL` ID đã đăng ký; tên template; đường dẫn tệp; status `IN_REVIEW`; version `v0.9.0`; ngày `2026-08-07`; owner; consumer; mục đích; đầu vào; đầu ra; phạm vi bao gồm; phạm vi loại trừ; dependency; phân loại nguồn.	Không có mâu thuẫn giữa ID, tên, đường dẫn, mục đích và template catalog; không diễn giải `IN_REVIEW` là baseline, approval hoặc production-ready.
Tier 2	Blank Template	Cấu trúc trống giúp BA thu thập và biểu diễn thông tin nhất quán, thay vì viết tự do và bỏ sót dữ liệu quyết định.	Các section, trường, bảng, quy tắc điền, định dạng ID, trạng thái, trường owner, nguồn, giả định, câu hỏi cần xác minh và liên kết traceability phù hợp với loại template.	Mỗi trường có nhãn, kiểu thông tin mong đợi và điều kiện điền rõ; không chứa dữ liệu Nova Foods đã hoàn thành; không che giấu trường bắt buộc bằng văn bản hướng dẫn chung chung.
Tier 3	Fully Completed Simulated Case Artifact	Ví dụ hoàn chỉnh cho thấy Tier 2 được áp dụng vào một tình huống có logic nghiệp vụ, ngoại lệ, nguồn và truy vết kiểm tra được.	Một artifact Nova Foods Trading & Manufacturing hoàn chỉnh dùng dữ liệu tổng hợp; tất cả trường bắt buộc của Tier 2 được điền; ID, thực thể, quy trình, rule và tham chiếu nhất quán với nguồn canonical áp dụng.	Không còn ô trống ở trường bắt buộc; mọi nội dung chưa xác minh được gắn đúng nhãn; ví dụ không tự tạo approval, quyết định pháp lý, cấu hình production hoặc dữ liệu thực tế.
Tier 4	Senior BA Quality Gate	Chất lượng không chỉ là “đã điền đủ”; Senior BA phải kiểm tra tính rõ ràng, nhất quán, kiểm chứng được và khả năng chuyển giao sang artifact kế tiếp.	Checklist có tiêu chí pass/fail; bằng chứng kiểm tra; lỗi phát hiện; hành động sửa; người thực hiện review; ngày review; kết quả `PASS`, `FAIL` hoặc `CONDITIONAL PASS`; liên kết tới Tier 1–3.	`PASS` chỉ khi toàn bộ tiêu chí bắt buộc có evidence và không có lỗi chặn; `CONDITIONAL PASS` không phải approval, baseline hay cho phép production.

Quy tắc áp dụng và quan hệ giữa các tầng

Một template chỉ được ghi là đủ bộ bốn tầng khi Tier 1, Tier 2, Tier 3 và Tier 4 cùng tham chiếu một TMPL ID duy nhất. Không được dùng một blank template chung chung để đại diện cho nhiều TMPL ID có mục đích hoặc output khác nhau.
Tier 1 phải được tạo trước Tier 2 vì cấu trúc blank template cần xuất phát từ mục đích, consumer, input và output đã xác định. Tier 3 chỉ được tạo từ Tier 2 tương ứng, không được viết một case example có cấu trúc khác rồi gọi là completed example của template.
Tier 4 phải kiểm tra cả nội dung và liên kết: metadata Tier 1 có đúng; trường Tier 2 có thể điền; dữ liệu Tier 3 có hoàn chỉnh và nhất quán; traceability có chỉ tới nguồn hoặc artifact liên quan hay không.
Nếu Tier 3 phát hiện một trường Tier 2 không thể điền mà không suy đoán, phải sửa Tier 2 và cập nhật Tier 1 nếu thay đổi làm lệch mục đích, input hoặc output. Không được lấp khoảng trống bằng dữ kiện được trình bày như sự thật Nova Foods.
Nếu Tier 4 phát hiện lỗi chặn, kết quả phải là FAIL. Lỗi chặn gồm: sai hoặc thiếu TMPL ID; thiếu trường bắt buộc; mâu thuẫn với canonical ID hoặc source classification; khẳng định approval không có record; trình bày giả định như fact; hoặc dùng ví dụ mô phỏng như dữ liệu vận hành thực tế.
Mỗi Tier 3 phải nêu rõ đây là Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh khi có dữ liệu thời gian, và VND khi có giá trị tiền tệ. Không được suy diễn rằng case artifact mô tả ERP, khách hàng, nhân sự, giao dịch hoặc chính sách có thật.
Status áp dụng cho bộ template hiện hành là IN_REVIEW, version v0.9.0, ngày 2026-08-07. Hoàn thành Tier 4 chỉ là bằng chứng quality-gate trong phạm vi review; không tạo baseline reference, approval reference, legal sign-off, accounting sign-off hoặc production authorization.

Ví dụ kiểm tra tính đầy đủ của một bộ template

Điểm kiểm tra	Evidence cần thấy	Kết quả nếu thiếu
Nhận diện	Cùng một `TMPL` ID xuất hiện tại Tier 1, Tier 2, Tier 3 và Tier 4.	`FAIL` vì không chứng minh được bốn artifact thuộc cùng một template.
Khả năng sử dụng	Tier 2 có trường hướng dẫn đủ để một BA khác điền mà không phải tự đoán cấu trúc.	`FAIL` hoặc yêu cầu sửa Tier 2.
Khả năng học từ case	Tier 3 điền toàn bộ trường bắt buộc, bao gồm ngoại lệ hoặc ghi nhận rõ rằng ngoại lệ không thuộc phạm vi template.	`FAIL` nếu case bỏ qua trường bắt buộc hoặc thay đổi cấu trúc Tier 2.
Kiểm tra senior	Tier 4 có tiêu chí, evidence và kết quả cụ thể cho từng tiêu chí.	`FAIL` nếu chỉ có nhận xét tổng quát như “đã kiểm tra”.
Ranh giới thẩm quyền	Tier 3 và Tier 4 không tuyên bố requirement được phê duyệt, nghĩa vụ pháp lý đã xác nhận hoặc sẵn sàng production.	`FAIL` và phải sửa ngôn ngữ kiểm soát.

Một template thiếu bất kỳ Tier nào được phân loại là chưa hoàn chỉnh trong template library. Nó có thể được giữ ở trạng thái IN_REVIEW để tiếp tục soạn thảo, nhưng không được mô tả là template delivery-ready, completed simulated case, hoặc đã qua Senior BA quality gate.

Quy tắc Placeholder Chưa Giải Quyết, Token Bí Mật An Toàn và Nội Dung Không Được Bỏ Trống

Placeholder tồn tại để biểu thị thông tin chưa có bằng chứng, không phải để che giấu quyết định thiếu, suy đoán bằng AI, hoặc chuyển trách nhiệm xác minh sang người đọc. Mọi placeholder phải có cấu trúc, lý do, owner xử lý và hành động tiếp theo có thể kiểm tra. Không được dùng placeholder như một giá trị nghiệp vụ, giá trị cấu hình ERP, điều khoản pháp lý, xác nhận tuân thủ hoặc kết quả đã được phê duyệt.

Loại thông tin chưa hoàn tất	Cú pháp được phép	Nội dung bắt buộc trong cú pháp	Cách xử lý
Câu hỏi cần quyết định	`[OPEN-QUESTION: nội dung câu hỏi]`	Câu hỏi đơn nghĩa, vai trò cần trả lời và artifact bị ảnh hưởng	Giữ nguyên trong lúc `IN_REVIEW`; không chuyển thành fact hoặc requirement.
Giả định mô phỏng	`[PROJECT-ASSUMPTION: nội dung giả định]`	Phạm vi giả định, tác động nếu sai và nhãn dữ liệu tổng hợp	Không mô tả là quy trình thực tế hoặc cấu hình production của Nova Foods.
Nội dung cần xác minh	`[VERIFICATION-REQUIRED: nội dung cần kiểm chứng]`	Nguồn cần kiểm tra, loại nguồn và vai trò có thẩm quyền xác minh	Không suy diễn kết luận pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật trước xác minh.
Giá trị chưa được cung cấp	`[VALUE-PENDING: tên trường]`	Tên trường, lý do thiếu và nơi nhận giá trị	Không để ô bắt buộc trống và không tự sinh giá trị bằng AI.

Các token bí mật chỉ được dùng để thể hiện tham chiếu an toàn, tuyệt đối không chứa bí mật thật, thông tin định danh cá nhân, khóa API, mật khẩu, chuỗi kết nối, cookie phiên, chữ ký số hoặc dữ liệu truy cập môi trường. Cú pháp chuẩn là ${SECRET_REF:ten-tham-chieu} hoặc ${ENV_REF:ten-bien-moi-truong}. Ví dụ hợp lệ: ${SECRET_REF:novafoods-erp-api-credential}. Ví dụ này chỉ là nhãn mô phỏng, không chứng minh secret tồn tại, không cho phép truy cập, và không được dùng làm cấu hình triển khai.

Quy tắc kiểm soát	Được phép	Không được phép
Giá trị secret	Tham chiếu token an toàn không tiết lộ giá trị	Ghi trực tiếp mật khẩu, khóa, token truy cập hoặc chuỗi kết nối
Dữ liệu Nova Foods	Dữ liệu tổng hợp, nhận diện rõ là mô phỏng giáo dục	Dữ liệu khách hàng, nhà cung cấp, nhân viên hoặc vận hành thực tế
Trường bắt buộc	Điền giá trị, hoặc dùng một placeholder có cấu trúc thuộc bảng trên	Để trống, dùng ký tự thay thế không có nghĩa, hoặc xóa hàng bắt buộc
Nguồn và căn cứ	Ghi đúng phân loại `Verified primary source`, `Project assumption` hoặc `Verification required`	Gán nguồn không tồn tại, trích dẫn không kiểm chứng, hoặc biến suy luận AI thành nguồn
Ngoại lệ	Nêu điều kiện, phạm vi và tác động của ngoại lệ	Ghi “áp dụng tương tự”, “theo thông lệ”, hoặc bỏ qua trường hợp lỗi và ngoại lệ

Nghiêm cấm bỏ hàng, cột, trường kiểm soát, điều kiện đầu vào, kết quả mong đợi, ngoại lệ, nguồn, owner hoặc trạng thái chỉ để làm artifact ngắn hơn. Nếu cấu trúc mẫu không áp dụng, phải ghi rõ [PROJECT-ASSUMPTION: trường không áp dụng cho phạm vi mô phỏng hiện tại] và nêu lý do; không được ghi nhận như một kết luận đã xác minh. Nội dung do AI tạo chỉ là bản nháp có kiểm soát: AI không được tự đóng placeholder, tự thay token tham chiếu bằng secret, tự gán nguồn, hoặc tự tuyên bố nội dung đã hoàn tất.

Phạm vi ví dụ Nova Foods hoàn chỉnh cho Tier 3

Tier 3 — Fully Completed Simulated Case Artifact là bản điền hoàn chỉnh của đúng một template, sử dụng case study Nova Foods Trading & Manufacturing để chứng minh cách một Business Analyst chuyển đầu vào mô phỏng thành artifact có thể đọc, rà soát và truy vết. Tier 3 phục vụ đào tạo; không phải hồ sơ vận hành thực tế, không phải cấu hình ERP, không tạo quyết định nghiệp vụ, không xác lập baseline và không chứng minh approval.

Quy tắc phạm vi	Yêu cầu bắt buộc cho Tier 3	Ranh giới không được vượt
Bối cảnh case	Dùng duy nhất tên Nova Foods Trading & Manufacturing; mô tả rõ module hoặc luồng liên quan như bán hàng, mua hàng, tồn kho, kho vận, sản xuất, chất lượng hoặc tài chính.	Không gán Nova Foods là doanh nghiệp có thật, khách hàng thật, hệ thống đang vận hành hoặc tổ chức đã xác nhận nội dung.
Dữ liệu	Mọi tên cá nhân, mã khách hàng, mã nhà cung cấp, lô hàng, số đơn, giá trị `VND`, ngày giao dịch, SKU, địa chỉ, email và số điện thoại phải là dữ liệu tổng hợp.	Không sao chép, suy diễn hoặc tái tạo dữ liệu cá nhân, bí mật thương mại, thông tin tài khoản, token, khóa truy cập hoặc dữ liệu production.
Mức độ hoàn chỉnh	Điền mọi trường bắt buộc của template bằng giá trị mô phỏng cụ thể, nhất quán và có thể kiểm tra trong nội bộ artifact. Ví dụ có thể nêu `REQ-FUNC-SALES-012` khi template cần liên kết requirement.	Không để trường bắt buộc ở dạng khoảng trống, ký hiệu thay thế chưa xử lý, nhận xét mơ hồ hoặc nội dung yêu cầu người đọc tự hoàn thiện.
Quan hệ nguồn	Nêu rõ đầu vào là scenario mô phỏng, `Project assumption`, `Verification required`, business rule, data definition hoặc requirement theo đúng phân loại đang có.	Không chuyển giả định thành fact, không biến tài liệu đào tạo thành nguồn pháp lý, và không gán tham chiếu điều khoản khi chưa xác minh licensed text hoặc nguồn chính thức phù hợp.
Khả năng rà soát	Kết quả, ngoại lệ, điều kiện biên, tác động dữ liệu và liên kết traceability phải đủ cụ thể để Senior BA hoặc QA Reviewer có thể kiểm tra logic.	Không dùng kết luận như “đúng”, “tuân thủ” hoặc “sẵn sàng production” nếu artifact không có bằng chứng và thẩm quyền tương ứng.
Thời điểm và trạng thái	Ví dụ Tier 3 phải phản ánh bối cảnh quản trị `IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, `vi-VN`, `Asia/Ho_Chi_Minh` và `VND` khi các trường đó xuất hiện trong template.	Không ghi hoặc ngụ ý `APPROVED`, `BASELINED`, production-ready hay user-approved.

Kịch bản tối thiểu phải tự nhất quán

Một Tier 3 hợp lệ phải xoay quanh một lát cắt nghiệp vụ có giới hạn, thay vì cố mô phỏng toàn bộ ERP. Lát cắt được chọn phải xác định được: sự kiện khởi phát, tác nhân, thực thể nghiệp vụ, quyết định hoặc quy tắc áp dụng, kết quả mong đợi và ngoại lệ chính. Ví dụ, artifact về yêu cầu bán hàng có thể mô phỏng việc tạo đơn bán cho khách hàng tổng hợp CUS-NF-018, kiểm tra tồn kho khả dụng của SKU tổng hợp SKU-NF-CHILI-500G, và xử lý trường hợp số lượng yêu cầu vượt tồn kho khả dụng. Ví dụ này chỉ là tình huống học tập; nó không xác nhận chính sách phân bổ tồn kho thực tế của Nova Foods.

Thành phần của lát cắt	Nội dung Tier 3 phải thể hiện	Ví dụ giới hạn hợp lệ
Sự kiện khởi phát	Điều gì bắt đầu luồng và dữ liệu đầu vào nào được nhận	Nhân viên kinh doanh nhập yêu cầu đặt 120 đơn vị `SKU-NF-CHILI-500G`.
Quyết định nghiệp vụ	Điều kiện nào dẫn tới nhánh xử lý	Hệ thống so sánh số lượng yêu cầu với tồn kho khả dụng mô phỏng.
Kết quả chính	Trạng thái hoặc đầu ra quan sát được	Đơn được tạo ở trạng thái chờ xác nhận khi tồn kho khả dụng đáp ứng.
Ngoại lệ	Trường hợp không đi theo kết quả chính	Khi tồn kho khả dụng thấp hơn 120 đơn vị, hệ thống hiển thị số lượng khả dụng và không tự cam kết ngày giao.
Nhãn xác minh	Nội dung nào chưa có nguồn xác nhận phù hợp	Chính sách ưu tiên phân bổ tồn kho được ghi `Project assumption` nếu chưa có Business Owner xác nhận.

Quy tắc về độ sâu và liên kết chéo

Tier 3 chỉ hoàn chỉnh trong phạm vi template đang minh họa. Một Business Requirements Document mô phỏng có thể tham chiếu artifact quy trình, data dictionary, business rule và test case dự kiến, nhưng không được thay thế toàn bộ nội dung chi tiết của các artifact đó.
Mỗi ID được dùng phải giữ nguyên định dạng canonical đã được cấp bởi artifact registry phù hợp. Nếu chưa có ID canonical cho một đối tượng, Tier 3 phải mô tả đối tượng bằng tên mô phỏng có kiểm soát và ghi Verification required cho việc cấp ID; không tự tạo ID có vẻ chính thức.
Khi ví dụ đụng tới dữ liệu cá nhân, hóa đơn, kế toán, thuế, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật, nội dung chỉ được mô tả như bối cảnh mô phỏng. Yêu cầu hoặc diễn giải chưa được kiểm chứng phải mang nhãn Verification required hoặc Project assumption.
Giá trị tiền tệ mô phỏng phải dùng VND; ngày phải rõ ràng theo định dạng YYYY-MM-DD; không dùng dữ liệu thời gian ngụ ý hoặc không xác định.
Một Tier 3 hoàn chỉnh phải cho phép đối chiếu ngược từ kết quả trong template tới scenario và đầu vào đã nêu. Nếu kết quả không giải thích được bằng dữ liệu, quy tắc hoặc giả định được ghi nhận, artifact không đạt phạm vi Tier 3.

Chính sách sử dụng và không sử dụng template quản trị hỗ trợ AI

Template quản trị hỗ trợ AI chỉ được dùng khi AI tham gia tạo, biến đổi, tóm tắt, phân loại, đối chiếu hoặc rà soát bản nháp artifact BA cho case study Nova Foods Trading & Manufacturing. Mục tiêu là làm rõ phạm vi hỗ trợ, giới hạn đầu ra và phần việc còn thuộc phán đoán của con người; không phải để biến đầu ra AI thành requirement, quyết định nghiệp vụ, kết luận pháp lý hoặc bằng chứng phê duyệt. Mọi dữ liệu đưa vào AI trong corpus này phải là dữ liệu tổng hợp, phù hợp bối cảnh vi-VN, Asia/Ho_Chi_Minh và VND.

Tình huống công việc	Có dùng template quản trị AI?	Cách dùng được phép	Ranh giới bắt buộc
Tạo dàn ý workshop, câu hỏi discovery hoặc danh sách giả định cho Nova Foods	Có	Ghi nhận AI là nguồn hỗ trợ tạo bản nháp để BA chọn lọc và chỉnh sửa.	Không trình bày giả định do AI sinh ra như fact đã được Business Owner xác nhận.
Tóm tắt nội dung do nhóm dự án đã cung cấp trong dữ liệu mô phỏng	Có	Dùng để tạo bản tóm tắt, nhóm chủ đề hoặc phát hiện điểm chưa rõ.	BA phải đối chiếu với nguồn đầu vào; bản tóm tắt không thay thế nguồn gốc.
Đề xuất cấu trúc requirement, acceptance criteria, test idea hoặc câu hỏi ngoại lệ	Có	Dùng như phương án khởi đầu cho BA phân tích.	Không gán ID canonical, không tự xác lập priority, phạm vi hay quyết định nghiệp vụ từ đề xuất AI.
So sánh tính nhất quán ngôn ngữ giữa các bản nháp artifact	Có	Dùng để phát hiện thuật ngữ khác nhau, câu mơ hồ hoặc liên kết có khả năng thiếu.	Kết quả là tín hiệu rà soát, không phải kết luận kiểm soát cuối cùng.
Soạn nội dung liên quan dữ liệu cá nhân, thuế, kế toán, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc	Chỉ dùng có điều kiện	AI có thể hỗ trợ lập danh sách câu hỏi xác minh hoặc diễn đạt nhãn `Verification required` và `Project assumption`.	Không dùng AI để diễn giải luật, xác nhận tuân thủ, kết luận nghĩa vụ hoặc thay thế xác minh từ nguồn chính thức và vai trò có thẩm quyền.
Đưa secret, mật khẩu, API key, token truy cập, dữ liệu cá nhân thật hoặc dữ liệu vận hành thật vào prompt	Không	Không nhập, không đính kèm, không chuyển đổi định dạng để đưa vào AI.	Chỉ dùng token an toàn và dữ liệu tổng hợp theo quy tắc corpus.
Quyết định baseline, approval, sign-off, release readiness hoặc production deployment	Không	Không dùng template AI để tạo, suy diễn hoặc xác nhận quyết định này.	`IN_REVIEW` tại `v0.9.0` ngày `2026-08-07` không phải approval, baseline hoặc production readiness.
Thay thế phỏng vấn stakeholder, xác nhận nghiệp vụ, kiểm thử thực tế hoặc review chuyên môn	Không	AI chỉ hỗ trợ chuẩn bị và rà soát bản nháp.	AI không phải stakeholder, Business Owner, Legal Owner, Accounting Owner, QA Reviewer hoặc người phê duyệt.

Quy tắc quyết định sử dụng: dùng template quản trị AI khi cả ba điều kiện đều đúng: (1) đầu vào là dữ liệu tổng hợp hoặc thông tin đã được phép dùng trong corpus; (2) đầu ra chỉ phục vụ phân tích, soạn thảo hoặc rà soát; và (3) một người có trách nhiệm chuyên môn vẫn thực hiện phán đoán, kiểm tra và quyết định cuối cùng. Nếu một điều kiện không đúng, không dùng template quản trị AI cho hoạt động đó.

Quy tắc diễn giải đầu ra: mọi nội dung AI tạo ra là đề xuất có thể sai, thiếu bối cảnh hoặc không còn phù hợp sau khi nguồn đầu vào thay đổi. Nội dung có tác động pháp lý, kế toán, thuế, bảo mật, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải giữ nhãn Verification required hoặc Project assumption khi chưa được xác minh theo nguồn và thẩm quyền phù hợp.

Định nghĩa Owner và Consumer cho Template Quản trị AI

Trong thư viện template, Owner là vai trò chịu trách nhiệm duy trì tính đúng đắn về cấu trúc, phạm vi sử dụng, phiên bản và hướng dẫn điền của một template quản trị AI. Consumer là vai trò sử dụng template như đầu vào hoặc bằng chứng làm việc, nhưng không vì thế có quyền thay đổi cấu trúc kiểm soát, suy diễn phê duyệt, hoặc biến nội dung AI tạo sinh thành quyết định có hiệu lực.

Vai trò	Phân loại	Trách nhiệm bắt buộc	Quyền hạn và giới hạn
Principal IT Business Analyst / Technical Curriculum Author	Owner thư viện template	Duy trì danh mục, định danh, tên tệp, hướng dẫn sử dụng và lịch sử thay đổi của template quản trị AI trong `/01-curriculum/TEMPLATE_MANIFEST.md`.	Được điều phối sửa đổi nội dung template; không có quyền tự ghi nhận approval, baseline, legal sign-off, quyết định kế toán hoặc cho phép sử dụng production.
Senior BA được phân công cho artifact	Owner nội dung instance	Bảo đảm instance dùng đúng mục đích, mô tả rõ đầu vào, đầu ra, giả định, giới hạn AI và người chịu trách nhiệm kiểm tra nội dung nghiệp vụ.	Không được trình bày bản nháp do AI hỗ trợ là xác nhận của Business Owner, Legal Owner hoặc người dùng.
Business Owner Nova Foods	Consumer nghiệp vụ và nguồn phản hồi	Dùng template để xem xét bối cảnh nghiệp vụ mô phỏng, thuật ngữ vận hành, lựa chọn quy trình và câu hỏi cần làm rõ.	Chỉ phản hồi hoặc đưa quyết định khi quyết định được ghi nhận trong artifact kiểm soát phù hợp; việc đọc hoặc nhận bản AI tạo sinh không tạo approval ngầm định.
Solution Architect / Technical Lead	Consumer kỹ thuật	Dùng nội dung đã được BA kiểm tra để đánh giá khả thi kỹ thuật, boundary tích hợp, dữ liệu và tác động kiến trúc.	Không chịu trách nhiệm xác nhận ý nghĩa nghiệp vụ, pháp lý hoặc kế toán chỉ từ nội dung AI hỗ trợ.
QA Reviewer	Consumer kiểm thử và khả năng kiểm chứng	Dùng artifact để nhận diện điều kiện chưa quan sát được, mâu thuẫn, thiếu test basis hoặc ngôn ngữ không thể kiểm thử.	Không được thay thế Business Owner để quyết định ưu tiên nghiệp vụ hoặc Legal Owner để diễn giải nghĩa vụ pháp lý.
Legal/Compliance Owner	Consumer chuyên môn có thẩm quyền theo phạm vi	Xem xét nội dung có liên quan dữ liệu cá nhân, pháp lý hoặc compliance khi artifact yêu cầu xác minh chuyên môn.	Nội dung AI không phải ý kiến pháp lý. Khi chưa có xác minh phù hợp, nội dung phải giữ nhãn `Verification required` hoặc `Project assumption`.
Data Owner / Security Owner	Consumer kiểm soát dữ liệu	Đánh giá việc dùng dữ liệu mô phỏng, phân loại dữ liệu, token an toàn và nguy cơ đưa dữ liệu không phù hợp vào công cụ AI.	Không cho phép đưa dữ liệu thật, bí mật, thông tin định danh cá nhân hoặc thông tin xác thực vào prompt chỉ vì template có trường nhập liệu.
Learner / Junior BA	Consumer học tập	Dùng blank template và ví dụ Nova Foods tổng hợp để thực hành đặt câu hỏi, cấu trúc hóa kết quả và nhận diện giới hạn AI.	Không được dùng output AI làm bằng chứng rằng requirement, rule, thiết kế hoặc quyết định đã được xác nhận.

Quy tắc phân định trách nhiệm

Mỗi instance template quản trị AI phải chỉ định đúng một Owner nội dung instance; nếu chưa xác định được vai trò này, instance chỉ được xem là bản nháp học tập và không được dùng làm đầu vào quyết định.
Một Consumer có thể phản hồi, phát hiện lỗi hoặc yêu cầu làm rõ, nhưng không được sửa trạng thái kiểm soát, phiên bản hoặc kết luận của Owner mà không có ghi nhận thay đổi phù hợp.
AI là công cụ hỗ trợ soạn thảo, tổng hợp hoặc kiểm tra cấu trúc; AI không thể là Owner, Consumer có thẩm quyền, người phê duyệt, nguồn nghiệp vụ gốc hay chủ thể chịu trách nhiệm.
Với Nova Foods Trading & Manufacturing, mọi Consumer phải hiểu rằng tên tổ chức, dữ liệu, quy trình và tình huống chỉ là mô phỏng giáo dục bằng dữ liệu tổng hợp tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07.
Khi trách nhiệm giữa BA, Business Owner, Legal/Compliance Owner và Technical Lead chồng lấn, Owner template phải tách rõ câu hỏi theo phạm vi: nghiệp vụ cho Business Owner, kỹ thuật cho Technical Lead, pháp lý/compliance cho vai trò có thẩm quyền. Không chuyển một câu trả lời AI thành kết luận thay cho bất kỳ vai trò nào trong các vai trò này.

Truy vết và Cổng Chất lượng dành riêng cho Sử dụng AI Hỗ trợ BA

Mọi nội dung được AI hỗ trợ trong corpus Nova Foods phải có thể truy ngược từ đầu ra về đúng đầu vào, phạm vi lệnh, nguồn tham chiếu và quyết định xác minh của con người. AI là công cụ hỗ trợ tạo bản nháp, phân tích cấu trúc hoặc phát hiện điểm thiếu; AI không là nguồn thẩm quyền cho requirement, business rule, diễn giải pháp lý, quyết định kế toán, xác nhận an toàn thực phẩm, sign-off kiểm thử hoặc quyết định production.

Điểm truy vết bắt buộc	Nội dung phải ghi trong artifact có AI hỗ trợ	Quy tắc kiểm soát
Nhận diện đầu ra	Artifact ID, đường dẫn tệp, version hiện hành, section hoặc ID dòng bị ảnh hưởng	Không được gán AI output vào artifact không xác định được vị trí thay đổi.
Mục đích AI	Tác vụ cụ thể, ví dụ: rà soát tính đầy đủ của acceptance criteria hoặc đối chiếu liên kết requirement đến test basis	Không dùng mô tả chung như “AI hỗ trợ phân tích”.
Đầu vào được phép	Danh sách ID, nội dung tổng hợp, nguồn chính thức hoặc project assumption đã được cung cấp cho tác vụ	Chỉ dữ liệu tổng hợp Nova Foods được đưa vào luồng AI của corpus.
Phân loại nguồn	`Verified primary source`, `Project assumption`, `Verification required`, hoặc nội dung do AI đề xuất	AI không được nâng cấp phân loại nguồn. Nội dung AI đề xuất mặc định chưa được xác minh.
Dấu vết biến đổi	Liên kết từ đầu vào → AI output → chỉnh sửa của BA → artifact đích	Nếu BA thay đổi đáng kể AI output, phải mô tả phần thay đổi và lý do chuyên môn.
Người chịu trách nhiệm rà soát	Vai trò reviewer phù hợp: Senior BA, QA Reviewer, Business Owner, Legal Owner, Accounting Owner, Security Owner hoặc Domain Owner	Việc ghi tên vai trò rà soát không phải approval và không thay thế quyết định có thẩm quyền được ghi nhận riêng.
Kết quả cổng chất lượng	`PASS FOR REVIEW`, `REWORK REQUIRED`, hoặc `STOP — ESCALATION REQUIRED`	Không dùng trạng thái này để suy diễn `APPROVED`, `BASELINED` hoặc production-ready.

Chuỗi truy vết tối thiểu cho mỗi phát hiện hoặc đề xuất có AI hỗ trợ là:

Nguồn/đầu vào được phân loại → AI-assisted finding → ID requirement/rule/data/test bị tác động → đánh giá của BA → evidence kiểm tra → quyết định cổng chất lượng

Ví dụ mô phỏng hợp lệ: AI phát hiện REQ-FUNC-SALES-012 có acceptance criterion chưa nêu xử lý khi số lượng giao vượt số lượng đặt. BA ghi nhận phát hiện này là nội dung do AI đề xuất, đối chiếu với business rule hoặc project assumption liên quan, bổ sung câu hỏi cần xác minh thay vì tự tạo quy tắc Nova Foods. Nếu chưa có nguồn nghiệp vụ xác nhận, kết quả phải là REWORK REQUIRED hoặc STOP — ESCALATION REQUIRED; không được chuyển đề xuất thành requirement đã xác nhận.

Tiêu chí quality gate AI-assisted	Evidence tối thiểu	Điều kiện đạt
Tính xác định đầu vào	ID artifact nguồn, version, phạm vi section và phân loại nguồn	Reviewer xác định được AI đã dựa trên nội dung nào và nội dung nào không thuộc phạm vi.
Tính đúng nguồn	URL nguồn chính thức hoặc nhãn `Project assumption`/`Verification required` còn nguyên vẹn	Không có trích dẫn, điều khoản, quyết định hoặc sự kiện được AI tạo ra nhưng không có nguồn kiểm chứng.
Tính toàn vẹn ID	Canonical ID của requirement, rule, data element, test case hoặc change request được giữ nguyên	Không đổi, tái sử dụng hoặc tạo ID giống ID hiện hữu chỉ để làm AI output có vẻ hoàn chỉnh.
Tính kiểm thử được	Requirement hoặc acceptance criterion sau rà soát có expected result, điều kiện và ngoại lệ đủ rõ	QA Reviewer có thể xác định test basis mà không suy đoán ý định của AI.
Tính an toàn dữ liệu	Không có bí mật, token thật, thông tin định danh cá nhân thật, thông tin khách hàng thật hoặc dữ liệu production	Ví dụ secret chỉ dùng token an toàn như `{{API_KEY_NOT_PROVIDED}}`; token này không được xem là giá trị cấu hình.
Ranh giới thẩm quyền	Nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm và bảo mật được chuyển đúng owner khi cần	AI output không được dùng làm kết luận chuyên môn hoặc bằng chứng compliance.
Khả năng tái kiểm	Reviewer tái hiện được logic kiểm tra từ input, finding và evidence đã lưu	Không có kết luận “đã kiểm tra” nhưng thiếu artifact nguồn, kết quả kiểm tra hoặc người chịu trách nhiệm rà soát.

Áp dụng quy tắc dừng bắt buộc khi AI output: mâu thuẫn với canonical business rule hoặc data dictionary; đưa ra nghĩa vụ pháp lý không được xác minh từ nguồn chính thức; chứa hoặc yêu cầu secret thật; che giấu placeholder chưa xử lý; hoặc làm đứt liên kết từ requirement tới acceptance criterion và test evidence. Trong trạng thái STOP — ESCALATION REQUIRED, BA chỉ được ghi nhận vấn đề, bảo toàn source classification và chuyển tới owner có thẩm quyền; không được tự thay thế khoảng trống bằng kết luận do AI sinh ra.

Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, mọi quality-gate record AI-assisted chỉ là bằng chứng review có kiểm soát cho corpus mô phỏng Nova Foods Trading & Manufacturing. Record đó không xác nhận approval của người dùng, không tạo baseline, và không cho phép sử dụng nội dung trong production.

Cross-File Consistency Checks, Self-Review, Open Issues, and Escalation

Ma trận kiểm tra liên tệp trước khi soạn Template Library

Mục tiêu của kiểm tra liên tệp là bảo đảm /01-curriculum/TEMPLATE_MANIFEST.md kế thừa đúng cấu trúc curriculum, chapter, năng lực, ID, business rule và data definition đã được kiểm soát; không tự tạo nguồn chân lý cạnh tranh. Tại ngày 2026-08-07, mọi artifact đối chiếu đều phải được hiểu theo Status: IN_REVIEW, Version: v0.9.0; kết quả khớp chỉ xác nhận tính nhất quán kế hoạch, không tạo baseline, approval hoặc xác nhận sẵn sàng production.

Tệp nguồn bắt buộc	Nội dung phải đối chiếu	Điều kiện đạt	Xử lý khi không khớp
`/01-curriculum/01_CURRICULUM_ARCHITECTURE.md`	Trình tự năng lực, dependency giữa handbook, template library, testing mini-book, traceability và Nova Foods running case	Mỗi nhóm template phục vụ một bước học hoặc handoff đã có trong kiến trúc; không đặt template testing trước test basis gồm requirement, rule, data và acceptance criterion	Dừng việc lập kế hoạch template bị ảnh hưởng; ghi nhận mâu thuẫn nguồn và chỉ sửa sau khi xác định artifact nào là nguồn kiểm soát cho quyết định đó
`/01-curriculum/CHAPTER_MANIFEST.md`	Phạm vi chính xác 26 handbook chapter, tên tệp từ `00-foundations.md` đến `25-ai-assisted-ba-workflow.md`, chapter dependency và ranh giới nội dung	Template được liên kết với chapter có nhu cầu sử dụng hợp lý; không tạo chapter thứ 27, không đổi filename chapter, không biến template thành handbook chapter	Giữ nguyên filename và phạm vi chapter; chuyển đề xuất thay đổi cấu trúc sang quản trị `CHAPTER_MANIFEST` thay vì tự sửa trong template manifest
`/01-curriculum/COMPETENCY_COVERAGE_MATRIX.md`	Competency, capability gate, evidence quan sát được và coverage của template	Mỗi template dự kiến có mục đích năng lực phân biệt được; template không tuyên bố đánh giá một competency không có trong matrix	Đánh dấu liên kết competency là chưa xác lập; không gán competency bằng suy đoán từ tên template
`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	Quy ước, namespace, format, vòng đời và tính duy nhất của các ID như requirement, rule, data, API, test, defect, change và release	Template chỉ dùng canonical ID đúng loại và đúng định dạng; placeholder ID không được trình bày là ID đã đăng ký	Không tạo ID mới hoặc tái sử dụng ID có sẵn; yêu cầu cập nhật registry theo quy trình kiểm soát trước khi template tham chiếu ID đó
`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	Canonical business rule, điều kiện, ngoại lệ, owner, source classification và quan hệ với requirement hoặc test	Template ghi nhận rule bằng tham chiếu `BR-...` canonical; không diễn giải lại rule thành nghĩa vụ mới, không đổi điều kiện hoặc ngoại lệ	Ưu tiên canonical rule; nếu template cần trường thông tin chưa tồn tại, ghi nhận nhu cầu cấu trúc chứ không tự phát minh rule Nova Foods
`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Tên thực thể, thuộc tính, định nghĩa, kiểu dữ liệu, miền giá trị, định danh, phân loại dữ liệu và quan hệ dữ liệu	Nhãn trường trong template khớp canonical term; ví dụ Nova Foods dùng dữ liệu tổng hợp, locale `vi-VN`, tiền tệ mô phỏng `VND` khi có giá trị tiền	Không đổi nghĩa field, không thêm thuộc tính được xem là canonical; chuyển nhu cầu định nghĩa mới về data dictionary để xác minh

Quy tắc đối chiếu và quyết định

Ưu tiên nguồn: Khi template manifest mâu thuẫn với một canonical artifact, canonical artifact được ưu tiên trong phạm vi nó quản lý: CANONICAL_BUSINESS_RULES.md quản lý business rule, CANONICAL_DATA_DICTIONARY.md quản lý định nghĩa dữ liệu, và TRACEABILITY_ID_REGISTRY.md quản lý định danh.
Không sao chép để thay thế: Template có thể nêu trường tham chiếu như Business Rule ID, Data Element ID hoặc Requirement ID; không được sao chép toàn văn rồi coi bản sao là nguồn chân lý mới.
Bảo toàn phân loại nguồn: Nội dung có liên quan pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật phải giữ nguyên phân loại nguồn hiện có. Nội dung chưa được xác minh phải mang nhãn Verification required hoặc Project assumption; không được nâng thành quy tắc bắt buộc chỉ vì xuất hiện trong template.
Kiểm tra ngữ nghĩa, không chỉ kiểm tra chuỗi ký tự: Ví dụ, nếu template dùng Lot ID, reviewer phải đối chiếu cả định nghĩa, chủ thể sở hữu, định dạng ID và quan hệ với hàng hóa hoặc tồn kho trong data dictionary; việc cùng tên trường nhưng khác nghĩa là lỗi không nhất quán.
Ranh giới mô phỏng: Mọi ví dụ, tên vai trò, đơn hàng, lô hàng, giá trị VND và dữ liệu Nova Foods trong template chỉ là dữ liệu tổng hợp cho đào tạo. Không được diễn giải chúng là dữ liệu khách hàng, cấu hình ERP thực tế hoặc bằng chứng về quy trình production.

Bằng chứng kiểm tra tối thiểu cho từng template dự kiến

Trường bằng chứng	Nội dung cần ghi nhận
Template ID và filename dự kiến	Định danh theo registry hoặc placeholder có nhãn rõ ràng là chưa đăng ký
Artifact nguồn đã kiểm	Một hoặc nhiều filename trong sáu artifact bắt buộc nêu trên
Đối tượng được đối chiếu	Chapter, competency, ID, business rule, data element, dependency hoặc source classification
Kết quả	`MATCH`, `MISMATCH`, hoặc `VERIFICATION REQUIRED`
Căn cứ	ID hoặc tên canonical chính xác, không dùng trích dẫn hoặc điều khoản không được cung cấp
Tác động	Template được phép tiếp tục lập kế hoạch, phải điều chỉnh liên kết, hoặc phải dừng để xử lý mâu thuẫn
Người ghi nhận	Vai trò thực hiện kiểm tra; việc ghi nhận không đồng nghĩa approval

Một template chỉ được xem là đủ điều kiện chuyển sang bước lập kế hoạch chi tiết khi không tạo mâu thuẫn với sáu artifact nguồn, không dùng ID ngoài registry, không thay thế canonical rule hoặc data definition, và duy trì trạng thái quản trị IN_REVIEW của corpus.

Checklist tự rà soát: đầy đủ, không chồng lấp và bao phủ vòng đời

Checklist này được áp dụng trước khi chuyển từ kế hoạch sang soạn thảo từng template trong thư viện Nova Foods Trading & Manufacturing. Người soạn phải đánh giá từng tiêu chí theo một trong ba kết quả: PASS, REWORK REQUIRED, hoặc VERIFICATION REQUIRED. PASS chỉ xác nhận rằng tiêu chí cấu trúc đã được kiểm tra trong phạm vi bản kế hoạch IN_REVIEW; không xác lập baseline, approval, tính đúng pháp lý hoặc khả năng dùng production.

Nhóm kiểm tra	Câu hỏi tự rà soát bắt buộc	Bằng chứng phải có trong nội dung template dự kiến	Điều kiện `REWORK REQUIRED`
Đầy đủ mục đích	Template có một mục đích nghiệp vụ hoặc quản trị xác định được không?	Mô tả đầu ra, người dùng dự kiến, thời điểm sử dụng và quyết định hoặc handoff được hỗ trợ.	Một template cố gắng đồng thời là BRD, thiết kế kỹ thuật, test case và biên bản phê duyệt.
Đầy đủ trường thông tin	Các trường bắt buộc có đủ để người dùng ghi nhận đầu vào, phân tích, quyết định, ngoại lệ và truy vết không?	Trường dữ liệu, hướng dẫn điền, định dạng giá trị và ví dụ tổng hợp Nova Foods khi cần.	Trường chỉ có nhãn chung như “Ghi chú” nhưng không nêu mục đích, chủ thể hoặc tiêu chí hoàn tất.
Đầy đủ trạng thái	Template có phân biệt bản nháp, đang review, đã được quyết định và bị thay thế không?	Trường status, version, ngày ghi nhận, owner và change reference phù hợp loại artifact.	Nội dung dùng các từ “approved”, “baselined” hoặc “final” mà không yêu cầu evidence kiểm soát tương ứng.
Không chồng lấp về nguồn chân lý	Mỗi loại thông tin có một nơi ghi nhận chính; template khác chỉ tham chiếu thay vì sao chép không?	Quy tắc tham chiếu ID cho requirement, business rule, data element, API, test case, defect hoặc change request.	Cùng một business rule hoặc định nghĩa dữ liệu được yêu cầu nhập toàn văn ở nhiều template mà không chỉ rõ nguồn chính.
Không chồng lấp về quyết định	Quyết định nghiệp vụ, kỹ thuật, kiểm thử và thay đổi có ranh giới rõ không?	Phân biệt decision log, requirement, architecture input, UAT evidence và change request.	Một biểu mẫu cho phép thay đổi requirement đã kiểm soát chỉ bằng ghi chú cuộc họp hoặc kết quả test.
Không chồng lấp về vai trò	Owner, contributor, reviewer và decision authority có được tách riêng không?	Trường vai trò và trách nhiệm theo từng hành động: soạn, kiểm tra, xác minh, quyết định.	Người ghi nhận được mô tả mặc nhiên có quyền phê duyệt, diễn giải pháp lý hoặc cho phép production.
Bao phủ discovery	Có template thu thập mục tiêu, stakeholder, vấn đề, phạm vi, giả định và câu hỏi cần làm rõ không?	Đầu vào discovery được chuyển tiếp được sang process và requirements.	Requirement xuất hiện mà không có chỗ ghi nhận nguồn, bối cảnh hoặc vấn đề cần giải quyết.
Bao phủ phân tích	Có template cho process, requirement, business rule, data, integration, UX và NFR theo phạm vi đã định không?	Liên kết từ nhu cầu đến tiêu chí chấp nhận và các ràng buộc liên quan.	Một loại phân tích cần thiết bị thiếu hoàn toàn hoặc bị thay bằng văn bản tự do không có cấu trúc.
Bao phủ xác minh và kiểm thử	Kết quả phân tích có thể tạo test basis, test case, defect và bằng chứng UAT không?	Requirement hoặc rule có acceptance criteria, expected result và tham chiếu testable.	Template requirement không có cách diễn đạt kết quả quan sát được hoặc không xử lý ngoại lệ.
Bao phủ thay đổi và phát hành	Có đường đi có kiểm soát từ thay đổi được đề xuất đến đánh giá tác động, release và vận hành không?	Trường change impact, phạm vi ảnh hưởng, quyết định, release note và operational handoff khi áp dụng.	Thay đổi sau review không có nơi ghi nhận tác động đến requirement, test hoặc tài liệu liên quan.
Bao phủ vận hành sau phát hành	Các template liên quan release có thể ghi nhận hỗ trợ, sự cố, tri thức vận hành và phản hồi cải tiến không?	Liên kết release/operation với defect, change hoặc bài học kinh nghiệm khi phù hợp.	Vòng đời kết thúc tại UAT mà không có cơ chế bàn giao hoặc ghi nhận vấn đề sau phát hành.
Kiểm soát dữ liệu mô phỏng	Ví dụ điền mẫu có giữ bối cảnh Nova Foods, `vi-VN`, `Asia/Ho_Chi_Minh`, `VND` và dữ liệu tổng hợp không?	Nhãn mô phỏng giáo dục và giá trị minh họa không định danh cá nhân hoặc doanh nghiệp thực.	Ví dụ chứa dữ liệu cá nhân thật, giao dịch thật, hoặc được diễn đạt như cấu hình ERP production.

Quy tắc kết luận tự rà soát

Một template chỉ đạt mức sẵn sàng soạn thảo khi không có kết quả REWORK REQUIRED trong ba trục: đầy đủ, không chồng lấp và vòng đời.
VERIFICATION REQUIRED được giữ nguyên trong template khi nội dung phụ thuộc vào xác minh chuyên môn, pháp lý, kế toán, tuân thủ hoặc vận hành; không được đổi nhãn này thành một khẳng định bắt buộc.
Khi hai template cùng thu thập một thông tin, template có chức năng ra quyết định hoặc duy trì nguồn chân lý giữ nội dung chính; template còn lại chỉ giữ ID tham chiếu, phiên bản và ngữ cảnh sử dụng.
Mỗi template phải chỉ rõ đầu vào nhận từ bước trước và đầu ra bàn giao cho bước sau. Không được coi một template là độc lập nếu người dùng không thể xác định nó được dùng trước, trong hay sau hoạt động nào của vòng đời BA.

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

Các mục dưới đây là đầu vào kiểm soát trước khi soạn thảo template. Chúng không phải requirement đã được phê duyệt, không tạo quyết định vận hành Nova Foods, và phải giữ nhãn Verification required hoặc Project assumption cho đến khi có bằng chứng phù hợp trong artifact kiểm soát có thẩm quyền.

Mã theo dõi	Loại	Vấn đề mở hoặc giả định hiện tại	Bằng chứng cần xác minh	Vai trò xác minh phù hợp	Tác động nếu chưa xác minh
`OI-TMPL-001`	`Project assumption`	Nova Foods Trading & Manufacturing được dùng xuyên suốt như case study ERP giáo dục; toàn bộ khách hàng, nhà cung cấp, nhân viên, lô hàng, kho, số tiền và mã giao dịch phải là dữ liệu tổng hợp.	Xác nhận phạm vi mô phỏng không sao chép dữ liệu, quy trình nội bộ hoặc thông tin nhận diện của tổ chức thực tế.	Senior BA và Business Owner	Template có thể vô tình được hiểu là mô tả hệ thống production hoặc sử dụng dữ liệu không phù hợp.
`OI-TMPL-002`	`Verification required`	Các template có trường liên quan dữ liệu cá nhân chỉ hướng dẫn phân loại, truy vết quyết định và yêu cầu xác minh; chúng không được diễn giải nghĩa vụ pháp lý từ Luật 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP.	Văn bản pháp luật hiện hành, phạm vi áp dụng cho dự án và cách diễn đạt requirement do Legal hoặc Compliance xác nhận.	Legal và Compliance	Không được ghi retention period, lawful basis, quyền chủ thể dữ liệu hoặc nghĩa vụ thông báo như quy tắc đã xác lập.
`OI-TMPL-003`	`Verification required`	Template nghiệp vụ tài chính, thuế, hóa đơn và chứng từ chỉ cung cấp cấu trúc phân tích; không chứa cách hạch toán, thuế suất, thời điểm lập hóa đơn hoặc kết luận tuân thủ.	Diễn giải áp dụng của Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và các sửa đổi có hiệu lực tại thời điểm triển khai.	Accounting và Legal	Các trường template phải dùng nhãn “cần xác minh” thay vì biến giả định thành quy tắc kế toán hoặc hóa đơn.
`OI-TMPL-004`	`Verification required`	Các template lô hàng, hạn dùng, truy xuất nguồn gốc, thu hồi và kiểm soát chất lượng chỉ mô tả điểm cần khai thác requirement; chúng không xác định nghĩa vụ an toàn thực phẩm.	Quy trình nghiệp vụ thực tế cần mô phỏng và diễn giải pháp lý liên quan Luật 55/2010/QH12.	Business Owner, Legal và Compliance	Không được khẳng định chuỗi truy xuất, thời hạn lưu vết, điều kiện thu hồi hoặc trách nhiệm pháp lý cụ thể.
`OI-TMPL-005`	`Project assumption`	Tiền tệ ví dụ trong template là `VND`, locale là `vi-VN`, múi giờ quản trị là `Asia/Ho_Chi_Minh`; đây là quy ước corpus, không xác nhận cấu hình ERP, tỷ giá hay lịch tài chính của tổ chức thực tế.	Quyết định cấu hình dự án nếu template được tái sử dụng ngoài corpus giáo dục.	Business Owner và Accounting	Không được suy ra quy tắc làm tròn, định dạng chứng từ, kỳ kế toán hoặc xử lý ngoại tệ.
`OI-TMPL-006`	`Verification required`	Template API có thể tham chiếu OpenAPI Specification `3.1.1` cho cấu trúc mô tả HTTP API, nhưng không mặc định quyết định giao thức xác thực, phân quyền, mã hóa, rate limit hoặc kiến trúc tích hợp.	Kiến trúc mục tiêu, threat model, tiêu chuẩn bảo mật dự án và phạm vi kiểm thử bảo mật.	Architect và QA	Các trường security trong template phải là câu hỏi/đầu vào cần xác minh, không là control đã được triển khai.
`OI-TMPL-007`	`Project assumption`	Template UX và accessibility định hướng ghi nhận nhu cầu tiếp cận; việc dùng WCAG `2.2` không xác nhận mức phù hợp, mức AA, hoặc kết quả kiểm thử accessibility của giao diện Nova Foods.	Phạm vi người dùng, thiết bị, công nghệ hỗ trợ và tiêu chí accessibility được chọn cho dự án.	Business Owner, Architect và QA	Không được tuyên bố giao diện compliant hoặc accessible chỉ vì template có checklist.
`OI-TMPL-008`	`Verification required`	Thuật ngữ kiểm thử được định hướng bởi ISTQB CTFL Syllabus `v4.0.1`; kỹ thuật test, mức test và bằng chứng pass/fail cụ thể vẫn phụ thuộc test strategy của dự án.	Test strategy, test environment, dữ liệu test tổng hợp và acceptance authority.	QA và Business Owner	Template không được biến một ví dụ test case thành bằng chứng UAT, sign-off hoặc production readiness.

Quy tắc xử lý: một mục chỉ được đóng khi có tham chiếu đến bằng chứng xác minh, vai trò có thẩm quyền và quyết định được ghi nhận trong artifact phù hợp. Việc một người soạn template điền nội dung, một reviewer đọc nội dung, hoặc artifact đang ở trạng thái IN_REVIEW không đóng vấn đề mở và không chuyển giả định thành sự thật đã xác nhận.

Ma trận Escalation Theo Thẩm Quyền Chuyên Môn

Mọi escalation phát sinh khi soạn thảo template cho Nova Foods phải được ghi nhận như một yêu cầu làm rõ có truy vết, không được tự chuyển thành requirement, business rule, quyết định thiết kế, diễn giải pháp luật hoặc xác nhận sẵn sàng triển khai. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, phản hồi của vai trò được hỏi chỉ có giá trị trong đúng phạm vi thẩm quyền và không tạo approval ngầm định cho /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/01_CURRICULUM_ARCHITECTURE.md hoặc /01-curriculum/CHAPTER_MANIFEST.md.

Vai trò nhận escalation	Điều kiện bắt buộc escalation	Câu hỏi hoặc bằng chứng cần gửi	Ranh giới quyết định
Senior BA	Template có requirement, acceptance criterion, business rule, stakeholder need hoặc traceability chưa rõ nguồn, bị trùng nghĩa, không kiểm thử được hoặc mâu thuẫn với cấu trúc học.	ID hiện có, artifact nguồn, mô tả mâu thuẫn, tác động tới template và phương án xử lý.	Làm rõ chất lượng phân tích, cấu trúc requirement và cách duy trì traceability; không xác nhận pháp lý, hạch toán hay thiết kế kỹ thuật.
Architect	Template mô tả API, integration, event, dữ liệu liên hệ, phân quyền kỹ thuật, NFR, logging, khả dụng hoặc ràng buộc kiến trúc chưa có căn cứ.	Luồng tích hợp, hệ thống nguồn/đích, dữ liệu trao đổi, giả định kỹ thuật, rủi ro và tham chiếu OAS hoặc tiêu chuẩn kỹ thuật khi áp dụng.	Xác nhận hướng kỹ thuật phù hợp để mô phỏng; không thay Business Owner quyết định quy trình và không tự diễn giải nghĩa vụ pháp lý.
QA	Acceptance criterion, test basis, expected result, negative case, defect workflow hoặc UAT evidence không quan sát hoặc kiểm thử được.	Requirement/rule liên quan, điều kiện đầu vào, kết quả mong đợi, ngoại lệ, dữ liệu mô phỏng và liên kết test dự kiến.	Xác định khả năng kiểm thử và evidence cần có theo thuật ngữ ISTQB CTFL; không phê duyệt requirement nghiệp vụ.
Business Owner	Quy trình Nova Foods về đơn hàng, tồn kho, lô hàng, hạn dùng, truy xuất, thu hồi, giá, ưu tiên hoặc ngoại lệ vận hành chưa có chủ thể quyết định.	Scenario mô phỏng, lựa chọn nghiệp vụ, tác động người dùng, giả định hiện tại và câu hỏi cần quyết định một nghĩa.	Xác nhận tính phù hợp của bối cảnh nghiệp vụ mô phỏng; không xác nhận tuân thủ luật, thuế hoặc cấu hình production.
Legal	Nội dung viện dẫn hoặc suy ra nghĩa vụ về dữ liệu cá nhân, hợp đồng, an toàn thực phẩm, truy xuất nguồn gốc, thu hồi hoặc quy định pháp luật Việt Nam.	URL nguồn chính thức, ngày truy cập `2026-08-07`, nội dung cần kiểm chứng, nhãn `Verification required` hoặc `Project assumption`, và tác động hệ thống dự kiến.	Xác minh diễn giải pháp lý thuộc phạm vi được giao; không để template tự khẳng định compliance khi chưa có xác minh hợp lệ.
Accounting	Template liên quan hạch toán, thuế, hóa đơn, chứng từ, giá vốn, công nợ, kỳ kế toán hoặc cách ghi nhận số tiền `VND`.	Nghiệp vụ giả định, trường dữ liệu, thời điểm ghi nhận, tác động sổ sách và tham chiếu Luật Kế toán hoặc Nghị định 123/2020/NĐ-CP khi có liên quan.	Xác nhận cách diễn giải kế toán thuộc thẩm quyền; không cho phép suy luận bút toán hoặc nghĩa vụ thuế từ ví dụ đào tạo.
Compliance	Yêu cầu kiểm soát, lưu vết, phân quyền, bảo mật, lưu giữ dữ liệu, kiểm tra tuân thủ hoặc bằng chứng kiểm soát không có chủ sở hữu xác nhận.	Control objective, phạm vi dữ liệu, rủi ro, evidence dự kiến, nguồn tiêu chuẩn và điểm chưa được kiểm chứng.	Đánh giá nhu cầu kiểm soát và bằng chứng compliance; OWASP, WCAG hoặc tiêu chuẩn quốc tế chỉ là nguồn tham khảo trừ khi được xác định khác bởi thẩm quyền phù hợp.

Quy tắc chuyển tiếp: nếu một nội dung đồng thời chạm dữ liệu cá nhân và thiết kế tích hợp, phải gửi Legal để xác minh nghĩa vụ, Architect để xác minh phương án kỹ thuật, và Compliance để xác minh control evidence. Nếu nội dung liên quan hóa đơn hoặc ghi nhận tài chính, Accounting là đầu mối chuyên môn; Legal được tham vấn khi cần xác minh hiệu lực quy định. Trong thời gian chưa có kết quả xác minh, template chỉ được dùng nhãn Verification required hoặc Project assumption; không được nâng thành quy tắc chuẩn của Nova Foods.

Ma trận Phân Bổ Duy Nhất Yêu Cầu Assignment

Tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, manifest xác nhận mọi yêu cầu trong assignment tạo /01-curriculum/TEMPLATE_MANIFEST.md đã được gán một và chỉ một section chịu trách nhiệm soạn thảo chính. “Gán duy nhất” nghĩa là một yêu cầu chỉ có một section sở hữu nội dung chuẩn tắc; section khác chỉ được phép tham chiếu liên kết mà không sao chép, diễn giải lại hoặc tạo nguồn chân lý cạnh tranh.

Mã phân bổ	Yêu cầu assignment	Section sở hữu duy nhất	Ranh giới trách nhiệm
`ALLOC-TMPL-01`	Tiêu đề H1, metadata quản trị artifact và phạm vi manifest	`1. H1 Title, Artifact Governance Metadata, and Manifest Scope`	Xác lập định danh, trạng thái `IN_REVIEW`, `v0.9.0`, phạm vi, quyền hạn Owner và giới hạn hiệu lực của manifest.
`ALLOC-TMPL-02`	Kiến trúc catalog template, registry `TMPL` và quy tắc đặt tên tệp	`2. Template Catalog Architecture, TMPL Identifier Registry, and File-Naming Rules`	Là nguồn duy nhất cho cấu trúc catalog, định danh template và quy ước filename.
`ALLOC-TMPL-03`	Template discovery, process, requirements, rules, data, API, UX, NFR và integration	`3. Discovery, Process, Requirements, Rules, Data, API, UX, NFR, and Integration Templates`	Lập kế hoạch nhóm template đầu vào và phân tích trước kiểm thử, không sở hữu template kiểm thử hoặc vận hành.
`ALLOC-TMPL-04`	Template testing, defect, UAT, change, release và operations	`4. Testing, Defect, UAT, Change, Release, and Operations Templates`	Lập kế hoạch nhóm template cho xác minh, chuyển giao và vận hành; không tái định nghĩa requirement hoặc business rule chuẩn tắc.
`ALLOC-TMPL-05`	AI-assisted governance, nghĩa vụ bốn tầng và quy tắc hoàn thành	`5. AI-Assisted Governance, Four-Tier Obligations, and Completion Rules`	Quy định cách dùng AI, phân loại nghĩa vụ và điều kiện hoàn thành artifact; không tạo phê duyệt ngầm định.
`ALLOC-TMPL-06`	Kiểm tra nhất quán liên tệp, tự rà soát, vấn đề mở, escalation và kiểm soát batch	`6. Cross-File Consistency Checks, Self-Review, Open Issues, and Escalation`	Đóng vòng kiểm soát trước drafting, bao gồm xác nhận phân bổ duy nhất này.

Quy tắc kiểm soát: nếu một nội dung có vẻ thuộc nhiều section, section sở hữu được xác định theo đầu ra chuẩn tắc mà nội dung đó quản lý, không theo số lần nội dung được nhắc đến. Ví dụ, một template UAT có thể tham chiếu requirement template của Section 3, nhưng catalog và cấu trúc UAT vẫn chỉ thuộc Section 4. Tương tự, Section 6 kiểm tra việc có phân bổ nhưng không được chuyển quyền sở hữu catalog, quy tắc ID hoặc nội dung template từ các section trước sang Section 6.

Không có yêu cầu assignment nào nằm ngoài sáu dòng phân bổ trên; không có yêu cầu nào được phân bổ đồng thời cho hai section. Xác nhận này là kiểm soát phạm vi lập kế hoạch cho corpus Nova Foods Trading & Manufacturing sử dụng dữ liệu tổng hợp, không phải baseline, approval, cam kết triển khai hoặc xác nhận nội dung đã được người dùng chấp thuận.

Ghi chú kiểm soát lô tạo tệp kế tiếp

Việc tạo các tệp template sau khi hoàn tất kế hoạch này phải thực hiện theo lô sinh có kiểm soát; một lô là đơn vị tạo mới hoặc cập nhật một tập tệp có phạm vi, đầu vào, đầu ra và bằng chứng kiểm soát xác định. Mục tiêu là tránh tạo template rời rạc, thay đổi định danh ngoài ý muốn, hoặc đưa nội dung Nova Foods mô phỏng vượt khỏi ranh giới nguồn của corpus.

Trường kiểm soát lô	Quy tắc bắt buộc
Mã lô	Dùng định dạng `GEN-TMPL-{NNN}`; số thứ tự tăng dần, không tái sử dụng.
Trạng thái ban đầu	Mọi tệp sinh trong lô kế tiếp phải mang `IN_REVIEW`, `v0.9.0`, ngày `2026-08-07`, locale `vi-VN`, múi giờ `Asia/Ho_Chi_Minh`, và tiền tệ mô phỏng `VND` khi có trường tiền tệ.
Phạm vi lô	Mỗi lô chỉ tạo các tệp thuộc một nhóm template đã được phân bổ trong manifest; không được tự mở rộng sang handbook chapter, canonical register, tài liệu quyết định, hoặc tài liệu production.
Đầu vào bắt buộc	`TEMPLATE_MANIFEST.md`, `CHAPTER_MANIFEST.md`, `TRACEABILITY_ID_REGISTRY.md`, `CANONICAL_BUSINESS_RULES.md`, `CANONICAL_DATA_DICTIONARY.md` và các dependency được manifest chỉ định cho template đó.
Đầu ra bắt buộc	Tệp template tại đường dẫn đã đăng ký, metadata quản trị, hướng dẫn sử dụng, trường dữ liệu, quy tắc đặt ID, liên kết traceability dự kiến và nhãn nguồn phù hợp.
Dữ liệu ví dụ	Chỉ dùng Nova Foods Trading & Manufacturing dưới dạng mô phỏng giáo dục với dữ liệu tổng hợp. Không dùng dữ liệu cá nhân, giao dịch thực, khách hàng thực, thông tin vận hành thực hoặc suy diễn cấu hình ERP thực tế.
Kiểm soát thay đổi	Lô không được đổi `TMPL` ID, tên tệp, đường dẫn, tên canonical entity, business-rule ID hoặc data-element ID đã đăng ký. Thay đổi các giá trị này là thay đổi controlled content và phải được ghi nhận theo cơ chế quản trị artifact áp dụng.
Điều kiện dừng	Dừng lô nếu đầu vào mâu thuẫn, ID chưa được đăng ký, nguồn pháp lý chưa được xác minh nhưng bị diễn đạt như nghĩa vụ bắt buộc, hoặc template đòi hỏi quyết định thuộc thẩm quyền Business Owner, Architect, QA, Legal, Accounting hoặc Compliance.

Thứ tự sinh tệp phải bám theo dependency thay vì theo độ tiện lợi soạn thảo: template có trường tham chiếu business rule, data element, requirement, test case hoặc API contract chỉ được tạo sau khi biết nguồn canonical dùng để tham chiếu. Template có thể chứa placeholder có kiểm soát như Verification required hoặc Project assumption khi nội dung cần xác minh; không được biến placeholder thành quy tắc Nova Foods, nghĩa vụ pháp lý, hạch toán, thuế, hóa đơn, bảo mật, an toàn thực phẩm hoặc quyết định production.

Mỗi GEN-TMPL-{NNN} phải ghi tối thiểu: danh sách tệp dự kiến tạo, ID template tương ứng, dependency đầu vào, phạm vi nội dung, người ghi nhận, thời điểm theo Asia/Ho_Chi_Minh, kết quả tạo tệp và các điểm phải giữ nhãn xác minh. Việc hoàn tất kỹ thuật của lô chỉ xác nhận rằng tệp đã được tạo theo phạm vi lô; không tạo baseline, không xác nhận chất lượng chuyên môn, không xác nhận approval và không cho phép sử dụng production.