08 Business Rules State And Decision Analysis

Artifact Governance Metadata

Trường kiểm soát	Giá trị
Đường dẫn tệp được kiểm soát	/02-handbook/08-business-rules-state-and-decision-analysis.md
Tiêu đề tài liệu	08 Business Rules State And Decision Analysis
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN
Bối cảnh quốc gia	Việt Nam
Đơn vị tiền tệ mô phỏng	VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Dữ liệu	Chỉ dữ liệu tổng hợp
Phân loại nguồn	Handbook educational artifact; kế thừa governance từ planning artifact được kiểm soát
Traceability nguồn quản trị	CHAPTER_MANIFEST — /01-curriculum/CHAPTER_MANIFEST.md; TRACEABILITY_ID_REGISTRY — /01-curriculum/TRACEABILITY_ID_REGISTRY.md; CANONICAL_BUSINESS_RULES — /01-curriculum/CANONICAL_BUSINESS_RULES.md
Owner	Principal IT Business Analyst / Technical Curriculum Author
Giới hạn thẩm quyền	Owner duy trì cấu trúc, traceability và lịch sử thay đổi; không xác lập baseline, approval, quyết định nghiệp vụ, pháp lý, kế toán, bảo mật hoặc production.
Baseline	Chưa có baseline reference tại v0.9.0.
Approval	Chưa có approval reference tại v0.9.0. IN_REVIEW không có nghĩa đã được phê duyệt.
Ranh giới sử dụng	Nội dung là học liệu. Không phải quy định vận hành ERP Nova Foods, tư vấn pháp lý, diễn giải kế toán hay chỉ dẫn production.

1. Concept l? g??

Artifact Governance Metadata

Trường	Giá trị
Status	IN_REVIEW
Version	v0.9.0
Updated	2026-08-07
Artifact	/02-handbook/08-business-rules-state-and-decision-analysis.md
Governance meaning	Nội dung đang được rà soát; chưa phải baseline và chưa có approval được ghi nhận.

Metadata này mô tả trạng thái của artifact học liệu. Status IN_REVIEW không xác nhận quy tắc vận hành, cấu hình ERP, thẩm quyền production hoặc chính sách Nova Foods thực tế. BA chịu trách nhiệm ghi nhận thay đổi và truy vết; Business Owner, Inventory/Operations Owner và Architect chỉ có authority trong phạm vi được xác nhận, không được suy diễn từ ví dụ mô phỏng.

Core — Khái niệm nền tảng

Business Rules State And Decision Analysis là kỹ thuật BA dùng để làm rõ ba thứ thường bị viết lẫn vào nhau: quy tắc nghiệp vụ, trạng thái của đối tượng nghiệp vụ, và quyết định tạo ra kết quả nghiệp vụ. Mục tiêu không phải vẽ quy trình đẹp. Mục tiêu là biến câu nói mơ hồ thành điều kiện có thể kiểm tra, kết quả có thể dự đoán, và trách nhiệm có thể truy vết.

Business rule là quy tắc giới hạn hoặc định hướng cách tổ chức được phép xử lý nghiệp vụ. Quy tắc trả lời: điều gì phải đúng, điều gì bị cấm, điều kiện nào làm kết quả thay đổi. Ví dụ dạng khái quát: “Chỉ được thực hiện X khi điều kiện Y đúng.” Quy tắc không tự là màn hình, API, bảng dữ liệu hay bước quy trình. Các thành phần đó chỉ là nơi hệ thống thực thi hoặc ghi nhận quy tắc.

State là trạng thái hiện thời của một đối tượng nghiệp vụ tại một thời điểm. Trạng thái cho biết đối tượng đang ở đâu trong vòng đời, từ đó xác định hành động nào còn hợp lệ. Một đối tượng không thể đồng thời ở hai trạng thái loại trừ nhau nếu mô hình không định nghĩa rõ khả năng đó. Vì vậy, phân tích trạng thái cần xác định trạng thái hợp lệ, điều kiện chuyển trạng thái, và trạng thái không được phép quay lại.

Decision analysis là phân tích cách chọn một kết quả từ nhiều khả năng dựa trên facts, điều kiện và quy tắc. Facts là dữ kiện đầu vào được quan sát hoặc ghi nhận. Decision không phải cảm nhận cá nhân; nó phải cho cùng kết quả khi cùng facts và cùng bộ quy tắc. Nếu hai người áp dụng cùng dữ kiện nhưng cho kết quả khác nhau, rule thiếu điều kiện, thiếu ưu tiên, hoặc thiếu quyền quyết định.

Ba phần liên kết chặt. State giới hạn việc gì có thể xảy ra tiếp theo. Business rule đặt điều kiện cho chuyển trạng thái hoặc kết quả. Decision analysis kiểm tra facts theo rule để chọn kết quả. Cầu nối suy luận là: không có state thì không biết hành động còn hợp lệ; không có rule thì không biết điều kiện đánh giá; không có decision logic thì không biết hệ thống phải chọn kết quả nào khi điều kiện khác nhau.

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

flowchart TB
    Facts["Facts<br/>dữ kiện đầu vào được quan sát hoặc ghi nhận"]
    Rules["Business rules<br/>điều kiện phải đúng, bị cấm, hoặc làm kết quả thay đổi"]
    Current["State hiện thời<br/>xác định hành động còn hợp lệ"]
    Decision{"Decision analysis<br/>đánh giá facts theo rules"}
    Allow["Outcome: cho phép thay đổi"]
    Reject["Outcome: từ chối hành động<br/>giữ nguyên state hiện thời"]
    Next["State kế tiếp<br/>chỉ hợp lệ khi outcome cho phép"]

    Facts --> Decision
    Rules --> Decision
    Current --> Decision
    Decision --> Allow
    Decision --> Reject
    Allow --> Next
    Reject --> Current

Ranh giới khái niệm: chương này phân tích logic nghiệp vụ độc lập với cách lập trình cụ thể. Nó không tự quyết định cấu hình ERP, thiết kế database, quyền production, diễn giải luật, hạch toán kế toán hay quy trình vận hành thật. Với Nova Foods, mọi đối tượng, trạng thái, quy tắc và dữ kiện trong handbook là mô phỏng giáo dục dùng dữ liệu tổng hợp; chúng chỉ trở thành yêu cầu vận hành khi có nguồn canonical, thẩm quyền phù hợp, baseline và approval được ghi nhận minh bạch.

Core — Từ điển thuật ngữ

Thuật ngữ	Nghĩa Việt ngắn gọn	Vai trò trong phân tích quy tắc
Business Rule (BR)	Quy tắc nghiệp vụ: mệnh đề ràng buộc, tính toán, cho phép hoặc cấm hành vi nghiệp vụ.	Nêu điều hệ thống và người dùng phải tuân theo.
State	Trạng thái: tình trạng hiện tại hợp lệ của đối tượng.	Xác định đối tượng đang ở đâu trong vòng đời.
Decision	Quyết định: kết quả chọn một phương án theo điều kiện.	Biến dữ kiện thành kết quả nhất quán.
Actor	Tác nhân: người, vai trò, hệ thống hoặc dịch vụ thực hiện hay kích hoạt hành vi.	Trả lời: ai thực hiện hành động?
Action	Hành động: việc actor làm với đối tượng.	Trả lời: làm gì? Ví dụ: gửi, duyệt, hủy.
Object	Đối tượng: thực thể chịu tác động, như đơn bán hàng hoặc phiếu nhập kho.	Trả lời: tác động lên cái gì?
Outcome	Kết quả: trạng thái, giá trị, thông báo hoặc bản ghi sau hành động.	Trả lời: kết quả mong đợi là gì?
ERP	Enterprise Resource Planning: hệ thống hoạch định nguồn lực doanh nghiệp, liên kết dữ liệu và quy trình nhiều bộ phận.	Bối cảnh hệ thống mô phỏng của Nova Foods.
BA	Business Analyst: chuyên viên phân tích nghiệp vụ.	Làm rõ quy tắc, bằng chứng, ngoại lệ và người có thẩm quyền quyết định.

Một câu quy tắc rõ phải tách được cấu trúc: actor thực hiện action lên object, khi điều kiện đúng, tạo outcome. Tách như vậy giúp BA kiểm tra thiếu thông tin. Nếu câu chỉ ghi “đơn hàng được duyệt”, chưa biết ai duyệt, điều kiện duyệt, đối tượng nào và kết quả dữ liệu nào thay đổi.

Applied — Ví dụ đơn bán hàng

Thành phần	Nội dung mô phỏng Nova Foods, dữ liệu tổng hợp
Facts	Nhân viên bán hàng tạo đơn SO-SYN-001 trị giá 12.500.000 VND.
Current Behavior	Hệ thống nhận thao tác gửi đơn nhưng chưa có câu quy tắc chuẩn mô tả kết quả.
Underlying Need	Cần diễn đạt đủ chủ thể, hành động, đối tượng và kết quả để đội kỹ thuật, kiểm thử và nghiệp vụ hiểu cùng một nghĩa.
Options	Viết câu mơ hồ “Gửi đơn để duyệt”; hoặc viết câu có cấu trúc đầy đủ.
Decision Criteria	Câu phải xác định được actor, action, object, điều kiện và outcome; không tự tạo thẩm quyền phê duyệt.
Decision	Dùng câu: “Nhân viên bán hàng gửi đơn bán hàng; hệ thống chuyển đơn sang trạng thái IN_REVIEW khi dữ liệu bắt buộc hợp lệ.”
Authority	Business Owner xác nhận ý nghĩa nghiệp vụ; BA ghi nhận và truy vết. Chưa có phê duyệt được ghi nhận.
Artifact	Câu quy tắc là nội dung học liệu mô phỏng, chưa phải mục trong CANONICAL_BUSINESS_RULES.
Consequence if Wrong	Thiếu actor có thể cấp sai quyền; thiếu điều kiện tạo xử lý không nhất quán; thiếu outcome làm test không xác định được kết quả cần kiểm.

Senior Lens

IN_REVIEW là state, không phải action. “Chuyển sang IN_REVIEW” là action hoặc outcome tùy vị trí câu: hành vi hệ thống là action; trạng thái sau hành vi là outcome. Bằng chứng là cùng chuỗi ký tự có thể chỉ tình trạng hiện tại hoặc kết quả cần đạt; BA phải ghi rõ ngữ cảnh để tránh đội phát triển biến trạng thái thành nút thao tác.

Quick Reference

Mẫu câu kiểm tra nhanh: [Actor] [action] [object] khi [condition], kết quả [outcome]. Ví dụ Nova Foods mô phỏng: “Hệ thống ERP ghi nhận đơn bán hàng khi nhân viên bán hàng gửi dữ liệu hợp lệ, kết quả đơn có trạng thái IN_REVIEW.”

Applied — Ví dụ phiếu yêu cầu xuất kho

Nova Foods Trading & Manufacturing là case study mô phỏng; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Ví dụ dùng một phiếu yêu cầu xuất kho mô phỏng, không khẳng định cấu hình hay quy tắc vận hành của doanh nghiệp thật.

Thành phần	Nội dung mô phỏng
Facts	Phiếu yêu cầu xuất kho có trạng thái DRAFT; mặt hàng yêu cầu là 120 thùng; tồn khả dụng ghi nhận trong ERP mô phỏng là 100 thùng.
Current Behavior	Người dùng có thể lưu phiếu ở DRAFT; hệ thống chưa tạo lệnh xuất kho.
Underlying Need	Cần quyết định phiếu có được chuyển sang APPROVED hay không trước khi tạo lệnh xuất. Bằng chứng: nhu cầu 120 thùng lớn hơn tồn khả dụng 100 thùng, nên phê duyệt ngay có thể tạo cam kết xuất vượt khả năng ghi nhận.
Options	(1) Chặn chuyển trạng thái; (2) cho phép chuyển APPROVED kèm cảnh báo; (3) cho phép duyệt một phần 100 thùng.
Decision Criteria	Đúng tồn khả dụng tại thời điểm quyết định; quyền của người duyệt; khả năng truy vết trạng thái; không tự suy diễn quy tắc kế toán, thuế, an toàn thực phẩm hay pháp lý.
Decision	Quy tắc minh họa: chỉ cho chuyển từ DRAFT sang APPROVED khi số lượng yêu cầu không vượt tồn khả dụng. Với 120 > 100, kết quả là giữ DRAFT và trả kết quả “Không đủ tồn khả dụng”.
Authority	Business Owner xác nhận chính sách cấp hàng; Inventory/Operations Owner xác nhận ý nghĩa tồn khả dụng; Architect xác nhận cách ERP lấy số tồn; BA ghi nhận rule và traceability. Không vai trò nào được ngầm xem là đã phê duyệt.
Artifact	Mô tả quy tắc, mô hình trạng thái và bảng quyết định thuộc phạm vi học liệu /02-handbook/08-business-rules-state-and-decision-analysis.md; trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu cho phép APPROVED khi không đủ tồn, kho có thể nhận lệnh không thể đáp ứng. Nếu chặn mọi thiếu hụt mà không có chính sách ngoại lệ được xác nhận, vận hành có thể mất khả năng xử lý tình huống hợp lệ.

stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> APPROVED: yêu cầu <= tồn khả dụng
    DRAFT --> DRAFT: yêu cầu > tồn khả dụng\nKết quả: Không đủ tồn khả dụng
    APPROVED --> [*]

Ranh giới khái niệm: business rule là phát biểu kiểm soát quyết định nghiệp vụ: khi điều kiện đúng hoặc sai, actor thực hiện action trên object sẽ nhận outcome xác định. Trong ví dụ, actor là người duyệt; action là chuyển trạng thái; object là phiếu yêu cầu xuất kho; outcome là APPROVED hoặc giữ DRAFT. State là trạng thái hợp lệ của object. Decision là việc chọn outcome bằng điều kiện. Không được lẫn ba phần này: DRAFT không phải quy tắc; “chuyển sang APPROVED” không phải điều kiện; “Không đủ tồn khả dụng” không phải trạng thái mới.

Loại trừ: ví dụ không định nghĩa thuật toán giữ hàng, cách tính tồn khả dụng, quyền chi tiết theo vai trò, giao diện ERP, API, bút toán kế toán, thuế, hóa đơn, truy xuất thực phẩm, dữ liệu cá nhân, SLA hay xử lý ngoại lệ sản xuất. Các nội dung đó cần artifact và thẩm quyền riêng. Quy tắc trên là giả định giáo dục, không phải điều khoản pháp lý, chính sách Nova Foods thực tế hay chỉ dẫn production.

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

Core

Business rule, state model và decision analysis tồn tại để chặn cùng một lỗi gốc: cùng một tình huống nhưng các bên hiểu outcome khác nhau. Nếu yêu cầu chỉ ghi “duyệt phiếu khi đủ tồn”, BA, kho, developer và QA có thể tự diễn giải “đủ”, thời điểm kiểm tra, trạng thái bị chặn và thông báo lỗi. Hệ quả quan sát được: developer tạo luồng chuyển trạng thái khác kỳ vọng vận hành; QA không có kết quả mong đợi duy nhất để kiểm thử; người dùng xử lý cùng phiếu theo cách khác nhau; thay đổi sau review phải sửa requirement, thiết kế, code và test.

State model làm rõ object được phép ở trạng thái nào và chuyển đi đâu. Business rule làm rõ điều kiện kiểm soát chuyển đổi đó. Decision analysis tách điều kiện, outcome và ngoại lệ thành cấu trúc có thể review. Ba phần này tạo một nguồn diễn giải chung; chúng không tạo phê duyệt, baseline hay thẩm quyền vận hành.

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

flowchart TB
    A["Trạng thái trước: DRAFT"] --> B["Kiểm tra tồn<br/>Thời điểm: cần xác nhận<br/>(khi gửi duyệt hay khi thực hiện duyệt)"]
    B --> C{"Số lượng tồn theo nguồn dữ liệu<br/>≥ số lượng yêu cầu trên phiếu?"}
    C -- Có --> D["Trạng thái sau: APPROVED"]
    C -- Không --> E["Giữ trạng thái: DRAFT<br/>Chặn duyệt<br/>Hiển thị lý do thiếu tồn"]

    F["Cần xác nhận:<br/>• Nguồn dữ liệu tồn<br/>• Owner hoặc hệ thống thực hiện kiểm tra"] -.-> B

Applied

Mục	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Facts	Phiếu yêu cầu xuất kho có trạng thái DRAFT và có thao tác yêu cầu chuyển sang APPROVED trong ví dụ học liệu.
Current Behavior	Không có rule và state transition được ghi riêng; câu “duyệt khi đủ tồn” nằm trong mô tả tự do.
Underlying Need	Cần một outcome duy nhất cho thao tác duyệt để kho, developer và QA cùng kiểm tra một điều kiện.
Options	(1) Giữ mô tả tự do; (2) ghi rule nhưng không mô hình trạng thái; (3) ghi rule, trạng thái nguồn, trạng thái đích và outcome khi điều kiện sai.
Decision Criteria	Outcome có xác định được không; trạng thái không hợp lệ có bị ngăn không; QA có viết test không cần suy đoán không; thay đổi điều kiện có xác định được phạm vi ảnh hưởng không.
Decision	Dùng option (3): tách điều kiện duyệt, transition DRAFT sang APPROVED, và outcome giữ DRAFT khi điều kiện không đạt.
Authority	Business Owner xác nhận mục tiêu nghiệp vụ; kho xác nhận ngữ cảnh vận hành; Architect xác nhận khả năng thiết kế; QA xác nhận test basis. Tài liệu học liệu không thay thế các thẩm quyền này.
Artifact	Nội dung rule/state/decision phải truy vết về CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY và /02-handbook/08-business-rules-state-and-decision-analysis.md; các artifact hiện IN_REVIEW, v0.9.0.
Consequence if Wrong	Nếu developer cho phép DRAFT sang APPROVED khi điều kiện chưa đạt, kho nhận yêu cầu không đáp ứng được. Nếu developer chặn mọi trường hợp mà không có outcome đã xác định, vận hành và QA không biết đó là lỗi, ngoại lệ hay hành vi dự kiến.

Trước khi phân tích: câu “duyệt khi đủ tồn” không nêu object nào được kiểm tra, trạng thái nào bị tác động, điều kiện được đánh giá lúc nào, hay hệ thống làm gì khi điều kiện sai. Mỗi vai trò phải tự bổ sung phần thiếu. Đây là ambiguity, tức mơ hồ làm nhiều cách hiểu đều có vẻ hợp lý.

Sau khi phân tích: một rule xác định điều kiện; state model giới hạn transition; decision xác định outcome cho từng nhánh. Khi rule đổi, BA truy ra transition, test case và thành phần bị ảnh hưởng thay vì tìm câu mô tả tự do trong nhiều tài liệu. Đây là giảm rework, tức làm lại do phát hiện hiểu sai muộn.

Senior Lens

Rủi ro governance xuất hiện khi một câu requirement vừa chứa policy, thao tác hệ thống và ngoại lệ nhưng không chỉ rõ owner quyết định từng phần. BA không được biến diễn giải của một người thành rule canonical. BA ghi điều kiện, nguồn, owner cần xác nhận và phạm vi tác động; quyết định nghiệp vụ vẫn thuộc vai trò có thẩm quyền.

Không dùng state model để che điều kiện nghiệp vụ. APPROVED là trạng thái, không chứng minh vì sao được duyệt. Không dùng decision table để thay state model. Bảng quyết định có thể trả về “giữ DRAFT”, nhưng không tự nói transition nào hợp lệ trước hoặc sau outcome đó. Tách đúng giúp phát hiện xung đột: hai rule cùng áp dụng cho một transition nhưng trả về hai outcome khác nhau.

Quick Reference

Rủi ro cần chặn	Thiếu gì	Hậu quả
Mơ hồ	Điều kiện hoặc outcome không rõ	Các vai trò hiểu khác nhau
Rework	Không truy được rule ảnh hưởng state, code và test	Sửa muộn nhiều artifact
Lỗi kiểm thử	Không có expected result xác định	QA phải tự suy đoán
Governance yếu	Không rõ ai xác nhận policy hoặc ngoại lệ	Nội dung review bị hiểu nhầm là quyết định
Transition sai	Không xác định trạng thái nguồn và đích	Hệ thống cho phép hoặc chặn sai thao tác

Core

Phân tích quy tắc nghiệp vụ, trạng thái và quyết định tồn tại để biến câu nói vận hành thành điều kiện kiểm tra được. Nếu chỉ ghi “không cho xuất kho khi chưa duyệt”, đội ERP chưa biết trạng thái nào là “đã duyệt”, ai đổi trạng thái, khi nào chặn, và bản ghi nào chứng minh việc chặn. Khoảng trống này tạo mơ hồ: cấu hình có thể cho xuất kho theo một cách, người dùng hiểu theo cách khác, còn QA không có tiêu chí quan sát để kiểm tra.

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. Ví dụ dùng phiếu yêu cầu xuất nguyên liệu Material Issue Request, không khẳng định cấu hình ERP hay quy trình thực của bất kỳ doanh nghiệp nào.

Góc nhìn	Trước khi phân tích trạng thái và quyết định	Sau khi phân tích trạng thái và quyết định	Hệ quả quan sát được
Câu mô tả	“Kho chỉ xuất nguyên liệu cho lệnh sản xuất đã được duyệt.”	Quy tắc được tách thành trạng thái nguồn, điều kiện chặn và hành động hệ thống.	Developer, kho và QA cùng kiểm tra một điều kiện.
Trạng thái	“Đã duyệt” không có danh sách giá trị.	Production Order.Status = RELEASED là điều kiện cho phép tạo phiếu xuất.	Phiếu ở DRAFT hoặc PENDING_APPROVAL bị chặn tại điểm tạo phiếu.
Quyết định	Nhân viên kho tự hỏi trưởng ca khi trạng thái không rõ.	Hệ thống đánh giá trạng thái trước khi tạo giao dịch xuất kho.	Thông báo chặn có thể ghi nhận và kiểm thử.
Truy vết	Không xác định bản ghi nào chứng minh xuất kho hợp lệ.	Phiếu xuất tham chiếu Production Order nguồn và trạng thái tại thời điểm kiểm tra.	QA đối chiếu được phiếu xuất với lệnh sản xuất liên quan.
Xử lý sai	Có thể xuất rồi sửa trạng thái sau.	Không tạo phiếu xuất nếu điều kiện không đạt; ngoại lệ cần quyết định có thẩm quyền riêng.	Giảm sửa dữ liệu sau giao dịch; không ngầm coi việc sửa tay là quy trình hợp lệ.

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

stateDiagram-v2
    direction TB

    state "Production Order.Status tại thời điểm tạo phiếu" as OrderStatus {
        [*] --> StatusRead
        StatusRead --> RELEASED: Production Order.Status = RELEASED
        StatusRead --> NotReleased: Production Order.Status != RELEASED
    }

    state "Yêu cầu tạo Material Issue Request" as IssueRequest {
        [*] --> CreateAttempt
        CreateAttempt --> OrderStatus
        RELEASED --> MaterialIssueCreated: tạo Material Issue Request
        NotReleased --> CreationBlocked: chặn tạo phiếu
        CreationBlocked --> BlockingMessageRecorded: hiển thị/ghi nhận thông báo chặn
        MaterialIssueCreated --> [*]
        BlockingMessageRecorded --> [*]
    }

Facts: Case mô phỏng có đối tượng Production Order và nhu cầu minh họa xuất nguyên liệu. Đây là dữ liệu tổng hợp phục vụ học liệu, không phải bằng chứng về ERP thật.

Current Behavior: Câu mô tả trước phân tích chỉ dùng cụm “đã được duyệt”. Vì không có giá trị trạng thái chuẩn, hai cách xây dựng đều có thể xuất hiện: cho phép xuất khi người dùng nhìn thấy trạng thái bất kỳ có chữ “duyệt”, hoặc chỉ cho phép khi trạng thái kỹ thuật là RELEASED.

Underlying Need: Kho cần biết tại thời điểm thao tác liệu giao dịch xuất có được phép hay không. QA cần đầu vào, kết quả mong đợi và dấu vết để kiểm tra. Nhu cầu này suy ra từ việc một câu nghiệp vụ phải tạo được hành vi hệ thống quan sát được, không chỉ tạo diễn giải bằng lời.

Options:
1. Cho nhân viên kho tự xác nhận bằng trao đổi ngoài hệ thống.
2. Chặn theo trạng thái kỹ thuật của Production Order.
3. Cho phép xuất mọi trạng thái rồi kiểm tra sau.

Decision Criteria: Quy tắc cần nhất quán giữa người dùng và hệ thống; có điểm kiểm tra trước giao dịch; tạo được bằng chứng kiểm thử; không trao quyền ngoại lệ ngầm cho thao tác kho.

Decision: Với ví dụ học liệu, chỉ trạng thái RELEASED cho phép tạo phiếu xuất nguyên liệu. DRAFT, PENDING_APPROVAL và REJECTED bị chặn. Đây là quyết định minh họa, chưa là quy tắc vận hành Nova Foods.

Authority: Business Owner quyết định ý nghĩa nghiệp vụ của trạng thái và ngoại lệ. Architect xác nhận cách biểu diễn trạng thái trong ERP. QA xác nhận ca kiểm thử. BA ghi nhận logic và truy vết; BA không tự phê duyệt quyết định.

Artifact: Ghi quyết định và điều kiện vào CANONICAL_BUSINESS_RULES; định nghĩa trường trạng thái vào CANONICAL_DATA_DICTIONARY; dùng TRACEABILITY_ID_REGISTRY khi có ID được đăng ký. Các artifact hiện có trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline hay approval.

Consequence if Wrong: Nếu PENDING_APPROVAL bị coi nhầm là đủ điều kiện xuất, kho có thể tạo giao dịch khi lệnh chưa đạt trạng thái được chọn. Nếu RELEASED bị chặn nhầm, kho không tạo được giao dịch dù lệnh đạt điều kiện. Cả hai lỗi đều nhìn thấy qua kết quả tạo phiếu, thông báo chặn và liên kết giữa phiếu xuất với Production Order.

Senior Lens

Đối chiếu trước/sau phải mô tả khác biệt có thể quan sát, không dùng số liệu không có nguồn. “Giảm lỗi” là nhận định chung; “hệ thống trả chặn khi Status != RELEASED” là hành vi kiểm tra được. Khi chưa có danh mục trạng thái canonical, không biến tên trạng thái minh họa thành fact vận hành.

Quick Reference

Thành phần cần có	Dạng kiểm tra được
Điều kiện	Production Order.Status = RELEASED
Thời điểm kiểm tra	Trước khi tạo phiếu xuất
Kết quả đạt	Cho phép tạo phiếu xuất
Kết quả không đạt	Chặn tạo phiếu xuất
Bằng chứng	Tham chiếu phiếu xuất tới Production Order và kết quả kiểm tra trạng thái

Core

Phân loại đúng nguồn gốc phát biểu chặn BA biến ý kiến thành quy tắc ERP. Verified fact là thông tin có bằng chứng kiểm tra được từ nguồn canonical. Stakeholder input là điều người liên quan nêu; hữu ích để khám phá, chưa tự thành sự thật hay yêu cầu. Project assumption là điều tạm giả định để tiếp tục phân tích, phải có điều kiện kiểm chứng. Decision là lựa chọn đã được vai trò có thẩm quyền ghi nhận. Verification-required claim là 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 bằng chứng hiện có chưa đủ.

IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND là verified fact cho corpus vì metadata nguồn canonical đã nêu. Chúng không chứng minh Nova Foods có ERP thật, đã baseline, được phê duyệt, compliant hoặc production-ready. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Loại	Bằng chứng tối thiểu	BA được làm	BA không được làm
Verified fact	URL chính thức, artifact canonical, bản ghi kiểm tra được	Trích nguồn và phạm vi dùng	Mở rộng thành kết luận ngoài nguồn
Stakeholder input	Người nói, thời điểm, ngữ cảnh ghi nhận	Ghi nguyên ý nghĩa, làm rõ	Gọi là rule đã xác nhận
Project assumption	Lý do, tác động, điều kiện kiểm chứng	Theo dõi và gắn nhãn assumption	Dùng làm acceptance criterion bắt buộc
Decision	Lựa chọn, tiêu chí, thẩm quyền, bằng chứng quyết định	Liên kết artifact quyết định	Suy diễn approval từ trạng thái IN_REVIEW
Verification-required claim	Chủ đề và khoảng trống bằng chứng	Chuyển đúng owner xác minh	Tự diễn giải pháp lý hoặc kế toán

Applied

Case Nova Foods mô phỏng: BA ghi nhận phát biểu “ERP phải giữ lịch sử thay đổi giá bán để kế toán đối chiếu.”

Trường	Nội dung artifact-ready
Facts	CANONICAL_BUSINESS_RULES và CHAPTER_MANIFEST đều có trạng thái IN_REVIEW, v0.9.0, chưa có baseline reference và approval reference. Luật Kế toán là nguồn chính thức, nhưng diễn giải kế toán cần Accounting Owner hoặc Legal Owner xác minh.
Current Behavior	Không có bằng chứng nguồn được cung cấp xác nhận cấu hình ERP Nova Foods, thời gian lưu lịch sử, trường dữ liệu hay quyền truy cập thực tế.
Underlying Need	Cần phân biệt nhu cầu kiểm soát được stakeholder nêu với nghĩa vụ hệ thống đã xác nhận; nếu không, BA có thể viết rule sai thẩm quyền.
Options	1. Ghi thành verified business rule. 2. Ghi stakeholder input và tạo mục verification-required. 3. Bỏ phát biểu khỏi phân tích.
Decision Criteria	Nguồn có xác nhận nghĩa vụ không; phạm vi có thuộc kế toán/pháp lý không; có authority record không; hệ quả nếu rule sai có gây sai dữ liệu hoặc kiểm soát không.
Decision	Chọn phương án 2: ghi phát biểu là stakeholder input; ghi yêu cầu xác minh với Accounting Owner hoặc Legal Owner. Không tạo business rule bắt buộc tại IN_REVIEW.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì phân loại và traceability. Accounting Owner hoặc Legal Owner xác minh diễn giải; Business Owner quyết định nhu cầu nghiệp vụ.
Artifact	Tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md; giữ status IN_REVIEW, version v0.9.0; không gán approval reference.
Consequence if Wrong	Nếu gọi ý kiến là fact, đội build có thể khóa thiết kế lưu vết sai phạm vi. Nếu gọi yêu cầu pháp lý là verified khi chưa kiểm tra, corpus tạo rủi ro governance và diễn giải sai thẩm quyền.

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

flowchart TB
    A[Phát biểu mới] --> B{Nguồn nào hỗ trợ phát biểu?}

    B -- Luật Kế toán chính thức --> C{Phạm vi rõ và diễn giải đã được Accounting Owner hoặc Legal Owner xác minh?}
    B -- Corpus nội bộ IN_REVIEW --> D[Corpus nội bộ chưa đủ xác nhận nghĩa vụ]
    B -- Ý kiến hoặc nhu cầu stakeholder --> E[Stakeholder input: ghi người nói và ngữ cảnh]
    B -- Không có nguồn phù hợp --> F[Verification-required claim]

    C -- Có --> G{Authority record xác nhận nghĩa vụ?}
    C -- Không --> F
    G -- Có --> H{Nếu diễn giải sai: sai dữ liệu, sai kiểm soát hoặc khóa thiết kế sai phạm vi?}
    G -- Không --> F

    H -- Có --> I[Verified fact: ghi nguồn, phạm vi, authority và rủi ro]
    H -- Không --> J[Verified fact: ghi nguồn, phạm vi và authority]

    D --> F
    E --> F

    F --> K{Cần xác minh gì?}
    K -- Diễn giải kế toán hoặc pháp lý --> L[Accounting Owner hoặc Legal Owner xác minh]
    K -- Nhu cầu nghiệp vụ --> M[Business Owner quyết định nhu cầu]

    L --> N[Principal IT Business Analyst / Technical Curriculum Author duy trì phân loại và traceability]
    M --> N
    N --> O[Case outcome: /01-curriculum/CANONICAL_BUSINESS_RULES.md giữ IN_REVIEW, v0.9.0]
    O --> P[Không baseline reference; không approval reference]
    P --> Q[Không tạo business rule bắt buộc]

Senior Lens

Cùng một câu có thể đổi loại theo bằng chứng. “Kho phải truy xuất lô hàng” là stakeholder input khi Quản lý Kho nêu nhu cầu. Câu này chỉ thành verified fact khi artifact hoặc nguồn chính thức xác nhận đúng phạm vi. Nếu suy luận “có thể cần lưu mã lô để phân tích tiếp”, đó là project assumption. Nếu yêu cầu liên quan Luật An toàn thực phẩm nhưng chưa được domain-owner và legal-owner xác minh cho phạm vi hệ thống, đó là verification-required claim, không phải quy tắc đã xác nhận.

Reasoning bridge: nguồn official chỉ xác nhận tồn tại và phạm vi tham chiếu của luật; nguồn không xác nhận cấu hình Nova Foods mô phỏng. Vì vậy BA phải tách bằng chứng về nguồn khỏi kết luận về requirement ERP.

Quick Reference

Câu hỏi kiểm tra	Phân loại khi trả lời “Có”
Có bằng chứng kiểm tra được, đúng phạm vi?	Verified fact
Có người liên quan nêu nhu cầu nhưng chưa xác minh?	Stakeholder input
Có giả định tạm để phân tích tiếp?	Project assumption
Có lựa chọn, tiêu chí, authority và bản ghi quyết định?	Decision
Có tác động pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật chưa đủ bằng chứng?	Verification-required claim

3. V? tr? trong Lifecycle

Core

Business rules state and decision analysis đi xuyên suốt vòng đời vì quy tắc chỉ có giá trị khi được biến từ nhu cầu mơ hồ thành điều kiện kiểm tra được. Entry gate là cổng vào: bằng chứng tối thiểu phải có trước khi bắt đầu pha. Exit gate là cổng ra: kết quả tối thiểu phải tồn tại trước khi chuyển pha. Gate không là phê duyệt ngầm định; tại Nova Foods mô phỏng, mọi nội dung dùng dữ liệu tổng hợp và trạng thái corpus vẫn là IN_REVIEW, v0.9.0, ngày 2026-08-07.

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

flowchart TB
    ED[Discovery Entry<br/>Vấn đề, phạm vi ban đầu,<br/>nguồn đầu vào phân loại]
    D[Discovery<br/>Nhu cầu và vấn đề]
    XD[Discovery Exit<br/>Mỗi phát biểu có nguồn, ngữ cảnh,<br/>trạng thái bằng chứng]
    EA[Analysis Entry<br/>Đầu vào Discovery đủ truy vết]
    A[Analysis<br/>Quy tắc, state, decision]
    XA[Analysis Exit<br/>Rule/state/decision có điều kiện, kết quả,<br/>traceability, acceptance criteria]
    EDE[Delivery Entry<br/>Đặc tả Analysis không mâu thuẫn nội bộ]
    DE[Delivery<br/>Đặc tả build]
    XDE[Delivery Exit<br/>Build bám đặc tả hoặc sai lệch ghi nhận]
    ET[Testing Entry<br/>Test basis: rule, transition,<br/>decision table hoặc acceptance criteria]
    T[Testing<br/>Test basis và kết quả]
    XT[Testing Exit<br/>Kết quả test liên kết rule/transition;<br/>lỗi hoặc phần chưa kiểm tra ghi rõ]
    ER[Release Entry<br/>Kết quả Testing và phạm vi thay đổi xác định]
    R[Release<br/>Gói phát hành]
    XR[Release Exit<br/>Phiên bản, thay đổi, điều kiện theo dõi ghi nhận;<br/>không suy ra production approval]
    EO[Operations Entry<br/>Thay đổi đã phát hành và tín hiệu vận hành hoặc ngoại lệ]
    O[Operations<br/>Theo dõi ngoại lệ]
    XO[Operations Exit<br/>Ngoại lệ phân loại: defect, change request,<br/>project assumption cần kiểm chứng<br/>hoặc verification-required claim]

    ED --> D --> XD --> EA --> A --> XA --> EDE --> DE --> XDE --> ET --> T --> XT --> ER --> R --> XR --> EO --> O --> XO
    XO -. Bằng chứng mới .-> ED

Pha	Entry gate chính xác	Hoạt động với rule, state, decision	Exit gate chính xác
Discovery	Có vấn đề nghiệp vụ, phạm vi ban đầu và nguồn đầu vào được phân loại.	Ghi nhận nhu cầu, phân biệt stakeholder input với verified fact, project assumption và verification-required claim.	Mỗi phát biểu có nguồn, ngữ cảnh và trạng thái bằng chứng; chưa gọi là rule đã xác nhận.
Analysis	Có đầu vào Discovery đủ truy vết.	Mô hình hóa state, transition, điều kiện quyết định, ngoại lệ và dữ liệu cần kiểm tra.	Rule có ID canonical khi đã đăng ký; state/decision có điều kiện, kết quả, traceability và acceptance criteria kiểm tra được.
Delivery	Có đặc tả Analysis không mâu thuẫn nội bộ.	Chuyển rule thành cấu hình, logic hoặc giao diện; giữ liên kết về rule và acceptance criteria.	Có bằng chứng phần build bám đặc tả hoặc có sai lệch được ghi nhận; không tự đổi ý nghĩa rule trong build.
Testing	Có test basis: rule, state transition, decision table hoặc acceptance criteria.	Thiết kế và chạy kiểm thử hộp đen, gồm nhánh đúng, nhánh sai và ngoại lệ.	Kết quả test liên kết từng rule/transition; lỗi hoặc phần chưa kiểm tra được ghi rõ.
Release	Có kết quả Testing và phạm vi thay đổi xác định.	Xác nhận gói phát hành không làm mất traceability rule-to-test.	Phiên bản, thay đổi và điều kiện theo dõi sau phát hành được ghi nhận; không suy ra production approval.
Operations	Có thay đổi đã phát hành và tín hiệu vận hành hoặc ngoại lệ.	Theo dõi ngoại lệ, lỗi quyết định, dữ liệu bất thường; đưa bằng chứng mới về Discovery.	Ngoại lệ được phân loại thành defect, change request, project assumption cần kiểm chứng hoặc verification-required claim.

Reasoning bridge: Discovery không đủ để viết logic vì phát biểu của stakeholder mới là đầu vào. Testing không thể kiểm tra “hệ thống phải đúng” vì câu này không cho điều kiện hay kết quả mong đợi. Do đó Analysis phải tạo rule, state transition và acceptance criteria trước Delivery và Testing.

Applied

Facts: Nova Foods là case mô phỏng giáo dục, dữ liệu tổng hợp. Một đơn bán hàng có thể ở state DRAFT, SUBMITTED, APPROVED hoặc REJECTED.

Current Behavior: Stakeholder input nói rằng đơn vượt hạn mức tín dụng “không nên được duyệt”. Câu này chưa nêu hạn mức nào, dữ liệu nào quyết định, hay kết quả khi vượt hạn mức.

Underlying Need: Cần ngăn transition từ SUBMITTED sang APPROVED khi dữ liệu đánh giá tín dụng trả về kết quả không đạt, đồng thời giữ bằng chứng để test.

Options: (1) Ghi câu stakeholder input trực tiếp vào ticket Delivery. (2) Phân tích thành điều kiện transition và decision table trước Delivery. Option (1) nhanh nhưng không tạo test basis đủ rõ. Option (2) thêm bước Analysis nhưng tạo điều kiện kiểm tra được.

Decision Criteria: Điều kiện phải chỉ rõ state đầu, dữ liệu đầu vào, phép so sánh, state kết quả và hành vi ngoại lệ. Cần giữ traceability về nguồn phát biểu.

Decision: Chọn Option (2). Analysis tạo project assumption: CreditAssessmentResult = FAIL chặn transition SUBMITTED sang APPROVED. Giá trị hạn mức, cách đánh giá tín dụng và trách nhiệm pháp lý là Verification required, không suy diễn từ case mô phỏng.

Authority: Không có authority record hoặc approval được cung cấp. Quyết định trên là quyết định học liệu về cách phân tích, không là quyết định vận hành Nova Foods.

Artifact: Liên kết tới CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY và test basis trong pha Testing; giữ nguyên trạng thái IN_REVIEW.

Consequence if Wrong: Nếu Delivery hiểu “không nên” là cảnh báo thay vì chặn transition, hệ thống có thể duyệt đơn sai. Nếu Testing không có điều kiện FAIL, test không chứng minh được hành vi chặn.

Senior Lens

Gate tốt kiểm tra khả năng chuyển pha, không kiểm tra cảm giác “đã phân tích đủ”. Ví dụ, exit Analysis đạt khi tester có thể tạo ca kiểm thử độc lập từ điều kiện và kết quả. Nếu tester phải hỏi BA “vượt hạn mức nghĩa là gì?”, exit gate chưa đạt.

Không dùng nguồn luật hoặc chuẩn để tự tạo rule ERP. ISO/IEC/IEEE 29148 được dùng trong phạm vi thuật ngữ requirement; ISTQB CTFL dùng cho thuật ngữ test basis và kiểm thử hộp đen. Các nguồn này không xác nhận cấu hình Nova Foods mô phỏng. Mọi yêu cầu liên quan pháp lý, kế toán, thuế, dữ liệu cá nhân hoặc an toàn thực phẩm vẫn cần nhãn Verification required và xác minh bởi vai trò có thẩm quyền.

Quick Reference

Kiểm tra trước chuyển pha	Đạt khi
Discovery sang Analysis	Nguồn phát biểu và loại bằng chứng rõ.
Analysis sang Delivery	Rule/state/decision có điều kiện và kết quả kiểm tra được.
Delivery sang Testing	Build hoặc sai lệch so với đặc tả được ghi nhận.
Testing sang Release	Có kết quả test truy vết về rule và transition.
Release sang Operations	Có phạm vi thay đổi và điều kiện theo dõi được ghi nhận.
Operations về Discovery	Ngoại lệ được phân loại, không tự biến thành rule mới.

Core

Owner là vai trò chịu trách nhiệm tạo, kiểm tra hoặc quyết định một artifact. Handoff là bàn giao có kiểm soát: bên gửi nêu artifact, trạng thái, vấn đề mở và giới hạn dùng; bên nhận xác nhận đủ đầu vào để tiếp tục. Owner không đồng nghĩa người có quyền phê duyệt.

Luồng	Upstream owner và bàn giao	Downstream owner nhận	Giới hạn thẩm quyền	Escalation
Quy tắc nghiệp vụ	Business Owner cung cấp mục tiêu, ngoại lệ nghiệp vụ và bằng chứng mô phỏng; BA ghi vào CANONICAL_BUSINESS_RULES	Architect, QA, Delivery dùng rule đã truy vết	BA không tự xác nhận rule đúng cho vận hành	Business Owner khi mục tiêu hoặc ưu tiên mâu thuẫn
Trạng thái ERP	BA mô tả state, transition và điều kiện; Data Owner kiểm tra nghĩa dữ liệu trong CANONICAL_DATA_DICTIONARY	Architect thiết kế kỹ thuật; QA lập test basis	BA không chọn cấu hình ERP hoặc mô hình dữ liệu triển khai	Architect khi transition ảnh hưởng tích hợp, phân quyền hoặc kiến trúc
Dữ liệu nhạy cảm	BA gắn rủi ro và nguồn; Security/Legal Owner đánh giá	Delivery và QA nhận yêu cầu kiểm soát đã được xác minh	BA không kết luận tuân thủ pháp luật hay bảo mật	Legal Owner hoặc Security Owner ngay khi có dữ liệu cá nhân, quyền truy cập, lưu trữ hoặc truyền dữ liệu
Quy tắc kế toán, thuế, hóa đơn	BA ghi nhận nhu cầu và nhãn Verification required	Accounting Owner xác nhận diễn giải; QA nhận tiêu chí đã xác minh	BA không diễn giải Luật Kế toán hoặc Nghị định 123/2020/NĐ-CP	Accounting Owner và Legal Owner trước khi rule được dùng làm yêu cầu

Cơ sở: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đều IN_REVIEW, v0.9.0, ngày 2026-08-07; vì chưa có baseline hay approval reference, không bên nào được gọi nội dung là đã phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng, chỉ dùng dữ liệu tổng hợp.

Applied

Mục	Nội dung mô phỏng Nova Foods
Facts	Đề xuất: đơn hàng bán chỉ chuyển từ PENDING_CREDIT sang RELEASED_FOR_FULFILLMENT khi khách hàng đạt điều kiện tín dụng.
Current Behavior	Chưa có rule canonical hay bằng chứng cấu hình ERP. CANONICAL_BUSINESS_RULES đang IN_REVIEW; vì vậy không thể coi đề xuất là hành vi hệ thống.
Underlying Need	Kho vận cần biết đơn nào được phép xử lý; Finance cần kiểm soát rủi ro công nợ.
Options	(1) BA tự ghi ngưỡng tín dụng; (2) Business Owner quyết định nhu cầu, Accounting Owner xác minh tiêu chí tín dụng, Architect đánh giá khả thi kỹ thuật.
Decision Criteria	Quyết định phải có owner nghiệp vụ, nguồn dữ liệu tín dụng xác định, xử lý ngoại lệ, tác động phân quyền và test basis truy vết.
Decision	Chọn phương án (2), vì ngưỡng tín dụng là quyết định nghiệp vụ/tài chính, không phải quyền của BA.
Authority	Business Owner quyết định mục tiêu và ngoại lệ; Accounting Owner xác minh nội dung tài chính; Architect quyết định cách triển khai; QA xác nhận kiểm thử. BA duy trì traceability.
Artifact	BA ghi đề xuất và liên kết đúng ID vào CANONICAL_BUSINESS_RULES; nghĩa trường tín dụng liên kết CANONICAL_DATA_DICTIONARY; định danh liên kết theo TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Nếu BA tự đặt ngưỡng, đơn hàng có thể bị chặn hoặc phát hành sai. Đây là rủi ro vận hành mô phỏng, không phải kết luận về Nova Foods thực tế.

Senior Lens

Escalate ngay khi một handoff chứa quyết định thuộc hai nhóm thẩm quyền. Ví dụ, trạng thái RELEASED_FOR_FULFILLMENT vừa ảnh hưởng công nợ vừa kích hoạt tích hợp kho: Business Owner và Accounting Owner xử lý ý nghĩa nghiệp vụ; Architect xử lý tích hợp. Lý do: cùng một state có thể đúng về nghiệp vụ nhưng không khả thi hoặc không an toàn về kỹ thuật.

BA phải bàn giao bằng câu kiểm soát: “Đây là đề xuất IN_REVIEW, nguồn là dữ liệu mô phỏng, phần tài chính cần Verification required.” Câu này giữ ranh giới nguồn và ngăn downstream owner hiểu nhầm draft là chỉ dẫn production.

Quick Reference

Tình huống	BA làm	BA không làm
Rule mâu thuẫn	Ghi rõ hai cách hiểu, bằng chứng và owner cần quyết định	Tự chọn cách hiểu thuận tiện
Thiếu owner	Dừng chuyển handoff, escalation tới vai trò có thẩm quyền	Gán owner giả định
Legal, accounting, privacy, food safety	Gắn Verification required, chuyển Legal/Accounting/domain owner	Diễn giải thành nghĩa vụ bắt buộc
Artifact chưa baseline	Giữ IN_REVIEW, v0.9.0 và traceability	Gọi là approved hoặc baselined

Core

Bản đồ vòng đời cho thấy phân tích quy tắc nghiệp vụ, trạng thái và quyết định đi cùng yêu cầu từ lúc phát hiện nhu cầu đến khi hệ thống vận hành. Nó không chứng minh quy tắc đã được phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; trạng thái corpus hiện là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

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

flowchart LR
    D[Discovery<br/>Phát hiện vấn đề, mục tiêu] --> A[Analysis<br/>Mô hình trạng thái, quy tắc, quyết định]
    A --> DE[Delivery<br/>Cấu hình, phát triển, tài liệu triển khai]
    DE --> T[Testing<br/>Kiểm thử theo quy tắc và chuyển trạng thái]
    T --> R[Release<br/>Phát hành kiểm soát]
    R --> O[Operations<br/>Vận hành, theo dõi ngoại lệ]
    O -->|Sự cố, ngoại lệ, thay đổi nhu cầu| D

    A -.-> X1[Artifact phân tích:<br/>state model, decision table,<br/>rule traceability]
    DE -.-> X2[Artifact giao hàng:<br/>cấu hình hoặc đặc tả kỹ thuật]
    T -.-> X3[Artifact kiểm thử:<br/>test basis, test case, kết quả]
    O -.-> X4[Artifact vận hành:<br/>log ngoại lệ, yêu cầu thay đổi]

Sơ đồ dùng mũi tên liền cho luồng giá trị chính và mũi tên nét đứt cho artifact hỗ trợ. Vòng quay từ Operations về Discovery có lý do: ngoại lệ thực tế có thể lộ ra trạng thái thiếu, điều kiện quyết định mơ hồ, hoặc dữ liệu đầu vào chưa được kiểm soát. Đây là phản hồi để phân tích lại, không phải quyền tự sửa quy tắc trong production.

Applied

Trường	Nội dung mô phỏng Nova Foods
Facts	Đơn bán hàng SO-SIM-00017 có thể ở Draft, Submitted, Credit Hold, Approved, Released, Cancelled.
Current Behavior	Nhân viên bán hàng thấy đơn bị chặn tín dụng nhưng không thấy điều kiện dẫn tới trạng thái Credit Hold.
Underlying Need	Chuỗi trạng thái phải giải thích được vì sao đơn dừng, ai xử lý tiếp, và dữ liệu nào quyết định chuyển trạng thái.
Options	Vẽ flowchart tự do; lập bảng trạng thái; kết hợp state model với decision table.
Decision Criteria	Người mới đọc hiểu được luồng; QA tạo được test case; kỹ thuật truy được điều kiện; vận hành nhận diện được ngoại lệ.
Decision	Dùng state model cho chuyển trạng thái và decision table cho điều kiện tín dụng. Lý do: trạng thái trả lời “đơn đang ở đâu”; bảng quyết định trả lời “vì sao đơn chuyển hoặc không chuyển”.
Authority	BA ghi nhận và truy vết mô hình. Business Owner xác nhận ý nghĩa nghiệp vụ; Finance/Accounting Owner xác nhận điều kiện tín dụng; Architect xác nhận khả năng kỹ thuật; QA xác nhận test basis.
Artifact	Tham chiếu kế hoạch canonical: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY. Không tạo rule vận hành mới trong handbook.
Consequence if Wrong	Đơn có thể được phát hành sai trạng thái, kiểm thử bỏ sót nhánh chặn, hoặc vận hành xử lý thủ công không nhất quán.

Senior Lens

Không nhầm “vòng đời của yêu cầu” với “vòng đời của đơn bán hàng”. Discovery đến Operations là vòng đời thay đổi của sản phẩm và quy tắc; Draft đến Released là vòng đời dữ liệu nghiệp vụ trong ERP. Hai vòng đời liên hệ qua artifact phân tích, nhưng không thay thế nhau. Bằng chứng là một thay đổi quy tắc có thể đi qua Discovery, Analysis, Delivery, Testing, Release và Operations, trong khi mỗi đơn bán hàng chỉ đi qua các trạng thái nghiệp vụ được mô hình hóa.

Quick Reference

Thành phần	Câu hỏi kiểm tra
Discovery	Vấn đề nào khiến cần xem lại quy tắc hoặc trạng thái?
Analysis	Trạng thái, sự kiện, điều kiện và ngoại lệ nào phải được mô hình hóa?
Delivery	Artifact phân tích nào được chuyển thành cấu hình hoặc đặc tả kỹ thuật?
Testing	Mỗi nhánh quyết định và chuyển trạng thái có test basis không?
Release	Thay đổi nào được đưa vào phạm vi phát hành kiểm soát?
Operations	Ngoại lệ nào tạo bằng chứng để quay lại phân tích?

4. Input c?n thi?t

Core

Phân tích quy tắc nghiệp vụ và trạng thái cần đầu vào trước khi vẽ sơ đồ. Quy tắc nghiệp vụ là điều kiện quyết định dữ liệu hoặc hành động nào được phép. Trạng thái là vị trí hiện tại của một đối tượng nghiệp vụ, ví dụ đơn hàng đang Draft hay Released. Không có đầu vào, BA chỉ đoán; mô hình tạo ra không truy được về nguồn.

Người mới không cần biết lập trình. Cần phân biệt bốn loại đầu vào: kiến thức nền để hiểu từ ngữ; bằng chứng để chứng minh nhận định; artifact nguồn để biết nội dung nằm ở đâu; ID canonical để liên kết ổn định giữa artifact.

Loại đầu vào	Câu hỏi nền tảng	Ví dụ Nova Foods mô phỏng
Kiến thức nền	Đối tượng nào đang được quản lý?	Đơn bán hàng, khách hàng, hạn mức tín dụng, phiếu xuất kho
Bằng chứng	Điều gì cho thấy hành vi hiện tại hoặc nhu cầu tồn tại?	Quy trình mô phỏng, bảng dữ liệu mô phỏng, ghi nhận workshop được kiểm soát
Artifact nguồn	Nội dung được quản lý trong tệp nào?	/01-curriculum/CANONICAL_BUSINESS_RULES.md
ID canonical	Tham chiếu nào không đổi khi tên hiển thị thay đổi?	CANONICAL_BUSINESS_RULES

ID canonical không phải tên gọi tự do. CANONICAL_BUSINESS_RULES luôn chỉ catalog quy tắc nghiệp vụ theo kế hoạch; CANONICAL_DATA_DICTIONARY luôn chỉ từ điển dữ liệu logic; TRACEABILITY_ID_REGISTRY luôn chỉ registry định danh. Giữ nguyên chuỗi ID giúp BA, QA và Architect truy cùng một nguồn, không suy diễn từ bản sao hoặc tên tệp gần giống.

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

flowchart LR
    K[Kiến thức nền] --> M[BA mô hình hóa]
    E[Bằng chứng] --> M
    A[Artifact nguồn] --> M
    I[ID canonical] --> T[Liên kết truy vết]
    M --> T
    T --> R[Quy tắc và trạng thái có nguồn]

Applied

Facts: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; toàn bộ dữ liệu là tổng hợp. Corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không có baseline reference hoặc approval reference được ghi nhận.

Current Behavior: Người học thấy trạng thái như Draft và Released trong ví dụ trước, nhưng chưa được phép coi chúng là cấu hình ERP thật hoặc quy tắc vận hành đã xác nhận.

Underlying Need: BA cần gom đúng nguồn trước khi mô tả điều kiện chuyển trạng thái. Lý do: trạng thái chỉ có nghĩa khi gắn với đối tượng dữ liệu, quy tắc và nguồn chứng cứ xác định.

Options: Dùng ghi nhớ cá nhân; dùng tên tệp không kiểm soát; hoặc dùng artifact nguồn cùng ID canonical.

Decision Criteria: Tham chiếu phải truy được, giữ nguyên định danh, không biến nội dung mô phỏng thành quyết định vận hành, không vượt thẩm quyền Business Owner, Legal Owner, Accounting Owner, Security hoặc Architect.

Decision: Dùng artifact kiểm soát và ID canonical dưới đây làm đầu vào phân tích. Đây là quyết định phương pháp học liệu, không phải rule mới cho Nova Foods.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết artifact. Owner không xác nhận quy tắc Nova Foods, không thiết lập baseline, không ghi nhận approval.

Artifact: /02-handbook/08-business-rules-state-and-decision-analysis.md tham chiếu các artifact nguồn dưới đây.

Consequence if Wrong: Một rule có thể bị gán nhầm nguồn, QA không truy được test basis, hoặc người đọc hiểu sai nội dung mô phỏng thành yêu cầu production.

Nội dung cần biết	Bằng chứng hoặc nguồn	Phân loại nguồn	Artifact nguồn	ID canonical giữ nguyên	Cầu nối suy luận
Cấu trúc chapter và đường dẫn handbook	Manifest xác định chapter là artifact có kiểm soát	Controlled planning artifact	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Manifest kiểm soát cấu trúc; vì vậy không tự đổi tên hoặc đường dẫn chapter
Quy tắc nghiệp vụ là gì và được quản lý ở đâu	Catalog quy tắc canonical được lập kế hoạch	Controlled planning artifact	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Catalog là nguồn liên kết rule; handbook không thay catalog tạo rule vận hành
Đối tượng và thuộc tính dữ liệu là gì	Từ điển dữ liệu logic canonical được lập kế hoạch	Controlled planning artifact	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Trạng thái phải thuộc một đối tượng dữ liệu; từ điển là điểm kiểm tra nghĩa dữ liệu
ID nào dùng để liên kết artifact	Registry định danh canonical được lập kế hoạch	Controlled planning artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	Registry ngăn BA tự đặt ID khác cho cùng một đối tượng
Thuật ngữ BA nền tảng	BABOK Guide Version 3, overview và errata chính thức	Primary official source	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Không áp dụng	Nguồn dùng cho thuật ngữ BA; không suy diễn số trang hoặc điều khoản chưa truy cập văn bản cấp phép
Ký pháp mô hình	UML 2.5.1 và BPMN 2.0.2 từ OMG	Primary official source	https://www.omg.org/spec/UML/2.5.1/About-UML/; https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/	Không áp dụng	UML/BPMN là nguồn ký pháp; sơ đồ Mermaid trong handbook là sơ đồ minh họa, không được gọi là BPMN
Bối cảnh Nova Foods	Case study giáo dục, Việt Nam, vi-VN, Asia/Ho_Chi_Minh, VND	Controlled curriculum context	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	01_CURRICULUM_ARCHITECTURE	Metadata xác định phạm vi mô phỏng; vì vậy mọi ví dụ chỉ là dữ liệu tổng hợp

Senior Lens

Một input tốt không phải “nhiều tài liệu”. Input tốt trả lời được ba câu: nội dung này nói về đối tượng nào; nguồn nào chịu trách nhiệm cho nội dung đó; ID nào giúp người khác tìm lại đúng nguồn. Ví dụ, nếu nói “đơn hàng chỉ được phát hành khi đủ điều kiện”, BA phải tách: đối tượng đơn hàng thuộc dữ liệu; điều kiện thuộc rule; cách liên kết thuộc registry. Ba phần này không nên bị gộp thành một câu không nguồn.

Không nâng cấp độ tin cậy của nguồn qua cách viết. Trang chuẩn chính thức hỗ trợ thuật ngữ hoặc ký pháp trong phạm vi công bố. Artifact IN_REVIEW hỗ trợ truy vết nội bộ có kiểm soát, nhưng không chứng minh nội dung đã được baseline, phê duyệt, tuân thủ pháp luật hoặc sẵn sàng production.

Quick Reference

Khi cần	Lấy từ đâu	Không được làm
Hiểu nghĩa rule và state	Kiến thức BA, mô hình dữ liệu, artifact nguồn	Tự biến ví dụ thành rule thật
Liên kết requirement, rule, data, test	TRACEABILITY_ID_REGISTRY	Đổi hoặc rút gọn ID canonical
Xác định nơi quản lý rule	CANONICAL_BUSINESS_RULES	Dùng handbook thay thế catalog
Xác định nghĩa đối tượng và trường dữ liệu	CANONICAL_DATA_DICTIONARY	Đoán nghĩa từ tên trường
Dùng chuẩn nghề nghiệp	URL nguồn chính thức trong source seed	Bịa điều khoản, trang hoặc trích dẫn

Core

Kiểm tra chất lượng đầu vào là lọc bằng chứng trước khi suy luận quy tắc. BA không biến nguồn thiếu, cũ, mâu thuẫn hoặc vượt thẩm quyền thành business rule. 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.

Kiểm tra	Tiêu chí đạt	Bằng chứng cần lưu	Hành động khi không đạt
Định danh	Artifact ID, filename, version khớp nguồn canonical	ID và đường dẫn nguyên dạng	Dừng liên kết; không tự đổi ID
Phân loại nguồn	Nguồn có nhãn primary, controlled planning, derived, assumption hoặc Verification required	Nhãn nguồn trong bảng phân tích	Gắn lại nhãn; không suy luận nghĩa vụ
Tính mới	Ngày truy cập, ngày cập nhật, version và timezone rõ	2026-08-07, Asia/Ho_Chi_Minh	Dừng nếu nguồn pháp lý hoặc chuẩn không rõ phiên bản
Thẩm quyền	Owner nguồn đúng phạm vi quyết định	Owner và giới hạn thẩm quyền	Escalate đúng vai trò; BA không tự xác nhận
Nhất quán	Không mâu thuẫn giữa nguồn canonical	So sánh ID, status, version, boundary	Dừng phân tích đến khi có kết luận được ghi nhận
Khả dụng	Có thể truy cập nguồn hoặc biết rõ giới hạn licensed text	URL chính thức hoặc đường dẫn corpus	Không bịa clause, trích dẫn, hoặc nội dung không thấy

Phân loại nguồn quyết định mức suy luận. Primary source là nguồn phát hành chính thức, như ISO, OMG, IIBA hoặc văn bản pháp luật. Controlled planning artifact là artifact corpus có quản trị nhưng chưa phải quy tắc vận hành. Derived analysis là nhận định BA rút từ nguồn, phải chỉ rõ cầu nối bằng chứng. Project assumption là giả định học liệu, không phải sự thật Nova Foods. Verification required là điểm chưa đủ bằng chứng hoặc cần chủ sở hữu chuyên môn xác nhận.

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

flowchart TB
    A[Nhận đầu vào] --> B{Artifact ID, filename và version khớp nguồn canonical?}
    B -- Không --> S[STOP — INPUT NOT USABLE]
    B -- Có --> C{Nhãn nguồn hợp lệ?}

    C -- Không --> C1{Gắn lại nhãn được?}
    C1 -- Có --> C6[Gắn lại nhãn nguồn]
    C6 --> C
    C1 -- Không --> S
    C -- Có --> T{Loại nguồn?}

    T -- Primary source --> F
    T -- Controlled planning artifact --> C2[Không suy luận thành quy tắc vận hành]
    T -- Derived analysis --> C3{Có cầu nối bằng chứng?}
    T -- Project assumption --> C4[Không coi là sự thật Nova Foods]
    T -- Verification required --> C5[Đánh dấu cần owner xác nhận]

    C2 --> F
    C3 -- Có --> F
    C3 -- Không --> X[Bổ sung cầu nối bằng chứng]
    C4 --> F
    C5 --> F

    X --> X1{Có thể bổ sung?}
    X1 -- Có --> C3
    X1 -- Không --> S

    F{Ngày truy cập, ngày cập nhật, version và timezone rõ?}
    F -- Có --> D
    F -- Không --> F1{Nguồn pháp lý hoặc tiêu chuẩn không rõ version?}
    F1 -- Có --> S
    F1 -- Không --> X3{Có thể bổ sung?}
    X3 -- Có --> X2[Bổ sung bằng chứng]
    X2 --> F
    X3 -- Không --> S

    D{Owner có thẩm quyền trong phạm vi quyết định?}
    D -- Không --> E[Escalate đúng owner]
    E --> S
    D -- Có --> K

    K{Truy cập được nguồn hoặc biết rõ giới hạn licensed text?}
    K -- Không --> K1[Không suy luận clause, trích dẫn hoặc nội dung không thấy]
    K1 --> S
    K -- Có --> M

    M{Có mâu thuẫn giữa nguồn canonical?}
    M -- Có --> M1[Dừng đến khi có kết luận được ghi nhận]
    M1 --> S
    M -- Không --> L

    L{Có điểm chưa xác minh hoặc nhãn Verification required?}
    L -- Không --> H[Đủ điều kiện phân tích theo giới hạn loại nguồn]
    L -- Có --> L2{Đúng owner đã xác minh và ghi nhận?}
    L2 -- Có --> H
    L2 -- Không --> S

Applied

Facts: /01-curriculum/CANONICAL_BUSINESS_RULES.md có Artifact ID CANONICAL_BUSINESS_RULES, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07. Tài liệu nêu Owner không có quyền xác nhận quy tắc là đúng cho vận hành thực tế.

Current Behavior: BA tìm thấy mô tả về catalog quy tắc và muốn dùng ngay làm bằng chứng rằng một rule ERP Nova Foods đã được chấp thuận.

Underlying Need: Phân biệt “có artifact quản trị” với “có rule nghiệp vụ đã được phê duyệt”. Cầu nối bằng chứng: status IN_REVIEW và không có baseline hoặc approval reference. Vì vậy không đủ căn cứ gọi rule là bắt buộc.

Options: (1) Gọi nội dung là rule đã áp dụng. (2) Gắn Controlled planning artifact và chỉ dùng để truy vết cấu trúc. (3) Dừng phân tích cho đến khi có nguồn nghiệp vụ có thẩm quyền.

Decision Criteria: Giữ đúng ID; không vượt giới hạn Owner; không biến planning artifact thành approval; bảo toàn nhãn chưa xác minh.

Decision: Chọn (2). Dùng CANONICAL_BUSINESS_RULES làm nguồn quản trị và gắn mọi nội dung rule chưa có bằng chứng nghiệp vụ là Verification required.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata; Business Owner xác nhận nghiệp vụ; Legal, Accounting, Security hoặc Architect xác nhận nội dung thuộc phạm vi họ.

Artifact: /01-curriculum/CANONICAL_BUSINESS_RULES.md, CANONICAL_BUSINESS_RULES, IN_REVIEW, v0.9.0.

Consequence if Wrong: Rule mô phỏng có thể bị hiểu thành cấu hình ERP, nghĩa vụ pháp lý hoặc quyết định vận hành. Traceability sai từ nguồn đến requirement và test basis.

Senior Lens

Freshness không chỉ là ngày gần nhất. Nguồn còn mới khi version, trạng thái, ngày truy cập và phạm vi hiệu lực đều phù hợp quyết định đang phân tích. Ví dụ, URL pháp lý truy cập ngày 2026-08-07 vẫn không đủ để kết luận yêu cầu hệ thống nếu cần diễn giải pháp lý; phải gắn Verification required và chuyển Legal Owner.

Loại nguồn	Freshness tối thiểu	Owner kiểm tra	Điều kiện dừng
Primary source pháp lý	URL chính thức, hiệu lực, lần sửa đổi cần kiểm tra	Legal Owner	Thiếu diễn giải pháp lý có thẩm quyền
Primary source chuẩn	Version và trạng thái xuất bản rõ	BA cùng chuyên gia phù hợp	Cần clause licensed text nhưng không truy cập được
Controlled planning artifact	ID, filename, Status, Version, ngày cập nhật khớp	Artifact Owner	ID hoặc metadata mâu thuẫn
Derived analysis	Nêu rõ nguồn gốc và suy luận	BA reviewer	Suy luận vượt quá bằng chứng
Project assumption	Gắn nhãn, phạm vi, lý do dùng	Business Owner hoặc người được chỉ định	Bị viết như fact hoặc rule bắt buộc
Verification required	Câu hỏi, owner xác minh, tác động rõ	Owner chuyên môn	Không có owner hoặc câu hỏi chặn quyết định

Quick Reference

• Chỉ dùng nguồn canonical với ID và filename nguyên dạng.
• IN_REVIEW không có nghĩa APPROVED, BASELINED, compliant hoặc production-ready.
• Nguồn pháp lý, kế toán, thuế, an toàn thực phẩm, privacy cần owner chuyên môn xác minh trước khi thành requirement.
• Dừng phân tích khi thiếu ID, thiếu version, sai owner, mâu thuẫn nguồn, hoặc nội dung chưa xác minh bị yêu cầu thành quyết định bắt buộc.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ giá trị dưới đây là dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Bảng input này không xác nhận cấu hình ERP, quy tắc vận hành, tuân thủ pháp lý hay phê duyệt.

Input ID	Input cần có	Giá trị Nova Foods tổng hợp	Nguồn artifact canonical	Phân loại nguồn	Owner nguồn	Freshness	Trạng thái xác minh	Mục đích cho phân tích rule/state
SRC-001	Thuật ngữ trạng thái đơn hàng	Draft, Submitted, IN_REVIEW, Approved, Rejected, Cancelled	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Planned canonical catalog	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	IN_REVIEW	Nhận diện tập trạng thái, không suy diễn chuyển trạng thái hợp lệ.
BR-NF-SO-001	Quy tắc xét duyệt Sales Order	Đơn bán SO-NF-2026-00017, tổng tiền tổng hợp 128.500.000 VND, trạng thái hiện tại IN_REVIEW	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Planned business-rule source	Business Owner: Verification required	2026-08-07	Verification required	Làm input để phân tích điều kiện, quyết định và ngoại lệ; chưa là rule áp dụng.
DD-NF-SO-001	Dữ liệu logical của Sales Order	SalesOrderId, CustomerId, OrderTotalVND, ApprovalStatus, CreatedAt	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Planned logical data dictionary	Data Owner: Verification required	2026-08-07	IN_REVIEW	Kiểm tra field nào cung cấp fact cho rule.
IDR-NF-SO-001	Quy ước định danh	SalesOrderId = SO-NF-YYYY-NNNNN	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	IN_REVIEW	Giữ liên kết ổn định giữa fact, rule, decision và artifact.
PROC-NF-ORDER-001	Luồng nghiệp vụ mô phỏng	Tạo đơn, gửi xét duyệt, xét duyệt, từ chối, hủy	Chưa có artifact process canonical được cung cấp	Unresolved project input	Process Owner: Verification required	Không xác định	UNRESOLVED — Verification required	Không được vẽ BPMN hoặc khẳng định thứ tự xử lý khi chưa có nguồn quy trình.
AUTH-NF-APP-001	Ma trận thẩm quyền xét duyệt	Vai trò dự kiến: Sales Admin, Sales Manager, Finance Controller	Chưa có artifact authority canonical được cung cấp	Unresolved project input	Business Owner: Verification required	Không xác định	UNRESOLVED — Verification required	Không được gán ai có quyền Approved hoặc Rejected.
LEGAL-VN-PD-001	Ràng buộc 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=	Official legal source	Legal Owner	Truy cập 2026-08-07	Verification required	Chỉ đánh dấu điểm cần Legal Owner xác nhận nếu đơn hàng chứa dữ liệu cá nhân.
LEGAL-VN-ACC-001	Ràng buộc kế toán	Luật 88/2015/QH13; hiệu lực 2017-01-01	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Official legal source	Accounting Owner	Truy cập 2026-08-07	Verification required	Không suy diễn ngưỡng duyệt, bút toán hay nghĩa vụ kế toán.
EVD-NF-SO-001	Bằng chứng mẫu tổng hợp	SO-NF-2026-00017 do CUS-NF-00142 tạo lúc 2026-08-07T09:15:00+07:00; ApprovalStatus=IN_REVIEW	Case evidence trong handbook này	Synthetic educational evidence	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	IN_REVIEW	Minh họa fact đầu vào; không phải log production.
QRY-NF-APP-001	Câu hỏi chưa giải quyết	Ngưỡng tiền nào bắt buộc xét duyệt? Ai được hủy sau Approved? Có cho gửi lại sau Rejected không?	Issue log chưa được cung cấp	Unresolved verification item	Business Owner và Process Owner: Verification required	Không xác định	UNRESOLVED — STOP FOR RULE DECISION	Không tạo decision table hoàn chỉnh cho các câu hỏi này.

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

flowchart TB
    A[EVD-NF-SO-001<br/>Fact tổng hợp<br/>IN_REVIEW]
    B[DD-NF-SO-001<br/>Tên và nghĩa field<br/>IN_REVIEW]
    C[BR-NF-SO-001<br/>Rule candidate<br/>Verification required]

    A --> F[Phân tích cấu trúc input<br/>Không xác lập quyết định vận hành<br/>Không xác lập chuyển trạng thái]
    B --> F
    C --> F

    F --> R{Business Owner đã xác nhận<br/>rule và ngưỡng?}
    R -->|Chưa| X[STOP FOR RULE DECISION<br/>UNRESOLVED — Verification required]
    R -->|Có| S{Business Owner đã xác nhận<br/>AUTH-NF-APP-001?}

    S -->|Chưa| X
    S -->|Có| V{Process Owner đã xác nhận<br/>PROC-NF-ORDER-001?}

    V -->|Chưa| X
    V -->|Có| W{Business Owner và Process Owner<br/>đã giải quyết QRY-NF-APP-001?}

    W -->|Chưa| X
    W -->|Có| P{Legal Owner xác định đơn hàng<br/>có dữ liệu cá nhân thuộc phạm vi áp dụng?}

    P -->|Có| Q[LEGAL-VN-PD-001<br/>Kiểm tra phạm vi dữ liệu cá nhân]
    Q --> QG{Legal Owner đã xác nhận<br/>phạm vi áp dụng?}
    QG -->|Chưa| Y[STOP FOR DOMAIN VERIFICATION<br/>UNRESOLVED — Verification required]
    QG -->|Có| K{Accounting Owner xác định<br/>có diễn giải kế toán liên quan?}
    P -->|Không| K

    K -->|Có| T[LEGAL-VN-ACC-001<br/>Kiểm tra phạm vi diễn giải kế toán]
    T --> TG{Accounting Owner đã xác nhận<br/>phạm vi áp dụng?}
    TG -->|Chưa| Y
    TG -->|Có| N[Chỉ sau xác nhận của<br/>các owner liên quan]
    K -->|Không| N

    N --> M[Principal IT Business Analyst /<br/>Technical Curriculum Author<br/>cập nhật artifact canonical<br/>và traceability]
    M --> O[Có thể mô hình hóa quyết định<br/>và chuyển trạng thái đã xác nhận]

    X --> J[Giữ phân tích ở trạng thái<br/>UNRESOLVED]
    Y --> J

    J -. Ngoại lệ .-> U{Có bỏ qua STOP<br/>và tiếp tục mô hình hóa?}
    U -->|Có| Z[Rủi ro<br/>Trạng thái sai<br/>Quyền sai<br/>Thiếu bằng chứng kiểm tra<br/>Diễn giải pháp lý hoặc kế toán<br/>thành cấu hình ERP bắt buộc]
    U -->|Không| J

Facts: SO-NF-2026-00017 có ApprovalStatus=IN_REVIEW và OrderTotalVND=128.500.000 VND; bằng chứng là EVD-NF-SO-001.

Current Behavior: Chưa có nguồn canonical xác minh chuyển trạng thái hay thẩm quyền duyệt; vì vậy không thể khẳng định hệ thống phải duyệt, từ chối, hoặc tự động xử lý đơn này.

Underlying Need: BA cần đủ fact, định nghĩa field, rule, luồng và thẩm quyền trước khi mô hình hóa quyết định.

Options: Dùng giả định không nhãn; dừng phân tích quyết định; hoặc ghi rõ item chưa xác minh và chỉ phân tích cấu trúc input.

Decision Criteria: Chọn cách không biến dữ liệu tổng hợp thành quy tắc vận hành, không vượt thẩm quyền Business Owner, Process Owner, Legal Owner hoặc Accounting Owner, và giữ traceability bằng ID canonical.

Decision: Dùng EVD-NF-SO-001, DD-NF-SO-001 và BR-NF-SO-001 làm input IN_REVIEW; giữ PROC-NF-ORDER-001, AUTH-NF-APP-001, QRY-NF-APP-001 nhãn UNRESOLVED — Verification required.

Authority: Business Owner xác nhận rule và ngưỡng; Process Owner xác nhận luồng; Legal Owner và Accounting Owner xác nhận diễn giải thuộc phạm vi của họ. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact và traceability.

Artifact: /02-handbook/08-business-rules-state-and-decision-analysis.md, section 04-inputs; liên kết /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Consequence if Wrong: Rule sai có thể đưa đơn sang trạng thái sai, gán quyền sai, làm thiếu bằng chứng kiểm tra, hoặc diễn đạt nhầm yêu cầu pháp lý và kế toán thành cấu hình ERP bắt buộc.

5. Step-by-step BA Activities

Core

BA biến input IN_REVIEW thành gói phân tích có thể review. Mỗi bước phải giữ liên kết từ fact đến quyết định. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Applied

Facts: EVD-NF-SO-001 ghi đơn mô phỏng SO-NF-2026-001, OrderTotalVND=128.500.000 VND. DD-NF-SO-001 và BR-NF-SO-001 là input đang IN_REVIEW. PROC-NF-ORDER-001, AUTH-NF-APP-001, QRY-NF-APP-001 là UNRESOLVED — Verification required.

Current Behavior: Chưa có nguồn canonical xác minh state transition, ngưỡng duyệt, người duyệt, hoặc hành vi ERP khi rule không thỏa.

Underlying Need: BA cần tách fact đã có khỏi rule chưa xác minh. Lý do: số tiền đơn chỉ là data; không tự chứng minh điều kiện duyệt.

Options:
1. Suy diễn rule từ OrderTotalVND.
2. Ghi rule giả định không nhãn.
3. Giữ trạng thái IN_REVIEW, lập câu hỏi và chuyển đúng owner.

Decision Criteria: Giữ traceability; không biến data tổng hợp thành quy tắc vận hành; không vượt thẩm quyền Business Owner, Process Owner, Legal Owner, Accounting Owner.

Decision: Chọn phương án 3. Chỉ phân tích cấu trúc quyết định. Không chốt state, threshold, authority, hoặc ERP behavior.

Authority: Business Owner xác nhận rule nghiệp vụ. Process Owner xác nhận luồng. Legal Owner và Accounting Owner xác nhận nội dung thuộc pháp lý, hóa đơn, kế toán. Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và traceability.

Artifact: /02-handbook/08-business-rules-state-and-decision-analysis.md; liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: State sai có thể đưa đơn vào xử lý sai; quyền sai có thể cho phép hoặc chặn duyệt sai; thiếu evidence làm QA không tạo được test basis.

#	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1	BA	Khóa phạm vi phân tích	SO-NF-2026-001, EVD-NF-SO-001	Danh sách fact và source ID	Chỉ dùng source có ID, status, đường dẫn canonical	Không có fact không nguồn	Source mâu thuẫn: Principal IT Business Analyst / Technical Curriculum Author
2	BA	Phân loại input	DD-NF-SO-001, BR-NF-SO-001, PROC-NF-ORDER-001, AUTH-NF-APP-001, QRY-NF-APP-001	Bảng verified, unresolved, Verification required	Chỉ item verified mới làm fact; unresolved không thành rule	Mỗi item có nhãn trạng thái	Thiếu định nghĩa field: Data Owner; thiếu rule: Business Owner
3	BA	Viết câu quyết định	OrderTotalVND, state hiện có, role cần xác minh	Decision statement và câu hỏi mở	Mỗi điều kiện phải chỉ rõ input, operator, outcome, authority	Không có threshold, role, state được suy diễn	Rule hoặc ngưỡng: Business Owner; flow: Process Owner
4	BA	Mô hình hóa state và nhánh	State model logic cho đơn bán mô phỏng	Sơ đồ Mermaid và transition register	Transition chỉ là proposed nếu chưa có PROC-NF-ORDER-001 xác minh	Không gọi proposed là cấu hình ERP	State hoặc workflow: Process Owner; kiến trúc tích hợp: Architect
5	BA	Gắn traceability	Fact, field, rule, question, owner	Traceability row dùng ID canonical	Mỗi kết luận có evidence hoặc nhãn Verification required	Không có orphan requirement hoặc orphan decision	ID chưa đăng ký hoặc trùng: TRACEABILITY_ID_REGISTRY owner
6	Reviewer đúng thẩm quyền	Review gói phân tích	Rule, flow, authority question	Review record nêu accept, reject, hoặc question	Không có reviewer vượt phạm vi chuyên môn	Không dùng review như approval	Legal/privacy: Legal Owner; accounting: Accounting Owner; security: Security Owner
7	BA	Handoff có kiểm soát	Gói IN_REVIEW cho bước tiếp theo	Handoff list: artifact, version v0.9.0, date 2026-08-07, open issues	Handoff phải nêu rõ item chưa quyết định	Không ghi APPROVED, BASELINED, hoặc user-approved	Blocking question giữ IN_REVIEW; trả về owner tương ứng

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

flowchart TB
    A[BA nhận EVD-NF-SO-001] --> B[Fact: OrderTotalVND=128.500.000 VND]
    B --> C[Input IN_REVIEW: DD-NF-SO-001 và BR-NF-SO-001]
    C --> D[Input UNRESOLVED — Verification required: PROC-NF-ORDER-001, AUTH-NF-APP-001, QRY-NF-APP-001]
    D --> E{Mỗi ID đã đăng ký; source có status; có đường dẫn canonical?}
    B -. Data, không chứng minh threshold hoặc rule .-> E

    E -- Không --> F[BA gắn Verification required]
    F --> G{Loại vấn đề?}
    G -- ID chưa đăng ký hoặc trùng --> H[TRACEABILITY_ID_REGISTRY owner]
    G -- Source mâu thuẫn --> I[Principal IT Business Analyst / Technical Curriculum Author]
    G -- Định nghĩa field --> J[Data Owner]
    G -- Rule, threshold hoặc authority --> K[Business Owner]
    G -- Flow hoặc state --> L[Process Owner]
    G -- Hành vi ERP chưa xác minh --> M{Thuộc quy trình hay tích hợp?}
    M -- Quy trình --> L
    M -- Tích hợp --> N[Architect]
    G -- Legal hoặc privacy --> O[Legal Owner]
    G -- Hóa đơn hoặc kế toán --> P[Accounting Owner]
    G -- Security --> Q[Security Owner]

    H --> R[Owner trả lời hoặc xác nhận evidence]
    I --> R
    J --> R
    K --> R
    L --> R
    N --> R
    O --> R
    P --> R
    Q --> R
    R --> S[BA cập nhật evidence và traceability]
    S --> C

    E -- Có --> T[BA soạn decision statement]
    T --> U{Mỗi điều kiện có input, operator, outcome, authority; không suy diễn threshold, role, state?}
    U -- Không --> F
    U -- Có --> V[BA mô hình hóa state và nhánh]
    V --> W{Transition chưa xác minh đã gắn proposed; không gọi proposed là cấu hình ERP?}
    W -- Không --> F
    W -- Có --> X[Reviewer đúng thẩm quyền tạo review record]
    X --> Y{Kết quả review?}
    Y -- Reject --> F
    Y -- Question blocking --> F
    Y -- Accept, chỉ kết quả review, không phải approval --> Z{Evidence, traceability, requirement và decision đủ; không orphan?}

    Z -- Không --> AA[Không có test basis; state hoặc quyền sai có thể làm xử lý hoặc duyệt sai]
    AA --> F
    Z -- Có --> AB{Còn blocking question?}
    AB -- Có --> AC[BA giữ artifact IN_REVIEW]
    AC --> F
    AB -- Không --> AD[BA handoff có kiểm soát: artifact, v0.9.0, 2026-08-07, open issues và trạng thái chưa quyết định]
    AD --> AE[Artifact vẫn IN_REVIEW; không ghi APPROVED, BASELINED hoặc user-approved]

Senior Lens

Không hỏi “đơn 128.500.000 VND có cần duyệt không?” như câu hỏi yes/no. Hỏi đủ input, rule source, owner, state trước và state sau, exception, evidence, consumer. Lý do: cùng amount có thể khác outcome khi customer type, credit status, warehouse hold, hoặc policy version khác; các field này chưa được source seed xác minh.

Quick Reference

Kiểm tra	Đạt khi
Fact	Có evidence ID và không bị diễn giải quá source
Rule	Có source canonical hoặc nhãn Verification required
Authority	Có owner đúng phạm vi quyết định
Handoff	Giữ IN_REVIEW, version v0.9.0, date 2026-08-07
Traceability	Dùng nguyên dạng EVD-NF-SO-001, DD-NF-SO-001, BR-NF-SO-001

Core

Quy trình phân tích quy tắc nghiệp vụ cần biến một nhận định thành bằng chứng kiểm tra được. Mỗi bước phải chỉ rõ ai làm, làm trên đối tượng nào, tạo bằng chứng gì, khi nào được đi tiếp và ai xử lý xung đột. 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, phiên bản v0.9.0, ngày 2026-08-07. Không bước nào tạo phê duyệt, baseline hay quyết định vận hành thực.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Xác định quy trình, sự kiện kích hoạt, trạng thái và câu hỏi cần quyết định.	Yêu cầu, luồng nghiệp vụ, vấn đề được ghi nhận.	Bản ghi phạm vi phân tích, giả định và danh sách nguồn.	Chỉ nhận nội dung có nguồn hoặc được gắn Verification required.	Phạm vi nêu rõ điểm bắt đầu, kết thúc, ngoại lệ và hệ thống liên quan.	Business Owner khi mục tiêu nghiệp vụ mơ hồ; Architect khi ranh giới hệ thống mơ hồ.
2. Thu thập fact	BA, Subject Matter Expert (SME, chuyên gia nghiệp vụ)	Ghi nhận fact quan sát được, không đổi fact thành rule.	Biểu mẫu, báo cáo, màn hình, dữ liệu mẫu tổng hợp, mô tả quy trình.	Bảng fact có nguồn, ngày ghi nhận và chủ thể cung cấp.	Fact phải truy về nguồn xác định; lời kể không có đối chiếu là giả định.	Mỗi fact tách khỏi diễn giải, không chứa từ kết luận như “phải” nếu chưa xác nhận.	SME khi fact mâu thuẫn; Data Owner khi dữ liệu hoặc định nghĩa trường không rõ.
3. Mô hình hóa trạng thái	BA	Liệt kê state, event, transition, điều kiện vào-ra và trạng thái cấm.	Đối tượng nghiệp vụ, ví dụ Sales Order hoặc Batch.	Bảng state-transition và sơ đồ trạng thái.	Mỗi transition cần event kích hoạt, actor hoặc hệ thống kích hoạt, guard condition.	Không có transition mồ côi; mỗi trạng thái có ý nghĩa nghiệp vụ và trạng thái kết thúc rõ.	Business Owner khi quyền chuyển trạng thái chưa rõ; Architect khi transition phụ thuộc tích hợp.
4. Tách rule khỏi process	BA	Viết rule theo cấu trúc điều kiện, hành động, kết quả; liên kết rule với transition.	Fact đã xác minh, mô hình trạng thái.	Bản nháp rule và ma trận rule-to-state.	Rule phải kiểm tra được bằng dữ liệu đầu vào và kết quả mong đợi; không sao chép bước thao tác.	Không trùng rule; không dùng từ mơ hồ như “hợp lý”, “nhanh”, “đủ”.	Business Owner khi có lựa chọn chính sách; Legal, Accounting hoặc Compliance Owner khi rule chạm phạm vi chuyên môn của họ.
5. Phân tích quyết định	BA	So sánh các lựa chọn bằng tiêu chí, tác động và rủi ro.	Rule mâu thuẫn, ngưỡng, quyền hạn, ngoại lệ.	Decision log gồm option, tiêu chí, bằng chứng và owner quyết định.	BA trình bày trade-off; chỉ vai trò có thẩm quyền chọn chính sách.	Tiêu chí đo được, ví dụ kiểm soát rủi ro, khả năng vận hành, tác động dữ liệu, khả năng kiểm thử.	Business Owner cho chính sách nghiệp vụ; Architect cho khả thi kỹ thuật; Security cho kiểm soát truy cập.
6. Xác định kiểm thử	BA, QA	Chuyển rule thành điều kiện kiểm thử, gồm happy path, boundary và exception.	Rule, state-transition, dữ liệu mẫu tổng hợp.	Rule test matrix với input, expected result, rule reference.	Mỗi rule có ít nhất một ca đạt và một ca vi phạm; rule có ngưỡng phải có ca biên.	Kết quả mong đợi không dựa vào suy đoán giao diện hoặc cấu hình chưa xác định.	QA khi không thể kiểm thử khách quan; BA quay lại SME khi expected result thiếu.
7. Review và handoff kiểm soát	BA	Gửi gói phân tích, ghi nhận comment, trạng thái giải quyết và liên kết traceability.	Rule catalog dự kiến, data dictionary dự kiến, decision log, test matrix.	Review record, danh sách issue, liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY.	Chỉ handoff khi mọi mục có nguồn, owner, trạng thái và route xử lý; mục chưa xác minh giữ nhãn Verification required.	Không gọi nội dung là approved hoặc baselined khi chưa có tham chiếu ghi nhận trong artifact kiểm soát.	Principal IT Business Analyst / Technical Curriculum Author xử lý xung đột traceability; chuyên gia thẩm quyền xử lý nội dung chuyên môn.

Bằng chứng là vật kiểm tra được, không phải ý kiến. Ví dụ, “đơn hàng không được giao khi chưa đạt điều kiện” chỉ thành rule khi BA chỉ ra trạng thái hiện tại, event yêu cầu giao, điều kiện kiểm tra, kết quả chặn hoặc cho phép, nguồn fact và owner có thẩm quyền xác nhận chính sách.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, trạng thái artifact IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. BA dùng bảng này để biến quan sát vận hành thành quyết định có truy vết; không biến giả định thành quy tắc ERP.

Mục	Nội dung thực thi
Facts	Đơn bán SO-SIM-00128 có tổng giá trị 18.500.000 VND. Khách hàng mô phỏng CUS-SIM-042 có hạn mức tín dụng tổng hợp 50.000.000 VND; dư nợ mở tổng hợp 38.000.000 VND.
Current Behavior	Nhân viên bán hàng tạo đơn; ERP mô phỏng cho đơn sang CONFIRMED mà chưa kiểm tra tổng dư nợ sau đơn.
Underlying Need	Chặn xác nhận đơn khi tổng nghĩa vụ tín dụng vượt hạn mức, để giảm rủi ro giao hàng khi khách hàng vượt mức tín dụng được cấp. Đây là nhu cầu nghiệp vụ, chưa là cấu hình production.
Options	O1: luôn cho xác nhận. O2: chặn tự động khi vượt hạn mức. O3: cho xác nhận nhưng yêu cầu Credit Controller phê duyệt ngoại lệ.
Decision Criteria	Kiểm soát rủi ro tín dụng; không cản đơn hợp lệ; có dấu vết người quyết định; không để Sales tự vượt kiểm soát tín dụng.
Decision	Chọn O3: hệ thống chuyển đơn vượt hạn mức sang IN_REVIEW; chỉ Credit Controller được quyết định CONFIRMED hoặc REJECTED. Lý do: 38.000.000 + 18.500.000 = 56.500.000 VND, lớn hơn 50.000.000 VND.
Authority	Business Owner xác nhận chính sách thương mại; Credit Controller quyết định từng ngoại lệ; Accounting Owner xác minh cách tính dư nợ; Architect xác nhận khả năng tích hợp dữ liệu công nợ. Chưa có approval được ghi nhận.
Artifact	Bản ghi rule dự kiến trong CANONICAL_BUSINESS_RULES; định nghĩa trường trong CANONICAL_DATA_DICTIONARY; liên kết ID qua TRACEABILITY_ID_REGISTRY. Giữ nguyên phân loại IN_REVIEW.
Consequence if Wrong	Nếu tính thiếu dư nợ, đơn vượt hạn mức có thể được giao. Nếu chặn sai, đơn hợp lệ bị trì hoãn, ảnh hưởng doanh thu và cam kết khách hàng.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1	BA	Thu thập số liệu đầu vào	SO-SIM-00128, hạn mức, dư nợ mở	Bảng Facts có nguồn và thời điểm tổng hợp	Không dùng số liệu không xác định nguồn	Tổng đơn, hạn mức, dư nợ đều là dữ liệu tổng hợp và đơn vị VND	Thiếu định nghĩa dư nợ: Accounting Owner
2	BA	Mô hình hóa trạng thái đơn	DRAFT, IN_REVIEW, CONFIRMED, REJECTED	Sơ đồ chuyển trạng thái	Vượt hạn mức phải vào IN_REVIEW	Mỗi trạng thái có điều kiện vào và ra	Mâu thuẫn luồng bán hàng: Business Owner
3	Credit Controller	Đánh giá ngoại lệ	Đơn ở IN_REVIEW	Quyết định mô phỏng và lý do	Chỉ vai trò tín dụng được xác nhận hoặc từ chối	Không có đường chuyển trực tiếp từ Sales sang CONFIRMED khi vượt hạn mức	Quyền vai trò không rõ: Security và Business Owner
4	BA	Gắn truy vết	Rule, trường dữ liệu, trạng thái	Liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY	Một quyết định phải liên kết evidence và authority	Không tạo ID mới ngoài registry	ID hoặc nguồn canonical mâu thuẫn: Principal IT Business Analyst / Technical Curriculum Author
5	QA Reviewer	Rà soát tình huống biên	Tổng nghĩa vụ bằng, nhỏ hơn, lớn hơn hạn mức	Kết quả kiểm tra mô phỏng	<= hạn mức: cho xác nhận; > hạn mức: IN_REVIEW	Có kiểm tra ba ngưỡng và kết quả khớp rule	Kết quả không khớp: BA và Credit Controller

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

stateDiagram-v2
    direction TB
    [*] --> DRAFT
    DRAFT --> IN_REVIEW: totalExposure > creditLimit
    DRAFT --> CONFIRMED: totalExposure <= creditLimit
    IN_REVIEW --> CONFIRMED: Credit Controller phê duyệt ngoại lệ
    IN_REVIEW --> REJECTED: Credit Controller từ chối ngoại lệ
    CONFIRMED --> [*]
    REJECTED --> [*]

    note right of DRAFT
        totalExposure = dư nợ mở + giá trị đơn
        Cùng tiền tệ VND và thời điểm chốt dữ liệu
    end note

Sơ đồ là Mermaid state diagram, không phải BPMN. totalExposure là tổng dư nợ mở và giá trị đơn; phép so sánh phải dùng cùng tiền tệ VND và cùng thời điểm chốt dữ liệu. Quy tắc pháp lý, kế toán, thuế và chính sách tín dụng thực tế: Verification required bởi vai trò có thẩm quyền.

6. Output thu ???c

Core

Output là artifact được tạo mới hoặc cập nhật để biến quy tắc, trạng thái và quyết định từ nội dung phân tích thành dữ liệu có thể truy vết. Mỗi artifact giữ IN_REVIEW, v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Artifact canonical	Tệp canonical	Owner	Trạng thái	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID rule, phát biểu rule, điều kiện, kết quả, ngoại lệ, authority cần xác minh, liên kết trạng thái và evidence	Ghi version, ngày, người ghi nhận, lý do đổi, ID rule bị ảnh hưởng
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	ID canonical, loại đối tượng, artifact nguồn, artifact đích, quan hệ truy vết, trạng thái liên kết	Không tái sử dụng ID; ghi mọi thêm, sửa, ngừng dùng ID và lý do
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tên dữ liệu, nghĩa nghiệp vụ, kiểu logic, nguồn, tiền tệ VND khi có giá trị tiền, quy tắc kiểm tra, liên kết rule	Ghi trường thêm hoặc đổi, tác động rule và lý do
State model trong handbook	/02-handbook/08-business-rules-state-and-decision-analysis.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Tên state, điều kiện vào, điều kiện ra, transition, vai trò thực hiện, transition bị cấm	Ghi state hoặc transition đổi, evidence, artifact bị tác động
Decision record trong handbook	/02-handbook/08-business-rules-state-and-decision-analysis.md	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong	Ghi quyết định thay thế, lý do, authority cần xác minh; không sửa im lặng

Owner duy trì cấu trúc, ID, phiên bản và lịch sử. Owner không có quyền tự xác nhận policy tín dụng, diễn giải pháp lý, quyết định kế toán, baseline, approval hoặc production use. Evidence cho giới hạn này là metadata của các artifact canonical đều ghi IN_REVIEW và chưa có baseline hoặc approval reference.

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

flowchart TB
    A[State and decision analysis]

    B[CANONICAL_BUSINESS_RULES]
    C[CANONICAL_DATA_DICTIONARY]
    D[TRACEABILITY_ID_REGISTRY]
    E[State model in handbook]
    F[Decision record in handbook]

    A -->|create or update artifact| B
    A -->|create or update artifact| C
    A -->|create or update artifact| D
    A -->|create or update artifact| E
    A -->|create or update artifact| F

    B -->|register ID and traceability link| D
    C -->|register ID and traceability link| D
    E -->|register ID and traceability link| D
    F -->|register ID and traceability link| D

    G[Change history in each artifact<br/>version, date, recorder, reason,<br/>affected rule, field, state, transition, decision, or ID]
    B -->|record change| G
    C -->|record change| G
    D -->|record ID change and reason| G
    E -->|record change| G
    F -->|record change| G

    H[Principal IT Business Analyst /<br/>Technical Curriculum Author]
    H -.->|maintains structure, IDs,<br/>versions, and history| B
    H -.->|maintains structure, IDs,<br/>versions, and history| C
    H -.->|maintains structure, IDs,<br/>versions, and history| D
    H -.->|maintains structure, IDs,<br/>versions, and history| E
    H -.->|maintains structure, IDs,<br/>versions, and history| F

    I[IN_REVIEW<br/>v0.9.0 · 2026-08-07<br/>vi-VN · Asia/Ho_Chi_Minh<br/>No baseline or approval reference]
    I -.-> B
    I -.-> C
    I -.-> D
    I -.-> E
    I -.-> F

    J[Owner cannot self-confirm:<br/>credit policy, legal interpretation,<br/>accounting decision, baseline, approval,<br/>or production use]
    H -.-> J

Applied

Facts: Đơn bán mô phỏng vượt hạn mức tín dụng và chuyển từ DRAFT sang IN_REVIEW.

Current Behavior: State model ghi điều kiện totalExposure > creditLimit; đơn không được chuyển trực tiếp sang CONFIRMED.

Underlying Need: Người review cần biết rule nào quyết định chuyển state, dữ liệu nào được so sánh, ai có authority xử lý ngoại lệ.

Options: Chỉ ghi state diagram; chỉ ghi rule catalog; cập nhật cả state model, rule catalog, data dictionary, registry và decision record.

Decision Criteria: Có ID canonical, truy ngược được từ transition đến rule và dữ liệu, giữ rõ authority, không suy diễn approval.

Decision: Cập nhật đủ năm artifact trong bảng vì transition phụ thuộc rule totalExposure > creditLimit, dữ liệu totalExposure và creditLimit, cùng quyết định ngoại lệ.

Authority: Credit Controller xử lý ngoại lệ mô phỏng; Business Owner xác minh policy nghiệp vụ thực tế; Accounting Owner xác minh diễn giải tài chính nếu phát sinh.

Artifact: Dùng đúng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY và /02-handbook/08-business-rules-state-and-decision-analysis.md.

Consequence if Wrong: Thiếu liên kết làm QA không xác định được test basis; sai authority có thể biến ví dụ học liệu thành chỉ dẫn vận hành không có thẩm quyền.

Senior Lens

Không tạo ID mới trong handbook nếu TRACEABILITY_ID_REGISTRY chưa ghi nhận ID đó. Không đổi nghĩa rule trong state diagram mà không cập nhật CANONICAL_BUSINESS_RULES. Không đổi tên hoặc đơn vị của dữ liệu tiền mà không cập nhật CANONICAL_DATA_DICTIONARY; so sánh totalExposure và creditLimit chỉ có nghĩa khi cùng VND và cùng thời điểm chốt dữ liệu.

Lịch sử thay đổi phải phân biệt thay đổi biên tập với thay đổi nghĩa. Sửa chính tả không đổi logic. Đổi toán tử từ > thành >=, thêm state, bỏ transition bị cấm, đổi authority hoặc đổi nguồn dữ liệu là thay đổi nghĩa; phải ghi tác động đến rule, state, decision record và traceability.

Quick Reference

Quy tắc	Áp dụng
Giữ ID nguyên dạng	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY
Giữ trạng thái	IN_REVIEW không phải approval, baseline hoặc production-ready
Ghi lịch sử	Version, ngày 2026-08-07, người ghi nhận, lý do, artifact bị tác động
Giữ source boundary	Handbook không thay thế policy, legal, accounting, security hoặc production authority
Giữ tính mô phỏng	Nova Foods và dữ liệu VND chỉ phục vụ giáo dục, dữ liệu tổng hợp

Core

Output của phân tích business rule, state và decision phải biến suy luận thành artifact có thể đọc, kiểm tra và truy vết. CANONICAL_BUSINESS_RULES là catalog quy tắc; mỗi dòng cần nêu điều kiện kích hoạt, hành vi bắt buộc hoặc cấm, ngoại lệ, dữ liệu dùng để đánh giá và nguồn hoặc giả định. CANONICAL_DATA_DICTIONARY định nghĩa dữ liệu logic dùng trong điều kiện. TRACEABILITY_ID_REGISTRY giữ định danh canonical; không tự đổi hoặc tự tạo biến thể ID.

Artifact canonical	Anatomy tối thiểu hoàn chỉnh	Mục đích
CANONICAL_BUSINESS_RULES	Quy tắc; trigger; điều kiện; kết quả; ngoại lệ; dữ liệu đầu vào; nguồn hoặc nhãn giả định; liên kết state/decision	Diễn đạt rule độc lập với màn hình hoặc code
State model	State; event; guard condition; transition; state sau; hành vi bị cấm	Chặn diễn giải mơ hồ về vòng đời
Decision table	Input condition; giá trị từng condition; rule column; outcome; priority; exception	Đảm bảo tổ hợp điều kiện không bị bỏ sót
Traceability entry trong TRACEABILITY_ID_REGISTRY	Artifact nguồn; artifact đích; lý do liên kết; phạm vi tác động	Chứng minh output bắt nguồn từ đâu

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.

Mục	Nội dung đã điền
Facts	Phiếu yêu cầu mua hàng mô phỏng có trạng thái Draft, Submitted, Approved, Rejected. Người tạo có thể sửa ở Draft hoặc sau khi bị Rejected.
Current Behavior	Khi gửi phiếu, ERP mô phỏng chưa có bảng quyết định để phân biệt yêu cầu thiếu mã nhà cung cấp với yêu cầu vượt ngưỡng giá trị.
Underlying Need	Cần xác định chuyển trạng thái nhất quán vì trạng thái quyết định quyền sửa và bước xử lý tiếp theo.
Options	1. Cho mọi phiếu sang Approved. 2. Cho mọi phiếu thiếu dữ liệu sang Rejected. 3. Chỉ cho Approved khi đủ mã nhà cung cấp và tổng tiền không vượt ngưỡng giả định.
Decision Criteria	Không cho duyệt khi thiếu dữ liệu định danh nhà cung cấp; giữ đường sửa cho người tạo; không diễn giải ngưỡng tiền là chính sách thực tế Nova Foods.
Decision	Chọn option 3. Submitted sang Approved khi có SupplierCode và TotalAmountVND không lớn hơn 50000000; các trường hợp khác sang Rejected. Ngưỡng là project assumption, cần Business Owner xác minh nếu dùng ngoài học liệu.
Authority	Business Owner xác nhận chính sách mua hàng; Accounting Owner xác minh ý nghĩa tiền tệ; Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận và truy vết.
Artifact	Nội dung rule vào CANONICAL_BUSINESS_RULES; định nghĩa SupplierCode, TotalAmountVND vào CANONICAL_DATA_DICTIONARY; liên kết artifact vào TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Phiếu thiếu nhà cung cấp có thể bị duyệt, hoặc phiếu hợp lệ bị trả lại; dữ liệu mua hàng mô phỏng mất nhất quán và test không có expected result tin cậy.

Decision table đầy đủ cho quyết định mô phỏng:

Rule column	SupplierCode có giá trị	TotalAmountVND	State hiện tại	State kết quả	Outcome
R1	Có	<= 50000000	Submitted	Approved	Cho phép duyệt
R2	Không	<= 50000000	Submitted	Rejected	Trả lại để bổ sung nhà cung cấp
R3	Có	> 50000000	Submitted	Rejected	Trả lại để xử lý theo chính sách cần xác minh
R4	Không	> 50000000	Submitted	Rejected	Trả lại vì thiếu nhà cung cấp và vượt ngưỡng giả định
R5	Có hoặc không	Có hoặc không	Draft	Draft	Không áp dụng quyết định duyệt trước event submit
R6	Có hoặc không	Có hoặc không	Approved	Approved	Cấm gửi lại trong mô hình này
R7	Có hoặc không	Có hoặc không	Rejected	Rejected	Chỉ chuyển sang Draft qua event revise

Senior Lens

Bảng quyết định bao phủ cả state không áp dụng để tránh lỗi phổ biến: test chỉ kiểm tra điều kiện tiền và quên event hoặc state hiện tại. R1–R4 chứng minh mọi tổ hợp nhị phân của mã nhà cung cấp và ngưỡng tiền tại Submitted đều có outcome. R5–R7 đặt boundary rõ: cùng dữ liệu nhưng state khác thì không được suy ra cùng kết quả. Đây là reasoning bridge: dữ liệu quyết định chỉ có nghĩa trong ngữ cảnh state và event.

Quick Reference

Kiểm tra anatomy	Kết quả cần thấy
Rule có thể đọc độc lập	Có trigger, condition, outcome và exception hoặc boundary
State model có thể test	Mỗi transition có state trước, event, guard và state sau
Decision table đủ tổ hợp	Không còn tổ hợp điều kiện nào chưa có outcome
Dữ liệu có nghĩa rõ	Mỗi field dùng trong rule tham chiếu CANONICAL_DATA_DICTIONARY
Liên kết không bị mất	Artifact nguồn và output được ghi trong TRACEABILITY_ID_REGISTRY

Core

Cổng chất lượng là kiểm tra tối thiểu trước khi đưa output sang downstream review, tức review của người nhận tiếp theo. Cổng này xác nhận artifact đủ để đọc, truy vết và phản biện; không xác nhận đúng nghiệp vụ cuối cùng, không tạo approval, baseline hay production readiness.

Output chịu cổng	Bằng chứng bắt buộc	Điều kiện đạt để sang review	Điều kiện chặn
Quy tắc nghiệp vụ tham chiếu CANONICAL_BUSINESS_RULES	ID giữ nguyên, nguồn hoặc giả định gắn nhãn, trạng thái và version hiện hành	Không mâu thuẫn source boundary; quy tắc phân biệt rõ fact, giả định và Verification required	Biến giả định thành nghĩa vụ; tự diễn giải pháp lý, kế toán hoặc thuế
Từ điển dữ liệu tham chiếu CANONICAL_DATA_DICTIONARY	Tên dữ liệu, ý nghĩa, kiểu logic, nguồn tạo và consumer	Mỗi trường được nêu có mục đích; không suy diễn schema triển khai	Thiếu nguồn dữ liệu; gọi thiết kế logic là cấu hình ERP
Liên kết truy vết tham chiếu TRACEABILITY_ID_REGISTRY	Canonical ID, artifact nguồn, artifact đích, lý do liên kết	Liên kết đọc được hai chiều và không tạo ID mới ngoài registry	ID biến thể, liên kết mồ côi, hoặc mâu thuẫn canonical source
Nội dung handbook /02-handbook/08-business-rules-state-and-decision-analysis.md	Section, nguồn tham chiếu, nhãn mô phỏng, change history	Dùng tiếng Việt rõ nghĩa; Nova Foods là mô phỏng, dữ liệu tổng hợp	Ghi nhận approval, baseline, tuân thủ hoặc sẵn sàng production khi chưa có bằng chứng

Applied

Mục	Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp
Facts	Corpus ở IN_REVIEW, 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.
Current Behavior	BA ghi rule trạng thái đơn hàng và chuyển cho reviewer khi chưa kiểm tra ID, nguồn và giới hạn thẩm quyền.
Underlying Need	Reviewer cần biết nội dung nào có thể phản biện ngay và nội dung nào phải chặn vì thiếu bằng chứng.
Options	(1) Chuyển mọi bản nháp; (2) chỉ chuyển sau cổng chất lượng tối thiểu.
Decision Criteria	Giữ canonical ID; phân biệt fact với giả định; có nguồn; không tuyên bố approval, baseline, compliance hoặc production readiness.
Decision	Chọn phương án (2). Output chỉ mang nhãn Ready for downstream review khi đạt toàn bộ điều kiện cổng.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì artifact; Business Owner, Legal Owner, Accounting Owner, Security, Architect và QA giữ thẩm quyền kết luận thuộc lĩnh vực họ.
Artifact	/02-handbook/08-business-rules-state-and-decision-analysis.md, liên kết quản trị tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	Reviewer nhận nội dung không truy vết được; giả định có thể bị hiểu sai thành rule vận hành; quyết định vượt thẩm quyền có thể lọt sang bước sau.

Senior Lens

Cổng chất lượng kiểm tra reviewability, nghĩa là khả năng review có căn cứ. Nó không kiểm tra acceptance, nghĩa là chấp nhận bởi người có thẩm quyền. Lý do: artifact IN_REVIEW còn có thể đổi; vì vậy dùng ngôn ngữ “đủ để review”, không dùng “đã đúng”, “đã phê duyệt” hoặc “sẵn sàng triển khai”.

Mỗi lần cập nhật phải ghi change-history: ngày 2026-08-07 hoặc ngày thay đổi thực tế theo Asia/Ho_Chi_Minh, version, người ghi nhận, phần thay đổi và lý do. Thiếu change-history làm reviewer không phân biệt được nội dung mới với nội dung đã có, nên chặn review.

Quick Reference

• Đạt cổng: ID đúng, nguồn rõ, giả định có nhãn, thẩm quyền đúng, change-history có mặt.
• Không đạt cổng: chặn và sửa artifact hoặc escalation.
• Đạt cổng: vẫn IN_REVIEW.
• Cổng chất lượng không tạo approval, baseline, compliance hay production readiness.

7. Who consumes those outputs?

Core

Nova Foods Trading & Manufacturing là case study mô phỏng; mọi dữ liệu là tổng hợp. Output từ phân tích business rule, state và decision không phải “tài liệu để lưu”. Mỗi output trả lời loại câu hỏi khác nhau, nên mỗi vai trò dùng nó để làm phần việc khác nhau.

Consumer	Output họ dùng	Cách dùng trực tiếp	Phần việc không thuộc họ
Developers	Rule catalog trong CANONICAL_BUSINESS_RULES, state model, decision table, data definition trong CANONICAL_DATA_DICTIONARY	Viết logic kiểm tra, chuyển trạng thái, thông báo lỗi, API và lưu dữ liệu đúng điều kiện	Không tự đổi ý nghĩa nghiệp vụ khi rule mơ hồ
QA	Rule catalog, state model, decision table, traceability trong TRACEABILITY_ID_REGISTRY	Tạo test basis, tức căn cứ để thiết kế test; kiểm tra trường hợp đúng, sai, biên và chuyển trạng thái bị chặn	Không tự xác nhận rule là nhu cầu đúng của nghiệp vụ
Architect	State model, data impact, integration rule, non-functional constraint	Chọn điểm kiểm soát giữa ERP module, API, database và quyền truy cập; phát hiện xung đột kiến trúc	Không thay Business Owner quyết định ưu tiên nghiệp vụ
PM/Product Owner	Rule catalog, decision record, traceability	Chia scope, sắp thứ tự backlog, làm rõ dependency và nhận diện item chưa đủ điều kiện phát triển	Không biến trạng thái IN_REVIEW thành approval
Business Owner	Business rule, decision table, worked scenario	Đối chiếu rule với mục tiêu vận hành, chính sách bán hàng, kho hoặc sản xuất của case mô phỏng	Không tự xác nhận thiết kế kỹ thuật khả thi
Operations	State model, exception flow, dữ liệu đầu vào và đầu ra	Hiểu thao tác nào tạo thay đổi trạng thái, điểm nào bị chặn, dữ liệu nào cần sửa khi lỗi	Không tự sửa rule canonical trong tài liệu
Specialist owners	Rule liên quan lĩnh vực: Accounting, Legal, Security, Food Safety hoặc Data Owner	Review phần thuộc chuyên môn, như dữ liệu cá nhân, hạch toán, truy xuất lô, quyền truy cập	Không kết luận thay phần việc ngoài chuyên môn

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

flowchart TB
    subgraph OUT[BA analysis outputs]
        BR[Rule catalog<br/>CANONICAL_BUSINESS_RULES]
        SM[State model]
        DT[Decision table]
        DD[Data definition<br/>CANONICAL_DATA_DICTIONARY]
        EF[Exception flow]
        DI[Data impact]
        IR[Integration rule]
        NFC[Non-functional constraint]
        DR[Decision record]
        TR[Traceability<br/>TRACEABILITY_ID_REGISTRY]
        WS[Worked scenario]
        IO[Input/output data]
    end

    subgraph USE[Consumers use outputs]
        DEV[Developers<br/>build logic, API, data storage]
        QA[QA<br/>derive test basis]
        ARC[Architect<br/>fit architecture]
        PO[PM/Product Owner<br/>plan scope and dependencies]
        BO[Business Owner<br/>validate business fit]
        OPS[Operations<br/>understand actions, blocks, corrections]
        SO[Specialist owners<br/>Accounting, Legal, Security,<br/>Food Safety, Data Owner]
    end

    BR --> DEV
    SM --> DEV
    DT --> DEV
    DD --> DEV

    BR --> QA
    SM --> QA
    DT --> QA
    TR --> QA

    SM --> ARC
    DI --> ARC
    IR --> ARC
    NFC --> ARC

    BR --> PO
    DR --> PO
    TR --> PO

    BR --> BO
    DT --> BO
    WS --> BO

    SM --> OPS
    EF --> OPS
    IO --> OPS

    BR --> SO

    subgraph BOUNDARY[Responsibility boundaries]
        NDEV[Developers<br/>do not change business meaning]
        NQA[QA<br/>do not validate requirement correctness]
        NARC[Architect<br/>do not set business priority]
        NPO[PM/Product Owner<br/>IN_REVIEW is not approval]
        NBO[Business Owner<br/>do not confirm technical feasibility]
        NOPS[Operations<br/>do not change canonical rules]
        NSO[Specialist owners<br/>do not decide outside domain]
    end

    DEV -. boundary .-> NDEV
    QA -. boundary .-> NQA
    ARC -. boundary .-> NARC
    PO -. boundary .-> NPO
    BO -. boundary .-> NBO
    OPS -. boundary .-> NOPS
    SO -. boundary .-> NSO

Applied

Thành phần	Nội dung
Facts	Case mô phỏng Nova Foods có rule chuyển trạng thái đơn hàng từ IN_REVIEW sang trạng thái tiếp theo. Rule, điều kiện dữ liệu và ID truy vết phải nằm trong artifact canonical, không nằm riêng trong ghi chú của Developer hay QA.
Current Behavior	Developer đọc state model để lập trình chặn chuyển trạng thái sai. QA dùng cùng state model để tạo test chuyển trạng thái hợp lệ và không hợp lệ. Operations dùng nó để biết thao tác nào bị từ chối.
Underlying Need	Cùng một điều kiện phải được hiểu nhất quán. Nếu Developer hiểu là kiểm tra dữ liệu bắt buộc, còn QA hiểu là kiểm tra quyền, hai bên sẽ kiểm tra hai thứ khác nhau.
Options	(1) Mỗi vai trò tự diễn giải bản sao tài liệu. (2) Mọi vai trò dùng cùng output canonical và tham chiếu ID.
Decision Criteria	Phương án phải giữ traceability, tức khả năng lần ngược từ logic, test hoặc vận hành về rule nguồn; giảm bản sao; không trao thẩm quyền nghiệp vụ cho vai trò kỹ thuật.
Decision	Chọn (2). Developer, QA, Architect, PM/Product Owner, Business Owner, Operations và specialist owners cùng dùng CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY theo nhu cầu vai trò.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết artifact. Mỗi owner chuyên môn giữ kết luận trong phạm vi mình. Trạng thái hiện hành là IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Artifact	/02-handbook/08-business-rules-state-and-decision-analysis.md; liên kết canonical tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Logic ERP, test và hướng dẫn vận hành có thể dùng ba cách hiểu khác nhau; lỗi chỉ lộ khi xử lý ngoại lệ hoặc tích hợp. Case mô phỏng không chứng minh cấu hình ERP thực tế.

Senior Lens

Một output có nhiều consumer không có nghĩa mọi consumer có quyền sửa nó. State model là ví dụ: Developer cần nó để viết guard condition, tức điều kiện chặn chuyển trạng thái; QA cần nó để phủ test; Operations cần nó để thao tác; Architect cần nó để đặt kiểm soát tích hợp. Nhu cầu dùng chung là bằng chứng phải duy trì một nguồn canonical, không phải bằng chứng chuyển quyền quyết định cho nhóm kỹ thuật.

PM/Product Owner dùng output để quản lý phạm vi, không dùng nó như bằng chứng rằng rule đã được Business Owner chấp nhận. Business Owner dùng output để xem rule có phục vụ vận hành hay không, không dùng nó để xác nhận API, database hoặc bảo mật. Chia ranh giới này ngăn “review kỹ thuật” bị hiểu nhầm thành “quyết định nghiệp vụ”.

Quick Reference

Output	Consumer chính	Kết quả họ tạo
Rule catalog	Developers, QA, Business Owner	Logic, test basis, review nghiệp vụ
State model	Developers, QA, Operations, Architect	Chuyển trạng thái, test flow, thao tác, kiểm soát kiến trúc
Decision table	Developers, QA, Business Owner, specialist owners	Điều kiện xử lý, test tổ hợp, review ngoại lệ
Data definition	Developers, QA, Architect, Data Owner	Mapping dữ liệu, kiểm tra dữ liệu, thiết kế lưu trữ và tích hợp
Traceability	PM/Product Owner, QA, BA, reviewer	Theo dõi liên kết rule, decision, test và thay đổi

Quyền quyết định, bằng chứng và điểm escalation

Core

Mỗi đầu ra phân tích quy tắc nghiệp vụ, trạng thái và quyết định chỉ hữu ích khi người nhận biết rõ ba ranh giới: được quyết định gì, phải dựa vào bằng chứng nào, và khi nào phải escalation. Escalation là chuyển vấn đề cho vai trò có thẩm quyền cao hơn hoặc chuyên môn phù hợp; không phải chuyển trách nhiệm mơ hồ.

Consumer	Có thể quyết định	Bằng chứng tối thiểu cần xem	Phải escalation khi
Developer	Cách hiện thực rule trong phạm vi đã xác định; xử lý lỗi kỹ thuật; ánh xạ trạng thái sang API hoặc UI	Rule ID, điều kiện vào, điều kiện chặn, trạng thái đầu ra, acceptance criteria	Rule thiếu điều kiện biên; một trạng thái cần thay đổi ý nghĩa nghiệp vụ; API làm lộ dữ liệu cá nhân
QA	Test basis; tập kiểm thử giá trị biên; lỗi có vi phạm rule hay không	Rule diễn đạt kiểm thử được, state transition, dữ liệu mẫu tổng hợp, expected result	Expected result mâu thuẫn rule; không xác định được trạng thái hợp lệ; lỗi có thể ảnh hưởng sổ sách hoặc truy xuất thực phẩm
Architect	Mẫu tích hợp, ownership dữ liệu, kiểm soát nhất quán và khả năng chịu lỗi	Data owner, luồng tích hợp, volume giả định, ràng buộc bảo mật, rule phụ thuộc hệ thống khác	Một rule yêu cầu thay đổi kiến trúc; xung đột nguồn dữ liệu canonical; rủi ro bảo mật hoặc dữ liệu cá nhân
PM/Product Owner	Ưu tiên backlog; phạm vi release; chấp nhận trade-off chức năng trong thẩm quyền sản phẩm	Giá trị nghiệp vụ, tác động người dùng, dependency, rủi ro, tiêu chí hoàn thành	Trade-off đổi chính sách giá, tín dụng, kế toán, pháp lý hoặc an toàn thực phẩm
Business Owner	Diễn giải mục tiêu nghiệp vụ và chọn chính sách vận hành trong thẩm quyền	Quy trình hiện hành đã xác minh, tác động doanh thu/chi phí mô phỏng, ngoại lệ nghiệp vụ	Quyết định chạm luật, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc vượt quyền đơn vị
Operations	Xác nhận tính vận hành được: ai thao tác, lúc nào, xử lý ngoại lệ ra sao	Luồng trạng thái, quyền thao tác, thời điểm cut-off, kịch bản lỗi, dữ liệu tổng hợp	Rule làm gián đoạn kho, giao hàng, sản xuất; ngoại lệ không có người chịu trách nhiệm
Specialist owner	Kết luận chuyên môn thuộc miền: Accounting, Legal, Security, Food Safety	Nguồn chính thức còn hiệu lực, bối cảnh nghiệp vụ, rule dự thảo, tác động và giả định	Có mâu thuẫn nguồn, thiếu căn cứ, hoặc cần xác nhận nghĩa vụ tuân thủ

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

flowchart TB
    A[BA chuẩn bị rule và bằng chứng tối thiểu] --> B{Consumer đủ thẩm quyền và bằng chứng đủ, nhất quán?}
    B -->|Có| C[Consumer quyết định trong phạm vi]
    B -->|Không đủ thẩm quyền / bằng chứng thiếu hoặc mâu thuẫn| D[Escalation tới specialist owner hoặc vai trò có thẩm quyền]
    D --> E[Specialist owner hoặc vai trò có thẩm quyền đưa kết luận]
    C --> F[BA ghi kết luận và nguồn]
    E --> F
    F --> G[BA cập nhật artifact sang IN_REVIEW]

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu tổng hợp. Rule dự thảo nói đơn bán hàng không được chuyển sang CONFIRMED khi khách hàng vượt hạn mức tín dụng.

Current Behavior: Developer hiểu “vượt” là tổng đơn hiện tại lớn hơn hạn mức. QA hiểu phải cộng cả công nợ chưa thanh toán. Hai cách hiểu tạo expected result khác nhau.

Underlying Need: Hệ thống cần chặn đúng rủi ro tín dụng, nhưng không được tự suy diễn chính sách tài chính.

Options:
1. Chặn theo giá trị đơn hiện tại.
2. Chặn theo công nợ mở cộng giá trị đơn hiện tại.
3. Cho phép xác nhận nếu có phê duyệt ngoại lệ.

Decision Criteria: Chính sách tín dụng được Business Owner xác nhận; cách tính công nợ do Accounting Owner xác nhận; trạng thái và quyền phê duyệt phải hiện diện trong artifact kiểm soát.

Decision: Chưa chọn option. Bằng chứng hiện có chỉ là rule dự thảo; chưa đủ xác định công thức hay quyền ngoại lệ.

Authority: Business Owner quyết định chính sách tín dụng. Accounting Owner xác nhận cách tính công nợ. Architect xem tác động tích hợp. Developer và QA không tự chọn option.

Artifact: Ghi câu hỏi và bằng chứng thiếu vào /01-curriculum/CANONICAL_BUSINESS_RULES.md; giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Chặn sai làm mất đơn hợp lệ; cho qua sai làm tăng rủi ro tín dụng mô phỏng. Nếu áp dụng thực tế còn có thể ảnh hưởng hạch toán, nên cần Accounting Owner xác nhận.

Senior Lens

Dấu hiệu escalation mạnh nhất là thay đổi ý nghĩa thay vì thay đổi cách làm. Developer chọn kiểu dữ liệu là cách làm. Quyết định “công nợ nào được tính vào hạn mức” là ý nghĩa chính sách, phải chuyển Business Owner và Accounting Owner. Evidence phải nối được từ kết luận về nguồn: rule dự thảo không đủ thay nguồn chính thức, quyết định owner, hoặc quy trình đã xác minh.

Với dữ liệu cá nhân, thuế, kế toán, hóa đơn, an toàn thực phẩm và truy xuất, BA chỉ đóng gói vấn đề: fact, tác động, nguồn, giả định và câu hỏi. Kết luận pháp lý, kế toán hoặc chuyên môn không được tự tạo từ artifact IN_REVIEW. Các nguồn luật trong corpus cần specialist owner xác minh trước khi biến thành requirement hệ thống.

Quick Reference

Tình huống	Câu hỏi làm rõ chính xác	Nơi escalation
Developer không rõ điều kiện chặn	“Giá trị nào được tính vào tổng nghĩa vụ tín dụng tại thời điểm chuyển sang CONFIRMED?”	Business Owner, Accounting Owner
QA không có expected result	“Với công nợ mở là 80.000.000 VND và đơn mới là 30.000.000 VND, kết quả trạng thái mong đợi là gì khi hạn mức là 100.000.000 VND?”	Business Owner
Architect thấy hai hệ thống cùng giữ số dư	“Hệ thống nào là nguồn dữ liệu canonical cho công nợ mở, và độ trễ đồng bộ chấp nhận được là bao nhiêu?”	Architect, Accounting Owner
Operations cần xử lý ngoại lệ	“Vai trò nào được phép phê duyệt vượt hạn mức, và phê duyệt đó hết hiệu lực khi nào?”	Business Owner, Operations Owner
Rule liên quan dữ liệu cá nhân	“Trường dữ liệu nào cần thiết cho quyết định, ai được xem, và căn cứ xử lý dữ liệu cần owner nào xác nhận?”	Security Owner, Legal Owner

Core

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, bàn giao sai thường không do thiếu tài liệu mà do hai bên gán nghĩa khác nhau cho cùng một đầu ra. BA phải biến giả định ngầm thành câu hỏi có thể trả lời, rồi ghi câu trả lời vào artifact canonical phù hợp. IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải bằng chứng phê duyệt hay baseline.

Hiểu nhầm khi bàn giao	Vì sao nguy hiểm	Câu hỏi làm rõ chính xác	Bằng chứng cần ghi
“Đơn hàng được duyệt” bị hiểu là trạng thái cuối cùng	Developer có thể khóa sửa đơn; QA có thể bỏ kiểm thử chuyển trạng thái tiếp theo	“Sau trạng thái Approved, người dùng còn được sửa số lượng, giá hoặc kho không? Nếu có, hệ thống chuyển về trạng thái nào và ai được quyền thực hiện?”	State model, transition rule, quyền theo vai trò
Bảng quyết định có ô trống bị hiểu là “không áp dụng”	Code có thể mặc định cho phép; QA không tạo test âm	“Ô trống này nghĩa là không áp dụng, chưa xác định, hay phải chặn giao dịch? Hành vi hệ thống và thông báo lỗi là gì?”	Decision table có giá trị tường minh: N/A, BLOCK, hoặc Verification required
Quy tắc “vượt hạn mức” bị hiểu là số tiền đã gồm thuế	Sai cách tính có thể đổi kết quả phê duyệt	“Hạn mức so với giá trị nào: trước thuế, sau thuế, sau chiết khấu, hay tổng đơn bằng VND? Làm tròn tại bước nào?”	Rule expression, định nghĩa trường trong CANONICAL_DATA_DICTIONARY
“Gửi thông báo” bị hiểu là yêu cầu đồng bộ	Architect thiết kế API chờ phản hồi; Operations kỳ vọng cảnh báo tức thời	“Thông báo phải xuất hiện trước khi người dùng hoàn tất thao tác không? Nếu dịch vụ thông báo lỗi, giao dịch chính có bị hủy không?”	Integration contract, failure behavior, monitoring rule
Nhãn “Verification required” bị hiểu là rule đã có hiệu lực	Nhóm delivery biến giả định thành cấu hình ERP	“Ai có thẩm quyền xác minh nội dung này, nguồn nào phải được kiểm tra, và trước khi xác minh hệ thống phải chặn, cho phép có cảnh báo, hay chưa triển khai?”	Issue log, owner thẩm quyền, source reference, quyết định được ghi nhận
Traceability link bị hiểu là bằng chứng nội dung đúng	Liên kết chỉ chứng minh quan hệ, không chứng minh quyết định nghiệp vụ	“Liên kết này truy đến requirement, rule, test hay quyết định nào? Nội dung nguồn còn ở IN_REVIEW hay đã có baseline reference?”	Canonical ID, trạng thái, version, nguồn gốc liên kết

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

stateDiagram-v2
    direction TB

    [*] --> Draft
    Draft --> InReview: submit
    InReview --> Approved: authorized owner decision recorded in canonical artifact
    InReview --> InReview: authorized owner or canonical record missing
    InReview --> Draft: clarification required
    Approved --> Baselined: baseline reference recorded in canonical artifact

    note right of InReview
        Workflow status is not approval evidence.
        IN_REVIEW, v0.9.0, and 2026-08-07 prove neither approval nor baseline.
    end note

    note right of Approved
        Approval is not baseline.
        Later transitions may still apply.
    end note

Sơ đồ là mô hình trạng thái minh họa, không phải BPMN. Cầu nối suy luận: nếu chuyển InReview sang Approved cần “authorized decision recorded”, thì câu “đã duyệt” không đủ; bên nhận phải hỏi ai quyết định, quyết định nằm ở artifact nào, và điều kiện chuyển trạng thái nào đã thỏa.

Applied

Facts: Bảng quyết định mô phỏng ghi: “Đơn mua vượt hạn mức cần phê duyệt”. Developer hiểu vượt 50.000.000 VND là chặn tạo đơn. QA hiểu là vẫn tạo đơn nhưng không cho gửi nhà cung cấp.

Current Behavior: Hai cách hiểu tạo hai luồng trạng thái khác nhau; không thể viết test nhất quán.

Underlying Need: Xác định điểm chặn nghiệp vụ và dữ liệu tính hạn mức.

Options: Chặn trước khi lưu đơn; lưu đơn ở InReview; cho gửi đơn rồi xử lý hậu kiểm.

Decision Criteria: Bằng chứng phải nêu thời điểm kiểm soát, giá trị tính bằng VND, vai trò có quyền chuyển trạng thái, và hậu quả khi dịch vụ phê duyệt không sẵn sàng.

Decision: Chưa chọn phương án. Nội dung hiện là giả định mô phỏng, Verification required.

Authority: Business Owner quyết định chính sách; Accounting Owner xác minh cơ sở giá trị; Architect xác minh khả năng tích hợp; BA ghi truy vết, không thay thế các thẩm quyền này.

Artifact: Ghi câu trả lời vào state model, decision table và liên kết canonical tới CANONICAL_BUSINESS_RULES cùng CANONICAL_DATA_DICTIONARY.

Consequence if Wrong: Đơn có thể bị chặn sai hoặc phát hành sai; test pass theo một cách hiểu nhưng vận hành theo cách khác.

Câu hỏi bàn giao bắt buộc: “Khi tổng giá trị đơn vượt 50.000.000 VND, hệ thống phải cho lưu đơn ở trạng thái nào, có được gửi nhà cung cấp không, giá trị này gồm các thành phần nào, và ai có quyền chuyển đơn sang Approved?”

8. Detailed Worked Example

Core

Ví dụ dùng Nova Foods Trading & Manufacturing mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. “Trạng thái” là giá trị cho biết đơn mua đang ở bước nào. “Hành vi hiện tại” là cách ERP đang xử lý theo quan sát mô phỏng, không phải quy tắc đã được phê duyệt.

Applied

Bối cảnh: Nhân viên mua hàng tạo đơn mua nguyên liệu bột cacao. Tổng tiền hàng là 52.000.000 VND, chưa gồm VAT và phí vận chuyển. Người tạo chọn nút Submit for approval. Hệ thống lưu đơn, hiện nhãn InReview, nhưng vẫn hiển thị nút Send to supplier.

Nhóm fact	Giá trị tổng hợp	Phân loại nguồn	Lý do liên quan
Đối tượng	Đơn mua nguyên liệu bột cacao	Giả định dự án mô phỏng	Là đối tượng cần kiểm soát trạng thái.
Tổng tiền hàng	52.000.000 VND	Giả định dự án mô phỏng	Giá trị vượt ngưỡng diễn giải trong workshop là 50.000.000 VND.
VAT	Chưa tính vào tổng tiền hàng	Giả định dự án mô phỏng	Làm rõ tổng nào đang được người dùng nhìn thấy.
Phí vận chuyển	Chưa nhập	Giả định dự án mô phỏng	Chưa thể kết luận phí có thuộc giá trị xét duyệt không.
Người tạo	Nhân viên mua hàng	Giả định dự án mô phỏng	Vai trò khởi tạo, không phải bằng chứng có quyền duyệt.
Hành động đã chọn	Submit for approval	Quan sát hành vi mô phỏng	Là sự kiện làm đơn đổi trạng thái.
Trạng thái sau lưu	InReview	Quan sát hành vi mô phỏng	Là kết quả hệ thống đang thể hiện.
Nút còn hiển thị	Send to supplier	Quan sát hành vi mô phỏng	Tạo khả năng gửi đơn trước khi biết kết quả duyệt.
Kết quả dịch vụ phê duyệt	Không có phản hồi thành công hoặc thất bại được ghi nhận	Giả định dự án mô phỏng	Không đủ bằng chứng để suy ra đơn đã được duyệt.

Current Behavior: Khi người dùng chọn Submit for approval, ERP đổi trạng thái đơn từ Draft sang InReview và lưu đơn. Sau khi lưu, giao diện vẫn cho phép chọn Send to supplier. Không có dữ liệu mô phỏng nào chứng minh hệ thống kiểm tra người duyệt, hạn mức, VAT, phí vận chuyển hoặc kết quả phê duyệt trước khi cho gửi. Suy luận này dựa trên hai bằng chứng: trạng thái hiển thị là InReview, và hành động gửi vẫn khả dụng.

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

stateDiagram-v2
    direction TB
    [*] --> Draft
    Draft --> InReview: Submit for approval\nERP lưu đơn\npurchaseOrderStatus = InReview
    InReview: sendToSupplierAvailable = true
    note right of InReview
        Quan sát: chưa ghi nhận kết quả phê duyệt
        Rủi ro: có thể chọn Send to supplier
        khi chưa có kết quả phê duyệt
        Chưa rõ: cho gửi là chủ ý hay lỗi
    end note

Trường dữ liệu đang quan sát	Giá trị	Ý nghĩa phân tích
purchaseOrderStatus	InReview	Đơn đang chờ xem xét theo tên trạng thái.
goodsAmount	52000000	Giá trị tiền hàng mô phỏng.
currencyCode	VND	Đơn vị tiền tệ của giá trị xét.
vatAmount	Chưa có giá trị	Không được tự cộng VAT vào ngưỡng.
shippingAmount	Chưa có giá trị	Không được tự cộng phí vận chuyển vào ngưỡng.
sendToSupplierAvailable	true	Bằng chứng giao diện chưa chặn gửi đơn.

Payload quan sát mô phỏng tại thời điểm lưu:

{
  "purchaseOrderStatus": "InReview",
  "goodsAmount": 52000000,
  "currencyCode": "VND",
  "vatAmount": null,
  "shippingAmount": null,
  "sendToSupplierAvailable": true
}

Ranh giới kết luận: ví dụ chưa xác định ngưỡng 50.000.000 VND là chính sách thật, chưa xác định tổng xét duyệt gồm VAT hay phí vận chuyển, và chưa xác định việc cho gửi đơn là lỗi hay chủ ý. Các điểm này là Verification required; chúng cần bằng chứng từ Business Owner, Accounting Owner và Architect trước khi thành quy tắc ERP.

Senior Lens

Không suy diễn InReview đồng nghĩa “đã duyệt”. Tên trạng thái chỉ là dữ liệu hiển thị; quyền gửi nhà cung cấp, công thức tính ngưỡng và điều kiện chuyển trạng thái cần được xác minh riêng. Giữ fact quan sát tách khỏi diễn giải để QA không biến giả định thành expected result.

Quick Reference

Thành phần	Nội dung đã biết	Nội dung chưa được xác minh
Trạng thái	Draft đổi sang InReview	Ai được chuyển sang trạng thái duyệt.
Giá trị	52.000.000 VND tiền hàng	VAT và phí vận chuyển có tính vào ngưỡng không.
Hành động	Send to supplier còn khả dụng	Có được phép gửi khi InReview không.
Nguồn	Dữ liệu tổng hợp Nova Foods mô phỏng	Chính sách nghiệp vụ có thẩm quyền.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing là case học liệu, dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Phân tích này thuộc /02-handbook/08-business-rules-state-and-decision-analysis.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không phải quyết định vận hành, kế toán, pháp lý hoặc production.

Thành phần	Giá trị mô phỏng
Quy trình	Phê duyệt đơn mua hàng nội địa
Đối tượng trạng thái	Purchase Requisition, yêu cầu mua hàng
ID yêu cầu	PR-NF-20260807-0042
Người tạo	USR-NF-0147 — Nhân viên mua hàng
Nhà cung cấp dự kiến	SUP-NF-0031 — Công ty Bao bì Minh Phát
Giá trị trước VAT	48,600,000 VND
Mục đích mua	Màng đóng gói cho lệnh sản xuất
Trạng thái hiện tại	IN_REVIEW
Nguồn rule dự kiến	CANONICAL_BUSINESS_RULES, trạng thái IN_REVIEW, chưa baseline
Nguồn dữ liệu dự kiến	CANONICAL_DATA_DICTIONARY, trạng thái IN_REVIEW, chưa baseline

Facts — sự kiện kiểm chứng được. Ngày 2026-08-07, PR-NF-20260807-0042 có một dòng hàng RM-PKG-0018, số lượng 600 kg, đơn giá 81,000 VND/kg, thành tiền 48,600,000 VND. Người tạo đã gửi yêu cầu từ DRAFT sang IN_REVIEW. Hệ thống mô phỏng hiện ghi một trường reviewer_user_id, nhưng không lưu hạn mức phê duyệt, không lưu quyết định chấp thuận hay từ chối, và không khóa sửa số tiền sau khi gửi.

{
  "purchase_requisition_id": "PR-NF-20260807-0042",
  "status": "IN_REVIEW",
  "requester_user_id": "USR-NF-0147",
  "supplier_id": "SUP-NF-0031",
  "currency_code": "VND",
  "amount_before_vat": 48600000,
  "line_items": [
    {
      "item_id": "RM-PKG-0018",
      "quantity": 600,
      "uom": "kg",
      "unit_price": 81000,
      "line_amount": 48600000
    }
  ],
  "reviewer_user_id": "USR-NF-0022"
}

Current Behavior — hành vi hiện tại. Khi người dùng nhấn gửi, hệ thống đổi trạng thái sang IN_REVIEW và gán USR-NF-0022 làm người xem xét. Bất kỳ người có quyền sửa yêu cầu vẫn có thể đổi số lượng, đơn giá hoặc nhà cung cấp. Vì tổng tiền có thể thay đổi mà không tái khởi động kiểm tra, dấu vết xem xét không còn chứng minh giá trị nào đã được xem xét.

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

stateDiagram-v2
    direction TB
    [*] --> DRAFT
    DRAFT --> IN_REVIEW: Người tạo gửi / Hệ thống gán reviewer_user_id = USR-NF-0022
    IN_REVIEW --> IN_REVIEW: Người có quyền sửa supplier_id,<br/>quantity hoặc unit_price / Trạng thái không đổi, không tái kiểm tra
    note right of IN_REVIEW
        supplier_id, quantity, unit_price được phép sửa.
        Chỉ quantity hoặc unit_price trực tiếp đổi
        amount_before_vat trong dữ liệu mẫu.
        Trạng thái vẫn IN_REVIEW; dấu vết xem xét
        không chứng minh giá trị đã xem xét.
    end note

Underlying Need — nhu cầu gốc. Nova Foods cần quyết định nào có thể đưa một yêu cầu mua từ IN_REVIEW sang APPROVED, dựa trên giá trị nào, và điều gì xảy ra khi giá trị thay đổi. Bằng chứng là 48,600,000 VND đang có thể bị sửa sau khi gửi nhưng trạng thái vẫn là IN_REVIEW; do đó vấn đề không phải thiếu nút phê duyệt mà là thiếu quy tắc bảo toàn tính nhất quán giữa giá trị được duyệt và trạng thái.

Options — các phương án.

ID	Phương án	Lợi ích	Rủi ro còn lại
OPT-PR-01	Một người xem xét duyệt mọi giá trị	Ít cấu hình	Không kiểm soát khác biệt giá trị
OPT-PR-02	Duyệt theo hạn mức; sửa dữ liệu tài chính đưa lại DRAFT	Dấu vết khớp giá trị, kiểm tra lại rõ	Cần lưu hạn mức và lịch sử trạng thái
OPT-PR-03	Duyệt theo hạn mức; cho phép sửa nhưng giữ IN_REVIEW	Ít bước hơn	Người duyệt có thể duyệt giá trị khác giá trị đã xem

Decision Criteria — tiêu chí quyết định.

ID	Tiêu chí	Trọng số	OPT-PR-01	OPT-PR-02	OPT-PR-03
DC-PR-01	Giá trị được duyệt phải truy vết được	5	2	5	2
DC-PR-02	Quyền duyệt phải phù hợp hạn mức	5	1	5	4
DC-PR-03	Trạng thái phản ánh đúng dữ liệu hiện hành	4	2	5	2
DC-PR-04	Dễ kiểm thử bằng dữ liệu đầu vào	3	3	5	3
	Tổng có trọng số		35	74	42

Decision — quyết định được đề xuất, chưa được ủy quyền. Khuyến nghị chọn OPT-PR-02. Suy luận: phương án này đạt 74, cao nhất; riêng hai tiêu chí trọng số cao nhất đều đạt 5, nên xử lý trực tiếp rủi ro giá trị thay đổi sau xem xét. Khuyến nghị không phải quyết định đã phê duyệt.

Rule ID	Quy tắc đề xuất
BR-PR-001	PR chỉ chuyển từ IN_REVIEW sang APPROVED khi người quyết định có hạn mức phê duyệt lớn hơn hoặc bằng amount_before_vat hiện hành.
BR-PR-002	Khi PR ở IN_REVIEW, thay đổi supplier_id, quantity, unit_price hoặc thêm, xóa dòng hàng phải chuyển PR về DRAFT.
BR-PR-003	Chỉ trạng thái APPROVED mới cho phép tạo đơn mua hàng từ PR.
BR-PR-004	Mỗi chuyển trạng thái phải lưu from_status, to_status, actor_user_id, occurred_at, reason_code và giá trị amount_before_vat tại thời điểm chuyển.

Authority — thẩm quyền. Business Owner xác nhận nhu cầu kiểm soát và ngưỡng nghiệp vụ. Accounting Owner xác nhận cách tính amount_before_vat và hạn mức nếu ảnh hưởng kiểm soát tài chính. Solution Architect xác nhận cơ chế quyền, khóa sửa và lưu lịch sử. QA Owner xác nhận test basis. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận khuyến nghị và traceability; không có thẩm quyền tự chuyển khuyến nghị thành quyết định.

Mục	Trạng thái
Khuyến nghị OPT-PR-02	IN_REVIEW
Quy tắc BR-PR-001 đến BR-PR-004	Đề xuất, chưa baseline
Quyết định có thẩm quyền	Chưa được ghi nhận
User approval	Không có

Artifact — artifact cần cập nhật khi có thẩm quyền quyết định.

Artifact	Mục cần ghi	Truy vết
/01-curriculum/CANONICAL_BUSINESS_RULES.md	BR-PR-001 đến BR-PR-004, owner, nguồn, trạng thái	PR-NF-20260807-0042
/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Thuộc tính lịch sử trạng thái và trường hạn mức logic	purchase_requisition_id
/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Đăng ký ID rule, option, criteria	OPT-PR-02, DC-PR-01
/02-handbook/08-business-rules-state-and-decision-analysis.md	Worked example này	BR-PR-001 đến BR-PR-004

Consequence if Wrong — hậu quả nếu sai. Nếu giữ OPT-PR-03, USR-NF-0022 có thể xem xét 48,600,000 VND, sau đó người tạo sửa thành 81,000,000 VND nhưng yêu cầu vẫn mang trạng thái IN_REVIEW; người duyệt không có tín hiệu bắt buộc xem lại. Nếu triển khai BR-PR-001 với ngưỡng hoặc công thức tiền sai, hệ thống có thể cấp quyền duyệt không phù hợp hoặc chặn yêu cầu hợp lệ. Đây là rủi ro kiểm soát mô phỏng; ngưỡng tài chính, diễn giải kế toán và nghĩa vụ pháp lý cần Accounting Owner, Legal Owner xác minh trước production.

Applied

Case SCN-NF-LOT-001: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. ERP nhận lô nguyên liệu LOT-RM-20260807-001 từ phiếu nhập GRN-20260807-001. Lô chỉ được dùng sản xuất sau khi Quality Control (QC, kiểm soát chất lượng) ghi kết quả đạt.

Nhóm	ID / giá trị đầy đủ	Nội dung
Scenario	SCN-NF-LOT-001	Chặn cấp phát lô chờ QC
Item	RM-SUGAR-001	Đường tinh luyện, đơn vị KG
Lot	LOT-RM-20260807-001	Số lượng nhận 1,000 KG; giá trị mô phỏng 18,500,000 VND
Goods receipt	GRN-20260807-001	Nhập kho WH-RM-HCM-01 lúc 2026-08-07T09:15:00+07:00
QC inspection	QC-20260807-001	Chỉ tiêu độ ẩm; kết quả PASS lúc 2026-08-07T14:20:00+07:00
Production request	PRD-REQ-20260807-001	Yêu cầu cấp phát 500 KG cho lệnh MO-20260807-001
Source boundary	CANONICAL_BUSINESS_RULES	Catalog quy tắc canonical, trạng thái IN_REVIEW, v0.9.0
Data boundary	CANONICAL_DATA_DICTIONARY	Từ điển dữ liệu logic canonical, trạng thái IN_REVIEW, v0.9.0
Traceability boundary	TRACEABILITY_ID_REGISTRY	Registry định danh canonical, trạng thái IN_REVIEW, v0.9.0

Facts (sự kiện quan sát được): GRN-20260807-001 tạo tồn kho vật lý 1,000 KG. Kết quả QC chưa tồn tại tại thời điểm 09:15. PRD-REQ-20260807-001 xin 500 KG lúc 10:00. Bằng chứng là timestamp của goods receipt và production request. Vì yêu cầu sản xuất đến trước QC-20260807-001, hệ thống phải phân biệt tồn kho đã nhận với tồn kho đủ điều kiện cấp phát.

Current Behavior (hành vi hiện tại): giả định dự án ASSUMP-NF-LOT-001: ERP chỉ kiểm tra số lượng khả dụng, không kiểm tra trạng thái QC. Do 1,000 KG >= 500 KG, hệ thống cho phép cấp phát. Đây là giả định dự án, không phải xác nhận cấu hình ERP thật.

Rule ID	Quy tắc đầy đủ	Điều kiện	Kết quả bắt buộc trong case
BR-NF-LOT-001	Lô nguyên liệu mới nhận phải có trạng thái QC_PENDING ngay sau khi xác nhận nhập kho.	Tạo GRN thành công.	Tạo tồn kho 1,000 KG; lotStatus = QC_PENDING.
BR-NF-LOT-002	Chỉ lô có trạng thái QC_RELEASED mới được cấp phát cho lệnh sản xuất.	Người dùng gửi yêu cầu cấp phát.	Chấp nhận khi lotStatus = QC_RELEASED; từ chối mọi trạng thái khác.
BR-NF-LOT-003	Kết quả QC PASS chuyển lô từ QC_PENDING sang QC_RELEASED; FAIL chuyển sang QC_REJECTED.	QC hoàn tất và ghi kết quả hợp lệ.	Lưu người ghi nhận, thời điểm, kết quả và trạng thái mới.
BR-NF-LOT-004	Lô QC_REJECTED không được cấp phát.	Yêu cầu cấp phát tham chiếu lô bị từ chối.	Trả lỗi nghiệp vụ, không trừ tồn kho.

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

flowchart TB
    GRN["ERP xác nhận GRN-20260807-001<br/>Tồn kho vật lý: 1,000 KG"] --> P["Lô LOT-RM-20260807-001<br/>lotStatus = QC_PENDING"]

    REQ10["ERP/API nhận PRD-REQ-20260807-001<br/>Cấp phát 500 KG lúc 10:00"] --> VALID10{"Payload đủ lotId, quantity, uom,<br/>productionOrderId và quantity > 0?"}
    VALID10 -- "Không" --> INVALID10["Từ chối tại trust boundary<br/>Không kiểm tra lotStatus<br/>Không trừ tồn kho"]
    VALID10 -- "Có" --> CHECK10["Kiểm tra lotStatus lúc 10:00"]
    P -. "QC_PENDING lúc 10:00" .-> CHECK10
    CHECK10 --> REJECT10["Từ chối PRD-REQ-20260807-001<br/>Lỗi nghiệp vụ; không trừ tồn kho"]
    REJECT10 -->|"Giữ nguyên trạng thái"| P

    P -. "Nếu bỏ qua kiểm soát trạng thái" .-> RISK["500 KG có thể vào MO-20260807-001<br/>trước khi QC đạt"]

    P --> QC{"Quality Control hoàn tất<br/>Kết quả QC?"}
    QC -- "PASS lúc 14:20" --> AUDIT_PASS["Lưu người ghi nhận, thời điểm 14:20,<br/>kết quả PASS và trạng thái mới"]
    AUDIT_PASS --> R["Lô LOT-RM-20260807-001<br/>lotStatus = QC_RELEASED"]

    QC -- "FAIL" --> AUDIT_FAIL["Lưu người ghi nhận, thời điểm,<br/>kết quả FAIL và trạng thái mới"]
    AUDIT_FAIL --> J["Lô LOT-RM-20260807-001<br/>lotStatus = QC_REJECTED"]

    AFTER["Yêu cầu cấp phát 500 KG mới hoặc thử lại<br/>sau khi QC hoàn tất"] --> VALID_AFTER{"Payload đủ lotId, quantity, uom,<br/>productionOrderId và quantity > 0?"}
    VALID_AFTER -- "Không" --> INVALID_AFTER["Từ chối tại trust boundary<br/>Không kiểm tra lotStatus<br/>Không trừ tồn kho"]
    VALID_AFTER -- "Có" --> STATUS_AFTER{"Kiểm tra lotStatus"}

    R -.-> STATUS_AFTER
    J -.-> STATUS_AFTER

    STATUS_AFTER -- "QC_RELEASED" --> ACCEPT["Chấp nhận yêu cầu; trừ 500 KG<br/>Tồn kho còn 500 KG trong case này"]
    ACCEPT -->|"Giữ lotStatus"| R

    STATUS_AFTER -- "QC_REJECTED" --> REJECTED_REJECT["Từ chối yêu cầu<br/>Lỗi nghiệp vụ; không trừ tồn kho"]
    REJECTED_REJECT -->|"Giữ nguyên trạng thái"| J

    STATUS_AFTER -- "Trạng thái không hợp lệ/không xác định" --> REJECT_DEFAULT["Từ chối yêu cầu<br/>Lỗi nghiệp vụ; không trừ tồn kho"]

Payload đầy đủ tại trust boundary API: API là giao diện để hệ thống khác gửi yêu cầu. Payload phải có lotId, quantity, uom, productionOrderId; thiếu trường hoặc số lượng không dương phải bị từ chối trước khi áp dụng rule.

{
  "requestId": "PRD-REQ-20260807-001",
  "warehouseId": "WH-RM-HCM-01",
  "lotId": "LOT-RM-20260807-001",
  "itemId": "RM-SUGAR-001",
  "quantity": 500,
  "uom": "KG",
  "productionOrderId": "MO-20260807-001",
  "requestedAt": "2026-08-07T10:00:00+07:00",
  "requestedBy": "USR-PROD-001"
}

Option	Cơ chế	Đánh giá theo tiêu chí DC-NF-LOT-001
OPT-NF-LOT-001	Cho cấp phát theo số lượng tồn kho, QC kiểm tra sau.	Nhanh cho sản xuất nhưng không ngăn lô chưa kiểm tra đi vào sản xuất. Không đạt tiêu chí kiểm soát chất lượng.
OPT-NF-LOT-002	Đặt lô QC_PENDING; chỉ cấp phát khi QC_RELEASED.	Chặn rủi ro trước cấp phát, có trạng thái truy vết, xử lý được PASS và FAIL. Đạt tiêu chí.
OPT-NF-LOT-003	QC xác nhận ngoài ERP bằng email hoặc bảng tính.	Có thể kiểm tra thủ công nhưng ERP không có bằng chứng trạng thái đáng tin cậy. Không đạt tiêu chí truy vết hệ thống.

Decision criterion ID	Tiêu chí quyết định	Bằng chứng đánh giá
DC-NF-LOT-001	Không cấp phát lô chưa có kết quả QC đạt.	PRD-REQ-20260807-001 đến trước QC-20260807-001.
DC-NF-LOT-002	Có truy vết trạng thái, kết quả QC, người ghi nhận và thời điểm.	Cần phân biệt QC_PENDING, QC_RELEASED, QC_REJECTED.
DC-NF-LOT-003	Không trừ tồn kho khi yêu cầu bị từ chối.	Tránh chênh lệch giữa tồn kho sổ sách và tồn kho có thể dùng.

Loại kết luận	Nội dung	Trạng thái thẩm quyền
Recommendation (khuyến nghị BA)	Chọn OPT-NF-LOT-002; áp dụng BR-NF-LOT-001 đến BR-NF-LOT-004. Lý do: chỉ option này đạt đủ DC-NF-LOT-001 đến DC-NF-LOT-003.	IN_REVIEW; không phải quyết định được cấp quyền.
Authorized decision (quyết định có thẩm quyền)	Chưa có quyết định được ghi nhận cho SCN-NF-LOT-001.	Không được suy diễn từ khuyến nghị, metadata, hoặc trạng thái IN_REVIEW.
Authority cần quyết định	Business Owner xác nhận quy trình; Quality Owner xác nhận tiêu chí QC; Architect xác nhận cách thực thi ERP/API.	Verification required trước production.

Artifact đầu ra: /02-handbook/08-business-rules-state-and-decision-analysis.md ghi scenario này như ví dụ học liệu; liên kết CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY. Các artifact nguồn đều IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, dữ liệu tổng hợp.

Consequence if Wrong (hậu quả nếu sai): nếu ERP cho phép QC_PENDING cấp phát, 500 KG có thể đi vào MO-20260807-001 trước khi QC đạt. Nếu ERP trừ tồn kho khi từ chối, tồn kho khả dụng sai 500 KG. Nếu ghi khuyến nghị như quyết định được cấp quyền, corpus tạo bằng chứng quản trị sai. Case này không diễn giải nghĩa vụ pháp lý hay xác nhận tuân thủ an toàn thực phẩm; cần Quality Owner và Legal Owner xác minh khi dùng ngoài học liệu.

9. Related Concepts & Dependencies

Core

Phân tích quy tắc nghiệp vụ, trạng thái và quyết định không tự tạo nguồn sự thật mới. Nó nối các nguồn canonical: nguồn sự thật được kiểm soát duy nhất cho một loại nội dung. BA đọc rule từ CANONICAL_BUSINESS_RULES, thuộc tính dữ liệu từ CANONICAL_DATA_DICTIONARY, định danh bền vững từ TRACEABILITY_ID_REGISTRY; handbook chỉ diễn giải cách dùng và giữ liên kết. Lý do: chép nguyên rule vào nhiều tệp tạo nhiều bản có thể lệch nhau.

Luồng phụ thuộc bắt đầu từ cấu trúc học liệu trong /01-curriculum/CHAPTER_MANIFEST.md và /01-curriculum/01_CURRICULUM_ARCHITECTURE.md. Chapter này dùng cấu trúc đó để giữ đúng vị trí section 9. Template dự kiến được tra trong /01-curriculum/TEMPLATE_MANIFEST.md; template không tự cấp ID. Registry cấp và giữ quan hệ ID; catalog rule giữ nội dung rule; data dictionary giữ nghĩa dữ liệu logic.

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

flowchart TB
    A["/01-curriculum/CHAPTER_MANIFEST.md<br/>Cấu trúc chapter"] --> H["/02-handbook/08-business-rules-state-and-decision-analysis.md<br/>Diễn giải cách dùng, giữ liên kết"]
    B["/01-curriculum/01_CURRICULUM_ARCHITECTURE.md<br/>Kiến trúc curriculum"] --> H
    C["CANONICAL_BUSINESS_RULES<br/>Nội dung BR canonical"] --> H
    D["CANONICAL_DATA_DICTIONARY<br/>Định nghĩa dữ liệu canonical"] --> H
    E["TRACEABILITY_ID_REGISTRY<br/>Cấp ID, giữ liên kết bền vững"] --> H
    F["/01-curriculum/TEMPLATE_MANIFEST.md<br/>Danh mục template; không cấp ID"] --> H

    F --> T["Template hạ nguồn<br/>Dùng template đã tra"]
    E --> G["Artifact hạ nguồn<br/>Tham chiếu ID, không tự cấp ID"]
    C --> G
    D --> G
    H -. "diễn giải cách dùng" .-> T
    H -. "diễn giải cách dùng" .-> G

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Scenario SCN-NF-LOT-001 đã dùng các trạng thái QC_PENDING, QC_RELEASED, QC_REJECTED và các ID BR-NF-LOT-001 đến BR-NF-LOT-004.

Current Behavior: chapter ghi ví dụ trạng thái và liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY. Chapter không trở thành catalog rule hoặc data dictionary thứ hai.

Underlying Need: learner cần biết rule nào điều khiển chuyển trạng thái, dữ liệu nào xác định lot, và ID nào giữ liên kết qua requirement, thiết kế, test. Bằng chứng: nếu QC_PENDING được diễn giải khác nhau giữa rule catalog và handbook, cùng một lot có thể được cấp phát hoặc bị chặn tùy tài liệu người đọc chọn.

Options:

Option	Cách làm	Đánh giá
OPT-NF-DEP-001	Chép toàn văn rule, trường dữ liệu và ID vào handbook	Tạo bản sao nguồn; rủi ro lệch phiên bản cao
OPT-NF-DEP-002	Handbook diễn giải ngắn, tham chiếu artifact canonical và giữ nguyên ID	Giữ một nguồn sự thật cho mỗi loại nội dung
OPT-NF-DEP-003	Chỉ ghi tên nghiệp vụ, không ghi ID hoặc đường dẫn	Người đọc không truy được nguồn kiểm soát

Decision Criteria:

ID tiêu chí	Tiêu chí	Lý do
DC-NF-DEP-001	Một nội dung rule chỉ có một nguồn canonical	Ngăn xung đột nội dung
DC-NF-DEP-002	Liên kết giữ nguyên Artifact ID, filename và persistent ID	Cho phép truy vết ổn định
DC-NF-DEP-003	Handbook không suy diễn authority, baseline hoặc approval	IN_REVIEW không phải phê duyệt

Decision: khuyến nghị OPT-NF-DEP-002. Handbook tham chiếu BR-NF-LOT-001 đến BR-NF-LOT-004, không chép lại như rule canonical mới. Đây là khuyến nghị biên soạn, không phải quyết định vận hành Nova Foods.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết artifact. Business Owner, Quality Owner, Architect, QA Owner, Legal Owner hoặc Accounting Owner giữ thẩm quyền theo nội dung chuyên môn; không có approval được ghi nhận tại v0.9.0.

Artifact: /02-handbook/08-business-rules-state-and-decision-analysis.md tham chiếu:

Loại phụ thuộc	Artifact ID	Filename canonical	Vai trò tại chapter
Cấu trúc chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Giữ slug, title, thứ tự section
Kiến trúc học liệu	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Giữ dependency giữa chapter và lifecycle
Đăng ký ID	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm soát ID như BR-NF-LOT-001
Catalog rule	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nguồn canonical của business rule
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nguồn canonical của định nghĩa dữ liệu
Danh mục template	TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Xác định template dự kiến, không cấp ID

Consequence if Wrong: nếu handbook đổi BR-NF-LOT-001 thành ID khác mà không qua registry, artifact hạ nguồn có thể liên kết nhầm rule. Nếu handbook tự định nghĩa lại QC_RELEASED, Quality Owner và QA có thể kiểm tra hai nghĩa khác nhau. Nếu bản sao rule được sửa im lặng, learner không biết bản nào đúng trong phạm vi IN_REVIEW.

Senior Lens

Phân biệt ba loại liên kết. Liên kết nội dung trỏ tới nơi định nghĩa rule hoặc dữ liệu. Liên kết định danh trỏ tới registry giữ ID duy nhất. Liên kết điều hướng trỏ tới chapter hoặc template giúp người dùng tìm đúng artifact. Một link có thể phục vụ nhiều mục đích, nhưng không được dùng link điều hướng để chứng minh nội dung canonical.

Khi cần diễn giải, ghi “tham chiếu” thay vì “quy định”. Ví dụ, QC_PENDING trong handbook là nhãn trạng thái của scenario mô phỏng; nghĩa logic canonical phải được kiểm tra tại CANONICAL_BUSINESS_RULES và thuộc tính dữ liệu liên quan phải được kiểm tra tại CANONICAL_DATA_DICTIONARY. Cầu nối suy luận là: trạng thái cần rule để biết chuyển đổi hợp lệ, và cần dữ liệu để xác định đối tượng bị chuyển đổi.

Quick Reference

Quy tắc	Áp dụng
Giữ nguyên Artifact ID, filename, version và status khi tham chiếu	Không đổi tên rút gọn, không dịch ID
Một rule chỉ có một nguồn canonical	Handbook giải thích, không nhân bản catalog
Một định nghĩa dữ liệu chỉ có một nguồn canonical	Không tự thêm kiểu dữ liệu, độ dài, hoặc nghĩa trường
ID mới phải đi qua TRACEABILITY_ID_REGISTRY	Không tự tạo ID trong chapter
IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND là metadata hiện hành	Không diễn giải thành baseline, approval hoặc production-ready
Nova Foods là mô phỏng giáo dục	Chỉ dùng dữ liệu tổng hợp; không suy diễn vận hành thực tế

Core

Ma trận truy vết liên kết một nhu cầu với các hiện vật triển khai và kiểm thử. Mỗi ID chỉ tham chiếu nguồn chân lý (canonical source of truth), không chép lại nội dung rule, định nghĩa dữ liệu, hay hợp đồng API. Bằng chứng: TRACEABILITY_ID_REGISTRY quản lý ID; CANONICAL_BUSINESS_RULES quản lý BR; CANONICAL_DATA_DICTIONARY quản lý DATA. Cả ba đang IN_REVIEW, v0.9.0, ngày 2026-08-07; không là baseline hay approval.

Applied

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

Trường	Nội dung
Facts	Seed chỉ xác minh artifact-level ID và đường dẫn canonical; không cung cấp ID bản ghi NEED, REQ, BR, AC, DATA/API hoặc TC cụ thể.
Current Behavior	Tác giả có thể vô tình tạo ID cục bộ trong handbook, làm registry và liên kết sau này lệch nhau.
Underlying Need	Một thay đổi requirement phải tìm được rule, acceptance criteria, dữ liệu/API và test case bị ảnh hưởng.
Options	Tạo ID mới trong chapter; hoặc ghi liên kết tới registry/canonical artifact và chờ ID được đăng ký.
Decision Criteria	ID phải có trong TRACEABILITY_ID_REGISTRY; nội dung BR/DATA phải trỏ đúng catalog; không suy diễn approval.
Decision	Dùng bảng liên kết dưới đây làm cấu trúc truy vết. Chỉ điền ID bản ghi sau khi registry đăng ký.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability; Business Owner, Architect, QA và owner chuyên môn xác nhận nội dung thuộc thẩm quyền.
Artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Một TC có thể kiểm thử rule cũ; API dùng trường không còn hiệu lực; AC không chứng minh REQ; thay đổi không được phát hiện trước delivery.

Loại liên kết	ID bản ghi hiện có từ seed	Nguồn chân lý phải tham chiếu	Liên kết tối thiểu phải ghi	Mục đích kiểm tra
NEED	Chưa được cung cấp	TRACEABILITY_ID_REGISTRY	NEED-ID liên kết REQ-ID	Chứng minh requirement giải quyết nhu cầu nào
REQ	Chưa được cung cấp	TRACEABILITY_ID_REGISTRY	REQ-ID liên kết NEED-ID, BR-ID, AC-ID	Phân biệt yêu cầu với rule và tiêu chí nghiệm thu
BR	Chưa được cung cấp	CANONICAL_BUSINESS_RULES	BR-ID liên kết REQ-ID, AC-ID, DATA-ID	Giữ logic nghiệp vụ tại catalog rule, không chép vào ma trận
AC	Chưa được cung cấp	TRACEABILITY_ID_REGISTRY	AC-ID liên kết REQ-ID, BR-ID, TC-ID	Cho QA biết điều kiện quan sát được để chấp nhận
DATA/API	Chưa được cung cấp	CANONICAL_DATA_DICTIONARY	DATA-ID hoặc API-ID liên kết BR-ID, REQ-ID, TC-ID	Kiểm tra field, kiểu dữ liệu, contract API và rule dùng cùng khái niệm
TC	Chưa được cung cấp	Registry khi test artifact được đăng ký	TC-ID liên kết AC-ID, BR-ID, DATA-ID hoặc API-ID	Chứng minh test basis và phạm vi regression

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

flowchart TB
    START["Thay đổi requirement"] --> OWNER["Principal IT Business Analyst /<br/>Technical Curriculum Author<br/>duy trì traceability"]
    OWNER --> GATE{"ID đã có tại nguồn chân lý tương ứng?"}

    GATE -->|Chưa| WAIT["Chờ đăng ký ID<br/>Không tạo ID cục bộ"]
    WAIT -.->|Sau khi đăng ký| GATE
    GATE -->|Rồi| MAP["Cập nhật liên kết truy vết"]

    MAP --> NEED["NEED-ID<br/>TRACEABILITY_ID_REGISTRY"]
    MAP --> REQ["REQ-ID<br/>TRACEABILITY_ID_REGISTRY"]
    MAP --> BR["BR-ID<br/>CANONICAL_BUSINESS_RULES"]
    MAP --> AC["AC-ID<br/>TRACEABILITY_ID_REGISTRY"]
    MAP --> DATA["DATA-ID / API-ID<br/>CANONICAL_DATA_DICTIONARY"]
    MAP --> TC["TC-ID<br/>Registry khi test artifact được đăng ký"]

    REQ -->|giải quyết| NEED
    REQ -->|liên kết| BR
    REQ -->|được nghiệm thu bởi| AC
    BR -->|dùng dữ liệu/API| DATA
    BR -->|được kiểm thử bởi| TC
    AC -->|được kiểm thử bởi| TC
    DATA -->|làm basis kiểm thử| TC

    MAP --> CONFIRM["Xác nhận nội dung<br/>thuộc thẩm quyền"]
    ACTORS["Business Owner<br/>Architect<br/>QA<br/>Owner chuyên môn"] --> CONFIRM
    CONFIRM --> CHECK{"ID đã đăng ký;<br/>BR/DATA trỏ đúng catalog;<br/>không suy diễn approval?"}

    CHECK -->|Không| RISK["TC kiểm thử rule cũ;<br/>API dùng field hết hiệu lực;<br/>AC không chứng minh REQ;<br/>thay đổi không được phát hiện trước delivery"]
    CHECK -->|Không| FIX["Sửa liên kết hoặc nội dung"]
    FIX --> MAP
    CHECK -->|Có| OUTCOME["Theo dõi tác động từ requirement<br/>đến rule, AC, dữ liệu/API và test"]

Senior Lens

Không dùng BR-ID để thay REQ-ID. Requirement nói hệ thống cần đạt gì; business rule nói điều kiện nghiệp vụ chi phối quyết định; acceptance criteria là điều kiện kiểm tra được; test case là bằng chứng thực thi. Bằng chứng suy luận: một rule có thể phục vụ nhiều requirement, còn một TC có thể kiểm tra nhiều AC. Gộp ID sẽ mất khả năng đánh giá tác động đúng mức.

Quick Reference

Kiểm tra trước khi ghi liên kết	Kết quả hợp lệ
ID xuất hiện trong registry?	Có; nếu chưa có, ghi trạng thái chưa đăng ký, không tự tạo ID trong handbook.
BR có nội dung bị chép lại?	Không; chỉ trỏ CANONICAL_BUSINESS_RULES.
DATA/API có định nghĩa field bị chép lại?	Không; chỉ trỏ CANONICAL_DATA_DICTIONARY.
TC liên kết AC hoặc BR?	Có khi áp dụng; nếu chưa có test artifact, ghi thiếu liên kết để quản lý gap.
Trạng thái bị diễn giải thành approval?	Không; toàn bộ liên kết hiện thuộc IN_REVIEW, v0.9.0.

Core

Lan truyền thay đổi là việc một thay đổi tại nguồn kiểm soát làm các artifact phụ thuộc phải được rà soát, cập nhật, hoặc bị chặn sử dụng. Phụ thuộc thay đổi im lặng khi nguồn sửa nội dung, trạng thái, ID, đường dẫn, phân loại nguồn, hoặc ý nghĩa dữ liệu nhưng không ghi version, lịch sử thay đổi, impact analysis, và liên kết truy vết.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu tổng hợp. Tại v0.9.0, trạng thái IN_REVIEW nghĩa là còn xem xét. Nó không nghĩa APPROVED, BASELINED, compliant, hoặc production-ready. Nếu artifact hạ nguồn đọc sai trạng thái này, learner có thể dùng nội dung review như quyết định ERP thật.

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

flowchart TB
    A[Canonical artifact thay đổi] --> B[Ghi version và lịch sử thay đổi]
    B --> C[Xác định artifact phụ thuộc]
    C --> D[Phân tích ảnh hưởng]
    D --> E{Ý nghĩa, ID, nguồn, dữ liệu hay trạng thái đổi?}
    E -->|Có| F[Chặn dùng artifact hạ nguồn chịu ảnh hưởng]
    F --> G[Ngăn dùng nội dung review như quyết định ERP thật]
    F --> H[Cập nhật liên kết và nội dung hạ nguồn]
    H --> I[QA traceability]
    I --> J[v0.9.0 giữ trạng thái IN_REVIEW]
    J --> K[Không phải APPROVED, BASELINED, compliant hoặc production-ready]
    E -->|Không| L[Ghi nhận không ảnh hưởng]

Applied

Mục	Nội dung
Facts	/01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, và handbook đều đang IN_REVIEW, v0.9.0, ngày 2026-08-07. Các nguồn nêu rõ chưa có baseline reference và approval reference.
Current Behavior	Một bản sao nội dung handbook ghi “rule đã chốt” nhưng không dẫn lại artifact canonical, không ghi thay đổi trạng thái, không cập nhật version.
Underlying Need	Người đọc cần biết nội dung nào đang là kế hoạch học liệu, nội dung nào có thể dùng làm test basis, và nội dung nào cần thẩm quyền Business Owner, Legal Owner, Accounting Owner, Security, Architect, hoặc QA xác nhận.
Options	1. Giữ bản sao và sửa tay khi phát hiện lệch. 2. Chỉ tham chiếu ID, đường dẫn canonical, version, status; mọi diễn giải hạ nguồn ghi rõ nguồn và trạng thái.
Decision Criteria	Không tạo nguồn chân lý thứ hai; giữ nguyên ID; phát hiện lệch trước khi dùng cho requirement, test case, API, dữ liệu, hoặc đào tạo; không suy diễn approval.
Decision	Chọn phương án 2. Artifact hạ nguồn chỉ diễn giải tác động; không sao chép lại rule canonical như rule mới.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability. Nội dung nghiệp vụ, pháp lý, kế toán, bảo mật, kiến trúc, QA cần owner chuyên môn tương ứng xác nhận trong artifact kiểm soát.
Artifact	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; /02-handbook/08-business-rules-state-and-decision-analysis.md.
Consequence if Wrong	Rule bị đổi im lặng có thể làm acceptance criteria kiểm sai; test case xác nhận hành vi cũ; API trả enum cũ; data dictionary mô tả trạng thái sai; learner tưởng IN_REVIEW là đã phê duyệt.

Senior Lens

Thay đổi không chỉ là sửa câu chữ. Đổi IN_REVIEW thành một trạng thái khác đổi mức tin cậy của toàn bộ nội dung tham chiếu. Bằng chứng là metadata của các artifact upstream nêu rõ IN_REVIEW không tạo baseline hay approval. Vì vậy, mọi artifact dùng trạng thái này làm điều kiện quyết định phải được rà soát.

Loại thay đổi im lặng	Cái gãy	Dấu hiệu kiểm tra
Đổi ID canonical	Liên kết traceability trỏ sai hoặc mất liên kết	ID trong handbook không còn khớp registry
Đổi đường dẫn tệp	Người đọc dùng bản cũ hoặc bản sao	Link không trỏ /01-curriculum/ canonical
Đổi source classification	Claim chuẩn, pháp lý, hoặc good practice bị diễn đạt quá thẩm quyền	Safe use boundary bị mất khỏi diễn giải
Đổi định nghĩa trường dữ liệu	Mapping API, validation, báo cáo, test data lệch nhau	Data dictionary và API description mô tả khác kiểu, nghĩa, hoặc giá trị
Đổi business rule	REQ, AC, TC kiểm hành vi cũ	Rule reference không có version hoặc lịch sử thay đổi tương ứng
Đổi trạng thái artifact	Nội dung review bị dùng như baseline	Có từ “đã chốt”, “đã phê duyệt”, “production-ready” nhưng không có reference minh bạch

Quy tắc kiểm soát: khi dependency đổi ý nghĩa, ID, source boundary, trạng thái, hoặc cấu trúc dữ liệu, dừng tái sử dụng nội dung phụ thuộc cho đến khi impact analysis ghi nhận rõ. Không bù bằng sửa câu riêng lẻ. Cần kiểm cả nơi tiêu thụ: requirement, acceptance criteria, test case, data/API description, template, và handbook.

Quick Reference

Kiểm tra trước khi dùng artifact phụ thuộc	Kết quả đúng
ID còn đúng registry?	Giữ nguyên canonical ID, không tự đặt biến thể
Đường dẫn còn canonical?	Dùng đúng /01-curriculum/... hoặc đường dẫn kiểm soát đã công bố
Status và version còn khớp?	IN_REVIEW, v0.9.0, ngày 2026-08-07 khi chưa có bản mới được ghi nhận
Nguồn có đổi phân loại hoặc safe use boundary?	Giữ nhãn Verification required khi chưa có xác minh chuyên môn
Nội dung hạ nguồn có biến claim thành approval?	Không; phải nêu rõ chưa có baseline và approval reference
Thay đổi có ảnh hưởng dữ liệu hoặc API?	Rà soát data definition, validation, mapping, error handling, AC và TC cùng đợt

10. Common Mistakes & Anti-patterns

Core

Business rule analysis fail when team records conclusion, not evidence. Người mới thường viết “hệ thống chặn đơn vượt hạn mức” nhưng thiếu điều kiện, dữ liệu đầu vào, thời điểm kiểm tra, người có quyền ngoại lệ, và hành vi khi lỗi. Câu này chưa đủ để cấu hình ERP, viết acceptance criteria, hoặc kiểm thử.

Sai lầm cụ thể	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Viết rule như khẩu hiệu	Có từ “nhanh”, “hợp lý”, “đúng quy trình”, không có điều kiện đo được	Nhầm policy với rule thực thi được	Tách thành điều kiện, dữ liệu, quyết định, kết quả, ngoại lệ
Gộp nhiều quyết định vào một rule	Một câu chứa “và”, “hoặc”, “trừ khi” nhưng không có bảng quyết định	Muốn viết ngắn, bỏ qua tổ hợp điều kiện	Tách rule theo một quyết định; dùng decision table khi nhiều điều kiện
Dùng trạng thái như ghi chú tự do	Người dùng nhập trạng thái không có trong danh sách; chuyển trạng thái không có điều kiện	Không lập state model trước khi viết màn hình	Xác định state, transition, trigger, guard condition, actor
Chỉ mô tả happy path	Không có xử lý dữ liệu thiếu, lỗi tích hợp, hủy, trả lại, hoặc retry	Team giả định lỗi hiếm nên chưa cần	Ghi tối thiểu một nhánh lỗi cho mỗi điểm đổi trạng thái hoặc ghi nhận tài chính
Nêu rule nhưng không chỉ nguồn	Cột Source trống, hoặc ghi “BA xác nhận”	Nhầm người ghi nhận với người có thẩm quyền	Gắn nguồn, loại nguồn, owner cần xác minh, trạng thái Verification required
Sao chép rule sang nhiều tài liệu	Requirement, API, test case có câu rule khác nhau	Không có nguồn chân lý canonical	Tham chiếu CANONICAL_BUSINESS_RULES; không sao chép rồi sửa cục bộ
Đặt tên trạng thái theo giao diện	Có trạng thái như Đã bấm lưu, Màu đỏ, Cần xem	Nhầm UI state với business state	Giữ business state độc lập UI; mô tả UI là hành vi trình bày
Biến assumption thành fact	Nội dung mô phỏng bị viết như chính sách Nova Foods thật	Không giữ nhãn dữ liệu tổng hợp	Gắn “project assumption” hoặc “Verification required”; giữ Nova Foods là mô phỏng giáo dục

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.

Mục	Nội dung
Facts	Đơn bán hàng mô phỏng SO-NF-2026-0087 trị giá 125.000.000 VND được tạo khi khách hàng còn dư nợ mô phỏng 90.000.000 VND.
Current Behavior	Tài liệu nháp ghi: “Đơn vượt hạn mức tín dụng phải được duyệt.” Không nêu hạn mức, thời điểm tính dư nợ, trạng thái đơn, hay người duyệt.
Underlying Need	ERP cần quyết định được đơn có chuyển từ DRAFT sang PENDING_CREDIT_REVIEW hay không, rồi mới cho phép xử lý tiếp.
Options	1. Cho mọi đơn vượt ngưỡng tự chuyển APPROVED. 2. Chặn mọi đơn vượt ngưỡng. 3. Chuyển đơn vào chờ rà soát khi tổng dư nợ sau đơn vượt hạn mức đã được xác minh.
Decision Criteria	Quyết định cần tránh phát hành đơn khi dữ liệu hạn mức chưa rõ; vẫn phải cho phép luồng rà soát có kiểm soát; không tự suy diễn chính sách tín dụng thật.
Decision	Với case học liệu, chọn option 3: khi phép tính mô phỏng cho thấy dư nợ sau đơn vượt hạn mức mô phỏng, đơn chuyển PENDING_CREDIT_REVIEW. Không mô tả quyền phê duyệt cuối vì chưa có nguồn thẩm quyền được xác minh.
Authority	Business Owner và Credit Owner là vai trò cần xác minh ngưỡng, công thức, quyền ngoại lệ. BA ghi nhận quyết định nháp, không tự xác nhận policy.
Artifact	Rule và trạng thái phải được liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, và TRACEABILITY_ID_REGISTRY; các artifact hiện IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu đơn bị tự duyệt do rule thiếu điều kiện, team có thể tạo giao dịch mô phỏng sai luồng, test sai expectation, và che giấu điểm cần Business Owner xác minh.

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

stateDiagram-v2
    direction TB
    [*] --> DRAFT

    DRAFT --> DRAFT: verifiedCreditLimit missing or unverified; hold
    DRAFT --> PENDING_CREDIT_REVIEW: verified limit; totalExposure > verifiedCreditLimit
    DRAFT --> READY_FOR_FULFILLMENT: verified limit; totalExposure <= verifiedCreditLimit

    PENDING_CREDIT_REVIEW --> DRAFT: credit data missing or corrected; recalculate required

    note right of PENDING_CREDIT_REVIEW
        Safe boundary: hold here or return to DRAFT.
        Never auto-transition to READY_FOR_FULFILLMENT.
        Business Owner and Credit Owner must verify
        verifiedCreditLimit, totalExposure formula,
        and exception authority.
    end note

[!WARNING] Không thay verifiedCreditLimit bằng số tự đặt hoặc diễn giải từ luật, kế toán, tín dụng, hay email không có owner xác minh. Ranh giới phục hồi an toàn: giữ đơn ở PENDING_CREDIT_REVIEW hoặc trả về DRAFT; không tự chuyển READY_FOR_FULFILLMENT.

Senior Lens

Sửa anti-pattern không phải viết thêm mô tả. Sửa đúng là khôi phục chuỗi bằng chứng: fact nào quan sát được, dữ liệu nào quyết định, rule nào áp dụng, trạng thái nào đổi, ai cần xác minh, artifact nào tiêu thụ kết quả. Nếu một mắt xích chưa biết, ghi khoảng trống có kiểm soát thay vì bịa điều kiện.

Team delivery hay sửa sai bằng cách “cho dev quyết định chi tiết”. Đây là chuyển rủi ro, không phải làm rõ. Dev có thể đề xuất cách thực thi, nhưng không nên tự chọn ngưỡng nghiệp vụ, quyền ngoại lệ, hoặc diễn giải pháp lý. BA cần đưa câu hỏi quyết định đúng owner, ghi nguồn và giữ nhãn chưa xác minh.

Quick Reference

Trước khi coi rule đủ dùng	Câu kiểm tra
Điều kiện	Dữ liệu nào làm rule đúng hoặc sai?
Hành động	Hệ thống đổi trạng thái, chặn, tính, hay thông báo gì?
Thời điểm	Rule chạy khi tạo, sửa, gửi duyệt, hay tích hợp?
Ngoại lệ	Dữ liệu thiếu hoặc lỗi thì giữ trạng thái nào?
Bằng chứng	Nguồn nào hỗ trợ rule; nguồn có thẩm quyền chưa?
Hạ nguồn	Requirement, acceptance criteria, test case, API và data definition có cùng nghĩa không?

Core

[!WARNING] Cảnh báo chỉ dùng khi lỗi có thể làm sai trạng thái, mất dấu vết, phát hành chứng từ sai, hoặc cho phép hành động không thể đảo ngược an toàn. Không dùng cảnh báo cho lỗi trình bày, sở thích ký hiệu, hoặc điểm chưa tối ưu. Cảnh báo quá nhiều làm người đọc bỏ qua cảnh báo thật.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã, số tiền và dữ liệu dưới đây là tổng hợp. Quy tắc và trạng thái trong /02-handbook/08-business-rules-state-and-decision-analysis.md đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải cấu hình ERP production hay quyết định đã phê duyệt.

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

stateDiagram-v2
    direction TB
    [*] --> DRAFT
    DRAFT --> IN_REVIEW: gửi xem xét
    IN_REVIEW --> APPROVED: quyết định hợp lệ
    IN_REVIEW --> DRAFT: yêu cầu sửa
    APPROVED --> POSTED: ghi nhận nghiệp vụ
    POSTED --> REVERSED: đảo bút toán có kiểm soát
    REVERSED --> [*]

Sơ đồ là Mermaid state diagram, không phải BPMN. Nó chỉ minh họa ranh giới phục hồi: POSTED không quay thẳng về DRAFT; cần REVERSED để giữ lịch sử.

Applied

Rủi ro thật	Facts	Current Behavior	Underlying Need	Options	Decision Criteria	Decision	Authority	Artifact	Consequence if Wrong	Safe recovery boundary
Ghi nhận phiếu nhập kho hai lần	Phiếu mô phỏng GRN-NF-2026-00041 có giá trị tổng hợp 12.500.000 VND; cùng mã được gửi lại sau lỗi mạng	ERP giả định tạo hai lần POSTED nếu nhận hai yêu cầu giống nhau	Ngăn tăng tồn kho và giá trị hàng tồn hai lần	Chặn theo GoodsReceiptID; cho phép tạo bản đảo; xóa bản đã ghi nhận	Có mất lịch sử không; có thay đổi tồn kho không; có thể kiểm toán không	Chặn gửi lặp trước POSTED; nếu đã POSTED, tạo REVERSED, không xóa	Business Owner xác nhận quy tắc kho; Accounting Owner xác nhận cách đảo ghi nhận	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; liên kết ID theo TRACEABILITY_ID_REGISTRY	Tồn kho, giá vốn và báo cáo quản trị mô phỏng sai	Chỉ đảo bản ghi sai khi xác định đúng GoodsReceiptID, lý do đảo và người có thẩm quyền; không sửa trực tiếp số lượng của bản POSTED
Xuất hóa đơn trước khi kiểm tra điều kiện	Đơn mô phỏng SO-NF-2026-00118 chuyển sang APPROVED, nhưng chưa có xác nhận giao hàng	Nhóm delivery xem APPROVED là đủ để phát hành	Tách phê duyệt đơn khỏi sự kiện giao hàng hoặc điều kiện chứng từ	Cho phép phát hành từ APPROVED; chặn đến khi có bằng chứng điều kiện; tự động phát hành	Có căn cứ nghiệp vụ được xác nhận không; có ảnh hưởng kế toán hoặc pháp lý không; có thể thu hồi an toàn không	Chặn phát hành tự động. Gắn Verification required cho điều kiện chứng từ và chuyển Accounting Owner, Legal Owner xác minh	Accounting Owner và Legal Owner; BA không tự diễn giải luật	Tham chiếu Luật Kế toán, Nghị định 123/2020/NĐ-CP là nguồn cần xác minh; không tạo clause mới	Chứng từ mô phỏng sai trạng thái, dẫn tới giả định tuân thủ sai	Dừng tại APPROVED; không chuyển POSTED hoặc tạo chứng từ cho đến khi có quyết định được ghi nhận từ vai trò có thẩm quyền
Mở lại lô thực phẩm đã khóa truy xuất	Lô mô phỏng LOT-NF-2026-08-017 bị đánh dấu QUARANTINED do chênh lệch kết quả kiểm tra	Người vận hành đổi trực tiếp trạng thái thành khả dụng để kịp giao hàng	Bảo toàn chuỗi truy xuất và quyết định chất lượng	Cho sửa trạng thái; tạo quyết định giải tỏa riêng; xóa cờ cách ly	Có giữ lịch sử không; người quyết định có đúng thẩm quyền không; có bằng chứng kiểm tra không	Không cho sửa đè. Chỉ tạo sự kiện giải tỏa mới nếu có quyết định Quality Owner được ghi nhận	Quality Owner; Legal Owner xác minh nghĩa vụ an toàn thực phẩm nếu áp dụng	CANONICAL_BUSINESS_RULES; nguồn Luật An toàn thực phẩm chỉ dùng cho bối cảnh, không suy diễn nghĩa vụ chi tiết	Lô không đạt điều kiện có thể bị dùng trong mô phỏng luồng giao hàng; mất dấu vết quyết định	Giữ QUARANTINED khi thiếu bằng chứng. Không “phục hồi” bằng đổi cờ trực tiếp; tạo sự kiện mới, liên kết lô, lý do và người quyết định

Senior Lens

Dấu hiệu cần cảnh báo: hành động làm thay đổi tồn kho, số dư, trạng thái truy xuất, chứng từ, hoặc quyền truy cập; hành động không thể hoàn tác bằng bản ghi mới; hoặc hành động dựa vào thẩm quyền chưa được ghi nhận. Cầu nối suy luận: các đối tượng này ảnh hưởng lịch sử nghiệp vụ; lịch sử cần kiểm toán và truy vết; vì vậy sửa đè hoặc bỏ qua kiểm soát tạo rủi ro thật.

Không gắn cảnh báo cho câu “cần làm rõ màn hình nào hiển thị nút”. Đây là điểm thiết kế chưa rõ, chưa chứng minh tác động mất dữ liệu hay sai trạng thái. Chỉ nâng thành cảnh báo khi nút cho phép chuyển POSTED mà không có kiểm soát quyền, kiểm tra đầu vào, hoặc đường đảo có truy vết.

[!WARNING] Không gọi nội dung IN_REVIEW là “đã phê duyệt”, “đã baseline”, “đúng luật”, hoặc “được Nova Foods chấp thuận”. Bằng chứng hiện có chỉ xác nhận artifact đang xem xét. Không có approval reference hay baseline reference tại v0.9.0.

Quick Reference

Khi gặp tình huống	Làm	Không làm
Bản ghi đã POSTED bị sai	Tạo bản đảo hoặc sự kiện hiệu chỉnh có liên kết bản gốc	Xóa bản ghi hoặc đổi trực tiếp dữ liệu lịch sử
Thiếu thẩm quyền pháp lý, kế toán, chất lượng	Gắn Verification required; dừng quyết định; chuyển đúng Owner	Tự viết nghĩa vụ bắt buộc hoặc tự xác nhận tuân thủ
Cảnh báo xuất hiện	Nêu rủi ro, đối tượng ảnh hưởng, điều kiện dừng và ranh giới phục hồi	Dùng cảnh báo để nhấn mạnh sở thích hoặc lỗi nhỏ
Cần mô tả trạng thái	Ghi rõ trạng thái nguồn, trạng thái đích, điều kiện và cách phục hồi	Cho phép quay ngược trạng thái quan trọng mà không lưu sự kiện mới

Core

Năm lỗi này khác nhau vì mỗi lỗi làm hỏng một điểm kiểm soát khác của quy tắc nghiệp vụ. Mơ hồ là câu có nhiều cách hiểu. Thiếu thông tin là chưa đủ điều kiện để quyết định. Khẳng định thẩm quyền không có bằng chứng là gán quyết định cho vai trò, luật hoặc phê duyệt chưa được ghi nhận. Dùng sai ký pháp là biểu đồ hoặc bảng nói khác ý nghĩa chuẩn. Đứt truy vết là không lần được từ quy tắc tới nguồn, quyết định, yêu cầu và kiểm thử.

Loại lỗi	Dấu hiệu quan sát	Nguyên nhân gốc	Sửa đúng
Mơ hồ	“Đơn lớn phải được duyệt”	Không định nghĩa “lớn”, người duyệt, thời điểm	Tách ngưỡng, đơn vị VND, trạng thái kích hoạt, vai trò quyết định
Thiếu thông tin	Có điều kiện nhưng không có nhánh khi dữ liệu rỗng	BA chỉ ghi happy path	Ghi dữ liệu bắt buộc, xử lý thiếu dữ liệu, trạng thái chặn
Khẳng định thẩm quyền không có bằng chứng	“Luật yêu cầu”, “CFO đã duyệt” nhưng không có nguồn hoặc approval reference	Nhầm ý kiến với nguồn kiểm soát	Gắn nguồn chính thức; ghi Verification required khi chưa có Legal Owner hoặc Accounting Owner xác nhận
Dùng sai ký pháp	Gọi PlantUML activity diagram là BPMN	Đồng nhất công cụ vẽ với chuẩn ký pháp	Gọi đúng tên biểu đồ; chỉ dùng BPMN 2.0.2 khi ký pháp BPMN đúng
Đứt truy vết	Rule trong sơ đồ không có nguồn, không có test basis	Soạn nhiều artifact độc lập	Liên kết về /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md và artifact nguồn

Cảnh báo: Khẳng định sai rằng quy tắc đã được Legal Owner, Accounting Owner hoặc Business Owner phê duyệt có thể khiến đội triển khai cấu hình ERP theo thẩm quyền không tồn tại. IN_REVIEW tại v0.9.0 không phải APPROVED hay BASELINED.

Applied

Nova Foods 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	Bản nháp ghi: “Đơn bán hàng giá trị cao cần duyệt trước khi giao.” Giá trị đơn 120.000.000 VND được nhập, nhưng chưa xác định giá trị trước hay sau chiết khấu, ai duyệt, và trạng thái nào chặn giao.
Current Behavior	Nhóm cấu hình chặn giao mọi đơn từ 100.000.000 VND trở lên, tính trên tổng trước chiết khấu.
Underlying Need	Ngăn giao hàng khi đơn vượt ngưỡng rủi ro thương mại do người có thẩm quyền xác định.
Options	(1) Giữ câu tự do. (2) Chặn theo tổng trước chiết khấu. (3) Đưa câu thành giả định dự án, yêu cầu Business Owner xác định công thức, ngưỡng và vai trò.
Decision Criteria	Có bằng chứng nguồn; tính được nhất quán từ dữ liệu; xác định trạng thái chặn; có chủ thể quyết định; kiểm thử được.
Decision	Chọn (3). Không cấu hình ngưỡng 100.000.000 VND thành quy tắc canonical khi chưa có nguồn và thẩm quyền.
Authority	Business Owner quyết định chính sách thương mại; Accounting Owner xác nhận nếu cách tính liên quan số liệu kế toán; BA ghi nhận và truy vết, không tự quyết.
Artifact	Cập nhật nháp quy tắc trong phạm vi IN_REVIEW; liên kết /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md; trạng thái nội dung: Verification required.
Consequence if Wrong	Đơn hợp lệ có thể bị chặn, hoặc đơn rủi ro có thể giao. Báo cáo doanh thu và kiểm thử dùng các công thức khác nhau.

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

stateDiagram-v2
    direction TB

    state "DraftRule\nNội dung nháp" as DraftRule
    state "VerificationRequired\nGiữ IN_REVIEW\nDừng cấu hình gây tác động" as VerificationRequired
    state "AuthorityDecision\nBusiness Owner xác định công thức, ngưỡng và vai trò\nAccounting Owner xác nhận nếu liên quan số liệu kế toán" as AuthorityDecision
    state "BARecord\nBA ghi nhận, giữ IN_REVIEW\nLiên kết hai artifact tham chiếu/truy vết" as BARecord
    state "RuleEligibleForConfiguration\nCó artifact kiểm soát, bằng chứng thẩm quyền\nvà liên kết truy vết tương ứng" as RuleEligibleForConfiguration
    state "ConfigurationAllowed\nĐược phép cấu hình vận hành" as ConfigurationAllowed
    state "ConfigurationRisk\nĐơn hợp lệ có thể bị chặn hoặc đơn rủi ro có thể giao\nBáo cáo doanh thu và kiểm thử có thể dùng công thức khác nhau" as ConfigurationRisk

    [*] --> DraftRule
    DraftRule --> VerificationRequired: thiếu nguồn, thẩm quyền hoặc truy vết
    VerificationRequired --> VerificationRequired: bằng chứng nguồn hoặc thẩm quyền chưa đủ
    VerificationRequired --> AuthorityDecision: có bằng chứng nguồn; chuyển đúng chủ thể quyết định
    AuthorityDecision --> VerificationRequired: thiếu công thức, ngưỡng, vai trò hoặc xác nhận kế toán cần thiết
    AuthorityDecision --> BARecord: quyết định đủ; xác nhận kế toán đã có nếu cần
    BARecord --> VerificationRequired: artifact kiểm soát, bằng chứng thẩm quyền hoặc liên kết truy vết chưa đủ
    BARecord --> RuleEligibleForConfiguration: liên kết CANONICAL_BUSINESS_RULES.md và TRACEABILITY_ID_REGISTRY.md; đủ bằng chứng
    VerificationRequired --> ConfigurationRisk: vẫn cấu hình gây tác động
    BARecord --> ConfigurationRisk: cấu hình khi chưa đủ điều kiện
    ConfigurationRisk --> VerificationRequired: dừng cấu hình; giữ giả định hoặc Verification required; không ghi đã phê duyệt
    RuleEligibleForConfiguration --> ConfigurationAllowed
    ConfigurationAllowed --> [*]

Ranh giới phục hồi an toàn: dừng cấu hình gây tác động vận hành, giữ nội dung là giả định hoặc Verification required, không đổi thành “đã phê duyệt”. Chỉ nâng trạng thái khi artifact kiểm soát có bằng chứng thẩm quyền và liên kết truy vết tương ứng.

Senior Lens

Không sửa mơ hồ bằng cách tự chọn nghĩa “hợp lý”. Lý do: lựa chọn đó là quyết định nghiệp vụ, không phải chỉnh câu. Không sửa thiếu thông tin bằng giá trị mặc định không có nguồn. Lý do: giá trị mặc định biến khoảng trống thành hành vi ERP. Không dùng URL nguồn luật để tuyên bố Nova Foods tuân thủ. Luật và nghị định trong source seed cần Legal Owner xác minh khi chuyển thành yêu cầu hệ thống.

Ký pháp phải khớp mục đích. State diagram mô tả trạng thái và chuyển trạng thái. BPMN mô tả luồng nghiệp vụ bằng ký pháp BPMN 2.0.2 của OMG. PlantUML chỉ là công cụ hoặc cú pháp tạo hình; không tự tạo tính chuẩn BPMN. Khi biểu đồ không diễn đạt được điều kiện dữ liệu, ghi điều kiện trong bảng quyết định hoặc rule catalog thay vì nhồi văn bản vào mũi tên.

Quick Reference

Kiểm tra trước khi dùng quy tắc	Đạt khi
Một nghĩa	Thuật ngữ, ngưỡng, thời điểm, đơn vị và ngoại lệ xác định
Đủ điều kiện	Có nhánh đúng, sai, thiếu dữ liệu và trạng thái kết quả
Đúng thẩm quyền	Nguồn hoặc quyết định được ghi nhận; chưa có thì Verification required
Đúng ký pháp	Tên biểu đồ khớp chuẩn và ý nghĩa ký pháp
Liên tục truy vết	Lần được từ quy tắc tới nguồn, artifact và kiểm thử dự kiến
Đúng trạng thái	Không gọi nội dung IN_REVIEW phiên bản v0.9.0 là baseline hoặc approval

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 quy tắc theo ý kiến mạnh nhất. Senior BA tách ba việc: xác định sự thật, đánh giá lựa chọn, chuyển quyết định đến đúng thẩm quyền. Lý do: quy tắc ERP có thể tác động tồn kho, doanh thu, truy xuất hoặc dữ liệu cá nhân; người ghi nhận phân tích không tự có quyền quyết định vận hành, pháp lý, kế toán hay kiến trúc.

Tình huống	Bằng chứng cần có	Đánh đổi cần nêu	Thẩm quyền quyết định
Muốn tự động chuyển trạng thái đơn hàng	State diagram, điều kiện dữ liệu, lỗi đã quan sát trong dữ liệu tổng hợp	Tự động hóa nhanh hơn nhưng có thể khóa đơn sai khi dữ liệu nguồn chậm	Business Owner quyết định nghiệp vụ; Architect xác nhận khả thi kỹ thuật
Ngoại lệ cho phép sửa chứng từ sau khi phát hành	Nguồn kế toán hoặc pháp lý đã xác minh, loại chứng từ, dấu vết audit	Linh hoạt cho vận hành nhưng giảm tính bất biến và khả năng kiểm tra	Accounting Owner và Legal Owner
Giữ đơn khi thiếu thông tin giao hàng	Danh sách trường bắt buộc, tỷ lệ thiếu dữ liệu, tác động giao hàng	Chặn sớm giảm lỗi nhưng tăng đơn bị treo	Business Owner
Đồng bộ dữ liệu khách hàng sang hệ khác	Data classification, mục đích dùng, trường dữ liệu, sơ đồ tích hợp	Đủ dữ liệu cho vận hành nhưng tăng rủi ro lộ dữ liệu	Security, Legal Owner, Architect

Ngoại lệ không phải “đường tắt” cho quy tắc bình thường. Ngoại lệ chỉ hợp lệ khi xác định đủ điều kiện kích hoạt, người cho phép, trạng thái kết quả, dấu vết ghi nhận và cách quay về luồng chuẩn. Ví dụ, “cho phép xuất kho khẩn” chưa là quy tắc dùng được. Cần biết khẩn theo tiêu chí nào, ai xác nhận, lô hàng nào bị ảnh hưởng, hệ thống ghi lý do ở đâu, và trạng thái đơn hàng sau xuất kho là gì. Thiếu một điểm, ngoại lệ biến thành quyền tùy ý.

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

flowchart TB
    A[Senior BA phát hiện mâu thuẫn quy tắc] --> B{Có nguồn canonical<br/>và dữ liệu kiểm chứng?}

    B -- Không --> C[Senior BA ghi nguồn hoặc dữ liệu còn thiếu]
    C --> D[Senior BA ghi Verification required<br/>và giữ trạng thái hiện tại]
    D --> E[Không cấu hình quy tắc]
    E --> F[Senior BA yêu cầu owner đúng phạm vi xác nhận:<br/>Business Owner, Accounting Owner, Legal Owner,<br/>Security hoặc Architect]
    F --> G[Senior BA ghi trạng thái chờ xác minh]

    B -- Có --> H[Senior BA so sánh lựa chọn<br/>theo tiêu chí và hệ quả]
    H --> I[Senior BA lập gói khuyến nghị:<br/>facts, nguồn, giả định, lựa chọn bị loại,<br/>tiêu chí, rủi ro còn lại và bằng chứng]

    I --> J{Có tác động nghiệp vụ?}
    J -- Có --> J1[Thêm Business Owner:<br/>quyết định quy tắc nghiệp vụ]
    J -- Không --> K{Có tác động kế toán?}
    J1 --> K

    K -- Có --> K1[Thêm Accounting Owner:<br/>quyết định theo phạm vi kế toán]
    K -- Không --> L{Có tác động pháp lý?}
    K1 --> L

    L -- Có --> L1[Thêm Legal Owner:<br/>quyết định theo phạm vi pháp lý]
    L -- Không --> M{Có tác động bảo mật<br/>hoặc dữ liệu cá nhân?}
    L1 --> M

    M -- Có --> M1[Thêm Security:<br/>quyết định theo phạm vi bảo mật]
    M -- Không --> N{Có tác động kỹ thuật<br/>hoặc tích hợp?}
    M1 --> N

    N -- Có --> N1[Thêm Architect:<br/>xác nhận khả thi và tác động kỹ thuật]
    N -- Không --> O{Đã xác định ít nhất<br/>một owner bắt buộc?}
    N1 --> O

    O -- Chưa xác định owner --> D
    O -- Đã xác định --> P{Cần một owner hay<br/>nhiều owner đồng phê duyệt?}

    P -- Một owner --> Q[Senior BA bàn giao gói khuyến nghị<br/>cho owner có thẩm quyền]
    Q --> S{Kết quả quyết định?}

    P -- Nhiều owner --> R[Senior BA bàn giao gói khuyến nghị<br/>cho tất cả owner bắt buộc]
    R --> W{Kết quả từ tất cả<br/>owner bắt buộc?}
    W -- Đủ phê duyệt --> U
    W -- Có từ chối --> V
    W -- Thiếu xác nhận hoặc còn bất đồng --> X[Giữ trạng thái Chờ duyệt<br/>và không cấu hình quy tắc]
    X --> Y[Escalate đúng thẩm quyền<br/>khi còn bất đồng]

    S -- Chờ duyệt --> T[Senior BA ghi trạng thái Chờ duyệt<br/>và không cấu hình quy tắc]
    S -- Phê duyệt --> U[Senior BA ghi quyết định đã phê duyệt<br/>và bàn giao qua quy trình kiểm soát thay đổi;<br/>không tự cấu hình]
    S -- Từ chối --> V[Senior BA ghi lý do từ chối,<br/>giữ trạng thái hiện tại<br/>và không cấu hình quy tắc]

Xung đột stakeholder phải ghi theo lợi ích và bằng chứng, không ghi thành tranh luận cá nhân. Sales có thể muốn bỏ kiểm tra tín dụng để chốt đơn nhanh. Finance có thể muốn chặn đơn để giảm rủi ro công nợ. Cầu nối suy luận là: mục tiêu Sales đo tốc độ chốt đơn; mục tiêu Finance đo mức rủi ro; quy tắc cần dữ liệu như hạn mức, dư nợ, tuổi nợ và quyền vượt ngưỡng. Nếu chưa có dữ liệu hoặc chủ sở hữu ngưỡng, Senior BA ghi Verification required trong CANONICAL_BUSINESS_RULES, không tự đặt ngưỡng VND.

Chất lượng bằng chứng quyết định mức chắc chắn của khuyến nghị. Bằng chứng mạnh gồm artifact kiểm soát có định danh, dữ liệu tổng hợp có nguồn và thời điểm, quy trình đã được mô tả nhất quán, hoặc xác nhận được ghi nhận từ vai trò có thẩm quyền. Ý kiến trong họp, ảnh chụp màn hình không rõ thời điểm, và “hệ thống cũ vẫn làm vậy” là đầu vào cần kiểm tra, không phải nguồn quyết định cuối. IN_REVIEW và v0.9.0 của /01-curriculum/CANONICAL_BUSINESS_RULES.md không tạo baseline, approval hay quyền áp dụng production.

Khuyến nghị có thể phòng vệ phải ghi: vấn đề, facts, nguồn, giả định, lựa chọn bị loại, tiêu chí so sánh, rủi ro còn lại, người có thẩm quyền và trạng thái quyết định. Khi chưa đủ bằng chứng, dùng câu: “Khuyến nghị tạm thời giữ trạng thái hiện tại vì chưa có nguồn canonical xác định điều kiện chuyển trạng thái; cần Business Owner xác nhận quy tắc và Architect xác nhận tác động tích hợp.” Câu này nêu giới hạn hiểu biết, lý do và bước quyết định; không bịa chắc chắn.

Senior Lens

Senior BA rà từng quy tắc theo chuỗi: điều kiện kích hoạt, dữ liệu đầu vào, trạng thái hiện tại, hành động, trạng thái kết quả, ngoại lệ, bằng chứng và người có thẩm quyền. Thiếu một mắt xích, quy tắc chưa đủ để cấu hình hay kiểm thử. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; không suy diễn thành quy tắc ERP thực tế.

Heuristic review	Kiểm tra cụ thể	Red flag	Ngưỡng escalation	Khi không áp dụng quy tắc thường
Một nguồn chân lý	Mỗi rule ID chỉ có một bản canonical trong CANONICAL_BUSINESS_RULES	Cùng rule có hai ngưỡng hoặc hai trạng thái kết quả	Dừng review khi artifact mâu thuẫn canonical	Quy tắc đang là giả định dự án và chưa có nguồn canonical
Điều kiện đo được	Ngưỡng dùng dữ liệu, đơn vị, thời điểm rõ	“Đơn lớn”, “khách quan trọng”, “gấp” không có định nghĩa	Escalate khi không thể viết test case xác định	Cần quyết định thủ công vì dữ liệu nguồn chưa đủ tin cậy
Chuyển trạng thái hợp lệ	Mỗi trạng thái đích có trạng thái trước và tác nhân hợp lệ	Có đường chuyển bỏ qua kiểm soát, ví dụ DRAFT sang POSTED	Escalate khi ảnh hưởng sổ sách, tồn kho, hóa đơn hoặc truy xuất lô	Quy trình khẩn cấp được Business Owner và owner chuyên môn xác định riêng
Ngoại lệ có rào chắn	Ngoại lệ nêu điều kiện, quyền override, log và hậu quả	“Manager có thể bỏ qua” nhưng không nêu phạm vi hay nhật ký	Escalate ngay khi override ảnh hưởng tiền, dữ liệu cá nhân, an toàn thực phẩm, bảo mật	Không cho phép override nếu kiểm soát thuộc pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm mà chưa có xác minh owner
Bằng chứng đủ mạnh	Phân biệt quan sát, dữ liệu, quyết định và giả định	Ý kiến workshop bị ghi thành fact	Escalate khi rule dựa duy nhất vào ký ức hoặc một cá nhân	Không dùng rule làm acceptance criterion khi bằng chứng chỉ là giả định
Tác động liên miền	Kiểm tra Sales, Warehouse, Finance, QA, Integration	Một rule sửa trạng thái đơn hàng nhưng không xét giữ hàng hay bút toán	Escalate khi thay đổi chạm từ hai domain trở lên	Tách rule nếu mỗi domain có owner, dữ liệu hoặc chu kỳ quyết định khác nhau

Dùng ngưỡng dừng thay vì “chốt tạm” khi rule có thể tạo giao dịch tài chính, xóa hay sửa dữ liệu truy xuất lô, làm lộ dữ liệu cá nhân, hoặc cho phép API vượt quyền. BA ghi Verification required, giữ rule ở IN_REVIEW, liên kết bằng chứng hiện có và chuyển câu hỏi đúng owner. Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, Luật An toàn thực phẩm và nguồn chính thức liên quan không tự biến thành cấu hình ERP; cần Legal Owner, Accounting Owner hoặc domain owner xác minh diễn giải và áp dụng.

Ví dụ: quy tắc thường “không cho xuất kho khi đơn bán chưa được duyệt” không áp dụng tự động cho tình huống thu hồi an toàn thực phẩm mô phỏng. Lý do: mục tiêu ưu tiên chuyển từ hoàn tất đơn hàng sang cô lập và truy xuất lô. Chỉ kích hoạt ngoại lệ khi quy trình thu hồi, quyền quyết định và dấu vết trạng thái được owner phù hợp xác định; không dùng nhãn “khẩn cấp” như quyền bỏ qua kiểm soát chung.

Senior Lens

Senior BA không biến thiếu bằng chứng thành kết luận. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, khuyến nghị phải tách rõ: fact (sự kiện có nguồn), assumption (giả định dự án), Verification required (cần xác minh), và quyết định đang chờ thẩm quyền. Cầu nối suy luận phải hiện diện: nguồn nào nói gì, nguồn đó đủ hay chưa, thiếu gì, thiếu đó đổi quyết định thế nào.

Mục ghi nhận	Ví dụ artifact-ready	Ý nghĩa kiểm soát
Fact	BR-INV-017 đang ở trạng thái IN_REVIEW trong CANONICAL_BUSINESS_RULES, version v0.9.0, ngày 2026-08-07.	Có bằng chứng từ artifact controlled, nhưng không chứng minh rule đã đúng cho vận hành.
Assumption	Giả định dự án: lô nguyên liệu bị khóa chất lượng không được cấp phát cho lệnh sản xuất.	Dùng để phân tích phương án; không gọi là quy định Nova Foods.
Verification required	Cần Quality Owner và Business Owner xác nhận trường hợp lô bị khóa nhưng cần dùng để kiểm nghiệm phá hủy.	Nêu đúng khoảng trống và người có thẩm quyền đóng khoảng trống.
Recommendation	Khuyến nghị giữ trạng thái khóa ngăn cấp phát tự động; thiết kế ngoại lệ riêng sau khi Quality Owner xác định điều kiện, bằng chứng và quyền cấp phép.	Kết luận có điều kiện, không bịa chắc chắn.
Decision status	OPEN — authority decision required	Không dùng APPROVED, BASELINED hay “đã thống nhất” khi chưa có tham chiếu ghi nhận.

Mẫu câu defensible recommendation, tức khuyến nghị có thể bảo vệ bằng bằng chứng: “Dựa trên CANONICAL_BUSINESS_RULES đang IN_REVIEW và giả định dự án về kiểm soát lô, khuyến nghị không cho phép cấp phát tự động khi trạng thái lô là QUALITY_HOLD. Bằng chứng hiện có chưa xác định ngoại lệ kiểm nghiệm phá hủy. Vì ngoại lệ có thể ảnh hưởng truy xuất và kiểm soát chất lượng, Verification required từ Quality Owner và Business Owner trước khi ghi rule canonical hoặc acceptance criterion.” Câu này nêu phạm vi bằng chứng, lý do suy luận, giới hạn, người quyết định và hành động tiếp theo.

Không dùng ngôn ngữ che giấu bất định như “hệ thống chắc chắn phải”, “nghiệp vụ luôn yêu cầu”, hoặc “đã được phê duyệt” nếu artifact không có nguồn và approval reference. Thay bằng mức độ tin cậy có kiểm tra được: High khi nguồn canonical và người có thẩm quyền cùng xác nhận; Medium khi có nhiều bằng chứng nhất quán nhưng thiếu quyết định thẩm quyền; Low khi chỉ có ý kiến workshop, ví dụ đào tạo, hoặc giả định dự án. Low không đủ để khóa thiết kế, tạo kiểm soát pháp lý, kế toán, an toàn thực phẩm, bảo mật hay production rule.

Trường khuyến nghị	Giá trị ghi trong artifact
Recommendation ID	Giữ ID liên quan hiện có, ví dụ BR-INV-017; không tạo ID thay thế khi chưa đăng ký canonical.
Evidence	CANONICAL_BUSINESS_RULES, trạng thái IN_REVIEW, version v0.9.0; dữ liệu Nova Foods là mô phỏng.
Reasoning	Khóa cấp phát tự động giảm nguy cơ dùng lô chưa đủ điều kiện; ngoại lệ chưa có điều kiện được xác minh.
Confidence	Medium
Boundary	Không diễn giải đây là yêu cầu pháp lý, quy định kế toán, hoặc cấu hình ERP production.
Required authority	Quality Owner quyết định điều kiện chất lượng; Business Owner quyết định chấp nhận rủi ro vận hành; Architect đánh giá cách thực thi nếu có thay đổi hệ thống.
Record location	/02-handbook/08-business-rules-state-and-decision-analysis.md, liên kết nguồn canonical bằng đúng ID.
Next state	OPEN — Verification required cho đến khi có bằng chứng và decision record hợp lệ.

Senior BA ghi cả hậu quả nếu khuyến nghị sai: nếu khóa quá chặt, kiểm nghiệm hợp lệ có thể bị chậm; nếu mở ngoại lệ quá rộng, lô chưa đủ điều kiện có thể bị cấp phát nhầm. Đây không phải dự đoán chắc chắn; đây là rủi ro suy ra từ hai lựa chọn kiểm soát. Vì chưa có bằng chứng về ngoại lệ, khuyến nghị ưu tiên chặn tự động và đưa ngoại lệ cho đúng thẩm quyền quyết định.

12. Associated Template Reference & Completed Artifact

Core

Template là khuôn ghi nhận thông tin nhất quán; artifact là tệp đã được điền nội dung theo khuôn. Tại v0.9.0, Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. IN_REVIEW nghĩa là đang xem xét, không phải đã phê duyệt, baseline, compliant hay sẵn sàng production.

Chương này không tự tạo ID template. Bằng chứng: /01-curriculum/TEMPLATE_MANIFEST.md là nguồn quản trị template dự kiến; seed hiện có không xác minh ID hay tệp template riêng cho chương 08. Dùng đúng artifact canonical bên dưới để tránh biến bản ghi học liệu thành quy tắc ERP thực.

Applied

Tình huống: BA cần ghi quy tắc BR-INV-017 về cấp phát lô, trạng thái lô và ngoại lệ.

Facts: BR-INV-017 đã xuất hiện trong nội dung chương; CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY là nguồn canonical được nêu. Current Behavior: quy tắc và trạng thái còn IN_REVIEW. Underlying Need: người đọc cần biết nơi ghi rule, ID, dữ liệu và quyết định mà không nhân bản nguồn chân lý. Options: ghi trực tiếp trong chapter; hoặc liên kết artifact canonical. Decision Criteria: giữ ID nguyên dạng, một nguồn chân lý, không tạo approval ngầm định, đúng thẩm quyền. Decision: chapter tham chiếu artifact canonical; không dùng chapter thay catalog. Authority: Principal IT Business Analyst / Technical Curriculum Author giữ quản trị; Business Owner, Quality Owner, Architect quyết định phần thuộc thẩm quyền. Artifact: các tệp trong bảng Quick Reference. Consequence if Wrong: ID lệch làm đứt traceability; rule chưa xác minh có thể bị hiểu sai thành cấu hình ERP hoặc quyết định vận hành.

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

flowchart TB
    P["Principal IT Business Analyst /<br/>Technical Curriculum Author"] -->|quản trị chapter và tham chiếu artifact| C["Chapter 08<br/>phân tích rule, state, decision"]

    C -->|tham chiếu, không thay catalog| R["CANONICAL_BUSINESS_RULES<br/>nguồn rule canonical"]
    C -->|tham chiếu, giữ nguyên ID| I["TRACEABILITY_ID_REGISTRY<br/>nguồn ID canonical"]
    C -->|tham chiếu nghĩa dữ liệu| D["CANONICAL_DATA_DICTIONARY<br/>nguồn nghĩa dữ liệu"]
    T["TEMPLATE_MANIFEST<br/>nguồn tra template dự kiến"] -->|tham chiếu dự kiến| C

    R --> BR["BR-INV-017<br/>trạng thái rule: IN_REVIEW"]
    I --> ID["ID: BR-INV-017"]
    ID --> BR

    BR --> AL["Phạm vi rule<br/>cấp phát lô"]
    BR --> ST["Đối tượng phân tích<br/>trạng thái lô"]
    BR --> EX["Phạm vi exception<br/>ngoại lệ"]
    D -->|định nghĩa dữ liệu liên quan| AL
    D -->|định nghĩa dữ liệu liên quan| ST
    D -->|định nghĩa dữ liệu liên quan| EX

    BO["Business Owner"] --> AUTH["Quyết định phần<br/>thuộc thẩm quyền"]
    QO["Quality Owner"] --> AUTH
    AR["Architect"] --> AUTH
    AUTH --> BOUND["Chapter chỉ tham chiếu<br/>không ghi thay quyết định"]

    BR --> IR["Giữ IN_REVIEW<br/>không ngụ ý approved"]
    IR --> OK["Chỉ dùng để tiếp tục phân tích<br/>không coi là quyết định vận hành"]
    IR -.->|Nếu rule chưa xác minh vẫn bị coi là quyết định| G["Bị hiểu thành cấu hình ERP<br/>hoặc quyết định vận hành"]

    C -.->|Nếu dùng chapter thay catalog| CP["Sao chép rule"]
    CP --> SS["Nhiều nguồn chân lý"]

    C -.->|Nếu không giữ nguyên ID| CH["Đổi ID"]
    CH --> XI["ID lệch"]
    XI --> XT["Đứt traceability"]

Senior Lens

Không dùng template để hợp thức hóa nội dung thiếu bằng chứng. Template chỉ kiểm soát cách ghi; không thay Business Owner xác nhận quy tắc, Quality Owner xác nhận điều kiện chất lượng, Architect xác nhận cách thực thi, hoặc Legal/Accounting Owner diễn giải nghĩa vụ pháp lý và kế toán.

Khi catalog rule, registry ID và data dictionary mâu thuẫn, dừng liên kết mới. Lý do: cùng một ID có nghĩa khác nhau sẽ làm rule, test và traceability không còn kiểm tra được. Giữ trạng thái IN_REVIEW, ghi rõ Verification required, rồi chuyển vấn đề cho owner đúng chuyên môn.

Quick Reference

Template ID / Artifact ID	Tệp canonical	Dùng khi	Không dùng khi	Owner	Consumers	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Tra ID, tên tệp, phạm vi và trạng thái template dự kiến trước khi chọn khuôn ghi nhận.	Không dùng như completed artifact, approval record, rule catalog hoặc nguồn quyết định Nova Foods.	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author, QA reviewer	ID và filename phải khớp manifest; trạng thái phải giữ IN_REVIEW, version v0.9.0.
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Tra rule ID, diễn đạt rule, boundary và thẩm quyền liên quan state/decision.	Không dùng để suy ra cấu hình ERP production, nghĩa vụ pháp lý, quyết định kế toán hoặc approval.	Principal IT Business Analyst / Technical Curriculum Author; nội dung cần owner chuyên môn xác minh	BA, Business Owner, Quality Owner, QA	Rule ID giữ nguyên; không biến project assumption thành mandatory rule; có authority và evidence boundary.
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra định danh rule, requirement, decision, data và liên kết cross-file.	Không dùng để tạo ID mới ngoài registry hoặc đổi ID đã có bằng tên dịch.	Principal IT Business Analyst / Technical Curriculum Author	BA, QA reviewer, curriculum author	ID đúng chuỗi canonical; một ID không gán hai nghĩa; liên kết không đứt.
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tra nghĩa logic của trạng thái, thuộc tính lô, mã định danh và dữ liệu liên quan rule.	Không dùng như physical schema, interface contract hoặc xác nhận dữ liệu production.	Principal IT Business Analyst / Technical Curriculum Author; Architect/Data Owner xác minh phần kỹ thuật	BA, Architect, QA, data analyst	Tên dữ liệu và nghĩa không mâu thuẫn rule; phân biệt logical data với triển khai kỹ thuật.
Không có ID template riêng được xác minh trong seed hiện hành	Không có filename template riêng được xác minh trong seed hiện hành	Chỉ dùng TEMPLATE_MANIFEST để tra trước khi một template riêng được đăng ký canonical.	Không tự đặt dạng như BR-TMPL-001, không tự tạo đường dẫn /03-templates/..., không gọi bản nháp là completed artifact.	Principal IT Business Analyst / Technical Curriculum Author	Handbook author, template author	Không có ID/file chưa đăng ký xuất hiện trong chapter; mọi phát hiện thiếu đăng ký giữ Verification required.

Core

Chapter lookup checklist là danh sách kiểm tra để người đọc tìm đúng nguồn kiểm soát trước khi dùng ví dụ quy tắc, trạng thái, quyết định, dữ liệu hoặc template. Mục tiêu: tránh biến nội dung học liệu thành quy định ERP thật. Nova Foods Trading & Manufacturing là case mô phỏng, chỉ dùng dữ liệu tổng hợp, trạng thái corpus 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.

Kiểm tra	Vị trí canonical	Dùng để xác nhận	Không suy ra được
Cấu trúc chapter	/01-curriculum/CHAPTER_MANIFEST.md	Chapter này tồn tại trong handbook, filename và dependency được kiểm soát	Baseline, approval, rule vận hành
Cấu trúc curriculum	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Vị trí Business Rules State And Decision Analysis trong chuỗi học	Yêu cầu ERP production
Template dự kiến	/01-curriculum/TEMPLATE_MANIFEST.md	Template nào được quy hoạch cho corpus	Template đã hoàn tất hoặc đã được chấp thuận
ID truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID canonical, loại ID, ranh giới dùng ID	Tạo ID mới ngoài registry
Catalog quy tắc	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nguồn canonical cho business rule khi catalog có nội dung được kiểm soát	Rule Nova Foods đã đúng cho vận hành thật
Từ điển dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Thuật ngữ dữ liệu logic, tên trường, ý nghĩa dữ liệu khi được đăng ký	Schema vật lý hoặc cấu hình ERP
Nguồn nghiên cứu	/00-research/00_SOURCE_MAP.md	Nguồn chuẩn, pháp lý, safe-use boundary	Diễn giải pháp lý, kế toán, thuế không có thẩm quyền
Nội dung chapter hiện tại	/02-handbook/08-business-rules-state-and-decision-analysis.md	Giải thích học liệu, ví dụ Nova Foods mô phỏng, liên kết artifact	Quyết định nghiệp vụ thật

Applied

Thành phần	Nội dung
Facts	Người học cần tìm artifact đã điền cho ví dụ trạng thái và quyết định Nova Foods. TEMPLATE_MANIFEST chỉ được mô tả là planned template manifest.
Current Behavior	Corpus cung cấp các vị trí canonical cho manifest, registry, catalog rule, data dictionary và chapter. Không có nguồn được cung cấp đăng ký filename hoặc đường dẫn của completed Nova Foods artifact cho chapter này.
Underlying Need	Phân biệt rõ artifact được quy hoạch với artifact đã điền. Nếu không phân biệt, người học có thể dùng kế hoạch làm bằng chứng nội dung.
Options	1. Tự đoán đường dẫn artifact đã điền. 2. Ghi nhận không có vị trí được đăng ký trong nguồn hiện có.
Decision Criteria	Chỉ dùng filename, ID, trạng thái và vị trí có bằng chứng từ artifact canonical. Không tạo filename mới. Không gọi IN_REVIEW là hoàn tất, baseline hoặc approval.
Decision	Chọn phương án 2. Vị trí filled Nova Foods artifact: chưa được đăng ký trong nguồn canonical được cung cấp cho micro-batch này.
Authority	Không xác định hoặc thay đổi vị trí artifact. Việc này thuộc kiểm soát corpus qua artifact canonical, không thuộc ví dụ học liệu.
Artifact	/02-handbook/08-business-rules-state-and-decision-analysis.md, đối chiếu với /01-curriculum/TEMPLATE_MANIFEST.md và /01-curriculum/CHAPTER_MANIFEST.md.
Consequence if Wrong	Đường dẫn bịa đặt làm đứt traceability, khiến người đọc không tìm được bằng chứng, và có thể hiểu sai artifact dự kiến thành artifact đã hoàn thành.

Senior Lens

Cầu nối suy luận: TEMPLATE_MANIFEST tự xác định là Planned Template Manifest; metadata nói IN_REVIEW; nguồn cung cấp không nêu artifact ID, filename hoặc đường dẫn cho completed Nova Foods artifact của chapter 08. Vì ba bằng chứng này thiếu, kết luận đúng là “chưa được đăng ký”, không phải “không tồn tại” và không phải tự tạo vị trí giả.

Checklist hoàn tất khi mọi liên kết dùng đúng chuỗi ID và đúng path canonical. Không thay /01-curriculum/CANONICAL_BUSINESS_RULES.md bằng bản trích, không thay /01-curriculum/CANONICAL_DATA_DICTIONARY.md bằng bảng trong chapter, không dùng nội dung mô phỏng làm bằng chứng pháp lý, kế toán, thuế, an toàn thực phẩm, privacy hoặc production.

Quick Reference

Mục tra cứu	Giá trị
Handbook chapter	/02-handbook/08-business-rules-state-and-decision-analysis.md
Chapter manifest	/01-curriculum/CHAPTER_MANIFEST.md
Template manifest	/01-curriculum/TEMPLATE_MANIFEST.md
Rule catalog	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Data dictionary	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
Traceability registry	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
Source map	/00-research/00_SOURCE_MAP.md
Filled Nova Foods artifact location	Chưa được đăng ký trong nguồn canonical được cung cấp
Cấm dùng	Filename tự tạo, ID tự tạo, bản sao không kiểm soát, suy diễn approval từ IN_REVIEW

Senior Lens

Rà soát liên tệp trước handoff nhằm chứng minh chapter không tự tạo rule, ID, nguồn hay thẩm quyền. Bằng chứng phải truy ngược về artifact canonical; suy luận chỉ hợp lệ khi ID, đường dẫn, trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và dữ liệu Nova Foods mô phỏng khớp nhau.

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

flowchart TB
    A[Chapter 08 section 12] --> B[Đối chiếu canonical ID, filename, artifact location, trạng thái và authority]
    B --> C{Filename, ID, location, trạng thái và authority<br/>đã đăng ký trong nguồn kiểm soát?}

    C -- Chưa --> D[Không gọi artifact canonical hoặc completed;<br/>giữ IN_REVIEW và ghi open issue]
    D --> E[Escalation Principal IT Business Analyst /<br/>Technical Curriculum Author]
    E --> F[Sửa traceability package;<br/>không kết luận chuyên môn]
    F --> G{Có bằng chứng đăng ký hợp lệ?}
    G -- Chưa --> E
    G -- Có --> H[Đối chiếu source boundary, IN_REVIEW,<br/>v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh<br/>và dữ liệu Nova Foods]

    C -- Có --> H
    H --> I[Đối chiếu template, rule, data dictionary<br/>và nhãn Verification required]
    I --> J{Có lệch ID, filename, metadata<br/>hoặc source boundary?}

    J -- Có --> K[Ghi open issue; giữ IN_REVIEW]
    K --> E
    J -- Không --> L{Có nội dung cần owner<br/>chuyên môn xác minh?}

    L -- Có --> M[Ghi open issue và<br/>gắn nhãn Verification required]
    M --> N[Phân loại đa lựa chọn;<br/>chuyển tới toàn bộ owner liên quan]

    N -- Ý nghĩa rule hoặc state --> O[Business Owner]
    N -- Điều kiện chất lượng BR-INV-017 --> P[Quality Owner]
    N -- Thuật ngữ dữ liệu hoặc quan hệ --> Q[Data Owner]
    N -- API, tích hợp hoặc khả thi thực thi --> R[Technical Architect]
    N -- Quyền hoặc dữ liệu nhạy cảm --> S[Security Owner]
    N -- Decision criteria và test basis --> T[QA Lead]
    N -- Pháp lý, kế toán, compliance,<br/>an toàn thực phẩm hoặc truy xuất --> U[Legal / Accounting / Compliance /<br/>Food Safety Domain Owner]

    O --> V[Principal IT Business Analyst /<br/>Technical Curriculum Author lập gói truy vết]
    P --> V
    Q --> V
    R --> V
    S --> V
    T --> V
    U --> V

    V --> W{Tất cả xác minh cần thiết<br/>có evidence hợp lệ?}
    W -- Chưa --> X[Giữ open issue và<br/>Verification required]
    W -- Có --> Y{Có approval reference hợp lệ<br/>trong nguồn kiểm soát?}
    X --> Y

    L -- Không --> Y
    Y -- Chưa --> Z[Ghi open issue approval;<br/>giữ IN_REVIEW]
    Y -- Có --> AA{Có baseline reference hợp lệ<br/>trong nguồn kiểm soát?}
    Z --> AA

    AA -- Chưa --> AB[Ghi open issue baseline;<br/>giữ IN_REVIEW]
    AA -- Có --> AC{Kiểm tra trước handoff:<br/>có sai ID, source boundary, trạng thái<br/>hoặc suy diễn approval/baseline?}
    AB --> AC

    AC -- Có --> AD[Nguy cơ: dùng ID sai, tìm artifact không tồn tại<br/>hoặc coi IN_REVIEW là approval, baseline,<br/>compliance hay production-ready]
    AD --> K
    AC -- Không --> AE[Handoff chapter, bảng issue<br/>và bằng chứng để review]
    AE --> AF[Giữ IN_REVIEW;<br/>không gọi approved, baselined, compliant<br/>hay production-ready]

Kiểm tra liên tệp	Bằng chứng phải đối chiếu	Kết quả cần ghi trước handoff	Escalation owner khi lệch
Danh tính chapter	/01-curriculum/CHAPTER_MANIFEST.md	Chapter 08 giữ đúng tên tệp /02-handbook/08-business-rules-state-and-decision-analysis.md; không đổi ID, slug hay 12 H2 blueprint	Principal IT Business Analyst / Technical Curriculum Author
Template và artifact liên quan	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ tham chiếu template đã đăng ký; không suy diễn tệp chưa có thành artifact hoàn tất	Principal IT Business Analyst / Technical Curriculum Author
ID rule, state, decision, requirement	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Mọi ID dùng đúng canonical; không tạo biến thể dịch thuật hoặc ID cục bộ	Principal IT Business Analyst / Technical Curriculum Author
Nguồn rule nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nội dung giải thích rule không được trình bày là quy định vận hành Nova Foods thực	Business Owner cho ý nghĩa nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author giữ traceability
Thuật ngữ dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên dữ liệu, trạng thái và quan hệ không mâu thuẫn dictionary canonical	Data Owner; Technical Architect nếu ảnh hưởng mô hình tích hợp
Ranh giới nguồn	/00-research/00_SOURCE_MAP.md	Nguồn pháp lý, chuẩn, good practice giữ đúng safe use boundary; không gán số điều khoản chưa kiểm chứng	Legal Owner, Accounting Owner, Compliance Owner hoặc Food Safety Domain Owner, tùy nội dung
Metadata quản trị	CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY	Không gọi IN_REVIEW là approved, baselined, compliant hay production-ready	Principal IT Business Analyst / Technical Curriculum Author

Open issues trước handoff

ID	Vấn đề mở	Bằng chứng và lý do	Owner escalation	Điều kiện đóng
OI-08-12-01	Chưa có baseline reference	Các artifact upstream đều ghi IN_REVIEW, v0.9.0, chưa có baseline reference. Vì vậy chapter không thể tuyên bố baseline.	Principal IT Business Analyst / Technical Curriculum Author	Có baseline reference được ghi minh bạch trong artifact kiểm soát
OI-08-12-02	Chưa có approval reference	Metadata upstream nêu rõ không có approval ngầm định từ Owner hoặc review. Vì vậy handoff chỉ là chuyển để review.	Principal IT Business Analyst / Technical Curriculum Author	Approval reference được ghi bởi vai trò có thẩm quyền
OI-08-12-03	Hiệu lực pháp lý của rule có thể bị suy diễn	Seed chỉ cho phép dùng luật, nghị định làm bối cảnh; diễn giải yêu cầu hệ thống cần xác minh chuyên môn.	Legal Owner; Accounting Owner nếu liên quan chứng từ hoặc hạch toán; Food Safety Domain Owner nếu liên quan truy xuất hoặc thu hồi	Kết luận xác minh gắn nguồn chính thức và phạm vi áp dụng
OI-08-12-04	Mức triển khai ERP chưa được xác nhận	Nova Foods là case mô phỏng, dữ liệu tổng hợp; không có bằng chứng cho cấu hình ERP, workflow hay quyền production.	Business Owner; Technical Architect; Security Owner khi có quyền hoặc dữ liệu nhạy cảm	Quyết định được ghi như giả định học liệu hoặc được xác nhận bởi owner phù hợp

Verification required trước handoff

Hạng mục	Kiểm tra bắt buộc	Owner
Tính nhất quán state	Mỗi trạng thái, điều kiện chuyển và hậu quả phải khớp rule canonical hoặc mang nhãn project assumption	Business Owner
Tính khả thi kỹ thuật	Rule có ảnh hưởng API, tích hợp, dữ liệu hoặc phân quyền phải được đánh giá riêng; không suy ra từ sơ đồ học liệu	Technical Architect; Security Owner
Khả năng kiểm thử	Decision criteria phải quan sát được để QA tạo test basis; dùng thuật ngữ kiểm thử nhất quán với ISTQB CTFL	QA Lead
Pháp lý và tuân thủ	Rule liên quan dữ liệu cá nhân, hóa đơn, kế toán, an toàn thực phẩm hoặc truy xuất phải giữ nhãn Verification required cho tới khi owner xác minh	Legal Owner; Accounting Owner; Compliance Owner; Food Safety Domain Owner
Nguồn và trích dẫn	URL, issuer, version và safe use boundary phải khớp /00-research/00_SOURCE_MAP.md; không bịa clause, quotation hay nghĩa vụ	Principal IT Business Analyst / Technical Curriculum Author

Completed artifact cho ví dụ này được ghi nhận với nội dung đầy đủ dưới đây, nhưng không được gán ID, filename hoặc đường dẫn canonical chưa được xác minh:

Trường	Nội dung
Artifact purpose	Ghi nhận cách BA liên kết business rule, state, decision, dữ liệu và bằng chứng trong case mô phỏng Nova Foods.
Artifact status	IN_REVIEW
Corpus version	v0.9.0
Case	Nova Foods Trading & Manufacturing
Rule reference	BR-INV-017
Rule subject	Cấp phát lô, trạng thái lô và ngoại lệ
Rule authority	Business Owner xác nhận ý nghĩa nghiệp vụ; Quality Owner xác nhận điều kiện chất lượng; Technical Architect xác nhận khả năng thực thi; Legal/Accounting Owner xác nhận phần thuộc pháp lý hoặc kế toán khi phát sinh.
Data authority	/01-curriculum/CANONICAL_DATA_DICTIONARY.md là nguồn tra nghĩa logic của dữ liệu.
ID authority	/01-curriculum/TRACEABILITY_ID_REGISTRY.md là nguồn kiểm tra ID canonical.
Rule authority source	/01-curriculum/CANONICAL_BUSINESS_RULES.md là nguồn rule canonical khi nội dung được kiểm soát.
Template authority source	/01-curriculum/TEMPLATE_MANIFEST.md là nguồn tra template dự kiến.
Completed artifact location	Chưa được đăng ký trong nguồn canonical được cung cấp.
Evidence boundary	Nội dung là học liệu mô phỏng, dùng dữ liệu tổng hợp; không chứng minh cấu hình ERP, workflow, quyền production, nghĩa vụ pháp lý, quyết định kế toán hoặc approval.
Review action	Đối chiếu ID, filename, trạng thái, source boundary và owner trước handoff.
Consequence if wrong	Người dùng có thể coi bản ghi học liệu là catalog vận hành, dùng ID sai, tìm artifact không tồn tại hoặc suy diễn approval từ IN_REVIEW.

Artifact này chưa phải completed artifact canonical. Người biên tập chỉ được gọi artifact là completed khi filename, ID, vị trí, nội dung, trạng thái và authority đã được đăng ký trong nguồn kiểm soát tương ứng. Cho tới khi đó, ghi rõ “chưa được đăng ký”, giữ IN_REVIEW, tạo Verification required và chuyển vấn đề cho Principal IT Business Analyst / Technical Curriculum Author.

Handoff chỉ chuyển chapter cùng bảng issue và bằng chứng đối chiếu. Nếu một rule đồng thời chạm nghiệp vụ, pháp lý, kế toán, bảo mật hoặc kiến trúc, phải escalation cho toàn bộ owner liên quan; Principal IT Business Analyst / Technical Curriculum Author lập gói truy vết, không thay kết luận chuyên môn.

Quyết định duyệt phiếu yêu cầu xuất kho

Sơ đồ trả lời: phiếu yêu cầu xuất kho ở DRAFT có được chuyển sang APPROVED không khi người duyệt yêu cầu duyệt? Quyết định so sánh số lượng yêu cầu với tồn khả dụng và giữ phiếu ở DRAFT khi không đủ tồn.

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

@startuml
[*] --> DRAFT

state "DRAFT\nPhiếu yêu cầu xuất kho" as DRAFT
state "APPROVED\nPhiếu đã được duyệt" as APPROVED
state "Đánh giá tồn khả dụng" as DECIDE <<choice>>

DRAFT --> DECIDE : Người duyệt yêu cầu\nchuyển sang APPROVED
DECIDE --> APPROVED : [Số lượng yêu cầu <= tồn khả dụng]
DECIDE --> DRAFT : [Số lượng yêu cầu > tồn khả dụng]\nKết quả: Không đủ tồn khả dụng

APPROVED --> [*]
@enduml

DRAFT và APPROVED là state hợp lệ của phiếu. Bước Đánh giá tồn khả dụng là choice pseudostate, tức điểm quyết định, không phải state của phiếu.

Người duyệt kích hoạt action chuyển phiếu từ DRAFT sang APPROVED. Hệ thống chỉ chuyển khi số lượng yêu cầu không vượt tồn khả dụng; nếu vượt, phiếu giữ DRAFT và trả outcome “Không đủ tồn khả dụng”.

Sơ đồ không mô tả tạo lệnh xuất kho, thuật toán tính tồn, quyền chi tiết hay xử lý ngoại lệ. Các nội dung này nằm ngoài phạm vi ví dụ học liệu.