Tmpl Ac 001 Acceptance Criteria

Trường kiểm soát	Giá trị được kiểm soát
Artifact ID	TMPL-AC-001
Tên tệp được kiểm soát	/03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md
Tiêu đề tài liệu	Tmpl Ac 001 Acceptance Criteria
Status	IN_REVIEW
Version	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND
Phân loại artifact	Controlled four-tier template: mẫu có kiểm soát gồm bốn tầng học liệu, không phải tài liệu phê duyệt hay cấu hình ERP production.
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ sử dụng dữ liệu tổng hợp.
Trạng thái baseline	Chưa có baseline reference tại v0.9.0. IN_REVIEW nghĩa là đang được xem xét có kiểm soát, không có nghĩa là BASELINED.
Trạng thái phê duyệt	Chưa có approval reference được ghi nhận. Sự tồn tại của Owner, metadata, nội dung mẫu hoặc lịch sử thay đổi không tạo phê duyệt ngầm định.
Nguồn định danh	TEMPLATE_MANIFEST, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, và CANONICAL_DATA_DICTIONARY là các artifact quản trị upstream được giữ nguyên định danh khi cần liên kết.
Ranh giới dữ liệu mô phỏng	Mọi tên người, mã yêu cầu, mã quy tắc, mã dữ liệu, mã kiểm thử, giá trị tiền tệ, ngày tháng, trạng thái quy trình và bằng chứng mang nhãn Nova Foods trong tài liệu này đều là dữ liệu tổng hợp phục vụ đào tạo. Chúng không chứng minh doanh nghiệp, hệ thống ERP, giao dịch, khách hàng, nhân sự hoặc hồ sơ vận hành có thật.
Ranh giới thẩm quyền	Owner duy trì định danh, phiên bản, trạng thái, metadata và lịch sử thay đổi; Owner không tự xác lập baseline, không ghi nhận approval, không xác nhận yêu cầu Nova Foods cho vận hành thực tế, và không thay thế thẩm quyền Business Owner, QA, Architect, Legal, Accounting, Security hoặc Compliance.

1. Tier 1 ? Metadata, Purpose, and Governance

Lịch sử thay đổi hiện hành

Version	Ngày	Trạng thái	Người ghi nhận	Thay đổi được ghi nhận
v0.9.0	2026-08-07	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo metadata quản trị cho artifact TMPL-AC-001 tại đường dẫn /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md; thiết lập ranh giới dữ liệu tổng hợp và trạng thái chưa baseline, chưa có approval reference.

Quy tắc diễn giải metadata: IN_REVIEW là trạng thái kiểm soát để nhận diện phiên bản đang được xem xét và cho phép truy vết thay đổi; vì vậy, không được suy diễn rằng nội dung đã đúng cho production, đã tuân thủ pháp luật, đã được kiểm thử, đã được Business Owner chấp thuận hoặc đã được phép triển khai. Lý do là metadata chỉ chứng minh danh tính và trạng thái quản trị của artifact, không phải bằng chứng cho một quyết định nghiệp vụ, pháp lý, kế toán, kỹ thuật hoặc vận hành.

Quy tắc dữ liệu tổng hợp: Nova Foods là case study mô phỏng. Nếu một ví dụ trong các tầng sau dùng mã như requirement, acceptance criterion, business rule, test case hoặc dữ liệu VND, mã đó chỉ phục vụ việc học cách liên kết artifact. Không được sao chép dữ liệu mô phỏng thành hồ sơ thực, không được dùng làm căn cứ cấu hình ERP, và không được diễn giải ví dụ thành nghĩa vụ pháp lý hay quy tắc kế toán thực tế.

Mục đích, điều kiện sử dụng và ranh giới thẩm quyền

TMPL-AC-001 tại /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md là mẫu Acceptance Criteria (tiêu chí chấp nhận): các điều kiện có thể kiểm tra để xác định một yêu cầu hoặc lát cắt chức năng mô phỏng Nova Foods đã đạt kết quả mong đợi hay chưa. Mục đích của mẫu là chuyển ý định nghiệp vụ đã được làm rõ thành tiêu chí quan sát, kiểm tra và truy vết được; vì vậy, tiêu chí không thay thế yêu cầu gốc, quy tắc nghiệp vụ, kịch bản kiểm thử hoặc quyết định phê duyệt. Toàn bộ ví dụ Nova Foods Trading & Manufacturing trong mẫu là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

Nội dung	Quy định áp dụng	Lý do và bằng chứng suy luận
Khi sử dụng	Dùng khi một yêu cầu, quy tắc, luồng nghiệp vụ hoặc thay đổi giao diện/API đã có định danh canonical và cần xác định kết quả chấp nhận có thể kiểm tra.	Không có đối tượng truy vết thì không thể chứng minh tiêu chí thuộc yêu cầu nào; do đó phải có liên kết đến TRACEABILITY_ID_REGISTRY trước khi viết tiêu chí.
Khi không sử dụng	Không dùng mẫu để tạo mới yêu cầu nghiệp vụ, tự đặt quy tắc Nova Foods, diễn giải pháp lý, quyết định thuế-kế toán, phê duyệt thiết kế kiến trúc, hoặc xác nhận hệ thống production tuân thủ.	Tiêu chí chấp nhận chỉ kiểm tra kết quả đã được xác định; việc tự điền quyết định vào tiêu chí làm đảo chiều từ “kiểm tra” sang “tạo chính sách”, vượt thẩm quyền của template.
Đầu vào tối thiểu	Có requirement hoặc user story định danh; phạm vi chức năng; actor; dữ liệu đầu vào mô phỏng; kết quả mong đợi; ngoại lệ đã biết; và liên kết quy tắc nếu có.	Một tiêu chí chỉ kiểm tra được khi biết ai thực hiện, trong điều kiện nào, với dữ liệu nào và kết quả nào là đúng hoặc sai.
Đầu ra hạ nguồn	Test basis cho kiểm thử; tham chiếu trong test case; liên kết traceability; đầu vào review nghiệp vụ và QA.	ISTQB CTFL dùng kiểm thử dựa trên test basis; acceptance criteria cung cấp điều kiện kiểm tra nhưng không tự trở thành bằng chứng kiểm thử.
Người sử dụng	Business Analyst soạn và duy trì liên kết; QA/Test Analyst chuyển tiêu chí thành kiểm thử; Business Owner xem xét ý nghĩa nghiệp vụ; Developer và Architect dùng để hiểu hành vi cần triển khai trong phạm vi được giao.	Mỗi vai trò tiêu thụ cùng một tiêu chí theo mục đích khác nhau, nên mọi thay đổi phải giữ một nguồn bản ghi kiểm soát thay vì sao chép sang nhiều nơi.

Owner của template là Principal IT Business Analyst / Technical Curriculum Author. Owner chịu trách nhiệm duy trì cấu trúc bốn tầng, định danh TMPL-AC-001, liên kết tới artifact canonical và lịch sử thay đổi của tài liệu. Owner có thể phát hiện mâu thuẫn, ghi nhận vấn đề và điều phối review, nhưng không có quyền tự xác nhận tiêu chí là đã được Business Owner chấp nhận, đã baseline, hợp pháp, đúng về kế toán, an toàn thực phẩm, bảo mật hoặc sẵn sàng production.

Tình huống	Thẩm quyền quyết định	Hành động escalation
Tiêu chí mâu thuẫn với mục tiêu hoặc quy trình nghiệp vụ mô phỏng	Business Owner	Gửi gói vấn đề gồm ID tiêu chí, requirement liên quan, dữ liệu mô phỏng, hai cách hiểu và ảnh hưởng truy vết; giữ trạng thái IN_REVIEW.
Tiêu chí dẫn chiếu hoặc diễn giải nghĩa vụ pháp lý về dữ liệu cá nhân, kế toán, hóa đơn hoặc an toàn thực phẩm	Legal Owner, Accounting Owner hoặc domain owner phù hợp	Gắn nhãn Verification required hoặc project assumption; không diễn đạt thành nghĩa vụ bắt buộc khi chưa có xác minh từ vai trò có thẩm quyền.
Tiêu chí phụ thuộc API, phân quyền, bảo mật, hiệu năng hoặc cấu trúc tích hợp	Architect và Security Owner	Chuyển câu hỏi quyết định kỹ thuật kèm requirement, rủi ro và liên kết đến tiêu chuẩn phù hợp; không để BA tự kết luận thiết kế.
Tiêu chí không thể kiểm tra khách quan hoặc thiếu dữ liệu kiểm thử	QA/Test Analyst phối hợp Business Analyst	Làm rõ điều kiện đầu vào, kết quả quan sát và quy tắc so sánh trước khi dùng làm test basis.

Mẫu phải tham chiếu đúng các nguồn canonical theo chức năng: TEMPLATE_MANIFEST xác định sự tồn tại và phạm vi template; TRACEABILITY_ID_REGISTRY kiểm soát ID liên kết; CANONICAL_BUSINESS_RULES là nguồn cho quy tắc nghiệp vụ đã được catalog; CANONICAL_DATA_DICTIONARY là nguồn cho tên và ý nghĩa dữ liệu logic. CHAPTER_MANIFEST chỉ được dùng để liên kết chapter khi manifest đã đăng ký liên kết đó; không tự tạo chapter ID hoặc suy diễn nội dung chapter. Mọi thay đổi làm đổi ý nghĩa tiêu chí, requirement liên kết, quy tắc, dữ liệu, ngoại lệ hoặc thẩm quyền review phải được ghi nhận qua cơ chế change control của corpus; trạng thái IN_REVIEW tại v0.9.0 không phải baseline, approval hay xác nhận sử dụng thực tế.

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

TMPL-AC-001 là định danh canonical của template Acceptance Criteria (tiêu chí chấp nhận), được kiểm soát tại tệp /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md. “Canonical” nghĩa là chuỗi định danh và đường dẫn được dùng làm điểm tham chiếu duy nhất trong corpus; không được đổi thành biến thể như AC-001, TMPL_AC_001 hoặc tên dịch tự do. Cơ sở suy luận là TEMPLATE_MANIFEST quản lý danh mục template, còn TRACEABILITY_ID_REGISTRY quản lý tính duy nhất và quy tắc sử dụng định danh; vì vậy template phải liên kết tới hai artifact này thay vì tự tạo danh mục ID riêng.

Hạng mục liên kết	Giá trị canonical hoặc nguồn kiểm soát	Cách áp dụng cho TMPL-AC-001	Ranh giới quyết định
Template identity	TMPL-AC-001	Ghi nguyên dạng trong header, liên kết traceability, evidence và yêu cầu thay đổi.	Không tái sử dụng ID này cho test case, business rule, API hoặc data field.
Controlled filename	/03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md	Đây là vị trí artifact được yêu cầu; bản sao xuất hoặc trích đoạn không thay thế tệp kiểm soát.	Không đổi tên tệp nếu chưa cập nhật manifest và các liên kết phụ thuộc.
Manifest identity	/01-curriculum/TEMPLATE_MANIFEST.md — TEMPLATE_MANIFEST	Xác nhận template thuộc template library dự kiến của corpus.	Manifest là nguồn kiểm soát danh mục, không tự xác nhận nội dung tiêu chí của một case.
ID governance	/01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY	Kiểm tra ID dùng trong Tier 3, liên kết requirement, rule, data và evidence trước khi ghi vào template.	Không tự cấp ID mới khi registry chưa có quy tắc hoặc chưa ghi nhận ID đó.
Business-rule reference	/01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES	Tiêu chí chấp nhận có thể kiểm chứng một business rule, nhưng không được viết lại rule thành nguồn chân lý thứ hai.	Rule liên quan pháp lý, thuế, kế toán, thực phẩm hoặc dữ liệu cá nhân phải giữ nhãn Verification required khi chưa có xác nhận đúng thẩm quyền.
Data reference	/01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY	Tên thực thể, trường dữ liệu, mã và ý nghĩa dữ liệu trong tiêu chí phải truy về từ điển dữ liệu khi đã được xác định.	Không biến tên trường minh họa thành thiết kế dữ liệu triển khai hoặc schema production.
Chapter linkage	/01-curriculum/CHAPTER_MANIFEST.md — CHAPTER_MANIFEST	Liên kết template với các chapter có nội dung requirement, business rule, traceability và testing theo entry được manifest đăng ký.	Không tự gán số chapter, tiêu đề chapter hoặc dependency chưa được manifest ghi nhận.
Curriculum boundary	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md — 01_CURRICULUM_ARCHITECTURE	Dùng để kiểm tra chuỗi học từ requirement đến acceptance criteria, traceability và test basis không bị đứt.	Không dùng template để thay đổi kiến trúc curriculum.
Source map	/00-research/00_SOURCE_MAP.md — 00_SOURCE_MAP	Mọi tham chiếu chuẩn, pháp lý hoặc good practice trong phần hướng dẫn phải truy được về nguồn đã phân loại.	Không suy diễn điều khoản, số trang, nghĩa vụ pháp lý hoặc tuyên bố tuân thủ ngoài safe use boundary.

Liên kết chapter được thực hiện theo nguyên tắc “chapter là ngữ cảnh học, template là công cụ thực hành”. Nghĩa là chapter có thể giải thích requirement, quy tắc nghiệp vụ, dữ liệu, truy vết và kiểm thử; còn TMPL-AC-001 chỉ cấu trúc hóa điều kiện có thể kiểm chứng để xác định một yêu cầu hay user story có được chấp nhận trong case Nova Foods mô phỏng hay không. Suy luận này bảo vệ một nguồn chân lý: acceptance criterion không thay thế requirement, không thay thế test case, và không tự tạo quyết định vận hành ERP.

Nguồn chuyên môn được phép tham chiếu theo đúng mục đích đã xác minh: BABOK Guide dùng cho thuật ngữ và thực hành BA; ISO/IEC/IEEE 29148:2018 dùng ở mức khái niệm kỹ nghệ yêu cầu theo abstract chính thức; ISTQB CTFL Syllabus v4.0.1 dùng cho thuật ngữ kiểm thử và kỹ thuật black-box; WCAG 2.2, OpenAPI Specification 3.1.1, OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 chỉ được dùng khi tiêu chí liên quan trực tiếp đến accessibility, API hoặc security. Luật Việt Nam trong 00_SOURCE_MAP chỉ là nguồn bối cảnh; bất kỳ tiêu chí nào được diễn đạt như nghĩa vụ pháp lý, kế toán, thuế, hóa đơn, bảo vệ dữ liệu cá nhân hoặc an toàn thực phẩm đều cần chủ sở hữu chuyên môn phù hợp xác minh trước khi được coi là áp dụng ngoài học liệu.

Mọi thay đổi đối với TMPL-AC-001 phải kiểm tra đồng thời bốn tác động: (1) ID, tên tệp hoặc quan hệ manifest có thay đổi không; (2) liên kết tới chapter, rule, data hoặc evidence có bị gãy không; (3) nguồn được viện dẫn có vượt safe use boundary hoặc bị diễn đạt quá mức không; và (4) thay đổi có biến dữ liệu tổng hợp Nova Foods thành tuyên bố về doanh nghiệp, cấu hình ERP hoặc tuân thủ thực tế không. Nếu một trong bốn điều kiện xảy ra, người soạn phải ghi nhận thay đổi theo cơ chế kiểm soát của corpus và chuyển vấn đề đến vai trò có thẩm quyền tương ứng. IN_REVIEW không tạo baseline, không chứng minh approval và không cho phép sử dụng production.

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

Cách dùng: Sao chép nguyên khối mẫu này cho một acceptance criterion (tiêu chí chấp nhận). Acceptance criterion là điều kiện có thể quan sát và kiểm tra để xác định một yêu cầu đã đạt kết quả mong đợi hay chưa. Chỉ điền dữ liệu đã được ghi nhận trong artifact nguồn; không dùng mẫu để tự tạo quy tắc nghiệp vụ, quyết định kiến trúc, kết luận pháp lý hoặc xác nhận triển khai.

2.1. Mẫu acceptance criterion trống

Trường	Nội dung cần điền
Acceptance Criterion ID	<mã định danh acceptance criterion đã đăng ký trong TRACEABILITY_ID_REGISTRY, ví dụ theo quy ước dự án>
Tên tiêu chí chấp nhận	<câu ngắn mô tả kết quả nghiệp vụ hoặc hệ thống cần được chấp nhận>
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Ngôn ngữ và locale	vi-VN
Đơn vị tiền tệ, nếu áp dụng	VND hoặc <không áp dụng>
Phạm vi case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Loại tiêu chí	<Functional hoặc Non-functional hoặc Data hoặc Integration hoặc Security hoặc Accessibility>
Đối tượng chịu tác động	<vai trò người dùng, hệ thống, dịch vụ, dữ liệu hoặc quy trình chịu tác động>
Mục tiêu kiểm tra	<kết quả cần chứng minh bằng quan sát hoặc kiểm thử; không ghi cách xây dựng nội bộ nếu không phải điều kiện chấp nhận>
Requirement nguồn	<Requirement ID canonical và tên requirement nguồn; không thay bằng diễn giải tự do>
Business rule liên quan	<Business Rule ID canonical> hoặc <không áp dụng; nêu lý do không áp dụng>
Data element liên quan	<Data Dictionary ID canonical và tên trường dữ liệu> hoặc <không áp dụng; nêu lý do không áp dụng>
Phụ thuộc	<ID artifact, interface, dữ liệu mẫu hoặc điều kiện tiền đề cần tồn tại trước khi kiểm tra> hoặc <không có phụ thuộc đã ghi nhận>
Giả định dự án	<giả định được ghi nhãn project assumption> hoặc <không có giả định đã ghi nhận>
Cần xác minh	<nội dung cần Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect hoặc QA xác minh> hoặc <không có mục cần xác minh đã ghi nhận>

2.2. Ngữ cảnh kiểm tra

Given / Bối cảnh ban đầu: <mô tả trạng thái ban đầu có thể thiết lập và quan sát được, bao gồm vai trò, dữ liệu tổng hợp, quyền truy cập mô phỏng và điều kiện hệ thống cần thiết>.

When / Hành động hoặc sự kiện kích hoạt: <mô tả một hành động người dùng, sự kiện hệ thống, lời gọi API hoặc mốc quy trình có thể thực hiện được>.

Then / Kết quả bắt buộc: <mô tả kết quả duy nhất, có thể quan sát, đo lường hoặc đối chiếu; dùng giá trị, trạng thái, thông báo hoặc bản ghi cụ thể nếu requirement nguồn đã quy định>.

Và / Điều kiện bảo toàn: <mô tả dữ liệu, quyền, trạng thái hoặc quy trình không được thay đổi ngoài phạm vi; ghi không áp dụng nếu requirement nguồn không nêu điều kiện này>.

2.3. Các điều kiện chấp nhận nguyên tử

Một điều kiện nguyên tử chỉ kiểm tra một kết quả chính. Sao chép nguyên khối bên dưới cho từng điều kiện cần thiết; mỗi khối phải có mã phụ duy nhất và không gộp nhiều kết quả độc lập vào một câu.

<Acceptance Criterion ID>-C01 — <tên ngắn của điều kiện kiểm tra>

• Tiền điều kiện: <dữ liệu tổng hợp, vai trò, trạng thái hồ sơ hoặc cấu hình mô phỏng phải tồn tại trước khi kiểm tra>.
• Thao tác kiểm tra: <các bước thao tác tối thiểu, theo thứ tự có thể lặp lại>.
• Kết quả mong đợi: <kết quả quan sát được, bao gồm giá trị, trạng thái, thông báo hoặc hành vi cần đạt>.
• Tiêu chí đạt: <điều kiện nhị phân để kết luận đạt, ví dụ giá trị hiển thị khớp nguồn hoặc trạng thái chuyển đúng trạng thái được yêu cầu>.
• Tiêu chí không đạt: <dấu hiệu cụ thể khiến điều kiện bị đánh dấu không đạt>.
• Phạm vi không kiểm tra: <nội dung chủ động loại trừ để tránh suy diễn vượt requirement nguồn>.

<Acceptance Criterion ID>-C02 — <tên ngắn của điều kiện kiểm tra>

• Tiền điều kiện: <điều kiện đầu vào cụ thể>.
• Thao tác kiểm tra: <thao tác hoặc sự kiện kích hoạt cụ thể>.
• Kết quả mong đợi: <kết quả có thể quan sát cụ thể>.
• Tiêu chí đạt: <điều kiện kết luận đạt cụ thể>.
• Tiêu chí không đạt: <dấu hiệu không đạt cụ thể>.
• Phạm vi không kiểm tra: <giới hạn kiểm tra cụ thể>.

2.4. Ràng buộc diễn đạt khi điền mẫu

Không dùng các từ như “nhanh”, “đúng”, “an toàn”, “thân thiện” hoặc “đầy đủ” nếu không nêu được cách quan sát và điều kiện kết luận. Ví dụ, thay vì viết <hệ thống xử lý nhanh>, điền <hệ thống hoàn tất phản hồi trong ngưỡng thời gian được requirement nguồn quy định>; nếu requirement nguồn chưa có ngưỡng, ghi <cần xác minh ngưỡng hiệu năng với vai trò có thẩm quyền>.

Không ghi bí mật thật vào mẫu. Khi acceptance criterion cần tham chiếu thông tin nhạy cảm, dùng mẫu tham chiếu an toàn: <secret-reference: tên-kho-bí-mật/định-danh-bí-mật/phiên-bản-tham-chiếu>; không điền mật khẩu, API key, token, chuỗi kết nối, số định danh cá nhân hoặc dữ liệu thật của Nova Foods. Mọi dữ liệu kiểm tra phải là dữ liệu tổng hợp, có nhãn mô phỏng và không được diễn đạt như bằng chứng về hệ thống ERP thực tế của Nova Foods.

Khung trống cho quyết định, ngoại lệ, bằng chứng, truy vết, versioning, review và sign-off

Mẫu này thuộc /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md và chỉ dùng cho Nova Foods mô phỏng, dữ liệu tổng hợp, không dùng dữ liệu thật. “Decision log” là nhật ký quyết định, “traceability” là truy vết, “sign-off” là xác nhận trách nhiệm cuối cùng. Mọi ô dưới đây phải giữ dạng <...> cho đến khi Tier 3 điền dữ liệu tổng hợp hợp lệ; không được xóa dòng nào vì mỗi dòng là một phần của kiểm soát chất lượng và kiểm soát nguồn gốc.

1) Bảng kiểm soát tài liệu và phiên bản

Trường	Giá trị chèn vào mẫu trống	Hướng dẫn cho người điền
Document ID	<TMPL-AC-001>	Giữ đúng định danh canonical của tài liệu.
Tên tệp	</03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md>	Ghi đúng đường dẫn kiểm soát của tệp.
Trạng thái	<IN_REVIEW>	Chỉ dùng giá trị trạng thái đã được kiểm soát trong corpus.
Phiên bản	<v0.9.0>	Không tự ý đổi số phiên bản trong mẫu trống.
Ngày cập nhật	<2026-08-07>	Dùng định dạng ngày theo YYYY-MM-DD.
Múi giờ	<Asia/Ho_Chi_Minh>	Ghi đúng múi giờ quản trị của corpus.
Locale	<vi-VN>	Ghi đúng locale áp dụng cho nội dung.
Đơn vị tiền tệ	<VND>	Chỉ là đơn vị trình bày trong case mô phỏng.
Phạm vi case	<Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp>	Luôn ghi rõ đây là mô phỏng, không phải vận hành thật.

2) Bảng nhật ký quyết định

Decision ID	Hạng mục quyết định	Câu hỏi cần chốt	Kết luận trống	Cơ sở xem xét	Người quyết định	Thời điểm	Trạng thái quyết định
<DEC-001>	<Decision topic>	<Câu hỏi nghiệp vụ cần quyết định>	<Pending>	<Nêu nguồn, quy tắc, hoặc giả định dự kiến>	<Role/Name>	<YYYY-MM-DD HH:MM>	<OPEN>
<DEC-002>	<Decision topic>	<Câu hỏi nghiệp vụ cần quyết định>	<Pending>	<Nêu nguồn, quy tắc, hoặc giả định dự kiến>	<Role/Name>	<YYYY-MM-DD HH:MM>	<OPEN>
<DEC-003>	<Decision topic>	<Câu hỏi nghiệp vụ cần quyết định>	<Pending>	<Nêu nguồn, quy tắc, hoặc giả định dự kiến>	<Role/Name>	<YYYY-MM-DD HH:MM>	<OPEN>

3) Bảng ngoại lệ

Exception ID	Mô tả ngoại lệ	Điều kiện kích hoạt	Ảnh hưởng	Hướng xử lý dự kiến	Chủ sở hữu xử lý	Trạng thái
<EXC-001>	<Mô tả trường hợp lệch chuẩn>	<Điều kiện phát sinh ngoại lệ>	<Ảnh hưởng tới nghiệp vụ, dữ liệu hoặc kiểm soát>	<Cách xử lý dự kiến>	<Role/Name>	<OPEN>
<EXC-002>	<Mô tả trường hợp lệch chuẩn>	<Điều kiện phát sinh ngoại lệ>	<Ảnh hưởng tới nghiệp vụ, dữ liệu hoặc kiểm soát>	<Cách xử lý dự kiến>	<Role/Name>	<OPEN>
<EXC-003>	<Mô tả trường hợp lệch chuẩn>	<Điều kiện phát sinh ngoại lệ>	<Ảnh hưởng tới nghiệp vụ, dữ liệu hoặc kiểm soát>	<Cách xử lý dự kiến>	<Role/Name>	<OPEN>

4) Bảng bằng chứng

Evidence ID	Loại bằng chứng	Tên bằng chứng	Nguồn phát sinh	Định dạng	Vị trí lưu trữ	Mối liên hệ với yêu cầu	Trạng thái
<EVD-001>	<Screenshot/Log/Export/Document>	<Tên bằng chứng>	<Hệ thống, cuộc họp, hay tài liệu nguồn>	<PDF/XLSX/PNG/MD/JSON>	<Đường dẫn lưu trữ>	<Requirement/Decision/Exception ID>	<RECEIVED>
<EVD-002>	<Screenshot/Log/Export/Document>	<Tên bằng chứng>	<Hệ thống, cuộc họp, hay tài liệu nguồn>	<PDF/XLSX/PNG/MD/JSON>	<Đường dẫn lưu trữ>	<Requirement/Decision/Exception ID>	<RECEIVED>
<EVD-003>	<Screenshot/Log/Export/Document>	<Tên bằng chứng>	<Hệ thống, cuộc họp, hay tài liệu nguồn>	<PDF/XLSX/PNG/MD/JSON>	<Đường dẫn lưu trữ>	<Requirement/Decision/Exception ID>	<RECEIVED>

5) Ma trận truy vết

Requirement ID	Acceptance Criterion ID	Decision ID	Exception ID	Evidence ID	Upstream source	Downstream artifact
<REQ-001>	<AC-001>	<DEC-001>	<EXC-001 hoặc none>	<EVD-001>	<CANONICAL_SOURCE_ID>	<Artifact/File/Section>
<REQ-002>	<AC-002>	<DEC-002>	<EXC-002 hoặc none>	<EVD-002>	<CANONICAL_SOURCE_ID>	<Artifact/File/Section>
<REQ-003>	<AC-003>	<DEC-003>	<EXC-003 hoặc none>	<EVD-003>	<CANONICAL_SOURCE_ID>	<Artifact/File/Section>

6) Bảng lịch sử phiên bản

Version	Ngày	Người cập nhật	Nội dung thay đổi	Lý do thay đổi	Tác động	Trạng thái
<v0.9.0>	<2026-08-07>	<Role/Name>	<Mô tả thay đổi>	<Lý do nghiệp vụ hoặc kỹ thuật>	<Low/Medium/High>	<IN_REVIEW>
<v0.9.1>	<YYYY-MM-DD>	<Role/Name>	<Mô tả thay đổi>	<Lý do nghiệp vụ hoặc kỹ thuật>	<Low/Medium/High>	<IN_REVIEW>
<v1.0.0>	<YYYY-MM-DD>	<Role/Name>	<Mô tả thay đổi>	<Lý do nghiệp vụ hoặc kỹ thuật>	<Low/Medium/High>	<PENDING_APPROVAL>

7) Bảng review

Review ID	Vai trò review	Người review	Ngày review	Kết luận review	Vấn đề ghi nhận	Hành động tiếp theo
<REV-001>	<BA/QA/Architect/Legal/Business Owner>	<Role/Name>	<YYYY-MM-DD>	<PASS/REVISE/REJECT>	<Issue summary>	<Next action>
<REV-002>	<BA/QA/Architect/Legal/Business Owner>	<Role/Name>	<YYYY-MM-DD>	<PASS/REVISE/REJECT>	<Issue summary>	<Next action>
<REV-003>	<BA/QA/Architect/Legal/Business Owner>	<Role/Name>	<YYYY-MM-DD>	<PASS/REVISE/REJECT>	<Issue summary>	<Next action>

8) Bảng sign-off

Sign-off ID	Vai trò xác nhận	Người xác nhận	Ngày xác nhận	Kết quả	Phạm vi xác nhận	Ghi chú
<SO-001>	<Owner/Reviewer/Approver>	<Role/Name>	<YYYY-MM-DD>	<APPROVED/NOT APPROVED>	<Scope of sign-off>	<Ghi chú kiểm soát>
<SO-002>	<Owner/Reviewer/Approver>	<Role/Name>	<YYYY-MM-DD>	<APPROVED/NOT APPROVED>	<Scope of sign-off>	<Ghi chú kiểm soát>
<SO-003>	<Owner/Reviewer/Approver>	<Role/Name>	<YYYY-MM-DD>	<APPROVED/NOT APPROVED>	<Scope of sign-off>	<Ghi chú kiểm soát>

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

Các trường dưới đây áp dụng cho mọi bản ghi Acceptance Criteria (tiêu chí chấp nhận): điều kiện có thể kiểm tra để xác định một yêu cầu hoặc phạm vi thay đổi có đạt kết quả mong đợi hay không. Người điền phải dùng dữ liệu của phạm vi đang phân tích; với Nova Foods Trading & Manufacturing, mọi dữ liệu chỉ là mô phỏng giáo dục và tổng hợp. Không suy diễn rằng giá trị mẫu, trạng thái review hoặc liên kết artifact tạo thành phê duyệt, baseline hay quyền triển khai production.

Trường template	Cách điền bằng placeholder mô tả	Giá trị được phép hoặc định dạng	Quy tắc kiểm tra
Acceptance Criteria ID	<ID tiêu chí chấp nhận đã đăng ký trong TRACEABILITY_ID_REGISTRY>	Chuỗi ID canonical đã đăng ký	Bắt buộc; không tự tạo biến thể ID; phải duy nhất trong phạm vi yêu cầu.
Requirement ID	<ID yêu cầu nguồn canonical>	ID tồn tại trong artifact nguồn được kiểm soát	Bắt buộc; một tiêu chí phải liên kết tối thiểu một yêu cầu; nếu không tìm thấy ID, ghi nhận vấn đề truy vết thay vì tự đoán.
Tên tiêu chí	<mệnh đề ngắn mô tả kết quả cần chấp nhận>	Tiếng Việt rõ nghĩa, một kết quả chính	Không dùng từ mơ hồ như “nhanh”, “đúng”, “thân thiện” nếu không có ngưỡng đo được.
Loại tiêu chí	<functional hoặc data hoặc integration hoặc security hoặc accessibility hoặc reporting hoặc auditability>	functional, data, integration, security, accessibility, reporting, auditability	Chọn một loại chính; nếu có nhiều loại, tách thành nhiều tiêu chí để test không bị nhập nhằng.
Mức ưu tiên	<Must hoặc Should hoặc Could>	Must, Should, Could	Must phải có bằng chứng kiểm thử trước khi có thể kết luận phạm vi đạt; mức ưu tiên không thay thế quyết định phê duyệt phạm vi.
Điều kiện trước	<trạng thái dữ liệu, vai trò, cấu hình hoặc sự kiện phải tồn tại trước khi kiểm tra>	Văn bản có thể xác minh	Bắt buộc nếu kết quả phụ thuộc quyền, trạng thái chứng từ, dữ liệu chủ hoặc tích hợp. Nếu không có điều kiện trước, ghi <Không có điều kiện trước; kiểm tra từ trạng thái khởi tạo xác định>.
Kích hoạt	<hành động người dùng hoặc sự kiện hệ thống bắt đầu kiểm tra>	Một hành động hoặc một sự kiện cụ thể	Không gộp nhiều hành động độc lập trong một trường; tách tiêu chí nếu mỗi hành động có kết quả riêng.
Kết quả mong đợi	<kết quả quan sát được, gồm dữ liệu hiển thị, trạng thái, thông báo hoặc bản ghi>	Câu khẳng định kiểm tra được	Phải chỉ rõ đối tượng, giá trị hoặc trạng thái cần quan sát; không dùng “hệ thống xử lý phù hợp”.
Quy tắc nghiệp vụ liên quan	<ID quy tắc từ CANONICAL_BUSINESS_RULES hoặc Verification required>	ID canonical hoặc Verification required	Không viết lại hoặc tự diễn giải quy tắc pháp lý, kế toán, thuế, an toàn thực phẩm hay bảo vệ dữ liệu cá nhân. Nếu chưa có rule canonical, ghi rõ cần xác minh chủ sở hữu thẩm quyền.
Dữ liệu kiểm thử	<tham chiếu bộ dữ liệu tổng hợp hoặc mô tả dữ liệu tổng hợp tối thiểu>	Chỉ dữ liệu tổng hợp	Không dùng tên thật, mã khách hàng thật, số tài khoản thật, token, mật khẩu, hóa đơn thật hoặc dữ liệu cá nhân thật.
Bằng chứng dự kiến	<loại bằng chứng và vị trí lưu trữ được kiểm soát>	ảnh chụp, log đã che thông tin, kết quả API đã che thông tin, báo cáo xuất, bản ghi audit	Bằng chứng phải cho phép đối chiếu tiêu chí nhưng không được chứa bí mật hoặc dữ liệu cá nhân không cần thiết.
Trạng thái kiểm tra	<NOT_RUN hoặc PASS hoặc FAIL hoặc BLOCKED hoặc NOT_APPLICABLE>	NOT_RUN, PASS, FAIL, BLOCKED, NOT_APPLICABLE	Chỉ dùng PASS khi bằng chứng đối chiếu được toàn bộ kết quả mong đợi. NOT_APPLICABLE phải nêu lý do và điều kiện khiến tiêu chí không áp dụng.
Ngoại lệ	<tình huống biên, lỗi nghiệp vụ, lỗi kỹ thuật hoặc trường hợp không áp dụng>	Mô tả cụ thể hoặc <Không có ngoại lệ được xác định tại thời điểm soạn>	Mỗi ngoại lệ phải nêu đầu vào, hành vi mong đợi và cách ghi nhận. Không biến ngoại lệ thành quy tắc mới nếu chưa có nguồn canonical.
Owner xác minh	<vai trò chịu trách nhiệm xác minh, không ghi tên cá nhân nếu chưa được cung cấp>	Ví dụ: QA, Business Owner, Security Reviewer, Accounting Owner	Vai trò phải phù hợp loại tiêu chí; người soạn template không tự xác nhận thay vai trò có thẩm quyền.
Ngày ghi nhận	<YYYY-MM-DD theo Asia/Ho_Chi_Minh>	Ngày hợp lệ theo ISO 8601	Không ghi ngày tương lai so với thời điểm thực hiện kiểm tra; dùng múi giờ quản trị Asia/Ho_Chi_Minh.
Nguồn và truy vết	<đường dẫn artifact canonical, ID nguồn, mục hoặc bảng liên quan>	Đường dẫn corpus và ID giữ nguyên	Tối thiểu phải truy ngược được tới requirement, rule, data definition hoặc quyết định nguồn. Liên kết không chứng minh approval.

Nhánh điều kiện theo loại tiêu chí: nếu Loại tiêu chí = integration, phải bổ sung <hệ thống nguồn>, <hệ thống đích>, <sự kiện trao đổi>, <mã phản hồi hoặc trạng thái xử lý> và <cách đối soát lỗi>. Nếu Loại tiêu chí = security, phải bổ sung <vai trò được phép>, <vai trò bị từ chối>, <tài nguyên được bảo vệ> và <bằng chứng không lộ bí mật>; tham chiếu OWASP chỉ là thực hành ngành, không phải kết luận tuân thủ. Nếu Loại tiêu chí = accessibility, phải nêu <công nghệ hỗ trợ hoặc thao tác bàn phím được kiểm tra> và <kết quả quan sát>; không tuyên bố đạt WCAG nếu chưa có đánh giá phù hợp. Nếu Loại tiêu chí = data hoặc reporting, phải nêu <nguồn dữ liệu>, <quy tắc tính hoặc ánh xạ>, <đơn vị VND nếu có giá trị tiền> và <cách đối soát tổng>.

Mẫu tham chiếu bí mật an toàn: chỉ ghi <secret-reference: vault-path/secret-name, quyền truy cập do Security Owner quản lý> hoặc <credential-reference: managed-identity-name>. Không điền mật khẩu, API key, access token, private key, chuỗi kết nối đầy đủ, số định danh cá nhân hoặc dữ liệu xác thực vào template, bằng chứng hay liên kết truy vết. Nếu tiêu chí không thể kiểm tra khi thiếu bí mật, đặt Trạng thái kiểm tra = BLOCKED, ghi <lý do chặn>, <vai trò cần xử lý> và <tham chiếu yêu cầu truy cập an toàn>; không sao chép bí mật để giải quyết trạng thái chặn.

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

Acceptance criteria (tiêu chí chấp nhận) là điều kiện có thể kiểm tra để xác định thay đổi ERP đáp ứng nhu cầu đã mô tả hay chưa. Hồ sơ dưới đây là case hoàn chỉnh của Nova Foods Trading & Manufacturing, là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

Trường lõi	Giá trị đã điền
Template ID	TMPL-AC-001
Acceptance Criteria Record ID	AC-NF-PO-001
Tiêu đề	Chặn xác nhận nhập kho khi số lượng thực nhận vượt số lượng còn mở của đơn mua
Status	IN_REVIEW
Version	v0.9.0
Ngày ghi nhận	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; VND
Tổ chức áp dụng	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Miền nghiệp vụ	Procurement to Inventory — từ mua hàng đến tồn kho
Loại tiêu chí	functional và data
Đối tượng kiểm thử	Chức năng xác nhận Goods Receipt (phiếu nhận hàng) của Nova Foods ERP mô phỏng
Trạng thái giao dịch đích	POSTED khi hợp lệ; REJECTED khi vượt số lượng còn mở
Phân loại dữ liệu	Dữ liệu giao dịch nội bộ mô phỏng; không chứa dữ liệu cá nhân, bí mật xác thực hoặc dữ liệu doanh nghiệp thực tế

3.1 Bối cảnh giao dịch mô phỏng

Nova Foods đặt mua thùng carton đóng gói từ nhà cung cấp mô phỏng An Phát Packaging. Đơn mua chỉ còn mở 120 THUNG; thủ kho nhập 125 THUNG. ERP phải ngăn xác nhận vì 125 THUNG > 120 THUNG, chênh 5 THUNG. Nếu hệ thống vẫn ghi nhận nhập kho, tồn kho và nghĩa vụ mua hàng mô phỏng sẽ cao hơn số lượng còn được phép nhận tại dòng đơn mua.

Thành phần	Giá trị mô phỏng hoàn chỉnh	Phân loại nguồn
Công ty	NF01 — Nova Foods Trading & Manufacturing	SIMULATED_PROJECT_FACT
Kho nhận hàng	WH-HCM-RM01 — Kho nguyên vật liệu TP.HCM	SIMULATED_PROJECT_FACT
Nhà cung cấp	SUP-AP-001 — An Phát Packaging	SIMULATED_PROJECT_FACT
Mã hàng	PKG-CTN-5KG-001 — Thùng carton 5 kg	SIMULATED_PROJECT_FACT
Đơn vị tính	THUNG	SIMULATED_PROJECT_FACT
Đơn mua	NF-PO-2026-0801-014	SIMULATED_PROJECT_FACT
Dòng đơn mua	NF-PO-2026-0801-014-L02	SIMULATED_PROJECT_FACT
Phiếu giao hàng nhà cung cấp	AP-DN-20260807-118	SIMULATED_PROJECT_FACT
Phiếu nhận hàng dự kiến	NF-GRN-2026-0807-032	SIMULATED_PROJECT_FACT
Ngày đặt hàng	2026-08-01	SIMULATED_PROJECT_FACT
Ngày nhận hàng	2026-08-07	SIMULATED_PROJECT_FACT
Số lượng đặt tại dòng đơn mua	300 THUNG	SIMULATED_PROJECT_FACT
Số lượng đã nhận trước giao dịch này	180 THUNG	SIMULATED_PROJECT_FACT
Số lượng còn mở trước giao dịch này	120 THUNG	SIMULATED_PROJECT_FACT
Số lượng thủ kho nhập để nhận	125 THUNG	SIMULATED_PROJECT_FACT
Đơn giá chưa bao gồm thuế	48.000 VND/THUNG	SIMULATED_PROJECT_FACT
Giá trị số lượng còn mở	5.760.000 VND	SIMULATED_PROJECT_FACT
Giá trị số lượng thủ kho nhập	6.000.000 VND	SIMULATED_PROJECT_FACT
Chênh lệch số lượng	5 THUNG	SIMULATED_PROJECT_FACT
Chênh lệch giá trị	240.000 VND	SIMULATED_PROJECT_FACT

3.2 Tác nhân và trách nhiệm trong tình huống

Actor ID	Tác nhân mô phỏng	Vai trò trong giao dịch	Hành động dự kiến	Kết quả hoặc trách nhiệm
USR-NF-WH-014	Nguyễn Minh Khoa	Warehouse Receiver — nhân viên nhận kho	Nhập số lượng thực nhận và yêu cầu xác nhận phiếu nhận hàng.	Không thể ghi nhận số lượng vượt số lượng còn mở; phải điều chỉnh số lượng hoặc chuyển chênh lệch cho bộ phận có trách nhiệm xử lý.
USR-NF-PR-006	Trần Bảo Ngọc	Procurement Officer — nhân viên mua hàng	Theo dõi số lượng còn mở của dòng đơn mua và xử lý thay đổi đơn mua nếu có nhu cầu hợp lệ.	Xác định có cần thay đổi đơn mua hay không; không dùng xác nhận nhận hàng để tự tăng số lượng đơn mua.
USR-NF-INV-003	Lê Quốc Huy	Inventory Controller — kiểm soát tồn kho	Đối soát chênh lệch giữa đơn mua, phiếu giao hàng và phiếu nhận hàng.	Có dữ liệu để xác định giao dịch bị chặn và nguyên nhân chênh lệch.
SYS-NF-ERP	Nova Foods ERP mô phỏng	Hệ thống xử lý	Kiểm tra số lượng còn mở trước khi ghi nhận tồn kho.	Chuyển giao dịch hợp lệ sang POSTED; từ chối giao dịch vượt số lượng còn mở bằng REJECTED.

3.3 Phân loại và ranh giới nguồn của hồ sơ

Source ID	Nguồn	Phân loại	Cách sử dụng trong hồ sơ
SRC-NF-SIM-PO-014	Dữ liệu đơn mua NF-PO-2026-0801-014 được tạo cho case học tập	SIMULATED_PROJECT_FACT	Cung cấp mã hàng, số lượng đặt, số lượng đã nhận, đơn giá và số lượng còn mở.
SRC-NF-SIM-DN-118	Phiếu giao hàng AP-DN-20260807-118 được tạo cho case học tập	SIMULATED_PROJECT_FACT	Cung cấp số lượng giao thực tế 125 THUNG vào ngày 2026-08-07.
SRC-NF-ASM-PO-001	Giả định dự án về kiểm soát không nhận vượt đơn mua	PROJECT_ASSUMPTION	Là cơ sở học tập cho nhu cầu kiểm tra số lượng; không phải quy định vận hành đã được phê duyệt.
CANONICAL_BUSINESS_RULES	Kế hoạch catalog quy tắc nghiệp vụ canonical của corpus	CONTROLLED_CORPUS_REFERENCE	Chỉ là liên kết quản trị; không xác nhận quy tắc cụ thể đã được baseline hoặc áp dụng thực tế.
CANONICAL_DATA_DICTIONARY	Kế hoạch từ điển dữ liệu logic canonical của corpus	CONTROLLED_CORPUS_REFERENCE	Dùng để giữ thuật ngữ đơn mua, dòng đơn mua, phiếu nhận hàng, số lượng và VND nhất quán.
ISO/IEC/IEEE 29148	ISO/IEC/IEEE 29148:2018, Edition 2	VERIFIED_PRIMARY_SOURCE	Tham chiếu phương pháp mô tả yêu cầu có thể kiểm tra; không viện dẫn điều khoản cụ thể vì chưa xác minh văn bản được cấp phép.
ISTQB CTFL Syllabus v4.0.1	ISTQB	VERIFIED_PRIMARY_SOURCE	Tham chiếu thuật ngữ kiểm thử và điều kiện kiểm tra; không thay thế quyết định nghiệp vụ Nova Foods.

Ranh giới áp dụng: Giá trị, mã giao dịch, con người, nhà cung cấp và hoạt động trong hồ sơ này đều là tổng hợp cho mục đích đào tạo. Hồ sơ ở trạng thái IN_REVIEW, không phải baseline, không thể hiện phê duyệt, không phải hướng dẫn triển khai production và không cấu thành kết luận pháp lý, kế toán, thuế hoặc tuân thủ.

Hồ sơ tiêu chí chấp nhận đã điền hoàn chỉnh — AC-NF-PO-001

Sự kiện kiểm tra: lúc xác nhận phiếu nhận hàng dự kiến NF-GRN-2026-0807-032, USR-NF-WH-014 nhập 125 THUNG cho dòng đơn mua NF-PO-2026-0801-014-L02. Hệ thống xác định số lượng còn mở là 120 THUNG, từ số lượng đặt 300 THUNG trừ số lượng đã nhận 180 THUNG.

Quy tắc mô phỏng: receivedQuantity của giao dịch xác nhận không được lớn hơn số lượng còn mở tại dòng đơn mua tại thời điểm hệ thống kiểm tra. Quy tắc là PROJECT_ASSUMPTION; Business Owner và Accounting Owner phải xác minh trước mọi sử dụng ngoài học liệu.

Acceptance Criterion ID	Điều kiện trước kiểm tra	Hành động của actor	Đối tượng hệ thống kiểm tra	Kết quả bắt buộc	Lý do và hệ quả
AC-NF-PO-001-C01	Dòng NF-PO-2026-0801-014-L02 có số lượng đặt 300 THUNG, đã nhận 180 THUNG, còn mở 120 THUNG.	USR-NF-WH-014 nhập 125 THUNG và yêu cầu xác nhận NF-GRN-2026-0807-032.	SYS-NF-ERP đọc số lượng còn mở của đúng dòng đơn mua trước khi ghi nhận tồn kho.	Hệ thống tính 125 - 120 = 5 THUNG vượt mức; không tạo giao dịch POSTED; đặt kết quả xác nhận là REJECTED.	Ngăn tồn kho và nghĩa vụ mua hàng mô phỏng tăng vượt chứng từ mua còn mở.
AC-NF-PO-001-C02	Cùng dữ liệu tại AC-NF-PO-001-C01.	USR-NF-WH-014 yêu cầu xác nhận số lượng vượt mức.	Thông báo kết quả cho người dùng nhập phiếu.	Hệ thống hiển thị lỗi nêu rõ số lượng nhập 125 THUNG, số lượng còn mở 120 THUNG và chênh lệch 5 THUNG.	Người nhận kho có căn cứ sửa số lượng hoặc yêu cầu bộ phận mua hàng xử lý thay đổi đơn mua; không phải suy đoán nguyên nhân từ lỗi chung.
AC-NF-PO-001-C03	Dòng đơn mua còn mở 120 THUNG; giao dịch trước đó bị REJECTED.	USR-NF-WH-014 sửa số lượng thực nhận thành 120 THUNG và yêu cầu xác nhận lại.	SYS-NF-ERP kiểm tra lại số lượng đã sửa với số lượng còn mở.	Hệ thống cho phép ghi nhận; trạng thái giao dịch là POSTED; số lượng nhận của giao dịch là 120 THUNG.	Phân biệt chặn dữ liệu vượt mức với chặn toàn bộ hoạt động nhận hàng hợp lệ.
AC-NF-PO-001-C04	Giao dịch 125 THUNG bị từ chối.	USR-NF-INV-003 đối soát đơn mua, phiếu giao hàng và kết quả xử lý phiếu nhận hàng.	Bản ghi giao dịch, số lượng nhập, số lượng còn mở, trạng thái và thông báo lỗi.	Hệ thống giữ kết quả REJECTED cùng dữ liệu kiểm tra đủ để đối soát giao dịch bị chặn.	Kiểm soát tồn kho cần bằng chứng về dữ liệu bị từ chối; thiếu bằng chứng làm chênh lệch khó giải thích.

Dữ liệu kiểm thử	Giá trị	Kết quả mong đợi	Authority hoặc giả định áp dụng
Số lượng đặt	300 THUNG	Là dữ liệu nguồn để tính số lượng còn mở.	SRC-NF-SIM-PO-014
Số lượng đã nhận	180 THUNG	Được trừ khỏi số lượng đặt.	SRC-NF-SIM-PO-014
Số lượng còn mở	120 THUNG	Là mức tối đa được phép xác nhận trong case này.	SRC-NF-SIM-PO-014
Số lượng nhập lần một	125 THUNG	Bị từ chối vì vượt 5 THUNG.	SRC-NF-SIM-DN-118; SRC-NF-ASM-PO-001
Số lượng nhập lần hai	120 THUNG	Được ghi nhận POSTED.	SRC-NF-ASM-PO-001
Đơn giá	48.000 VND/THUNG	Dùng diễn giải giá trị chênh lệch; không quyết định điều kiện chặn.	SRC-NF-SIM-PO-014
Giá trị chênh lệch	240.000 VND	Là 5 × 48.000 VND; dùng đối soát mô phỏng.	Dữ liệu tổng hợp của case

Quyết định nghiệp vụ cần xác minh: Procurement Officer xử lý thay đổi đơn mua khi có nhu cầu hợp lệ; Inventory Controller đối soát chênh lệch; hệ thống không được coi phiếu nhận hàng là cơ chế tự sửa số lượng đã cam kết trên đơn mua. Thẩm quyền xác nhận quy tắc này cho vận hành thực tế chưa được ghi nhận. Artifact giữ trạng thái IN_REVIEW.

Hồ sơ tiêu chí chấp nhận đã điền hoàn chỉnh — NF-AC-PRC-001

Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục, toàn bộ người dùng, mã giao dịch, số tiền và dữ liệu dưới đây là dữ liệu tổng hợp. Hồ sơ NF-AC-PRC-001 là ví dụ độc lập về Purchase Requisition; không thay thế hoặc sửa phạm vi của AC-NF-PO-001.

Trường lõi	Giá trị đã điền
Artifact ID	TMPL-AC-001
Acceptance Criteria ID	NF-AC-PRC-001
Tên chức năng	Kiểm soát tạo yêu cầu mua nguyên liệu bột mì
Phạm vi quy trình	Procurement — Purchase Requisition
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày ghi nhận	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; VND
Người khởi tạo mô phỏng	Nguyễn Minh An — Nhân viên Kế hoạch sản xuất
Vai trò quyết định nghiệp vụ mô phỏng	Trần Quốc Bảo — Procurement Manager
Phân loại nguồn	PROJECT_ASSUMPTION — quy tắc mô phỏng phục vụ học liệu, chưa phải quy định vận hành hoặc kế toán thực tế

Sự kiện nghiệp vụ: lúc 09:15 ngày 2026-08-07, Nguyễn Minh An tạo Phiếu yêu cầu mua PR-20260807-014 cho mã nguyên liệu RM-FLOUR-001, tên “Bột mì đa dụng 25 kg”, số lượng 120 bao, đơn giá dự kiến 365.000 VND/bao, thành tiền dự kiến 43.800.000 VND. Kho nhận dự kiến là WH-RM-HCM-01; ngày cần hàng là 2026-08-12; nhà cung cấp đề xuất là SUP-024 — Công ty TNHH Nguyên liệu An Phúc, là dữ liệu mô phỏng.

Hiện trạng mô phỏng: người dùng có thể lưu phiếu thiếu ngày cần hàng hoặc nhập số lượng bằng 0, làm bộ phận mua hàng phải trả lại phiếu qua email. Phiếu thiếu dữ liệu tối thiểu không xác định được thời điểm cần mua và khối lượng cần đặt; hệ thống phải chặn lưu trước khi phiếu vào luồng phê duyệt.

Quy tắc ID	Quy tắc đã điền	Điều kiện kiểm tra	Kết quả bắt buộc
NF-BR-PRC-001	Số lượng yêu cầu phải là số nguyên dương.	requestedQuantity = 0, -5 hoặc 12,5.	Không lưu phiếu; hiển thị “Số lượng phải là số nguyên lớn hơn 0.”
NF-BR-PRC-002	Ngày cần hàng không được sớm hơn ngày tạo phiếu.	requiredDate < 2026-08-07.	Không lưu phiếu; hiển thị “Ngày cần hàng phải bằng hoặc sau ngày tạo phiếu.”
NF-BR-PRC-003	Giá trị dự kiến bằng số lượng nhân đơn giá dự kiến.	120 × 365.000 VND.	Hệ thống tự tính và hiển thị 43.800.000 VND; người dùng không sửa trực tiếp trường thành tiền.
NF-BR-PRC-004	Phiếu có giá trị từ 30.000.000 VND phải chờ Procurement Manager phê duyệt trước khi chuyển mua hàng.	estimatedAmount = 43.800.000 VND.	Gán người phê duyệt mô phỏng là Trần Quốc Bảo; trạng thái chuyển thành PENDING_APPROVAL.

Trạng thái	Điều kiện vào trạng thái	Hành động được phép	Điều kiện ra trạng thái
DRAFT	Người dùng mở phiếu mới.	Nhập, sửa, lưu nháp, gửi phê duyệt.	Gửi khi bốn quy tắc dữ liệu hợp lệ.
PENDING_APPROVAL	Phiếu hợp lệ và giá trị 43.800.000 VND.	Procurement Manager phê duyệt hoặc từ chối.	Phê duyệt chuyển APPROVED; từ chối chuyển REJECTED.
APPROVED	Procurement Manager chọn phê duyệt.	Bộ phận mua hàng tạo đơn mua từ phiếu.	Tạo đơn mua chuyển CONVERTED_TO_PO.
REJECTED	Procurement Manager chọn từ chối và nhập lý do.	Người tạo sửa và gửi lại.	Gửi lại chuyển PENDING_APPROVAL.
CONVERTED_TO_PO	Đơn mua mô phỏng PO-20260807-008 được tạo từ phiếu.	Chỉ xem phiếu gốc.	Không có chuyển trạng thái tiếp theo trong phạm vi tiêu chí này.

Payload lưu phiếu hợp lệ:

Trường payload	Giá trị
requisitionId	PR-20260807-014
requesterId	USR-PLAN-003
materialId	RM-FLOUR-001
warehouseId	WH-RM-HCM-01
supplierSuggestionId	SUP-024
requestedQuantity	120
uom	BAG
estimatedUnitPrice	365000
currencyCode	VND
estimatedAmount	43800000
requestDate	2026-08-07
requiredDate	2026-08-12
status	PENDING_APPROVAL
approvalAssigneeId	USR-PRC-001

Nhu cầu nền tảng: Kế hoạch sản xuất cần phiếu yêu cầu mua có dữ liệu đủ, giá trị tính nhất quán và trạng thái rõ ràng để chuyển giao không phụ thuộc diễn giải thủ công. Hai lựa chọn đã xét là cho phép lưu mọi phiếu rồi kiểm tra bằng email, hoặc chặn dữ liệu không hợp lệ tại thời điểm lưu. Lựa chọn thứ hai được kiến nghị vì ngăn lỗi tại nguồn, giữ thành tiền có thể kiểm tra lại và chỉ chuyển phiếu đủ dữ liệu vào phê duyệt.

Trần Quốc Bảo là vai trò có thẩm quyền nghiệp vụ mô phỏng để quyết định ngưỡng phê duyệt; Principal IT Business Analyst chỉ ghi nhận tiêu chí, không xác nhận thẩm quyền hoặc phê duyệt thực tế. Nếu cấu hình sai, phiếu thiếu dữ liệu có thể được mua nhầm thời điểm, số lượng hoặc giá trị; ngược lại, áp ngưỡng phê duyệt sai có thể khiến giao dịch giá trị cao không được kiểm soát hoặc giao dịch giá trị thấp bị chậm không cần thiết. Các ngưỡng tiền tệ và vai trò trong hồ sơ này là PROJECT_ASSUMPTION; Business Owner và Accounting Owner cần xác minh trước mọi sử dụng ngoài mục đích học liệu.

Phân tích và quyết định cho tình huống mô phỏng kiểm soát hạn mức tín dụng

Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Giao dịch phân tích là đơn bán hàng SO-NF-20260807-0142, lập lúc 10:15 ngày 2026-08-07 theo Asia/Ho_Chi_Minh, cho khách hàng mô phỏng CUS-NF-00087 — Công ty TNHH Phân phối An Phúc. Tổng giá trị cần giao là 128.700.000 VND; dư nợ đang mở được giả lập là 385.000.000 VND; hạn mức tín dụng được giả lập là 450.000.000 VND.

Hạng mục	Nội dung đã điền	Phân loại nguồn	Cầu nối bằng chứng và suy luận
Sự kiện thực tế quan sát	Nhân viên Kinh doanh NV-SAL-014 — Lê Minh Anh tạo đơn SO-NF-20260807-0142; ERP mô phỏng chỉ cảnh báo khi tổng dư nợ sau đơn vượt hạn mức nhưng vẫn cho phép chuyển đơn sang READY_TO_SHIP.	Quan sát quy trình mô phỏng OBS-NF-AC-001, dữ liệu tổng hợp	385.000.000 + 128.700.000 = 513.700.000 VND, cao hơn 450.000.000 VND là 63.700.000 VND; cảnh báo đơn thuần không ngăn rủi ro tín dụng.
Hành vi hiện tại	Khi người dùng bấm xác nhận đơn, hệ thống hiện thông báo “Vượt hạn mức tín dụng” nhưng không tạo tác vụ phê duyệt, không khóa phiếu xuất kho và không lưu người chịu trách nhiệm chấp nhận rủi ro.	Quan sát quy trình mô phỏng OBS-NF-AC-001, dữ liệu tổng hợp	Không có trạng thái kiểm soát hoặc nhật ký quyết định; bộ phận Kho có thể giao hàng dù ngoại lệ tín dụng chưa được người có thẩm quyền quyết định.
Nhu cầu nền tảng	Cần biến cảnh báo thành điểm kiểm soát: đơn vượt hạn mức phải bị chặn giao hàng, chuyển đến đúng người có thẩm quyền, và chỉ được mở khóa bằng quyết định có lưu vết.	Suy luận BA INF-NF-AC-001	Nhu cầu suy ra từ chênh lệch 63.700.000 VND và khoảng trống kiểm soát; không phải kết luận về quy định pháp lý, kế toán hoặc chính sách tín dụng thực tế.
Quy tắc đề xuất	BR-PROJ-AC-001: Nếu Dư nợ đang mở + Giá trị đơn chờ giao > Hạn mức tín dụng đang hiệu lực, ERP đặt đơn ở CREDIT_HOLD, không cho tạo phiếu xuất kho, đồng thời tạo yêu cầu xem xét tín dụng.	Giả định dự án ASM-NF-AC-001	Điều kiện số học kiểm tra cùng thời điểm trước khi phát hành giao hàng. Business Owner và Accounting Owner phải xác minh trước khi dùng ngoài học liệu.
Ngoại lệ đã định nghĩa	Người có thẩm quyền có thể chọn APPROVE_OVERRIDE cho đúng đơn, ghi lý do tối thiểu 20 ký tự, giá trị vượt 63.700.000 VND, thời điểm quyết định và định danh người quyết định. Nếu từ chối, đơn chuyển CREDIT_REJECTED; nếu được duyệt, đơn chuyển CREDIT_RELEASED.	Giả định dự án ASM-NF-AC-002	Ngoại lệ không thay đổi hạn mức khách hàng; chỉ giải phóng một đơn cụ thể. Phân biệt này ngăn quyết định giao hàng vô tình sửa dữ liệu tín dụng dài hạn.

Phương án	Mô tả	Tiêu chí đánh giá	Kết quả
OPT-NF-AC-001	Giữ cảnh báo, cho phép Kinh doanh tiếp tục giao hàng.	Ngăn giao hàng vượt hạn mức; có truy vết người quyết định; giảm thao tác thủ công.	Không đạt: không ngăn giao hàng và không có quyết định được lưu vết.
OPT-NF-AC-002	Khóa toàn bộ khách hàng ngay khi vượt hạn mức, không cho bất kỳ đơn nào tiếp tục.	Ngăn giao hàng vượt hạn mức; phạm vi tác động tối thiểu; hỗ trợ ngoại lệ có kiểm soát.	Đạt kiểm soát nhưng không đạt phạm vi tối thiểu: có thể chặn cả các đơn đã được chấp thuận riêng.
OPT-NF-AC-003	Khóa từng đơn vượt hạn mức, tạo luồng xem xét và chỉ giải phóng chính đơn được quyết định.	Ngăn giao hàng vượt hạn mức; lưu vết đầy đủ; phạm vi tác động tối thiểu; người dùng xử lý được.	Đạt cả bốn tiêu chí.

Khuyến nghị: chọn OPT-NF-AC-003. Phương án chặn chính giao dịch tạo ra phần vượt 63.700.000 VND, cho phép ngoại lệ có trách nhiệm rõ ràng, và không biến quyết định cho một đơn thành thay đổi vĩnh viễn đối với hồ sơ khách hàng.

Quyết định cần có	Người có thẩm quyền quyết định	Trạng thái tại v0.9.0	Hệ quả nếu quyết định sai hoặc không được kiểm soát
Xác nhận ngưỡng áp dụng, đối tượng được cấp ngoại lệ và thời hạn hiệu lực ngoại lệ	Business Owner của quy trình Order-to-Cash, với Accounting Owner xác minh tác động tín dụng và hạch toán	IN_REVIEW; chưa có phê duyệt được ghi nhận	Nếu ngưỡng quá cao, Nova Foods mô phỏng có thể giao hàng khi khả năng thu hồi chưa được xem xét; nếu quá thấp, đơn hợp lệ bị chặn gây chậm giao hàng và tăng xử lý thủ công.
Xác nhận thiết kế trạng thái CREDIT_HOLD, CREDIT_RELEASED, CREDIT_REJECTED và kiểm soát quyền mở khóa	Solution Architect và Security Owner	IN_REVIEW; yêu cầu xác minh	Nếu quyền mở khóa cấp sai, người không có thẩm quyền có thể bỏ qua kiểm soát; nếu chuyển trạng thái sai, Kho có thể giao hàng cho đơn chưa được giải phóng.
Xác nhận cách hiển thị và lưu nhật ký quyết định ngoại lệ	Business Owner, QA Owner và Security Owner	IN_REVIEW; yêu cầu xác minh	Nếu không lưu lý do, người quyết định và thời điểm, không thể giải thích vì sao đơn vượt hạn mức được giao; nếu hiển thị dư nợ cho sai vai trò, dữ liệu tài chính mô phỏng bị lộ không cần thiết.

Quyết định trên là đề xuất của artifact /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md, không phải phê duyệt, baseline, chỉ dẫn production, diễn giải pháp lý hay kết luận kế toán.

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

Nova Foods là mô phỏng giáo dục, dùng dữ liệu tổng hợp VND theo vi-VN tại Asia/Ho_Chi_Minh. Với cùng một kịch bản đơn hàng bán ra có giá trị 68.200.000 VND vượt ngưỡng kiểm soát tín dụng 63.700.000 VND, phần này chỉ ghi nhận ngoại lệ, đường đi âm, bằng chứng và hồ sơ escalations cho quyết định xử lý, không mở rộng sang thiết kế đầy đủ traceability matrix ở micro-batch sau. “Ngoại lệ” ở đây là tình huống được xử lý khác luồng chuẩn; “đường đi âm” là trường hợp kiểm tra thất bại hoặc bị chặn; “evidence” là bằng chứng kiểm tra có thể truy vết; “escalation” là chuyển vấn đề lên vai trò có thẩm quyền cao hơn khi một quyết định chạm ranh giới trách nhiệm.

Mã tình huống	Điều kiện kích hoạt	Kết quả mong đợi	Bằng chứng tối thiểu cần có	Lý do kiểm soát
EXC-AC-001	Đơn hàng SO-NF-20260807-0142 có tổng giá trị 68.200.000 VND, vượt ngưỡng kiểm soát 63.700.000 VND	Hệ thống giữ trạng thái CREDIT_HOLD, không cho phát hành lệnh giao hàng tự động	Ảnh chụp màn hình trạng thái đơn, log workflow, mã quyết định ngoại lệ, thời gian xử lý theo giờ Asia/Ho_Chi_Minh	Ngăn giao hàng khi chưa có xác nhận thẩm quyền
EXC-AC-002	Người dùng vai trò Sales Clerk cố gắng duyệt ngoại lệ	Hệ thống từ chối, hiển thị thông báo không đủ quyền	Audit log, mã lỗi phân quyền, user role tại thời điểm thao tác	Tránh người không có thẩm quyền tự mở khóa tín dụng
EXC-AC-003	Dữ liệu dư nợ khách hàng không khớp giữa màn hình và nguồn đối soát tổng hợp	Hệ thống treo quyết định, chuyển sang kiểm tra thủ công	Bản ghi đối soát, timestamp, ảnh chụp hai nguồn dữ liệu, ticket kiểm tra	Không để quyết định ngoại lệ dựa trên dữ liệu mâu thuẫn

Đường đi âm	Bước kiểm tra	Mẫu dữ liệu tổng hợp	Kỳ vọng thất bại hợp lệ	Diễn giải kiểm soát
NEG-AC-001	Nhập đơn có giá trị 0 VND	SO-NF-20260807-0000	Bị từ chối vì đơn không hợp lệ về giá trị kinh doanh	Kiểm tra biên dữ liệu thấp nhất
NEG-AC-002	Nhập đơn thiếu mã khách hàng	SO-NF-20260807-0143	Bị chặn trước bước kiểm tín dụng	Không thể tính rủi ro khi thiếu khóa định danh
NEG-AC-003	Cố tình bấm nút “Release Credit” khi chưa có phê duyệt	Người dùng Sales Clerk	Hệ thống khóa thao tác và ghi log	Bảo vệ điểm kiểm soát quan trọng của quy trình

Nhóm bằng chứng	Mã bằng chứng	Tên tệp hoặc nguồn lưu	Nội dung phải nhìn thấy	Mục đích truy vết
Màn hình	EV-SCR-AC-001	/03-templates/evidence/2026-08-07/so-nf-20260807-0142-credit-hold.png	Trạng thái CREDIT_HOLD, số tiền 68.200.000 VND, thời điểm xử lý	Xác nhận hành vi giao diện đúng với quyết định kiểm soát
Nhật ký hệ thống	EV-LOG-AC-001	/03-templates/evidence/2026-08-07/audit-credit-decision.log	User, role, action, timestamp, decision code	Chứng minh ai làm gì và khi nào
Dữ liệu kiểm tra	EV-DATA-AC-001	/03-templates/evidence/2026-08-07/test-data-credit-limit.csv	Dòng dữ liệu synthetic có ngưỡng và giá trị vượt ngưỡng	Làm test basis cho kiểm thử âm và ngoại lệ
Ticket xử lý	EV-TCK-AC-001	/03-templates/evidence/2026-08-07/exception-escalation-001.md	Lý do escalations, người nhận, thời hạn phản hồi	Chứng minh đường đi ngoại lệ đã được chuyển đúng thẩm quyền

Các giả định dự án phải ghi rõ là giả định, không được biến thành quy tắc thật nếu chưa có xác minh: 63.700.000 VND là ngưỡng nghiệp vụ mô phỏng trong corpus, không đại diện cho hạn mức thật của Nova Foods; trạng thái CREDIT_HOLD là trạng thái thiết kế dùng cho học liệu, không hàm ý cấu hình ERP thực tế; vai trò Sales Clerk, Sales Manager, Accounting Owner là vai trò mô phỏng phục vụ phân rã trách nhiệm. Cách suy luận ở đây là: vì một quyết định vượt ngưỡng chạm cả quyền duyệt, tín dụng và ảnh hưởng giao hàng, nên phải tách thành giả định, bằng chứng và thẩm quyền thay vì hợp nhất chúng thành một kết luận đơn lẻ.

Mục cần xác minh	Vì sao phải xác minh	Vai trò xác minh	Trạng thái tại v0.9.0
Ngưỡng 63.700.000 VND có phải rule chính thức hay chỉ là giả lập học liệu	Nếu xác minh sai, acceptance criteria sẽ biến thành quy định vận hành không đúng thẩm quyền	Business Owner + Accounting Owner	VERIFICATION REQUIRED
Quyền mở khóa tín dụng có được gán cho đúng vai trò hay không	Đây là điểm kiểm soát nhạy cảm, dễ dẫn đến bypass quy trình	Solution Architect + Security Owner	VERIFICATION REQUIRED
Mẫu lưu audit log có đáp ứng yêu cầu truy vết tối thiểu hay không	Không có log thì không thể chứng minh quyết định ngoại lệ	QA Owner + Security Owner	VERIFICATION REQUIRED
Có phát sinh dữ liệu cá nhân trong log hoặc ảnh chụp màn hình hay không	Nếu có, phải gắn nhãn bảo vệ dữ liệu và xin xác minh pháp lý/đạo đức phù hợp	Legal Owner + Data Protection Owner	VERIFICATION REQUIRED

Hồ sơ escalations cho cùng kịch bản được ghi nhận như sau: khi đơn SO-NF-20260807-0142 vượt ngưỡng và người tạo đơn không có quyền duyệt, hệ thống phải chuyển lên Sales Manager để xem xét nghiệp vụ, đồng thời chuyển bản sao kiểm soát sang Accounting Owner nếu quyết định có thể ảnh hưởng công nợ; nếu dữ liệu đầu vào mâu thuẫn, escalation phải dừng ở trạng thái chờ xác minh thay vì tiếp tục giải phóng đơn. Mỗi escalation cần có mã riêng, người nhận, thời điểm, lý do và kết luận tạm thời; nếu thiếu một trong bốn yếu tố này thì bằng chứng chưa đủ để coi là đóng vòng kiểm soát.

Mã escalation	Nguồn kích hoạt	Người nhận	Lý do chuyển	Kết luận tạm thời
ESC-AC-001	Đơn vượt ngưỡng và cần duyệt ngoại lệ	Sales Manager	Cần thẩm quyền kinh doanh để quyết định có cho tiếp tục hay không	Chờ duyệt thủ công
ESC-AC-002	Quyền người dùng không đủ để mở khóa	Security Owner	Phát hiện thao tác vượt quyền	Từ chối và giữ nguyên trạng thái khóa
ESC-AC-003	Dữ liệu dư nợ không khớp giữa hai nguồn	Accounting Owner	Cần đối soát trước khi ra quyết định tín dụng	Tạm dừng xử lý, không phát hành giao hàng

Liên kết reasoning tối thiểu cho phần này là: khi một đơn vượt ngưỡng kiểm soát, hệ thống không được tự suy luận rằng “đơn vẫn hợp lệ” chỉ vì dữ liệu còn thiếu hoặc người dùng yêu cầu gấp; thay vào đó, phải giữ trạng thái khóa, tạo bằng chứng, đánh dấu phần chưa xác minh và escalations đúng vai trò. Cách làm này bảo đảm phần evidence của template không chỉ có ảnh chụp hay log, mà còn chứng minh được vì sao từng quyết định âm, ngoại lệ và chuyển giao thẩm quyền là cần thiết.

Ma trận truy vết đầu-cuối cho tình huống xác nhận đơn bán hàng có kiểm tra hạn mức tín dụng

Truy vết đầu-cuối (end-to-end traceability) là khả năng lần ngược từ kiểm thử hoặc tiêu chí chấp nhận về nhu cầu nghiệp vụ ban đầu, và lần xuôi từ nhu cầu đến dữ liệu, giao diện lập trình ứng dụng và kiểm thử. Ma trận dưới đây áp dụng cho Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp, tại trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Các liên kết là nội dung học liệu đang xem xét; không phải baseline, không phải phê duyệt và không xác nhận cấu hình ERP thực tế.

Thứ tự truy vết	ID và nội dung đã liên kết	Artifact hoặc vị trí kiểm soát	Phân loại nguồn và cầu nối suy luận
1	NEED-NF-AC-001 — Nhân viên bán hàng cần biết ngay khi xác nhận đơn hàng liệu tổng công nợ dự kiến của khách có vượt hạn mức tín dụng mô phỏng hay không, để không tạo đơn bán chịu ngoài mức kiểm soát nội bộ giả định.	/03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md, Tier 3 case record	Project assumption. Cầu nối: nhu cầu kiểm soát rủi ro bán chịu được biểu đạt thành nhu cầu hiển thị quyết định trước khi đơn được xác nhận; không suy diễn đây là nghĩa vụ pháp lý hay chính sách thực tế.
2	REQ-NF-AC-001 — Khi người dùng chọn Xác nhận đơn hàng, hệ thống phải tính Dư nợ hiện tại + Giá trị đơn hàng sau chiết khấu và so sánh với hạn mức tín dụng tổng hợp của khách hàng.	/03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md, Tier 3 case record	Kế thừa trực tiếp từ NEED-NF-AC-001: để biết đơn có vượt hạn mức, hệ thống cần một phép tính và một điểm kích hoạt xác định.
3	BR-NF-AC-001 — Đơn hàng chỉ có thể chuyển sang trạng thái CONFIRMED khi tổng công nợ dự kiến không lớn hơn hạn mức tín dụng; nếu lớn hơn, trạng thái đơn giữ là CREDIT_HOLD.	/01-curriculum/CANONICAL_BUSINESS_RULES.md — tham chiếu quy tắc mô phỏng đang IN_REVIEW	Project assumption. Cầu nối: REQ-NF-AC-001 yêu cầu so sánh; quy tắc này quy định kết quả nghiệp vụ của hai nhánh so sánh. Catalog có trạng thái IN_REVIEW, nên không được diễn đạt là quy tắc đã baseline hoặc đã được Business Owner phê duyệt.
4	AC-NF-AC-001 — Với khách hàng CUS-NF-001, hạn mức 50.000.000 VND, dư nợ 42.000.000 VND và đơn SO-NF-20260807-001 có giá trị sau chiết khấu 8.500.000 VND, khi xác nhận đơn thì hệ thống hiển thị CREDIT_HOLD; không tạo bản ghi xác nhận đơn.	/03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md, Tier 3 case record	Kế thừa từ BR-NF-AC-001: 42.000.000 + 8.500.000 = 50.500.000 VND, lớn hơn 50.000.000 VND. Vì tổng công nợ dự kiến vượt hạn mức, CREDIT_HOLD là kết quả đúng theo nhánh vượt hạn mức. Tiêu chí này là test basis mô phỏng đang IN_REVIEW, không xác nhận hành vi ERP thực tế.
5	DATA-NF-AC-001 — Customer.creditLimitVnd, Customer.outstandingBalanceVnd, SalesOrder.netAmountVnd, SalesOrder.creditCheckStatus, SalesOrder.status.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md — tham chiếu mô hình dữ liệu logic đang IN_REVIEW	Kế thừa từ phép tính tại REQ-NF-AC-001 và kết quả tại BR-NF-AC-001: ba trường tiền tệ là đầu vào tính toán; hai trường trạng thái lưu kết quả kiểm soát. Đây là tên dữ liệu logic cho học liệu, không xác nhận schema vật lý hay cấu hình ERP.
6	API-NF-AC-001 — POST /api/v1/sales-orders/SO-NF-20260807-001/confirm trả về 200 cùng creditCheckStatus: "CREDIT_HOLD" và status: "DRAFT" khi vượt hạn mức.	/03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md, liên kết API mô phỏng	Kế thừa từ BR-NF-AC-001: API là điểm giao tiếp kỹ thuật thực hiện hành vi “không chuyển sang CONFIRMED”. Mô tả HTTP là quy ước case study; chưa phải hợp đồng OpenAPI đã baseline.
7	TC-NF-AC-001 — Dùng CUS-NF-001: hạn mức 50.000.000 VND, dư nợ 42.000.000 VND; dùng SO-NF-20260807-001: giá trị sau chiết khấu 8.500.000 VND. Thao tác gọi xác nhận đơn; kết quả mong đợi là tổng dự kiến 50.500.000 VND, creditCheckStatus = CREDIT_HOLD, status = DRAFT, không có xác nhận đơn.	/03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md, liên kết test case mô phỏng	Kế thừa từ DATA-NF-AC-001, API-NF-AC-001 và BR-NF-AC-001: 50.500.000 VND > 50.000.000 VND, nên kiểm thử chứng minh nhánh vượt hạn mức bằng dữ liệu có thể tính lại độc lập. Thuật ngữ test case là trường hợp kiểm thử gồm dữ liệu, thao tác và kết quả mong đợi.
8	DEF — Chưa có bản ghi khiếm khuyết được liên kết.	Không tạo DEF trong phiên bản này.	Không phát minh defect khi chưa có kết quả thực thi kiểm thử ghi nhận lỗi. Việc không có DEF không chứng minh yêu cầu hoặc triển khai không có lỗi.
9	CR — Chưa có yêu cầu thay đổi được liên kết.	Không tạo CR trong phiên bản này.	Dữ liệu của AC-NF-AC-001 và TC-NF-AC-001 cùng dùng giá trị đơn 8.500.000 VND, tạo tổng 50.500.000 VND và cùng kiểm tra nhánh CREDIT_HOLD. Không có căn cứ để ghi nhận Change Request hoặc khẳng định thay đổi so với baseline, vì không có baseline reference.

Quy tắc kiểm tra liên kết: TC-NF-AC-001 chỉ đạt tính truy vết khi có thể lần ngược đủ chuỗi TC → API → DATA → AC → BR → REQ → NEED; mọi sửa đổi giá trị hạn mức, công thức, trạng thái hoặc endpoint phải rà lại toàn chuỗi này. Principal IT Business Analyst / Technical Curriculum Author phải ghi nhận và điều phối review khi phát hiện mâu thuẫn trong chuỗi; vai trò này không tự sửa quy tắc như một quyết định nghiệp vụ, không tạo approval và không xác nhận baseline.

Bảng quyết định và dữ liệu kiểm thử hoàn chỉnh cho case Nova Foods

Bảng quyết định (decision table) là cách biến các điều kiện nghiệp vụ thành các tổ hợp đầu vào và kết quả mong đợi có thể kiểm tra lặp lại. Trong case mô phỏng Nova Foods Trading & Manufacturing, bảng này phục vụ tiêu chí chấp nhận AC-NF-SO-001 của luồng tạo đơn bán hàng: hệ thống ERP chỉ cho phép xác nhận đơn khi khách hàng hoạt động, mặt hàng còn hiệu lực bán, số lượng hợp lệ và tổng giá trị đơn không vượt hạn mức tín dụng còn lại. Toàn bộ mã, tên, số tiền và dữ liệu dưới đây là dữ liệu tổng hợp cho mục đích giáo dục; không phải cấu hình hay quyết định vận hành thực tế. Artifact đang ở 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ệ VND; chưa có baseline hoặc approval reference.

Điều kiện / Hành động	C1: Đơn hợp lệ trong hạn mức	C2: Vượt hạn mức tín dụng	C3: Khách hàng không hoạt động	C4: Mặt hàng ngừng bán	C5: Số lượng không hợp lệ
Khách hàng có trạng thái ACTIVE	Có	Có	Không	Có	Có
Mặt hàng có trạng thái ACTIVE	Có	Có	Có	Không	Có
Số lượng đặt lớn hơn 0	Có	Có	Có	Có	Không
Tổng giá trị đơn nhỏ hơn hoặc bằng hạn mức tín dụng còn lại	Có	Không	Có	Có	Có
Tạo số đơn bán hàng	Có	Không	Không	Không	Không
Trạng thái đơn sau xử lý	CONFIRMED	CREDIT_HOLD	REJECTED	REJECTED	REJECTED
Mã kết quả nghiệp vụ	SO_CONFIRMED	SO_CREDIT_HOLD	SO_CUSTOMER_INACTIVE	SO_ITEM_INACTIVE	SO_INVALID_QUANTITY

Payload kiểm thử dưới đây là nội dung JSON tổng hợp dùng làm đầu vào cho dịch vụ tạo đơn bán hàng của case. customerCode, itemCode, số lượng và đơn giá được chọn để bao phủ đầy đủ năm cột quyết định; requestId là khóa đối chiếu riêng cho từng dữ liệu kiểm thử.

[
  {
    "requestId": "REQ-NF-SO-001",
    "orderDate": "2026-08-07",
    "currency": "VND",
    "customerCode": "CUS-NF-001",
    "customerStatus": "ACTIVE",
    "creditLimitRemaining": 50000000,
    "itemCode": "FG-NF-CHA-500",
    "itemStatus": "ACTIVE",
    "quantity": 100,
    "unitPrice": 180000,
    "orderTotal": 18000000
  },
  {
    "requestId": "REQ-NF-SO-002",
    "orderDate": "2026-08-07",
    "currency": "VND",
    "customerCode": "CUS-NF-002",
    "customerStatus": "ACTIVE",
    "creditLimitRemaining": 12000000,
    "itemCode": "FG-NF-CHA-500",
    "itemStatus": "ACTIVE",
    "quantity": 100,
    "unitPrice": 180000,
    "orderTotal": 18000000
  },
  {
    "requestId": "REQ-NF-SO-003",
    "orderDate": "2026-08-07",
    "currency": "VND",
    "customerCode": "CUS-NF-003",
    "customerStatus": "INACTIVE",
    "creditLimitRemaining": 90000000,
    "itemCode": "FG-NF-CHA-500",
    "itemStatus": "ACTIVE",
    "quantity": 20,
    "unitPrice": 180000,
    "orderTotal": 3600000
  },
  {
    "requestId": "REQ-NF-SO-004",
    "orderDate": "2026-08-07",
    "currency": "VND",
    "customerCode": "CUS-NF-004",
    "customerStatus": "ACTIVE",
    "creditLimitRemaining": 90000000,
    "itemCode": "FG-NF-NUOC-250",
    "itemStatus": "INACTIVE",
    "quantity": 30,
    "unitPrice": 25000,
    "orderTotal": 750000
  },
  {
    "requestId": "REQ-NF-SO-005",
    "orderDate": "2026-08-07",
    "currency": "VND",
    "customerCode": "CUS-NF-005",
    "customerStatus": "ACTIVE",
    "creditLimitRemaining": 90000000,
    "itemCode": "FG-NF-CHA-500",
    "itemStatus": "ACTIVE",
    "quantity": 0,
    "unitPrice": 180000,
    "orderTotal": 0
  }
]

Dữ liệu kiểm thử	Tổ hợp bảng quyết định	Kết quả mong đợi có thể quan sát	Cơ sở suy luận
REQ-NF-SO-001	C1	Hệ thống tạo đơn bán hàng và trả trạng thái CONFIRMED, mã SO_CONFIRMED, tổng tiền 18.000.000 VND.	Khách hàng và mặt hàng đều ACTIVE; 100 lớn hơn 0; 18.000.000 VND không vượt 50.000.000 VND hạn mức còn lại.
REQ-NF-SO-002	C2	Hệ thống không xác nhận đơn, trả trạng thái CREDIT_HOLD, mã SO_CREDIT_HOLD.	Ba điều kiện dữ liệu chủ thể và số lượng hợp lệ, nhưng 18.000.000 VND lớn hơn 12.000.000 VND hạn mức còn lại.
REQ-NF-SO-003	C3	Hệ thống không tạo đơn, trả trạng thái REJECTED, mã SO_CUSTOMER_INACTIVE.	customerStatus là INACTIVE; vì vậy điều kiện khách hàng hoạt động không đạt, dù tổng đơn thấp hơn hạn mức còn lại.
REQ-NF-SO-004	C4	Hệ thống không tạo đơn, trả trạng thái REJECTED, mã SO_ITEM_INACTIVE.	itemStatus là INACTIVE; vì vậy mặt hàng không đủ điều kiện bán trong case này.
REQ-NF-SO-005	C5	Hệ thống không tạo đơn, trả trạng thái REJECTED, mã SO_INVALID_QUANTITY.	quantity bằng 0, không thỏa điều kiện số lượng phải lớn hơn 0; tổng tiền bằng 0 không thay đổi kết luận này.

5. Tier 4 ? Senior BA Quality Gate

Senior BA Quality Gate là cổng kiểm tra chất lượng trước baseline: Senior Business Analyst (BA cấp cao) xác minh acceptance criteria có đủ rõ để kiểm thử và truy vết, đồng thời nhận diện nội dung vượt thẩm quyền BA. Cổng này chỉ tạo kết quả review tại trạng thái IN_REVIEW, không tạo baseline, không xác nhận tuân thủ và không hàm ý phê duyệt. Áp dụng cho Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND, phiên bản v0.9.0, ngày 2026-08-07.

Kết quả	Ý nghĩa	Hành động bắt buộc
PASS	Tiêu chí có bằng chứng kiểm tra được, không mâu thuẫn trong phạm vi review và nguồn/thẩm quyền đã được gắn đúng.	Giữ kết quả cùng liên kết truy vết; vẫn chờ các cổng review khác và không gọi là đã phê duyệt.
FAIL	Có lỗi xác định được nhưng có thể sửa trong artifact hoặc artifact phụ thuộc mà không phải dừng toàn bộ review.	Ghi lỗi, tác động, owner xử lý và điều kiện kiểm tra lại; không dùng dòng lỗi làm test basis.
STOP	Thiếu hoặc mâu thuẫn làm cho việc đánh giá, kiểm thử, truy vết hoặc quyết định phạm vi trở nên không đáng tin cậy.	Dừng review đối với acceptance criteria bị ảnh hưởng; bảo toàn phiên bản hiện tại, không tự suy diễn quy tắc thay thế.
ESCALATION	Vấn đề cần quyết định hoặc diễn giải từ vai trò có thẩm quyền ngoài Senior BA.	Lập gói escalation gồm vấn đề, bằng chứng, tác động, các câu hỏi quyết định và artifact liên quan; Senior BA không tự đưa ra kết luận thay vai trò chuyên môn.

Hạng mục kiểm tra	PASS khi	FAIL khi	STOP khi	Escalation đến
Tính đầy đủ	Mỗi acceptance criterion nêu rõ điều kiện đầu vào, hành vi/kết quả kỳ vọng, trạng thái hoặc mã kết quả quan sát được, và trường hợp ngoại lệ trong phạm vi.	Thiếu một thành phần nhưng có thể bổ sung từ requirement hoặc business rule đã liên kết.	Không xác định được phạm vi chức năng, kết quả cần chấp nhận hoặc dữ liệu tối thiểu để kiểm thử.	Business Owner khi phải quyết định phạm vi hay kết quả nghiệp vụ.
Tính nhất quán	Thuật ngữ, mã trạng thái, đơn vị tiền tệ, quy tắc tính và kết quả không mâu thuẫn giữa criterion, rule, data dictionary và test data liên kết.	Có khác biệt về nhãn, định dạng hoặc diễn đạt nhưng không đổi ý nghĩa nghiệp vụ.	Hai nguồn canonical yêu cầu hai kết quả khác nhau cho cùng điều kiện đầu vào.	Business Owner và Principal IT Business Analyst / Technical Curriculum Author; bổ sung Architect nếu mâu thuẫn liên quan thiết kế hệ thống.
Khả năng kiểm thử	Người kiểm thử độc lập có thể tạo dữ liệu, thực hiện hành động và so sánh actual result với expected result mà không phải đoán ý định. “Testable” nghĩa là kiểm thử được bằng quan sát hoặc đo đạc có thể lặp lại.	Kết quả dùng từ chủ quan như “nhanh”, “hợp lý”, “phù hợp” nhưng có thể thay bằng ngưỡng, trạng thái hoặc thông báo xác định.	Không có oracle kiểm thử, tức chuẩn để quyết định kết quả thực tế là đạt hay không đạt, hoặc criterion phụ thuộc vào phán đoán không được định nghĩa.	QA/Test Lead; Business Owner nếu cần định nghĩa tiêu chí chấp nhận nghiệp vụ.
Truy vết	Mỗi criterion liên kết được ngược đến requirement, business rule, quyết định hoặc nguồn phù hợp; liên kết xuôi đến test scenario/test case dự kiến. “Traceability” là khả năng lần theo quan hệ này theo cả hai chiều.	Có ID hoặc liên kết sai nhưng có thể sửa bằng artifact canonical.	Requirement hoặc rule nền tảng không tồn tại, ID không đăng ký, hoặc không thể xác định nguồn gốc của criterion.	Principal IT Business Analyst / Technical Curriculum Author; Business Owner khi thiếu quyết định nghiệp vụ gốc.
Thẩm quyền nguồn	Nguồn được phân loại đúng: nguồn chính thức, tài liệu dự án, giả định dự án hoặc Verification required; criterion không nâng suy luận thành nghĩa vụ pháp lý.	Có nguồn tham khảo nhưng phân loại chưa rõ hoặc ngày truy cập chưa được ghi phù hợp.	Criterion khẳng định nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật mà không có nguồn chính thức và owner chuyên môn xác minh.	Legal Owner, Accounting Owner, Compliance Owner, Security Owner hoặc Domain Owner tùy nội dung.
Ownership	Mỗi hành vi, dữ liệu, quyết định hold/reject/confirm và xử lý ngoại lệ có owner nghiệp vụ hoặc hệ thống được xác định; owner biết giới hạn thẩm quyền của mình.	Vai trò đã nêu nhưng trách nhiệm quyết định hoặc xử lý lỗi chưa rõ.	Một criterion yêu cầu Senior BA, QA hoặc kỹ thuật tự quyết định chính sách kinh doanh, pháp lý hay kế toán.	Business Owner; Legal, Accounting, Security hoặc Architect theo loại quyết định.
Ranh giới bảo mật và riêng tư	Criterion chỉ yêu cầu dữ liệu cần thiết, phân biệt dữ liệu cá nhân với dữ liệu nghiệp vụ, và nêu kết quả quan sát không làm lộ dữ liệu nhạy cảm. Tham chiếu OWASP ASVS hoặc OWASP API Security Top 10 chỉ là thực hành ngành, không phải luật Việt Nam.	Có nguy cơ lộ dữ liệu trong thông báo lỗi, log hoặc test evidence nhưng có thể giới hạn trường hiển thị.	Criterion yêu cầu hiển thị, lưu, truyền hoặc cấp quyền truy cập dữ liệu cá nhân/nhạy cảm mà chưa có căn cứ xử lý và kiểm soát được xác minh.	Security Owner và Legal/Privacy Owner; đối chiếu Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP khi phù hợp.
Ranh giới pháp lý, kế toán và hóa đơn/chứng từ	Criterion chỉ mô tả hành vi hệ thống trong case mô phỏng; mọi diễn giải luật, kế toán, thuế, hóa đơn hoặc chứng từ chưa xác minh được gắn Verification required hoặc giả định dự án.	Có thuật ngữ pháp lý/kế toán chưa chính xác nhưng chưa được dùng để quyết định hệ thống.	Criterion áp đặt bút toán, thuế suất, phát hành hóa đơn, thời hạn lưu trữ, nghĩa vụ truy xuất hoặc kết luận tuân thủ mà không có xác nhận của role có thẩm quyền.	Accounting Owner, Legal Owner, Tax Owner hoặc Food-safety Domain Owner; đối chiếu nguồn chính thức thích hợp, gồm Luật Kế toán và Nghị định 123/2020/NĐ-CP.
Tác động thay đổi	Mỗi thay đổi criterion xác định artifact, rule, dữ liệu, API, giao diện, test case, đào tạo hoặc báo cáo có thể bị ảnh hưởng; tác động được phân loại trước khi sửa.	Danh sách ảnh hưởng chưa đủ chi tiết nhưng có thể rà soát từ traceability hiện có.	Thay đổi làm đổi kết quả nghiệp vụ, quyền truy cập, cách tính tiền hoặc trạng thái đơn hàng nhưng không có đánh giá tác động và quyết định chủ sở hữu.	Business Owner, Architect, QA/Test Lead, Security Owner và Accounting Owner theo phạm vi tác động.

Quy tắc quyết định cổng: một dòng STOP có ưu tiên cao hơn mọi dòng PASS; một dòng ESCALATION không được đóng bằng nhận định của Senior BA. Khi chỉ có FAIL, artifact có thể được sửa và kiểm tra lại theo đúng liên kết truy vết. Khi phát hiện yêu cầu ngoài phạm vi giáo dục mô phỏng hoặc có nguy cơ bị hiểu là chỉ dẫn production, phải ghi nhận STOP và chuyển vấn đề đến owner phù hợp.

Ma trận kiểm tra chất lượng Senior BA: phạm vi, bằng chứng và ranh giới thẩm quyền

Senior BA Quality Gate là cổng rà soát trước baseline, nhằm xác định acceptance criteria (tiêu chí chấp nhận) có đủ rõ để kiểm thử, có liên kết được về nguồn và không vượt thẩm quyền chuyên môn hay pháp lý. Cổng này áp dụng cho /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là dữ liệu tổng hợp, vì vậy kết quả rà soát không xác nhận cấu hình ERP, tuân thủ hay khả năng vận hành thực tế.

Hạng mục kiểm tra	Câu hỏi kiểm tra từ nguyên tắc đầu tiên	Bằng chứng cần có trong acceptance criteria	Ranh giới quyết định và suy luận
Tính đầy đủ (completeness)	Người kiểm thử có thể hiểu đầy đủ điều kiện bắt đầu, hành động, kết quả mong đợi, dữ liệu đầu vào, ngoại lệ và trạng thái kết thúc mà không phải tự đoán không?	Mỗi tiêu chí phải nêu rõ actor hoặc hệ thống thực hiện, dữ liệu tổng hợp được dùng, điều kiện tiền đề, sự kiện kích hoạt, kết quả quan sát được và xử lý ngoại lệ liên quan.	Một câu “hệ thống xử lý đúng” không đủ vì không xác định được “đúng” là giá trị, trạng thái hay thông báo nào. Thiếu một thành phần làm tăng diễn giải chủ quan, nên cần trả về người soạn để bổ sung nội dung.
Tính nhất quán (consistency)	Các thuật ngữ, mã định danh, trạng thái, đơn vị tiền và quy tắc có cùng nghĩa tại mọi nơi không?	Tên Nova Foods, mã requirement, mã business rule, tên trường dữ liệu, trạng thái và giá trị VND phải khớp với nguồn canonical được liên kết.	Đối chiếu với TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY. Nếu cùng một khái niệm có hai tên hoặc hai giá trị mâu thuẫn, không được tự chọn cách hiểu; phải ghi nhận mâu thuẫn để chủ sở hữu nguồn canonical làm rõ.
Khả năng kiểm thử (testability)	Một người kiểm thử độc lập có thể tạo dữ liệu, thực hiện bước kiểm tra và xác định kết quả đạt hoặc không đạt bằng quan sát khách quan không?	Tiêu chí phải chứa điều kiện có thể đo hoặc xác minh: giá trị hiển thị, trạng thái lưu, quyền bị từ chối, bản ghi được tạo, thông báo lỗi, hoặc dữ liệu không được lộ.	“Nhanh”, “thân thiện”, “an toàn” không tự kiểm thử được nếu thiếu ngưỡng, kịch bản hoặc bằng chứng quan sát. Thuật ngữ kiểm thử dùng theo phạm vi thuật ngữ của ISTQB CTFL; không suy diễn thành kết quả kiểm thử thực tế.
Truy vết (traceability)	Có thể lần ngược từ tiêu chí về nhu cầu, requirement, quy tắc, dữ liệu và nguồn không; đồng thời lần xuôi sang test basis không?	Mỗi acceptance criterion phải có liên kết cụ thể đến artifact hoặc ID nguồn; liên kết phải giữ nguyên định danh và đường dẫn canonical khi được trích dẫn.	Truy vết không phải chỉ là ghi tên tài liệu. Chuỗi phải giải thích quan hệ: nhu cầu hoặc rule nào tạo ra tiêu chí nào, và tiêu chí đó xác minh kết quả nào. Liên kết hỏng, ID không đăng ký hoặc chỉ dẫn đến tài liệu không liên quan làm chuỗi bằng chứng không sử dụng được.
Thẩm quyền nguồn (source authority)	Nguồn được dùng có đủ thẩm quyền cho loại tuyên bố đang đưa vào tiêu chí không?	Nguồn chuẩn, pháp lý, nghiệp vụ hoặc kỹ thuật phải được phân loại rõ theo /00-research/00_SOURCE_MAP.md; URL và trạng thái nguồn phải giữ nguyên khi cần tham chiếu.	BABOK Guide hỗ trợ thuật ngữ và thực hành BA, không tạo nghĩa vụ pháp lý. OWASP ASVS và OWASP API Security Top 10 là chuẩn/thực hành bảo mật, không phải luật Việt Nam. ISO/IEC/IEEE 29148 chỉ được dùng trong phạm vi thông tin chính thức đã xác minh; không gán số điều khoản khi chưa kiểm tra văn bản được cấp phép.
Ownership (quyền sở hữu trách nhiệm)	Ai chịu trách nhiệm xác nhận nội dung nghiệp vụ, kỹ thuật, kiểm thử, pháp lý, kế toán và bảo mật; người soạn template có đang thay thế vai trò đó không?	Mỗi quyết định có ảnh hưởng phải nêu vai trò owner phù hợp, phạm vi trách nhiệm và giới hạn thẩm quyền; không dùng tên cá nhân hoặc tuyên bố đã được chấp thuận.	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc, ID và truy vết của artifact, nhưng không thay Business Owner, Architect, QA, Legal Owner, Accounting Owner, Security Owner hoặc Compliance Owner xác nhận nội dung chuyên môn.
Ranh giới bảo mật và quyền riêng tư	Tiêu chí có làm lộ dữ liệu cá nhân, bí mật xác thực, dữ liệu tài chính nhạy cảm hoặc mô tả kiểm soát bảo mật như đã triển khai không?	Chỉ dùng dữ liệu tổng hợp; không ghi mật khẩu, token, thông tin định danh cá nhân thật, khóa bí mật hoặc chi tiết khai thác. Yêu cầu bảo vệ dữ liệu phải gắn nhãn nguồn và vai trò xác minh.	Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý chính thức được liệt kê, nhưng việc chuyển thành yêu cầu hệ thống cần Legal Owner hoặc Compliance Owner xác minh. Không suy diễn tuân thủ từ việc có acceptance criterion.
Ranh giới pháp lý và kế toán	Tiêu chí có diễn đạt giả định nghiệp vụ như kết luận pháp lý, thuế, hóa đơn hoặc hạch toán bắt buộc không?	Mọi nội dung liên quan kế toán, hóa đơn, chứng từ hoặc lưu vết phải ghi rõ nguồn, phạm vi mô phỏng và nhãn Verification required khi chưa có xác minh của vai trò có thẩm quyền.	Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP là nguồn tham chiếu chính thức, nhưng không thay thế diễn giải của Accounting Owner hoặc Legal Owner. Acceptance criteria không được tự xác lập cách hạch toán, nghĩa vụ thuế hay hiệu lực hóa đơn.
Ranh giới an toàn thực phẩm và truy xuất	Tiêu chí truy xuất có phân biệt rõ ví dụ học liệu với quy trình thu hồi, kiểm soát chất lượng hoặc nghĩa vụ thực phẩm thực tế không?	Các tình huống lô hàng, nguyên liệu, thành phẩm hoặc truy xuất phải dùng mã và dữ liệu Nova Foods tổng hợp; liên kết ngữ cảnh đến Luật An toàn thực phẩm 55/2010/QH12 nếu nêu lý do cần xác minh.	Luật là bối cảnh cho nhu cầu truy xuất/thu hồi, không cho phép Senior BA tự xác định quy trình tuân thủ. Domain Owner và Legal Owner phải xác minh mọi yêu cầu được diễn đạt như nghĩa vụ áp dụng.
Tác động thay đổi (change impact)	Nếu tiêu chí, quy tắc, dữ liệu, quyền truy cập hoặc nguồn thay đổi, những artifact nào cần được rà soát lại?	Mỗi thay đổi phải nhận diện ít nhất requirement liên quan, acceptance criteria, test basis, business rule, data dictionary, API hoặc quy trình bị ảnh hưởng nếu có.	Suy luận tác động phải dựa trên liên kết truy vết đang tồn tại, không dựa vào phỏng đoán. Thay đổi một định nghĩa dữ liệu có thể làm thay đổi dữ liệu kiểm thử; thay đổi rule có thể làm thay đổi kết quả mong đợi; thay đổi nguồn pháp lý có thể cần Legal/Compliance Owner đánh giá lại.

Quy tắc diễn giải: Một acceptance criterion chỉ nên được coi là đủ điều kiện đi tiếp trong luồng rà soát khi toàn bộ thông tin cần cho người kiểm thử và người truy vết đã hiện diện, không có mâu thuẫn với nguồn canonical, và mọi kết luận vượt phạm vi BA đã được gắn đúng owner cùng nhãn xác minh. Việc ghi nhận các điều kiện này chỉ phản ánh chất lượng tài liệu tại thời điểm 2026-08-07; không phải baseline, phê duyệt, xác nhận pháp lý, xác nhận kế toán, xác nhận bảo mật hoặc cho phép triển khai production.

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

Ví dụ Tier 3 của TMPL-AC-001_ACCEPTANCE_CRITERIA.md được rà soát như một hồ sơ mô phỏng của Nova Foods Trading & Manufacturing, chỉ dùng dữ liệu tổng hợp tại Việt Nam, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND. Kết quả dưới đây là ghi nhận trước baseline tại 2026-08-07, trạng thái artifact IN_REVIEW, phiên bản v0.9.0; đây không phải phê duyệt, xác nhận tuân thủ hoặc cho phép triển khai production.

ID phát hiện	Điểm kiểm tra đã áp dụng	Bằng chứng và cầu nối suy luận	Kết quả	Hành động trước baseline
TMPL-AC-001-QG-01	Tính đầy đủ của criterion	Hồ sơ Tier 3 có mục tiêu nghiệp vụ, điều kiện trước, hành động người dùng, dữ liệu đầu vào, kết quả mong đợi, ngoại lệ và bằng chứng kiểm thử. Vì một tiêu chí chấp nhận phải cho phép xác định điều kiện đạt hoặc không đạt, các thành phần này tạo được điểm bắt đầu và điểm kết thúc cho kiểm thử.	PASS	Giữ nguyên cấu trúc hồ sơ khi chuyển thành test basis.
TMPL-AC-001-QG-02	Tính nhất quán dữ liệu và đơn vị tiền tệ	Giá trị tiền trong ví dụ được biểu diễn bằng VND; ngày và thời điểm dùng bối cảnh vi-VN và Asia/Ho_Chi_Minh. Vì dữ liệu đầu vào, kết quả tính toán và bằng chứng cùng một quy ước locale, người kiểm thử không phải tự đổi định dạng để suy luận kết quả.	PASS	Không thay đổi quy ước định dạng nếu chưa có thay đổi được kiểm soát.
TMPL-AC-001-QG-03	Khả năng kiểm thử (testability)	Kết quả mong đợi trong hồ sơ mô tả trạng thái hiển thị, thông báo lỗi hoặc bản ghi được tạo theo điều kiện đầu vào xác định. “Testability” là khả năng kiểm tra một yêu cầu bằng quan sát có thể lặp lại. Tuy nhiên, thời gian phản hồi và số người dùng đồng thời chưa có ngưỡng đo hoặc nguồn kiến trúc.	FAIL	Bổ sung criterion phi chức năng có số đo, môi trường đo và chủ sở hữu xác nhận; không tự đặt ngưỡng hiệu năng.
TMPL-AC-001-QG-04	Traceability từ criterion đến nguồn	Các liên kết traceability của hồ sơ dẫn về CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY. Cầu nối là criterion sử dụng quy tắc và trường dữ liệu đã được đặt tên tại các artifact canonical, thay vì tạo nguồn chân lý thứ hai trong template.	PASS	Đối chiếu lại liên kết khi các artifact nguồn đổi phiên bản.
TMPL-AC-001-QG-05	Thẩm quyền nguồn (source authority)	Các phần liên quan pháp lý, kế toán, hóa đơn, dữ liệu cá nhân và an toàn thực phẩm chỉ được gắn nhãn Verification required hoặc giả định dự án; không diễn đạt như kết luận pháp lý. Điều này phù hợp ranh giới nguồn tại /00-research/00_SOURCE_MAP.md, trong đó văn bản luật cần vai trò pháp lý hoặc chuyên môn được ủy quyền xác minh.	PASS	Duy trì nhãn xác minh cho đến khi có kết luận được ghi nhận bởi đúng vai trò có thẩm quyền.
TMPL-AC-001-QG-06	Ownership và quyết định nghiệp vụ	Hồ sơ phân biệt người thực hiện thao tác, Business Owner, QA reviewer, Architect, Security Owner, Legal Owner và Accounting Owner. Vì người viết template không có quyền thay các vai trò này quyết định, việc chỉ định trách nhiệm giúp ngăn suy diễn rằng Senior BA đã phê chuẩn nội dung chuyên môn.	PASS	Ghi nhận tên vai trò, không thay bằng tuyên bố đã được cá nhân phê duyệt.
TMPL-AC-001-QG-07	Ranh giới bảo mật và dữ liệu cá nhân	Ví dụ có giới hạn chỉ dùng dữ liệu tổng hợp, không dùng khách hàng thật, số điện thoại thật, địa chỉ thật hoặc thông tin định danh cá nhân thật. Đây là biện pháp giảm rủi ro cho học liệu; nó không chứng minh hệ thống ERP đáp ứng OWASP ASVS hoặc pháp luật bảo vệ dữ liệu cá nhân.	PASS	Security Owner xác minh yêu cầu quyền truy cập, nhật ký và bảo vệ dữ liệu nếu criterion được chuyển thành yêu cầu hệ thống.
TMPL-AC-001-QG-08	Ranh giới kế toán, thuế và hóa đơn	Các kết quả có tác động đến hạch toán, thuế hoặc hóa đơn trong ví dụ không được xác định là bút toán, mức thuế hay nghĩa vụ pháp lý chính thức. Vì /00-research/00_SOURCE_MAP.md nêu Luật Kế toán và Nghị định 123/2020/NĐ-CP cần xác minh chuyên môn hiện hành, template không đủ thẩm quyền để kết luận.	STOP	Không đưa criterion có tác động hạch toán, thuế hoặc hóa đơn vào baseline cho đến khi Accounting Owner và Legal Owner xác minh nguồn áp dụng và quyết định nghiệp vụ.
TMPL-AC-001-QG-09	Tác động thay đổi (change impact)	Hồ sơ xác định thay đổi đối với quy tắc nghiệp vụ hoặc trường dữ liệu có thể ảnh hưởng criterion, test case, dữ liệu kiểm thử và bằng chứng. Tuy nhiên, chưa có đánh giá tác động đối với tích hợp, phân quyền và báo cáo vì các dependency kỹ thuật chưa được xác nhận trong artifact nguồn.	ESCALATE	Principal IT Business Analyst / Technical Curriculum Author lập gói câu hỏi cho Architect, Security Owner và Business Owner; chỉ cập nhật traceability sau khi các vai trò này ghi nhận quyết định trong artifact được kiểm soát.

Kết luận ghi nhận: Ví dụ Nova Foods mô phỏng đủ điều kiện tiếp tục chỉnh sửa ở trạng thái IN_REVIEW, nhưng chưa đủ điều kiện đề xuất baseline do TMPL-AC-001-QG-08 có kết quả STOP. Điều kiện mở dừng là có xác minh được ghi nhận bởi Accounting Owner và Legal Owner cho ranh giới kế toán, thuế và hóa đơn; đồng thời TMPL-AC-001-QG-03 và TMPL-AC-001-QG-09 phải được xử lý bằng tiêu chí đo được và đánh giá tác động có truy vết.

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

6.1 Ma trận kiểm tra chéo tính nhất quán

Kiểm tra chéo (cross-file check) là đối chiếu một thông tin kiểm soát của template với nguồn quản trị được chỉ định để phát hiện mâu thuẫn: hai nguồn cùng áp dụng nhưng đưa ra hai giá trị hoặc hai quy tắc không thể cùng đúng. Việc thiếu một bằng chứng trong phần trích nguồn hiện có được ghi nhận là giới hạn bằng chứng, không tự động bị kết luận là mâu thuẫn. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi ví dụ và dữ liệu đều là dữ liệu tổng hợp.

Mã kiểm tra	Đối tượng đối chiếu	Bằng chứng và cầu nối suy luận	Kết quả tại 2026-08-07	Quy tắc áp dụng cho TMPL-AC-001
TMPL-AC-001-XF-01	Manifest template và nhận diện tệp	Tệp hiện hành có đường dẫn /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md; /01-curriculum/TEMPLATE_MANIFEST.md là nguồn quản trị danh mục template dự kiến. Cả phạm vi template manifest và tài liệu hiện hành đều thuộc corpus IT Business Analyst, dùng Nova Foods mô phỏng và dữ liệu tổng hợp.	Không có mâu thuẫn phạm vi được chứng minh từ nguồn đã cung cấp. Phần trích không hiển thị dòng đăng ký riêng của TMPL-AC-001, vì vậy không được tự khẳng định template đã được đăng ký hoặc baseline.	Giữ nguyên filename, ID TMPL-AC-001, trạng thái IN_REVIEW, phiên bản v0.9.0; không thay bằng tên dịch, tên rút gọn hoặc mã mới.
TMPL-AC-001-XF-02	CHAPTER_MANIFEST và TEMPLATE_MANIFEST	Hai manifest đều ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, bối cảnh Việt Nam và VND mô phỏng. Cùng một bộ giá trị quản trị không tạo xung đột trạng thái hay locale.	Phù hợp.	Ngày, tiền tệ, định dạng tiếng Việt và thời điểm kiểm soát trong criterion hoặc evidence phải theo vi-VN, Asia/Ho_Chi_Minh, VND; không suy ra nghĩa vụ vận hành thực tế.
TMPL-AC-001-XF-03	Registry định danh	/01-curriculum/TRACEABILITY_ID_REGISTRY.md xác định registry là nguồn canonical cho định danh và yêu cầu giữ nguyên chuỗi ID khi liên kết. Suy ra một acceptance criterion chỉ được liên kết bằng ID đã có trong artifact nguồn; template không có quyền cấp lại hoặc đổi nghĩa ID.	Phù hợp về nguyên tắc; không có bằng chứng nào cho phép tạo ID thay thế.	Mọi liên kết requirement, business rule, data field, test case và evidence phải giữ ID nguồn nguyên dạng. Không dùng một ID criterion để thay thế ID của quy tắc hoặc trường dữ liệu.
TMPL-AC-001-XF-04	Canonical business rules	/01-curriculum/CANONICAL_BUSINESS_RULES.md là catalog canonical của quy tắc nghiệp vụ và nêu rõ Owner không được tự xác nhận quy tắc là đúng cho vận hành thực tế. Acceptance criterion là điều kiện kiểm tra kết quả, không phải nguồn để phát minh hoặc phê duyệt quy tắc.	Phù hợp về ranh giới thẩm quyền.	Khi criterion phụ thuộc business rule, phải tham chiếu CANONICAL_BUSINESS_RULES và ID rule nguồn. Nếu nội dung rule chưa được xác minh, criterion phải giữ nhãn phù hợp thay vì diễn đạt thành quy tắc Nova Foods đã có hiệu lực.
TMPL-AC-001-XF-05	Canonical data dictionary	/01-curriculum/CANONICAL_DATA_DICTIONARY.md là nguồn canonical cho từ điển dữ liệu logic. Vì acceptance criterion có thể kiểm tra giá trị, trạng thái, định dạng hoặc khả năng hiển thị của dữ liệu, tên trường và nghĩa dữ liệu phải lấy từ từ điển thay vì do template đặt mới.	Không có mâu thuẫn nguyên tắc.	Không đổi tên trường, kiểu nghĩa logic hoặc phân loại dữ liệu trong acceptance criterion. Một criterion chỉ mô tả điều kiện đạt/không đạt dựa trên trường canonical đã được liên kết.
TMPL-AC-001-XF-06	Nguồn nghiên cứu và phân loại nguồn	/00-research/00_SOURCE_MAP.md phân loại BABOK, ISO/IEC/IEEE 29148, ISTQB CTFL, OpenAPI, WCAG, OWASP và văn bản Việt Nam theo ranh giới sử dụng an toàn. Nguồn này cấm bịa số trang, điều khoản hoặc kết luận pháp lý; đồng thời yêu cầu legal-owner verification đối với yêu cầu suy ra từ pháp luật.	Phù hợp nếu template chỉ dùng nguồn để định hướng thuật ngữ và kiểm thử, không gán hiệu lực pháp lý cho ví dụ.	Không ghi “tuân thủ pháp luật”, “đạt chuẩn”, hoặc trích điều khoản cụ thể nếu chưa có xác minh từ nguồn chính thức và vai trò có thẩm quyền.
TMPL-AC-001-XF-07	Chapter liên quan và consumer hạ nguồn	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md quy định chuỗi học từ requirement, acceptance criteria, traceability đến test basis; testing mini-book nhận đầu vào và không tự suy diễn business rule. Do đó criterion phải đủ rõ để làm test basis (cơ sở kiểm thử), nhưng không được tự trở thành test case hay cấu hình ERP.	Phù hợp với chuỗi tiêu thụ hạ nguồn.	Mỗi criterion hoàn chỉnh phải cho phép QA xác định điều kiện tiền đề, hành động, kết quả quan sát được và bằng chứng mong đợi; không được ép QA hoặc Architect suy đoán rule, dữ liệu, quyền truy cập hay tích hợp chưa được nguồn canonical xác định.
TMPL-AC-001-XF-08	Ranh giới authority và trạng thái	Tất cả artifact quản trị được cung cấp đều xác nhận IN_REVIEW không phải APPROVED, BASELINED, production-ready, compliant hoặc user-approved. Kết luận này nhất quán với Quality Gate trước đó của template, trong đó còn điều kiện STOP cho ranh giới kế toán, thuế và hóa đơn.	Không có mâu thuẫn; có ràng buộc bắt buộc phải giữ trạng thái review.	Không dùng acceptance criterion, evidence, kết quả kiểm tra hoặc việc hoàn tất template để tuyên bố approval, baseline, compliance, quyết định kế toán, quyết định pháp lý hay quyền triển khai production.

6.2 Quy tắc phân giải khi phát hiện mâu thuẫn

Nguồn có tính canonical quyết định định danh, tên trường và quy tắc trong phạm vi chuyên môn của chính nguồn đó: TRACEABILITY_ID_REGISTRY quyết định chuỗi ID; CANONICAL_BUSINESS_RULES quyết định tham chiếu quy tắc; CANONICAL_DATA_DICTIONARY quyết định nghĩa dữ liệu logic; manifest quyết định đường dẫn, phạm vi và metadata quản trị. Vì vậy, TMPL-AC-001 chỉ được phản ánh các giá trị này vào criterion, traceability và evidence; không được sửa nguồn canonical bằng cách ghi giá trị khác trong template.

Khi một criterion mâu thuẫn với nguồn canonical, kết quả kiểm tra của criterion là không đạt về tính nhất quán, dù kịch bản kiểm thử có thể cho ra kết quả kỹ thuật mong muốn. Lý do là một kết quả kỹ thuật không thể chứng minh tính đúng đắn của một ID, business rule hoặc nghĩa dữ liệu đã bị tham chiếu sai. Bản sửa phải bắt đầu từ artifact có thẩm quyền với loại thông tin đang mâu thuẫn, sau đó mới đồng bộ liên kết vào TMPL-AC-001 và consumer hạ nguồn.

Không được coi việc một tài liệu chưa có baseline hoặc chưa có approval là mâu thuẫn nội dung. Đây là trạng thái quản trị chung của corpus tại v0.9.0. Cho đến khi có tham chiếu baseline hoặc approval được ghi nhận minh bạch trong artifact kiểm soát, toàn bộ acceptance criteria của Nova Foods vẫn là học liệu mô phỏng đang xem xét, sử dụng dữ liệu tổng hợp và không thay thế thẩm quyền của Business Owner, Architect, QA, Security Owner, Accounting Owner, Legal Owner hoặc Compliance Owner.

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

Để bàn giao có kiểm soát, mỗi mục chưa được kết luận phải được phân loại rõ: vấn đề mở là điểm có mâu thuẫn hoặc thiếu quyết định; giả định dự án là điều tạm dùng cho ví dụ học liệu nhưng không được coi là sự thật vận hành; cần xác minh là nội dung chỉ được kết luận bởi vai trò có thẩm quyền và bằng chứng phù hợp. Sổ dưới đây là đầy đủ cho phạm vi TMPL-AC-001 tại IN_REVIEW, v0.9.0, ngày 2026-08-07; Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

ID theo dõi	Phân loại nguồn	Nội dung chưa kết luận và cầu nối bằng chứng	ID/tệp bị ảnh hưởng	Owner xử lý	Tác động nếu chưa xử lý	Hành động kế tiếp
OI-AC-001	Vấn đề mở	TMPL-AC-001 đang là template acceptance criteria, tức điều kiện kiểm tra để quyết định một yêu cầu có đạt hay không; nhưng TEMPLATE_MANIFEST và CHAPTER_MANIFEST đều ở IN_REVIEW, không có baseline hay approval reference. Vì vậy không có căn cứ để gọi bất kỳ tiêu chí Nova Foods nào là đã phê duyệt.	TMPL-AC-001; /01-curriculum/TEMPLATE_MANIFEST.md; /01-curriculum/CHAPTER_MANIFEST.md	Principal IT Business Analyst / Technical Curriculum Author	Tiêu chí có thể bị hiểu sai là cam kết triển khai hoặc bằng chứng chấp nhận production.	Giữ nhãn IN_REVIEW trên mọi tiêu chí đã điền; chỉ ghi nhận baseline hoặc approval khi artifact kiểm soát có tham chiếu minh bạch từ vai trò có thẩm quyền.
PA-AC-001	Giả định dự án	Các ví dụ trong Tier 3 sử dụng Nova Foods, vi-VN, Asia/Ho_Chi_Minh và VND vì metadata của TEMPLATE_MANIFEST, CHAPTER_MANIFEST và TRACEABILITY_ID_REGISTRY quy định bối cảnh này. Cầu nối suy luận là metadata corpus chỉ xác định bối cảnh học liệu, không xác nhận cấu hình ERP thực tế.	TMPL-AC-001; TEMPLATE_MANIFEST; CHAPTER_MANIFEST; TRACEABILITY_ID_REGISTRY	Business Owner Nova Foods mô phỏng	Nếu bị chuyển thành fact vận hành, learner có thể nhầm dữ liệu tổng hợp với dữ liệu doanh nghiệp thật.	Giữ cụm “mô phỏng giáo dục, dữ liệu tổng hợp” trong mọi acceptance criterion và evidence mẫu; không dùng dữ liệu cá nhân, hóa đơn thật hoặc số liệu vận hành thật.
VR-AC-001	Cần xác minh — pháp lý	Bất kỳ acceptance criterion nào suy ra nghĩa vụ bảo vệ dữ liệu cá nhân phải được Legal Owner xác minh theo Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP. Bằng chứng nguồn xác nhận văn bản chính thức và hiệu lực từ 2026-01-01, nhưng seed không cung cấp diễn giải điều khoản áp dụng cho một ERP cụ thể.	TMPL-AC-001; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; 00_SOURCE_MAP	Legal Owner	Diễn đạt điều kiện kiểm thử như nghĩa vụ pháp lý khi chưa có kết luận pháp lý có thể tạo tuyên bố tuân thủ sai.	Gắn Verification required; Legal Owner xác định phạm vi dữ liệu, căn cứ áp dụng và câu chữ được phép dùng trước khi tiêu chí pháp lý được đưa vào nội dung có tính quyết định.
VR-AC-002	Cần xác minh — kế toán/thuế	Tiêu chí liên quan hạch toán, chứng từ hoặc hóa đơn cần Accounting Owner và Legal Owner xác minh. Cầu nối bằng chứng: seed có Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP, đồng thời nêu rõ diễn giải kế toán cần vai trò được ủy quyền và phải kiểm tra sửa đổi trước khi dùng production.	TMPL-AC-001; CANONICAL_BUSINESS_RULES; 00_SOURCE_MAP	Accounting Owner, Legal Owner	Tiêu chí có thể biến ví dụ học liệu thành hướng dẫn hạch toán, thuế hoặc hóa đơn không được xác nhận.	Không gán trạng thái “đạt tuân thủ” cho tiêu chí; chuyển câu hỏi áp dụng, sửa đổi văn bản và cách diễn giải tới Accounting Owner và Legal Owner để có kết luận được ghi nhận.
VR-AC-003	Cần xác minh — an toàn thực phẩm và truy xuất	Tiêu chí về truy xuất lô hoặc thu hồi thực phẩm chỉ có thể dùng như bối cảnh mô phỏng. Cầu nối bằng chứng là Luật An toàn thực phẩm 55/2010/QH12 được seed xác định cho ngữ cảnh truy xuất/thu hồi, nhưng yêu cầu domain-owner và legal verification.	TMPL-AC-001; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; 00_SOURCE_MAP	Food Safety Domain Owner, Legal Owner	Có nguy cơ diễn giải một ví dụ acceptance criterion thành quy trình thu hồi thực tế hoặc xác nhận an toàn thực phẩm.	Gắn Verification required cho mọi rule/criterion về lô, hạn dùng, truy xuất và thu hồi; chỉ thay nhãn này bằng tham chiếu kết luận của Food Safety Domain Owner và Legal Owner.
VR-AC-004	Cần xác minh — kiểm thử và chất lượng	Thuật ngữ kiểm thử hộp đen (black-box testing, kiểm thử theo đầu vào/đầu ra quan sát được thay vì mã nguồn) có thể tham chiếu ISTQB CTFL Syllabus v4.0.1. Tuy nhiên, syllabus là nguồn thuật ngữ và kỹ thuật; nó không tự xác nhận test case, test data hay kết quả đạt của Nova Foods.	TMPL-AC-001; 00_SOURCE_MAP	QA Owner	Nếu thiếu test basis và bằng chứng chạy kiểm thử, một criterion có thể bị gắn “pass” chỉ vì đã viết đúng cấu trúc.	QA Owner liên kết từng criterion với test basis, dữ liệu tổng hợp, kết quả mong đợi và bằng chứng kiểm thử trước khi ghi nhận trạng thái kết quả.
VR-AC-005	Cần xác minh — bảo mật và kiến trúc	OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 là chuẩn/good practice bảo mật, không phải luật Việt Nam; OpenAPI Specification 3.1.1 là nguồn chuẩn cho mô tả HTTP API. Vì seed không chứa thiết kế API, phân quyền hay kiến trúc Nova Foods, không thể suy ra tiêu chí bảo mật hoặc API đã đạt.	TMPL-AC-001; CANONICAL_DATA_DICTIONARY; 00_SOURCE_MAP	Security Owner, Solution Architect	Tiêu chí có thể sai phạm vi, nhầm good practice với nghĩa vụ pháp lý, hoặc xác nhận kiểm soát kỹ thuật chưa tồn tại.	Security Owner và Solution Architect xác định phạm vi giao diện, dữ liệu, quyền truy cập và bằng chứng kỹ thuật; chỉ sau đó mới liên kết criterion với nguồn OWASP hoặc OAS phù hợp.
VR-AC-006	Cần xác minh — khả năng tiếp cận	WCAG 2.2 là khuyến nghị chuẩn cho khả năng tiếp cận (accessibility, khả năng người dùng có nhu cầu hỗ trợ vẫn sử dụng được giao diện), nhưng seed yêu cầu mọi tuyên bố về success criterion phải khớp nguồn. Không có đặc tả giao diện hay kết quả kiểm thử hỗ trợ trong đầu vào.	TMPL-AC-001; 00_SOURCE_MAP	UX Owner, QA Owner	Không được tuyên bố giao diện Nova Foods “đạt WCAG 2.2” chỉ dựa trên template.	Chỉ dùng yêu cầu accessibility ở dạng Verification required; UX Owner xác định phạm vi giao diện, QA Owner xác định phương pháp và bằng chứng kiểm thử tương ứng.

Quy tắc bàn giao cuối và lan truyền thay đổi có kiểm soát

Việc bàn giao (handoff, chuyển giao đầu vào có truy vết cho vai trò hoặc artifact kế tiếp) của /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md chỉ chuyển gói học liệu mô phỏng Nova Foods Trading & Manufacturing, sử dụng dữ liệu tổng hợp, không chuyển quyền quyết định vận hành ERP. Cơ sở áp dụng là metadata của các artifact nguồn đều ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và không có baseline hoặc approval reference; vì vậy, gói bàn giao phải giữ nguyên trạng thái IN_REVIEW, không được gắn nhãn “đã phê duyệt”, “đã baseline”, “sẵn sàng production” hoặc “tuân thủ”.

Thành phần bàn giao	Giá trị phải giữ nguyên	Bên nhận sử dụng	Ranh giới sử dụng
Artifact chính	TMPL-AC-001; /03-templates/TMPL-AC-001_ACCEPTANCE_CRITERIA.md; IN_REVIEW; v0.9.0	Tác giả chapter, tác giả template liên quan, QA reviewer	Dùng làm mẫu học acceptance criteria; không là test case production hoặc cam kết nghiệm thu thực tế.
Nguồn định danh	TRACEABILITY_ID_REGISTRY; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	Chỉ registry quyết định cấu trúc và tính duy nhất của ID; không tự đổi, tái sử dụng hoặc tạo biến thể ID trong template.
Nguồn quy tắc và dữ liệu	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Business Owner, Accounting Owner, Legal Owner, Security, Architect khi thuộc phạm vi của họ	Template chỉ tham chiếu; không diễn giải thành quy tắc vận hành, kết luận pháp lý, kế toán, bảo mật hoặc kiến trúc.
Danh mục điều phối	TEMPLATE_MANIFEST; CHAPTER_MANIFEST; 01_CURRICULUM_ARCHITECTURE	Curriculum owner và tác giả artifact phụ thuộc	Dùng để định tuyến thay đổi và bảo toàn filename, dependency, phạm vi học tập; không tạo baseline.

Mỗi lần phát hiện nhu cầu sửa nội dung, người ghi nhận phải tạo một yêu cầu thay đổi có truy vết trước khi sửa artifact. Yêu cầu phải nêu: artifact nguồn gây thay đổi, ID bị ảnh hưởng, loại ảnh hưởng, lý do, bằng chứng liên kết và vai trò có thẩm quyền cần xem xét. Suy luận này xuất phát từ việc TRACEABILITY_ID_REGISTRY là nguồn canonical cho định danh, còn CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là nguồn canonical theo miền nội dung; do đó sửa trực tiếp acceptance criterion mà không liên kết về nguồn sẽ làm đứt đường truy vết.

Tác nhân thay đổi	Điều kiện kích hoạt	Lan truyền bắt buộc	Người điều phối	Quyết định thuộc thẩm quyền
Đổi ID, filename hoặc liên kết traceability	Registry thay đổi hoặc phát hiện ID không còn hợp lệ	Cập nhật mọi liên kết trong TMPL-AC-001, template/chapter nhận liên kết và manifest liên quan	Principal IT Business Analyst / Technical Curriculum Author	Registry owner xác nhận định danh; Owner chỉ điều phối, không tự phê duyệt nội dung nghiệp vụ.
Đổi quy tắc nghiệp vụ hoặc điều kiện chấp nhận	CANONICAL_BUSINESS_RULES thay đổi hoặc phát hiện diễn giải khác nhau	Rà soát criterion, expected result, exception và traceability link bị ảnh hưởng	Principal IT Business Analyst / Technical Curriculum Author	Business Owner xác nhận ý nghĩa nghiệp vụ; Accounting Owner hoặc Legal Owner tham gia nếu nội dung thuộc kế toán hoặc pháp lý.
Đổi tên trường, kiểu dữ liệu, giá trị miền hoặc phân loại dữ liệu	CANONICAL_DATA_DICTIONARY thay đổi	Rà soát dữ liệu đầu vào, kết quả mong đợi, dữ liệu kiểm thử tổng hợp và liên kết downstream	Principal IT Business Analyst / Technical Curriculum Author	Data/Architect owner xác nhận mô hình; Security owner xác nhận khi có phân loại hoặc kiểm soát dữ liệu.
Đổi cấu trúc template hoặc quan hệ chapter-template	TEMPLATE_MANIFEST, CHAPTER_MANIFEST hoặc 01_CURRICULUM_ARCHITECTURE thay đổi	Đồng bộ tên tệp, phạm vi, dependency và hướng dẫn sử dụng cho consumer bị ảnh hưởng	Principal IT Business Analyst / Technical Curriculum Author	Curriculum owner quyết định cấu trúc học liệu; không quyết định requirement Nova Foods thực tế.

Quy tắc lan truyền là “nguồn trước, bản sao sau”: chỉ cập nhật diễn giải tại TMPL-AC-001 sau khi nguồn canonical tương ứng đã có thay đổi được ghi nhận đúng thẩm quyền. Nếu một acceptance criterion chạm đồng thời quy tắc nghiệp vụ và dữ liệu, phải gửi cùng một gói thay đổi đến các owner liên quan thay vì để một người tự kết luận toàn bộ. Lý do là mỗi owner chỉ có thẩm quyền trong miền chuyên môn của mình; việc gom kết luận pháp lý, kế toán, bảo mật, kiến trúc và nghiệp vụ vào một vai trò BA sẽ vượt authority boundary (ranh giới thẩm quyền).

Khi bàn giao cho downstream consumer (artifact hoặc vai trò sử dụng đầu ra ở bước sau), gói phải gồm liên kết tới artifact chính, phiên bản, trạng thái, danh sách ID được tham chiếu và cảnh báo rằng mọi ví dụ Nova Foods là mô phỏng. Bên nhận được phép dùng gói để soạn học liệu, lập kế hoạch kiểm thử hoặc thực hiện review; bên nhận không được suy diễn acceptance criterion thành phê duyệt người dùng, quyết định cấu hình ERP, nghĩa vụ pháp lý hoặc tiêu chí nghiệm thu production. Mọi thay đổi hoàn tất theo quy trình này vẫn giữ IN_REVIEW tại v0.9.0 cho đến khi một tham chiếu baseline hoặc approval hợp lệ được ghi minh bạch bởi vai trò có thẩm quyền.