/01-curriculum/COMPETENCY_COVERAGE_MATRIX.md — Independent Junior-to-Senior BA Competency Coverage Matrix Plan

Governance, document control, and artifact header

Metadata quản trị artifact

Trường kiểm soát	Giá trị chuẩn	Diễn giải và ranh giới áp dụng
Artifact ID	COMPETENCY_COVERAGE_MATRIX	Định danh quản trị duy nhất của ma trận trong corpus Nova Foods. Căn cứ: quy ước ID viết hoa có dấu gạch dưới đang dùng tại các artifact trực tiếp như CHAPTER_MANIFEST và TRACEABILITY_ID_REGISTRY; vì vậy các liên kết sau này phải giữ nguyên chuỗi này, không dùng biến thể dịch thuật.
Đường dẫn tệp được kiểm soát	/01-curriculum/COMPETENCY_COVERAGE_MATRIX.md	Đây là vị trí canonical của artifact. Bản sao, bản xuất hoặc trích đoạn không thay thế tệp tại đường dẫn này khi đối chiếu metadata, version hoặc traceability.
Tiêu đề artifact	Independent Junior-to-Senior BA Competency Coverage Matrix Plan	Tiêu đề xác định đây là kế hoạch ma trận bao phủ năng lực (competency coverage matrix), tức công cụ đối chiếu năng lực BA với nội dung học liệu dự kiến; không phải đánh giá năng lực của một cá nhân thực tế.
Status	IN_REVIEW	Trạng thái cho biết artifact đang được xem xét có kiểm soát và vẫn có thể thay đổi theo truy vết. IN_REVIEW không đồng nghĩa APPROVED, BASELINED, sẵn sàng production, tuân thủ pháp luật hoặc đã được người dùng chấp thuận.
Version	v0.9.0	Phiên bản kế hoạch hiện hành tại ngày ghi nhận. Version nhận diện trạng thái kiểm soát của artifact, không xác nhận ma trận đã hoàn chỉnh, đã được rà soát chuyên môn đầy đủ hoặc có hiệu lực vận hành.
Owner	Curriculum Governance Owner: Principal IT Business Analyst / Technical Curriculum Author	Owner là vai trò chịu trách nhiệm quản trị artifact này. Owner duy trì tính toàn vẹn của ID, đường dẫn, metadata, version, trạng thái và liên kết quản trị với các artifact curriculum liên quan; Owner theo dõi vấn đề cần xác minh và chuyển nội dung vượt thẩm quyền đến vai trò có thẩm quyền tương ứng. Định danh cá nhân không được ghi nhận trong metadata hiện hành.
Giới hạn thẩm quyền Owner	Owner không tự thiết lập baseline, không ghi nhận approval, không xác nhận competency framework là chuẩn tuyển dụng thực tế, không quyết định cấu hình ERP Nova Foods, và không thay thế thẩm quyền của Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA Reviewer.	Căn cứ: các artifact phụ thuộc trực tiếp áp dụng cùng giới hạn thẩm quyền để ngăn việc suy diễn quyền phê chuẩn từ vai trò quản trị tài liệu.
Last updated date	2026-08-07	Ngày cập nhật được diễn giải theo múi giờ quản trị của corpus, không suy diễn thời điểm review, approval hoặc baseline.
Timezone	Asia/Ho_Chi_Minh	Múi giờ chuẩn để ghi nhận ngày giờ thay đổi, evidence và hoạt động review liên quan artifact.
Locale	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND	Nội dung được viết cho ngữ cảnh Việt Nam. VND chỉ là đơn vị tiền tệ của case study mô phỏng, không xác nhận dữ liệu tài chính hoặc giao dịch thực tế.
Case-study context	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp	Nova Foods là ngữ cảnh học tập giả lập để learner thực hành phân tích nghiệp vụ độc lập từ junior đến senior; tên tổ chức, quy trình, vai trò và dữ liệu không đại diện cho tổ chức hoặc ERP đang vận hành thực tế.
Artifact classification	Controlled planning artifact cho ma trận kế hoạch bao phủ năng lực BA độc lập từ junior đến senior trong corpus Nova Foods	Phân loại này giới hạn mục đích vào lập kế hoạch curriculum và kiểm tra độ bao phủ dự kiến. Artifact không phải hồ sơ nhân sự, tiêu chuẩn chứng nhận, requirement triển khai, quyết định vận hành hoặc hướng dẫn production.
Baseline reference	Chưa có baseline reference tại v0.9.0	Không có baseline được ghi nhận trong metadata hiện hành; do đó không được gọi bất kỳ hàng ma trận, mức năng lực, nguồn tham chiếu hoặc liên kết curriculum nào là baseline.
Approval reference	Chưa có approval reference tại v0.9.0	Không có approval được ghi nhận. Sự tồn tại của Owner, metadata, version hoặc trạng thái IN_REVIEW không tạo approval ngầm định từ bất kỳ vai trò nào.

Lịch sử thay đổi có kiểm soát

Lịch sử thay đổi (change history) là nhật ký ghi nhận điều gì đã thay đổi, khi nào thay đổi và thay đổi đó được kiểm soát ở mức nào. Nhật ký này tạo bằng chứng truy vết cho quá trình soạn thảo, nhưng không tự biến nội dung thành bản chuẩn (baseline) hoặc nội dung đã được phê duyệt (approval). Căn cứ là trạng thái hiện hành IN_REVIEW và phiên bản v0.9.0; vì vậy, dòng ghi nhận dưới đây chỉ xác nhận hoạt động lập kế hoạch cho artifact, không xác nhận độ đầy đủ của ma trận, năng lực BA thực tế, yêu cầu ERP, hay quyết định vận hành của Nova Foods.

Version	Ngày ghi nhận	Múi giờ	Status	Người ghi nhận	Loại thay đổi	Nội dung thay đổi có kiểm soát	Tác động kiểm soát	Tham chiếu baseline	Tham chiếu approval
v0.9.0	2026-08-07	Asia/Ho_Chi_Minh	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo kế hoạch	Khởi tạo lịch sử thay đổi cho /01-curriculum/COMPETENCY_COVERAGE_MATRIX.md như một kế hoạch ma trận bao phủ năng lực BA độc lập từ junior đến senior trong bối cảnh Nova Foods Trading & Manufacturing mô phỏng giáo dục; chỉ sử dụng dữ liệu tổng hợp.	Thiết lập điểm bắt đầu có truy vết cho việc soạn thảo và review tiếp theo. Không xác nhận nội dung ma trận là hoàn chỉnh, chính xác cho vận hành thực tế, sẵn sàng production, phù hợp pháp lý hoặc có hiệu lực đào tạo chính thức.	Không có baseline reference tại v0.9.0.	Không có approval reference tại v0.9.0.

Quy tắc diễn giải: một dòng lịch sử chỉ là bằng chứng rằng thay đổi đã được ghi nhận trong artifact được kiểm soát. Để gọi bất kỳ phiên bản hoặc nội dung nào là “đã baseline”, artifact phải có tham chiếu baseline minh bạch; để gọi là “đã phê duyệt”, artifact phải có tham chiếu approval minh bạch từ vai trò có thẩm quyền. Hiện chưa có hai loại tham chiếu này, nên không được suy diễn sự chấp thuận từ Owner, version, trạng thái IN_REVIEW, ngày cập nhật, sự tồn tại của bảng, hoặc tên Nova Foods.

Tuyên bố kiểm soát tài liệu: kế hoạch, không phải ma trận hoàn chỉnh

/01-curriculum/COMPETENCY_COVERAGE_MATRIX.md là controlled planning artifact (artifact kế hoạch có kiểm soát), nghĩa là tài liệu được quản lý để định hướng cách xây dựng và rà soát ma trận năng lực, thay vì là bản ma trận năng lực đã hoàn tất để sử dụng như nguồn kết luận. Lý do là phiên bản kế hoạch cần được kiểm tra dần về phạm vi năng lực, tiêu chí phân loại, liên kết học liệu và tính nhất quán với các artifact canonical trước khi có thể trình bày một mức độ bao phủ năng lực như kết quả đã xác lập.

Nội dung cần phân biệt	Diễn giải áp dụng cho tài liệu này	Hệ quả khi đọc hoặc tái sử dụng
Kế hoạch ma trận năng lực	Xác định cấu trúc dự kiến, cách tổ chức, nguyên tắc kiểm tra và điều kiện cần có để lập ma trận.	Có thể dùng để hướng dẫn công việc soạn thảo và review, nhưng không dùng làm bằng chứng rằng một năng lực đã được bao phủ.
Ma trận năng lực hoàn chỉnh	Phải có các dòng năng lực, mức độ junior-to-senior, liên kết artifact học liệu, tiêu chí đánh giá và kết quả kiểm tra đầy đủ theo cấu trúc đã được xác định.	Chỉ được gọi là ma trận hoàn chỉnh khi các nội dung trên thực sự hiện diện, truy vết được và không còn mâu thuẫn kiểm soát chưa xử lý.
Khẳng định bao phủ	Là kết luận rằng một năng lực cụ thể đã được dạy, thực hành và đánh giá bằng bằng chứng xác định.	Không được suy ra từ tiêu đề, cấu trúc dự kiến, tên chapter hoặc sự tồn tại của tệp này.
Nội dung minh họa Nova Foods	Là bối cảnh học tập mô phỏng cho Nova Foods Trading & Manufacturing, sử dụng dữ liệu tổng hợp.	Không phải cấu hình ERP, năng lực đã được xác nhận trong tổ chức thực tế, hay bằng chứng về nhu cầu nhân sự thực tế.

Quy tắc diễn giải là: một “kế hoạch” trả lời sẽ xây dựng và kiểm tra ma trận như thế nào, còn “ma trận cuối cùng” phải trả lời năng lực nào được bao phủ ở mức nào, bằng artifact nào và bằng bằng chứng nào. Vì tài liệu này chỉ thuộc vế thứ nhất tại giai đoạn lập kế hoạch, mọi phát biểu về độ đầy đủ, mức trưởng thành năng lực, khả năng độc lập thực hiện công việc hoặc kết quả đào tạo phải được xem là chưa được thiết lập bởi riêng artifact này.

Khi một nội dung trong /01-curriculum/COMPETENCY_COVERAGE_MATRIX.md chưa có liên kết rõ ràng giữa năng lực, cấp độ, học liệu, bài thực hành và cách đánh giá, người soạn phải ghi nhận đó là khoảng trống của kế hoạch hoặc nội dung cần được xây dựng tiếp; không được chuyển khoảng trống thành kết luận rằng người học đã đạt năng lực. Cách kiểm soát này bảo vệ tính trung thực của traceability (truy vết: khả năng lần từ một kết luận về nguồn và bằng chứng hỗ trợ nó) và ngăn việc nhầm lẫn giữa ý định thiết kế curriculum với kết quả đã được chứng minh.

Phạm vi năng lực BA độc lập cho Nova Foods

Phạm vi của ma trận này chỉ bao phủ năng lực cần được phát triển và chứng minh để một Business Analyst (BA, Chuyên viên Phân tích Nghiệp vụ) có thể làm việc ngày càng độc lập, từ mức junior đến senior, trong case study Nova Foods Trading & Manufacturing. Nova Foods là bối cảnh mô phỏng giáo dục; toàn bộ tên quy trình, vai trò, tình huống và dữ liệu được sử dụng trong ma trận phải là dữ liệu tổng hợp. Lý do giới hạn theo một case study là năng lực BA chỉ có thể đánh giá nhất quán khi người học áp dụng cùng thuật ngữ, cùng bối cảnh nghiệp vụ và cùng chuỗi artifact mô phỏng, thay vì ghép các ví dụ rời rạc từ nhiều doanh nghiệp không liên quan.

“Độc lập” trong phạm vi này nghĩa là BA có thể tự chuẩn bị, phân tích, tạo artifact, kiểm tra tính nhất quán và nêu điểm cần quyết định dựa trên bằng chứng có thể truy vết. Độc lập không có nghĩa BA được tự thay thế thẩm quyền của Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA. Cầu nối suy luận là: BA cần sở hữu chất lượng phân tích và khả năng đưa vấn đề đến đúng người quyết định, trong khi quyết định nghiệp vụ, pháp lý, kế toán, kiến trúc, bảo mật và vận hành vẫn thuộc vai trò có thẩm quyền tương ứng.

Ranh giới	Bao gồm trong ma trận	Không bao gồm trong ma trận	Tiêu chí quyết định
Đối tượng học	Lộ trình năng lực từ junior đến senior BA có khả năng thực hiện công việc độc lập theo mức độ tăng dần.	Lộ trình cho Project Manager, Developer, Tester, Accountant, Legal Counsel hoặc người vận hành nhà máy như một nghề nghiệp riêng.	Chỉ đưa vào khi năng lực đó giúp BA tạo, phân tích, làm rõ, truy vết hoặc bàn giao artifact BA.
Bối cảnh tổ chức	Nova Foods Trading & Manufacturing trong vai trò case study mô phỏng.	Doanh nghiệp thực, khách hàng thực, nhà cung cấp thực hoặc đơn vị ngoài Nova Foods.	Mọi ví dụ phải giữ tên Nova Foods và không suy diễn sự tồn tại của hệ thống ERP thực tế.
Dữ liệu	Mã, tên, số lượng, giá trị VND, vai trò và tình huống tổng hợp phục vụ học tập.	Dữ liệu cá nhân, giao dịch, hợp đồng, cấu hình, thông tin truy cập hoặc số liệu vận hành thực.	Nếu dữ liệu có thể nhận diện người, tổ chức hoặc hoạt động thực, dữ liệu đó nằm ngoài phạm vi.
Mức senior	Năng lực dẫn dắt phân tích, kiểm tra chất lượng, quản lý phụ thuộc, nhận diện rủi ro và thực hiện escalation có căn cứ.	Quyền phê duyệt thay Business Owner hoặc xác nhận tuân thủ thay chuyên gia có thẩm quyền.	Senior BA nâng mức độ phán đoán và điều phối, không tự mở rộng quyền quyết định.
Kết quả áp dụng	Minh chứng học tập và artifact mô phỏng có thể được đối chiếu trong corpus Nova Foods.	Cam kết triển khai ERP, hướng dẫn production, cấu hình hệ thống hoặc quyết định vận hành thực tế.	Artifact chỉ được dùng để đánh giá năng lực học tập trong case study.

Ma trận không mở rộng sang phạm vi đào tạo chung cho mọi ngành, mọi quốc gia hoặc mọi loại hệ thống. Bối cảnh Việt Nam, vi-VN, Asia/Ho_Chi_Minh và VND chỉ giúp người học diễn giải ví dụ Nova Foods một cách nhất quán; chúng không biến ví dụ thành yêu cầu pháp lý, kế toán hay vận hành. Khi một năng lực đòi hỏi kết luận thuộc thẩm quyền chuyên môn khác, ma trận phải đánh giá khả năng BA nhận diện giới hạn, ghi nhãn cần xác minh và chuyển đúng vai trò, thay vì đánh giá BA như người ra quyết định thay thế.

Ghi chú kiểm soát về không phê duyệt, không baseline và không sử dụng production

/01-curriculum/COMPETENCY_COVERAGE_MATRIX.md là artifact kế hoạch đang được kiểm soát để chuẩn bị ma trận bao phủ năng lực Business Analyst (BA). Vì artifact này có trạng thái IN_REVIEW và phiên bản v0.9.0, nội dung chỉ có thể được đọc là bản đang xem xét, có thể thay đổi và cần được truy vết; không có căn cứ nào trong trạng thái, phiên bản, tên tệp, vai trò Owner hoặc việc tồn tại của nội dung để suy ra một quyết định đã được phê duyệt.

Nội dung không được suy diễn	Căn cứ kiểm soát	Cách diễn giải bắt buộc
Approval (phê duyệt)	Không có approval reference được ghi nhận minh bạch trong artifact được kiểm soát.	Không được gọi bất kỳ competency, mức độ năng lực, nguồn tham chiếu, ví dụ, tiêu chí hay liên kết nào là “đã phê duyệt”, “được chấp thuận” hoặc tương đương.
Baseline (đường cơ sở đã khóa)	Không có baseline reference được ghi nhận minh bạch. Baseline là phiên bản nội dung được một thẩm quyền phù hợp xác nhận để làm mốc kiểm soát thay đổi.	Không được coi v0.9.0, cấu trúc ma trận dự kiến, ID, tên cột hoặc nội dung review là baseline.
Production (vận hành thực tế)	Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục và chỉ sử dụng dữ liệu tổng hợp.	Không được dùng artifact này để cấu hình ERP, hướng dẫn vận hành, xác nhận tuân thủ, đào tạo bắt buộc trong tổ chức thực tế hoặc ra quyết định triển khai.
Thẩm quyền Owner	Owner duy trì tính toàn vẹn quản trị của artifact, không thay thế Business Owner, Legal Owner, Accounting Owner, Security, Architect, QA hoặc thẩm quyền vận hành.	Việc Owner tạo, cập nhật hoặc điều phối review không cấu thành phê duyệt chuyên môn, pháp lý, kỹ thuật hay nghiệp vụ.

Quy tắc đọc áp dụng là: chỉ được sử dụng các thuật ngữ “đã phê duyệt”, “đã baseline” hoặc “được phép production” khi có tham chiếu kiểm soát rõ ràng tới quyết định tương ứng, nêu được artifact nguồn, phiên bản, thẩm quyền ra quyết định và phạm vi áp dụng. Lý do là một ma trận năng lực có thể ảnh hưởng đến cách diễn giải chuẩn đầu ra đào tạo; nếu thiếu bằng chứng quyết định và thẩm quyền phù hợp, việc gán các trạng thái trên sẽ biến nội dung kế hoạch thành cam kết không có căn cứ.

Mọi tên gọi, tình huống ERP, quy trình và dữ liệu liên quan Nova Foods trong artifact này chỉ phục vụ học tập bằng dữ liệu tổng hợp. Chúng không xác nhận sự tồn tại của hệ thống thực tế, không đại diện cho yêu cầu của người dùng thực tế, và không tạo nghĩa vụ pháp lý, kế toán, bảo mật, chất lượng hoặc vận hành.

Competency framework, classification rubric, and source policy

Mục tiêu ma trận và đối tượng sử dụng theo lộ trình Junior đến Senior BA

Ma trận này là công cụ lập kế hoạch để đối chiếu năng lực của Business Analyst (BA, Chuyên viên Phân tích Nghiệp vụ) với nội dung học, bài thực hành và artifact dự kiến trong corpus Nova Foods Trading & Manufacturing. Mục tiêu không phải là xếp hạng con người hoặc xác nhận một cá nhân đủ điều kiện làm việc thực tế. Mục tiêu là cho người học thấy một năng lực được xây từ kiến thức nền, thao tác có hướng dẫn, khả năng tự phân tích và cuối cùng là năng lực đưa ra khuyến nghị có kiểm soát. Cầu nối suy luận là: BA không thể thực hiện một quyết định phức tạp đáng tin cậy nếu chưa biết xác định vấn đề, thu thập bằng chứng, nêu giả định và kiểm tra tác động của quyết định đó.

Nova Foods là case study mô phỏng giáo dục; mọi quy trình ERP, tên vai trò, số liệu VND, dữ liệu và tình huống được dùng trong ma trận đều là dữ liệu tổng hợp. Vì vậy, “Senior BA” trong ma trận chỉ mô tả mức năng lực học tập dự kiến, không xác nhận thẩm quyền phê duyệt, quyền quyết định vận hành, năng lực pháp lý, năng lực kế toán hay quyền triển khai production.

Nhóm người đọc	Nhu cầu sử dụng ma trận	Kết quả cần nhận được
Người học mới bắt đầu	Biết điểm xuất phát, thuật ngữ cần học và thứ tự phát triển hợp lý.	Có lộ trình từ hiểu khái niệm đến tạo được artifact BA đơn giản với hướng dẫn.
Junior BA	Xác định khoảng cách giữa việc hoàn thành một biểu mẫu và việc giải thích được lý do chọn nội dung.	Có thể thực hiện tác vụ BA xác định phạm vi, ghi nhận giả định và yêu cầu phản hồi review.
Mid-level BA	Liên kết nhiều artifact, nhận diện mâu thuẫn và đánh giá tác động liên phòng ban.	Có thể chuẩn bị phân tích có traceability (khả năng truy vết nguồn gốc và liên kết của thông tin) để hỗ trợ quyết định.
Senior BA	Dẫn dắt cách phân tích, làm rõ rủi ro, giới hạn thẩm quyền và phương án xử lý cho vấn đề chưa đủ bằng chứng.	Có thể đưa ra khuyến nghị có điều kiện, nêu rõ bằng chứng, giả định, bên cần xác minh và tác động nếu không xử lý.
Curriculum Author và reviewer	Kiểm tra liệu lộ trình học có tạo được tiến triển năng lực thực chất hay chỉ lặp lại thuật ngữ.	Có cơ sở để phát hiện khoảng trống, trùng lặp hoặc bước học vượt quá năng lực đầu vào.

Lộ trình Junior đến Senior được tổ chức theo nguyên tắc “từ thực hiện tác vụ đến chịu trách nhiệm về chất lượng phân tích”. Ở mức Junior, người học cần biết sử dụng cấu trúc có sẵn và phân biệt dữ kiện với giả định. Ở mức cao hơn, người học cần giải thích quan hệ nguyên nhân–hệ quả giữa mục tiêu nghiệp vụ, quy trình, dữ liệu, yêu cầu và rủi ro. Ở mức Senior, người học không được tự thay thế quyết định của Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA; năng lực senior được thể hiện bằng việc xác định đúng người có thẩm quyền, chuẩn bị câu hỏi quyết định được và bảo toàn truy vết.

Mốc phát triển	Trọng tâm học tập	Dấu hiệu tiến bộ có thể quan sát trong bối cảnh mô phỏng
Junior — hiểu và thực hiện có hướng dẫn	Học thuật ngữ, cấu trúc artifact và quy tắc ghi nhận thông tin.	Phân biệt được mục tiêu, yêu cầu, quy tắc nghiệp vụ, dữ liệu và giả định trong một tình huống Nova Foods tổng hợp.
Junior độc lập có kiểm soát	Hoàn thành tác vụ BA có phạm vi rõ, tự kiểm tra tính đầy đủ cơ bản.	Ghi được câu hỏi làm rõ, nêu nguồn đầu vào và không biến thông tin chưa xác minh thành sự thật.
Mid-level — phân tích liên kết	Đánh giá tác động giữa quy trình, dữ liệu, yêu cầu, kiểm thử và bên liên quan.	Phát hiện một thay đổi có thể ảnh hưởng nhiều artifact và mô tả được chuỗi tác động.
Senior — định hướng quyết định	Thiết kế cách tiếp cận, quản lý bất định và đưa khuyến nghị có điều kiện.	Trình bày phương án, tiêu chí lựa chọn, rủi ro, giả định và điểm cần escalation (chuyển vấn đề đến vai trò có thẩm quyền) mà không tự tuyên bố phê duyệt.

Ma trận được dùng để kiểm tra tính nhất quán giữa cam kết đào tạo và năng lực đầu ra dự kiến, không dùng làm hồ sơ đánh giá nhân sự, tiêu chí tuyển dụng hay bằng chứng chứng nhận nghề nghiệp. Lý do là corpus hiện ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, chưa có tham chiếu baseline hoặc approval. Do đó, mọi kết luận từ ma trận chỉ là kế hoạch phát triển học liệu trong bối cảnh vi-VN, Asia/Ho_Chi_Minh và VND mô phỏng.

Thang phân loại mức độ bao phủ năng lực

Ma trận đánh giá mức độ mà corpus học liệu giúp người học hình thành và chứng minh một năng lực BA, không đánh giá mức độ người học đã được tuyển dụng, đã làm dự án thật hay đã được phê duyệt. Nova Foods Trading & Manufacturing là bối cảnh mô phỏng giáo dục; mọi ví dụ, quy trình và dữ liệu đều là dữ liệu tổng hợp. Vì vậy, mức phân loại được xác định bằng bằng chứng học tập có thể kiểm tra trong corpus, thay vì suy đoán từ tiêu đề chương hoặc từ việc một thuật ngữ xuất hiện.

Mức phân loại	Định nghĩa vận hành	Bằng chứng tối thiểu để gán mức	Không được gán mức này khi	Ví dụ phân loại
Deep (Bao phủ sâu)	Người học được dẫn từ khái niệm đến thực hành độc lập: hiểu mục đích, áp dụng kỹ thuật, tạo đầu ra, tự kiểm tra chất lượng và xử lý tình huống thay đổi hoặc xung đột.	Có hướng dẫn từng bước; đầu ra BA cụ thể; ví dụ làm việc hoàn chỉnh bằng dữ liệu tổng hợp; tiêu chí chất lượng hoặc lỗi thường gặp; bài tập buộc người học giải thích quyết định. Cầu nối suy luận là: nhiều loại bằng chứng này cùng chứng minh năng lực không chỉ được biết mà còn được thực hành và kiểm tra.	Chỉ có định nghĩa, danh sách bước, mẫu trống, hoặc một ví dụ không yêu cầu người học tạo và đánh giá đầu ra.	Năng lực “phân tích yêu cầu” là Deep nếu learner lập yêu cầu, tiêu chí chấp nhận, xử lý mâu thuẫn và tự đối chiếu chất lượng đầu ra.
Partial (Bao phủ một phần)	Corpus dạy một phần có ý nghĩa của năng lực nhưng chưa đủ để người học thực hiện độc lập toàn bộ vòng đời hoặc chưa chạm đến điều kiện khó, kiểm tra chất lượng, hay đầu ra liên quan.	Có giải thích và ít nhất một hoạt động hoặc đầu ra liên quan trực tiếp đến năng lực; đồng thời xác định rõ phần nào chưa được dạy hoặc chưa được chứng minh. Cầu nối suy luận là: có bằng chứng thực hành nên không phải “Mention”, nhưng thiếu một thành phần thiết yếu nên chưa thể là “Deep”.	Phạm vi thiếu không được chỉ rõ, hoặc phần hiện có chỉ nhắc tên kỹ thuật mà không cho learner thao tác trên dữ liệu/tình huống mô phỏng.	Năng lực “mô hình hóa quy trình” là Partial nếu learner đọc và chỉnh sửa luồng đơn giản nhưng chưa đánh giá ngoại lệ, trách nhiệm hoặc chất lượng mô hình.
Mention (Đề cập)	Thuật ngữ, mục tiêu hoặc sự tồn tại của năng lực được giới thiệu để định hướng, nhưng corpus chưa cung cấp đủ hướng dẫn và thực hành để hình thành năng lực.	Có định nghĩa ngắn, liên kết khái niệm hoặc lời nhắc về thời điểm dùng năng lực. Cầu nối suy luận là: nội dung giúp nhận biết phạm vi, nhưng không có đầu ra hay tiêu chí quan sát để chứng minh thực hành.	Có bài tập tạo đầu ra hoặc hướng dẫn thao tác đủ rõ; khi đó phải xem xét Partial hoặc Deep.	“Quản trị thay đổi” xuất hiện trong phần tổng quan như một trách nhiệm BA nhưng chưa có tình huống, kỹ thuật hay đầu ra tương ứng là Mention.
Explicitly excluded (Chủ động loại trừ)	Năng lực được ghi nhận là nằm ngoài phạm vi có chủ đích của corpus hoặc của giai đoạn học, kèm ranh giới rõ ràng để tránh hiểu nhầm là khoảng trống vô tình.	Có tuyên bố loại trừ, lý do phạm vi và ranh giới thẩm quyền hoặc đối tượng học. Cầu nối suy luận là: việc nêu rõ lý do phân biệt “không dạy theo thiết kế” với “chưa có nội dung”.	Chỉ không tìm thấy nội dung mà không có tuyên bố loại trừ; trường hợp đó là Missing.	“Cấu hình ERP production” là Explicitly excluded nếu corpus chỉ đào tạo BA và nêu rõ không hướng dẫn cấu hình hay cấp quyền triển khai hệ thống thực tế.
Missing (Thiếu)	Không có nội dung đủ để nhận biết, hướng dẫn hoặc thực hành năng lực; cũng không có quyết định loại trừ được ghi nhận.	Không tìm thấy bằng chứng nội dung, đầu ra, ví dụ hay tuyên bố loại trừ sau khi kiểm tra các phần có liên quan trong corpus. Cầu nối suy luận là: không có căn cứ để xác nhận learner đã được giới thiệu hoặc rèn luyện năng lực.	Có dù chỉ nội dung định hướng đáng tin cậy; khi đó tối thiểu phải là Mention.	Nếu corpus không đề cập cách BA quản lý yêu cầu mâu thuẫn, không có ví dụ, bài tập hay tuyên bố loại trừ, năng lực này là Missing.

Quy tắc chấm là sử dụng mức thấp nhất mà bằng chứng thực sự hỗ trợ, không nâng mức vì tiêu đề chương nghe phù hợp hoặc vì người biên soạn cho rằng kiến thức đó “thường được hiểu”. Ví dụ, một mẫu có trường “tiêu chí chấp nhận” chỉ chứng minh sự hiện diện của cấu trúc đầu ra; nếu learner không được hướng dẫn viết, kiểm tra tính kiểm thử được và sửa lỗi, bằng chứng chưa đủ cho Deep.

Khi bằng chứng có vẻ nằm giữa hai mức, người lập ma trận phải đặt câu hỏi theo thứ tự: learner có được giải thích mục đích không; learner có tự tạo hoặc sửa đầu ra không; đầu ra có được kiểm tra bằng tiêu chí quan sát được không; learner có xử lý biến thể, ngoại lệ hoặc xung đột không. Câu trả lời tăng dần từ “không có” đến “có đầy đủ” dẫn lần lượt từ Missing, Mention, Partial đến Deep; chỉ dùng Explicitly excluded khi ranh giới loại trừ đã được ghi rõ, không dùng để che phủ khoảng trống nội dung.

Năng lực cốt lõi và quy tắc không để trống năng lực thiết yếu

Năng lực cốt lõi là năng lực mà người học phải có để thực hiện độc lập một phần công việc BA (Business Analyst — Chuyên viên Phân tích Nghiệp vụ) có ảnh hưởng trực tiếp đến tính đúng đắn, khả năng kiểm tra hoặc khả năng bàn giao của giải pháp. Đây không phải là danh sách kỹ năng “nên biết”; nếu thiếu năng lực cốt lõi, người học có thể tạo ra yêu cầu mơ hồ, không truy vết được quyết định, hoặc chuyển giao sai thông tin cho nhóm thiết kế, phát triển, kiểm thử và nghiệp vụ.

Một năng lực được xác định là cốt lõi khi thỏa ít nhất một tiêu chí dưới đây. Cầu nối suy luận là: tiêu chí chỉ ra hậu quả có thể xảy ra khi thiếu năng lực; hậu quả ảnh hưởng trực tiếp đến chất lượng phân tích nên năng lực phải được bảo đảm trong lộ trình junior-to-senior.

Tiêu chí xác định	Cầu nối suy luận	Ví dụ trong bối cảnh Nova Foods mô phỏng
Là đầu vào bắt buộc để hiểu vấn đề nghiệp vụ	Không hiểu mục tiêu, phạm vi và bên liên quan thì BA không thể xác định đúng vấn đề cần giải quyết.	Phân biệt nhu cầu theo dõi lô hàng với một yêu cầu cấu hình ERP cụ thể.
Tạo hoặc kiểm soát artifact được dùng bởi vai trò khác	Artifact thiếu cấu trúc hoặc thiếu căn cứ làm đứt thông tin khi chuyển sang thiết kế, xây dựng hoặc kiểm thử.	Soạn yêu cầu, quy tắc nghiệp vụ, tiêu chí chấp nhận và liên kết truy vết ở mức học liệu.
Giảm rủi ro sai lệch quyết định có tác động đáng kể	Một quyết định thiếu phân tích về dữ liệu, quy trình, ngoại lệ hoặc quyền truy cập có thể tạo lỗi lan truyền qua nhiều nhóm.	Nhận diện việc một thay đổi trạng thái đơn hàng có thể ảnh hưởng tồn kho, giao hàng và báo cáo mô phỏng.
Là tiền đề để thực hiện năng lực BA ở cấp cao hơn	Không có nền tảng thì người học chỉ lặp lại mẫu biểu mà không thể đánh giá chất lượng hay xử lý tình huống mới.	Không thể phân tích tác động thay đổi nếu chưa biết liên kết yêu cầu với quy trình và dữ liệu.
Có thể quan sát, thực hành và đánh giá bằng đầu ra cụ thể	Năng lực đào tạo phải được kiểm chứng bằng hành vi hoặc artifact, không chỉ bằng việc người học biết thuật ngữ.	Người học giải thích được vì sao một yêu cầu cần làm rõ và ghi được câu hỏi làm rõ có ngữ cảnh.

Quy tắc bắt buộc của ma trận là: không năng lực cốt lõi nào được giữ trạng thái Missing khi hoàn tất kế hoạch coverage. Missing ở đây nghĩa là corpus chưa có nội dung học, bài thực hành, artifact hướng dẫn hoặc cơ chế đánh giá đủ để người học hình thành năng lực đó. Quy tắc này áp dụng cho toàn bộ lộ trình junior-to-senior, không cho phép bù trừ bằng việc một năng lực khác được trình bày sâu hơn.

Khi phát hiện một năng lực cốt lõi đang Missing, người lập ma trận phải thực hiện một trong hai xử lý trước khi coi coverage là đầy đủ: (1) bổ sung liên kết tới nội dung và hoạt động học phù hợp trong corpus đã được kiểm soát; hoặc (2) đánh giá lại việc gán nhãn “cốt lõi” và ghi rõ căn cứ rằng năng lực đó không còn đáp ứng bất kỳ tiêu chí cốt lõi nào ở trên. Không được đổi tên năng lực, gom vào một nhãn chung chung, hoặc giả định người học đã biết từ kinh nghiệm bên ngoài để xóa trạng thái Missing.

Ví dụ, nếu người học cần chuyển một yêu cầu Nova Foods mô phỏng sang đầu vào kiểm thử nhưng corpus không giúp họ xác định tiêu chí chấp nhận hoặc điều kiện ngoại lệ, năng lực này vẫn là khoảng trống cốt lõi. Lý do là đầu ra BA không thể được kiểm tra một cách nhất quán; do đó, việc chỉ có mô tả quy trình hoặc thuật ngữ kiểm thử không thay thế năng lực tạo test basis (cơ sở để thiết kế kiểm thử). Mọi ví dụ Nova Foods trong ma trận chỉ dùng dữ liệu tổng hợp, phục vụ giáo dục và không xác nhận quy trình, cấu hình ERP hay quyết định vận hành thực tế.

Xác định năng lực Partial quan trọng và kế hoạch xử lý bắt buộc

Partial nghĩa là năng lực đã xuất hiện trong học liệu nhưng người học chưa có đủ chuỗi bằng chứng để thực hiện độc lập trong một tình huống mới: còn thiếu giải thích nguyên lý, bước thực hành, artifact đầu ra, tiêu chí kiểm tra chất lượng, ví dụ đã giải hoặc đánh giá năng lực quan sát được. Một mục Partial được coi là quan trọng khi khoảng thiếu đó có thể làm đứt chuỗi từ phát hiện nhu cầu đến yêu cầu, giải pháp, kiểm thử hoặc bàn giao; hoặc khi thiếu năng lực này khiến Junior BA không thể tiến lên mức BA độc lập một cách an toàn.

Tiêu chí quyết định	Câu hỏi kiểm tra	Kết luận
Thuộc chuỗi công việc BA cốt lõi	Người học có cần năng lực này để hiểu vấn đề, làm rõ yêu cầu, mô hình hóa, xác nhận, truy vết hoặc hỗ trợ kiểm thử không?	Nếu có, đánh dấu là Partial quan trọng khi bằng chứng học tập chưa đủ.
Có quan hệ phụ thuộc	Chapter, template hoặc bài thực hành khác có giả định người học đã làm được năng lực này không?	Nếu có, khoảng thiếu có thể lan truyền sang nhiều phần học liệu nên phải xử lý.
Có rủi ro chất lượng hoặc kiểm soát	Việc thiếu năng lực có thể tạo yêu cầu mơ hồ, dữ liệu không nhất quán, tiêu chí chấp nhận không kiểm thử được, hoặc suy diễn vượt thẩm quyền không?	Nếu có, phải có kế hoạch xử lý trước khi dùng năng lực đó làm đầu vào cho bài sau.
Cần cho chuyển cấp độ	Năng lực có phân biệt giữa người mới chỉ biết thuật ngữ và BA có thể tạo đầu ra được review không?	Nếu có, không được chỉ giữ ở mức nhắc đến.
Có giới hạn chuyên môn cần xác minh	Năng lực chạm đến pháp lý, kế toán, quyền riêng tư, an toàn thực phẩm, bảo mật hoặc kiến trúc không?	Nếu có, kế hoạch phải nêu vai trò cần escalation và giữ nhãn Verification required hoặc giả định dự án phù hợp.

Quy tắc áp dụng là: một mục Partial phải được ghi là Partial quan trọng nếu thỏa ít nhất một trong ba điều kiện đầu tiên, hoặc nếu nó là điều kiện cần để người học tạo artifact được kiểm tra bởi người khác. Không được hạ mức quan trọng chỉ vì nội dung khó, thiếu thời lượng, hoặc chưa có ví dụ. Lý do là ma trận dùng để phát hiện khoảng trống năng lực, không dùng để che giấu khoảng trống bằng cách đổi nhãn.

Mỗi Partial quan trọng phải có kế hoạch xử lý tường minh ngay trong dòng ma trận hoặc trong artifact liên kết được nêu rõ. “Tường minh” nghĩa là người review có thể trả lời được: thiếu phần nào, sẽ bổ sung ở đâu, người học phải tạo ra đầu ra gì, đầu ra được kiểm tra thế nào, và khi nào mới được đánh giá lại mức độ bao phủ. Kế hoạch chỉ ghi “bổ sung nội dung” không đạt yêu cầu vì không chỉ ra bằng chứng rằng người học đã chuyển từ biết khái niệm sang làm được công việc.

Thành phần kế hoạch xử lý	Nội dung bắt buộc ghi nhận	Ví dụ mô phỏng Nova Foods
Khoảng thiếu cụ thể	Phân biệt rõ thiếu kiến thức, kỹ thuật, thực hành, artifact, kiểm tra chất lượng hay ranh giới thẩm quyền.	Người học biết khái niệm business rule nhưng chưa tách được quy tắc khỏi yêu cầu chức năng trong tình huống quản lý lô hàng mô phỏng.
Biện pháp bổ sung	Nêu chapter, bài tập, hướng dẫn, template hoặc buổi review dự kiến sẽ bổ sung; không coi đây là cam kết đã hoàn thành.	Bổ sung bài thực hành phân loại phát biểu thành quy tắc, yêu cầu chức năng và giả định dự án; liên kết đến CANONICAL_BUSINESS_RULES.
Bằng chứng đầu ra	Chỉ rõ artifact người học phải tạo hoặc cập nhật.	Bảng phân loại phát biểu và bản ghi quy tắc có ID tham chiếu theo TRACEABILITY_ID_REGISTRY.
Cổng chất lượng	Đặt điều kiện kiểm tra khách quan để nhận biết phần thiếu đã được xử lý.	Reviewer kiểm tra mỗi quy tắc có nguồn hoặc nhãn giả định/xác minh, có điều kiện áp dụng và không bị trình bày như quyết định vận hành thực tế.
Năng lực quan sát được	Mô tả hành vi mà người học thực hiện được, không chỉ mô tả nội dung đã đọc.	Người học giải thích được vì sao một phát biểu là quy tắc, nêu được điểm cần xác minh và không tự kết luận nghĩa vụ pháp lý hoặc kế toán.
Điều kiện đánh giá lại	Xác định bằng chứng tối thiểu để xem xét chuyển từ Partial sang mức bao phủ cao hơn.	Có hướng dẫn, ví dụ đã giải, bài thực hành độc lập, artifact đầu ra và kết quả qua cổng chất lượng.

Ví dụ, “phân tích tác động của thay đổi dữ liệu” là Partial quan trọng nếu curriculum chỉ giới thiệu từ điển dữ liệu mà chưa yêu cầu người học lần theo ảnh hưởng tới quy tắc, giao diện, tích hợp và kiểm thử. Cầu nối suy luận là: thay đổi một thuộc tính dữ liệu có thể làm thay đổi nhiều artifact phụ thuộc; do đó, chỉ biết định nghĩa dữ liệu chưa chứng minh khả năng đánh giá tác động. Kế hoạch xử lý phải yêu cầu người học dùng dữ liệu tổng hợp của Nova Foods, lập bảng tác động có liên kết đến CANONICAL_DATA_DICTIONARY, và qua review kiểm tra rằng không có kết luận về cấu hình ERP thực tế, dữ liệu cá nhân thực hoặc nghĩa vụ tuân thủ chưa được xác minh.

Một Partial quan trọng chỉ được giữ mở khi kế hoạch xử lý đã có đủ sáu thành phần trên. Nếu chưa xác định được nơi bổ sung, artifact đầu ra, cổng chất lượng hoặc thẩm quyền xác minh, mục đó phải được nêu là rủi ro coverage để điều phối chỉnh sửa curriculum; không được suy diễn rằng Nova Foods đã chấp nhận cách xử lý, đã baseline nội dung, hoặc đã phê duyệt năng lực.

Cột bằng chứng dự kiến để chứng minh năng lực học viên

Ma trận sẽ không chỉ ghi tên năng lực mà phải ghi bằng chứng có thể kiểm tra. Lý do là một năng lực chỉ được coi là đã được curriculum hỗ trợ khi người rà soát lần theo được từ nội dung học, đầu ra học viên, ví dụ áp dụng, tiêu chí kiểm tra đến hành vi quan sát được. Mỗi dòng năng lực vì vậy dự kiến có năm cột bằng chứng dưới đây; các liên kết chỉ tham chiếu artifact canonical đang ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, không xác nhận baseline, approval hay năng lực đã được chứng minh trong vận hành thực tế.

Cột bằng chứng dự kiến	Nội dung phải ghi	Quy tắc ghi nhận và cầu nối suy luận
Chapter linkage — liên kết chapter	Tên chapter và tham chiếu đến entry tương ứng trong /01-curriculum/CHAPTER_MANIFEST.md.	Chapter là nơi giải thích khái niệm, quy trình hoặc kỹ thuật. Liên kết này trả lời câu hỏi: “Người học được dạy năng lực này ở đâu?” Không được tự tạo chapter ID, tên tệp chapter hoặc số thứ tự không có trong manifest.
Artifact linkage — liên kết artifact	Artifact đầu ra mà học viên phải đọc, lập hoặc cập nhật; giữ nguyên Artifact ID và đường dẫn canonical nếu đã có.	Artifact biến kiến thức thành kết quả có thể rà soát. Ví dụ, năng lực phân tích quy tắc có thể liên kết CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; năng lực dữ liệu có thể liên kết CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; năng lực truy vết có thể liên kết TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Worked example linkage — liên kết ví dụ thực hành có hướng dẫn	Tên tình huống Nova Foods mô phỏng, dữ liệu tổng hợp sử dụng và artifact học viên tạo hoặc đánh giá trong tình huống đó.	Ví dụ thực hành tạo cầu nối từ “biết cách làm” sang “áp dụng trong ngữ cảnh”. Ví dụ phải nêu rõ đây là Nova Foods Trading & Manufacturing mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; không suy diễn đó là quy trình, cấu hình hay dữ liệu ERP thực tế.
Quality gate — cổng chất lượng	Điều kiện kiểm tra tối thiểu, người hoặc vai trò rà soát dự kiến, và tiêu chí đạt/không đạt có thể quan sát.	Quality gate kiểm tra đầu ra thay vì đánh giá theo cảm nhận. Ví dụ: liên kết artifact phải dùng đúng ID canonical; một quy tắc được nêu trong ví dụ phải có nguồn hoặc nhãn xác minh phù hợp; một mục dữ liệu phải không mâu thuẫn với định nghĩa trong CANONICAL_DATA_DICTIONARY. Vai trò rà soát chỉ thực hiện review trong phạm vi thẩm quyền, không tạo approval ngầm định.
Observable learner capability — năng lực người học có thể quan sát	Một hành động đo được, đối tượng áp dụng, kết quả cần tạo và giới hạn thẩm quyền.	Cột này trả lời câu hỏi: “Người học làm được gì mà người rà soát có thể nhìn thấy?” Câu viết phải dùng động từ kiểm chứng được như “lập”, “phân biệt”, “liên kết”, “đối chiếu”, “nêu câu hỏi escalation”; tránh các động từ không đo được như “hiểu” hoặc “nắm vững” nếu không có đầu ra chứng minh.

Bản ghi minh họa dưới đây cho thấy cách năm cột kết nối thành một chuỗi bằng chứng. Việc học viên liên kết một quy tắc với dữ liệu và đăng ký định danh là bằng chứng thao tác; quality gate kiểm tra tính nhất quán của thao tác đó; do đó năng lực quan sát được không suy ra từ việc học viên chỉ đọc tài liệu.

Năng lực được theo dõi	Chapter linkage	Artifact linkage	Worked example linkage	Quality gate	Observable learner capability
Duy trì truy vết giữa quy tắc nghiệp vụ và dữ liệu logic	Entry chapter phù hợp trong /01-curriculum/CHAPTER_MANIFEST.md	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; TRACEABILITY_ID_REGISTRY	Tình huống mô phỏng Nova Foods về kiểm tra tính đầy đủ của một quy tắc đặt hàng và thuộc tính dữ liệu liên quan, sử dụng mã và giá trị tổng hợp	Người rà soát đối chiếu: ID được dùng đúng registry; liên kết không thay thế nguồn canonical; nội dung chưa xác minh vẫn giữ nhãn phù hợp	Học viên lập được một liên kết truy vết có ID, chỉ ra được artifact nguồn, mô tả được điểm chưa đủ bằng chứng và chuyển điểm đó đến vai trò có thẩm quyền thay vì tự xác nhận quy tắc

Khi một cột chưa thể điền bằng tham chiếu kiểm chứng được, dòng ma trận phải giữ rõ khoảng trống bằng chứng tại chính cột đó; không được bù bằng tên artifact gần giống, giả định rằng chapter đã dạy nội dung, hoặc diễn giải ví dụ mô phỏng thành xác nhận nghiệp vụ Nova Foods.

Chính sách nguồn cho ma trận năng lực

Ma trận chỉ sử dụng verified primary-source seed được cung cấp, với ngày truy cập 2026-08-07, làm tập nguồn bên ngoài ban đầu. Lý do là một ma trận năng lực phải cho người học biết căn cứ của nhận định bao phủ, thay vì biến kinh nghiệm của tác giả thành sự thật không kiểm chứng. Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục; mọi ví dụ chỉ dùng dữ liệu tổng hợp và không được xem là bằng chứng về cấu hình, quy trình hoặc nghĩa vụ vận hành thực tế.

Nhãn phân loại nguồn	Ý nghĩa sử dụng trong ma trận	Nguồn seed được phép gắn nhãn	Giới hạn diễn giải bắt buộc
Normative standard (tiêu chuẩn/quy phạm chuẩn hóa)	Nguồn xác định thuật ngữ, ký pháp hoặc cấu trúc kỹ thuật theo tổ chức phát hành. Ma trận dùng nguồn này để đánh giá người học có thể đọc, lập hoặc đối chiếu artifact theo chuẩn.	BPMN 2.0.2; UML 2.5.1; OpenAPI Specification OAS 3.1.1; WCAG 2.2 Recommendation; ISO/IEC/IEEE 29148:2018.	Chỉ nêu nội dung có thể đối chiếu với URL chính thức. Với ISO/IEC/IEEE 29148, không suy diễn điều khoản chính xác khi chưa kiểm tra văn bản được cấp phép. Không gọi sơ đồ hoạt động PlantUML là BPMN.
Industry good practice (thực hành tốt ngành)	Nguồn hỗ trợ cách làm được cộng đồng chuyên môn công nhận rộng rãi, dùng để định hướng kỹ năng và chất lượng đầu ra, không tự tạo nghĩa vụ pháp lý.	BABOK Guide Version 3; ISTQB CTFL Syllabus v4.0.1; OWASP ASVS 5.0.0; OWASP API Security Top 10 2023.	BABOK được dùng cho vùng kiến thức, nhiệm vụ, năng lực và thuật ngữ BA; không bịa số trang hoặc điều khoản. OWASP là chuẩn/thực hành xác minh an ninh ngành, không phải luật Việt Nam.
Project convention (quy ước dự án)	Quy tắc nội bộ corpus giúp liên kết nhất quán giữa chapter, template và artifact.	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/TEMPLATE_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Giữ nguyên Artifact ID, filename, IN_REVIEW, v0.9.0, vi-VN, Asia/Ho_Chi_Minh và bối cảnh VND. Quy ước corpus không phải tiêu chuẩn ngoài, không phải baseline, approval hay requirement production.
Author recommendation (khuyến nghị của tác giả)	Đề xuất phương pháp học, cách tổ chức ma trận hoặc thứ tự phát triển năng lực khi seed không quy định trực tiếp.	Không có nguồn bên ngoài bổ sung; phải ghi rõ đây là khuyến nghị biên soạn.	Không được gắn khuyến nghị thành quy định của Nova Foods, yêu cầu pháp lý, quy tắc kế toán, nghĩa vụ an toàn thực phẩm hoặc cam kết kỹ thuật. Cầu nối suy luận phải nêu rõ: nguồn nào hỗ trợ bối cảnh và phần nào là lựa chọn thiết kế học liệu.
Verification required (cần xác minh)	Nhãn giữ chỗ kiểm soát khi một nhận định cần văn bản đầy đủ, phiên bản mới hơn hoặc kết luận của vai trò có thẩm quyền trước khi dùng làm yêu cầu.	ISO/IEC/IEEE 29148 khi cần điều khoản; Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15; Nghị định 356/2025/NĐ-CP; Luật Kế toán 88/2015/QH13; Nghị định 123/2020/NĐ-CP; Luật An toàn thực phẩm 55/2010/QH12.	Không chuyển nhãn này thành kết luận bắt buộc. Việc xác minh phải dựa trên nguồn chính thức hiện hành và vai trò chuyên môn phù hợp; riêng Nghị định 123/2020/NĐ-CP cần kiểm tra sửa đổi trước khi dùng cho bối cảnh production.

Quy tắc ghi nguồn cho từng dòng ma trận là: ghi tên nguồn + phiên bản/trạng thái + nhãn phân loại + mục đích dùng. Ví dụ, một năng lực “mô tả API HTTP” có thể dẫn đến OpenAPI Specification — OAS 3.1.1 — Normative standard — đối chiếu cấu trúc mô tả HTTP API; suy luận này hợp lệ vì seed xác định OAS là nguồn quy phạm cho tính năng OAS 3.1 và mô tả HTTP API. Ngược lại, một nhận định như “Nova Foods phải lưu chứng từ trong một thời hạn cụ thể” không được tạo từ seed này nếu chưa có kiểm tra văn bản hiện hành và thẩm quyền chuyên môn; dòng tương ứng phải mang nhãn Verification required, không được diễn đạt như fact của case study.

Không được bổ sung blog, bài viết cộng đồng, tài liệu huấn luyện không được xác minh, trích dẫn không có URL chính thức, hoặc nguồn tự suy đoán vào ma trận. Khi nguồn seed không đủ để kết luận, tác giả giữ nguyên giới hạn bằng Verification required hoặc ghi Author recommendation nếu nội dung chỉ là lựa chọn sư phạm; hai nhãn này bảo toàn khác biệt giữa bằng chứng, suy luận và ý kiến thiết kế.

Lan canh xac minh cho khang dinh phap ly, ke toan, du lieu ca nhan va an toan thuc pham

Nova Foods Trading & Manufacturing la case study giao duc mo phong, chi dung du lieu tong hop; vi vay, mot vi du co so tien VND, ma don hang hoac thong tin nha cung cap mo phong khong chung minh nghia vu phap ly, cach hach toan, cau hinh ERP hay muc do tuan thu thuc te. BA phai tach bach su kien quan sat duoc trong hoc lieu voi khang dinh chuan tac: su kien chi mo ta tinh huong hoc; khang dinh chuan tac chi duoc viet khi co nguon chinh thuc con hieu luc va nguoi co tham quyen chuyen mon xac minh cho pham vi ap dung.

Nhom khang dinh	Can cu duoc phep tham chieu trong seed	Cach viet duoc phep trong matrix va hoc lieu	Cach viet bi cam	Nguoi/can cu can xac minh truoc khi chuyen thanh yeu cau
Phap ly bao ve du lieu ca nhan	Luat Bao ve du lieu ca nhan 91/2025/QH15 va Nghi dinh 356/2025/ND-CP	“Can Verification required voi Legal Owner ve nghia vu ap dung cho du lieu ca nhan mo phong.”	“Nova Foods bat buoc thu thap dong y theo quy trinh X” khi chua doi chieu van ban va pham vi xu ly.	Legal Owner; van ban chinh thuc hien hanh, pham vi xu ly, vai tro cac ben va quyet dinh ap dung duoc ghi nhan.
Ke toan, hoa don, chung tu	Luat Ke toan 88/2015/QH13; Nghi dinh 123/2020/ND-CP	“Cach dinh khoan, thoi diem ghi nhan va xu ly chung tu trong vi du la Project assumption.”	“ERP phai hach toan tai tai khoan X” hoac “hoa don phai duoc lap theo luong Y” nhu ket luan co hieu luc.	Accounting Owner va Legal Owner; doi chieu van ban hien hanh, sua doi neu co, chinh sach ke toan va mo hinh giao dich thuc te.
An toan thuc pham, truy xuat va thu hoi	Luat An toan thuc pham 55/2010/QH12	“Kha nang lien ket lo hang mo phong phuc vu bai hoc ve truy xuat; quy tac van hanh can Verification required.”	“He thong dap ung yeu cau truy xuat/thu hoi” hoac gan thoi hanh dong, bieu mau, nguong chat luong nhu nghia vu da xac lap.	Food-safety Domain Owner va Legal Owner; quy trinh chat luong, pham vi san pham, co quan/chuong trinh ap dung va bang chung xac minh.
Bao mat co lien quan du lieu	OWASP ASVS 5.0.0; OWASP API Security Top 10 2023	“Day la tham chieu thuc hanh bao mat; quyet dinh kiem soat cho Nova Foods can Verification required.”	Goi OWASP la luat Viet Nam, hoac ket luan he thong tuan thu chi tu mot vi du hoc tap.	Security Owner va Architect; phan loai du lieu, kien truc, nguy co va pham vi kiem thu.

Quy tac nhan va cau noi suy luan: neu noi dung chi co tinh huong hoc, chua co doi chieu day du nguon chinh thuc hien hanh va chua co ket luan cua vai tro co tham quyen, BA phai gan nhan Project assumption. Ly do la seed chi xac nhan ton tai va ranh gioi su dung cua nguon, khong cung cap ket luan ap dung cho mot cau hinh ERP cu the. Neu noi dung co the anh huong nghia vu phap ly, thue, ke toan, quyen rieng tu, an toan thuc pham, truy xuat hoac thu hoi, BA phai gan nhan Verification required; ly do la ket luan nay can doi chieu van ban hien hanh, pham vi thuc te va thiet ke duoc de xuat.

Mau dien dat an toan trong artifact: “Trong don hang mo phong NF-SO-0001, truong lien ket lo hang duoc dung de minh hoa nhu cau truy vet; quy tac luu giu, pham vi truy xuat va hanh dong thu hoi la Verification required voi Food-safety Domain Owner va Legal Owner.” Mau nay giu duoc gia tri hoc tap vi learner van thay quan he giua du lieu va rui ro, dong thoi khong suy dien thanh nghia vu van hanh hay tuan thu cua Nova Foods.

Khong duoc dung cac tu “tuan thu”, “hop phap”, “dung quy dinh”, “du dieu kien xuat hoa don”, “duoc phep xu ly du lieu”, “dat yeu cau an toan thuc pham” hoac tuong duong neu artifact khong co bang chung xac minh phu hop. IN_REVIEW, v0.9.0, ngay 2026-08-07 va viec ton tai cua /01-curriculum/COMPETENCY_COVERAGE_MATRIX.md khong tao baseline, approval, legal sign-off, accounting sign-off hay quyen dua noi dung vao production.

Foundational BA domains: strategy, discovery, elicitation, stakeholders, process, requirements, rules, and data

Phạm vi lập kế hoạch cho nhóm năng lực Strategy

Trong ma trận, Strategy Analysis (phân tích chiến lược) được hiểu là năng lực nối bối cảnh tổ chức, vấn đề hoặc cơ hội, mục tiêu cần đạt và hướng thay đổi có thể kiểm chứng. Cách phân loại này dựa trên seed của BABOK Guide v3, vốn cho phép dùng các knowledge area, task, competency và thuật ngữ BA; không suy diễn số trang hoặc điều khoản vì nguồn được cấp chỉ xác nhận phạm vi sử dụng an toàn. Với Nova Foods, mọi mục tiêu, số liệu, quy trình và lợi ích đều là mô phỏng giáo dục, dữ liệu tổng hợp, không phải quyết định vận hành hoặc cam kết tài chính thực tế.

ID năng lực dự kiến	Phân loại	Năng lực quan sát được	Chapter Nova Foods bắt buộc liên kết	Artifact/template mapping	Worked example mapping	Quality gate	Learner capability đạt được
BA-STR-001	Core	Mô tả được bối cảnh hiện tại, vấn đề hoặc cơ hội bằng cấu trúc: hiện trạng, tác động, nhóm bị ảnh hưởng, bằng chứng và phạm vi chưa biết. Learner phải phân biệt fact (sự kiện có bằng chứng), assumption (giả định dùng tạm) và verification required (cần xác minh).	Chapter case study Nova Foods về bối cảnh tổ chức và định hướng thay đổi; tên và định danh chapter phải được lấy nguyên văn từ /01-curriculum/CHAPTER_MANIFEST.md, không tự tạo ID.	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/CHAPTER_MANIFEST.md; mẫu ghi nhận vấn đề hoặc opportunity trong TEMPLATE_MANIFEST nếu template đó được manifest đăng ký.	Tình huống mô phỏng hợp nhất dữ liệu bán hàng và sản xuất của Nova Foods; mọi con số quy đổi dùng VND tổng hợp và phải gắn nhãn Project assumption nếu chưa có nguồn xác minh.	Có thể truy ngược từng nhận định về nguồn, quan sát mô phỏng hoặc giả định; không dùng ngôn ngữ khẳng định cho dữ liệu chưa kiểm chứng.	Viết được problem statement ngắn, không nhảy ngay sang giải pháp ERP và biết chỉ ra bằng chứng còn thiếu.
BA-STR-002	Core	Chuyển bối cảnh thành mục tiêu có kết quả quan sát được: đối tượng hưởng lợi, thay đổi mong muốn, chỉ báo kết quả, thời điểm đo và giới hạn phạm vi. Learner phải giải thích vì sao một mục tiêu chỉ có giá trị khi có cách quan sát hoặc kiểm tra kết quả.	Chapter case study Nova Foods về mục tiêu kinh doanh, phạm vi sáng kiến và tiêu chí thành công; đối chiếu entry canonical trong CHAPTER_MANIFEST.	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; template mục tiêu, phạm vi và success measure được tham chiếu đúng ID từ /01-curriculum/TEMPLATE_MANIFEST.md.	Ví dụ: giảm việc nhập lặp thông tin đơn hàng trong quy trình mô phỏng; chưa được gọi là KPI thực tế, chưa gán giá trị đạt được nếu chưa có dữ liệu baseline.	Mỗi mục tiêu có chủ thể, hành vi hoặc kết quả cần thay đổi, cách đo, đơn vị đo và nhãn Project assumption hoặc Verification required khi phù hợp.	Viết được objective và success measure có thể chuyển tiếp cho các chapter yêu cầu mà không biến mục tiêu thành requirement kỹ thuật.
BA-STR-003	Core	Phân tích capability gap (khoảng cách năng lực) giữa trạng thái hiện tại và trạng thái mục tiêu ở mức nghiệp vụ; nêu nguyên nhân đã có bằng chứng, nguyên nhân cần xác minh, tác động và các hướng xử lý khả dĩ mà không mặc định phải mua hoặc cấu hình một module ERP.	Chapter case study Nova Foods về current state, target state và gap; mapping phải dùng đúng chapter entry canonical trong /01-curriculum/CHAPTER_MANIFEST.md.	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/TEMPLATE_MANIFEST.md; các artifact phân tích quy trình, yêu cầu, rule hoặc data chỉ được liên kết khi chúng đã có ID canonical trong corpus.	Gap mô phỏng: thông tin lô hàng không nhất quán giữa bán hàng và sản xuất. Đây là ví dụ học tập; phạm vi truy xuất, thu hồi và nghĩa vụ an toàn thực phẩm là Verification required với vai trò có thẩm quyền, không được tự kết luận.	Bảng gap phải tách hiện trạng, mục tiêu, bằng chứng, tác động, giả định, phụ thuộc và câu hỏi escalation; không chứa fabricated quotation hoặc fabricated clause.	So sánh được current state với target state, nhận diện khoảng trống và biết khi nào cần chuyển vấn đề sang Business Owner, Legal, Accounting, Food-safety Domain Owner hoặc Architect.
BA-STR-004	Partial có kiểm soát	Đề xuất và so sánh các hướng thay đổi theo tiêu chí lợi ích, chi phí mô phỏng, rủi ro, phụ thuộc, khả năng thực hiện và tác động stakeholder; chỉ đưa ra recommendation có điều kiện, không tuyên bố lựa chọn đã được chấp thuận.	Chapter case study Nova Foods về option analysis và định hướng giải pháp; chapter ID/tên phải giữ nguyên từ CHAPTER_MANIFEST, không thay bằng tên tự đặt trong ma trận.	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/TEMPLATE_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md để liên kết option, giả định và vấn đề cần quyết định nếu các ID tương ứng đã được đăng ký.	So sánh mô phỏng giữa chuẩn hóa dữ liệu dùng chung và bổ sung bước kiểm soát thủ công; không mô tả cấu hình ERP thực tế, không gán chi phí thật và không gọi kết quả là business approval.	Mỗi option có tiêu chí đánh giá, nguồn hoặc giả định, rủi ro, phụ thuộc, điều kiện loại trừ và người có thẩm quyền quyết định; trạng thái tài liệu vẫn IN_REVIEW, v0.9.0.	Lập được bảng lựa chọn minh bạch, nêu recommendation có điều kiện và tạo gói escalation thay vì tự quyết định thay business hoặc technical authority.

Quy tắc chất lượng và xử lý năng lực Partial

Một dòng Strategy chỉ được phân loại Core khi learner có thể tạo artifact quan sát được, giải thích cầu nối từ bằng chứng đến kết luận, và nối được kết quả với chapter cùng template canonical. Dòng BA-STR-004 giữ trạng thái Partial có kiểm soát vì việc phân tích option chưa đủ để trao thẩm quyền quyết định cho Business Owner, Architect, Accounting, Legal, Security hoặc Food-safety Domain Owner; seed chỉ cho phép dùng nguồn theo ranh giới đã nêu, không cung cấp quyết định Nova Foods cụ thể. Treatment plan gồm bốn bước: dạy khung option analysis với dữ liệu tổng hợp; bắt learner ghi rõ Project assumption và Verification required; kiểm tra bảng option bằng quality gate về traceability và thẩm quyền; sau đó chuyển các điểm chưa quyết định vào gói escalation có Artifact ID, nguồn, tác động và câu hỏi đơn nghĩa. Không được ghi approved, baselined, user-approved hoặc diễn đạt tương đương khi chưa có reference hợp lệ.

Hàng năng lực Discovery và năng lực quan sát được

Discovery là hoạt động khám phá có cấu trúc để chuyển một tín hiệu vấn đề ban đầu thành phạm vi tìm hiểu, giả định, câu hỏi, bằng chứng và quyết định cần làm rõ. Discovery khác elicitation: discovery xác định cần biết gì, từ nguồn nào và vì sao; elicitation sẽ thu thập thông tin bằng phỏng vấn, workshop, quan sát hoặc kỹ thuật cụ thể. Căn cứ phân loại là BABOK Guide Version 3 của IIBA sử dụng các khái niệm phân tích nhu cầu, bối cảnh thay đổi và quản lý thông tin BA; không suy diễn số trang hoặc điều khoản từ nguồn chỉ có thể truy cập theo giấy phép. Mọi ví dụ Nova Foods Trading & Manufacturing là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Matrix Row ID	Năng lực discovery và phân loại	Năng lực quan sát được của learner	Ánh xạ chapter Nova Foods bắt buộc	Ánh xạ artifact/template bắt buộc	Ánh xạ ví dụ thực hành tổng hợp	Quality gate trước khi đánh dấu Covered	Learner có thể thực hiện độc lập
CCM-DISC-01	Xác định tín hiệu vấn đề và ranh giới khám phá — Core	Phân biệt được triệu chứng với vấn đề cần tìm hiểu; viết được problem statement ngắn gồm tác động, đối tượng bị ảnh hưởng, ranh giới ban đầu và điều chưa biết.	Chapter có mục tiêu giải thích bối cảnh Nova Foods và khởi tạo case study, được tham chiếu bằng entry canonical trong /01-curriculum/CHAPTER_MANIFEST.md.	Tham chiếu template discovery đã đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md; liên kết định danh dùng /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Tín hiệu tổng hợp: một số đơn đặt hàng nội bộ được nhập lại từ bảng tính vào ERP mô phỏng. Learner ghi nhận đây là tín hiệu cần khám phá, không kết luận nguyên nhân là lỗi người dùng hoặc lỗi hệ thống.	Problem statement phải tách rõ: điều quan sát được, tác động giả định, phạm vi chưa xác minh và câu hỏi mở. Không được ghi một giả định thành fact Nova Foods.	Mở một discovery brief có thể review, biết dừng ở “cần xác minh” khi chưa có bằng chứng.
CCM-DISC-02	Lập giả định, câu hỏi và kế hoạch bằng chứng — Core	Chuyển vấn đề thành câu hỏi có thể kiểm chứng; ghi nguồn bằng chứng dự kiến, mức độ tin cậy, người sở hữu quyết định và tiêu chí đóng câu hỏi.	Chapter hướng dẫn discovery và case chapter liên quan luồng đặt hàng Nova Foods, theo tên và ID nguyên trạng trong CHAPTER_MANIFEST.	Discovery log và assumption log phải dùng đúng filename, Template ID và trạng thái đã đăng ký trong TEMPLATE_MANIFEST; không tự tạo tên canonical mới trong matrix.	Với tín hiệu nhập lại đơn hàng, learner lập câu hỏi: dữ liệu nào bị nhập lại, ở điểm bàn giao nào, tần suất tổng hợp là bao nhiêu, và bằng chứng nào phân biệt được trùng thao tác với yêu cầu kiểm soát hợp lệ.	Mỗi câu hỏi phải có lý do nghiệp vụ, nguồn dự kiến và điều kiện xác minh. Câu hỏi không được giả định sẵn giải pháp như “cần tích hợp API”.	Lập discovery backlog có thứ tự ưu tiên theo tác động và độ bất định, thay vì thu thập thông tin không mục tiêu.
CCM-DISC-03	Tổng hợp evidence và quản lý bất định — Core	Ghi nhận được evidence, nguồn, ngày ghi nhận, giới hạn sử dụng và kết luận tạm thời; phân loại được fact, assumption, conflict và verification required.	Chapter dạy cách chuyển discovery findings thành đầu vào phân tích trong case study Nova Foods, theo manifest canonical.	Liên kết với /01-curriculum/TRACEABILITY_ID_REGISTRY.md; nếu finding tác động thuật ngữ hoặc dữ liệu logic, chỉ tham chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md, không sửa định nghĩa canonical từ discovery note.	Evidence tổng hợp cho thấy một phiếu đặt hàng mẫu có mã mặt hàng và số lượng; evidence này chỉ chứng minh cấu trúc ví dụ, không chứng minh quy trình ERP thực tế, quyền truy cập hay cấu hình Nova Foods.	Mỗi kết luận phải truy ngược được tới evidence hoặc được gắn Project assumption hay Verification required. Conflict phải còn hiển thị, không được âm thầm chọn một phiên bản.	Tạo được findings register để Senior BA, Business Owner hoặc Architect review mà không phải suy đoán nguồn của kết luận.
CCM-DISC-04	Đề xuất hướng khám phá tiếp theo và quyết định escalation — Core	Diễn giải được tác động của bất định lên phạm vi học liệu; xác định được câu hỏi nào cần Business Owner, Architect, Legal Owner, Accounting Owner, QA hoặc Security xử lý.	Chapter chuyển discovery findings sang phân tích chi tiết của Nova Foods, theo dependency được ghi trong CHAPTER_MANIFEST.	Nếu phát hiện liên quan quy tắc nghiệp vụ, chỉ tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md; nếu liên quan dữ liệu, chỉ tham chiếu CANONICAL_DATA_DICTIONARY; không tự xác nhận rule hoặc yêu cầu pháp lý.	Learner phát hiện việc lưu mã khách hàng trong ví dụ có thể liên quan dữ liệu cá nhân. Cầu nối suy luận là mã có thể nhận diện một chủ thể khi kết hợp dữ liệu khác; vì chưa có phân loại pháp lý được xác minh, kết quả phải là Verification required và escalation đến Legal/Security Owner.	Escalation package phải nêu câu hỏi đơn nghĩa, artifact ảnh hưởng, evidence, giả định đang dùng, hậu quả nếu chưa quyết định và vai trò có thẩm quyền. Không được ghi “đã tuân thủ” hoặc “đã được phê duyệt”.	Biết quyết định phần nào có thể tiếp tục như học liệu mô phỏng và phần nào phải dừng để chờ thẩm quyền phù hợp.

Quy tắc ánh xạ bắt buộc. Mỗi hàng CCM-DISC-* phải liên kết đến một entry chapter thực có trong /01-curriculum/CHAPTER_MANIFEST.md và một template thực có trong /01-curriculum/TEMPLATE_MANIFEST.md trước khi được đánh giá Covered. Lý do là matrix chỉ đo năng lực khi learner có nơi học, artifact để thực hành và ví dụ Nova Foods tổng hợp để kiểm tra đầu ra. Trong micro-batch này không tạo Chapter ID, Template ID hoặc filename mới vì các định danh đó thuộc manifest canonical tương ứng.

Mẫu xử lý trạng thái Partial cho discovery. Ghi Partial khi hàng có giải thích khái niệm và ví dụ nhưng thiếu ít nhất một trong ba yếu tố: artifact thực hành, quality gate có thể kiểm tra, hoặc ánh xạ chapter-template canonical. Bản ghi xử lý phải có các trường: Matrix Row ID; khoảng trống; bằng chứng hiện có; ảnh hưởng đến learner; artifact cần bổ sung theo TEMPLATE_MANIFEST; chapter cần liên kết theo CHAPTER_MANIFEST; người chịu trách nhiệm chuẩn bị; vai trò review cần thiết; trạng thái IN_REVIEW; và tiêu chí chuyển sang Covered. Ví dụ, CCM-DISC-03 là Partial nếu learner chỉ đọc findings register mà chưa phân loại được fact, assumption, conflict và Verification required trên dữ liệu Nova Foods tổng hợp. Điều kiện hoàn tất là learner tạo register, truy vết từng kết luận đến evidence hoặc nhãn bất định, và quality gate xác nhận không có kết luận vượt quá evidence.

Elicitation — các hàng năng lực và năng lực quan sát được

Elicitation (khai thác thông tin) là hoạt động BA chủ động thu nhận, làm rõ và ghi nhận nhu cầu, ràng buộc, vấn đề và tiêu chí thành công từ nguồn phù hợp; đây không phải là hành động tự quyết định yêu cầu thay người có thẩm quyền. Phân loại nguồn cho toàn bộ các hàng dưới đây là Primary terminology source: BABOK Guide Version 3 của IIBA, dùng cho thuật ngữ và nhóm năng lực BA. Cầu nối suy luận là: vì đầu ra của khai thác phải có nguồn, ngữ cảnh và điểm chưa rõ để có thể kiểm tra lại, ma trận yêu cầu mỗi năng lực phải tạo evidence có thể truy vết thay vì chỉ ghi “đã họp”. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tình huống và dữ liệu nêu dưới đây là dữ liệu tổng hợp.

Năng lực elicitation	Phân loại trong ma trận	Năng lực quan sát được của learner	Ánh xạ chapter Nova Foods bắt buộc	Ánh xạ artifact/template bắt buộc	Ánh xạ ví dụ thực hành mô phỏng	Quality gate trước khi được ghi nhận là Covered	Learner capability sau học
Lập kế hoạch phiên khai thác thông tin	Core	Xác định mục tiêu phiên, câu hỏi cần trả lời, nguồn thông tin, kỹ thuật phù hợp, đầu vào cần đọc trước, đầu ra dự kiến và rủi ro hiểu sai.	Phải liên kết tới chapter trong /01-curriculum/CHAPTER_MANIFEST.md có phạm vi discovery hoặc elicitation; không tự đặt tên chapter hoặc filename ngoài manifest.	Phải liên kết template kế hoạch workshop/phỏng vấn đã đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md; bản kế hoạch phải tham chiếu đúng template ID khi manifest công bố ID.	Lập kế hoạch buổi làm rõ lý do đơn hàng bán bị giữ tại Nova Foods, với câu hỏi phân biệt giữa thiếu tồn kho, thiếu thông tin khách hàng và chờ phê duyệt nội bộ.	Mục tiêu được viết dưới dạng câu hỏi có thể trả lời; mỗi người tham gia có lý do được mời; kỹ thuật được chọn có lý do phù hợp với độ bất định; không có kết luận nghiệp vụ được viết trước phiên.	Tự chuẩn bị được một phiên elicitation ngắn, biết phân biệt điều cần hỏi với điều BA đang giả định.
Thực hiện phỏng vấn, workshop và quan sát có cấu trúc	Core	Dùng câu hỏi mở để khám phá, câu hỏi đóng để xác nhận; diễn đạt lại để kiểm tra hiểu; tách fact, opinion, assumption và decision; ghi nhận bất đồng mà không tự hòa giải bằng suy đoán.	Phải liên kết tới chapter có hướng dẫn kỹ thuật elicitation trong manifest và chapter case study chứa tình huống Nova Foods tương ứng.	Phải dùng template agenda, biên bản khai thác và nhật ký quyết định hoặc nhật ký vấn đề theo /01-curriculum/TEMPLATE_MANIFEST.md; không thay thế bằng ghi chú không nguồn.	Mô phỏng workshop giữa bộ phận Bán hàng, Kho và Kế toán về thời điểm chuyển đơn hàng sang trạng thái “sẵn sàng xuất”; số lượng đơn, mã hàng và số tiền đều là dữ liệu tổng hợp bằng VND.	Biên bản có ngày giờ theo Asia/Ho_Chi_Minh, mục tiêu, người cung cấp thông tin, câu hỏi chính, câu trả lời, điểm bất đồng và hành động tiếp theo; nội dung chưa xác minh được gắn nhãn Verification required hoặc Project assumption.	Điều phối được trao đổi cơ bản mà không biến ý kiến của một người thành yêu cầu đã xác nhận.
Phân tích và hợp nhất kết quả khai thác	Core	Chuyển ghi chú thô thành nhu cầu, vấn đề, giả định, câu hỏi mở, xung đột và evidence source; phát hiện khi hai nguồn nói khác nhau; giữ nguyên nguồn của từng kết luận.	Phải liên kết chapter về chuyển hóa discovery/elicitation thành đầu vào phân tích yêu cầu, theo mapping chính thức trong /01-curriculum/CHAPTER_MANIFEST.md.	Phải liên kết tới template tổng hợp findings, assumption log, issue log và decision log trong /01-curriculum/TEMPLATE_MANIFEST.md; traceability dùng quy ước của /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Từ hai ghi chú mô phỏng, xác định xung đột: Sales muốn cho phép sửa địa chỉ giao sau khi tạo đơn, còn Kho cần biết thời điểm khóa thông tin để chuẩn bị xuất hàng.	Mỗi finding có evidence source; assumption không bị viết như fact; xung đột có mô tả hai phía và câu hỏi cần quyết định; không tự tạo business rule Nova Foods.	Biết biến lời kể rời rạc thành đầu vào có cấu trúc cho phân tích tiếp theo và biết dừng khi thiếu thẩm quyền quyết định.
Xác nhận lại hiểu biết sau phiên khai thác	Core	Gửi bản tóm tắt trung tính, yêu cầu xác nhận về độ chính xác của nội dung đã ghi, theo dõi phản hồi và cập nhật dấu vết thay đổi; phân biệt xác nhận hiểu biết với phê duyệt requirement.	Phải liên kết chapter về review, validation hoặc traceability được xác định trong /01-curriculum/CHAPTER_MANIFEST.md; không diễn giải hoạt động xác nhận là approval.	Phải dùng template recap/xác nhận kết quả và change log trong /01-curriculum/TEMPLATE_MANIFEST.md; liên kết các thay đổi đến artifact nguồn bằng ID canonical khi đã đăng ký.	Gửi recap mô phỏng cho các vai trò Nova Foods về nguyên nhân đơn bị giữ, nêu rõ phần “đã nghe”, “cần xác minh” và “cần Business Owner quyết định”.	Recap không chứa ngôn ngữ “đã phê duyệt” khi không có approval reference; mọi thay đổi có nguồn, thời điểm và tác động; câu hỏi chưa có câu trả lời vẫn mở và được gán vai trò xử lý.	Tạo được vòng phản hồi kiểm chứng được, giảm rủi ro BA diễn giải sai nhưng không tuyên bố có phê duyệt.

Quy tắc ánh xạ bắt buộc trong ma trận: mỗi hàng Core ở trên phải có ít nhất một liên kết chapter và một liên kết template được lấy nguyên dạng từ /01-curriculum/CHAPTER_MANIFEST.md và /01-curriculum/TEMPLATE_MANIFEST.md. Cầu nối suy luận là: manifest là nguồn kiểm soát tên, đường dẫn và phạm vi artifact; vì compact dependency chưa cung cấp các entry chapter/template cụ thể, việc tự tạo filename, chapter number hoặc template ID sẽ làm hỏng traceability. Khi các manifest công bố mapping cụ thể, ma trận chỉ được điền bằng định danh canonical đó và vẫn giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Hàng năng lực phân tích và quản trị bên liên quan

Bên liên quan (stakeholder) là cá nhân, nhóm hoặc vai trò có thể ảnh hưởng, bị ảnh hưởng, hoặc nắm tri thức cần thiết cho thay đổi. Phân tích bên liên quan xác định ai cần tham gia, ảnh hưởng gì và cần bằng chứng nào; quản trị bên liên quan lập kế hoạch, thực hiện và theo dõi việc tham gia đó. Hai năng lực được xếp Core vì yêu cầu Nova Foods Trading & Manufacturing là mô phỏng ERP có nhiều vai trò nghiệp vụ; suy luận này dựa trên phạm vi case study đa chức năng và thuật ngữ, năng lực BA từ BABOK Guide Version 3. Mọi tên vai trò, tình huống và dữ liệu dưới đây là tổng hợp, chỉ phục vụ học tập.

Matrix Row ID	Năng lực và khả năng quan sát được	Phân loại	Ánh xạ chapter Nova Foods bắt buộc	Ánh xạ artifact/template bắt buộc	Ánh xạ ví dụ thực hành tổng hợp	Quality gate trước khi chuyển bước	Năng lực đầu ra của learner
CCM-STA-01	Nhận diện và phân đoạn bên liên quan. Learner liệt kê vai trò, đơn vị, mục tiêu, quyền quyết định, tri thức miền nghiệp vụ, mức ảnh hưởng và mức bị ảnh hưởng; phân biệt người cung cấp thông tin với người ra quyết định.	Core	Phải liên kết đến chapter trong /01-curriculum/CHAPTER_MANIFEST.md có phạm vi discovery, elicitation hoặc stakeholder; không tự đặt tên hay mã chapter ngoài manifest.	Phải chọn template đã đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md cho stakeholder register hoặc stakeholder map; liên kết quản trị dùng TRACEABILITY_ID_REGISTRY.	ERP mô phỏng cần thay đổi cách xử lý yêu cầu mua nguyên liệu. Learner nhận diện tối thiểu các vai trò: Purchasing, Warehouse, Production Planning, Quality, Accounting và IT Support; không gán quyền phê duyệt thực tế cho bất kỳ vai trò nào.	Mỗi vai trò phải có ít nhất một lý do tham gia gắn với quyết định, thông tin hoặc tác động. Nếu một vai trò vừa sở hữu quy tắc vừa chịu tác động nhưng chưa rõ thẩm quyền, ghi Verification required và escalation đến Business Owner.	Tạo được danh sách bên liên quan có căn cứ, không bỏ sót vai trò ảnh hưởng cao chỉ vì không trực tiếp sử dụng màn hình ERP.
CCM-STA-02	Đánh giá ảnh hưởng, mức quan tâm và rủi ro tham gia. Learner dùng tiêu chí nhất quán để xếp mức ảnh hưởng, mức quan tâm, mức sẵn sàng thay đổi, rủi ro xung đột và phương thức tương tác phù hợp.	Core	Phải liên kết đến chapter trong CHAPTER_MANIFEST hướng dẫn lập kế hoạch discovery hoặc quản trị stakeholder.	Stakeholder map, engagement assessment và decision log phải dùng template đã đăng ký trong TEMPLATE_MANIFEST; không tạo bản sao làm nguồn chân lý thứ hai.	Quality có ảnh hưởng cao vì cung cấp tiêu chí kiểm soát lô nguyên liệu mô phỏng, nhưng lịch tham gia hạn chế. Learner xếp vai trò này là ưu tiên tham vấn sớm, nêu lý do là thiếu đầu vào sẽ làm yêu cầu không kiểm chứng được.	Mỗi mức xếp hạng phải có evidence/reasoning bridge: quan sát hoặc giả định tổng hợp → tác động đến phạm vi/quyết định → cách tham gia. Không chấp nhận nhãn “quan trọng” không có lý do.	Ưu tiên đúng người, đúng thời điểm; nhận diện rủi ro chậm phản hồi hoặc xung đột mục tiêu trước khi tổ chức phiên elicitation.
CCM-STA-03	Lập kế hoạch tham gia và truyền thông. Learner xác định mục tiêu từng phiên, người chủ trì, người tham gia, đầu vào, kỹ thuật elicitation, đầu ra, thời hạn phản hồi và đường escalation.	Core	Phải liên kết đến chapter trong CHAPTER_MANIFEST có nội dung elicitation, stakeholder hoặc quản trị quyết định.	Kế hoạch workshop/interview, communication plan, action log và decision log phải tham chiếu template tương ứng trong TEMPLATE_MANIFEST.	Với workshop mô phỏng về yêu cầu mua hàng, Purchasing cung cấp luồng ngoại lệ; Warehouse xác nhận điểm nhận hàng; Accounting chỉ được mời để nêu nhu cầu thông tin chứng từ, không được suy diễn thành xác nhận diễn giải pháp luật hoặc kế toán.	Kế hoạch phải chỉ rõ câu hỏi cần trả lời, đầu ra dự kiến và owner hành động. Nếu câu hỏi liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc tuân thủ, phải gắn nguồn chính thức phù hợp hoặc Verification required, đồng thời chỉ định vai trò escalation có thẩm quyền.	Điều phối được hoạt động tham gia có mục tiêu, tránh họp rộng nhưng không tạo được quyết định hay bằng chứng.
CCM-STA-04	Quản lý bất đồng, phản hồi và quyết định. Learner ghi nhận quan điểm khác nhau, tách sự kiện khỏi ý kiến, truy nguyên ảnh hưởng tới artifact, đề xuất lựa chọn và chuyển đúng người có thẩm quyền quyết định.	Core	Phải liên kết đến chapter trong CHAPTER_MANIFEST có phạm vi requirements governance, stakeholder management hoặc traceability.	Decision log, issue log và liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi bất đồng ảnh hưởng quy tắc hoặc dữ liệu; ID phải đối chiếu TRACEABILITY_ID_REGISTRY.	Purchasing muốn cho phép sửa số lượng sau khi gửi yêu cầu; Warehouse lo ngại lệch kế hoạch nhận hàng. Learner ghi hai quan điểm, tác động giả định, câu hỏi quyết định và người cần quyết định; không tự viết quy tắc ERP cuối cùng.	Không được đóng issue khi chỉ có ý kiến của BA hoặc khi thiếu người có thẩm quyền. Mỗi quyết định phải nêu trạng thái, bằng chứng, artifact bị ảnh hưởng và điều kiện mở lại; tại IN_REVIEW, không gọi là approved hoặc baselined.	Biến xung đột thành vấn đề có thể quyết định, giữ được lịch sử lý do và không vượt thẩm quyền.
CCM-STA-05	Theo dõi mức tham gia và điều chỉnh chiến lược. Learner so sánh kế hoạch với thực tế, ghi nhận phản hồi thiếu, thay đổi vai trò hoặc rủi ro mới; sau đó cập nhật kế hoạch tham gia và traceability bị ảnh hưởng.	Core	Phải liên kết đến chapter trong CHAPTER_MANIFEST có phạm vi quản trị stakeholder, thay đổi hoặc traceability.	Engagement tracker, action log, issue log và change record dùng template đã đăng ký trong TEMPLATE_MANIFEST; liên kết thay đổi giữ nguyên ID canonical trong registry.	Vai trò Quality không thể dự workshop mô phỏng. Learner ghi rủi ro thiếu tiêu chí kiểm soát, chuyển sang phỏng vấn có cấu trúc, xác định đầu vào cần review và giữ nhãn giả định cho phần chưa được xác minh.	Có bằng chứng cho từng thay đổi: sự kiện tham gia → rủi ro/ảnh hưởng → hành động thay thế → artifact cần cập nhật. Nếu không có cách thu thập đầu vào tối thiểu, dừng chuyển yêu cầu liên quan sang bước tiếp theo.	Duy trì sự tham gia có kiểm soát trong thay đổi, không coi danh sách stakeholder ban đầu là bất biến.

Quy tắc ánh xạ bắt buộc: mỗi hàng CCM-STA-* phải có liên kết hai chiều đến một chapter được đăng ký trong /01-curriculum/CHAPTER_MANIFEST.md và một template được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md. Cầu nối suy luận là: chapter dạy kỹ năng, template tạo bằng chứng thực hành, còn TRACEABILITY_ID_REGISTRY kiểm soát định danh liên kết; thiếu một trong ba thành phần thì không chứng minh được learner vừa hiểu vừa thực hiện được năng lực.

Khuôn xử lý Partial: khi một hàng chỉ có chapter nhưng chưa có template, hoặc có template nhưng ví dụ chưa kiểm tra được quality gate, ghi phân loại Partial và lập bản ghi gồm Matrix Row ID, phần bao phủ hiện có, bằng chứng thiếu, artifact bị ảnh hưởng, rủi ro học tập, hành động bổ sung, vai trò escalation và tiêu chí hoàn tất. Không nâng Partial thành Core chỉ dựa trên sự hiện diện của thuật ngữ stakeholder; chỉ cập nhật sau khi chapter, template, ví dụ tổng hợp và quality gate liên kết đầy đủ trong trạng thái kiểm soát IN_REVIEW, version v0.9.0.

Các dòng năng lực phân tích và mô hình hóa quy trình trong ma trận

Phạm vi này lập các dòng năng lực cho process analysis/modelling (phân tích và mô hình hóa quy trình): người học phải chuyển được thông tin về công việc, vai trò, sự kiện, quyết định, đầu vào và đầu ra thành mô hình có thể đọc, kiểm tra và truy vết. Nova Foods Trading & Manufacturing chỉ là case study mô phỏng giáo dục, sử dụng dữ liệu tổng hợp trong bối cảnh vi-VN, VND, Asia/Ho_Chi_Minh; các mô hình dưới đây không được diễn giải là quy trình ERP đang vận hành.

ID dòng năng lực dự kiến	Năng lực và khả năng quan sát được	Phân loại	Ánh xạ chapter trong Nova Foods	Ánh xạ artifact/template	Ánh xạ worked example	Quality gate	Năng lực đầu ra của learner
PCM-01	Xác định scope và boundary (phạm vi và ranh giới) của quy trình bằng trigger, điểm bắt đầu, điểm kết thúc, actor, hệ thống liên quan, đầu vào và đầu ra. Learner phải phân biệt “quy trình cần phân tích” với các quy trình liên quan nhưng nằm ngoài phạm vi.	Core	Gắn vào chapter trong /01-curriculum/CHAPTER_MANIFEST.md có nội dung process analysis của case study Nova Foods; không tự tạo chapter ID ngoài manifest.	Bản ghi process scope và process inventory theo template entry tương ứng trong /01-curriculum/TEMPLATE_MANIFEST.md.	Quy trình mô phỏng từ nhu cầu bổ sung nguyên liệu đến ghi nhận tiếp nhận tại kho; dữ liệu và vai trò chỉ là synthetic data.	Có đủ start event, end event, in-scope, out-of-scope, actor, input, output và assumption; mọi ranh giới chưa có bằng chứng phải gắn Verification required.	Learner viết được một process scope ngắn, không lẫn mục tiêu quy trình với giải pháp phần mềm và không mở rộng phạm vi chỉ vì thấy một bước có liên quan.
PCM-02	Phân rã quy trình theo level of detail (mức độ chi tiết): process, subprocess, activity, task; nhận diện happy path (luồng chính), alternative path (luồng thay thế) và exception path (luồng ngoại lệ).	Core	Gắn vào chapter process analysis của Nova Foods trong /01-curriculum/CHAPTER_MANIFEST.md, với liên kết ngược đến scope của PCM-01.	Process hierarchy, SIPOC hoặc process inventory nếu các template này được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md; không gọi tên template chưa có trong manifest là canonical.	Ví dụ mô phỏng: tiếp nhận nguyên liệu có nhánh “đủ số lượng”, “thiếu số lượng” và “phát hiện sai mã hàng”; không suy diễn đây là cấu hình ERP thực tế.	Mỗi activity có một hành động và một kết quả kiểm tra được; không trộn nhiều cấp độ vào cùng một sơ đồ; các nhánh phải có điều kiện hoặc lý do tồn tại.	Learner biết chọn mức chi tiết phù hợp với câu hỏi phân tích, tránh sơ đồ quá tổng quát không dùng được hoặc quá chi tiết không còn phục vụ quyết định.
PCM-03	Mô hình hóa luồng, trách nhiệm và điểm bàn giao bằng ký pháp phù hợp. BPMN được dùng khi cần ngữ nghĩa sự kiện, task, gateway, pool/lane; UML activity diagram chỉ dùng theo ngữ nghĩa UML. PlantUML là công cụ biểu diễn, không biến activity diagram thành BPMN.	Core	Chapter process modelling của Nova Foods theo entry chính thức trong /01-curriculum/CHAPTER_MANIFEST.md.	Process model và notation legend theo template entry tương ứng trong /01-curriculum/TEMPLATE_MANIFEST.md; nguồn ký pháp BPMN là OMG BPMN 2.0.2 và nguồn UML là OMG UML 2.5.1.	Sơ đồ mô phỏng các lane “Mua hàng”, “Kho” và “Kế toán” cho luồng tiếp nhận; lane chỉ mô tả trách nhiệm minh họa, không xác nhận cơ cấu tổ chức thật.	Mỗi sequence flow có hướng rõ; gateway có điều kiện; message flow không bị dùng thay sequence flow; actor hoặc lane chịu trách nhiệm cho từng task; notation legend khớp ký pháp đã chọn.	Learner tạo được sơ đồ đọc được bởi BA, business reader và delivery team, đồng thời giải thích được vì sao chọn BPMN hoặc UML thay vì gắn nhãn sai.
PCM-04	Phân tích as-is/to-be (hiện trạng/tương lai), nhận diện pain point, waste, delay, rework, control point và cơ hội cải tiến mà không nhảy thẳng vào giải pháp. Mỗi nhận định phải có evidence hoặc được ghi là assumption.	Core	Chapter process analysis của Nova Foods trong /01-curriculum/CHAPTER_MANIFEST.md, liên kết tới worked example mô phỏng cùng quy trình.	As-is/to-be comparison, issue log hoặc improvement candidate theo template đã đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md.	So sánh mô phỏng giữa việc đối chiếu phiếu nhận hàng thủ công và luồng có bước kiểm tra mã nguyên liệu; không khẳng định hiệu quả, chi phí hoặc thời gian thực tế.	Mỗi pain point có bước quy trình, tác động, evidence source, owner cần xác minh và trạng thái; to-be không được trình bày như requirement đã được chấp thuận.	Learner phân biệt được vấn đề quy trình, nguyên nhân giả định và ý tưởng giải pháp; biết đặt câu hỏi kiểm chứng trước khi đề xuất thay đổi.
PCM-05	Kiểm tra tính đầy đủ và nhất quán của mô hình: start/end, nhánh quyết định, loop, handoff, exception, dữ liệu vào/ra và liên kết giữa các sơ đồ; phát hiện dead end, bước không có owner và nhánh không có điều kiện.	Core	Chapter process quality hoặc process modelling trong /01-curriculum/CHAPTER_MANIFEST.md, theo đúng chapter entry canonical.	Process review checklist và traceability reference tới các artifact liên quan trong /01-curriculum/TEMPLATE_MANIFEST.md; không dùng review checklist để tạo approval.	Worked example mô phỏng thực hiện walkthrough sơ đồ tiếp nhận nguyên liệu bằng synthetic data và ghi defect trong review log.	Sơ đồ phải qua static review theo checklist; mọi defect có ID truy vết, vị trí, mức độ, evidence và cách xử lý; IN_REVIEW của corpus không được gọi là approval hay baseline.	Learner tự review được một mô hình quy trình, ghi nhận defect có căn cứ và biết khi nào phải escalation thay vì tự sửa bằng phỏng đoán.

Quy tắc phân loại và xử lý Partial: một dòng chỉ được gắn Core khi chapter, artifact, worked example và quality gate đều cung cấp bằng chứng để quan sát năng lực; nếu rubric của section 2 phân loại một năng lực process là Partial, ma trận phải ghi nguyên nhân thiếu, phần năng lực đã bao phủ, chapter hoặc template còn thiếu, rủi ro đối với learner capability và hành động bổ sung cụ thể. Trong thời gian chưa đủ bằng chứng, trạng thái phải giữ Partial — Verification required, không chuyển thành Core bằng suy luận từ tên chapter hoặc sự tồn tại của sơ đồ.

Cầu nối nguồn và ranh giới: BPMN 2.0.2 của OMG là nguồn chuẩn cho ký pháp BPMN; UML 2.5.1 của OMG là nguồn chuẩn cho ngữ nghĩa UML. Vì các nguồn này quy định notation và semantics chứ không chứng minh quy trình Nova Foods, mọi bước, actor, thời gian, kiểm soát hoặc nhánh nghiệp vụ trong worked example chỉ là dữ liệu tổng hợp và giả định học tập. /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md và các artifact được chúng đăng ký là điểm truy vết canonical; tại Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, không có nội dung nào được gọi là đã baseline, đã phê duyệt hoặc được người dùng chấp thuận.

Hàng năng lực phân tích và đặc tả yêu cầu

Phân tích yêu cầu là hoạt động biến nhu cầu, vấn đề và kết quả mong muốn thành các phát biểu có thể hiểu, kiểm tra và truy vết; đặc tả yêu cầu là ghi các phát biểu đó trong cấu trúc đủ rõ để đội triển khai và kiểm thử không phải tự suy đoán. Lý do xếp đây là năng lực Core là vì một yêu cầu không rõ nguồn, phạm vi, điều kiện và tiêu chí chấp nhận sẽ không tạo được test basis (cơ sở kiểm thử) đáng tin cậy. Thuật ngữ và phạm vi kỹ năng tham chiếu BABOK Guide Version 3; nguyên tắc chất lượng đặc tả tham chiếu mô tả công khai của ISO/IEC/IEEE 29148:2018. Không suy diễn điều khoản chi tiết từ văn bản có giấy phép.

Hàng năng lực trong ma trận	Phân loại	Năng lực có thể quan sát	Ánh xạ chapter Nova Foods bắt buộc	Ánh xạ artifact/template bắt buộc	Ánh xạ ví dụ thực hành mô phỏng	Quality gate (cổng chất lượng)	Năng lực đầu ra của learner
Phân rã nhu cầu thành yêu cầu	Core	Tách được mục tiêu, phạm vi, actor, kích hoạt, đầu ra và ngoại lệ; phân biệt “cần đạt kết quả gì” với “giải pháp sẽ xây thế nào”.	Phải liên kết các chapter case study Nova Foods được CHAPTER_MANIFEST phân loại cho nhu cầu, phạm vi và yêu cầu; không tự đặt tên hoặc số chapter ngoài manifest.	Requirement record phải liên kết TRACEABILITY_ID_REGISTRY; thuật ngữ dữ liệu chỉ được tham chiếu từ CANONICAL_DATA_DICTIONARY.	Nhu cầu mô phỏng: giảm việc nhập lại thông tin đơn đặt hàng đại lý. Learner viết yêu cầu về kết quả ghi nhận đơn, không mặc định giao diện, API hoặc cấu hình ERP.	Mỗi requirement có nguồn, mục tiêu liên quan, actor hoặc hệ thống chịu tác động, phạm vi và trạng thái giả định/xác minh. Nếu thiếu một trường, không chuyển sang đặc tả chi tiết.	Viết được requirement độc lập với giải pháp và chỉ ra thông tin còn thiếu.
Đặc tả yêu cầu chức năng	Core	Viết được hành vi hệ thống dưới dạng điều kiện đầu vào, xử lý mong đợi, kết quả đầu ra, luồng chính và ngoại lệ; dùng thuật ngữ nhất quán.	Phải liên kết chapter Nova Foods về yêu cầu chức năng theo CHAPTER_MANIFEST và chapter case study có tình huống đơn hàng mô phỏng.	Bản đặc tả phải dùng ID đã đăng ký trong TRACEABILITY_ID_REGISTRY; quy tắc được dẫn chiếu, không sao chép, từ CANONICAL_BUSINESS_RULES.	Với đơn hàng đại lý mô phỏng NF-SO-00021, requirement nêu hệ thống ghi nhận đơn khi trường bắt buộc hợp lệ; giá, hạn mức và điều kiện duyệt chỉ là tham chiếu rule, không được tự khẳng định là quy định vận hành.	Câu requirement dùng một chủ thể, một hành vi chính, điều kiện rõ và kết quả quan sát được; không dùng từ mơ hồ như “nhanh”, “thân thiện”, “phù hợp” nếu không có tiêu chí đo hoặc nguồn xác minh.	Soạn được requirement chức năng có thể bàn giao cho thiết kế và kiểm thử mà không làm thay quyết định kiến trúc.
Xác định tiêu chí chấp nhận	Core	Chuyển requirement thành acceptance criteria (tiêu chí chấp nhận): điều kiện có thể quan sát để đánh giá requirement đã được đáp ứng hay chưa.	Phải liên kết chapter Nova Foods về yêu cầu và chuyển giao test basis theo CHAPTER_MANIFEST; không biến chapter testing thành nguồn sở hữu requirement.	Tiêu chí chấp nhận liên kết requirement ID trong TRACEABILITY_ID_REGISTRY; rule ID và data term ID phải giữ nguyên canonical ID từ artifact nguồn.	Cho NF-SO-00021, learner lập tiêu chí: khi người dùng nhập mã đại lý hợp lệ và dòng hàng hợp lệ theo rule được dẫn chiếu, hệ thống lưu đơn với mã đơn duy nhất; trường hợp không hợp lệ phải có kết quả xử lý được mô tả.	Mỗi tiêu chí phải có tiền điều kiện, dữ liệu mô phỏng, hành động hoặc sự kiện, kết quả mong đợi và liên kết requirement; kết quả phải kiểm tra được bằng quan sát, không dựa vào suy đoán ý định.	Viết được tiêu chí chấp nhận làm đầu vào kiểm thử mà không tự tạo business rule mới.
Phân tích mâu thuẫn, khoảng trống và giả định yêu cầu	Core	Phát hiện requirement trùng, xung đột, thiếu actor, thiếu ngoại lệ, thiếu nguồn hoặc vượt thẩm quyền; ghi rõ giả định thay vì che giấu khoảng trống.	Phải rà soát liên kết chéo với mọi chapter Nova Foods liên quan được manifest chỉ định; chapter mapping là bằng chứng phạm vi, không là xác nhận nội dung đã được phê duyệt.	Ghi xung đột và quyết định cần xác minh trong artifact truy vết có ID từ TRACEABILITY_ID_REGISTRY; đối chiếu rule với CANONICAL_BUSINESS_RULES và thuật ngữ với CANONICAL_DATA_DICTIONARY.	Nếu yêu cầu nói “tự động chấp nhận mọi đơn hàng” nhưng rule được dẫn chiếu có điều kiện chưa xác minh, learner ghi xung đột, tác động và vai trò cần quyết định; không tự chọn cách xử lý.	Không còn mâu thuẫn chưa gắn nhãn; mọi giả định nêu rõ nguồn thiếu, tác động và owner cần xác minh. Nội dung liên quan pháp lý, kế toán, thuế, an toàn thực phẩm hoặc dữ liệu cá nhân phải mang nhãn Verification required.	Biết dừng suy diễn, tạo gói câu hỏi đơn nghĩa và giữ được ranh giới thẩm quyền BA.
Truy vết và quản lý thay đổi requirement	Core	Thiết lập liên kết từ nhu cầu đến requirement, tiêu chí chấp nhận, rule và thuật ngữ dữ liệu; đánh giá tác động khi một requirement thay đổi.	Phải dùng chapter mapping canonical trong CHAPTER_MANIFEST để xác định nơi học và nơi áp dụng; không dùng mapping để tuyên bố baseline hoặc approval.	Liên kết bắt buộc: TRACEABILITY_ID_REGISTRY → requirement ID; CANONICAL_BUSINESS_RULES → rule ID; CANONICAL_DATA_DICTIONARY → data term ID.	Khi thay đổi mô tả đơn hàng mô phỏng, learner lập danh sách requirement, acceptance criteria, rule reference và data term bị tác động trước khi đề xuất cập nhật.	Mỗi liên kết có chiều truy vết, trạng thái IN_REVIEW, phiên bản v0.9.0 và ngày 2026-08-07; không ghi “đã phê duyệt”, “đã baseline” hoặc “sẵn sàng production”.	Đánh giá được tác động thay đổi theo bằng chứng artifact thay vì chỉ sửa một đoạn đặc tả.

Áp dụng bắt buộc cho tất cả các hàng trên: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ ngữ cảnh VND. Mapping chapter và template chỉ có hiệu lực khi giữ nguyên filename, Artifact ID, trạng thái IN_REVIEW và version v0.9.0 của nguồn canonical; sự tồn tại của mapping không chứng minh requirement đúng cho vận hành thực tế, không tạo baseline và không thể hiện user approval.

3.x Business rules competency rows

Business rules (quy tắc nghiệp vụ) là lớp quyết định “nếu điều kiện nào xảy ra thì hệ thống hoặc con người phải làm gì”, nên khi xây matrix, tôi tách năng lực này theo mức từ nhận diện đến chuẩn hóa và kiểm soát thay đổi. Lý do là một BA mới vào nghề thường thấy câu chữ rời rạc trong tài liệu, còn BA mạnh phải biến được câu chữ đó thành quy tắc có thể truy vết, kiểm tra, và dùng làm đầu vào cho requirements, test, và data. Trong corpus Nova Foods mô phỏng, mọi ví dụ dưới đây chỉ dùng dữ liệu tổng hợp; nếu quy tắc có nguồn từ luật, kế toán, hóa đơn, bảo vệ dữ liệu cá nhân, an toàn thực phẩm hoặc kiểm soát nội bộ, thì phải gắn nhãn Verification required cho đến khi vai trò có thẩm quyền xác minh.

Mã row	Năng lực business rules	Classification	Chapter mapping trong Nova Foods	Artifact mapping	Worked example mapping	Quality gate	Learner capability	Treatment plan nếu Partial
BR-01	Nhận diện quy tắc nghiệp vụ từ narrative, quy trình, biểu mẫu, màn hình, báo cáo	Full	Các chapter Nova Foods có nghiệp vụ phát sinh quyết định như bán hàng, mua hàng, kho, kế toán, truy xuất, phê duyệt trong CHAPTER_MANIFEST	CANONICAL_BUSINESS_RULES.md, CHAPTER_MANIFEST.md	Từ câu mô tả tổng hợp “đơn hàng vượt ngưỡng thì cần phê duyệt” tách thành điều kiện, chủ thể quyết định, hành động	Có thể chỉ ra nguồn rule, phạm vi áp dụng, và lý do rule đó tồn tại	Người học biết nhìn thấy rule ẩn trong tài liệu không cấu trúc	Không áp dụng
BR-02	Chuẩn hóa rule thành câu phát biểu kiểm tra được, có ID, trạng thái, nguồn, ngoại lệ	Partial	Chapter Nova Foods về yêu cầu và template nghiệp vụ nơi rule được ghi nhận lần đầu	CANONICAL_BUSINESS_RULES.md, TEMPLATE_MANIFEST.md	Viết rule tổng hợp thành mẫu: “Khi X, hệ thống phải Y, trừ khi Z” nhưng chưa được legal/owner xác minh	Rule phải có một nghĩa duy nhất, không nhập nhằng điều kiện hoặc ngoại lệ	Người học có thể viết lại rule rõ hơn, nhưng chưa được tự xác nhận đúng về vận hành	Giữ trạng thái Partial, ghi rõ thiếu thẩm quyền xác minh hoặc thiếu nguồn chuẩn; chuyển sang escalation thay vì nâng thành Full
BR-03	Phát hiện xung đột, trùng lặp, hoặc phụ thuộc giữa các rule	Full	Chapter Nova Foods có nhiều rule chồng lấp giữa bán hàng, tồn kho, hóa đơn, truy xuất	CANONICAL_BUSINESS_RULES.md, TRACEABILITY_ID_REGISTRY.md, CANONICAL_DATA_DICTIONARY.md	Hai rule tổng hợp cùng điều chỉnh mức phê duyệt nhưng khác ngưỡng; BA phải nhận ra mâu thuẫn và gom thành vấn đề	Không để hai rule trái nhau cùng tồn tại mà không gắn nhãn xung đột	Người học biết so sánh rule theo điều kiện, chủ thể, thời điểm hiệu lực, và đối tượng áp dụng	Không áp dụng
BR-04	Gắn rule vào requirement, acceptance criteria, và test basis	Partial	Chapter Nova Foods có template yêu cầu và template kiểm thử liên quan đến rule	CANONICAL_BUSINESS_RULES.md, TEMPLATE_MANIFEST.md, TRACEABILITY_ID_REGISTRY.md	Từ rule tổng hợp “hóa đơn phải khớp đơn hàng” tạo acceptance criteria và điều kiện kiểm thử, nhưng chỉ khi nguồn đã xác minh	Rule phải đủ rõ để chuyển thành testable statement, không được dừng ở diễn giải cảm tính	Người học hiểu vì sao rule phải kiểm thử được chứ không chỉ “nghe hợp lý”	Giữ Partial nếu chưa có liên kết truy vết tới requirement hoặc chưa có chủ thể xác nhận; bổ sung evidence trước khi dùng làm test basis
BR-05	Quản lý vòng đời rule và thay đổi rule	Partial	Chapter Nova Foods có tình huống thay đổi do quy trình, biểu mẫu, hoặc chính sách nội bộ	CANONICAL_BUSINESS_RULES.md, CHAPTER_MANIFEST.md, TEMPLATE_MANIFEST.md	Một rule tổng hợp ban đầu chỉ là giả định học liệu; khi có xác minh mới được chuyển sang trạng thái kiểm soát phù hợp	Mọi thay đổi phải có nguồn, người ghi nhận, thời điểm, và lý do thay đổi	Người học hiểu rule không bất biến; rule có version và history	Partial phải giữ nguyên cho đến khi có owner hợp lệ và lịch sử thay đổi rõ; không được tự đóng trạng thái bằng suy đoán

Nguyên tắc xử lý Partial trong năng lực business rules là: chưa đủ nguồn, chưa đủ thẩm quyền, hoặc chưa đủ truy vết thì giữ nguyên Partial, không “nâng cấp bằng niềm tin”. Cầu nối suy luận phải đi theo chuỗi: mô tả nghiệp vụ → tách rule → chuẩn hóa câu rule → gắn ID/trạng thái → đối chiếu chapter Nova Foods và template tương ứng → xác minh bởi vai trò có thẩm quyền nếu rule liên quan luật, kế toán, dữ liệu cá nhân, an toàn thực phẩm, hoặc kiểm soát vận hành. Với Nova Foods mô phỏng và dữ liệu tổng hợp בלבד, mục tiêu của hàng business rules trong matrix là giúp learner biết nhận ra, viết lại, kiểm tra xung đột, và trace được rule; không phải tự xác nhận rule đó là đúng cho production.

3.x Ma trận năng lực phân tích dữ liệu và mô hình dữ liệu logic

Phân tích dữ liệu là năng lực xác định dữ liệu nghiệp vụ cần được thu thập, sử dụng, kiểm soát và đối chiếu để một quy trình có thể vận hành; mô hình dữ liệu logic là năng lực biểu diễn các thực thể nghiệp vụ, thuộc tính, định danh và quan hệ của chúng độc lập với cấu hình cơ sở dữ liệu hoặc ERP. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi mã, tên và giá trị minh họa trong các bài làm chỉ dùng dữ liệu tổng hợp, tiền tệ VND, locale vi-VN.

Năng lực cần có trong ma trận	Phân loại hiện tại	Năng lực quan sát được của learner	Ánh xạ chapter bắt buộc	Ánh xạ artifact/template bắt buộc	Ánh xạ ví dụ thực hành Nova Foods mô phỏng	Quality gate trước khi ghi nhận coverage	Năng lực đầu ra
Phân tích dữ liệu nghiệp vụ	Partial	Phân biệt dữ liệu đầu vào, dữ liệu được tạo, dữ liệu tham chiếu và dữ liệu đầu ra của một luồng nghiệp vụ; xác định chủ sở hữu nghiệp vụ, nguồn tạo, mục đích sử dụng, mức bắt buộc và rủi ro chất lượng của từng trường dữ liệu.	Phải liên kết đến entry chapter trong /01-curriculum/CHAPTER_MANIFEST.md có kết quả học tập về khám phá dữ liệu, yêu cầu dữ liệu hoặc phân tích nghiệp vụ. Không được tự đặt mã chapter khi manifest chưa công bố mã phù hợp.	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; template tương ứng phải được tham chiếu bằng ID và đường dẫn đã đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md.	Learner lập data inventory tổng hợp cho tình huống “ghi nhận đơn bán hàng mô phỏng”: SalesOrder, SalesOrderLine, Customer, Product, Warehouse; nêu rõ SalesOrderID là định danh nghiệp vụ mô phỏng, OrderDate là ngày phát sinh, CustomerID liên kết khách hàng, UnitPriceVND là giá trị tiền tệ mô phỏng.	Mỗi trường phải có định nghĩa nghiệp vụ đơn nghĩa, nguồn tạo được nêu, kiểu hoặc dạng giá trị logic, mức bắt buộc và bằng chứng liên kết tới quy trình hoặc requirement. Không được biến giả định về thuế, kế toán, dữ liệu cá nhân hoặc truy xuất thực phẩm thành quy tắc bắt buộc.	Tự tạo được inventory dữ liệu đủ để phát hiện thiếu trường, trùng nghĩa, dữ liệu không có chủ sở hữu hoặc dữ liệu không có mục đích sử dụng.
Mô hình dữ liệu logic	Partial	Tách thực thể khỏi thuộc tính; chọn định danh logic; mô tả quan hệ một-một, một-nhiều hoặc nhiều-nhiều; phát hiện thực thể trung gian; kiểm tra tính nhất quán giữa mô hình, từ điển dữ liệu và ví dụ nghiệp vụ.	Phải liên kết đến entry chapter trong /01-curriculum/CHAPTER_MANIFEST.md có kết quả học tập về mô hình hóa dữ liệu logic hoặc đặc tả dữ liệu. Việc dùng UML chỉ được mô tả là tham chiếu ngữ nghĩa từ OMG UML 2.5.1 khi chapter thực sự sử dụng ký pháp đó.	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; sơ đồ logic và data dictionary phải dùng template đã được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md, không dùng tệp cá nhân làm nguồn chân lý.	Learner dựng mô hình logic tổng hợp trong đó một SalesOrder có nhiều SalesOrderLine; mỗi dòng tham chiếu một Product; một Customer có thể có nhiều SalesOrder. Nếu một đơn có thể liên quan nhiều kho và một kho phục vụ nhiều đơn, learner phải nêu nhu cầu thực thể liên kết thay vì gắn lặp danh sách kho vào một thuộc tính.	Mọi thực thể có định danh logic; mọi quan hệ có lực lượng tham gia được giải thích bằng tình huống nghiệp vụ; thuộc tính đa trị, thuộc tính tính toán và dữ liệu lặp phải được xử lý có chủ đích; tên trường trong sơ đồ khớp định nghĩa trong từ điển dữ liệu.	Chuyển được câu chuyện nghiệp vụ thành mô hình dữ liệu logic có thể review bởi Business Owner và Architect mà không tự quyết định cấu trúc vật lý, khóa kỹ thuật, index hoặc cấu hình ERP.

Cầu nối bằng chứng và lý do phân loại: hai năng lực được đánh dấu Partial vì /01-curriculum/CANONICAL_DATA_DICTIONARY.md đang là kế hoạch ở trạng thái IN_REVIEW, phiên bản v0.9.0, và nguồn dependency được cung cấp không xác nhận chapter entry hoặc template ID đã hoàn tất coverage cho từng năng lực. Suy luận này không đánh giá năng lực là đã hoàn thành: artifact dữ liệu canonical tồn tại như kế hoạch quản trị cho phép xác định điểm neo traceability, nhưng không là bằng chứng baseline, approval, cấu hình ERP hay xác nhận vận hành.

Trường xử lý bắt buộc cho Partial	Cách ghi nhận áp dụng cho hai hàng trên
Khoảng trống coverage	Chapter entry, template ID, bài tập được chấm và tiêu chí đánh giá chưa có bằng chứng canonical đầy đủ trong dependency được cung cấp.
Bằng chứng cần bổ sung	Liên kết chapter ID đã được công bố trong CHAPTER_MANIFEST; ID template và đường dẫn đã đăng ký trong TEMPLATE_MANIFEST; bài làm dùng dữ liệu Nova Foods tổng hợp; kết quả review ghi rõ lỗi phát hiện và cách sửa.
Tiêu chí chuyển trạng thái	Chỉ chuyển khỏi Partial khi một learner có thể hoàn thành cả data inventory và mô hình logic, vượt quality gate, và các liên kết chapter-template-artifact có thể truy vết hai chiều.
Ranh giới thẩm quyền	BA được phân tích ý nghĩa dữ liệu và ghi nhận câu hỏi. BA không được tự xác nhận nghĩa vụ pháp lý về dữ liệu cá nhân, diễn giải kế toán, quy tắc hóa đơn, yêu cầu an toàn thực phẩm, thời hạn lưu trữ hoặc quyết định kiến trúc dữ liệu. Các nội dung đó phải giữ nhãn Verification required và escalation đến chủ thể có thẩm quyền.
Điều kiện dừng	Dừng coverage nếu một thuộc tính dữ liệu được mô tả như nghĩa vụ pháp lý hoặc quy tắc Nova Foods nhưng không có nguồn chính thức, chủ sở hữu thẩm quyền và bằng chứng review tương ứng; không thay thế khoảng trống bằng dữ liệu thực hoặc suy diễn cấu hình production.

Ma trận ánh xạ bắt buộc cho năng lực BA nền tảng

Phân loại Core—Planned Complete nghĩa là năng lực cốt lõi phải có đủ chuỗi học tập: chapter Nova Foods mô phỏng, template được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md, ví dụ dữ liệu tổng hợp, quality gate (cổng chất lượng) và bằng chứng năng lực người học. Cầu nối suy luận là: nếu chỉ có lý thuyết mà không có artifact và tiêu chí kiểm tra, người học không thể chứng minh năng lực đầu ra; vì vậy mỗi hàng bắt buộc phải liên kết đủ sáu cột dưới đây. Các tham chiếu chapter phải được đối chiếu với /01-curriculum/CHAPTER_MANIFEST.md; không tự đặt ID hoặc filename chapter khi manifest chưa cung cấp định danh trong phạm vi lô này.

ID năng lực	Năng lực và khả năng quan sát được	Phân loại	Ánh xạ chapter Nova Foods mô phỏng	Ánh xạ artifact/template	Ánh xạ ví dụ thực hành dùng dữ liệu tổng hợp	Quality gate	Năng lực đầu ra của người học
CCM-FDN-STR-01	Strategy (chiến lược): phân biệt vấn đề, mục tiêu, kết quả mong đợi, chỉ số và ràng buộc; giải thích vì sao một thay đổi ERP được ưu tiên.	Core—Planned Complete	Chapter case study về bối cảnh, mục tiêu và phạm vi thay đổi Nova Foods.	Business case, problem statement, objective-to-KPI map; template phải được chọn từ TEMPLATE_MANIFEST.	So sánh tình trạng chậm xác nhận đơn bán hàng với mục tiêu rút ngắn thời gian xác nhận; mọi số liệu thời gian là tổng hợp.	Mỗi mục tiêu có chỉ số đo, chủ sở hữu đo lường, đường cơ sở được gắn nhãn giả định hoặc Verification required, và không bị viết thành cam kết vận hành thực tế.	Có thể chuyển một mối quan tâm kinh doanh thành mục tiêu có thể đo và nêu rõ giả định cần xác minh.
CCM-FDN-DIS-01	Discovery (khám phá): xác định phạm vi tri thức cần tìm, nguồn bằng chứng, khoảng trống và câu hỏi quyết định.	Core—Planned Complete	Chapter case study về khởi động khám phá quy trình order-to-cash của Nova Foods.	Discovery plan, source inventory, assumption and question log; template phải được chọn từ TEMPLATE_MANIFEST.	Lập câu hỏi về điểm bắt đầu xác nhận đơn, vai trò xử lý và dữ liệu cần quan sát trong luồng đơn hàng mô phỏng.	Mỗi câu hỏi nêu quyết định bị ảnh hưởng, nguồn dự kiến, người sở hữu tri thức và trạng thái xác minh; không biến suy đoán thành fact.	Có thể thiết kế hoạt động khám phá có mục đích và nhận diện rõ điều chưa biết.
CCM-FDN-ELI-01	Elicitation (khai thác yêu cầu): chuẩn bị, thực hiện và ghi nhận thông tin bằng phỏng vấn, workshop hoặc quan sát phù hợp.	Core—Planned Complete	Chapter case study về khai thác nhu cầu của Sales, Kho và Kế toán trong ERP Nova Foods.	Elicitation plan, agenda, question set, session note, decision log; template phải được chọn từ TEMPLATE_MANIFEST.	Soạn agenda workshop xử lý tình huống đơn hàng cần kiểm tra tồn kho trước khi xác nhận, với vai trò mô phỏng.	Câu hỏi không dẫn dắt; ghi chú tách phát biểu, bằng chứng, giả định và quyết định; quyết định chưa có thẩm quyền phải giữ trạng thái mở để escalation.	Có thể điều phối một phiên khai thác giả lập và chuyển ghi nhận thô thành đầu vào có cấu trúc.
CCM-FDN-STK-01	Stakeholder analysis and management (phân tích và quản lý các bên liên quan): nhận diện ảnh hưởng, nhu cầu thông tin, quyền quyết định và cách tham gia.	Core—Planned Complete	Chapter case study về bản đồ bên liên quan cho thay đổi ERP Nova Foods.	Stakeholder map, RACI draft, communication plan, issue log; template phải được chọn từ TEMPLATE_MANIFEST.	Phân tích Sales Manager, Warehouse Supervisor, Accounting Owner, Security Owner và Business Owner trong thay đổi xác nhận đơn mô phỏng.	Mỗi vai trò có lợi ích, ảnh hưởng, trách nhiệm và ranh giới thẩm quyền; BA không gán quyền phê duyệt, pháp lý hay kế toán thay cho role owner.	Có thể lập bản đồ stakeholder và chọn cách tham gia phù hợp với rủi ro quyết định.
CCM-FDN-PRC-01	Process analysis and modelling (phân tích và mô hình hóa quy trình): xác định trigger, hoạt động, quyết định, ngoại lệ, đầu vào và đầu ra.	Core—Planned Complete	Chapter case study về quy trình từ tiếp nhận đơn đến giao hàng của Nova Foods.	As-is/to-be process model, process narrative, pain-point log; BPMN chỉ dùng khi ký pháp BPMN 2.0.2 được áp dụng đúng.	Mô hình hóa luồng đơn bán hàng mô phỏng: nhận đơn, kiểm tra dữ liệu, kiểm tra tồn kho, xác nhận hoặc trả về bổ sung.	Mô hình có phạm vi, trigger, end state, lane/role, nhánh quyết định và ngoại lệ; không gọi sơ đồ hoạt động không tuân ký pháp là BPMN.	Có thể phát hiện điểm nghẽn và mô tả quy trình đủ rõ để thảo luận với nghiệp vụ và kỹ thuật.
CCM-FDN-REQ-01	Requirements analysis and specification (phân tích và đặc tả yêu cầu): tách business requirement, stakeholder requirement, functional requirement và acceptance criteria (tiêu chí chấp nhận).	Core—Planned Complete	Chapter case study về đặc tả thay đổi xác nhận đơn hàng Nova Foods.	Requirement catalog, user story/use case, acceptance criteria, requirement traceability entry; template phải được chọn từ TEMPLATE_MANIFEST.	Viết yêu cầu cho việc cảnh báo khi thiếu dữ liệu giao hàng trong đơn mô phỏng, kèm tiêu chí chấp nhận có điều kiện và kết quả quan sát được.	Requirement đơn nghĩa, kiểm thử được, có nguồn và trạng thái; acceptance criteria không chứa rule chưa xác minh hoặc diễn giải pháp lý tự suy đoán.	Có thể viết yêu cầu có thể chuyển giao cho thiết kế và kiểm thử mà vẫn truy được nguồn.
CCM-FDN-RUL-01	Business rules (quy tắc nghiệp vụ): nhận diện điều kiện, hành động, ngoại lệ, nguồn thẩm quyền và tác động của quy tắc.	Core—Planned Complete	Chapter case study về quy tắc kiểm tra đơn, tồn kho và trạng thái xử lý Nova Foods.	Rule catalog entry liên kết /01-curriculum/CANONICAL_BUSINESS_RULES.md, decision table và rule-to-requirement trace.	Diễn đạt quy tắc mô phỏng: đơn thiếu mã khách hàng không được chuyển sang bước xác nhận cho đến khi dữ liệu được bổ sung.	Mỗi rule có ID từ registry khi đã được đăng ký, câu phát biểu nguyên tử, nguồn, owner xác minh, ngoại lệ và liên kết requirement; quy tắc thuế, kế toán, an toàn thực phẩm hoặc pháp lý phải gắn Verification required nếu chưa có xác minh thẩm quyền.	Có thể tách rule khỏi màn hình hoặc quy trình, tránh sao chép cùng một rule vào nhiều artifact.
CCM-FDN-DAT-01	Data analysis and logical data modelling (phân tích dữ liệu và mô hình dữ liệu logic): xác định entity, thuộc tính, khóa logic, quan hệ, chất lượng dữ liệu và vòng đời dữ liệu.	Core—Planned Complete	Chapter case study về dữ liệu khách hàng, đơn hàng, dòng đơn và tồn kho Nova Foods.	Logical data model, data dictionary entry liên kết /01-curriculum/CANONICAL_DATA_DICTIONARY.md, data-quality rule và data lineage note.	Lập mô hình logic tổng hợp cho Customer, SalesOrder, SalesOrderLine và InventoryBalance; dùng mã và giá trị VND mô phỏng.	Entity có định nghĩa nghiệp vụ; thuộc tính có ý nghĩa, kiểu logic và nguồn; quan hệ có lực lượng; dữ liệu cá nhân hoặc dữ liệu nhạy cảm tiềm năng được phân loại và chuyển Security/Legal Owner xác minh khi cần.	Có thể phát hiện mơ hồ dữ liệu, mô tả quan hệ logic và liên kết dữ liệu với requirement cùng business rule.

Quy tắc ánh xạ bắt buộc là mỗi artifact trong bảng phải mang tham chiếu ngược đến chapter Nova Foods mô phỏng, Artifact ID hoặc đường dẫn canonical khi đã có, và ID năng lực CCM-FDN-*. Bằng chứng cho quy tắc này là chuỗi strategy → discovery → elicitation → requirement/rule/data chỉ giữ được tính truy vết khi người học có thể đi từ năng lực đến ví dụ và quay lại artifact nguồn. Tại IN_REVIEW, version v0.9.0, ngày 2026-08-07, các mapping này là kế hoạch học liệu; chúng không là baseline, approval, yêu cầu ERP production hoặc xác nhận pháp lý, kế toán, bảo mật hay vận hành.

Khuôn xử lý có kiểm soát cho năng lực được phân loại Partial

Partial nghĩa là learner hoặc handbook đã có bằng chứng cho một phần năng lực nhưng chưa đủ chuỗi bằng chứng để thực hiện độc lập, kiểm tra được và bàn giao được. Suy luận này dựa trên nguyên tắc năng lực BA phải quan sát được qua đầu ra công việc: chỉ biết thuật ngữ hoặc hoàn thành một biểu mẫu không chứng minh được khả năng phân tích, nêu giả định, xử lý mâu thuẫn và truy vết quyết định. Mỗi dòng Partial trong ma trận phải tạo một bản ghi xử lý riêng; không được dùng Partial để che giấu thiếu chapter, thiếu template, thiếu ví dụ hoặc thiếu người có thẩm quyền xác minh.

Trường bắt buộc trong bản ghi xử lý Partial	Cách điền và bằng chứng phải lưu	Căn cứ → kết luận kiểm soát
Competency name	Ghi đúng tên năng lực trong dòng ma trận: Strategy, Discovery, Elicitation, Stakeholder Analysis and Management, Process Analysis/Modelling, Requirements Analysis/Specification, Business Rules, hoặc Data Analysis and Logical Data Modelling.	Tên chuẩn giúp liên kết một khoảng trống với đúng năng lực, thay vì sửa chung chung trên nhiều chapter.
Partial boundary	Nêu chính xác phần learner đã làm được, phần chưa làm được và hậu quả học tập nếu giữ nguyên. Ví dụ: learner có thể vẽ luồng hiện trạng nhưng chưa phân biệt ngoại lệ, điểm quyết định và quy tắc chi phối luồng.	Bằng chứng bị thiếu phải được mô tả ở mức hành vi; nếu không, không thể thiết kế biện pháp bổ sung có thể kiểm tra.
Evidence reviewed	Liệt kê chapter ID và tên tệp từ /01-curriculum/CHAPTER_MANIFEST.md; template ID và tên tệp từ /01-curriculum/TEMPLATE_MANIFEST.md; artifact canonical liên quan nếu có, gồm CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY.	Manifest và artifact canonical là nguồn nhận diện được kiểm soát; không tự tạo tên chapter, template hoặc ID mới trong bản ghi xử lý.
Nova Foods mapping	Chỉ rõ tình huống Nova Foods Trading & Manufacturing mô phỏng được dùng để luyện tập, dữ liệu tổng hợp được phép dùng và câu hỏi nghiệp vụ cần phân tích.	Case study tạo ngữ cảnh quan sát được, nhưng vì Nova Foods là mô phỏng giáo dục nên không được suy diễn thành quy trình ERP thực tế hoặc quyết định vận hành thực tế.
Root cause	Chọn một hoặc nhiều nguyên nhân: thiếu khái niệm, thiếu trình tự thao tác, thiếu ví dụ đối chiếu, thiếu template, thiếu quality gate, hoặc dependency chưa sẵn sàng.	Biện pháp phải sửa nguyên nhân; thêm nội dung lý thuyết sẽ không giải quyết khoảng trống do thiếu đầu ra thực hành hoặc thiếu kiểm tra.
Treatment action	Ghi một hành động có đầu ra cụ thể: bổ sung giải thích từ nguyên lý; thêm worked example; thêm bài thực hành; bổ sung trường template; hoặc thêm review checkpoint.	Một hành động có đầu ra xác định cho phép reviewer kiểm tra việc xử lý đã hoàn tất về mặt nội dung, không đồng nghĩa approval hay baseline.
Acceptance evidence	Xác định artifact learner phải nộp, tiêu chí kiểm tra, liên kết traceability và vai trò review phù hợp.	Năng lực chỉ chuyển khỏi Partial khi đầu ra chứng minh được hành vi còn thiếu và vượt qua quality gate đã định nghĩa.
Source and authority boundary	Ghi nguồn được dùng và nhãn Verification required khi nội dung chạm pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc quyết định kiến trúc.	Nguồn seed chỉ cho phép dùng trong safe use boundary; BA curriculum author không thay thế Legal Owner, Accounting Owner, Security, Architect hoặc Business Owner.
Status and follow-up	Giữ trạng thái bản ghi là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh; nêu điều kiện kiểm tra lại.	Metadata corpus xác nhận đây là kế hoạch đang review, không phải baseline, approval, xác nhận chất lượng chuyên môn hay quyền dùng production.

Năng lực Partial	Khoảng trống phải kiểm tra	Biện pháp tối thiểu	Bằng chứng đạt quality gate
Strategy	Không nối được vấn đề, mục tiêu, chỉ số đo lường và lựa chọn thay đổi.	Thêm worked example yêu cầu phân biệt triệu chứng với nguyên nhân và lập chuỗi mục tiêu–chỉ số–giả định.	Learner nêu được giả định, chỉ số và lý do một đề xuất chưa được chọn; liên kết đến chapter và template canonical.
Discovery	Thu thập được thông tin nhưng chưa xác định phạm vi, câu hỏi ưu tiên hoặc khoảng trống tri thức.	Bổ sung discovery plan với giả thuyết, nguồn thông tin, câu hỏi và tiêu chí đóng phát hiện.	Kế hoạch phân biệt fact, assumption và Verification required; không biến thông tin chưa xác minh thành requirement.
Elicitation	Biết phỏng vấn hoặc workshop nhưng chưa chọn kỹ thuật theo mục tiêu và stakeholder.	Thêm bài chọn kỹ thuật elicitation theo xung đột, độ bất định và mức sẵn sàng dữ liệu.	Learner giải thích quan hệ mục tiêu–kỹ thuật–đầu ra–rủi ro, có bằng chứng ghi nhận câu hỏi và kết quả.
Stakeholder Analysis and Management	Có danh sách stakeholder nhưng chưa phân tích ảnh hưởng, quyền quyết định hoặc cách xử lý bất đồng.	Bổ sung stakeholder map và engagement approach cho tình huống Nova Foods mô phỏng.	Bản đồ nêu rõ quyền hạn, nhu cầu thông tin, rủi ro xung đột và đường escalation; không tự gán quyền phê duyệt.
Process Analysis/Modelling	Có sơ đồ nhưng không mô tả trigger, outcome, ngoại lệ, handoff hoặc rule chi phối.	Thêm bài phân tích hiện trạng và tương lai, dùng notation đúng nguồn được công bố.	Sơ đồ và mô tả quy trình liên kết được trigger, actor, bước, ngoại lệ, outcome và business rule; chỉ gọi là BPMN khi dùng BPMN 2.0.2.
Requirements Analysis/Specification	Có yêu cầu dạng mong muốn nhưng chưa rõ điều kiện, ưu tiên, acceptance criteria hoặc dependency.	Bổ sung thực hành tách business need, stakeholder requirement, solution requirement và acceptance criteria.	Mỗi requirement có nguồn, lý do, tiêu chí chấp nhận, dependency và liên kết truy vết; nội dung yêu cầu hệ thống phải giữ nhãn xác minh khi cần.
Business Rules	Viết rule lẫn với quy trình, UI hoặc giải pháp kỹ thuật; chưa quản lý ngoại lệ và nguồn thẩm quyền.	Đối chiếu rule với catalog CANONICAL_BUSINESS_RULES, bổ sung cấu trúc điều kiện–hành động–ngoại lệ–nguồn.	Rule có định danh canonical đã đăng ký, phạm vi, điều kiện áp dụng, ngoại lệ và owner xác minh; nội dung pháp lý hoặc kế toán giữ Verification required.
Data Analysis and Logical Data Modelling	Liệt kê trường dữ liệu nhưng chưa xác định entity, quan hệ, định nghĩa, chất lượng hoặc nguồn hệ thống.	Đối chiếu với CANONICAL_DATA_DICTIONARY, bổ sung logical data model và data dictionary entry.	Learner chứng minh được entity, thuộc tính, khóa logic, quan hệ, quy tắc chất lượng và traceability đến requirement; không suy diễn schema triển khai hoặc dữ liệu thật.

Quality gate của mọi bản ghi Partial gồm bốn kiểm tra tuần tự: kiểm tra liên kết đến chapter và template đã đăng ký trong manifest; kiểm tra worked example Nova Foods chỉ dùng dữ liệu tổng hợp theo vi-VN và VND; kiểm tra không có kết luận pháp lý, kế toán, thuế, bảo mật hoặc vận hành vượt thẩm quyền; và kiểm tra bằng chứng learner đáp ứng đúng hành vi còn thiếu. Nếu một liên kết canonical chưa tồn tại, nguồn mâu thuẫn, hoặc biện pháp yêu cầu quyết định của nhiều owner chuyên môn, bản ghi giữ Partial và được escalation theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không được tự đổi sang Covered hoặc diễn giải là đã được phê duyệt.

Quy tắc ánh xạ bắt buộc tới chapter và template của Nova Foods

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp. Mỗi dòng năng lực nền tảng được tạo trong ma trận phải có liên kết hai chiều tới ít nhất một chapter case study và một template thực hành: chapter giải thích bối cảnh, quyết định và cách làm; template buộc learner tạo bằng chứng đầu ra. Cầu nối suy luận là: nếu năng lực chỉ có chapter, learner có thể đọc nhưng chưa chứng minh được khả năng thực hiện; nếu chỉ có template, learner có thể điền biểu mẫu nhưng không biết khi nào và vì sao dùng nó. Vì vậy, một dòng không có đủ hai liên kết không được ghi nhận là coverage hoàn chỉnh.

Trường ánh xạ bắt buộc trong mỗi dòng competency	Giá trị phải ghi	Quy tắc kiểm soát
Case-study chapter ID	ID chapter nguyên dạng từ /01-curriculum/CHAPTER_MANIFEST.md	Không tự tạo ID, dịch ID, rút gọn tên chapter hoặc thay bằng số thứ tự không có trong manifest.
Case-study chapter filename	Đường dẫn tệp chapter nguyên dạng từ CHAPTER_MANIFEST	Filename là bằng chứng vị trí học liệu; tên hiển thị không thay thế filename.
Template ID	ID template nguyên dạng từ /01-curriculum/TEMPLATE_MANIFEST.md	Một competency có thể dùng nhiều template khi cần nhiều loại bằng chứng, nhưng từng ID phải tồn tại trong manifest.
Template filename	Đường dẫn tệp template nguyên dạng từ TEMPLATE_MANIFEST	Không dùng bản sao, bản xuất hoặc tệp tự đặt tên làm thay thế template được kiểm soát.
Nova Foods worked-example anchor	Mục, tình huống hoặc dữ liệu tổng hợp được chapter chỉ định	Ví dụ chỉ minh họa học tập; không được diễn giải là dữ liệu khách hàng, giao dịch, cấu hình ERP hoặc quyết định vận hành thật.
Canonical cross-reference	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc TRACEABILITY_ID_REGISTRY khi output có rule, data hoặc ID	Chỉ thêm tham chiếu khi bản chất đầu ra cần nguồn chân lý tương ứng; không biến tham chiếu thành xác nhận nội dung đã đúng hoặc đã baseline.

Việc chọn chapter và template phải theo chuỗi bằng chứng: năng lực cần quan sát được → hoạt động Nova Foods mô phỏng → đầu ra learner tạo được → chapter hướng dẫn hoạt động → template ghi nhận đầu ra. Ví dụ, khi một dòng competency yêu cầu learner phân tích một thông tin có tính quy tắc, chapter được chọn phải trình bày tình huống Nova Foods mô phỏng có quyết định cần làm rõ; template được chọn phải có nơi ghi điều kiện, kết quả, nguồn và trạng thái xác minh; đồng thời liên kết tới CANONICAL_BUSINESS_RULES phải giữ nguyên khi quy tắc được đăng ký. Không được dùng một chapter chỉ nói khái niệm chung hoặc một template không có trường bằng chứng để tạo cảm giác đã coverage.

Tại phiên bản v0.9.0, trạng thái IN_REVIEW, ngày 2026-08-07, các ID và filename chapter/template phải được sao chép từ hai manifest authoritative, không được suy đoán từ tên miền năng lực. Nếu một chapter hoặc template cần thiết chưa có entry canonical trong /01-curriculum/CHAPTER_MANIFEST.md hoặc /01-curriculum/TEMPLATE_MANIFEST.md, dòng ma trận phải giữ trạng thái ánh xạ chưa hoàn chỉnh và không được thay thế bằng ID tự tạo. Điều này bảo toàn truy vết vì manifest là nguồn xác định danh tính học liệu, còn ma trận chỉ là nơi tiêu thụ và kiểm tra liên kết.

Cổng kiểm tra cho mỗi ánh xạ là: ID và filename khớp manifest; chapter thực sự chứa tình huống Nova Foods mô phỏng liên quan; template có thể tạo ra bằng chứng learner độc lập thực hiện; mọi rule hoặc dữ liệu logic được tham chiếu về đúng artifact canonical; và nội dung không tuyên bố baseline, approval, tuân thủ pháp lý hay sẵn sàng production. Chỉ khi năm điều kiện cùng đúng, ánh xạ chapter–template mới đủ điều kiện làm bằng chứng coverage trong ma trận.

Solution literacy domains: APIs/integration, architecture literacy, UX/accessibility, NFR/security

Kế hoạch dòng năng lực API và tích hợp

API (Application Programming Interface, giao diện để hệ thống trao đổi dữ liệu/chức năng qua một hợp đồng kỹ thuật) không được dạy như năng lực tự quyết kiến trúc hay tự triển khai. Learner phải đọc được giao diện, phát hiện câu hỏi nghiệp vụ–dữ liệu–trách nhiệm còn thiếu, và chuyển vấn đề đúng vai trò. Cầu nối suy luận là: một yêu cầu nghiệp vụ Nova Foods mô phỏng chỉ có thể đi qua tích hợp nhất quán khi BA xác định được bên gọi, bên cung cấp, dữ liệu trao đổi, điều kiện lỗi và bằng chứng kiểm thử; tuy nhiên các quyết định endpoint, xác thực, hạ tầng, giới hạn tải và triển khai thuộc thẩm quyền Architect, Security hoặc đội kỹ thuật.

Competency ID dự kiến trong ma trận	Năng lực và phân loại	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ thực hành Nova Foods mô phỏng, dữ liệu tổng hợp	Quality gate trước khi ghi nhận coverage	Năng lực learner đạt được
API-INT-01	Partial — API consumer/provider literacy: phân biệt hệ thống cung cấp (provider) và hệ thống gọi (consumer); xác định mục tiêu nghiệp vụ, sự kiện kích hoạt, dữ liệu vào/ra và chủ sở hữu câu hỏi. Phân loại Partial vì handbook dạy đọc và phân tích hợp đồng, không trao quyền thiết kế tích hợp.	Chưa được ghi trong đầu vào hiện có. Phải lấy nguyên ID và filename từ /01-curriculum/CHAPTER_MANIFEST.md; không tạo ID thay thế.	Chưa được ghi trong đầu vào hiện có. Phải lấy nguyên ID và filename từ /01-curriculum/TEMPLATE_MANIFEST.md; template cần có trường caller, provider, trigger, payload logic, owner và trạng thái xác minh.	Đơn hàng bán hàng mô phỏng SO-SYN-1001 cần gửi trạng thái “sẵn sàng xuất kho” từ ERP mô phỏng sang kênh giao nhận mô phỏng. Đây chỉ là tình huống học tập, không suy diễn endpoint hay cấu hình ERP thực tế.	Learner chỉ ra được provider, consumer, trigger, dữ liệu tối thiểu, kết quả mong đợi, ngoại lệ và chủ sở hữu chưa xác minh; không viết quyết định kiến trúc như sự thật Nova Foods.	Đọc được luồng tích hợp ở cấp BA và đặt câu hỏi có thể hành động cho Business Owner, Architect và đội kỹ thuật.
API-INT-02	Partial — OpenAPI-oriented literacy: đọc đặc tả OpenAPI (OpenAPI Specification, chuẩn mô tả HTTP API) ở mức paths, operation, request, response, parameter, schema và mã trạng thái HTTP; đối chiếu với requirement và acceptance criteria.	Chưa được ghi trong đầu vào hiện có; dùng entry canonical của CHAPTER_MANIFEST khi có.	Chưa được ghi trong đầu vào hiện có; dùng entry canonical của TEMPLATE_MANIFEST khi có. Artifact phải phân biệt “bằng chứng từ đặc tả” với “giả định nghiệp vụ”.	Learner đối chiếu yêu cầu tra cứu tồn kho mô phỏng theo itemCode và warehouseCode với một trích đoạn OpenAPI giả lập; xác định trường nào chưa có định nghĩa nghiệp vụ hoặc chưa liên kết tới CANONICAL_DATA_DICTIONARY.	Có liên kết hai chiều giữa điều kiện nghiệp vụ, trường dữ liệu logic, request/response và phản hồi lỗi; không tuyên bố schema hoặc HTTP status là đã được Architect phê chuẩn.	Đọc được một hợp đồng API để phát hiện thiếu dữ liệu, mâu thuẫn tên trường và khoảng trống acceptance criteria.
API-INT-03	Partial — integration exception and reconciliation analysis: mô tả trường hợp gửi trùng, phản hồi chậm, từ chối dữ liệu, không nhận phản hồi hoặc lệch trạng thái; phân biệt lỗi nghiệp vụ với lỗi kỹ thuật ở mức quan sát.	Chưa được ghi trong đầu vào hiện có; lấy ID/filename canonical từ CHAPTER_MANIFEST.	Chưa được ghi trong đầu vào hiện có; lấy ID/filename canonical từ TEMPLATE_MANIFEST. Artifact phải ghi correlation/reference ID mô phỏng, thời điểm, trạng thái nguồn–đích và người xử lý.	Một lần gửi xác nhận xuất hàng cho SO-SYN-1001 nhận phản hồi không thành công; learner lập danh sách bằng chứng cần thu thập và câu hỏi xác minh, không tự chỉ định cơ chế retry hoặc thiết kế hàng đợi.	Ngoại lệ có trigger, tác động nghiệp vụ, dữ liệu liên quan, chủ sở hữu xử lý, cách đối soát và tiêu chí đóng được mô tả; phần chưa xác minh giữ nhãn Verification required.	Chuyển sự cố tích hợp thành yêu cầu làm rõ, test basis và dấu vết đối soát thay vì suy đoán nguyên nhân kỹ thuật.
API-INT-04	Partial — API data contract traceability: liên kết trường trong hợp đồng API với định nghĩa dữ liệu logic, business rule và tiêu chí chấp nhận; nhận diện dữ liệu nhạy cảm để chuyển Security review.	Chưa được ghi trong đầu vào hiện có; lấy ID/filename canonical từ CHAPTER_MANIFEST.	Chưa được ghi trong đầu vào hiện có; dùng các artifact canonical CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES và ID tương ứng trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tạo mã quy tắc hoặc mã dữ liệu mới.	Payload mô phỏng chứa mã đơn hàng, mã mặt hàng và địa điểm kho; learner lập bảng trường–ý nghĩa–nguồn chân lý–rule liên quan–trạng thái xác minh. Nếu xuất hiện dữ liệu cá nhân hoặc thông tin truy cập, learner phải chuyển Security/Legal Owner.	Mỗi trường quan trọng có nguồn chân lý hoặc được đánh dấu thiếu nguồn; rule không bị sao chép thành rule mới; dữ liệu nhạy cảm không được đưa vào ví dụ chi tiết hay log mô phỏng.	Duy trì truy vết từ nhu cầu nghiệp vụ tới hợp đồng dữ liệu mà không vượt thẩm quyền bảo mật, pháp lý hoặc kiến trúc.

Chuẩn nguồn và ranh giới thẩm quyền

OpenAPI Specification OAS 3.1.1, do OpenAPI Initiative công bố ngày 2024-10-24, là nguồn normative cho cú pháp và khả năng biểu đạt của đặc tả HTTP API. Vì vậy learner có thể dùng nguồn này để hiểu ý nghĩa của cấu trúc đặc tả, nhưng không được suy ra rằng một API Nova Foods mô phỏng phải dùng toàn bộ tính năng của OAS hoặc đã tuân thủ OAS trong triển khai.

Các thực hành như đặt tên nhất quán, lập bảng mapping trường, mô tả lỗi có thể quan sát và đối soát trạng thái là good practice: hữu ích để giảm mơ hồ, nhưng không phải điều khoản pháp lý hay quyết định kiến trúc. Quy ước như tên endpoint, định dạng mã lỗi, cơ chế retry, timeout, xác thực, phân quyền, versioning và công cụ API là project convention hoặc quyết định kỹ thuật; chỉ được ghi sau khi vai trò có thẩm quyền xác nhận trong artifact kiểm soát phù hợp.

Quy tắc xử lý trạng thái Partial

Partial nghĩa là coverage có chủ đích nhưng giới hạn: learner được đánh giá năng lực đọc, phân tích, truy vết, viết câu hỏi và chuẩn bị bằng chứng; learner không được đánh giá là có thẩm quyền thiết kế API, phê chuẩn hợp đồng kỹ thuật, chọn cơ chế tích hợp, xác nhận an toàn dữ liệu hoặc cho phép production. Dòng Partial chỉ được tính coverage khi chapter và template canonical đã được manifest xác định, ví dụ mô phỏng dùng dữ liệu tổng hợp, và quality gate chứng minh learner đã nêu rõ phần cần escalation. Nếu thiếu một trong các liên kết này, trạng thái ánh xạ phải giữ là chưa hoàn chỉnh tại IN_REVIEW, v0.9.0, ngày 2026-08-07, thay vì bù bằng ID, filename hoặc xác nhận tự tạo.

Kế hoạch hàng năng lực về đọc hiểu kiến trúc: ngữ cảnh, thành phần và ranh giới

Đọc hiểu kiến trúc (architecture literacy) là khả năng để BA hiểu hệ thống nằm ở đâu trong bức tranh nghiệp vụ-kỹ thuật, thành phần nào chịu trách nhiệm gì, và dữ liệu hoặc trách nhiệm không được vượt qua ranh giới nào. BA không thiết kế kiến trúc đích, không chọn công nghệ, không phê duyệt kết nối hay quyết định triển khai. Phân loại Partial — literacy được áp dụng vì handbook cần giúp learner đặt câu hỏi đúng và phát hiện mâu thuẫn requirement, trong khi thẩm quyền thiết kế vẫn thuộc Architect và các vai trò chuyên môn liên quan.

Hàng năng lực dự kiến	Phân loại	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ thực hành	Quality gate	Năng lực learner đạt được
Đọc sơ đồ ngữ cảnh (context diagram): nhận diện hệ thống đang xét, tác nhân bên ngoài và luồng trao đổi ở mức khái niệm	Partial — literacy	CHAPTER_MANIFEST — chapter solution literacy được đăng ký canonical cho chủ đề architecture literacy; không gán ID chapter mới trong lô này	Context view dự kiến được đăng ký trong TEMPLATE_MANIFEST; liên kết requirement và thuật ngữ với CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi các artifact đó có nội dung phù hợp	Nova Foods mô phỏng: phân biệt ranh giới giữa ERP mô phỏng, Nhân viên kho mô phỏng và Nhà cung cấp mô phỏng khi ghi nhận yêu cầu theo dõi tình trạng đơn mua; chỉ dùng mã và dữ liệu tổng hợp	Sơ đồ phải nêu rõ một hệ thống trung tâm, tác nhân ngoài hệ thống và ý nghĩa từng luồng; không được biến giả định kết nối thành cấu hình ERP thực tế	Giải thích được “ai/đâu” tương tác với hệ thống, chỉ ra câu hỏi còn thiếu về chủ sở hữu luồng và tránh gọi tác nhân ngoài là thành phần nội bộ
Đọc sơ đồ thành phần (component view): nhận biết trách nhiệm logic, điểm hợp tác và phụ thuộc giữa các thành phần	Partial — literacy	CHAPTER_MANIFEST — chapter solution literacy được đăng ký canonical cho chủ đề architecture literacy	Component view dự kiến được đăng ký trong TEMPLATE_MANIFEST; quyết định, giả định và điểm chưa rõ phải được truy vết theo quy tắc ID canonical trong TRACEABILITY_ID_REGISTRY	Nova Foods mô phỏng: diễn giải sơ đồ gồm thành phần Quản lý đơn mua, Quản lý tồn kho và Báo cáo vận hành; learner xác định trách nhiệm mô tả của từng thành phần mà không suy diễn microservice, cơ sở dữ liệu hay nền tảng triển khai	Mỗi thành phần có một trách nhiệm nghiệp vụ-kỹ thuật ở mức logic; quan hệ phải diễn đạt được lý do phụ thuộc; không có thành phần “làm mọi việc” hoặc trách nhiệm chồng lấn chưa được nêu	Phát hiện được requirement đặt nhầm trách nhiệm, nêu được tác động khi một thành phần thay đổi, và lập câu hỏi cho Architect thay vì tự chọn cấu trúc kỹ thuật
Phân tích ranh giới (boundary analysis): tách trách nhiệm, quyền sở hữu dữ liệu, phạm vi thay đổi và điểm cần escalation	Partial — literacy	CHAPTER_MANIFEST — chapter solution literacy được đăng ký canonical cho chủ đề architecture literacy	Boundary decision record dự kiến được đăng ký trong TEMPLATE_MANIFEST; thuật ngữ dữ liệu chỉ tham chiếu từ CANONICAL_DATA_DICTIONARY, không tạo nguồn chân lý dữ liệu thứ hai	Nova Foods mô phỏng: yêu cầu hiển thị “tình trạng giao hàng” được tách thành dữ liệu do ERP mô phỏng sở hữu, dữ liệu do bên ngoài mô phỏng cung cấp và dữ liệu chưa xác định chủ sở hữu; learner ghi rõ Verification required cho phần chưa có bằng chứng	Mỗi dữ liệu, quy tắc và hành động có ranh giới sở hữu được nêu hoặc được gắn Verification required; yêu cầu vượt ranh giới phải có câu hỏi escalation tới Architect hoặc Business Owner phù hợp	Phân biệt được ranh giới nghiệp vụ, dữ liệu và kỹ thuật; không viết requirement như thể BA có quyền quyết định hệ thống nào sở hữu dữ liệu hoặc cách các hệ thống kết nối

Cầu nối suy luận cho ba hàng trên là: requirement chỉ kiểm thử và triển khai nhất quán khi biết phạm vi hệ thống, trách nhiệm logic và điểm chuyển giao; vì vậy BA cần đọc được ba lớp này trước khi hoàn thiện requirement. BABOK Guide được dùng như nguồn chính về năng lực và thuật ngữ BA; UML 2.5.1 của OMG chỉ là nguồn chuẩn khi tài liệu thực sự tuyên bố dùng ngữ nghĩa UML. Sơ đồ ngữ cảnh hoặc sơ đồ thành phần tự chọn không mặc nhiên là UML và không được gắn nhãn UML nếu chưa đối chiếu ký pháp phù hợp.

Phân biệt nguồn áp dụng: ngữ nghĩa UML, khi được sử dụng đúng phạm vi, là tiêu chuẩn chuẩn tắc (normative standard); việc BA dùng context view và component view để làm rõ requirement là thực hành tốt (good practice); tên sơ đồ, mức độ chi tiết, ký hiệu màu, bố cục và nơi lưu artifact của Nova Foods mô phỏng là quy ước dự án (project convention). Không quy ước nào trong số này tạo nghĩa vụ pháp lý, quyết định kiến trúc thực tế hay phê duyệt triển khai.

Với mọi hàng Partial, learner được phép mô tả bằng chứng, chỉ ra mâu thuẫn, nêu giả định và lập gói escalation gồm artifact bị ảnh hưởng, ranh giới đang mơ hồ, tác động nếu hiểu sai và câu hỏi cần quyết định. Learner không được tự chọn kiến trúc, công nghệ, cơ chế lưu trữ, mô hình triển khai, chủ sở hữu dữ liệu thực tế hoặc kết luận rằng Nova Foods đáp ứng một tiêu chuẩn. Tất cả ví dụ Nova Foods trong hàng này là mô phỏng giáo dục và chỉ sử dụng dữ liệu tổng hợp.

Kế hoạch hàng năng lực UX và khả năng tiếp cận theo WCAG

Khả năng sử dụng (UX, user experience) là mức độ người dùng hoàn thành mục tiêu hiệu quả, dễ hiểu và ít lỗi; khả năng tiếp cận (accessibility) là việc người có nhu cầu tiếp cận khác nhau vẫn có thể nhận biết, vận hành và hiểu được giao diện. Trong Nova Foods Trading & Manufacturing, đây là bối cảnh mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; BA học cách phát hiện, diễn đạt và truy vết nhu cầu UX/accessibility, không tự nhận thẩm quyền thiết kế giao diện cuối cùng, kiểm định kỹ thuật chuyên sâu hoặc xác nhận tuân thủ production.

ID hàng năng lực dự kiến	Năng lực và phân loại	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ thực hành tổng hợp	Quality gate	Năng lực đầu ra của học viên
CCM-UX-01	UX discovery literacy — Partial. Nhận diện người dùng, mục tiêu tác vụ, ngữ cảnh sử dụng, điểm đau và lỗi có thể xảy ra trước khi viết requirement. Đây là good practice BA, không phải tiêu chuẩn pháp lý hay thiết kế UI bắt buộc.	CHAPTER_MANIFEST: chapter thuộc nhóm solution literacy về UX/accessibility; chỉ được ghi ID chapter sau khi manifest có entry canonical tương ứng.	CANONICAL_BUSINESS_RULES để phân biệt rule với nhu cầu trải nghiệm; CANONICAL_DATA_DICTIONARY để dùng đúng nhãn dữ liệu; matrix này là nơi ghi coverage. Không tạo filename hoặc template ID chưa đăng ký.	Người dùng kho tổng hợp nhập số lô nguyên liệu vào màn hình nhận hàng. BA ghi mục tiêu “xác định đúng lô trước khi lưu”, rủi ro “nhập nhầm ký tự O và số 0”, và câu hỏi cần xác minh với nghiệp vụ về mã lô hợp lệ.	Tác vụ có actor, mục tiêu, bối cảnh, lỗi/rủi ro và câu hỏi xác minh; không biến sở thích giao diện thành business rule.	Phân biệt được nhu cầu người dùng, yêu cầu chức năng và quyết định thiết kế; lập được đầu vào rõ cho UX designer hoặc Product Owner.
CCM-UX-02	Accessible requirement elicitation — Partial. Chuyển quan sát thành requirement có thể kiểm thử, ví dụ yêu cầu trạng thái lỗi được nhận biết không chỉ bằng màu. WCAG được dùng làm chuẩn tham chiếu normative accessibility recommendation của W3C, không tự động là luật Việt Nam hay chứng nhận compliance.	CHAPTER_MANIFEST: chapter solution literacy về UX/accessibility, phụ thuộc chapter requirements và acceptance criteria theo manifest.	CANONICAL_DATA_DICTIONARY để xác định field mô phỏng như LotCode; TRACEABILITY_ID_REGISTRY để đăng ký liên kết khi có ID requirement/test canonical.	Với field LotCode của phiếu nhận hàng mô phỏng, BA viết acceptance criterion: khi giá trị không hợp lệ, hệ thống hiển thị thông điệp văn bản nêu field và lỗi; không chỉ đổi viền đỏ. Giá trị mẫu LO-NF-260807-01 là dữ liệu tổng hợp.	Requirement nêu được hành vi quan sát được, điều kiện kích hoạt và kết quả; không ghi “tuân thủ WCAG” nếu chưa xác định success criterion, phạm vi giao diện và người kiểm tra có thẩm quyền.	Viết được acceptance criterion hỗ trợ accessibility mà không tự tuyên bố thiết kế đạt chuẩn hoặc đã kiểm định.
CCM-UX-03	WCAG-aware classification — Partial. Phân loại một vấn đề theo nguyên tắc WCAG phù hợp ở mức nhận biết: có thể nhận biết (perceivable), có thể vận hành (operable), có thể hiểu (understandable), và vững chắc với công nghệ hỗ trợ (robust). Đây là literacy, không phải năng lực audit WCAG.	CHAPTER_MANIFEST: chapter solution literacy về UX/accessibility; chapter phải liên kết nguồn WCAG 2.2 chính thức thay vì tự chép hoặc diễn giải clause chưa kiểm chứng.	TRACEABILITY_ID_REGISTRY cho liên kết issue–requirement–test nếu registry cấp ID; COMPETENCY_COVERAGE_MATRIX ghi phân loại và giới hạn thẩm quyền.	Nút “Lưu phiếu nhận” mô phỏng chỉ hiện biểu tượng đĩa mềm. BA đánh dấu rủi ro hiểu sai chức năng và yêu cầu UX designer đánh giá nhãn văn bản hoặc tên truy cập phù hợp; BA không tự chỉ định mã HTML, ARIA hay thành phần thiết kế.	Mỗi nhận định WCAG phải có: quan sát giao diện, tác động người dùng, nguyên tắc liên quan ở mức phù hợp, bằng chứng cần thu thập và owner escalation.	Có thể phát hiện rủi ro accessibility, mô tả tác động bằng ngôn ngữ requirement và chuyển đúng người có chuyên môn.
CCM-UX-04	Accessibility evidence and escalation — Partial. Đọc và rà soát bằng chứng do UX designer, accessibility specialist hoặc QA cung cấp; nhận diện khi cần escalation. Đây là project convention khi quy định format review, checklist, owner và thời điểm review; không được gọi convention là WCAG.	CHAPTER_MANIFEST: chapter solution literacy về UX/accessibility, liên kết chapter testing khi manifest xác định dependency canonical.	TRACEABILITY_ID_REGISTRY để liên kết issue, evidence và owner; không ghi kết luận compliance vào CANONICAL_BUSINESS_RULES khi chưa có thẩm quyền.	Một bản prototype tổng hợp của màn hình điều chỉnh tồn kho không thể thao tác chỉ bằng bàn phím trong buổi review. BA ghi issue, bước tái hiện, tác động dự kiến, ảnh prototype và chuyển UX/accessibility specialist cùng QA; không tự đóng issue.	Evidence phân tách rõ “đã quan sát”, “giả định”, “cần xác minh”; owner và quyết định cần có được nêu rõ; không có tuyên bố đã đạt WCAG hoặc đã được chấp thuận.	Chuẩn bị được gói escalation có thể hành động, bảo toàn traceability và ranh giới trách nhiệm.

Quy tắc phân loại nguồn: WCAG 2.2 Recommendation, bản ngày 2024-12-12 của W3C tại https://www.w3.org/TR/WCAG22/, là nguồn chuẩn tham chiếu cho thuật ngữ và success criterion accessibility. BABOK Guide Version 3 tại nguồn IIBA chỉ hỗ trợ ngôn ngữ năng lực BA và không thay thế WCAG. “Good practice” là cách làm hợp lý như mô tả tác vụ, lỗi và tác động người dùng; “project convention” là quy ước nội bộ dự kiến như mẫu issue hoặc thời điểm review. Cầu nối suy luận là: vì nguồn seed chỉ xác nhận WCAG là Recommendation và không cấp kết quả đánh giá cho giao diện Nova Foods, matrix chỉ cho phép dạy cách tham chiếu và chuẩn bị bằng chứng, không cho phép kết luận đạt chuẩn.

Caveat và xử lý Partial: Tất cả bốn hàng được phân loại Partial vì handbook chỉ dạy BA nhận diện, diễn đạt, truy vết và escalation. BA không có design authority để chọn interaction pattern cuối cùng; không có authority để xác nhận màu sắc, tương phản, keyboard behavior, screen-reader behavior hay sự phù hợp với một WCAG success criterion cụ thể; và không có authority để tuyên bố legal compliance. Nếu requirement tác động người dùng khuyết tật, giao diện khách hàng, giao diện nhân viên có rủi ro an toàn hoặc một tuyên bố “WCAG compliant”, BA phải giữ nhãn Verification required, chuyển UX/accessibility specialist và QA reviewer, đồng thời bảo toàn liên kết tới nguồn WCAG chính thức.

Ma trận năng lực NFR: hiệu năng, sẵn sàng, độ tin cậy, khả năng bảo trì và hỗ trợ

Yêu cầu phi chức năng (Non-Functional Requirements, NFR) mô tả chất lượng và ràng buộc vận hành của giải pháp, thay vì hành vi nghiệp vụ riêng lẻ. Các dòng dưới đây dùng Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; không xác lập ngưỡng vận hành ERP thực tế, cam kết dịch vụ hay quyết định kiến trúc.

Năng lực cần có	Phân loại	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ thực hành tổng hợp	Quality gate	Năng lực người học
Phân rã performance (hiệu năng) thành giao dịch, tải đồng thời, thời gian đáp ứng, điểm đo và điều kiện tải	Core; Partial đối với thiết kế tối ưu kỹ thuật	CHAPTER_MANIFEST: chapter về yêu cầu, acceptance criteria và solution literacy	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; template được đăng ký qua TEMPLATE_MANIFEST	Luồng mô phỏng “lập đơn bán hàng”: phân biệt mục tiêu thời gian phản hồi tại màn hình với thời gian hoàn tất xử lý nền	Mỗi chỉ tiêu phải có tác nhân, giao dịch, điều kiện tải, đơn vị đo, percentile hoặc cách tổng hợp, điểm bắt đầu-kết thúc đo, và nguồn xác nhận ngưỡng	Viết được NFR có thể kiểm thử; không tự chọn cấu hình hạ tầng, cơ chế cache hoặc năng lực máy chủ
Phân tích availability (mức sẵn sàng sử dụng) theo phạm vi dịch vụ, giờ phục vụ, bảo trì có kế hoạch và cách ghi nhận gián đoạn	Core; Partial đối với cam kết SLA và thiết kế dự phòng	CHAPTER_MANIFEST: chapter về stakeholder, yêu cầu và vận hành	CANONICAL_BUSINESS_RULES; traceability theo TRACEABILITY_ID_REGISTRY	Kênh mô phỏng nhận đơn đại lý cần xác định “dịch vụ nào”, “khung giờ nào”, và liệu bảo trì đã báo trước có được loại khỏi phép đo	Không dùng một tỷ lệ phần trăm đứng độc lập; phải nêu phạm vi, cửa sổ thời gian, cách tính, ngoại lệ và Business Owner/Operations Owner cần xác nhận	Phát hiện câu “hệ thống luôn hoạt động” là không kiểm thử được và chuyển thành câu hỏi có cấu trúc
Mô tả reliability (độ tin cậy: hệ thống cho kết quả đúng và ổn định trong điều kiện đã nêu) qua tỷ lệ lỗi, xử lý lặp, khôi phục lỗi và tính nhất quán kết quả	Core; Partial đối với thiết kế retry, queue hoặc cơ chế phân tán	CHAPTER_MANIFEST: chapter về business rule, dữ liệu, requirements và testing handoff	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; test basis theo thuật ngữ ISTQB CTFL	Đồng bộ mô phỏng tồn kho: một yêu cầu gửi lại không được tạo hai lần biến động tồn kho; đây là mục tiêu nghiệp vụ cần kiểm thử, không phải chỉ dẫn chọn công nghệ	Liên kết được NFR với quy tắc nghiệp vụ, dữ liệu bị ảnh hưởng, trạng thái lỗi, hành vi khôi phục và bằng chứng kiểm thử; không suy diễn giải pháp kỹ thuật	Phân biệt lỗi chức năng với chỉ số độ tin cậy, viết acceptance criterion cho tình huống lỗi có thể quan sát
Xác định maintainability (khả năng bảo trì: mức dễ sửa đổi, chẩn đoán và kiểm thử khi thay đổi) bằng yêu cầu về cấu hình, tài liệu, khả năng quan sát và tác động thay đổi	Partial; handbook dạy literacy, không trao quyền thiết kế kiến trúc	CHAPTER_MANIFEST: chapter về traceability, change impact và delivery	TRACEABILITY_ID_REGISTRY; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Thay đổi mô phỏng quy tắc chiết khấu phải truy được từ rule đến dữ liệu, requirement, acceptance criteria và test basis	Requirement phải nêu đối tượng thay đổi, bằng chứng truy vết cần giữ và vai trò xác nhận tác động; Architect/Engineering xác nhận cách hiện thực	Lập được câu hỏi impact analysis và gói escalation; không quyết định module hóa, logging framework hoặc chuẩn mã nguồn
Xác định supportability (khả năng hỗ trợ: mức hệ thống có thể được đội vận hành/hỗ trợ tiếp nhận, chẩn đoán và xử lý) qua cảnh báo, mã lỗi, runbook, dữ liệu chẩn đoán và đường chuyển cấp	Partial; handbook dạy literacy và yêu cầu đầu vào vận hành	CHAPTER_MANIFEST: chapter về operations, handover và governance	TRACEABILITY_ID_REGISTRY; template được đăng ký qua TEMPLATE_MANIFEST	Lỗi mô phỏng “không tạo được phiếu xuất kho” cần có mã tham chiếu, thời điểm, giao dịch bị ảnh hưởng và tuyến chuyển cho đội hỗ trợ, không hiển thị dữ liệu cá nhân thực	Mỗi NFR hỗ trợ phải nêu người dùng thông tin chẩn đoán, thông tin tối thiểu, thời gian lưu giữ do owner có thẩm quyền xác nhận, và tuyến escalation	Chuyển nhu cầu “dễ hỗ trợ” thành điều kiện kiểm tra được; không tự phê chuẩn runbook, quyền truy cập hay thời hạn lưu log

Nguồn chuẩn có phạm vi khác nhau. ISO/IEC/IEEE 29148:2018 là nguồn normative standard (tiêu chuẩn chuẩn tắc) để định hướng chất lượng diễn đạt requirement; do văn bản đầy đủ có thể cần quyền truy cập, không gán số điều khoản khi chưa kiểm chứng văn bản được cấp phép. Các cách đo như percentile phản hồi, tỷ lệ lỗi, cửa sổ sẵn sàng và phân loại incident là good practice (thực hành tốt), chỉ được dùng làm khung câu hỏi và tiêu chí đo. Tên giao dịch Nova Foods, nhãn NFR, lịch phục vụ, ngưỡng số học, cách loại trừ bảo trì và mẫu báo cáo là project convention (quy ước dự án) khi đã được ghi trong artifact kiểm soát; tại v0.9.0, IN_REVIEW, chưa có ngưỡng nào được coi là baseline hoặc đã phê duyệt.

Quy tắc xử lý Partial là tách rõ “BA hiểu để phát hiện, diễn đạt và truy vết” khỏi “vai trò chuyên môn thiết kế và xác nhận”. Cầu nối suy luận là: NFR chỉ kiểm thử được khi có phép đo và điều kiện; nhưng lựa chọn kiến trúc để đạt phép đo đòi hỏi năng lực kỹ thuật và thẩm quyền ngoài BA. Vì vậy, learner phải ghi nhận giả định, câu hỏi quyết định, artifact bị ảnh hưởng và rủi ro nếu chưa có ngưỡng; sau đó escalation tới Architect cho năng lực kỹ thuật, Operations Owner cho vận hành, QA cho khả năng kiểm thử và Business Owner cho mức dịch vụ chấp nhận được.

Hàng năng lực bảo mật: nhận biết rủi ro, đặc tả có truy vết và escalation đúng thẩm quyền

Bảo mật trong handbook được dạy từ nguyên tắc bảo vệ tính bí mật, toàn vẹn và khả dụng của thông tin: chỉ đúng người được truy cập, dữ liệu không bị sửa trái phép và dịch vụ vẫn hoạt động khi cần. BA không thay Security Engineer thiết kế kiểm soát kỹ thuật hoặc xác nhận an toàn hệ thống; BA phải nhận biết rủi ro, hỏi đúng câu hỏi, ghi yêu cầu kiểm chứng được và chuyển quyết định đến đúng vai trò. Cầu nối suy luận là: một luồng nghiệp vụ xử lý người dùng, quyền, dữ liệu hoặc giao dịch thì có khả năng bị truy cập sai, thay đổi sai hoặc lộ dữ liệu; vì vậy backlog, requirement và tiêu chí chấp nhận phải mang thông tin phân loại, rủi ro và chủ thể xác minh.

Năng lực bảo mật	Phân loại	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ làm việc	Quality gate	Năng lực đầu ra của learner
Nhận diện tài sản, dữ liệu và tác nhân cần bảo vệ	Core literacy	CHAPTER_MANIFEST — chapter về phân tích requirement, dữ liệu và stakeholder	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nova Foods mô phỏng: BA ghi nhận trường SupplierContactEmail và BankAccountReference là dữ liệu cần hạn chế hiển thị trong quy trình tạo nhà cung cấp	Mỗi dữ liệu nhạy cảm có mục đích sử dụng, nhóm người truy cập dự kiến, nơi xuất hiện và nhãn Verification required khi chưa có Security hoặc Legal xác minh	Phân biệt dữ liệu nghiệp vụ thông thường với dữ liệu có rủi ro bảo mật; không tự kết luận phân loại pháp lý
Viết yêu cầu kiểm soát truy cập theo vai trò	Core practice; Partial về thiết kế phân quyền	CHAPTER_MANIFEST — chapter về requirement, business rule và acceptance criteria	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nova Foods mô phỏng: vai trò Purchasing Clerk tạo yêu cầu nhà cung cấp, còn Finance Reviewer xem thông tin thanh toán; ví dụ không khẳng định đây là phân quyền ERP thực tế	Requirement phải nêu hành động, vai trò, đối tượng dữ liệu, kết quả bị từ chối khi không đủ quyền và evidence kiểm thử; không dùng câu mơ hồ như “hệ thống phải an toàn”	Chuyển nhu cầu “chỉ người phù hợp được xem” thành điều kiện kiểm thử được; không tự thiết kế mô hình quyền, cơ chế xác thực hoặc cấu hình hệ thống
Nhận biết rủi ro ứng dụng và API theo OWASP	Awareness; Partial về đánh giá kỹ thuật	CHAPTER_MANIFEST — chapter về solution literacy, integration và rủi ro	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nova Foods mô phỏng: khi yêu cầu tra cứu đơn mua theo mã đơn, BA đặt câu hỏi liệu người dùng chỉ xem được đơn thuộc phạm vi được cấp quyền, nhằm nhận biết nguy cơ truy cập đối tượng sai quyền	Mỗi rủi ro được mô tả bằng tài sản, tác nhân, hành vi không mong muốn, hậu quả và owner xử lý; tham chiếu OWASP chỉ ở mức nhận biết, không tuyên bố lỗ hổng đã tồn tại	Nhận biết các chủ đề OWASP API Security Top 10 2023 như kiểm soát truy cập theo đối tượng, xác thực và lộ dữ liệu quá mức; biết khi nào cần Security review
Ghi nhận yêu cầu bảo mật và tiêu chí chấp nhận có thể xác minh	Core practice	CHAPTER_MANIFEST — chapter về requirement quality, acceptance criteria và traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Nova Foods mô phỏng: “Khi người dùng không có quyền xem thông tin thanh toán nhà cung cấp, hệ thống không trả về giá trị đó trên màn hình hoặc trong kết quả xuất dữ liệu.”	Requirement liên kết được với rủi ro, dữ liệu bị ảnh hưởng, test basis và owner xác minh; tiêu chí không tiết lộ secret, token, mật khẩu hoặc dữ liệu cá nhân tổng hợp ngoài mục đích ví dụ	Viết được requirement và acceptance criterion ở mức hành vi quan sát được; không chọn thuật toán mã hóa, cấu hình log hoặc công cụ quét bảo mật
Chuẩn bị escalation bảo mật và bảo vệ bằng chứng	Core governance	CHAPTER_MANIFEST — chapter về governance, risk, issue và escalation	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nova Foods mô phỏng: BA phát hiện yêu cầu xuất danh sách nhà cung cấp chưa xác định người nhận, mục đích và thời hạn lưu tệp; BA lập gói câu hỏi cho Security Owner và Legal Owner	Gói escalation có bối cảnh, artifact bị ảnh hưởng, dữ liệu tổng hợp minh họa, rủi ro, câu hỏi quyết định, vai trò cần phản hồi và tác động nếu chưa xác minh	Không che giấu rủi ro bằng giả định; duy trì traceability trong khi chờ quyết định có thẩm quyền

Loại nguồn	Cách phân loại trong ma trận	Cách dùng và giới hạn
Chuẩn hoặc nghĩa vụ có tính chuẩn tắc	Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý chính thức; nội dung requirement suy ra từ đó luôn mang nhãn Verification required cho đến khi Legal Owner xác minh	BA ghi nguồn, bối cảnh dữ liệu và câu hỏi cần quyết định; không diễn giải luật thành cấu hình ERP hoặc kết luận tuân thủ
Tiêu chuẩn xác minh bảo mật ngành	OWASP ASVS 5.0.0 là chuẩn xác minh bảo mật ngành, không phải luật Việt Nam	Dùng để định hướng câu hỏi kiểm soát và phạm vi review; Security Owner quyết định mức áp dụng, bằng chứng và kết luận
Good practice nhận biết rủi ro	OWASP API Security Top 10 2023 là tài liệu good practice/awareness, không phải checklist chứng nhận	Dùng để phát hiện dấu hiệu cần hỏi sâu hơn, đặc biệt khi có API, quyền truy cập hoặc dữ liệu nhạy cảm; không dùng để tuyên bố API “an toàn”
Project convention	Nhãn dữ liệu, cấu trúc risk log, format escalation và cách liên kết ID là quy ước corpus Nova Foods mô phỏng	Chỉ tạo tính nhất quán học liệu; không thay thế chính sách bảo mật, quyết định kiến trúc hoặc quy trình vận hành thực tế

Các hàng được gắn Partial khi handbook chỉ dạy năng lực đọc hiểu và chuyển giao đúng: learner có thể nhận biết vấn đề, mô tả tác động nghiệp vụ, tạo traceability và triệu tập đúng owner, nhưng không có design authority đối với kiến trúc xác thực, quản lý khóa, mã hóa, cấu hình phân quyền, kiểm thử xâm nhập hoặc chấp nhận rủi ro. Escalation là bắt buộc khi yêu cầu liên quan dữ liệu cá nhân, bí mật xác thực, quyền truy cập đặc quyền, truyền dữ liệu ra ngoài ranh giới hệ thống, phát hiện khả năng truy cập trái phép, hoặc khi business value mâu thuẫn với kiểm soát bảo mật. Security Owner đánh giá kiểm soát kỹ thuật và rủi ro; Legal Owner xác minh nghĩa vụ pháp lý; Architect xác định ranh giới giải pháp; BA giữ nguyên nhãn chưa xác minh và không tự đóng quyết định.

Ma trận ánh xạ cho từng competency: phân loại, chapter, artifact, ví dụ, quality gate, năng lực người học

Bảng dưới đây chuẩn hóa cách đọc mỗi competency theo cùng một khung ra quyết định. Classification là nhãn quản trị cho biết nội dung thuộc Normative (chuẩn bắt buộc từ nguồn gốc thẩm quyền như OpenAPI Specification, WCAG, OWASP ASVS), Good practice (thực hành tốt ngành, có giá trị định hướng nhưng không phải nghĩa vụ pháp lý), hay Project convention (quy ước của corpus Nova Foods để đồng bộ học liệu). Chapter mapping chỉ chapter/khối học liệu sẽ chứa năng lực đó trong handbook. Artifact mapping chỉ các tệp kiểm soát đang là nguồn chân lý liên quan. Worked example mapping chỉ ví dụ mô phỏng Nova Foods dùng dữ liệu tổng hợp. Quality gate là điều kiện qua cổng trước khi learner được coi là đạt mức đọc hiểu. Learner capability mô tả điều learner làm được ở mức zero-entry, tức biết nhận diện, mô tả và chuyển giao đúng, chưa mặc định có quyền thiết kế.

Competency	Classification	Chapter mapping	Artifact mapping	Worked example mapping	Quality gate	Learner capability
API và integration, gồm OpenAPI-oriented literacy	Partial; OpenAPI là Normative, còn cách BA trình bày trong handbook là Good practice để đọc và chuyển giao	Chapter về APIs/integration trong phần solution literacy	CANONICAL_DATA_DICTIONARY.md, TRACEABILITY_ID_REGISTRY.md	Nova Foods mô phỏng luồng đơn hàng bán ra qua API đơn giản giữa ERP và kênh bán hàng	Learner đọc được endpoint, request/response, parameter, status code, và biết chỗ nào cần hỏi Solution Architect hoặc API Owner	Mô tả được dữ liệu vào/ra, nhận biết rủi ro tích hợp, ghi traceability, không tự thiết kế API hoặc quyết định bảo mật
Architecture literacy: context, component, boundary	Partial; UML là Normative về ký hiệu nếu dùng đúng ngữ nghĩa, còn mức BA ở đây chủ yếu là Good practice để hiểu cấu trúc	Chapter về architecture literacy trong phần solution literacy	01_CURRICULUM_ARCHITECTURE.md, CHAPTER_MANIFEST.md	Nova Foods mô phỏng sơ đồ ngữ cảnh cho phân hệ bán hàng, kho và kế toán	Learner phân biệt context, component, boundary, data flow và ranh giới thẩm quyền	Đọc được sơ đồ, giải thích được luồng nghiệp vụ qua thành phần, và biết khi nào phải escalte sang Architect
UX và accessibility (khả năng sử dụng và tiếp cận), có xét WCAG	Partial; WCAG là Normative, còn handbook chỉ dạy mức đọc hiểu và kiểm tra dấu hiệu	Chapter về UX/accessibility trong phần solution literacy	TEMPLATE_MANIFEST.md, CANONICAL_DATA_DICTIONARY.md nếu có field hiển thị/chọn lọc	Nova Foods mô phỏng màn hình nhập đơn hàng có nhãn, tab order và thông báo lỗi	Learner nhận ra vi phạm khả năng tiếp cận như thiếu nhãn, tương phản yếu, lỗi không rõ, thao tác bàn phím kém	Mô tả được vấn đề trải nghiệm và khả năng tiếp cận, tạo issue đúng ngôn ngữ, không tự xác nhận “đạt WCAG”
Non-functional requirements (NFR, yêu cầu phi chức năng): performance, availability, reliability, maintainability, supportability	Good practice; một số chỉ tiêu có thể thành yêu cầu dự án nhưng handbook không tự biến chúng thành cam kết vận hành	Chapter về NFR trong phần solution literacy	CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md	Nova Foods mô phỏng SLA phản hồi báo cáo bán hàng cuối ngày và tiêu chí khả dụng của màn hình nhập liệu	Learner phân biệt mục tiêu đo lường, ngưỡng chấp nhận, và giả định vận hành	Chuyển yêu cầu kinh doanh thành tiêu chí NFR có thể kiểm tra, nhưng không tự đặt benchmark kỹ thuật hay cam kết hạ tầng
Security awareness: OWASP, ranh giới leo thang, quyền truy cập	Partial; OWASP ASVS và OWASP API Security Top 10 là Good practice, còn nghĩa vụ pháp lý chỉ phát sinh khi Legal/Owner xác minh	Chapter về security awareness trong phần solution literacy	TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES.md, các nhãn xác minh pháp lý nếu có	Nova Foods mô phỏng quyền truy cập báo cáo tài chính và dữ liệu cá nhân của khách hàng	Learner phát hiện dấu hiệu dữ liệu nhạy cảm, quyền đặc quyền, API lộ thông tin, hoặc kiểm soát truy cập yếu	Mô tả rủi ro, giữ nguyên nhãn chưa xác minh, và escalte đúng owner; không tự kết luận an toàn hay hợp pháp

Quy tắc đọc bảng này là: nếu Classification là Normative, learner phải bám theo chuẩn gốc và chỉ diễn giải ở mức BA; nếu là Good practice, learner dùng để định hướng thiết kế trao đổi với team; nếu là Partial, handbook chỉ cấp năng lực quan sát, mô tả và chuyển giao, không cấp quyền quyết định thiết kế. Với Nova Foods, mọi ví dụ đều là mô phỏng giáo dục, dữ liệu tổng hợp, không phải cấu hình ERP thực tế.

Quy tắc phân biệt tiêu chuẩn chuẩn tắc, thực hành tốt và quy ước dự án trong các hàng năng lực giải pháp

Mỗi hàng trong ma trận phải gắn một Source classification duy nhất cho từng phát biểu có tính hướng dẫn, vì cùng một chủ đề có thể dùng nhiều nguồn nhưng không có cùng mức bắt buộc. Cầu nối suy luận là: nguồn ban hành và trạng thái công bố quyết định loại nguồn; loại nguồn quyết định cách diễn đạt năng lực, mức bằng chứng cần có và vai trò được phép xác nhận. BA không được nâng một khuyến nghị kỹ thuật thành nghĩa vụ pháp lý, cũng không được hạ một nghĩa vụ pháp lý đã xác minh thành lựa chọn tùy ý của dự án.

Phân loại nguồn	Định nghĩa dùng trong ma trận	Nguồn áp dụng đã xác minh	Cách ghi yêu cầu hoặc năng lực	Ranh giới quyết định
Tiêu chuẩn chuẩn tắc (normative standard: tài liệu quy định cú pháp, ngữ nghĩa hoặc tiêu chí chính thức trong phạm vi do tổ chức ban hành xác định)	Dùng khi learner phải đọc, đối chiếu hoặc áp dụng đúng một quy ước kỹ thuật được nguồn chính thức xác định. “Chuẩn tắc” không tự động có nghĩa là luật Việt Nam.	OpenAPI Specification OAS 3.1.1 cho mô tả HTTP API; WCAG 2.2 Recommendation cho tiêu chí truy cập số; BPMN 2.0.2 và UML 2.5.1 khi gọi đúng tên và ngữ nghĩa ký pháp.	Ghi rõ tên, phiên bản nguồn và hành động kiểm chứng, ví dụ: “Đối chiếu mô tả API với cấu trúc OAS 3.1.1.” Không ghi “tuân thủ đầy đủ” nếu chưa có phạm vi, bằng chứng và người xác nhận.	BA học cách nhận diện, đặt câu hỏi và truy vết; Architect, UX/accessibility specialist hoặc vai trò được chỉ định xác nhận quyết định thiết kế và mức tuân thủ.
Nghĩa vụ pháp lý cần xác minh	Dùng cho nguồn luật, nghị định Việt Nam có thể tạo nghĩa vụ, nhưng việc chuyển văn bản pháp lý thành yêu cầu hệ thống cần diễn giải có thẩm quyền.	Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP về bảo vệ dữ liệu cá nhân; các nguồn pháp lý khác trong verified primary-source seed khi liên quan.	Gắn nhãn Verification required; ghi nguồn, tình huống giả định và câu hỏi cần quyết định. Không tự suy ra thời hạn lưu trữ, cơ chế đồng ý, quyền truy cập hay cấu hình hệ thống.	Legal/Compliance Owner xác minh cách diễn giải; Security và Architect đánh giá biện pháp kỹ thuật; BA duy trì traceability và tác động requirement.
Thực hành tốt ngành (good practice: cách làm được cộng đồng chuyên môn khuyến nghị nhưng không tự thân là luật, hợp đồng hoặc quy định dự án)	Dùng để định hướng nhận diện rủi ro, chất lượng và câu hỏi rà soát. Giá trị của nó nằm ở việc giúp BA phát hiện điểm cần làm rõ, không thay quyền phê duyệt thiết kế.	OWASP ASVS 5.0.0 là chuẩn kiểm chứng an ninh ngành; OWASP API Security Top 10 2023 là nguồn nhận thức và thực hành tốt; BABOK Guide Version 3 là nguồn thuật ngữ, nhiệm vụ và năng lực BA.	Dùng động từ “tham chiếu”, “nhận diện”, “đề xuất câu hỏi kiểm chứng”, “escalate”. Ví dụ: “Nhận diện nguy cơ kiểm soát truy cập không phù hợp và chuyển Security review.”	Security Owner quyết định kiểm soát an ninh; Architect quyết định giải pháp kỹ thuật; BA không xác nhận API là an toàn hoặc đạt ASVS.
Quy ước dự án (project convention: quy tắc nhất quán nội bộ được corpus hoặc dự án công bố để phối hợp làm việc)	Dùng cho tên tệp, định danh, trạng thái tài liệu, cấu trúc template, cách liên kết và cách ghi nhãn xác minh. Quy ước tạo tính nhất quán, không thay thế tiêu chuẩn kỹ thuật hay nghĩa vụ pháp lý.	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, cùng metadata corpus hiện hành.	Ghi chính xác ID, đường dẫn, trạng thái và ranh giới: IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND.	Principal IT Business Analyst / Technical Curriculum Author duy trì quản trị artifact, nhưng không có quyền biến quy ước thành approval, baseline, quyết định kiến trúc, xác nhận bảo mật hoặc xác nhận pháp lý.

Quy tắc diễn đạt trong ma trận là: chỉ dùng từ “bắt buộc” khi nghĩa vụ đã có nguồn phù hợp, phạm vi áp dụng và vai trò xác nhận được ghi rõ; chỉ dùng “nên” cho thực hành tốt; dùng “phải theo quy ước corpus” khi điều đang kiểm soát là định danh, tệp, trạng thái hoặc traceability nội bộ. Căn cứ là OpenAPI, WCAG, BPMN và UML có nguồn phát hành chính thức cho lĩnh vực chuyên môn tương ứng, trong khi OWASP API Security Top 10 được nguồn seed phân loại rõ là awareness/good practice, còn các tệp manifest và registry chỉ là controlled planning artifact ở trạng thái IN_REVIEW.

Ví dụ mô phỏng Nova Foods Trading & Manufacturing, chỉ dùng dữ liệu tổng hợp: nếu một learner thấy tài liệu giao tiếp giữa ERP và dịch vụ vận chuyển mô tả endpoint HTTP, learner có thể đối chiếu cấu trúc mô tả với OAS 3.1.1 theo phân loại tiêu chuẩn chuẩn tắc. Nếu learner phát hiện endpoint cho phép xem đơn giao hàng mà chưa nêu phạm vi quyền truy cập, learner dùng OWASP API Security Top 10 như thực hành tốt để lập câu hỏi rủi ro và escalation tới Security Owner, không kết luận có lỗ hổng. Nếu tài liệu yêu cầu liên kết với artifact khác, learner phải dùng đúng TRACEABILITY_ID_REGISTRY theo quy ước dự án, nhưng không được suy ra rằng liên kết đó đã được phê duyệt.

Mọi hàng dùng luật về dữ liệu cá nhân phải giữ nhãn Verification required cho đến khi Legal/Compliance Owner xác nhận cách áp dụng vào tình huống cụ thể. Mọi hàng dùng tiêu chuẩn kỹ thuật hoặc thực hành tốt chỉ dạy năng lực đọc hiểu, đối chiếu và chuyển vấn đề đúng vai trò nếu handbook chưa trao thẩm quyền thiết kế. Cách xử lý này bảo đảm learner có thể làm việc độc lập trong việc thu thập bằng chứng và bảo toàn truy vết, đồng thời không vượt ranh giới quyết định của Architect, Security, Legal/Compliance, UX/accessibility specialist hoặc Business Owner.

Kế hoạch xử lý các năng lực Partial khi handbook chỉ dạy hiểu biết, không trao thẩm quyền thiết kế

Partial là phân loại cho năng lực mà learner được học đủ để nhận diện vấn đề, đọc artifact, đặt câu hỏi đúng và kích hoạt escalation, nhưng chưa được dạy hoặc không được phép tự ra quyết định thiết kế, xác minh chuyên môn, phê chuẩn hay triển khai. Cầu nối suy luận là: các chủ đề giải pháp có thể ảnh hưởng đến kiến trúc, bảo mật, tuân thủ hoặc vận hành; trong khi các artifact nguồn đều xác định Principal IT Business Analyst / Technical Curriculum Author không thay thế Architect, Security, Legal, QA, Accounting hoặc Business Owner. Vì vậy, ma trận không được ghi “đạt” nếu learner chỉ có khả năng diễn giải ở mức nhận biết.

Trường ma trận bắt buộc cho dòng Partial	Cách ghi nhận kế hoạch	Tiêu chí chất lượng của dòng
Classification	Ghi Partial — literacy only hoặc Partial — analysis and escalation; không dùng Full chỉ vì learner có thể điền biểu mẫu.	Có nêu rõ việc learner làm được, không làm được và vai trò có thẩm quyền quyết định.
Chapter mapping	Liên kết đến chapter trong CHAPTER_MANIFEST dạy cách đọc, phân tích hoặc chuẩn bị câu hỏi; không suy diễn chapter đó trao quyền thiết kế.	Tên chapter và định danh phải lấy nguyên dạng từ /01-curriculum/CHAPTER_MANIFEST.md khi manifest cung cấp.
Artifact mapping	Liên kết artifact phân tích, checklist, issue log hoặc escalation package; không liên kết trực tiếp tới quyết định kỹ thuật như thể đó là output do BA tự phê duyệt.	Giữ nguyên Artifact ID và filename canonical, gồm /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md khi phù hợp.
Worked example mapping	Dùng tình huống Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, để learner nhận biết thiếu thông tin hoặc xung đột.	Ví dụ phải kết thúc bằng câu hỏi/escalation có người nhận, không kết thúc bằng một quyết định triển khai do learner tự đưa ra.
Quality gate	Kiểm tra ranh giới thẩm quyền, nguồn tham chiếu, nhãn giả định và khả năng truy vết từ vấn đề đến người có thẩm quyền.	Không có yêu cầu pháp lý, bảo mật, kiến trúc hoặc vận hành nào bị trình bày là đã xác nhận khi chưa có evidence phù hợp.
Learner capability	Mô tả bằng động từ quan sát được: nhận diện, phân loại, so sánh, diễn giải, truy vết, chuẩn bị câu hỏi, ghi nhận rủi ro và escalation.	Không dùng động từ trao thẩm quyền như phê duyệt, chứng nhận tuân thủ, quyết định kiến trúc, ký thiết kế hoặc cho phép production.

Mức năng lực Partial	Learner được thực hiện trong handbook	Learner không được tự thực hiện	Điểm nhận bàn giao/escalation
Partial — literacy only	Đọc thuật ngữ, xác định thành phần artifact, diễn giải tác động nghiệp vụ sơ bộ và nêu câu hỏi cần làm rõ.	Không tạo specification có giá trị triển khai, không chọn giải pháp kỹ thuật, không xác nhận đáp ứng chuẩn.	Chuyển Architect, Security, UX/accessibility specialist, QA hoặc owner chuyên môn tương ứng.
Partial — analysis and escalation	Đối chiếu requirement với artifact hiện có, phát hiện mâu thuẫn, ghi rủi ro và chuẩn bị evidence mô phỏng.	Không tự đóng issue dựa trên nhận định cá nhân, không tự chấp nhận trade-off rủi ro.	Gửi gói escalation gồm requirement liên quan, artifact bị ảnh hưởng, nguồn, giả định, câu hỏi đơn nghĩa và hậu quả nếu chưa quyết định.
Partial — controlled contribution	Soạn phần đầu vào BA như business context, acceptance intent, dữ liệu tổng hợp minh họa hoặc traceability link.	Không sửa phần kết luận chuyên môn của người có thẩm quyền, không biến đầu vào BA thành sign-off.	Người chịu trách nhiệm chuyên môn rà soát và quyết định; ma trận chỉ ghi nhận learner đã chuẩn bị đầu vào đúng ranh giới.

Phân loại nguồn phải được ghi ngay trên từng dòng Partial để tránh nhầm giữa tiêu chuẩn bắt buộc, thực hành tốt và quy ước dự án. “Normative standard” là tiêu chuẩn có nội dung chuẩn tắc, ví dụ OpenAPI Specification OAS 3.1.1 của OpenAPI Initiative hoặc WCAG 2.2 Recommendation của W3C; learner chỉ học cách nhận diện phạm vi và tham chiếu đúng nguồn, còn việc tuyên bố một thiết kế đáp ứng tiêu chuẩn cần người có thẩm quyền và bằng chứng kiểm tra. “Good practice” là thực hành tốt của ngành, ví dụ OWASP ASVS 5.0.0 và OWASP API Security Top 10 bản 2023; không được trình bày là luật Việt Nam hoặc tự động thành nghĩa vụ dự án. “Project convention” là quy ước được corpus hoặc dự án ghi nhận, như cấu trúc tên artifact, cách dùng ID và nhãn Verification required; quy ước này hỗ trợ nhất quán nhưng không thay thế tiêu chuẩn, luật hoặc quyết định chuyên môn.

Điều kiện phát hiện trong bài học hoặc ví dụ mô phỏng Nova Foods	Phân loại phải giữ	Xử lý Partial bắt buộc	Bằng chứng tối thiểu để qua quality gate
Learner có thể đọc một artifact nhưng không có nguồn hoặc năng lực để kiểm chứng tính đúng đắn chuyên môn.	Partial — literacy only	Ghi rõ “đọc và đặt câu hỏi, không xác minh thiết kế”; chỉ định vai trò xác minh.	Link nguồn chính thức, câu hỏi cần xác minh và vai trò nhận escalation.
Một yêu cầu liên quan dữ liệu cá nhân, bảo mật, kiến trúc, kế toán, thuế, hóa đơn hoặc an toàn thực phẩm.	Partial — analysis and escalation	Giữ nhãn Verification required; không chuyển giả định thành requirement bắt buộc.	Artifact bị ảnh hưởng, nguồn chính thức áp dụng, giả định hiện tại và Legal/Security/Accounting/domain owner nhận xử lý.
Learner đề xuất một phương án có trade-off chi phí, hiệu năng, khả dụng hoặc rủi ro.	Partial — controlled contribution	Cho phép mô tả tác động và câu hỏi quyết định; không cho phép chọn phương án cuối cùng.	Danh sách phương án, tiêu chí đánh giá, rủi ro còn lại và Architect hoặc owner có thẩm quyền quyết định.
Không có nguồn canonical, Artifact ID chưa đăng ký hoặc traceability mâu thuẫn.	Partial — blocked	Dừng chuyển năng lực sang trạng thái hoàn thành; không tạo ID, rule hoặc quyết định thay thế.	Vấn đề được ghi nhận để xử lý theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; các liên kết canonical được xác minh trước khi tiếp tục.

Ví dụ làm việc cho Nova Foods chỉ dùng dữ liệu tổng hợp: learner nhận một mô tả rằng màn hình mô phỏng “Theo dõi đơn giao hàng” có thể cần hiển thị trạng thái đơn. Nếu chưa có nguồn xác nhận quyền xem trạng thái, learner ở mức Partial được phép xác định dữ liệu, actor và rủi ro truy cập; liên kết câu hỏi với /01-curriculum/CANONICAL_DATA_DICTIONARY.md; và chuyển Security cùng Architect xác định cơ chế phân quyền. Learner không được tự tuyên bố quyền truy cập, xác nhận bảo mật, hoặc thiết kế cấu trúc phân quyền. Quality gate đạt khi ví dụ phân biệt được điều learner quan sát với điều cần chuyên gia quyết định, giữ nhãn dữ liệu tổng hợp và không hàm ý Nova Foods có cấu hình ERP thực tế.

Delivery, testing, traceability, operations, governance, leadership, and AI-assisted work

Phạm vi micro-batch này chỉ lập kế hoạch các hàng năng lực về phân phối linh hoạt (Agile delivery: phân nhỏ giá trị để nhận phản hồi sớm và điều chỉnh) và phân phối dự báo (predictive delivery: lập kế hoạch theo các giai đoạn, phạm vi và điểm kiểm soát xác định trước). Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục, mọi đơn hàng, vai trò và dữ liệu minh họa đều là dữ liệu tổng hợp; không suy diễn đây là quy trình ERP thực tế.

Cầu nối nguồn cho các hàng dưới đây là: BABOK Guide Version 3 cho thuật ngữ, nhiệm vụ và năng lực BA; ISO/IEC/IEEE 29148:2018 cho bối cảnh quản lý thông tin yêu cầu. Hai nguồn xác nhận giá trị của phân tích yêu cầu có kiểm soát, nhưng không tự chọn Agile hay predictive cho Nova Foods. Vì lựa chọn phương pháp delivery phụ thuộc độ ổn định phạm vi, nhịp phản hồi, ràng buộc hợp đồng và năng lực tổ chức, learner chỉ được phân tích bằng chứng và đề xuất phương án; quyết định áp dụng thuộc thẩm quyền delivery owner và Business Owner.

Năng lực cần có	Phân loại coverage	Chapter mapping	Artifact mapping	Worked example mapping	Quality gate	Learner capability
Phân biệt Agile delivery với predictive delivery theo dấu hiệu công việc	Core	CHAPTER_MANIFEST.md: chapter có phạm vi delivery approach, lifecycle và BA planning	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/COMPETENCY_COVERAGE_MATRIX.md	So sánh hai cách xử lý yêu cầu mô phỏng “cập nhật trạng thái đơn giao hàng”: thay đổi thường xuyên thì đề xuất vòng phản hồi ngắn; phạm vi ổn định và cần mốc bàn giao rõ thì đề xuất kế hoạch giai đoạn	Nêu tối thiểu ba bằng chứng: độ ổn định yêu cầu, tần suất phản hồi nghiệp vụ, và mức độ phụ thuộc; không kết luận phương pháp tối ưu khi chưa có owner quyết định	Giải thích được phương pháp là cách tổ chức công việc, không phải nhãn chất lượng hay quyền bỏ qua phân tích
Hỗ trợ Agile backlog refinement, tức làm rõ và chuẩn bị danh sách hạng mục công việc trước khi chọn thực hiện	Core	CHAPTER_MANIFEST.md: chapter có phạm vi Agile BA, requirements lifecycle và stakeholder collaboration	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Với hạng mục mô phỏng “hiển thị ngày giao dự kiến”, learner tách actor, mục tiêu, dữ liệu cần đọc, quy tắc còn cần xác minh và điều kiện chấp nhận ở mức dự kiến	Mỗi hạng mục liên kết được đến nguồn rule hoặc data canonical hiện có; điểm chưa có nguồn phải ghi Verification required, không biến thành quy tắc Nova Foods	Viết được hạng mục rõ giá trị nghiệp vụ, phát hiện câu hỏi mở và chuẩn bị nội dung để nhóm liên quan thảo luận
Hỗ trợ lập kế hoạch vòng lặp Agile và phân nhỏ phạm vi theo giá trị có thể quan sát	Core	CHAPTER_MANIFEST.md: chapter có phạm vi Agile delivery planning và decomposition	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Chia luồng mô phỏng theo dõi giao hàng thành xem danh sách, xem chi tiết và hiển thị trạng thái; không mặc định thiết kế màn hình, API hoặc quyền truy cập	Phần chia nhỏ giữ được mục tiêu nghiệp vụ và dependency; không dùng nhãn “hoàn thành” cho hạng mục thiếu nguồn dữ liệu, rule hoặc quyết định kiến trúc	Tạo được đề xuất lát cắt công việc nhỏ, nhận biết dependency và nêu rõ phần chưa thể cam kết
Điều hành trao đổi phản hồi trong Agile theo ranh giới vai trò BA	Partial — controlled contribution	CHAPTER_MANIFEST.md: chapter có phạm vi Agile collaboration, facilitation và stakeholder engagement	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Learner ghi nhận phản hồi mô phỏng từ Kho và Bán hàng rằng tên trạng thái giao hàng khó hiểu; learner chuyển phản hồi thành câu hỏi, tác động và lựa chọn cần owner quyết định	Biên bản phân biệt rõ phản hồi, giả định, câu hỏi và quyết định; không ghi nhận đồng thuận là approval hoặc tự đóng tranh chấp liên phòng ban	Chuẩn bị và điều phối thảo luận có cấu trúc; escalation khi phản hồi thay đổi mục tiêu, phạm vi hoặc thẩm quyền
Lập cấu trúc delivery predictive theo phase, deliverable và decision gate	Core	CHAPTER_MANIFEST.md: chapter có phạm vi predictive delivery, BA planning và requirements lifecycle	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/CHAPTER_MANIFEST.md	Lập luồng mô phỏng: khám phá nhu cầu, phân tích yêu cầu, review nội dung, xây dựng, kiểm tra và chuyển giao; mỗi phase nêu đầu vào, đầu ra và vai trò xem xét	Không gọi phase gate là approval khi chưa có tham chiếu approval; đầu ra phải có nguồn và owner chịu trách nhiệm review	Mô tả được logic tuần tự của delivery dự báo và điều kiện thông tin cần có trước khi chuyển phase
Chuẩn bị gói yêu cầu cho predictive delivery mà không tự tạo baseline	Core	CHAPTER_MANIFEST.md: chapter có phạm vi requirement specification, review và predictive handoff	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Với yêu cầu mô phỏng “ghi nhận trạng thái giao hàng”, learner lập gói gồm mục tiêu, actor, dữ liệu tham chiếu, quy tắc liên quan, điểm chưa xác minh và vai trò review	Gói phân biệt requirement, project assumption và Verification required; không dùng từ “baseline”, “đã phê duyệt” hoặc “sẵn sàng production” tại IN_REVIEW	Chuẩn bị được bộ thông tin nhất quán để reviewer đánh giá mà không vượt thẩm quyền Business Owner, Architect, QA hoặc Legal
Nhận diện điều kiện cần chuyển từ Agile sang predictive, hoặc kết hợp hai cách tiếp cận	Partial — controlled contribution	CHAPTER_MANIFEST.md: chapter có phạm vi delivery approach selection và governance boundary	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Learner ghi nhận rằng phần hiển thị trạng thái có phản hồi thay đổi nhanh, còn phần liên quan dữ liệu kế toán hoặc pháp lý có nguồn và kiểm soát chuyên môn khác; learner lập phân tích tác động, không chọn mô hình cuối cùng	Có bằng chứng cho từng phần công việc, dependency và rủi ro nếu dùng sai nhịp delivery; quyết định mô hình phải được escalation đến delivery owner cùng các owner chuyên môn liên quan	Đề xuất được phương án có điều kiện và diễn đạt trade-off rõ ràng, không áp đặt Agile hoặc predictive bằng sở thích cá nhân

Với hai hàng Partial — controlled contribution, kế hoạch xử lý là giữ learner ở vai trò chuẩn bị bằng chứng thay vì quyết định: learner được lập câu hỏi, mô tả tác động đến phạm vi và dependency, và chỉ ra owner cần xử lý. Lý do là quyết định cách vận hành delivery có thể ảnh hưởng cam kết nguồn lực, lịch bàn giao, kiểm soát thay đổi và trách nhiệm liên phòng ban; các tác động đó vượt thẩm quyền của BA learner. Quality gate chỉ đạt khi gói escalation dẫn chiếu đúng artifact canonical, ghi rõ dữ liệu tổng hợp, và không tạo approval, baseline hoặc quyết định Nova Foods ngầm định.

Kế hoạch các dòng năng lực ước lượng và ưu tiên hoá

Ước lượng (estimation) là dự báo có căn cứ về quy mô, nỗ lực, thời lượng, chi phí hoặc mức bất định; nó không phải cam kết giao hàng. Ưu tiên hoá (prioritization) là sắp thứ tự thực hiện theo giá trị, rủi ro, tính cấp thiết và năng lực thực hiện hữu hạn. Cầu nối suy luận là: Nova Foods là case study ERP mô phỏng, nên một thay đổi như kiểm tra hạn dùng có thể có giá trị vận hành cao nhưng vẫn phải được so sánh minh bạch với rủi ro, dependency và năng lực nhóm; BA không tự quyết định ngân sách, phạm vi baseline hay thứ tự triển khai thực tế.

ID dòng năng lực kế hoạch	Năng lực và phân loại	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ làm việc	Quality gate	Năng lực đầu ra của learner
CCM-05-EST-01	Ước lượng Agile, Core. Agile là cách phát triển lặp ngắn, trong đó nhóm dùng đơn vị tương đối như story point để so sánh độ lớn và độ phức tạp, không quy đổi mặc định thành giờ.	Chapter entry về delivery Agile trong CHAPTER_MANIFEST; việc dùng ID/tên chapter chỉ được chốt theo manifest, không tự tạo ID chapter.	Backlog có trường ước lượng; liên kết requirement, rule và dependency qua TRACEABILITY_ID_REGISTRY. Business rule tham chiếu đúng CANONICAL_BUSINESS_RULES.	User story mô phỏng: “Nhân viên kho ghi nhận lô hàng nhập có ngày hết hạn.” Nhóm so sánh với story tham chiếu đã hiểu rõ, tách phần nhập liệu, kiểm tra dữ liệu và hiển thị cảnh báo; kết quả minh hoạ là 8 story point, kèm nhãn giả định về giao diện và dữ liệu lô.	Mỗi estimate phải ghi đơn vị, phạm vi, giả định, dependency, mức tin cậy và người/nhóm cung cấp estimate. BA không đổi 8 story point thành số ngày công nếu nhóm chưa cung cấp dữ liệu năng lực lịch sử.	Có thể điều phối làm rõ story, tách story quá lớn, ghi nhận bất định và truyền đạt vì sao estimate thay đổi khi hiểu biết thay đổi.
CCM-05-EST-02	Ước lượng predictive, Core. Predictive là cách lập kế hoạch dựa trên phạm vi được mô tả trước để dự báo công sức, lịch và chi phí; dự báo phải phân biệt với phê duyệt ngân sách hoặc cam kết hợp đồng.	Chapter entry về delivery predictive trong CHAPTER_MANIFEST; phụ thuộc nội dung requirement và data đã được truy vết.	Estimate basis gồm phạm vi, WBS ở mức công việc, giả định, constraint, dependency và phiên bản nguồn; liên kết ID qua TRACEABILITY_ID_REGISTRY. Thuật ngữ dữ liệu tham chiếu CANONICAL_DATA_DICTIONARY.	Thay đổi mô phỏng “bổ sung trường ExpiryDate cho dữ liệu lô hàng”: BA tách việc phân tích, đặc tả, cấu hình giả định, kiểm thử và UAT. Nếu chưa có xác nhận kiến trúc hoặc năng lực đội ngũ, BA ghi “Verification required”, không gán số giờ như một sự thật.	Có breakdown phạm vi; không đếm trùng hạng mục; mỗi estimate có basis và ngày hiệu lực; rủi ro hoặc dependency chưa quyết định phải làm lộ phần dự phòng thay vì che trong một con số tổng.	Có thể xây dựng estimate basis có thể kiểm tra lại, giải thích chênh lệch giữa bản dự báo và phạm vi mới, và escalation khi quyết định vượt thẩm quyền BA.
CCM-05-PRI-01	Ưu tiên theo giá trị, cấp thiết, rủi ro và dependency, Core. Không dùng một điểm số duy nhất để che khuất mâu thuẫn giữa các tiêu chí.	Chapter entry về lập kế hoạch delivery và quản lý backlog/phạm vi trong CHAPTER_MANIFEST.	Priority register liên kết backlog item với requirement, business rule, rủi ro, dependency và quyết định. Rule chỉ tham chiếu từ CANONICAL_BUSINESS_RULES, không suy diễn thành nghĩa vụ pháp lý.	Ba hạng mục mô phỏng: cảnh báo hạn dùng, xuất báo cáo tồn kho, và đổi màu giao diện. BA ghi giá trị vận hành, mức cấp thiết, dependency dữ liệu và rủi ro từng hạng mục; cảnh báo hạn dùng được đề xuất ưu tiên cao vì giảm nguy cơ xử lý lô không phù hợp, nhưng kết luận vẫn là đề xuất chờ Business Owner xác nhận.	Tiêu chí và thang đo được công bố trước khi chấm; mỗi điểm có evidence; các hạng mục bị ràng buộc pháp lý, kế toán hoặc an toàn thực phẩm phải giữ nhãn “Verification required” cho đến khi đúng owner xác minh.	Có thể lập bảng ưu tiên có giải thích, nhận diện trade-off và trình bày lựa chọn thay thế thay vì áp đặt ý kiến cá nhân.
CCM-05-PRI-02	Quản lý thay đổi ưu tiên, Partial. Learner cần hiểu rằng thứ tự backlog có thể đổi khi có evidence mới, nhưng chưa đủ thẩm quyền để tự thay đổi baseline, ngân sách hoặc cam kết release.	Chapter entry về quản lý delivery trong CHAPTER_MANIFEST; nội dung change control chi tiết thuộc phạm vi competency khác của section này.	Priority decision log liên kết TRACEABILITY_ID_REGISTRY; nguồn rule và data tiếp tục là CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi bị ảnh hưởng.	Giả định mô phỏng: phát hiện trường hạn dùng chưa có nguồn dữ liệu được xác nhận. BA đề xuất hạ độ tin cậy của estimate, đánh dấu dependency dữ liệu và yêu cầu Business Owner cùng Data/Architecture owner quyết định, thay vì âm thầm giữ ưu tiên cũ.	Log phải nêu trigger thay đổi, item bị ảnh hưởng, evidence, lựa chọn, tác động estimate và vai trò cần quyết định. Không được ghi “đã phê duyệt” khi không có approval reference.	Có thể phát hiện khi một thay đổi ưu tiên cần escalation, chuẩn bị gói quyết định có căn cứ và bảo toàn lịch sử truy vết.

Quy tắc ví dụ và ranh giới nguồn: Mọi số liệu như 8 story point, tên trường ExpiryDate, backlog item và tình huống Nova Foods trong các dòng trên là dữ liệu tổng hợp phục vụ học tập. BABOK Guide Version 3 là nguồn thuật ngữ và năng lực BA ở mức khái quát; không gán số trang hoặc điều khoản không được kiểm chứng. Không suy diễn từ ví dụ này rằng Nova Foods có quy trình ERP, quy tắc hạn dùng, ngân sách, thứ tự phát hành hoặc nghĩa vụ tuân thủ thực tế.

Kế hoạch xử lý Partial: CCM-05-PRI-02 chỉ đạt đầy đủ khi learner có thể lập decision log từ evidence, phân biệt đề xuất với quyết định có thẩm quyền, và chỉ rõ owner cần escalation. Trong khi chưa đủ evidence về quy tắc nghiệp vụ, dữ liệu, kiến trúc, pháp lý hoặc thẩm quyền Business Owner, matrix phải giữ phân loại Partial; không nâng lên Core hoàn tất chỉ vì learner đã tạo bảng chấm điểm.

Kế hoạch hàng competency về Testing, UAT và kỹ thuật kiểm thử hộp đen

Phạm vi này chuyển requirement và acceptance criteria thành bằng chứng kiểm thử có thể thực hiện, nhưng không biến ví dụ Nova Foods thành quy trình ERP thực tế. Cầu nối suy luận là: nếu learner chưa xác định được test basis (cơ sở kiểm thử), thì chưa thể chọn ca kiểm thử có căn cứ; nếu chưa phân biệt system testing với UAT (User Acceptance Testing — kiểm thử chấp nhận của người dùng), thì chưa thể kết luận sản phẩm đáp ứng nhu cầu nghiệp vụ. Thuật ngữ kiểm thử và kỹ thuật hộp đen phải bám ISTQB CTFL Syllabus v4.0.1; thuật ngữ BA và acceptance criteria tham chiếu BABOK Guide Version 3, không tự gán số trang hoặc điều khoản.

ID competency dự kiến	Classification	Chapter mapping	Artifact mapping	Worked example mapping	Quality gate	Learner capability
CCM-05-TST-01	Core	Chapter về requirements, acceptance criteria và testing; tên chapter phải đối chiếu với /01-curriculum/CHAPTER_MANIFEST.md	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; template test basis trong /01-curriculum/TEMPLATE_MANIFEST.md nếu template đã được đăng ký	Nova Foods mô phỏng: kiểm tra yêu cầu tạo đơn nhập hàng với dữ liệu tổng hợp gồm mã hàng, số lượng, đơn giá VND và ngày dự kiến nhận	Mỗi test condition phải chỉ ra nguồn requirement, rule hoặc data field; expected result phải quan sát được; không dùng câu “hệ thống hoạt động đúng” làm tiêu chí	Tách được test condition, precondition, input, action, expected result và evidence; nhận biết nội dung nào còn là giả định hoặc Verification required
CCM-05-TST-02	Core	Chapter về test analysis và black-box techniques; xác định tên/ID canonical từ CHAPTER_MANIFEST	Template test design được truy nguyên qua /01-curriculum/TEMPLATE_MANIFEST.md; thuật ngữ kỹ thuật tham chiếu ISTQB CTFL Syllabus v4.0.1	Dùng dữ liệu tổng hợp cho số lượng đặt hàng: lớp không hợp lệ, lớp hợp lệ và giá trị biên tại ngưỡng giả định của bài học; không diễn giải thành ngưỡng vận hành Nova Foods	Bảng test phải nêu kỹ thuật được chọn, lý do chọn, partition hoặc boundary tương ứng, expected result và trường hợp không áp dụng; không gọi kiểm thử giao diện là kiểm thử hộp đen nếu không có input–output observable	Chọn được kỹ thuật hộp đen phù hợp thay vì tạo danh sách ca kiểm thử tùy ý
CCM-05-TST-03	Core	Chapter về test techniques và scenario-based testing	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và test-case template đã đăng ký	Với rule tổng hợp “chỉ cho phép trạng thái Đã kiểm tra khi đủ trường bắt buộc”, learner lập ca cho thiếu trường, đủ trường và trạng thái không hợp lệ	Mỗi nhánh quyết định phải xuất hiện trong decision table; mỗi chuyển trạng thái phải có trạng thái đầu, sự kiện, trạng thái sau và điều kiện chặn	Giải thích và áp dụng được: equivalence partitioning (phân hoạch tương đương), boundary value analysis (phân tích giá trị biên), decision table testing (bảng quyết định), state transition testing (chuyển trạng thái) và use case testing (kiểm thử theo ca sử dụng)
CCM-05-TST-04	Core	Chapter về UAT planning và execution	UAT scenario, UAT data sheet, defect log và outcome record phải được đăng ký trong /01-curriculum/TEMPLATE_MANIFEST.md trước khi dùng	Người dùng giả lập đóng vai nhân viên kho kiểm tra luồng nhận hàng bằng dữ liệu tổng hợp; kết quả chỉ là bằng chứng học tập, không phải xác nhận vận hành	UAT scenario phải có mục tiêu nghiệp vụ, vai trò giả lập, dữ liệu tổng hợp, điều kiện trước, bước thực hiện, expected business outcome, evidence và tiêu chí pass/fail; người thực hiện không được tự ghi approval thay business owner	Phân biệt được UAT với system test: system test kiểm tra hành vi giải pháp theo test basis kỹ thuật/nghiệp vụ, còn UAT kiểm tra khả năng đáp ứng mục tiêu sử dụng của vai trò nghiệp vụ
CCM-05-TST-05	Partial	Chapter về defect handling, retest và UAT evidence	Defect log và retest record theo template canonical đã đăng ký; không tự tạo filename ngoài manifest	Tạo defect mô phỏng khi nhập số lượng bằng giá trị biên cho kết quả khác expected result; ghi severity, reproduction steps, evidence và trạng thái retest	Không được đóng defect chỉ vì có bản sửa; phải có reproduction rõ ràng, expected/actual result, evidence, retest result và người có thẩm quyền đánh giá outcome; không ghi “đã chấp thuận” nếu không có approval reference	Có thể phân biệt defect, change request, clarification và test-data issue; biết giữ trạng thái Partial khi thiếu evidence hoặc thiếu vai trò quyết định
CCM-05-TST-06	Partial	Chapter về test completion, UAT exit criteria và quality review	Test summary, UAT outcome và quality-gate checklist được đối chiếu qua TEMPLATE_MANIFEST	Đánh giá bài tập Nova Foods mô phỏng theo độ bao phủ requirement/rule, kết quả pass/fail, defect còn mở và giới hạn dữ liệu tổng hợp	Không dùng một tỷ lệ pass đơn lẻ để kết luận đạt; phải kiểm tra test basis, coverage, unresolved risk, defect impact, evidence completeness và quyền kết luận của vai trò liên quan	Lập được quality-gate note có kết luận giới hạn: đủ điều kiện chuyển sang bước review tiếp theo, cần rework, hoặc STOP — PLAN REWORK REQUIRED; không gọi là production-ready hay user-approved

Bộ quy tắc coverage kỹ thuật hộp đen: CCM-05-TST-02 chỉ được đánh dấu đạt khi bài làm có ít nhất một ví dụ đúng cho phân hoạch tương đương và giá trị biên, đồng thời giải thích được vì sao không phải mọi giá trị đều cần kiểm thử riêng. Bài làm phải có bảng quyết định khi kết quả phụ thuộc nhiều điều kiện kết hợp, có state transition khi kết quả phụ thuộc trạng thái trước và sự kiện chuyển đổi, và có use case testing khi cần bao phủ luồng chính cùng luồng thay thế. Pairwise testing (kiểm thử từng cặp) chỉ đưa vào bài nâng cao khi có nhiều tham số độc lập; không dùng nó thay cho phân tích rule hoặc boundary. Các kỹ thuật này được chọn vì loại lỗi cần phát hiện, không phải để đạt số lượng ca kiểm thử.

Kế hoạch xử lý Partial: Với CCM-05-TST-05 và CCM-05-TST-06, learner phải sửa bài theo checklist gồm test basis, kỹ thuật đã chọn, expected/actual result, evidence, trạng thái defect, giới hạn dữ liệu và vai trò cần escalation. Nếu nguồn rule, ngưỡng dữ liệu, kết quả nghiệp vụ hoặc quyền kết luận chưa được xác minh, matrix giữ Partial và gắn Verification required; không tự bổ sung quy định Nova Foods. Nguồn trực tiếp được phép dùng là ISTQB CTFL Syllabus v4.0.1, BABOK Guide Version 3, các artifact canonical nêu trong bảng và dữ liệu tổng hợp của Nova Foods; ngày đối chiếu nguồn là 2026-08-07, bối cảnh vi-VN, Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Kế hoạch các dòng năng lực: truy vết và quản lý thay đổi

Truy vết (traceability) là khả năng nối một nhu cầu hoặc vấn đề nghiệp vụ với yêu cầu, quy tắc, dữ liệu, tiêu chí chấp nhận, kiểm thử và thay đổi liên quan để có thể chứng minh tác động theo hai chiều: từ nhu cầu xuống bằng chứng triển khai, và từ lỗi hoặc thay đổi ngược lên nguồn quyết định. Quản lý thay đổi (change management) là quy trình ghi nhận, phân tích tác động, quyết định theo đúng thẩm quyền và cập nhật có kiểm soát; BA không tự coi yêu cầu mới là đã được phê duyệt. Các dòng dưới dùng Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục, toàn bộ mã và dữ liệu là tổng hợp.

ID dòng năng lực	Năng lực và phân loại	Ánh xạ chapter	Ánh xạ artifact canonical	Ví dụ thực hành Nova Foods mô phỏng	Quality gate	Năng lực đầu ra
CCM-05-TRC-01	Full — Lập liên kết truy vết hai chiều. Learner phân biệt ID với nội dung: ID giữ liên kết ổn định, còn nội dung có thể được sửa theo version.	Chapter trong CHAPTER_MANIFEST có phạm vi requirements, business rules, data và testing; phải kiểm tra tên chapter/ID thực tế trước khi gắn liên kết.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Nhu cầu mô phỏng “chặn xuất kho lô đã bị giữ chất lượng” được nối từ stakeholder need đến requirement, business rule, thuộc tính trạng thái lô, acceptance criteria và test case. Không tự khẳng định đây là quy tắc vận hành thực tế.	Mỗi liên kết có nguồn, đích, loại liên kết và version; không có ID tự tạo trùng registry; liên kết không được dùng để suy diễn approval hoặc baseline.	Tạo và đọc được ma trận truy vết; xác định được một requirement bị thiếu test basis hoặc một test case không có nguồn yêu cầu.
CCM-05-TRC-02	Full — Phân tích tác động thay đổi. Impact analysis là phân tích phần bị ảnh hưởng trước khi sửa, không phải danh sách ý kiến.	Chapter trong CHAPTER_MANIFEST về requirements, process, data, integration và testing; đối chiếu dependency thực tế trước khi xác nhận phạm vi.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Đề xuất mô phỏng đổi điều kiện cho phép xuất kho khiến BA kiểm tra rule liên quan, trường dữ liệu trạng thái lô, quy trình kho, API nếu có, acceptance criteria và test regression. Cầu nối suy luận là điều kiện thay đổi có thể làm thay đổi dữ liệu được chấp nhận, nên phải kiểm tra cả nơi tạo, lưu và sử dụng dữ liệu đó.	Báo cáo tác động phải tách rõ: ảnh hưởng xác nhận được từ liên kết hiện có; giả định dự án; và điểm Verification required. Không được biến “không tìm thấy liên kết” thành kết luận “không có tác động”.	Lập được impact analysis có phạm vi, rủi ro, dependency, câu hỏi mở và vai trò cần xác minh.
CCM-05-CHG-01	Full — Ghi nhận và phân loại change request. Change request là yêu cầu thay đổi có cấu trúc, khác với lỗi, câu hỏi làm rõ và yêu cầu mới chưa được xác nhận.	Chapter trong CHAPTER_MANIFEST về delivery, traceability và governance; mapping chỉ hoàn tất khi manifest có chapter entry phù hợp.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md là nguồn kiểm tra định danh; các artifact bị đổi vẫn giữ tệp canonical hiện hữu thay vì tạo bản sao không kiểm soát.	Một quản lý kho mô phỏng đề nghị thêm trạng thái “chờ kiểm tra”. BA ghi nguồn yêu cầu, lý do, phạm vi dự kiến, ID bị ảnh hưởng, rủi ro và quyết định cần có; không gán ngay trạng thái “được duyệt”.	Bản ghi thay đổi phân biệt rõ requestor, business rationale, phạm vi, tác động, quyết định cần thiết, trạng thái quản trị và evidence; không chứa dữ liệu cá nhân hay vận hành thật.	Chuyển một yêu cầu nói miệng thành change record có thể review và không làm mất nguồn gốc.
CCM-05-CHG-02	Partial — Điều phối quyết định thay đổi và kiểm soát version. BA chuẩn bị bằng chứng và duy trì liên kết, nhưng không thay Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance quyết định.	Chapter trong CHAPTER_MANIFEST về governance và delivery; đây là coverage Partial vì thẩm quyền phê duyệt nằm ngoài vai trò BA.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Nếu thay đổi mô phỏng ảnh hưởng truy xuất nguồn gốc thực phẩm hoặc dữ liệu cá nhân, BA gắn nhãn Verification required, nêu luật/nguồn có thể liên quan và chuyển gói câu hỏi cho domain owner cùng Legal Owner. Cầu nối suy luận là các nguồn chính thức nêu bối cảnh pháp lý, nhưng không đủ để BA tự diễn giải nghĩa vụ hệ thống.	Không có từ ngữ “đã phê duyệt”, “đã baseline” hoặc “tuân thủ” nếu artifact không có tham chiếu tương ứng; version thay đổi phải chỉ rõ các liên kết cần cập nhật và các liên kết còn chưa xác minh.	Biết khi nào cần escalation; bảo toàn lịch sử quyết định và không che giấu giới hạn thẩm quyền bằng cập nhật tài liệu.

Kế hoạch xử lý coverage Partial cho CCM-05-CHG-02: Learner hoàn thành một gói escalation gồm change record, impact analysis, danh sách artifact/ID bị ảnh hưởng, phân loại điểm cần xác minh, câu hỏi quyết định đơn nghĩa và vai trò có thẩm quyền. Bài tập chỉ đánh giá chất lượng chuẩn bị bằng chứng, không đánh giá việc learner tự ra quyết định pháp lý, kế toán, an toàn thực phẩm, bảo mật hay phê duyệt phạm vi. Nếu thay đổi chạm đến truy xuất nguồn gốc thực phẩm, dữ liệu cá nhân, hóa đơn hoặc kế toán, nguồn chính thức chỉ được phân loại là verified primary source cho bối cảnh; kết luận hệ thống phải giữ nhãn Verification required cho đến khi có xác minh từ owner phù hợp.

Nguồn và ranh giới sử dụng: BABOK Guide Version 3 được dùng theo phân loại verified primary source cho thuật ngữ BA, truy vết và quản lý thay đổi; ISO/IEC/IEEE 29148:2018 được dùng theo phân loại verified primary source cho bối cảnh quản lý yêu cầu, nhưng không nêu điều khoản chi tiết vì văn bản đầy đủ có thể cần quyền truy cập. ISTQB CTFL Syllabus v4.0.1 là verified primary source để kiểm tra rằng liên kết requirement–test basis hỗ trợ kiểm thử, không phải bằng chứng rằng Nova Foods đã kiểm thử hoặc chấp nhận sản phẩm.

Kế hoạch các hàng năng lực phát hành và vận hành

Phát hành (release) là đưa một thay đổi đã được chuẩn bị vào môi trường sử dụng theo một gói kiểm soát; vận hành (operations) là theo dõi, hỗ trợ và xử lý tín hiệu sau khi thay đổi được sử dụng. Hai năng lực này phải được học như một chuỗi: yêu cầu thay đổi tạo đầu vào, gói phát hành ghi rõ phạm vi và điều kiện, bằng chứng sau phát hành xác nhận kết quả hoặc kích hoạt xử lý sự cố. Cầu nối suy luận là BABOK Guide v3 dùng các khái niệm đánh giá giải pháp và quản lý vòng đời yêu cầu; vì vậy BA không tự triển khai kỹ thuật, nhưng phải làm rõ giá trị, phạm vi, tác động, tiêu chí theo dõi và đường truy vết của thay đổi. Nova Foods Trading & Manufacturing chỉ là tình huống mô phỏng giáo dục; mọi mã, số liệu và dữ liệu dưới đây là tổng hợp.

Năng lực cần có	Phân loại coverage	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ thực hành Nova Foods mô phỏng	Quality gate trước khi ghi nhận đạt	Năng lực đầu ra của learner
Lập gói sẵn sàng phát hành (release readiness package)	Core	CHAPTER_MANIFEST — chapter delivery/release được đối chiếu khi biên soạn	Release readiness checklist; release scope summary; liên kết TRACEABILITY_ID_REGISTRY	Thay đổi hiển thị trạng thái “Chờ đối chiếu” cho đơn mua nguyên liệu mô phỏng PO-SIM-024; gói ghi phạm vi màn hình, vai trò bị ảnh hưởng, dữ liệu mẫu và tiêu chí quan sát sau phát hành	Mỗi thay đổi có định danh truy vết; phạm vi bao gồm và loại trừ được viết riêng; dependency, môi trường, đầu mối nhận thông tin và điều kiện dừng được nêu; không gọi IN_REVIEW là đã sẵn sàng production	Phân biệt được “có thay đổi” với “đủ thông tin để xem xét phát hành”; tạo được gói để đội kỹ thuật, QA và vận hành cùng đọc mà không suy diễn phạm vi
Chuẩn bị kế hoạch chuyển đổi và phương án quay lui (rollback) ở góc nhìn BA	Core	CHAPTER_MANIFEST — chapter delivery/release được đối chiếu khi biên soạn	Cutover impact note; rollback decision record; tham chiếu CANONICAL_DATA_DICTIONARY	Nếu trạng thái mới làm nhân viên kho mô phỏng không tìm được đơn mua PO-SIM-024, ghi điều kiện quay lui là không truy xuất được bản ghi mẫu theo luồng đã mô tả; dữ liệu mô phỏng không bị sửa hoặc xóa khi chưa có quyết định đúng thẩm quyền	Phân biệt rollback nghiệp vụ với khôi phục kỹ thuật; xác định owner quyết định, dữ liệu bị ảnh hưởng, mốc thời gian, thông báo và bằng chứng cần lưu; BA không tự quyết định khôi phục hệ thống	Diễn đạt được tác động nghiệp vụ của cutover, nêu được ngưỡng cần escalation và chuyển câu hỏi kỹ thuật cho Architect hoặc đội vận hành
Theo dõi sau phát hành và ghi nhận tín hiệu vận hành (post-release monitoring)	Core	CHAPTER_MANIFEST — chapter operations được đối chiếu khi biên soạn	Post-release observation log; issue intake record; liên kết CANONICAL_BUSINESS_RULES khi tín hiệu liên quan quy tắc	Trong 2 giờ mô phỏng sau phát hành, ghi nhận 12 lượt mở đơn mua, 1 phản ánh không thấy trạng thái mới và 0 bản ghi có giá trị tiền tệ bị thay đổi; số liệu chỉ minh họa, không là KPI vận hành thực tế	Mỗi tín hiệu có thời điểm theo Asia/Ho_Chi_Minh, nguồn quan sát, mức tác động, artifact liên quan và trạng thái xử lý; tách dữ kiện quan sát khỏi giả thuyết nguyên nhân	Lập được nhật ký sau phát hành có thể truy vết, không biến một phản ánh đơn lẻ thành kết luận lỗi hệ thống
Hỗ trợ vận hành tuyến đầu và phân luồng sự cố	Partial	CHAPTER_MANIFEST — chapter operations/support được đối chiếu khi biên soạn	Support triage note; operational handover note; issue-to-artifact link	Nhân viên mua hàng mô phỏng báo không thấy trạng thái “Chờ đối chiếu”; learner ghi dữ kiện, bước tái hiện do người báo mô tả, vai trò bị ảnh hưởng và liên kết tới gói phát hành, thay vì tự gán nguyên nhân là lỗi quyền hoặc lỗi dữ liệu	Triage note không chứa dữ liệu cá nhân hay thông tin production; mức độ ưu tiên có căn cứ tác động; vấn đề vượt thẩm quyền BA được chuyển đúng vai trò; không hứa thời gian khắc phục khi chưa có xác nhận của đội xử lý	Tiếp nhận được vấn đề vận hành theo cấu trúc, bảo toàn bằng chứng và biết ranh giới giữa hỗ trợ BA, quyết định vận hành, phân tích kỹ thuật và xử lý bảo mật

Phân loại nguồn và ranh giới sử dụng: BABOK Guide v3 là nguồn chính cho thuật ngữ năng lực BA, quản lý vòng đời yêu cầu và đánh giá giải pháp; không viện dẫn số trang hoặc điều khoản không có trong nguồn seed. ISO/IEC/IEEE 29148:2018 chỉ được dùng ở mức định hướng về tính rõ ràng và khả năng truy vết của thông tin yêu cầu, vì văn bản điều khoản cần kiểm tra bản được cấp phép. Không dùng các hàng này để tạo quy trình triển khai production, quyền truy cập, thời gian xử lý sự cố, hoặc nghĩa vụ pháp lý cho Nova Foods.

Kế hoạch xử lý mục Partial — hỗ trợ vận hành tuyến đầu: Mức Partial có nghĩa learner phải thực hiện được intake, phân loại và truy vết vấn đề, nhưng chưa được coi là có năng lực điều hành service desk, phê duyệt mức độ nghiêm trọng, thay đổi cấu hình, khôi phục dữ liệu hoặc đóng sự cố kỹ thuật. Bằng chứng để nâng coverage chỉ có thể là bài thực hành chứa một triage note hoàn chỉnh, liên kết được tới release package và nêu rõ vai trò escalation. Nếu vấn đề có dấu hiệu lộ dữ liệu, thay đổi số liệu kế toán, ảnh hưởng truy xuất nguồn gốc thực phẩm hoặc cần thay đổi kiến trúc, learner phải giữ nhãn Verification required và chuyển gói thông tin cho Security, Accounting Owner, Legal/Compliance Owner, domain owner hoặc Architect tương ứng; không tự kết luận nguyên nhân hay biện pháp khắc phục.

Hạng mục governance competency rows — kế hoạch phủ năng lực quản trị

Governance (quản trị) trong ma trận được hiểu là khả năng xác định ai có quyền quyết định, bằng chứng nào được dùng, trạng thái nào được phép ghi nhận và khi nào phải dừng hoặc chuyển vấn đề. Suy luận này dựa trên ranh giới của 01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY: các artifact đều yêu cầu bảo toàn ID, filename, version, status, traceability và không diễn giải IN_REVIEW thành APPROVED, BASELINED, production-ready hoặc user-approved. Các hàng dưới đây là hàng năng lực dự kiến của matrix; mã canonical cuối cùng phải được đối chiếu với /01-curriculum/TRACEABILITY_ID_REGISTRY.md, không tự tạo mã thay thế registry.

Hàng năng lực governance	Phân loại	Chapter mapping	Artifact mapping	Worked example mapping	Quality gate	Learner capability
Xác định quyền quyết định và giới hạn thẩm quyền	Core BA competency; governance	Chapter về governance, document control và decision rights trong CHAPTER_MANIFEST	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nova Foods mô phỏng: phân biệt việc BA duy trì metadata với việc Business Owner, Architect, QA, Legal hoặc Accounting Owner quyết định nội dung chuyên môn	Mỗi quyết định có owner, input, evidence, trạng thái và giới hạn thẩm quyền; không có câu chữ ngầm khẳng định approval	Learner lập được bảng decision-rights tối thiểu và biết từ chối thay vai trò chuyên môn
Kiểm soát trạng thái, version, baseline và approval	Core BA competency; document governance	Chapter về controlled artifacts và change history	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/TEMPLATE_MANIFEST.md	Với dữ liệu tổng hợp Nova Foods ở IN_REVIEW, learner ghi v0.9.0, ngày 2026-08-07, nhưng không gọi nội dung là baseline hoặc approved	Header, version, timezone Asia/Ho_Chi_Minh, locale vi-VN, bối cảnh VND và change history khớp nhau; mọi tuyên bố approval phải có approval reference	Learner đọc đúng ý nghĩa trạng thái và cập nhật lịch sử thay đổi mà không tạo approval ngầm định
Duy trì định danh và tính toàn vẹn traceability	Core BA competency; governance control	Chapter về artifact identity và traceability trong CHAPTER_MANIFEST	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Khi một hàng matrix tham chiếu rule hoặc entity mô phỏng, learner giữ nguyên canonical ID và đường dẫn tệp, không dùng tên rút gọn	ID, filename, source classification và liên kết đầu-cuối tra được; ID chưa có trong registry phải mang nhãn cần xác minh	Learner phát hiện được liên kết sai, ID trùng hoặc tham chiếu bản sao không canonical
Phân loại nguồn và kiểm soát tuyên bố compliance	Governance-adjacent; Partial cần xử lý có điều kiện	Chapter về source policy, governance và legal boundary	Verified primary-source seed; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Với Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán hoặc Luật An toàn thực phẩm, learner ghi nguồn chính thức và chuyển yêu cầu hệ thống cho legal-owner hoặc accounting-owner verification	Phân biệt Normative, Official legal source, Industry good practice, Educational assumption và Verification required; không biến OWASP thành luật Việt Nam	Learner viết được một claim có nguồn, phạm vi áp dụng và người xác minh; biết dừng khi thiếu văn bản hiện hành
Chuẩn bị bằng chứng governance và auditability	Core BA competency; governance evidence	Chapter về controlled evidence và review readiness	/01-curriculum/TEMPLATE_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Hồ sơ mô phỏng phải chỉ ra artifact liên quan, version, ngày ghi nhận, owner, thay đổi và điểm còn cần xác minh; dữ liệu Nova Foods chỉ là dữ liệu tổng hợp	Evidence có thể truy ngược về artifact canonical và source; không dùng quotation, clause, số liệu hoặc xác nhận không có trong nguồn	Learner tạo được evidence index tối thiểu và phân biệt “đã ghi nhận kỹ thuật” với “đã được chuyên môn phê chuẩn”

Treatment plan cho các hàng Partial: Với năng lực phân loại nguồn pháp lý và compliance, curriculum chỉ dạy cách nhận diện nguồn, ghi nhãn giả định, bảo toàn liên kết và lập gói verification; không dạy learner tự kết luận nghĩa vụ pháp lý, kế toán, thuế, privacy, food safety hoặc production control. Với năng lực governance nói chung, quality gate bắt buộc là kiểm tra Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, dữ liệu tổng hợp và không có approval reference giả định. Nếu thiếu owner, source, canonical ID, evidence hoặc thẩm quyền quyết định, trạng thái đầu ra là STOP — PLAN REWORK REQUIRED, không được lấp khoảng trống bằng rule Nova Foods hoặc cam kết tuân thủ.

Kế hoạch hàng năng lực: lãnh đạo và phán đoán escalation

Lãnh đạo trong phạm vi BA không có nghĩa là tự quyết thay Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance. Đó là năng lực tạo rõ ràng cho quyết định: nhận diện vấn đề, thu thập bằng chứng, chỉ ra tác động, đề xuất các phương án có ranh giới thẩm quyền và chuyển đúng vai trò quyết định. Escalation (chuyển vấn đề lên vai trò có thẩm quyền) được kích hoạt khi BA không thể giải quyết chỉ bằng làm rõ requirement, hoặc khi quyết định có thể làm thay đổi phạm vi, rủi ro, dữ liệu, kiến trúc, kiểm soát hoặc khả năng vận hành. Cầu nối suy luận là: IN_REVIEW và không có baseline hoặc approval reference trong các artifact nguồn, nên learner phải học cách bảo toàn trạng thái chưa xác nhận thay vì diễn đạt một kết luận như quyết định đã được phê duyệt.

Hàng năng lực dự kiến	Phân loại	Ánh xạ chapter	Ánh xạ artifact canonical	Ánh xạ ví dụ thực hành Nova Foods mô phỏng	Quality gate (cổng chất lượng)	Năng lực đầu ra của learner
Dẫn dắt làm rõ vấn đề liên chức năng	Core	Chapter trong CHAPTER_MANIFEST bao phủ stakeholder, delivery và leadership; khi đăng ký ma trận phải đối chiếu đúng chapter entry, không tự đặt mã chapter.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kho vận và Kế toán có cách hiểu khác nhau về thời điểm ghi nhận trạng thái “đã giao” của một đơn giao hàng mô phỏng. BA lập vấn đề, tách fact, giả định và câu hỏi quyết định.	Vấn đề có một câu mô tả trung lập; mỗi nhận định gắn nguồn artifact hoặc nhãn “Verification required”; không gán lỗi cho cá nhân; xác định rõ người quyết định.	Điều phối trao đổi để biến bất đồng mơ hồ thành câu hỏi có thể quyết định, không tự chọn quy tắc nghiệp vụ.
Phán đoán ngưỡng escalation	Core	Chapter trong CHAPTER_MANIFEST bao phủ delivery, risk, governance và leadership; đối chiếu entry canonical trước khi ghi mapping cuối.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Một đề xuất thay đổi trường dữ liệu người nhận hàng mô phỏng vừa ảnh hưởng API, quyền truy cập và khả năng chứa dữ liệu cá nhân.	Gói escalation nêu tối thiểu: trigger, artifact ảnh hưởng, rủi ro nếu trì hoãn, lựa chọn khả dĩ, vai trò quyết định và deadline học liệu; không kết luận tuân thủ pháp luật hay an toàn dữ liệu.	Phân biệt được việc BA có thể tự làm rõ với việc phải chuyển Architect, Security hoặc Legal Owner.
Chuẩn bị gói quyết định có traceability	Core	Chapter trong CHAPTER_MANIFEST bao phủ traceability, change control và leadership; mapping chính thức phải dùng manifest.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Business Owner được yêu cầu chọn giữa giữ đơn vị tồn kho hiện tại hoặc thay đổi cách hiển thị quy đổi cho báo cáo mô phỏng bằng VND.	Gói có liên kết hai chiều từ vấn đề đến requirement, rule, data item và ảnh hưởng học liệu; nêu rõ cái gì chưa xác minh; không tạo rule mới trong biên bản escalation.	Tạo được decision brief ngắn, có bằng chứng và có thể kiểm tra ngược về nguồn canonical.
Điều hành rủi ro, phụ thuộc và cam kết	Core	Chapter trong CHAPTER_MANIFEST bao phủ planning, delivery và leadership; đối chiếu chapter entry trước khi hoàn thiện matrix.	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nhóm mô phỏng muốn cam kết ngày demo trước khi QA có test basis hoàn chỉnh và trước khi Architect làm rõ phụ thuộc tích hợp.	Rủi ro ghi theo cấu trúc nguyên nhân–sự kiện–hậu quả; dependency có owner vai trò; cam kết được ghi là dự kiến, không gọi là approval hoặc baseline.	Nêu được điều kiện để tiếp tục, trì hoãn hoặc escalation mà không che giấu bất định.
Giao tiếp bất đồng và khuyến nghị không vượt thẩm quyền	Core	Chapter trong CHAPTER_MANIFEST bao phủ stakeholder engagement và leadership; mapping chính thức phụ thuộc manifest.	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Sales đề nghị bỏ kiểm tra hạn mức tín dụng mô phỏng để xử lý đơn nhanh; Finance nêu rủi ro nhưng chưa có quyết định được ghi nhận.	BA trình bày ít nhất hai phương án, tác động và câu hỏi quyết định; giữ nhãn giả định; không tuyên bố cách xử lý là yêu cầu kế toán hợp lệ.	Giao tiếp được khuyến nghị có lý do, lắng nghe phản biện và chuyển quyết định đến Business Owner cùng Accounting Owner khi cần.
Escalation governance-adjacent: kiểm soát thay đổi nội dung có ràng buộc chuyên môn	Partial	Chapter trong CHAPTER_MANIFEST bao phủ governance, change control và leadership; đây là coverage một phần vì learner không được đào tạo để phê chuẩn kiểm soát chuyên ngành.	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Một thay đổi mô phỏng có thể ảnh hưởng thông tin cá nhân, hóa đơn hoặc truy xuất thực phẩm. Nguồn pháp lý đã liệt kê chỉ cho phép nhận diện nhu cầu xác minh, không đủ để BA tự diễn giải nghĩa vụ.	Phân loại đúng lĩnh vực cần escalation: Legal/Compliance cho dữ liệu cá nhân, Accounting cho hạch toán hoặc hóa đơn, domain owner cho an toàn thực phẩm; giữ “Verification required” đến khi có bằng chứng từ vai trò có thẩm quyền.	Biết đóng gói và theo dõi escalation governance-adjacent, nhưng không ký xác nhận pháp lý, kế toán, compliance hay production.

Quy tắc quyết định escalation cho bài thực hành. Learner phải escalation khi có ít nhất một điều kiện: nguồn canonical mâu thuẫn; thay đổi ảnh hưởng từ hai vai trò chuyên môn trở lên; không xác định được chủ sở hữu quyết định; giả định có thể làm sai dữ liệu, quy tắc hoặc quyết định vận hành; hoặc thời hạn delivery buộc nhóm cam kết khi evidence chưa đủ. Learner có thể tiếp tục tự xử lý khi vấn đề chỉ là lỗi trình bày, thiếu liên kết traceability, hoặc cần làm rõ thuật ngữ mà không làm thay đổi rule, data, phạm vi hay thẩm quyền.

Treatment plan cho mục Partial. Coverage governance-adjacent chỉ dạy BA nhận biết tín hiệu, lập escalation package và bảo toàn traceability; không dạy learner diễn giải Luật Bảo vệ dữ liệu cá nhân, Nghị định hướng dẫn, Luật Kế toán, quy định hóa đơn hay Luật An toàn thực phẩm thành requirement xác định. Bằng chứng của việc hoàn thành là một gói escalation dùng dữ liệu tổng hợp Nova Foods, có câu hỏi đơn nghĩa, tham chiếu artifact bị ảnh hưởng, rủi ro của việc chưa quyết định và vai trò cần phản hồi. Gói này vẫn ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh; việc tạo gói không xác nhận approval, baseline, tuân thủ hoặc quyền triển khai production.

Kế hoạch hàng năng lực BA có hỗ trợ AI: ranh giới an toàn và kiểm tra bởi con người

AI-assisted BA work (công việc BA có hỗ trợ trí tuệ nhân tạo) là việc dùng công cụ AI để tạo bản nháp, tóm tắt, so sánh hoặc phát hiện điểm cần làm rõ; AI không phải Business Owner, Legal Owner, Accounting Owner, Security, Architect, QA Reviewer hay người phê duyệt. Cầu nối suy luận là BABOK Guide dùng để định hướng năng lực và thuật ngữ BA, trong khi các artifact Nova Foods đang IN_REVIEW, chưa có baseline hay approval; vì vậy đầu ra AI chỉ có thể là vật liệu phân tích cần người có thẩm quyền kiểm tra, không thể trở thành requirement, business rule, kết luận pháp lý hoặc quyết định triển khai.

ID hàng ma trận	Năng lực được lập kế hoạch	Phân loại coverage	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ ví dụ thực hành Nova Foods mô phỏng	Quality gate	Năng lực người học
CCM-05-AI-01	Dùng AI để tạo bản nháp có cấu trúc từ đầu vào đã được phép dùng	Partial	Chương về AI-assisted BA work: tạo bản nháp có kiểm soát	/01-curriculum/COMPETENCY_COVERAGE_MATRIX.md; /01-curriculum/CHAPTER_MANIFEST.md	Từ một mô tả tổng hợp về yêu cầu tra cứu trạng thái lô hàng, learner yêu cầu AI đề xuất danh sách câu hỏi làm rõ, không yêu cầu AI tự viết business rule.	Prompt ghi rõ mục đích học liệu, dữ liệu tổng hợp, phạm vi đầu vào và yêu cầu không suy diễn; đầu ra được gắn nhãn AI draft — human review required.	Viết prompt có ngữ cảnh, giới hạn nhiệm vụ và tiêu chí đầu ra; phân biệt bản nháp với nội dung đã được xác minh.
CCM-05-AI-02	Kiểm tra, hiệu chỉnh và truy vết đầu ra AI trước khi dùng trong artifact BA	Partial	Chương về AI-assisted BA work: human review và evidence bridge	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Learner đối chiếu một danh sách trường dữ liệu do AI đề xuất với CANONICAL_DATA_DICTIONARY; trường không có nguồn canonical được ghi là giả định hoặc câu hỏi cần xác minh, không được thêm vào data dictionary như sự thật.	Reviewer là con người kiểm từng nhận định theo nguồn, ghi liên kết nguồn hoặc lý do loại bỏ; không còn phát biểu không có evidence bridge.	Phát hiện hallucination, mâu thuẫn, thiếu ngữ cảnh và ngôn ngữ khẳng định quá mức; bảo toàn traceability từ nhận định đến nguồn.
CCM-05-AI-03	Bảo vệ dữ liệu và giới hạn thông tin khi dùng AI	Partial	Chương về AI-assisted BA work: safe-use boundary và xử lý thông tin	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Learner thay tên khách hàng, mã đơn hàng, địa chỉ, token, API key và dữ liệu vận hành bằng dữ liệu tổng hợp trước khi soạn prompt về quy trình đổi trả hàng.	Prompt không chứa dữ liệu cá nhân, bí mật xác thực, dữ liệu giao dịch thực, cấu hình ERP thực hoặc thông tin bảo mật; nếu phân loại dữ liệu chưa rõ thì không đưa vào AI và lập gói escalation.	Phân loại sơ bộ dữ liệu, tối thiểu hóa đầu vào và chọn phương án không sử dụng AI khi không chứng minh được an toàn.
CCM-05-AI-04	Phán đoán khi AI tạo nội dung chạm tới pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc quyết định vận hành	Partial	Chương về AI-assisted BA work: escalation judgment	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md	AI đề xuất quy tắc lưu giữ hóa đơn hoặc điều kiện truy xuất lô thực phẩm. Learner không sao chép thành rule Nova Foods mà ghi nhãn Verification required, nêu nguồn luật liên quan và chuyển câu hỏi cho Legal Owner, Accounting Owner hoặc domain owner phù hợp.	Không có kết luận AI nào được diễn đạt là nghĩa vụ pháp lý, diễn giải kế toán, xác nhận bảo mật hoặc quyết định production; escalation package có câu hỏi đơn nghĩa, artifact ảnh hưởng, giả định và hậu quả.	Nhận biết ranh giới thẩm quyền, dừng suy diễn và chuyển đúng vai trò quyết định thay vì dùng AI để thay thế chuyên gia.

Phạm vi dùng AI an toàn trong học liệu này là: diễn đạt lại nội dung do learner đã cung cấp, đề xuất câu hỏi phỏng vấn, tạo checklist review, so sánh hai bản nháp do learner cung cấp, hoặc chỉ ra mâu thuẫn có thể có để người học kiểm tra. Phạm vi này được chọn vì các tác vụ tạo hỗ trợ phân tích nhưng không chuyển thẩm quyền xác nhận sang AI; mọi dữ liệu của Nova Foods Trading & Manufacturing vẫn là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

AI không được dùng để tự xác nhận compliance với Luật Bảo vệ dữ liệu cá nhân, Nghị định hướng dẫn bảo vệ dữ liệu cá nhân, Luật Kế toán, quy định hóa đơn chứng từ, Luật An toàn thực phẩm, OWASP ASVS, OWASP API Security Top 10, WCAG, ISO/IEC/IEEE 29148 hoặc bất kỳ nguồn nào khác. Lý do là nguồn pháp lý cần vai trò có thẩm quyền diễn giải, còn các nguồn kỹ thuật và tiêu chuẩn chỉ được áp dụng sau khi đối chiếu nội dung nguồn phù hợp; learner phải ghi Verification required khi nội dung AI chạm đến nghĩa vụ, kiểm soát hoặc kết luận chuyên môn chưa được nguồn và reviewer xác thực.

Kế hoạch xử lý Partial cho CCM-05-AI-01 đến CCM-05-AI-04 là giữ các hàng này ở mức năng lực hỗ trợ, không chấm learner theo độ hay của văn bản AI tạo ra. Bằng chứng đạt yêu cầu là prompt đã được làm sạch dữ liệu, đầu ra có nhãn bản nháp, bảng đối chiếu nhận định–nguồn–quyết định của reviewer, và gói escalation khi phát hiện ranh giới thẩm quyền. Nếu thiếu bất kỳ bằng chứng nào, kết quả là “chưa đạt quality gate”; learner phải sửa artifact hoặc dừng sử dụng đầu ra AI, không được nâng nội dung đó thành canonical rule, requirement hay quyết định Nova Foods.

Ma trận ánh xạ tối thiểu cho từng năng lực delivery và governance

Ma trận này quy định cấu trúc một dòng năng lực trong /01-curriculum/COMPETENCY_COVERAGE_MATRIX.md. “Phân loại” cho biết mức bao phủ dự kiến: Core là năng lực bắt buộc để người học thực hiện độc lập trong bài mô phỏng; Partial là năng lực chỉ dạy đến ranh giới BA, cần chuyển quyết định chuyên môn cho vai trò có thẩm quyền. Cầu nối suy luận là: mục tiêu section 05 yêu cầu bao phủ chuỗi từ lập kế hoạch đến vận hành; vì vậy mỗi năng lực phải có chapter để học khái niệm, artifact để thực hành, ví dụ Nova Foods để kiểm chứng khả năng áp dụng, quality gate để đo được đầu ra, và mô tả năng lực để ngăn việc nhầm “đã đọc” với “có thể làm”.

Năng lực	Phân loại	Ánh xạ chapter	Ánh xạ artifact	Ánh xạ worked example Nova Foods mô phỏng, dữ liệu tổng hợp	Quality gate	Năng lực người học sau khi đạt
Lập kế hoạch và cộng tác Agile (Agile: cách phân phối lặp ngắn, ưu tiên phản hồi)	Core	Entry trong CHAPTER_MANIFEST về delivery Agile, backlog và refinement	Backlog, user story, acceptance criteria và kế hoạch iteration được đăng ký qua TEMPLATE_MANIFEST	Nhóm ERP ưu tiên chức năng ghi nhận đơn bán thực phẩm mô phỏng theo từng iteration	Mỗi user story có mục tiêu nghiệp vụ, tiêu chí chấp nhận kiểm thử được và liên kết tới rule hoặc dữ liệu liên quan	Tách được nhu cầu lớn thành lát cắt giá trị nhỏ, làm rõ trước khi đội phát triển cam kết thực hiện
Lập kế hoạch predictive (predictive: lập kế hoạch theo giai đoạn và mốc kiểm soát trước)	Core	Entry trong CHAPTER_MANIFEST về delivery predictive, phạm vi và milestone	WBS mức BA, danh mục deliverable, dependency log và milestone plan qua TEMPLATE_MANIFEST	Lập kế hoạch mô phỏng cho luồng mua nguyên liệu, nhận hàng và đối chiếu chứng từ	Phạm vi, phụ thuộc, giả định và mốc bàn giao được tách thành trường riêng; không biến giả định thành requirement	Lập được kế hoạch BA có dependency rõ ràng và nêu được điều gì thay đổi khi một mốc bị trễ
Ước lượng và ưu tiên	Core	Entry trong CHAPTER_MANIFEST về estimation, prioritization và quyết định dựa trên giá trị	Estimation worksheet, priority rationale và decision log qua TEMPLATE_MANIFEST	So sánh ưu tiên giữa cảnh báo tồn kho thấp và cải tiến màn hình tra cứu lô hàng mô phỏng	Mỗi mức ưu tiên nêu giá trị, rủi ro, phụ thuộc, chi phí hoặc độ không chắc chắn; người học không tự xác nhận ngân sách	Ước lượng ở mức phù hợp với thông tin hiện có, giải thích tiêu chí ưu tiên và nhận diện điểm cần Business Owner quyết định
Thiết kế kiểm thử và hỗ trợ UAT (User Acceptance Testing: kiểm thử chấp nhận bởi đại diện nghiệp vụ)	Core	Entry trong CHAPTER_MANIFEST về test basis, testing và UAT	Test scenario, test case, UAT evidence log và defect record qua TEMPLATE_MANIFEST	Kiểm thử mô phỏng việc chặn nhập số lượng âm trong phiếu điều chỉnh tồn kho	Mỗi test case truy được về requirement, acceptance criterion hoặc business rule; kết quả Pass hoặc Fail có bằng chứng tổng hợp	Chuyển yêu cầu thành điều kiện kiểm thử, hỗ trợ người dùng kiểm thử theo kịch bản và ghi nhận lỗi không suy diễn nguyên nhân kỹ thuật
Traceability và kiểm soát thay đổi	Core	Entry trong CHAPTER_MANIFEST về traceability, impact analysis và change control	Traceability matrix, change request, impact assessment và decision log; định danh phải tuân theo TRACEABILITY_ID_REGISTRY	Yêu cầu mô phỏng đổi cách hiển thị trạng thái lô hàng tác động đến báo cáo, API và kịch bản UAT	Không có liên kết mồ côi giữa nhu cầu, requirement, rule, dữ liệu, test và thay đổi; thay đổi chưa quyết định giữ trạng thái mở	Phân tích được tác động theo chuỗi nguồn–yêu cầu–thiết kế–kiểm thử và không tự biến change request thành quyết định đã phê duyệt
Release và vận hành	Core	Entry trong CHAPTER_MANIFEST về release readiness, handover và operational support	Release checklist, cutover communication, support runbook và incident intake qua TEMPLATE_MANIFEST	Chuẩn bị phát hành mô phỏng chức năng theo dõi lô nguyên liệu và tiếp nhận sự cố không hiển thị được lịch sử lô	Checklist phân biệt rõ điều kiện sẵn sàng, rủi ro còn lại, người chịu trách nhiệm và bằng chứng; không tuyên bố sẵn sàng production	Chuẩn bị bàn giao có cấu trúc, mô tả được thông tin vận hành cần thiết và định tuyến sự cố đúng vai trò
Governance BA và kiểm soát nguồn chân lý	Partial	Entry trong CHAPTER_MANIFEST về governance, document control và decision authority	Artifact header, source register, assumption log, issue log và decision log; tham chiếu canonical giữ nguyên CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	Phát hiện quy tắc hạn dùng mô phỏng xuất hiện khác nhau giữa backlog và tài liệu quy tắc	Mọi mâu thuẫn chỉ rõ nguồn, ảnh hưởng, chủ sở hữu cần quyết định và trạng thái xác minh; BA không tự hợp thức hóa nội dung pháp lý, kế toán hoặc compliance	Duy trì nguồn chân lý và lập gói escalation, nhưng dừng tại ranh giới thẩm quyền của Business Owner, Legal, Accounting, Security hoặc Architect
Lãnh đạo cộng tác và phán đoán escalation	Partial	Entry trong CHAPTER_MANIFEST về stakeholder leadership, conflict handling và escalation	Stakeholder map, RAID log, meeting record và escalation brief qua TEMPLATE_MANIFEST	Xử lý bất đồng mô phỏng giữa kho và bán hàng về thời điểm cho phép xuất lô gần hạn	Escalation brief nêu sự kiện, lựa chọn, tác động, bằng chứng, quyết định cần có và vai trò quyết định; không gán kết luận cho người chưa quyết định	Điều phối làm rõ đa bên, nhận diện bế tắc cần escalation và trình bày lựa chọn trung lập, có thể quyết định
Công việc BA có hỗ trợ AI (AI-assisted BA work: dùng công cụ AI để hỗ trợ soạn thảo, phân tích hoặc rà soát)	Partial	Entry trong CHAPTER_MANIFEST về AI-assisted BA work, human review và information handling	AI-use record, prompt log đã làm sạch dữ liệu, human-review checklist và provenance note qua TEMPLATE_MANIFEST	Dùng AI tạo bản nháp câu hỏi làm rõ cho quy trình thu hồi lô thực phẩm mô phỏng, sau đó BA rà soát với nguồn canonical	Đầu ra AI phải ghi nguồn đầu vào an toàn, người rà soát, lỗi hoặc thay đổi sau rà soát và trạng thái chưa xác nhận; không nhập dữ liệu cá nhân, bí mật, khóa truy cập hoặc quyết định pháp lý vào công cụ AI	Dùng AI để tăng tốc bản nháp và phát hiện khoảng trống, đồng thời tự kiểm tra tính đúng, truy vết nguồn và chuyển nội dung vượt thẩm quyền cho người phù hợp

Ánh xạ trên chỉ là kế hoạch coverage tại IN_REVIEW, v0.9.0, ngày 2026-08-07, theo vi-VN và Asia/Ho_Chi_Minh. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi ví dụ dùng dữ liệu tổng hợp và không xác nhận cấu hình ERP, quy tắc vận hành, tuân thủ pháp lý hoặc phê duyệt thực tế.

Kế hoạch xử lý các năng lực phân loại Partial về AI và khu vực giáp ranh quản trị

Partial nghĩa là năng lực đã có giá trị học tập và có thể được đưa vào ma trận, nhưng chưa đủ căn cứ để dạy như một thực hành độc lập, bắt buộc hoặc đã được xác nhận cho Nova Foods. Cầu nối suy luận là: các artifact canonical đều có trạng thái IN_REVIEW, chưa có baseline hoặc approval reference; đồng thời nguồn đã xác minh chỉ cho phép dùng BABOK Guide cho thuật ngữ và năng lực BA, còn pháp lý, kế toán, bảo mật và vận hành phải do vai trò có thẩm quyền xác minh. Vì vậy, mỗi hàng Partial phải chỉ rõ phần learner được thực hành, phần learner chỉ được nhận biết, và điều kiện chuyển sang Covered.

Năng lực Partial cần có trong ma trận	Căn cứ phân loại và cầu nối suy luận	Kế hoạch xử lý học liệu và artifact	Chương/nguồn mapping được phép ghi	Quality gate trước khi nâng mức	Learner capability sau khi học
AI-assisted BA work — sử dụng AI hỗ trợ phân tích nghiệp vụ	Không có nguồn AI-specific trong verified primary-source seed để xác nhận một quy trình AI là chuẩn bắt buộc; BABOK Guide hỗ trợ vai trò, kỹ năng và nhiệm vụ BA nhưng không thay thế quyết định của người có thẩm quyền. Do đó chỉ có thể dạy AI như công cụ hỗ trợ tạo bản nháp, không phải nguồn chân lý.	Thiết kế bài thực hành dùng dữ liệu tổng hợp của Nova Foods để tạo bản nháp user story, câu hỏi làm rõ hoặc bảng truy vết. Learner phải đính kèm “nhật ký kiểm tra đầu ra AI” gồm: mục đích prompt, loại dữ liệu đã dùng, giả định AI tạo ra, lỗi hoặc mâu thuẫn phát hiện được, nguồn canonical đã đối chiếu và người chịu trách nhiệm review. Không đưa dữ liệu cá nhân, thông tin khách hàng thực, bí mật vận hành, token, endpoint thực hoặc nội dung chưa được phép vào công cụ AI.	Ghi mapping tới BABOK Guide ở mức thuật ngữ về phân tích, stakeholder và yêu cầu; ghi mapping artifact tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi learner đối chiếu đầu ra. Không gán AI output thành nguồn canonical.	Reviewer xác nhận đầu ra AI đã được kiểm tra thủ công với artifact canonical, mọi nhận định không có bằng chứng được gắn “giả định” hoặc loại bỏ, và không có dữ liệu ngoài phạm vi mô phỏng. Nếu AI tạo rule, số liệu hoặc quyết định chưa tồn tại trong nguồn, gate không đạt.	Có thể dùng AI để tăng tốc bản nháp và phát hiện câu hỏi cần làm rõ; có thể giải thích vì sao không được dùng AI để tự xác nhận requirement, compliance, thiết kế kiến trúc hoặc approval.
Human review của đầu ra AI — kiểm tra của con người	AI có thể tạo nội dung nghe hợp lý nhưng sai nguồn, sai phạm vi hoặc che giấu giả định. Đây là suy luận từ nguyên tắc traceability của corpus: một assertion chỉ đáng tin khi truy được về nguồn canonical hoặc được gắn nhãn xác minh.	Bài tập yêu cầu learner so sánh từng statement do AI sinh với một trong ba trạng thái: “có bằng chứng”, “mâu thuẫn nguồn”, hoặc “Verification required”. Learner không được sửa trạng thái IN_REVIEW thành baseline, approval hoặc compliant trong bản nháp do AI tạo.	Artifact mapping bắt buộc dùng đúng ID TRACEABILITY_ID_REGISTRY; khi statement liên quan rule hoặc dữ liệu, đối chiếu lần lượt với CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY.	100% statement có tính quyết định phải có nguồn, nhãn giả định hoặc escalation owner. Reviewer kiểm tra ít nhất một mâu thuẫn được learner phát hiện và cách learner sửa nội dung thay vì chỉ chép lại AI output.	Có thể thực hiện human review theo checklist và giữ được ranh giới giữa nội dung hỗ trợ học tập với bằng chứng có thể truy vết.
Governance-adjacent requirement — yêu cầu giáp ranh pháp lý, kế toán, bảo mật, dữ liệu cá nhân hoặc an toàn thực phẩm	Verified source seed xác định các văn bản pháp lý là nguồn chính thức, nhưng cũng quy định mọi system requirement suy ra từ chúng cần legal-owner verification; OWASP là chuẩn thực hành ngành, không phải pháp luật Việt Nam. BA curriculum owner không có thẩm quyền diễn giải thay các owner này.	Dạy learner lập “gói escalation” thay vì tự viết nghĩa vụ bắt buộc. Gói gồm: vấn đề đơn nghĩa; nguồn đã tra; artifact bị ảnh hưởng; dữ liệu Nova Foods tổng hợp minh họa; giả định hiện tại; rủi ro nếu chưa xác minh; câu hỏi quyết định; vai trò owner cần phản hồi.	Chỉ ghi nguồn theo đúng phân loại: luật và nghị định từ URL chính thức; OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023 là industry awareness/good practice; không gán số điều, khoản hoặc diễn giải chi tiết khi chưa kiểm tra văn bản được cấp quyền truy cập.	Quality gate đạt khi gói escalation không chứa kết luận pháp lý, thuế, kế toán, bảo mật hay compliance do BA tự xác nhận; vai trò escalation phù hợp được nêu rõ; mọi yêu cầu còn chưa xác minh mang nhãn Verification required.	Có thể nhận diện khi một yêu cầu vượt quyền BA, đóng gói vấn đề đủ để owner chuyên môn quyết định, và duy trì traceability trong thời gian chờ xác minh.
Governance của trạng thái, baseline và approval	Các dependency xác nhận IN_REVIEW không đồng nghĩa APPROVED, BASELINED, production-ready hoặc user-approved. Vì trạng thái artifact ảnh hưởng cách diễn giải bằng chứng, đây là năng lực quản trị cần dạy nhưng chỉ ở mức thao tác và nhận biết cho learner mới.	Dùng ví dụ tổng hợp: learner nhận một requirement tham chiếu CANONICAL_BUSINESS_RULES ở IN_REVIEW, sau đó phải viết mô tả trung tính “đang được xem xét” thay vì “đã được phê duyệt”. Learner ghi impact khi rule thay đổi và mở liên kết tới registry, không tự đóng change.	Mapping artifact dùng nguyên dạng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; chapter mapping phải được đối chiếu với CHAPTER_MANIFEST.md trước khi ghi mã chapter cụ thể trong ma trận.	Reviewer kiểm tra learner không dùng các từ “đã phê duyệt”, “đã baseline”, “tuân thủ” hoặc “sẵn sàng production” khi artifact không có bằng chứng tương ứng; mọi mapping giữ đúng ID và filename canonical.	Có thể đọc trạng thái tài liệu đúng nghĩa, bảo toàn nguồn chân lý và báo tác động thay đổi mà không giả định quyền phê chuẩn.

Quy tắc nâng từ Partial sang Covered là phải có đủ bốn bằng chứng: nội dung học liệu xác định được phạm vi thao tác; artifact mẫu dùng dữ liệu tổng hợp Nova Foods; worked example cho thấy learner tạo hoặc kiểm tra bằng chứng; và quality gate có tiêu chí pass/fail do reviewer phù hợp thực hiện. Với AI-assisted BA work, bằng chứng còn phải chứng minh human review và cấm đưa dữ liệu ngoài phạm vi mô phỏng. Với nội dung giáp ranh governance, bằng chứng còn phải giữ nhãn Verification required cho đến khi artifact kiểm soát ghi nhận nguồn và thẩm quyền xác minh phù hợp.

Cross-file checks, self-review, open issues, and escalation needs

Kế hoạch đối chiếu liên tệp

Đối chiếu liên tệp (cross-file check) là hoạt động kiểm tra một hàng của ma trận năng lực có cùng ý nghĩa, cùng định danh và cùng ranh giới thẩm quyền với các artifact nguồn trong corpus hay không. Mục tiêu là bảo đảm ma trận chỉ lập kế hoạch bao phủ năng lực; không tự tạo quy tắc Nova Foods, trường dữ liệu, mã định danh, chapter, template hoặc kết luận chuyên môn mới. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi ví dụ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ mô phỏng VND.

Tệp nguồn canonical cần đối chiếu	Nội dung ma trận phải kiểm tra	Cách đối chiếu cụ thể	Kết quả được phép ghi vào ma trận
/01-curriculum/01_CURRICULUM_ARCHITECTURE.md (01_CURRICULUM_ARCHITECTURE)	Cấu trúc curriculum, chuỗi học, dependency giữa các miền năng lực và ranh giới planning artifact	Đọc mục kiến trúc liên quan trước khi gán competency vào chapter hoặc artifact. Kiểm tra năng lực đầu vào xuất hiện trước năng lực phụ thuộc; ví dụ, learner phải có requirement, business rule và logical data cơ bản trước khi thực hành traceability hoặc test basis.	Ghi mapping phù hợp chuỗi học và nêu dependency bằng ngôn ngữ kế hoạch. Không diễn giải kiến trúc thành requirement vận hành ERP.
/01-curriculum/CHAPTER_MANIFEST.md (CHAPTER_MANIFEST)	Danh mục authoritative gồm 26 handbook chapter, filename, phạm vi chapter và dependency đã đăng ký	Đếm và đối chiếu mapping của từng competency với entry chapter có thật trong manifest. Xác nhận tên chapter, đường dẫn và phạm vi dùng đúng nguyên dạng; không tự đặt chapter thứ 27, mã chapter mới hoặc chuyển một competency sang chapter ngoài phạm vi entry.	Ghi chapter mapping chỉ khi tìm thấy entry tương ứng trong manifest. Nếu phạm vi chapter chưa đủ rõ, giữ mapping ở mức dự kiến và nhãn Verification required, không suy diễn nội dung chapter.
/01-curriculum/TEMPLATE_MANIFEST.md (TEMPLATE_MANIFEST)	Template dự kiến, phạm vi template, dependency đầu vào và giới hạn sử dụng	Với mỗi artifact mà competency cần thực hành, đối chiếu template có trong manifest và kiểm tra template nhận đúng đầu vào. Ví dụ, template traceability chỉ được liên kết khi dependency requirement, rule hoặc data reference được manifest cho phép.	Ghi tên template hoặc loại artifact theo manifest; phân biệt template dự kiến với artifact đã hoàn chỉnh. Không coi việc có template là bằng chứng baseline, approval hoặc chất lượng production.
/01-curriculum/CANONICAL_BUSINESS_RULES.md (CANONICAL_BUSINESS_RULES)	Định danh, nguồn, trạng thái và ranh giới của business rule (quy tắc nghiệp vụ: điều kiện quyết định hoặc ràng buộc nghiệp vụ)	Khi competency đề cập business rule, kiểm tra tham chiếu dùng đúng Artifact ID và không biến ví dụ học tập thành rule canonical. Đối chiếu nhãn nguồn: nội dung pháp lý, kế toán, thuế, an toàn thực phẩm hoặc quyền riêng tư chưa được xác minh phải giữ Verification required hoặc project assumption theo catalog.	Ghi năng lực “phân tích, truy vết và phân loại rule” thay vì khẳng định rule đúng cho vận hành thực tế. Không tạo, đổi nghĩa hoặc hợp nhất rule từ suy luận của ma trận.
/01-curriculum/CANONICAL_DATA_DICTIONARY.md (CANONICAL_DATA_DICTIONARY)	Entity, attribute, thuật ngữ dữ liệu logic, phân loại dữ liệu và ranh giới dữ liệu tổng hợp	Khi competency cần data mapping, kiểm tra tên entity hoặc attribute tham chiếu có trong từ điển dữ liệu canonical. Phân biệt logical data dictionary với schema triển khai; không tự suy ra kiểu dữ liệu vật lý, API field, dữ liệu cá nhân thật hoặc cấu hình ERP.	Ghi năng lực đọc, làm rõ và truy vết dữ liệu logic; dùng ví dụ Nova Foods tổng hợp. Mọi thuộc tính chưa được canonical xác nhận chỉ được mô tả là giả định hoặc cần xác minh.
/01-curriculum/TRACEABILITY_ID_REGISTRY.md (TRACEABILITY_ID_REGISTRY)	Cú pháp, namespace, quy tắc cấp và liên kết ID cho yêu cầu, rule, data, test, risk hoặc artifact liên quan	Kiểm tra mọi ID được ma trận tham chiếu giữ nguyên chuỗi canonical, không trùng, không đổi tiền tố và không dùng ID minh họa như ID đã đăng ký. Kiểm tra quan hệ truy vết chỉ nối các loại đối tượng mà registry cho phép.	Ghi reference ID nguyên dạng khi đã tồn tại trong registry; nếu chưa có ID, mô tả loại liên kết cần đăng ký thay vì tự cấp mã mới trong ma trận.

Trình tự kiểm tra áp dụng cho từng hàng ma trận

1. Xác định competency, mức bao phủ dự kiến và bằng chứng học tập dự kiến của hàng ma trận.
2. Đối chiếu 01_CURRICULUM_ARCHITECTURE để xác nhận competency không phá vỡ chuỗi học hoặc ranh giới của curriculum.
3. Đối chiếu CHAPTER_MANIFEST để xác nhận chapter mapping thuộc một trong 26 chapter authoritative và phạm vi chapter hỗ trợ đúng competency đó.
4. Đối chiếu TEMPLATE_MANIFEST để xác nhận artifact thực hành dự kiến có template tương ứng và dependency đầu vào không mâu thuẫn.
5. Khi hàng có business rule, data hoặc traceability reference, lần lượt đối chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY.
6. Ghi kết quả kiểm tra tại hàng ma trận bằng các trạng thái kiểm soát: Aligned khi tham chiếu khớp nguồn; Verification required khi nguồn có nhưng ý nghĩa hoặc thẩm quyền chưa đủ để kết luận; Conflict detected khi ID, phạm vi, nguồn hoặc quan hệ truy vết mâu thuẫn. Các trạng thái này là bằng chứng review, không phải approval.

Tình huống đối chiếu	Lý do đánh giá	Cách ghi an toàn trong ma trận
Tên artifact và đường dẫn trùng khớp, nhưng artifact vẫn là IN_REVIEW	Định danh được xác nhận, còn nội dung vẫn có thể thay đổi và chưa được baseline	Giữ reference canonical, ghi IN_REVIEW v0.9.0, ngày 2026-08-07; không dùng “đã phê duyệt” hoặc “đã baseline”.
Chapter mapping có trong manifest nhưng template cần thiết chưa được manifest hỗ trợ	Competency có vị trí học nhưng bằng chứng thực hành chưa đủ căn cứ liên kết	Ghi chapter mapping theo manifest và đánh dấu artifact mapping là Verification required.
Ví dụ cần nhắc đến điều kiện pháp lý, kế toán, bảo mật hoặc dữ liệu cá nhân	Ma trận không có thẩm quyền tự chuyển nguồn bên ngoài thành nghĩa vụ Nova Foods	Chỉ ghi mục tiêu năng lực và nguồn phân loại; giữ nhãn Verification required, không viết kết luận tuân thủ.
ID trong bản nháp khác với registry, dù nghĩa vụ mô tả có vẻ tương tự	ID là khóa truy vết; thay đổi chuỗi có thể tạo liên kết sai hoặc đối tượng giả	Không chuẩn hóa thủ công. Ghi đúng ID registry nếu đã có, hoặc chỉ mô tả nhu cầu đăng ký ID.
Data term trong ví dụ không có trong data dictionary	Thuật ngữ mới có thể gây trùng nghĩa, sai nghĩa hoặc ngụ ý thiết kế triển khai	Dùng thuật ngữ canonical hiện có, hoặc gắn ví dụ là giả định cần xác minh; không bổ sung attribute vào ma trận.

Tất cả sáu artifact nguồn nêu trên đều đang ở IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Vì vậy, kết quả của kế hoạch đối chiếu chỉ xác nhận sự nhất quán dự kiến giữa các tài liệu đang xem xét. Kết quả này không tạo baseline, không ghi nhận approval, không xác nhận yêu cầu thực tế của Nova Foods và không cấp quyền sử dụng production.

Kiểm tra phủ kín năng lực cốt lõi và loại bỏ trạng thái Missing

Mục tiêu kiểm tra là bảo đảm ma trận cuối cùng không cam kết đào tạo một năng lực BA cốt lõi mà lại không có chỗ học hoặc cách người học thể hiện năng lực đó. “Phủ kín” nghĩa là mỗi năng lực cốt lõi trong khung năng lực của ma trận phải có ít nhất một mục tiêu học tập, một điểm đặt trong handbook và một bằng chứng đầu ra dự kiến. Cầu nối suy luận là: curriculum chỉ có thể tuyên bố phát triển năng lực khi người học được hướng dẫn thực hành và tạo ra đầu ra có thể quan sát; vì vậy, chỉ nêu tên năng lực hoặc chỉ có lý thuyết không đủ để đổi trạng thái sang Covered.

Trạng thái phủ kín	Điều kiện áp dụng trong ma trận	Kết luận kiểm tra
Covered	Có mục tiêu học tập cụ thể; có ít nhất một chapter thuộc tập 26 handbook chapter; có hoạt động hoặc đầu ra dự kiến cho người học; liên kết không mâu thuẫn với phạm vi Nova Foods mô phỏng.	Đạt điều kiện phủ kín.
Partial	Có mục tiêu hoặc chapter liên quan, nhưng thiếu một trong các thành phần: thực hành, đầu ra quan sát được, hoặc mức độ học phù hợp với năng lực.	Chưa được tính là phủ kín hoàn toàn; phải được xử lý theo kế hoạch riêng của mục Partial.
Missing	Không có mục tiêu học tập, không có chapter hỗ trợ, hoặc chỉ có đề cập rời rạc không tạo được năng lực thực hành.	Không chấp nhận trong ma trận dự kiến; phải sửa trước khi chuyển sang xem xét baseline.
Out of scope	Năng lực không thuộc năng lực BA cốt lõi đã chọn hoặc thuộc thẩm quyền chuyên môn khác như kết luận pháp lý, quyết định kế toán, phê duyệt bảo mật hay thiết kế kiến trúc triển khai.	Không được dùng để che trạng thái Missing; phải nêu rõ lý do loại trừ và ranh giới thẩm quyền.

Thực hiện kiểm tra theo từng dòng năng lực cốt lõi, không kiểm tra theo cảm nhận tổng thể. Người rà soát đọc cột năng lực, xác định mục tiêu học tập tương ứng, rồi đối chiếu chapter được gán với năng lực cần hình thành. Nếu chapter chỉ giải thích khái niệm mà không yêu cầu người học áp dụng vào tình huống Nova Foods Trading & Manufacturing mô phỏng bằng dữ liệu tổng hợp, bằng chứng cho năng lực vẫn chưa đầy đủ. Ví dụ, năng lực “phân tích yêu cầu” chỉ đạt Covered khi người học được học cách phân biệt yêu cầu nghiệp vụ với yêu cầu giải pháp, áp dụng vào tình huống ERP mô phỏng và tạo đầu ra yêu cầu có tiêu chí kiểm tra được; một đoạn định nghĩa đơn lẻ chỉ hỗ trợ nhận biết, không chứng minh năng lực thực hành.

Nhóm năng lực cốt lõi cần quét	Bằng chứng tối thiểu để không là Missing	Dấu hiệu phải gắn Missing
Chiến lược, bối cảnh và vấn đề nghiệp vụ	Mục tiêu học về vấn đề, mục tiêu, phạm vi và giá trị; chapter hướng dẫn áp dụng vào bối cảnh Nova Foods mô phỏng.	Chỉ mô tả ERP hoặc vai trò BA mà không có cách phân tích vấn đề.
Khám phá, khơi gợi và quản lý bên liên quan	Mục tiêu học, kỹ thuật thu thập thông tin, cách ghi nhận nhu cầu hoặc mâu thuẫn và bài tập đầu ra.	Chỉ liệt kê stakeholder hoặc kỹ thuật hỏi đáp.
Quy trình, yêu cầu, quy tắc nghiệp vụ và dữ liệu	Hướng dẫn phân tích quy trình, biểu đạt yêu cầu, phân biệt rule với requirement và mô hình hóa dữ liệu logic.	Không có chỗ để người học chuyển nhu cầu thành nội dung có cấu trúc.
Giải pháp số, tích hợp, UX, NFR và bảo mật	Mục tiêu học ở mức BA literacy, có tình huống nhận diện tác động và đầu ra phân tích phù hợp.	Đòi hỏi người học tự quyết kiến trúc, xác nhận bảo mật hoặc cam kết tuân thủ.
Delivery, kiểm thử, truy vết, vận hành và quản trị thay đổi	Có chuỗi học từ requirement đến tiêu chí chấp nhận, test basis và quản lý thay đổi.	Testing hoặc delivery xuất hiện tách rời, không nhận đầu vào từ phân tích.
Lãnh đạo, giao tiếp, đạo đức nghề nghiệp và AI-assisted work	Có hướng dẫn ra quyết định dựa trên bằng chứng, nêu giới hạn thẩm quyền và kiểm soát đầu ra do AI hỗ trợ.	Gán AI hoặc giao tiếp như kỹ năng tự phát, không có tiêu chí sử dụng an toàn và có trách nhiệm.

Quy tắc quyết định là Missing = 0 đối với toàn bộ tập năng lực cốt lõi trước khi ma trận được đưa sang bước xem xét tiếp theo. Không được đổi Missing thành Covered chỉ vì một chapter có tiêu đề gần nghĩa, một template dự kiến tồn tại, hoặc vì BA suy luận rằng người học “có thể tự học thêm”. Khi phát hiện Missing, người lập kế hoạch phải bổ sung hoặc điều chỉnh mục tiêu học và chapter mapping trong phạm vi corpus; nếu năng lực cần nội dung vượt thẩm quyền BA hoặc đòi hỏi xác nhận chuyên môn, phải giữ giới hạn đó là nội dung mô phỏng và không biến nó thành quyết định Nova Foods thực tế. Mọi kiểm tra áp dụng cho /01-curriculum/COMPETENCY_COVERAGE_MATRIX.md ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND; Nova Foods chỉ là case study giáo dục với dữ liệu tổng hợp.

Kế hoạch xử lý bắt buộc cho từng năng lực quan trọng ở mức Partial

Partial (phủ một phần) nghĩa là ma trận đã xác định ít nhất một bằng chứng học tập cho năng lực, nhưng bằng chứng đó chưa đủ để người học thực hiện độc lập trong bối cảnh Nova Foods Trading & Manufacturing mô phỏng. Một mục Partial được xem là quan trọng khi thiếu hụt của nó có thể làm đứt chuỗi từ khám phá nhu cầu đến yêu cầu, dữ liệu, quy tắc, giải pháp, kiểm thử hoặc bàn giao; hoặc khi năng lực đó cần để đọc, tạo, rà soát hay truy vết artifact. Đây là suy luận kiểm soát: một kỹ năng chỉ được nêu tên nhưng không có thực hành, đầu ra và tiêu chí đánh giá thì chưa tạo được năng lực làm việc có thể kiểm chứng.

Mỗi dòng Partial quan trọng trong ma trận cuối cùng phải có một treatment plan (kế hoạch xử lý), không được chỉ ghi nhận khoảng trống. Kế hoạch xử lý phải chỉ rõ phần năng lực còn thiếu, cách bổ sung có thể kiểm tra, artifact đầu ra dự kiến, tiêu chí đạt và trạng thái sau xử lý dự kiến. “Dự kiến” không phải xác nhận hoàn thành, baseline hoặc approval; toàn bộ nội dung Nova Foods trong kế hoạch là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

Thành phần bắt buộc của treatment plan	Quy tắc ghi trong ma trận	Lý do kiểm soát
Phần thiếu cụ thể	Nêu hành vi chưa được phủ, ví dụ: “phân biệt business rule với acceptance criteria” thay vì “cần học thêm requirement”.	Thiếu hụt có thể hành động chỉ khi diễn đạt thành một năng lực quan sát được.
Loại xử lý	Chọn một hoặc kết hợp: bổ sung giải thích nền tảng, ví dụ có hướng dẫn, bài thực hành độc lập, peer review mô phỏng, quality gate (cổng chất lượng), hoặc đánh giá.	Một định nghĩa đơn lẻ không bù được thiếu hụt về thực hành và kiểm tra chất lượng.
Artifact đầu ra	Ghi tên loại artifact mà người học phải tạo hoặc rà soát, như backlog, use case, bảng quyết định, mô hình dữ liệu logic, API contract hoặc test case. Không tạo ID mới ngoài registry.	Đầu ra biến năng lực trừu tượng thành bằng chứng có thể truy vết.
Tiêu chí đạt	Nêu điều kiện kiểm tra được, như “mỗi rule được tách khỏi requirement và nêu nguồn/nhãn giả định” hoặc “test case liên kết được với acceptance criteria”.	Tránh đóng Partial dựa trên cảm nhận chủ quan.
Ranh giới nguồn và thẩm quyền	Gắn Verification required khi nội dung chạm pháp lý, kế toán, bảo mật, kiến trúc hoặc quyết định nghiệp vụ thực tế.	Học liệu không được biến giả định thành quy định Nova Foods hoặc kết luận chuyên môn.
Kết quả dự kiến	Chỉ dùng Covered khi đã có nội dung học, thực hành, artifact và quality gate tương ứng trong kế hoạch; nếu thiếu một phần thì giữ Partial.	Ngăn việc nâng trạng thái chỉ vì đã gán một chương hoặc một template.

Áp dụng quy tắc xử lý theo mức thiếu hụt sau:

Dạng Partial quan trọng	Treatment plan tối thiểu	Bằng chứng dự kiến để chuyển trạng thái
Có khái niệm nhưng chưa có thao tác	Bổ sung ví dụ từng bước và bài thực hành cá nhân trên dữ liệu tổng hợp Nova Foods.	Người học tạo được artifact đúng cấu trúc và giải thích được quyết định chính.
Có thao tác nhưng chưa có tiêu chí chất lượng	Bổ sung checklist review và quality gate trước khi nộp artifact.	Artifact được tự rà soát theo tiêu chí rõ ràng; lỗi phát hiện và cách sửa được ghi nhận.
Có artifact nhưng chưa có liên kết đầu-cuối	Bổ sung bài tập nối nhu cầu, requirement, rule, dữ liệu, acceptance criteria và kiểm thử khi phù hợp.	Liên kết truy vết có thể đọc ngược từ đầu ra về nguồn học liệu mà không suy diễn thêm.
Có ví dụ nhưng chỉ ở một bối cảnh đơn giản	Bổ sung biến thể tình huống, ngoại lệ hoặc xung đột mô phỏng; không tự tạo quy tắc vận hành thực tế.	Người học phân biệt được điều kiện bình thường, ngoại lệ và điểm cần escalation.
Có nội dung kỹ thuật nhưng BA chưa biết giới hạn vai trò	Bổ sung phần “BA làm gì, không tự quyết gì, hỏi ai” và tình huống escalation.	Người học chuyển đúng vấn đề đến Architect, QA, Legal, Accounting, Security hoặc Business Owner khi vượt thẩm quyền.
Liên quan quy định hoặc dữ liệu nhạy cảm nhưng nguồn chưa đủ	Giữ Partial, gắn Verification required, mô tả câu hỏi xác minh và vai trò có thẩm quyền.	Chỉ được nâng trạng thái khi có nguồn phù hợp và kết luận được ghi nhận bởi vai trò có thẩm quyền; không suy diễn từ học liệu.

Ví dụ áp dụng: nếu năng lực “viết acceptance criteria” có mô tả và ví dụ nhưng chưa yêu cầu người học liên kết tiêu chí với test case, dòng này vẫn là Partial. Treatment plan phải bổ sung bài thực hành viết acceptance criteria cho một yêu cầu mô phỏng, tạo test case tương ứng theo thuật ngữ kiểm thử phù hợp, rồi áp dụng quality gate kiểm tra tính rõ ràng, khả năng kiểm thử và liên kết. Nếu ví dụ liên quan hóa đơn, dữ liệu cá nhân hoặc sổ sách, nội dung chỉ được dùng như tình huống tổng hợp và phải giữ nhãn Verification required; BA không được tự kết luận nghĩa vụ pháp lý, kế toán hoặc tuân thủ.

Không được đóng một Partial quan trọng bằng cách trỏ tới một chương chung, một template trống hoặc một nguồn bên ngoài mà không nêu hành động và bằng chứng. Nếu chưa xác định được artifact đầu ra, tiêu chí đạt, nguồn phù hợp hoặc vai trò xác minh cho treatment plan, mục phải tiếp tục giữ Partial và được ghi nhận là khoảng trống cần xử lý trước khi ma trận được xem xét cho bước tiếp theo.

Kiểm tra căn chỉnh ánh xạ với 26 handbook chapter và ràng buộc case study Nova Foods

Ánh xạ chương là liên kết có thể kiểm tra giữa một năng lực trong ma trận và chapter nơi người học được dạy, thực hành hoặc đánh giá năng lực đó. Mục tiêu kiểm tra không phải là tăng số liên kết, mà là bảo đảm người học nhận đúng tiền đề trước khi thực hiện bài tập tiếp theo. Bằng chứng cấu trúc là /01-curriculum/01_CURRICULUM_ARCHITECTURE.md xác định chuỗi học và dependency; bằng chứng danh mục là /01-curriculum/CHAPTER_MANIFEST.md là manifest có thẩm quyền cho đúng 26 handbook chapter. Vì vậy, ma trận không được tự đặt tên chapter, số chapter, filename hoặc dependency thay thế hai artifact này.

Phép kiểm	Cách thực hiện	Điều kiện đạt	Lý do và cầu nối suy luận
Đủ tập 26 chapter	Đối chiếu tập chapter được tham chiếu trong ma trận với toàn bộ 26 entry canonical của CHAPTER_MANIFEST.	Mỗi tham chiếu trỏ đến đúng một entry manifest; không có chapter ngoài manifest, chapter trùng do đổi cách viết, hoặc chapter manifest bị bỏ khỏi phạm vi kiểm tra.	Manifest là nguồn kiểm soát danh mục chapter; một tên tự đặt có thể tạo liên kết không truy vết được.
Đúng mục đích chapter	So sánh năng lực, mức độ mong đợi và loại hoạt động trong ô ma trận với mục tiêu, scope và dependency của chapter trong manifest và architecture.	Chapter được gán thực sự dạy hoặc sử dụng năng lực đó; không chỉ nhắc thuật ngữ hoặc dùng kết quả mà chưa dạy tiền đề.	Việc “có đề cập” không chứng minh “có năng lực”; người học mới cần được xây nền trước khi áp dụng.
Đúng thứ tự học	Rà các liên kết từ năng lực nền tảng đến năng lực áp dụng, kiểm thử và bàn giao theo dependency kiến trúc.	Không yêu cầu learner viết acceptance criteria, test basis, API description hoặc mô hình dữ liệu trước khi có chapter cung cấp requirement, business rule, dữ liệu hoặc quy trình làm đầu vào.	Một đầu ra BA chỉ đáng tin khi có đầu vào đã được giải thích và kiểm soát; đảo thứ tự tạo ra học thuộc mẫu thay vì năng lực độc lập.
Không gán quá mức	Kiểm tra từng chapter được gán nhiều năng lực để phân biệt “chủ đạo”, “hỗ trợ” và “tham chiếu”.	Một chapter chỉ chịu trách nhiệm chính cho nội dung nằm trong scope manifest; các liên kết hỗ trợ phải nêu rõ học viên dùng lại kiến thức nào.	Gán mọi năng lực cho mọi chapter làm mất trách nhiệm dạy học và che lấp khoảng trống coverage.
Phù hợp case study	Rà ví dụ, bài tập và đầu ra được liên kết với chapter để xác nhận cùng bối cảnh Nova Foods Trading & Manufacturing.	Mọi tình huống là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ mô phỏng VND khi có giá trị tiền.	Metadata của architecture và manifest giới hạn Nova Foods là case study mô phỏng; dữ liệu hay quyết định thực tế sẽ vượt phạm vi corpus.
Giữ ranh giới thẩm quyền	Rà các chapter có nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc kiến trúc.	Liên kết chỉ đào tạo cách BA ghi nhận, phân tích và chuyển câu hỏi; không biến bài tập thành kết luận pháp lý, kế toán, bảo mật, cấu hình ERP hay quyết định vận hành.	Owner curriculum không thay thế Legal, Accounting, Security, Architect hoặc Business Owner; ví dụ học liệu không tạo thẩm quyền chuyên môn.

Mỗi dòng ánh xạ trong ma trận phải dùng tối thiểu bốn trường kiểm tra: năng lực, chapter canonical theo CHAPTER_MANIFEST, vai trò của chapter (Chủ đạo hoặc Hỗ trợ), và bằng chứng học tập dự kiến. Trường “Chủ đạo” chỉ được dùng khi chapter có mục tiêu và hoạt động giúp learner tạo hoặc đánh giá đầu ra của năng lực; trường “Hỗ trợ” chỉ được dùng khi chapter dùng lại năng lực đã được hình thành ở chapter khác. Ví dụ, một chapter sử dụng sơ đồ quy trình trong case Nova Foods chỉ là hỗ trợ cho năng lực đọc quy trình nếu manifest không xác định việc hướng dẫn mô hình hóa quy trình là mục tiêu của chapter đó.

Kết quả kiểm tra phải ghi theo ba trạng thái: Aligned khi liên kết khớp manifest, dependency và ràng buộc case study; Needs correction khi chapter tồn tại nhưng vai trò, thứ tự hoặc bằng chứng học tập chưa khớp; Blocked khi liên kết cần một chapter, nội dung case hoặc quyết định ngoài scope canonical. Blocked không được xử lý bằng cách tự tạo chapter thứ 27, đổi tên entry manifest, bổ sung yêu cầu Nova Foods giả định là sự thật, hoặc diễn giải quy định thành nghĩa vụ triển khai. Với trạng thái này, ma trận giữ nhãn Verification required và chuyển câu hỏi có ranh giới rõ ràng tới artifact hoặc vai trò có thẩm quyền phù hợp.

Kiểm tra ánh xạ artifact có ví dụ làm mẫu và cổng chất lượng

Mỗi dòng ánh xạ năng lực–artifact trong ma trận cuối phải chứng minh được người học không chỉ “biết tên” artifact mà còn có một ví dụ làm mẫu (worked example — mẫu đã được điền một phần hoặc hoàn chỉnh để chỉ ra cách áp dụng) và một cổng chất lượng (quality gate — điều kiện kiểm tra tối thiểu trước khi artifact được coi là đủ đầu vào cho hoạt động học kế tiếp). Cầu nối suy luận là: CHAPTER_MANIFEST quản lý các chapter, TEMPLATE_MANIFEST quản lý template dự kiến; vì vậy, một năng lực được ánh xạ đến chapter hoặc template nhưng thiếu mẫu thực hành và tiêu chí kiểm tra sẽ không chứng minh được khả năng chuyển kiến thức thành đầu ra BA có thể rà soát.

Thành phần cần có trên dòng ánh xạ	Điều kiện kiểm tra cụ thể	Bằng chứng cần ghi trong ma trận	Kết quả nếu không đạt
Artifact đích	Ghi đúng Artifact ID và đường dẫn canonical khi artifact đã được xác định trong manifest hoặc registry. Không dùng tên tệp suy đoán hay bản sao.	Ví dụ: CHAPTER_MANIFEST, /01-curriculum/CHAPTER_MANIFEST.md; TEMPLATE_MANIFEST, /01-curriculum/TEMPLATE_MANIFEST.md.	Không công nhận ánh xạ artifact; giữ trạng thái cần làm rõ, không tự tạo định danh thay thế.
Ví dụ làm mẫu	Có tình huống Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, đầu vào, cách điền và đầu ra mong đợi.	Mô tả ngắn một mẫu như “phiếu làm rõ yêu cầu truy xuất lô hàng” với mã lô tổng hợp, câu hỏi, giả định và kết quả cần kiểm tra.	Năng lực chỉ được xem là có tài liệu tham khảo, chưa có bằng chứng thực hành.
Cổng chất lượng	Có tiêu chí đạt/không đạt có thể kiểm tra, gắn với mục đích artifact và không biến giả định thành quy tắc vận hành.	Danh sách điều kiện như đủ nguồn, đủ ID liên kết, phân biệt fact/assumption/Verification required, và không có dữ liệu thực.	Artifact không được dùng làm đầu vào cho bài tập, traceability hoặc đánh giá tiếp theo.
Vai trò rà soát	Cổng yêu cầu chuyên môn nào thì chỉ rõ vai trò có thẩm quyền kiểm tra.	QA kiểm tra khả năng kiểm thử; Architect kiểm tra ranh giới kỹ thuật; Business Owner xác nhận ngữ cảnh nghiệp vụ mô phỏng khi cần.	Không gán kết luận chuyên môn cho Principal IT Business Analyst / Technical Curriculum Author.
Nguồn và nhãn	Mỗi mẫu giữ nhãn phân loại nguồn: nguồn chuẩn, nguồn pháp lý chính thức, giả định dự án, hoặc Verification required.	Liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY hoặc nguồn ngoài được phép dùng theo ranh giới đã công bố.	Dừng sử dụng mẫu nếu nhãn nguồn bị thiếu hoặc diễn đạt nguồn tham khảo thành nghĩa vụ bắt buộc.

Ví dụ kiểm tra áp dụng: nếu một dòng ma trận ánh xạ năng lực “viết tiêu chí chấp nhận” tới một template dự kiến trong TEMPLATE_MANIFEST, dòng đó phải nêu một mẫu tiêu chí cho tình huống đơn hàng mô phỏng Nova Foods. Mẫu cần có điều kiện đầu vào, hành vi mong đợi và kết quả kiểm tra được; ví dụ không được khẳng định chính sách giao hàng, thuế, hóa đơn hoặc lưu trữ dữ liệu là quy tắc thực tế của Nova Foods. Cổng chất lượng tương ứng chỉ đạt khi tiêu chí có thể kiểm thử, tham chiếu được requirement hoặc business rule đã phân loại nguồn, và không chứa dữ liệu cá nhân hay giao dịch thật.

Loại artifact học tập	Ví dụ làm mẫu tối thiểu	Cổng chất lượng tối thiểu
Requirement hoặc user story	Một yêu cầu mô phỏng về ghi nhận trạng thái lô hàng, có actor, mục tiêu, phạm vi và nhãn nguồn.	Không mâu thuẫn với CANONICAL_BUSINESS_RULES; mọi quy tắc chưa xác minh phải giữ Verification required.
Business rule catalog entry	Một quy tắc mô phỏng có điều kiện, kết quả, ngoại lệ và nguồn phân loại.	Không diễn giải luật, kế toán hoặc an toàn thực phẩm thành kết luận có thẩm quyền khi chưa có xác minh phù hợp.
Data dictionary entry	Một thuộc tính dữ liệu logic mô phỏng, gồm định nghĩa, kiểu dữ liệu logic, ví dụ tổng hợp và liên kết rule.	Không biến mô hình logic thành cấu hình ERP; không chứa dữ liệu thật; liên kết được tới CANONICAL_DATA_DICTIONARY.
Test scenario	Một kịch bản kiểm thử từ requirement và tiêu chí chấp nhận mô phỏng, gồm dữ liệu đầu vào tổng hợp và kết quả kỳ vọng.	Có test basis truy vết được; kết quả kỳ vọng không dựa trên giả định chưa gắn nhãn.
API hoặc tích hợp	Một yêu cầu giao tiếp API mô phỏng, mô tả mục đích, dữ liệu trao đổi và lỗi dự kiến.	Nếu tham chiếu OpenAPI thì chỉ dùng đúng ranh giới OAS 3.1.1; quyết định kiến trúc, bảo mật hoặc endpoint thực phải được chuyển đúng vai trò.

Người lập ma trận ghi “có ví dụ” chỉ khi ví dụ thực sự hướng dẫn thao tác trên artifact, không chỉ nhắc tên artifact. Người lập ma trận ghi “qua cổng chất lượng” chỉ khi từng điều kiện kiểm tra có bằng chứng truy vết đến artifact canonical hoặc nhãn nguồn rõ ràng. Vì toàn bộ corpus đang ở IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, mọi kết quả kiểm tra này chỉ xác nhận mức sẵn sàng của kế hoạch học liệu mô phỏng; không tạo baseline, approval, xác nhận tuân thủ hoặc quyền sử dụng production.

Danh sách tự rà soát: đầy đủ, không chồng lấp, truy vết và nhãn nguồn

Tự rà soát (self-review) là bước người lập ma trận kiểm chứng chất lượng logic của chính bản dự thảo trước khi chuyển sang vòng xem xét khác. Với Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục chỉ dùng dữ liệu tổng hợp, kết quả tự rà soát chỉ xác nhận mức sẵn sàng để tiếp tục IN_REVIEW; không xác nhận baseline, approval, tính tuân thủ hay khả năng dùng cho production.

Mã kiểm	Tiêu chí và cách kiểm cụ thể	Bằng chứng phải có trong ma trận	Kết quả hợp lệ
SR-CMP-01	Đầy đủ (completeness): từng năng lực cốt lõi phải có một dòng riêng, mức độ bao phủ, chapter, artifact, ví dụ thực hành và cổng chất lượng (quality gate, điểm kiểm tra điều kiện đạt) tương ứng.	Mỗi dòng năng lực có đủ các trường bắt buộc; không để trống mapping chỉ vì nội dung sẽ được viết sau.	Không có năng lực cốt lõi ở trạng thái Missing.
SR-CMP-02	Kiểm tra tính đầy đủ của chuỗi học: người học phải có đầu vào kiến thức trước khi được yêu cầu tạo artifact hoặc thực hiện quality gate.	Mapping thể hiện thứ tự từ khái niệm, kỹ thuật, ví dụ Nova Foods mô phỏng, bài thực hành đến tiêu chí kiểm tra.	Không có artifact hoặc đánh giá đòi hỏi khái niệm chưa được dạy.
SR-NOV-01	Không chồng lấp (non-overlap): một competency có thể xuất hiện ở nhiều chapter, nhưng mỗi chapter phải đóng góp một mục tiêu khác nhau.	Mô tả vai trò chapter phân biệt rõ: giới thiệu, thực hành, áp dụng tình huống, kiểm tra chất lượng hoặc tích hợp.	Không có hai dòng có cùng competency, cùng mục tiêu học, cùng artifact và cùng quality gate.
SR-NOV-02	Nếu một artifact phục vụ nhiều competency, xác định competency chính và competency hỗ trợ để tránh đếm đôi mức bao phủ.	Cột ghi chú nêu rõ “chính” hoặc “hỗ trợ”, cùng lý do dựa trên đầu ra học tập.	Một artifact không được dùng làm bằng chứng duy nhất cho hai competency độc lập nếu không phân tách tiêu chí chấm.
SR-TRC-01	Truy vết (traceability): mỗi khẳng định về năng lực, chapter, artifact hoặc quy tắc phải lần ngược được đến một định danh canonical hoặc nguồn được phép.	Giữ nguyên ID, filename và phân loại nguồn; liên kết dùng dạng tham chiếu, không sao chép làm nguồn chân lý mới.	Không có ID tự tạo, ID biến thể, filename rút gọn hoặc liên kết không xác định được nguồn.
SR-TRC-02	Kiểm tra chuỗi bằng chứng của mỗi competency: competency → chapter → artifact → worked example (ví dụ đã làm mẫu) → quality gate.	Từng mũi tên trong chuỗi có tên đối tượng và mục đích kiểm tra rõ ràng.	Có thể giải thích vì sao artifact chứng minh được năng lực, thay vì chỉ nêu tên artifact.
SR-SRC-01	Nhãn nguồn (source labeling): phân biệt nguồn chuẩn mực, nguồn pháp lý chính thức, artifact nội bộ canonical, giả định dự án và mục cần xác minh.	Mỗi dòng có nhãn nguồn phù hợp với loại phát biểu đang sử dụng.	Không trình bày giả định Nova Foods như quy tắc vận hành, nghĩa vụ pháp lý hoặc cấu hình ERP thực tế.
SR-SRC-02	Kiểm tra giới hạn sử dụng nguồn: BABOK Guide dùng cho thuật ngữ và năng lực BA; BPMN và UML dùng cho ký pháp; ISTQB CTFL dùng cho thuật ngữ kiểm thử; OpenAPI Specification dùng cho mô tả HTTP API; WCAG dùng cho khả năng tiếp cận; OWASP dùng cho thực hành an ninh.	Khi viện dẫn, chỉ nêu phạm vi sử dụng đã xác minh; không nêu số trang, điều khoản hoặc diễn giải chi tiết chưa có văn bản được cấp quyền.	Không gán thẩm quyền pháp lý cho nguồn ngành, và không gán nghĩa vụ kỹ thuật cụ thể vượt bằng chứng nguồn.
SR-SRC-03	Nội dung liên quan dữ liệu cá nhân, kế toán, hóa đơn chứng từ, an toàn thực phẩm hoặc truy xuất phải mang nhãn Verification required khi chưa có xác minh bởi vai trò có thẩm quyền.	Nhãn nằm ngay tại phát biểu hoặc dòng mapping bị ảnh hưởng, kèm loại quyết định cần xác minh.	Không dùng nhãn này để che giấu thiếu sót; vẫn phải mô tả ranh giới điều chưa được kết luận.

Quy tắc quyết định khi tự rà soát: Một dòng chỉ được đánh dấu “đủ điều kiện giữ trong bản ma trận IN_REVIEW” khi đạt đồng thời SR-CMP-01, SR-NOV-01, SR-TRC-01 và SR-SRC-01. Lý do là năng lực không có bằng chứng học tập thì không thể đo được; nội dung trùng lặp làm sai cảm nhận về độ bao phủ; thiếu truy vết làm mất khả năng kiểm tra; và nhãn nguồn sai làm vượt ranh giới thẩm quyền.

Ví dụ áp dụng: Nếu competency “phân tích quy tắc nghiệp vụ” được liên kết với một catalog quy tắc và một ví dụ Nova Foods mô phỏng, dòng ma trận phải nêu artifact làm đầu ra, ví dụ đã làm mẫu để người mới hiểu cách áp dụng, và quality gate kiểm tra quy tắc có điều kiện, ngoại lệ, nguồn và trạng thái xác minh hay không. Nếu ví dụ đề cập thời hạn lưu chứng từ hoặc nghĩa vụ pháp lý, nhãn phải là nguồn pháp lý chính thức hoặc Verification required; không được suy luận từ case study mô phỏng thành kết luận pháp lý.

Danh sách vấn đề mở về khoảng trống nguồn và nội dung cần xác minh

Danh sách này ghi nhận các điểm chưa đủ bằng chứng để ma trận năng lực được diễn đạt như một kết luận chuyên môn hoặc quy định áp dụng. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi ví dụ, mã, số tiền VND và dữ liệu trong ma trận chỉ dùng dữ liệu tổng hợp. Tại ngày 2026-08-07, tất cả artifact liên quan đang ở trạng thái IN_REVIEW, phiên bản v0.9.0; vì vậy một liên kết tới artifact không tự chứng minh rằng nội dung đã được baseline, phê duyệt hoặc áp dụng cho production.

Vấn đề mở	Bằng chứng và cầu nối suy luận	Nhãn bắt buộc trong ma trận khi chưa đóng vấn đề	Bằng chứng cần có để đóng vấn đề	Ranh giới sử dụng hiện tại
Diễn giải nghĩa vụ bảo vệ dữ liệu cá nhân cho ví dụ ERP	Nguồn chính thức đã xác định là Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, đều có hiệu lực từ 2026-01-01; source seed không cung cấp diễn giải áp dụng cho từng trường dữ liệu, luồng tích hợp hoặc quyền truy cập của Nova Foods. Do đó không thể suy từ tên luật thành yêu cầu hệ thống cụ thể.	Verification required — legal/privacy interpretation	Diễn giải được ghi nhận trong artifact kiểm soát, nêu rõ phạm vi dữ liệu, mục đích xử lý và giới hạn áp dụng cho tình huống mô phỏng.	Chỉ dạy cách BA ghi nhận câu hỏi, phân loại giả định và truy vết nguồn; không tuyên bố cấu hình ERP tuân thủ pháp luật.
Yêu cầu kế toán, thuế, hóa đơn và chứng từ	Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP là nguồn pháp lý đã nhận diện, nhưng source seed yêu cầu xác minh các sửa đổi sau này trước khi dùng cho production. Mọi ví dụ hóa đơn, hạch toán, thuế suất hoặc thời hạn chứng từ vượt quá dữ liệu nguồn hiện có.	Verification required — accounting/tax/invoice interpretation	Nguồn chính thức hiện hành được đối chiếu và kết luận áp dụng được ghi nhận minh bạch trong artifact kiểm soát.	Chỉ dùng tình huống chứng từ tổng hợp để luyện elicitation, rule analysis và traceability; không trình bày như hướng dẫn kế toán hoặc thuế.
Quy tắc truy xuất nguồn gốc và thu hồi thực phẩm	Luật 55/2010/QH12 cung cấp bối cảnh pháp lý về an toàn thực phẩm, nhưng source seed nêu rõ việc ánh xạ sang quy trình traceability hoặc recall cần xác minh theo chuyên môn miền nghiệp vụ và pháp lý. Vì thế không thể tự tạo thời hạn, mức độ lô hàng hoặc luồng thu hồi cho Nova Foods.	Verification required — food-safety/traceability interpretation	Bằng chứng về phạm vi quy trình, dữ liệu lô và điều kiện truy xuất được ghi nhận trong catalog quy tắc hoặc artifact kiểm soát liên quan.	Có thể dùng chuỗi lô hàng hoàn toàn tổng hợp để minh họa data lineage; không xác nhận đây là quy trình an toàn thực phẩm thực tế.
Tham chiếu điều khoản chính xác của tiêu chuẩn có kiểm soát bản quyền	BABOK Guide Version 3 và ISO/IEC/IEEE 29148:2018 được xác nhận qua trang chính thức, nhưng source seed giới hạn việc dùng nội dung đầy đủ hoặc điều khoản chính xác khi chưa có quyền truy cập và kiểm chứng. Do đó ma trận không được gán số trang, số điều khoản hoặc phát biểu chi tiết không có bằng chứng.	Verification required — licensed-text clause reference	Bản văn được cấp quyền truy cập hoặc bằng chứng thư mục chính thức cho phép đối chiếu chính xác phiên bản, điều khoản và ngữ cảnh.	Chỉ dùng thuật ngữ, phạm vi tổng quan và liên kết nguồn chính thức; không mô phỏng trích dẫn điều khoản.
Mức áp dụng cụ thể của OWASP, WCAG, OpenAPI, BPMN, UML và ISTQB	Các nguồn chuẩn hoặc hướng dẫn đã được xác định, gồm WCAG 2.2, OAS 3.1.1, BPMN 2.0.2, UML 2.5.1, ISTQB CTFL v4.0.1, OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023. Tuy nhiên, sự tồn tại của chuẩn không chứng minh một mức kiểm thử, cấu hình API, tiêu chí truy cập hay kiểm soát bảo mật cụ thể cho Nova Foods.	Verification required — solution/control applicability	Phạm vi áp dụng, phiên bản và tiêu chí đánh giá được xác định trong artifact kiểm soát, kèm nguồn tương ứng.	Dùng chuẩn để dạy thuật ngữ và cách đặt quality gate; không tuyên bố hệ thống mô phỏng đạt chứng nhận, compliant hoặc secure.
Nội dung canonical chưa phải là kết luận vận hành	CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều là kế hoạch canonical ở trạng thái IN_REVIEW. Vì vậy tên rule, entity, thuộc tính hoặc trạng thái dự kiến trong các artifact này chưa đủ căn cứ để trở thành requirement Nova Foods đã xác nhận.	Project assumption hoặc Verification required, tùy mức độ thiếu nguồn	Rule hoặc định nghĩa dữ liệu có định danh ổn định, nguồn, trạng thái xác minh và liên kết rõ tới artifact được kiểm soát.	Ma trận chỉ mô tả năng lực tạo và kiểm tra rule/data artifact, không khẳng định giá trị nghiệp vụ mô phỏng là đúng cho vận hành thực tế.
Thiếu bằng chứng baseline và approval cho các nguồn curriculum	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md, /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md đều ghi rõ chưa có baseline reference hoặc approval reference tại v0.9.0. Suy ra ma trận chỉ là kế hoạch xem xét, không phải cam kết đào tạo đã được chấp thuận.	IN_REVIEW — not baselined; no approval reference	Baseline reference hoặc approval reference được ghi nhận rõ trong artifact kiểm soát theo lịch sử thay đổi.	Không dùng ma trận để công bố chương trình chính thức, chứng minh năng lực đã được đánh giá, hoặc cho phép sử dụng production.
Khoảng trống nguồn cho yêu cầu phi chức năng có số đo	Source seed xác định các chuẩn tham khảo, nhưng không cung cấp mục tiêu định lượng riêng cho hiệu năng, khả dụng, khôi phục, lưu trữ, phân quyền hoặc logging của Nova Foods. Từ đó, mọi con số SLA, RTO, RPO, thời gian phản hồi hoặc thời hạn lưu giữ sẽ là suy diễn không có nguồn.	Project assumption — synthetic learning example hoặc Verification required	Nguồn nghiệp vụ, kiến trúc hoặc vận hành được ghi nhận cùng đơn vị đo, điều kiện đo và phạm vi áp dụng.	Chỉ dùng chỉ số tổng hợp để dạy cách viết NFR; không gán chỉ số đó cho ERP thực tế.

Quy tắc duy trì vấn đề mở: Mỗi dòng ma trận bị ảnh hưởng phải giữ nguyên nhãn nguồn cho đến khi có bằng chứng đóng vấn đề trong artifact kiểm soát. Việc một competency có ví dụ minh họa không thay thế nguồn chính thức, và việc một nguồn chính thức tồn tại không thay thế xác minh mức áp dụng cho Nova Foods mô phỏng.

Ma trận nhu cầu leo thang thẩm quyền

Leo thang (escalation) là chuyển một điểm cần quyết định hoặc xác minh đến đúng vai trò có thẩm quyền, kèm bằng chứng và câu hỏi đơn nghĩa; đây không phải là cơ chế xin phê duyệt ngầm. Trong corpus Nova Foods Trading & Manufacturing mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, Principal IT Business Analyst / Technical Curriculum Author lập gói leo thang và duy trì liên kết, nhưng không được tự thay thế kết luận chuyên môn. Mọi gói phải ghi rõ artifact bị ảnh hưởng, ID hoặc tên trường/quy tắc nếu đã tồn tại, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 theo Asia/Ho_Chi_Minh, nguồn tham chiếu, giả định hiện hành, quyết định cần có và tác động khi chưa có kết luận.

Vai trò nhận leo thang	Kích hoạt cụ thể trong ma trận năng lực	Bằng chứng tối thiểu trong gói	Ranh giới quyết định và cách xử lý kết quả
Senior BA	Một năng lực được gán mức độ, chương, artifact hoặc tiêu chí đánh giá nhưng cách diễn giải BA không nhất quán giữa các phần học; hoặc một năng lực cần phân biệt giữa kỹ năng phân tích và quyết định nghiệp vụ.	Dòng ma trận liên quan; mục tiêu học; dependency từ 01_CURRICULUM_ARCHITECTURE; lý do hai cách gán tạo khác biệt.	Senior BA hướng dẫn nguyên tắc BA và tính phù hợp sư phạm. BA chỉ cập nhật cách diễn giải khi kết luận được ghi nhận; không gọi đó là baseline hoặc approval.
Architect	Nội dung năng lực đề cập ranh giới hệ thống, tích hợp, API, cấu trúc dữ liệu kỹ thuật, hiệu năng, khả dụng hoặc lựa chọn kiến trúc.	Mapping tới CANONICAL_DATA_DICTIONARY, CHAPTER_MANIFEST hoặc TEMPLATE_MANIFEST; sơ đồ hoặc ví dụ tổng hợp; câu hỏi về giới hạn kỹ thuật.	Architect xác định tính hợp lý kiến trúc và các phụ thuộc kỹ thuật. Không được suy từ ví dụ học liệu thành cấu hình ERP Nova Foods thực tế.
QA Reviewer	Artifact học tập yêu cầu test basis, acceptance criteria, kỹ thuật kiểm thử, quality gate hoặc bằng chứng kiểm tra nhưng tiêu chí chưa kiểm thử được.	Requirement hoặc rule tham chiếu; điều kiện đầu vào, hành động, kết quả mong đợi; liên kết tới thuật ngữ ISTQB CTFL Syllabus v4.0.1 khi phù hợp.	QA Reviewer xác định khả năng kiểm thử và mức bằng chứng chất lượng. BA không tự tuyên bố test pass, chất lượng đạt, hay sẵn sàng production.
Legal Owner	Dòng ma trận hoặc ví dụ liên quan dữ liệu cá nhân, nghĩa vụ pháp lý, hóa đơn/chứng từ, an toàn thực phẩm, lưu giữ dữ liệu hoặc diễn giải quy định Việt Nam.	Nguồn chính thức liên quan, gồm Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 55/2010/QH12 hoặc Nghị định 123/2020/NĐ-CP khi áp dụng; nội dung dự kiến; nhãn Verification required.	Legal Owner xác minh diễn giải pháp lý và phạm vi áp dụng. Trước khi có kết luận, nội dung chỉ được mô tả là giả định dự án hoặc điểm cần xác minh, không phải nghĩa vụ bắt buộc.
Accounting Owner	Nội dung đề cập hạch toán, thuế, đối soát, kỳ kế toán, đơn vị tiền tệ VND, chứng từ hoặc quy tắc ghi nhận tài chính.	Quy tắc hoặc dữ liệu logic bị ảnh hưởng; ví dụ số liệu tổng hợp; tham chiếu Luật Kế toán 88/2015/QH13 và nguồn hóa đơn/chứng từ khi liên quan.	Accounting Owner xác định cách diễn giải kế toán. Ví dụ đào tạo không được nâng thành chính sách kế toán, cách tính thuế hoặc bút toán vận hành.
Security Owner	Nội dung có phân quyền, xác thực, secret, API endpoint, dữ liệu nhạy cảm, nhật ký, mã hóa hoặc nguy cơ API.	Thành phần và loại dữ liệu mô phỏng; luồng truy cập; rủi ro; tham chiếu OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023 khi phù hợp.	Security Owner xác định yêu cầu và mức kiểm soát bảo mật. BA không công bố chi tiết có thể bị hiểu là thông tin cấu hình thực hoặc xác nhận hệ thống an toàn.
Business Owner	Quy tắc, ưu tiên, KPI, ngoại lệ quy trình, quyền quyết định hoặc kết quả nghiệp vụ chưa có nguồn canonical rõ ràng.	Câu hỏi nghiệp vụ; lựa chọn tác động; quy trình/chapter liên quan; tham chiếu CANONICAL_BUSINESS_RULES nếu có; dữ liệu minh họa tổng hợp.	Business Owner xác định ý nghĩa nghiệp vụ và ưu tiên. Cho đến khi có ghi nhận kiểm soát phù hợp, BA giữ nhãn giả định hoặc Verification required, không tự xác nhận yêu cầu Nova Foods.

Khi một điểm đồng thời tác động pháp lý và bảo mật, kế toán và quy tắc nghiệp vụ, hoặc kiến trúc và kiểm thử, BA phải gửi cùng một gói có liên kết thống nhất tới các vai trò liên quan thay vì tách thành các kết luận độc lập. Lý do là một quyết định đơn lẻ có thể thay đổi nhiều loại bằng chứng: chẳng hạn trường dữ liệu mô phỏng vừa cần Business Owner xác định mục đích nghiệp vụ, vừa cần Legal Owner xác minh căn cứ xử lý dữ liệu, Security Owner xác định bảo vệ, Architect xác định khả năng triển khai và QA Reviewer xác định điều kiện kiểm thử. TRACEABILITY_ID_REGISTRY là nơi bảo toàn định danh và liên kết của gói; registry không thay thế thẩm quyền chuyên môn của bất kỳ vai trò nào.

Tiêu chí dừng khi ma trận kế hoạch tạo khoảng trống truy vết, xung đột nguồn hoặc vượt ranh giới thẩm quyền

Điều kiện dừng là quy tắc buộc ngừng soạn tiếp, không chuyển ma trận sang trạng thái xem xét baseline, khi bằng chứng hiện có không cho phép liên kết an toàn giữa năng lực BA, chapter, artifact, nguồn và người có thẩm quyền. Quy tắc này áp dụng cho Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, tại trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, theo vi-VN và Asia/Ho_Chi_Minh. “Traceability” (truy vết) là khả năng lần ngược từ một ô năng lực trong ma trận về nguồn, artifact và mục tiêu học tương ứng; vì vậy, một liên kết không xác định được nguồn hoặc ID canonical không thể được coi là liên kết hợp lệ.

Mã dừng	Điều kiện kích hoạt có thể kiểm chứng	Cầu nối bằng chứng và lý do dừng	Hành động bắt buộc khi dừng	Điều kiện được phép tiếp tục
STOP-TRC-01	Một năng lực, chapter, artifact, quy tắc hoặc dữ liệu được nêu trong ma trận nhưng không có ID, tên tệp hoặc điểm tham chiếu canonical tương ứng.	Ma trận chỉ có giá trị điều hướng khi một mục có thể lần về artifact nguồn. Nếu không xác định được liên kết tới /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md hoặc /01-curriculum/TRACEABILITY_ID_REGISTRY.md, người học và reviewer không thể phân biệt nội dung có căn cứ với suy diễn.	Gắn trạng thái STOP — PLAN REWORK REQUIRED cho phạm vi bị ảnh hưởng; không tạo liên kết thay thế bằng tên gần giống, ID tự đặt hoặc diễn giải tự do.	Liên kết được sửa để dùng đúng ID và đường dẫn canonical, hoặc mục không có nguồn được loại khỏi ma trận kế hoạch.
STOP-TRC-02	Một ô ma trận gán cùng một ID cho hai ý nghĩa khác nhau, hoặc dùng một biến thể ID không được registry công nhận.	TRACEABILITY_ID_REGISTRY là nguồn kiểm soát định danh. Một ID có nhiều nghĩa làm đứt quan hệ một-đến-một cần thiết để xác định artifact, phạm vi và lịch sử thay đổi.	Ngừng dùng ID mâu thuẫn trong ma trận; giữ nguyên nội dung đang tranh chấp ở nhãn Verification required, không đổi nghĩa của ID để làm khớp bảng.	Registry xác nhận định danh canonical hoặc một định danh hợp lệ được đăng ký theo cơ chế kiểm soát của corpus.
STOP-SRC-01	Nội dung ma trận mâu thuẫn về trạng thái, phiên bản, đường dẫn, phạm vi hoặc ranh giới sử dụng với metadata canonical của artifact nguồn.	Sáu artifact phụ thuộc đều xác định IN_REVIEW, v0.9.0 và không có baseline hoặc approval reference. Vì vậy, một ô mô tả nội dung là đã baseline, đã phê duyệt, production-ready hoặc đã được người dùng chấp thuận sẽ trái nguồn kiểm soát.	Dừng phạm vi có mâu thuẫn; thay mô tả kết luận bằng trạng thái kế hoạch phù hợp nếu bằng chứng cho phép, hoặc loại mô tả đó khỏi ma trận.	Mô tả trong ma trận khớp metadata nguồn, không suy diễn approval hay baseline từ sự tồn tại của artifact hoặc vai trò Owner.
STOP-SRC-02	Ma trận trình bày quy tắc pháp lý, kế toán, thuế, an toàn thực phẩm, bảo vệ dữ liệu cá nhân hoặc bảo mật như nghĩa vụ Nova Foods mà không có nguồn chính thức phù hợp và xác minh của vai trò có thẩm quyền.	Nguồn seed chỉ cho phép dùng nguồn chính thức trong ranh giới an toàn đã nêu; các chi tiết chưa đối chiếu văn bản hiện hành phải là giả định dự án hoặc Verification required. Học liệu không có quyền biến diễn giải thành nghĩa vụ vận hành.	Dừng việc ghi nhận mục đó là năng lực đã được bao phủ đầy đủ hoặc là quality gate bắt buộc; không tự tạo điều khoản, mức ngưỡng, thời hạn hay kết luận tuân thủ.	Nội dung được đổi thành mục học có nhãn phù hợp, hoặc có xác minh được ghi nhận từ thẩm quyền chuyên môn đúng phạm vi.
STOP-AUTH-01	Ma trận yêu cầu Principal IT Business Analyst / Technical Curriculum Author tự quyết định rule vận hành, cấu hình ERP, kiến trúc, kiểm thử, pháp lý, kế toán, bảo mật hoặc phê chuẩn chất lượng.	Owner chỉ duy trì tính toàn vẹn của artifact, định danh và liên kết quản trị. Quyết định chuyên môn hoặc vận hành thuộc authority boundary (ranh giới thẩm quyền) của vai trò được giao, không thuộc quyền của người soạn curriculum.	Dừng mục có yêu cầu vượt thẩm quyền; chỉ giữ câu hỏi, giả định và tác động học tập ở mức mô phỏng, không ghi kết luận thay cho vai trò chuyên môn.	Mục được giới hạn lại thành năng lực học tập, hoặc quyết định được ghi nhận từ vai trò có thẩm quyền trong artifact kiểm soát.
STOP-AUTH-02	Một worked example (ví dụ đã làm mẫu) hoặc quality gate (cổng chất lượng) bị diễn đạt như xác nhận dữ liệu thật, phê duyệt nghiệp vụ thật, kiểm thử thật hoặc quyền đưa vào production.	Nova Foods là mô phỏng và dữ liệu là tổng hợp; ví dụ chỉ chứng minh cách học viên thực hành, không chứng minh tính đúng đắn của ERP thực tế. Quality gate trong ma trận chỉ có thể kiểm tra chất lượng học liệu và tính nhất quán nội bộ.	Dừng cách diễn đạt có hàm ý vận hành thực tế; không dùng ví dụ để thay thế bằng chứng nghiệm thu, legal sign-off hoặc security verification.	Ví dụ và cổng chất lượng được gắn rõ là mô phỏng giáo dục, dữ liệu tổng hợp, không phải quyết định hoặc xác nhận production.

Khi bất kỳ mã dừng nào được kích hoạt, phạm vi bị ảnh hưởng không được đánh dấu là “Covered”, không được dùng để chứng minh đủ điều kiện baseline và không được bù bằng suy đoán. Việc tiếp tục chỉ hợp lệ sau khi nguyên nhân được xử lý bằng liên kết canonical, nhãn xác minh phù hợp hoặc giới hạn lại nội dung trong ranh giới thẩm quyền; trạng thái toàn tài liệu vẫn là IN_REVIEW cho đến khi artifact kiểm soát có bằng chứng trạng thái khác.