17 Implementation Readiness And Handoff Pack

Trường kiểm soát	Giá trị
Đường dẫn tệp được kiểm soát	/02-handbook/17-implementation-readiness-and-handoff-pack.md
Tiêu đề	17 Implementation Readiness And Handoff Pack
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp
Phân loại	Handbook chapter; học liệu có kiểm soát
Owner	Principal IT Business Analyst / Technical Curriculum Author
Baseline	Chưa có baseline reference tại v0.9.0; IN_REVIEW không phải BASELINED
Approval	Chưa có approval reference; metadata và nội dung review không tạo approval ngầm định
Nguồn tham chiếu	BABOK Guide Version 3: thuật ngữ và thực hành BA; ISO/IEC/IEEE 29148:2018: khung yêu cầu. Chỉ dùng trong phạm vi nguồn công khai đã xác minh; không suy diễn điều khoản có bản quyền.
Ranh giới thẩm quyền	Nội dung không xác nhận yêu cầu Nova Foods, cấu hình ERP, tuân thủ pháp lý, quyết định kế toán, bảo mật, vận hành hay quyền triển khai production.

1. Concept l? g??

Core

Implementation Readiness And Handoff Pack là gói bằng chứng có cấu trúc để đội triển khai nhận biết hệ thống cần có gì, dữ liệu nào cần sẵn, ai làm việc gì, điều kiện nào phải kiểm tra, và điểm nào chưa được xác nhận trước khi chuyển từ phân tích sang cấu hình, phát triển, kiểm thử hoặc vận hành. “Readiness” nghĩa là mức sẵn sàng; không phải lời khẳng định hệ thống đã sẵn sàng. “Handoff” nghĩa là bàn giao thông tin có truy vết giữa các vai trò; không phải chuyển trách nhiệm mơ hồ qua cuộc họp hoặc tin nhắn.

Từ điểm xuất phát, một thay đổi ERP không thể được triển khai an toàn chỉ vì có mô tả nhu cầu. Đội cấu hình cần biết quy tắc nào phải cấu hình; đội phát triển cần biết hành vi nào phải xây; QA cần biết cái gì làm test basis; business cần biết dữ liệu, quyết định và người chịu trách nhiệm nào còn thiếu. Bằng chứng cho nhu cầu này là mỗi nhóm tiêu thụ cùng một thay đổi theo mục đích khác nhau. Handoff pack gom các thông tin đã được định danh, liên kết và gắn trạng thái để giảm suy diễn khác nhau.

Khái niệm này có bốn phần nền tảng. Actor là tác nhân thực hiện hoặc chịu trách nhiệm cho công việc, ví dụ Warehouse Supervisor. Action là hành động cần làm, ví dụ xác nhận xuất kho. Object là đối tượng bị tác động, ví dụ phiếu xuất kho hoặc lô hàng. Outcome là kết quả quan sát được sau hành động, ví dụ tồn kho khả dụng giảm và chứng từ có trạng thái mới. Bốn phần này tạo câu hỏi tối thiểu: ai làm gì với cái gì để đạt kết quả nào. Nếu thiếu một phần, đội nhận bàn giao phải tự đoán; suy diễn đó làm tăng rủi ro build sai hoặc test sai.

Handoff pack không thay thế requirement, business rule, data dictionary, thiết kế kỹ thuật, kế hoạch kiểm thử hay quyết định phê duyệt. Nó là lớp liên kết giữa các artifact đó: chỉ rõ artifact nào là đầu vào, phiên bản nào đang được xem xét, ai tiêu thụ, và khoảng trống nào cần escalation. Vì IN_REVIEW chưa phải approval, pack tại trạng thái này phải giữ nhãn chưa xác nhận thay vì biến giả định thành quyết định.

Ví dụ tối thiểu, Nova Foods là case study mô phỏng dùng dữ liệu tổng hợp. Nhu cầu mô phỏng: nhân viên kho ghi nhận xuất 50 thùng sản phẩm từ lô LOT-SYN-20260807-01. Actor là nhân viên kho; action là xác nhận xuất; object là giao dịch xuất kho và lô tổng hợp; outcome là giao dịch được ghi nhận để các bước sau có cùng dữ liệu tham chiếu. Handoff pack chỉ ghi nhu cầu, artifact liên quan, trạng thái và điểm cần xác nhận. Pack không tự quyết cách hạch toán, cách truy xuất thực phẩm, quyền truy cập, cấu hình ERP, hay nghĩa vụ pháp lý; các nội dung đó cần owner có thẩm quyền và nguồn xác minh phù hợp.

Core

Implementation Readiness là mức sẵn sàng để đội triển khai dùng các đầu ra BA chuyển sang cấu hình, phát triển, kiểm thử, đào tạo hoặc vận hành. Handoff Pack là gói bàn giao có kiểm soát: tập hợp artifact, liên kết truy vết, trạng thái và điểm còn cần xác minh. Gói này không tự tạo phê duyệt, baseline hay quyền triển khai production.

Thuật ngữ	Nghĩa Việt Nam	Vai trò trong handoff
Actor	Chủ thể thực hiện hoặc chịu trách nhiệm hành động: người, vai trò, hệ thống.	Nêu rõ ai nhận, kiểm tra, dùng artifact.
Action	Hành động có thể quan sát: cấu hình, kiểm thử, xác minh, bàn giao.	Cho biết việc phải làm với đầu ra.
Object	Đối tượng bị tác động: requirement, rule, API, báo cáo, dữ liệu.	Xác định thứ được bàn giao, tránh nói chung chung.
Outcome	Kết quả mong đợi, có thể kiểm tra.	Xác định điều kiện hoàn thành handoff.
Artifact	Tài liệu hoặc tệp có định danh, ví dụ requirement specification hay traceability matrix.	Bằng chứng đầu vào cho vai trò nhận bàn giao.
Traceability	Truy vết liên kết nguồn, nhu cầu, requirement, rule, test và artifact liên quan.	Giúp phát hiện đầu ra thiếu nguồn hoặc mâu thuẫn.
Readiness	Trạng thái đủ đầu vào để bước kế tiếp bắt đầu có kiểm soát.	Không đồng nghĩa APPROVED, BASELINED hay production-ready.
Handoff	Chuyển giao trách nhiệm sử dụng đầu ra giữa vai trò hoặc giai đoạn.	Phải nêu người giao, người nhận, đối tượng và giới hạn.
RACI	Responsible, Accountable, Consulted, Informed: thực hiện, chịu trách nhiệm cuối, được tham vấn, được thông báo.	Làm rõ trách nhiệm; không thay approval record.
UAT	User Acceptance Testing: kiểm thử chấp nhận người dùng.	Là bước kiểm tra phù hợp nhu cầu, không phải bằng chứng tự động rằng mọi bên đã phê duyệt.

Công thức tối thiểu: Actor thực hiện Action trên Object để tạo Outcome. Ví dụ Nova Foods Trading & Manufacturing là mô phỏng: “QA Lead kiểm tra CANONICAL_BUSINESS_RULES để xác định test basis có liên kết nguồn.” Actor là QA Lead; action là kiểm tra; object là CANONICAL_BUSINESS_RULES; outcome là xác định được mức đầy đủ của test basis. Kết luận chỉ là đánh giá trong học liệu vì artifact đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải xác nhận cấu hình ERP thật.

Applied

Ví dụ tối thiểu — Nova Foods Trading & Manufacturing, mô phỏng giáo dục, dữ liệu tổng hợp: Nhân viên Kho thành phẩm là actor (người hoặc vai trò thực hiện). Người này thực hiện action (hành động) “xác nhận số lượng đã xuất”. Đối tượng là object (thực thể bị tác động) “Phiếu xuất kho mô phỏng GI-2026-00017”. Outcome (kết quả mong đợi) là hồ sơ bàn giao giúp đội triển khai biết dữ liệu, quy tắc, vai trò và điểm kiểm tra nào phải được chuyển thành cấu hình, phát triển hoặc kiểm thử.

Mục	Nội dung mô phỏng
Facts	ERP cần thay thế ghi chép bảng tính cho xác nhận xuất kho. Dữ liệu ví dụ: GI-2026-00017, mặt hàng NF-TP-001, số lượng 120, đơn vị thùng, ngày 2026-08-07, tiền tệ ngữ cảnh VND.
Current Behavior	Nhân viên Kho gửi bảng tính cho Kế toán sau khi hàng rời kho. Người nhận phải tự đối chiếu mã phiếu và số lượng.
Underlying Need	Đội triển khai cần một gói handoff chỉ rõ ai làm gì trên đối tượng nào, kết quả nào được chấp nhận, và phần nào còn cần xác minh. Bằng chứng: mô tả hiện tại có vai trò, phiếu và số lượng nhưng chưa tự tạo được tiêu chí cấu hình hay kiểm thử.
Options	(1) Chỉ bàn giao mô tả tự do. (2) Bàn giao có cấu trúc: phạm vi, quy tắc đã ghi nhận, dữ liệu mẫu tổng hợp, giả định, điểm cần xác minh và truy vết artifact.
Decision Criteria	Không mất ngữ cảnh nghiệp vụ; không biến giả định thành quy tắc bắt buộc; truy được nguồn; không trao quyền phê duyệt ngoài thẩm quyền.
Decision	Dùng gói handoff có cấu trúc. Gói ghi rõ IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, dữ liệu tổng hợp và trạng thái chưa baseline.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact. Business Owner, Architect, QA, Accounting Owner, Legal Owner và Security giữ thẩm quyền xác nhận phần thuộc chuyên môn của họ.
Artifact	/02-handbook/17-implementation-readiness-and-handoff-pack.md là học liệu. Nguồn quản trị liên quan: CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Consequence if Wrong	Nếu bàn giao nhầm “120 thùng” là dữ liệu production hoặc nhầm giả định thành quy tắc, đội triển khai có thể cấu hình sai, QA kiểm thử sai basis, hoặc Kế toán nhận dữ liệu không đủ căn cứ.

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

flowchart TB
    A[Actor: Nhân viên Kho] -->|xác nhận số lượng đã xuất| B[Object: Phiếu xuất kho mô phỏng<br/>GI-2026-00017 · 120 thùng<br/>Dữ liệu tổng hợp, không phải production]
    B --> H[Handoff pack có cấu trúc]

    M[Handoff owner:<br/>Principal IT Business Analyst /<br/>Technical Curriculum Author] -->|duy trì| H

    H --> K[Nội dung đã ghi nhận:<br/>dữ liệu, quy tắc ghi nhận, vai trò,<br/>nguồn và truy vết artifact]
    H --> G[Giả định và điểm cần xác minh]
    H --> S[Trạng thái:<br/>IN_REVIEW · v0.9.0 · chưa baseline]

    K --> R[Review và chuẩn bị:<br/>đội triển khai, QA]
    G --> X[Phần chưa xác minh:<br/>giữ IN_REVIEW · không baseline<br/>không dùng làm căn cứ production]
    S --> X

    G --> O[Owner chuyên môn:<br/>Business Owner · Architect · QA · Accounting · Legal · Security<br/>Xác nhận phần thuộc thẩm quyền]
    O -->|chỉ phần đã xác nhận| V[Được dùng theo thẩm quyền:<br/>cấu hình, phát triển hoặc kiểm thử]
    O -->|phần chưa xác nhận| X

    X --> W[Rủi ro:<br/>dữ liệu tổng hợp hoặc giả định bị hiểu là<br/>dữ liệu production hoặc quy tắc bắt buộc]
    W --> Z[Hệ quả:<br/>cấu hình hoặc kiểm thử sai basis]

Ranh giới concept: Implementation readiness and handoff pack là gói chuyển giao có kiểm soát giữa phân tích và thực thi. Gói này làm rõ nội dung đã biết, nguồn của nội dung, giả định, khoảng cần xác minh, người tiêu thụ và quyền quyết định. Gói không tự biến yêu cầu thành cấu hình ERP, không tự xác nhận dữ liệu đúng, không tạo baseline, không tạo approval, không xác nhận tuân thủ pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hay khả năng production.

Loại trừ: Không mô tả cấu hình màn hình, API, mapping dữ liệu, test case chi tiết, kế hoạch cutover, đào tạo người dùng, vận hành sau go-live hoặc quyết định chọn nhà cung cấp. Các nội dung đó cần artifact và vai trò có thẩm quyền riêng. Mọi chi tiết pháp lý, kế toán, thuế, truy xuất thực phẩm hoặc dữ liệu cá nhân trong ví dụ này là ngữ cảnh học liệu; cần xác minh bởi owner chuyên môn trước bất kỳ sử dụng thực tế nào.

2. T?i sao concept n?y t?n t?i?

Core

Implementation readiness and handoff pack tồn tại để ngăn khoảng trống giữa “BA đã phân tích” và “đội sau có thể thực thi đúng”. Handoff là chuyển giao có kiểm soát: người nhận biết phải dùng artifact nào, nội dung nào là đầu vào, giới hạn nào còn hiệu lực, ai có quyền quyết định, và điều gì không được tự suy diễn.

Nếu không có gói này, requirement có thể nằm rải rác trong ghi chú họp, bảng tính, ticket và trao đổi miệng. Đội triển khai phải chọn cách hiểu thay vì nhận một basis, tức căn cứ làm việc, có thể truy vết. Một lựa chọn kỹ thuật lúc đó dễ bị hiểu nhầm là quyết định nghiệp vụ; một giả định dễ bị cấu hình thành quy tắc; một khoảng chưa xác minh dễ bị QA kiểm thử như hành vi bắt buộc.

Rủi ro chính không phải thiếu tài liệu, mà thiếu ranh giới trách nhiệm. BA có thể mô tả nhu cầu, nhưng không tự xác nhận cấu hình ERP, diễn giải kế toán, tuân thủ pháp lý, bảo mật hoặc khả năng production. Gói bàn giao phải giữ ranh giới này để người triển khai biết khi nào phải dừng và chuyển vấn đề tới Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance.

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

flowchart TB
    A[BA artifact rời rạc] --> B{Có handoff pack kiểm soát?}

    B -->|Không| C[Đội nhận tự suy diễn]
    C --> D[Cấu hình hoặc kiểm thử lệch]
    D --> E[Rework và tranh chấp trách nhiệm]

    B -->|Có| F[Đầu vào, phạm vi, owner và giới hạn rõ]
    F --> I[Đội nhận thực thi theo căn cứ]
    I --> J{Có điểm chưa rõ?}
    J -->|Không| K[Thực thi có kiểm soát]
    J -->|Có| L[Đội nhận dừng tự suy diễn]
    L --> M[Chuyển tới owner có thẩm quyền xử lý]
    M --> N{Đã được xác minh hoặc quyết định?}
    N -->|Chưa| O[Chặn thực thi; giữ trạng thái chưa rõ]
    N -->|Rồi| P[Cập nhật căn cứ bàn giao]
    P --> K

    A -.-> H[Guardrail: BA không tự xác nhận cấu hình ERP, diễn giải kế toán, tuân thủ pháp lý, bảo mật hoặc khả năng vận hành production]
    H -.-> F
    M -.-> Q[Owner tùy vấn đề: Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance]

Applied

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, handoff pack ngăn đội nhận biến nội dung học liệu thành chỉ dẫn vận hành thật. Ví dụ, artifact có thể nêu mã chứng từ mô phỏng GI-2026-00017; mã này chỉ làm vật thể minh họa cho traceability, không chứng minh định dạng chứng từ, quy tắc xuất kho hoặc cấu hình ERP thực tế của Nova Foods.

Thiếu ranh giới trên gây bốn dạng hỏng. Thứ nhất, rework: đội cấu hình theo cách hiểu hiện tại rồi phải sửa khi nguồn canonical làm rõ. Thứ hai, ambiguity, tức mơ hồ: BA, QA và triển khai dùng cùng từ nhưng hiểu khác đối tượng, trạng thái hoặc điều kiện. Thứ ba, governance risk, tức rủi ro quản trị: nội dung IN_REVIEW bị dùng như baseline hoặc approval. Thứ tư, compliance risk: ngữ cảnh liên quan dữ liệu cá nhân, kế toán, hóa đơn hoặc an toàn thực phẩm bị diễn đạt thành yêu cầu bắt buộc khi chưa có xác minh owner chuyên môn.

Senior Lens

Gói bàn giao không thay thế quyết định; nó làm quyết định chưa có trở nên nhìn thấy được. Đây là khác biệt quan trọng. “Không rõ” nhưng được ghi nhận, gắn owner và điều kiện escalation an toàn hơn “có vẻ rõ” nhưng không có căn cứ.

Tại v0.9.0, trạng thái IN_REVIEW của corpus Nova Foods chỉ cho biết artifact đang được xem xét có kiểm soát. Nó không là APPROVED, không là BASELINED, không xác nhận production-ready và không tạo quyền tự triển khai. Vì vậy, handoff pack phải bảo toàn trạng thái nguồn thay vì nâng trạng thái bằng câu chữ.

Senior BA kiểm tra một câu hỏi trước khi chuyển giao: “Người nhận có thể phân biệt điều được cung cấp với điều họ phải xin quyết định không?” Nếu câu trả lời là không, gói chưa sẵn sàng để handoff, dù số lượng file nhiều.

Quick Reference

Rủi ro cần ngăn	Cơ chế của handoff pack	Hậu quả nếu thiếu
Diễn giải khác nhau	Chỉ rõ artifact nguồn, phạm vi và người tiêu thụ	Cấu hình, phát triển hoặc kiểm thử lệch nhau
Rework	Ghi rõ dependency và điểm cần escalation	Làm lại sau khi phát hiện căn cứ thiếu hoặc sai
Mất traceability	Giữ canonical ID và đường dẫn nguồn	Không biết thay đổi nào ảnh hưởng artifact nào
Vượt thẩm quyền	Nêu owner quyết định và giới hạn BA	Nội dung học liệu bị dùng như quyết định nghiệp vụ hoặc chuyên môn
Hiểu sai trạng thái	Bảo toàn IN_REVIEW, v0.9.0, ngày 2026-08-07	Nhầm review thành baseline, approval hoặc quyền production

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Implementation Readiness And Handoff Pack tồn tại để biến nội dung đã phân tích thành gói bàn giao có chủ sở hữu, phạm vi, bằng chứng kiểm tra và điểm mở rõ ràng. Không có gói này, đội triển khai phải tự đoán phần nào được giao, phần nào còn chờ quyết định.

Thành phần	Trước khi có handoff pack	Sau khi có handoff pack	Hệ quả quan sát được
Facts	Có yêu cầu mô phỏng tạo phiếu xuất kho cho đơn bán SO-NF-2026-00017; không có một tệp bàn giao tập trung.	Gói bàn giao liên kết yêu cầu, quy tắc, dữ liệu kiểm thử và trạng thái review.	Người nhận biết đúng tập artifact cần đọc.
Current Behavior	BA gửi ghi chú rời qua nhiều kênh; QA nhận mô tả luồng nhưng không biết dữ liệu nào dùng để kiểm tra.	BA lập danh mục bàn giao, nêu đầu vào, đầu ra, owner và trạng thái từng mục.	QA không phải suy diễn test basis, tức cơ sở để thiết kế kiểm thử.
Underlying Need	Đội ERP cần biết khi nào đơn bán được phép tạo phiếu xuất kho, ai chịu trách nhiệm làm rõ điểm chưa chốt, và bằng chứng nào xác nhận luồng.	Gói bàn giao tách phần sẵn sàng khỏi phần cần xác minh.	Developer không biến giả định thành cấu hình ERP.
Options	(1) Bàn giao qua trao đổi miệng; (2) gửi nhiều tệp không có chỉ mục; (3) dùng handoff pack có traceability.	Chọn phương án (3).	Có đường truy từ hạng mục bàn giao về artifact nguồn.
Decision Criteria	Không làm mất nguồn gốc; không gọi IN_REVIEW là đã phê duyệt; xác định người xử lý điểm mở; hỗ trợ kiểm thử và triển khai.	Handoff pack phải giữ nguyên ID, đường dẫn, trạng thái và version nguồn.	Governance không bị thay bằng suy đoán cá nhân.
Decision	Dùng handoff pack cho luồng xuất kho mô phỏng, tham chiếu artifact canonical thay vì chép lại quy tắc.	Trạng thái gói và artifact nguồn giữ IN_REVIEW, version v0.9.0, ngày 2026-08-07.	Người nhận không hiểu nhầm nội dung review là baseline hay approval.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability học liệu. Business Owner, Architect, QA và các owner chuyên môn giữ thẩm quyền quyết định phần thuộc phạm vi họ.	Không có phê duyệt nào được ghi nhận từ case mô phỏng này.	Không phát sinh tuyên bố thẩm quyền sai.
Artifact	Không có chỉ mục bàn giao duy nhất cho SO-NF-2026-00017.	Handoff pack tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.	Nguồn canonical không bị thay bằng bản sao cục bộ.
Consequence if Wrong	Developer có thể cấu hình xuất kho ngay khi đơn bán được tạo, trong khi điều kiện tồn kho hoặc phê duyệt chưa được xác định trong gói. QA có thể kiểm thử luồng khác cách hiểu của BA.	Điểm chưa rõ được ghi là cần xác minh trước cấu hình hoặc kiểm thử kết luận.	Giảm rework do phát hiện khác biệt khi đã cấu hình hoặc đã viết test.

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

flowchart TB
    A[BA ghi yêu cầu xuất kho mô phỏng] --> B{Có handoff pack?}

    B -- Không --> C[Không có chỉ mục artifact, owner và trạng thái]
    C --> D[Developer cấu hình luồng khác cách hiểu của BA]
    C --> E[QA thiết kế kiểm thử trên cơ sở khác cách hiểu của BA]

    B -- Có --> F[BA lập chỉ mục artifact, đầu vào, đầu ra và trạng thái]
    F --> G[BA gán từng điểm mở cho owner chuyên môn có thẩm quyền]
    G --> H{Điểm mở đã được owner xử lý?}

    H -- Chưa --> P[Dừng ở chuẩn bị<br/>Chưa cấu hình, QA chưa kết luận]
    H -- Đã --> I[Owner cập nhật artifact nguồn và trạng thái review<br/>BA cập nhật traceability]
    I --> J{Artifact nguồn đạt trạng thái cho phép triển khai<br/>và kết luận kiểm thử?}

    J -- Chưa --> P
    J -- Đã --> K[Developer cấu hình theo artifact nguồn]
    J -- Đã --> L[QA kiểm thử và kết luận theo artifact nguồn]

    F --> M[Case hiện tại<br/>IN_REVIEW, v0.9.0, chưa có phê duyệt]
    M --> P

Trước: câu “đơn bán tạo phiếu xuất kho” có thể bị hiểu là hành động tự động, hành động do kho thực hiện, hoặc hành động sau phê duyệt. Ba cách hiểu tạo ba cấu hình và ba bộ kiểm thử khác nhau. Sau: handoff pack ghi rõ artifact nào mô tả luồng, artifact nào giữ quy tắc, ai xử lý điểm mở và trạng thái IN_REVIEW; người nhận thấy ngay nội dung chưa đủ điều kiện kết luận.

Core

Implementation Readiness And Handoff Pack tồn tại để người nhận bàn giao phân biệt đúng loại thông tin trước khi dùng nó làm cấu hình, kiểm thử, quyết định hay cam kết. Cùng một câu về Nova Foods có thể là dữ kiện, ý kiến, giả định, quyết định, hoặc điểm cần xác minh. Gộp chúng thành “requirement” làm ERP cấu hình theo điều chưa được chứng minh.

Loại	Định nghĩa từ gốc	Bằng chứng tối thiểu	Được phép dùng làm gì	Không được suy diễn
Verified fact — sự kiện đã xác minh	Điều đã đối chiếu với nguồn xác định, còn truy xuất được	URL chính thức, artifact kiểm soát, bản ghi hệ thống, hoặc bằng chứng có ngày 2026-08-07	Làm đầu vào phân tích	Không tự biến thành quyết định hay yêu cầu
Stakeholder input — đầu vào bên liên quan	Điều một vai trò cung cấp từ góc nhìn, nhu cầu hoặc kinh nghiệm của họ	Tên vai trò, thời điểm, nội dung ghi nhận	Tạo câu hỏi, phương án, tiêu chí	Không gọi là fact nếu chưa đối chiếu
Project assumption — giả định dự án	Điều tạm coi đúng để công việc tiếp tục khi bằng chứng chưa đủ	Lý do, chủ sở hữu xác minh, điều kiện hết hiệu lực	Lập kế hoạch có điều kiện	Không cấu hình production như quy tắc đã chốt
Decision — quyết định	Lựa chọn giữa phương án bởi người có thẩm quyền xác định	Phương án, tiêu chí, authority, ngày, artifact	Làm cơ sở triển khai trong phạm vi quyết định	Không gọi là approval, baseline hay tuân thủ nếu chưa có bằng chứng riêng
Verification-required claim — nhận định cần xác minh	Phát biểu có thể ảnh hưởng pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc vận hành nhưng chưa đủ bằng chứng/thẩm quyền	Nhãn Verification required, nguồn cần kiểm tra, owner phù hợp	Chặn suy diễn; đưa vào hàng đợi xác minh	Không chuyển thành business rule

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

flowchart TB
    A[Thông tin nhận vào] --> B{Đã đối chiếu nguồn xác định<br/>và có bằng chứng truy xuất được?}
    B -- Có --> C[Verified fact]
    B -- Không --> D{Là phát biểu stakeholder<br/>có vai trò, thời điểm, nội dung?}
    D -- Có --> E[Stakeholder input]
    D -- Không --> F{Cần tạm dùng để lập kế hoạch<br/>và có lý do, owner xác minh,<br/>điều kiện hết hiệu lực?}
    F -- Có --> G[Project assumption]
    F -- Không --> H{Có thể ảnh hưởng pháp lý, kế toán,<br/>thuế, an toàn thực phẩm, bảo mật<br/>hoặc vận hành?}

    H -- Không --> Q[Lưu nguồn hoặc bằng chứng<br/>và làm rõ phân loại]
    H -- Có --> V[Verification-required claim]
    V --> W[Gắn nhãn Verification required;<br/>nêu nguồn cần kiểm tra và owner phù hợp]
    W --> Y[Owner phù hợp đối chiếu nguồn<br/>và lưu bằng chứng]
    Y --> X{Kết quả xác minh}
    X -- Đã xác minh --> C
    X -- Chưa đủ bằng chứng --> N[Chờ owner xác minh;<br/>không dùng làm business rule]
    X -- Bị bác bỏ --> Z[Lưu kết quả bác bỏ;<br/>không dùng làm business rule]

    C --> R[Thông tin có thể hỗ trợ<br/>quyết định triển khai]
    E --> R
    G --> R
    R --> I{Có phương án, tiêu chí, authority,<br/>ngày và artifact ghi nhận lựa chọn?}
    I -- Có --> J[Decision;<br/>liên kết thông tin hỗ trợ]
    I -- Không --> K[Giữ nguyên phân loại;<br/>lưu liên kết nguồn và bằng chứng]

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp. Tình huống bàn giao ERP: màn hình tạo lệnh xuất kho có trường Lot Number.

Mục	Nội dung ghi nhận	Phân loại	Cầu nối bằng chứng/lý do
Facts	CHAPTER_MANIFEST có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07; không có baseline hay approval reference.	Verified fact	Metadata artifact kiểm soát ghi rõ trạng thái; vì vậy không được nói nội dung đã được chấp thuận.
Current Behavior	Warehouse Supervisor nói nhân viên kho thường ghi mã lô khi xuất hàng.	Stakeholder input	Đây là báo cáo của vai trò, chưa có log ERP hay quy trình được xác minh kèm theo.
Underlying Need	Handoff cần biết Lot Number là bắt buộc, tùy chọn, hay chỉ hiển thị.	Verification-required claim	Câu trả lời ảnh hưởng validation, dữ liệu giao dịch và khả năng truy xuất; chưa có nguồn nghiệp vụ/pháp lý được xác minh cho cấu hình này.
Options	(1) bắt buộc nhập Lot Number; (2) cho phép trống; (3) chặn xuất kho khi chưa chọn lô từ tồn kho.	Options	Ba lựa chọn tạo hành vi hệ thống khác nhau; không lựa chọn nào tự đúng từ stakeholder input.
Decision Criteria	Có bằng chứng quy trình kho; khả năng dữ liệu tồn kho theo lô; kết luận của Business Owner và domain owner; tác động kiểm thử.	Decision criteria	Tiêu chí nối nhu cầu với bằng chứng và thẩm quyền, không dựa vào mức độ tự tin của người ghi nhận.
Decision	Chưa có quyết định ghi nhận. Giữ Lot Number ở trạng thái cần xác minh trong handoff.	Verification-required claim	IN_REVIEW và thiếu authority record không đủ để tạo decision.
Authority	Business Owner quyết định quy tắc vận hành; domain owner và Legal Owner xác minh nội dung truy xuất/an toàn thực phẩm nếu được viện dẫn.	Authority boundary	Owner curriculum không có thẩm quyền xác nhận yêu cầu Nova Foods hay diễn giải pháp lý.
Artifact	Ghi traceability tới /01-curriculum/CHAPTER_MANIFEST.md, CHAPTER_MANIFEST; không tạo ID mới.	Artifact	Giữ ID và đường dẫn canonical đã có; tránh tạo nguồn chân lý song song.
Consequence if Wrong	Nếu coi lời Warehouse Supervisor là fact rồi đặt bắt buộc, nhân viên có thể bị chặn xuất hàng khi dữ liệu lô chưa sẵn sàng. Nếu coi đó là quyết định, QA có thể viết test theo quy tắc chưa được authority chọn.	Hậu quả quan sát được	Hành vi chặn giao dịch và test basis sai có thể quan sát trong cấu hình và test case; không cần số liệu bịa đặt.

Senior Lens

Quy tắc ghi chép: mỗi dòng handoff phải có loại thông tin, nguồn, ngày, người hoặc vai trò cung cấp, thẩm quyền quyết định, và trạng thái xác minh. “Stakeholder nói” trả lời câu hỏi ai đã nói gì; “verified fact” trả lời điều gì đã được đối chiếu; “decision” trả lời ai đã chọn phương án nào. Ba câu hỏi khác nhau, nên không được dùng cùng nhãn.

Không dùng nguồn pháp lý trong verified primary-source seed để khẳng định Nova Foods phải cấu hình cụ thể Lot Number. Luật An toàn thực phẩm là nguồn bối cảnh truy xuất; yêu cầu hệ thống suy ra từ luật vẫn cần domain-owner và legal-owner verification. Đây là ranh giới giữa nguồn tham khảo đáng tin và claim đủ điều kiện triển khai.

Quick Reference

Câu kiểm tra	Nhãn đúng
“Artifact ghi IN_REVIEW.”	Verified fact
“Warehouse Supervisor muốn nhập mã lô.”	Stakeholder input
“Tạm lập kế hoạch theo dữ liệu lô tồn tại.”	Project assumption
“Business Owner chọn chặn xuất khi chưa chọn lô.”	Decision, chỉ khi có bản ghi authority
“Quy định pháp lý yêu cầu chặn xuất.”	Verification-required claim, đến khi Legal Owner xác minh

3. V? tr? trong Lifecycle

Core

Implementation Readiness And Handoff Pack nằm cuối chuỗi làm rõ yêu cầu và đầu chuỗi triển khai. Mục đích: biến nội dung IN_REVIEW thành gói đầu vào có thể kiểm tra cho Delivery, Testing, Release và Operations. Gói không tự tạo baseline, approval, quyết định nghiệp vụ, quyết định kiến trúc hay quyền production.

Entry gate là điều kiện phải đạt trước khi pha bắt đầu. Exit gate là điều kiện phải kiểm tra trước khi chuyển pha. Gate ngăn Delivery tự đoán yêu cầu, Testing tự tạo test basis, hoặc Operations nhận thay đổi không biết cách vận hành.

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

flowchart TB
    D[Discovery<br/>Khám phá]
    A[Analysis<br/>Phân tích]
    DE[Delivery<br/>Xây dựng hoặc cấu hình]
    Q{Requirement, rule, data hoặc<br/>acceptance criteria mơ hồ/mâu thuẫn?}
    T[Testing<br/>Kiểm thử]
    R[Release<br/>Phát hành]
    O[Operations<br/>Vận hành]
    F{Input vận hành thuộc loại nào?}

    D -->|Exit Discovery; Entry Analysis: vấn đề đủ rõ; phạm vi Discovery và nguồn input còn traceability| A
    A -->|Entry Delivery: requirement, rule, data, acceptance criteria có traceability; trạng thái IN_REVIEW, khoảng trống và điều kiện xác minh được nêu| DE
    DE --> Q
    Q -->|Có: trả lại làm rõ; không suy đoán| A
    Q -->|Không; Exit Delivery: build hoặc cấu hình có định danh phiên bản; chênh lệch với pack được ghi nhận; Entry Testing: test basis không mâu thuẫn, môi trường hoặc đối tượng kiểm thử sẵn sàng| T
    T -->|Exit Testing; Entry Release: test result, defect, quyết định xử lý, phạm vi release, bằng chứng test và known limitation được ghi nhận; “passed” không phải approval| R
    R -->|Exit Release: nêu nội dung vào/không vào release, escalation và trạng thái thẩm quyền; Entry Operations: hướng dẫn vận hành, hỗ trợ, rollback hoặc xử lý sự cố đã bàn giao| O
    O -->|Sự cố hoặc thay đổi được ghi nhận thành input mới| F
    F -->|Vấn đề, phạm vi hoặc stakeholder input mới| D
    F -->|Requirement, rule, data, acceptance criteria hoặc thay đổi cần làm rõ; không âm thầm sửa business rule| A

Pha	Entry gate chính xác	Hoạt động liên quan pack	Exit gate chính xác
Discovery	Vấn đề nghiệp vụ Nova Foods mô phỏng được mô tả; nguồn input được phân loại stakeholder input, fact, assumption hoặc verification required.	Ghi nhận mục tiêu, phạm vi ban đầu, rủi ro và câu hỏi chưa xác minh.	Vấn đề đủ rõ để phân tích; không biến ý kiến thành business rule.
Analysis	Phạm vi Discovery và nguồn input còn truy vết được.	Làm rõ requirement, business rule, dữ liệu, luồng ngoại lệ, acceptance criteria và dependency.	Mỗi nội dung bàn giao chỉ rõ nguồn, trạng thái IN_REVIEW, khoảng trống và điều kiện cần xác minh.
Delivery	Delivery nhận được requirement và acceptance criteria có traceability; nội dung chưa quyết định được đánh dấu, không suy đoán.	Dùng pack làm build/configuration basis; trả lại câu hỏi khi requirement mơ hồ hoặc mâu thuẫn.	Build hoặc cấu hình có định danh phiên bản; chênh lệch với pack được ghi nhận.
Testing	Test basis gồm requirement, rule, data và acceptance criteria; môi trường hoặc đối tượng kiểm thử sẵn sàng.	Dùng pack để lập test condition và đối chiếu expected result.	Kết quả test, defect và quyết định xử lý được ghi nhận; không gọi “passed” thay cho approval.
Release	Phạm vi release, bằng chứng test và known limitation được ghi nhận.	Rà pack với release note, hướng dẫn hỗ trợ và rủi ro còn mở.	Gói phát hành nêu rõ nội dung vào release, nội dung không vào release, điểm cần escalation và trạng thái thẩm quyền.
Operations	Operations nhận phạm vi thay đổi, hướng dẫn vận hành và kênh xử lý sự cố.	Dùng pack làm ngữ cảnh hỗ trợ; ghi nhận phản hồi thành input mới.	Sự cố hoặc thay đổi mới được phân loại và quay về Discovery hoặc Analysis; không sửa rule im lặng trong vận hành.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp.

Mục	Nội dung
Facts	Requirement mô phỏng đề cập xuất kho thành phẩm theo lô. CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Current Behavior	Warehouse Supervisor mô phỏng nói nhân viên đôi khi chọn lô sau khi tạo phiếu xuất. Đây là stakeholder input, chưa phải fact đã xác minh hay rule đã quyết định.
Underlying Need	Delivery và Testing cần biết hệ thống phải cho phép, cảnh báo hay chặn xuất khi chưa chọn lô. Ba hành vi tạo expected result khác nhau.
Options	Cho phép xuất không chọn lô; cảnh báo nhưng vẫn cho xuất; chặn xác nhận xuất đến khi chọn lô.
Decision Criteria	Bằng chứng quy trình đã xác minh; khả năng dữ liệu lô có sẵn đúng thời điểm; tác động giao hàng; xác minh của Business Owner, domain owner và khi cần Legal Owner.
Decision	Chưa chọn phương án. Pack giữ trạng thái IN_REVIEW và ghi Verification required; không đưa quy tắc chặn vào Delivery như quyết định.
Authority	Business Owner quyết định hành vi nghiệp vụ. Domain owner xác minh khả năng vận hành kho. Legal Owner xác minh claim pháp lý nếu có. BA duy trì traceability, không thay các thẩm quyền này.
Artifact	Tham chiếu canonical: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Nếu Delivery tự chọn chặn, xuất hàng mô phỏng có thể bị dừng bởi rule chưa được chọn. Nếu Testing tự chọn cho phép, test có thể xác nhận hành vi trái quyết định sau này.

Suy luận lifecycle: vì hành vi chưa được quyết định ở Analysis, nó không vượt Entry gate Delivery như requirement bắt buộc. Bằng chứng là ba option còn tồn tại và authority chưa có decision record. Delivery chỉ được xây phần không phụ thuộc quyết định này, hoặc dừng phần phụ thuộc cho đến khi có quyết định được ghi nhận.

Senior Lens

Không đo độ sẵn sàng bằng số lượng tài liệu. Đo bằng khả năng pha sau trả lời không suy đoán bốn câu: xây gì, kiểm thử gì, dữ liệu nào ảnh hưởng, và điểm nào chưa có thẩm quyền quyết định. Một acceptance criterion thiếu nguồn hoặc trạng thái xác minh không đạt Exit gate Analysis, dù câu chữ rõ.

IN_REVIEW là trạng thái kiểm soát, không phải tín hiệu được phép release. Version v0.9.0 và ngày 2026-08-07 chỉ định danh snapshot học liệu. Chúng không xác nhận Nova Foods đã cấu hình ERP, đã tuân thủ pháp lý, đã baseline hoặc đã phê duyệt.

Quick Reference

Gate	Đạt khi	Không đạt khi
Discovery sang Analysis	Input có nguồn và phân loại rõ.	Ý kiến stakeholder bị ghi thành fact hoặc rule.
Analysis sang Delivery	Requirement, acceptance criteria và dependency còn truy vết được.	Delivery phải đoán hành vi hệ thống.
Delivery sang Testing	Đối tượng kiểm thử và chênh lệch build được ghi nhận.	Tester chỉ có mô tả miệng hoặc ảnh màn hình.
Testing sang Release	Kết quả test, defect disposition và phạm vi release được ghi nhận.	“Đã test” không chỉ ra test nào, kết quả nào.
Release sang Operations	Hướng dẫn hỗ trợ và known limitation đi cùng thay đổi.	Operations nhận thay đổi nhưng không biết xử lý lỗi hoặc giới hạn.

Core

Handoff là điểm bàn giao có kiểm soát giữa vai trò trước và vai trò nhận. Bàn giao không phải gửi tệp; phải xác định artifact, owner chịu trách nhiệm, giới hạn quyền quyết định, điều kiện nhận và nơi escalation. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, trạng thái corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07.

Luồng bàn giao	Upstream owner	Artifact bàn giao	Downstream owner	Quyền người nhận	Escalation khi
Nhu cầu sang phân tích	Business Owner	Mục tiêu, vấn đề, ưu tiên nghiệp vụ mô phỏng	Business Analyst	Làm rõ, cấu trúc, truy vết nhu cầu	Mục tiêu mâu thuẫn hoặc ưu tiên đổi
Phân tích sang giải pháp	Business Analyst	Requirement, acceptance criteria, liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi có	Solution Architect, Delivery Lead	Đánh giá khả thi kỹ thuật, ước lượng, đề xuất phương án	Đề xuất đổi ý nghĩa nghiệp vụ, dữ liệu hoặc kiểm soát bảo mật
Thiết kế sang kiểm thử	Delivery Lead, Solution Architect	Build note, cấu hình mô phỏng, API contract nếu có, traceability	QA Lead	Lập test basis, kiểm thử, ghi defect	Không có tiêu chí chấp nhận kiểm thử được hoặc môi trường không tái hiện được
Kiểm thử sang phát hành	QA Lead	Test evidence, defect trạng thái, rủi ro còn lại	Release Manager	Lập kế hoạch phát hành, điều phối rollback	Defect ảnh hưởng dữ liệu, bảo mật, tài chính, truy xuất thực phẩm
Phát hành sang vận hành	Release Manager	Release note, hướng dẫn vận hành, known limitation	Operations Owner	Vận hành, giám sát, ghi incident	Incident vượt runbook hoặc cần đổi quy tắc nghiệp vụ

Applied

Trường	Nội dung case Nova Foods mô phỏng
Facts	BA ghi yêu cầu chặn tạo phiếu xuất kho khi số lượng yêu cầu lớn hơn tồn khả dụng tổng hợp. Requirement tham chiếu CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY, đều IN_REVIEW.
Current Behavior	Delivery Lead nhận mô tả tự do nhưng không có quy tắc xử lý đơn vị tính hoặc thời điểm đọc tồn kho.
Underlying Need	Cần phân biệt BA bàn giao ý nghĩa nghiệp vụ với Architect quyết định cách kiểm tra tồn kho. Bằng chứng: hai quyết định này tác động khác nhau đến quy tắc và kiến trúc.
Options	(1) BA tự chỉ định cơ chế khóa tồn kho. (2) BA ghi điều kiện nghiệp vụ và escalation cho Architect.
Decision Criteria	Không vượt thẩm quyền; giữ traceability; không biến giả định thành quy tắc đã phê duyệt; QA có test basis rõ.
Decision	Chọn phương án 2. BA bàn giao điều kiện nghiệp vụ, dữ liệu cần dùng và acceptance criteria; Architect xác định cơ chế kỹ thuật.
Authority	Business Owner quyết định ý nghĩa ưu tiên nghiệp vụ. Solution Architect quyết định thiết kế. QA Lead đánh giá bằng chứng kiểm thử. BA không tự xác nhận compliance, kế toán, pháp lý hoặc production readiness.
Artifact	Ghi handoff trong /02-handbook/17-implementation-readiness-and-handoff-pack.md; giữ ID canonical nguyên dạng.
Consequence if Wrong	BA tự chọn khóa dữ liệu có thể tạo thiết kế sai, test sai mục tiêu, hoặc che mất xung đột giữa tốc độ xuất hàng và tính nhất quán tồn kho.

Senior Lens

Escalation phải chứa quyết định bị chặn, artifact liên quan, tác động, owner cần quyết và thời điểm cần phản hồi. Không escalation bằng câu “cần xem lại” vì không nêu ai quyết việc gì. Nếu vấn đề liên quan quy tắc pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật, BA chỉ đóng gói bằng chứng và chuyển đúng Legal Owner, Accounting Owner, domain owner, Security hoặc Architect. Các nguồn trong /00-research/00_SOURCE_MAP.md là ranh giới tham chiếu; không thay thế xác minh chuyên môn có thẩm quyền.

Quick Reference

Quy tắc	Áp dụng
Người tạo artifact không mặc nhiên có quyền phê duyệt artifact	Giữ tách biệt trách nhiệm soạn, review và quyết định
Handoff thiếu owner nhận là handoff chưa hoàn tất	Gán một vai trò nhận rõ ràng
Handoff thiếu điều kiện nhận tạo suy diễn	Ghi artifact, trạng thái, phạm vi và điểm mở
Escalation không chuyển quyền quyết định sang BA	BA bảo toàn traceability, owner có thẩm quyền quyết định
IN_REVIEW không phải BASELINED hoặc approved	Không gọi requirement, rule, data definition là đã chốt

Core

Bản đồ lifecycle làm rõ thứ tự chuyển giao của Implementation Readiness And Handoff Pack trong Nova Foods Trading & Manufacturing, mô phỏng giáo dục, dữ liệu tổng hợp. Sơ đồ không tạo gate phê duyệt, không thay thế quyết định của Business Owner, Architect, QA, Legal, Accounting hoặc Operations. Nó chỉ cho biết gói handoff phải được đặt ở đâu để đội nhận không suy diễn thiếu đầu vào.

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

flowchart TB
    D[Discovery<br/>Nhu cầu và vấn đề] --> A[Analysis<br/>Yêu cầu, rule, dữ liệu]
    A --> I[Implementation Readiness<br/>Handoff Pack<br/><i>Không phải approval gate</i>]
    I -->|Phạm vi, rule, dữ liệu,<br/>acceptance criteria| DV[Delivery<br/>Cấu hình, phát triển, tích hợp]
    DV --> T[Testing<br/>Kiểm thử theo test basis]
    T --> R[Release<br/>Chuẩn bị phát hành]
    R --> O[Operations<br/>Vận hành, hỗ trợ, phản hồi]

    I -. traceability và acceptance criteria .-> T
    I -. runbook, ownership, known limits .-> R
    I -. hỗ trợ vận hành và escalation .-> O

    OWN[Business Owner, Architect, QA,<br/>Legal, Accounting, Operations<br/>giữ quyết định thuộc vai trò] -. quyết định không do pack phê duyệt .-> I

    GAP[Đầu vào thiếu hoặc mơ hồ] --> INT[Các đội tự diễn giải khác nhau]
    INT --> MIS[Kết quả lệch nhau<br/>dù từng đội làm đúng phần mình]
    GAP -. rủi ro cần tránh .-> I

Lý do đặt pack sau Analysis: Delivery cần requirement, business rule, dữ liệu và tiêu chí chấp nhận đủ rõ trước khi cấu hình hoặc viết mã. Lý do pack tiếp tục phục vụ Testing, Release và Operations: cùng một quyết định phải được kiểm tra, phát hành và vận hành theo cùng nguồn truy vết; nếu mỗi đội tự diễn giải, kết quả có thể lệch dù từng đội đều làm đúng phần mình.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	ERP cần hỗ trợ quy trình bán hàng phân phối; dữ liệu khách hàng, đơn hàng và hạn mức tín dụng là dữ liệu tổng hợp. Artifact đang IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Analyst chuyển requirement rời rạc cho Delivery; QA nhận mô tả khác; Operations không biết giới hạn xử lý khi đồng bộ thất bại.
Underlying Need	Một handoff pack nối cùng requirement từ Analysis đến Operations, để mỗi đội biết nguồn nào phải dùng và điểm nào phải hỏi lại.
Options	Chỉ dùng ticket Delivery; dùng nhiều tài liệu không liên kết; dùng một pack có liên kết đến artifact canonical.
Decision Criteria	Không nhân bản business rule; giữ traceability; nêu owner nhận thông tin; không biến tài liệu học liệu thành phê duyệt hoặc cấu hình production.
Decision	Dùng Implementation Readiness And Handoff Pack như bản đồ liên kết. Pack tham chiếu, không chép lại, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc và truy vết. Business Owner quyết định nghiệp vụ; Architect quyết định kỹ thuật; QA quyết định bằng chứng kiểm thử; Operations quyết định quy trình vận hành.
Artifact	/02-handbook/17-implementation-readiness-and-handoff-pack.md, Status IN_REVIEW, Version v0.9.0.
Consequence if Wrong	Delivery có thể cấu hình theo diễn giải khác QA; Release thiếu thông tin hỗ trợ; Operations xử lý sai sự cố. Đây là rủi ro mô phỏng, không phải kết luận về hệ thống thực tế.

Senior Lens

Không gọi mũi tên trong sơ đồ là approval. Mũi tên chỉ xác nhận quan hệ sử dụng thông tin: đội sau dùng đầu ra đội trước làm ngữ cảnh hoặc test basis, tức tập thông tin làm nền cho kiểm thử. Bằng chứng cho giới hạn này nằm trong metadata các artifact upstream: tất cả đang IN_REVIEW, chưa có baseline reference và chưa có approval reference.

Không dùng sơ đồ này để suy ra nghĩa vụ pháp lý, thuế, kế toán, bảo vệ dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc. Khi handoff chạm các lĩnh vực đó, giữ nhãn Verification required và chuyển vấn đề cho owner có thẩm quyền. Source map chỉ cho phép dùng nguồn pháp lý chính thức như ranh giới tham chiếu, không cho phép tự diễn giải thành rule Nova Foods.

Quick Reference

Ký hiệu	Nghĩa vận hành trong sơ đồ
Đường liền	Trình tự lifecycle cấp cao.
Đường nét đứt	Nội dung pack hỗ trợ pha nhận, không phải quyết định phê duyệt.
Analysis đến Implementation Readiness	Điểm đặt pack sau khi có đầu vào phân tích đủ để liên kết.
Implementation Readiness đến Operations	Chuỗi truy vết kéo dài đến người vận hành, không dừng ở đội Delivery.
IN_REVIEW	Nội dung đang xem xét; không phải BASELINED, approved, production-ready hoặc compliant.

4. Input c?n thi?t

Core

Input là thông tin BA nhận trước khi lập Implementation Readiness And Handoff Pack. Người mới không cần biết ERP trước: ERP là phần mềm liên kết nghiệp vụ như mua hàng, kho, sản xuất, bán hàng và kế toán trên cùng hệ thống. Handoff pack chỉ đáng tin khi mỗi kết luận trỏ ngược được về bằng chứng nguồn.

Bằng chứng gồm artifact nguồn, dữ liệu mô phỏng, sơ đồ, rule catalog hoặc quyết định đã ghi nhận. Không dùng ghi nhớ cá nhân, trao đổi miệng không có bản ghi, hay suy đoán cấu hình làm bằng chứng. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu chỉ là dữ liệu tổng hợp.

Canonical ID là định danh chuẩn, cố định của artifact hoặc đối tượng truy vết. ID giữ liên kết ổn định khi tiêu đề được dịch, bảng được di chuyển, hoặc tệp được xuất sang định dạng khác. Ví dụ TRACEABILITY_ID_REGISTRY luôn chỉ registry định danh; không thay bằng “registry ID” hoặc tên dịch khác.

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

flowchart TB
    A[Bằng chứng nguồn: artifact, dữ liệu mô phỏng, sơ đồ, rule catalog, quyết định đã ghi nhận] --> C[Handoff pack]
    B[Canonical ID còn nguyên] --> C
    C --> D[Kết luận truy ngược tới bằng chứng nguồn]

    E[Metadata upstream: IN_REVIEW] -. trạng thái .-> C
    F[Chưa có baseline reference] -. ranh giới .-> C
    G[Chưa có approval reference] -. ranh giới .-> C

Sơ đồ mô tả quan hệ thông tin. Không phải luồng phê duyệt. Lý do: metadata upstream đều ghi IN_REVIEW, chưa có baseline reference và chưa có approval reference.

Applied

Thành phần	Nội dung cho Nova Foods mô phỏng
Facts	Pack cần nối yêu cầu, quy tắc, dữ liệu và truy vết để Delivery, QA, Operations không tự đoán cùng một nội dung theo nhiều cách.
Current Behavior	Corpus có các artifact kế hoạch được kiểm soát, cùng Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.
Underlying Need	Người nhận pack phải biết thông tin nào là nguồn, vị trí nguồn ở đâu, và ID nào phải giữ nguyên khi tham chiếu chéo.
Options	(1) Chép nội dung sang pack không dẫn nguồn. (2) Chỉ nêu tên tài liệu. (3) Nêu đường dẫn kiểm soát, Artifact ID và giới hạn sử dụng.
Decision Criteria	Truy ngược được; không tạo ID mới; không biến kế hoạch thành rule vận hành; không diễn giải pháp lý, kế toán hay tuân thủ ngoài thẩm quyền.
Decision	Dùng phương án (3). Pack chỉ lập chỉ mục input; artifact nguồn vẫn là nguồn chân lý.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết. Business Owner, Architect, QA, Legal, Accounting, Security và Compliance giữ thẩm quyền nội dung thuộc lĩnh vực của họ.
Artifact	/02-handbook/17-implementation-readiness-and-handoff-pack.md, Status IN_REVIEW, Version v0.9.0.
Consequence if Wrong	Delivery có thể cấu hình từ bản sao lỗi thời; QA mất test basis; Operations nhận hướng dẫn không truy ngược được. Đây là rủi ro mô phỏng.

Senior Lens

Inventory đầu vào không phải danh sách tệp dài. Nó trả lời ba câu hỏi: cần hiểu gì trước, bằng chứng nằm ở đâu, và liên kết nào không được đổi. Nếu không trả lời được, pack chưa có nền truy vết.

Kiến thức hoặc bằng chứng cần có	Canonical ID hoặc đường dẫn giữ nguyên	Vai trò trong handoff	Ranh giới sử dụng
Cấu trúc curriculum và dependency chapter	01_CURRICULUM_ARCHITECTURE — /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Xác định vị trí học liệu và chuỗi từ requirement đến testing, delivery.	Kế hoạch curriculum; không phải requirement ERP.
Manifest chapter	CHAPTER_MANIFEST — /01-curriculum/CHAPTER_MANIFEST.md	Giữ tên chapter, filename và phạm vi chapter ổn định.	Không tạo baseline hay approval.
Registry định danh	TRACEABILITY_ID_REGISTRY — /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Tra cứu và bảo toàn canonical ID khi tạo liên kết chéo.	Không tự cấp ID ngoài registry.
Catalog quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES — /01-curriculum/CANONICAL_BUSINESS_RULES.md	Nối rule với requirement, test basis và handoff context.	Nội dung đang IN_REVIEW; không suy ra rule vận hành thực.
Từ điển dữ liệu logic	CANONICAL_DATA_DICTIONARY — /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Giải thích dữ liệu, trường dữ liệu và nghĩa logic trước khi Delivery cấu hình hoặc QA kiểm thử.	Không phải đặc tả database hay cấu hình production.
Source map	00_SOURCE_MAP — /00-research/00_SOURCE_MAP.md	Cho biết nguồn chuẩn, URL chính thức và ranh giới dùng nguồn.	Không tự bịa điều khoản, trang, nghĩa vụ pháp lý hoặc trích dẫn.
Template manifest	TEMPLATE_MANIFEST — /01-curriculum/TEMPLATE_MANIFEST.md	Biết template nào được dự kiến dùng trong corpus.	Template dự kiến không chứng minh nội dung đã hoàn tất hay được phê duyệt.

Verification required: Nội dung về thuế, kế toán, dữ liệu cá nhân, hóa đơn, an toàn thực phẩm hoặc truy xuất nguồn gốc phải được Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner xác minh theo thẩm quyền. Bằng chứng là source map phân loại các nguồn này là nguồn pháp lý hoặc chuyên ngành có ranh giới sử dụng; từ đó không thể suy ra Nova Foods mô phỏng đã tuân thủ.

Quick Reference

Quy tắc	Áp dụng
Giữ nguyên ID	Dùng đúng TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; không dịch hoặc rút gọn ID.
Giữ nguyên đường dẫn	Dẫn /01-curriculum/... hoặc /00-research/... đúng như artifact kiểm soát.
Phân biệt nguồn và bản sao	Artifact nguồn là nơi quản trị nội dung; handoff pack chỉ tham chiếu.
Không suy đoán	Thiếu bằng chứng không được thay bằng cấu hình ERP, rule Nova Foods hoặc kết luận tuân thủ tự tạo.
Giữ trạng thái	IN_REVIEW không phải BASELINED, approved, production-ready hoặc compliant.

Kiểm tra chất lượng, phân loại, độ mới, ownership và điều kiện dừng

Input là thông tin BA dùng để quyết định handoff có đủ căn cứ hay không. Không phải mọi tệp đều đáng tin như nhau. BA phải phân loại nguồn trước, kiểm tra chất lượng sau, rồi mới dùng nội dung để liên kết requirement, dữ liệu, quy tắc hay quyết định. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị dưới đây là dữ liệu tổng hợp, không phải bằng chứng ERP thực tế.

Phân loại nguồn	Ý nghĩa	Được dùng cho	Không được suy diễn
PRIMARY_OFFICIAL	Nguồn do cơ quan, tổ chức chuẩn hoặc chủ sở hữu chính thức phát hành	Bối cảnh chuẩn, pháp lý, thuật ngữ	Điều khoản chi tiết khi chỉ có trang giới thiệu hoặc chưa kiểm tra văn bản được cấp quyền
CANONICAL_INTERNAL	Artifact kiểm soát trong corpus, có ID và đường dẫn canonical	Traceability, metadata, phạm vi học liệu	Approval, baseline, quyết định vận hành
PROJECT_ASSUMPTION	Giả định học liệu được gắn nhãn rõ	Minh họa lựa chọn BA	Nghĩa vụ pháp lý, cấu hình ERP, quy tắc vận hành
VERIFICATION_REQUIRED	Thông tin chưa đủ bằng chứng hoặc cần owner chuyên môn xác nhận	Danh sách vấn đề, điều kiện dừng, kế hoạch xác minh	Requirement sẵn sàng build hoặc test
DERIVED_ANALYSIS	Kết luận BA nối từ nhiều nguồn đã ghi rõ	So sánh phương án, phát hiện thiếu hụt	Thay thế nguồn gốc hoặc thẩm quyền owner

Kiểm tra chất lượng gồm năm câu hỏi. Identity: tệp, ID, phiên bản và đường dẫn có đúng canonical không. Completeness: thông tin có đủ trường cần dùng không. Consistency: nội dung có mâu thuẫn với nguồn canonical khác không. Freshness: ngày cập nhật còn trong ngưỡng áp dụng không. Authority: người hoặc tổ chức phát hành có quyền xác nhận loại nội dung đó không. Một input chỉ “dùng được có điều kiện” khi năm câu hỏi có kết quả ghi nhận; trạng thái IN_REVIEW không biến input thành APPROVED hay BASELINED.

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

flowchart TB
    A[Nhận input] --> B{Phân loại nguồn rõ?}
    B -- Không --> S0[STOP: xác định và gắn nhãn phân loại nguồn]
    B -- Có --> Q[Ghi đủ 5 kết quả:<br/>Identity, Completeness, Consistency,<br/>Freshness, Authority]

    Q --> D{Định danh canonical đúng?}
    D -- Không --> OI[Principal IT Business Analyst /<br/>Technical Curriculum Author]
    OI --> S1[STOP: sửa định danh hoặc tìm nguồn canonical]

    D -- Có --> E{Đủ, nhất quán và còn mới?}
    E -- Không --> V[Gắn VERIFICATION_REQUIRED;<br/>ghi lỗi Completeness, Consistency hoặc Freshness]
    E -- Có --> F{Authority phù hợp nội dung?}
    F -- Không --> VA[Gắn VERIFICATION_REQUIRED;<br/>ghi lỗi Authority và nội dung cần xác minh]
    F -- Có --> K{Kiểm tra theo loại đạt?<br/>Metadata corpus khớp snapshot;<br/>pháp lý có URL chính thức và Legal Owner diễn giải;<br/>business rule truy CANONICAL_BUSINESS_RULES<br/>hoặc gắn PROJECT_ASSUMPTION;<br/>dữ liệu truy CANONICAL_DATA_DICTIONARY;<br/>Traceability ID có trong registry;<br/>API có OpenAPI hoặc đặc tả canonical;<br/>test basis truy vết được}

    K -- Không --> VK[Gắn VERIFICATION_REQUIRED;<br/>ghi kiểm tra theo loại bị lỗi]
    K -- Có --> T{Requirement, acceptance criteria, rule,<br/>test data, mapping/interface và integration contract<br/>truy ngược được evidence?}
    T -- Không --> S2[STOP: bổ sung evidence và traceability]

    T -- Có --> R{Artifact IN_REVIEW bị dùng<br/>như baseline hoặc approval?}
    R -- Có --> S3[STOP: IN_REVIEW không phải<br/>baseline hoặc approval]

    R -- Không --> P{Mục đích sử dụng phù hợp<br/>phân loại nguồn?}
    P -- Không --> S4[STOP: không vượt giới hạn<br/>của phân loại nguồn]
    P -- Có --> U[Dùng có điều kiện và có traceability;<br/>CANONICAL_INTERNAL không thay approval hoặc baseline;<br/>PROJECT_ASSUMPTION không thay fact vận hành]

    V --> X{Nội dung nào cần owner xác minh?}
    VA --> X
    VK --> X

    X -- Metadata corpus --> OM[Principal IT Business Analyst /<br/>Technical Curriculum Author]
    OM --> SM[STOP — PLAN REWORK REQUIRED]

    X -- Nguồn pháp lý --> OL[Legal Owner]
    X -- Quy tắc nghiệp vụ --> OB[Business Owner]
    X -- Dữ liệu logic --> OD[Data Owner và Architect]
    X -- Traceability ID --> OT[Principal IT Business Analyst /<br/>Technical Curriculum Author]
    X -- API và tích hợp --> OA[Technical Architect]
    X -- Test basis --> OQ[QA Lead]
    X -- Accounting --> OAC[Owner thẩm quyền về accounting]
    X -- Security --> OS[Owner thẩm quyền về security]
    X -- Food-safety --> OF[Owner thẩm quyền về food-safety]
    X -- Quyết định kiến trúc --> OAR[Technical Architect]
    X -- PROJECT_ASSUMPTION --> OP[Owner thẩm quyền theo nội dung]
    X -- DERIVED_ANALYSIS --> ODA[Owner thẩm quyền của nguồn gốc]
    X -- Nội dung khác --> SX[STOP: xác định owner thẩm quyền]

    OT --> ST[STOP: đăng ký hoặc sửa Traceability ID]

    OL --> N[Owner xác minh;<br/>không tự nâng cấp trạng thái]
    OB --> N
    OD --> N
    OA --> N
    OQ --> N
    OP --> N
    ODA --> N

    OAC --> S5[STOP: chờ owner xác minh]
    OS --> S5
    OF --> S5
    OAR --> S5

    N --> H{Vấn đề ảnh hưởng requirement,<br/>build/test basis, mapping/interface,<br/>tích hợp hoặc quyết định handoff?}
    H -- Có --> S5
    H -- Không --> G[Giữ VERIFICATION_REQUIRED;<br/>ghi giới hạn sử dụng, vấn đề, source ID,<br/>owner, ảnh hưởng và trạng thái]

Kiểm tra	Quy tắc Nova Foods mô phỏng	Freshness tối đa	Owner chịu trách nhiệm	Kết quả khi lỗi
Định danh	Giữ nguyên Artifact ID, filename, status, version	Không áp dụng	Principal IT Business Analyst / Technical Curriculum Author	Dừng dùng bản sao hoặc ID biến thể
Metadata corpus	Phải khớp IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND	0 ngày so với snapshot corpus	Principal IT Business Analyst / Technical Curriculum Author	STOP — PLAN REWORK REQUIRED nếu mâu thuẫn
Nguồn pháp lý	Chỉ dùng URL chính thức; diễn giải nghĩa vụ cần Legal Owner	Theo ngày truy cập 2026-08-07; kiểm tra sửa đổi trước production	Legal Owner	Gắn VERIFICATION_REQUIRED; dừng nếu tạo requirement bắt buộc
Quy tắc nghiệp vụ	Phải truy về CANONICAL_BUSINESS_RULES hoặc được gắn PROJECT_ASSUMPTION	Theo version artifact	Business Owner	Không đưa vào build/test basis
Dữ liệu logic	Phải truy về CANONICAL_DATA_DICTIONARY; không suy ra trường dữ liệu từ ví dụ	Theo version artifact	Data Owner và Architect	Dừng mapping/interface liên quan
Traceability ID	ID phải có trong TRACEABILITY_ID_REGISTRY	Theo version artifact	Principal IT Business Analyst / Technical Curriculum Author	Dừng liên kết nếu ID chưa đăng ký
API và tích hợp	HTTP contract cần OpenAPI hoặc đặc tả canonical; URL, schema, lỗi phải có owner kỹ thuật	Theo version contract	Technical Architect	Dừng handoff tích hợp
Test basis	Requirement, acceptance criteria, rule và dữ liệu test phải truy vết được	Theo version nguồn gốc	QA Lead	Không tuyên bố test-ready

Freshness không chỉ là ngày cũ hay mới. Input còn mới khi chưa có thay đổi đã biết làm thay đổi ý nghĩa. Ví dụ, https://vanban.chinhphu.vn/?docid=201365&pageid=27160 là nguồn chính thức cho Nghị định 123/2020/NĐ-CP, nhưng seed đã nêu phải kiểm tra sửa đổi sau này trước production. Vì vậy, BA chỉ ghi được “nguồn tham khảo pháp lý, cần Legal Owner xác minh hiệu lực và diễn giải”; không được biến thành rule hóa đơn của Nova Foods.

Dừng handoff khi có một trong các điều kiện: ID không tồn tại hoặc mâu thuẫn; nguồn VERIFICATION_REQUIRED bị dùng làm fact; legal, accounting, security, food-safety hoặc kiến trúc bị quyết định bởi BA không có owner thẩm quyền; input quá freshness threshold; requirement không truy ngược được evidence; hoặc artifact mang IN_REVIEW bị gọi là baseline hay approval. Dừng là kiểm soát chất lượng, không phải thất bại. BA ghi vấn đề, source ID, owner cần xác minh, ảnh hưởng và trạng thái; không tự điền kết luận để làm đủ hồ sơ.

Core — Bảng đầu vào Nova Foods mô phỏng

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị dưới đây là dữ liệu tổng hợp. “Input” là thông tin hoặc artifact có sẵn để BA dùng khi chuẩn bị gói bàn giao. Một dòng chỉ dùng được khi giữ nguyên ID, đường dẫn, phân loại nguồn và trạng thái xác minh.

Input cần có	Giá trị Nova Foods mô phỏng	ID/đường dẫn canonical	Phân loại nguồn	Owner ghi nhận	Độ mới tại 2026-08-07	Trạng thái xác minh	Điểm chưa giải quyết
Bối cảnh case	Việt Nam, vi-VN, Asia/Ho_Chi_Minh, VND	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có bằng chứng metadata	Không chứng minh cấu hình ERP thật
Danh mục chapter	Chapter 17, 12 section, section 4 là 04-inputs	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có bằng chứng metadata	Không có baseline reference
Danh mục template	Template chỉ là kế hoạch, không phải artifact đã dùng production	/01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có bằng chứng metadata	CẦN XÁC MINH template nào được tạo ở pha sau
Registry định danh	ID phải giữ nguyên khi liên kết traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có bằng chứng metadata	CẦN XÁC MINH ID nghiệp vụ mới trước khi đăng ký
Catalog quy tắc	Quy tắc Nova Foods chưa là quy định vận hành thật	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có bằng chứng metadata	Không được suy diễn rule chưa có nguồn và thẩm quyền
Từ điển dữ liệu	Định nghĩa dữ liệu logic canonical của corpus	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có bằng chứng metadata	CẦN XÁC MINH mapping sang schema ERP thực
Bản đồ nguồn	Danh sách nguồn chuẩn, ranh giới sử dụng và QA nguồn	/00-research/00_SOURCE_MAP.md	Controlled research artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có bằng chứng metadata	Không thay thế văn bản có bản quyền hoặc tư vấn chuyên môn
Chuẩn requirement	ISO/IEC/IEEE 29148:2018, Edition 2	https://www.iso.org/standard/72089.html	External primary source	ISO/IEC/IEEE	Trạng thái nguồn kiểm tra 2026-08-07	Chỉ dùng abstract và bibliographic status	CẦN XÁC MINH điều khoản chính xác qua licensed text
Bảo vệ dữ liệu cá nhân	Luật 91/2025/QH15, hiệu lực 2026-01-01	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	External primary legal source	Quốc hội Việt Nam	Truy cập 2026-08-07	URL chính thức được seed xác minh	CẦN XÁC MINH yêu cầu hệ thống với Legal Owner
Hóa đơn, chứng từ	Nghị định 123/2020/NĐ-CP, hiệu lực 2022-07-01	https://vanban.chinhphu.vn/?docid=201365&pageid=27160	External primary legal source	Chính phủ Việt Nam	Truy cập 2026-08-07	URL chính thức được seed xác minh	CẦN XÁC MINH sửa đổi sau nguồn seed với Accounting Owner

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

flowchart TB
    A["Input có nguồn được phân loại"]
    A --> B["BA giữ nguyên ID, đường dẫn, phân loại nguồn, trạng thái xác minh"]
    B --> C{"Giữ nguyên đủ 4 thuộc tính bắt buộc?"}
    C -->|Không| D["Không dùng dòng làm input gói handoff"]
    C -->|Có| E{"Trạng thái xác minh và điểm chưa giải quyết cho phép dùng?"}
    E -->|Có bằng chứng; trong ranh giới nguồn| F["Dùng dòng làm input gói handoff"]
    E -->|CẦN XÁC MINH hoặc thiếu bằng chứng| G["Gắn nhãn verification required"]
    G --> H["Không dùng để suy diễn hoặc quyết định"]
    H --> I["BA xác định điểm chưa giải quyết và source owner ghi nhận"]
    I --> J["Bổ sung hoặc xác minh bằng chứng với owner phù hợp"]
    J --> K{"Đã xác minh và còn trong ranh giới nguồn?"}
    K -->|Có| B
    K -->|Không| L["Giữ trạng thái không đủ điều kiện dùng"]
    L --> D

Applied

Thành phần	Nội dung
Facts	Gói handoff Nova Foods mô phỏng cần tham chiếu quy tắc dữ liệu và nghĩa vụ bảo vệ dữ liệu.
Current Behavior	Corpus chỉ có artifact IN_REVIEW, không có baseline hoặc approval reference.
Underlying Need	Người nhận cần phân biệt thông tin có bằng chứng quản trị với điểm còn phải xác minh.
Options	Dùng như quyết định cuối; hoặc dùng làm input có nhãn trạng thái và ranh giới nguồn.
Decision Criteria	Không tạo approval ngầm định; giữ traceability; không biến nguồn pháp lý thành yêu cầu hệ thống chưa được Legal Owner xác minh.
Decision	Chỉ dùng dòng có CẦN XÁC MINH làm điểm mở để xác minh, không dùng làm rule triển khai.
Authority	Legal Owner xác minh pháp lý; Accounting Owner xác minh kế toán và hóa đơn; Principal IT Business Analyst / Technical Curriculum Author duy trì traceability.
Artifact	/02-handbook/17-implementation-readiness-and-handoff-pack.md
Consequence if Wrong	Gói handoff có thể mô tả giả định như nghĩa vụ bắt buộc, làm sai phạm vi, owner và quyết định triển khai.

Senior Lens

Bảng đủ không phải bảng có nhiều dòng. Bảng đủ khi mỗi input cần cho phạm vi đang xét có nguồn, owner, độ mới, trạng thái và điểm chưa giải quyết. Bằng chứng là IN_REVIEW không đồng nghĩa BASELINED; vì vậy không được đổi nhãn CẦN XÁC MINH thành kết luận.

Quick Reference

• Giữ nguyên: 00_SOURCE_MAP, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
• Dùng dữ liệu Nova Foods tổng hợp, không dữ liệu doanh nghiệp thật.
• Dừng dùng input làm quyết định khi nguồn không canonical, ID không đăng ký, hoặc owner chuyên môn chưa xác minh.

5. Step-by-step BA Activities

Core

BA chuẩn bị, kiểm tra, gom bằng chứng, điều phối review, rồi bàn giao có kiểm soát. Mục tiêu không phải gửi nhiều tệp. Mục tiêu là người nhận biết tệp nào còn IN_REVIEW, nguồn nào canonical, ai quyết định điểm mở, và không dùng giả định mô phỏng làm quyết định triển khai.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Mọi dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

Bước	Actor	Action trên object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi handoff	Principal IT Business Analyst / Technical Curriculum Author	Đọc phạm vi /02-handbook/17-implementation-readiness-and-handoff-pack.md; lập danh sách artifact đầu vào.	Danh sách input gồm 00_SOURCE_MAP, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.	Chỉ nhận artifact có đường dẫn và ID canonical.	Mỗi dòng có ID, path, version v0.9.0, status IN_REVIEW.	ID, path hoặc version mâu thuẫn: escalation Principal IT Business Analyst / Technical Curriculum Author để giữ traceability; không tự đổi ID.
2. Phân loại trạng thái bằng chứng	BA	Gắn trạng thái cho từng input: usable for review, CẦN XÁC MINH, hoặc không dùng.	Register bằng chứng có source, owner, trạng thái, ngày 2026-08-07.	IN_REVIEW không phải BASELINED, không phải approval.	Không có dòng nào diễn giải review như phê duyệt.	Điểm bị hiểu thành approval: escalation Owner quản trị artifact.
3. Đối chiếu traceability	BA	So sánh ID quy tắc, dữ liệu, nguồn với registry và catalog canonical.	Ma trận truy vết input-to-handoff.	Một claim chỉ được đưa vào handoff khi có artifact nguồn xác định.	Không có claim mồ côi; không đổi tên ID canonical.	Nguồn mâu thuẫn hoặc ID chưa đăng ký: escalation Principal IT Business Analyst / Technical Curriculum Author; dừng claim đó.
4. Phát hiện quyết định cần thẩm quyền	BA	Tách nội dung thành quản trị tài liệu, nghiệp vụ, kiến trúc, QA, pháp lý, kế toán, bảo mật.	Issue log nêu câu hỏi, bằng chứng, owner cần xác minh.	BA không thay Business Owner, Architect, QA, Legal Owner, Accounting Owner hoặc Security xác nhận chuyên môn.	Mỗi điểm chuyên môn có đúng owner và nhãn CẦN XÁC MINH khi chưa có kết luận.	Quy tắc pháp lý: Legal Owner; kế toán/hóa đơn: Accounting Owner; kiến trúc/tích hợp: Architect; test: QA; bảo mật: Security; nghiệp vụ: Business Owner.
5. Soạn gói handoff	BA	Gom scope, input, traceability, issue log, trạng thái và người nhận vào gói bàn giao.	Bản handoff trong /02-handbook/17-implementation-readiness-and-handoff-pack.md.	Gói chỉ mô tả bằng chứng có sẵn; không tạo requirement ERP mới.	Có nhãn mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07.	Thiếu input hoặc evidence: trả về bước 1 hoặc 3; không bàn giao như hoàn tất.
6. Review kiểm soát	Reviewer theo vai trò	Kiểm tra gói theo phạm vi và thẩm quyền.	Review record: finding, artifact ID, owner, trạng thái xử lý.	Reviewer chỉ xác nhận phần thuộc vai trò mình; review không tự tạo approval.	Không còn lỗi ID, đường dẫn, trạng thái, source boundary hoặc nhãn xác minh.	Finding thuộc vai trò khác: chuyển đúng owner; BA giữ liên kết issue log.
7. Bàn giao có kiểm soát	BA	Chuyển gói và register bằng chứng cho người nhận đã xác định; ghi nhận thời điểm bàn giao.	Handoff record theo Asia/Ho_Chi_Minh, danh sách người nhận, artifact và điểm mở.	Bàn giao nghĩa là chuyển trách nhiệm xử lý tiếp, không nghĩa là baseline hoặc production-ready.	Người nhận nhận đủ artifact path, trạng thái và escalation owner.	Người nhận thiếu quyền hoặc phát hiện mâu thuẫn: trả gói về BA để điều phối, không tự sửa nguồn canonical.

Facts: Corpus Nova Foods chỉ có artifact IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; chưa có baseline reference hoặc approval reference.

Current Behavior: Input quản trị, quy tắc và dữ liệu nằm ở các artifact canonical riêng. Người nhận có thể nhầm tài liệu review với quyết định triển khai nếu BA không gắn trạng thái.

Underlying Need: Handoff cần giữ được chuỗi bằng chứng từ nguồn đến điểm cần xác minh, để reviewer biết nội dung nào dùng được cho review và nội dung nào phải chuyển owner chuyên môn.

Options: Bàn giao một bản tóm tắt không traceability; hoặc bàn giao gói có input register, ma trận truy vết, issue log và escalation route.

Decision Criteria: Không tạo approval ngầm định; không đổi ID canonical; không diễn giải luật, kế toán, bảo mật hoặc kiến trúc vượt thẩm quyền; người nhận truy lại được nguồn.

Decision: Dùng gói handoff có kiểm soát. Mọi điểm chưa có xác minh chuyên môn giữ nhãn CẦN XÁC MINH.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Business Owner, Architect, QA, Legal Owner, Accounting Owner và Security quyết định phần thuộc thẩm quyền tương ứng.

Artifact: /02-handbook/17-implementation-readiness-and-handoff-pack.md

Consequence if Wrong: Người nhận có thể dùng giả định mô phỏng như rule ERP, bỏ sót owner quyết định, hoặc hiểu IN_REVIEW là đã được phê duyệt.

Senior Lens

Handoff tốt giảm suy diễn. Bằng chứng là mỗi điểm mở có source, lý do chưa kết luận, owner và đường escalation. Handoff xấu thường có tệp đầy đủ nhưng không nói rõ tệp nào là canonical, tệp nào chỉ là input review.

Quick Reference

• Bắt đầu bằng scope và artifact canonical.
• Giữ IN_REVIEW khác BASELINED và approval.
• Không tự đóng điểm pháp lý, kế toán, bảo mật, QA, kiến trúc hoặc nghiệp vụ.
• Bàn giao record phải nêu người nhận, thời điểm, artifact, trạng thái và điểm mở.

Core

Mỗi bước BA phải tạo bằng chứng kiểm tra được. Điều này ngăn handoff dựa vào trí nhớ hoặc suy đoán. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu là tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	Business Analyst	Đối chiếu mục tiêu handoff với artifact nguồn	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Danh sách artifact đầu vào, phiên bản, trạng thái, đường dẫn canonical	Chỉ dùng artifact có ID, đường dẫn, IN_REVIEW, v0.9.0 nhất quán	Không có tên tệp biến thể, ID tự đặt, hoặc diễn giải IN_REVIEW là approved	Principal IT Business Analyst / Technical Curriculum Author khi metadata mâu thuẫn
2. Kiểm kê nội dung	Business Analyst	Lập ma trận nội dung cần bàn giao và nguồn chứng minh	Requirement, business rule, data, interface, test basis mô phỏng	Ma trận truy vết nguồn-đầu ra	Mỗi mục phải có nguồn canonical hoặc nhãn Verification required	Không có requirement, rule, field, API hay nghĩa vụ pháp lý vô nguồn	Business Owner, Architect, Legal Owner, Accounting Owner, Security Owner theo loại khoảng trống
3. Kiểm tra nhất quán	Business Analyst và QA reviewer	So sánh thuật ngữ, ID, trạng thái, phạm vi giữa các artifact	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, registry ID	Log sai khác có nguồn, tác động, người xử lý	Sai khác ID, định nghĩa, phạm vi, hoặc source classification phải chặn handoff	Không còn sai khác chưa phân loại; mọi kết luận có bằng chứng dẫn tới nguồn	Principal IT Business Analyst / Technical Curriculum Author; sau đó owner chuyên môn phù hợp
4. Xác định quyết định mở	Business Analyst	Tách fact, assumption, decision cần thẩm quyền, và verification required	Các điểm chưa đủ bằng chứng	Decision log ghi owner, bằng chứng thiếu, tác động nếu sai	BA không tự chốt pháp lý, kế toán, bảo mật, kiến trúc, vận hành	Không gắn nhãn “đã phê duyệt”, “đã baseline”, “tuân thủ”, hoặc production-ready	Legal Owner, Accounting Owner, Security Owner, Architect, Business Owner
5. Đóng gói handoff	Business Analyst	Tạo gói bàn giao với liên kết artifact, giới hạn sử dụng và điểm mở	Danh mục artifact đã kiểm tra	Handoff index, traceability matrix, decision log, issue log	Gói chỉ tham chiếu đường dẫn canonical; không sao chép thành nguồn chân lý mới	Người nhận mở được từng artifact và xác định được trạng thái, version, owner, boundary	Principal IT Business Analyst / Technical Curriculum Author khi liên kết hỏng hoặc thiếu artifact
6. Review có kiểm soát	Consumer owner và Business Analyst	Review tính dùng được, tính truy vết, giới hạn thẩm quyền	Gói handoff và bằng chứng	Review record: nhận xét, phân loại, owner xử lý, ngày theo Asia/Ho_Chi_Minh	Nhận xét làm thay đổi rule, data, API, security, legal, accounting phải quay về owner có thẩm quyền	Không đóng review khi nhận xét trọng yếu thiếu owner hoặc evidence	Owner chuyên môn tương ứng; QA reviewer cho test basis
7. Bàn giao kiểm soát	Business Analyst	Ghi nhận người nhận, phạm vi nhận, trạng thái và giới hạn	Gói đã review	Biên bản handoff nội bộ ghi IN_REVIEW	Bàn giao chỉ xác nhận chuyển giao thông tin, không xác nhận approval hay baseline	Biên bản nêu rõ dữ liệu mô phỏng, không dùng production, các điểm Verification required	Principal IT Business Analyst / Technical Curriculum Author nếu người nhận yêu cầu biến handoff thành approval

Applied

Quy tắc thực thi: actor làm action trên object; evidence chứng minh action đã xảy ra; decision rule quyết định đi tiếp hay dừng; quality gate kiểm tra evidence đủ; escalation route chuyển quyết định sang đúng thẩm quyền. Nếu evidence không chỉ được nguồn canonical, người nhận không thể kiểm tra lại. Vì vậy handoff phải dừng thay vì điền suy đoán.

Senior Lens

“Controlled handoff” là bàn giao có kiểm soát: người nhận biết chính xác nhận gì, nguồn nào chi phối, nội dung nào chưa xác minh, ai quyết phần còn mở. Nó không phải approval. IN_REVIEW nghĩa nội dung còn có thể đổi; không được đổi trạng thái này thành cam kết triển khai.

Quick Reference

• Thiếu source: gắn Verification required, không tự suy diễn.
• Mâu thuẫn ID hoặc định nghĩa: chặn quality gate.
• Quyết định pháp lý, kế toán, bảo mật, kiến trúc: escalation ngay.
• Handoff record: ghi chuyển giao thông tin, không ghi user approval, baseline, hay production readiness.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Bảng dưới biến gói bàn giao thành chuỗi kiểm tra được: mỗi hành động tạo bằng chứng, mỗi quyết định có tiêu chí, mỗi lệch nguồn được chuyển đúng thẩm quyền. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND giữ nguyên từ artifact nguồn.

Chặng thực thi	Facts và Current Behavior	Underlying Need	Options và Decision Criteria	Decision, Authority, Artifact	Consequence if Wrong
Gom đầu vào	Facts: /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md đều IN_REVIEW. Current Behavior: chưa có baseline hay approval reference.	Nhóm nhận bàn giao cần biết nội dung nào là kế hoạch, nội dung nào chưa đủ thẩm quyền dùng để cấu hình ERP.	Option 1: ghi mọi nội dung là sẵn sàng. Option 2: giữ nhãn trạng thái nguồn. Tiêu chí: không suy diễn approval từ metadata.	Decision: dùng Option 2. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì traceability; Business Owner, Architect, QA, Legal, Accounting, Security quyết nội dung thuộc thẩm quyền. Artifact: gói tham chiếu nguồn.	Team cấu hình nhầm nội dung review thành quyết định production.
Đối chiếu liên kết	Facts: registry là nguồn kiểm soát ID; rule catalog là nguồn quy tắc; data dictionary là nguồn dữ liệu logic. Current Behavior: các artifact có ranh giới riêng.	Handoff cần tránh một ID, quy tắc, hoặc trường dữ liệu bị sao chép thành nhiều nguồn chân lý.	Option 1: dùng bản trích. Option 2: liên kết artifact canonical. Tiêu chí: giữ đúng ID, filename, trạng thái, version.	Decision: dùng Option 2. Authority: BA ghi nhận sai lệch; owner artifact sửa metadata; chuyên gia chức năng xác minh nội dung. Artifact: bảng traceability bàn giao.	Developer dùng ID không canonical hoặc áp dụng rule sai nguồn.
Xử lý điểm cần xác minh	Facts: nguồn pháp lý chỉ cho phép dùng trong ranh giới đã xác minh; diễn giải thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm cần chủ sở hữu chuyên môn. Current Behavior: corpus không xác nhận compliance Nova Foods.	Người nhận cần phân biệt project assumption với yêu cầu đã được chủ thể có thẩm quyền xác minh.	Option 1: BA tự kết luận. Option 2: gắn Verification required và escalation. Tiêu chí: đề xuất chạm pháp lý, kế toán, bảo mật, kiến trúc, vận hành thực tế.	Decision: dùng Option 2. Authority: Legal Owner, Accounting Owner, Security, Architect, Business Owner theo phạm vi. Artifact: danh sách điểm mở có nguồn và route escalation.	ERP triển khai logic trái yêu cầu pháp lý hoặc kiểm soát nội bộ.
Chuyển gói review	Facts: IN_REVIEW không phải APPROVED hoặc BASELINED. Current Behavior: chưa có approval reference.	Bên nhận cần nhận đúng phạm vi kiểm tra, không nhận lệnh triển khai.	Option 1: gọi là handoff production. Option 2: gọi controlled review handoff. Tiêu chí: có hay không baseline và approval reference được ghi nhận.	Decision: dùng Option 2. Authority: Owner điều phối gói; người có thẩm quyền ghi quyết định riêng. Artifact: review handoff package.	Handoff bị hiểu là cấp phép cấu hình, test, hoặc go-live.

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

flowchart TB
    A[Thu thập artifact nguồn IN_REVIEW] --> B[Đối chiếu ID, filename, version, trạng thái]
    B --> C{Mâu thuẫn nguồn hoặc thiếu truy vết?}
    C -- Có --> D[BA lập gói vấn đề, chuyển Business Owner, Architect, QA, Legal, Accounting hoặc Security theo phạm vi]
    D --> E[Giữ nhãn Verification required hoặc IN_REVIEW]
    C -- Không --> F{Có baseline và approval reference?}
    E --> G[Handoff kiểm soát cho review, không dùng production]
    F -- Không --> G
    F -- Có --> H[Xử lý theo quyết định và approval reference đã ghi nhận]
    H --> I[Không tự động cho phép cấu hình, kiểm thử hoặc go-live]

Suy luận: artifact nguồn cùng ghi IN_REVIEW và không có baseline hoặc approval reference; vì vậy gói Nova Foods chỉ được chuyển để review có kiểm soát. Đây không phải bằng chứng Nova Foods đã chấp thuận, tuân thủ, cấu hình, kiểm thử hoặc vận hành ERP.

6. Output thu ???c

Core

Output là artifact được tạo mới hoặc cập nhật sau hoạt động BA, để bên sau hiểu cùng một phạm vi mà không suy đoán. Với Nova Foods Trading & Manufacturing là case mô phỏng, chỉ dùng dữ liệu tổng hợp, output không phải cấu hình ERP, không phải quyết định vận hành, không phải bằng chứng tuân thủ.

Artifact	Canonical ID	Owner quản trị	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Bản đồ nguồn tham chiếu	00_SOURCE_MAP	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	URL chính thức, tổ chức phát hành, version/status, phạm vi dùng an toàn, ngày truy cập 2026-08-07	Ghi version, ngày, nội dung thay đổi, lý do và ảnh hưởng source boundary
Danh mục định danh truy vết	TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID canonical, loại đối tượng, quy tắc đặt ID, quan hệ truy vết, authority khi ID chạm lĩnh vực chuyên môn	Không đổi ID im lặng; ghi ID cũ, ID mới nếu được phép, lý do, artifact bị ảnh hưởng
Catalog quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Rule ID, phát biểu rule, nguồn, phạm vi, ngoại lệ, nhãn Verification required khi chưa có authority xác nhận	Ghi thay đổi rule theo version; giữ lịch sử wording, nguồn và tác động traceability
Từ điển dữ liệu logic	CANONICAL_DATA_DICTIONARY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Data element ID, tên, định nghĩa, kiểu logic, nguồn, phân loại dữ liệu, rule liên quan	Ghi trường thêm, sửa, ngừng dùng; không xóa lịch sử định nghĩa
Kiến trúc curriculum	01_CURRICULUM_ARCHITECTURE	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Phạm vi học, dependency, ranh giới authority, liên kết handbook/template	Ghi thay đổi cấu trúc, dependency và ảnh hưởng chapter
Manifest chapter	CHAPTER_MANIFEST	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Đường dẫn canonical, chapter scope, thứ tự, dependency, boundary	Ghi thay đổi filename, scope hoặc dependency; không tạo chapter ID biến thể
Manifest template	TEMPLATE_MANIFEST	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Template ID, tệp dự kiến, input, output, scope, nhãn xác minh cần giữ	Ghi thay đổi template mapping và dependency

Owner quản trị giữ tính toàn vẹn artifact: ID, filename, status, version và lịch sử. Owner không vì giữ artifact mà có quyền xác nhận legal, accounting, security, architecture, business decision, baseline, approval hay production use.

Mỗi artifact phải giữ metadata chung: Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, Việt Nam và VND mô phỏng. Bằng chứng: các artifact upstream cùng công bố các giá trị này. Suy luận: output downstream phải giữ cùng metadata để không tạo hai trạng thái quản trị mâu thuẫn.

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

flowchart TB
    A[Artifact upstream công bố metadata chung] --> B[Principal IT Business Analyst / Technical Curriculum Author<br/>tạo hoặc cập nhật output]
    B --> C[Đồng bộ integrity<br/>ID, filename, status, version<br/>2026-08-07, Asia/Ho_Chi_Minh, vi-VN, Việt Nam, VND mô phỏng]
    C --> D[Ghi lịch sử thay đổi<br/>nội dung, lý do, ảnh hưởng]
    D --> E[Output downstream<br/>Status: IN_REVIEW<br/>cùng metadata upstream]

    B -. owner quản trị, không có authority .-> F[Không xác nhận<br/>legal, accounting, security, architecture<br/>business decision, baseline, approval<br/>hoặc production use]

Applied

Nova Foods là mô phỏng giáo dục. Facts: nguồn upstream ghi IN_REVIEW, v0.9.0, không có baseline reference và không có approval reference. Current Behavior: BA cần gom output để reviewer kiểm tra truy vết giữa nguồn, rule và data. Underlying Need: người nhận phải biết artifact nào là nguồn canonical, ai duy trì và thay đổi nào đã xảy ra.

Thành phần	Nội dung Nova Foods mô phỏng
Options	Option 1: tạo bản tóm tắt không ID. Option 2: cập nhật artifact canonical và ghi change history.
Decision Criteria	Không mất traceability; không thay ID; không biến review thành approval; giữ source boundary.
Decision	Chọn Option 2. Evidence: TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là artifact canonical đã được xác định.
Authority	Principal IT Business Analyst / Technical Curriculum Author quản trị artifact; Legal Owner, Accounting Owner, Security, Architect hoặc Business Owner quyết định nội dung thuộc thẩm quyền họ.
Artifact	Cập nhật có kiểm soát vào 00_SOURCE_MAP, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, 01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST, TEMPLATE_MANIFEST.
Consequence if Wrong	Reviewer dùng bản sao thay nguồn canonical; rule mất liên kết nguồn; thay đổi không thể audit; IN_REVIEW bị hiểu sai thành approval.

Ví dụ dòng lịch sử tối thiểu: 2026-08-07 | v0.9.0 | IN_REVIEW | Principal IT Business Analyst / Technical Curriculum Author | Khởi tạo metadata và liên kết artifact Nova Foods mô phỏng | Không có baseline hoặc approval reference. Dòng này ghi việc quản trị đã diễn ra, không khẳng định nội dung đã được phê duyệt.

Senior Lens

Không tạo artifact mới khi artifact canonical hiện có chứa đúng loại thông tin. Lý do: thêm bản sao tạo thêm nguồn chân lý và tăng nguy cơ lệch version. Chỉ tạo artifact riêng khi registry đã cấp ID canonical, filename được kiểm soát và owner chịu trách nhiệm lịch sử thay đổi.

IN_REVIEW là trạng thái làm việc có kiểm soát. Nó cho phép sửa có truy vết, không cho phép gọi artifact là APPROVED, BASELINED, compliant, production-ready hoặc user-approved. Khi nội dung chạm Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, hóa đơn, an toàn thực phẩm, security hoặc kiến trúc, giữ nhãn Verification required cho đến khi authority phù hợp ghi nhận kết luận trong artifact kiểm soát.

Quick Reference

Quy tắc	Áp dụng
Dùng đúng ID canonical	Không dịch, rút gọn hoặc tự tạo biến thể ID
Giữ đúng filename nguồn	Bản xuất hoặc bản sao không thay artifact kiểm soát
Ghi lịch sử trước khi chuyển review	Không sửa im lặng v0.9.0
Giữ IN_REVIEW	Không suy diễn baseline, approval hoặc production readiness
Giữ source classification	Nguồn pháp lý, chuẩn, good practice và project assumption không được trộn lẫn

Core

Output anatomy là cấu trúc đủ để người review đọc, truy vết và kiểm tra gói bàn giao. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp. Gói không tạo quyết định vận hành ERP, baseline, approval hoặc production readiness.

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

flowchart TB
  subgraph I[Controlled upstream sources]
    M[CHAPTER_MANIFEST<br/>TEMPLATE_MANIFEST<br/>TRACEABILITY_ID_REGISTRY]
    C[CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY]
    S[00_SOURCE_MAP<br/>01_CURRICULUM_ARCHITECTURE]
  end

  F[Controlled file:<br/>/02-handbook/17-implementation-readiness-and-handoff-pack.md]
  ID[Document identity:<br/>17 Implementation Readiness And Handoff Pack]
  G[Governance context:<br/>IN_REVIEW · v0.9.0 · 2026-08-07<br/>Asia/Ho_Chi_Minh · vi-VN · VND]
  K[Case classification:<br/>simulated educational case<br/>synthetic data only]

  F --> ID
  ID --> G
  G --> K

  M --> H[Handoff output anatomy]
  C --> H
  S --> H
  F --> H
  K --> H

  H --> Q[Scope:<br/>readiness and handoff<br/>for downstream review only]
  Q --> P[Payload:<br/>requirement reference · rule reference<br/>logical data reference · test-basis reference<br/>open verification label]
  Q --> T[Canonical links<br/>and specific review questions]
  Q --> R[Change record:<br/>version · date · change description<br/>affected artifact · traceability link]

  R --> M
  R --> C
  R --> S

  P --> V{Legal, accounting, tax,<br/>food safety, or security claim?}
  V -->|Yes| O[Authorized owner verification required<br/>before mandatory requirement]
  V -->|No| T
  O --> T

  T --> D[Downstream review]
  R --> D

  D --> B[Review support only]
  B -.-> X[Not ERP operation, baseline,<br/>approval, or production readiness]

Thành phần anatomy	Nội dung bắt buộc	Bằng chứng hoặc lý do
Controlled file	/02-handbook/17-implementation-readiness-and-handoff-pack.md	Đường dẫn xác định vị trí kiểm soát của nội dung handoff.
Document identity	17 Implementation Readiness And Handoff Pack	Tên tài liệu phân biệt gói handoff với registry, rule catalog và data dictionary.
Governance context	IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND	Metadata chung corpus khóa ngữ cảnh review; IN_REVIEW không phải approval hay baseline.
Source classification	Controlled planning artifact; simulated educational case; synthetic data only	Phân loại ngăn người dùng hiểu ví dụ là cấu hình ERP thực, quy định pháp lý hay bằng chứng tuân thủ.
Scope statement	Readiness và handoff cho review hạ nguồn	Mục đích giới hạn nội dung vào khả năng review, không xác nhận triển khai.
Input traceability	CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; 00_SOURCE_MAP; 01_CURRICULUM_ARCHITECTURE	Các artifact này là nguồn kiểm soát đã nêu; output phải chỉ rõ nguồn thay vì tự tạo nguồn chân lý mới.
Artifact payload	Requirement reference, rule reference, logical data reference, test-basis reference, open verification label	Reviewer cần biết cái gì được bàn giao, nguồn nào hỗ trợ nó, điểm nào chưa được xác minh.
Evidence boundary	Không diễn giải luật, kế toán, thuế, an toàn thực phẩm hay bảo mật thành yêu cầu bắt buộc khi chưa có owner có thẩm quyền xác minh	Nguồn seed quy định rõ các suy diễn này cần Verification required.
Review entry point	Danh sách liên kết canonical và câu hỏi review cụ thể	Review bắt đầu từ artifact nguồn, không từ giả định của người nhận.
Change record	Phiên bản, ngày, mô tả thay đổi, artifact bị ảnh hưởng, liên kết traceability	Lịch sử thay đổi cho phép reviewer biết nội dung nào đổi và kiểm tra tác động.

Applied

Facts: Nova Foods Trading & Manufacturing là mô phỏng; case dùng dữ liệu tổng hợp. Corpus đang ở IN_REVIEW, v0.9.0, ngày 2026-08-07. Không có baseline reference hoặc approval reference.

Current Behavior: Learner có nhiều artifact nguồn, nhưng nếu handoff chỉ ghi “đã sẵn sàng” thì QA, Architect hoặc Business Owner không biết rule, dữ liệu và nguồn nào phải review.

Underlying Need: Tạo một output anatomy làm “bản đồ gói bàn giao”: mỗi nội dung có nguồn canonical, ranh giới suy diễn và điểm review.

Options:
1. Một đoạn tóm tắt tự do.
2. Một bảng anatomy có liên kết artifact nguồn.
3. Một đặc tả triển khai ERP đầy đủ.

Decision Criteria: Không tạo nguồn chân lý mới; giữ canonical ID và filename; đủ cho review; không vượt thẩm quyền pháp lý, kế toán, kiến trúc hoặc production.

Decision: Chọn bảng anatomy có traceability tới artifact nguồn. Lý do: bảng cho phép đối chiếu từng thành phần; đoạn tự do khó kiểm tra; đặc tả triển khai vượt phạm vi học liệu IN_REVIEW.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability. Business Owner, Architect, QA, Legal Owner, Accounting Owner, Security Owner giữ thẩm quyền xác minh chuyên môn thuộc phạm vi của họ.

Artifact: Micro-example hoàn chỉnh dưới đây.

Mục output	Giá trị Nova Foods mô phỏng	Nguồn canonical	Phân loại nguồn	Diễn giải review
Handoff package	17 Implementation Readiness And Handoff Pack	/02-handbook/17-implementation-readiness-and-handoff-pack.md	Handbook artifact đang soạn	Gói hướng dẫn review, không phải release package.
Curriculum scope	26 handbook chapters có manifest quản trị	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Kiểm tra chapter này còn nằm trong cấu trúc corpus.
Template scope	Template được lập kế hoạch, chưa mặc định tồn tại hoặc được phê duyệt	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact	Không gọi template là completed artifact khi manifest chỉ là kế hoạch.
ID control	ID phải dùng đúng registry; không tự đổi tên hoặc tạo alias	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Reviewer đối chiếu định danh trước khi theo traceability.
Business-rule boundary	Rule chỉ là catalog kế hoạch cho đến khi có nội dung và thẩm quyền xác minh	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Không chuyển rule mô phỏng thành quy định Nova Foods thực.
Logical-data boundary	Data field và nghĩa logic phải tham chiếu data dictionary	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	Không suy diễn schema, API field hoặc database design.
Research-source boundary	Nguồn chuẩn, pháp lý và good practice có safe-use boundary	00_SOURCE_MAP tại /00-research/00_SOURCE_MAP.md	Verified primary-source map	Không bịa điều khoản, trang, nghĩa vụ pháp lý hoặc xác nhận compliance.
Architecture context	Chuỗi học từ requirement đến test basis phải không đứt traceability	01_CURRICULUM_ARCHITECTURE tại /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Kiểm tra output không làm learner phải tự suy diễn rule hoặc test basis.
Verification label	Verification required cho chi tiết pháp lý, kế toán, thuế, privacy, food safety chưa đối chiếu văn bản hiện hành	Verified source seed	Source boundary	Nhãn giữ khoảng trống minh bạch cho owner có thẩm quyền.
Change-history row	v0.9.0 khởi tạo; 2026-08-07; mô tả: anatomy và micro-example cho review; ảnh hưởng: section 6	Artifact metadata của corpus	Governance metadata	Dòng này ghi thay đổi nội dung học liệu, không ghi approval.

Consequence if Wrong: Nếu gói thay source canonical bằng tóm tắt tự do, reviewer có thể review sai rule hoặc data reference. Nếu gọi IN_REVIEW là approved, người nhận có thể hiểu sai thẩm quyền và dùng nội dung mô phỏng như chỉ dẫn production.

Senior Lens

Inference phải có cầu nối bằng chứng. Ví dụ, kết luận “cần nhãn Verification required” không xuất phát từ cảm tính: source seed nói chi tiết pháp lý, kế toán, thuế, privacy, food safety và traceability chưa đối chiếu phải mang nhãn này. Vì vậy output chỉ ghi nhãn và nguồn; không tự viết nghĩa vụ vận hành.

Một anatomy tốt không cố “đầy đủ mọi tài liệu có thể có”. Nó đầy đủ theo mục đích review: người nhận xác định được file kiểm soát, nguồn canonical, giới hạn sử dụng, nội dung cần review và lịch sử thay đổi. Thêm design, cấu hình ERP hoặc quyết định production khi chưa có đầu vào sẽ biến handoff thành suy diễn.

Quick Reference

Kiểm tra anatomy	Đạt khi
Có file và tên tài liệu	Dùng đúng /02-handbook/17-implementation-readiness-and-handoff-pack.md và 17 Implementation Readiness And Handoff Pack.
Có traceability	Mỗi nội dung Nova Foods mô phỏng liên kết tới artifact canonical hoặc verified source seed.
Có ranh giới nguồn	Không biến source overview, planning artifact hoặc dữ liệu tổng hợp thành xác nhận vận hành.
Có micro-example đủ hàng	Mọi thành phần anatomy trong bảng đều có giá trị, nguồn và diễn giải review.
Có lịch sử thay đổi	Ghi version, ngày, mô tả và phạm vi ảnh hưởng; không ghi approval không tồn tại.

Core

Quality gate là cổng kiểm tra chất lượng trước downstream review, không phải phê duyệt. Mỗi output chỉ được gắn READY_FOR_DOWNSTREAM_REVIEW khi reviewer có thể kiểm tra nội dung mà không phải suy đoán nguồn, phạm vi, trạng thái hay thay đổi. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; trạng thái artifact vẫn là IN_REVIEW, version v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh.

Kiểm tra bắt buộc	Điều kiện đạt	Bằng chứng cần có	Không chứng minh
Nhận diện	Canonical ID, filename, owner, status, version khớp nguồn kiểm soát	Metadata trong artifact	Approval, baseline
Traceability	Mỗi nhận định liên kết artifact nguồn hoặc nhãn Verification required	ID và đường dẫn nguồn	Nguồn đã xác nhận nội dung nghiệp vụ
Nội dung	Không mâu thuẫn source boundary; giả định ghi rõ là giả định dự án	Bảng kiểm và change history	Sẵn sàng production
Thay đổi	Có dòng lịch sử nêu ngày, người ghi nhận, nội dung đổi, lý do	Change-history entry	Người có thẩm quyền đã chấp thuận
Khả năng review	Không có TODO, TBD, ellipsis, dòng thiếu, hoặc kết luận pháp lý/kế toán tự suy diễn	Kiểm tra toàn văn	Compliance hoặc legal sign-off

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

stateDiagram-v2
    direction TB
    [*] --> IN_REVIEW
    IN_REVIEW --> READY_FOR_DOWNSTREAM_REVIEW: đạt Nhận diện, Traceability, Nội dung, Thay đổi và Khả năng review
    READY_FOR_DOWNSTREAM_REVIEW --> IN_REVIEW: bất kỳ kiểm tra bắt buộc nào không còn đạt
    READY_FOR_DOWNSTREAM_REVIEW --> READY_FOR_DOWNSTREAM_REVIEW: artifact owner bàn giao cho reviewer để downstream review

    note right of READY_FOR_DOWNSTREAM_REVIEW
        Artifact giữ trạng thái này sau bàn giao.
        Bàn giao không phải phê duyệt.
    end note

Applied

Facts: Output mô phỏng CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md có status IN_REVIEW, version v0.9.0. Nguồn quản trị nêu Owner không có quyền tự baseline, approval, legal hay accounting sign-off.

Current Behavior: Reviewer nhận artifact khi metadata và liên kết nguồn hiện diện, nhưng phải trả lại nếu change history không giải thích thay đổi hoặc rule bị diễn đạt thành nghĩa vụ pháp lý chưa xác minh.

Underlying Need: Downstream reviewer cần biết chính xác đang review cái gì, dựa trên đâu, và phần nào chưa đủ thẩm quyền xác nhận.

Options:

Phương án	Hệ quả
Gắn READY_FOR_DOWNSTREAM_REVIEW sau khi viết xong	Reviewer có thể nhận nội dung thiếu traceability
Chờ approval rồi mới review	Sai thứ tự; review là đầu vào cho approval nếu có
Dùng quality gate kiểm tra đầy đủ trước review	Giữ được truy vết và không tạo approval ngầm định

Decision Criteria: Chọn phương án nếu giữ đúng canonical ID, source classification, change history, ranh giới thẩm quyền và cho phép reviewer kiểm tra không suy đoán.

Decision: Dùng quality gate trước downstream review. READY_FOR_DOWNSTREAM_REVIEW chỉ là nhãn sẵn sàng để xem xét.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và bằng chứng kiểm tra. Business Owner, Legal Owner, Accounting Owner, Architect, Security hoặc QA chỉ xác nhận phần thuộc thẩm quyền của họ khi có ghi nhận riêng.

Artifact: CANONICAL_BUSINESS_RULES, /01-curriculum/CANONICAL_BUSINESS_RULES.md, IN_REVIEW, v0.9.0; change history phải ghi 2026-08-07, người ghi nhận, phạm vi thay đổi và lý do.

Consequence if Wrong: Gọi output là approved hoặc production-ready sẽ biến kiểm tra tài liệu thành quyết định vượt thẩm quyền, làm sai traceability và có thể khiến downstream team dùng giả định mô phỏng như rule vận hành thật.

Senior Lens

Quality gate kiểm tra khả năng review, không kiểm tra tính đúng cuối cùng. Cầu nối suy luận: artifact IN_REVIEW còn có thể đổi; vì vậy gate chỉ xác nhận reviewer nhận đủ ngữ cảnh để phát hiện lỗi. Nếu một output chứa thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật, gate phải kiểm tra nhãn Verification required và owner chuyên môn cần thiết; không thay nhãn này bằng kết luận tuân thủ.

Quick Reference

Nhãn	Được dùng khi	Không được hiểu là
IN_REVIEW	Artifact đang xem xét có kiểm soát	Approved, baselined, production-ready
READY_FOR_DOWNSTREAM_REVIEW	Quality gate đủ bằng chứng để reviewer bắt đầu	Review đã hoàn tất hoặc nội dung đã đúng
Verification required	Cần xác minh bởi nguồn hoặc vai trò có thẩm quyền	Rule bắt buộc đã được xác nhận

7. Who consumes those outputs?

Core

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Output của Implementation Readiness And Handoff Pack không tự tạo phê duyệt hay baseline. Chúng là test basis: căn cứ để vai trò downstream hiểu cùng một phạm vi trước khi xây dựng, kiểm thử, cấu hình hoặc vận hành.

Consumer	Output họ dùng	Cách dùng trong công việc	Kết quả họ cần tạo
Developers	Requirement package, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, traceability	Chuyển rule, trường dữ liệu, trạng thái và acceptance criteria thành cấu hình hoặc mã nguồn	Thiết kế kỹ thuật, cấu hình, mã nguồn, unit test
QA	Acceptance criteria, business rule, traceability, luồng nghiệp vụ	Tạo test condition, test case và liên kết lỗi về requirement gốc	Test cases, test evidence, defect record
Architect	Integration boundary, data dictionary, non-functional requirement	Kiểm tra luồng dữ liệu, ownership, interface và ràng buộc kỹ thuật	Architecture decision record, integration design
PM/Product Owner	Scope, dependency, risk, traceability	Lập kế hoạch delivery, ưu tiên backlog và theo dõi chặn tiến độ	Delivery plan, backlog ordering, risk log
Business Owner	Business process, rule, acceptance criteria	Kiểm tra output có phản ánh mục tiêu nghiệp vụ mô phỏng hay không	Business review comment, quyết định nghiệp vụ thuộc thẩm quyền
Operations	Runbook draft, role matrix, exception flow	Chuẩn bị vận hành, hỗ trợ người dùng và xử lý ngoại lệ sau triển khai	Operating procedure, support readiness input
Specialist owners	Output thuộc miền chuyên môn: kế toán, pháp lý, bảo mật, an toàn thực phẩm	Xem xét nội dung có nhãn Verification required	Ý kiến chuyên môn được ghi nhận riêng

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

flowchart TB
    BA[BA handoff pack<br/>Test basis only<br/>No approval or baseline]

    BA --> DEV[Developers]
    BA --> QA[QA]
    BA --> ARC[Architect]
    BA --> PM[PM/Product Owner]
    BA --> BO[Business Owner]
    BA --> OPS[Operations]
    BA -->|Verification required| SPO[Specialist owners]

    DEV --> BUILD[Technical design<br/>Configuration, code, unit test]
    QA --> TEST[Test cases<br/>Test evidence, defect record]
    ARC --> DESIGN[Architecture decision record<br/>Integration design]
    PM --> PLAN[Delivery plan<br/>Backlog ordering, risk log]
    BO --> REVIEW[Business review comment<br/>Business decision within authority]
    OPS --> READY[Operating procedure<br/>Support readiness input]
    SPO --> VERIFY[Specialist opinion<br/>Recorded separately]

Applied

Facts: CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đang ở IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Chúng thuộc corpus Nova Foods mô phỏng; không phải cấu hình ERP production.

Current Behavior: Developers đọc rule để biết điều kiện xử lý. QA đọc cùng rule để tạo kiểm thử. Architect đọc data dictionary để xác định dữ liệu nào đi qua integration. Operations đọc exception flow để chuẩn bị xử lý sự cố.

Underlying Need: Mỗi consumer phải dùng cùng nguồn canonical. Cầu nối suy luận: nếu Developers dùng bản sao rule còn QA dùng bản trích khác, hai bên có thể xây và kiểm thử hai cách hiểu khác nhau; traceability mất khả năng chứng minh lỗi bắt nguồn từ đâu.

Options: Dùng artifact canonical được kiểm soát; hoặc dùng bản sao không có liên kết nguồn. Chỉ lựa chọn đầu giữ được ID, trạng thái và version để đối chiếu.

Decision Criteria: Consumer phải thấy được artifact ID, filename, IN_REVIEW, v0.9.0, phạm vi mô phỏng và liên kết traceability trước khi dùng output.

Decision: Handoff package tham chiếu trực tiếp CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY; không thay bằng tên diễn giải hoặc bản sao không kiểm soát.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết artifact và metadata. Mỗi consumer dùng output trong phạm vi vai trò; không suy diễn việc nhận handoff thành approval.

Artifact: /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md, trạng thái IN_REVIEW, phiên bản v0.9.0.

Consequence if Wrong: Developer có thể build theo rule cũ, QA kiểm thử rule khác, Architect thiết kế sai ownership dữ liệu, Operations nhận quy trình không khớp hệ thống mô phỏng.

Senior Lens

Không phải mọi output đều dành cho mọi người. Business Owner cần hiểu outcome và rule nghiệp vụ, không cần quyết định kiểu dữ liệu kỹ thuật. Architect cần biết boundary và ownership dữ liệu, không tự thay Business Owner xác nhận mục tiêu nghiệp vụ. QA cần acceptance criteria có thể kiểm thử, không tự biến khoảng trống thành rule. Cầu nối suy luận: chuyên môn mỗi vai trò khác nhau; giao cả gói mà không chỉ rõ mục đích dùng sẽ tạo review bề rộng nhưng không có accountability rõ.

Quick Reference

Output	Consumer chính	Consumer phụ
CANONICAL_BUSINESS_RULES	Developers, QA, Business Owner	PM/Product Owner, Operations
CANONICAL_DATA_DICTIONARY	Developers, Architect	QA, specialist owners
Traceability	QA, PM/Product Owner	Developers, Architect
Acceptance criteria	QA, Developers	Business Owner, PM/Product Owner
Integration boundary	Architect, Developers	QA, Operations
Exception flow	Operations, QA	Business Owner, Developers

Core

Mỗi người nhận bàn giao dùng output để ra quyết định trong phạm vi vai trò, không dùng để tự tạo rule mới. Bằng chứng phải truy về artifact canonical đang IN_REVIEW, v0.9.0, ngày 2026-08-07; Nova Foods Trading & Manufacturing là case mô phỏng, chỉ có dữ liệu tổng hợp. Thiếu bằng chứng, người nhận phải escalation thay vì suy diễn.

Consumer	Có thể quyết định	Bằng chứng cần	Phải escalation khi
Developer	Cách hiện thực kỹ thuật, thứ tự build, lỗi validation có thể chặn lưu	Requirement, acceptance criteria, field definition từ CANONICAL_DATA_DICTIONARY, rule từ CANONICAL_BUSINESS_RULES, traceability ID	Rule mơ hồ; field thiếu kiểu/độ dài; yêu cầu xung đột API, bảo mật hoặc dữ liệu
QA	Test basis, test case, dữ liệu test tổng hợp, mức độ pass/fail theo acceptance criteria	Requirement có truy vết, business rule, expected result, lỗi đã tái lập	Không có expected result; acceptance criteria không đo được; lỗi có thể là thay đổi requirement
Architect	Pattern tích hợp, ranh giới hệ thống, non-functional requirement, rủi ro kiến trúc	Interface scope, data ownership, volume giả định, security constraint, dependency	Thay đổi ảnh hưởng data owner, API contract, quyền truy cập, hiệu năng hoặc hệ thống ngoài
PM/Product Owner	Ưu tiên backlog, phạm vi release, trade-off thời gian/chi phí/phạm vi	Mục tiêu nghiệp vụ, dependency, estimate, risk, acceptance criteria	Trade-off làm mất outcome nghiệp vụ; scope change; dependency không có owner
Business Owner	Ý nghĩa nghiệp vụ, ưu tiên quy trình, chấp nhận rule thuộc nghiệp vụ	Luồng hiện tại, vấn đề, rule đề xuất, tác động vận hành, dữ liệu mô phỏng	Rule liên quan kế toán, thuế, pháp lý, an toàn thực phẩm hoặc quyền dữ liệu cá nhân
Operations	Readiness vận hành, phân quyền tác nghiệp, xử lý ngoại lệ, hỗ trợ sau go-live	Process flow, runbook, exception path, training impact, audit need	Quy trình không có người xử lý ngoại lệ; thiếu quyền; downtime hoặc dữ liệu sai gây gián đoạn
Specialist owner	Kết luận chuyên môn trong miền được giao, như Accounting, Legal, Security, Food Safety	Nguồn chính thức, dữ liệu liên quan, giả định dự án, câu hỏi quyết định	Bằng chứng không đủ; nguồn hết hiệu lực; yêu cầu bị diễn giải thành tuân thủ hoặc quyết định production

Bằng chứng không phải ý kiến miệng. Bằng chứng là artifact có ID, phiên bản, nguồn và quan hệ truy vết. Ví dụ, Developer thấy trường supplier_tax_code cần bắt buộc nhưng CANONICAL_DATA_DICTIONARY không nêu nullability. Developer có thể chặn build phần validation; không được tự chọn “bắt buộc”. BA ghi vấn đề, liên kết requirement và chuyển Business Owner cùng specialist owner phù hợp.

Senior Lens

Escalation là đưa quyết định lên đúng thẩm quyền, không phải chuyển việc. Gói escalation tối thiểu gồm: ID bị ảnh hưởng; mô tả mâu thuẫn; artifact và phiên bản nguồn; tác động nếu chọn từng phương án; câu hỏi cần trả lời; owner được đề nghị. Không ghi “đã phê duyệt” khi artifact vẫn IN_REVIEW.

Hiểu nhầm bàn giao	Rủi ro	Câu hỏi làm rõ chính xác
“QA tự hiểu expected result từ màn hình.”	Test xác nhận hành vi ngẫu nhiên, không xác nhận requirement	“Acceptance criteria nào xác định kết quả mong đợi cho trường hợp dữ liệu không hợp lệ?”
“Developer chọn rule hợp lý nhất.”	Code biến thành nguồn chân lý nghiệp vụ	“Rule canonical nào cho phép hoặc cấm trạng thái này, và Business Owner nào quyết định khi chưa có rule?”
“Architect quyết luôn chính sách giữ dữ liệu.”	Quyết định vượt thẩm quyền pháp lý và nghiệp vụ	“Data owner, Legal Owner và Business Owner nào xác nhận thời hạn lưu giữ; nguồn chính thức nào được dùng?”
“PM giảm scope nên bỏ kiểm soát.”	Release thiếu kiểm soát bảo mật hoặc truy vết	“Kiểm soát nào là bắt buộc do risk, ai sở hữu quyết định chấp nhận risk, và bằng chứng ghi ở artifact nào?”
“Operations sẽ xử lý thủ công nếu lỗi.”	Không có runbook, người trực hoặc giới hạn xử lý	“Ai xử lý ngoại lệ, trong thời gian nào, quyền nào cần cấp, và bản ghi nào phải được tạo?”

Quy tắc dừng: một output chạm đồng thời nghiệp vụ, kiến trúc, bảo mật, kế toán, pháp lý hoặc vận hành thì không vai trò đơn lẻ nào tự chốt. BA giữ traceability và câu hỏi; role có thẩm quyền mới ra kết luận.

Core

Handoff thất bại khi người nhận đọc cùng artifact nhưng gán nghĩa khác nhau. Nova Foods Trading & Manufacturing là case mô phỏng, chỉ dùng dữ liệu tổng hợp. IN_REVIEW và v0.9.0 ngày 2026-08-07 cho biết nội dung còn xem xét; không cho phép suy ra baseline, phê duyệt, cấu hình ERP hay quyền triển khai.

Hiểu nhầm phải được đổi thành câu hỏi có thể trả lời bằng artifact, nguồn canonical, vai trò có thẩm quyền hoặc quyết định được ghi nhận. Không hỏi “đã rõ chưa?” vì câu trả lời không tạo bằng chứng.

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

flowchart TB
    A[Artifact handoff] --> B[Người nhận nêu cách hiểu và câu hỏi kiểm chứng]
    B --> C{Artifact có đủ bằng chứng để trả lời câu hỏi kiểm chứng?}

    C -- Có --> G[Ghi kết luận có căn cứ từ artifact]
    C -- Không --> D{Nguồn canonical có đủ bằng chứng để trả lời câu hỏi kiểm chứng?}

    D -- Có --> H[Ghi kết luận và nguồn canonical]
    D -- Không --> E{Cần quyết định từ vai trò có thẩm quyền?}

    E -- Có --> I[Chuyển câu hỏi đến vai trò có thẩm quyền]
    I --> J{Kết quả đã được ghi nhận?}
    J -- Có quyết định --> L[Ghi kết luận và quyết định có thẩm quyền]
    J -- Chưa ghi nhận --> K[Yêu cầu ghi nhận quyết định]
    K --> J
    J -- Chưa thể trả lời --> V[Ghi câu hỏi OPEN/UNRESOLVED, owner và bước tiếp theo]

    E -- Không --> F{Có bằng chứng mới và owner phù hợp để cập nhật?}
    F -- Artifact --> FA[Artifact owner cập nhật artifact theo bằng chứng và thẩm quyền]
    FA --> C
    F -- Nguồn canonical --> FC[Canonical source owner cập nhật nguồn theo bằng chứng và thẩm quyền]
    FC --> D
    F -- Không --> V

    G --> R[Tiếp tục review]
    H --> R
    L --> R
    V --> W[Chỉ tiếp tục phần không phụ thuộc câu hỏi mở]
    W --> R

    R --> S{Có yêu cầu triển khai?}
    S -- Không --> T[Chỉ review; không suy ra quyền triển khai]
    S -- Có --> M{Có bằng chứng baseline được phê duyệt?}

    M -- Có --> O{Có bằng chứng quyền triển khai?}
    M -- Chưa có quyết định được ghi nhận --> N[Yêu cầu baseline owner quyết định và ghi nhận trạng thái baseline]
    N --> M
    M -- Không được phê duyệt --> X[Dừng và đóng yêu cầu triển khai hiện tại]

    O -- Có --> Q[Triển khai theo baseline và quyền đã được ghi nhận]
    O -- Chưa có quyết định --> P[Yêu cầu deployment authority quyết định và ghi nhận quyền triển khai]
    P --> O
    O -- Không được cho phép --> Y[Dừng và đóng yêu cầu triển khai hiện tại]

    X --> Z[Chỉ tiếp tục review]
    Y --> Z
    Z --> U{Có yêu cầu triển khai mới cùng bằng chứng hợp lệ?}
    U -- Không --> T
    U -- Có --> M

Applied

Facts	Current Behavior	Underlying Need	Options	Decision Criteria	Decision	Authority	Artifact	Consequence if Wrong
Developer đọc “chặn đơn khi vượt hạn mức”	Developer tự hiểu chặn tại màn hình tạo đơn	Xác định điểm kiểm soát, trạng thái đơn, thông báo lỗi	Chặn UI; chặn API; chặn cả hai	Có đường tích hợp nào tạo đơn ngoài UI; API có là trust boundary hay không	Không tự chọn. Làm rõ trước khi build	Business Owner quyết định rule; Architect quyết định điểm kiểm soát kỹ thuật	CANONICAL_BUSINESS_RULES; TRACEABILITY_ID_REGISTRY	Có thể tạo đơn vượt hạn mức qua tích hợp
QA thấy “ngày giao không được trước ngày đặt”	QA chỉ tạo test giao diện	Xác định múi giờ, trường nguồn, hành vi API	Test UI; test API; test cả hai	Trường nào là nguồn dữ liệu; có import hay API không	Không suy diễn phạm vi test	Business Owner xác nhận ý nghĩa nghiệp vụ; QA Owner xác nhận test basis	CANONICAL_DATA_DICTIONARY; CANONICAL_BUSINESS_RULES	Lỗi lọt qua kênh import
Operations nhận hướng dẫn “lưu vết lô hàng”	Hiểu là phải giữ mọi dữ liệu vô thời hạn	Phân biệt yêu cầu nghiệp vụ, pháp lý, kỹ thuật lưu trữ	Đặt thời hạn; không đặt thời hạn	Có nguồn pháp lý hiện hành và kết luận Legal Owner không	Gắn Verification required; không đặt thời hạn	Legal Owner, Food-safety specialist owner, Operations Owner	Nguồn Luật An toàn thực phẩm; nguồn Luật Bảo vệ dữ liệu cá nhân	Nhầm hướng dẫn học liệu thành nghĩa vụ vận hành hoặc pháp lý

Các câu hỏi làm rõ phải giữ nguyên phạm vi. Ví dụ “chặn” không đủ vì có thể là cảnh báo, không cho lưu, không cho gửi API, hoặc cho phép ngoại lệ theo quyền.

Hiểu nhầm phổ biến	Câu hỏi làm rõ chính xác	Escalate khi
“Chặn đơn” nghĩa là vô hiệu nút Lưu	“Khi tổng dư nợ mô phỏng vượt hạn mức, hệ thống phải từ chối tạo đơn, từ chối xác nhận đơn, hay chỉ cảnh báo? Hành vi này áp dụng cho UI, API và import nào?”	Câu trả lời thay đổi rule nghiệp vụ hoặc kiến trúc tích hợp
“Ngày” là ngày lịch	“Trường delivery_date được so sánh theo ngày tại Asia/Ho_Chi_Minh hay theo thời điểm có múi giờ? Giá trị trống bị từ chối hay được phép?”	Có API, dữ liệu liên vùng thời gian, hoặc tác động sổ sách
“Người có quyền” là một vai trò chung	“Role ID nào được phép vượt kiểm soát, hành động nào được phép, và mỗi ngoại lệ cần lưu người thực hiện, thời điểm, lý do nào?”	Tác động phân quyền, bảo mật, kiểm soát nội bộ
“Lưu vết lô” là lưu mọi trường	“Sự kiện nào tạo traceability record: nhập kho, chuyển kho, xuất bán, thu hồi? Mã lô nào là khóa liên kết canonical?”	Có yêu cầu pháp lý, an toàn thực phẩm, hoặc thiết kế dữ liệu
“Đã sẵn sàng handoff” nghĩa là đã được chấp thuận	“Artifact nào ghi trạng thái review, baseline hoặc approval? Ai có thẩm quyền ghi nhận từng trạng thái?”	Không có tham chiếu baseline hoặc approval rõ ràng

Senior Lens

Bằng chứng tối thiểu cho làm rõ gồm: ID rule hoặc data field canonical, đoạn artifact gây mơ hồ, cách diễn giải cạnh tranh, tác động nếu chọn sai, owner cần quyết định. BA không thay Business Owner quyết định chính sách, không thay Architect quyết định kiến trúc, không thay Legal Owner diễn giải nghĩa vụ pháp lý.

Quy tắc: nếu câu trả lời tạo mới hạn mức, thời hạn lưu dữ liệu, quyền vượt kiểm soát, nghĩa vụ pháp lý, cấu hình bảo mật hoặc hành vi API, phải escalation. Nếu chỉ xác định thuật ngữ đã có nguồn canonical, BA ghi liên kết truy vết và cập nhật cách diễn đạt; không đổi ý nghĩa rule.

Quick Reference

• Handoff là chuyển artifact kèm nghĩa vận hành được kiểm tra, không phải gửi tệp.
• Câu hỏi tốt nêu điều kiện, hành vi, kênh áp dụng, dữ liệu và owner.
• IN_REVIEW không phải BASELINED hoặc APPROVED.
• Nova Foods là mô phỏng giáo dục; chi tiết pháp lý, kế toán, an toàn thực phẩm phải giữ nhãn Verification required khi chưa có xác nhận owner có thẩm quyền.

8. Detailed Worked Example

Applied

Bối cảnh: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Tình huống nằm trong phạm vi handoff triển khai ERP: kho thành phẩm cần xử lý yêu cầu xuất bán có truy vết lô. Trạng thái tài liệu /02-handbook/17-implementation-readiness-and-handoff-pack.md là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Nhóm fact	Fact tổng hợp	Bằng chứng và phân loại nguồn
Đơn vị bán	Chi nhánh phân phối miền Nam tạo đơn bán SO-NF-2026-0817 ngày 2026-08-07.	Dữ liệu tình huống mô phỏng; không phải dữ liệu ERP thực.
Khách hàng	Khách hàng mô phỏng CUS-NF-0421 đặt 240 thùng sữa hạt 1 lít.	Dữ liệu tình huống mô phỏng.
Mặt hàng	Mã hàng FG-NF-SH01, tên “Sữa hạt Nova 1L”, đơn vị tồn kho THUNG.	Dữ liệu tình huống mô phỏng; chưa là master data được baseline.
Yêu cầu lô	Đơn bán yêu cầu ghi nhận mã lô khi xuất kho để hỗ trợ truy vết.	Bối cảnh nghiệp vụ mô phỏng. Luật An toàn thực phẩm được dùng làm ngữ cảnh truy vết; chi tiết nghĩa vụ áp dụng thực tế: Verification required.
Tồn kho	Kho thành phẩm WH-FG-HCM có 150 thùng lô LOT-NF-260701-A và 130 thùng lô LOT-NF-260715-B.	Báo cáo tồn kho mô phỏng do kho cung cấp trong case.
Hạn dùng	Lô LOT-NF-260701-A có hạn dùng 2026-10-01; lô LOT-NF-260715-B có hạn dùng 2026-10-15.	Dữ liệu lô mô phỏng. Không kết luận chính sách FEFO là bắt buộc.
Yêu cầu giao	Bộ phận bán hàng yêu cầu giao đủ 240 thùng ngày 2026-08-08.	Yêu cầu vận hành mô phỏng.
Kênh hiện hành	Nhân viên kho nhận phiếu xuất PDF qua email nội bộ, đối chiếu số lượng bằng bảng tính.	Quan sát hiện trạng mô phỏng.
Hạn chế hiện hành	Bảng tính có cột mã lô nhưng không bắt buộc nhập; ERP hiện hành chỉ ghi nhận tổng số lượng xuất.	Hiện trạng mô phỏng; cần xác minh khi áp dụng vào hệ thống thực.

Current Behavior — hành vi hiện tại: Khi đơn SO-NF-2026-0817 được xác nhận, nhân viên bán hàng gửi PDF cho kho. Thủ kho mở bảng tính tồn kho, tự chọn lô đủ số lượng, ghi số lượng xuất vào phiếu giấy, rồi cập nhật tổng 240 THUNG vào ERP. ERP không kiểm tra tổng số lượng theo từng lô, không lưu liên kết bắt buộc giữa đơn bán, phiếu xuất và mã lô. Vì vậy, số lượng tổng có thể đúng nhưng lịch sử lô có thể thiếu hoặc sai.

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

flowchart TB
    A[Sales tạo SO-NF-2026-0817<br/>240 THUNG FG-NF-SH01] --> B[SO được xác nhận]
    B --> C[Gửi PDF qua email nội bộ]
    C --> D[Kho mở bảng tính tồn kho]
    D --> E[Bảng tính không bắt buộc mã lô]
    E --> F[Thủ kho tự chọn và phân bổ lô]
    F --> G[LOT-NF-260701-A<br/>Phân bổ 150 / tồn 150 THUNG]
    F --> H[LOT-NF-260715-B<br/>Phân bổ 90 / tồn 130 THUNG]
    G --> I[Thủ kho ghi số lượng xuất<br/>vào phiếu giấy]
    H --> I
    I --> J[Thủ kho cập nhật ERP<br/>tổng xuất 240 THUNG]
    J --> K[ERP không kiểm tra tổng số lượng<br/>theo từng lô]
    K --> L[ERP không bắt buộc<br/>lưu liên kết đơn-lô]
    L --> M[Lịch sử lô có thể thiếu hoặc sai<br/>ERP không chứng minh đơn đã xuất từ lô nào]

Bước hiện tại	Người thực hiện	Dữ liệu được ghi	Dữ liệu không được hệ thống kiểm soát	Rủi ro quan sát được
Tạo đơn bán	Nhân viên bán hàng	Mã đơn, mã hàng, số lượng, ngày giao	Phân bổ lô xuất	Kho không có phân bổ lô hệ thống ngay từ đầu.
Chọn lô	Thủ kho	Có thể ghi mã lô trong bảng tính hoặc phiếu giấy	Quy tắc bắt buộc, kiểm tra tồn theo lô, liên kết đơn-lô	Hai người có thể chọn khác lô cho cùng đơn.
Xác nhận xuất	Thủ kho	Tổng số lượng 240 THUNG	150 THUNG từ LOT-NF-260701-A; 90 THUNG từ LOT-NF-260715-B	ERP không chứng minh được đơn đã xuất từ lô nào.
Hỏi lại sau giao	Bán hàng hoặc QA	Tra cứu email, phiếu giấy, bảng tính	Nguồn chân lý duy nhất và log thay đổi	Mất thời gian; kết quả phụ thuộc bản ghi thủ công còn tồn tại.

Ranh giới ví dụ: Facts và Current Behavior chỉ mô tả hiện trạng mô phỏng để chuẩn bị handoff. Chúng không phải quyết định đã được ủy quyền, không phải cấu hình ERP, không phải xác nhận tuân thủ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc production.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND. Tình huống: kho nhận 500 kg nguyên liệu “Bột cacao” từ nhà cung cấp mô phỏng. ERP phải giữ hàng ở trạng thái chờ kiểm tra chất lượng trước khi cho phép dùng cho lệnh sản xuất.

Bước phân tích	Nội dung và cầu nối suy luận
Facts	Phiếu nhận hàng mô phỏng ghi receiptNo: GRN-20260807-001, ngày 2026-08-07, kho WH-RM-HCM, mặt hàng RM-COCOA-001, số lượng 500, đơn vị kg, lô nhà cung cấp SUP-COCOA-260807-A. Nhân viên kho có thể ghi nhận hàng trước khi QA kiểm tra. Không có bằng chứng nguồn nào cho phép suy diễn quy định vận hành thật của Nova Foods.
Current Behavior	Hệ thống hiện tại giả định cộng ngay 500 kg vào tồn khả dụng khi kho xác nhận nhận hàng. Lệnh sản xuất có thể chọn toàn bộ 500 kg ngay sau thời điểm nhận. Bằng chứng là trạng thái tồn chỉ có một giá trị “có sẵn”, không phân biệt hàng chờ kiểm tra và hàng đạt kiểm tra.
Underlying Need	Cần tách tồn khả dụng (available inventory), tức số lượng được phép cấp phát hoặc xuất dùng, khỏi số lượng vật lý đã nhận. Suy luận: vì QA chưa có kết quả, 500 kg chưa có căn cứ nghiệp vụ để đưa vào lệnh sản xuất; do đó ERP cần trạng thái kiểm soát lô. Đây là nhu cầu kiểm soát quy trình, không phải kết luận tuân thủ pháp lý hay an toàn thực phẩm.
Options	Phương án 1: cộng ngay vào tồn khả dụng, QA ghi chú ngoài hệ thống. Phương án 2: nhận hàng vào trạng thái PENDING_QA; chỉ QA được đổi sang RELEASED hoặc REJECTED. Phương án 3: chặn toàn bộ nhận hàng cho đến khi QA kiểm tra tại cổng kho.
Decision Criteria	Đánh giá theo bốn tiêu chí: ngăn xuất nhầm lô chưa kiểm tra; giữ được số lượng vật lý tại kho; truy vết người và thời điểm đổi trạng thái; không chặn hoạt động tiếp nhận khi QA kiểm tra sau. Phương án 1 thất bại tiêu chí ngăn xuất nhầm và truy vết. Phương án 3 giữ kiểm soát nhưng chặn nhận hàng, làm tăng rủi ro ùn tắc kho. Phương án 2 thỏa cả bốn tiêu chí trong phạm vi mô phỏng.
Decision	Khuyến nghị BA: dùng Phương án 2. Khi nhận, tạo lô tồn PENDING_QA, số lượng vật lý tăng 500 kg, tồn khả dụng tăng 0 kg. QA đổi RELEASED thì tồn khả dụng tăng theo số lượng được chấp nhận. QA đổi REJECTED thì lô không khả dụng và chờ quy trình xử lý tiếp theo.
Authority	Chưa có quyết định được phê duyệt. Business Owner phải xác nhận điểm kiểm soát vận hành; QA Owner phải xác nhận trạng thái và quyền đổi trạng thái; Solution Architect phải xác nhận mô hình dữ liệu và phân quyền; Accounting Owner phải xác nhận cách ghi nhận tồn nếu thiết kế ảnh hưởng sổ kế toán. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận khuyến nghị và truy vết, không có thẩm quyền phê duyệt.
Artifact	Ghi nhu cầu, trạng thái, quy tắc và payload vào artifact kiểm soát phù hợp; tham chiếu nguyên dạng /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Các artifact này đều IN_REVIEW, v0.9.0, ngày 2026-08-07; không phải baseline hay approval.
Consequence if Wrong	Nếu chọn Phương án 1, lệnh sản xuất có thể dùng nguyên liệu chưa được QA chấp nhận; truy vết lô và điều tra sai lệch bị yếu. Nếu chọn Phương án 3 khi không có nhu cầu thực tế, kho có thể không nhận được hàng đúng lúc. Nếu trao quyền đổi trạng thái cho kho thay vì QA, kiểm soát tách biệt trách nhiệm mất hiệu lực.

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

stateDiagram-v2
    direction TB

    [*] --> PENDING_QA: Kho xác nhận nhận 500 kg

    state "PENDING_QA<br/>Vật lý: 500 kg<br/>Khả dụng: 0 kg<br/>Không được cấp phát" as PENDING_QA
    state "RELEASED<br/>QA chấp nhận q kg, 0 ≤ q ≤ 500<br/>Khả dụng: q kg<br/>Phần còn lại: 500 − q kg, không khả dụng" as RELEASED
    state "REJECTED<br/>Khả dụng: 0 kg<br/>Không được cấp phát<br/>Chờ quy trình xử lý tiếp" as REJECTED

    PENDING_QA --> RELEASED: Chỉ QA chuyển trạng thái<br/>Nhập số lượng chấp nhận q
    PENDING_QA --> REJECTED: Chỉ QA chuyển trạng thái<br/>Chọn REJECTED

    note right of PENDING_QA
        Mọi trạng thái khác RELEASED:
        ERP từ chối cấp phát cho sản xuất.
        Lưu receiptNo, supplierLotNo,
        người đổi, thời điểm,
        trạng thái cũ và mới.
    end note

    RELEASED --> [*]: Cấp phát tối đa q kg

Quy tắc đề xuất để review:

Quy tắc	Điều kiện	Kết quả
Quy tắc trạng thái nhận hàng	Kho xác nhận nhận 500 kg lô SUP-COCOA-260807-A	Tạo tồn vật lý 500 kg, tồn khả dụng 0 kg, trạng thái PENDING_QA.
Quy tắc cấp phát	Trạng thái lô khác RELEASED	ERP từ chối cấp phát lô cho lệnh sản xuất.
Quy tắc QA chấp nhận	QA nhập số lượng chấp nhận từ 0 đến 500 kg	Chỉ số lượng chấp nhận trở thành tồn khả dụng.
Quy tắc QA từ chối	QA chọn REJECTED	Tồn khả dụng của lô bằng 0 kg.
Quy tắc truy vết	Có thay đổi trạng thái	Lưu số phiếu nhận, mã lô nhà cung cấp, người đổi trạng thái, thời điểm theo Asia/Ho_Chi_Minh, trạng thái cũ và trạng thái mới.

Payload minh họa cho sự kiện nhận hàng:

{
  "receiptNo": "GRN-20260807-001",
  "receiptDate": "2026-08-07",
  "warehouseCode": "WH-RM-HCM",
  "itemCode": "RM-COCOA-001",
  "quantity": 500,
  "uom": "kg",
  "supplierLotNo": "SUP-COCOA-260807-A",
  "qualityStatus": "PENDING_QA",
  "physicalQuantity": 500,
  "availableQuantity": 0,
  "currency": "VND"
}

Payload chỉ là dữ liệu mô phỏng cho phân tích. Không là hợp đồng API, cấu hình ERP, quyết định kế toán, quyết định an toàn thực phẩm, hay hướng dẫn production.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Scenario: kho thành phẩm chặn xuất bán lô gần hết hạn khi Sales Order chưa có phê duyệt ngoại lệ.

Loại	ID / giá trị	Nội dung đầy đủ	Phân loại nguồn
Scenario	NF-SCN-IRH-001	Giao 240 thùng sữa hạt cho khách CUS-000184; kho còn lô sắp hết hạn	Synthetic case record
Sales Order	SO-20260807-0042	Khách yêu cầu giao ngày 2026-08-08; 240 thùng	Synthetic transaction
Customer	CUS-000184	Công ty TNHH Bách Hóa An Phú	Synthetic master data
Item	FG-NF-ALM-1L	Sữa hạt hạnh nhân 1L, đơn vị tồn THUNG	Synthetic master data
Batch	BAT-ALM-260810-A	Tồn khả dụng 240 thùng; ngày hết hạn 2026-08-10	Synthetic inventory data
Rule	BR-IRH-001	Chỉ cho phép phân bổ lô khi số ngày từ ngày giao yêu cầu đến ngày hết hạn lớn hơn hoặc bằng 5	Project assumption; cần Business Owner và Food Safety Owner xác minh
Exception request	EXR-20260807-0007	Yêu cầu xuất lô có 2 ngày hạn dùng còn lại	Synthetic transaction
Handoff artifact	IRH-PACK-001	Gói sẵn sàng triển khai cho scenario NF-SCN-IRH-001	Synthetic artifact
Controlled references	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY	Nguồn canonical dự kiến cho rule, field và ID; đều IN_REVIEW, v0.9.0	Controlled planning artifacts

Facts. SO-20260807-0042 cần giao ngày 2026-08-08. BAT-ALM-260810-A hết hạn ngày 2026-08-10. Chênh lệch ngày là 2: 2026-08-10 - 2026-08-08 = 2. Rule giả định BR-IRH-001 cần tối thiểu 5 ngày. Bằng chứng dẫn tới kết luận: 2 < 5; lô không đạt điều kiện phân bổ chuẩn.

Current Behavior. Nhân viên kho kiểm tra hạn dùng bằng bảng tính ngoài ERP. Khi thiếu hàng, nhân viên có thể chọn lô bất kỳ còn tồn rồi xác nhận giao. ERP giả định chưa lưu requestedDeliveryDate, chưa tính remainingShelfLifeDays, chưa tạo bản ghi ngoại lệ. Hệ quả quan sát được: quyết định xuất lô không truy vết được về rule, người quyết định, hay lý do.

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

flowchart TB
    P["IRH-PACK-001 v0.9.0<br/>OPT-IRH-003 · IN_REVIEW<br/>Luồng đề xuất, chưa phải production"] --> TH["Business Owner và Food Safety Owner<br/>xác minh ngưỡng 5 ngày"]
    TH --> G1{"Ngưỡng 5 ngày<br/>đã xác minh?"}
    G1 -->|Chưa| R["Giữ IN_REVIEW<br/>không cấu hình hoặc chạy production"]
    G1 -->|Rồi| BP["Business Owner<br/>xác minh policy ngoại lệ"]
    BP --> G2{"Policy ngoại lệ<br/>đã xác minh?"}
    G2 -->|Chưa| R
    G2 -->|Rồi| SA["Solution Architect<br/>xác minh mapping field và validation ERP"]
    SA --> G3{"Mapping và validation<br/>đã xác minh?"}
    G3 -->|Chưa| R
    G3 -->|Rồi| LQ{"Rule được diễn giải thành<br/>nghĩa vụ pháp lý?"}
    LQ -->|Có| LO["Legal Owner và Food Safety Owner<br/>xác minh diễn giải"]
    LO --> G4{"Diễn giải pháp lý<br/>đã xác minh?"}
    G4 -->|Chưa| R
    G4 -->|Rồi| QA["QA Owner<br/>xác minh test basis"]
    LQ -->|Không| QA
    QA --> G5{"Test basis<br/>đã xác minh?"}
    G5 -->|Chưa| R
    G5 -->|Rồi| RDY["Đủ cơ sở trình quyết định<br/>triển khai IRH-PACK-001"]
    RDY --> DEP{"Đã có quyết định triển khai<br/>được ủy quyền?"}
    DEP -->|Chưa| R
    DEP -->|Rồi| PROD["Cho phép cấu hình và chạy<br/>luồng thực thi trong ERP"]

    PROD --> A["Sales Order<br/>SO-20260807-0042"]
    A --> B["Đọc requestedDeliveryDate<br/>2026-08-08"]
    B --> C["Đọc batch BAT-ALM-260810-A<br/>expiryDate 2026-08-10"]
    C --> D{"remainingShelfLifeDays >= 5?"}
    D -->|Có| STD["Cho phép allocation<br/>và shipment chuẩn"]
    D -->|Không: 2 ngày| EX["Tạo exception request<br/>EXR-20260807-0007"]
    EX --> BLK["Chặn allocation và shipment"]
    BLK --> DR{"Quyết định ngoại lệ hợp lệ?<br/>Đúng Business Owner và policy<br/>đúng phạm vi, còn thời hạn"}
    DR -->|Chưa có| WAIT["Duy trì chặn<br/>chờ Business Owner quyết định"]
    WAIT --> DR
    DR -->|Thiếu thẩm quyền hoặc hết hạn| INVALID["Duy trì chặn<br/>quyết định không hợp lệ"]
    DR -->|Hợp lệ| REC["Lưu decision record<br/>người quyết định · lý do<br/>phạm vi · thời hạn"]
    REC --> DG{"Kết quả quyết định<br/>EXR-20260807-0007"}
    DG -->|Từ chối| DENY["Từ chối ngoại lệ<br/>duy trì chặn allocation và shipment"]
    DG -->|Chấp thuận| OPEN["Mở allocation và shipment<br/>theo phạm vi quyết định"]

Underlying Need. Cần kiểm soát phân bổ lô trong ERP, không phải thêm bảng tính. Lý do: ERP phải lưu cùng dữ liệu giao hàng, lô hàng, rule result và ngoại lệ; từ đó QA và vận hành kiểm tra được vì sao shipment bị chặn hoặc được mở. Đây là nhu cầu truy vết thực thi, không phải kết luận pháp lý hay xác nhận tuân thủ an toàn thực phẩm.

Option	Cách làm	Bằng chứng đánh giá	Kết quả
OPT-IRH-001	Giữ bảng tính, kho tự kiểm tra	Không chặn giao trong ERP; không có audit trail tại transaction	Không khuyến nghị
OPT-IRH-002	ERP chặn cứng mọi lô dưới 5 ngày	Chặn được rủi ro; không xử lý trường hợp nghiệp vụ hợp lệ cần ngoại lệ	Khuyến nghị có điều kiện
OPT-IRH-003	ERP chặn mặc định, tạo exception có người quyết định và thời hạn	Chặn mặc định; lưu lý do, phạm vi và quyết định; không tự biến ngoại lệ thành quy tắc	Khuyến nghị

Decision criteria	OPT-IRH-001	OPT-IRH-002	OPT-IRH-003
Chặn allocation không đạt rule	Không	Có	Có
Truy vết người và lý do ngoại lệ	Không	Không áp dụng	Có
Không suy diễn thẩm quyền pháp lý hoặc food safety	Không kiểm soát	Có	Có
Hỗ trợ vận hành khi có ngoại lệ hợp lệ	Có, không kiểm soát	Không	Có

Recommendation. BA khuyến nghị OPT-IRH-003: cấu hình kiểm tra BR-IRH-001; khi remainingShelfLifeDays < 5, ERP tạo EXR-20260807-0007-type record và chặn shipment tới khi có quyết định được ghi nhận. Khuyến nghị này dựa trên bảng tiêu chí, chưa là quyết định được phê duyệt.

Decision. Chưa có quyết định được ủy quyền. IRH-PACK-001 phải ghi trạng thái IN_REVIEW, version v0.9.0, date 2026-08-07; không được ghi APPROVED, BASELINED, hay triển khai production. Business Owner quyết định chính sách ngoại lệ; Food Safety Owner xác minh ngưỡng hạn dùng; Solution Architect xác minh cách cấu hình ERP; QA Owner xác minh test basis. Legal Owner xác minh nếu rule được diễn giải thành nghĩa vụ pháp lý.

Authority.

Nội dung	Vai trò có thẩm quyền	Trạng thái hiện tại
Ngưỡng 5 ngày của BR-IRH-001	Business Owner, Food Safety Owner	Project assumption; Verification required
Cho phép exception EXR-20260807-0007	Business Owner theo policy được xác minh	Chưa có quyết định
Mapping field và validation ERP	Solution Architect	Chưa xác minh
Test case và kết quả test	QA Owner	Chưa xác minh
Diễn giải quy định an toàn thực phẩm	Legal Owner, Food Safety Owner	Verification required

Artifact. Payload dưới là dữ liệu trao đổi mô phỏng cho IRH-PACK-001. Payload không phải OpenAPI contract, không phải cấu hình production.

{
  "artifactId": "IRH-PACK-001",
  "status": "IN_REVIEW",
  "version": "v0.9.0",
  "asOfDate": "2026-08-07",
  "timezone": "Asia/Ho_Chi_Minh",
  "locale": "vi-VN",
  "currency": "VND",
  "scenarioId": "NF-SCN-IRH-001",
  "salesOrderId": "SO-20260807-0042",
  "customerId": "CUS-000184",
  "itemId": "FG-NF-ALM-1L",
  "batchId": "BAT-ALM-260810-A",
  "requestedDeliveryDate": "2026-08-08",
  "expiryDate": "2026-08-10",
  "availableQuantity": 240,
  "uom": "THUNG",
  "businessRuleId": "BR-IRH-001",
  "minimumShelfLifeDays": 5,
  "calculatedRemainingShelfLifeDays": 2,
  "ruleResult": "FAIL",
  "systemAction": "BLOCK_ALLOCATION_AND_SHIPMENT",
  "exceptionRequestId": "EXR-20260807-0007",
  "recommendationId": "OPT-IRH-003",
  "authorizedDecision": null,
  "verificationRequired": [
    "Business Owner",
    "Food Safety Owner",
    "Solution Architect",
    "QA Owner",
    "Legal Owner"
  ],
  "dataClassification": "SYNTHETIC_EDUCATIONAL"
}

Consequence if Wrong. Nếu tính hạn dùng sai, ERP có thể chặn đơn đạt điều kiện hoặc cho xuất lô không đạt ngưỡng giả định. Nếu coi khuyến nghị là quyết định, team có thể cấu hình ERP khi chưa có Business Owner và Food Safety Owner xác minh. Nếu thiếu exception record, QA không thể lập test basis đầy đủ và vận hành không truy vết được ai đã mở chặn.

9. Related Concepts & Dependencies

Core

Dependency là quan hệ phụ thuộc: artifact hiện tại cần đầu vào từ artifact khác để giữ đúng nghĩa, đúng ID và đúng phạm vi. Với handoff pack, không chép lại quy tắc, định nghĩa dữ liệu hay danh mục ID vào pack. Pack chỉ tham chiếu nguồn canonical, tức nguồn chân lý được kiểm soát duy nhất.

Nova Foods là case study mô phỏng; mọi dữ liệu là tổng hợp. IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN và VND phải giữ nhất quán với artifact nguồn. Các giá trị này mô tả trạng thái học liệu, không xác nhận baseline, approval, tuân thủ hay sẵn sàng production.

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

flowchart TB
    SM["00_SOURCE_MAP"]
    CA["01_CURRICULUM_ARCHITECTURE"]
    CM["CHAPTER_MANIFEST"]
    TM["TEMPLATE_MANIFEST"]
    IDR["TRACEABILITY_ID_REGISTRY"]
    BR["CANONICAL_BUSINESS_RULES"]
    DD["CANONICAL_DATA_DICTIONARY"]
    HP["/02-handbook/17-implementation-readiness-and-handoff-pack.md<br/>Handoff pack<br/>Chỉ tham chiếu nguồn; không chép quy tắc, định nghĩa, danh mục ID"]

    SM -->|"safe-use boundary"| HP
    CA -->|"curriculum structure"| HP
    CM -->|"chapter scope / filename"| HP
    TM -->|"template catalog"| HP
    IDR -->|"persistent IDs"| HP
    BR -->|"business rules"| HP
    DD -->|"data definitions"| HP

Applied

Trường	Nội dung
Facts	Pack dùng IRH-PACK-001, NF-SCN-IRH-001, SO-20260807-0042, BR-IRH-001, EXR-20260807-0007 và dữ liệu tổng hợp của Nova Foods.
Current Behavior	Pack ghi giá trị minh họa và tham chiếu ID; không tự tạo bản sao rule, schema dữ liệu, đăng ký ID hay định nghĩa template.
Underlying Need	Người nhận handoff cần lần về đúng nguồn khi kiểm tra nghĩa ID, dữ liệu, rule, trạng thái và phạm vi artifact.
Options	1. Chép toàn bộ nội dung nguồn vào pack. 2. Chỉ ghi ID không nêu nguồn. 3. Ghi ID nguyên dạng, đường dẫn canonical và vai trò nguồn.
Decision Criteria	Không trùng nguồn chân lý; truy vết được; không đổi nghĩa ID; không biến ví dụ thành cấu hình ERP; phù hợp IN_REVIEW.
Decision	Chọn phương án 3. Pack tham chiếu, không sao chép canonical content.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner, Food Safety Owner, Solution Architect, QA Owner, Legal Owner giữ thẩm quyền chuyên môn tương ứng.
Artifact	/02-handbook/17-implementation-readiness-and-handoff-pack.md, section 09-dependencies; artifact liên quan giữ nguyên filename và Artifact ID.
Consequence if Wrong	Bản sao rule có thể lệch nguồn; ID có thể bị dùng sai; team test hoặc cấu hình dựa trên nội dung cũ mà không biết.

Hướng phụ thuộc	Concept hoặc artifact	Vai trò với handoff pack	Cách tham chiếu đúng	Không được làm
Upstream	/00-research/00_SOURCE_MAP.md — 00_SOURCE_MAP	Nêu nguồn chuẩn, URL chính thức và safe-use boundary	Dẫn Artifact ID, filename, version/status khi cần xác minh nguồn	Suy diễn điều khoản pháp lý, kế toán hoặc chuẩn kỹ thuật ngoài boundary
Upstream	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md — 01_CURRICULUM_ARCHITECTURE	Giữ chuỗi học từ requirement đến test basis và handoff	Dùng để kiểm tra pack không đứt traceability curriculum	Biến kiến trúc curriculum thành quyết định ERP
Upstream	/01-curriculum/CHAPTER_MANIFEST.md — CHAPTER_MANIFEST	Giữ chapter title, section, filename và phạm vi canonical	Giữ đúng /02-handbook/17-implementation-readiness-and-handoff-pack.md	Đổi tên file hoặc tự mở rộng phạm vi chapter
Upstream	/01-curriculum/TEMPLATE_MANIFEST.md — TEMPLATE_MANIFEST	Xác định template nào được lập kế hoạch	Tham chiếu template ID khi manifest đã đăng ký	Tạo template ID hoặc nói template đã được phê duyệt
Upstream	/01-curriculum/TRACEABILITY_ID_REGISTRY.md — TRACEABILITY_ID_REGISTRY	Nguồn quản lý persistent ID, tức ID không đổi khi nội dung được sửa có kiểm soát	Giữ nguyên IRH-PACK-001, NF-SCN-IRH-001, BR-IRH-001, EXR-20260807-0007	Đổi format, tái sử dụng hoặc gán nghĩa mới cho ID trong handbook
Upstream	/01-curriculum/CANONICAL_BUSINESS_RULES.md — CANONICAL_BUSINESS_RULES	Nguồn duy nhất của nghĩa và trạng thái business rule	Pack ghi BR-IRH-001 và link về catalog	Chép rule vào pack rồi sửa độc lập
Upstream	/01-curriculum/CANONICAL_DATA_DICTIONARY.md — CANONICAL_DATA_DICTIONARY	Nguồn định nghĩa logic cho salesOrderId, batchId, expiryDate, availableQuantity, uom	Pack dùng field name nguyên dạng và tham chiếu dictionary	Tự đổi kiểu dữ liệu, đơn vị tính hay nghĩa field
Downstream	QA handoff và test basis	Dùng pack làm đầu vào kiểm tra test readiness	QA đọc source canonical khi cần nghĩa rule hoặc field	Xem payload minh họa là API contract hoặc test result
Downstream	Solution design và configuration review	Dùng ID để đối chiếu rule, data và exception	Architect kiểm tra dependency tại nguồn canonical	Cấu hình production từ case study mô phỏng

Senior Lens

Persistent ID không phải nội dung. BR-IRH-001 chỉ là khóa ổn định để tìm đúng rule trong CANONICAL_BUSINESS_RULES; nghĩa rule, owner, trạng thái xác minh và lịch sử thay đổi nằm ở catalog đó. Lý do: cùng một rule có thể đổi câu chữ để rõ hơn, nhưng liên kết từ pack, test và exception phải không đứt.

Một tham chiếu đủ dùng gồm: Artifact ID, filename canonical, persistent ID và mục đích dùng. Ví dụ: BR-IRH-001 được dùng trong IRH-PACK-001 để chỉ rule kiểm tra hạn dùng; nghĩa chính thức phải tra tại /01-curriculum/CANONICAL_BUSINESS_RULES.md. Cầu nối suy luận là: pack cần chứng minh rule nào ảnh hưởng handoff, còn catalog mới có trách nhiệm quản lý nội dung rule.

Nếu artifact nguồn chưa có baseline hoặc approval reference, pack phải giữ nhãn IN_REVIEW. Không được nâng trạng thái bằng cách gọi một link là “đã phê duyệt”. Lý do: liên kết kỹ thuật chứng minh quan hệ phụ thuộc, không chứng minh thẩm quyền quyết định.

Quick Reference

Quy tắc	Áp dụng
Một khái niệm, một nguồn canonical	Rule ở CANONICAL_BUSINESS_RULES; dữ liệu ở CANONICAL_DATA_DICTIONARY; ID ở TRACEABILITY_ID_REGISTRY.
Pack là consumer, không phải registry	Handoff pack tham chiếu ID, không cấp phát hay đổi ID.
Giữ nguyên định danh	Không dịch, rút gọn hoặc sửa IRH-PACK-001, BR-IRH-001, NF-SCN-IRH-001, EXR-20260807-0007.
Giữ nguyên boundary	Payload mô phỏng không là OpenAPI contract, cấu hình ERP hay bằng chứng production.
Kiểm tra trước khi handoff	Xác nhận filename, Artifact ID, status, version, ngày và nguồn canonical còn khớp.

Core

Ma trận truy vết liên kết nhu cầu với bằng chứng kiểm thử. NEED là nhu cầu gốc; REQ là yêu cầu; BR là quy tắc nghiệp vụ; AC là tiêu chí chấp nhận; DATA/API là hợp đồng dữ liệu hoặc giao diện lập trình ứng dụng; TC là ca kiểm thử. ID chỉ hợp lệ khi đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; bảng dưới dùng dữ liệu tổng hợp Nova Foods, không tạo nguồn chân lý mới.

Loại	ID minh họa	Liên kết trực tiếp	Mục đích kiểm soát	Nguồn canonical
NEED	NEED-NF-001	REQ-NF-001	Nêu nhu cầu truy vết lô thành phẩm mô phỏng	Registry ID
REQ	REQ-NF-001	NEED-NF-001, BR-NF-001, AC-NF-001	Mô tả hành vi ERP cần có	Requirement artifact được kiểm soát
BR	BR-NF-001	REQ-NF-001, DATA-NF-001	Giữ điều kiện nghiệp vụ về mã lô	/01-curriculum/CANONICAL_BUSINESS_RULES.md
AC	AC-NF-001	REQ-NF-001, TC-NF-001	Xác định điều kiện đạt theo góc nhìn người nhận bàn giao	Requirement artifact được kiểm soát
DATA/API	DATA-NF-001	BR-NF-001, TC-NF-001	Xác định trường batchCode và kiểm tra giao tiếp	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
TC	TC-NF-001	AC-NF-001, DATA-NF-001	Chứng minh yêu cầu đạt hoặc thất bại	Test artifact được kiểm soát

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

flowchart LR
    NEED["NEED-NF-001<br/>Truy vết lô"] --> REQ["REQ-NF-001<br/>Tra cứu lô"]
    REQ --> BR["BR-NF-001<br/>Mã lô bắt buộc"]
    REQ --> AC["AC-NF-001<br/>Hiển thị kết quả"]
    BR --> DATA["DATA-NF-001<br/>batchCode"]
    AC --> TC["TC-NF-001<br/>Kiểm thử tra cứu"]
    DATA --> TC

Applied

Facts: Nova Foods là case mô phỏng; dữ liệu tổng hợp có lô NF-FG-260807-01. Current Behavior: màn hình tra cứu thành phẩm nhận batchCode nhưng đặc tả API chưa chỉ rõ phản hồi khi mã lô không tồn tại. Underlying Need: người dùng mô phỏng cần phân biệt “không có dữ liệu” với lỗi giao tiếp để không xử lý nhầm lô. Options: trả HTTP 404; trả HTTP 200 với danh sách rỗng; không ghi hành vi. Decision Criteria: liên kết được từ NEED đến TC, nhất quán giữa AC và API, không suy diễn quy định pháp lý hay cấu hình production. Decision: ghi hành vi đã chọn vào REQ-NF-001, AC-NF-001, DATA-NF-001 và TC-NF-001 cùng đợt thay đổi; không chốt mã trạng thái nếu source canonical chưa nêu. Authority: Business Owner xác nhận nhu cầu; Architect xác nhận hợp đồng API; QA xác nhận khả năng kiểm thử. Artifact: mỗi artifact giữ nội dung riêng, bảng chỉ giữ ID và quan hệ. Consequence if Wrong: TC có thể kiểm tra phản hồi khác AC, đội tích hợp xử lý sai “không tìm thấy”, bàn giao không chứng minh được REQ đã được kiểm thử.

Senior Lens

Không dùng một ID thay cho nhiều cấp. NEED-NF-001 không phải REQ-NF-001: NEED giải thích vì sao cần thay đổi, REQ nói hệ thống phải làm gì. BR-NF-001 không phải AC: BR áp dụng ổn định cho nghiệp vụ, AC đo kết quả chấp nhận của một yêu cầu. DATA-NF-001 không thay API contract: từ điển dữ liệu định nghĩa nghĩa trường logic; đặc tả API định nghĩa đường truyền, request và response. Khi chưa có đặc tả API canonical, cột DATA/API phải ghi đúng artifact đang kiểm soát, không biến bảng truy vết thành đặc tả thay thế.

Thay đổi im lặng ở BR-NF-001 làm REQ-NF-001 có thể còn đúng câu chữ nhưng sai hành vi; AC-NF-001 và TC-NF-001 sẽ kiểm thử quy tắc cũ. Thay đổi im lặng ở DATA-NF-001 có thể làm API gửi trường sai kiểu hoặc sai ràng buộc. Dấu hiệu tối thiểu: một ID nguồn đổi version nhưng liên kết đích không có bản ghi đánh giá tác động. Khi gặp dấu hiệu này, dừng bàn giao phần bị ảnh hưởng, mở đánh giá tác động theo registry, rồi cập nhật hoặc kết luận không ảnh hưởng có bằng chứng.

Quick Reference

Kiểm tra trước bàn giao	Đạt khi
NEED đến REQ	Mỗi REQ có ít nhất một NEED hoặc ghi rõ không áp dụng
REQ đến BR và AC	Quy tắc áp dụng và điều kiện chấp nhận đều có ID riêng
AC đến TC	Mỗi AC có ít nhất một TC kiểm tra kết quả
DATA/API đến TC	TC kiểm tra trường, kiểu, ràng buộc hoặc phản hồi liên quan
Nguồn ID	ID tra được tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md
Trạng thái	Mọi liên kết thuộc corpus IN_REVIEW, v0.9.0, ngày 2026-08-07; không diễn giải là baseline hoặc phê duyệt

Core

Lan truyền thay đổi là việc một thay đổi ở nguồn phụ thuộc làm thay đổi ý nghĩa, tính đúng đắn hoặc khả năng kiểm chứng của artifact dùng nguồn đó. Nguồn canonical là nơi duy nhất sở hữu nội dung gốc; artifact khác chỉ giữ liên kết, không sao chép quy tắc, định nghĩa dữ liệu hay định danh. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline hay phê duyệt.

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

flowchart TB
    A["CANONICAL_BUSINESS_RULES<br/>đổi điều kiện chặn giao dịch"]
    B["Không rà soát hoặc cập nhật<br/>artifact hạ nguồn"]
    C["Acceptance criteria<br/>giữ điều kiện cũ"]
    D["Test case<br/>giữ điều kiện cũ"]
    E["Đội phát triển<br/>làm theo criteria cũ"]
    F["QA<br/>xác nhận triển khai bằng test cũ"]
    G["Bằng chứng kiểm tra<br/>không còn đúng"]
    H["Sai lệch không phát hiện"]
    I["Handoff pack<br/>báo sẵn sàng dựa trên bằng chứng sai"]

    A -. "thay đổi im lặng" .-> B
    B --> C
    B --> D
    C --> E
    E --> F
    D --> F
    F --> G
    G --> H
    H --> I

Thay đổi im lặng nguy hiểm vì liên kết vẫn tồn tại nhưng nghĩa đã lệch. Ví dụ, catalog quy tắc đổi điều kiện chặn giao dịch, còn acceptance criteria và test case giữ điều kiện cũ. Đội phát triển có thể làm đúng tài liệu cũ, QA có thể xác nhận đúng test cũ, nhưng handoff pack báo “sẵn sàng” dựa trên bằng chứng không còn đúng.

Applied

Trường	Nội dung
Facts	CANONICAL_DATA_DICTIONARY đổi định nghĩa logic một trường dùng trong payload API mô phỏng của Nova Foods. Artifact phụ thuộc vẫn tham chiếu đúng tên trường nhưng chưa được rà soát lại.
Current Behavior	Requirement, acceptance criteria, API contract và test case tiếp tục dùng diễn giải cũ. Không có bản ghi thay đổi liên kết các artifact bị ảnh hưởng.
Underlying Need	Bảo đảm mỗi thay đổi canonical tạo danh sách tác động và trạng thái xử lý trước khi handoff dùng bằng chứng đó.
Options	1. Sửa im lặng các artifact phụ thuộc. 2. Ghi thay đổi tại nguồn canonical, đánh dấu artifact phụ thuộc cần rà soát, rồi cập nhật từng artifact có lịch sử.
Decision Criteria	Giữ nguồn chân lý duy nhất; truy được lý do thay đổi; không ngầm tạo approval; QA phân biệt được test basis cũ và mới.
Decision	Chọn phương án 2. Chỉ nguồn canonical đổi nội dung gốc. Artifact phụ thuộc ghi tham chiếu và trạng thái tác động, không chép lại định nghĩa.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance xác nhận phần thuộc thẩm quyền của họ khi thay đổi chạm phạm vi đó.
Artifact	Nguồn: /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Kiểm tra ID và liên kết tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Gói handoff cập nhật tại /02-handbook/17-implementation-readiness-and-handoff-pack.md.
Consequence if Wrong	API gửi dữ liệu không còn phù hợp định nghĩa; mapping lỗi; test pass giả; báo cáo hoặc giao dịch mô phỏng dùng dữ liệu sai nghĩa. Nếu liên quan dữ liệu cá nhân, kế toán, an toàn thực phẩm hoặc hóa đơn, phải gắn Verification required và chuyển đúng owner, không tự suy diễn nghĩa vụ.

Senior Lens

Dấu hiệu thay đổi cần đánh giá tác động gồm: đổi định nghĩa, kiểu dữ liệu, giá trị cho phép, điều kiện quy tắc, quyền truy cập, mã lỗi API, tiêu chí chấp nhận, hoặc phạm vi test. Lý do: mỗi mục này có thể đổi kết quả hệ thống dù tên ID không đổi.

Không được dùng việc “không có lỗi build” làm bằng chứng không có tác động. Build chỉ kiểm tra cấu trúc kỹ thuật; không chứng minh business rule, data meaning và acceptance criteria còn đồng nhất. Khi nguồn canonical thay đổi, trạng thái đúng của artifact phụ thuộc là “cần rà soát” cho đến khi có bằng chứng cập nhật; không tự gọi là đã phê duyệt.

Quick Reference

Thay đổi im lặng tại	Điều có thể vỡ	Kiểm soát tối thiểu
CANONICAL_BUSINESS_RULES	Requirement, acceptance criteria, test expected result lệch quy tắc	Ghi tác động, rà soát test basis và cập nhật lịch sử thay đổi
CANONICAL_DATA_DICTIONARY	Mapping, validation, API payload, báo cáo lệch nghĩa dữ liệu	Rà soát field mapping, contract và dữ liệu test tổng hợp
TRACEABILITY_ID_REGISTRY	Liên kết trỏ sai hoặc mất truy vết	Không tái sử dụng ID; kiểm tra liên kết trước handoff
Source classification hoặc nguồn pháp lý	Requirement diễn giải quá thẩm quyền hoặc dựa giả định cũ	Giữ nhãn Verification required; chuyển Legal/Compliance owner khi phù hợp
API contract	Consumer gửi hoặc nhận payload không tương thích	Version hóa contract, rà soát lỗi HTTP và test tích hợp

10. Common Mistakes & Anti-patterns

Core

Sai lầm triển khai thường không bắt đầu từ lỗi lập trình. Nó bắt đầu khi BA hoặc delivery team chuyển đầu vào chưa đủ thành quyết định có vẻ chắc chắn. “Red flag” là dấu hiệu quan sát được cho thấy artifact chưa sẵn sàng handoff.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Ghi requirement bằng mục tiêu mơ hồ	Câu như “hệ thống xử lý nhanh”, “duyệt đúng”, không có điều kiện và kết quả đo được	Nhầm business objective với requirement có thể xây và kiểm thử	Tách mục tiêu, điều kiện kích hoạt, dữ liệu đầu vào, kết quả, ngoại lệ và acceptance criteria
Handoff khi rule chưa đủ	Developer hỏi liên tục về trạng thái, trường bắt buộc, điều kiện chặn	BA chỉ ghi happy path, bỏ luồng lỗi và dữ liệu thiếu	Rà soát từng trạng thái, lỗi validation, quyền thao tác, dữ liệu biên và kết quả mong đợi
Dùng ví dụ tổng hợp như rule	Một con số hoặc mã mẫu bị đưa thẳng vào cấu hình	Không phân biệt dữ liệu minh họa với quyết định nghiệp vụ	Gắn nhãn project assumption cho dữ liệu giả định; chuyển Business Owner xác nhận quyết định vận hành
Handoff không có test basis	QA chỉ có user story hoặc ảnh màn hình	Acceptance criteria không liên kết requirement, rule và dữ liệu test	Bổ sung liên kết requirement, business rule, expected result và dữ liệu test tổng hợp
Sửa artifact nhưng không báo phần phụ thuộc	Mapping API, test case, báo cáo dùng giá trị cũ	Không đánh giá tác động trước khi đổi	Ghi thay đổi, xác định artifact phụ thuộc, rà soát rồi mới handoff lại

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

flowchart TB
    A[Phát hiện red flag] --> B[Xác định artifact gốc bị lỗi]
    B --> C[Đối chiếu requirement, rule, data và acceptance criteria]
    C --> D{Đủ thông tin để sửa?}
    D -- Không --> E[Ghi câu hỏi theo loại thông tin thiếu; gắn nhãn project assumption cho dữ liệu chưa xác nhận]
    E --> F[Đúng owner xác nhận thông tin; Business Owner xác nhận quyết định nghiệp vụ]
    F --> C
    D -- Có --> G[Cập nhật artifact và liên kết]
    G --> H[Ghi thay đổi]
    H --> I[Xác định artifact phụ thuộc]
    I --> J[Rà soát tác động]
    J --> K[QA và delivery rà soát handoff]

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp.

Thành phần	Nội dung
Facts	Requirement REQ-SO-014 mô tả: “ERP chặn đơn bán khi khách hàng vượt hạn mức tín dụng.” Handoff gồm màn hình đơn bán nhưng không nêu thời điểm kiểm tra, cách tính số dư, hay xử lý đơn đang chờ duyệt.
Current Behavior	Developer có thể chặn mọi đơn ngay khi nhập. QA có thể mong đợi chặn chỉ lúc xác nhận đơn. Hai cách cho kết quả khác nhau.
Underlying Need	Cần bảo vệ kiểm soát tín dụng mà vẫn cho phép nhân viên bán hàng nhập nháp đơn hợp lệ.
Options	(1) Kiểm tra khi lưu nháp. (2) Kiểm tra khi xác nhận đơn. (3) Kiểm tra ở cả hai thời điểm.
Decision Criteria	Xác định điểm nào tạo cam kết nghiệp vụ, dữ liệu công nợ nào được tính, người nào được phép xử lý ngoại lệ, và test nào chứng minh kết quả.
Decision	Không tự chọn phương án. Cập nhật artifact để ghi ba phương án, dữ liệu cần xác nhận và câu hỏi cho Business Owner.
Authority	Business Owner quyết định chính sách tín dụng mô phỏng; BA duy trì requirement và traceability. Tại IN_REVIEW, không có approval hay baseline.
Artifact	Cập nhật REQ-SO-014, liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY nếu các ID đã tồn tại trong artifact canonical.
Consequence if Wrong	Chặn quá sớm làm mất khả năng nhập nháp; chặn quá muộn tạo đơn không thỏa kiểm soát tín dụng. QA không có expected result duy nhất để kiểm thử.

Senior Lens

Phục hồi an toàn nghĩa là sửa phần thiếu mà không tự bịa rule. Với REQ-SO-014, BA có thể ghi nhận điểm chưa xác định và giữ trạng thái IN_REVIEW; không được đổi thành “đã chấp thuận” chỉ vì developer cần câu trả lời. Bằng chứng là metadata corpus xác định IN_REVIEW không phải BASELINED hoặc approval.

[!WARNING] Không cho phép release dựa trên acceptance criteria thiếu trạng thái, điều kiện chặn hoặc expected result. Rủi ro là hệ thống và QA cùng làm đúng theo hai cách khác nhau. Recovery boundary: dừng handoff phần bị ảnh hưởng, giữ dữ liệu tổng hợp, làm rõ với đúng owner, rồi cập nhật liên kết trước khi tiếp tục.

Quick Reference

Kiểm tra trước handoff	Đạt khi
Requirement có thể xây	Có trigger, input, xử lý, output, ngoại lệ và tiêu chí chấp nhận
Delivery hiểu giống QA	Cùng một expected result cho từng điều kiện quan trọng
Dữ liệu minh họa an toàn	Chỉ dùng dữ liệu tổng hợp Nova Foods, không biến ví dụ thành policy
Artifact còn nhất quán	Requirement, rule, data, API hoặc test basis liên kết được bằng ID canonical
Quyết định đúng thẩm quyền	BA ghi nhận và điều phối; owner có thẩm quyền quyết định nội dung thuộc phạm vi mình

Core

[!WARNING] Rủi ro thật: đưa gói handoff có lỗi chặn triển khai vào môi trường production có thể làm sai tồn kho, chứng từ, quyền truy cập hoặc khả năng truy vết. Nova Foods là case mô phỏng; dữ liệu bên dưới là dữ liệu tổng hợp, không xác nhận cấu hình ERP thực tế.

Cảnh báo chỉ dùng khi lỗi có hậu quả vận hành, tài chính, bảo mật hoặc tuân thủ. Không gắn cảnh báo cho lỗi trình bày nhỏ. Mỗi cảnh báo phải nêu điều kiện dừng, bằng chứng cần kiểm và ranh giới phục hồi an toàn.

Tình huống lỗi Nova Foods mô phỏng	Dấu hiệu quan sát được	Rủi ro thật	Hành động an toàn	Ranh giới phục hồi
File mapping đơn vị tính ghi kg cho nguyên liệu nhưng giao diện nhập theo g	Kịch bản UAT cho số lượng 1.000 nhưng kết quả tồn kho lệch 1.000 lần	Sai tồn kho, sai giá vốn, có thể phát hành lệnh sản xuất sai	Dừng import master data; cô lập file mapping; đối chiếu mẫu dữ liệu tổng hợp với Data Owner	Chỉ nạp lại sau khi mapping, dữ liệu thử và kết quả đối soát được ghi nhận trong artifact kiểm soát
Tài khoản kiểm thử có quyền duyệt và quyền tạo nhà cung cấp	Cùng một user tạo, sửa, duyệt bản ghi trong demo	Rủi ro phân quyền xung đột, không chứng minh được kiểm soát truy cập	Không tái sử dụng tài khoản đó cho production; yêu cầu Security và Business Owner xác định ma trận quyền	BA chỉ ghi nhận khoảng trống và liên kết bằng chứng; không tự cấp hoặc thu hồi quyền
API handoff mô tả endpoint nhưng không có mã lỗi cho đơn hàng trùng	Consumer không biết xử lý khi nhận HTTP 409 hoặc lỗi tương đương	Tạo đơn lặp, sai doanh thu hoặc mất dữ liệu giao dịch	Chặn tích hợp tự động; chạy lại bằng dữ liệu tổng hợp trong môi trường không production	Chỉ mở lại luồng khi Architect và QA xác nhận cách xử lý lỗi, idempotency và test evidence
Tài liệu gọi yêu cầu “đã tuân thủ luật dữ liệu cá nhân” nhưng không có kết luận Legal Owner	Không có nguồn, phạm vi dữ liệu, quyết định hoặc người có thẩm quyền	Tuyên bố tuân thủ không được hỗ trợ, dẫn đến quyết định triển khai sai	Gỡ tuyên bố; gắn Verification required; chuyển Legal Owner xem xét	Không diễn giải Luật 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP thành cấu hình bắt buộc khi chưa có xác minh

Applied

Facts: Gói handoff mô phỏng Nova Foods chứa /01-curriculum/CANONICAL_DATA_DICTIONARY.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. File import dữ liệu tổng hợp có trường quantity_uom = kg, nhưng kịch bản kiểm thử nhập số lượng theo g.

Current Behavior: Nhóm delivery định nạp file vì đã chạy được một lần trên môi trường demo. Bằng chứng chỉ cho thấy tiến trình import hoàn tất; không chứng minh số lượng sau quy đổi đúng.

Underlying Need: Cần chứng minh dữ liệu được hiểu nhất quán trước khi dùng làm đầu vào triển khai. “Import thành công” chỉ xác nhận kỹ thuật nhận file; không xác nhận ý nghĩa nghiệp vụ.

Options: (1) Nạp tiếp và sửa chênh lệch sau. (2) Dừng nạp, đối soát một mẫu nguyên liệu tổng hợp, sửa mapping rồi kiểm thử lại. (3) Tự đổi đơn vị trong file mà không ghi nhận thay đổi.

Decision Criteria: Chọn phương án không làm phát sinh dữ liệu sai, giữ được dấu vết thay đổi, không vượt thẩm quyền BA, và tạo bằng chứng QA có thể kiểm lại.

Decision: Chọn phương án (2). Không dùng cảnh báo để kết luận lỗi đã được sửa; cảnh báo chỉ giữ trạng thái dừng cho đến khi có bằng chứng đối soát.

Authority: Data Owner xác nhận nghĩa đơn vị tính; Architect xác nhận cơ chế quy đổi; QA xác nhận kết quả kiểm thử. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận vấn đề và giữ traceability.

Artifact: Ghi liên kết tới CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY, file mapping đang xem xét, kết quả test dữ liệu tổng hợp và quyết định của vai trò có thẩm quyền. Không gọi các artifact IN_REVIEW là baseline hay approved.

Consequence if Wrong: Nếu bỏ qua, 250 kg nguyên liệu tổng hợp có thể bị hiểu thành 250.000 g hoặc ngược lại. Lỗi lan sang tồn kho, kế hoạch sản xuất và báo cáo chi phí trước khi người dùng nhận ra.

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

flowchart TB
    A[Phát hiện chênh lệch đơn vị tính] --> B{Có thể ảnh hưởng số lượng hoặc giá trị?}

    B -- Không --> I[Ghi nhận để xử lý riêng<br/>Không kích hoạt cảnh báo dừng]

    B -- Có --> P[Principal IT Business Analyst / Technical Curriculum Author<br/>ghi nhận vấn đề và duy trì traceability]
    P --> C{Đánh giá phương án theo tiêu chí quyết định}

    C -- Tiếp tục import --> R[Loại bỏ phương án<br/>Nguy cơ 250 kg bị hiểu thành 250.000 g hoặc ngược lại<br/>Sai tồn kho, kế hoạch sản xuất và báo cáo chi phí]

    C -- Tự đổi đơn vị trong file --> S[Loại bỏ phương án<br/>Không có dấu vết thay đổi<br/>Vượt thẩm quyền BA]

    C -- Dừng và đối soát --> D[Dừng import và cô lập file<br/>Cảnh báo chỉ giữ trạng thái dừng]
    D --> E[Đối soát mẫu nguyên liệu tổng hợp]
    E --> F[Data Owner xác nhận nghĩa đơn vị tính]
    F --> G[Architect xác nhận cơ chế quy đổi]
    G --> H[Sửa mapping theo xác nhận của Data Owner và Architect<br/>Ghi nhận thay đổi]
    H --> J[QA chạy lại kiểm thử dữ liệu tổng hợp]
    J --> K{Đủ xác nhận và bằng chứng?<br/>Data Owner: nghĩa đơn vị<br/>Architect: cơ chế quy đổi<br/>QA: kết quả kiểm thử}

    K -- Không --> D
    K -- Có --> L[Principal IT Business Analyst / Technical Curriculum Author<br/>ghi liên kết và duy trì traceability]
    L --> N[Liên kết CANONICAL_DATA_DICTIONARY,<br/>TRACEABILITY_ID_REGISTRY, mapping, kết quả kiểm thử<br/>và quyết định của vai trò có thẩm quyền]
    N --> O[Artifact ở trạng thái IN_REVIEW<br/>Không gọi là baseline hoặc approved]
    O --> M[Tiếp tục handoff có kiểm soát]

Senior Lens

Ranh giới phục hồi là điểm ngăn nhóm “sửa nhanh” làm mất bằng chứng. Với dữ liệu, không sửa trực tiếp bản import đã lỗi rồi tuyên bố sạch; giữ bản lỗi, tạo bản sửa có định danh phiên bản, ghi lý do thay đổi và kiểm lại. Với quyền truy cập, không dùng tài khoản đặc quyền để chứng minh quy trình phân quyền; cần ma trận quyền và xác nhận Security. Với quy định pháp lý, không biến URL nguồn thành kết luận triển khai; nguồn chính thức là bằng chứng cần xem xét, không thay Legal Owner quyết định.

Quick Reference

Quy tắc	Áp dụng
Dùng warning khi có khả năng gây thiệt hại hoặc chặn triển khai an toàn	Sai dữ liệu, phân quyền, tích hợp, tuyên bố tuân thủ
Mỗi warning phải có điểm dừng	Không tiếp tục import, release hoặc cấp quyền khi chưa có bằng chứng
Phục hồi phải giữ traceability	Giữ file lỗi, file sửa, kết quả test và vai trò xác nhận
IN_REVIEW không phải approval	Không tuyên bố Nova Foods đã baseline, approved, compliant hoặc production-ready

Core

Năm lỗi phải tách riêng vì mỗi lỗi hỏng một loại kiểm soát khác nhau. Mơ hồ là câu có nhiều cách hiểu hợp lý. Thiếu hoàn chỉnh là thiếu dữ kiện để xây, kiểm thử hoặc bàn giao. Khẳng định thẩm quyền không có chứng cứ là gán quyết định cho người, nguồn hoặc trạng thái chưa xác nhận. Dùng sai ký pháp là gọi sai loại sơ đồ hoặc dùng ký hiệu không đúng ngữ nghĩa chuẩn. Đứt truy vết là không nối được yêu cầu với nguồn, quy tắc, dữ liệu, quyết định hoặc kiểm thử.

Loại lỗi	Red flag quan sát được	Vì sao lỗi	Sửa đúng
Mơ hồ	“Hệ thống xử lý nhanh”, “duyệt khi cần”	Không có điều kiện đo được	Viết chủ thể, sự kiện, điều kiện, kết quả, ngoại lệ
Thiếu hoàn chỉnh	Có luồng chính nhưng không có lỗi, quyền, dữ liệu đầu vào	Delivery team tự lấp khoảng trống	Ghi rõ khoảng trống là Verification required hoặc project assumption
Khẳng định thẩm quyền không có chứng cứ	“Đã được duyệt”, “theo luật”, “Finance yêu cầu” nhưng không có artifact tham chiếu	Biến ghi chú thành quyết định	Nêu vai trò cần xác nhận; không ghi approval khi chưa có approval reference
Dùng sai ký pháp	Sơ đồ PlantUML activity được gọi BPMN	Người đọc suy luận sai trách nhiệm, event, gateway	Gọi đúng tên sơ đồ; chỉ gọi BPMN khi dùng BPMN 2.0.2 theo OMG
Đứt truy vết	Rule trong tài liệu không có nguồn canonical hoặc ID	Không xác định được ai sửa, ai kiểm thử	Liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi ID đã được đăng ký

Applied

Facts: Nova Foods là case mô phỏng giáo dục, dữ liệu tổng hợp. Ghi chú bàn giao viết: “Đơn bán vượt hạn mức tín dụng phải được Finance duyệt nhanh theo luật.”

Current Behavior: Dev hiểu mọi đơn vượt hạn mức bị chặn. QA không có ngưỡng, vai trò duyệt, thời hạn phản hồi, trạng thái đơn, nguồn luật hoặc test basis.

Underlying Need: Cần tách nhu cầu kiểm soát tín dụng khỏi giả định về quy tắc tài chính và thẩm quyền phê duyệt.

Options: Giữ nguyên câu; tự đặt ngưỡng VND và người duyệt; hoặc ghi nhu cầu cùng các điểm cần xác minh.

Decision Criteria: Câu chỉ đủ dùng khi có điều kiện kích hoạt, dữ liệu so sánh, kết quả hệ thống, vai trò có thẩm quyền, nguồn canonical và liên kết kiểm thử.

Decision: Thay bằng: “Khi giá trị phơi nhiễm tín dụng của khách hàng vượt ngưỡng được Business Owner và Accounting Owner xác nhận, ERP phải đặt đơn ở trạng thái chờ quyết định theo quyền được xác nhận. Ngưỡng, cách tính và người quyết định: Verification required.” Câu này không tạo rule vận hành.

Authority: Business Owner xác nhận nhu cầu nghiệp vụ. Accounting Owner xác nhận cách tính và kiểm soát kế toán. Legal Owner xác nhận nếu có diễn giải pháp luật. Principal IT Business Analyst / Technical Curriculum Author chỉ giữ traceability.

Artifact: Ghi nguồn và trạng thái trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; định danh chỉ dùng sau khi có trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Dữ liệu “phơi nhiễm tín dụng” chỉ mô tả logic sau khi được khai báo trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Consequence if Wrong: Chặn sai đơn làm mất doanh thu mô phỏng; cho qua sai đơn tạo rủi ro công nợ mô phỏng; quan trọng hơn, corpus ghi nhầm giả định thành quyết định có thẩm quyền.

Cảnh báo: Không dùng cụm “theo luật” để ép rule ERP khi chưa có Legal Owner xác nhận đối chiếu nguồn chính thức hiện hành. Nguồn pháp lý trong corpus chỉ đặt bối cảnh; không tự tạo nghĩa vụ cấu hình.

Senior Lens

Không sửa mơ hồ bằng cách tự đoán. Sửa bằng câu hỏi đóng có bằng chứng: ai quyết định, quyết định cái gì, dựa trên dữ liệu nào, tại thời điểm nào, kết quả nào, ngoại lệ nào. Không sửa thiếu hoàn chỉnh bằng thêm chi tiết tưởng tượng. Gắn Verification required giữ khoảng trống nhìn thấy được, rồi chuyển đúng owner.

Kiểm tra ký pháp trước khi kiểm tra nội dung. BPMN là chuẩn ký pháp quy trình của OMG; UML activity diagram và PlantUML activity diagram không tự thành BPMN. Một sơ đồ có swimlane nhưng không có BPMN event, gateway và semantics đúng vẫn không được gắn nhãn BPMN. Tên đúng bảo vệ người đọc khỏi suy luận sai về trigger, nhánh và trách nhiệm.

Truy vết không phải danh sách link trang trí. Mỗi claim có tác động delivery phải trả lời được: nguồn nào nói gì, artifact canonical nào giữ nội dung, ID nào định danh, ai có thẩm quyền xác nhận, test nào chứng minh. Thiếu một mắt xích thì claim chưa đủ điều kiện thành đầu vào triển khai.

Quick Reference

Kiểm tra trước handoff	Đạt khi	Không đạt khi
Mơ hồ	Một người đọc xác định được điều kiện và kết quả	Có từ “nhanh”, “phù hợp”, “khi cần” không định nghĩa
Hoàn chỉnh	Có luồng lỗi, quyền, dữ liệu, ngoại lệ cần thiết	Team phải tự chọn hành vi
Thẩm quyền	Có vai trò, nguồn và trạng thái ghi nhận đúng	Gọi IN_REVIEW là approved hoặc baselined
Ký pháp	Tên sơ đồ khớp chuẩn và ngữ nghĩa dùng	Gọi PlantUML là BPMN
Truy vết	Claim nối tới artifact canonical và ID đã đăng ký	ID tự tạo, link chết, hoặc không có nguồn

11. Senior BA Notes & Rules of Thumb

Senior Lens

Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Senior BA không chọn phương án “đẹp nhất”; chọn phương án có bằng chứng đủ mạnh, đúng thẩm quyền, và rủi ro còn lại được ghi rõ. Trade-off là đánh đổi: ví dụ kiểm soát lô chặt hơn tăng khả năng truy vết nhưng có thể tăng thao tác kho và thời gian xuất hàng. Suy luận chỉ hợp lệ khi nối được từ fact quan sát, tác động nghiệp vụ, tiêu chí quyết định, đến owner có quyền quyết.

Điểm xem xét	Câu hỏi senior	Bằng chứng cần có	Không tự quyết khi
Trade-off	Lợi ích nào đổi lấy chi phí, thời gian, rủi ro nào?	Quy trình hiện tại, dữ liệu khối lượng mô phỏng, lỗi đã ghi nhận	Ảnh hưởng ngân sách, kiến trúc, kiểm soát kế toán
Ngoại lệ	Quy tắc thường có còn áp dụng khi hàng bị thu hồi, đơn gấp, hệ thống lỗi?	Kịch bản ngoại lệ, owner vận hành, tác động audit	Ngoại lệ làm yếu kiểm soát pháp lý, an toàn thực phẩm, bảo mật
Xung đột stakeholder	Ai chịu hậu quả nếu chọn sai?	Nhu cầu từng vai trò, tiêu chí đo được, quyết định còn mở	Hai bên đòi kết quả trái nhau mà không có owner phân xử
Chất lượng bằng chứng	Đây là fact, assumption hay ý kiến?	Nguồn ngày tháng, artifact canonical, phạm vi dữ liệu	Nguồn truyền miệng, ảnh chụp không rõ ngữ cảnh, dữ liệu không truy xuất được
Thẩm quyền quyết định	Ai có quyền chấp nhận rủi ro?	Vai trò được ghi trong artifact kiểm soát	BA bị yêu cầu xác nhận pháp lý, kế toán, bảo mật, production

Ví dụ xung đột: Trưởng kho muốn cho phép xuất hàng khi thiếu mã lô để tránh chậm giao; QA muốn chặn tuyệt đối để giữ truy vết. Fact là yêu cầu xuất hàng có thể xảy ra khi dữ liệu lô thiếu, nhưng chưa có bằng chứng rằng cho phép xuất vẫn đáp ứng kiểm soát cần thiết. Nhu cầu gốc của kho là giảm chậm trễ, không phải mặc định bỏ kiểm soát. Senior BA ghi hai option: chặn xuất cho đến khi bổ sung mã lô; hoặc cho phép ngoại lệ có phê duyệt và nhật ký. Quyết định không thuộc BA nếu ảnh hưởng an toàn thực phẩm, compliance, quyền override hay thiết kế ERP. Gắn Verification required, chuyển Business Owner, QA Owner, Architect và legal/compliance owner khi phù hợp.

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

flowchart TB
    A["Bằng chứng hoặc thông tin từ artifact / dữ liệu mô phỏng"] --> B{"Nguồn truy xuất được<br/>và đủ ngữ cảnh?"}

    B -- "Không" --> C["Ghi Verification required<br/>và khoảng trống bằng chứng"]
    C --> D["Chuyển owner phù hợp theo loại quyết định"]
    D --> E["Trạng thái: chờ xác minh hoặc quyết định"]

    B -- "Có" --> F{"Liên quan pháp lý, kế toán,<br/>bảo mật, production, an toàn thực phẩm<br/>hoặc compliance?"}
    F -- "Có" --> G["Ghi Verification required"]
    G --> H["Chuyển Legal, Accounting, Security, QA,<br/>Compliance hoặc owner production phù hợp xác minh"]
    H --> I["Trạng thái: chờ xác minh chuyên môn"]
    I --> J{"Đã có bằng chứng<br/>được owner phù hợp xác minh?"}
    J -- "Không" --> E
    J -- "Có" --> K["BA đánh giá trong ranh giới<br/>bằng chứng đã xác minh"]
    F -- "Không" --> K

    K --> L["Phân loại fact, assumption, inference"]
    L --> M["Ghi khoảng trống bằng chứng<br/>và mức chắc chắn"]
    M --> N["Đánh giá tác động nghiệp vụ, trade-off,<br/>ngoại lệ và rủi ro còn lại"]
    N --> O["So sánh option theo tiêu chí quyết định"]
    O --> P["BA lập recommendation:<br/>nguồn, tiêu chí, khoảng trống,<br/>mức chắc chắn, rủi ro còn lại"]
    P --> Q{"Cần owner chấp nhận rủi ro<br/>hoặc quyết định?"}

    Q -- "Không" --> R["Ghi recommendation và traceability;<br/>không ghi approved"]
    Q -- "Có" --> S["Chuyển Business Owner, Architect, QA,<br/>Legal, Accounting, Security, Compliance<br/>hoặc owner production theo thẩm quyền"]
    S --> T["Trạng thái: chờ owner quyết định"]
    T --> U{"Owner có thẩm quyền<br/>chấp nhận rủi ro?"}
    U -- "Không hoặc chưa quyết định" --> V["Ghi từ chối hoặc đang chờ;<br/>giữ trạng thái chưa approved"]
    U -- "Có" --> W["Ghi nhận chấp nhận rủi ro<br/>và traceability"]
    W --> X{"Cần baseline hoặc cấu hình?"}
    X -- "Không" --> Y["Kết thúc với outcome<br/>chấp nhận rủi ro đã ghi nhận"]
    X -- "Có" --> Z["Owner đúng thẩm quyền phê duyệt<br/>baseline hoặc cấu hình"]
    Z --> AA["Ghi outcome phê duyệt<br/>và traceability"]

    W -. "Chấp nhận rủi ro không thay<br/>phê duyệt thay đổi" .-> Z

Ngoại lệ không phải lỗ hổng mặc định. Chỉ dùng khi trigger, phạm vi, người phê duyệt, log, thời hạn và cách quay lại quy tắc thường đều xác định. Không áp dụng quy tắc “ưu tiên tiến độ” khi ngoại lệ có thể làm mất dữ liệu, phá vỡ phân quyền, che giấu sai lệch kế toán, hoặc làm suy yếu truy vết lô. Với yêu cầu liên quan Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, hóa đơn chứng từ, hoặc an toàn thực phẩm, tài liệu học liệu chỉ ghi bối cảnh và Verification required; không diễn giải thành nghĩa vụ triển khai.

Recommendation có thể phòng vệ phải nói rõ mức chắc chắn. Mẫu ghi nhận: “Dựa trên [nguồn/artifact], phương án X phù hợp hơn Y theo [tiêu chí]. Bằng chứng chưa xác nhận [khoảng trống]. Rủi ro còn lại là [rủi ro]. Cần [vai trò] quyết định trước khi đưa vào baseline hoặc cấu hình.” Không đổi IN_REVIEW thành approved, không gọi plan là baseline, không dùng chức danh Senior BA để thay thẩm quyền Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance.

Senior Lens

Senior BA review handoff pack theo bằng chứng, không theo độ đầy đủ bề ngoài. Heuristic: mỗi yêu cầu, quy tắc, mapping, quyết định và rủi ro phải có nguồn, owner, trạng thái, tác động và đường dẫn artifact kiểm soát. Nếu một dòng không trả lời được “ai xác nhận?”, “bằng chứng nào?”, “ảnh hưởng thành phần nào?” thì chưa đủ điều kiện handoff. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07, không gọi nội dung là baseline, approved hoặc production-ready.

Điểm review	Quy tắc bình thường	Red flag	Ngưỡng escalation	Khi không áp dụng quy tắc bình thường
Traceability	Mỗi requirement liên kết nguồn và artifact đích	ID thay đổi, nguồn chỉ là ghi chú miệng, liên kết sang tệp không canonical	Escalate khi thiếu nguồn cho requirement có tác động tích hợp, dữ liệu, tài chính, bảo mật hoặc kiểm thử	Không ép tạo ID mới cho nội dung chỉ là diễn giải học liệu; giữ ranh giới artifact và không biến diễn giải thành requirement
Quy tắc nghiệp vụ	Tra cứu CANONICAL_BUSINESS_RULES trước khi ghi lại rule	Hai artifact chứa hai giá trị ngưỡng, trạng thái hoặc điều kiện khác nhau	Escalate ngay khi mâu thuẫn có thể đổi kết quả ERP, số tiền VND, tồn kho, truy xuất hoặc phê duyệt	Không tự chọn “bản mới hơn” nếu chưa có lịch sử thay đổi và authority hợp lệ
Dữ liệu	Field, định nghĩa, định dạng và owner phải khớp CANONICAL_DATA_DICTIONARY	Cùng tên field nhưng nghĩa khác; dữ liệu cá nhân bị đưa vào log hoặc file handoff	Escalate khi thay đổi dữ liệu ảnh hưởng quyền truy cập, lưu giữ, tích hợp hoặc báo cáo	Không suy diễn nghĩa dữ liệu từ tên cột; yêu cầu Data Owner hoặc Security xác minh
Tích hợp	Contract nêu endpoint, payload, lỗi, retry và owner hai đầu	Không có xử lý lỗi; bên gửi và bên nhận hiểu khác thời điểm đồng bộ	Escalate khi thiếu contract cho luồng tạo/chỉnh sửa dữ liệu hoặc khi lỗi có thể mất/nhân bản giao dịch	Không dùng sơ đồ như bằng chứng API; cần đặc tả được kiểm tra, ví dụ OpenAPI nếu phạm vi đã chọn OAS
Tuân thủ	Gắn nhãn Verification required cho suy diễn pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân	BA viết “bắt buộc theo luật” nhưng không có xác minh owner chuyên môn	Escalate ngay khi nội dung có thể tạo nghĩa vụ pháp lý, kế toán hoặc quyền xử lý dữ liệu cá nhân	Không thay Legal Owner, Accounting Owner hoặc Compliance Owner bằng nguồn tổng quan hay kinh nghiệm dự án
Kiểm thử	Acceptance criteria có test basis, dữ liệu kiểm thử tổng hợp và expected result	“Test được” nhưng không có expected result; test dùng dữ liệu giống dữ liệu thật	Escalate khi requirement không thể xác minh hoặc kết quả sai gây sai sổ sách, lộ dữ liệu, lỗi truy xuất	Không yêu cầu BA quyết định test coverage cuối cùng; QA Owner quyết định chiến lược và mức chấp nhận rủi ro

Red flag mạnh hơn số lượng tài liệu. Một handoff pack có 30 trang nhưng thiếu owner quyết định cho rule ảnh hưởng hóa đơn vẫn yếu hơn một pack ngắn có nguồn, phạm vi và điểm mở rõ. Suy luận: người triển khai cần biết cái gì được phép làm; độ dài không cấp thẩm quyền. Vì vậy Senior BA dừng review khi phát hiện “đã thống nhất” nhưng không có artifact, authority hoặc trạng thái kiểm soát chứng minh.

Escalation không chờ đến khi mọi chi tiết hoàn thiện. Escalate ngay nếu có một trong các điều kiện: thay đổi có thể làm mất dữ liệu; thay đổi quyền truy cập; thay đổi logic số tiền VND; thay đổi định nghĩa master data; xung đột giữa Business Owner và Architect; quy tắc có diễn giải pháp lý/kế toán; hoặc một quyết định cần từ hai authority trở lên. BA lập issue log với fact, artifact liên quan, tác động, lựa chọn và câu hỏi quyết định; authority phù hợp kết luận. Principal IT Business Analyst / Technical Curriculum Author chỉ bảo toàn truy vết, không thay thế quyết định đó.

Không áp dụng quy tắc “chỉ handoff khi mọi điểm đóng” cho rủi ro đã được nhận diện nhưng chưa thể giải quyết trong phạm vi tài liệu. Điều kiện: điểm mở được gắn nhãn rõ, có owner xử lý, deadline theo Asia/Ho_Chi_Minh, tác động bị khoanh vùng và không mở đường cho triển khai production. Với Nova Foods mô phỏng, ví dụ “ngưỡng lưu trữ chứng từ” chưa được Legal hoặc Accounting Owner xác minh phải giữ Verification required; không chuyển thành cấu hình ERP hay business rule canonical.

Senior Lens

Senior BA không biến khoảng trống bằng chứng thành kết luận. Khuyến nghị có thể dùng khi ghi rõ: điều đã biết, nguồn và độ mạnh bằng chứng, điều chưa biết, giả định, tác động nếu giả định sai, người có thẩm quyền quyết định, và thời điểm kiểm chứng. Với Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu dưới đây là dữ liệu tổng hợp; không chứng minh cấu hình ERP, tuân thủ pháp lý, hay quyết định vận hành thực tế.

Thành phần ghi nhận	Ví dụ artifact-ready	Lý do phòng vệ quyết định
Fact	F-IR-011-01: File /01-curriculum/CANONICAL_BUSINESS_RULES.md, Status IN_REVIEW, Version v0.9.0, chưa có baseline reference.	Fact bám artifact kiểm soát, không suy diễn thành phê duyệt.
Evidence	E-IR-011-01: Metadata của CANONICAL_BUSINESS_RULES ghi Owner không thay thế Business Owner, Legal Owner, Accounting Owner, Security hoặc Architect.	Evidence nêu nguồn và giới hạn thẩm quyền.
Uncertainty	U-IR-011-01: Chưa có bằng chứng xác minh quy tắc chặn xuất kho khi lô hàng hết hạn trong ERP mô phỏng.	Nêu điều chưa biết, không gọi là lỗi hay yêu cầu đã xác nhận.
Assumption	A-IR-011-01: Project assumption: ERP cần cảnh báo lô hết hạn trước khi xác nhận xuất kho.	Assumption tách khỏi fact; có thể bị bác bỏ.
Recommendation	R-IR-011-01: Không cấu hình chặn cứng trước khi Business Owner và Food-safety owner xác nhận hành vi mong muốn; chuẩn bị hai phương án cảnh báo hoặc chặn.	Khuyến nghị giới hạn hành động theo bằng chứng hiện có.
Decision owner	Business Owner và Food-safety owner	BA ghi nhận, không chiếm quyền quyết định nghiệp vụ hoặc an toàn thực phẩm.
Verification	V-IR-011-01: Verification required: đối chiếu quy trình vận hành mô phỏng, trách nhiệm xử lý ngoại lệ và nguồn pháp lý hiện hành trước production use.	Đặt đường kiểm chứng rõ.
Traceability	Liên kết: CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; TRACEABILITY_ID_REGISTRY.	Người review lần được nguồn và phạm vi.

Mẫu câu senior: “Dựa trên F-IR-011-01 và E-IR-011-01, khuyến nghị chưa cấu hình chặn cứng. Đây không phải xác nhận rằng cảnh báo là đủ, vì U-IR-011-01 chưa được kiểm chứng. A-IR-011-01 chỉ là giả định dự án. Business Owner và Food-safety owner quyết định giữa cảnh báo, chặn cứng, hoặc ngoại lệ có kiểm soát; BA cập nhật artifact sau khi có quyết định được ghi nhận.” Cấu trúc này phân biệt fact, inference và quyết định: fact là điều artifact nói; inference là suy luận từ fact; quyết định thuộc đúng authority.

Không dùng “đã được đồng ý”, “đúng luật”, “đủ an toàn”, “sẵn sàng production” khi thiếu approval reference hoặc kiểm chứng chuyên môn. Với dữ liệu pháp lý, kế toán, thuế, bảo vệ dữ liệu cá nhân, an toàn thực phẩm, traceability hoặc bảo mật, ghi Verification required và chuyển kết luận cho Legal Owner, Accounting Owner, Food-safety owner hoặc Security. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không phải APPROVED hay BASELINED.

12. Associated Template Reference & Completed Artifact

Core

Template là khung ghi nhận lặp lại; artifact là bản ghi đã điền theo khung. Chapter này chỉ tham chiếu template và artifact nguồn, không tự tạo ID, tệp, baseline hoặc approval. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Applied

Facts: TEMPLATE_MANIFEST quản lý danh mục template dự kiến; TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là artifact canonical liên quan readiness và handoff. Tất cả đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: Chapter 17 cần chỉ ra đúng nguồn để learner, BA, QA và vai trò chuyên môn tìm khung ghi nhận, rule, data và ID.

Underlying Need: Handoff thất bại khi người nhận dùng bản sao không kiểm soát, ID tự đặt, hoặc diễn giải IN_REVIEW thành đã phê duyệt.

Options: Dùng tên gọi tự do; sao chép bảng registry vào chapter; hoặc tham chiếu ID và đường dẫn canonical.

Decision Criteria: Giữ traceability; không tạo nguồn chân lý thứ hai; không bịa template ID; không vượt thẩm quyền Legal Owner, Accounting Owner, Security, Architect, QA hoặc Business Owner.

Decision: Dùng tham chiếu canonical bên dưới. Không gán template chuyên biệt khi TEMPLATE_MANIFEST chưa cung cấp entry đã xác minh cho Chapter 17.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Chủ sở hữu chuyên môn xác nhận nội dung thuộc thẩm quyền mình; không có approval được ghi nhận.

Artifact: Tham chiếu trong ### Quick Reference.

Consequence if Wrong: Sai ID hoặc sai tệp làm đứt traceability; rule, data hoặc quyết định có thể bị dùng sai ngữ cảnh. Sai diễn giải pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm phải chuyển owner chuyên môn xác minh.

Senior Lens

Không gọi artifact là “mẫu đã duyệt” chỉ vì có ID hoặc nằm trong thư mục kiểm soát. Bằng chứng là metadata của các artifact nguồn ghi IN_REVIEW, chưa có baseline reference và chưa có approval reference. Vì vậy, BA chỉ được nói “template/reference đang được kiểm soát để review”.

Không tự suy ra template triển khai từ TEMPLATE_MANIFEST. Evidence: nguồn được cung cấp xác nhận manifest quản lý template dự kiến, nhưng không cung cấp entry template riêng cho Chapter 17. Reasoning: gán ID hoặc filename mới sẽ phá vỡ canonical registry. Boundary: dùng manifest để tra cứu; chỉ liên kết template ID sau khi entry canonical tồn tại.

Quick Reference

Template/reference ID	Tệp canonical	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Cần xác định template đã đăng ký, filename và phạm vi template dự kiến.	Không dùng để khẳng định template đã baseline, approved hoặc production-ready.	Principal IT Business Analyst / Technical Curriculum Author	BA curriculum author, chapter reviewer	ID, filename, status và version khớp manifest; không tự tạo entry.
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra ID traceability cho fact, assumption, issue, verification hoặc decision.	Không dùng thay business rule, data definition hoặc quyết định chuyên môn.	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, Architect, domain owner	ID giữ nguyên; liên kết trỏ đúng artifact; escalation nếu ID hàm ý quyết định pháp lý, kế toán, bảo mật hoặc vận hành.
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Cần tham chiếu rule nghiệp vụ trong readiness hoặc handoff.	Không dùng để tự xác nhận rule là đúng cho Nova Foods vận hành thực.	Principal IT Business Analyst / Technical Curriculum Author	BA, Business Owner, QA reviewer	Rule reference giữ nguyên ID; rule pháp lý, kế toán, thuế, privacy, food-safety ghi Verification required.
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Cần thống nhất tên dữ liệu, ý nghĩa logic hoặc boundary dữ liệu.	Không dùng thay physical schema, mapping triển khai hoặc quyết định tích hợp.	Principal IT Business Analyst / Technical Curriculum Author	BA, Data/Integration Architect, QA reviewer	Data term khớp dictionary; field nhạy cảm hoặc access control cần Security review.
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Cần kiểm tra chapter identity, filename và dependency cấp chapter.	Không dùng làm template điền nội dung hoặc bằng chứng approval.	Principal IT Business Analyst / Technical Curriculum Author	Curriculum author, chapter reviewer	Slug, title, đường dẫn và status khớp manifest.
01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Cần kiểm tra vị trí Chapter 17 trong lifecycle học liệu và dependency curriculum.	Không dùng để quyết định cấu hình ERP hoặc quy trình Nova Foods thực.	Principal IT Business Analyst / Technical Curriculum Author	Curriculum author, reviewer	Không tạo mâu thuẫn chuỗi học hoặc nguồn chân lý thứ hai.

Template ID và filename riêng cho completed artifact của Chapter 17: Verification required từ entry canonical trong TEMPLATE_MANIFEST. Không tự đặt vì nguồn seed không xác minh entry đó.

Quick Reference

Tra cứu bắt đầu từ CHAPTER_MANIFEST, vì manifest là nguồn kiểm soát đường dẫn và cấu trúc chapter. Sau đó mở đúng tệp, đối chiếu đủ 12 mục H2. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi ví dụ chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.

Kiểm tra	Vị trí tra cứu	Bằng chứng đạt
Đúng chapter	/01-curriculum/CHAPTER_MANIFEST.md	Entry trỏ tới /02-handbook/17-implementation-readiness-and-handoff-pack.md
Đúng artifact điền hoàn chỉnh	/02-handbook/17-implementation-readiness-and-handoff-pack.md	Tệp chứa nội dung áp dụng Nova Foods mô phỏng
Đúng trạng thái	Header artifact hiện hành	IN_REVIEW, không diễn giải là baseline hay approval
Đúng phiên bản và ngày	Header artifact hiện hành	v0.9.0; 2026-08-07
Đúng định danh liên quan	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID giữ nguyên, không tự tạo biến thể
Đúng nguồn canonical cho rule và data	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Chỉ tham chiếu, không chép lại hay tự nâng thành quyết định vận hành

#	Chapter lookup checklist	Vị trí trong artifact điền hoàn chỉnh
1	1. Concept l? g?? tồn tại và giải thích thuật ngữ nền tảng	/02-handbook/17-implementation-readiness-and-handoff-pack.md, H2 mục 1
2	2. T?i sao concept n?y t?n t?i? nêu vấn đề cần giải quyết	Cùng tệp, H2 mục 2
3	3. V? tr? trong Lifecycle đặt handoff trong vòng đời delivery	Cùng tệp, H2 mục 3
4	4. Input c?n thi?t xác định đầu vào có nguồn	Cùng tệp, H2 mục 4
5	5. Step-by-step BA Activities mô tả hoạt động BA theo thứ tự	Cùng tệp, H2 mục 5
6	6. Output thu ???c liệt kê đầu ra kiểm soát được	Cùng tệp, H2 mục 6
7	7. Who consumes those outputs? chỉ người nhận và mục đích dùng	Cùng tệp, H2 mục 7
8	8. Detailed Worked Example dùng tình huống Nova Foods tổng hợp	Cùng tệp, H2 mục 8
9	9. Related Concepts & Dependencies nêu dependency và ranh giới nguồn	Cùng tệp, H2 mục 9
10	10. Common Mistakes & Anti-patterns nêu lỗi và hậu quả	Cùng tệp, H2 mục 10
11	11. Senior BA Notes & Rules of Thumb ghi phán đoán senior có bằng chứng	Cùng tệp, H2 mục 11
12	12. Associated Template Reference & Completed Artifact chỉ vị trí template và artifact điền	Cùng tệp, H2 mục 12

flowchart TD
    A[CHAPTER_MANIFEST] --> B[/02-handbook/17-implementation-readiness-and-handoff-pack.md]
    B --> C[Đối chiếu 12 H2 blueprint]
    C --> D[Kiểm tra status IN_REVIEW, v0.9.0, 2026-08-07]
    D --> E[Tra cứu ID tại TRACEABILITY_ID_REGISTRY]
    E --> F[Artifact Nova Foods mô phỏng đủ điều kiện tra cứu]

Không dùng checklist này để xác nhận chất lượng, baseline, approval, tuân thủ pháp lý, cấu hình ERP hay sẵn sàng production. Checklist chỉ chứng minh vị trí tra cứu và tính đủ của cấu trúc chapter.

Core

Rà soát liên tệp là kiểm tra một yêu cầu, ID, trạng thái và giới hạn thẩm quyền còn giữ cùng ý nghĩa khi xuất hiện ở nhiều artifact. Mục tiêu không phải xác nhận Nova Foods đã sẵn sàng triển khai. Mục tiêu là chặn mâu thuẫn học liệu trước handoff chương. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp; trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

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

flowchart TB
    A[Soạn phần chương] --> B[Đối chiếu metadata corpus]
    I[Corpus: v0.9.0 · 2026-08-07] -. ngữ cảnh corpus .-> B
    B --> C[Đối chiếu ID, filename, source boundary]
    C --> D{Có mâu thuẫn hoặc suy diễn vượt thẩm quyền?}
    D -- Không --> E[Ghi kết quả self-review]
    D -- Có --> F[Ghi open issue hoặc Verification required]
    F --> G[Escalate tới owner của issue]
    G --> J[Giữ open issue hoặc Verification required chờ phản hồi owner]
    E --> H[Handoff chương: IN_REVIEW, không xác nhận sẵn sàng triển khai]
    J --> H

Applied

Facts: Chương /02-handbook/17-implementation-readiness-and-handoff-pack.md dùng IN_REVIEW, v0.9.0, Asia/Ho_Chi_Minh, vi-VN, VND, và Nova Foods mô phỏng. Evidence: metadata từ CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.

Current Behavior: Các artifact nguồn đều nói chưa có baseline và approval. Suy ra chapter không được gọi nội dung là “đã phê duyệt”, “production-ready” hoặc “tuân thủ”.

Underlying Need: Người nhận handoff cần biết lỗi nào chặn tính nhất quán, việc nào cần xác minh chuyên môn, ai quyết định. Không có bảng này, BA dễ biến giả định học liệu thành quyết định ERP.

Options: (1) Chỉ kiểm tra chapter hiện tại. (2) Kiểm tra chapter và artifact canonical liên quan. Option 2 được chọn vì filename, ID, source boundary và thẩm quyền nằm ngoài chapter.

Decision Criteria: Giữ nguyên canonical ID và filename; không tạo approval ngầm định; không diễn giải luật, kế toán, bảo mật hoặc kiến trúc ngoài thẩm quyền; mỗi vấn đề có owner rõ.

Decision: Handoff chỉ kèm self-review register dưới đây. Mục chưa giải quyết giữ Open hoặc Verification required; không che bằng từ ngữ chắc chắn.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì gói review. Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect và QA Reviewer quyết định phần thuộc thẩm quyền họ.

Artifact: Self-review register cho /02-handbook/17-implementation-readiness-and-handoff-pack.md, trạng thái IN_REVIEW, v0.9.0.

Consequence if Wrong: Sai ID làm đứt traceability. Gọi IN_REVIEW là approved làm sai governance. Tự kết luận pháp lý, kế toán, an toàn thực phẩm hoặc bảo mật có thể biến học liệu mô phỏng thành chỉ dẫn vận hành sai.

Kiểm tra liên tệp	Evidence cần đối chiếu	Kết quả hiện tại	Xử lý nếu lệch
Metadata trạng thái, version, ngày	CHAPTER_MANIFEST; 00_SOURCE_MAP	Khớp IN_REVIEW, v0.9.0, 2026-08-07	Principal IT Business Analyst / Technical Curriculum Author sửa chapter hoặc ghi issue
Canonical filename và chapter boundary	CHAPTER_MANIFEST	Cần giữ /02-handbook/17-implementation-readiness-and-handoff-pack.md	Principal IT Business Analyst / Technical Curriculum Author
ID và traceability	TRACEABILITY_ID_REGISTRY	Verification required: không tự tạo ID mới trong chapter	Principal IT Business Analyst / Technical Curriculum Author
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Verification required: không chuyển catalog plan thành rule vận hành	Business Owner; Principal IT Business Analyst / Technical Curriculum Author
Dữ liệu logic	CANONICAL_DATA_DICTIONARY	Verification required: không suy diễn field, retention, quyền truy cập	Architect; Security Owner
Nguồn pháp lý và chuyên ngành	00_SOURCE_MAP	Open: hiệu lực áp dụng cho ERP thực tế không được xác nhận trong handbook	Legal Owner; Accounting Owner; Food Safety Domain Owner
Test readiness	ISTQB CTFL Syllabus v4.0.1 boundary	Open: test basis production chưa tồn tại trong case mô phỏng	QA Reviewer
API, accessibility, security	OAS 3.1.1, WCAG 2.2, OWASP boundaries	Verification required: không tuyên bố conformant hoặc secure	Architect; Security Owner

Senior Lens

Open issue khác defect. Defect là sai so với nguồn canonical đã xác định. Open issue là thiếu quyết định hoặc thiếu evidence. Verification required là nội dung có thể đúng về hướng, nhưng cần owner có thẩm quyền kiểm tra trước khi dùng ngoài học liệu.

ID review	Loại	Vấn đề	Reasoning bridge	Escalation owner	Điều kiện đóng
IR-17-001	Open	Chưa có baseline reference	Mọi artifact nguồn ghi IN_REVIEW; không có baseline reference. Vì vậy handoff không thể khẳng định baseline.	Principal IT Business Analyst / Technical Curriculum Author	Baseline reference được ghi trong artifact kiểm soát bởi người có thẩm quyền
IR-17-002	Verification required	Nghĩa vụ bảo vệ dữ liệu cá nhân cho ERP thực tế	00_SOURCE_MAP nêu Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, đồng thời yêu cầu legal-owner verification.	Legal Owner	Legal Owner xác minh phạm vi áp dụng và ghi evidence
IR-17-003	Verification required	Diễn giải kế toán, hóa đơn, chứng từ	Nguồn Luật Kế toán và Nghị định 123/2020/NĐ-CP có boundary yêu cầu authorized accounting/legal role.	Accounting Owner; Legal Owner	Owner ghi nhận diễn giải được phép dùng
IR-17-004	Verification required	Traceability và recall thực tế	Luật An toàn thực phẩm chỉ là context; source seed yêu cầu domain-owner và legal verification.	Food Safety Domain Owner; Legal Owner	Owner xác minh rule và evidence nguồn
IR-17-005	Open	Không có test evidence cho production	Case chỉ là mô phỏng, không có environment hay test execution evidence.	QA Reviewer	QA Reviewer xác định test basis và evidence hợp lệ
IR-17-006	Verification required	Security, API, accessibility implementation	OWASP, OAS, WCAG là boundary chuẩn; chapter không có quyền tự xác nhận implementation conformant.	Security Owner; Architect	Owner review thiết kế hoặc implementation evidence

Quick Reference

Trước handoff, người soạn kiểm tra đủ: canonical IDs giữ nguyên; filenames không đổi; IN_REVIEW không bị đổi nghĩa; v0.9.0 và 2026-08-07 thống nhất; Nova Foods luôn được gắn mô phỏng và dữ liệu tổng hợp; không có approval claim; pháp lý, kế toán, an toàn thực phẩm, bảo mật, kiến trúc và QA đều có đúng escalation owner.

Handoff chỉ chuyển chapter cùng register IR-17-001 đến IR-17-006. Handoff không đóng open issue, không xác nhận approval, không cấp phép production.