/01-curriculum/01_CURRICULUM_ARCHITECTURE.md — Curriculum Architecture for IT BUSINESS ANALYST — ZERO TO DELIVERY READY

1. H1 title và metadata quản trị artifact

Artifact Governance Metadata

Trường kiểm soát	Giá trị kiểm soát
Artifact ID	01_CURRICULUM_ARCHITECTURE
Tên tệp được kiểm soát	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md
Tiêu đề artifact	Curriculum Architecture for IT BUSINESS ANALYST — ZERO TO DELIVERY READY
Status	IN_REVIEW
Version	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Trách nhiệm Owner	Duy trì cấu trúc curriculum architecture, kiểm soát phiên bản, ghi nhận đầy đủ lịch sử thay đổi, bảo toàn định danh artifact và điều phối các thay đổi có ảnh hưởng đến handbook hoặc template library.
Giới hạn thẩm quyền Owner	Owner không có quyền tự xác nhận baseline, approval, legal/compliance sign-off, quyết định kế toán, quyết định vận hành Nova Foods hoặc quyết định triển khai production.
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Phân loại artifact	Controlled planning artifact cho curriculum architecture
Change history hiện hành	Khởi tạo tại v0.9.0 ngày 2026-08-07; thiết lập metadata quản trị cho /01-curriculum/01_CURRICULUM_ARCHITECTURE.md ở trạng thái IN_REVIEW.
Baseline reference	Chưa có baseline reference tại phiên bản hiện hành.
Approval reference	Chưa có approval reference tại phiên bản hiện hành.

Version	Ngày	Status	Người ghi nhận	Nội dung thay đổi	Tác động kiểm soát
v0.9.0	2026-08-07	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo artifact governance metadata, định danh file, ownership, locale quản trị và change-history record đầu tiên cho kiến trúc curriculum.	Không tác động baseline vì artifact chưa có baseline reference.

Quy tắc quản trị metadata

1. Mọi sửa đổi controlled content phải tạo hoặc cập nhật một dòng change history với version, ngày, người ghi nhận, mô tả thay đổi và tác động kiểm soát. Không được thay thế nội dung cũ mà không để lại dấu vết thay đổi.
2. v0.9.0 là định danh phiên bản hiện hành duy nhất của artifact này. Không được dùng version không có trong change history để tham chiếu, liên kết chéo hoặc suy luận trạng thái.
3. Trường Status phải luôn phản ánh trạng thái kiểm soát thực tế. Tại thời điểm 2026-08-07, trạng thái cố định là IN_REVIEW; không được đổi thành trạng thái khác chỉ bằng cách sửa nội dung mà không cập nhật metadata và change history.
4. Owner chịu trách nhiệm về tính toàn vẹn quản trị của artifact, không đồng nghĩa Owner là người phê duyệt nội dung chuyên môn, pháp lý, kế toán, compliance hoặc production.
5. Mọi metadata được ghi theo ngày YYYY-MM-DD; bối cảnh thời gian là Asia/Ho_Chi_Minh. Các ví dụ Nova Foods chỉ dùng dữ liệu tổng hợp và không được diễn giải là dữ liệu, quyết định hoặc xác nhận của doanh nghiệp thực.

Tuyên bố trạng thái lập kế hoạch, baseline và thẩm quyền review

Artifact /01-curriculum/01_CURRICULUM_ARCHITECTURE.md tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, là bản kế hoạch kiến trúc curriculum trước khi drafting nội dung chính cho handbook và template library IT BUSINESS ANALYST — ZERO TO DELIVERY READY. Mục đích của bản kế hoạch là xác định cách tổ chức nội dung sẽ được soạn thảo sau đó; nó không xác nhận rằng các chapter, capability gate, assessment, ví dụ Nova Foods hoặc liên kết giữa các artifact đã hoàn chỉnh, đúng chuyên môn, sẵn sàng phát hành hay sẵn sàng sử dụng trong delivery.

Nội dung cần phân biệt	Trạng thái của artifact hiện tại	Hệ quả kiểm soát
Kế hoạch trước drafting	Có	Có thể dùng để định hướng việc soạn các artifact tiếp theo trong trạng thái kiểm soát phù hợp.
Drafting nội dung chính	Chưa được xác nhận hoàn tất bởi artifact này	Không được suy luận rằng handbook hoặc template library đã được viết, kiểm tra đầy đủ hoặc phát hành.
Baseline	Chưa baseline	Không có baseline reference, không có mốc nội dung đóng băng và không có quyền coi nội dung là chuẩn áp dụng.
Approval	Chưa có approval được ghi nhận	IN_REVIEW không phải là APPROVED, không phải xác nhận của người dùng, và không phải bằng chứng chấp thuận của bất kỳ vai trò nào.
Review của authorized role	Chưa được thay thế	Các kết luận cần thẩm quyền vẫn phải được review bởi vai trò được ủy quyền đúng phạm vi trước khi được dùng làm quyết định hoặc cam kết.

Không được dùng artifact này để thay thế review của authorized role, gồm nhưng không giới hạn ở người chịu trách nhiệm nghiệp vụ, kiến trúc kỹ thuật, kiểm thử, bảo mật, accessibility, pháp lý, kế toán, thuế, bảo vệ dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc. Với Nova Foods Trading & Manufacturing, mọi tình huống, dữ liệu, vai trò và quyết định là mô phỏng giáo dục; do đó chúng không tạo bằng chứng rằng một doanh nghiệp thực đã phê duyệt curriculum, tuân thủ quy định hoặc chấp nhận một cách triển khai.

Quy tắc diễn giải bắt buộc: chỉ một quyết định được ghi nhận rõ bởi vai trò có thẩm quyền trong artifact kiểm soát phù hợp mới có thể được xem là approval cho đúng quyết định đó. Việc tồn tại H1, cấu trúc section, bảng kế hoạch, nội dung IN_REVIEW, hoặc sự hiện diện của Owner không tạo approval ngầm định. Trước khi có baseline và approval được ghi nhận hợp lệ, mọi nội dung của artifact phải được hiểu là đề xuất có kiểm soát để review, không phải chỉ thị triển khai, requirement được phê duyệt, cam kết pháp lý hay chuẩn production.

Phạm vi áp dụng và ranh giới sử dụng của Curriculum Architecture

Artifact /01-curriculum/01_CURRICULUM_ARCHITECTURE.md chỉ xác định curriculum architecture cho handbook và template library của chương trình IT BUSINESS ANALYST — ZERO TO DELIVERY READY. Nội dung hợp lệ gồm cấu trúc học tập, trình tự năng lực, quan hệ phụ thuộc giữa các chủ đề, vị trí dự kiến của chapter, mục tiêu sử dụng của nhóm artifact đào tạo và nguyên tắc định tuyến người học qua case study mô phỏng Nova Foods Trading & Manufacturing.

Đối tượng	Trong phạm vi của artifact	Ngoài phạm vi của artifact
Handbook	Xác định handbook cần bao phủ năng lực, chủ đề và luồng học nào.	Soạn đầy đủ nội dung bài học, quyết định câu chữ cuối cùng, hoặc ban hành handbook như tài liệu vận hành.
Template library	Xác định nhóm template cần được curriculum tham chiếu và thứ tự học cách dùng template.	Thiết kế, điền mẫu, phê duyệt, hoặc phát hành template cụ thể tại /03-templates/.
Requirements	Dạy cách phân tích, cấu trúc và truy vết requirement trong bối cảnh Nova Foods mô phỏng.	Tạo, xác nhận, baseline hoặc phê duyệt business requirement, functional requirement, acceptance criterion hay business rule cho hệ thống thực.
Nova Foods	Dùng Nova Foods Trading & Manufacturing làm running case giáo dục với dữ liệu tổng hợp.	Khẳng định dữ liệu, quy trình, chính sách, hệ thống hoặc quyết định là của doanh nghiệp có thật.
Legal/compliance	Chỉ định điểm học cần nhận biết nhu cầu xác minh pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc.	Diễn giải pháp luật, xác nhận tuân thủ, cấp legal/compliance sign-off, hoặc chuyển nội dung đào tạo thành nghĩa vụ áp dụng cho production.

Ranh giới quyết định được áp dụng như sau:

1. Khi curriculum nêu “người học sẽ thực hành viết REQ-FUNC-SALES-012”, đây là định hướng năng lực và traceability cho corpus; nó không tạo requirement đã được chấp thuận cho Nova Foods hoặc bất kỳ tổ chức nào.
2. Khi curriculum tham chiếu BPMN, UML, OpenAPI, ISTQB, WCAG hoặc OWASP, việc tham chiếu chỉ xác định nhu cầu học và mức kỹ thuật dự kiến. Mọi claim chuẩn mực chi tiết phải tuân thủ phân loại nguồn và ranh giới xác minh tại /00-research/00_SOURCE_MAP.md.
3. Khi một chủ đề liên quan Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, hóa đơn chứng từ, an toàn thực phẩm hoặc truy xuất nguồn gốc, curriculum chỉ được định tuyến nội dung tới Verification required hoặc Project assumption khi chưa có xác minh phù hợp. Artifact không được suy ra yêu cầu pháp lý, ngoại lệ, thời hạn, trách nhiệm hoặc quyết định triển khai.
4. Mọi output mang tính requirement, template hoàn chỉnh, thiết kế solution, test case thực thi, cấu hình, API contract, phê duyệt nghiệp vụ hoặc sign-off chuyên môn phải được quản trị trong artifact đúng loại và bởi vai trò được ủy quyền đúng phạm vi.

Do đó, artifact này là bản đồ kiến trúc cho việc xây dựng năng lực và tổ chức corpus, không phải nguồn thay thế cho requirements management, template governance, legal review, compliance assessment, accounting interpretation hay production authorization.

Quy tắc kiểm soát nội dung cấp tài liệu

Các quy tắc dưới đây áp dụng cho toàn bộ nội dung có kiểm soát trong /01-curriculum/01_CURRICULUM_ARCHITECTURE.md. Mục tiêu là bảo đảm người đọc có thể xác định phiên bản đang xem, người chịu trách nhiệm duy trì, lý do thay đổi và trạng thái baseline của từng thay đổi; đồng thời ngăn việc thay thế nội dung đã kiểm soát mà không có dấu vết.

Lĩnh vực kiểm soát	Quy tắc bắt buộc	Tiêu chí áp dụng
Versioning	Mỗi thay đổi làm thay đổi ý nghĩa kiến trúc, cấu trúc chapter, dependency, capability gate, phạm vi hoặc quyết định quản trị phải cập nhật version theo quy ước kiểm soát của corpus. Không dùng lại một version cho hai trạng thái nội dung khác nhau.	Version phải khớp giữa metadata và change history của chính artifact.
Ownership	Owner chịu trách nhiệm duy trì tính nhất quán, điều phối cập nhật, ghi nhận tác động liên file và bảo toàn traceability. Ownership không trao quyền tự xác nhận baseline, phê duyệt chuyên môn, pháp lý, kế toán hoặc production.	Mọi thay đổi phải nêu Owner hoặc vai trò thực hiện và vai trò cần review khi có phụ thuộc.
Change history	Mỗi lần cập nhật phải có một dòng lịch sử gồm version, ngày, trạng thái, người hoặc vai trò chịu trách nhiệm, mô tả thay đổi cụ thể và tác động đến baseline. Mô tả như “cập nhật nội dung” không đủ để audit.	Có thể phân biệt được thay đổi câu chữ, thay đổi cấu trúc và thay đổi quyết định.
Baseline boundary	Nội dung ở trạng thái IN_REVIEW là nội dung đang được xem xét và có thể thay đổi có kiểm soát; không được gọi là baseline. Khi một baseline được thiết lập trong tương lai, mọi thay đổi tác động nội dung baseline phải đi qua Change Request theo quy ước CR-{DOMAIN}-{NNN}.	Không suy diễn IN_REVIEW là BASELINED, APPROVED hoặc sẵn sàng triển khai.
Không ghi đè im lặng	Không được thay thế, xóa, đổi ID, đổi filename, đổi source classification, đổi traceability hoặc đảo ngược quyết định đã ghi nhận mà không cập nhật version và change history.	Nếu lý do thay đổi chưa rõ, giữ nội dung hiện hữu và ghi nhận điểm cần xử lý trong luồng review thay vì sửa ẩn.

Quy tắc xử lý thay đổi: thay đổi biên tập thuần túy chỉ được thực hiện khi không làm đổi nghĩa, ID, liên kết phụ thuộc, phạm vi hoặc quyết định quản trị. Nếu một chỉnh sửa có thể làm người đọc hiểu khác về logic curriculum, mức năng lực, liên kết với handbook hoặc template library, chỉnh sửa đó được xem là thay đổi có kiểm soát và phải được ghi vào change history.

Ví dụ áp dụng: việc đổi tên một chapter nhưng vẫn giữ nguyên mục tiêu học, dependency và stable ID phải ghi rõ tên cũ, tên mới và tác động liên kết. Việc thay SRC-STD-ISTQB-001 bằng một nguồn khác, hoặc đổi phân loại nguồn từ Industry good practice sang Normative standard, không được coi là sửa biên tập; đây là thay đổi có tác động traceability và phải được review theo phạm vi phù hợp.

2. Kiến trúc 26 chapter và logic tiến trình học

Danh mục dưới đây là spine cố định gồm đúng 26 chapter, đánh số từ 00 đến 25. Mỗi chapter có một Chapter ID ổn định để liên kết về sau với handbook, template, cheatsheet, glossary, QA và artifact của running case Nova Foods Trading & Manufacturing — mô phỏng giáo dục. Tên chapter mô tả phạm vi dự kiến, không phải tuyên bố rằng learner đã được cấp quyền quyết định nghiệp vụ, pháp lý, kế toán hoặc production.

STT	Chapter ID	Chapter title dự kiến	Vai trò trong tiến trình học	Nhóm chủ đề
00	CH-00	Orientation: Nghề IT Business Analyst và môi trường delivery	Thiết lập từ đầu các khái niệm BA, sản phẩm số, dự án, vai trò và ranh giới trách nhiệm cho người chưa có nền tảng BA hoặc software engineering.	Foundations
01	CH-01	Business Context, Value và Problem Framing	Học cách phân biệt vấn đề, mục tiêu, lợi ích, phạm vi và giả định trước khi đề xuất giải pháp.	Foundations
02	CH-02	Nova Foods Domain Primer và Operating Context	Đặt learner vào ngữ cảnh mô phỏng Nova Foods để nhận diện chuỗi giá trị, đơn vị vận hành, dữ liệu nghiệp vụ và điểm đau delivery.	Foundations
03	CH-03	BA Work Planning và Artifact Lifecycle	Hình thành tư duy lập kế hoạch công việc BA, chọn artifact, quản lý phiên bản và theo dõi trạng thái review.	Foundations
04	CH-04	Stakeholder Identification và Engagement	Xác định ai tạo, sử dụng, phê duyệt, ảnh hưởng hoặc chịu tác động bởi thay đổi nghiệp vụ và hệ thống.	Discovery
05	CH-05	Discovery Strategy và Problem Investigation	Chuyển business context thành câu hỏi discovery có mục tiêu, phạm vi khảo sát và bằng chứng cần thu thập.	Discovery
06	CH-06	Elicitation Techniques và Facilitation	Thực hành chuẩn bị, thực hiện và ghi nhận kết quả phỏng vấn, workshop, quan sát, khảo sát và phân tích tài liệu.	Stakeholder / Elicitation
07	CH-07	Elicitation Analysis và Knowledge Consolidation	Biến thông tin thô, ý kiến mâu thuẫn và giả định thành knowledge có cấu trúc, nguồn gốc và điểm cần làm rõ.	Stakeholder / Elicitation
08	CH-08	Scope, Outcomes và Requirement Decomposition	Tách nhu cầu business thành outcome, capability, feature và requirement ở mức phù hợp để delivery.	Requirements
09	CH-09	Functional Requirements và Acceptance Criteria	Đặc tả hành vi hệ thống và điều kiện chấp nhận có thể quan sát, kiểm tra và truy vết.	Requirements
10	CH-10	Non-functional Requirements và Quality Attributes	Nhận diện, diễn đạt và kiểm tra các kỳ vọng về hiệu năng, khả dụng, bảo mật, accessibility, vận hành và dữ liệu.	Requirements
11	CH-11	Business Rules, Decisions và Exception Handling	Phân biệt business rule với requirement; mô hình hóa điều kiện, quyết định, ngoại lệ và quyền sở hữu rule.	Business Rules
12	CH-12	Process Modeling Fundamentals	Xây dựng tư duy mô hình hóa luồng công việc, vai trò, điểm bắt đầu, kết thúc, quyết định và handoff.	Process
13	CH-13	BPMN Process Models cho Nova Foods	Áp dụng BPMN 2.0.2 có kiểm soát để biểu diễn quy trình mô phỏng như bán hàng, mua hàng, kho, giao nhận và xử lý ngoại lệ.	Process
14	CH-14	Data Fundamentals và Conceptual Data Modeling	Nhận diện business entity, thuộc tính, định danh, quan hệ, vòng đời dữ liệu và chất lượng dữ liệu.	Data
15	CH-15	Logical Data Specification và Data Validation	Chuyển mô hình dữ liệu khái niệm thành định nghĩa dữ liệu, rule kiểm tra, giá trị hợp lệ và trách nhiệm quản trị dữ liệu.	Data
16	CH-16	API và Integration Analysis	Phân tích ranh giới hệ thống, consumer-provider, request-response, lỗi tích hợp và dữ liệu trao đổi.	API / Integration
17	CH-17	OpenAPI-oriented API Specification	Đọc và đặc tả API theo tư duy OpenAPI 3.1.1, liên kết endpoint, payload, status, validation và requirement.	API / Integration
18	CH-18	State, Lifecycle và Event Modeling	Mô hình hóa trạng thái, chuyển trạng thái, event, điều kiện chuyển đổi và hành vi không hợp lệ của đối tượng nghiệp vụ.	State
19	CH-19	Traceability, Baseline và Change Control	Thiết lập liên kết có kiểm soát giữa need, requirement, rule, model, acceptance criterion, test và thay đổi.	Governance
20	CH-20	Risk, Assumption, Dependency và Escalation	Đánh giá điều chưa chắc chắn, phụ thuộc, tác động và ngưỡng cần chuyển quyết định cho owner có thẩm quyền.	Governance
21	CH-21	Requirement Quality Review và Decision Support	Kiểm tra tính rõ ràng, nhất quán, khả thi, kiểm thử được và hỗ trợ stakeholder chọn phương án có căn cứ.	Governance
22	CH-22	Testing Foundations cho Business Analyst	Xây dựng ngôn ngữ kiểm thử chung giữa BA, QA và delivery team; phân biệt test basis, test condition, test case, defect và evidence.	Testing
23	CH-23	Test Design, UAT và Defect Collaboration	Chuyển requirement, rule, process, data và state thành điều kiện kiểm thử, test case, UAT evidence và xử lý defect.	Testing
24	CH-24	End-to-End Delivery Workflow	Kết nối discovery, specification, review, development collaboration, testing, change control và handoff trong một luồng delivery hoàn chỉnh.	Capstone Workflow
25	CH-25	Nova Foods Capstone: Delivery-ready BA Pack	Tổng hợp năng lực junior-to-senior thành bộ artifact nhất quán cho một phạm vi Nova Foods mô phỏng, có truy vết và điểm escalation rõ ràng.	Capstone Workflow

2.1 Trình tự học từ foundations đến delivery-ready

Lộ trình 26 chapter được tổ chức như một chuỗi năng lực tăng dần: người học trước hết hiểu vấn đề nghiệp vụ và ngôn ngữ delivery, sau đó thu thập bằng chứng, mô hình hóa, đặc tả, kiểm tra chất lượng và cuối cùng điều phối quyết định hoặc escalation có căn cứ. Trình tự này không giả định người học đã biết Business Analysis, phát triển phần mềm, API, kiểm thử hoặc quy định ngành.

Giai đoạn học	Chapter dự kiến	Năng lực được xây dựng theo thứ tự	Đầu ra học tập tối thiểu trong Nova Foods mô phỏng	Điều kiện chuyển giai đoạn
Foundations	CH-00 đến CH-03	Nhận diện BA là hoạt động làm rõ nhu cầu, bối cảnh, giá trị và giới hạn; phân biệt problem, need, requirement, solution và assumption.	Problem statement cho một tình huống Nova Foods; glossary tối thiểu; stakeholder context ban đầu; danh sách assumption có nhãn Project assumption.	Người học diễn đạt được vấn đề mà không nhảy thẳng sang màn hình, database hoặc giải pháp kỹ thuật.
Discovery	CH-04 đến CH-05	Xác định phạm vi khám phá, mục tiêu, câu hỏi cần trả lời, nguồn bằng chứng và khoảng trống thông tin.	Discovery plan, phạm vi in/out, business objective, danh sách câu hỏi và evidence log.	Mỗi kết luận có nguồn, quan sát, giả định hoặc câu hỏi mở được phân biệt rõ.
Stakeholder/Elicitation	CH-06 đến CH-07	Xác định stakeholder, quyền lợi, ảnh hưởng, xung đột; chuẩn bị và thực hiện elicitation có cấu trúc.	Stakeholder map, agenda workshop/phỏng vấn, elicitation notes, issue log và kết quả xác nhận nội dung theo quy trình dự án.	Người học tách được ý kiến, fact, yêu cầu, quyết định và vấn đề chưa được quyết định.
Requirements	CH-08 đến CH-10	Chuyển nhu cầu đã khám phá thành requirement có phạm vi, ưu tiên, nguồn gốc và tiêu chí kiểm tra; quản lý liên kết giữa need, requirement và acceptance criteria.	Các ID mô phỏng như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03; requirement package có traceability.	Requirement mô tả kết quả cần đạt và điều kiện chấp nhận, không che giấu business rule trong câu chữ mơ hồ.
Business Rules	CH-11 đến CH-12	Tách rule khỏi requirement và process; xác định điều kiện, hành động, ngoại lệ, quyền quyết định và nguồn rule.	Rule catalog với ID như BR-SALES-004, decision table hoặc decision tree, danh sách rule cần xác minh.	Rule liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải mang nhãn Verification required nếu chưa có xác minh từ owner có thẩm quyền.
Process/Data/API/State	CH-13 đến CH-18	Mô hình hóa luồng công việc, dữ liệu, tích hợp và vòng đời trạng thái theo mức đủ để delivery team hiểu cùng một hành vi hệ thống.	Process model; data dictionary; interface/API contract; state model; liên kết tới REQ-FUNC-*, BR-* và AC-*.	Người học kiểm tra được sự nhất quán giữa actor, dữ liệu đầu vào/đầu ra, business rule, trạng thái và lỗi nghiệp vụ. PlantUML activity diagram không được gọi là BPMN nếu không dùng đúng ký pháp BPMN đã xác minh.
Governance	CH-19 đến CH-21	Quản lý thay đổi, phạm vi, risk, assumption, dependency, chất lượng requirement và lựa chọn phương án.	Change record theo quy ước CR-{DOMAIN}-{NNN}, RAID log, quality review findings, decision brief và escalation record.	Người học biết khi nào cần đề xuất phương án, khi nào phải dừng để escalation; không tự thay legal, accounting, security, privacy hoặc domain owner ra quyết định.
Testing	CH-22 đến CH-23	Dùng requirement làm test basis; thiết kế test condition, test case, UAT evidence và cộng tác xử lý defect.	Liên kết REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07; UAT scenario, expected result, defect evidence.	Mỗi test case kiểm tra được hành vi quan sát được, bao gồm luồng hợp lệ, ngoại lệ, rule boundary và state transition phù hợp.
Capstone Workflow	CH-24 đến CH-25	Tích hợp toàn bộ chuỗi từ discovery đến handoff; đánh giá trade-off, tính sẵn sàng delivery và điểm cần escalation.	Nova Foods delivery-ready BA pack mô phỏng gồm scope, requirements, rules, models, traceability, test evidence, change/risk record và handoff summary.	Bộ artifact nhất quán nội bộ, truy vết được, nêu rõ Project assumption và Verification required, không tự nhận production-ready, compliant hoặc được phê duyệt.

Logic tiến trình: các giai đoạn có thể quay lại giai đoạn trước khi phát hiện bằng chứng mới, nhưng không được bỏ qua dependency nhận thức. Ví dụ, API contract chỉ được đặc tả sau khi hành vi nghiệp vụ, dữ liệu và rule liên quan đã đủ rõ; test case không thay thế acceptance criteria; escalation không thay thế việc BA phân tích tác động và chuẩn bị lựa chọn. Vì vậy, “delivery-ready” trong curriculum nghĩa là người học có thể tạo và liên kết artifact phục vụ quyết định delivery trong case Nova Foods mô phỏng, không phải có thẩm quyền triển khai production hoặc xác nhận tuân thủ pháp lý.

Chuỗi phụ thuộc học tập 00–25 với giả định đầu vào bằng 0 về BA/SE

Chapter ID	Prerequisite bắt buộc trước khi học	Downstream dependency phải phục vụ	Quy tắc kiểm tra phụ thuộc
CH-00	Không yêu cầu kiến thức BA hoặc software engineering; chỉ cần đọc hiểu tiếng Việt và năng lực theo dõi ký hiệu tài liệu	Tạo ngôn ngữ chung để hiểu các chapter sau	Nếu learner chưa phân biệt được artifact, requirement, model, rule thì chưa được chuyển tiếp
CH-01	CH-00	Làm nền cho cách đọc nguồn, thuật ngữ và ranh giới sử dụng nguồn	Mọi thuật ngữ sau này phải có thể truy ngược về nguồn hoặc convention đã định
CH-02	CH-01	Chuẩn bị cho nhận diện bối cảnh nghiệp vụ Nova Foods	Nếu chưa hiểu bối cảnh, không được sang discovery chi tiết
CH-03	CH-02	Cung cấp khung nhận diện stakeholder và nguồn thông tin	Nếu chưa xác định ai cung cấp thông tin, elicitation sẽ bị sai đầu vào
CH-04	CH-03	Hỗ trợ kỹ thuật đặt câu hỏi, ghi nhận quan sát và làm rõ nhu cầu	Nếu không có kỹ thuật hỏi đúng, requirement sẽ thiếu hoặc lệch
CH-05	CH-04	Chuyển thông tin thu thập được thành nhu cầu có cấu trúc	Không được nhảy sang đặc tả khi nhu cầu còn mơ hồ
CH-06	CH-05	Làm tiền đề cho phân loại requirement và mức độ chi tiết	Nếu chưa phân loại đúng, downstream model và test sẽ không nhất quán
CH-07	CH-06	Cần để chuyển nhu cầu thành business rule có điều kiện rõ ràng	Rule phụ thuộc vào requirement đã được diễn đạt rõ ngữ nghĩa
CH-08	CH-07	Hỗ trợ mô hình hóa quy trình nghiệp vụ ở mức quan sát được	Process model phải phản ánh rule và requirement trước đó
CH-09	CH-08	Chuẩn bị cho mô hình dữ liệu logic, thực thể và thuộc tính	Data model downstream phụ thuộc vào process và requirement đã chốt
CH-10	CH-09	Làm nền cho xác định API boundary và trao đổi thông điệp	API contract không được định nghĩa khi dữ liệu và hành vi chưa rõ
CH-11	CH-10	Cần để diễn giải trạng thái, vòng đời và chuyển trạng thái	State model phụ thuộc vào process, data và event đã nhận diện
CH-12	CH-11	Dùng để gom các quan hệ phụ thuộc thành traceability tuyến tính	Nếu traceability thiếu, kiểm soát thay đổi sẽ đứt mạch
CH-13	CH-12	Cung cấp cách kiểm tra tính nhất quán nội bộ của artifact	Chưa kiểm tra chất lượng thì chưa chuyển sang governance logic
CH-14	CH-13	Là nền cho review, exception handling và escalation judgment	Governance chỉ có ý nghĩa khi đã có artifact đủ rõ để soát
CH-15	CH-14	Cần để chuyển từ xác định vấn đề sang đánh giá rủi ro và tác động	Risk handling phụ thuộc vào quy tắc và traceability đã có
CH-16	CH-15	Hỗ trợ chuẩn bị acceptance perspective và kiểm thử mức nghiệp vụ	Test không thể tạo từ ý tưởng chung; phải bám requirement/rule
CH-17	CH-16	Làm nền cho test case, test scenario và dữ liệu kiểm thử	Test artifacts downstream phụ thuộc trực tiếp vào acceptance logic
CH-18	CH-17	Cần để đối chiếu coverage, gap và defect triage	Không có coverage thì không thể kết luận sẵn sàng bàn giao
CH-19	CH-18	Chuẩn bị cho kiểm soát thay đổi, versioning và impact review	Change control phụ thuộc vào baseline logic và traceability
CH-20	CH-19	Cần để tổng hợp nhiều artifact thành bộ hồ sơ nhất quán	Tổng hợp chỉ làm được khi từng mảnh đã có dependency rõ
CH-21	CH-20	Làm nền cho phối hợp đa bên và ra quyết định có kiểm soát	Stakeholder quyết định phải dựa trên chuỗi phụ thuộc đã kiểm tra
CH-22	CH-21	Cần để đánh giá mức độ sẵn sàng delivery ở cấp senior	Readiness judgment phụ thuộc vào evidence từ các chapter trước
CH-23	CH-22	Hỗ trợ xử lý ngoại lệ, trade-off và escalation path	Nếu chưa có judgment thì chưa đủ điều kiện escalte có cấu trúc
CH-24	CH-23	Tổng hợp toàn bộ học phần thành luồng triển khai mô phỏng	Capstone chỉ nhận đầu vào từ các chapter đã khép kín dependency
CH-25	CH-24	Kết thúc spine bằng bàn giao học tập có truy vết đầy đủ	Downstream cuối cùng là bộ artifact delivery-ready cho Nova Foods mô phỏng

Quy tắc phụ thuộc áp dụng xuyên suốt spine 00–25: 1. Không chapter nào được hiểu như đã có sẵn nền BA hoặc software engineering; mọi khái niệm phải được giới thiệu từ đầu bằng ngôn ngữ người học mới. 2. Prerequisite là điều kiện tối thiểu để hiểu chapter hiện tại, không phải danh sách tham khảo tùy chọn. 3. Downstream dependency là kết quả học tập mà chapter hiện tại phải cung cấp cho chapter sau; nếu chapter sau không dùng lại được đầu ra, chuỗi học phải bị xem là đứt. 4. Khi phát hiện khoảng trống kiến thức, learner phải quay về chapter nền liên quan thay vì bỏ qua dependency. 5. Trong /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, đây chỉ là bản đồ phụ thuộc học tập cho Nova Foods mô phỏng; chưa phải nội dung đào tạo chi tiết, chưa phải baseline đào tạo và chưa hàm ý người học đã có năng lực chuyên môn đầu vào.

Logic phân tầng năng lực từ junior đến senior

Curriculum phân tầng theo khả năng biến thông tin chưa cấu trúc thành quyết định có thể truy vết, không theo số năm kinh nghiệm hoặc mức độ thành thạo công cụ. Một learner chỉ được chuyển lên tầng kế tiếp khi vừa giải thích được khái niệm, vừa tạo được artifact phù hợp, vừa chỉ ra giới hạn thẩm quyền của artifact đó. Trong Nova Foods mô phỏng, năng lực cao hơn không có nghĩa là tự quyết thay business owner, legal owner, accounting owner, security owner hoặc solution architect.

Tầng năng lực	Trọng tâm tư duy	Hành vi và artifact tối thiểu	Dấu hiệu chưa đạt	Ranh giới thẩm quyền
Junior 1 — Nhận diện khái niệm	Phân biệt vấn đề, nhu cầu, requirement, business rule, assumption, risk, issue và decision.	Gắn đúng nhãn cho một phát biểu như “Kho bán hàng cần biết đơn nào đã giao”; ghi nguồn, người cung cấp thông tin và điều chưa biết.	Gọi mọi phát biểu của stakeholder là requirement; nhầm assumption với fact; không nêu nguồn.	Không tự suy diễn chính sách thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc pháp lý.
Junior 2 — Mô hình hóa có hướng dẫn	Chuyển ngôn ngữ tự nhiên thành mô hình có phạm vi và quan hệ rõ ràng.	Lập stakeholder map, process sketch, danh sách dữ liệu hoặc state draft cho Nova Foods; giải thích mỗi ký hiệu và quan hệ bằng ngôn ngữ đơn giản.	Sơ đồ đẹp nhưng không chỉ ra actor, trigger, input, output hoặc ngoại lệ.	Không gọi sơ đồ tự do là BPMN hoặc UML nếu chưa đáp ứng đúng quy ước và ngữ nghĩa tương ứng.
Intermediate 1 — Đặc tả kiểm tra được	Biến nhu cầu đã hiểu thành requirement, business rule và acceptance criteria có thể quan sát.	Liên kết NEED-SALES-001 với requirement, rule, acceptance criteria và câu hỏi mở; nêu điều kiện, hành động, kết quả và trường hợp lỗi.	Requirement chứa nhiều ý không tách được; acceptance criteria chỉ lặp lại requirement; không nêu dữ liệu đầu vào hoặc kết quả mong đợi.	Không biến project assumption thành nghĩa vụ pháp lý hoặc quyết định kiến trúc.
Intermediate 2 — Kiểm tra chất lượng và nhất quán	Tìm mâu thuẫn, thiếu sót, không kiểm tra được và đứt traceability trước khi chuyển giao.	Thực hiện review matrix giữa process, data, rule, API, state, requirement và test condition; ghi defect của artifact cùng tác động và hướng xử lý đề xuất.	Chỉ sửa câu chữ; không phát hiện xung đột giữa rule và process hoặc trạng thái không có transition hợp lệ.	BA nêu rủi ro và bằng chứng, không tự xác nhận compliance, security adequacy hoặc accounting correctness.
Senior-ready — Ra quyết định có căn cứ	So sánh phương án theo giá trị, rủi ro, dependency, chi phí thay đổi, khả năng kiểm thử và ownership.	Lập decision record nêu vấn đề, phương án, tiêu chí đánh giá, tác động tới Nova Foods mô phỏng, thông tin còn thiếu, decision owner và điểm cần xác minh.	Chọn phương án vì “thường làm như vậy”; không nêu trade-off hoặc người có quyền quyết định.	BA điều phối và khuyến nghị; decision owner giữ quyền quyết định trong phạm vi nghiệp vụ hoặc kỹ thuật được phân công.
Senior-ready — Escalation judgment	Nhận biết khi bằng chứng không đủ, thẩm quyền không phù hợp hoặc rủi ro vượt ngưỡng xử lý của nhóm.	Tạo escalation package gồm fact đã xác minh, assumption, câu hỏi quyết định, tác động nếu trì hoãn, owner cần tham gia và artifact bị ảnh hưởng.	Escalate mơ hồ không có câu hỏi; hoặc tiếp tục đặc tả chi tiết khi chưa rõ policy, ownership hay tính hợp pháp.	Các nội dung privacy, pháp lý, kế toán, thuế, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc và security phải được gắn Verification required khi chưa có xác minh từ owner có thẩm quyền.

Chuỗi phát triển bắt buộc: nhận diện đúng trước khi mô hình hóa; mô hình hóa đủ ngữ cảnh trước khi đặc tả; đặc tả kiểm tra được trước khi kiểm tra chất lượng; chất lượng đủ bằng chứng trước khi khuyến nghị quyết định; và chỉ thực hiện escalation khi learner xác định được câu hỏi, tác động, owner và phần việc không thuộc thẩm quyền của mình.

Quy tắc đánh giá phân tầng: 1. Không chấm đạt chỉ vì learner dùng đúng thuật ngữ. Bằng chứng đạt phải bao gồm artifact, lý giải lựa chọn và traceability tới thông tin đầu vào. 2. Một artifact có thể là bản nháp phục vụ học tập, nhưng phải phân biệt rõ Project assumption, fact đã xác minh và Verification required. 3. Khi hai nguồn mâu thuẫn, learner không được âm thầm chọn một nguồn. Learner phải ghi nhận xung đột, tác động tới artifact và chuyển đúng decision owner. 4. Năng lực senior-ready được thể hiện qua judgment có căn cứ và biết dừng đúng lúc, không phải qua việc thay thế thẩm quyền của chuyên gia. 5. Architecture này là bản đồ năng lực độc lập cho /01-curriculum/01_CURRICULUM_ARCHITECTURE.md; chapter text sau đó mới quyết định bài giảng, bài tập, template và rubric chi tiết.

Nguyên tắc độc lập giữa Curriculum Architecture và nội dung chapter

/01-curriculum/01_CURRICULUM_ARCHITECTURE.md là bản đồ học tập có kiểm soát cho corpus IT BUSINESS ANALYST — ZERO TO DELIVERY READY, không phải handbook, giáo án, slide, bài tập đầy đủ, template thực thi hay đặc tả Nova Foods. Tại trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, artifact này xác định cấu trúc, ranh giới và quan hệ học tập ở mức kiến trúc; mỗi chapter sau đó phải tự cung cấp nội dung đào tạo chi tiết mà không làm thay đổi ngầm kiến trúc đã công bố.

Thành phần	Thuộc Curriculum Architecture	Không thuộc Curriculum Architecture
Mục đích	Xác định learner cần đi qua những năng lực nào, theo trật tự và ranh giới nào	Dạy đầy đủ cách thực hiện từng kỹ thuật hoặc công cụ
Mức chi tiết	Chapter ID, tiêu đề dự kiến, vai trò, nhóm chủ đề, prerequisite, dependency và điểm chuyển năng lực	Bài giảng, giải thích thuật ngữ đầy đủ, ví dụ hoàn chỉnh, bài tập, đáp án, rubric chấm chi tiết
Nova Foods	Chỉ định Nova Foods Trading & Manufacturing là running case mô phỏng và chỉ ra loại artifact sẽ được dùng để học	Khẳng định dữ liệu, quy trình, chính sách hoặc quyết định của Nova Foods là thực tế hay đã được phê duyệt
Nguồn tham chiếu	Chỉ nêu ranh giới sử dụng và nguồn cần truy vết từ /00-research/00_SOURCE_MAP.md	Diễn giải chi tiết điều khoản, clause, page, quotation hoặc nghĩa vụ pháp lý chưa được xác minh
Thay đổi	Ghi nhận tác động cấu trúc khi chapter mới làm phát sinh, bỏ hoặc đảo dependency	Tự ý sửa spine chỉ vì muốn bổ sung một ví dụ, một bài tập hoặc một cách diễn đạt

Quy tắc tách lớp: chapter text được phép triển khai kiến thức, ví dụ, bài thực hành và tiêu chí kiểm tra trong phạm vi chapter đã được kiến trúc cấp chỗ. Chapter text không được tự tạo chapter ID, đổi tên file chuẩn, thay đổi thứ tự học, nâng một project assumption thành fact, hoặc chuyển nội dung Verification required thành yêu cầu bắt buộc. Nếu cần thay đổi một trong các yếu tố đó, tác giả phải ghi nhận tác động lên architecture và định tuyến thay đổi theo cơ chế CR-{DOMAIN}-{NNN} sau khi artifact được baseline; tại thời điểm hiện tại không được suy diễn baseline hoặc phê duyệt.

Tiêu chí kiểm tra độc lập trước khi viết chapter text:

Kiểm tra	Đạt khi	Không đạt khi
Đọc độc lập	Người lập kế hoạch có thể hiểu hành trình năng lực và ranh giới từng phần chỉ từ architecture	Phải đọc handbook mới biết chapter có vai trò gì trong hành trình
Triển khai độc lập	Người viết chapter có thể biết đầu vào, đầu ra học tập và dependency cần tôn trọng mà không phải tự đoán cấu trúc	Chapter phải tự xác định lại vị trí, prerequisite hoặc downstream dependency
Thay thế độc lập	Có thể cập nhật ví dụ Nova Foods, template hoặc phương pháp giảng dạy mà không đổi spine	Một thay đổi ví dụ buộc sửa cấu trúc curriculum dù không thay đổi năng lực mục tiêu
Truy vết độc lập	Mọi claim nguồn, pháp lý hoặc chuẩn chi tiết được giữ tại artifact phù hợp và truy vết về /00-research/00_SOURCE_MAP.md	Architecture chứa claim kỹ thuật, pháp lý hoặc chuẩn mực chi tiết vượt quá ranh giới source đã xác minh

Vì vậy, curriculum architecture chỉ trả lời: học gì ở cấp năng lực, học trước hoặc sau nội dung nào, và khi nào learner được chuyển sang loại công việc phức tạp hơn. Chapter text mới trả lời: giải thích như thế nào, dùng artifact nào, thực hành ra sao và đánh giá bằng bằng chứng gì. Cách phân định này giữ cho bản đồ học tập bền vững khi nội dung đào tạo được cải tiến, đồng thời ngăn việc chi tiết mô phỏng của Nova Foods bị hiểu nhầm là quyết định production, nghĩa vụ pháp lý hoặc xác nhận của doanh nghiệp thực.

3. Capability gates, pedagogical boundaries và assessment approach

Capability gate là ngưỡng năng lực quan sát được, dùng để quyết định learner có thể chuyển sang loại bài tập BA phức tạp hơn trong corpus Nova Foods hay chưa. Gate không đo thời gian học, số chapter đã đọc hoặc khả năng nhớ thuật ngữ; gate đo khả năng biến thông tin còn mơ hồ thành artifact có cấu trúc, giữ được liên kết giữa vấn đề, requirement và bằng chứng kiểm tra. Mọi ví dụ Nova Foods Trading & Manufacturing là dữ liệu mô phỏng giáo dục; IN_REVIEW, v0.9.0, ngày 2026-08-07.

Cấp độ	Learner có thể thực hiện độc lập trong phạm vi bài tập	Bằng chứng năng lực tối thiểu	Chưa được suy diễn
Beginner	Nhận biết problem statement, stakeholder, business process, requirement, acceptance criterion và test case là các loại thông tin khác nhau; điền artifact mẫu với dữ liệu đã được cung cấp.	Phân loại đúng một phát biểu mô phỏng vào nhóm need, requirement, business rule hoặc câu hỏi cần làm rõ; không trộn lẫn giải pháp với nhu cầu.	Không suy diễn quy tắc nghiệp vụ, quy định pháp lý, cấu hình ERP hoặc tác động liên phòng ban từ một câu mô tả ngắn.
Novice	Soạn bản nháp có cấu trúc cho need, functional requirement, acceptance criterion và câu hỏi làm rõ; mô tả happy path của một luồng hẹp như tạo đơn hàng mô phỏng.	Tạo chuỗi liên kết nhất quán, ví dụ NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-03 → TC-SALES-012-07; chỉ ra dữ kiện nào là Project assumption.	Không tự đóng các điểm mơ hồ có ảnh hưởng tiền, tồn kho, hóa đơn, dữ liệu cá nhân hoặc truy xuất nguồn gốc.
Intermediate	Phân tích ngoại lệ, xung đột thuật ngữ, dữ liệu đầu vào/đầu ra và tác động xuyên artifact; đề xuất các phương án có điều kiện cho một phạm vi Nova Foods xác định.	Requirement có actor, trigger, điều kiện, kết quả; acceptance criterion kiểm tra được; traceability chỉ ra requirement nào chưa có test hoặc có dependency chưa rõ.	Không trình bày giả định dự án như fact, không coi sơ đồ hoạt động PlantUML là BPMN, và không biến mô tả API thành business rule.
Delivery-ready	Chuẩn bị gói phân tích đủ để một nhóm delivery review: phạm vi, requirement, business rule, acceptance criteria, dependency, open question, risk và liên kết test.	Phát hiện tác động khi thay đổi một requirement; giải thích vì sao lựa chọn wording, phạm vi và tiêu chí quyết định; duy trì nhất quán ID, thuật ngữ và trạng thái xác minh.	Không có nghĩa là đã có thẩm quyền phê duyệt nghiệp vụ, pháp lý, kế toán, bảo mật, kiến trúc hoặc production release.
Senior reasoning patterns	Lập luận theo hệ quả hệ thống thay vì chỉ hoàn tất biểu mẫu: phân tách fact, assumption, decision và verification need; kiểm tra trade-off giữa giá trị nghiệp vụ, rủi ro, khả năng kiểm thử và khả năng vận hành.	Nêu được ít nhất hai phương án, tiêu chí chọn, tác động downstream và điều kiện làm thay đổi quyết định; chủ động giữ vấn đề ở trạng thái chưa kết luận khi bằng chứng chưa đủ.	Không đồng nhất senior reasoning với chức danh Senior BA, quyền quyết định cuối cùng hoặc kinh nghiệm dự án có giám sát.

Quy tắc chuyển gate

1. Learner chỉ được coi là đạt một gate khi tạo được artifact tương ứng và giải thích được mối liên hệ giữa các thành phần trong artifact đó.
2. Việc dùng đúng template nhưng không giải thích được nguồn gốc dữ kiện, điều kiện biên hoặc ảnh hưởng của thay đổi chỉ chứng minh thao tác biểu mẫu, không chứng minh năng lực ở gate cao hơn.
3. Khi thông tin liên quan đến pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật chưa được xác minh từ nguồn và vai trò có thẩm quyền, learner phải giữ nhãn Verification required hoặc Project assumption; không được nâng cấp thành requirement đã xác nhận.
4. Delivery-ready là mục tiêu hoàn thành curriculum: learner tạo được gói artifact có thể review trong dự án mô phỏng. Đây không phải xác nhận đủ kinh nghiệm thay thế cho làm dự án thực tế có giám sát.
5. Senior reasoning patterns được lồng vào mọi gate từ novice trở lên: luôn hỏi “bằng chứng nào hỗ trợ kết luận này?”, “ai chịu tác động?”, “điều gì xảy ra khi ngoại lệ xảy ra?” và “điều gì chưa được phép kết luận?”.

3.01 Ranh giới tự thực hiện, giám sát và escalation theo thẩm quyền

Learner có thể soạn thảo và phân tích, nhưng không được nhầm quyền tạo artifact với quyền quyết định nghiệp vụ, pháp lý, kiến trúc, tài chính hoặc production. Trong Nova Foods Trading & Manufacturing, mọi nội dung là dữ liệu mô phỏng giáo dục; learner phải ghi rõ Project assumption khi thiếu căn cứ và ghi Verification required khi vấn đề cần chuyên gia xác nhận. Không được tự chuyển một giả định thành business rule, compliance requirement hoặc quyết định triển khai.

Tình huống hoặc artifact Nova Foods	Learner được tự thực hiện	Cần giám sát trước khi dùng trong luồng dự án	Phải escalation tới	Điều kiện escalation và đầu ra tối thiểu
Ghi nhận stakeholder, problem statement, mục tiêu sơ bộ cho quy trình bán hàng hoặc mua hàng	Soạn stakeholder map, câu hỏi làm rõ, phạm vi sơ bộ và danh sách giả định.	Senior BA rà độ đầy đủ, ngôn ngữ trung lập và tác động liên phòng ban.	Business Owner, PM	Escalate khi có xung đột mục tiêu, thay đổi phạm vi, ưu tiên hoặc KPI. Gửi issue log nêu bối cảnh, lựa chọn, tác động và quyết định cần có.
Mô hình hóa quy trình hiện tại hoặc đề xuất	Vẽ workflow phục vụ phân tích, xác định actor, bước xử lý, điểm chờ và exception quan sát được từ case study.	Senior BA hoặc Domain Owner rà tính đúng đắn nghiệp vụ; chỉ gọi là BPMN khi notation đã được kiểm tra theo nguồn phù hợp.	Domain Owner, Business Owner	Escalate khi chưa rõ ai sở hữu bước, ai có quyền phê duyệt, hoặc quy trình ảnh hưởng kho, chất lượng, giao hàng hay truy xuất thực phẩm.
Viết NEED-xxx, REQ-FUNC-xxx, acceptance criteria và traceability sơ bộ	Soạn requirement rõ input, xử lý, output, error condition; liên kết requirement với need, rule, test idea và assumption.	Senior BA rà tính không mâu thuẫn, khả kiểm thử và phạm vi.	Business Owner, Domain Owner, PM	Escalate khi requirement làm thay đổi chính sách giá, chiết khấu, hoàn tiền, phân bổ hàng, quyền phê duyệt hoặc kế hoạch phát hành.
Business rule về giá, chiết khấu, hạn mức tín dụng, hàng khuyến mại hoặc đổi trả	Ghi nhận rule được cung cấp, chỉ ra ngoại lệ, dữ liệu cần thiết và câu hỏi chưa xác minh.	Senior BA hỗ trợ phân tách rule, requirement và assumption.	Business Owner, Accounting, Domain Owner	Learner không tự đặt ngưỡng tiền, chính sách hạch toán hoặc quyền override. Gửi rule candidate kèm nguồn phát sinh, tác động và trường hợp biên.
Dữ liệu khách hàng, nhân viên, nhà cung cấp hoặc người liên hệ	Lập data dictionary sơ bộ, phân loại dữ liệu theo mục đích sử dụng giả định và ghi dependency.	Senior BA rà traceability; Security rà yêu cầu kiểm soát kỹ thuật sơ bộ.	Legal, Security, Business Owner	Escalate ngay khi có dữ liệu cá nhân, chia sẻ dữ liệu qua API, retention, consent, phân quyền hoặc chuyển dữ liệu. Mọi diễn giải luật phải là Verification required cho đến khi Legal xác nhận.
Hóa đơn, chứng từ, thuế, doanh thu, công nợ, giá vốn hoặc bút toán	Mô tả luồng nghiệp vụ và các điểm giao với ERP ở mức câu hỏi phân tích.	Senior BA rà phạm vi artifact và cách gắn cờ rủi ro.	Accounting, Legal, Business Owner	Learner không tự diễn giải nghĩa vụ kế toán, thuế hoặc hóa đơn điện tử. Đầu ra là accounting question log, không phải quy tắc bắt buộc.
Truy xuất lô hàng, hạn dùng, thu hồi hoặc kiểm soát chất lượng thực phẩm	Ghi nhận event, dữ liệu lô, điểm truy vết và scenario cần làm rõ trong Nova Foods.	Senior BA và Domain Owner rà tính khả dụng của mô hình.	Domain Owner, Legal, Business Owner	Escalate khi xác định dữ liệu bắt buộc, thời hạn lưu, trigger thu hồi hoặc trách nhiệm tuân thủ. Không được khẳng định Nova Foods tuân thủ luật an toàn thực phẩm.
API, tích hợp ERP, mapping dữ liệu và xử lý lỗi	Soạn contract draft gồm consumer, request, response, mã lỗi dự kiến, mapping nguồn-đích và traceability tới requirement.	Architect rà thiết kế tích hợp; Security rà authentication, authorization và dữ liệu nhạy cảm.	Architect, Security, Domain Owner	Escalate khi có thay đổi system of record, đồng bộ hai chiều, idempotency, quyền truy cập, dữ liệu cá nhân hoặc ảnh hưởng hiệu năng. Learner không tự chốt API contract production.
Phân quyền, role matrix, audit trail và xử lý ngoại lệ	Nhận diện actor, hành động cần kiểm soát, xung đột nhiệm vụ và scenario lạm dụng ở mức phân tích.	Senior BA rà logic nghiệp vụ; Security rà nguyên tắc kiểm soát.	Security, Business Owner, Accounting	Escalate khi quyền có thể tạo, sửa, duyệt hoặc xóa giao dịch tài chính; khi có access đặc quyền; hoặc khi yêu cầu audit có tác động pháp lý.
Mốc phát hành, ưu tiên backlog, thay đổi scope hoặc dependency liên nhóm	Chuẩn bị impact analysis, dependency list, rủi ro và phương án phân kỳ.	Senior BA rà độ tin cậy của phân tích.	PM, Business Owner, Architect	Learner không tự cam kết ngày giao, nguồn lực, ngân sách hoặc phạm vi release. PM điều phối quyết định kế hoạch; Business Owner quyết định ưu tiên nghiệp vụ; Architect xác nhận tính khả thi kỹ thuật.

Quy tắc dừng: learner phải dừng tự quyết và tạo escalation record khi một đề xuất tác động đến tiền, nghĩa vụ pháp lý, dữ liệu cá nhân, an toàn thực phẩm, kiểm soát bảo mật, kiến trúc tích hợp, quyền phê duyệt, cam kết tiến độ hoặc chính sách nghiệp vụ. Escalation record phải có: mã artifact liên quan, mô tả vấn đề, giả định hiện tại, tác động nếu sai, vai trò cần quyết định, câu hỏi quyết định và trạng thái Verification required nếu chưa có bằng chứng đủ thẩm quyền.

3.1 Ranh giới sư phạm và giới hạn sử dụng của curriculum

Curriculum này là môi trường học có kiểm soát, sử dụng Nova Foods Trading & Manufacturing như một mô phỏng giáo dục. Mục tiêu là giúp learner luyện tạo và rà soát artifact BA có truy vết; không tạo thẩm quyền để learner đại diện doanh nghiệp, diễn giải luật, xác nhận tuân thủ, phê duyệt yêu cầu hoặc quyết định triển khai production. Mọi dữ liệu, vai trò, giao dịch và quyết định trong case đều là synthetic data.

Ranh giới	Curriculum này cung cấp	Curriculum này không cung cấp	Cách dùng đúng trong Nova Foods
Interview guide	Khung chuẩn bị bối cảnh, câu hỏi làm rõ, giả định và ghi nhận evidence vào artifact.	Kịch bản phỏng vấn bảo đảm khai thác đủ yêu cầu, kỹ năng điều phối stakeholder thực tế, hoặc cách xử lý xung đột quyền lực.	Learner có thể lập Question Log cho quy trình bán hàng, nhưng không được suy diễn câu trả lời mô phỏng là xác nhận từ Business Owner.
Exam preparation	Bài tập áp dụng thuật ngữ, mô hình hóa, truy vết và review artifact trong ngữ cảnh delivery.	Ngân hàng câu hỏi, mẹo thi, dự đoán đề thi, cam kết điểm số hoặc lộ trình vượt qua kỳ thi.	Nếu dùng thuật ngữ từ SRC-STD-BABOK-001 hoặc SRC-STD-ISTQB-001, chỉ dùng trong ranh giới nguồn đã xác minh tại /00-research/00_SOURCE_MAP.md.
Certification preparation	Cơ hội thực hành năng lực có thể liên quan đến BA, requirements, testing và kỹ thuật tài liệu hóa.	Khóa luyện chứng chỉ, xác nhận điều kiện dự thi, xác nhận số giờ kinh nghiệm, hoặc tuyên bố tương đương chứng nhận chuyên môn.	Không gắn nhãn artifact Nova Foods là bằng chứng đáp ứng điều kiện của bất kỳ tổ chức chứng nhận nào.
Supervised project experience	Tình huống mô phỏng, template, tiêu chí kiểm tra và phản hồi dựa trên artifact.	Trải nghiệm dự án có khách hàng thật, quyền truy cập hệ thống thật, hậu quả vận hành thật, mentoring tại dự án, hoặc trách nhiệm delivery.	Learner phải ghi rõ Project assumption và Verification required khi thông tin thực tế chưa tồn tại trong case.
Legal, accounting, security và domain authority	Cách nhận diện điểm cần xác minh và route đúng vai trò chuyên môn.	Diễn giải pháp luật, quyết định hạch toán, thiết kế kiểm soát bảo mật, xác nhận an toàn thực phẩm, hoặc xác nhận traceability production.	Nội dung liên quan dữ liệu cá nhân, hóa đơn, kế toán, an toàn thực phẩm và truy xuất nguồn gốc phải giữ nhãn Verification required cho đến khi được owner có thẩm quyền kiểm tra trong dự án thực.

Quy tắc sử dụng artifact học tập

1. Artifact được tạo trong curriculum là bản thực hành, không phải baseline dự án, không phải hợp đồng, không phải chứng cứ tuân thủ và không phải cấu hình triển khai.
2. Learner không được chuyển một giả định của Nova Foods thành business rule, yêu cầu bắt buộc hoặc acceptance criterion mà không nêu nguồn, chủ sở hữu quyết định và trạng thái xác minh.
3. Khi bài học tham chiếu chuẩn hoặc nguồn bên ngoài, learner phải giữ đúng phân loại nguồn từ /00-research/00_SOURCE_MAP.md: Normative standard, Official Vietnamese law, Industry good practice, Project convention hoặc Author recommendation.
4. Không được suy ra clause, page number, quotation, nghĩa vụ pháp lý chi tiết hoặc yêu cầu kỹ thuật chi tiết từ metadata, trang giới thiệu hoặc nguồn có trạng thái Limited-use caution.
5. Một sơ đồ hoạt động PlantUML chỉ là sơ đồ hoạt động PlantUML; không được gọi là BPMN nếu chưa được mô hình hóa và kiểm tra theo ký pháp BPMN phù hợp.
6. API example chỉ minh họa cách mô tả interface; không tự xác lập business rule, quyền truy cập, nghĩa vụ privacy, quy tắc kế toán hoặc quyết định kiến trúc.
7. Trạng thái corpus hiện là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; trạng thái này không xác nhận curriculum, artifact hoặc nội dung Nova Foods đã sẵn sàng cho production.

Ví dụ phân định đúng và sai

Tình huống học tập	Diễn đạt được phép	Diễn đạt không được phép
Hoàn tiền đơn bán hàng	“BR-SALES-004 là Project assumption; cần Business Owner và Accounting xác minh giới hạn hoàn tiền trước khi baseline.”	“Nova Foods bắt buộc hoàn tiền dưới một mức cụ thể theo quy định kế toán.”
Dữ liệu khách hàng	“Trường số điện thoại trong mô phỏng cần Verification required về mục đích xử lý, quyền truy cập và lưu giữ.”	“Thiết kế hiện tại đã tuân thủ pháp luật bảo vệ dữ liệu cá nhân.”
Truy xuất lô hàng	“Luồng truy xuất lô là bài tập phân tích; Domain Owner và Legal cần xác minh nghĩa vụ áp dụng thực tế.”	“Mô hình này đáp ứng đầy đủ yêu cầu pháp lý về an toàn thực phẩm.”
Kiểm thử API	“Test case mô phỏng kiểm tra phản hồi lỗi theo API contract đã giả định.”	“Test case chứng minh API production an toàn trước mọi tấn công.”

Ranh giới này bảo vệ tính trung thực học thuật và delivery reasoning: learner được thực hành cách nêu rõ điều mình biết, điều đang giả định, điều cần bằng chứng và điều phải chuyển tới người có thẩm quyền.

Assessment delivery-oriented: chấm chất lượng artifact, lập luận và kiểm soát quality gate

Đánh giá trong curriculum này đo năng lực tạo ra đầu ra có thể dùng để tiếp tục delivery, không đo khả năng ghi nhớ định nghĩa rời rạc. Một bài làm đạt yêu cầu phải cho thấy quan hệ nhất quán giữa nhu cầu, requirement, business rule, acceptance criteria, test case và quyết định còn mở. Trắc nghiệm ngắn chỉ được dùng như kiểm tra tự học thuật ngữ; không được dùng làm căn cứ chính để kết luận learner có khả năng thực hiện BA trong dự án.

Trục đánh giá	Bằng chứng phải nộp	Tiêu chí quan sát được	Dấu hiệu chưa đạt
Artifact quality	Requirement, process model, data mapping, API description, backlog item hoặc test set theo bài tập Nova Foods	Cấu trúc rõ; ID được dùng nhất quán; phạm vi, giả định, ngoại lệ và điều kiện kiểm tra được thể hiện	Nội dung chung chung, trộn business need với solution, thiếu điều kiện biên hoặc không thể kiểm tra
Reasoning quality	Decision log hoặc phần giải thích kèm artifact	Nêu được vấn đề, các lựa chọn đã cân nhắc, tiêu chí chọn, tác động và rủi ro còn lại	Chỉ nêu kết luận; dùng “best practice” như lý do thay cho bằng chứng ngữ cảnh
Traceability	Ma trận liên kết giữa NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03 và TC-SALES-012-07 khi bài tập sử dụng các ID này	Mỗi liên kết trả lời được: nhu cầu nào được đáp ứng, requirement nào được kiểm thử, test nào chứng minh acceptance criterion	Requirement không có nguồn gốc, acceptance criterion không gắn requirement, hoặc test case không chứng minh được điều kiện nghiệm thu
Decision criteria	Tiêu chí ưu tiên, so sánh phương án hoặc điều kiện chấp nhận	Tiêu chí cụ thể theo giá trị nghiệp vụ, rủi ro, khả thi kỹ thuật, vận hành và dữ liệu	Chọn phương án theo sở thích cá nhân hoặc chỉ vì “dễ làm” mà không nêu trade-off
Quality gates	Checklist tự rà soát và bản sửa sau review	Phát hiện lỗi, sửa có chủ đích, ghi nhận phần chưa đủ căn cứ là Project assumption hoặc Verification required	Tuyên bố chắc chắn về pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm khi chưa có xác minh phù hợp

Mỗi bài thực hành được đánh giá qua bốn quality gate liên tiếp:

1. Gate phạm vi: artifact xác định đúng vấn đề Nova Foods mô phỏng, actor, trigger, outcome và phần ngoài phạm vi. Bài không qua gate này không được đánh giá sâu về mô hình hay chi tiết giải pháp.
2. Gate kiểm tra được: requirement và acceptance criteria phải có điều kiện đầu vào, hành vi kỳ vọng và kết quả quan sát được. Ví dụ, yêu cầu hoàn tiền phải nêu dữ liệu đầu vào, trạng thái đơn hàng áp dụng, kết quả hệ thống và trường hợp bị từ chối; không chấp nhận câu “hệ thống xử lý hoàn tiền nhanh”.
3. Gate truy vết và nhất quán: learner phải đối chiếu ID, thuật ngữ, trạng thái và dữ liệu giữa các artifact. Khi REQ-FUNC-SALES-012 thay đổi, learner phải chỉ ra acceptance criteria và test case chịu ảnh hưởng, hoặc giải thích có căn cứ vì sao không bị ảnh hưởng.
4. Gate rủi ro và thẩm quyền: learner phải phân biệt quyết định có thể đưa ra trong bài tập với nội dung cần xác minh. Mọi diễn giải liên quan đến dữ liệu cá nhân, hóa đơn, kế toán, an toàn thực phẩm hoặc truy xuất nguồn gốc mà chưa được kiểm tra theo nguồn chính thức phải mang nhãn Verification required; không được chuyển thành yêu cầu production.

Rubric ưu tiên chất lượng sửa đổi hơn câu trả lời đầu tiên. Một artifact ban đầu có lỗi nhưng được learner tự phát hiện, truy nguyên tác động và sửa nhất quán sẽ được ghi nhận năng lực reasoning cao hơn artifact có bề ngoài hoàn chỉnh nhưng không giải thích được quyết định. Review cũng phải kiểm tra khả năng nêu giới hạn: learner cần nói rõ dữ kiện nào là synthetic data của Nova Foods, dữ kiện nào là Project assumption, và điểm nào không đủ thẩm quyền để kết luận.

Kết quả đánh giá được ghi theo trạng thái Đạt, Cần làm rõ hoặc Không đạt quality gate, kèm bằng chứng artifact và nhận xét có thể hành động. Đạt trong curriculum chỉ xác nhận đầu ra học tập đáp ứng tiêu chí bài tập ở trạng thái IN_REVIEW, Version v0.9.0, ngày 2026-08-07; không cấu thành phê duyệt nghiệp vụ, xác nhận tuân thủ, baseline dự án hoặc quyền triển khai production.

3.1 Tiêu chí đánh giá đầu ra: tạo được, giải thích được, nhận diện được và biết dừng đúng lúc

Đầu ra học tập được đánh giá bằng bằng chứng có thể kiểm tra trong artifact của Nova Foods Trading & Manufacturing — mô phỏng giáo dục; không đánh giá bằng việc nhớ định nghĩa đơn lẻ. Một learner chỉ được ghi nhận đạt khi vừa tạo được sản phẩm BA có cấu trúc, vừa giải thích được cơ sở quyết định, chỉ ra được rủi ro còn mở, và phân định được quyết định nào vượt thẩm quyền cá nhân.

Mã tiêu chí	Năng lực đầu ra phải chứng minh	Bằng chứng artifact tối thiểu	Không đạt khi
LO-OUT-001	Tạo artifact có thể được người khác sử dụng để tiếp tục delivery	Một artifact có ID, phạm vi, giả định, nguồn đầu vào, nội dung chính, liên kết truy vết và trạng thái rõ ràng; ví dụ REQ-FUNC-SALES-012 liên kết tới AC-SALES-012-03 và TC-SALES-012-07.	Viết mô tả chung chung, không xác định actor, điều kiện, dữ liệu, kết quả mong đợi hoặc không thể lần ngược về nhu cầu/rủi ro liên quan.
LO-OUT-002	Giải thích quyết định BA bằng tiêu chí thay vì ý kiến cá nhân	Ghi rõ phương án đã xem xét, tiêu chí lựa chọn, tác động tới quy trình, dữ liệu, người dùng và dependency; phân biệt Project assumption, Verification required và thông tin đã có căn cứ.	Kết luận “nên làm” mà không nêu vấn đề, lựa chọn thay thế, trade-off, người chịu tác động hoặc căn cứ của kết luận.
LO-OUT-003	Nhận diện rủi ro và chuyển rủi ro thành hành động quản trị được	Risk entry nêu trigger, hậu quả, mức tác động, dependency, owner xử lý và điểm cần xác minh; ví dụ dữ liệu số hóa đơn trong luồng hoàn tiền có thể liên quan Accounting và cần Verification required.	Chỉ ghi “có rủi ro” mà không mô tả điều gì có thể xảy ra, ai bị ảnh hưởng, thông tin nào thiếu hoặc ai phải xử lý.
LO-OUT-004	Biết khi nào không được tự quyết và thực hiện escalation đúng vai trò	Escalation note nêu quyết định bị chặn, lý do vượt thẩm quyền, câu hỏi cần trả lời, artifact liên quan, owner nhận escalation và tác động nếu chưa có phản hồi.	Tự đặt business rule, diễn giải nghĩa vụ pháp lý, chấp nhận rủi ro bảo mật, hoặc quyết định hạch toán mà không có owner có thẩm quyền.

Quy tắc chấm bằng chứng: artifact được xem là dùng được cho mục đích học tập khi một reviewer có thể trả lời bốn câu hỏi: (1) learner đã tạo ra cái gì và phạm vi ở đâu; (2) vì sao lựa chọn này được đề xuất; (3) điều gì có thể sai hoặc chưa được xác minh; và (4) ai phải quyết định phần còn lại. Nếu bất kỳ câu nào không trả lời được từ artifact hoặc liên kết của nó, learner phải chỉnh sửa artifact thay vì bổ sung lời giải thích miệng.

Tình huống Nova Foods mô phỏng	Learner được làm	Learner không được tự quyết	Escalation bắt buộc
Yêu cầu hoàn tiền đơn bán	Phác thảo workflow, xác định actor, dữ liệu đầu vào, trạng thái yêu cầu, acceptance criteria và câu hỏi mở cho REQ-FUNC-SALES-012.	Tự ấn định ngưỡng tiền hoàn, cách hạch toán, điều kiện xuất hóa đơn điều chỉnh hoặc thời hạn lưu chứng từ.	Business Owner xác nhận chính sách; Accounting xác nhận tác động hạch toán/chứng từ; Legal xác minh nội dung có yếu tố pháp lý.
API đồng bộ khách hàng	Làm rõ consumer, payload nghiệp vụ cần thiết, lỗi mong đợi và truy vết từ requirement đến API-xxx.	Chọn cơ chế xác thực, quyết định quyền truy cập, retention dữ liệu cá nhân hoặc chấp nhận lộ lọt dữ liệu.	Architect quyết định kiến trúc; Security đánh giá kiểm soát; Legal xác minh yêu cầu liên quan dữ liệu cá nhân.
Truy xuất lô nguyên liệu	Mô hình hóa câu hỏi nghiệp vụ, điểm ghi nhận lô, dữ liệu cần truy vết và các trường hợp thiếu dữ liệu.	Khẳng định quy tắc là nghĩa vụ an toàn thực phẩm hiện hành hoặc tự chấp nhận khoảng trống truy xuất.	Domain Owner xác nhận vận hành; Legal xác minh áp dụng pháp lý; PM xử lý tác động phạm vi, tiến độ và dependency.

Một câu trả lời học tập tốt không phải là câu trả lời chắc chắn trong mọi tình huống. Với nội dung thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc kiểm soát bảo mật chưa được xác minh từ nguồn hiện hành, learner phải ghi Verification required, giữ nguyên câu hỏi cần xác minh và chuyển tới đúng owner. Đây là bằng chứng của năng lực delivery-oriented: BA làm rõ và bảo vệ chất lượng quyết định, không thay thế thẩm quyền của Senior BA, PM, Architect, Business Owner, Legal, Accounting, Security hoặc Domain Owner.

4. Nova Foods running-case progression và technical depth ladder

Nova Foods Trading & Manufacturing là một single running case study xuyên suốt 26 chapter. Case không được thay bằng doanh nghiệp, ngành hay bối cảnh khác khi learner chuyển từ phân tích nghiệp vụ sang đặc tả, kiểm thử và vận hành. Mọi artifact kế tiếp phải kế thừa thuật ngữ, mã định danh, giả định và quyết định đã được ghi nhận trước đó; nếu xuất hiện mâu thuẫn, learner phải ghi nhận gap hoặc câu hỏi cần xác minh thay vì tự đổi bối cảnh.

Bối cảnh mô phỏng thống nhất: Nova Foods nhận đơn của khách hàng phân phối, bán thành phẩm thực phẩm đóng gói, lập kế hoạch đáp ứng đơn, mua nguyên liệu, quản lý tồn kho và lô hàng, sản xuất, giao hàng, ghi nhận nghiệp vụ tài chính liên quan và theo dõi báo cáo vận hành. Toàn bộ tổ chức, con người, số liệu, giao dịch và quyết định trong case là synthetic data phục vụ giáo dục.

Chặng tiến triển	Câu hỏi BA cần trả lời từ nguyên lý đầu tiên	Artifact Nova Foods tối thiểu	Ví dụ truy vết kế tiếp
AS-IS	Hiện nay ai làm gì, dùng thông tin nào, tạo ra kết quả nào và điểm bàn giao ở đâu?	Process narrative, stakeholder map, AS-IS flow cho tiếp nhận và xử lý đơn hàng	Pain point về nhập lại thông tin khách hàng được giữ nguyên để phân tích gap
Gap	Kết quả hiện tại khác kết quả mong muốn ở đâu; nguyên nhân, tác động và bằng chứng là gì?	Gap register, problem statement, impact assessment	GAP-SALES-001 liên kết tới nhu cầu giảm nhập trùng dữ liệu đơn hàng
TO-BE	Quy trình mục tiêu thay đổi trách nhiệm, điểm quyết định, dữ liệu và ngoại lệ như thế nào?	TO-BE process model, scope boundary, decision log	TO-BE tạo yêu cầu cho bước kiểm tra trạng thái khách hàng trước xác nhận đơn
Requirements	Hệ thống hoặc quy trình phải cung cấp năng lực nào để đạt TO-BE, cho ai và trong điều kiện nào?	Business need, functional requirement, non-functional concern, acceptance criteria	NEED-SALES-001 → REQ-FUNC-SALES-012 → AC-SALES-012-01
Rules	Quyết định nào phải nhất quán, điều kiện nào kích hoạt hoặc chặn hành động, và ai sở hữu chính sách?	Business rule catalog, rule-to-requirement matrix	BR-SALES-004 được tham chiếu bởi REQ-FUNC-SALES-012; giá trị ngưỡng là Project assumption hoặc Verification required nếu chưa được owner xác nhận
Data	Đối tượng nghiệp vụ nào phải được nhận diện, thuộc tính nào bắt buộc, dữ liệu nào là nguồn gốc và quan hệ nào cần bảo toàn?	Conceptual data model, data dictionary, validation matrix	Customer, Sales Order, Order Line, Product, Batch là các đối tượng có traceability tới requirement và rule
API	Hệ thống nào trao đổi dữ liệu gì, khi nào, với định dạng phản hồi và lỗi nghiệp vụ nào?	API use case, endpoint contract draft, payload field mapping, error catalogue	API-SALES-001 truy vết đến REQ-FUNC-SALES-012, BR-SALES-004 và các acceptance criteria liên quan
Workflow	Ai khởi tạo, kiểm tra, phê duyệt, xử lý ngoại lệ và hoàn tất công việc; trạng thái nào được phép chuyển?	Workflow specification, state transition table, role matrix	Một đơn hàng chỉ chuyển từ Draft sang Confirmed khi các điều kiện requirement và rule được đáp ứng
Testing	Bằng chứng nào chứng minh requirement, rule, dữ liệu, API và workflow hoạt động theo kỳ vọng?	Test scenario, test case, test data set, defect record	TC-SALES-012-07 kiểm tra phản hồi lỗi khi request vi phạm BR-SALES-004
Operations	Sau khi đưa vào sử dụng, ai theo dõi sự cố, chất lượng dữ liệu, ngoại lệ quy trình và thay đổi có kiểm soát?	Operational handoff note, monitoring question set, support triage flow, change intake	Sự cố đồng bộ đơn hàng được đối chiếu với API-SALES-001, dữ liệu liên quan và test evidence trước khi mở change request

Quy tắc chuyển chặng và truy vết

1. Không tạo TO-BE chỉ từ ý tưởng giải pháp. Mỗi thay đổi phải truy ngược được tới AS-IS evidence hoặc gap đã ghi nhận.
2. Không coi business rule là cấu hình kỹ thuật mặc định. Rule phải có owner nghiệp vụ, điều kiện áp dụng, kết quả khi vi phạm và liên kết requirement; nội dung thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc chưa được xác minh phải gắn Verification required.
3. Không thiết kế API trước khi xác định đối tượng dữ liệu, mục đích trao đổi và lỗi nghiệp vụ cần xử lý. OpenAPI hoặc endpoint contract chỉ biểu diễn interface; chúng không tự tạo business policy.
4. Không đóng workflow chỉ bằng sơ đồ. Workflow phải nêu trạng thái đầu vào, actor, quyết định, ngoại lệ, trạng thái đầu ra và requirement/rule chi phối.
5. Không coi testing là bước tách rời. Mỗi test case phải kiểm tra được một hoặc nhiều acceptance criteria, rule, validation dữ liệu, hành vi API hoặc chuyển trạng thái workflow.
6. Không coi operations là “sau dự án”. Từ khi viết requirement, learner phải xác định dữ liệu hoặc sự kiện nào hỗ trợ điều tra lỗi, đối soát giao dịch và tiếp nhận thay đổi.

Ví dụ chuỗi nhất quán trong Nova Foods

Liên kết	Nội dung mô phỏng
GAP-SALES-001	Nhân viên kinh doanh phải kiểm tra thủ công thông tin khách hàng từ nhiều nguồn trước khi xác nhận đơn.
NEED-SALES-001	Cần giảm việc xác minh phân tán để nhân viên có thể xử lý đơn với thông tin khách hàng nhất quán.
REQ-FUNC-SALES-012	Hệ thống phải kiểm tra trạng thái khách hàng trước khi cho phép xác nhận đơn hàng.
BR-SALES-004	Điều kiện cho phép xác nhận đơn được xác định bởi chính sách nghiệp vụ của Nova Foods; giá trị điều kiện cụ thể chưa được xác nhận được gắn Project assumption hoặc Verification required.
DATA-SALES-003	Đối tượng Customer cần có định danh, trạng thái nghiệp vụ và thời điểm cập nhật để phục vụ kiểm tra.
API-SALES-001	Consumer gửi yêu cầu xác nhận đơn; service phản hồi kết quả thành công hoặc lỗi nghiệp vụ có mã xác định.
WF-SALES-002	Luồng xác nhận đơn dừng tại trạng thái kiểm tra khi điều kiện của BR-SALES-004 chưa đạt.
TC-SALES-012-07	Test case dùng khách hàng synthetic có trạng thái không đáp ứng điều kiện để xác nhận hệ thống chặn chuyển trạng thái và trả lỗi mong đợi.
OPS-SALES-001	Support triage đối chiếu mã lỗi, mã đơn, thời điểm xử lý và phiên bản interface để phân loại sự cố hoặc yêu cầu thay đổi.

Mọi ví dụ phải dùng người mô phỏng, chẳng hạn Nguyễn Minh An (simulated Sales Executive), mã khách hàng synthetic như CUS-NF-00021, và giao dịch mô phỏng như SO-NF-2026-00018. Không dùng dữ liệu cá nhân thật, thông tin đăng nhập thật, API key thật, token thật hoặc secret thật. Nếu cần minh họa tham chiếu bí mật, chỉ dùng safe secret reference như secretRef: "vault://nova-foods/nonprod/crm-sync"; tham chiếu này không đại diện cho kho bí mật, hệ thống hay quyền truy cập có thật.

4.1 Thứ tự đưa domain vào curriculum và kiểm soát độ sâu kỹ thuật

Nova Foods Trading & Manufacturing là một case study duy nhất xuyên suốt 26 chapter. Domain được mở rộng theo quan hệ nghiệp vụ có thể quan sát trước, rồi mới đến quan hệ liên phòng ban, tích hợp và kiểm soát. Cách sắp xếp này tránh yêu cầu người học hiểu API, dữ liệu tồn kho, bút toán hoặc workflow phê duyệt khi chưa hiểu tác nhân, mục tiêu và điểm đau của quy trình bán hàng cơ bản.

Cụm chapter	Domain được giới thiệu	Mục đích học tập trong Nova Foods	Độ sâu tối đa được phép	Boundary chống dồn technical depth
Chapter 1–4	CRM	Nhận diện khách hàng, đầu mối liên hệ, cơ hội bán hàng và nhu cầu của đội kinh doanh. Người học mô tả được ai tương tác với Nova Foods và vì sao cần quản lý thông tin khách hàng.	concept-level	Chỉ dùng ngôn ngữ business capability, actor, pain point và outcome; chưa yêu cầu mô hình dữ liệu CRM, phân quyền chi tiết hoặc tích hợp.
Chapter 5–7	Sales	Theo dõi hành trình từ cơ hội đến báo giá, đơn bán và nhu cầu giao hàng; xác định handoff giữa Sales và các bộ phận tiếp nhận đơn.	analysis-level	Tập trung AS-IS, vấn đề, stakeholder và phạm vi; chưa đặc tả endpoint, cấu trúc payload, trạng thái hệ thống chi tiết hoặc logic tính tiền.
Chapter 8–9	Pricing	Làm rõ vì sao giá có thể khác theo khách hàng, sản phẩm, số lượng hoặc chương trình bán hàng trong bối cảnh mô phỏng Nova Foods.	analysis-level	Dạy cách phân biệt policy, exception và decision owner; không đưa công thức định giá phức tạp, thuật toán tối ưu hoặc cấu hình engine giá.
Chapter 10–12	Procurement và Inventory	Liên kết nhu cầu mua nguyên liệu, tiếp nhận hàng, kiểm tra tồn kho và khả năng đáp ứng đơn bán. Người học thấy được Sales không vận hành độc lập với nguồn cung và tồn kho.	analysis-level chuyển sang specification-level có kiểm soát	Chỉ đặc tả một lát cắt có ưu tiên, như nhu cầu mua phát sinh từ thiếu hụt mô phỏng; chưa đồng thời yêu cầu kiến trúc kho, đồng bộ thời gian thực và xử lý mọi ngoại lệ tồn kho.
Chapter 13–15	Manufacturing	Mở rộng case từ doanh nghiệp thương mại sang bối cảnh sản xuất: nguyên liệu, kế hoạch sản xuất, thành phẩm và tác động đến khả năng giao hàng.	specification-level	Chỉ dùng luồng sản xuất đủ để phân tích dependency với Inventory và Sales; không mô phỏng chi tiết MES, định mức kỹ thuật thực tế, công thức sản xuất thật hoặc kiểm soát nhà máy production.
Chapter 16–18	Approval	Đưa approval vào sau khi người học đã nhận diện được quyết định có rủi ro, ví dụ ngoại lệ giá, mua hàng hoặc điều chỉnh đơn.	specification-level	Approval không được dạy như một chuỗi nút bấm độc lập; mỗi bước phải truy về business decision, điều kiện kích hoạt, vai trò quyết định và kết quả cần ghi nhận.
Chapter 19–21	Finance	Kết nối giao dịch bán, mua, tồn kho và sản xuất với nhu cầu kiểm soát tài chính, đối soát và chứng từ ở mức nghiệp vụ.	specification-level	Nội dung thuế, kế toán, hóa đơn và hạch toán chỉ là bối cảnh mô phỏng. Mọi diễn giải thành nghĩa vụ pháp lý hoặc quy tắc production phải gắn Verification required và được review bởi owner pháp lý/kế toán có thẩm quyền.
Chapter 22–24	BI	Chuyển các câu hỏi vận hành thành nhu cầu báo cáo, chỉ số và góc nhìn quản trị: doanh số, hiệu quả giá, tồn kho, mua hàng và tiến độ sản xuất.	testable-level	Bắt đầu từ decision question và metric definition trước; không yêu cầu thiết kế data warehouse, pipeline, semantic layer hoặc công cụ BI cụ thể nếu chưa có nhu cầu đã được phân tích.
Chapter 25–26	Liên domain có kiểm soát	Tổng hợp CRM, Sales, Pricing, Procurement, Inventory, Manufacturing, Finance, Approval và BI thành phạm vi delivery nhất quán cho Nova Foods.	governance-level	Chỉ đánh giá tính nhất quán, dependency, rủi ro, traceability và khả năng bàn giao; không mở thêm domain mới hoặc thay case study.

Quy tắc sequencing bắt buộc

1. Mỗi domain mới phải trả lời được câu hỏi nghiệp vụ mà domain trước tạo ra. Ví dụ: Sales tạo câu hỏi “có thể đáp ứng đơn không”; Inventory và Procurement mới được đưa vào để phân tích câu hỏi đó.
2. CRM, Sales và Pricing là lớp tiếp cận khách hàng và thương mại; Procurement, Inventory và Manufacturing là lớp đáp ứng; Approval và Finance là lớp kiểm soát; BI là lớp quan sát và hỗ trợ quyết định. Không đảo thứ tự này chỉ để giới thiệu công cụ kỹ thuật sớm.
3. Một chapter chỉ được tăng một nấc độ sâu chủ đạo. Nếu nội dung đang ở analysis-level, chapter không được đồng thời đòi hỏi người học hoàn tất đặc tả tích hợp, thiết kế dữ liệu và kiểm thử chi tiết.
4. Khi một quyết định liên domain xuất hiện, curriculum phải quay lại artifact đã học của Nova Foods thay vì tạo tình huống hoặc doanh nghiệp mới. Ví dụ, ngoại lệ giá trong Pricing được liên kết với Sales và Approval của cùng khách hàng, đơn hàng và bối cảnh mô phỏng đã thiết lập.
5. governance-level không đồng nghĩa với quyền phê duyệt nghiệp vụ, pháp lý, kế toán hay production. Đây là năng lực nhận diện owner, dependency, bằng chứng cần có và điểm cần escalation trong case study giáo dục.

Technical depth ladder theo cụm chapter

Trong /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, technical depth được tăng có kiểm soát qua 26 chapter để người học đi từ hiểu vấn đề đến tạo artifact có thể được đội delivery kiểm tra. Đây là Project convention và Author recommendation cho Nova Foods Trading & Manufacturing — mô phỏng giáo dục; không phải diễn giải điều khoản của SRC-STD-ISO29148-001, SRC-STD-BPMN-001, SRC-STD-UML-001, SRC-STD-ISTQB-001 hoặc SRC-STD-OAS-001. Trạng thái áp dụng: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Cụm chapter	Technical depth	Người học phải làm được	Artifact hoặc bằng chứng tối thiểu	Ranh giới không được vượt qua
Chapter 1–4	concept-level	Phân biệt business problem, stakeholder need, process, requirement, rule, data và solution; giải thích vì sao một phát biểu chưa đủ điều kiện trở thành requirement.	Problem statement, stakeholder map, glossary entry, process scope và danh sách giả định được gắn nhãn.	Không viết API contract, data schema chi tiết, test case hoặc quyết định kiến trúc. Không biến ý kiến stakeholder thành fact.
Chapter 5–9	analysis-level	Phân tích tác nhân, trigger, luồng chính, ngoại lệ, pain point, dependency, business outcome và khoảng trống giữa hiện trạng với mục tiêu.	AS-IS analysis, gap register, stakeholder concern log, business need có ID như NEED-SALES-001, và traceability sơ bộ.	Không tự suy diễn solution, SLA, quyền truy cập, nghĩa vụ pháp lý hoặc accounting treatment khi chưa có nguồn và owner có thẩm quyền.
Chapter 10–16	specification-level	Chuyển nhu cầu đã phân tích thành requirement rõ phạm vi, business rule, acceptance criterion, data definition, workflow logic và interface expectation.	Requirement như REQ-FUNC-SALES-012, business rule như BR-SALES-004, acceptance criterion như AC-SALES-012-03, field catalogue, decision table và API expectation có truy vết.	Không thay business rule bằng mô tả giao diện; không coi OpenAPI, BPMN hoặc UML là nguồn tạo ra nghiệp vụ. Mọi chi tiết pháp lý, thuế, kế toán, privacy, an toàn thực phẩm hoặc truy xuất phải là Verification required hoặc Project assumption khi chưa được xác minh phù hợp.
Chapter 17–21	testable-level	Chứng minh requirement có thể quan sát và kiểm tra qua positive path, negative path, boundary, exception, data validation và integration response.	Test condition, test case như TC-SALES-012-07, test data set mô phỏng, expected result, defect evidence và liên kết REQ → AC → TC.	Không tuyên bố hệ thống đã pass, production-ready hoặc compliant chỉ vì test case đã được viết. Không dùng test data để suy ra dữ liệu thật hoặc thông tin bí mật.
Chapter 22–26	governance-level	Quản trị thay đổi, version, dependency, risk, decision, quality gate, handoff và operational readiness của các artifact đã tạo.	Traceability matrix hoàn chỉnh, change impact assessment, decision log, risk/escalation record, handoff checklist và operational evidence expectation.	Không tự xác nhận baseline, approval, legal compliance, accounting approval hoặc production release. Mọi thay đổi sau baseline giả định phải đi qua Change Request theo quy ước CR-{DOMAIN}-{NNN}.

Quy tắc chuyển cấp độ

1. Một artifact chỉ được nâng từ concept-level lên analysis-level khi đã xác định rõ vấn đề, phạm vi và stakeholder bị ảnh hưởng; mô tả giải pháp không thay thế bằng chứng về vấn đề.
2. Một mục chỉ được nâng lên specification-level khi có ID ổn định, nguồn hoặc giả định được phân loại, điều kiện áp dụng, ngoại lệ và tiêu chí kiểm tra sơ bộ.
3. Một requirement chỉ đạt testable-level khi người kiểm thử độc lập có thể xác định precondition, dữ liệu đầu vào, hành động, kết quả mong đợi và liên kết đến acceptance criterion mà không phải hỏi lại tác giả về ý nghĩa chính.
4. governance-level không làm artifact “đúng” hơn về nội dung nghiệp vụ; cấp độ này xác nhận artifact có owner, version, traceability, tác động thay đổi và đường escalations rõ ràng.
5. Nếu thiếu bằng chứng, thiếu owner quyết định, hoặc có nội dung thuộc pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hay truy xuất nguồn gốc, mức độ kỹ thuật phải dừng ở mô tả Project assumption hoặc Verification required; không được nâng cấp bằng suy đoán.

Ví dụ về kiểm tra độ sâu: câu “hệ thống phải kiểm tra hạn mức” chỉ ở mức concept-level hoặc analysis-level. Khi được gắn REQ-FUNC-SALES-012, nêu điều kiện, dữ liệu cần dùng, phản hồi khi không đạt và AC-SALES-012-03, nó đạt specification-level. Khi có TC-SALES-012-07 kiểm tra giá trị dưới ngưỡng, bằng ngưỡng, vượt ngưỡng và dữ liệu không hợp lệ, nó đạt testable-level. Khi các liên kết, thay đổi và quyết định liên quan được ghi nhận có kiểm soát, nó mới tham gia được vào governance-level.

Nguyên tắc dữ liệu mô phỏng và tham chiếu bí mật an toàn trong Nova Foods

Mọi ví dụ, bài tập, template, sơ đồ, payload API, test case và minh họa vận hành trong corpus sử dụng dữ liệu tổng hợp cho Nova Foods Trading & Manufacturing — mô phỏng giáo dục. Không sao chép, suy diễn, ghép nối hoặc trình bày dữ liệu có thể nhận diện cá nhân, khách hàng, nhà cung cấp, nhân viên, giao dịch, cấu hình hay bí mật từ môi trường thực tế. Quy tắc này áp dụng nhất quán cho toàn bộ 26 chapter và mọi artifact liên kết.

Loại nội dung	Quy tắc bắt buộc	Ví dụ được phép	Không được phép
Synthetic data	Tạo mới cho mục đích học tập; không có nguồn production và không có khả năng đối chiếu về một chủ thể thực.	Mã khách hàng CUS-NF-000184, sản phẩm SKU-NF-CHILI-250G, địa chỉ 127 Đường Mô Phỏng, Quận 7, TP. Hồ Chí Minh.	Tên, số điện thoại, email, địa chỉ, mã số thuế hoặc số tài khoản lấy từ hồ sơ thực.
Simulated people	Dùng nhân vật hư cấu với vai trò nghiệp vụ rõ ràng; danh tính chỉ phục vụ traceability học tập.	Nguyễn Minh An — Sales Operations Lead (simulated), Trần Gia Hân — Procurement Analyst (simulated).	Gán tên người thật vào tình huống Nova Foods hoặc mô tả họ đã đưa ra quyết định thực tế.
Simulated transactions	Giao dịch phải có mã, thời điểm, số lượng và giá trị mô phỏng; không khẳng định là chứng từ hợp pháp hay số liệu kế toán thực.	SO-NF-202608-0042, ngày 2026-08-07, giá trị 12.500.000 VND, trạng thái Pending Approval.	Số hóa đơn, sao kê, đơn hàng, lịch sử thanh toán hoặc số liệu doanh thu lấy từ doanh nghiệp thật.
Safe secret references	Chỉ biểu diễn sự tồn tại, owner, môi trường và cơ chế quản lý secret; giá trị secret luôn là placeholder không sử dụng được.	Authorization: Bearer ${NOVA_FOODS_API_TOKEN}, secretRef: vault://nova-foods/nonprod/erp-api-client.	API key, password, cookie phiên đăng nhập, private key, connection string có thông tin xác thực hoặc token có khả năng hoạt động.

Quy tắc tạo và ghi nhãn dữ liệu: mỗi tập dữ liệu minh họa phải thể hiện rõ tính mô phỏng bằng ít nhất một trong các dấu hiệu: tiền tố NF-, trường dataClassification: SYNTHETIC, chú thích (simulated), hoặc một ghi chú ngay cạnh bảng/payload. Mã định danh mô phỏng phải ổn định trong phạm vi ví dụ đang truy vết; chẳng hạn CUS-NF-000184 phải tiếp tục chỉ cùng một khách hàng mô phỏng khi được tham chiếu giữa requirement, API example và test case của cùng chuỗi học tập.

Quy tắc bảo vệ ngữ cảnh nhạy cảm: thông tin về thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc và hóa đơn trong ví dụ chỉ nhằm minh họa phân tích nghiệp vụ. Nếu một chi tiết được diễn đạt như nghĩa vụ pháp lý, quy tắc hạch toán hoặc yêu cầu tuân thủ, nội dung phải được gắn Verification required hoặc Project assumption cho đến khi được kiểm tra bởi vai trò có thẩm quyền. Ví dụ, một trường taxCode có thể dùng giá trị tổng hợp 0319999999, nhưng không được kết luận trường đó thỏa điều kiện pháp lý hay đủ để phát hành hóa đơn.

Mẫu tham chiếu secret an toàn:

integration:
  system: Nova Foods ERP Sandbox
  environment: nonprod
  clientId: ${NOVA_FOODS_ERP_CLIENT_ID}
  clientSecretRef: vault://nova-foods/nonprod/erp-client-secret
  authorization: Bearer ${NOVA_FOODS_ERP_ACCESS_TOKEN}

Placeholder chỉ mô tả hợp đồng giao tiếp và không phải bằng chứng rằng secret vault, client, token hoặc môi trường tương ứng đã tồn tại. Không ghi secret vào Markdown, ảnh chụp màn hình, file OpenAPI, test evidence, commit message hoặc defect description. Khi cần minh họa lỗi xác thực, chỉ dùng thông báo tổng quát như 401 Unauthorized — simulated credential rejected; không đưa token bị che một phần vì ngay cả chuỗi che một phần cũng có thể bắt nguồn từ secret thực.

4.1 Quy tắc bất biến của single running case study Nova Foods

Toàn bộ 26 chapter sử dụng duy nhất Nova Foods Trading & Manufacturing là running case study. Nova Foods là doanh nghiệp mô phỏng phục vụ giáo dục; mọi tổ chức, nhân sự, sản phẩm, giao dịch, chứng từ, số liệu, quyết định và sự kiện trong case đều là synthetic data. Learner không được chuyển sang một doanh nghiệp, ngành hàng hoặc dự án minh họa khác để giải quyết bài tập chính, vì việc thay case làm đứt traceability từ problem statement đến artifact delivery.

Quy tắc ID	Quy tắc áp dụng	Bằng chứng thực hiện trong chapter	Không được phép
CASE-CONT-001	Mọi chapter phải tham chiếu Nova Foods khi cần bối cảnh nghiệp vụ, stakeholder, dữ liệu hoặc artifact.	Chapter nêu rõ artifact đang mở rộng, kiểm tra hoặc liên kết với artifact Nova Foods đã có.	Dùng công ty giả định thứ hai như case chính hoặc thay Nova Foods bằng một case mới.
CASE-CONT-002	Một sự kiện nghiệp vụ chỉ có một nhận diện ổn định trong corpus.	Mã, tên và ý nghĩa đã công bố của entity, requirement, rule, API, workflow, test hoặc issue được giữ nguyên khi tái sử dụng.	Đổi tên, đổi mã hoặc đổi ý nghĩa artifact để tạo ví dụ thuận tiện mà không có Change Request hợp lệ.
CASE-CONT-003	Chapter sau chỉ được mở rộng, làm rõ, kiểm tra hoặc quản trị artifact của chapter trước.	Có liên kết ngược đến ID nguồn, chẳng hạn requirement phải chỉ ra need hoặc gap liên quan.	Viết artifact độc lập không có nguồn gốc trong case, rồi gọi là một phần của Nova Foods.
CASE-CONT-004	Mâu thuẫn trong case là đối tượng phân tích, không phải lý do thay case.	Ghi nhận conflict, assumption, risk hoặc Verification required với owner phù hợp.	Tự sửa sự kiện, rule, số liệu hoặc quyết định mô phỏng để che mâu thuẫn.
CASE-CONT-005	Nova Foods không được trình bày như doanh nghiệp thật hoặc hệ thống production.	Nội dung dùng nhãn “mô phỏng giáo dục”, “Project assumption” hoặc Verification required khi cần.	Khẳng định Nova Foods đã vận hành, đã tuân thủ pháp luật, đã phê duyệt hoặc đã triển khai thực tế.

Đơn vị continuity tối thiểu là một chuỗi có thể truy vết: bối cảnh Nova Foods → vấn đề hoặc cơ hội đã ghi nhận → artifact phân tích → artifact delivery liên quan → bằng chứng kiểm tra hoặc quyết định quản trị. Ví dụ, nếu một chapter tạo NEED-SALES-001, chapter khác chỉ được diễn giải thành requirement, acceptance criterion, test condition hoặc truy vết liên quan khi vẫn bảo toàn ID, phạm vi và giả định đã công bố; không được tạo một nhu cầu “Sales” mới với nội dung tương đương chỉ vì thay đổi format bài học.

Loại thay đổi đối với case	Xử lý bắt buộc	Trạng thái cho phép
Bổ sung chi tiết chưa từng được xác định nhưng không mâu thuẫn nội dung hiện hữu	Gắn nguồn artifact, nêu rõ đây là Project assumption nếu chưa được xác minh, và liên kết tới chapter sử dụng.	Có thể đưa vào bản nháp IN_REVIEW.
Phát hiện mâu thuẫn về thuật ngữ, ID, dữ liệu hoặc quan hệ artifact	Ghi nhận issue; giữ nguyên bản ghi cũ để truy vết; đề xuất thay đổi theo CR-{DOMAIN}-{NNN} sau baseline.	Không tự sửa im lặng.
Cần minh họa ngoài Nova Foods để giải thích khái niệm phổ quát	Chỉ dùng ví dụ vi mô, không tạo narrative, stakeholder, transaction hay artifact chain cạnh tranh với Nova Foods.	Chỉ là minh họa phụ; bài tập và deliverable vẫn thuộc Nova Foods.
Cần thay đổi ngành, pháp nhân, thị trường hoặc mục tiêu cốt lõi của Nova Foods	Escalate tới Owner vì thay đổi này phá vỡ continuity của curriculum.	Không đưa vào chapter như thay thế case.

Các tên người mô phỏng, mã giao dịch mô phỏng và safe secret references có thể được bổ sung dần, nhưng phải thuộc cùng universe Nova Foods và không chứa dữ liệu cá nhân thật, secret thật, URL nội bộ thật, token, mật khẩu hoặc thông tin truy cập. Nếu một nội dung thuộc thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc chưa được kiểm chứng trực tiếp với nguồn chính thức hiện hành, nội dung đó phải được gắn Verification required hoặc Project assumption; không biến giả định của case thành nghĩa vụ pháp lý hay quyết định production.

5. Testing mini-book placement, dependency chain và phase handoff

5.1 Vị trí kiến trúc của testing mini-book trong 26 chapter

Testing không được đặt như phụ lục kiểm tra cuối khóa hoặc kỹ năng riêng của QA. Trong curriculum 26 chapter, cụm Parts 18, 19 và 20 là một mini-book liên tiếp về testing for BA: người học chuyển từ việc diễn đạt nhu cầu và yêu cầu sang thiết kế bằng chứng có thể kiểm tra, hỗ trợ làm rõ lỗi nghiệp vụ, và chuẩn bị đầu vào cho nghiệm thu. Cụm này chỉ sử dụng Nova Foods Trading & Manufacturing là running case mô phỏng; không tạo case, pháp nhân hoặc dữ liệu vận hành cạnh tranh.

Vị trí trong 26 chapter	Vai trò trong mini-book testing for BA	Deliverable học tập trọng tâm	Ranh giới trách nhiệm BA
Part 18	Đặt nền tảng tư duy kiểm thử cho BA: vì sao requirement phải tạo ra bằng chứng quan sát được và vì sao lỗi cần được diễn đạt theo tác động nghiệp vụ.	Bản đồ liên kết giữa artifact nghiệp vụ và đối tượng kiểm thử của Nova Foods.	BA không thay thế Test Manager, QA Engineer, Developer hoặc người có thẩm quyền quyết định chất lượng production.
Part 19	Đào sâu việc chuyển hóa hành vi nghiệp vụ mong đợi thành các tình huống kiểm tra có cấu trúc, có thể review với stakeholder.	Bộ scenario minh họa gắn với requirement của Nova Foods, dùng dữ liệu mô phỏng.	BA làm rõ ý nghĩa nghiệp vụ, điều kiện, ngoại lệ và tiêu chí có thể xác minh; không tự xác nhận hệ thống đã đạt chất lượng.
Part 20	Kết nối kiểm thử với vòng phản hồi delivery: ghi nhận phát hiện, làm rõ tác động requirement và hỗ trợ chuẩn bị nghiệm thu nghiệp vụ.	Gói handoff cho hoạt động kiểm thử và nghiệm thu trong case study.	BA hỗ trợ phân tích và truy vết; quyết định sửa lỗi, phát hành hay chấp nhận rủi ro thuộc governance dự án được chỉ định.

5.2 Quy tắc đặt cụm Parts 18–20

1. Đặt sau nền tảng discovery, process analysis, requirement và acceptance-oriented thinking. Người học phải đã nhìn thấy requirement như một cam kết diễn đạt được, thay vì xem testing là thao tác tạo danh sách kiểm tra độc lập với nghiệp vụ.
2. Đặt trước các nội dung handbook đòi hỏi evidence-based delivery. Các chapter sau được phép giả định rằng người học đã hiểu sự khác biệt giữa mô tả chức năng, điều kiện kiểm tra, bằng chứng thực thi và phản hồi nghiệp vụ.
3. Giữ ba part như một cụm không tách rời. Part 18 giải thích mục tiêu BA trong testing; Part 19 luyện cấu trúc hóa đối tượng cần kiểm tra; Part 20 đặt kết quả vào ngữ cảnh delivery và handoff. Không đảo Part 20 lên trước Part 18 hoặc dạy Part 19 như một danh mục mẫu đơn lẻ.
4. Không biến cụm này thành khóa đào tạo automation hoặc performance engineering. Curriculum công nhận các lĩnh vực đó tồn tại nhưng trọng tâm của mini-book là năng lực BA tạo rõ ràng, truy vết và hội thoại nghiệp vụ phục vụ kiểm thử.
5. Mọi minh họa Nova Foods là synthetic data only. Ví dụ có thể dùng ID đã quy ước như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03 và TC-SALES-012-07; không suy diễn rằng các ID này là quy định của ISO/IEC/IEEE 29148 hay ISTQB.

5.3 Nguồn và ranh giới học thuật cho vị trí mini-book

Nội dung kiến trúc	Nguồn tham chiếu	Phân loại nguồn	Cách dùng được phép trong curriculum
Thuật ngữ và phạm vi học testing nền tảng	SRC-STD-ISTQB-001 — ISTQB CTFL Syllabus v4.0.1	Industry good practice	Dùng để định hướng thuật ngữ và phạm vi curriculum; không trích dẫn nguyên văn, số mục hoặc diễn giải chi tiết chưa được đối chiếu trực tiếp.
Liên hệ giữa phân tích nghiệp vụ, requirement và delivery	SRC-STD-BABOK-001 — BABOK Guide Version 3	Industry professional reference	Dùng cho định hướng năng lực BA; không gán chi tiết task, technique hoặc competency cho BABOK nếu chưa kiểm tra toàn văn được cấp phép.
Cấu trúc ID và phân chia Parts 18–20	Nova Foods corpus convention	Project convention / Author recommendation	Là quy ước giáo dục nội bộ corpus, không phải yêu cầu chuẩn quốc tế, quy định pháp luật hoặc quy trình production.

Cụm Parts 18–20 vì vậy là điểm chuyển có chủ đích từ “viết nội dung đúng ý” sang “tạo nội dung có thể được kiểm tra và thảo luận bằng chứng”. Với trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vị trí này là thiết kế curriculum đang được review, không phải baseline đã được phê duyệt.

Chuỗi truy vết bắt buộc từ nhu cầu đến chấp nhận

Cụm testing cho BA phải dạy testing như một chuỗi bằng chứng liên tục, không phải hoạt động viết test case tách rời. Mỗi bước trả lời một câu hỏi: tổ chức cần gì, hệ thống phải làm gì, quy tắc nào giới hạn hành vi, điều kiện nào chứng minh được kết quả, và kết quả thực thi có đủ để chuyển giao hay không. Chuỗi bắt buộc cho mọi phạm vi có kiểm thử trong Nova Foods là:

NEED -> REQ -> BR -> AC -> Test Condition -> Test Scenario -> Test Case -> Test Data -> Execution -> DEF -> Retest -> Regression -> UAT -> Acceptance

Mắt xích	Mục đích và đầu ra tối thiểu	Quy tắc truy vết bắt buộc
NEED	Nêu vấn đề hoặc kết quả nghiệp vụ cần đạt, ví dụ NEED-SALES-001.	Không tạo test case trực tiếp từ NEED vì NEED chưa đủ chi tiết để kiểm tra.
REQ	Chuyển NEED thành yêu cầu có thể phân tích, ví dụ REQ-FUNC-SALES-012.	Mỗi REQ phải liên kết ít nhất một NEED hoặc một Change Request hợp lệ.
BR	Ghi quy tắc nghiệp vụ quyết định điều gì được phép, bị chặn hoặc được tính toán; ví dụ BR-SALES-004.	BR không bị thay thế bởi mô tả màn hình, API hoặc test case; mọi test liên quan phải chỉ rõ BR áp dụng.
AC	Mô tả kết quả quan sát và kiểm tra được để chứng minh REQ đáp ứng kỳ vọng, ví dụ AC-SALES-012-03.	AC phải liên kết về REQ; nếu AC phụ thuộc BR thì phải nêu BR tương ứng.
Test Condition	Xác định một khía cạnh cần kiểm tra, như quyền thao tác, dữ liệu thiếu, kết quả tính toán hoặc trạng thái xử lý.	Một AC có thể tạo nhiều Test Condition; không mặc định một AC chỉ có một test.
Test Scenario	Nhóm hóa luồng kiểm thử theo ngữ cảnh nghiệp vụ đầu-cuối, tác nhân và tiền điều kiện.	Scenario phải cho biết Test Condition nào được bao phủ và không được thay thế Test Case thực thi.
Test Case	Hướng dẫn thực thi có tiền điều kiện, bước làm, dữ liệu tham chiếu và kết quả mong đợi. Ví dụ định danh đã có: TC-SALES-012-07.	Mỗi Test Case phải truy được ít nhất đến AC; với logic nghiệp vụ phải truy được thêm BR.
Test Data	Bộ dữ liệu tổng hợp, có kiểm soát, phục vụ đúng điều kiện kiểm thử.	Chỉ dùng dữ liệu mô phỏng của Nova Foods; không đưa dữ liệu cá nhân, khách hàng hoặc giao dịch production vào corpus.
Execution	Ghi kết quả thực tế, người thực thi, môi trường, thời điểm, bằng chứng và trạng thái Pass, Fail, Blocked hoặc Not Run.	Pass chỉ xác nhận kết quả quan sát khớp expected result của lần chạy; không tự xác nhận toàn bộ REQ đã được chấp nhận.
DEF	Ghi nhận sai lệch giữa kết quả thực tế và expected result trong một defect record có định danh được kiểm soát.	DEF phải liên kết Test Case, bản build hoặc môi trường bị ảnh hưởng và bằng chứng tái lập; không suy diễn nguyên nhân kỹ thuật khi chưa được đội kỹ thuật xác nhận.
Retest	Chạy lại Test Case từng thất bại sau khi có bản sửa được cung cấp.	Retest chỉ kết luận lỗi ghi nhận có còn tái lập trên phạm vi đã sửa hay không.
Regression	Kiểm tra các hành vi liên quan có nguy cơ bị ảnh hưởng bởi thay đổi.	Regression phải dựa trên impact analysis từ REQ, BR, AC, luồng nghiệp vụ và tích hợp liên quan; không đồng nhất với Retest.
UAT	Người dùng nghiệp vụ được chỉ định xác nhận quy trình đáp ứng nhu cầu trong bối cảnh sử dụng đã thống nhất.	UAT dùng kịch bản và dữ liệu mô phỏng được kiểm soát; mọi vấn đề mới phải quay về DEF hoặc thay đổi yêu cầu theo governance.
Acceptance	Ghi nhận quyết định chấp nhận phạm vi theo tiêu chí, bằng chứng và thẩm quyền đã xác định của dự án.	Acceptance không được suy ra từ việc toàn bộ Test Case Pass; không được ghi là đã có chấp nhận khi artifact vẫn IN_REVIEW.

Ví dụ truy vết tối thiểu cho Nova Foods: NEED-SALES-001 được cụ thể hóa thành REQ-FUNC-SALES-012; hành vi bị giới hạn bởi BR-SALES-004; kết quả mong đợi được kiểm tra qua AC-SALES-012-03; từ đó tạo Test Condition về trường hợp thỏa và không thỏa quy tắc, Test Scenario cho luồng xử lý bán hàng liên quan, và TC-SALES-012-07 với Test Data tổng hợp. Nếu Execution cho kết quả khác AC, phải mở DEF; sau bản sửa, thực hiện Retest cho TC-SALES-012-07 và Regression cho các luồng có cùng REQ, BR hoặc tích hợp bị tác động. Chỉ khi bằng chứng UAT và điều kiện Acceptance theo governance dự án đầy đủ thì phạm vi mới có thể được xem xét chấp nhận; đây không phải tuyên bố rằng Nova Foods mô phỏng đã được phê duyệt.

Phạm vi kỹ thuật black-box bắt buộc trong kiến trúc curriculum

Kiến trúc curriculum phải dạy black-box testing từ góc nhìn BA: kiểm tra hành vi quan sát được so với rule, điều kiện và dữ liệu đầu vào/đầu ra đã được xác định; không suy đoán cấu trúc mã nguồn hay thuật toán nội bộ. SRC-STD-ISTQB-001 là nguồn sơ cấp cho thuật ngữ và định hướng kỹ thuật kiểm thử; SRC-STD-OAS-001 là nguồn chuẩn cho cách mô tả HTTP API. Việc áp dụng dưới đây là Author recommendation cho corpus Nova Foods Trading & Manufacturing, không phải diễn giải điều khoản chi tiết của các nguồn.

Kỹ thuật	Mục tiêu học tập bắt buộc	Dạng rule hoặc rủi ro phù hợp tại Nova Foods	Bằng chứng BA phải tạo	Ví dụ mô phỏng giáo dục
Equivalence Partitioning (EP)	Chia miền dữ liệu thành các nhóm được hệ thống xử lý tương đương; chọn ít nhất một giá trị đại diện cho mỗi nhóm hợp lệ và không hợp lệ.	Mã kho, loại đơn hàng, trạng thái chứng từ, số lượng giao hàng.	Bảng partition nêu trường dữ liệu, miền hợp lệ, từng partition không hợp lệ, giá trị đại diện và kết quả kỳ vọng.	Trường warehouseCode: partition hợp lệ là mã kho đang hoạt động; không hợp lệ gồm mã không tồn tại, mã đã ngừng hoạt động và giá trị rỗng.
Boundary Value Analysis (BVA)	Kiểm tra điểm biên vì lỗi thường xuất hiện tại giới hạn thấp, cao và giá trị sát biên.	Số lượng, trọng lượng, tỷ lệ chiết khấu, độ dài mã lô, ngày giao hàng được phép.	Ma trận giá trị min-1, min, min+1, max-1, max, max+1, kèm đơn vị đo và expected result.	Nếu số lượng xuất kho cho phép từ 1 đến 9.999 đơn vị, tập dữ liệu tối thiểu phải có 0, 1, 2, 9.998, 9.999 và 10.000.
Decision Tables	Biến tổ hợp điều kiện nghiệp vụ thành các cột quyết định đầy đủ, phát hiện tổ hợp bị thiếu hoặc mâu thuẫn.	Phê duyệt giảm giá, chặn xuất kho, điều kiện áp dụng chương trình khuyến mại.	Decision table có điều kiện, action, rule column, giá trị “Có/Không/Không áp dụng”, rule ID và expected result.	Quyết định cho phép áp dụng giảm giá phụ thuộc vào trạng thái khách hàng, hiệu lực chương trình và quyền người dùng; mỗi tổ hợp dẫn tới một action rõ ràng.
State Transition Testing	Kiểm tra trạng thái, sự kiện kích hoạt chuyển trạng thái, chuyển trạng thái không hợp lệ và hành vi khi lặp sự kiện.	Vòng đời đơn bán hàng, phiếu xuất kho, yêu cầu trả hàng, trạng thái phê duyệt.	State model, transition matrix gồm trạng thái hiện tại, event, trạng thái kế tiếp, điều kiện chặn và thông báo kỳ vọng.	Đơn hàng ở trạng thái Cancelled không được chuyển lại Confirmed bằng thao tác xác nhận thông thường; hệ thống phải từ chối theo rule đã công bố.
Use Case Testing	Kiểm tra end-to-end theo mục tiêu actor, luồng chính, luồng thay thế và ngoại lệ nghiệp vụ.	Nhân viên bán hàng tạo đơn, thủ kho xác nhận xuất, kế toán theo dõi chứng từ trong phạm vi mô phỏng.	Use case test pack liên kết actor, precondition, main flow, alternate flow, exception flow, dữ liệu và outcome.	Actor “Nhân viên bán hàng” tạo đơn có hàng tồn khả dụng; luồng thay thế xảy ra khi một dòng hàng không đủ tồn và phải cho kết quả được quy định rõ.
API boundary/payload testing	Kiểm tra contract API qua endpoint, method, required field, kiểu dữ liệu, giới hạn dữ liệu, cấu trúc payload, HTTP response và error payload.	Tạo đơn hàng, tra cứu tồn kho, cập nhật trạng thái giao hàng qua API mô phỏng.	API test matrix liên kết endpoint, request payload, boundary/partition, expected HTTP status, response body và error code nếu được đặc tả.	Với API tạo đơn, payload thiếu customerId, items rỗng, quantity bằng 0, quantity vượt giới hạn và kiểu dữ liệu sai phải là các ca riêng biệt; expected result phải lấy từ API contract đã kiểm soát, không tự suy diễn.

Quy tắc chọn kỹ thuật: EP và BVA là tối thiểu cho mọi trường có miền giá trị hoặc giới hạn; decision table là bắt buộc khi kết quả phụ thuộc từ hai điều kiện nghiệp vụ trở lên; state transition testing áp dụng khi artifact có lifecycle; use case testing áp dụng cho hành trình actor xuyên nhiều bước; API boundary/payload testing áp dụng cho interface có contract API. Một rule có thể cần nhiều kỹ thuật: ví dụ giới hạn số lượng dùng EP và BVA, còn quyền xuất kho theo trạng thái dùng decision table kết hợp state transition testing.

Các ví dụ Nova Foods chỉ là dữ liệu mô phỏng giáo dục bằng VND và không xác nhận quy tắc vận hành, pháp lý, kế toán, an toàn thực phẩm hoặc production của bất kỳ doanh nghiệp thực tế nào.

5.1 Phụ thuộc liên phase trước khi phát triển cụm nội dung testing

Curriculum chỉ chuyển sang viết các chapter handbook khi chuỗi artifact từ Phase 1 đến Phase 5 duy trì được cùng một phạm vi, thuật ngữ, nguồn và truy vết. Với Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, mỗi phase tạo đầu vào kiểm soát cho phase kế tiếp; không phase nào tự thay thế xác minh chuyên môn, pháp lý, kế toán hoặc quyết định production.

Phase	Artifact/nhóm artifact phụ thuộc	Đầu ra phải bàn giao cho phase sau	Quy tắc handoff
Phase 1 — Source mapping	/00-research/00_SOURCE_MAP.md	Danh mục nguồn, phân loại thẩm quyền, giới hạn claim, trạng thái Verified, Verification required hoặc Limited-use caution	Chỉ dùng nguồn trong phạm vi sử dụng an toàn đã ghi nhận. Không chuyển diễn giải pháp lý, clause, page hoặc quotation chưa xác minh thành nội dung dạy học có tính khẳng định.
Phase 2 — Curriculum baseline artifacts	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Kiến trúc 26 chapter, thứ tự học, capability gate, ranh giới sư phạm, tiến trình Nova Foods và phụ thuộc giữa các phần	Mỗi chapter được đặt trong luồng học có lý do; không tạo nội dung handbook làm thay đổi âm thầm kiến trúc curriculum đang IN_REVIEW.
Phase 3 — Templates	Artifact trong /03-templates/	Biểu mẫu có trường dữ liệu, hướng dẫn điền, quy ước ID, trạng thái và liên kết traceability	Template phải phản ánh terminology và ID đã được curriculum quy định. Nếu template đòi hỏi rule pháp lý hoặc nghiệp vụ chưa xác minh, trường liên quan phải ghi Verification required hoặc Project assumption.
Phase 4 — Chapters	Artifact trong /02-handbook/	Nội dung học, ví dụ Nova Foods tổng hợp, bài thực hành và hướng dẫn sử dụng template	Chapter chỉ diễn giải bằng chứng, phạm vi và template đã có. Không được tự tạo baseline requirement, xác nhận tuân thủ hoặc mô tả Nova Foods như doanh nghiệp thật.
Phase 5 — Cheatsheets, glossary, QA	Artifact trong /04-cheatsheets/, /05-glossary/, /06-qa/	Tài liệu tra cứu ngắn, định nghĩa chuẩn hóa và kiểm tra nhất quán liên file	QA đối chiếu filename, ID, thuật ngữ, nguồn, trạng thái xác minh và traceability; QA phát hiện sai lệch nhưng không tự phê duyệt hay baseline artifact.

Quy tắc phụ thuộc bắt buộc

1. Phase 1 là nguồn kiểm soát cho mọi claim tham chiếu chuẩn, đặc tả, luật Việt Nam và industry good practice. Ví dụ, ISTQB CTFL chỉ được dùng theo ranh giới đã ghi tại SRC-STD-ISTQB-001; OpenAPI Specification 3.1.1 chỉ được dùng theo ranh giới tại SRC-STD-OAS-001.
2. Phase 2 chuyển source boundary thành cấu trúc học. Đây là nơi quyết định chapter nào dạy khái niệm, chapter nào yêu cầu thực hành, và artifact nào phải tồn tại trước khi người học dùng template.
3. Phase 3 biến cấu trúc học thành công cụ thao tác. Một chapter không nên yêu cầu người học tạo artifact có cấu trúc trường dữ liệu khi template kiểm soát chưa tồn tại hoặc chưa được liên kết với glossary và QA.
4. Phase 4 chỉ được viết sau khi nhận đủ đầu vào từ ba phase đầu. Khi phát hiện thiếu nguồn, thiếu định nghĩa, xung đột ID hoặc dependency chưa giải quyết, tác giả phải đưa vấn đề về artifact phase phù hợp thay vì tự sửa quy ước trong handbook.
5. Phase 5 là vòng kiểm tra cuối để phát hiện chênh lệch giữa curriculum, template và handbook. Cheatsheet không được rút gọn đến mức làm đổi nghĩa; glossary không được tạo định nghĩa cạnh tranh; QA không được biến giả định thành fact.

Điểm kiểm soát	Điều kiện tối thiểu	Hành động nếu chưa đạt
Handoff Phase 1 → Phase 2	/00-research/00_SOURCE_MAP.md còn IN_REVIEW nhưng có source boundary, phân loại và nhãn xác minh đủ dùng cho lập kế hoạch	Giữ nội dung curriculum ở mức kiến trúc; ghi nhận nội dung phụ thuộc là Verification required, không suy diễn claim chi tiết.
Handoff Phase 2 → Phase 3	Kiến trúc 26 chapter xác định rõ artifact học tập cần tạo và quan hệ giữa chúng	Không tạo template độc lập hoặc đặt ID không khớp quy ước curriculum.
Handoff Phase 3 → Phase 4	Template có cấu trúc trường, hướng dẫn sử dụng và liên kết thuật ngữ cần thiết	Không viết bài thực hành yêu cầu người học điền biểu mẫu chưa được kiểm soát.
Handoff Phase 4 → Phase 5	Chapter dùng đúng filename, canonical ID, source classification và ranh giới mô phỏng Nova Foods	Ghi nhận sai lệch để sửa tại nguồn sở hữu; không che giấu bằng cách sửa thuật ngữ cục bộ trong cheatsheet hoặc glossary.

Trạng thái chung của corpus tại thời điểm 2026-08-07 là IN_REVIEW, phiên bản v0.9.0. Handoff trong kế hoạch này thể hiện đủ điều kiện tiếp tục soạn thảo có kiểm soát, không đồng nghĩa với baseline, phê duyệt người dùng, xác nhận pháp lý, xác nhận kế toán hoặc quyền triển khai production.

Điều kiện sẵn sàng để học cụm testing và soạn handbook tiếp theo

Cụm testing chỉ được mở khi người học và corpus đã có đủ đầu vào để kiểm thử một yêu cầu đã được kiểm soát, không biến testing thành hoạt động đoán chức năng. Trong Nova Foods Trading & Manufacturing, mọi ví dụ vẫn là dữ liệu mô phỏng giáo dục, dùng vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND; không được suy diễn đây là cấu hình hoặc dữ liệu của doanh nghiệp thật.

Mã gate	Điều kiện bắt buộc	Bằng chứng artifact-ready	Quy tắc không đạt
TEST-READY-001	Prerequisite knowledge	Người học phân biệt được business need, requirement, business rule, acceptance criterion, defect và mức độ kiểm thử; đọc được process model hoặc use case ở mức đủ xác định actor, trigger, luồng chính và ngoại lệ.	Không cho viết test artifact nếu chưa xác định được đối tượng cần kiểm thử và kết quả quan sát được.
TEST-READY-002	Requirement có thể kiểm thử	Requirement có ID ổn định, mô tả phạm vi, điều kiện đầu vào, kết quả mong đợi và các rule liên quan; nội dung pháp lý, kế toán, privacy hoặc an toàn thực phẩm chưa xác minh phải mang nhãn Verification required hoặc Project assumption.	Không chuyển giả định chưa được kiểm chứng thành expected result bắt buộc.
TEST-READY-003	Traceability baseline	Có liên kết một chiều và truy ngược giữa need, requirement, business rule, acceptance criterion và artifact kiểm thử tương ứng; ID không bị tái sử dụng cho đối tượng khác.	Dừng tạo test case khi không truy được test về requirement hoặc không xác định được requirement bị tác động khi test thất bại.
TEST-READY-004	Controlled template availability	Template đang dùng có owner, phiên bản, trường bắt buộc, quy tắc đặt ID và trạng thái kiểm soát; template phải phân biệt rõ test condition, test scenario, test case, test data, execution record và defect record.	Không dùng bảng tự phát trong chapter như artifact chuẩn; ghi nhận nhu cầu template vào phạm vi kiểm soát trước khi soạn nội dung phụ thuộc.
TEST-READY-005	Source boundary được giữ nguyên	Thuật ngữ testing chỉ được dạy trong ranh giới an toàn của SRC-STD-ISTQB-001 — ISTQB CTFL Syllabus v4.0.1; claim chi tiết chưa đối chiếu trực tiếp phải ghi Verification required.	Không gán diễn giải chi tiết, clause, trang hoặc câu trích dẫn chưa xác minh cho ISTQB hay nguồn khác.
TEST-READY-006	Governance corpus nhất quán	Tham chiếu nguồn xuất phát từ /00-research/00_SOURCE_MAP.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không diễn giải trạng thái này là baseline hoặc phê duyệt.	Giữ nội dung ở trạng thái soạn thảo có kiểm soát và nêu rõ dependency chưa đáp ứng.

Tiêu chí quyết định handoff: chỉ khi toàn bộ TEST-READY-001 đến TEST-READY-006 đạt thì handbook chapter sau được phép dùng test artifact như đầu ra học tập. “Đạt” xác nhận mức sẵn sàng học tập và truy vết của corpus, không xác nhận acceptance nghiệp vụ, tuân thủ pháp lý, chất lượng production hoặc thẩm quyền phê duyệt của bất kỳ vai trò nào.

6. Cross-file checks, self-review, open issues và escalation needs

6.1 Ma trận đối chiếu chéo trước khi soạn curriculum

Đối chiếu chéo bảo đảm kiến trúc curriculum là một cấu trúc có truy vết, không phải danh sách chapter độc lập. Mọi đối chiếu dùng corpus Nova Foods Trading & Manufacturing là mô phỏng giáo dục, giữ Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, ngữ cảnh vi-VN, Asia/Ho_Chi_Minh và VND. Không được diễn giải kết quả đối chiếu là baseline, phê duyệt, xác nhận tuân thủ hoặc quyết định production.

Artifact đối chiếu	Đối tượng phải khớp với curriculum architecture	Kiểm tra cụ thể	Kết quả hợp lệ	Xử lý khi lệch
CHAPTER_MANIFEST.md	26 chapter, thứ tự học, mục tiêu, prerequisite, output và phạm vi chapter	Mỗi chapter trong manifest xuất hiện đúng một lần trong kiến trúc; thứ tự dependency không mâu thuẫn; chapter không nhận nội dung nằm ngoài boundary đã công bố	Chapter title, mã chapter, dependency và output học tập nhất quán	Ghi nhận mismatch theo ID chapter; không tự đổi thứ tự hoặc gộp/tách chapter chỉ trong architecture
TEMPLATE_MANIFEST.md	Template được giới thiệu, thời điểm sử dụng và artifact output	Mỗi template được nêu trong chapter phải tồn tại trong manifest; template ID, tên, owner và mục đích không bị đổi nghĩa	Không có template “tự phát”; chapter chỉ tham chiếu template có kiểm soát	Giữ template ở mức planned dependency, không tạo tên file hoặc ID mới
CANONICAL_BUSINESS_RULES.md	Business rule Nova Foods, rule ID, domain và authority classification	Rule như BR-SALES-004 chỉ được dùng khi ID, diễn giải và trạng thái authority khớp canonical source; rule không được suy ra từ API, test case hoặc sơ đồ	Rule được gắn đúng chapter, đúng domain và đúng nguồn thẩm quyền	Ưu tiên canonical rule; loại bỏ diễn giải mâu thuẫn trong architecture
CANONICAL_DATA_DICTIONARY.md	Entity, field, định nghĩa dữ liệu, classification và data ownership	Tên business term, entity và field dùng trong lộ trình học phải khớp canonical dictionary; không biến field kỹ thuật thành business term nếu chưa được định nghĩa	Không có synonym làm phát sinh dữ liệu khác nghĩa; classification dữ liệu nhất quán	Dùng canonical term; đánh dấu tham chiếu chưa có định nghĩa thay vì tự định nghĩa
TRACEABILITY_ID_REGISTRY.md	Quy ước và tính duy nhất của ID	ID như NEED-SALES-001, REQ-FUNC-SALES-012, AC-SALES-012-03, TC-SALES-012-07 phải đúng pattern, đúng domain và không trùng	Mỗi ID có một ý nghĩa ổn định, liên kết được qua need → requirement → acceptance criteria → test	Không tái sử dụng ID; không tạo canonical ID mới trong architecture
COMPETENCY_COVERAGE_MATRIX.md	Capability, learning objective, chapter coverage và assessment evidence	Mỗi capability gate có chapter đóng góp và bằng chứng học tập; không có chapter trọng yếu không đóng góp năng lực nào	Coverage đủ chiều rộng BA, requirements, process, data, API, quality và testing theo phạm vi đã định	Điều chỉnh mapping coverage, không thêm năng lực hoặc assessment mới ngoài matrix
Glossary trong /05-glossary/	Thuật ngữ BA, nghiệp vụ Nova Foods, kỹ thuật và source terminology	Một khái niệm chỉ có một preferred term; acronym được mở rộng nhất quán; thuật ngữ Việt-Anh không bị dùng đổi nghĩa giữa chapter	“Requirement”, “business rule”, “acceptance criterion”, “test case”, “BPMN”, “UML” và thuật ngữ Nova Foods dùng đồng nhất	Ưu tiên glossary; không coi biến thể câu chữ là thuật ngữ mới
Cheatsheets trong /04-cheatsheets/	Hướng dẫn thao tác rút gọn và giới hạn sử dụng	Cheatsheet chỉ tóm tắt nội dung đã có căn cứ trong handbook/canonical artifact; không trở thành nguồn authority mới	Không có rule, clause, quy định pháp lý hoặc notation claim chỉ tồn tại ở cheatsheet	Chuyển claim thiếu nguồn về Verification required hoặc bỏ khỏi cheatsheet
QA report trong /06-qa/	Lỗi nhất quán, link hỏng, ID trùng, coverage gap và source-boundary violation	Các phát hiện QA liên quan chapter map, ID, thuật ngữ, authority classification và link artifact phải được phản ánh nhất quán	Không có finding mở làm thay đổi nghĩa của architecture mà không được ghi nhận	Giữ finding là evidence kiểm soát; không đóng finding bằng cách sửa im lặng artifact khác

6.2 Quy tắc phân loại nguồn khi đối chiếu

Loại nội dung	Phân loại phải được giữ	Quy tắc kiểm tra trong kiến trúc
BABOK Guide, ISO/IEC/IEEE 29148, BPMN, UML, OpenAPI, WCAG	Normative standard hoặc normative specification theo phân loại đã ghi tại /00-research/00_SOURCE_MAP.md	Không gán clause, page, quotation hoặc diễn giải chi tiết nếu chưa có bằng chứng nguồn được truy cập hợp lệ
Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm	Official Vietnamese law	Nội dung áp dụng cho Nova Foods chỉ là bối cảnh học tập; chi tiết nghĩa vụ hệ thống chưa xác minh phải là Verification required
ISTQB CTFL, OWASP ASVS, OWASP API Security Top 10	Theo phân loại trong source map; không nâng industry good practice thành luật	Không dùng để khẳng định nghĩa vụ pháp lý hoặc certification của Nova Foods
ID convention, chapter sequence, màu sơ đồ, cấu trúc artifact Nova Foods	Project convention hoặc Author recommendation	Không quy gán các quy ước corpus cho tiêu chuẩn, luật hoặc tổ chức phát hành

6.3 Quy tắc quyết định khi hai artifact mâu thuẫn

1. Artifact canonical theo đúng loại thông tin được ưu tiên: business rule ưu tiên CANONICAL_BUSINESS_RULES.md; định nghĩa dữ liệu ưu tiên CANONICAL_DATA_DICTIONARY.md; ID ưu tiên TRACEABILITY_ID_REGISTRY.md; coverage ưu tiên COMPETENCY_COVERAGE_MATRIX.md.
2. CHAPTER_MANIFEST.md quyết định danh mục và cấu trúc chapter, nhưng không có thẩm quyền thay thế business rule, data definition hoặc source classification canonical.
3. TEMPLATE_MANIFEST.md quyết định template có kiểm soát, nhưng không biến template field thành requirement hoặc business rule.
4. QA report là bằng chứng phát hiện; QA report không tự tạo authority mới cho nội dung nghiệp vụ, pháp lý, kế toán, privacy, food safety, security hoặc notation.
5. Khi source map ghi Verification required hoặc Limited-use caution, architecture chỉ được mô tả dependency học tập và boundary an toàn; không được nâng nội dung đó thành quy tắc bắt buộc cho Nova Foods.

6.1 Self-review checklist: completeness, uniqueness, authority và boundary consistency

Checklist này được áp dụng cho /01-curriculum/01_CURRICULUM_ARCHITECTURE.md ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Mục tiêu là kiểm tra chất lượng của kiến trúc curriculum trước khi viết nội dung chapter, không xác nhận baseline, phê duyệt nghiệp vụ hoặc tuân thủ production cho Nova Foods Trading & Manufacturing.

ID kiểm tra	Nội dung tự kiểm	Tiêu chí đạt cụ thể	Bằng chứng cần hiện diện trong architecture	Không đạt khi
ARCH-SELF-001	Tính đầy đủ cấu trúc	Có đủ 26 chapter theo kiến trúc đã định; mỗi chapter có mục tiêu học, đầu ra học tập, năng lực đích, Nova Foods context và artifact hoặc exercise dự kiến.	Mỗi chapter xuất hiện đúng một lần trong phần kiến trúc chapter.	Có chapter thiếu mục tiêu, thiếu đầu ra, hoặc không xác định vai trò trong tiến trình học.
ARCH-SELF-002	Không trùng lặp chapter	Một chủ đề có một chapter chủ quản; chapter khác chỉ được phép tham chiếu dependency, không dạy lại cùng mục tiêu và cùng artifact.	Ranh giới “teaches / applies / references” cho các chủ đề giao thoa như requirements, process, data, API và testing.	Hai chapter cùng tuyên bố sở hữu một kỹ năng, template hoặc assessment mà không phân định vai trò.
ARCH-SELF-003	Tiến trình năng lực	Thứ tự chapter đi từ problem framing, elicitation, analysis, specification, validation đến delivery handoff; kỹ năng sau chỉ dùng kiến thức đã được giới thiệu trước đó.	Dependency chain thể hiện prerequisite và capability gate.	Yêu cầu người học viết API contract, test case hoặc traceability trước khi có nền tảng requirement liên quan.
ARCH-SELF-004	Coverage theo năng lực	Mỗi competency cần đạt được gắn với ít nhất một chapter dạy kiến thức, một hoạt động thực hành và một điểm đánh giá.	Liên kết nhất quán với COMPETENCY_COVERAGE_MATRIX.md.	Năng lực chỉ được nêu như khẩu hiệu, không có chapter hoặc assessment kiểm chứng.
ARCH-SELF-005	Phân loại authority	Mọi claim được gắn đúng một loại: Normative standard, Official Vietnamese law, Industry good practice, Project convention hoặc Author recommendation.	Nhãn authority cạnh các quy tắc có nguy cơ bị hiểu là bắt buộc.	Gọi OWASP là luật; gọi quy ước ID Nova Foods là yêu cầu ISO; hoặc trình bày khuyến nghị tác giả như nghĩa vụ pháp lý.
ARCH-SELF-006	Boundary của claim	Nội dung chỉ diễn đạt trong phạm vi nguồn đã xác minh; chi tiết chưa đủ căn cứ phải mang nhãn Verification required hoặc Project assumption phù hợp.	Không có số điều khoản, số trang, trích dẫn, nghĩa vụ compliance hoặc diễn giải chi tiết không có nguồn kiểm chứng.	Tạo mandatory requirement từ nguồn Limited-use caution hoặc từ giả định case study.
ARCH-SELF-007	Ranh giới Nova Foods	Nova Foods là mô phỏng giáo dục; ID, quy trình, dữ liệu VND và tình huống vận hành chỉ là corpus convention, không là dữ kiện của doanh nghiệp thật.	Tuyên bố mô phỏng và giới hạn sử dụng nhất quán trong toàn architecture.	Khẳng định Nova Foods đang vận hành, đã phê duyệt rule, đã tuân thủ luật hoặc có dữ liệu production.
ARCH-SELF-008	Ranh giới notation và kỹ thuật	BPMN chỉ được gọi là BPMN khi dùng đúng notation BPMN; UML, OpenAPI, WCAG và ISTQB chỉ được quy gán trong phạm vi nguồn tương ứng.	Phân biệt rõ sơ đồ học tập, project convention và notation chuẩn.	Gọi PlantUML activity diagram là BPMN hoặc suy diễn semantics chuẩn từ minh họa không chuẩn.
ARCH-SELF-009	Ranh giới artifact	Architecture định hướng artifact cần học nhưng không tự tạo business rule, requirement, acceptance criterion, API contract hoặc test result cho delivery thật.	Mỗi đầu ra được mô tả là artifact học tập hoặc template định hướng.	Nội dung biến curriculum architecture thành đặc tả triển khai Nova Foods.
ARCH-SELF-010	Nhất quán định danh và ngôn ngữ	Giữ nguyên tên file, canonical ID, thuật ngữ Nova Foods, Việt Nam, vi-VN, Asia/Ho_Chi_Minh và VND khi đã được corpus xác định.	Không có biến thể tự phát của filename, ID prefix hoặc tên domain.	Đổi REQ-FUNC-SALES-012, AC-SALES-012-03, TC-SALES-012-07 sang cấu trúc mới không có nguồn quản trị.

Quy tắc xử lý phát hiện: nếu một mục không đạt, chỉ sửa phạm vi architecture hoặc gắn nhãn phân loại phù hợp; không tự tạo authority, không suy diễn nội dung pháp lý, kế toán, privacy, an toàn thực phẩm, security hoặc testing ngoài nguồn và boundary đã có.

Open issues và hạng mục cần xác minh trước khi cố định kiến trúc curriculum

Các mục dưới đây chưa được suy diễn thành yêu cầu tuân thủ, business rule bắt buộc, acceptance criterion hoặc quyết định production. Mỗi mục giữ trạng thái Verification required cho đến khi có bằng chứng từ nguồn chính thức hiện hành và xác nhận của vai trò có thẩm quyền. Nova Foods Trading & Manufacturing là case study mô phỏng; các tình huống chỉ phục vụ học tập.

Mã theo dõi	Lĩnh vực	Hạng mục cần xác minh	Ảnh hưởng đến curriculum architecture	Phân loại nguồn và ranh giới sử dụng	Bằng chứng cần có để đóng mục
VR-CURR-LEGAL-001	Legal	Phạm vi áp dụng, nghĩa vụ và ngoại lệ liên quan đến Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP đối với dữ liệu khách hàng, nhân viên, nhà cung cấp trong case Nova Foods.	Quyết định mức sâu của chapter elicitation, data requirements, consent, retention và quyền truy cập; không được dạy một luồng consent cụ thể như nghĩa vụ pháp lý đã xác nhận.	Official Vietnamese law; chỉ dùng metadata và hiệu lực đã xác minh. Diễn giải yêu cầu hệ thống chi tiết là Verification required.	Bản đối chiếu văn bản hiện hành, xác định applicability cho tình huống mô phỏng và kết luận diễn giải của Legal Owner.
VR-CURR-ACCOUNT-001	Accounting	Cách phân định giữa đơn hàng, giao hàng, hóa đơn, ghi nhận công nợ, hoàn tiền, điều chỉnh chứng từ và dữ liệu kế toán.	Xác định ranh giới chapter Sales, Finance integration, business rules và test scenarios; tránh biến ví dụ BR-SALES-004 thành quy tắc kế toán hoặc thuế.	Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP là Official Vietnamese law; mọi diễn giải nghiệp vụ, thuế và amendment status là Verification required.	Ma trận sự kiện nghiệp vụ–chứng từ–bút toán ở mức khái niệm, được Accounting Owner kiểm tra cùng Legal Owner khi có yếu tố pháp lý.
VR-CURR-PRIVACY-002	Privacy và dữ liệu	Danh mục dữ liệu nào trong mô phỏng được xem là dữ liệu cá nhân; vai trò controller/processor, thời hạn lưu giữ, masking trong test data và điều kiện truy xuất dữ liệu.	Quyết định nội dung data dictionary, API examples, test fixtures, security acceptance criteria và quy tắc không dùng dữ liệu thật.	Official Vietnamese law cho nguyên tắc pháp lý; quy ước dùng dữ liệu tổng hợp là Project convention. Không suy ra retention period cụ thể.	Data classification mẫu, quy tắc synthetic-data và quyết định phạm vi data handling do Legal Owner và Security Owner xác minh.
VR-CURR-FOOD-001	Food safety và traceability	Mức truy xuất cần mô phỏng giữa nguyên liệu, lô sản xuất, thành phẩm, kho, đơn bán và thu hồi; điều kiện nào kích hoạt hold hoặc recall.	Quyết định độ sâu của running case từ Inventory đến Manufacturing, traceability matrix và test coverage cho lot/batch.	Luật An toàn thực phẩm 55/2010/QH12 là Official Vietnamese law; quy trình lot, hold, recall của Nova Foods là Project assumption nếu chưa có domain validation.	Sơ đồ truy xuất mẫu, định nghĩa lot/batch/expiry và các scenario recall được Domain Owner cùng Legal Owner xác minh.
VR-CURR-SEC-001	Security	Mức tối thiểu cần dạy về authentication, authorization, segregation of duties, audit logging, API authorization và xử lý lỗi an toàn.	Quyết định technical depth ladder cho role matrix, API contract, non-functional requirements và security test cases.	OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 là Industry good practice, không phải luật Việt Nam; OpenAPI 3.1.1 không tự định nghĩa authorization policy.	Security baseline dành cho corpus, mapping rõ nội dung là good practice hoặc project convention, do Security Owner và Architect xác minh.
VR-CURR-NOTATION-001	Notation	Ranh giới chính xác giữa BPMN 2.0.2, UML 2.5.1, PlantUML và sơ đồ minh họa tự do; đặc biệt là event, gateway, message flow, state và sequence semantics.	Ngăn chapter và template gọi sai tên loại sơ đồ; quyết định checklist notation và tiêu chí đánh giá mô hình.	BPMN 2.0.2 và UML 2.5.1 là Normative standard; claim về semantics chi tiết phải đối chiếu specification. PlantUML activity diagram không được gọi là BPMN.	Notation policy nêu loại sơ đồ, mục đích, ký hiệu được phép và nhãn bắt buộc cho sơ đồ không phải BPMN/UML chuẩn.
VR-CURR-TEST-001	Testing scope	Phạm vi tối thiểu giữa unit, integration, system, UAT, regression, security, accessibility, data migration và API testing trong lộ trình 26 chapter.	Quyết định dependency giữa requirement, acceptance criterion, test condition, test case, defect và phase handoff; tránh dạy UAT như hoạt động thay thế toàn bộ kiểm thử kỹ thuật.	ISTQB CTFL v4.0.1 là nguồn chính cho thuật ngữ và kỹ thuật black-box; claim chi tiết chưa đối chiếu trực tiếp syllabus là Verification required.	Test scope matrix gắn từng loại kiểm thử với objective, owner, input/output và giới hạn không thuộc trách nhiệm BA.
VR-CURR-ACCESS-001	Accessibility	Mức áp dụng WCAG 2.2 cho ví dụ UI, acceptance criteria và test evidence của portal nội bộ hoặc kênh khách hàng.	Quyết định có đưa accessibility vào non-functional requirement và testing mini-book hay chỉ giới thiệu awareness.	WCAG 2.2 là Normative recommendation; không nêu số success criterion hoặc mức conformant nếu chưa đối chiếu trực tiếp nguồn.	Accessibility boundary xác định đối tượng người dùng, loại giao diện, mức evidence học viên phải tạo và claim được phép sử dụng.

Quy tắc xử lý kiến trúc: Một mục còn Verification required không ngăn curriculum giải thích phương pháp BA từ first principles, nhưng ngăn việc trình bày chi tiết pháp lý, kế toán, an toàn thực phẩm hoặc security control như kết luận đã được xác nhận. Khi chưa có bằng chứng đóng mục, chapter liên quan chỉ được dùng nhãn Project assumption, dữ liệu tổng hợp và ví dụ có giới hạn thẩm quyền rõ ràng.

Escalation needs và ranh giới thẩm quyền quyết định

Escalation là việc chuyển một điểm chưa thể quyết định an toàn ở cấp người viết curriculum sang vai trò có thẩm quyền phù hợp, kèm câu hỏi quyết định, tác động lên Nova Foods và bằng chứng nguồn. Người viết không tự chuyển nội dung Verification required thành quy tắc bắt buộc, không diễn giải luật thay Legal Owner, không xác nhận hạch toán thay Accounting Owner và không chấp thuận thiết kế thay Architect. Mọi nội dung sau escalation vẫn giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, cho đến khi được cập nhật có truy vết trong artifact liên quan.

Chuyển lên vai trò	Escalate khi nào	Quyết định hoặc xác minh cần nhận	Ranh giới bắt buộc
Senior BA	Requirement, business rule, acceptance criterion hoặc traceability giữa chapter, template và case Nova Foods mâu thuẫn; một nội dung vượt khỏi mục tiêu học hoặc tạo trùng lặp chapter.	Chọn cách diễn đạt BA, phân rã requirement và liên kết artifact phù hợp.	Senior BA không thay thế thẩm quyền pháp lý, kế toán, security hoặc domain.
PM	Có xung đột phạm vi, thứ tự phụ thuộc, nguồn lực học liệu, mốc bàn giao hoặc tác động liên chapter làm thay đổi kế hoạch delivery.	Quyết định ưu tiên, phạm vi release, sequencing và quản trị thay đổi.	PM không được tự diễn giải nghĩa vụ pháp lý hoặc phê duyệt thiết kế kỹ thuật chuyên sâu.
Architect	Nội dung liên quan kiến trúc tích hợp, API contract, phân quyền kỹ thuật, dữ liệu xuyên hệ thống, hiệu năng, logging, resilience hoặc lựa chọn công nghệ.	Xác minh feasibility, boundary giữa hệ thống và quyết định kiến trúc cần mô phỏng trong Nova Foods.	OpenAPI Specification là nguồn kỹ thuật; API không tự tạo business rule hay quyền truy cập hợp lệ.
Business Owner	Quy tắc về mục tiêu kinh doanh, ưu tiên vận hành, ngoại lệ quy trình bán hàng, mua hàng, kho hoặc quyết định chấp nhận trade-off nghiệp vụ.	Xác nhận ý định nghiệp vụ và mức ưu tiên của outcome mô phỏng.	Không được dùng ý kiến Business Owner để suy ra tuân thủ luật, cách hạch toán hoặc biện pháp security.
Legal Owner	Nội dung có thể tạo nghĩa vụ hoặc diễn giải về Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm, lưu giữ dữ liệu, hóa đơn hoặc trách nhiệm pháp lý.	Xác minh applicability, hiệu lực, diễn giải và giới hạn của yêu cầu pháp lý.	Trước xác minh, chỉ ghi Verification required hoặc Project assumption; không gọi nội dung là nghĩa vụ tuân thủ đã xác nhận.
Accounting Owner	Quy tắc ảnh hưởng bút toán, công nợ, doanh thu, giá vốn, thuế, đối soát, hóa đơn, kỳ khóa sổ hoặc điều chỉnh tài chính.	Xác minh logic nghiệp vụ-kế toán và dữ liệu cần kiểm soát.	Ví dụ hoàn tiền của Nova Foods không được mặc định là cách hạch toán hoặc xử lý hóa đơn hợp lệ.
Security Owner	Nội dung về xác thực, phân quyền, quản lý bí mật, audit log, mã hóa, bảo vệ API, xử lý sự cố hoặc dữ liệu cá nhân.	Xác minh security requirement, threat/risk boundary và verification approach.	OWASP ASVS và OWASP API Security Top 10 là industry good practice, không phải luật Việt Nam.
Domain Owner	Quy tắc chất lượng thực phẩm, lô hàng, hạn dùng, truy xuất nguồn gốc, thu hồi, kiểm dịch, điều kiện kho hoặc ngoại lệ vận hành chuyên ngành.	Xác nhận quy trình thực tế cần mô phỏng và thuật ngữ domain đúng ngữ cảnh.	Domain confirmation không thay thế Legal Owner khi nội dung được trình bày như nghĩa vụ pháp lý.

Quy tắc ghi nhận escalation: Mỗi yêu cầu chuyển cấp phải nêu rõ artifact bị ảnh hưởng, đoạn hoặc ID đã tồn tại nếu có, source classification, trạng thái Verification required hoặc Project assumption, câu hỏi cần quyết định, tác động nếu chưa quyết định và vai trò nhận escalation. Không được tạo trích dẫn, điều khoản, lời phát biểu hay phê duyệt giả định để đóng escalation.

Tiêu chí stop/go để chuyển từ planning sang drafting

Mục tiêu của quyết định này là xác nhận kiến trúc curriculum có thể được soạn thảo nhất quán, không phải xác nhận nội dung đã đúng về pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc sẵn sàng triển khai production. Tại IN_REVIEW, v0.9.0, ngày 2026-08-07, chỉ được chuyển sang drafting khi các dependency kiến trúc chính đã được nhận diện, có vị trí sử dụng rõ ràng và không tạo mâu thuẫn về phạm vi hoặc thẩm quyền.

Điều kiện quyết định	Bằng chứng tối thiểu trong plan	Quy tắc GO	Quy tắc STOP
Cấu trúc 26 chapter khả thi	Mỗi chapter có mục tiêu học, đầu vào, đầu ra và vị trí trong trình tự năng lực	Không có chapter bị cô lập hoặc yêu cầu kiến thức chưa được dạy trước đó	Có chapter phụ thuộc vào khái niệm, artifact hoặc kỹ năng chưa có điểm giới thiệu
Nova Foods running case liên tục	Luồng case từ discovery đến delivery liên kết với các artifact dự kiến	Cùng thuật ngữ, thực thể và bối cảnh mô phỏng được dùng xuyên suốt	Một chapter đổi nghĩa thực thể, quy trình hoặc phạm vi Nova Foods mà không có lý do kiến trúc
Dependency artifact đã xác định	Liên kết dự kiến tới CHAPTER_MANIFEST.md, TEMPLATE_MANIFEST.md, CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, TRACEABILITY_ID_REGISTRY.md, COMPETENCY_COVERAGE_MATRIX.md, glossary, cheatsheets và QA report	Mỗi dependency có vai trò rõ: nguồn định danh, nội dung, kiểm soát hoặc bằng chứng	Drafting phải tự tạo lại rule, data definition, ID hoặc thuật ngữ vì dependency chưa được xác định
Boundary thẩm quyền được giữ	Nội dung được phân biệt giữa nguồn chuẩn, luật chính thức, industry good practice, project convention, author recommendation và Verification required	Không biến giả định curriculum thành nghĩa vụ pháp lý, rule kế toán hoặc quyết định production	Có claim chi tiết thuộc legal, accounting, privacy, food safety, security hoặc testing nhưng thiếu nhãn và đường xác minh
Coverage năng lực có thể kiểm tra	Chapter, exercise, template và assessment được dự kiến nối với competency coverage	Mỗi capability gate có cách quan sát hoặc đánh giá tương ứng	Có năng lực cam kết đào tạo nhưng không có chapter hoặc assessment hỗ trợ
Handoff sang testing và delivery rõ	Chuỗi từ requirement, acceptance criteria, traceability đến test basis được xác định ở cấp kiến trúc	Testing mini-book nhận đủ đầu vào từ các chapter trước, không tự suy diễn business rule	Testing được đặt trước khi learner có requirement, rule, data hoặc acceptance criteria làm test basis

Quy tắc quyết định: đặt trạng thái GO FOR IN_REVIEW DRAFTING chỉ khi toàn bộ điều kiện trên đạt ở mức kiến trúc và mọi nội dung chưa được xác minh được giữ nguyên nhãn Verification required hoặc Project assumption phù hợp. Khi đó, drafting được phép tạo nội dung chi tiết theo các dependency đã nhận diện, nhưng không được tự nhận BASELINED, được phê duyệt, tuân thủ pháp luật hoặc sẵn sàng production.

Đặt trạng thái STOP — PLAN REWORK REQUIRED nếu chỉ một điều kiện tạo ra mâu thuẫn chuỗi học, đứt traceability, trùng lặp nguồn chân lý, hoặc vượt boundary thẩm quyền. Trong trạng thái dừng, chỉ được sửa kiến trúc, làm rõ dependency và duy trì các nhãn xác minh; không được chuyển khoảng trống đó thành rule Nova Foods hay acceptance criterion có tính bắt buộc.