Error: Codex review requested revision: Nhánh lỗi bị thiếu. ValidateRequest chỉ nối sang CreateRequest khi dữ liệu hợp lệ; sơ đồ không chỉ ra đường từ yêu cầu không hợp lệ đến phản hồi lỗi, dù prose và source đều yêu cầu outcome gồm thành công hoặc lỗi.; Ký hiệu actor gây mơ hồ. Sơ đồ dùng UML actor cho Người dùng nghiệp vụ, nhưng note lại ghi Actor: Nova Foods ERP; source xác định ERP là actor của tương tác API. Cần phân biệt tác nhân nghiệp vụ xác nhận đơn với actor khởi tạo API.; Quan hệ ERP - CreateDelivery, CreateDelivery - Hub, ReturnOutcome - DeliveryResponse và DeliveryResponse - ERP không có hướng rõ ràng. Request, response và trách nhiệm bên gửi/bên nhận vì vậy khó đọc.; Luồng User --> ConfirmOrder biến việc xác nhận đơn thành thao tác trực tiếp của người dùng. Source chỉ xác định trigger là trạng thái Confirmed, không xác định ai hoặc cơ chế nào chuyển trạng thái. Nên bắt đầu từ sự kiện Đơn chuyển sang Confirmed hoặc đánh dấu actor xác nhận là chưa xác định.; Câu Hub quyết định nhận hoặc từ chối dễ bị hiểu là thẩm quyền quyết định nghiệp vụ. Source chỉ hỗ trợ việc Hub kiểm tra request và trả kết quả kỹ thuật; quy tắc hợp lệ và owner phê duyệt chưa được đặc tả.; Sơ đồ chưa thể hiện ranh giới quan trọng giữa 201 Created và việc ERP lưu kết quả thất bại. Nó chỉ có nhánh ERP --> SaveResult, không có outcome quan sát được khi ERP không lưu được deliveryId hoặc trạng thái.
Error: Codex review requested revision: BPMN XML outruns boundary stating chapter does not establish “sơ đồ BPMN chuẩn”. Disclaimer covers simulation and operations, but does not say diagram is illustrative BPMN rather than canonical BPMN specification.; Diagram omits status transitions DRAFT → PENDING_APPROVAL and REJECTED → DRAFT. Tasks “Gửi yêu cầu duyệt” and “Sửa yêu cầu” show actions, not resulting statuses required by source.; Approval evidence remains incomplete. “Ghi APPROVED” and “Ghi REJECTED” do not show recording approver and decision time, though source identifies these as verifiable audit evidence.; Gateway branches use decision labels but state no decision criteria. Source requires approval according to defined criteria and warns that approval without conditions, authority, and trace is weak control.
assets/diagrams/00-foundations-001-b93139a4.mmd — REVISE — Sơ đồ bỏ sót hàng thành phẩm, trong khi phần ranh giới xác định object gồm hàng thành phẩm và phiếu nhận hàng mô phỏng. Cần thể hiện đầy đủ object bị tác động.; Nhãn “kết quả cần đạt” mơ hồ và không mô tả quan hệ nghiệp vụ cụ thể. Cần dùng nhãn cụ thể, nhất quán với việc ghi nhận làm tồn kho phản ánh hàng đã nhận.; Sơ đồ gần như lặp nguyên chuỗi actor–action–object–outcome đã được giải thích ngay bên dưới, nên chưa tạo thêm giá trị trực quan. Cần làm rõ quan hệ giữa hàng nhận, phiếu ghi nhận và trạng thái tồn kho mà không thêm chi tiết thiết kế.
assets/diagrams/00-foundations-002-19a4b2c8.mmd — REVISE — Nút “Làm lại và tranh chấp trách nhiệm” thêm hậu quả “tranh chấp trách nhiệm” không được phần văn xuôi nêu. Bỏ hậu quả này hoặc thay bằng hậu quả được hỗ trợ như sửa yêu cầu, thiết kế, test basis, dữ liệu, phân quyền, tích hợp và tài liệu.; Sơ đồ chỉ thể hiện ambiguity và rework, nhưng bỏ rủi ro governance failure quan trọng. Bổ sung nhánh thể hiện việc trộn nhu cầu với cách triển khai có thể làm ví dụ bị hiểu nhầm thành yêu cầu, quyết định kiến trúc hoặc quy định vận hành.; Nhãn “Phân tích và quyết định có kiểm soát” mơ hồ về cơ chế và thẩm quyền. Làm rõ rằng artifact và owner phù hợp xử lý cách xây và người quyết định; Concept chỉ giữ câu hỏi ở mức outcome và phát hiện điểm chưa biết.; Nhánh “Có” ngụ ý đủ bốn thành phần tự động tạo quyết định có kiểm soát. Phần văn xuôi chỉ hỗ trợ kết luận rằng phạm vi nhu cầu rõ hơn; governance còn phụ thuộc artifact và owner phù hợp. Thể hiện dependency này hoặc giới hạn outcome của nhánh.
assets/diagrams/00-foundations-003-b19ab985.mmd — REVISE — Nút “Sales xác nhận SO-NF-2026-0087” đặt sai hoặc làm mơ hồ điểm kiểm tra. Phần prose xác định ERP kiểm tra lúc xác nhận giao hàng, không phải lúc Sales xác nhận đơn. Cần ghi đúng sự kiện xác nhận giao hàng và đúng actor thực hiện nếu đã được xác minh.; Gateway “Tổng phơi nhiễm vượt hạn mức?” đưa vào thuật ngữ và công thức chưa được section xác lập. Prose chỉ nêu đối chiếu số dư công nợ với hạn mức và còn yêu cầu xác minh công thức số dư. Cần dùng điều kiện candidate được hỗ trợ hoặc thể hiện rõ điều kiện chưa được xác minh.; Nút “Finance xử lý theo quyền được xác minh” mâu thuẫn với phần rủi ro còn lại, nơi quyền bỏ chặn vẫn cần xác minh. Cần thể hiện quyền xử lý ngoại lệ là điểm chưa quyết định, không phải quyền đã được xác minh.; Nhánh Credit Hold kết thúc bằng hành vi “xử lý” mơ hồ, không cho biết kết quả ngoại lệ như giữ chặn hay bỏ chặn. Cần thể hiện ranh giới chưa quyết định hoặc các outcome chỉ khi section đã hỗ trợ.; Luồng D → E → F ngụ ý Finance chỉ xử lý sau khi Kho thử hoặc không thể tạo phiếu xuất. Section không xác lập thứ tự này. Cần tránh biểu diễn quan hệ tuần tự chưa được hỗ trợ.
assets/diagrams/00-foundations-004-ff916e62.mmd — REVISE — Nhánh “Có nguồn kiểm tra được?” dẫn thẳng đến “Fact đã xác minh”, nhưng nguồn kiểm tra được không đồng nghĩa nội dung đã được xác minh. Stakeholder input, artifact IN_REVIEW và văn bản pháp luật đều có thể có nguồn nhưng chưa đủ authority hoặc bằng chứng cho claim. Cần tách khả năng truy nguồn khỏi trạng thái xác minh.; Các nhánh từ “Stakeholder input”, “Project assumption” và “Verification-required claim” hội tụ rồi chuyển thành “Decision”, gây hiểu rằng nhãn phân loại tự biến thành quyết định khi có authority. Prose yêu cầu giữ nguyên phân loại, còn decision là hành động quản trị riêng dựa trên options, criteria và authority. Cần biểu diễn decision như kết quả xử lý claim, không thay thế nhãn nguồn.; Gateway “Có authority và tiêu chí đã ghi?” dùng “authority” mơ hồ và gộp nhiều điều kiện. Section phân biệt Business Owner, domain owner, Legal Owner và Architect theo loại claim. Cần thể hiện tuyến xác minh hoặc owner phù hợp, nhất là claim pháp lý, nghiệp vụ và khả năng hệ thống.; Nhánh “Chưa có” chỉ nói “Giữ nhãn và lập đường xác minh” nhưng không thể hiện boundary quan trọng: không nâng claim thành canonical rule, không gọi artifact IN_REVIEW là approved hoặc baselined. Cần nêu rõ trạng thái bị chặn hoặc điều kiện chưa được phép.; Sơ đồ bỏ qua kết quả xác minh không ủng hộ claim. Claim có thể được xác nhận, thu hẹp phạm vi hoặc bác bỏ; hiện sơ đồ chỉ dẫn đến Decision hoặc tiếp tục xác minh. Cần thêm outcome xử lý claim sai hoặc chỉ đúng có điều kiện.
assets/diagrams/00-foundations-005-4f4aa277.mmd — REVISE — Discovery exit omits measurable goals and verification gaps; add both to match stated gate.; Analysis entry omits requirement that critical questions remain explicit rather than hidden by assumptions; add condition.; Analysis exit omits data, exceptions, and labeled unverified points; add them.; Delivery entry omits prohibition against inferred legal, accounting, or security rules; add condition.; Delivery exit omits deployment in an appropriate environment; add outcome.; Testing entry omits test environment; add it.; Testing exit omits regression evidence scoped to tested change; add it.; Release entry omits recorded residual risks; add condition.; Release exit omits operations guidance and authorized, recorded release decision; add both.; Operations entry says only "monitoring ready" but prose requires completed release plus monitoring and support readiness; correct label.; Operations outcome omits operational data and weakens explicit lifecycle rule that new change returns to Discovery when a new need appears; show both.
assets/diagrams/00-foundations-006-87665778.mmd — REVISE — Luồng QA Owner → Business Owner không được bảng hoặc prose xác lập như một handoff trực tiếp. Cần loại bỏ luồng này hoặc bổ sung căn cứ rõ về owner hạ nguồn, nội dung bàn giao và giới hạn thẩm quyền.; Luồng BA → Architect chỉ thể hiện câu hỏi mở, nhưng bỏ kết quả thuộc thẩm quyền của Architect: kết luận khả thi kiến trúc. Cần thể hiện việc Architect trả kết luận cho BA hoặc owner tiếp theo.; Luồng BA → Delivery Team ghi “Rule, acceptance criteria” nhưng bỏ traceability, quyết định đã ghi nhận và giả định, làm mất ngữ cảnh tối thiểu được prose yêu cầu. Cần sửa nhãn để phản ánh đủ nội dung handoff.; Nhánh escalation chỉ nêu pháp lý, kế toán và bảo mật, trong khi bảng còn yêu cầu Compliance hoặc domain owner. Cần dùng nhãn bao quát đầy đủ phạm vi specialist owner.; Sơ đồ không thể hiện ranh giới quan trọng rằng Delivery Team không tự đổi business rule và BA không tự kết luận kiến trúc, chất lượng hoặc vấn đề chuyên môn. Cần thể hiện các giới hạn này hoặc tránh để chuỗi mũi tên hàm ý chuyển toàn bộ thẩm quyền.
assets/diagrams/00-foundations-007-93ad810f.mmd — REVISE — D --> A và D -. phát hiện nhu cầu mới .-> A trùng cùng hướng nhưng không phân biệt điều kiện hoặc ý nghĩa; bỏ cạnh phản hồi trùng hoặc đổi điểm xuất phát theo đúng luồng phản hồi được mô tả.; O --> D và O -. sự cố hoặc thay đổi nhu cầu .-> D trùng cùng hướng, khiến quan hệ giữa vòng đời chính và phản hồi vận hành mơ hồ; giữ một cạnh có nhãn thể hiện điều kiện quay lại.; Nhãn Kiểm thử theo test basis đưa thuật ngữ không được giải thích trong đoạn văn; dùng khái niệm đã được phần này hỗ trợ hoặc bổ sung định nghĩa trong prose.; Cạnh D -. phát hiện nhu cầu mới .-> A không phải mũi tên quay lại như prose tuyên bố và không thể hiện vòng phản hồi; sửa hướng, nguồn hoặc mô tả prose để hai phần nhất quán.
assets/diagrams/00-foundations-008-be50c44a.mmd — REVISE — Luồng “Kiến thức nền” → “Câu hỏi BA” và “Bằng chứng” → “Câu hỏi BA” biến input thành câu hỏi, nhưng phần prose chỉ nói input phục vụ phân tích; cần thể hiện quan hệ được nêu, không thêm bước suy diễn.; Luồng “Artifact nguồn” → “Bằng chứng” ngụ ý mọi artifact nguồn tự trở thành bằng chứng, trái với phân biệt trong prose; cần thể hiện artifact nguồn là nguồn được nhận diện để đọc, tham chiếu và truy vết.; “Canonical ID” không nối với “Artifact nguồn”, nên không thể hiện ID định danh nguồn nào; cần gắn Canonical ID với artifact nguồn.; Luồng đến “Nội dung phân tích” đi qua “Câu hỏi BA” và “Liên kết truy vết”, nhưng không cho thấy bằng chứng hoặc artifact nguồn hỗ trợ nội dung nào như mục đích được tuyên bố; cần thể hiện quan hệ hỗ trợ và truy vết nguồn–nội dung.; Nhãn “Liên kết truy vết” mơ hồ vì không nêu hai đầu liên kết; cần dùng nhãn hoặc cấu trúc cho biết nội dung phân tích truy về artifact nguồn bằng Canonical ID.
assets/diagrams/00-foundations-009-336b18ff.mmd — REVISE — Gateway "Có nguồn và owner?" gộp hai tiêu chí khác nhau và dùng "owner" mơ hồ: người chịu trách nhiệm hay người có thẩm quyền xác nhận. Tách hoặc ghi rõ từng tiêu chí.; Luồng thiếu trường hợp input chắc chắn đã hết hiệu lực hoặc sai phạm vi. Thêm nhánh "Không" với kết quả dừng; nhánh "Không rõ" giữ trạng thái cần xác minh.; Nút "Verification required" là trạng thái cụt, không thể hiện điều kiện quay lại phân tích hoặc chuyển sang dừng sau xác minh. Bổ sung bước xác minh bởi đúng thẩm quyền và hai kết quả đạt/không đạt.; Kết quả "Đủ điều kiện phân tích" được cấp khi chưa kiểm tra đủ năm câu hỏi trong prose: nguồn canonical, version/status/ngày truy cập, tính mới, đúng thẩm quyền và khả năng truy vết. Bổ sung các gateway còn thiếu hoặc đổi kết quả để không ngụ ý đã hoàn tất kiểm tra.; Sơ đồ bỏ qua mức tin cậy và điều kiện phải dừng, dù prose xác định đây là thuộc tính bắt buộc để input dùng được. Thêm kiểm tra tương ứng trước kết quả cho phép phân tích.; Nhánh "Mâu thuẫn nguồn canonical?" dẫn thẳng tới STOP nhưng prose không quy định mọi mâu thuẫn đều phải loại bỏ vĩnh viễn. Thể hiện dừng sử dụng làm căn cứ cho đến khi mâu thuẫn được xác minh hoặc phân xử.
assets/diagrams/00-foundations-010-a81777e8.mmd — REVISE — Gateway ID và đường dẫn canonical? gộp hai điều kiện và có thể loại sai nguồn pháp lý chỉ được truy qua URL trong 00_SOURCE_MAP. Tách điều kiện nhận diện/truy vết hoặc diễn đạt để bao phủ cả canonical ID, artifact path và official-source URL.; Nhánh Không dẫn thẳng đến STOP: không dùng làm căn cứ nhưng không phân biệt việc giữ dòng trong inventory với việc dùng làm căn cứ viết tiếp. Thể hiện rõ đầu vào vẫn được ghi nhận trong inventory nhưng chưa được dùng làm căn cứ.; Nhánh chưa xác minh kết thúc tại Chờ owner có thẩm quyền xác minh, thiếu kết quả sau xác minh. Bổ sung vòng quay lại gateway trạng thái hoặc hai kết quả: đủ điều kiện dùng làm bằng chứng và không được chấp nhận.; Nhãn Trạng thái xác minh đủ? mơ hồ vì section không định nghĩa đủ. Gắn điều kiện cụ thể với trạng thái phù hợp cho mục đích sử dụng và xác nhận của owner có thẩm quyền.; Sơ đồ không thể hiện ranh giới thẩm quyền quan trọng giữa quản trị artifact và xác minh nội dung. Phân biệt Principal IT Business Analyst / Technical Curriculum Author với Legal Owner, Accounting Owner, Food-safety Owner, Business Owner.
assets/diagrams/00-foundations-011-84b42333.mmd — REVISE — Nút Escalate owner có thẩm quyền mơ hồ và làm mất phân tuyến escalation trong bảng. Cần thể hiện owner theo nguyên nhân: Business Owner hoặc Warehouse Representative cho thiếu bằng chứng vận hành, Architect cho khả năng kỹ thuật, Food-safety Owner cho an toàn thực phẩm, Legal Owner cho dữ liệu cá nhân, Principal IT Business Analyst / Technical Curriculum Author cho mâu thuẫn nguồn hoặc traceability.; Gateway Đủ evidence và đúng authority? gộp hai điều kiện có tuyến xử lý khác nhau. Cần tách hoặc ghi rõ điều kiện và đích escalation tương ứng.; Nhánh Quality gate đạt? -- Không --> B đưa mọi lỗi về bước ghi nhận facts, trái với bảng: acceptance criterion không kiểm thử được trả về BA, rule không rõ chuyển Business Owner, còn lỗi có thể thuộc need, options, decision hoặc traceability. Cần định tuyến rework theo loại lỗi hoặc về bước phù hợp.; Sơ đồ bỏ điều kiện dừng handoff khi thiếu owner, nguồn hoặc trạng thái. Cần thể hiện Controlled handoff chỉ xảy ra khi evidence, owner và điểm mở đều hiển thị; nếu thiếu thì dừng và sửa traceability.; Sơ đồ không thể hiện trạng thái đầu ra handoff gồm IN_REVIEW và không phải production instruction. Cần giữ ranh giới này để tránh biến project assumption thành quy tắc vận hành đã phê duyệt.
assets/diagrams/00-foundations-012-bf4469e1.mmd — REVISE — Nút “Business Owner quyết định chính sách” hàm ý quyết định đã xảy ra, trái với trạng thái hiện tại “Chưa chọn phương án vận hành”. Cần thể hiện đây là bước chờ quyết định hoặc kết quả tương lai.; Luồng từ quyết định của Business Owner quay thẳng về “Giữ trạng thái IN_REVIEW” không nêu điều kiện chuyển trạng thái sau quyết định. Cần phân biệt quyết định nghiệp vụ với phê duyệt hoặc baseline để tránh hiểu sai IN_REVIEW.; Nút “Đủ điều kiện xem xét phân bổ” mơ hồ về actor, hành động và kết quả. Cần nêu rõ ai xem xét phân bổ và việc này không đồng nghĩa đơn được chấp nhận.; Nhánh xác minh thiếu phụ thuộc canonical được quy định trong bước 2. Cần gắn việc xác minh định nghĩa với CANONICAL_DATA_DICTIONARY hoặc nguồn canonical.; Nhãn “Escalate Data Owner và Architect” trộn tiếng Anh và tiếng Việt, đồng thời không dùng cấu trúc song song với nhãn khác. Cần đổi thành hành động tiếng Việt cụ thể và giữ đúng hai owner.
assets/diagrams/00-foundations-013-e18370af.mmd — REVISE — Gateway “Thuộc artifact canonical nào?” ngụ ý chỉ chọn một artifact, trong khi một evidence có thể ảnh hưởng nhiều artifact và nghĩa vụ lịch sử yêu cầu ghi các nguồn, field, rule hoặc liên kết bị tác động. Cần thể hiện khả năng cập nhật một hoặc nhiều artifact canonical.; Luồng không thể hiện ràng buộc “không tạo ID nghiệp vụ mới” và chỉ cập nhật artifact canonical đã tồn tại. Nhánh TRACEABILITY_ID_REGISTRY vì vậy có thể bị hiểu thành nơi tự tạo ID. Cần nêu rõ dùng ID canonical đã đăng ký, không tái dùng hoặc tự đặt ID.; Bước cập nhật artifact bị lược bỏ: các nhánh đi thẳng từ phân loại sang “Ghi change history”, nên không thể hiện hành động cập nhật có kiểm soát cùng nội dung tối thiểu. Cần thêm bước cập nhật artifact canonical trước khi ghi lịch sử.; Kết quả chỉ nêu “Giữ IN_REVIEW”, bỏ các thuộc tính bắt buộc phải giữ nguyên: Artifact ID, đường dẫn canonical, version, locale, múi giờ, bối cảnh Việt Nam và VND. Cần thể hiện kiểm tra bảo toàn metadata hoặc kết quả bao quát các ràng buộc này.; Diagram không chỉ rõ owner thực hiện hoặc kiểm soát cập nhật dù section quy định owner cho mọi artifact. Cần gắn Principal IT Business Analyst / Technical Curriculum Author với hành động cập nhật và ghi lịch sử.
assets/diagrams/00-foundations-014-8412ad49.mmd — REVISE — Các mũi tên khẳng định chuỗi phụ thuộc trực tiếp từ 00_SOURCE_MAP đến hai artifact canonical rồi đến TRACEABILITY_ID_REGISTRY, nhưng phần văn xuôi chỉ yêu cầu liên kết truy vết, không xác lập quy trình hoặc thứ tự này. Cần biểu diễn chúng như liên kết truy vết hoặc bổ sung căn cứ trong văn xuôi.; Nút Output sẵn sàng review mơ hồ về output nào và ngụ ý hoàn tất TRACEABILITY_ID_REGISTRY đủ để đạt IN_REVIEW. Cần nêu artifact đích cụ thể và các điều kiện bắt buộc: owner, version, ngày cập nhật, nội dung tối thiểu, traceability và change history.; Owner là thành phần bắt buộc nhưng bị bỏ khỏi luồng dẫn đến trạng thái review. Cần thể hiện vai trò chịu trách nhiệm cập nhật hoặc kiểm tra trạng thái nếu sơ đồ mô tả readiness.; Nhãn Dữ liệu logic không diễn đạt cụ thể chức năng của CANONICAL_DATA_DICTIONARY. Cần dùng nhãn phản ánh nội dung hoặc giá trị truy vết được mô tả trong bảng.
assets/diagrams/00-foundations-015-214fcda0.mmd — REVISE — Sơ đồ bỏ hai điều kiện gate bắt buộc: phạm vi rõ và lịch sử thay đổi có mặt. Bổ sung gateway cùng kết quả tương ứng: phạm vi thiếu thì trả về soạn lại; lịch sử thay đổi thiếu thì không chuyển review.; Gateway “Đúng thẩm quyền, không mâu thuẫn?” gộp hai điều kiện có hậu quả khác nhau. Tách gateway: sai thẩm quyền thì escalate và không tự kết luận; có mâu thuẫn thì dừng chuyển review.; Nhãn “Escalate hoặc chỉnh sửa” mơ hồ và làm yếu quy tắc thẩm quyền. Gắn từng nhánh với một kết quả cụ thể theo bảng.; “Metadata canonical đúng?” không thể hiện đủ định danh bắt buộc gồm Artifact ID, đường dẫn canonical, IN_REVIEW, v0.9.0 và ngày 2026-08-07. Dùng nhãn cụ thể hơn hoặc thể hiện các tiêu chí trong node.; “Traceability và source boundary đủ?” trộn traceability với boundary nhưng không thể hiện yêu cầu phân loại fact, assumption hoặc Verification required. Làm rõ tiêu chí để tránh hiểu mọi nguồn dẫn đều đủ.; Chuỗi “Ready for downstream review” rồi “IN_REVIEW giữ nguyên” dễ bị đọc như chuyển sang trạng thái Ready trước khi quay lại IN_REVIEW. Thể hiện chuyển downstream review là kết quả, còn IN_REVIEW là trạng thái không đổi.
assets/diagrams/00-foundations-016-cd538469.mmd — REVISE — Single BA outputs node implies every consumer receives same undifferentiated output set. Replace generic links with supported output-to-consumer relationships from table.; DEV --> BUILD[Build] is ambiguous and overstates direct conversion from BA output to implementation. Show supported use: Developers combine requirements, business rules, data dictionary, process flow, and interface contract to define system behavior.; QA --> TEST[Test basis] misrepresents direction: BA outputs form test basis; QA uses that basis to design tests. Correct relationship and name concrete inputs or outcome.; Specialist branch omits critical Verification required condition and authoritative-owner review boundary. Add condition without implying BA-authored notes are validated conclusions.; Diagram omits artifact-specific dependencies central to Architect, Operations, PM/Product Owner, and Business Owner responsibilities, making ownership boundaries misleadingly broad.; Visual mostly duplicates nearby prose at lower precision. Add explanatory structure showing which outputs support which role decisions, or remove diagram.
assets/diagrams/00-foundations-017-d884b723.mmd — REVISE — Nhánh “Không” tại gateway “Câu trả lời thuộc thẩm quyền chuyên môn?” dẫn đến “Ghi nhận giả định dự án để review”, trái nguyên tắc mọi nội dung chưa ghi rõ phải là điểm cần làm rõ, không phải giả định. Cần loại bỏ hoặc đổi kết quả thành tiếp tục làm rõ mà không dùng giả định để triển khai.; Bước “Escalate kèm artifact ID, bằng chứng, tác động” đưa vào quy trình escalation, trường artifact ID và yêu cầu phân tích tác động chưa được phần văn xuôi hỗ trợ. Cần bỏ chi tiết này hoặc bổ sung căn cứ tương ứng trong nội dung.; Gateway “Câu trả lời thuộc thẩm quyền chuyên môn?” không xác định chuyên môn nào, ai quyết định và tiêu chí phân loại. Cần nêu rõ chủ thể, ranh giới thẩm quyền và điều kiện chuyển nhánh.; Kết quả “Không tự đổi rule hoặc thiết kế” chỉ bao phủ rule và thiết kế, trong khi văn xuôi còn cấm coi nội dung review là quyết định vận hành, pháp lý, kế toán hoặc kiến trúc. Cần phản ánh đủ phạm vi hậu quả bị cấm.; Nhánh “Có” từ artifact đi đến sử dụng nội dung nhưng không nhắc trạng thái IN_REVIEW giới hạn quyền sử dụng và không cho phép coi nội dung là APPROVED hoặc BASELINED. Cần thể hiện rõ ranh giới này tại bước sử dụng hoặc kết quả.
assets/diagrams/00-foundations-018-682b23bd.mmd — REVISE — Bước H không nêu khách hàng là bên quyết định và bỏ lựa chọn đổi mặt hàng; cần thể hiện đủ ba lựa chọn: giao một phần, đổi ngày giao hoặc đổi mặt hàng.; Luồng H → I biến giao một phần thành kết quả mặc định. Phần prose chỉ cho phép soạn 350 thùng khi khách hàng đồng ý qua email; cần có điều kiện hoặc nhánh quyết định trước bước soạn hàng.; Sơ đồ không thể hiện trường hợp khách hàng không đồng ý giao một phần; cần thể hiện nhánh thay đổi cam kết hoặc kết thúc phù hợp thay vì luôn xuất 350 thùng.; Bước J mô tả dữ liệu bảng tính nhưng chưa làm rõ ERP không nhận quan hệ giữa dòng xuất, lô hàng và hạn dùng; cần thể hiện ranh giới hệ thống này.; Bước L dừng ở nhận chứng từ, bỏ kết quả quan trọng: kế toán phải đối chiếu thủ công đơn 480 thùng với thực giao 350 thùng; cần bổ sung hoạt động và phụ thuộc thủ công này.; Sơ đồ không thể hiện việc ERP thiếu bản ghi tập trung cho lý do thiếu, lựa chọn khách hàng và thay đổi cam kết giao; cần thể hiện thiếu hụt kiểm soát tại điểm trao đổi hoặc ranh giới hệ thống.
assets/diagrams/00-foundations-019-a46dea06.mmd — REVISE — Bước “Hàng giao khách” khẳng định kết quả giao hàng đã xảy ra, trong khi phần văn xuôi chỉ xác nhận ERP cho phép xuất kho và có phiếu xuất mô phỏng. Sửa thành trạng thái được văn bản hỗ trợ hoặc loại bỏ bước này.; Luồng “Hàng giao khách” rồi mới “Báo cáo cuối ngày phát hiện lô gần hạn” áp đặt thứ tự thời gian không được phần văn xuôi xác nhận. Tách việc phát hiện cuối ngày khỏi kết quả giao hàng hoặc thể hiện đúng mốc đã có bằng chứng.; Nhãn “Nhân viên kho chọn lô có tồn” bỏ mất tiêu chí lựa chọn theo vị trí kệ, yếu tố chính giải thích vì sao FEFO không được áp dụng. Sửa nhãn để nêu rõ nhân viên chọn lô theo vị trí kệ.; Nhãn “Báo cáo cuối ngày phát hiện lô gần hạn” che mất actor. Phần văn xuôi xác định quản lý kho phát hiện khi xem báo cáo; sửa sang chủ động và nêu rõ quản lý kho.; Sơ đồ chưa làm rõ ERP chỉ kiểm tra tồn kho dương và không kiểm tra số ngày còn lại trước hạn dùng. Bổ sung ranh giới kiểm soát bị thiếu để trực quan hóa đúng nguyên nhân nghiệp vụ.
assets/diagrams/00-foundations-020-48fafc80.mmd — REVISE — Luồng thiếu sự kiện “nhân viên kho xác nhận xuất kho” giữa chọn lô và kiểm tra tồn; bổ sung bước này để thể hiện đúng điểm kích hoạt kiểm tra Goods Issue.; Nút “Không kiểm tra QC / PENDING_QC” đặt sau “ERP tạo Goods Issue” làm sai thứ tự logic: bỏ qua kiểm tra QC là điều kiện xử lý trước hoặc trong lúc xác nhận, không phải bước sau khi Goods Issue đã được tạo. Chuyển nội dung này vào nhánh kiểm tra trước kết quả tạo Goods Issue.; Nhãn “Không kiểm tra QC / PENDING_QC” trộn hành vi hệ thống với trạng thái lô. Tách hoặc đổi thành nhãn cụ thể, thể hiện ERP chỉ kiểm tra tồn và không đánh giá qcStatus = PENDING_QC.
assets/diagrams/00-foundations-021-8192bea6.mmd — REVISE — Hai node 00_SOURCE_MAP và 01_CURRICULUM_ARCHITECTURE cùng quan hệ giữa chúng không được phần văn xuôi hoặc bảng xác lập; cần loại bỏ hoặc bổ sung căn cứ trong section.; Nhánh CA --> TM dừng tại TEMPLATE_MANIFEST, trong khi bảng nói handbook dùng ID, mục đích template và downstream nhận artifact hoàn chỉnh; cần thể hiện dependency từ TEMPLATE_MANIFEST đến handbook hoặc artifact áp dụng.; Nhãn template dự kiến mâu thuẫn sắc thái với template đã đăng ký trong bảng; cần dùng trạng thái canonical cụ thể, nhất quán.; Nhãn Template và artifact áp dụng gộp hai đối tượng và không nêu outcome cụ thể; cần tách hoặc đổi thành downstream concrete phù hợp với các dòng bảng.; Section 9 không được surrounding section xác nhận; cần dùng tên section hiện có hoặc bỏ tham chiếu số section nếu không có nguồn canonical.; Sơ đồ bỏ ngoại lệ quan trọng: dependency không xác nhận quy trình ERP thật hay phê duyệt vận hành; cần thể hiện boundary này để tránh diễn giải dependency như bằng chứng vận hành.
assets/diagrams/00-foundations-022-a57d918a.mmd — REVISE — Liên kết DATA/API → TC không được prose hoặc bảng loại liên kết hỗ trợ. Xóa liên kết này, hoặc bổ sung quy tắc và nguồn canonical tương ứng vào prose trước khi giữ nó.
assets/diagrams/00-foundations-024-33563291.mmd — REVISE — Gateway “Đủ điều kiện kiểm tra?” mơ hồ, không nêu điều kiện quyết định. Cần gắn với chính sách tín dụng đã được xác minh và xác nhận của Business Owner.; “Đúng owner xác minh” không xác định actor và trách nhiệm. Cần phân biệt Business Owner quyết định chính sách, Accounting Owner xác nhận cách xác định công nợ, BA duy trì traceability.; “Traceability kiểm tra” thiếu actor, dùng cấu trúc không rõ hành động. Cần thể hiện BA kiểm tra hoặc cập nhật traceability.; Nút “AC, TC, data, API liên quan” chứa AC và API không được section xác lập trực tiếp. Cần bỏ hoặc thay bằng artifact được nêu: requirement draft, business-rule reference, data definition và traceability link.; Diagram bỏ ranh giới phục hồi an toàn: chưa cấu hình khóa đơn, chưa chốt test pass/fail, chưa coi rule là đã phê duyệt. Cần thể hiện trạng thái hoặc outcome này để nhánh Verification required không bị hiểu là cho phép triển khai.; Nhánh “Có” không thể hiện outcome sau kiểm tra traceability. Cần nêu requirement vẫn là draft hay đủ cơ sở chuyển sang bước quyết định/phê duyệt được section hỗ trợ.
assets/diagrams/00-foundations-025-e65f921d.mmd — REVISE — Nhãn “Chuyển đúng Owner” mơ hồ, không thể hiện phân quyền đã nêu. Cần chỉ rõ Legal Owner và Accounting Owner xác minh nghĩa vụ; Business Owner quyết định quy trình; Architect đánh giá cấu hình; BA giữ traceability.; Nhánh “Có” đi thẳng đến đánh giá tác động, bỏ điều kiện phải có quyết định nghiệp vụ được ghi nhận. Cần thêm gateway hoặc bước xác nhận quyết định nghiệp vụ trước khi xem xét cấu hình.; Sơ đồ không thể hiện kết quả sau đánh giá tác động và khả năng hoàn tác. Cần nêu quyết định cho phép cấu hình/phát hành hoặc tiếp tục dừng, dựa trên xác minh và phê duyệt.; Bước “Ghi traceability trong artifact kiểm soát” thiếu artifact cụ thể và trạng thái cần giữ. Cần nêu CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY, và không đổi IN_REVIEW thành baseline khi chưa đủ xác minh.; Nhánh “Không” kết thúc tại chuyển Owner, bỏ trạng thái chờ xác minh và ranh giới an toàn. Cần thể hiện tiếp tục dừng cấu hình/phát hành cho đến khi xác minh, không tự mở khóa production hoặc tự diễn giải luật.
assets/diagrams/00-foundations-026-a30bd0d3.mmd — REVISE — Nhánh "Project assumption" không được section cho phép như kết quả thay thế; Decision yêu cầu ghi "Verification required" và không tạo business rule mới. Bỏ lựa chọn này hoặc chỉ dùng khi prose xác định rõ điều kiện, thẩm quyền và cách quản lý assumption.; Sơ đồ dừng tại các bước ghi nhận hoặc sửa lỗi nhưng không thể hiện việc Quality Owner xác nhận chính sách chất lượng và Business Owner xác nhận tác động vận hành. Bổ sung điểm quyết định và chủ thể có thẩm quyền.; Sơ đồ bỏ trạng thái kiểm soát bắt buộc của artifact: IN_REVIEW, version v0.9.0, ngày 2026-08-07. Thể hiện kết quả giữ artifact ở trạng thái chưa phê duyệt cho đến khi có approval reference.; Sơ đồ không thể hiện ngoại lệ nghiệp vụ cần xác minh, gồm quyền override và trường hợp đơn hàng đã xác nhận. Bổ sung chúng vào phạm vi verification thay vì chỉ hỏi điều kiện đo được.; Nhãn "Có nguồn và người có thẩm quyền?" gộp hai tiêu chí có thể cho kết quả khác nhau. Tách kiểm tra bằng chứng nguồn khỏi kiểm tra người có quyền quyết định.; Nhãn "Ký pháp và ID đúng canonical?" không khớp hoàn toàn với Decision Criteria, vốn yêu cầu ngưỡng đo được, phạm vi giao dịch, thẩm quyền và đường đến test basis. Chỉ giữ kiểm tra canonical sau khi các tiêu chí nội dung đã được xác nhận.; Nhãn "Liên kết source rule data acceptance criteria test basis" mơ hồ, thiếu quan hệ và dấu câu. Đổi thành nhãn cụ thể, song song, nêu rõ liên kết nguồn, business rule, data definition, acceptance criteria và test basis với các registry canonical tương ứng.; Sơ đồ bỏ cảnh báo trọng yếu rằng metadata, Owner, IN_REVIEW, version hoặc cuộc họp không có record không chứng minh phê duyệt. Bổ sung outcome ngăn ghi "đã phê duyệt" khi thiếu approval reference.
assets/diagrams/00-foundations-027-f6ef28d6.mmd — REVISE — Các nhánh từ gateway “Quyết định thuộc thẩm quyền nào?” không có điều kiện và có thể bị hiểu là ba lựa chọn loại trừ nhau. Gắn điều kiện cụ thể cho từng nhánh hoặc thể hiện ba xác nhận có thể cùng cần thiết: nhu cầu vận hành, cách phản ánh kế toán, khả thi kỹ thuật.; Các node Owner chỉ nêu tên và phạm vi, không nêu hành động. Đổi thành hành động đúng theo phần prose: Business Owner quyết định nhu cầu vận hành; Accounting Owner xác nhận cách phản ánh điều chỉnh; Architect xác nhận khả thi kỹ thuật.; Luồng thiếu trạng thái đầu ra của nhánh thiếu bằng chứng. Sau “Gắn Verification required”, phải thể hiện artifact vẫn ở trạng thái chờ xác minh và liên kết nguồn canonical khi nội dung tương ứng được đăng ký; không nên kết thúc như thể BA đã có khuyến nghị đủ căn cứ.; Node cuối “BA ghi khuyến nghị và đánh đổi” nhập cả nhánh đủ và thiếu bằng chứng, làm mờ khác biệt giữa khuyến nghị tạm thời và quyết định đã được Owner xác nhận. Tách hoặc ghi rõ trạng thái khuyến nghị, quyết định và traceability tương ứng.; Sơ đồ không thể hiện kết quả cụ thể của phân tích: khuyến nghị tạm thời phương án B, chưa phải quyết định kế toán hay rule đã xác nhận. Bổ sung outcome này để tránh biến quy trình chung thành bản sao rút gọn của bảng Authority.
assets/diagrams/00-foundations-028-22ad56d1.mmd — REVISE — Các vai trò Owner và Consumer cùng bước kiểm tra quality gate không được phần văn xuôi xác định; cần bỏ hoặc bổ sung căn cứ trong phần văn xuôi.; Nhãn template canonical, ID, file và tên giao diện TEMPLATE_MANIFEST cụ thể hơn thông tin được nêu trong phần văn xuôi; cần dùng thuật ngữ đã được định nghĩa hoặc bổ sung định nghĩa tương ứng.; Gateway Đã có template canonical? thiếu nhánh Không; nhánh Không rõ chỉ xử lý trường hợp chưa xác định, không xử lý trường hợp chắc chắn chưa có template. Cần thể hiện đầy đủ kết quả gateway.; Nhánh Không tự tạo ID hoặc file là chỉ dẫn nhưng không nêu kết quả hoặc bước tiếp theo; cần chỉ rõ điểm dừng hay cơ chế xử lý được phần văn xuôi hỗ trợ.; Sơ đồ không thể hiện trạng thái và giới hạn quan trọng của dữ liệu mô phỏng: IN_REVIEW, v0.9.0, ngày 2026-08-07, không tạo baseline hoặc approval. Cần thể hiện nếu sơ đồ nhằm mô tả quy trình áp dụng cho bối cảnh này.
assets/diagrams/00-foundations-029-fa800508.mmd — REVISE — Nhánh D -->|Không| F cho phép handoff ngay khi không có kết luận legal, accounting, security hoặc architecture, nhưng prose còn yêu cầu mọi lỗi có owner, mọi suy diễn có evidence bridge và mọi điểm chưa xác minh giữ nhãn rõ. Cần thêm gateway kiểm tra đủ ba điều kiện handoff.; Gateway Có kết luận legal, accounting, security, architecture? bỏ sót kết luận thuộc Business Owner và QA Owner, gồm business rule, acceptance criteria và test evidence. Cần bao phủ mọi miền chuyên môn và owner nêu trong section.; Nhãn Có kết luận mơ hồ và có thể khiến kết luận đã được authority xác nhận vẫn bị escalation. Cần chỉ rõ đây là kết luận hoặc suy diễn chưa có evidence hay thẩm quyền.; Bước Escalate đúng owner không thể hiện owner được chọn theo loại issue, dù bảng quy định Legal Owner, Accounting Owner, Business Owner, Technical Architect, Security Owner và QA Owner. Cần thể hiện điều kiện định tuyến owner.; Sau Chỉ cập nhật sau phản hồi có thẩm quyền, flow kết thúc mà không quay lại đối chiếu, kiểm tra điều kiện handoff hoặc tạo kết quả handoff. Cần thêm vòng tái kiểm tra và outcome rõ.; Flow không thể hiện Principal IT Business Analyst / Technical Curriculum Author đóng gói issue, link artifact và giữ traceability, cũng không thể hiện ranh giới không thay owner chuyên môn kết luận. Cần gắn actor và boundary này vào bước escalation/handoff.
assets/diagrams/01-ba-role-lifecycle-and-governance-001-afeea354.mmd — REVISE — Thứ tự D → A mâu thuẫn mô tả vòng đời: BA ghi artifact có thể kiểm tra trước khi hỗ trợ quyết định. Cần thể hiện artifact làm đầu vào cho quyết định hoặc thể hiện rõ artifact được cập nhật sau quyết định.; Nhãn “Quyết định thuộc đúng thẩm quyền” không nêu chủ thể quyết định, trong khi phần văn bản phân định Business Owner, Accounting Owner, Architect và BA. Cần chỉ rõ owner tương ứng hoặc thể hiện BA không phải người ra quyết định.; Governance được nối với BA, quyết định và artifact nhưng không nối với thay đổi hệ thống, dù văn bản định nghĩa governance kiểm soát thay đổi phải được ghi nhận. Cần thể hiện quan hệ này hoặc đổi kết quả để tránh ngụ ý governance dừng trước thay đổi.
assets/diagrams/01-ba-role-lifecycle-and-governance-003-c97c712d.mmd — REVISE — Các mũi tên thể hiện quan hệ tất định, trong khi phần văn xuôi chỉ khẳng định rủi ro "có thể" xảy ra. Cần ghi rõ quan hệ khả dĩ, chẳng hạn thêm nhãn "có thể dẫn đến".; Kết quả "Rework, tranh chấp trách nhiệm" không được phần văn xuôi nêu hoặc giải thích trực tiếp. Cần bỏ các kết quả này hoặc bổ sung căn cứ tương ứng trong nội dung xung quanh.
assets/diagrams/01-ba-role-lifecycle-and-governance-004-08f00da0.mmd — REVISE — Nút quyết định “Có quyết định thời điểm giữ hàng?” không phân biệt quyết định đã ghi nháp với quyết định đã được Business Owner phê duyệt. Sửa điều kiện để thể hiện quyết định phải do Business Owner xác nhận trước khi dùng làm quy tắc.; Nhánh “Không” đi thẳng đến diễn giải khác nhau và cam kết tồn không nhất quán, nhưng đoạn văn nêu đội có thể dừng trước build khi thiếu quyết định. Bổ sung điểm dừng hoặc review khi chưa có phê duyệt; chỉ gắn hậu quả không nhất quán với trường hợp vẫn tiếp tục build hay vận hành.; Nhãn “Có, được ghi trong artifact” có thể khiến artifact IN_REVIEW, chưa baseline và chưa approval trở thành test basis. Làm rõ trạng thái artifact đủ điều kiện sử dụng.; Luồng tích cực bỏ vai trò quyết định và ranh giới thẩm quyền: Business Owner quyết định, Architect xác nhận khả năng cấu hình, BA điều phối và truy vết. Thể hiện ít nhất chủ thể phê duyệt và bước xác nhận khả năng cấu hình nếu luồng dẫn đến kiểm tra ERP.; “Hiển thị lượng giữ hàng cho kho” được trình bày như kết quả chắc chắn dù phần prose chỉ nêu đây là tiêu chí và hành vi cần xem xét. Đổi nhãn để thể hiện yêu cầu hoặc kết quả cần kiểm chứng, không phải chức năng đã tồn tại.
assets/diagrams/01-ba-role-lifecycle-and-governance-005-e8f7dc22.mmd — REVISE — Gateway “Có bằng chứng kiểm soát?” mơ hồ: chưa nêu bằng chứng đã được xác minh và đủ để phân loại phát biểu là fact. Cần làm rõ điều kiện xác minh theo artifact hoặc nguồn có thẩm quyền.; Gateway “Đã có thẩm quyền chọn phương án?” nhầm giữa việc có thẩm quyền và việc thẩm quyền đã ra quyết định. Cần thể hiện quyết định đã được owner phù hợp phê duyệt, không chỉ tồn tại quyền quyết định.; Các nhánh Stakeholder input, Project assumption và Verification-required claim đi thẳng tới Decision, bỏ qua bước xác minh, đánh giá Decision Criteria và lựa chọn giữa các Options. Cần bổ sung các điều kiện này trước Decision.; Sơ đồ bỏ sót ranh giới trách nhiệm giữa Business Owner, Quality Owner, Architect và Legal Owner. Cần thể hiện owner tham gia theo loại xác nhận, đặc biệt khi viện dẫn yêu cầu pháp lý.; Nhánh “Có” từ bằng chứng tới “Fact đã xác minh” có thể khiến bằng chứng chưa được phê duyệt tại trạng thái IN_REVIEW bị hiểu là fact đã chốt. Cần phân biệt bằng chứng hiện có với bằng chứng đã được kiểm tra và xác nhận.; Kết quả “Giữ nhãn và xác minh” thiếu hành động, owner và đích truy vết. Cần nêu giữ phân loại hiện tại, ghi vào artifact phù hợp và liên kết registry/canonical artifact khi đã đăng ký.
assets/diagrams/01-ba-role-lifecycle-and-governance-006-e5300a0f.mmd — REVISE — Discovery exit không khớp bảng: sơ đồ nêu "stakeholder input" nhưng bỏ "câu hỏi cần xác minh". Thay bằng problem statement, phạm vi ban đầu và câu hỏi cần xác minh.; Analysis exit dùng "traceability đủ kiểm tra" mơ hồ và bỏ giả định, nguồn, rule cùng nhãn cho điểm chưa xác minh. Ghi exit gate cụ thể, song song với bảng.; Release exit phát sinh "rollback readiness" và "operational handover evidence" không được section hỗ trợ, đồng thời bỏ phạm vi release và điều kiện vận hành. Xóa nội dung phát sinh; dùng release record, phạm vi đưa ra và điều kiện vận hành.; Delivery dùng "build/configuration" không song song với thuật ngữ "build hoặc cấu hình" trong bảng. Đồng nhất cách diễn đạt.
assets/diagrams/01-ba-role-lifecycle-and-governance-007-33c1cc6b.mmd — REVISE — Sơ đồ thiếu Subject Matter Expert và Data Owner, dù bảng xác định họ là upstream owner của quy tắc nghiệp vụ và dữ liệu. Bổ sung các luồng này hoặc giới hạn rõ sơ đồ chỉ mô tả một tập luồng.; Nút "Architect / Delivery Lead" gộp hai vai trò có trách nhiệm khác nhau: Architect cung cấp đánh giá khả thi, còn Delivery Lead nhận requirement và thiết kế. Tách hai owner và thể hiện đúng chiều handoff.; Business Owner xuất hiện dưới hai nút "Upstream: Business Owner" và "Business Owner", gây hiểu nhầm thành hai actor. Dùng một nút hoặc phân biệt rõ vai trò theo từng luồng.; Sơ đồ không thể hiện cơ chế handoff có kiểm soát được prose định nghĩa: artifact, trạng thái, câu hỏi mở, rủi ro và xác nhận đã nhận không đồng nghĩa phê duyệt. Bổ sung trạng thái hoặc nhãn handoff thể hiện ranh giới này.; Luồng tuân thủ chỉ thể hiện BA gửi rủi ro và nhận kết luận, nhưng bảng còn xác định Business Owner, Architect và QA Owner là downstream owner của kết luận. Thể hiện bước chuyển giao kết luận đến đúng owner.; Nhãn "Requirement, rule, acceptance criteria" dùng "rule" mơ hồ và có thể ngụ ý BA tạo hoặc sở hữu quy tắc canonical, trái giới hạn BA. Đổi thành quy tắc có bằng chứng nguồn hoặc liên kết canonical.; Sơ đồ bỏ luồng dữ liệu, escalation và các ngoại lệ trọng yếu như dữ liệu cá nhân, xung đột định nghĩa, rủi ro bảo mật, mất dữ liệu và tranh chấp expected result. Bổ sung ranh giới hoặc nhánh escalation cần thiết để không làm mô hình governance sai lệch.
assets/diagrams/01-ba-role-lifecycle-and-governance-008-ef9136de.mmd — REVISE — Luồng Testing → Release ghi “Kết quả kiểm thử và lỗi cần xử lý”, dễ hiểu rằng lỗi chưa xử lý được chuyển thẳng sang phát hành. Đổi đầu ra thành trạng thái đủ điều kiện phát hành; nếu muốn thể hiện xử lý lỗi, bổ sung vòng quay lại Delivery chỉ khi phần prose cũng mô tả vòng này.; Nhãn “Chức năng đã xây dựng” hẹp hơn nội dung prose “thay đổi kỹ thuật”. Đổi nhãn để bao quát mọi thay đổi kỹ thuật, không chỉ chức năng.
assets/diagrams/01-ba-role-lifecycle-and-governance-009-8c1776d3.mmd — REVISE — Bằng chứng tổng hợp thêm trạng thái tổng hợp không được phần văn xuôi xác lập; đổi thành Bằng chứng.; Sơ đồ bỏ quan hệ với kết quả nghiệp vụ cần đạt, dù đây là một trong ba câu hỏi BA phải hiểu trước; bổ sung đầu vào này vào phần hình thành ngữ cảnh phân tích.; BA hiểu ngữ cảnh quá rộng, không cho biết ngữ cảnh gồm mục tiêu nghiệp vụ, bằng chứng hiện trạng và artifact nguồn; dùng nhãn cụ thể phản ánh các thành phần được nêu.; Canonical ID dùng ngôn ngữ không song song với các nhãn tiếng Việt và chưa nhấn mạnh yêu cầu giữ nguyên định danh giữa artifact; đổi thành Định danh canonical.; Quan hệ A --> T ngụ ý hiểu ngữ cảnh tự tạo traceability, nhưng văn xuôi chỉ xác lập định danh canonical giúp mở đúng nguồn; sửa quan hệ để traceability thể hiện liên kết giữa định danh và artifact nguồn được kiểm soát.
assets/diagrams/01-ba-role-lifecycle-and-governance-010-35dd757d.mmd — REVISE — Gateway “Nội dung vượt legal/accounting/security authority?” đưa accounting và security vào dù section không nêu hai authority này. Đổi phạm vi kiểm tra thành safe use boundary và thẩm quyền Food Safety Owner/Legal Owner.; Nhánh thiếu canonical ID/URL kết thúc tại “STOP”, trong khi Decision yêu cầu giữ ghi chú làm evidence chưa xác minh, gắn VERIFICATION_REQUIRED, liên kết nguồn phù hợp và chuyển đúng owner xác minh. Thể hiện các bước này thay vì kết thúc luồng.; Nhánh “Nguồn còn mới và đúng thẩm quyền?” gộp hai tiêu chí nhưng không phân biệt cách xử lý nguồn cũ với nguồn sai thẩm quyền. Cả hai cần dẫn rõ đến VERIFICATION_REQUIRED và owner có thẩm quyền.; Kết quả “Đủ điều kiện làm evidence phân tích” bỏ ranh giới quan trọng: evidence không trở thành business rule bắt buộc và không tạo approval ngầm định. Bổ sung outcome này.; Diagram không thể hiện trách nhiệm: Food Safety Owner và Legal Owner xác minh nghĩa vụ; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability. Gắn actor vào bước xác minh và bước traceability.; Nhãn “Có owner” mơ hồ vì không nói owner có thẩm quyền. Dùng điều kiện cụ thể phù hợp Decision Criteria.
assets/diagrams/01-ba-role-lifecycle-and-governance-011-bec276ff.mmd — REVISE — Gateway "Canonical ID and filename present?" omits required owner, access date, and source-boundary checks. Add these criteria before controlled use.; Gateway "Authority verification needed?" is ambiguous because section assigns verification by subject matter to Legal Owner, Accounting Owner, Food Safety Owner, or Security Owner. Name applicable authority or state concrete routing criterion.; Branch "Label Verification required" ends without showing whether source may be used, must await confirmation, or remains limited to an unverified statement. Add explicit resulting state and usage boundary.; Outcome "Use within source boundary" can follow "No" verification without showing authority confirmation where required. Prevent path from implying unverified specialist content is approved.; Diagram omits Principal IT Business Analyst / Technical Curriculum Author responsibility for traceability maintenance. Show owner for traceability step or outcome.
assets/diagrams/01-ba-role-lifecycle-and-governance-012-3f083241.mmd — REVISE — Luồng Available --> Allocated --> QA_Hold mô tả lô chờ QA từng khả dụng và được cấp phát trước khi kiểm tra, trái với fact rằng tồn khả dụng và tồn chờ QA là hai trạng thái riêng. Cần thể hiện lô vào QA_Hold trước khi có thể trở thành Available hoặc được cấp phát.; Chuyển tiếp QA_Hold --> Available: QA Owner từ chối lô làm lô bị từ chối trở thành hàng khả dụng, trái với mục tiêu ngăn xuất hàng chưa đạt điều kiện. Cần dùng trạng thái kết quả không khả dụng hoặc sửa điều kiện chuyển tiếp thành QA chấp thuận.; Ghi chú cho phép cam kết từ QA_Hold khi có quyết định Business Owner và xác nhận QA Owner, nhưng prose yêu cầu QA giải phóng hàng trước khi hàng có thể giao. Cần tách quyết định chính sách giao một phần của Business Owner khỏi quyền xác nhận giải phóng lô của QA Owner.; Nhãn Nhập tồn kho tổng hợp không thể hiện ranh giới lô, trạng thái hay điều kiện phân loại ban đầu, trong khi section yêu cầu truy vết theo lô và phân biệt 100 thùng khả dụng với 20 thùng chờ QA. Cần dùng sự kiện nhập và điều kiện phân loại cụ thể.; Chuyển tiếp Allocated --> Released: QA Owner xác nhận điều kiện xuất ngụ ý mọi hàng đã cấp phát đều cần QA xác nhận, nhưng section chỉ gắn QA với phần đang kiểm tra. Cần giới hạn QA release cho lô ở QA_Hold hoặc nêu bằng chứng cho kiểm soát QA trên toàn bộ lô.
assets/diagrams/01-ba-role-lifecycle-and-governance-013-1c6d4959.mmd — REVISE — Các mũi tên thể hiện luồng hoặc dependency từ TRACEABILITY_ID_REGISTRY sang CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY, nhưng section chỉ xác định bốn artifact và nghĩa vụ quản trị; không xác định trình tự hoặc dependency này. Cần bỏ quan hệ không được prose hỗ trợ hoặc dùng quan hệ đã được section nêu rõ.; Downstream review package không phải artifact, trạng thái hoặc giao diện được định nghĩa trong section. Cần bỏ node này hoặc thay bằng khái niệm có tên và vai trò được prose xác nhận.; CHAPTER_MANIFEST link nhập nhằng giữa artifact CHAPTER_MANIFEST và liên kết tới artifact. Cần dùng đúng canonical ID và biểu diễn quan hệ cụ thể được section hỗ trợ.; Sơ đồ bỏ qua ranh giới quản trị quan trọng: Business Owner xác nhận nội dung nghiệp vụ, Data Owner xác nhận nghĩa dữ liệu, và Principal IT Business Analyst / Technical Curriculum Author quản trị artifact. Cần thể hiện các owner nếu sơ đồ nhằm giải thích quy trình quản trị.; Sơ đồ không thể hiện giới hạn của IN_REVIEW, dễ khiến luồng kết thúc tại manifest bị hiểu là approval hoặc baseline. Cần thể hiện rõ IN_REVIEW không đồng nghĩa approval, baseline, compliance, production readiness hoặc user acceptance.; BA activity evidence quá rộng và không khớp thuật ngữ cụ thể ID nguồn, ID output, loại bằng chứng trong prose. Cần dùng nhãn cụ thể, có thể kiểm tra được.
assets/diagrams/01-ba-role-lifecycle-and-governance-014-58ee2dc1.mmd — REVISE — Nhánh Không --> Tiếp tục xử lý đơn chưa được prose hỗ trợ: quy tắc chỉ yêu cầu tạo review khi variance_percent >= 5, không khẳng định giá trị dưới 5 luôn được tiếp tục. Bỏ kết quả này hoặc bổ sung quy tắc xác nhận.; Sơ đồ bỏ ngoại lệ Hàng mẫu giá 0 VND không tính tỷ lệ chênh lệch; luồng hiện tại ngụ ý mọi đơn đều tính variance_percent. Thêm nhánh kiểm tra ngoại lệ trước bước tính tỷ lệ.; Điểm kết thúc Ghi nhận quyết định review không thể hiện chênh lệch được quyết định ra sao dù phạm vi prose kết thúc tại quyết định. Xác định và thể hiện kết quả quyết định được prose hỗ trợ, hoặc thu hẹp mô tả phạm vi.
assets/diagrams/01-ba-role-lifecycle-and-governance-015-ff4cf361.mmd — REVISE — Nhãn thiếu hoặc mâu thuẫn chỉ bao phủ một phần trường hợp không đạt gate; các lỗi traceability, boundary, lịch sử thay đổi hoặc trường bắt buộc cũng phải giữ artifact ở Draft. Đổi điều kiện thành chưa đạt quality gate hoặc diễn đạt tương đương.; Chuyển trạng thái IN_REVIEW --> Draft: reviewer trả lại chưa được prose xác lập rõ; section chỉ định nghĩa downstream review và khả năng phản biện. Bỏ chuyển trạng thái này hoặc bổ sung prose quy định reviewer có quyền trả artifact về Draft.
assets/diagrams/01-ba-role-lifecycle-and-governance-016-b215722d.mmd — REVISE — Nút PM/Product Owner và kết quả Scope and priority không được phần văn xuôi xác lập; bỏ nhánh này hoặc bổ sung căn cứ rõ trong nội dung.; Nhãn BA outputs quá mơ hồ, không thể hiện các output cụ thể gồm process flow, requirement, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và traceability matrix; cần dùng nhãn cụ thể hoặc phân tách nguồn.; Sơ đồ thể hiện mọi consumer nhận chung một nguồn đồng nhất, trong khi quyết định nêu output được tách theo mục đích và liên kết bằng ID canonical; cần thể hiện quan hệ này để tránh sai nghĩa.; Vai trò nguồn tham chiếu của CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và traceability matrix bị bỏ sót; cần thể hiện dependency giữa requirement, rule, field logic và kiểm thử.; Nhãn Technical design rộng hơn căn cứ trong phần văn xuôi, vốn chỉ nêu nhu cầu Architect xác định dữ liệu lô có đi qua hệ thống khác hay không; cần thu hẹp nhãn theo integration/data flow hoặc bổ sung căn cứ.; Sơ đồ không thể hiện ranh giới thẩm quyền giữa BA, Business Owner, Architect, QA, Operations và specialist owners, dù đây là nội dung governance trọng yếu; cần biểu diễn ownership hoặc authority boundary.; Rủi ro Operations không có owner xử lý lỗi tích hợp bị làm phẳng thành Operational readiness; cần thể hiện trách nhiệm xử lý hoặc escalation cho lỗi nhập lô.
assets/diagrams/01-ba-role-lifecycle-and-governance-017-5b6dbe64.mmd — REVISE — Gateway “Trong thẩm quyền?” không hỗ trợ nhánh “Không hoặc mâu thuẫn”: mâu thuẫn bằng chứng không đồng nghĩa ngoài thẩm quyền. Cần đổi gateway để bao quát cả thẩm quyền và tính nhất quán của bằng chứng, hoặc tách hai điều kiện.; “Quyết định chuyên môn” thu hẹp sai phạm vi escalation. Bảng còn có quyết định về mục tiêu, ngân sách, thời hạn, vận hành, kiến trúc và chấp nhận rủi ro doanh nghiệp. Cần dùng nhãn kết quả bao quát quyết định của owner có thẩm quyền.; “Escalation đúng owner” chưa cụ thể về trách nhiệm. Cần thể hiện chuyển đến owner có thẩm quyền tương ứng, không mặc định specialist owner.
assets/diagrams/01-ba-role-lifecycle-and-governance-018-a2b5eb73.mmd — REVISE — Nhánh B -- Có evidence --> C không song song với câu hỏi Người nhận hiểu cùng phạm vi?: Có evidence không xác nhận người nhận hiểu đúng phạm vi. Đổi điều kiện thành kết quả kiểm tra phạm vi cụ thể.; C[Thực hiện theo artifact] mâu thuẫn trạng thái IN_REVIEW, v0.9.0: section nêu rõ artifact chưa phải baseline, phê duyệt, cấu hình ERP hoặc chỉ dẫn production. Outcome phải giới hạn ở tiếp nhận hoặc sử dụng theo trạng thái review, không cho phép thực hiện trực tiếp.; F[Cập nhật traceability trong artifact] không được prose quy định. Section yêu cầu chuyển giao kèm ngữ cảnh và đặt câu hỏi chính xác, nhưng không xác lập bước cập nhật traceability. Bỏ bước hoặc bổ sung căn cứ trong prose.; G[Escalate owner chuyên môn] dùng nhãn pha tiếng Anh và thiếu actor chịu trách nhiệm escalation. Dùng nhãn tiếng Việt cụ thể, nêu BA hoặc người nhận thực hiện nếu section xác lập trách nhiệm đó.; Luồng G --> F giả định escalation luôn tạo câu trả lời đủ thẩm quyền để cập nhật artifact. Thiếu bước nhận và kiểm tra câu trả lời, cùng nhánh khi owner chưa xác minh hoặc vấn đề vẫn chưa được giải quyết.; Diagram bỏ boundary quan trọng: requirement chưa được xác minh phải giữ trạng thái assumption hoặc unresolved, không được chuyển sang thực hiện. Thêm outcome dừng/chờ xác minh nếu prose hỗ trợ.
assets/diagrams/01-ba-role-lifecycle-and-governance-019-27240677.mmd — REVISE — Bước F khẳng định nhân viên tiếp tục xác nhận đơn, nhưng phần văn xuôi chỉ chứng minh ERP hiển thị “đủ hàng”; đổi thành kết quả được hỗ trợ hoặc bỏ bước F.; Gateway D chỉ có nhánh “Có”, khiến quyết định trông thiếu nhánh xử lý khi RequestedQuantity > OnHandQuantity; thêm nhánh “Không” với kết quả được phần văn xuôi xác nhận, hoặc trình bày D như phép kiểm tra của case cụ thể thay vì gateway.; Liên kết G tới C gây hiểu rằng đơn Draft ảnh hưởng bước đọc OnHandQuantity; phần văn xuôi nói ERP không dùng nhu cầu 900 BOT trong công thức. Liên kết phải chỉ rõ nhu cầu này bị loại khỏi phép tính AvailableToPromise.; Nhãn “Nguyên nhân dữ liệu” ở H mơ hồ và gán quan hệ nhân quả chưa chính xác. Thiếu ReservedQuantity hoặc phân bổ kho là giới hạn dữ liệu; công thức AvailableToPromise = OnHandQuantity mới trực tiếp tạo kết quả AVAILABLE.; Sơ đồ chưa thể hiện hậu quả chính đã được chứng minh: hai đơn yêu cầu tổng 2.100 BOT, vượt tồn hiển thị 600 BOT. Bổ sung kết quả này để hình có giá trị giải thích vượt phần mô tả tuần tự.
assets/diagrams/01-ba-role-lifecycle-and-governance-020-a93deead.mmd — REVISE — Gateway Mỗi lô đủ tồn và đúng SKU? bỏ điều kiện trạng thái lô được phép xuất trong BR-NF-LOT-004; bổ sung kiểm tra trạng thái lô.; Các bước kiểm tra, từ chối, ghi phân bổ, xác nhận và cập nhật tồn không nêu actor hoặc hệ thống thực hiện; phân biệt thao tác nhân viên kho với kiểm tra và ghi nhận của ERP.; Sơ đồ thể hiện luồng như quy trình đã được phê duyệt dù nội dung chỉ là đề xuất IN_REVIEW, v0.9.0; gắn nhãn luồng đề xuất hoặc nêu điểm cần approval trước production.; Nhánh Từ chối xác nhận gộp mọi lỗi và không cho biết phiếu vẫn chưa xác nhận; thể hiện trạng thái kết thúc cụ thể hoặc đường quay lại sửa phân bổ.; Bước Cập nhật tồn theo từng lô và lưu truy vết chưa thể hiện yêu cầu không xác nhận nếu cập nhật dữ liệu thất bại; thể hiện xác nhận, cập nhật tồn và lưu truy vết như một kết quả nhất quán, tránh ngụ ý phiếu có thể đã xác nhận trước khi ghi tồn hoàn tất.
assets/diagrams/01-ba-role-lifecycle-and-governance-021-82358fc6.mmd — REVISE — Nhánh D -- Có --> F[Phân bổ 240 chai] không nêu chỉ cần phân bổ thêm 60 chai từ lô vừa được Quality Owner chuyển sang AVAILABLE; nhãn hiện tại dễ bị hiểu là phân bổ toàn bộ 240 chai từ lô này. Cần làm rõ cơ cấu 180 + 60.; Nút E[Chọn giao 180 chai hoặc điều chỉnh ngày giao] không xác định Business Owner là người có thẩm quyền chọn phương án. Cần ghi rõ owner để không biến khuyến nghị BA thành quyết định.; Nhánh thiếu hàng bỏ sót phương án chờ Quality Owner xác nhận lô, dù BR-NFS-EX-002 và OPT-NFS-EX-003 nêu rõ phương án này. Cần thể hiện đủ ba lựa chọn: giao một phần, chờ kiểm tra chất lượng, hoặc điều chỉnh đơn/ngày giao.; Luồng đi từ phân bổ thẳng đến Tạo phiếu xuất, bỏ điều kiện phải thông báo và xác nhận với khách về số lượng, ngày giao thực tế theo DC-NFS-EX-003. Cần thêm gateway hoặc bước xác nhận trước khi tạo chứng từ.; Nhãn được Quality xác nhận AVAILABLE? dùng tên vai trò không đầy đủ và không mô tả đúng quyền chuyển trạng thái. Cần dùng Quality Owner đã xác nhận chuyển lô sang AVAILABLE?.
assets/diagrams/01-ba-role-lifecycle-and-governance-022-2eee5515.mmd — REVISE — Các cạnh SM --> CA và CA --> CM nêu quan hệ phụ thuộc không được prose xác nhận. Bổ sung căn cứ trong section hoặc loại bỏ các cạnh khỏi sơ đồ.; Nhãn ID persistent không tự nhiên và không cụ thể về vai trò của registry. Dùng nhãn tiếng Việt rõ nghĩa, nhất quán với các nhãn còn lại.; Nhãn đích Section 9 không khớp ngữ cảnh trích dẫn chỉ hiển thị ### Core, nên người đọc không thể kiểm chứng ranh giới. Ghi đúng tiêu đề hoặc định danh section có thể đối chiếu.
assets/diagrams/01-ba-role-lifecycle-and-governance-023-89731196.mmd — REVISE — Chiều liên kết không nhất quán với bảng: sơ đồ dùng R --> B, R --> A, R --> D, trong khi bảng xác định BR liên kết đến REQ, AC liên kết đến REQ và DATA/API liên kết đến REQ. Cần biểu diễn chiều theo quy ước của bảng hoặc ghi rõ mũi tên thể hiện phụ thuộc thay vì hướng liên kết.; Thiếu liên kết DATA/API đến AC dù bảng nêu AC là đích dùng liên kết. Cần bổ sung quan hệ này nếu sơ đồ mô tả đầy đủ traceability.; Nhãn AC và TC bỏ nguồn canonical tương ứng: artifact requirement được registry liên kết và registry test/traceability được đăng ký. Cần thể hiện nguồn ID hoặc ranh giới registry nhất quán với NEED, REQ, BR và DATA/API.; Sơ đồ không thể hiện ngoại lệ REQ có thể truy về NEED hoặc nguồn thẩm quyền ghi rõ. Cần thể hiện nhánh nguồn thẩm quyền để tránh ngụ ý mọi REQ bắt buộc xuất phát từ NEED.; Sơ đồ bỏ trạng thái và phiên bản áp dụng cho mọi artifact: IN_REVIEW, v0.9.0, 2026-08-07. Cần thể hiện dưới dạng ghi chú chung nếu các nút đại diện artifact của case Nova Foods.
assets/diagrams/01-ba-role-lifecycle-and-governance-024-56f420ee.mmd — REVISE — Nhãn “Review theo thẩm quyền” đưa vào khái niệm thẩm quyền nhưng đoạn văn không xác định vai trò, chủ thể hoặc quy tắc thẩm quyền. Cần đổi thành bước rà soát liên kết được đoạn văn hỗ trợ, hoặc bổ sung prose xác định người review và thẩm quyền.; Bước “Cập nhật liên kết NEED/REQ/BR/AC/DATA/API/TC” giả định mọi loại liên kết đều phải cập nhật trước khi artifact phụ thuộc được cập nhật hoặc chặn. Prose chỉ yêu cầu rà soát liên kết và lan truyền thay đổi khi liên quan. Cần thể hiện điều kiện theo phạm vi ảnh hưởng, tránh ngụ ý cập nhật toàn bộ liên kết.; Nhãn “Ghi thay đổi có ID và thời điểm” quy định hai trường bắt buộc chưa được prose nêu rõ. Cần đổi thành ghi nhận thay đổi, hoặc bổ sung prose quy định ID và thời điểm.
assets/diagrams/01-ba-role-lifecycle-and-governance-025-45989561.mmd — REVISE — Bước “Kiểm tra nguồn và owner có thẩm quyền” không có nhánh kết quả. Thêm gateway phân biệt nguồn và owner hợp lệ với trường hợp thiếu hoặc chưa được xác nhận; trường hợp sau phải giữ nội dung ở IN_REVIEW và yêu cầu owner phù hợp xác nhận.; Nhánh “Có ảnh hưởng build hoặc test?” chỉ dừng dùng nội dung sai nhưng bỏ sót thay đổi logic nghiệp vụ đã đi vào pull request hoặc cấu hình production. Bổ sung phạm vi ảnh hưởng tới build, test, merge và cấu hình.; Bước “Sửa artifact và liên kết” mơ hồ về artifact kiểm soát cần cập nhật. Nêu rõ cập nhật artifact canonical hoặc artifact kiểm soát phù hợp, gồm nguồn, trạng thái và liên kết truy vết.; Luồng kết thúc ở “Review lại phạm vi tác động” nhưng không nêu điều kiện được tiếp tục sử dụng. Thêm kết quả xác nhận nội dung đã được review, baseline hoặc phê duyệt theo kiểm soát tương ứng trước khi dùng lại.; Các bước kiểm tra, dừng sử dụng, sửa và review không gắn owner dù trách nhiệm là trọng tâm phần văn xuôi. Gắn actor phù hợp như BA, Business Owner, QA hoặc delivery tại bước actor quan trọng.
assets/diagrams/01-ba-role-lifecycle-and-governance-026-45c31f81.mmd — REVISE — Nhánh “Có sửa dữ liệu hoặc cấu hình thực?” giả định thay đổi thực đã xảy ra, trong khi section chỉ nêu nội dung được chuyển như quyết định triển khai và quyết định cuối là không sửa ERP. Cần bám đúng trạng thái được mô tả.; Bước “Khôi phục từ bản sao hoặc giao dịch đảo được owner cho phép” đưa thêm cơ chế khôi phục, giao dịch đảo và quyền phê duyệt không có trong section. Cần loại bỏ hoặc chỉ thể hiện hành động được prose hỗ trợ.; Bước “Ghi sự cố” coi tình huống là sự cố đã xảy ra, nhưng section chỉ xác nhận rủi ro từ nội dung chưa được phê duyệt. Cần dùng trạng thái giả định hoặc vấn đề cần kiểm soát.; Nhãn “đúng owner” mơ hồ và bỏ mất ranh giới thẩm quyền: Business Owner xác nhận chính sách giữ hàng, Architect xác nhận khả năng hệ thống, Accounting Owner xác nhận tác động kế toán. Cần nêu rõ từng owner và phạm vi quyết định.; Diagram bỏ gateway kiểm tra nguồn canonical, traceability và trạng thái cho phép, dù đây là tiêu chí quyết định cốt lõi. Cần thể hiện kiểm tra trước mọi quyết định triển khai.; Nhánh “Không” dẫn thẳng đến giữ nội dung trong phạm vi học liệu nhưng không thể hiện việc ghi nguồn, trạng thái và liên kết các artifact canonical theo Decision và Artifact. Cần bổ sung bước kiểm soát này.
assets/diagrams/01-ba-role-lifecycle-and-governance-027-51d001c6.mmd — REVISE — Nhánh mơ hồ ghi “thêm tiêu chí đo được”, dễ hiểu rằng BA tự chọn giá trị nghiệp vụ, trái ranh giới thẩm quyền ngay sau sơ đồ. Cần thể hiện việc lấy tiêu chí từ nguồn có thẩm quyền hoặc gắn Verification required.; Nhánh thẩm quyền dùng từ “escalation” nhưng không nêu đích chuyển. Cần chỉ rõ Legal Owner, Accounting Owner, Business Owner hoặc domain owner phù hợp.; Nhánh không đầy đủ ghi “bổ sung phạm vi xử lý”, quá mơ hồ và không bao quát trigger, đầu vào, quy tắc, ngoại lệ, trạng thái sau xử lý, đầu ra và consumer như bảng.; Bước hội tụ chỉ kiểm tra source boundary và trạng thái IN_REVIEW, nhưng bỏ hành động phục hồi quan trọng: dừng dùng phát biểu làm quyết định và gắn Verification required khi chưa xác minh.; Sơ đồ không thể hiện rủi ro riêng của phát biểu pháp lý, kế toán, an toàn thực phẩm hoặc phê duyệt. Cần có nhánh hoặc điều kiện chuyển đúng owner thay vì đưa mọi lỗi qua cùng một bước kiểm tra.
assets/diagrams/01-ba-role-lifecycle-and-governance-028-6d959902.mmd — REVISE — Nhánh “Không” bỏ qua bước xác định tác động nghiệp vụ, dữ liệu và kiểm soát. Thiếu bằng chứng chỉ làm giảm độ tin cậy và yêu cầu Verification required; BA vẫn phải phân tích tác động trước khi xác định thẩm quyền.; Gateway “Chạm legal, accounting, security hoặc architecture?” gom bốn ranh giới chuyên môn thành một nhánh và nhãn “Chuyển chuyên gia có thẩm quyền”. Prose yêu cầu phân đúng Legal Owner, Accounting Owner, Security hoặc Architect; chuyên gia không có thẩm quyền chưa thể quyết định.; Luồng chỉ chọn chuyên môn hoặc Business Owner, gây hiểu rằng hai bên loại trừ nhau. Yêu cầu chạm nhiều miền phải được chia thành các phần quyết định; Business Owner vẫn quyết định ưu tiên hoặc quy trình nghiệp vụ, còn owner chuyên môn quyết định phần thuộc ranh giới của mình.; Nhãn “Có bằng chứng đủ mạnh?” mơ hồ và nhị phân, không thể hiện thứ tự chất lượng bằng chứng hoặc mức tin cậy được prose yêu cầu. Cần nêu tiêu chí đủ cho quyết định và giữ trạng thái chưa xác minh khi nguồn hoặc thẩm quyền chưa đủ.; Bước sau khi chuyển thẩm quyền chỉ ghi “recommendation, evidence và điều kiện”, không ghi quyết định, owner, mức tin cậy hoặc điều kiện đảo quyết định. Cần phản ánh đầy đủ nội dung ghi nhận được mô tả trong prose.; Kết quả “Giữ trạng thái IN_REVIEW” dễ bị hiểu là mọi đề xuất luôn phải giữ IN_REVIEW, kể cả sau quyết định. IN_REVIEW trong prose mô tả trạng thái các artifact canonical hiện tại và giới hạn suy luận; cần gắn kết quả này với artifact chưa có bằng chứng APPROVED hoặc BASELINED.
assets/diagrams/01-ba-role-lifecycle-and-governance-029-69399861.mmd — REVISE — "section 12" không xuất hiện trong phần văn xuôi; bỏ tham chiếu hoặc nêu căn cứ rõ trong phần này.; "So khớp ID, path, status, version" bỏ sót các giá trị bắt buộc: ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND, tính chất case mô phỏng và dữ liệu tổng hợp; thêm các kiểm tra này bằng nhãn cụ thể.; "source boundary và labels" mơ hồ, không chỉ rõ nguồn, trạng thái IN_REVIEW và giới hạn thẩm quyền cần giữ nguyên; thay bằng tiêu chí kiểm tra cụ thể.; Nhánh "Không" cho phép handoff mà không xác nhận đủ toàn bộ định danh, trạng thái, nguồn và giới hạn thẩm quyền; bổ sung điều kiện đạt đầy đủ trước khi handoff.; "Ghi open issue hoặc Verification required", "Escalate đúng owner" và "Đóng gói review evidence" là bước, trạng thái và owner không được phần văn xuôi xác lập; bổ sung căn cứ trong văn xuôi hoặc bỏ khỏi sơ đồ.; Hai nhánh "Có" và "Không" cùng kết thúc tại handoff IN_REVIEW, nhưng nhánh có mâu thuẫn chưa thể hiện yêu cầu dừng handoff để làm rõ; sửa kết quả nhánh này thành trạng thái chặn cho đến khi mâu thuẫn được xử lý.
assets/diagrams/02-stakeholders-domain-and-context-001-4b2c142b.mmd — REVISE — Luồng chỉ thể hiện BA xác định domain và context, bỏ thiếu bước phân tích stakeholder dù phần văn bản yêu cầu xác định đủ ba phần trước khi viết yêu cầu. Cần thể hiện BA xác định stakeholder liên quan, gồm người cung cấp đầu vào, người quyết định và owner.; Nhãn "Phạm vi hiểu chung" mơ hồ, không nêu actor nào thống nhất hoặc nội dung nào được thống nhất. Cần dùng trạng thái cụ thể về actor, outcome và ranh giới nghiệp vụ đã được các stakeholder liên quan thống nhất.; Nhánh rủi ro chỉ ghi "thiếu context", trong khi văn bản quy nguyên nhân cho việc không xác định stakeholder, domain và context. Cần sửa điều kiện để phản ánh đủ ba thiếu hụt hoặc giới hạn rõ nhánh này chỉ minh họa riêng rủi ro thiếu context.; Nhãn "Thiết kế và kiểm thử" gộp hai hoạt động nhưng không nêu quan hệ truy vết từ nhu cầu đến yêu cầu và kiểm thử, vốn là kết quả quan trọng trong văn bản. Cần thể hiện kiểm thử truy vết được về nhu cầu hoặc tách rõ kết quả mong đợi.
assets/diagrams/02-stakeholders-domain-and-context-002-037d10ca.mmd — REVISE — Hai nhánh “Xác nhận” và “Không xác nhận” cùng đi tới một bước giống hệt nhau, nên sơ đồ không thể hiện trạng thái hoặc kết quả thông báo khác nhau. Cần phân biệt kết quả quan sát được của từng nhánh.; Bước “Lưu dấu vết người yêu cầu, trạng thái, lý do” đặt sau Customer Service, ngụ ý việc lưu chỉ xảy ra sau khi thông báo và có thể thuộc trách nhiệm Customer Service. Phần prose không hỗ trợ thứ tự hoặc quyền sở hữu này. Cần đặt việc ghi nhận tại điểm tạo/cập nhật yêu cầu và thể hiện đúng chủ thể chịu trách nhiệm.; Nhãn “Customer Service thông báo trạng thái” chưa nêu trạng thái nào được thông báo. Cần gắn nội dung thông báo với kết quả xác nhận hoặc không xác nhận của Warehouse Supervisor.
assets/diagrams/02-stakeholders-domain-and-context-003-19627067.mmd — REVISE — Nhánh Có nguồn truy lại được? dẫn thẳng đến Fact đã xác minh đánh đồng khả năng truy nguồn với việc nguồn đã đủ sức kiểm chứng. Đổi điều kiện để yêu cầu nguồn kiểm chứng và kết quả xác minh, phù hợp Decision Criteria.; Verification-required claim được trình bày như loại thông tin ngang hàng với Stakeholder input và Project assumption, trong khi prose chỉ quy định Verification required là trạng thái gắn cho phạm vi cần xác minh. Sửa thành trạng thái hoặc điểm xác minh, không thành loại claim mới.; Gateway Đã chọn phương án theo tiêu chí và authority? dùng authority mơ hồ và bỏ ranh giới thẩm quyền quan trọng. Nêu rõ Business Owner/domain owner xác minh nhu cầu vận hành, Legal Owner xác minh nghĩa vụ pháp lý, Architect xác minh khả năng thiết kế; BA/Author chỉ duy trì traceability.; Nhánh đến Decision không phân biệt quyết định phân loại học liệu với quyết định vận hành Nova Foods. Bổ sung ranh giới này để tránh hàm ý BA/Author có quyền phê duyệt vận hành.; Luồng không thể hiện ngoại lệ pháp lý trọng yếu: phạm vi liên quan Luật An toàn thực phẩm phải giữ trạng thái cần xác minh pháp lý. Bổ sung điều kiện hoặc điểm kiểm soát trước khi coi kết quả là quyết định hợp lệ.
assets/diagrams/02-stakeholders-domain-and-context-004-5771001b.mmd — REVISE — Discovery exit thiếu problem statement, phạm vi ban đầu và nhãn Verification required cho claim chưa xác minh. Bổ sung các điều kiện này để khớp exit gate trong bảng.; Analysis exit ghi mơ hồ điểm xác minh liên kết và thiếu truy vết requirement về nguồn, ghi nhận mâu thuẫn, điều kiện làm assumption sai, cùng giới hạn không biến diễn giải pháp lý thành rule. Thay bằng điều kiện cụ thể trong bảng.; Delivery entry phạm vi phân tích đủ để xây dựng không thể hiện requirement đủ rõ và điểm chưa quyết định không bị che thành certainty. Sửa label để giữ cả hai điều kiện.; Testing exit kết quả test ghi nhận và sai lệch được phân loại thiếu trạng thái Pass, Fail hoặc Blocked và liên kết defect hoặc gap về requirement nguồn. Bổ sung outcome và traceability cụ thể.; Release exit thêm bằng chứng triển khai, khái niệm không được exit gate hỗ trợ trực tiếp, nhưng bỏ phạm vi phát hành, giới hạn đã biết và điểm theo dõi. Loại claim không được hỗ trợ; dùng đúng ba kết quả trong bảng.; Operations entry đổi người vận hành có thông tin thay đổi cần thiết thành hướng dẫn vận hành hiện có, làm hẹp và thay đổi điều kiện nguồn. Dùng wording được prose hỗ trợ.; Operations exit thiếu giới hạn quan trọng: phản hồi không tự trở thành requirement đã quyết định. Bổ sung condition này để vòng phản hồi không gây hiểu sai.
assets/diagrams/02-stakeholders-domain-and-context-006-1af88bf9.mmd — REVISE — Sơ đồ gộp Artifact nguồn và Canonical ID bền vững thành một đầu vào, trong khi bảng xác định bốn nhóm input riêng biệt. Cần thể hiện canonical ID như nhóm input độc lập hoặc làm rõ quan hệ của nó với artifact nguồn.; Nhãn BA đọc input quá mơ hồ và không phản ánh yêu cầu hợp nhất, kiểm kê, kiểm tra nguồn và gắn nhãn giả định trong phần văn bản. Cần dùng hành động cụ thể, đúng phạm vi được mô tả.; Nhãn kết quả trộn tiếng Việt với context, không nhất quán với thuật ngữ bối cảnh trong phần văn bản. Cần thống nhất thuật ngữ.; Sơ đồ gần như lặp lại danh sách đầu vào và kết luận traceability, nhưng bỏ mất quan hệ quan trọng: nhận định phải truy ngược về nguồn hoặc mang nhãn giả định. Cần thể hiện quan hệ này để sơ đồ có giá trị giải thích riêng.
assets/diagrams/02-stakeholders-domain-and-context-007-59d06040.mmd — REVISE — Gateway D chỉ kiểm tra có Version, ngày hiệu lực hoặc ngày truy cập; chưa kiểm tra nguồn còn hiệu lực và đủ mới cho kết luận. Cần bổ sung điều kiện về tính hiện hành.; Nhánh B -- Không dẫn thẳng đến STOP, bỏ sót cách xử lý nguồn chưa đủ evidence bằng Project assumption hoặc Verification required. Cần thể hiện trạng thái được phép nhưng không được dùng làm evidence.; Nhãn Nội dung vượt ranh giới pháp lý, kế toán, bảo mật hoặc vận hành? mơ hồ về ranh giới và chủ thể. Cần diễn đạt thành kết luận có vượt thẩm quyền của người đang sử dụng nguồn hay cần xác minh chuyên môn không.; Escalate đúng Owner không chỉ rõ ánh xạ Legal Owner, Accounting Owner, Security, Architect hoặc Business Owner như phần prose yêu cầu. Cần nêu Owner theo loại nội dung hoặc làm rõ tiêu chí chọn Owner.; Sơ đồ không thể hiện rủi ro dùng dữ liệu mô phỏng như dữ liệu vận hành thật, dù đây là ranh giới quyết định quan trọng trong section. Cần thêm kiểm tra hoặc outcome ngăn dữ liệu mô phỏng trở thành evidence vận hành.
assets/diagrams/02-stakeholders-domain-and-context-008-30689984.mmd — REVISE — Diagram omits Missing controlled input, despite stakeholder list and current-state process being explicit input categories. Add this source category and show it entering BA input inventory without being treated as verified evidence.; Do not convert into ERP rule narrows stated restriction. Prose also prohibits using unverified information as ERP configuration, legal conclusion, or operational decision. Expand outcome to cover all four prohibited uses.; Verification required items is ambiguous because verification is status applied across several source categories, not separate source type. Show verification as status or gate on inventory items.; Stakeholder and domain context implies direct usable outcome without showing verification boundary. Distinguish recorded context from claims approved for requirements or decisions.
assets/diagrams/02-stakeholders-domain-and-context-009-26672320.mmd — REVISE — Nút I thêm Accounting dù section không xác định Accounting là authority. Xóa Accounting hoặc bổ sung bằng chứng trong prose.; Nút K gán trạng thái IN_REVIEW cho controlled handoff, trong khi section chỉ gán trạng thái này cho controlled planning artifacts. Đổi outcome để trạng thái áp dụng rõ cho artifact.; Nút H dùng nhãn mơ hồ Owner chuyên môn. Nêu Domain Owner, Legal Owner, Architect hoặc Security theo phạm vi review.
assets/diagrams/02-stakeholders-domain-and-context-010-e9b770ac.mmd — REVISE — Nhánh Không đạt hoặc thiếu bằng chứng dẫn đến trạng thái Giữ kiểm tra chưa được phần văn xuôi xác lập; cần bổ sung bằng chứng trong văn xuôi hoặc bỏ nhánh khỏi sơ đồ.; Luồng H --> D --> Q gán Business Owner, QA Manager và Warehouse Manager cùng làm rõ rồi trả hồ sơ về QA, nhưng phần văn xuôi chỉ nêu thẩm quyền từng vai trò và điều kiện escalation, không quy định quy trình xử lý này; cần căn chỉnh với quyền quyết định và đường escalation đã nêu.; Nhãn Làm rõ quyết định mơ hồ, không cho biết quyết định gì, ai quyết định và tiêu chí kết thúc; cần dùng kết quả nghiệp vụ cụ thể được phần văn xuôi hỗ trợ.
assets/diagrams/02-stakeholders-domain-and-context-011-72354386.mmd — REVISE — Nút Stakeholder và bằng chứng mô phỏng trộn actor với evidence và không xác định artifact nguồn cụ thể. Tách hoặc đổi nhãn để chỉ rõ nguồn liên kết được section hỗ trợ.; Các mũi tên không ghi quan hệ nên có thể bị hiểu là luồng xử lý hoặc phụ thuộc tạo approval. Gắn nhãn quan hệ như liên kết tới để khớp tuyên bố rằng liên kết không tạo baseline hay approval.; Hai liên kết tới DECISION_LOG chưa được prose giải thích rõ như các liên kết tới registry và catalog canonical. Bổ sung diễn giải quanh sơ đồ hoặc bỏ liên kết nếu section không xác lập quan hệ này.
assets/diagrams/02-stakeholders-domain-and-context-012-41fa715c.mmd — REVISE — Sơ đồ biến anatomy thành chuỗi tuyến tính nhưng bỏ qua Mục tiêu và Phạm vi, nên không thể hiện ranh giới chi phối Fact, Hiện trạng, Nhu cầu gốc và Lựa chọn. Cần thể hiện Mục tiêu và Phạm vi cùng quan hệ kiểm soát chuỗi phân tích.; Nút "Fact và nguồn" bỏ mất phân loại căn cứ bắt buộc: primary, assumption, Verification required. Cần thể hiện phân loại này để không đánh đồng bằng chứng với giả định.; Sơ đồ bỏ Stakeholder và Thẩm quyền, dù phần prose yêu cầu phân biệt người bị ảnh hưởng, người có quyền quyết định và các owner xác nhận. Cần thể hiện vai trò review/xác nhận quanh Quyết định đề xuất.; Sơ đồ bỏ Hệ quả sai, nên không truyền tải rủi ro và mức ưu tiên review. Cần thể hiện hệ quả hoặc quan hệ của nó với bước review quyết định.; Nút "Traceability tới artifact canonical" chỉ phản ánh một phần mục Liên kết; thiếu ID canonical, tệp nguồn canonical và phạm vi liên kết. Cần dùng nhãn cụ thể bao quát đủ ba thành phần.; Mũi tên từ "Quyết định đề xuất" thẳng tới traceability có thể khiến người đọc hiểu đề xuất đã thành quyết định có hiệu lực. Cần thể hiện bước xác nhận của owner có thẩm quyền hoặc phân biệt rõ đề xuất với quyết định đã xác nhận.
assets/diagrams/02-stakeholders-domain-and-context-013-c5bb99e5.mmd — REVISE — Chuyển tiếp Ready_for_Downstream_Review --> [*] không có nhãn, dễ bị hiểu là hoàn tất, phê duyệt hoặc chấp thuận. Gắn sự kiện cụ thể thể hiện artifact rời phạm vi gate để đi vào downstream review, không hàm ý approval.; Nhánh sau downstream review chỉ nêu trường hợp reviewer phát hiện lỗi; kết quả khi reviewer không phát hiện lỗi nằm ngoài phạm vi gate nhưng chưa được thể hiện rõ. Xác định rõ ranh giới sơ đồ tại thời điểm bàn giao để tránh biến trạng thái sẵn sàng thành kết quả review.
assets/diagrams/02-stakeholders-domain-and-context-014-344cba85.mmd — REVISE — "BA outputs" assigns source ownership to BA, conflicting with prose stating outputs are not exclusively for BA. Replace concept with role-neutral shared artifacts or corpus.; Unlabeled arrows hide which artifacts each consumer uses. Show concrete artifact-to-consumer relationships or remove diagram.; Outcome labels are vague and omit concrete results listed in table, including API contracts, test scenarios, architecture decisions, release plans, runbook drafts, and specialist findings.; Diagram omits critical constraints: Developers cannot derive business rules from stakeholder map, QA cannot treat context diagram as complete test cases, and specialist ownership is required for canonical rules.; Diagram duplicates table structure while removing artifact, usage, ownership, and limitation details. It adds no explanatory relationship beyond one source feeding seven consumers.
assets/diagrams/02-stakeholders-domain-and-context-015-6ae90c7c.mmd — REVISE — Nút "Người tiêu thụ" gộp bảy vai trò có thẩm quyền và điều kiện escalation khác nhau, làm mất ranh giới quyết định; cần thể hiện hoặc tham chiếu rõ các nhóm vai trò và thẩm quyền tương ứng.; Nhánh từ "Người tiêu thụ" sang "Quyết định trong thẩm quyền" và "Điểm mơ hồ hoặc rủi ro" thiếu điều kiện phân nhánh; cần ghi rõ quyết định trực tiếp khi đủ bằng chứng và đúng thẩm quyền, escalation khi gặp điều kiện trong bảng.; Nút "Owner chuyên môn phù hợp" mơ hồ và hẹp hơn bảng: nơi nhận escalation có thể là Business Owner, Architect, PM/Product Owner hoặc specialist owner tùy vấn đề; cần dùng nhãn bao quát chủ thể có thẩm quyền phù hợp.; Nhánh "Quyết định trong thẩm quyền" kết thúc mà không cho biết quyết định được ghi nhận hoặc trả về BA, trong khi nhánh escalation có vòng phản hồi; cần làm rõ kết quả và cơ chế ghi nhận nhất quán.; Sơ đồ có thể khiến người đọc hiểu Nova Foods đã có quyết định hoặc xác minh được ghi nhận, trái trạng thái corpus IN_REVIEW và việc chưa có baseline hay phê duyệt; cần phân biệt quy trình mục tiêu với trạng thái hiện tại.
assets/diagrams/02-stakeholders-domain-and-context-016-35769f3f.mmd — REVISE — Gateway "Có nguồn canonical và thẩm quyền?" gộp hai điều kiện khác nhau; phần văn xuôi chỉ yêu cầu kiểm tra nguồn canonical có trả lời trực tiếp hay không. Đổi điều kiện để phản ánh đúng tiêu chí này.; Nhánh "Không" dẫn tới "Escalation đúng owner" bổ sung bước và vai trò không được phần văn xuôi xác lập. Loại bỏ bước này hoặc bổ sung căn cứ rõ trong nội dung nguồn.; Sơ đồ không thể hiện BA là người ghi câu hỏi khi nguồn không trả lời trực tiếp. Gắn actor BA với bước này.; Nhánh "Có" dừng tại "Diễn giải theo nguồn", còn bước ghi kết quả vào artifact chỉ nằm sau nhánh làm rõ. Làm rõ kết quả của cả hai nhánh và đường quay về artifact nếu đó là quy trình dự kiến.; Nhãn "Có nguồn canonical và thẩm quyền?" và "Escalation đúng owner" mơ hồ, không nêu nguồn nào, thẩm quyền của ai hoặc owner nào. Dùng nhãn cụ thể, được phần văn xuôi hỗ trợ.; Sơ đồ chưa thể hiện ranh giới quan trọng: trạng thái IN_REVIEW không phải quyết định đã được xác nhận. Bổ sung điều kiện hoặc kết quả ngăn người nhận coi artifact là quyết định xác nhận.
assets/diagrams/02-stakeholders-domain-and-context-017-53ab7a8a.mmd — REVISE — Luồng D → E kết thúc tại “Trả lời qua chat” nhưng không quay về Nhân viên Kinh doanh; cần thể hiện Kho trả lời cho Nhân viên Kinh doanh trước khi người này thông báo miệng cho khách hàng.; Nhánh B → F khiến thông báo “có thể giao đủ” độc lập với phản hồi tồn kho, trái mô tả trình tự hiện tại; cần nối quyết định thông báo với phản hồi 1.000 chai mà nhân viên Kinh doanh nhận được.; Cạnh G -.-> F ngụ ý lịch sản xuất riêng tác động trực tiếp đến cam kết giao đủ, trong khi phần prose chỉ nói Kho phải hỏi Điều độ sản xuất khi thiếu hàng và chưa xác nhận việc hỏi đã xảy ra trong tình huống này; cần bỏ hàm ý trực tiếp hoặc thể hiện đúng ranh giới, chủ thể và trạng thái chưa đối chiếu.; Sơ đồ bỏ qua điểm thiếu 200 chai và bước Kho hỏi Điều độ sản xuất khi thiếu hàng; cần thể hiện nhánh thiếu hàng cùng phụ thuộc thủ công này nếu mục tiêu là mô tả đầy đủ Current Behavior.; Nhãn “Trả lời qua chat” thiếu chủ thể và nội dung; cần dùng nhãn cụ thể, chủ động, nêu Kho trả lời tồn khả dụng 1.000 chai cho Nhân viên Kinh doanh.
assets/diagrams/02-stakeholders-domain-and-context-018-f2021322.mmd — REVISE — Nhánh “Không” kết thúc tại “Loại lô khỏi cấp phát”, không quay lại kiểm tra lô còn lại. Cần thể hiện tiếp tục duyệt các lô để tránh ngụ ý toàn bộ cấp phát dừng khi gặp một lô không hợp lệ.; Luồng chỉ thể hiện cấp phát toàn bộ 900 gói từ một lô. Quy tắc prose yêu cầu cấp phát theo số lượng cần giao và có thể cần nhiều lô. Cần thể hiện cấp phát lần lượt theo thứ tự FEFO đến khi đủ số lượng hoặc báo thiếu tồn khả dụng.; Nhánh đổi lô kết thúc tại “Chuyển ngoại lệ cho Warehouse Manager”, không thể hiện kết quả chấp thuận hoặc từ chối và trạng thái cấp phát tương ứng. Cần thêm quyết định của Warehouse Manager; không được ngụ ý nhập override_reason đồng nghĩa ngoại lệ được chấp thuận.; Gateway “Người dùng đổi lô?” thiếu điều kiện quan trọng “trong khi lô FEFO vẫn đủ điều kiện”. Cần ghi rõ điều kiện này để khớp BR-PROP-FEFO-01 và tránh áp dụng luồng ngoại lệ cho trường hợp lô đề xuất đã mất hiệu lực.
assets/diagrams/02-stakeholders-domain-and-context-019-db4302eb.mmd — REVISE — Sơ đồ trộn ba chiều trạng thái độc lập thành một chuỗi: inventoryStatus (QUALITY_HOLD), qcReleaseStatus (PENDING_REVIEW, RELEASED, REJECTED) và trạng thái thực hiện giao hàng (ALLOCATABLE, SHIPPED). Payload cho thấy QUALITY_HOLD và PENDING_REVIEW tồn tại đồng thời, không phải trạng thái chuyển tiếp. Cần tách rõ từng chiều trạng thái hoặc thể hiện quan hệ điều kiện giữa chúng.; Chuyển tiếp [*] --> QUALITY_HOLD: Hoàn thành MO-NF-20260806-014 không được quy tắc hỗ trợ. BR-NF-08-002 chỉ yêu cầu QUALITY_HOLD khi qcReleaseStatus = PENDING_REVIEW; không quy định hoàn thành MO tự động tạo hold. Cần gắn QUALITY_HOLD với điều kiện PENDING_REVIEW hoặc bỏ quan hệ nhân quả chưa xác nhận.; Chuyển tiếp QUALITY_HOLD --> PENDING_REVIEW: Tạo QC-NF-20260807-009 mâu thuẫn mô hình dữ liệu hiện trạng: QUALITY_HOLD và PENDING_REVIEW là giá trị của hai trường khác nhau và cùng xuất hiện trong payload. Cần biểu diễn chúng đồng thời, không nối như trạng thái trước–sau.; ALLOCATABLE và BLOCKED không xuất hiện trong payload, bảng quy tắc hoặc kết luận dưới dạng trạng thái hệ thống đã xác định. Phần prose chỉ nói cho phép hoặc cấm hành động. Cần dùng chúng như kết quả/quyền hành động, hoặc ghi rõ đây là trạng thái đề xuất cần xác nhận.; Sơ đồ bỏ nhánh kiểm soát trọng tâm: yêu cầu xác nhận xuất khi qcReleaseStatus != RELEASED phải bị chặn. Cần thể hiện điều kiện gateway/guard và kết quả từ chối xác nhận xuất, gồm trường hợp hiện tại PENDING_REVIEW.; Nhãn QA Manager kết luận đạt/không đạt chưa liên kết cụ thể với ROLE-NF-QA-MANAGER, còn quyền này mới là khuyến nghị IN_REVIEW, chưa được phê duyệt. Cần dùng ID vai trò và đánh dấu ranh giới giả định/khuyến nghị để tránh diễn đạt như quyết định đã có hiệu lực.; Nhánh REJECTED --> BLOCKED không đủ bao quát quy tắc: PENDING_REVIEW cũng phải bị chặn phân bổ và xuất. Cần thể hiện cả hai kết quả không đủ điều kiện, đồng thời phân biệt QUALITY_HOLD với kết luận không đạt.
assets/diagrams/02-stakeholders-domain-and-context-020-9fb0b593.mmd — REVISE — Các cạnh SM --> CA --> CM --> H thể hiện chuỗi phụ thuộc tuần tự, trong khi bảng xác định 00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE và CHAPTER_MANIFEST đều là dependency upstream mà chapter dùng trực tiếp. Sửa hướng liên kết để phản ánh đúng dependency trực tiếp, hoặc bổ sung bằng chứng cho chuỗi phụ thuộc.; Nhãn Section 9 không được prose hoặc bảng xác nhận. Xóa nhãn này hoặc dùng tên section canonical đã được nguồn hỗ trợ.; Nhãn Artifact downstream quá chung và số ít, trong khi bảng nêu nhiều loại: artifact phân tích, template hoàn chỉnh và test artifact tương lai. Dùng nhãn bao quát đúng phạm vi hoặc tách nhóm nếu quan hệ khác nhau.; Nhãn Nguồn và boundary pha ngôn ngữ và không nêu rõ safe use boundary. Dùng wording cụ thể, song song với bảng.
assets/diagrams/02-stakeholders-domain-and-context-021-ee2034e6.mmd — REVISE — API-NF-001 is not established as canonical artifact or approved traceability ID in section. Remove API node and edges unless prose explicitly defines ID and relationships.; R --> P --> T conflicts with stated data risk: prose says API fields must belong to DATA-NF-001, but diagram shows no DATA-NF-001 dependency on API. Add supported data-to-API relationship only after prose defines it.; BR-NF-001 --> AC-NF-001 is not explicitly supported. Section states REQ-NF-001 references business rule and TC-NF-001 checks acceptance criterion, but does not state acceptance criterion derives from business rule. Clarify prose or correct relationship.; Diagram omits ownership and review boundary despite section naming maintaining and confirming authorities and stating no approval is inferred. Add boundary or ownership only if diagram intends to represent governance; otherwise narrow diagram scope explicitly in prose.
assets/diagrams/02-stakeholders-domain-and-context-022-2397477d.mmd — REVISE — Nhánh kiểm soát bỏ sót thông báo cho owner artifact phụ thuộc, dù prose xác định đây là dấu hiệu phân biệt thay đổi im lặng. Cần thể hiện bước thông báo owner hoặc gắn trách nhiệm này vào bước xử lý artifact bị ảnh hưởng.; Nhãn “Review theo thẩm quyền” không chỉ rõ ai review hoặc thẩm quyền nào, trong khi actor quan trọng cho kiểm soát thay đổi. Cần nêu owner hoặc vai trò phê duyệt được section hỗ trợ.; Kết quả “Lỗi build, test sai, vận hành sai” vượt quá prose: section chỉ nêu mâu thuẫn giữa nguồn canonical mới và artifact phụ thuộc cũ; không xác lập lỗi build hay lỗi vận hành. Cần giới hạn outcome vào mâu thuẫn semantic, requirement/API/test case lỗi thời, hoặc bổ sung prose hỗ trợ các hậu quả này.; “Đăng version và lịch sử thay đổi” thiếu song song về hành động và không tự nhiên. Cần dùng hai động từ cụ thể, như “Tạo version và ghi lịch sử thay đổi”.
assets/diagrams/02-stakeholders-domain-and-context-023-494aa063.mmd — REVISE — Gateway “Có đủ điều kiện kiểm chứng?” quá rộng, không phản ánh các tiêu chí cụ thể trong bảng: nguồn canonical, dependency, tiêu chí đo, acceptance criteria, luồng ngoại lệ, trạng thái approval và bằng chứng thẩm quyền. Cần nêu điều kiện quyết định cụ thể hoặc giới hạn rõ phạm vi gateway.; Nhánh “Có” kết thúc tại “Giữ requirement và liên kết test basis”, nhưng requirement hợp lệ vẫn có thể cần dependency, nguồn canonical, acceptance criteria và cập nhật artifact liên quan. Cần thể hiện kết quả đầy đủ hoặc không mô tả đây như quy trình chung.; Nhánh “Không” gộp “Viết lại” với “gắn Verification required” dù hai hành động áp dụng cho lỗi khác nhau: requirement không đo được cần viết lại; assumption chưa xác minh cần gắn trạng thái và chuyển Legal hoặc Accounting Owner. Cần tách theo loại thiếu sót.; “Chuyển đúng owner quyết định” mơ hồ và bỏ mất owner cụ thể duy nhất được section hỗ trợ là Legal hoặc Accounting Owner cho assumption cần xác minh. Cần gọi đúng vai trò hoặc tránh khái quát thành bước bắt buộc cho mọi lỗi.; Chuỗi E → F → G biến mọi trường hợp không đủ điều kiện thành cùng một quy trình, không được bảng hỗ trợ. Nhiều lỗi có hành động sửa riêng như tách requirement, bổ sung luồng lỗi, giữ IN_REVIEW, hoặc tham chiếu ID và phiên bản. Cần tránh áp đặt trình tự phổ quát.; Sơ đồ bỏ ranh giới trạng thái review/approval và rủi ro dùng tài liệu IN_REVIEW để cấu hình ERP, quyết định kế toán hoặc xác nhận pháp lý. Vì section nhấn mạnh đây là cảnh báo trọng yếu, cần thể hiện điểm chặn hoặc giới hạn sử dụng nếu sơ đồ nhằm mô tả quy trình xử lý chung.
assets/diagrams/02-stakeholders-domain-and-context-024-e3e69da7.mmd — REVISE — Gateway B thêm rủi ro “lộ dữ liệu” nhưng phần prose không nêu rủi ro này. Xóa điều kiện đó hoặc bổ sung căn cứ trong prose.; Bước F dùng “Business Owner, Accounting Owner, Architect hoặc QA”, khiến một bên bất kỳ có thể được hiểu là đủ thẩm quyền. Phải thể hiện phân công riêng: Business Owner xác nhận chính sách, Accounting Owner xác nhận tác động chứng từ, Architect xác nhận thiết kế tích hợp, QA xác nhận test basis.; Gateway G hỏi chung “Có quyết định được ghi nhận?” nhưng không kiểm tra đủ xác nhận theo thẩm quyền, điều kiện tồn kho và điều kiện chứng từ. Sửa gateway để yêu cầu các xác minh áp dụng đã được ghi nhận trước khi bỏ chặn.; Nhánh G -- Có dẫn tới “Cập nhật traceability rồi kiểm tra lại” nhưng không nêu kết quả kiểm tra lại hoặc điều kiện gỡ chặn. Thêm outcome rõ: tiếp tục chặn nếu chưa đạt; chỉ cho phép cấu hình hoặc test phát hành khi đủ xác minh.; Bước E “Lưu artifact, log và nguồn” mơ hồ về trạng thái bắt buộc. Cần nêu artifact giữ giả định ở IN_REVIEW và liên kết nguồn quyết định/canonical rule/traceability thay vì ngụ ý đã có business rule hợp lệ.
assets/diagrams/02-stakeholders-domain-and-context-025-16a38f23.mmd — REVISE — Nhãn "Business Owner + Food-safety Owner xác minh nội dung" gộp hai thẩm quyền khác nhau. Cần tách Business Owner xác nhận chính sách xuất kho và Food-safety Owner xác nhận tiêu chí hạn dùng.; Nút "Acceptance criteria chưa được tạo thành rule đã phê duyệt" mơ hồ và trộn acceptance criteria với business rule. Cần nêu acceptance criteria chưa được tạo và rule chưa được phê duyệt như hai trạng thái riêng.; Sơ đồ không thể hiện các câu hỏi quyết định còn mở: ngày xuất dự kiến, cách xác định "còn hạn", manager có thẩm quyền và hành vi khi không còn lô hợp lệ. Cần biểu diễn chúng như nội dung phải xác minh, không phải rule đã xác nhận.; Sơ đồ không thể hiện thiếu baseline reference và approval reference. Cần ghi rõ hai tham chiếu chưa tồn tại để tránh diễn giải trạng thái IN_REVIEW thành đã được phê duyệt.; Vai trò BA trong duy trì liên kết và trạng thái bị bỏ qua. Cần thể hiện BA quản lý truy vết nhưng không phê duyệt nội dung.; Đường R đến B không làm rõ quan hệ giữa requirement và nguồn canonical. Cần đặt nhãn quan hệ cụ thể để tránh hiểu rằng requirement tự tạo hoặc phê duyệt canonical rule.
assets/diagrams/02-stakeholders-domain-and-context-026-65f46853.mmd — REVISE — Luồng chọn template, điền dữ liệu, kiểm tra và chuyển artifact sang IN_REVIEW không được phần văn xuôi xác nhận; cần bổ sung căn cứ trong văn xuôi hoặc loại bỏ các bước và trạng thái không có căn cứ.; TEMPLATE_MANIFEST chỉ lập kế hoạch template, không chứng minh template đã được tạo; nhãn Chọn template đã đăng ký và bước tạo artifact có thể khiến người đọc hiểu template đã tồn tại. Cần thể hiện rõ ranh giới giữa mục đăng ký trong manifest và template thực tế.; Không có actor cho các hành động chọn, điền và kiểm tra; cần nêu owner thực hiện từng bước nếu quy trình này có căn cứ.; Kiểm tra owner, consumer, quality gate mơ hồ: không nêu đối tượng kiểm tra, tiêu chí đạt hoặc kết quả khi không đạt. Cần dùng nhãn cụ thể và thể hiện nhánh thất bại nếu quality gate quyết định trạng thái.; Artifact IN_REVIEW là trạng thái và kết quả không được định nghĩa trong phần văn xuôi; cần xác nhận điều kiện chuyển trạng thái, owner và ý nghĩa hoặc bỏ trạng thái này.
assets/diagrams/02-stakeholders-domain-and-context-027-7c26322b.mmd — REVISE — Nhãn “Đối chiếu metadata” thu hẹp sai phạm vi: prose yêu cầu kiểm tra ID, trạng thái, version, đường dẫn và giới hạn thẩm quyền, không chỉ metadata. Cần dùng nhãn bao quát đủ các tiêu chí này.; Gateway “Mâu thuẫn hoặc cần thẩm quyền?” gộp hai điều kiện khác loại và không nêu tiêu chí quyết định. Cần tách hoặc diễn đạt rõ trường hợp có mâu thuẫn và trường hợp vượt giới hạn thẩm quyền.; “Handoff chapter kèm bằng chứng review” là bước và đầu ra chưa được prose xác lập. Cần bỏ hoặc bổ sung căn cứ trong prose.; “Escalation đúng owner” đưa vào quy trình escalation và owner chưa được section xác định. Cần bỏ hoặc bổ sung owner, điều kiện escalation và điểm tiếp nhận trong prose.; Diagram không thể hiện rủi ro trọng yếu được prose nêu: coi IN_REVIEW là đã phê duyệt, đổi tên artifact canonical, và biến dữ liệu Nova Foods mô phỏng thành quy tắc thật. Cần thể hiện các ngoại lệ này hoặc một bước kiểm tra phân loại bao quát rõ chúng.; Các nhánh chỉ nêu tên nguồn nhưng không cho biết nguồn nào kiểm tra ID, trạng thái, version, đường dẫn hay thẩm quyền. Cần làm rõ quan hệ giữa tiêu chí và nguồn đối chiếu để luồng có giá trị kiểm tra thực tế.
assets/diagrams/03-discovery-interviewing-and-note-taking-001-5ee029d0.mmd — REVISE — Luồng bỏ qua bước BA kiểm tra cách hiểu với người cung cấp thông tin; thêm bước xác nhận trước khi ghi nhận đầu vào phân tích.; Luồng tuyến tính kết thúc tại phân tích nhưng không thể hiện câu hỏi và giả định cần xác minh bằng hỏi tiếp hoặc đối chiếu nguồn khác; thêm vòng xác minh về trao đổi khám phá.; Nhãn “Phân biệt fact, giả định, câu hỏi” mô tả thao tác nhưng chưa thể hiện ba trạng thái phải được tách rõ trong ghi chú; sửa nhãn để gắn việc phân loại với ghi chú có cấu trúc.
assets/diagrams/03-discovery-interviewing-and-note-taking-002-cb56e930.mmd — REVISE — Cạnh D -->|thiếu trạng thái trên màn hình| KT khiến đơn hàng có vẻ chủ động chuyển việc sang Kế toán. Sửa quan hệ để Nhân viên Kho là actor gọi Kế toán vì màn hình đơn thiếu trạng thái.; Luồng hiện tại bỏ bước chờ trả lời, dù đây là khó khăn và bằng chứng chính cho underlying need. Bổ sung trạng thái chờ giữa lúc Kho hỏi và Kế toán trả lời.; Nhãn trả lời trạng thái mơ hồ. Đổi thành trạng thái nghiệp vụ cụ thể như được phép xuất hoặc không được phép xuất, nhưng không thêm quy tắc quyết định chưa được xác minh.
assets/diagrams/03-discovery-interviewing-and-note-taking-003-055ed4d6.mmd — REVISE — Nhãn “Quyết định xuất hoặc giữ” gán hàm ý quyền quyết định cho Nhân viên Kho, trong khi prose chỉ nói Kho hành động theo câu trả lời của Kế toán và quyết định giải pháp vẫn chưa có. Cần thể hiện rõ câu trả lời của Kế toán là đầu vào, đồng thời phân biệt hành động vận hành với quyết định về requirement.; Hai luồng đang tách rời nên không cho thấy ghi chú discovery bắt nguồn từ tình huống SO-SIM-001. Cần nối tình huống quan sát với bước ghi nhận và xác minh.; “Requirement hoặc decision sau xác minh” mơ hồ về nội dung, điều kiện và chủ thể xác minh. Cần dùng nhãn cụ thể, song song ngôn ngữ, đồng thời thể hiện Business Owner, Accounting Owner và Architect theo thẩm quyền nêu trong bảng.; Sơ đồ bỏ qua trạng thái quan trọng “Chưa quyết định”, dễ khiến người đọc hiểu rằng discovery tất yếu tạo requirement hoặc decision. Cần thể hiện đây là kết quả khả dĩ sau xác minh, không phải kết quả đã đạt.; Sơ đồ không thể hiện ràng buộc phân quyền và không lộ thông tin nhạy cảm, dù đây là tiêu chí quyết định và ranh giới quan trọng của cách hiển thị. Cần đưa ràng buộc này vào luồng xác minh hoặc kết quả.
assets/diagrams/03-discovery-interviewing-and-note-taking-004-1dc7ec1a.mmd — REVISE — Nhánh “Thiếu hàng” dẫn tới “Chuyển quyết định xử lý thiếu hàng” không được phần văn bản xác lập như một bước vận hành và không nêu người nhận quyết định. Cần thay bằng trạng thái hoặc hành động đã được xác nhận trong nội dung, hoặc ghi rõ đây là điểm chưa quyết định cần Business Owner xác nhận.; Nút “Kho phản hồi tồn khả dụng?” trộn hai tiêu chí: trạng thái phản hồi (“Chưa phản hồi”) và kết quả tồn (“Đủ hàng”, “Thiếu hàng”). Cần dùng các điều kiện cùng cấp, cụ thể và loại trừ nhau.
assets/diagrams/03-discovery-interviewing-and-note-taking-005-4986ad99.mmd — REVISE — Project assumption không xuất hiện trong phần văn xuôi; xóa nhánh này hoặc bổ sung cơ sở nội dung ngoài sơ đồ.; Điều kiện Có nguồn kiểm tra được? chưa đủ để kết luận Fact đã xác minh; nguồn phải canonical, có ID, trạng thái đọc được và nội dung đã được đối chiếu.; Đã chọn phương án bởi authority? mơ hồ và gộp sai thẩm quyền; Business Owner quyết định vận hành, Accounting Owner xác nhận tác động sổ sách, Architect xác nhận cơ chế hệ thống.; Luồng cho phép Verification-required claim đi thẳng tới Decision, bỏ qua bước xác minh cần thiết và có thể biến nội dung chưa kiểm chứng thành quyết định.; Sơ đồ bỏ sót kết quả quan trọng của case: chưa có quyết định và không được ghi stakeholder input thành business rule trong CANONICAL_BUSINESS_RULES.
assets/diagrams/03-discovery-interviewing-and-note-taking-006-ecbd3548.mmd — REVISE — Luồng Discovery → Analysis ngụ ý mọi ghi chú đã phân loại đều chuyển thành đầu vào phân tích. Phần văn bản yêu cầu nội dung phải đủ nguồn và đủ thẩm quyền; assumption và verification required phải còn được nhìn thấy. Nhãn chuyển tiếp cần thể hiện gateway này.; Nhãn “traceability đủ” không cụ thể và yếu hơn exit gate trong bảng. Cần nêu requirement và acceptance criteria liên kết về nguồn, còn mâu thuẫn được ghi nhận.; Exit Delivery dùng “build/deployable” nhưng bảng yêu cầu thay đổi xây dựng liên kết với requirement và chênh lệch được ghi nhận. Cần dùng điều kiện exit được hỗ trợ trực tiếp, không thêm trạng thái deployable chưa được định nghĩa.; Exit Release nêu “hướng dẫn vận hành có mặt”, trong khi exit gate của bảng yêu cầu gói phát hành có truy vết và nội dung chưa xác minh giữ nhãn. Cần thay bằng điều kiện tương ứng hoặc bổ sung cơ sở trong prose.
assets/diagrams/03-discovery-interviewing-and-note-taking-007-9604146e.mmd — REVISE — Nút upstream chỉ nêu Business Owner, trong khi bảng quy định Business Owner hoặc Process Owner. Cần thể hiện cả Process Owner.; Sơ đồ bỏ sót cơ chế bàn giao có kiểm soát: người gửi nêu факт, nguồn, điểm chưa rõ và câu hỏi; người nhận xác nhận phạm vi xử lý. Cần thể hiện nội dung bàn giao và bước xác nhận.; Nhãn "xung đột hoặc vượt quyền" thêm điều kiện "xung đột" không được phần văn bản hoặc bảng xác lập. Cần bỏ điều kiện này hoặc bổ sung căn cứ trong prose.; Nút "đúng owner có thẩm quyền" mơ hồ, không chỉ rõ owner quyết định theo loại vấn đề. Cần gắn escalation với owner có thẩm quyền tương ứng hoặc mô tả quy tắc định tuyến cụ thể.
assets/diagrams/03-discovery-interviewing-and-note-taking-008-c8532949.mmd — REVISE — Hai cặp D→A và O→D xuất hiện bằng cả mũi tên liền lẫn nét đứt, làm mờ khác biệt giữa dòng chính và vòng phản hồi. Giữ một loại mũi tên cho mỗi quan hệ hoặc đổi đích/điều kiện để mỗi mũi tên biểu thị luồng riêng.; Nhãn “lỗi hoặc thiếu test basis” trên T→A gom mọi lỗi kiểm thử về Analysis, trong khi lỗi có thể thuộc Delivery và đoạn văn chỉ yêu cầu đối chiếu bằng chứng trước khi kết luận. Thu hẹp điều kiện về Analysis hoặc thể hiện bước phân loại lỗi trước khi quay lại pha phù hợp.; Nhãn “ghi chú mơ hồ hoặc nhu cầu mới” trên D→A không khớp hoàn toàn với ý nghĩa vòng phản hồi: ghi chú mơ hồ chưa đủ điều kiện chuyển sang Analysis, còn nhu cầu mới thiếu nguồn phát sinh. Làm rõ điều kiện và hướng quay về pha tạo bằng chứng.
assets/diagrams/03-discovery-interviewing-and-note-taking-009-784a5207.mmd — REVISE — Nhãn "Bằng chứng nguồn" nhập nhằng giữa bằng chứng và artifact nguồn, trong khi phần văn xuôi phân biệt rõ hai khái niệm. Cần thể hiện riêng "Bằng chứng" và "Artifact nguồn (tệp hoặc URL)" hoặc dùng nhãn không xóa ranh giới này.; Nhãn "Canonical ID và đường dẫn" thu hẹp artifact nguồn thành đường dẫn, bỏ sót tệp không được biểu diễn bằng URL. Cần dùng thuật ngữ bao quát đúng phạm vi tệp hoặc URL.
assets/diagrams/03-discovery-interviewing-and-note-taking-010-29d0c800.mmd — REVISE — Thiếu gateway kiểm tra ranh giới sử dụng. Bổ sung điều kiện không biến học liệu mô phỏng thành cấu hình ERP, nghĩa vụ pháp lý hoặc phê duyệt; nhánh không đạt phải giữ nhãn giả định hoặc Verification required.; Nhánh Escalate đúng vai trò kết thúc mà không thể hiện trạng thái sử dụng nội dung. Làm rõ nội dung chưa đủ điều kiện làm kết luận cho đến khi Owner đúng thẩm quyền xác nhận.
assets/diagrams/03-discovery-interviewing-and-note-taking-011-20209e8d.mmd — REVISE — Nhãn “Dùng trong safe use boundary” mơ hồ và không nêu giới hạn đã xác định. Cần ghi rõ primary source chỉ xác định thuật ngữ hoặc bối cảnh.; Nhánh synthetic thiếu điều kiện sử dụng quan trọng. Cần thể hiện bằng chứng synthetic chỉ kích hoạt câu hỏi làm rõ và giữ nhãn “Cần xác minh”, không trở thành fact vận hành.; Kết quả chung “Note phỏng vấn có truy vết” che mất ranh giới giữa fact có nguồn và điểm chưa xác minh. Cần thể hiện hai trạng thái note riêng hoặc điều kiện hợp nhất không làm mất nhãn.; Sơ đồ bỏ qua thẩm quyền xác minh kết luận chuyên môn. Cần thể hiện Legal Owner, Accounting Owner hoặc domain owner tại điểm xác minh, nếu sơ đồ mô tả luồng từ nguồn đến note hợp lệ.
assets/diagrams/03-discovery-interviewing-and-note-taking-012-48165720.mmd — REVISE — Nhánh Có gán trạng thái MATCHED, nhưng phần văn xuôi không xác lập trạng thái này. Xóa trạng thái hoặc dùng kết quả được phần văn xuôi hỗ trợ.; Nhánh Không bỏ qua điều kiện bắt buộc mã lý do và tham chiếu chứng từ trước khi chuyển xử lý. Bổ sung các bước này sau EXCEPTION.; Chuỗi Business Owner → Accounting Owner → Solution Architect → QA thể hiện thứ tự phê duyệt phụ thuộc, trong khi phần Authority chỉ phân công trách nhiệm, không quy định trình tự. Không biểu diễn chuỗi tuần tự nếu chưa có căn cứ.; Nhãn ERP mô phỏng đối chiếu hóa đơn: 480 kg khiến ERP thành tác nhân đối chiếu, nhưng phần Current Behavior nêu Kế toán tạm dừng đối chiếu. Điều chỉnh tác nhân hoặc bước để phản ánh đúng luồng được mô tả.; Sơ đồ không thể hiện trạng thái đề xuất IN_REVIEW, tính chất chưa canonical và ranh giới BA không thay thẩm quyền xác nhận. Bổ sung ranh giới này để tránh hiểu đề xuất là quy tắc đã phê duyệt.
assets/diagrams/03-discovery-interviewing-and-note-taking-013-9f9d1aa2.mmd — REVISE — Nút TRACEABILITY_ID_REGISTRY biểu diễn registry như artifact được tạo hoặc cập nhật, trong khi bảng xác định artifact là Mục truy vết phát hiện; cần đặt nhãn theo artifact và thể hiện registry chỉ cấp hoặc quản lý Canonical ID.; Sơ đồ không thể hiện trạng thái IN_REVIEW, khiến Downstream review thiếu điều kiện kiểm soát; cần cho thấy mọi artifact chỉ đi vào downstream review với trạng thái IN_REVIEW, không phải APPROVED hoặc BASELINED.; Luồng từ Biên bản phỏng vấn sang ba artifact làm mờ nghĩa vụ giữ bằng chứng nguồn; cần thể hiện mỗi artifact duy trì liên kết với bằng chứng phỏng vấn.; Sơ đồ bỏ qua ngoại lệ quan trọng: không tự đặt canonical ID khi TRACEABILITY_ID_REGISTRY chưa cấp; cần thể hiện ranh giới hoặc điều kiện này.; Sơ đồ bỏ qua owner duy trì, phiên bản, ngày cập nhật và lịch sử thay đổi—các kiểm soát bắt buộc của mọi artifact; cần thể hiện ít nhất ranh giới quản trị chung thay vì mô tả luồng tạo artifact đơn thuần.; Ba nhánh dùng nhãn không song song: một registry và hai canonical artifact; cần dùng tên artifact cùng cấp để tránh nhầm interface quản trị với output.
assets/diagrams/03-discovery-interviewing-and-note-taking-014-685673a7.mmd — REVISE — Thiếu Open Point dù đây là thành phần bắt buộc và nhánh xử lý nội dung chưa đủ bằng chứng; bổ sung Open Point và liên kết nó với bước xác minh hoặc review.; Candidate output mơ hồ, không tương ứng rõ với thành phần nào trong bảng; đổi nhãn thành artifact cụ thể được prose hỗ trợ hoặc thể hiện gói bằng chứng gồm Underlying Need và Open Point.; Luồng Interview facts → Current behavior → Underlying need làm Facts và Current Behavior trông như các trạng thái tuần tự, trong khi prose mô tả hai nhóm bằng chứng làm cơ sở cho Underlying Need; sửa quan hệ để cả Facts và Current Behavior cùng dẫn tới Underlying Need.; Sơ đồ chưa thể hiện yêu cầu tách quan sát khỏi diễn giải; bổ sung ranh giới hoặc quan hệ cụ thể để tránh ngụ ý mọi fact tự động trở thành mô tả hành vi hay nhu cầu.; Downstream review quá chung, không nêu kết quả kiểm tra được mô tả trong prose; dùng nhãn cụ thể thể hiện người sau kiểm tra nguồn, diễn giải, nhu cầu và điểm cần xác minh.
assets/diagrams/03-discovery-interviewing-and-note-taking-015-f8a0c559.mmd — REVISE — Nhãn QG-OUT-01 đến QG-OUT-06 không được định nghĩa trong section; thay bằng các điều kiện gate đã nêu: có nguồn discovery, phân biệt fact với nhu cầu suy ra, gắn Verification required và không gọi yêu cầu là đã phê duyệt.; Nhánh Đủ và Thiếu quá mơ hồ; nêu rõ đủ hoặc thiếu điều kiện gate nào.; QA và Accounting không có vai trò review được section xác lập; bỏ các actor này hoặc bổ sung căn cứ trong prose.; Business và Legal không khớp tên owner trong bảng; dùng Business Owner và Legal/Food-safety owner để giữ ownership chính xác.; Luồng kết thúc tại review nhưng không thể hiện kết quả review hoặc đường quay lại sau khi bổ sung evidence; thêm outcome và vòng phản hồi nếu section xác nhận các bước này.
assets/diagrams/03-discovery-interviewing-and-note-taking-016-6c6d9def.mmd — REVISE — Nhãn “Runbook view” không được phần văn xuôi hỗ trợ; Operations kiểm tra thao tác trong ca vận hành, không tạo hoặc xem runbook. Cần dùng kết quả được nêu trong phần văn xuôi.; Các nhãn “Build view”, “Test view”, “Architecture view”, “Scope view” và “Domain view” quá mơ hồ, không thể hiện hành động cụ thể của từng vai trò. Cần dùng cách diễn đạt cụ thể, song song với trách nhiệm trong bảng.; Nút “Discovery outputs” gộp sáu loại đầu ra, làm mất quan hệ khác nhau giữa từng artifact và từng vai trò được bảng mô tả. Cần thể hiện khác biệt có giá trị hoặc bỏ sơ đồ.; Sơ đồ gần như lặp lại đoạn văn liệt kê vai trò, nhưng không bổ sung luồng, ranh giới, phụ thuộc hoặc insight mới. Cần bổ sung giá trị giải thích thay vì chỉ đổi văn xuôi thành hình.; Metadata chung chỉ thể hiện IN_REVIEW, bỏ v0.9.0, ngày 2026-08-07 và giới hạn dữ liệu tổng hợp. Nếu nút đại diện trạng thái artifact, cần thể hiện đầy đủ metadata hoặc tránh ngụ ý đây là mô hình trạng thái hoàn chỉnh.
assets/diagrams/03-discovery-interviewing-and-note-taking-017-72e61716.mmd — REVISE — Gateway Consumer decision scope thiếu nhãn điều kiện trên hai nhánh; cần phân biệt rõ quyết định nằm trong thẩm quyền consumer với quyết định phải chuyển specialist hoặc owner.; Luồng Specialist or owner authority → Escalation record đồng nhất thẩm quyền chuyên môn với escalation; cần thể hiện specialist/owner có thể đưa ra quyết định, còn escalation chỉ phát sinh khi vượt quyền, có xung đột, hoặc gặp điều kiện escalation trong bảng.; Outcome Traceable requirement or risk bỏ sót quyết định đã được xác nhận; cần bao quát requirement, risk, hoặc decision có truy vết.; Nhãn Team-level decision mơ hồ về owner và không khớp các phạm vi quyết định khác nhau của Developer, QA, Architect, PM/Product Owner, Business Owner và Operations; cần dùng nhãn thể hiện quyết định trong phạm vi thẩm quyền consumer.; Sơ đồ không thể hiện trạng thái governance quan trọng: artifact vẫn IN_REVIEW, v0.9.0, chưa là baseline hay approval; cần tránh để luồng kết thúc bị hiểu là requirement đã được phê duyệt.
assets/diagrams/03-discovery-interviewing-and-note-taking-018-25aa6584.mmd — REVISE — Luồng A → B → C thể hiện việc tra bảng tính luôn xảy ra, trái với mô tả “nếu nhớ thực hiện bước này”. Cần biểu diễn điều kiện hoặc nhánh bỏ qua bước tra cứu trước khi xác nhận.; Các cạnh F → C và G → C ngụ ý dữ liệu công nợ và hạn mức đi vào bước xác nhận ERP, trong khi section khẳng định bảng tính không tích hợp và ERP không hiển thị các dữ liệu này. Cần thể hiện chúng chỉ được tra cứu thủ công tại B hoặc tách khỏi ERP.; Bước kho kiểm tra tồn kho bị bỏ khỏi D → E dù prose nêu rõ kho kiểm tra tồn kho rồi chuẩn bị hàng. Cần thêm bước kiểm tra hoặc đổi E thành nhãn bao gồm cả kiểm tra tồn kho và chuẩn bị hàng.; F và G tách công nợ với hạn mức thành hai nguồn trực quan dù cả hai nằm trong cùng bảng tính do Kế toán công nợ quản lý. Cần thể hiện cùng nguồn và tránh gây hiểu nhầm về hai giao diện hoặc hai hệ thống.
assets/diagrams/03-discovery-interviewing-and-note-taking-019-62041ca6.mmd — REVISE — Thiếu trạng thái PENDING_INSPECTION của 120 thùng trước khi tách 112 AVAILABLE và 8 QUARANTINED; bổ sung trạng thái này để thể hiện đúng O2 và phân biệt nhận vật lý với khả dụng.; Sơ đồ trình bày luồng như quy trình đã có hiệu lực, trong khi nội dung xác định đây là RECOMMENDED_NOT_AUTHORIZED, corpus IN_REVIEW và chưa có approval reference; bổ sung ranh giới hoặc nhãn thể hiện luồng đề xuất, chưa được phê duyệt.; Nhãn Được cấp phát mơ hồ về chủ thể và điều kiện; đổi thành kết quả cụ thể rằng hệ thống chỉ cho phép cấp phát số lượng ở trạng thái AVAILABLE sau khi Quality Owner RELEASE phần cách ly.; Nhánh RETURN và DISPOSE kết thúc mà không thể hiện ranh giới thẩm quyền liên quan; bổ sung Procurement Owner cho xử lý với nhà cung cấp sau RETURN và Accounting Owner cho xác nhận tác động chứng từ, giá trị, hạch toán khi áp dụng.; Sơ đồ không thể hiện điều kiện cấm cấp phát đối với QUARANTINED, dù đây là kiểm soát và rủi ro chính của phần; bổ sung điều kiện rằng 8 thùng không được cấp phát, dùng cho sản xuất hoặc chuyển kho trước khi Quality Owner đổi trạng thái.
assets/diagrams/03-discovery-interviewing-and-note-taking-020-596eabe7.mmd — REVISE — Nhánh A --> D mô tả việc ghi sổ song song với lưu ERP, trái với fact rằng thủ kho lưu phiếu trước rồi mới ghi 35 kg bao rách. Sửa quan hệ thành B --> D để thể hiện đúng trình tự.; Nhãn hành động không nêu actor dù actor quan trọng cho hành vi quan sát được. Gắn “Thủ kho” với bước nhận, lưu phiếu và ghi sổ; giữ “Sản xuất” ở kết quả cấp phát.; E chỉ nêu mất liên kết mã lô nhưng không thể hiện hệ quả kiểm soát của nhánh giấy. Nối E với rủi ro ERP không dùng được dữ liệu hư hỏng để chặn cấp phát, nhưng không biến khuyến nghị chưa được duyệt thành trạng thái hiện có.
assets/diagrams/03-discovery-interviewing-and-note-taking-021-cd23b32f.mmd — REVISE — Upstream dependency /00-research/00_SOURCE_MAP.md appears in canonical-source table but is omitted from diagram. Add it or explicitly limit diagram scope.; Downstream nodes interview note, requirement artifact, and test basis are not established by surrounding prose. Support these outcomes in prose or remove them.; Downstream labels are broad and ambiguous. Use concrete artifact names or canonical IDs supported by section.
assets/diagrams/03-discovery-interviewing-and-note-taking-022-2bd0ae70.mmd — REVISE — Sơ đồ thiếu liên kết NEED --> AC, dù bảng xác định AC là đích sử dụng trực tiếp của NEED; cần bổ sung hoặc sửa bảng/prose để thống nhất mô hình.; Sơ đồ đảo hoặc không thể hiện đầy đủ quan hệ của REQ: bảng nêu đích BR, AC, DATA/API, TC, nhưng sơ đồ dùng BR --> REQ, DATA --> REQ và thiếu REQ --> TC; cần xác định rõ mũi tên biểu thị truy vết hay phụ thuộc rồi đồng bộ hướng và phạm vi liên kết.; Sơ đồ thiếu BR --> AC, dù bảng xác định AC là đích sử dụng của BR; cần thể hiện liên kết này hoặc loại khỏi bảng nếu không phải quan hệ trực tiếp.; Sơ đồ thiếu DATA/API --> TC, dù bảng xác định TC là đích sử dụng của DATA/API; cần thể hiện để test case truy được dữ liệu hoặc hợp đồng API liên quan.; Luận điểm “nối mỗi nhu cầu với requirement, rule, tiêu chí chấp nhận, dữ liệu/API và test case” không được sơ đồ thể hiện trọn vẹn: không có đường truy vết từ NEED đến DATA/API; cần bổ sung đường liên kết được prose hỗ trợ hoặc thu hẹp phát biểu.
assets/diagrams/03-discovery-interviewing-and-note-taking-023-3d7090f6.mmd — REVISE — Nhánh chuẩn thiếu trạng thái ngoại lệ quan trọng: IN_REVIEW tại v0.9.0 không phải baseline hoặc approval. Cần thể hiện điều kiện này để tránh hiểu rằng hoàn tất review đồng nghĩa thay đổi đã được chấp thuận.; Bước Ghi thay đổi và version chưa bao quát lịch sử thay đổi và người cần xem xét như prose yêu cầu. Cần ghi rõ các nội dung bắt buộc này hoặc tách thành bước cụ thể.; Nhãn Review đúng thẩm quyền không nêu chủ thể hoặc thẩm quyền phê duyệt, dù actor quyết định ý nghĩa của review. Cần xác định vai trò chịu trách nhiệm hoặc diễn đạt rõ đây là review, không phải approval.; Bước Kiểm tra liên kết và bằng chứng thêm khái niệm “bằng chứng” chưa được section giải thích rõ. Cần gắn nó với artifact phụ thuộc, ID và nguồn chân lý đã nêu, hoặc bỏ phần không được prose hỗ trợ.
assets/diagrams/03-discovery-interviewing-and-note-taking-024-a251ad8c.mmd — REVISE — Gateway “Đủ điều kiện kiểm chứng?” mơ hồ: không rõ đang đánh giá phát biểu có đủ thông tin để kiểm chứng hay đã được nguồn có thẩm quyền xác minh. Cần đặt điều kiện cụ thể, phù hợp với trạng thái xác minh.; Nhánh “Không” kết thúc tại “Question log hoặc Verification required”, không thể hiện việc bổ sung bằng chứng, xác định Legal Owner hoặc Accounting Owner, rồi quay lại đánh giá. Cần thêm vòng xác minh và kết quả sau xác minh.; Bước “Requirement hoặc decision candidate” gộp hai kết quả có thẩm quyền và vòng đời khác nhau. Cần tách requirement candidate khỏi decision candidate hoặc nêu rõ quyết định chỉ được hình thành sau xác minh bởi owner phù hợp.; Sơ đồ bỏ qua phân biệt diễn giải của BA với Facts. Cần thể hiện Underlying Need là phân tích, không phải phát biểu đã được xác nhận.; Bước “Liên kết nguồn và artifact liên quan” thiếu giả định, quyết định và trạng thái xác minh mà bảng yêu cầu. Cần bổ sung các liên kết truy vết này.; Không có kết quả cho phát biểu không được xác minh hoặc bị bác bỏ. Cần thể hiện trạng thái giữ mở, bác bỏ hoặc không chuyển thành requirement/rule.
assets/diagrams/03-discovery-interviewing-and-note-taking-025-3eff22d3.mmd — REVISE — Các bước “Xác định authority có thẩm quyền”, “Khóa quyết định khỏi yêu cầu triển khai” và “Phục hồi bằng xác minh và cập nhật traceability” không được phần văn xuôi quy định; cần bỏ hoặc bổ sung căn cứ rõ trong nội dung.; Nhãn “Phục hồi” hàm ý sự cố đã xảy ra, trong khi luồng bắt đầu từ đánh giá ghi chú phỏng vấn; cần dùng trạng thái hoặc kết quả đúng với ngữ cảnh phòng ngừa.; Nhánh “Có” bỏ qua yêu cầu cảnh báo không thay cho ghi chú “cần làm rõ”; cần thể hiện việc tiếp tục ghi nhận điểm mở khi thông tin chưa hoàn chỉnh.; Điều kiện “hậu quả nghiêm trọng” quá mơ hồ so với tiêu chí đã nêu: mất dữ liệu, sai quyết định có thẩm quyền, phát hành yêu cầu không kiểm thử được, hoặc rủi ro an toàn thực phẩm, tài chính, bảo mật; cần làm điều kiện cụ thể hoặc liên kết rõ với tiêu chí này.; Các từ “artifact”, “authority” và “traceability” trộn ngôn ngữ, thiếu đối tượng cụ thể; cần dùng nhãn tiếng Việt rõ nghĩa và nhất quán.; Luồng không nêu BA là chủ thể thực hiện phân loại và ghi nhận, dù phần văn xuôi giao trách nhiệm này cho BA; cần thể hiện chủ thể tại bước có trách nhiệm.
assets/diagrams/03-discovery-interviewing-and-note-taking-026-1bfd40b7.mmd — REVISE — Gateway B chưa bao quát các dữ kiện bắt buộc trong prose: mã kho, mã nguyên liệu, mức tồn, đơn vị tính, lịch kiểm tra, người nhận cảnh báo và người có quyền đổi ngưỡng. Cần nêu đủ hoặc dùng tiêu chí cụ thể về nội dung rule có thể kiểm thử.; Nhãn "owner" mơ hồ: có thể chỉ người sở hữu rule, người nhận cảnh báo hoặc người có thẩm quyền phê duyệt. Cần tách rõ vai trò vận hành và thẩm quyền xác minh.; Nhánh E không nêu ai xác minh nội dung nào. Cần thể hiện Business Owner xác nhận nhu cầu, Warehouse Manager xác nhận thực tế kho và Architect xác nhận cơ chế cảnh báo theo phần Authority.; Kết quả "Đủ basis cho artifact tiếp theo" mơ hồ và có thể bị hiểu là approved hoặc baselined. Cần giới hạn kết quả vào việc đủ căn cứ liên kết tới CANONICAL_BUSINESS_RULES sau khi nội dung và thẩm quyền đã được xác minh.; Sơ đồ thiếu ranh giới trạng thái quan trọng: nội dung thiếu bằng chứng phải giữ Verification required, còn IN_REVIEW không được coi là approved hoặc baselined. Cần thể hiện rõ giới hạn này tại nhánh kết quả.
assets/diagrams/03-discovery-interviewing-and-note-taking-027-30f9e4ca.mmd — REVISE — Thứ tự sai: sơ đồ liên kết template trước khi kiểm tra quality gate. Phải xác minh ID, đường dẫn canonical và trạng thái hiện hành IN_REVIEW trước khi liên kết.; Nhãn Chỉ dùng làm artifact IN_REVIEW mơ hồ, dễ diễn giải trạng thái thành mục đích sử dụng. Phải thể hiện rõ IN_REVIEW là trạng thái cần xác minh, không phải baseline hay approval.; Nhánh Không thiếu kết quả kiểm soát quan trọng: không gắn mẫu chưa đăng ký vào artifact Nova Foods. Bổ sung kết quả này mà không tạo ID hay đường dẫn.; Actor BA quá hẹp so với consumer được nêu: handbook author, template author và QA reviewer cũng tra manifest. Dùng actor bao quát đúng phạm vi hoặc bỏ actor khỏi điểm bắt đầu.
assets/diagrams/03-discovery-interviewing-and-note-taking-028-90b9a55f.mmd — REVISE — Nhánh Có đi thẳng từ kiểm ID registry và metadata đến dùng artifact, nhưng bỏ qua các kiểm tra bắt buộc theo nội dung artifact: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và 00_SOURCE_MAP. Cần thể hiện các kiểm tra có điều kiện này trước kết quả sử dụng.; Nhãn “Chỉ dùng artifact cùng IN_REVIEW v0.9.0” thiếu ngày metadata bắt buộc 2026-08-07 và dùng từ “cùng” mơ hồ. Cần nêu đủ trạng thái, phiên bản và ngày chính xác.; Nhánh Không kết thúc ở lệnh cấm tạo tên tệp hoặc ID mới nhưng chưa nêu kết quả vận hành: không liên kết artifact và quay về TEMPLATE_MANIFEST khi manifest đăng ký filled-artifact path. Cần thể hiện kết quả này.; Bước “Đối chiếu ID registry và metadata” gộp hai nguồn và nhiều tiêu chí khác loại, làm mờ việc giữ nguyên ID canonical và không gọi artifact approved, baselined hoặc production-ready. Cần tách hoặc làm rõ tiêu chí kiểm tra.
assets/diagrams/03-discovery-interviewing-and-note-taking-029-4a43a4a7.mmd — REVISE — Nhánh "Có" thêm "Escalation đúng owner" nhưng đoạn văn không xác định owner, cơ chế escalation, hoặc yêu cầu chuyển cấp. Cần bổ sung căn cứ trong prose hoặc bỏ bước này.; Nhãn "Đối chiếu rule, data, source boundary" mơ hồ, trộn tiếng Anh và không chỉ rõ nguồn kiểm soát cần đối chiếu. Cần dùng thuật ngữ cụ thể, nhất quán với prose: fact, quy tắc, approval, baseline, nghĩa vụ pháp lý và ranh giới nguồn.; Kết quả "Đánh dấu sẵn sàng handoff chapter" có thể ngụ ý đủ điều kiện bàn giao dù sơ đồ chưa thể hiện kiểm tra trạng thái corpus, phiên bản, ngày, múi giờ và tính tổng hợp của dữ liệu Nova Foods. Cần thể hiện các điều kiện kiểm soát này hoặc giới hạn rõ phạm vi sơ đồ.; Cụm "verification-required" là trạng thái hoặc loại issue chưa được prose định nghĩa. Cần định nghĩa trong section hoặc thay bằng khái niệm đã được hỗ trợ.
assets/diagrams/04-current-state-as-is-and-process-mapping-001-528df114.mmd — REVISE — Sơ đồ bỏ qua nhánh quan trọng khi không có bằng chứng. Cần thể hiện nội dung chưa được xác nhận phải được gắn là giả định hoặc điểm cần xác minh, không được chuyển thẳng sang mô tả As-Is.; Chuỗi tuyến tính ngụ ý mọi quan sát đều đủ để mô tả As-Is và phát hiện vấn đề. Cần có điểm kiểm tra mức độ xác nhận của bằng chứng trước khi coi nội dung là hiện trạng.; Nhãn “Nhu cầu nghiệp vụ hiện có” mơ hồ: có thể chỉ nhu cầu khởi phát quy trình nghiệp vụ hoặc nhu cầu khảo sát của BA. Cần làm rõ đối tượng bắt đầu luồng.; Sơ đồ gần như lặp lại trình tự đã nêu trong văn bản, nhưng không biểu diễn các thành phần Process Mapping được nhấn mạnh như điểm quyết định, dữ liệu, kết quả và điểm kết thúc.
assets/diagrams/04-current-state-as-is-and-process-mapping-002-5fec7fcd.mmd — REVISE — Nhãn outcome “Tồn kho mô phỏng được cập nhật” mơ hồ và thiếu kết quả đã nêu trong bảng. Cần thể hiện tồn kho mô phỏng giảm theo số lượng được ghi nhận và phiếu chuyển sang trạng thái đã ghi nhận xuất.
assets/diagrams/04-current-state-as-is-and-process-mapping-004-841c468f.mmd — REVISE — Nhãn "ERP mô phỏng được cấu hình" mơ hồ và không tương ứng rõ với bước nào trong prose; cần diễn đạt cụ thể việc cấu hình hoặc xây luồng ERP từ requirement mơ hồ.; Nhãn "Kiểm tra được với quy trình mô phỏng" không rõ đối tượng được kiểm tra và "quy trình mô phỏng" là gì; cần nêu rõ requirement hoặc cấu hình ERP được đối chiếu với As-Is map.; Nhánh tích cực bỏ qua giá trị trọng yếu được section nêu: điểm kiểm soát hiện hữu, dữ liệu sử dụng, vai trò bàn giao, ngoại lệ và dấu vết nguồn; cần thể hiện ít nhất các yếu tố quyết định phạm vi và kiểm tra tác động.; Hai nhánh chưa song song về kết quả: nhánh thiếu map kết thúc bằng làm lại, còn nhánh có map chỉ kết thúc bằng khả năng kiểm tra; cần dùng kết quả đối xứng, cụ thể để làm rõ khác biệt.
assets/diagrams/04-current-state-as-is-and-process-mapping-005-378de79b.mmd — REVISE — Sơ đồ thiếu bước "duyệt xuất" dù bảng khẳng định luồng gồm nhận đơn, kiểm tra tồn, duyệt xuất và ghi nhận chứng từ. Bổ sung đúng bước, owner và vị trí theo hiện trạng đã được owner xác nhận; nếu hiện trạng không có bước này, sửa prose thay vì sơ đồ.; Hai nhánh B --> C và B --> D khiến việc Sales sửa số lượng trông như bước mặc định ngay sau kiểm tra tồn, trong khi prose mô tả sự kiện có thể xảy ra sau khi Warehouse đã chuẩn bị hàng. Biểu diễn C như ngoại lệ hoặc sự kiện thay đổi có thể phát sinh trong khoảng trước khi xuất.; Nhánh từ B sang C và D không có điều kiện, gateway hoặc dấu hiệu song song nên thứ tự và quan hệ phụ thuộc bị mơ hồ. Ghi rõ điều kiện dẫn đến sửa đơn và thời điểm Warehouse được phép tiếp tục.; Nhãn nét đứt thông tin có thể không tới Warehouse mô tả rủi ro nhưng đích D dễ bị hiểu là thông tin thiếu vẫn kích hoạt xuất hàng. Thể hiện rõ đây là handoff thất bại hoặc kiểm tra "Warehouse đã nhận thay đổi trước xuất hàng chưa", không phải luồng thực thi bình thường.; Sơ đồ chưa thể hiện trạng thái đơn dùng để Warehouse xuất hàng và Accounting ghi nhận, dù đây là nhu cầu trung tâm của section. Bổ sung dữ liệu hoặc trạng thái tại handoff nếu đã quan sát được; nếu chưa xác định, đánh dấu rõ là điểm cần xác minh thay vì phát minh trạng thái.
assets/diagrams/04-current-state-as-is-and-process-mapping-006-b047df5f.mmd — REVISE — Nhánh Stakeholder input đi thẳng tới gateway về authority, trái với Decision trong bảng: BA phải giữ nhãn stakeholder input đồng thời tạo Verification-required claim. Cần thể hiện bước tạo claim cần xác minh.; Gateway Đã có authority ghi nhận lựa chọn? nhập chung xác nhận cách vận hành với quyết định. Authority xác nhận nguồn hoặc tác động không tự động biến phát biểu thành Decision. Cần tách xác minh claim khỏi phê duyệt quyết định.; Nhãn authority mơ hồ, bỏ mất ranh giới trách nhiệm nêu trong bảng: Warehouse Operations Owner xác nhận vận hành, Accounting Owner xác nhận tác động hạch toán, Legal Owner xác minh diễn giải pháp lý. Cần chỉ rõ owner theo loại xác nhận.; Nhánh Có dẫn tới Decision thiếu Decision Criteria: nguồn quan sát được, phạm vi rõ, owner xác nhận, không suy diễn nghĩa vụ kế toán hoặc pháp lý. Cần thể hiện điều kiện quyết định hoặc tránh mô tả rằng một lần authority ghi nhận là đủ.; Sơ đồ không thể hiện kết quả hiện tại Chưa có quyết định và claim vẫn cần xác minh. Nhánh Giữ nhãn hiện tại, không nâng cấp quá chung, không phản ánh trạng thái áp dụng cụ thể.
assets/diagrams/04-current-state-as-is-and-process-mapping-007-912ae28a.mmd — REVISE — Luồng Operations chỉ quay về Discovery, trong khi bảng quy định phát hiện mới quay về Discovery hoặc Analysis. Bổ sung nhánh về Analysis với điều kiện cụ thể.; Sơ đồ chỉ thể hiện exit gate của Analysis, làm mờ các entry gate và exit gate quan trọng của Delivery, Testing, Release và Operations. Thể hiện các gate quyết định chuyển pha hoặc ghi rõ sơ đồ chỉ minh họa gate Analysis.; Nhánh "Không" tại exit gate Analysis luôn quay lại Analysis nhưng không nêu hành động khắc phục thiếu luồng, ngoại lệ hoặc bằng chứng. Gắn nhãn kết quả cụ thể, phù hợp tiêu chí gate.; Release được nối thẳng từ Testing mà không thể hiện điều kiện có kết quả testing và phạm vi phát hành rõ. Bổ sung điều kiện chuyển pha để tránh diễn giải rằng mọi lần testing đều dẫn đến release.; Operations không thể hiện kết quả kiểm soát "không sửa ngầm sơ đồ đã kiểm soát". Bổ sung ranh giới kiểm soát hoặc kết quả chuyển phát hiện về pha thích hợp.
assets/diagrams/04-current-state-as-is-and-process-mapping-008-8556305f.mmd — REVISE — Nhãn Testing “Đối chiếu hành vi hệ thống với luồng đã xác định” dễ hiểu sai rằng hệ thống mới phải khớp nguyên trạng As-Is. Cần nêu As-Is là đường cơ sở để phân biệt hành vi cũ, lỗi mới và thay đổi dự kiến.; Phần văn xuôi nói As-Is tiếp tục làm tài liệu vận hành, nhưng sơ đồ chỉ nêu Operations ghi nhận lệch và phản hồi. Cần thể hiện rõ As-Is hỗ trợ tài liệu hoặc đối chiếu vận hành.; Bước Release và kết quả “Phát hành thay đổi đã kiểm thử” chưa được phần văn xuôi giải thích trực tiếp. Cần bổ sung căn cứ trong văn xuôi hoặc bỏ chi tiết này khỏi sơ đồ.
assets/diagrams/04-current-state-as-is-and-process-mapping-009-d861c9bf.mmd — REVISE — Nhãn "Traceability" mơ hồ và không song song với các nhãn hành động còn lại. Cần nêu cụ thể chủ thể và kết quả truy vết, phù hợp với nội dung nối process map với nguồn, quy tắc, dữ liệu và quyết định.; Luồng "Canonical ID" → "Traceability" ngụ ý Canonical ID tự tạo khả năng truy vết, trong khi prose còn xác định artifact nguồn cho phép truy ngược cách BA hình thành mô hình. Cần thể hiện đúng vai trò phối hợp hoặc giới hạn rõ loại truy vết do Canonical ID hỗ trợ.
assets/diagrams/04-current-state-as-is-and-process-mapping-010-e3c12a39.mmd — REVISE — Thiếu kiểm tra toàn vẹn: phải xác nhận đủ ngữ cảnh, ngày và phiên bản; nếu không đạt, không được trích rule hoặc luồng.; Thiếu kiểm tra ranh giới thẩm quyền pháp lý, kế toán và production; nếu vượt ranh giới, phải gắn nhãn và escalation.; Nhánh mâu thuẫn dùng chung STOP: không map current state, rộng hơn prose. Prose chỉ yêu cầu dừng mapping phần bị ảnh hưởng; cần thể hiện đúng phạm vi này.; Nhánh Escalate đúng Owner không cho biết đầu vào có bị dừng dùng làm fact trong lúc chờ xác nhận hay không. Cần thể hiện trạng thái chưa đủ điều kiện mapping.; Kết quả Đủ điều kiện làm evidence mơ hồ vì section phân loại nhiều mức bằng chứng. Cần nêu rõ đầu vào chỉ đủ điều kiện dùng cho current-state mapping theo phân loại nguồn tương ứng, không tự động trở thành fact chính thức.
assets/diagrams/04-current-state-as-is-and-process-mapping-011-ec6fc948.mmd — REVISE — Sơ đồ chỉ thể hiện 4 đầu vào nhưng bảng còn TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, 00_SOURCE_MAP và bằng chứng ERP bị thiếu. Cần thể hiện đủ đầu vào liên quan hoặc ghi rõ sơ đồ chỉ minh họa tập con và tiêu chí chọn.; Nhãn Phát hiện đã gắn Verification required khẳng định có phát hiện và liên kết đã được tạo, trong khi prose chỉ liệt kê hạng mục cần xác minh và cho biết chưa có ID nghiệp vụ được đăng ký. Cần đổi kết quả thành trạng thái chưa xác minh được prose hỗ trợ, không hàm ý traceability đã hoàn tất.; Luồng CHAPTER_MANIFEST vào Phân tích As-Is làm metadata quản trị trông như bằng chứng vận hành. Cần tách nguồn quản trị corpus khỏi bằng chứng, quan sát và bằng chứng thiếu.; Sơ đồ bỏ ranh giới quan trọng giữa fact mô phỏng, giả định minh họa, kế hoạch catalog và bằng chứng thiếu. Cần biểu diễn các trạng thái nguồn này để tránh người đọc hiểu mọi đầu vào có cùng độ tin cậy.; Sơ đồ không thể hiện chủ sở hữu nguồn hoặc trách nhiệm xác minh dù bảng nêu Business Owner, Warehouse Owner, Accounting Owner và System Owner mô phỏng. Cần thể hiện owner nếu sơ đồ nhằm giải thích luồng phân tích và xác minh.; Sơ đồ gần như lặp lại danh sách đầu vào trong bảng, chưa giải thích cách phân loại nguồn, đánh giá độ tin cậy hoặc chuyển hạng mục chưa giải quyết thành việc xác minh. Cần bổ sung quan hệ phân tích có ý nghĩa hoặc bỏ sơ đồ nếu không tạo thêm giá trị.
assets/diagrams/04-current-state-as-is-and-process-mapping-012-25014bdc.mmd — REVISE — Sơ đồ trình bày kiểm tra tồn khả dụng, chặn nhánh thiếu tồn và tạo yêu cầu xuất tối đa tồn khả dụng như luồng As-Is đang vận hành. Phần Current Behavior chỉ xác nhận Kinh doanh gửi email, Kho kiểm tra file riêng và Kế toán biết khi nhận yêu cầu lập hóa đơn; phần Decision gọi cơ chế tối đa 900 thùng là đề xuất cần xác nhận. Cần phân biệt rõ bước quan sát hiện tại với kết luận phân tích chưa được phê duyệt.; Các bước “Kiểm tra tồn vật lý” và “Trừ số lượng đã giữ chỗ” không nêu chủ thể, trong khi prose phân biệt Kinh doanh, Kho và nguồn dữ liệu riêng. Cần gắn đúng actor hoặc điểm bàn giao đã được section hỗ trợ.; Nhánh “Business Owner chọn giao một phần?” làm Business Owner thành người thực hiện quyết định trong luồng hiện tại, nhưng section chỉ nêu Business Owner là authority cần xác nhận chính sách. Cần tránh biểu diễn phê duyệt này như sự kiện As-Is đã được quan sát.; Nhánh “Không” đi đến “Ghi nhận phần đơn chờ hàng hoặc hủy” rồi “Escalation đến Business Owner” không nhất quán: Business Owner vừa chọn, sau đó quy trình lại escalation đến cùng vai trò. Cần sửa thứ tự và owner, hoặc bỏ escalation nếu không có bất đồng cần chuyển cấp.; Nút “Ghi nhận phần đơn chờ hàng hoặc hủy” gộp hai kết quả khác nhau mà không có điều kiện quyết định. Cần tách trạng thái chờ hàng và hủy, kèm quyền quyết định được section hỗ trợ.; Sơ đồ bỏ luồng email, file theo dõi riêng và thời điểm Kế toán chỉ biết đơn khi nhận yêu cầu lập hóa đơn. Đây là các đặc điểm trọng yếu của As-Is và nguồn rủi ro thiếu điểm kiểm soát chung. Cần thể hiện chúng nếu sơ đồ tiếp tục được mô tả là quan sát As-Is.
assets/diagrams/04-current-state-as-is-and-process-mapping-013-be4e1297.mmd — REVISE — Thiếu owner chịu trách nhiệm cập nhật và review artifact. Bổ sung vai trò Principal IT Business Analyst / Technical Curriculum Author tại bước hoặc boundary phù hợp.; Nhãn Cập nhật traceability mơ hồ và không dùng tên canonical. Đổi thành Cập nhật TRACEABILITY_ID_REGISTRY.; Luồng bỏ qua nghĩa vụ ghi lịch sử thay đổi, dù đây là điều kiện kiểm soát bắt buộc cho mọi output. Bổ sung bước ghi ngày, version, lý do, nguồn và tác động trước trạng thái IN_REVIEW.; Luồng không thể hiện kiểm soát ID: section không được tự cấp ID mới và artifact chưa đăng ký phải chờ registry cập nhật có kiểm soát. Bổ sung decision hoặc chú thích boundary cho trường hợp cần artifact mới.; Các nhánh đi thẳng vào IN_REVIEW khiến trạng thái trông như kết quả tự động sau cập nhật, không thể hiện yêu cầu nội dung tối thiểu và bằng chứng phục vụ review. Bổ sung bước kiểm tra đủ nội dung, nguồn và traceability trước trạng thái.; Nhãn trộn tiếng Việt và tiếng Anh thiếu song song: business rule, data element, handbook, traceability. Chuẩn hóa theo thuật ngữ cụ thể trong bảng, ưu tiên quy tắc nghiệp vụ, dữ liệu logic, bản mô tả quy trình As-Is và tên canonical.
assets/diagrams/04-current-state-as-is-and-process-mapping-014-ac3d9a23.mmd — REVISE — Các bước nhận đơn, nhập bảng theo dõi, xác nhận tồn kho, gọi điện cho kho, lập phiếu, chuẩn bị hàng và giao hàng không có bằng chứng trong phần văn xuôi; phải dẫn nguồn hỗ trợ hoặc thay bằng nội dung đã được nguồn xác nhận.; Sơ đồ không nêu phạm vi, sự kiện bắt đầu, điểm kết thúc và ngoại lệ trong phạm vi; phải xác định rõ ranh giới quy trình.; Quyền sở hữu bước và bàn giao giữa nhân viên bán hàng, kho và bên giao hàng không rõ; phải thể hiện tác nhân chịu trách nhiệm cho từng bước.; Gateway "Tồn kho được xác nhận?" không nêu ai xác nhận, dựa trên dữ liệu nào hoặc điều kiện phân nhánh cụ thể; phải bổ sung chủ thể, đầu vào và tiêu chí quyết định.; Nhánh "Không" quay lại bước nhập đơn nhưng không cho biết dữ liệu nào được sửa hoặc điều kiện nào kết thúc vòng lặp; phải mô tả thay đổi trạng thái và điều kiện thoát.; Các nhãn "bảng theo dõi", "phiếu yêu cầu xuất kho" và "cập nhật bảng theo dõi" không xác định dữ liệu, trạng thái hoặc chứng từ bị tạo hay sửa; phải dùng nhãn cụ thể và nhất quán.; Bước "Giao hàng và cập nhật bảng theo dõi" gộp hai hành động có thể thuộc hai chủ thể và hai thời điểm; phải tách hoặc chứng minh cùng chủ thể thực hiện trong một bước.; Sơ đồ không thể hiện điểm đau, tác động hoặc nguyên nhân quan sát được dù đây là thành phần bắt buộc của gói As-Is; phải đánh dấu điểm đau có nguồn hoặc nói rõ sơ đồ chỉ bao phủ luồng công việc.; Sơ đồ không phân biệt nguồn primary, project assumption và Verification required; phải gắn ranh giới nguồn cho các nội dung chưa được xác minh.; Sơ đồ không có liên kết truy vết đến source map, ID, rule hoặc data dictionary khi phù hợp; phải bổ sung tham chiếu truy vết cho bước, quyết định, dữ liệu và chứng từ.
assets/diagrams/04-current-state-as-is-and-process-mapping-015-e54ade3a.mmd — REVISE — Luồng cho phép chuyển downstream review sau hai gateway, nhưng bảng yêu cầu thêm ranh giới nguồn, tính nhất quán, khả năng review và lịch sử thay đổi. Phải thể hiện mọi điều kiện bắt buộc trước trạng thái ready.; Change history chỉ xuất hiện khi sửa artifact, trong khi gate yêu cầu bằng chứng lịch sử cho mọi sửa đổi. Phải kiểm tra change-history entry như điều kiện gate, không chỉ như hành động khắc phục.; Gateway “Nguồn và giả định được gắn nhãn?” chưa bao quát yêu cầu không biến học liệu, luật, chuẩn hoặc dữ liệu mô phỏng thành quyết định thật của Nova Foods. Phải thể hiện rõ kiểm tra ranh giới nguồn.; Nhãn “Đủ metadata” mơ hồ vì không nêu Artifact ID, filename canonical, trạng thái IN_REVIEW, phiên bản v0.9.0 và múi giờ Asia/Ho_Chi_Minh. Phải dùng điều kiện cụ thể hoặc tách gateway.; Nút cuối đặt “Không suy ra approval, baseline hoặc production readiness” như bước xảy ra sau reviewer, trong khi đây là giới hạn ý nghĩa của quality gate và trạng thái IN_REVIEW. Phải biểu diễn như ràng buộc áp dụng cho trạng thái ready/review, không như bước quy trình kế tiếp.; Diagram bỏ qua kết quả riêng của lỗi tính nhất quán: ghi lỗi và sửa trước review. Phải giữ hậu quả này thay vì gộp mọi thiếu sót vào nhánh sửa chung không nêu việc ghi lỗi.
assets/diagrams/04-current-state-as-is-and-process-mapping-017-8a1d906c.mmd — REVISE — Gateway “Quyết định thuộc ai?” tạo các nhánh loại trừ lẫn nhau, trong khi section quy định Business Owner quyết định, Operations xác nhận khả thi, specialist owner xác minh và Architect xem tác động. Sửa luồng để thể hiện vai trò phối hợp, không phải bốn owner quyết định thay thế nhau.; Các nhánh “Pháp lý, kế toán, an toàn thực phẩm, bảo mật” thêm kế toán và bảo mật không được tình huống này hỗ trợ. Chỉ giữ các lĩnh vực và specialist owner được section nêu.; Nút “Quyết định được ghi nhận” ngụ ý đã có quyết định, trái với trạng thái artifact IN_REVIEW và nội dung “Chưa quyết định”. Cần thể hiện trạng thái chờ xác minh, escalation và quyết định chưa hoàn tất.; Luồng bỏ điều kiện Verification required đối với pháp lý và an toàn thực phẩm, gồm specialist owner và nguồn chính thức. Cần thể hiện cổng xác minh trước khi ghi nhận quyết định.; Nút “Developer và QA dùng làm đầu vào” gộp hai vai trò khác nhau. Developer dùng quyết định làm đầu vào; QA xác định kiểm thử từ quyết định đã ghi nhận. Cần tách vai trò hoặc ghi rõ hai kết quả.; Luồng bỏ nguyên tắc BA không tự biến suy luận thành rule và không tự chọn khi hậu quả thuộc nhiều owner. Cần thể hiện escalation khi chưa đủ thẩm quyền hoặc bằng chứng.
assets/diagrams/04-current-state-as-is-and-process-mapping-018-395e41ee.mmd — REVISE — Nhãn quyết định "Hiểu giống nguồn?" mơ hồ: không xác định "nguồn" là người cung cấp phát biểu, evidence đầu vào hay nguồn canonical. Cần nêu rõ đối tượng dùng để đối chiếu.; Bước "Ghi câu trả lời vào artifact kiểm soát" dễ biến câu trả lời làm rõ thành quy tắc đã xác nhận, trái với cảnh báo rằng phát biểu người tham gia chỉ là evidence. Cần thể hiện trạng thái phù hợp như evidence, assumption hoặc nội dung đã được nguồn canonical xác nhận.; Chủ thể tại các bước đặt câu hỏi và ghi nhận không rõ. Cần chỉ rõ ai chịu trách nhiệm cập nhật artifact để tránh ngầm giao quyền kiểm soát cho "Người nhận".; Luồng kết thúc tại "Dùng làm đầu vào công việc" bỏ qua ranh giới IN_REVIEW, v0.9.0, chưa baseline hoặc phê duyệt. Cần thể hiện điều kiện sử dụng không đồng nghĩa với phê duyệt.; Sơ đồ không phân biệt nội dung As-Is với thay đổi mong muốn cho trạng thái tương lai, dù đây là rủi ro chính của phần văn bản. Cần có kiểm tra hoặc ranh giới ngăn đề xuất tương lai bị ghi thành Current State As-Is.
assets/diagrams/04-current-state-as-is-and-process-mapping-019-9579027d.mmd — REVISE — Sơ đồ bỏ bước ASIS-008-01-S01 dù phạm vi bắt đầu khi xe đến kho. Thêm sự kiện xe đến và bước Bảo vệ cho xe vào theo lịch giao giấy.; Luồng từ QA đi thẳng đến nhập Excel khiến việc nhập liệu có vẻ độc lập với hai kết quả xử lý hàng. Nối lại hai nhánh 196 đạt và 2 hỏng trước bước nhập GRN_20260807.xlsx để thể hiện dòng Excel dùng cả số lượng đạt, số lượng hỏng và vị trí lưu.; Sơ đồ vượt ranh giới đã nêu: phạm vi kết thúc khi kế toán nhận bảng qua email, nhưng nút cuối mô tả kế toán nhập lại dữ liệu. Kết thúc tại Kế toán nhận GRN_20260807.xlsx; nếu giữ bước nhập lại, đánh dấu rõ là ngoài phạm vi quan sát chi tiết.; Nhãn Kho đối chiếu PO PDF thiếu chứng từ đối chiếu và mã cụ thể. Đổi thành nhãn cụ thể thể hiện Kho đối chiếu PO-20260807-014.pdf với DN-MT-20260807-118.
assets/diagrams/04-current-state-as-is-and-process-mapping-020-c60d21fe.mmd — REVISE — Edge C --> E wrongly implies ERP total inventory creates SO-20260807-031. Section says sales creates order, then warehouse selects 50 cartons using total inventory. Correct flow must show sales order as separate event and warehouse allocation or picking step against ERP total.; Flow omits outbound transaction or picking step. G and H claim missing structured link between outbound stock and lot code, but no outbound stock event appears. Add concrete 50-carton outbound step before outcome.; Flow omits documented exception: when Excel and ERP inventory differ, Warehouse Manager receives phone verification request before release. Add mismatch condition and manual-verification branch.; G label omits actor and object. Section says warehouse employee records lot code in free-text delivery note. Make actor, lot code, and delivery-note target explicit.
assets/diagrams/04-current-state-as-is-and-process-mapping-021-a0b500ea.mmd — REVISE — Nhánh Có khẳng định Thủ kho cho phép cấp phát thủ công, nhưng section không xác nhận hành vi hoặc thẩm quyền này; WR-NF-ASIS-003 còn là giả định cần xác minh. Sửa nhãn thành kết quả được bằng chứng hỗ trợ hoặc thể hiện rõ trạng thái Verification required.; Nhánh Không khẳng định thủ kho liên hệ mua hàng qua email, nhưng section chỉ nêu bảng tính và email như công cụ phân tán, không xác nhận actor, trigger hoặc quy trình xử lý QA không đạt. Bỏ nhánh hoặc bổ sung trạng thái cần xác minh trong nhãn.; Gateway chỉ hỏi QA thông báo đạt? nhưng không thể hiện cập nhật trạng thái QA, vai trò ghi quyết định hoặc thời điểm quyết định, dù đây là ranh giới quan trọng trong tiêu chí đánh giá. Bổ sung kết quả trạng thái cụ thể như PASSED và FAILED nếu section xác nhận.; Bước đối chiếu PO không thể hiện ngoại lệ nhận vượt số lượng hoặc việc bảng tính không chặn vượt PO. Bổ sung gateway hoặc chú thích cụ thể rằng đối chiếu bằng mắt và không có chặn hệ thống.; Sơ đồ trình bày các kết quả sau QA như hành vi As-Is đã xác nhận, làm mờ ranh giới giữa Current behavior và Project assumption; Verification required. Đánh dấu ranh giới xác minh hoặc dừng luồng tại điểm chưa có bằng chứng.
assets/diagrams/04-current-state-as-is-and-process-mapping-022-9934e58a.mmd — REVISE — 00_SOURCE_MAP và quan hệ 00_SOURCE_MAP --> 01_CURRICULUM_ARCHITECTURE không được section hoặc bảng dependency xác lập. Xóa node và cạnh này, hoặc bổ sung nguồn canonical tương ứng vào prose.; Cạnh 01_CURRICULUM_ARCHITECTURE --> CHAPTER_MANIFEST mô tả dependency giữa hai artifact nhưng prose chỉ xác lập từng artifact là upstream của Chapter 04. Đổi quan hệ để cả hai trực tiếp đi vào Chapter 04, hoặc bổ sung bằng chứng canonical cho dependency hiện tại.; Nhãn Requirement analysis, Test analysis, Data/API analysis không song song với tên downstream trong bảng. Dùng nhãn bám sát Requirement và rule analysis cùng API, data, test artifacts, hoặc giải thích rõ phép tách này trong prose.; Sơ đồ không thể hiện ràng buộc cốt lõi: Chapter 04 chỉ liên kết nguồn canonical, không sao chép rule, cấu trúc dữ liệu hoặc ID. Thêm boundary hoặc nhãn quan hệ để tránh hiểu các nguồn upstream là nội dung được nhập và tái định nghĩa.
assets/diagrams/04-current-state-as-is-and-process-mapping-023-881b05a0.mmd — REVISE — Diagram omits direct REQ --> TC link supported by REQ row (TC destination) and TC row (REQ test basis). Add REQ --> TC.; Diagram omits BR --> AC link listed in BR row. Add BR --> AC.; Diagram shows only REQ --> DATA and DATA --> TC, while DATA/API row lists REQ, AC, and TC as destinations. Add DATA --> AC; clarify or reverse REQ relationship if arrows represent listed destination direction.; Arrow meaning remains unstated. Define arrows as traceability links rather than sequence or causality, because current left-to-right flow can imply lifecycle order unsupported by prose.
assets/diagrams/04-current-state-as-is-and-process-mapping-024-258f4c5b.mmd — REVISE — “Update affected references or mark conflict” adds unsupported conflict-handling behavior. Section only requires affected artifacts to be reassessed; remove or ground this action in prose.; “Review by proper authority” invents owner and approval control absent from section. Define authority and review responsibility in prose or remove step.; “Retain traceable evidence” adds retention requirement not explicitly stated. Ground evidence-retention requirement in prose or limit label to stated version and change-history records.; Silent-change path omits two defining conditions: no impact notification and no linkage assessment. Represent these omissions or clarify that “silent change” covers all four listed governance failures.; “Wrong process, requirement, test, or data use” includes “data use,” which surrounding section does not identify as outcome. Remove it or add supporting prose.
assets/diagrams/04-current-state-as-is-and-process-mapping-025-6af7ca43.mmd — REVISE — Nhánh “Chưa có” dừng ở “Không biến thành fact hoặc requirement”, không thể hiện việc xác minh và đánh giá lại bằng chứng. Cần nối câu hỏi xác minh tới bước thu thập hoặc đối chiếu bằng chứng, rồi quay lại gateway “Có bằng chứng kiểm tra được?”.; Nhãn “Không biến thành fact hoặc requirement” là câu phủ định, trộn tiếng Anh và không nêu trạng thái đầu ra. Cần dùng nhãn cụ thể như “Giữ ở trạng thái nhận định cần xác minh”.; Luồng có bằng chứng đưa nội dung vào as-is map trước khi đối chiếu ngoại lệ và điểm bàn giao. Trình tự này dễ hợp thức hóa mô tả chưa đủ. Cần đối chiếu ngoại lệ và điểm bàn giao trước khi đưa vào bản đồ hiện trạng, hoặc thể hiện bước cập nhật bản đồ sau đối chiếu.; Sơ đồ không nêu chủ thể thực hiện quan sát, ghi nhận, xác minh và đối chiếu dù phần prose nhấn mạnh trách nhiệm của BA. Cần ghi rõ BA hoặc vai trò chịu trách nhiệm tại các bước này.
assets/diagrams/04-current-state-as-is-and-process-mapping-026-2993b81e.mmd — REVISE — Thiếu ranh giới quan trọng: không được dùng Verification required để che quyết định thiết kế đã triển khai. Bổ sung nhánh kiểm tra hoặc kết quả chặn riêng cho trường hợp này.; Nhãn Chuyển đúng Owner xác minh chưa cụ thể về trách nhiệm. Sửa nhãn để thể hiện Owner có thẩm quyền theo loại phát biểu, phù hợp ví dụ Legal Owner và Accounting Owner trong bảng.; Nhánh Có dẫn thẳng đến Giữ phát biểu và liên kết nguồn nhưng chưa nêu bằng chứng phải được ghi nhận. Sửa kết quả để yêu cầu giữ phát biểu cùng bằng chứng nguồn và thẩm quyền đã ghi nhận.
assets/diagrams/04-current-state-as-is-and-process-mapping-027-22186a6c.mmd — REVISE — Nhánh “Có nguồn canonical và authority xác minh” thu hẹp nguồn hợp lệ trái với prose, vốn cho phép nguồn phỏng vấn hoặc artifact được kiểm soát. Sửa điều kiện để phản ánh đúng hai loại nguồn và yêu cầu authority xác minh.; Nhánh escalation chỉ nêu Business Owner, bỏ Accounting Owner khi tiêu chí liên quan hạn mức tín dụng hoặc giá trị tiền. Bổ sung điều kiện và owner này.; Nhãn “Escalate Business Owner” trộn ngôn ngữ và không nêu chủ thể thực hiện. Dùng nhãn tiếng Việt, chủ động, xác định Principal IT Business Analyst / Technical Curriculum Author là bên chuyển yêu cầu xác minh.; Nhánh đã xác minh kết thúc ở “Cập nhật artifact có truy vết” nhưng không thể hiện giới hạn quyết định: chỉ cập nhật ngưỡng hoặc quyền duyệt khi nguồn và authority xác nhận. Làm rõ outcome để tránh hiểu rằng mọi nội dung canonical đều được tự động đưa vào AS-IS.
assets/diagrams/04-current-state-as-is-and-process-mapping-028-d64dc4c6.mmd — REVISE — Nhãn "Fact: bằng chứng nguồn" nhập nhằng giữa sự kiện và bằng chứng. Cần tách fact được quan sát khỏi nguồn hoặc artifact dùng để kiểm chứng.; Luồng C sang E khiến mọi inference dẫn thẳng đến quyết định. Cần thể hiện inference có giới hạn, có thể chỉ cần xác minh thêm và không mặc nhiên tạo decision.; Gateway "Đủ chất lượng và nhất quán?" gộp hai tiêu chí nhưng không thể hiện trường hợp bằng chứng đủ chất lượng mà mâu thuẫn với nguồn khác. Cần đưa mâu thuẫn vào nhánh escalation hoặc verification.; Nhánh authority thiếu Process Owner, System Owner, Risk Owner, Security và QA dù phần prose giao trách nhiệm hoặc nêu rõ BA không thay các vai trò này. Cần bổ sung hoặc dùng nhóm owner cụ thể, không dùng nhãn chung.; Nhãn "Authorized owner" không cụ thể và không song song với Business Owner, Architect. Cần ghi Accounting Owner, Legal Owner hoặc Compliance Owner.; Thiếu điều kiện escalation khi vấn đề thuộc nhiều authority, nguồn canonical mâu thuẫn thực hành, thiếu evidence nhưng bị yêu cầu chốt thiết kế, hoặc kết luận tác động quyền truy cập, phê duyệt, tiền, tồn kho, hóa đơn, dữ liệu cá nhân, truy xuất, tích hợp hay bảo mật.; Escalation package là điểm cuối nhưng không nêu outcome hoặc authority tiếp nhận. Cần thể hiện gói escalation giữ nguồn, phạm vi, bất định, rủi ro, option và decision authority.
assets/diagrams/04-current-state-as-is-and-process-mapping-029-718ce614.mmd — REVISE — Gateway "Có owner quyết định rõ?" áp dụng cho mọi bước As-Is, trong khi prose chỉ yêu cầu owner cho quyết định. Cần phân biệt bước tác nghiệp với điểm quyết định trước khi kiểm tra owner.; Nhánh thiếu bằng chứng chỉ dẫn đến "Không suy diễn rule hoặc control", bỏ ngưỡng escalation khi không có bằng chứng độc lập cho thao tác tạo, sửa, duyệt hoặc xóa dữ liệu. Cần thể hiện điều kiện escalation này.; Gateway ảnh hưởng nhạy cảm bỏ các trigger escalation bắt buộc: giao thoa từ hai thẩm quyền, quyền truy cập, API và dữ liệu giá trị bằng VND. Cần bổ sung hoặc khái quát chính xác toàn bộ trigger.; Kết quả "Escalate đúng authority" không thể hiện authority theo domain và yêu cầu owner xác minh diễn giải pháp lý. Cần nêu rõ chuyển đến Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner phù hợp.; Sơ đồ bỏ ngoại lệ workaround đang là kiểm soát bù trừ duy nhất. Nhánh ghi As-Is hiện có thể ngụ ý bước không thuộc nhóm nhạy cảm được ghi nhận mà không cần giữ control, nêu rủi ro và chuyển quyết định thay đổi cho owner. Cần thể hiện boundary này.; Các nhãn pha trộn Việt-Anh như "owner", "rule", "control", "authority" làm giảm tính cụ thể và song song. Cần dùng thuật ngữ nhất quán với vai trò và hành động được định nghĩa trong prose.
assets/diagrams/04-current-state-as-is-and-process-mapping-030-54055ab9.mmd — REVISE — Luồng tuyến tính bỏ điều kiện khi nhận định chạm luật, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân hoặc bảo mật. Cần thể hiện gateway dẫn tới Verification required và vai trò domain owner có thẩm quyền xác minh.; Nút Authority xác minh hoặc quyết định gộp hai trách nhiệm khác nhau và không nêu actor cụ thể. Cần phân biệt Warehouse Manager xác nhận luồng, Architect đánh giá tích hợp, domain owner xác minh nội dung chuyên môn và Business Owner quyết định ưu tiên.; Nút trạng thái không thể hiện ranh giới quản trị quan trọng: IN_REVIEW không tạo baseline hoặc approval. Cần ghi rõ kết quả này để tránh diễn giải trạng thái thành phê duyệt.; Nút Uncertainty và giả định gộp hai khái niệm có chức năng khác nhau. Cần tách điều chưa biết và ảnh hưởng nếu sai khỏi giả định tạm dùng cho phân tích.; Sơ đồ gần như lặp lại bảng và đoạn văn theo chuỗi, chưa làm rõ nhánh điều kiện, quyền quyết định hoặc ngoại lệ. Cần dùng cấu trúc luồng để giải thích các điểm này thay vì chỉ tuần tự hóa nội dung.
assets/diagrams/04-current-state-as-is-and-process-mapping-031-994ff52d.mmd — REVISE — Nút C thêm owner và quality gate nhưng prose không xác nhận đây là trường bắt buộc trong manifest. Xóa các trường này hoặc bổ sung căn cứ trong prose.; Nút E biến việc tham chiếu manifest thành quy trình đăng ký, trong khi prose chỉ xác định manifest là nguồn kiểm soát để kiểm tra template hợp lệ. Đổi thành hành động kiểm tra manifest hoặc bổ sung quy trình đăng ký có căn cứ.; Nút F khẳng định artifact phải liên kết rule, data, traceability, nhưng prose chỉ liệt kê các loại thông tin có thể cần ghi nhận và không đặt yêu cầu liên kết cả ba. Sửa outcome theo đúng điều kiện dùng template trong prose.; Nhánh Không dừng ở bước đăng ký, không nêu outcome hiện tại: không dùng ID, filename hoặc đường dẫn chưa đăng ký. Thêm outcome này để giữ đúng ranh giới kiểm soát.
assets/diagrams/04-current-state-as-is-and-process-mapping-032-83027285.mmd — REVISE — Nhánh 01_CURRICULUM_ARCHITECTURE không có kết quả kiểm tra. Bổ sung kết quả: giữ thứ tự As-Is Process Mapping trước requirement, rule, data và testing; không tự tạo requirement chưa có nguồn.; Nhánh TEMPLATE_MANIFEST không có kết quả kiểm tra. Bổ sung kết quả: chỉ dùng template ID và filename đã đăng ký.; Sơ đồ bỏ qua ngoại lệ quan trọng: completed current-state artifact chưa có Artifact ID, filename hoặc đường dẫn canonical. Thể hiện rõ không được bịa vị trí; chỉ liên kết chapter đang xây dựng cho đến khi artifact kiểm soát đăng ký.; Kết quả Giữ tên tệp và cấu trúc chapter chưa bao quát dependency được nêu trong bảng. Sửa nhãn để gồm tên tệp, cấu trúc chapter và dependency.; Các nhãn kết quả trộn tiếng Việt với từ tiếng Anh không cần thiết như chapter, rule, source boundary. Chuẩn hóa thành cách gọi cụ thể, song song với bảng hoặc giữ thuật ngữ chính thức nhất quán.
assets/diagrams/04-current-state-as-is-and-process-mapping-033-8560e4d4.mmd — REVISE — Nhãn “Escalate đúng owner” mơ hồ và bỏ mất phân tuyến owner theo loại vấn đề. Cần thể hiện owner tương ứng: Legal Owner, Accounting Owner, Domain Owner, Business Owner, Technical Architect, Security Owner, QA Owner hoặc Principal IT Business Analyst / Technical Curriculum Author.; Luồng kiểm tra chỉ nêu manifest, registry, rule và data dictionary, nhưng bỏ hai phụ thuộc kiểm soát trong section: source map và curriculum architecture. Cần đưa hai đối chiếu này vào phạm vi rà soát.; Nhánh “Có mâu thuẫn hoặc suy diễn?” gộp hai tình huống có cách xử lý khác nhau. Mâu thuẫn nguồn canonical phải dừng handoff phần nội dung bị ảnh hưởng; suy diễn phải giữ nhãn giả định hoặc Verification required và chuyển owner xác minh. Cần tách điều kiện và kết quả.; Cả hai nhánh đều kết thúc tại “Ghi kết quả IN_REVIEW”, làm mất điều kiện handoff: danh sách open issue phải được giữ và từng mục Verification required phải có owner. Cần thể hiện các điều kiện này trước kết quả handoff.; Sơ đồ bỏ ngoại lệ cấm tự kết luận khi nguồn canonical mâu thuẫn. Cần thể hiện Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề, chuyển đúng owner và không tự sửa định danh hoặc quyết định thay owner.
assets/diagrams/05-business-needs-objectives-and-scope-001-c4c0c50f.mmd — REVISE — Nhãn “118 đạt” thêm trạng thái chất lượng chưa được prose xác nhận; đổi thành khái niệm đã nêu như “118 thực nhận” hoặc xác nhận rõ tiêu chí “đạt”.; Nhãn “Thông tin chênh lệch dùng chung” mơ hồ về dữ liệu và chủ thể sử dụng; cần nêu cụ thể kết quả nhận hàng gồm số thực nhận và số hư hỏng, dùng chung cho tồn kho và mua hàng.; Nhãn “Mua hàng xử lý tiếp” không cho biết kết quả được hỗ trợ và có thể bị hiểu thành quyết định trả hàng hoặc thanh toán; cần giới hạn thành tiếp nhận dữ liệu chênh lệch để xử lý theo quyết định có thẩm quyền.; Luồng thiếu ranh giới quan trọng: ghi nhận chênh lệch không tự động giảm hóa đơn, quyết định trả hàng hoặc tạo bút toán; cần thể hiện rõ giới hạn này để tránh diễn giải sai hậu quả nghiệp vụ.
assets/diagrams/05-business-needs-objectives-and-scope-002-92198678.mmd — REVISE — Nút D đưa "cấu hình" vào hậu quả rework nhưng phần văn xuôi không nêu cấu hình; thay bằng các đầu ra được hỗ trợ như mã, tài liệu, kiểm thử, đào tạo hoặc dữ liệu mô phỏng.; Nút G nêu "chậm bàn giao" nhưng phần văn xuôi không xác lập hậu quả này; bỏ kết quả này hoặc thay bằng rủi ro đã nêu: scope creep, tác động kế toán, pháp lý, bảo mật, kiến trúc hoặc lỗi quản trị.; Nhánh quản trị bỏ mất điều kiện trạng thái quan trọng: IN_REVIEW tại v0.9.0 không phải baseline, approval hay quyền triển khai; bổ sung nhánh hoặc nút thể hiện ranh giới này.; Nút F "Hạng mục phát sinh không được quyết định" mơ hồ; đổi thành diễn đạt cụ thể về hạng mục ngoài phạm vi bị suy đoán thành cam kết hoặc phạm vi tăng không kiểm soát.; Nhánh tích cực gộp business need, objective và scope nhưng không thể hiện vai trò riêng của objective là kết quả có thể kiểm tra; bổ sung quan hệ này để tránh làm mất một khái niệm cốt lõi.
assets/diagrams/05-business-needs-objectives-and-scope-003-1cd5af4b.mmd — REVISE — Luồng “Trước” bắt buộc kho xem bảng tính và đi qua bước đối chiếu trước khi xác nhận giao hàng, trái với mô tả rằng bán hàng có thể xác nhận đơn trước khi kho đối chiếu lô. Cần thể hiện nhánh xác nhận sớm hoặc không mô tả sai thứ tự hiện trạng.; Gateway “Lô được đối chiếu thủ công?” chỉ có nhánh “Không rõ” và “Có”; thiếu trường hợp “Không”, đồng thời “Không rõ” không song song với câu hỏi có/không. Cần dùng các điều kiện đầy đủ, cụ thể và loại trừ nhau.; Luồng “Sau” trình bày “Kho chọn lô”, “Dừng xử lý” và liên kết đơn–lô như quy trình đã quyết định, trong khi section nói chưa có quyết định trong micro-batch. Cần phân biệt rõ nhu cầu hoặc phương án đang xem xét với quy trình mục tiêu đã phê duyệt.; Nhãn “ghi nhận cần làm rõ” không nêu đối tượng cần làm rõ, người ghi nhận hoặc điều kiện tiếp tục. Cần dùng trạng thái và trách nhiệm cụ thể được section hỗ trợ.; Diagram bỏ qua điểm quyết định còn mở và thẩm quyền của Business Owner, owner vận hành kho cùng các owner liên quan. Cần thể hiện ranh giới chưa quyết định hoặc tránh mô tả luồng “Sau” như kết luận chính thức.
assets/diagrams/05-business-needs-objectives-and-scope-004-7e890dfc.mmd — REVISE — Nhánh F → H gán mọi nội dung không phải stakeholder input và không cần tạm dùng thành Verification-required claim. Định nghĩa chỉ áp dụng cho nhận định có thể ảnh hưởng scope, pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc vận hành và chưa đủ nguồn. Bổ sung điều kiện ảnh hưởng và nguồn chưa đủ; không ép nội dung ngoài phạm vi vào nhãn này.; Gateway I thiếu tiêu chí bắt buộc của Decision. Prose yêu cầu phương án, tiêu chí, authority và artifact quyết định; nhãn “Có authority và ghi nhận” chỉ thể hiện một phần. Bổ sung đủ điều kiện.; Gateway I không có nhánh “Không”, khiến C, E, G và H trông như đều phải tiến tới Decision. Bổ sung kết quả giữ nguyên nhãn khi chưa hình thành quyết định.; Các cạnh C/E/G/H → I có thể ngụ ý Decision thay thế nhãn nguồn. Prose phân biệt năm nhãn và cấm suy diễn fact, input hoặc assumption thành quyết định. Thể hiện chúng là đầu vào cho việc ra quyết định, không phải trạng thái tự chuyển thành Decision.
assets/diagrams/05-business-needs-objectives-and-scope-005-c9be6951.mmd — REVISE — Luồng Testing → Release ghi “evidence đạt tiêu chí release” và không có nhánh khi tiêu chí chưa đạt, trong khi bảng cho phép kết quả đạt hoặc chưa đạt, defect còn mở và quyết định release theo mức rủi ro. Cần thể hiện điều kiện chuyển tiếp hoặc nhánh quay lại Delivery khi chưa đủ điều kiện.; Luồng Release → Operations ghi “được triển khai và theo dõi”, nhưng exit gate chỉ yêu cầu triển khai và xác định điểm theo dõi sau release. Cần đổi nhãn để không khẳng định hoạt động theo dõi đã xảy ra.; Operations chỉ quay về Discovery, trong khi bảng nêu bằng chứng có thể chuyển về Discovery hoặc Analysis khi cần. Cần thể hiện cả hai đích hoặc ghi điều kiện phân loại quyết định đích.
assets/diagrams/05-business-needs-objectives-and-scope-006-b01dbe41.mmd — REVISE — Luồng QA Lead chỉ đến Business Owner, nhưng bảng yêu cầu bàn giao defect, test evidence và rủi ro phát hành cho Business Owner, Delivery Lead và BA. Bổ sung đủ ba Owner nhận và artifact còn thiếu.; Luồng Operations Owner chỉ đến BA, nhưng bảng yêu cầu bàn giao sự cố, phản hồi vận hành và yêu cầu thay đổi cho BA và Business Owner. Bổ sung Business Owner và yêu cầu thay đổi.; Nút "Architect / Delivery Lead" gộp hai vai trò thành một Owner nhận, làm mờ trách nhiệm riêng. Tách Architect và Delivery Lead hoặc biểu diễn rõ cả hai là người nhận.; Luồng escalation chỉ xuất phát từ BA và dùng nhãn mơ hồ "vượt thẩm quyền". Bảng quy định điểm escalation cụ thể cho từng hướng bàn giao, gồm xung đột mục tiêu, an toàn thực phẩm, tích hợp, dữ liệu cá nhân, phân quyền, requirement mơ hồ, sai lệch VND, tồn kho, truy xuất lô, an ninh, kế toán và thu hồi sản phẩm. Biểu diễn các điều kiện và Owner phù hợp, không ngụ ý mọi escalation đều qua BA.; Các nhãn artifact lược bỏ thành phần quan trọng: BA sang kỹ thuật thiếu phạm vi, giả định và câu hỏi mở; BA sang kiểm thử thiếu ví dụ dữ liệu tổng hợp; QA thiếu rủi ro phát hành; Operations thiếu yêu cầu thay đổi. Bổ sung để ranh giới handoff không sai lệch.; Sơ đồ không thể hiện cấu trúc handoff đã định nghĩa gồm đầu ra, nguồn, người nhận, điều kiện đủ và vấn đề mở. Bổ sung ít nhất các thành phần cần thiết hoặc giới hạn rõ sơ đồ chỉ mô tả hướng bàn giao để tránh tạo cảm giác đây là handoff đầy đủ.
assets/diagrams/05-business-needs-objectives-and-scope-008-0b47ccfb.mmd — REVISE — Sơ đồ biến bốn nhóm cần kiểm kê thành chuỗi bước tuyến tính, trong khi phần văn xuôi không quy định thứ tự Kiến thức tiền đề → Bằng chứng → Source artifact → Canonical ID. Cần thể hiện chúng là các nhóm input cùng hỗ trợ việc xác định business need, objective và scope, hoặc bổ sung căn cứ văn xuôi cho quan hệ tuần tự.; Nhãn "Source artifact canonical" mơ hồ và không khớp thuật ngữ "Source artifact" trong bảng. Cần dùng nhãn cụ thể, nhất quán và tách rõ artifact nguồn với tính canonical của nguồn.; Nhãn "Đọc bằng chứng" mô tả hành động, còn các nút lân cận mô tả loại thông tin; cấu trúc không song song. Cần thống nhất các nút thành nhóm input hoặc thành hành động có căn cứ.; Mũi tên từ "Canonical ID" đến "Business need, objective, scope" hàm ý ID trực tiếp tạo ra ba kết quả, trong khi văn xuôi chỉ nói ID giữ liên kết giữa nhu cầu, quy tắc, dữ liệu, nguồn và artifact. Cần sửa quan hệ để phản ánh vai trò liên kết, không phải quan hệ sinh ra kết quả.
assets/diagrams/05-business-needs-objectives-and-scope-009-2bc4bbc9.mmd — REVISE — Gateway "Có ID hoặc URL canonical?" không bao quát yêu cầu định danh: giữ nguyên Artifact ID, tên tệp và URL canonical. Cần diễn đạt rõ ID cũng phải thuộc registry/metadata và không dùng phép "hoặc" để bỏ qua định danh bắt buộc của artifact.; Luồng thiếu kiểm tra issuer và phân loại nguồn, dù phần prose quy định phân loại quyết định cách dùng. Cần thêm điều kiện phân biệt primary, controlled internal, simulated case, assumption và Verification required trước khi cho phép dùng làm evidence.; Nhãn "Nguồn đúng phạm vi và còn mới?" gộp hai tiêu chí có hậu quả khác nhau, làm mất nhánh xử lý cụ thể. Cần tách kiểm tra phạm vi khỏi tính mới hoặc nêu rõ điều kiện nào thất bại và hành động tương ứng.; Các kết quả "Đánh dấu Verification required" và "Escalate đúng owner" kết thúc mà không nói input chưa được dùng làm requirement/evidence cho đến khi xác minh. Cần thể hiện trạng thái chờ và cấm tiếp tục dùng làm căn cứ.; Nhánh thành công "Dùng làm evidence có truy vết" có thể cho phép simulated case, assumption hoặc controlled internal xác nhận vận hành Nova Foods, trái safe use boundary. Cần giới hạn kết quả theo loại nguồn và phạm vi được phép.
assets/diagrams/05-business-needs-objectives-and-scope-010-1277cd25.mmd — REVISE — Nhãn “Nhân nhãn Verification required” sai từ; sửa thành “Gắn nhãn Verification required”.; Gateway “Đủ thẩm quyền và xác minh?” nhập nhằng giữa thẩm quyền nguồn, thẩm quyền người xác minh và trạng thái xác minh; cần tách hoặc ghi rõ điều kiện quyết định.; Sơ đồ bỏ vai trò Legal Owner, Accounting Owner và domain owner trong bước xác minh; cần thể hiện chuyển điểm chưa xác minh đến đúng owner.; Nhánh “Có” chưa thể hiện đầu vào gồm nguồn, giá trị mô phỏng, trạng thái kiểm tra và điểm chưa xác minh như Decision đã nêu; cần phản ánh artifact đầu ra cụ thể.; Nhánh “Không” dừng ở cấm tạo rule hoặc cấu hình ERP, nhưng thiếu trạng thái chờ xác minh và khả năng quay lại phân tích sau khi owner xác nhận; cần thể hiện vòng đời điểm chưa xác minh.
assets/diagrams/05-business-needs-objectives-and-scope-011-60076a75.mmd — REVISE — Luồng từ biểu mẫu đến kiểm tra và tạo đơn ERP ngụ ý tích hợp trực tiếp, trái với quyết định phạm vi phương án 2 dùng tệp bảng tính trung gian. Phải thể hiện bước xuất, nhập hoặc tiếp nhận tệp trước khi kiểm tra.; Nút D gộp Business Owner, Architect, Accounting Owner và QA thành một tuyến escalation, làm sai khác thẩm quyền riêng được nêu trong bảng. Phải gắn từng loại vấn đề với vai trò xác nhận tương ứng.; Nhánh Có tại nút C kết thúc mà không có kết quả hoặc đường quay lại phân tích. Phải thể hiện trạng thái chờ xác minh, quyết định dừng hoặc quay lại sau xác nhận.; Các bước kiểm tra, trả lỗi và tạo đơn không nêu tác nhân hoặc ranh giới hệ thống. Phải phân biệt BA phân tích với chức năng của luồng nhập tệp hoặc ERP mô phỏng.; Nút I chỉ nối từ nhánh tạo đơn thành công, ngụ ý traceability chỉ được cập nhật khi tạo đơn. Phải tách cập nhật artifact phân tích khỏi xử lý giao dịch hoặc cho thấy cả lỗi và kết quả xác minh đều được lưu vết.; Nhãn "Thiếu bằng chứng" quá rộng và không thể hiện điểm chưa xác minh cụ thể là khả năng API ERP; đồng thời API không thuộc quyết định phương án 2. Phải nêu điều kiện xác minh phù hợp với quyết định đang IN_REVIEW.; Nhãn "Escalate" không song song ngôn ngữ với phần còn lại và chuỗi tên vai trò thiếu dấu phân cách. Phải dùng nhãn tiếng Việt, cụ thể, có quan hệ rõ giữa vấn đề và người xác nhận.
assets/diagrams/05-business-needs-objectives-and-scope-012-8691acfa.mmd — REVISE — Các mũi tên B --> C và B --> D ngụ ý NOVA-SCP-001 và NOVA-SNR-001 được tạo tuần tự từ NOVA-BNO-001; phần văn bản chỉ xác định ba artifact và liên kết traceability, không xác nhận dependency này. Cần bỏ quan hệ tuần tự hoặc chỉ thể hiện quan hệ được văn bản xác nhận.; TRACEABILITY_ID_REGISTRY phải liên kết cả NOVA-BNO-001, NOVA-SCP-001 và NOVA-SNR-001, nhưng sơ đồ không có liên kết trực tiếp từ NOVA-BNO-001 đến registry. Cần thể hiện đủ ba liên kết.; Evidence nguồn mô phỏng chỉ nối với NOVA-BNO-001, trong khi nghĩa vụ traceability yêu cầu liên kết cả ba artifact với nguồn và Stakeholder Need Register phải ghi nguồn của need. Cần thể hiện nguồn cho các artifact liên quan hoặc tránh mô tả luồng nguồn không đầy đủ.; Downstream review input mơ hồ, không chỉ rõ artifact kế tiếp, actor nhận hoặc loại review. Cần dùng nhãn cụ thể được section xác nhận hoặc loại bỏ node này.; Sơ đồ không thể hiện trạng thái chung IN_REVIEW và dễ khiến đầu ra cuối được hiểu là đã sẵn sàng cho bước tiếp theo. Cần biểu thị rõ đây chỉ là input đang review, không phải APPROVED, BASELINED, compliant hay production-ready.
assets/diagrams/05-business-needs-objectives-and-scope-013-c34a8dbd.mmd — REVISE — Chuỗi A → B ngụ ý dữ liệu từ phiếu nhận hàng được chuyển vào Excel, nhưng phần prose chỉ xác nhận hai facts riêng: mã lô được ghi trên phiếu giấy và Excel tổng hợp theo mã hàng. Cần thể hiện đây là hai trạng thái quan sát liên quan, không khẳng định luồng dữ liệu chưa có bằng chứng.; Nút D chỉ ghi ID nên không thể hiện Underlying Need bắt buộc: cần biết số lượng tồn theo từng lô. Cần làm rõ nhu cầu gắn với BUS-NEED-NF-001.; Các cạnh từ D đến CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES không nêu loại quan hệ, dễ bị hiểu là đầu ra hoặc phụ thuộc triển khai thay vì Related artifact. Cần gắn nhãn quan hệ cụ thể.; Sơ đồ mô tả traceability nhưng bỏ Evidence và Open verification, làm chuỗi trông như kết luận đã được xác minh. Cần thể hiện Project assumption và điểm cần xác minh về thời hạn lưu vết lô, hoặc giới hạn rõ sơ đồ chỉ minh họa fact–need–related artifact.
assets/diagrams/05-business-needs-objectives-and-scope-014-e87a99fb.mmd — REVISE — Nhánh IN_REVIEW --> Draft chỉ nêu thiếu bằng chứng hoặc lịch sử thay đổi, bỏ sót trường hợp không đạt về nhận dạng, phạm vi, truy vết và khả năng đọc. Sửa nhãn để bao quát mọi kiểm tra không đạt trong bảng.; Chuyển tiếp Draft --> IN_REVIEW: metadata + traceability đủ không được phần prose xác lập như điều kiện chuyển trạng thái và bỏ qua các yêu cầu nhận dạng khác như filename canonical, phiên bản và ngày. Sửa theo điều kiện được nêu đầy đủ hoặc bỏ chuyển tiếp này.; Trạng thái DownstreamReviewReady không xuất hiện trong prose. Phần prose chỉ nói artifact được chuyển sang downstream review sau khi đạt cổng. Đổi thành kết quả hoặc bước có tên bám sát downstream review, không phát minh trạng thái readiness.; Nhánh trả về không thể hiện người nhận xử lý dù bảng quy định trả về người soạn. Gắn hành động trả về người soạn vào nhãn chuyển tiếp.; DownstreamReviewReady --> [*] dễ ngụ ý quy trình kết thúc sau cổng chất lượng, trong khi cổng chỉ cho phép chuyển sang downstream review và không tạo approval, baseline, tuân thủ pháp lý hay production readiness. Thể hiện rõ ranh giới chuyển giao, không dùng kết thúc quy trình gây hiểu sai.
assets/diagrams/05-business-needs-objectives-and-scope-015-51c4198e.mmd — REVISE — Nhãn "PM Product Owner" gộp hai vai trò mà prose phân biệt: Product Owner tối ưu giá trị sản phẩm, PM quản lý giao hàng. Cần tách vai trò hoặc ghi rõ trách nhiệm riêng.; Các cạnh từ "Business Needs Objectives Scope" đến consumer không thể hiện output cụ thể mà từng vai trò sử dụng, nên gần như lặp lại cột Consumer và làm mất quan hệ chính trong bảng. Cần thể hiện output liên quan trên cạnh hoặc qua node trung gian.; Nhãn nguồn "Business Needs Objectives Scope" bỏ các output được prose nêu: in-scope/out-of-scope, giả định, ràng buộc, stakeholder và tiêu chí thành công. Cần dùng nhãn bao quát đúng tập output hoặc thể hiện các nhóm output.; Các outcome dùng mức độ cụ thể không đồng đều: "Build behavior", "Test basis", "Architecture assessment", "Plan and priority", "Business value review", "Operational readiness", "Specialist review". Cần dùng cấu trúc song song, cụ thể và bám đúng cách dùng trong bảng.; "Plan and priority" mơ hồ và không tự nhiên; prose nêu lập kế hoạch, quản lý backlog, thứ tự giao hàng và trade-off. Cần thay bằng outcome cụ thể được section hỗ trợ.; Nhánh Specialist owners chỉ ghi "Specialist review", không thể hiện ranh giới thẩm quyền và trách nhiệm traceability của BA; omission này có thể khiến người đọc hiểu rằng BA hoặc specialist sở hữu toàn bộ kết luận. Cần thể hiện rõ specialist kết luận phần chuyên môn, BA giữ traceability.
assets/diagrams/05-business-needs-objectives-and-scope-016-47936902.mmd — REVISE — Gateway “Người nhận hiểu đúng phạm vi?” không khớp nhãn nhánh “Có evidence và authority” và “Thiếu evidence hoặc authority”; sửa gateway thành điều kiện kiểm tra evidence và authority, hoặc đổi nhãn nhánh thành câu trả lời trực tiếp cho câu hỏi.; Luồng bỏ qua trạng thái kiểm soát trọng yếu trong prose: IN_REVIEW, phiên bản, ngày, fact, project assumption và Verification required; bổ sung bước kiểm tra các dấu hiệu này trước khi ra quyết định.; Nhánh E -- Không --> A khiến BA gửi lại output mà không ghi nhận câu trả lời hoặc cập nhật traceability; thay bằng bước ghi làm rõ trong artifact kiểm soát rồi mới bàn giao lại.; Kết quả “Ra quyết định trong thẩm quyền” chưa thể hiện điều kiện nội dung đã đủ evidence và được đúng người có authority kết luận; làm rõ điều kiện để tránh biến hiểu đúng phạm vi thành phê duyệt mặc định.; “Escalate đúng owner” còn mơ hồ so với các owner được section nêu; chỉ rõ owner có thẩm quyền hoặc specialist owner phù hợp với vấn đề.
assets/diagrams/05-business-needs-objectives-and-scope-017-76e037be.mmd — REVISE — Luồng bỏ qua điều kiện ERP chấp nhận phiếu xuất vì 120 không vượt tồn tổng 180. Cần thể hiện điều kiện hoặc kết quả kiểm tra này giữa bước xem tồn và tạo phiếu xuất.; Nhãn "Kho tự chọn lô hàng" mơ hồ, không thể hiện việc nhân viên kho xem trạng thái lô trong bảng tính trước khi lấy hàng. Cần nêu rõ chủ thể và hành động kiểm tra trạng thái lô.; Luồng không thể hiện ranh giới dữ liệu quan trọng: trạng thái lô nằm trong bảng tính, còn ERP không lưu liên kết giữa đơn bán và Lot ID thực tế. Cần làm rõ việc ghi nhận ngoài ERP hoặc mất liên kết tại kết quả cuối.; Nhãn "Ghi nhận xuất hàng ngoài liên kết lô trong ERP" khó hiểu và không tự nhiên. Cần diễn đạt cụ thể rằng ERP ghi nhận xuất 120 thùng nhưng không lưu Lot ID đã lấy.; Nhãn dùng "Sales" trong khi phần còn lại dùng tiếng Việt. Cần đổi thành chủ thể cụ thể, nhất quán như "Nhân viên bán hàng".
assets/diagrams/05-business-needs-objectives-and-scope-018-07d5004b.mmd — REVISE — Nhánh override dừng tại trạng thái mơ hồ “Chờ xác nhận ngoại lệ theo quyền được thiết kế”; cần thể hiện chủ thể có thẩm quyền xác nhận và hai kết quả chấp thuận hoặc từ chối.; Nhánh override chưa dẫn tới kết quả nghiệp vụ cuối cùng; cần thể hiện chấp thuận cho phép xác nhận dòng xuất, còn từ chối giữ chặn và yêu cầu đổi lô hoặc xuất một phần.; Gateway “Vai trò override được cấp quyền?” không làm rõ đang kiểm tra quyền của người chọn lô hay người phê duyệt ngoại lệ; cần gắn kiểm tra quyền với đúng actor theo phân quyền do Business Owner và Quality Owner chỉ định.; Nhánh “Đổi lô hoặc xuất một phần” không quay lại bước chọn và kiểm tra lô, nên luồng bỏ sót việc áp dụng lại điều kiện hạn dùng cho phương án thay thế; cần nối lại bước chọn lô hoặc kiểm tra điều kiện.; Luồng xác nhận hợp lệ chỉ kiểm tra ngày hết hạn, trong khi bối cảnh nêu điều kiện số lượng khả dụng và C5 về xuất một phần; cần thể hiện ranh giới rằng sơ đồ chỉ mô tả kiểm soát hạn dùng hoặc bổ sung kiểm tra số lượng liên quan.
assets/diagrams/05-business-needs-objectives-and-scope-019-08c5d39e.mmd — REVISE — Nút kiểm tra tổng phân bổ chỉ thể hiện trường hợp 80 + 40 = 120, không có nhánh khi tổng phân bổ khác lượng đơn. Bổ sung nhánh không xác nhận phân bổ và xử lý ngoại lệ theo WRK-BR-003.; Sơ đồ dùng ID lô nhưng không thể hiện yêu cầu lưu ID lô trên từng dòng phân bổ. Bổ sung bước lưu hai dòng phân bổ kèm lotId để phản ánh WRK-BR-004.; Nhánh thiếu hàng ghi ghi nhận thiếu hàng như hành vi xác định, trong khi cách xử lý giao thiếu còn chờ Business Owner và Warehouse Owner xác nhận. Đổi nhãn để chỉ thể hiện không xác nhận phân bổ và chuyển xử lý thiếu hàng sang trạng thái chờ quyết định.; Điểm kết thúc PROPOSED thiếu ranh giới quản trị quan trọng. Thể hiện rõ trạng thái này chờ Business Owner và Warehouse Owner xác nhận, không phải phân bổ đã phê duyệt.
assets/diagrams/05-business-needs-objectives-and-scope-020-08a54dc4.mmd — REVISE — Các phụ thuộc TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY không có đường dẫn tệp hoặc định danh canonical duy nhất; bổ sung tham chiếu tệp chính xác để phù hợp định nghĩa nguồn chân lý canonical.; Phần văn xuôi không xác nhận năm nguồn upstream cụ thể đều cấp dữ liệu cho Section 9; bổ sung căn cứ trong phần hoặc loại bỏ quan hệ không được hỗ trợ.; Nhãn Section 9 phụ thuộc đánh số dễ thay đổi và không nêu tên mục; dùng tên mục cụ thể kèm số mục nếu cần.; Nhãn handbook chapter khác và templates và completed artifacts quá rộng, không xác định artifact hoặc ranh giới phụ thuộc; liệt kê nhóm đích có định danh cụ thể hoặc thu hẹp nhãn.; Sơ đồ thể hiện F như trung gian duy nhất giữa mọi nguồn canonical và mọi artifact downstream, nhưng văn xuôi chỉ yêu cầu artifact liên kết trực tiếp tới nguồn canonical; sửa quan hệ hoặc bổ sung giải thích rằng Section 9 sở hữu dependency map và downstream chỉ tham chiếu map này.
assets/diagrams/05-business-needs-objectives-and-scope-021-6a662a26.mmd — REVISE — Thiếu liên kết REQ–TC. Bảng xác định TC là bằng chứng kiểm tra cả AC và REQ, nhưng sơ đồ chỉ nối TC với AC, BR và DATA/API. Bổ sung liên kết trực tiếp giữa REQ và TC.; Mũi tên không nêu ý nghĩa nên quan hệ BR → REQ và REQ → DATA/API dễ bị hiểu là luồng xử lý hoặc phụ thuộc một chiều, trong khi phần văn xuôi chỉ xác lập quan hệ truy vết. Gắn nhãn quan hệ hoặc quy ước rõ chiều truy vết.
assets/diagrams/05-business-needs-objectives-and-scope-022-13a5fe0b.mmd — REVISE — Luồng chỉ liệt kê artifact phụ thuộc, không thể hiện hành động đánh giá và cập nhật nhất quán. Đổi nhãn các bước C–E thành hành động cụ thể nhận diện, đánh giá hoặc cập nhật artifact.; "Review có ghi nhận" mơ hồ và không thể hiện yêu cầu quản trị nêu trong prose. Làm rõ kết quả phải ghi nhận version, lịch sử thay đổi và danh sách artifact bị ảnh hưởng.; "Nguồn canonical đổi / CANONICAL_DATA_DICTIONARY" thu hẹp khái niệm thành một nguồn dữ liệu cụ thể nhưng prose áp dụng cho mọi nguồn phụ thuộc. Dùng nhãn nguồn phụ thuộc đổi, trừ khi CANONICAL_DATA_DICTIONARY đã được định nghĩa trong ngữ cảnh trước.; Sơ đồ kết thúc ở review nhưng không thể hiện điều kiện an toàn: mọi artifact phụ thuộc đã được nhận diện, đánh giá và cập nhật nhất quán. Bổ sung kết quả hoặc điều kiện hoàn tất này.
assets/diagrams/05-business-needs-objectives-and-scope-023-d83e7e03.mmd — REVISE — DecisionRecorded --> Configurable mâu thuẫn quyết định hiện tại là không cấu hình. Chỉ cho phép cấu hình sau khi quyết định có thẩm quyền xác nhận quy tắc, phạm vi, ngoại lệ và ảnh hưởng đơn đang xử lý.; Điều kiện có quyết định được ghi nhận quá rộng. Phải nêu quyết định từ Business Owner và xác nhận ảnh hưởng kế toán từ Accounting Owner; việc ghi nhận đơn thuần không đủ thẩm quyền.; SafeBoundary không thể hiện ranh giới phục hồi đã nêu: dừng cấu hình, giữ bản nháp và nhãn Verification required, ghi tác động chưa quyết định, chuyển đúng vai trò, giữ lịch sử, không đặt APPROVED, không tạo quyết định hồi tố.; SafeBoundary --> DraftNeed: bổ sung nguồn và vai trò quyết định bỏ qua bước xác minh và quyết định có thẩm quyền. Điều chỉnh luồng để việc bổ sung bằng chứng không tự đưa nhu cầu về trạng thái nháp như đã xử lý xong.; Sơ đồ bỏ trạng thái artifact IN_REVIEW và không phân biệt trạng thái kiểm soát tài liệu với trạng thái sẵn sàng cấu hình. Bổ sung hoặc ánh xạ rõ trạng thái để tránh hiểu DecisionRecorded là phê duyệt.; Sơ đồ bỏ nhánh kết quả khi quyết định bác bỏ ngưỡng, thay đổi chính sách hoặc tiếp tục giữ Verification required. Thêm kết quả không cấu hình để phản ánh phương án đã chọn và ngoại lệ quyết định.
assets/diagrams/05-business-needs-objectives-and-scope-024-cec695bc.mmd — REVISE — Gateway “Có actor, điều kiện, kết quả đo được?” không phản ánh đủ tiêu chí trong prose: phạm vi giao dịch, ngưỡng ngày, ngoại lệ và thời điểm đánh giá. Cần sửa tiêu chí để bao phủ điều kiện kiểm thử đã nêu.; Gateway “Có ID nguồn canonical và owner?” gây hiểu sai rằng phải có ID mới. Prose yêu cầu không gắn ID khi registry chưa cấp; chỉ cần liên kết artifact canonical và giữ Verification required. Cần tách kiểm tra nguồn, owner và trạng thái ID.; Gateway “Notation được gọi đúng chuẩn?” cùng nhánh “Dùng sai ký pháp” không có cơ sở trong section và không liên quan quyết định về ngưỡng hạn dùng. Cần bỏ hoặc thay bằng kiểm tra được prose hỗ trợ.; Diagram không chỉ rõ owner quyết định: Business Owner, Quality/Food-safety Owner và vai trò pháp lý phù hợp. Cần thể hiện BA chỉ giữ traceability và nhãn xác minh, không tự đặt ngưỡng.; Nhánh “Ghi câu hỏi và Verification required” thiếu bước chuyển câu hỏi tới đúng owner và thiếu các nội dung phải xác nhận. Cần nêu phạm vi giao dịch, ngưỡng ngày, ngoại lệ và thời điểm đánh giá.; Vòng lặp I --> A mơ hồ: không cho biết sự kiện hoặc bằng chứng nào cho phép cập nhật draft. Cần thể hiện chỉ sửa requirement sau khi owner cung cấp quyết định và nguồn xác minh.; Kết quả “Đủ điều kiện review” quá chung, không thể hiện trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07 hoặc các liên kết canonical phải giữ. Cần dùng outcome cụ thể phù hợp artifact.; Diagram bỏ ranh giới pháp lý quan trọng: không được gọi vấn đề là lỗi tuân thủ khi Legal Owner chưa xác minh, và Luật An toàn thực phẩm không đủ để suy ra ngưỡng ERP. Cần có nhánh hoặc boundary thể hiện giới hạn này.; Diagram bỏ hậu quả của quyết định sai: chặn xuất hàng hợp lệ hoặc cho phép giao dịch chưa được phê duyệt. Cần thể hiện risk để giải thích vì sao không được biến giả định thành quyết định.
assets/diagrams/05-business-needs-objectives-and-scope-025-ae34caa4.mmd — REVISE — Thiếu Assumption dù phần văn bản yêu cầu tách riêng fact, assumption, inference, unknown và decision required. Bổ sung assumption cùng tác động nếu sai và liên kết nó với recommendation.; Luồng Recommendation đi thẳng đến Decision record, không thể hiện decision owner hoặc authority ra quyết định. Bổ sung bước quyết định bởi authority phù hợp; Senior BA chỉ ghi nhận.; Nút Xác minh bởi authority phù hợp chỉ nhận đầu vào từ Unknown, khiến inference, assumption và recommendation không cần xác minh. Thể hiện rõ đối tượng cần xác minh và vai trò chịu trách nhiệm.; Nút Decision record không nêu decision, decision owner, trạng thái bằng chứng và artifact liên kết như yêu cầu trong bảng. Làm nhãn hoặc cấu trúc luồng cụ thể hơn.; Kết quả chỉ thể hiện IN_REVIEW khi thiếu approval reference, nhưng không thể hiện điều kiện chuyển trạng thái khi có approval hợp lệ. Bổ sung gateway theo sự tồn tại của approval reference và đúng authority, không ngụ ý Decision record tự tạo approval.; Thiếu consequence if wrong và rủi ro còn lại, trong khi văn bản coi đây là mắt xích cần truy ngược của khuyến nghị có thể bảo vệ. Bổ sung kết quả hoặc nhánh ghi nhận hậu quả nếu quyết định sai.; Nhãn authority phù hợp mơ hồ. Chỉ rõ authority theo loại quyết định: Business Owner, Quality Owner, Architect hoặc Legal Owner khi được kích hoạt.
assets/diagrams/05-business-needs-objectives-and-scope-026-4b62f995.mmd — REVISE — Gateway chỉ kiểm tra template ID và filename, nhưng prose yêu cầu cả mục đích dùng và version đang review. Bổ sung đủ bốn điều kiện vào gateway.; Sơ đồ bỏ sót điều kiện template mới phải được đăng ký hợp lệ trước khi chapter liên kết. Thể hiện điều kiện này trong luồng hoặc gateway.; Bước "Kiểm tra owner, consumer, quality gate" không được section hỗ trợ và xuất hiện sau khi đã tham chiếu. Xóa bước này hoặc bổ sung prose làm căn cứ và đặt kiểm tra trước hành động liên kết.; Nhãn "Tham chiếu đúng ID và đường dẫn" không bao quát mục đích dùng và version, đồng thời đổi "filename" thành "đường dẫn" không có căn cứ rõ. Giữ thuật ngữ canonical filename và nêu đủ tiêu chí.; Nhánh "Không" chỉ cấm tạo ID hoặc filename mới nhưng không nêu kết quả chính: không liên kết chapter. Làm rõ outcome này.
assets/diagrams/05-business-needs-objectives-and-scope-027-aa5475f4.mmd — REVISE — Nhãn "Chapter section 12 draft" không được phần văn xuôi xác lập; dùng phạm vi được hỗ trợ là bản nháp chapter hoặc nêu rõ nguồn canonical xác nhận section 12.; Actor "Principal IT Business Analyst / Technical Curriculum Author" không được phần văn xuôi xác lập; thay bằng owner biên tập được governance metadata chỉ định hoặc bổ sung căn cứ ownership.; Nhãn "Escalate đúng owner" mơ hồ; chỉ rõ owner được tra từ governance metadata upstream và phân biệt escalation với approval.; Luồng từ "Authority required" đi thẳng qua "Recheck cross-file" đến handoff, không thể hiện trường hợp chưa có quyết định authority. Bổ sung điều kiện resolved/unresolved; issue chưa giải quyết phải được giữ trong issue log và không được mô tả như đã phê duyệt hoặc baseline.; Diagram không thể hiện ba trạng thái review quan trọng trong bảng: Pass, Verification required và Open issue. Bổ sung gateway hoặc outcome cho verification, mismatch đã sửa và issue còn mở.; Bước "So khớp metadata corpus" quá rộng và chồng lấn với bước kế tiếp; nêu cụ thể metadata/version/status/date/case-study boundary, đồng thời giữ ID, filename, business rules, data terms và legal-source boundary thành phạm vi kiểm tra rõ ràng.
assets/diagrams/06-requirements-foundations-001-086293e5.mmd — REVISE — Quan hệ kết quả sai chủ thể: sơ đồ cho thấy “120 thùng NF-MANGO-1L” làm tồn khả dụng tăng, trong khi sự kiện “ghi nhận nhập kho đã xác nhận” mới tạo kết quả nghiệp vụ. Cần nối hành động hoặc sự kiện ghi nhận với outcome.; Quan hệ tham chiếu mơ hồ: sơ đồ cho thấy hàng hóa tham chiếu lệnh sản xuất, nhưng prose quy định giao dịch nhập kho tham chiếu lệnh sản xuất. Cần gắn MO-SIM-20260807-01 với giao dịch hoặc sự kiện ghi nhận.; Sơ đồ gần như lặp lại bảng Actor–Action–Object–Outcome, chưa thể hiện Evidence hoặc chuỗi truy vết từ sự kiện thực tế qua lệnh sản xuất tới thay đổi tồn kho. Cần bổ sung quan hệ truy vết để tạo giá trị giải thích.; Nhãn Kết quả cần có chưa phản ánh điều kiện xác nhận nêu trong prose. Cần diễn đạt rõ tồn khả dụng tăng sau khi việc nhận thành phẩm được xác nhận, tránh ngụ ý mọi thao tác ghi nhận đều tự động tạo outcome hợp lệ.
assets/diagrams/06-requirements-foundations-002-8e2fea15.mmd — REVISE — Nhãn "Chức năng hoàn thành" khẳng định trạng thái hoàn thành dù prose chỉ mô tả Developer có thể triển khai theo cách tự suy luận. Cần đổi thành kết quả cụ thể như triển khai theo cách hiểu riêng, không hàm ý đã đáp ứng requirement.; Nhãn "Requirement rõ outcome và điều kiện" còn trừu tượng. Cần nêu outcome quan sát được: tồn khả dụng của NF-MANGO-1L tại WH-FG-HCM tăng 120 thùng sau ghi nhận thành công.; Nhánh requirement rõ bỏ mất ranh giới quyết định và ownership, trong khi authority và governance là phần trọng yếu của section. Cần thể hiện Business Owner, Warehouse Owner, Architect và QA giữ đúng phạm vi quyết định hoặc kiểm tra.; Kết quả "Giảm ambiguity và governance risk" trộn hai kết quả nhưng sơ đồ chỉ thể hiện cơ chế giảm diễn giải và cải thiện kiểm thử; chưa thể hiện cơ chế giảm governance risk. Cần thêm luồng quyền quyết định hoặc bỏ phần governance khỏi kết quả.; Hai nhánh chưa song song: nhánh mơ hồ kết thúc bằng hậu quả, còn nhánh rõ kết thúc bằng lợi ích tổng quát. Cần dùng cấu trúc song song từ requirement đến xây dựng, kiểm thử và outcome để so sánh trực tiếp.; Nhãn pha trộn tiếng Việt và tiếng Anh như "outcome", "ambiguity" và "governance risk" làm giảm tính cụ thể. Cần dùng thuật ngữ nhất quán với prose hoặc diễn đạt tiếng Việt rõ nghĩa.
assets/diagrams/06-requirements-foundations-003-86a8e837.mmd — REVISE — Bước kiểm tra bỏ điều kiện “tại kho được chọn”. Sửa nhãn B thành kiểm tra tồn khả dụng của từng dòng tại kho được chọn.; Nhánh lỗi ghi “số lượng thiếu”, không khớp prose yêu cầu hiển thị “số lượng yêu cầu” và “số lượng khả dụng”. Sửa nhãn F để nêu đủ ba trường: mã hàng, số lượng yêu cầu, số lượng khả dụng.
assets/diagrams/06-requirements-foundations-004-71d3fe02.mmd — REVISE — Gateway “Có bằng chứng kiểm tra được?” đặt sai tiêu chí ưu tiên: stakeholder input và decision cũng có thể có bằng chứng nhưng không trở thành verified fact. Cần phân loại bản chất phát biểu trước, rồi kiểm tra bằng chứng tối thiểu của loại tương ứng.; Gateway “Đã chọn phương án bởi đúng authority?” chưa đủ điều kiện nhận diện Decision. Cần thể hiện lựa chọn giữa các phương án theo tiêu chí, đúng thẩm quyền và có artifact ghi nhận.; Nhánh mặc định “Verification required” mở rộng sai định nghĩa. Chỉ claim có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc thiết kế và chưa đủ chứng cứ mới thuộc loại này; phát biểu không khớp loại nào cần nhánh xử lý riêng hoặc tiêu chí giới hạn rõ.; Diagram bỏ qua trường hợp bằng chứng chỉ xác minh việc stakeholder đã phát biểu, không xác minh nội dung phát biểu. Cần tránh đường đi khiến bằng chứng nguồn bị hiểu thành bằng chứng tính đúng.
assets/diagrams/06-requirements-foundations-005-4f465936.mmd — REVISE — Nhãn Testing → Release thêm điều kiện “defect được ghi theo mức độ”, nhưng phần prose không quy định phân mức defect. Bỏ nội dung này hoặc thay bằng kết quả test, defect và phạm vi chưa kiểm tra được ghi nhận.; Nhãn Testing → Release bỏ điều kiện quan trọng “không gọi đạt khi test basis thiếu”. Bổ sung điều kiện này để tránh biểu diễn sai cổng phát hành.; Nhãn Release → Operations dùng cụm mơ hồ “theo kiểm soát áp dụng” và không thể hiện trạng thái phát hành thực tế hoặc giới hạn không suy ra approval từ deploy. Thay bằng outcome cụ thể bám bảng.; Nhãn Analysis → Delivery không thể hiện dependency, assumption và verification required còn mở phải được ghi riêng. Bổ sung ngoại lệ mở vì đây là ranh giới quan trọng của build basis.; Nhãn Operations → Discovery thể hiện đúng vòng phản hồi nhưng bỏ nguyên tắc không sửa requirement cũ im lặng. Bổ sung ràng buộc này hoặc diễn đạt tín hiệu mới phải được ghi thành input Discovery mới.
assets/diagrams/06-requirements-foundations-006-6f627adf.mmd — REVISE — Thiếu escalation từ Release và Operations dù bảng nêu rủi ro vận hành, truy vết thực phẩm, dữ liệu cá nhân và rollback. Bổ sung nhánh từ R hoặc O tới đúng authority owner.; Nhãn Correct authority owner mơ hồ, không thể hiện các authority pháp lý, kế toán, bảo mật, dữ liệu cá nhân, an toàn thực phẩm và vận hành đã nêu. Thay bằng owner cụ thể hoặc phân nhóm authority rõ ràng.; Node Delivery gộp Architect + Delivery Lead, nhưng bảng xác định Delivery Lead là upstream owner của handoff sang testing. Phân biệt vai trò quyết định kiến trúc với vai trò bàn giao build để tránh hiểu sai ownership.; Sơ đồ không thể hiện điều kiện handoff cốt lõi: owner trước xác nhận đầu vào đủ và owner sau xác nhận artifact dùng được. Bổ sung checkpoint hoặc nhãn điều kiện tại mỗi handoff.; Các nhãn escalation dùng cấu trúc không song song và trộn mức khái quát: ambiguity or authority conflict, security or architecture impact, acceptance dispute. Chuẩn hóa thành điều kiện escalation cụ thể, phù hợp bảng.
assets/diagrams/06-requirements-foundations-008-addb19f5.mmd — REVISE — Nhãn "Câu hỏi BA" mơ hồ: không thể hiện BA đang xác định hoặc kiểm tra điều gì. Cần đổi thành bước hành động cụ thể, phù hợp với prose, như xác định phạm vi, evidence và nguồn tham chiếu.; Sơ đồ cho thấy bốn input trực tiếp tạo ra requirement có traceability, nhưng prose chỉ giải thích rõ vai trò truy vết của source artifact và canonical ID. Cần thể hiện quan hệ truy vết cụ thể hoặc tránh ngụ ý mọi input đóng vai trò giống nhau.; Luồng thiếu chủ thể thực hiện bước phân tích. Vì hành động thuộc BA và ownership có ý nghĩa, cần gắn BA với bước xử lý thay vì chỉ dùng danh từ "Câu hỏi BA".
assets/diagrams/06-requirements-foundations-009-3f7f3bc9.mmd — REVISE — Gateway “Còn hiệu lực và không mâu thuẫn?” gộp câu 3 và 4 nhưng chỉ có một nhánh “Không”, khiến input hết hiệu lực tự động bị loại như input mâu thuẫn. Prose chỉ quy định câu 1, 2 hoặc 4 trả lời “không” thì không đủ điều kiện tạo requirement. Tách hai tiêu chí và thể hiện đúng hậu quả của từng tiêu chí.; Nhãn “Phân loại: fact, assumption, hoặc evidence” không khớp tiêu chí thứ năm trong prose: “fact, assumption hay Verification required”. Thay “evidence” bằng “Verification required” hoặc làm rõ evidence là loại nguồn, không phải trạng thái xác minh.; Nhánh “Gắn Verification required” chỉ xuất hiện sau gateway hiệu lực/mâu thuẫn, trong khi prose định nghĩa trạng thái này rộng hơn: mọi điểm chưa đủ bằng chứng hoặc cần thẩm quyền chuyên môn. Mở rộng điều kiện dẫn đến trạng thái này và tránh dùng nó cho trường hợp mâu thuẫn vốn bị loại theo quy tắc rõ ràng.
assets/diagrams/06-requirements-foundations-010-7fa501fd.mmd — REVISE — Gateway thiếu điều kiện approval hoặc baseline hợp lệ. Thêm kiểm tra này trước khi cho phép dùng đầu vào làm cơ sở tạo requirement bắt buộc.; Nhãn "Owner đúng thẩm quyền?" mơ hồ giữa xác định đúng owner và đã được owner xác nhận. Sửa nhãn để thể hiện yêu cầu xác nhận của Business Owner, Data Owner, Domain Owner hoặc Legal Owner tương ứng.; Nhánh E dừng tại "Được dùng làm evidence", không nêu ranh giới evidence chưa xác minh. Nối nhánh này tới kết quả giữ traceability nhưng không suy diễn requirement bắt buộc nếu chưa có xác nhận.; Sơ đồ bỏ sót ngoại lệ trọng yếu của INP-NF-008: URL đã kiểm nhưng chưa có kết luận Legal Owner. Thể hiện nguồn hợp lệ không đồng nghĩa kết luận pháp lý hợp lệ.; Điều kiện freshness chỉ ghi "rõ" thay vì tiêu chí cụ thể "còn mới tại 2026-08-07". Dùng nhãn concrete phản ánh đúng tiêu chí.
assets/diagrams/06-requirements-foundations-011-34dc064d.mmd — REVISE — Nút C ghi Chặn tạo phiếu: thiếu tồn kho, trái Current Behavior: ERP kiểm tra tồn kho trước khi xác nhận xuất, không phải trước khi tạo phiếu. Sửa kết quả thành chặn xác nhận xuất do thiếu tồn kho hoặc điều chỉnh luồng theo đúng điểm kiểm tra đã mô tả.; Bước Chuyển Quality Owner xác minh trạng thái lô và vòng lặp cập nhật Released chưa được section xác lập thành quy trình vận hành. Authority chỉ giao Quality Owner xác nhận nghĩa trạng thái; không nói mọi lô không đạt đều được chuyển cho owner này hoặc owner này cập nhật trạng thái. Xóa bước/vòng lặp hoặc bổ sung nguồn prose xác nhận quy trình và chủ thể cập nhật.; Sơ đồ không thể hiện ranh giới luồng chuẩn và ngoại lệ chưa được định nghĩa. Bổ sung nhãn nêu đây là luồng chuẩn, không có quyền bỏ qua; trường hợp ngoại lệ phải dừng để Business Owner và Quality Owner xác định trong artifact kiểm soát.; Nhãn Không hoặc trống đúng logic nhưng che các trạng thái được quyết định nêu rõ: Blocked, Pending hoặc trống. Dùng nhãn cụ thể để giữ traceability với Decision.
assets/diagrams/06-requirements-foundations-012-a0e1325d.mmd — REVISE — Nút F khẳng định "Đủ đầu vào cho downstream review" dù chuỗi chưa thể hiện nội dung tối thiểu, version và owner quyết định. Sửa điều kiện đầu ra để chỉ đạt khi reviewer có nội dung, nguồn, canonical ID, version, lịch sử thay đổi và owner phù hợp.; Chuỗi tuyến tính biến IN_REVIEW thành bước dẫn tới trạng thái đủ đầu vào. Phần prose chỉ định nghĩa đây là trạng thái kiểm soát, không phải bằng chứng đầy đủ, phê duyệt hay baseline. Sửa quan hệ để IN_REVIEW là trạng thái của artifact, không phải điều kiện chứng minh artifact đã đủ.; Nhãn "Gắn canonical ID và nguồn" ghép hai nghĩa vụ khác loại và không thể hiện safe use boundary của nguồn. Tách hoặc làm rõ rằng ID phục vụ truy vết, còn nguồn phải có issuer, version/status, ngày truy cập và giới hạn sử dụng.; Sơ đồ bỏ qua ranh giới thẩm quyền owner, dễ khiến người đọc hiểu Owner curriculum xác nhận nội dung chuyên môn. Bổ sung ranh giới review hoặc điều kiện chuyển tới đúng Business Owner, Quality Owner, Solution Architect, Legal/Compliance Owner, Accounting Owner hay QA.
assets/diagrams/06-requirements-foundations-013-179fe219.mmd — REVISE — Nhánh Không --> Hiển thị lỗi bắt buộc thêm hành vi giao diện chưa được section xác nhận; prose chỉ yêu cầu không thể hoàn tất Goods Receipt. Cần bỏ bước này hoặc bổ sung bằng chứng về thông báo lỗi trong prose.; Nhãn Hiển thị lỗi bắt buộc mơ hồ: không nêu lỗi gì và trường nào gây lỗi. Nếu prose xác nhận hành vi này, cần dùng nhãn cụ thể như thông báo thiếu Lot Number.; Luồng E --> B giả định người dùng quay lại bước nhập toàn bộ Goods Receipt; section không xác nhận điểm quay lại. Cần bỏ vòng lặp hoặc làm rõ bước sửa Lot Number bằng nội dung được prose hỗ trợ.
assets/diagrams/06-requirements-foundations-014-57d05f85.mmd — REVISE — Thiếu cổng kiểm tra phạm vi: thêm điều kiện xác nhận nội dung thuộc phạm vi artifact và không biến giả định thành quy tắc vận hành.; Cổng metadata chỉ hỏi có status và version, nên có thể chấp nhận giá trị sai: ghi rõ Status: IN_REVIEW và Version: v0.9.0.; Cổng traceability chưa bao quát yêu cầu giữ nguyên phân loại nguồn và gắn nhãn cho nội dung nhạy cảm chưa đối chiếu đầy đủ: bổ sung hai tiêu chí này bằng nhãn cụ thể.; Cổng change history thiếu ngày 2026-08-07, lý do thay đổi và tác động: bổ sung đủ tiêu chí.; Nhãn Nguồn, giả định, Verification required truy vết được? ghép các loại kiểm soát khác nhau và diễn đạt mơ hồ: tách hoặc viết lại thành điều kiện song song, cụ thể.; Các nhánh trả về không nêu artifact quay lại bước kiểm tra nào: nối chúng về cổng tương ứng hoặc thể hiện rõ kết quả dừng để tránh quy trình cụt.
assets/diagrams/06-requirements-foundations-015-acb25b45.mmd — REVISE — Diagram duplicates table’s consumer mapping without showing transformation from requirements outputs into distinct downstream work. Add relationship or structure explaining how each consumer converts requirements into build work, test evidence, architecture decisions, release decisions, business validation, operational readiness, or specialist validation.; "Requirements outputs" collapses nine distinct output types into one ambiguous node. Distinguish relevant output categories or state that all listed outputs feed consumer-specific work.; "Architect: design boundary" is narrower and less concrete than section, which covers platform impact, integration, performance, security, service decomposition, data ownership, execution location, dependencies, and constraints. Use concrete outcome aligned with prose.; "Operations: run process" omits preparation, SOP, training, monitoring, support, exception handling, and operational readiness. Correct label or structure to represent operational enablement rather than only process execution.; "Business Owner: business fit" is ambiguous. Section describes validation against business goals, expected value, policy, reporting, decisions, and observable outcomes. Use concrete validation wording.; "Specialist owner: domain check" understates ownership and verification of accounting, legal, food-safety, quality, security, and other specialist constraints. Use concrete specialist-validation wording.
assets/diagrams/06-requirements-foundations-016-4ca9562c.mmd — REVISE — Gateway Trong quyền quyết định? không bao phủ các điều kiện escalation trong bảng như rule mơ hồ, dữ liệu thiếu, nguồn chưa xác minh, rủi ro bảo mật, tác động liên hệ thống hoặc gián đoạn vận hành. Cần thể hiện cả thẩm quyền lẫn điều kiện cần escalation.; Nhãn Không hoặc mâu thuẫn không song song với câu hỏi gateway và không xác định mâu thuẫn giữa những nội dung nào. Cần dùng điều kiện cụ thể, nhất quán với gateway.; Bước Làm rõ hoặc quyết định chuyên môn gộp hai kết quả khác owner và thẩm quyền. Cần phân biệt làm rõ requirement với quyết định thuộc specialist owner hoặc cấp có thẩm quyền.; Cạnh U --> R ngụ ý mọi làm rõ hoặc quyết định quay lại đúng trạng thái IN_REVIEW v0.9.0. Section không hỗ trợ việc giữ nguyên version/state; kết quả có thể là nội dung sửa đổi, approval, baseline hoặc quyết định ngoài requirement. Cần thể hiện trạng thái đầu ra được prose hỗ trợ hoặc bỏ vòng lặp này.
assets/diagrams/06-requirements-foundations-017-650694eb.mmd — REVISE — Nhánh “Không” dẫn đến “Thực hiện trong phạm vi artifact” mâu thuẫn trạng thái IN_REVIEW, vì phần văn xuôi xác định artifact chưa phải baseline hay phê duyệt. Đổi kết quả thành hành động không ngụ ý được phép triển khai, hoặc bổ sung điều kiện phê duyệt được section hỗ trợ.; Luồng bắt buộc mọi câu hỏi làm rõ đi qua “Escalate đúng owner”, trong khi section chỉ yêu cầu owner có thẩm quyền cho quyết định thuộc thẩm quyền hoặc chuyên môn. Tách gateway xác định có cần owner xác nhận hay không.; “BA ghi bằng chứng và tác động traceability” gán trách nhiệm cụ thể cho BA nhưng section chỉ khẳng định artifact là bằng chứng, không quy định BA luôn thực hiện bước này. Bỏ actor hoặc bổ sung căn cứ trách nhiệm trong prose.; “Artifact kiểm soát được cập nhật” mơ hồ về artifact nào, ai cập nhật và kết quả còn IN_REVIEW hay đã được phê duyệt. Dùng nhãn kết quả cụ thể, phù hợp trạng thái và thẩm quyền nêu trong section.; Luồng kết thúc sau cập nhật, thiếu bước người nhận đọc lại artifact đã cập nhật trước khi hành động. Bổ sung vòng quay về bước đọc để tránh tiếp tục dựa trên nội dung cũ.; Nhãn trộn tiếng Việt với “traceability” và “Escalate”, làm giảm tính song song và cụ thể. Dùng thuật ngữ tiếng Việt nhất quán hoặc thuật ngữ đã được định nghĩa trong curriculum.
assets/diagrams/06-requirements-foundations-018-85be86d5.mmd — REVISE — Nút D dùng gateway hỏi điều kiện nhưng chỉ có nhánh Có, làm luồng quyết định bị thiếu nhánh Không. Vì section chưa xác nhận kết quả nghiệp vụ khi không vượt hạn mức, hãy đổi D thành nút so sánh/kết luận cụ thể cho trường hợp hiện tại, không dùng gateway; hoặc bổ sung nhánh Không chỉ khi có nguồn được ủy quyền xác định kết quả.; Nhãn Đặt ON_HOLD_CREDIT mô tả hành động hệ thống chưa được section chứng minh rõ; section chỉ xác nhận trạng thái hiện thấy và phép tính dẫn đến trạng thái. Hãy dùng nhãn kết quả quan sát được như Kết quả hiện tại: ON_HOLD_CREDIT, trừ khi có bằng chứng ERP chủ động đặt trạng thái tại bước này.
assets/diagrams/06-requirements-foundations-019-5d48f6f4.mmd — REVISE — Nhánh D -- Không --> G[Ghi nhận xuất kho] khẳng định mọi dòng không hết hạn được ghi nhận ngay, trong khi SC-INV-EXP-002 yêu cầu xử lý tiếp theo quy tắc tồn kho và cách diễn giải ngày hết hạn còn chờ Quality Owner xác minh. Sửa nhãn hoặc thêm bước thể hiện tiếp tục xử lý theo các quy tắc đã được phê duyệt, không bảo đảm POSTED ngay.; Sơ đồ thể hiện xử lý độc lập từng dòng nhưng bỏ qua giả định quan trọng: hệ thống phải hỗ trợ tách dòng; Architect xác minh khả năng này và Business Owner quyết định tách dòng hay chặn cả phiếu. Bổ sung boundary hoặc ghi chú quyết định chưa xác minh để tránh trình bày O3 như hành vi đã được chấp thuận.; Nhánh thiếu tồn kho chỉ ghi Trả lỗi thiếu tồn kho, không nêu kết quả trạng thái hoặc kết thúc luồng. Bổ sung kết thúc cụ thể, nhưng chỉ nêu không giảm tồn kho hoặc không POSTED nếu section xác nhận hành vi đó; nếu chưa có bằng chứng, đánh dấu cần xác minh.; Nhãn Giữ nguyên tồn kho và trạng thái chưa POSTED mơ hồ về đối tượng trạng thái. Đổi thành nhãn cụ thể cho dòng xuất kho, phù hợp BR-INV-EXP-002: không giảm available_quantity, không tạo bút toán tồn kho, không đặt dòng thành POSTED.
assets/diagrams/06-requirements-foundations-020-12f57597.mmd — REVISE — Gateway chỉ có nhánh Không; thiếu nhánh Có và kết quả được phép phân bổ, nên mô hình không thể hiện đầy đủ BR-NF-INV-001.; Nhãn Chọn LOT-ALM-260801-A không nêu đây là lô ứng viên do ERP kiểm tra; cách viết có thể bị hiểu là lô đã được chọn hoặc phân bổ trước khi xác thực.; Diagram không nêu ERP là chủ thể tính ngưỡng, kiểm tra điều kiện và chặn phân bổ, dù ownership hệ thống quan trọng với yêu cầu.; Luồng gần như lặp nguyên phép tính và kết quả REJECTED đã có trong prose cùng bảng, chưa bổ sung góc nhìn đáng kể ngoài nội dung lân cận.
assets/diagrams/06-requirements-foundations-021-5776eb75.mmd — REVISE — Quan hệ 00_SOURCE_MAP → 01_CURRICULUM_ARCHITECTURE → CHAPTER_MANIFEST không được phần văn xuôi hoặc bảng nguồn canonical xác nhận. Sửa để chỉ thể hiện dependency đã nêu, hoặc bổ sung căn cứ ngoài diagram.; Nút 01_CURRICULUM_ARCHITECTURE không xuất hiện trong danh sách nguồn canonical của section, nên vai trò sở hữu hoặc trung gian còn mơ hồ. Bỏ nút hoặc làm rõ nguồn và quan hệ trong prose.; Quan hệ chương → ART-NF-INV-001 và chính ID này không được phần surrounding section xác nhận. Bỏ artifact hoặc bổ sung mô tả về artifact, loại quan hệ và nguồn quản trị ID.; 00_SOURCE_MAP được bảng mô tả là nguồn chương dùng, nhưng diagram chỉ nối gián tiếp qua architecture và manifest. Sửa quan hệ để không tạo dependency trung gian sai hoặc thiếu.
assets/diagrams/06-requirements-foundations-022-a75bce54.mmd — REVISE — Remove P --> T. Section defines TC-NF-INV-001 as proving AC-NF-INV-001, not testing API-NF-INV-001; extra edge contradicts stated decision.; Remove D --> P unless prose or registry explicitly defines this relation. Section states DATA-NF-INV-001 supports BR-NF-INV-001, not API-NF-INV-001.; Mark API-NF-INV-001 and its R --> P relation as conditional. Prose limits API applicability to cases where API is registered; current diagram presents API as unconditional.
assets/diagrams/06-requirements-foundations-023-7af856c4.mmd — REVISE — Luồng thiếu bước thông báo consumer, dù phần prose xác định không thông báo consumer là thành phần của thay đổi im lặng. Bổ sung bước thông báo consumer bị ảnh hưởng sau phân tích tác động.; Nhãn "Cập nhật liên kết hoặc giữ nguyên" gộp hai kết quả nhưng không nêu điều kiện chọn nhánh. Tách thành gateway dựa trên kết quả phân tích tác động; mỗi nhánh phải dẫn đến cập nhật hoặc giữ nguyên kèm bằng chứng.; Luồng không thể hiện điều kiện "artifact phụ thuộc phải được đánh giá lại trước khi dùng tiếp". Bổ sung điểm kiểm soát chặn sử dụng tiếp cho đến khi hoàn tất đánh giá và review.; Nhãn "Review theo thẩm quyền" mơ hồ về actor và kết quả. Gắn review với Owner hoặc vai trò có thẩm quyền được section hỗ trợ, đồng thời nêu kết quả cho phép dùng tiếp hoặc yêu cầu sửa.; Danh sách artifact phụ thuộc bỏ acceptance criterion và mapping dữ liệu, hai dependency trọng yếu được prose và bảng nêu rõ. Bổ sung hoặc dùng nhãn bao quát không làm mất các dependency này.
assets/diagrams/06-requirements-foundations-024-1ac9942c.mmd — REVISE — Nút quyết định “Xác định lỗi” không có nhánh hoặc điều kiện ra. Bổ sung nhánh theo loại red flag hoặc đổi thành bước xử lý.; Luồng bắt buộc mọi trường hợp qua “Thu thập bằng chứng nguồn”, nhưng bảng chỉ yêu cầu phân biệt bằng chứng với requirement trong trường hợp sao chép lời họp. Chỉ áp dụng bước này cho nhánh phù hợp.; Luồng bắt buộc mọi trường hợp kiểm tra nguồn canonical và traceability, trong khi hành động này chỉ được nêu cho lỗi sửa bản sao. Chỉ áp dụng cho nhánh liên quan hoặc nêu rõ điều kiện kích hoạt.; “Đưa lại trạng thái IN_REVIEW” ngụ ý mọi requirement từng rời trạng thái này và phải quay lại. Phần prose chỉ yêu cầu giữ IN_REVIEW khi chưa có approval; sửa nhãn và điều kiện để không tạo chuyển trạng thái ngoài nội dung.; Sơ đồ bỏ các hành động sửa riêng cho red flag: tách hành vi, bổ sung ngoại lệ, thay từ mơ hồ bằng tiêu chí đo được, và tách nhu cầu khỏi giải pháp. Thể hiện các nhánh sửa tương ứng.; Sơ đồ không thể hiện owner có thẩm quyền hoặc ranh giới trách nhiệm Architect/UX dù prose dùng chúng để quyết định tính hợp lệ và phạm vi thiết kế. Bổ sung owner tại điểm xác nhận hoặc ghi rõ trách nhiệm.; Nhãn “Xác định lỗi”, “bằng chứng nguồn” và “traceability” còn chung chung. Dùng tên red flag, artifact canonical và kết quả kiểm tra cụ thể.
assets/diagrams/06-requirements-foundations-025-014e7e6e.mmd — REVISE — Gateway “Có owner và bằng chứng đủ?” nhập nhằng giữa việc xác định owner và việc owner có thẩm quyền đã ra quyết định. Sửa điều kiện để yêu cầu quyết định hoặc xác minh từ đúng owner, không chỉ sự tồn tại của owner.; Nhãn “owner đúng thẩm quyền” và “Có quyết định được ghi nhận?” làm mất ranh giới thẩm quyền giữa Business Owner, Food-safety Owner và Legal Owner. Sửa luồng để phản ánh Business Owner quyết định nhu cầu vận hành; Food-safety Owner và Legal Owner xác minh nghĩa vụ khi áp dụng.; Trạng thái “IN_REVIEW” không xuất hiện trong prose; prose chỉ quy định trạng thái mở cần xác minh và nhãn “Verification required”. Thay “IN_REVIEW” bằng trạng thái được section hỗ trợ hoặc bổ sung định nghĩa canonical ngoài diagram trước khi dùng.; Nhánh “Có” từ quyết định được ghi nhận đi thẳng đến soạn điều kiện kiểm tra được, dù prose yêu cầu không tạo kết luận pháp lý hoặc an toàn thực phẩm chưa xác minh. Sửa điều kiện để quyết định chỉ mở tiếp luồng khi các xác minh bắt buộc từ đúng owner đã hoàn tất.
assets/diagrams/06-requirements-foundations-026-db9a9db8.mmd — REVISE — Luồng C --> H cho phép requirement trở thành kiểm chứng được ngay sau khi làm rõ ngưỡng, trạng thái và tác nhân, nhưng bỏ qua kiểm tra nguồn và thẩm quyền tại D. Sửa luồng để requirement sau làm rõ vẫn phải qua kiểm tra nguồn và thẩm quyền.; Sơ đồ bỏ ngoại lệ dịch vụ tín dụng không phản hồi, dù section đánh dấu nội dung này là Verification required. Bổ sung nhánh thể hiện trạng thái chưa xác minh và không triển khai hành vi giả định.; Sơ đồ không thể hiện quyền override và vai trò duyệt là rule chưa xác minh. Bổ sung chúng vào nhánh Verification required hoặc dùng nhãn bao quát cụ thể cho ngưỡng, override, vai trò duyệt và lỗi dịch vụ.; Gateway Có nguồn và thẩm quyền? không chỉ rõ owner cần xác nhận. Bổ sung Business Owner, Finance Owner và Architect tại bước xác minh tương ứng để giữ boundary quyết định.; Nhãn Liên kết canonical ID mơ hồ và có thể bị hiểu là tạo hoặc liên kết một ID chung. Đổi thành liên kết REQ-SO-014 tới artifact canonical phù hợp, không tạo ID thay thế.
assets/diagrams/06-requirements-foundations-027-76d5dbb0.mmd — REVISE — Trạng thái IN_REVIEW không được phần văn xuôi định nghĩa. Xóa trạng thái này hoặc thay bằng kết quả được hỗ trợ như tham chiếu artifact đã xác minh.; Bước Kiểm tra owner, consumer, quality gate không có nhánh xử lý khi tiêu chí không đạt. Thêm gateway đạt/không đạt; nhánh không đạt phải dừng sử dụng hoặc chuyển đúng owner để xác minh.; Gateway Nội dung thuộc thẩm quyền chuyên môn? mơ hồ và đảo nghĩa: nhánh Có lại chuyển escalation. Đổi điều kiện thành nội dung vượt thẩm quyền BA hoặc cần owner chuyên môn xác minh, với nhánh song song rõ ràng.; Nhãn escalation owner không xuất hiện trong phần văn xuôi và không xác định owner nào. Dùng các vai trò đã nêu: Business Owner, Legal Owner, Accounting Owner, Security Owner, Architect hoặc QA Reviewer theo phạm vi nội dung.; Nhánh Không tại kiểm tra manifest dẫn thẳng đến dùng artifact canonical nhưng không thể hiện yêu cầu ID và đường dẫn phải được xác minh. Làm rõ chỉ tham chiếu artifact canonical có ID và đường dẫn xác minh; không dùng template chưa đăng ký.; Sơ đồ bỏ kết quả khi owner, consumer hoặc quality gate không rõ, dù đây là boundary quyết định chính. Thể hiện rõ không được dùng artifact cho đến khi các tiêu chí được xác minh.
assets/diagrams/06-requirements-foundations-028-0f302bb0.mmd — REVISE — Sơ đồ lặp lại thứ tự 12 mục trong bảng Quick Reference, chưa bổ sung quan hệ, quyết định hoặc cách tra cứu mới. Cần thể hiện giá trị giải thích vượt ngoài danh sách tuần tự, hoặc bỏ sơ đồ.; Luồng kết thúc tại liên kết artifact nhưng bỏ tiêu chí hoàn tất: đúng đường dẫn và metadata IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Cần thể hiện bước kiểm tra hoàn tất nếu sơ đồ mô tả toàn bộ quy trình tra cứu.; Luồng bỏ ngoại lệ quan trọng cho nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, dữ liệu cá nhân và bảo mật. Cần thể hiện điều kiện gắn nhãn Verification required hoặc project assumption cho đến khi owner có thẩm quyền xác minh.; Nhãn Nova Foods filled artifact, dependency và output trộn tiếng Anh với tiếng Việt và chưa đủ cụ thể. Cần dùng thuật ngữ nhất quán, cụ thể, song song với bảng và prose.; Sơ đồ không thể hiện ranh giới case study: dữ liệu tổng hợp, không phải cấu hình ERP, rule vận hành, bằng chứng tuân thủ, baseline hay approval. Cần đưa ranh giới này vào luồng nếu sơ đồ hướng dẫn cách sử dụng artifact.
assets/diagrams/06-requirements-foundations-029-2457ad1c.mmd — REVISE — Nút "So khớp metadata corpus" quá mơ hồ và bỏ các giá trị bắt buộc: Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh. Sửa nhãn hoặc thêm bước thể hiện việc đối chiếu các giá trị này.; Sơ đồ bỏ ranh giới dữ liệu quan trọng: Nova Foods là case mô phỏng và chỉ dùng dữ liệu tổng hợp. Bổ sung kiểm tra này vào bước source boundary.; Sơ đồ không thể hiện sáu artifact canonical được nêu làm bằng chứng, khiến dependency của hoạt động đối chiếu không rõ. Thể hiện nguồn đối chiếu hoặc dùng nhãn cụ thể bao quát đúng sáu tệp.; Bước "Đính kèm phiếu self-review" không được prose hỗ trợ; prose chỉ yêu cầu tự rà soát trước handoff. Xóa bước này hoặc bổ sung căn cứ trong prose.; Nhãn "Escalate đúng owner" mơ hồ vì section không xác định owner hay quy tắc định tuyến. Dùng nhãn giới hạn theo thẩm quyền được mô tả, hoặc xác định owner trong prose.; Nhánh không có mâu thuẫn kết thúc tại "Giữ Status IN_REVIEW" nhưng không thể hiện handoff sang review, là kết quả được prose nêu. Bổ sung kết quả handoff mà không biến self-review thành phê duyệt.
assets/diagrams/07-user-stories-and-acceptance-criteria-001-8ac0b762.mmd — REVISE — Mũi tên tạo chuỗi xử lý vận hành đã được xác nhận, trong khi phần văn xuôi chỉ xác nhận nhu cầu và user story đang IN_REVIEW. Cần thể hiện đây là quan hệ nhu cầu/kết quả mong muốn, không phải quy trình ERP đã phê duyệt.; Nhãn “ERP ghi nhận đơn bán” khẳng định hành vi hệ thống và trùng ý với “Nhân viên bán hàng tạo đơn”, dù phần Artifact loại trừ thiết kế hoặc hành vi ERP cụ thể. Cần bỏ bước hệ thống chưa được xác nhận hoặc đổi nhãn để giữ đúng mức khái niệm của user story.; Nhãn “Kho thấy đơn chờ kiểm tra” có thể bị hiểu là trạng thái đơn chính thức, trong khi phần loại trừ nói không suy ra trạng thái đơn. Cần diễn đạt thành kết quả mong muốn: kho biết đơn nào cần kiểm tra khả năng đáp ứng.
assets/diagrams/07-user-stories-and-acceptance-criteria-002-e63aa8cf.mmd — REVISE — Chuỗi B → C → D thể hiện “kiểm thử không có chuẩn kiểm tra” là hậu quả của “phát triển sai phạm vi”, trong khi phần văn xuôi xác định nguyên nhân là thiếu acceptance criteria. Cần nối đúng nguyên nhân hoặc tách hai hậu quả song song.; Nhãn “Diễn giải khác nhau” không nêu các bên diễn giải khác nhau, dù khác biệt giữa nghiệp vụ, BA, phát triển, kiểm thử và người dùng là trọng tâm. Cần thể hiện chủ thể hoặc phạm vi khác biệt.; Nhánh A → F ngụ ý nhu cầu chưa rõ tự dẫn đến user story. Cần biểu đạt user story và acceptance criteria là biện pháp làm rõ, không phải kết quả tự nhiên của sự mơ hồ.; Kết quả tiêu cực chỉ nêu “làm lại và tranh chấp trách nhiệm”, bỏ các hậu quả được liệt kê như lỗi phát hiện muộn, sửa thiết kế, sửa mã và viết lại kiểm thử. Có thể gom nhóm, nhưng nhãn phải bao quát đúng rủi ro.
assets/diagrams/07-user-stories-and-acceptance-criteria-003-177f1030.mmd — REVISE — Gateway xuất hiện ngay sau bước nhập phiếu, khiến thời điểm kiểm tra bị hiểu là lúc nhập hoặc lưu. Cần thêm hành động Xác nhận xuất trước gateway để khớp user story và decision.; Nhánh Không chỉ nêu Giữ phiếu ở trạng thái nháp, chưa thể hiện hành động Xác nhận xuất bị từ chối và tồn kho không tự bị trừ. Cần thể hiện đủ hai kết quả này.; Nhánh Có ghi Cho phép xác nhận xuất như kết quả vô điều kiện, trái tiêu chí 4: chỉ cho phép tiếp tục nếu không có điều kiện chặn khác. Cần ghi rõ ngoại lệ này.
assets/diagrams/07-user-stories-and-acceptance-criteria-004-37a59bcb.mmd — REVISE — Nhánh F → H phân loại mọi đầu vào không có nguồn, không phải stakeholder input và không cần dùng tạm thành Verification-required claim. Prose chỉ dành loại này cho mệnh đề có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc cấu hình. Cần thêm điều kiện về phạm vi ảnh hưởng; đầu vào ngoài phạm vi cần kết quả riêng.; Decision không có nhánh phân loại trực tiếp từ đầu vào dù prose định nghĩa đây là loại bằng chứng độc lập. Luồng hiện tại chỉ tạo Decision sau bước xác minh hoặc làm rõ stakeholder input, assumption hay verification-required claim. Cần cho phép nhận diện decision đã được ghi nhận bằng authority và artifact phù hợp.; Gateway K dùng câu hỏi “Có quyết định đúng thẩm quyền?” sau mọi bước J, khiến stakeholder input, project assumption và verification-required claim có vẻ chỉ được đóng bằng decision. Prose yêu cầu các kết quả khác nhau: làm rõ stakeholder input, đóng assumption bằng xác minh, kiểm tra claim qua nguồn hoặc owner. Cần thể hiện kết quả xác minh tương ứng, không ép mọi nhánh qua Decision.; Nhánh K → M gộp nhiều trạng thái thành “Giữ nhãn chưa xác minh”. Nhãn này không chính xác với stakeholder input đã xác định nguồn phát biểu và không đủ cụ thể cho project assumption hoặc verification-required claim. Cần giữ đúng nhãn từng loại cùng trạng thái chưa đóng hoặc chưa đủ bằng chứng.; Nhánh C → I cho phép mọi fact đã xác minh đi thẳng vào story hoặc acceptance criteria. Prose cảnh báo metadata corpus chỉ xác nhận metadata, không xác nhận business rule, cấu hình ERP, baseline hay approval. Cần thể hiện fact chỉ hỗ trợ nội dung trong đúng phạm vi nguồn chứng minh.
assets/diagrams/07-user-stories-and-acceptance-criteria-005-1298e89c.mmd — REVISE — Nhãn Discovery → Analysis ghi "Entry: nhu cầu được ghi nhận" nhưng không thể hiện exit gate Discovery: vấn đề, outcome và điểm chưa biết đã được diễn đạt, kèm nhãn xác minh phù hợp. Cần ghi đúng gate bàn giao giữa hai pha.; Nhãn Analysis → Delivery "story và AC đủ kiểm tra" quá mơ hồ và bỏ điều kiện quan trọng: story không mâu thuẫn với fact đã xác minh, AC có điều kiện–hành động–kết quả, điểm rủi ro còn giữ nhãn xác minh. Cần dùng tiêu chí gate cụ thể.; Luồng Testing thiếu nhánh lỗi hoặc AC thiếu, mơ hồ quay về Analysis. Đây là ngoại lệ và vòng phản hồi được prose nêu rõ; cần thể hiện.; Luồng Operations → Discovery gộp "nhu cầu hoặc sai lệch mới", trong khi prose yêu cầu phân loại phản hồi thành sự cố, cải tiến hoặc nhu cầu mới và chỉ nói nhu cầu mới quay lại Discovery. Cần thể hiện bước phân loại hoặc giới hạn nhãn luồng về nhu cầu mới.; Sơ đồ chỉ gắn một gate cho mỗi chuyển tiếp, làm mờ quan hệ giữa exit gate pha trước và entry gate pha sau. Cần thể hiện nhất quán loại gate hoặc nêu rõ gate bàn giao.; Nhãn Delivery → Testing dùng từ "trace" không đồng nhất với prose tiếng Việt "đối chiếu". Cần dùng thuật ngữ cụ thể, nhất quán.
assets/diagrams/07-user-stories-and-acceptance-criteria-006-ee73201c.mmd — REVISE — Luồng QA chỉ trả kết quả cho BA, trong khi bảng quy định QA bàn giao kết quả xác minh, lỗi và rủi ro còn lại cho Business Owner và BA; thêm Business Owner làm downstream owner để thể hiện đúng quyền chấp nhận rủi ro phát hành.; Nhãn BA → Architect / Technical Lead “Làm rõ khả thi, ràng buộc kỹ thuật” không khớp nội dung bàn giao trong bảng và làm mơ hồ chủ thể làm rõ; đổi nhãn thành nội dung cụ thể gồm user story, acceptance criteria, câu hỏi mở và ràng buộc đã biết.; Các luồng Architect / Technical Lead → Delivery Team và Delivery Team → QA đưa thêm handoff thiết kế, bản xây dựng và thay đổi kỹ thuật nhưng bảng không xác định ownership hoặc nội dung bàn giao tương ứng; bổ sung hỗ trợ trong prose/bảng hoặc bỏ khỏi sơ đồ.; Luồng specialist kết luận trực tiếp cho Business Owner không thể hiện BA nhận kết luận để cập nhật story và traceability; section chỉ xác định BA gửi vấn đề chuyên ngành và giữ nhãn “Verification required”, nên cần làm rõ downstream của kết luận hoặc giới hạn luồng theo nội dung đã xác lập.
assets/diagrams/07-user-stories-and-acceptance-criteria-008-14435e9e.mmd — REVISE — Quan hệ A[Quan sát mô phỏng] --> B[Artifact nguồn] đảo chiều cầu nối suy luận trong prose: quan sát được lấy từ artifact, không tạo ra artifact nguồn. Sửa hướng hoặc cấu trúc để artifact nguồn hỗ trợ quan sát/evidence.; Hai cạnh không nhãn F --- B và F --- E mơ hồ: không cho biết Canonical ID được giữ nguyên để liên kết cùng đối tượng qua artifact và user story. Gắn nhãn quan hệ cụ thể.; Chuỗi Artifact nguồn --> Evidence có thể truy lại chưa thể hiện ranh giới quan trọng rằng evidence không phải kết luận và không chứng minh nguyên nhân. Bổ sung trạng thái hoặc điều kiện ngăn người đọc hiểu evidence tự dẫn đến kết luận.
assets/diagrams/07-user-stories-and-acceptance-criteria-009-55674fb7.mmd — REVISE — Nhánh C -- Không --> S dẫn tới trạng thái STOP: thiếu định danh, nhưng lỗi thực tế là thiếu phân loại nguồn. Cần trạng thái hoặc nhãn kết quả đúng với nguyên nhân.; Gateway Còn mới và nhất quán? gộp hai kiểm tra có hậu quả khác nhau. Nguồn không còn mới thì không được suy ra requirement hiện hành; nguồn mâu thuẫn thì phải dừng phân rã story đến khi xử lý. Cần tách gateway và kết quả tương ứng.; Diagram bỏ kiểm tra khả năng truy vết evidence. Prose yêu cầu URL chính thức hoặc artifact canonical và cấm tạo acceptance criterion bắt buộc khi thiếu evidence. Cần thêm bước kiểm chứng cùng nhánh không đạt.; Nhánh Owner có thẩm quyền? -- Không --> Gắn Verification required và escalation chưa thể hiện yêu cầu escalation đúng vai trò và giới hạn thẩm quyền. Cần nêu kết quả cụ thể hơn.; Kết quả cuối cho phép dùng đầu vào làm evidence ngay sau kiểm tra owner, dù chưa kiểm tra evidence truy vết được. Cần đặt kiểm chứng trước kết quả này.
assets/diagrams/07-user-stories-and-acceptance-criteria-010-31c1e3a4.mmd — REVISE — Luồng B --> E --> F tạo Acceptance Criteria trước khi kiểm tra rule và data đã xác minh, trái với quyết định không thêm Acceptance Criteria vận hành khi nguồn còn IN_REVIEW. Cần đặt cổng xác minh trước bước tạo Acceptance Criteria.; Nhãn Có rule và data được xác minh? không nêu chủ thể xác minh. Cần gắn Business Owner với nhu cầu nghiệp vụ, Data Owner với dữ liệu và Architect với hành vi hệ thống; Legal Owner chỉ tham gia khi có nghĩa vụ pháp lý.; Nhánh Có chỉ dẫn đến Liên kết ID canonical, chưa thể hiện điều kiện nguồn canonical phải chuyển khỏi IN_REVIEW hoặc được chủ sở hữu có thẩm quyền xác nhận. Cần nêu trạng thái hoặc bằng chứng xác minh đủ điều kiện.; Nhánh Không dùng Verification required nhưng không chỉ rõ artifact nào mang nhãn và không thể hiện quyết định giữ User Story ở mức ví dụ học liệu. Cần xác định User Story hoặc Acceptance Criteria mang trạng thái cần xác minh và không trở thành rule bắt buộc.; Sơ đồ bỏ qua kết quả quan trọng khi xác minh thất bại: không thêm tiêu chí về phê duyệt, cập nhật tồn, truy xuất lô hoặc hạch toán. Cần thể hiện ranh giới này để tránh suy diễn hành vi ERP.; Sơ đồ không thể hiện trách nhiệm của Principal IT Business Analyst / Technical Curriculum Author chỉ giữ traceability. Cần phân biệt vai trò truy vết với quyền xác nhận.; Nhãn Input mô phỏng quá rộng so với fact cụ thể. Cần làm rõ đây là ví dụ nhận 500 kgRM-SUGAR-001 vào WH-HCM-01, hoặc ghi rõ input chỉ là fact mô phỏng chưa xác minh.
assets/diagrams/07-user-stories-and-acceptance-criteria-011-3d700a19.mmd — REVISE — Trạng thái DRAFT không được section định nghĩa. Cần bổ sung nguồn nghiệp vụ cho trạng thái này hoặc loại khỏi sơ đồ.; Nhánh DRAFT --> ON_HOLD chỉ mô tả trường hợp ngày giao sau ngày tạo, nhưng không thể hiện kết quả khi điều kiện sai hoặc dữ liệu ngày thiếu/không hợp lệ. Cần thể hiện nhánh còn lại và điểm xử lý ngoại lệ theo rule catalog.; Trạng thái CANCELLED và chuyển tiếp ON_HOLD --> CANCELLED không có facts, decision rule, owner hoặc acceptance criterion hỗ trợ. Cần bổ sung căn cứ nghiệp vụ hoặc loại bỏ.; Chuyển tiếp FULFILLMENT_IN_PROGRESS --> [*] ngụ ý quy trình hoàn tất nhưng không nêu trạng thái hoặc kết quả cuối có thể quan sát. Section chỉ xác nhận kho nhận xử lý. Cần đặt ranh giới sơ đồ tại bước bàn giao cho kho hoặc bổ sung trạng thái hoàn tất có căn cứ.; Nhãn xác nhận điều kiện mở giữ chưa nêu điều kiện, sự kiện hoặc actor xác nhận, trong khi rule catalog còn IN_REVIEW. Cần ghi rõ đây là điều kiện chờ xác nhận và gắn owner có thẩm quyền.; Sơ đồ không thể hiện ràng buộc trọng yếu: ON_HOLD không được tạo yêu cầu xuất kho và tích hợp kho chỉ nhận đơn ở READY_FOR_FULFILLMENT. Cần biểu diễn ranh giới hoặc điều kiện chặn này để tránh hiểu sai.
assets/diagrams/07-user-stories-and-acceptance-criteria-012-0316769e.mmd — REVISE — Traceability link chỉ nối từ User Story, trong khi prose yêu cầu liên kết evidence, need, story, criterion, rule, assumption và điểm cần xác minh. Cần thể hiện đầy đủ phạm vi liên kết hoặc đổi cấu trúc để tránh ngụ ý link chỉ thuộc User Story.; Sơ đồ bỏ TRACEABILITY_ID_REGISTRY, dù section xác định đây là nguồn bắt buộc cấp ID cho User Story, Acceptance Criteria và Decision record. Cần thể hiện dependency cấp ID và không ngụ ý artifact có thể được tạo với ID tự đặt.; Nhãn Evidence hoặc project assumption gộp evidence và assumption thành một nguồn tương đương, trong khi prose phân biệt chúng và yêu cầu assumption có thể cần xác minh. Cần tách hai khái niệm hoặc thể hiện rõ trạng thái xác minh.; Các mũi tên từ Decision record, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY chỉ tới User Story tạo nghĩa dependency không được giải thích và bỏ quan hệ tác động tới Acceptance Criteria, rule, test basis hoặc tích hợp/báo cáo đã nêu trong bảng. Cần chỉnh quan hệ để bám đúng nghĩa traceability/tác động.; Sơ đồ không thể hiện trạng thái IN_REVIEW, owner xác nhận/xác minh, hoặc nghĩa vụ giữ lịch sử thay đổi. Nếu sơ đồ nhằm tóm tắt toàn bộ mô hình output, đây là thiếu sót trọng yếu; nếu chỉ mô tả traceability, cần đặt phạm vi hoặc nhãn cụ thể để không gây hiểu nhầm.
assets/diagrams/07-user-stories-and-acceptance-criteria-013-9c6ca363.mmd — REVISE — Traceability Record thiếu nguồn và artifact đích dù bảng xác định đây là liên kết bắt buộc. Bổ sung hai nút biên và quan hệ với TR.; Mũi tên không có nhãn nên quan hệ bị hiểu như luồng tạo tác. Gắn nhãn quan hệ cụ thể như “được đặc tả bởi”, “được truy vết trong” và “ghi nhận thay đổi của”.; CH --> US và CH --> AC ngụ ý Change History tạo hoặc dẫn đến User Story và Acceptance Criteria, trong khi prose chỉ hỗ trợ quan hệ ghi nhận thay đổi và ảnh hưởng. Chỉnh hướng hoặc nhãn để thể hiện US/AC có thay đổi được ghi trong CH.; Nhãn “AC-NF-SO-001-01..03” dùng ký hiệu khoảng mơ hồ. Đổi thành cách ghi cụ thể, như “AC-NF-SO-001-01 đến -03”.
assets/diagrams/07-user-stories-and-acceptance-criteria-014-d849dcb6.mmd — REVISE — Nhánh đạt chỉ nêu “Đủ ID, nguồn, liên kết, lịch sử”, bỏ các điều kiện bắt buộc khác: mọi trường bắt buộc có giá trị, nguồn phân loại đúng, giả định gắn nhãn và status không cao hơn IN_REVIEW. Sửa nhãn để phản ánh đủ gate hoặc dẫn chiếu rõ “Đạt toàn bộ điều kiện gate”.; Nhánh không đạt “Thiếu hoặc mâu thuẫn” quá hẹp; prose còn quy định thay ID, dùng dữ liệu thật, biến giả định thành fact và ghi trạng thái cao hơn IN_REVIEW. Sửa nhãn thành điều kiện bao quát mọi trường hợp không đạt.; Actor “BA” chưa được section xác định là owner duy nhất của bước soạn hoặc cập nhật. Sửa thành actor được prose hỗ trợ hoặc bỏ actor khỏi nhãn.; Kết quả “Không tạo approval hoặc production readiness” đặt sau “Reviewer xem xét” dễ suy diễn rằng hoạt động review không thể tạo quyết định tiếp theo. Prose chỉ khẳng định quality gate không đồng nghĩa approval, baseline, xác nhận nghiệp vụ, tuân thủ hoặc production readiness. Gắn giới hạn này với kết quả gate và nêu đủ phạm vi.; Nhãn “Ready for downstream review” trộn tiếng Anh với tiếng Việt và có thể bị hiểu như trạng thái chính thức mới. Đổi thành mô tả cụ thể rằng artifact đạt gate để chuyển review, không nâng status khỏi IN_REVIEW.
assets/diagrams/07-user-stories-and-acceptance-criteria-015-116811da.mmd — REVISE — Diagram invents unsupported actors and uses: Architect, Business Owner, Operations, Specialist owner, architecture fit, business value input, operational fit, and domain validation input do not appear in surrounding prose. Remove them or add prose that defines their roles and outputs.; Developer and QA are not named in surrounding prose. Prose supports design and test basis, but not assignment of those uses to specific actors. Remove actor attribution or document it in prose.; PM/Product Owner and Developer labels combine or generalize roles without defined ownership. Clarify each role in prose or use only supported concepts.; Arrows from BA imply BA owns and distributes user stories and acceptance criteria. Surrounding prose defines outputs, not creator, owner, handoff, or workflow. Avoid this implication or document ownership and flow.; Build/design input is ambiguous and not parallel with prose, which names design directly. Use concrete, consistently phrased outcomes if diagram remains.; Diagram omits prose-supported consistency across testing, design, and prioritization. Show this relationship or explain it outside diagram.; Diagram does not represent status boundary IN_REVIEW or warning that content is not baseline, approved, or authorized for production. Add visible boundary when diagram could otherwise imply an approved operational workflow.
assets/diagrams/07-user-stories-and-acceptance-criteria-016-e82a752e.mmd — REVISE — Gateway Cần quyết định pháp lý, kế toán, kiến trúc, vận hành? bỏ sót Business Owner, PM/Product Owner, QA và domain owner dù bảng giao quyền quyết định hoặc xác nhận cho các vai trò này. Cần bao quát mọi loại quyết định và owner được nêu trong bảng.; Nhãn Đúng owner trả lời mơ hồ và đặt trước bước xác định nhu cầu escalation, khiến luồng có thể hiểu rằng owner đã trả lời rồi mới chọn owner quyết định. Cần thể hiện rõ BA ghi câu hỏi, xác định owner có thẩm quyền, rồi owner đó trả lời hoặc quyết định.; Escalate đúng specialist owner không đúng cho mọi nhánh: Business Owner, PM/Product Owner và QA không luôn là specialist owner. Cần dùng nhãn owner phù hợp với ma trận escalation trong bảng.; Cập nhật artifact truy vết chưa nêu yêu cầu liên kết câu trả lời lại user story và acceptance criteria. Cần làm rõ artifact nào được cập nhật và liên kết truy vết nào phải được giữ.; Handoff có kiểm soát là kết quả trừu tượng, không cho biết tiêu chí quan sát được. Cần nêu kết quả cụ thể như đủ cơ sở bàn giao mà không biến suy diễn thành quy tắc, thiết kế hoặc phê duyệt.
assets/diagrams/07-user-stories-and-acceptance-criteria-017-2532c0db.mmd — REVISE — Sơ đồ bỏ sót lỗ hổng “không kiểm tra trùng mã lô trong cùng lần nhận”. Bổ sung bước nhập mã lô và kết quả không kiểm tra trùng.; Nhánh “QC chưa có kết quả tại thời điểm nhận” không nối với kết quả “Không phân biệt chờ QC và có thể dùng”, nên chưa thể hiện cầu nối suy luận trung tâm. Bổ sung điểm hội tụ giữa tồn kho tổng và trạng thái QC chưa có trước kết quả này.; Sơ đồ không thể hiện việc thiếu liên kết hệ thống giữa lần nhận và kết quả QC. Bổ sung ranh giới hoặc nhãn cụ thể cho trao đổi thủ công và sự thiếu liên kết.; Các hành động “Ghi bảng tính cục bộ”, “Gửi thông tin lô” và “xem tồn kho tổng” thiếu chủ thể dù trách nhiệm vai trò quan trọng. Gắn Nhân viên kho, QC và Điều phối sản xuất với bước tương ứng.
assets/diagrams/07-user-stories-and-acceptance-criteria-018-534a9179.mmd — REVISE — Nhánh bằng nhau tạo trạng thái RECEIVED, nhưng phần surrounding section không định nghĩa hoặc xác nhận trạng thái này. Xóa trạng thái hoặc bổ sung nguồn prose trước khi dùng.; Luồng thiếu hành động lưu receivedQty thực nhận. Thêm bước lưu nhận hàng để phản ánh AC-SIM-PO-001 và DC-01.; Bước Nhập varianceReason bắt buộc không thể hiện trường hợp thiếu lý do bị từ chối hoàn tất. Thêm gateway kiểm tra varianceReason và kết quả lỗi theo AC-SIM-PO-002.; Luồng QTY_VARIANCE thiếu liên kết tới PO-SIM-20260807-001 và DN-SIM-20260807-014. Thêm bước hoặc kết quả thể hiện traceability theo AC-SIM-PO-003 và DC-02.; Luồng không thể hiện ranh giới quyền: nhân viên kho không được đổi trạng thái sang RESOLVED. Thêm boundary hoặc kết quả quyền hạn theo AC-SIM-PO-004 và DC-03.; Nhãn Procurement Owner xử lý ngoại lệ mơ hồ về kết quả và có thể ngụ ý quyền xử lý đã được phê duyệt, trong khi quy trình còn IN_REVIEW. Gắn nhãn đây là luồng dự kiến hoặc giới hạn sơ đồ tại tác vụ được tạo.
assets/diagrams/07-user-stories-and-acceptance-criteria-019-ec886a52.mmd — REVISE — Sơ đồ chỉ thể hiện luồng thành công, bỏ nhánh lỗi tạo shipment trong TS-NF-INV-005. Bổ sung kết quả không trả thành công và hành động hoàn tác tồn hoặc bù trừ.; Sơ đồ thể hiện giảm tồn rồi tạo shipment như hành vi đã xác lập, trong khi BR-NF-INV-004 chỉ là recommendation và cơ chế giao dịch hoặc bù trừ chưa được Architect quyết định. Gắn trạng thái đề xuất hoặc thể hiện ranh giới giao dịch/cơ chế bù trừ chưa quyết định.; Bước Kiểm tra SO, kho, sản phẩm, lô, số lượng chỉ nhận phản hồi 150 CTN khả dụng, không thể hiện kết quả kiểm tra SO, kho, sản phẩm và lô. Tách hoặc đổi phản hồi để bao quát đầy đủ kết quả kiểm tra.; Nhãn lô A và lô B mơ hồ so với ID đầy đủ trong payload. Dùng LOT-NF-CHILI-20260720-A và LOT-NF-CHILI-20260725-B.; Luồng bỏ điều kiện ưu tiên lô và ngoại lệ overrideReason từ BR-NF-INV-003/TS-NF-INV-004. Bổ sung nhánh kiểm tra thứ tự lô hoặc giới hạn rõ sơ đồ chỉ mô tả happy path của TS-NF-INV-001.; Thông điệp đầu không nêu giao diện giả định POST /api/v1/inventory/issues, khiến ranh giới API thiếu rõ ràng. Gắn endpoint và giữ trạng thái giả định, không mô tả như API production.
assets/diagrams/07-user-stories-and-acceptance-criteria-020-4cf43f8e.mmd — REVISE — Các cạnh SM --> CH, CM --> CH và TM --> CH không được phần văn xuôi xác lập; cần loại bỏ hoặc bổ sung căn cứ trong section.; OUT chỉ ghi US và AC nhưng các phụ thuộc IDR, BR, DD còn áp dụng cho TS, rule ID và field lotId; cần thể hiện đúng đối tượng phụ thuộc hoặc thu hẹp các cạnh.; CH --> OUT làm OUT trông như artifact riêng nằm ngoài chapter, trong khi văn xuôi xác định chapter là artifact tiêu thụ và US/AC là nội dung trong chapter; cần làm rõ ranh giới chứa hoặc quan hệ tiêu thụ.; Sơ đồ không phân biệt nguồn canonical với artifact tiêu thụ, nên các cạnh IDR, BR và DD chỉ biểu diễn liên kết chung, chưa thể hiện vai trò phụ thuộc được Decision yêu cầu; cần gắn nhãn quan hệ cụ thể.; Sơ đồ bỏ metadata IN_REVIEW, v0.9.0, 2026-08-07 và ranh giới không có approval hoặc baseline; thiếu trạng thái này có thể khiến nguồn canonical bị hiểu nhầm là đã approved.; Sơ đồ không thể hiện các owner quyết định và xác minh nội dung; cần bổ sung owner nếu mục tiêu là mô tả authority, hoặc giới hạn rõ sơ đồ chỉ mô tả traceability dependency.
assets/diagrams/07-user-stories-and-acceptance-criteria-021-6c73c4ba.mmd — REVISE — Sơ đồ thiếu liên kết REQ-NF-001 → TC-NF-001 được khai báo trong bảng; bổ sung cạnh này để thể hiện yêu cầu được kiểm thử trực tiếp.; Sơ đồ thiếu liên kết giữa BR-NF-001 và AC-NF-001 được khai báo hai chiều trong bảng; bổ sung một cạnh thể hiện quan hệ truy vết, tránh ngụ ý tiêu chí chấp nhận độc lập với quy tắc.; Sơ đồ thiếu liên kết giữa DATA-NF-001 và API-NF-001 được khai báo trong bảng; bổ sung cạnh để thể hiện API sử dụng trường dữ liệu canonical.
assets/diagrams/07-user-stories-and-acceptance-criteria-022-faba0f86.mmd — REVISE — "Review theo thẩm quyền" đưa vào khái niệm thẩm quyền không được phần văn bản xác định; cần bỏ hoặc thay bằng bước review được văn bản hỗ trợ.; Nhánh kiểm soát chỉ nêu ghi nhận thay đổi và đánh giá ảnh hưởng, nhưng bỏ việc thông báo consumer—một tiêu chí trực tiếp phân biệt thay đổi im lặng; cần thể hiện điều kiện này.; "Lỗi build" không khớp ví dụ: đội phát triển có thể build đúng theo tiêu chí cũ nhưng tạo kết quả sai so với canonical mới; cần dùng hậu quả chính xác hơn.; "data/API" trong bước cập nhật mơ hồ giữa artifact dữ liệu và hợp đồng API; cần dùng nhãn cụ thể, nhất quán với canonical data dictionary và hợp đồng API trong văn bản.
assets/diagrams/07-user-stories-and-acceptance-criteria-023-6c5adace.mmd — REVISE — Trạng thái IN_REVIEW không được section định nghĩa. Thay bằng trạng thái đã nêu: giữ Verification required và không chốt hành vi.; Gateway Có quyết định được ghi nhận? mơ hồ về chủ thể và nội dung. Nêu rõ Business Owner xác nhận quy tắc, ngoại lệ vận hành và quyết định được ghi vào artifact canonical phù hợp.; Bước Chuyển Business Owner và domain owner khiến hai vai trò có cùng thẩm quyền quyết định. Phân biệt Business Owner xác nhận nhu cầu, ngoại lệ; Food-safety/domain owner xác nhận ngữ cảnh truy xuất.; Nhánh đi thẳng từ rule canonical đến viết AC bỏ qua kiểm tra dữ liệu canonical, quyền override và khả năng kiểm thử được nêu trong Decision Criteria. Bổ sung kiểm tra các điều kiện này trước khi chốt AC.; Diagram bỏ vai trò Architect và QA dù bảng Authority gắn họ với cách thực hiện và testability. Thêm bước review tương ứng hoặc giới hạn rõ diagram chỉ mô tả quyết định nghiệp vụ trước review kỹ thuật và kiểm thử.
assets/diagrams/07-user-stories-and-acceptance-criteria-024-767e3ade.mmd — REVISE — Final state Status IN_REVIEW and requirement for recorded approval lack support in surrounding prose. Remove them or document this workflow state and approval rule in prose.; Step QA kiểm thử lại assigns QA to every recovery path, while prose requires retesting but names QA only in one scenario. Use actor-neutral retesting or add general QA ownership to prose.; Label Chuyển đúng Owner xác nhận is ambiguous. Name applicable owners or state selection rule supported by table: Business Owner, Accounting Owner, or Legal Owner.; Diagram omits critical safe-recovery boundaries: do not modify production data and do not make legal, accounting, or compliance conclusions. Show these constraints or make diagram scope explicitly exclude them.; Low-risk branch ends after wording correction without preserving evidence or retesting. Clarify intended terminal outcome because prose requires traceable artifact correction and defines safe recovery through retesting.
assets/diagrams/07-user-stories-and-acceptance-criteria-025-1c9518ea.mmd — REVISE — Nhánh S -.thiếu ID hoặc link.-> X gắn đứt truy vết riêng với nguồn, trong khi prose định nghĩa lỗi tại bất kỳ liên kết nào giữa nguồn, quy tắc, story, acceptance criteria và test basis. Cần biểu diễn phạm vi toàn chuỗi hoặc nêu rõ đây chỉ là ví dụ.; Nhãn claim approval không có evidence pha trộn ngôn ngữ và chưa bao quát quyết định, quy định pháp lý hoặc baseline không có bằng chứng. Cần dùng nhãn tiếng Việt cụ thể, song song với thuật ngữ trong prose.; Nhánh thẩm quyền kết thúc tại loại lỗi nhưng bỏ cách xử lý quan trọng: gắn Verification required và chỉ rõ vai trò cần xác nhận. Cần thể hiện kết quả xử lý hoặc giới hạn rõ sơ đồ chỉ phân loại lỗi.; Chuỗi chính không biểu diễn liên kết canonical ID được prose yêu cầu để khôi phục truy vết. Mũi tên hiện có thể bị hiểu là quan hệ khái niệm, không phải liên kết truy vết kiểm chứng được. Cần làm rõ ý nghĩa liên kết.
assets/diagrams/07-user-stories-and-acceptance-criteria-026-e735022c.mmd — REVISE — Gateway F gộp nhiều kiểm tra khác loại thành một câu hỏi và bỏ sót các miền escalation đã nêu: giá, tồn kho, dữ liệu cá nhân, an toàn thực phẩm và truy vết. Cần thể hiện đủ boundary hoặc dùng nhãn bao quát, cụ thể, bám đúng ngưỡng hậu quả.; Nhánh F -- Khong --> G cho phép review tiếp mà không kiểm tra nguồn canonical, ý nghĩa và biên dữ liệu, decision authority hoặc ngoại lệ áp dụng. Cần bổ sung các kiểm tra bắt buộc trước outcome review.; Gateway H chỉ hỏi "Đúng thẩm quyền đã xác định?" nên không thể hiện trường hợp quyết định thuộc từ hai vai trò chuyên môn trở lên, vốn phải escalation ngay. Cần có điều kiện riêng cho xung đột hoặc nhiều thẩm quyền.; Diagram mô tả escalation theo loại impact, trong khi prose quy định ngưỡng dựa vào hậu quả nếu chọn sai, không dựa vào sự hiện diện chung của impact. Cần sửa gateway để phản ánh consequence-based escalation.; Các node C và E là điểm kết thúc, không cho thấy story quay lại review sau khi làm rõ. Cần thể hiện trạng thái trả về làm rõ và vòng review lại, hoặc outcome chưa đạt review.; Node G "Cho phep review tiep" mơ hồ, không xác định story đạt review, còn IN_REVIEW, hay chuyển sang bước nào. Cần dùng outcome kiểm chứng được và phù hợp trạng thái.; Diagram bỏ ngoại lệ quan trọng: discovery không được gọi là Acceptance Criterion, project assumption không được diễn đạt như rule vận hành, và không tách story khi làm mất kiểm soát giao dịch. Cần biểu diễn boundary hoặc exception note để tránh quy trình máy móc.; Nhãn thiếu dấu tiếng Việt và dùng từ không song song, trong khi hai nhãn "thẩm quyền" lại có dấu. Cần chuẩn hóa ngôn ngữ, cấu trúc câu hỏi và nhánh "Có/Không".
assets/diagrams/07-user-stories-and-acceptance-criteria-027-cd659258.mmd — REVISE — Quality gate omits relevant dependencies named in section: TEMPLATE_MANIFEST and 00_SOURCE_MAP. Add them where template registration, filename, source classification, or legal-source boundary requires validation.; Pass outcome points to current handbook file, creating circular and ambiguous meaning. Replace outcome concept with permitted chapter reference or eligible-for-use state while preserving status IN_REVIEW.; Gate condition "Đủ ID, bằng chứng, thẩm quyền" omits required checks for canonical filename, fact versus assumption versus Verification required, non-approval status, simulated ERP data, and legal/accounting/security/operations source boundaries. Represent these checks or reference concrete minimum gate.; Failure branch "Escalation đúng owner" lacks supported owner routing. Identify issue-based routing: Business Owner for policy, Architect for technical feasibility, Security or Legal Owner for relevant controls, and registry maintainer for ID conflicts.; Diagram hides stated responsibility boundary: BA records and links traceability but does not approve policy, architecture, security, or legal decisions. Show this boundary or avoid implying quality gate grants approval.
assets/diagrams/07-user-stories-and-acceptance-criteria-028-3930da99.mmd — REVISE — Nhãn "Tra nguồn hoặc dependency canonical" mơ hồ: từ "hoặc" che giấu hai kiểm tra khác nhau và không nêu các ID canonical cần giữ nguyên. Cần thể hiện rõ kiểm tra nguồn của story và kiểm tra dependency canonical.; Luồng không thể hiện ranh giới artifact: worked example nằm trong chính chapter, còn template chưa có đường dẫn canonical không được xem là artifact đã điền. Cần thể hiện ràng buộc tra cứu này.; Bước "Đối chiếu anti-pattern và senior rules" gộp hai nhóm kiểm tra khác mục đích, làm mất điều kiện evidence/reasoning bridge và nhãn "Verification required" hoặc "project assumption". Cần tách hoặc ghi rõ điều kiện kiểm tra.; Kết quả chỉ nêu "IN_REVIEW" nhưng bỏ điều kiện không tạo baseline hoặc approval. Cần nêu rõ trạng thái không đồng nghĩa phê duyệt.; Sơ đồ chủ yếu chuyển bảng Quick Reference thành chuỗi tuyến tính, chưa giải thích nhánh, điều kiện hay quan hệ mới. Cần bổ sung giá trị điều hướng hoặc logic kiểm tra thay vì lặp lại thứ tự mục.
assets/diagrams/07-user-stories-and-acceptance-criteria-029-04a4207c.mmd — REVISE — Nhãn “Verification required” không xuất hiện trong phần văn xuôi; bỏ bước này hoặc bổ sung căn cứ trong văn xuôi.; “Escalation đúng owner” tự tạo hành động và owner chưa được phần văn xuôi xác định; bỏ nhánh này hoặc nêu rõ owner và quy tắc escalation trong văn xuôi.; “Đối chiếu ID và filename” thêm kiểm tra filename chưa được yêu cầu rõ; đổi thành nội dung chỉ phản ánh kiểm tra chéo tệp, ID và tham chiếu.; Sơ đồ bỏ sót kiểm tra quan trọng rằng mọi nguồn đều IN_REVIEW, v0.9.0, ngày 2026-08-07 và chưa có baseline hoặc approval; cần thể hiện điều kiện này trước handoff.; Sơ đồ bỏ sót ranh giới Nova Foods: case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; cần thể hiện nếu quy trình kiểm tra bao phủ toàn bộ yêu cầu trong đoạn văn.; Gateway gộp “mâu thuẫn” và “vượt thẩm quyền” nhưng chỉ dẫn đến một kết quả mơ hồ; cần nêu kết quả riêng, có căn cứ, cho từng điều kiện hoặc giới hạn gateway theo quy tắc đã được phần văn xuôi hỗ trợ.
assets/diagrams/08-business-rules-state-and-decision-analysis-001-6a87768a.mmd — REVISE — Sơ đồ trạng thái mô hình hóa "Kết_quả_quyết_định" như một state, trái với prose: decision là logic chọn kết quả, không phải trạng thái của đối tượng. Cần phân biệt bước đánh giá quyết định với state nghiệp vụ.; Các nhãn "Trạng_thái_hiện_tại", "Kết_quả_quyết_định" và "Trạng_thái_kế_tiếp" quá khái quát, không cho biết trạng thái hay kết quả cụ thể và không đáp ứng tiêu chí nhãn concrete. Cần dùng ví dụ nghiệp vụ cụ thể hoặc chuyển sang sơ đồ khái niệm thể hiện rõ vai trò của state, facts, rules và decision.; Nhánh quay lại "Trạng_thái_hiện_tại" mô tả kết quả không cho phép thay đổi nhưng không làm rõ đây là giữ nguyên state, từ chối hành động hay phát sinh lỗi. Cần ghi outcome cụ thể để tránh nhập nhằng.; Nút khởi đầu "[*]" ngụ ý điểm bắt đầu vòng đời, trong khi prose chỉ nói state hiện thời và không xác định initial state hay sự kiện khởi tạo. Cần bỏ ngụ ý vòng đời này hoặc cung cấp state khởi tạo được section hỗ trợ.; Facts và business rules chỉ xuất hiện trong một nhãn chuyển tiếp, khiến quan hệ decision kiểm tra facts theo rules không được thể hiện rõ; sơ đồ hiện gần như lặp lại nguyên văn đoạn cầu nối suy luận. Cần làm quan hệ đầu vào, đánh giá và outcome trực quan hơn.
assets/diagrams/08-business-rules-state-and-decision-analysis-002-d0133e58.mmd — REVISE — Các chi tiết “Nhân viên bán hàng”, “Đơn bán hàng”, trạng thái “IN_REVIEW” và “báo lỗi” không được phần văn xuôi xác lập; cần thay bằng nội dung đã được hỗ trợ hoặc bổ sung ngữ cảnh văn xuôi tương ứng.; Nhãn “Điều kiện quyết định” và hai nhánh “Đạt”/“Không đạt” không nêu điều kiện cụ thể, nên không thể kiểm tra logic quyết định; cần ghi tiêu chí và kết quả kiểm tra rõ ràng.; Sơ đồ thể hiện hành động gửi luôn dẫn đến bước kiểm tra nhưng không nêu điều kiện kích hoạt, dữ liệu thay đổi hoặc thông báo lỗi cụ thể; cần làm rõ outcome của từng nhánh theo cấu trúc được mô tả.
assets/diagrams/08-business-rules-state-and-decision-analysis-003-71171ef6.mmd — REVISE — [*] --> DRAFT khẳng định DRAFT là trạng thái khởi đầu của mọi phiếu, nhưng phần văn xuôi chỉ mô tả phiếu ví dụ đang ở DRAFT. Bỏ chuyển tiếp này hoặc bổ sung căn cứ xác nhận trạng thái khởi đầu.; APPROVED --> [*] khẳng định vòng đời kết thúc ngay sau phê duyệt, trong khi phần văn xuôi nói phê duyệt diễn ra trước khi tạo lệnh xuất. Bỏ chuyển tiếp kết thúc hoặc xác định rõ ý nghĩa trạng thái cuối trong văn xuôi.
assets/diagrams/08-business-rules-state-and-decision-analysis-004-9a90a817.mmd — REVISE — Trạng thái DRAFT không được section xác định; cần bổ sung căn cứ trong prose hoặc bỏ trạng thái này khỏi diagram.; Chuyển APPROVED --> [*] biến APPROVED thành điểm kết thúc, nhưng section không mô tả vòng đời kết thúc sau phê duyệt; cần bỏ chuyển đổi hoặc nêu rõ quy tắc kết thúc.; Nhãn “Điều kiện duyệt được đánh giá đúng/sai” mơ hồ và không thể kiểm thử; cần dùng điều kiện cùng outcome cụ thể, như kết quả kiểm tra đủ tồn và trạng thái khi không đủ tồn.; Nhánh điều kiện sai dùng self-loop nhưng không nêu hành vi quan sát được như chặn duyệt hoặc thông báo lỗi; cần thể hiện outcome mà prose yêu cầu làm rõ.
assets/diagrams/08-business-rules-state-and-decision-analysis-005-254ed82d.mmd — REVISE — RELEASED --> Check makes validation occur only after order reaches RELEASED; prose requires validation when user attempts to create Material Issue Request for any relevant status. Connect creation attempt to check, not RELEASED state.; ReadOrderStatus --> BlockIssue: Status != RELEASED is unreachable in shown flow because Check is entered only from RELEASED. Model both allowed and blocked outcomes from creation-time status check.; Check --> CLOSED: tạo phiếu xuất hợp lệ implies successful material issue closes Production Order. Section does not support this rule. Remove this outcome or replace it with supported outcome: material issue created.; RELEASED --> CLOSED and lifecycle transitions DRAFT --> PENDING_APPROVAL --> RELEASED, PENDING_APPROVAL --> REJECTED are not established by surrounding prose. Prose names status values and eligibility, not allowed lifecycle transitions. Remove unsupported transitions or document them in prose.; AllowIssue and BlockIssue have no explicit resulting events or terminal outcomes. Show concrete observable results supported by prose: create material issue, or reject creation and record/display blocking message.; Diagram mixes Production Order lifecycle states with material-issue decision states inside one state machine without clear object boundary. Separate or label boundaries so readers know which states belong to Production Order and which outcomes belong to creation request.; Condition labels use generic Status; prose defines Production Order.Status. Use exact field label to avoid ambiguity.
assets/diagrams/08-business-rules-state-and-decision-analysis-006-c7e64735.mmd — REVISE — Nhánh Có nguồn canonical kiểm tra được? dẫn thẳng đến Verified fact sai với section: CANONICAL_BUSINESS_RULES và CHAPTER_MANIFEST đang IN_REVIEW, chưa có baseline reference hoặc approval reference. Cần thêm điều kiện xác nhận trạng thái, phạm vi và authority trước khi phân loại là verified fact.; Nhãn nguồn canonical mơ hồ và có thể đồng nhất artifact nội bộ với nguồn chính thức. Cần phân biệt nguồn corpus đang IN_REVIEW, nguồn pháp lý chính thức và diễn giải cần Accounting Owner hoặc Legal Owner xác minh.; Nhánh stakeholder input dẫn đến gateway Có authority record và lựa chọn rõ?, rồi có thể tạo Decision. Luồng này không phản ánh quyết định của case: phát biểu phải thành verification-required claim và chuyển Accounting Owner hoặc Legal Owner xác minh; Business Owner chỉ quyết định nhu cầu nghiệp vụ.; Nhãn chuyển owner phù hợp thiếu owner cụ thể dù section nêu rõ Accounting Owner, Legal Owner và Business Owner. Cần ghi owner theo loại xác minh hoặc quyết định.; Sơ đồ bỏ trạng thái và ràng buộc artifact quan trọng: giữ IN_REVIEW, v0.9.0, không gán baseline reference hoặc approval reference, không tạo business rule bắt buộc. Cần thể hiện outcome này cho case.; Sơ đồ bỏ ngoại lệ rủi ro cao được dùng làm tiêu chí quyết định: diễn giải sai có thể khóa thiết kế lưu vết sai phạm vi, gây sai dữ liệu hoặc kiểm soát. Cần thể hiện kiểm tra hệ quả trước khi nâng claim thành rule hoặc decision.
assets/diagrams/08-business-rules-state-and-decision-analysis-007-9c13b2e8.mmd — REVISE — Luồng pha dùng mũi tên liền vô điều kiện song song với mũi tên Exit gate, khiến gate có vẻ không kiểm soát chuyển pha. Cần biểu diễn mỗi chuyển pha qua Exit gate tương ứng hoặc bỏ luồng liền gây mơ hồ.; Discovery Exit ghi "stakeholder input hoặc verified fact phân loại rõ" không khớp tiêu chí đầy đủ: mỗi phát biểu phải có nguồn, ngữ cảnh và trạng thái bằng chứng. Cần sửa nhãn theo tiêu chí này.; Sơ đồ chỉ nêu Entry gate của Discovery, bỏ Entry gate của Analysis, Delivery, Testing, Release và Operations. Cần thể hiện nhất quán các Entry gate hoặc xác định rõ sơ đồ chỉ mô tả Exit gate.; Release Exit bỏ phiên bản và cảnh báo không suy ra production approval. Cần thêm hai điều kiện để tránh hiểu sai trạng thái phát hành thành phê duyệt production.; Operations phản hồi chung chung, bỏ kết quả phân loại thành defect, change request, project assumption cần kiểm chứng hoặc verification-required claim. Cần thể hiện kết quả phân loại trước khi quay lại Discovery.; Mũi tên tự nối Discovery cho Entry gate mô tả điều kiện tiên quyết như vòng lặp nội pha. Cần dùng ký hiệu hoặc nút gate không ngụ ý Discovery tự tạo đầu vào cho chính nó.
assets/diagrams/08-business-rules-state-and-decision-analysis-010-0c5d9db9.mmd — REVISE — Nhánh "Mâu thuẫn hoặc điểm chưa xác minh?" gộp hai tình huống có hậu quả khác nhau. Mâu thuẫn phải dừng phân tích đến khi có kết luận được ghi nhận; chỉ gắn "Verification required" rồi chuyển sang "Đủ điều kiện phân tích" trái bảng tiêu chí. Tách nhánh mâu thuẫn khỏi điểm chưa xác minh và đưa mâu thuẫn về trạng thái dừng.; Nhánh "Freshness và version rõ?" đưa mọi trường hợp "Không" về STOP, trong khi prose chỉ bắt buộc dừng khi nguồn pháp lý hoặc tiêu chuẩn không rõ phiên bản. Bổ sung điều kiện loại nguồn hoặc diễn đạt đúng phạm vi dừng.; Sơ đồ bỏ kiểm tra phân loại nguồn, dù prose xác định phân loại quyết định mức suy luận và cấm suy luận nghĩa vụ khi nhãn chưa đúng. Thêm gateway xác nhận nhãn primary, controlled planning, derived, assumption hoặc Verification required trước phân tích.; Sơ đồ bỏ kiểm tra khả dụng và giới hạn licensed text, làm mất rủi ro bịa clause, trích dẫn hoặc nội dung chưa truy cập. Thêm kiểm tra khả dụng cùng kết quả không được suy luận nội dung không thấy.; Nhãn "ID và nguồn rõ?" mơ hồ, không bao quát yêu cầu Artifact ID, filename và version khớp nguồn canonical. Dùng tiêu chí định danh cụ thể, không gộp với phân loại nguồn.
assets/diagrams/08-business-rules-state-and-decision-analysis-011-3967e740.mmd — REVISE — Luồng EVD-NF-SO-001 → DD-NF-SO-001 ngụ ý bằng chứng tạo hoặc xác định nghĩa field; section chỉ xác nhận đây là hai input riêng. Biểu diễn chúng thành các input song song cho phân tích.; QRY-NF-APP-001 mang trạng thái UNRESOLVED — STOP FOR RULE DECISION nhưng bị bỏ khỏi sơ đồ. Thêm dependency này vào điểm dừng.; BR-NF-SO-001 có trạng thái Verification required nhưng nhãn Rule candidate chưa thể hiện ranh giới xác minh. Gắn rõ IN_REVIEW hoặc Verification required để tránh hiểu là rule đã được xác nhận.; C → Decision/state analysis ngụ ý có thể tiếp tục phân tích quyết định dù thiếu luồng, thẩm quyền và câu hỏi rule trọng yếu. Giới hạn outcome thành phân tích cấu trúc input, hoặc thể hiện analysis bị chặn cho đến khi các item unresolved được xác minh.; Nhãn Decision/state analysis quá rộng và không cụ thể. Dùng nhãn phản ánh phạm vi được section cho phép: phân tích cấu trúc input, không xác lập chuyển trạng thái hay quyết định vận hành.
assets/diagrams/08-business-rules-state-and-decision-analysis-012-c3347de5.mmd — REVISE — Nhánh Không chỉ chuyển đến Business Owner hoặc Process Owner, nhưng bảng quy định thêm Data Owner, Legal Owner, Accounting Owner, Security Owner, Architect và owner của TRACEABILITY_ID_REGISTRY theo loại vấn đề. Bổ sung định tuyến theo phạm vi hoặc dùng nhãn owner tương ứng thay vì giới hạn hai owner.; Luồng Escalate Business Owner hoặc Process Owner kết thúc tại Giữ artifact IN_REVIEW, không thể hiện owner trả lời, BA cập nhật evidence rồi đánh giá lại. Bổ sung vòng phản hồi về bước phân loại hoặc gateway kiểm tra evidence.; Gateway Có rule và authority canonical? gộp rule, flow và authority thành một điều kiện, trong khi section giao chúng cho owner khác nhau. Tách điều kiện hoặc ghi rõ tất cả phần bắt buộc phải được xác minh.; Nhãn Review theo thẩm quyền thiếu actor và có thể bị hiểu thành approval. Ghi rõ reviewer đúng thẩm quyền tạo review record, không phê duyệt ngoài phạm vi.; Nhãn Handoff controlled mơ hồ, không song song ngôn ngữ với nhãn còn lại và bỏ điều kiện phải nêu open issues, version, date, trạng thái chưa quyết định. Dùng nhãn tiếng Việt cụ thể về handoff có kiểm soát và giữ IN_REVIEW khi còn blocking question.; Sơ đồ bỏ quality gate cấm ghi APPROVED, BASELINED hoặc user-approved. Thể hiện outcome vẫn IN_REVIEW khi còn câu hỏi chặn để tránh handoff bị hiểu là phê duyệt.; Các bước Gắn Verification required, escalation và handoff không nêu actor. Bổ sung BA hoặc reviewer tại bước actor có ý nghĩa để khớp trách nhiệm trong bảng.
assets/diagrams/08-business-rules-state-and-decision-analysis-013-68a5ab8f.mmd — REVISE — CONFIRMED --> [*] and REJECTED --> [*] assert both states end order lifecycle, but section supports only credit-decision outcomes, not terminal order states. Remove terminal transitions or explicitly scope [*] as end of credit-review subprocess in surrounding prose.; Transition labels Credit Controller accepts exception and Credit Controller rejects exception describe exception handling inconsistently: rejection rejects order, not exception. Use parallel, outcome-specific labels such as Credit Controller confirms order and Credit Controller rejects order.
assets/diagrams/08-business-rules-state-and-decision-analysis-014-a7a20367.mmd — REVISE — Các mũi tên không có nhãn nên quan hệ giữa hoạt động phân tích, artifact và registry bị mơ hồ; cần ghi rõ quan hệ như tạo hoặc cập nhật artifact và đăng ký liên kết truy vết.; Nhánh trực tiếp từ State and decision analysis đến TRACEABILITY_ID_REGISTRY chồng nghĩa với các nhánh artifact đến registry; cần làm rõ registry nhận ID và quan hệ truy vết từ từng artifact, không trình bày hai cơ chế không phân biệt.; Nhãn State model và Decision record không đủ cụ thể so với bảng canonical; cần dùng tên artifact nhất quán để phân biệt hai nội dung cùng nằm trong handbook.; Sơ đồ bỏ qua ranh giới quyền hạn quan trọng: Owner duy trì cấu trúc, ID, phiên bản và lịch sử nhưng không được tự xác nhận policy, pháp lý, kế toán, baseline, approval hoặc production use; cần thể hiện ranh giới quản trị hoặc trạng thái IN_REVIEW để tránh ngụ ý artifact đã được phê duyệt.; Sơ đồ không thể hiện nghĩa vụ lưu lịch sử thay đổi, dù đây là kết quả bắt buộc cho mọi artifact; cần biểu diễn version, ngày, lý do và đối tượng bị ảnh hưởng như phần quản trị chung.
assets/diagrams/08-business-rules-state-and-decision-analysis-015-e0a201ce.mmd — REVISE — Các state Draft, Submitted, Approved, Rejected và event submit, approve, reject, revise không có nguồn hoặc nghiệp vụ hỗ trợ trong section; thay bằng mô hình có căn cứ từ artifact canonical hoặc ghi rõ đây là ví dụ giả định.; Guard đủ điều kiện và thiếu điều kiện mơ hồ, không nêu dữ liệu hay rule dùng để đánh giá; thay bằng điều kiện cụ thể và liên kết ID trong CANONICAL_BUSINESS_RULES hoặc TRACEABILITY_ID_REGISTRY.; Transition dùng nhãn không song song: submit và revise chỉ nêu event, còn approve khi đủ điều kiện và reject khi thiếu điều kiện trộn event với guard; tách event và guard theo cú pháp nhất quán.; State model thiếu hành vi bị cấm, dù anatomy tối thiểu yêu cầu thành phần này; bổ sung constraint tương ứng hoặc artifact liên kết thể hiện rõ hành vi cấm.; Nhánh từ Submitted giả định mọi trường hợp đều Approved hoặc Rejected, nhưng không chứng minh tính đầy đủ, priority hay exception; bổ sung trường hợp chưa đủ dữ liệu, ngoại lệ, hoặc chứng minh hai guard loại trừ nhau và bao phủ toàn bộ.; Transition Approved --> [*] biến phê duyệt thành kết thúc vòng đời nhưng section không hỗ trợ boundary này; xác nhận bằng nguồn hoặc bỏ terminal transition.
assets/diagrams/08-business-rules-state-and-decision-analysis-016-bc8d2380.mmd — REVISE — Nút D thêm thẩm quyền bảo mật và kiến trúc, nhưng section không nêu hai boundary này. Xóa chúng hoặc bổ sung căn cứ trong prose.; Nhánh D -- Không --> E yêu cầu "escalation đúng owner", nhưng section không xác định owner hay quy trình escalation. Không được thể hiện như yêu cầu đã được hỗ trợ.; Nút G áp dụng "Status vẫn IN_REVIEW" cho mọi output, trong khi section chỉ phủ nhận approval, baseline và production readiness; không quy định trạng thái chung IN_REVIEW. Thay bằng outcome được prose hỗ trợ hoặc bổ sung quy định trạng thái.; Các gateway gộp mất điều kiện riêng theo từng output: source boundary và fact; mục đích, nguồn tạo, consumer và không suy diễn schema; truy vết hai chiều, không tạo ID mới và không có liên kết mồ côi; nguồn tham chiếu, nhãn mô phỏng, change history và tiếng Việt rõ nghĩa. Cần thể hiện nhánh kiểm tra theo loại output hoặc giới hạn rõ diagram chỉ là luồng tổng quát.; Nhãn "đúng canonical" và "đúng owner" mơ hồ. Cần nêu canonical source hoặc registry được kiểm tra và owner nào có thẩm quyền.
assets/diagrams/08-business-rules-state-and-decision-analysis-017-835af21b.mmd — REVISE — Diagram collapses distinct outputs into ambiguous BA outputs, hiding which actor uses rule catalog, state model, decision table, data definition, exception flow, data impact, integration rule, non-functional constraint, decision record, traceability, and worked scenario. Show supported output-to-consumer dependencies explicitly.; Arrows from BA outputs to CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, and TRACEABILITY_ID_REGISTRY mix outputs with storage or governance locations. Label relationship concretely, such as where each output is maintained or traced.; Operations: run process overstates surrounding prose. Operations use state model, exception flow, and input/output data to understand actions, blocks, and corrections; diagram must use that narrower supported outcome.; Visual omits role boundaries listed in table, including prohibited ownership changes and approval assumptions. Add boundaries where omission could imply actors may change canonical rules, validate requirements, approve business priorities, or confirm technical feasibility.; Diagram mostly duplicates consumer list without explaining differentiated usage, dependencies, or handoffs. Add explanatory structure grounded in table rather than another actor inventory.
assets/diagrams/08-business-rules-state-and-decision-analysis-018-c886daf0.mmd — REVISE — Gateway chỉ hỏi "Consumer có đủ thẩm quyền?" nhưng nhánh escalation còn phụ thuộc bằng chứng thiếu, không còn hiệu lực hoặc mâu thuẫn. Sửa điều kiện gateway để bao quát cả thẩm quyền và mức đầy đủ, nhất quán của bằng chứng.; Nhãn "Escalation tới owner chuyên môn" thu hẹp sai định nghĩa: escalation có thể tới vai trò có thẩm quyền cao hơn hoặc chuyên môn phù hợp. Sửa nhãn để thể hiện cả hai đích.; Nhánh "Có" kết thúc tại "Quyết định trong phạm vi", còn nhánh escalation mới ghi kết luận và cập nhật artifact. Sửa luồng để mọi quyết định đều có kết luận, nguồn và cập nhật artifact nếu đó là quy trình chung; nếu không, section phải nêu rõ khác biệt.; Trạng thái "IN_REVIEW" không được section hỗ trợ. Xóa trạng thái hoặc bổ sung định nghĩa và điều kiện chuyển trạng thái trong prose.; Nhãn nhánh "Không hoặc bằng chứng mâu thuẫn" bỏ sót các trigger đã nêu: thiếu căn cứ, rủi ro bảo mật, dữ liệu cá nhân, pháp lý, kế toán, an toàn thực phẩm, thay đổi kiến trúc và gián đoạn vận hành. Khái quát bằng điều kiện được prose hỗ trợ thay vì liệt kê thiếu.; "BA ghi rule và bằng chứng" chưa phản ánh yêu cầu bằng chứng tối thiểu khác nhau theo consumer. Làm rõ BA tập hợp bằng chứng cần thiết cho consumer hoặc bỏ bước nếu section không giao ownership này cho BA.
assets/diagrams/08-business-rules-state-and-decision-analysis-019-4ba24eeb.mmd — REVISE — Approved --> [*] biến Approved thành trạng thái cuối, trái với cảnh báo rằng “được duyệt” không mặc nhiên là trạng thái cuối. Cần bỏ kết thúc này hoặc bổ sung chuyển trạng thái sau Approved có căn cứ trong nội dung.; Nhãn authorized decision recorded nêu điều kiện nhưng không xác định chủ thể có thẩm quyền hoặc artifact ghi quyết định, trong khi phần giải thích yêu cầu làm rõ cả hai. Cần dùng điều kiện cụ thể, có căn cứ từ canonical artifact và owner thẩm quyền.; Sơ đồ chỉ lặp lại cầu nối suy luận về chuyển InReview sang Approved, nhưng không biểu diễn rủi ro bàn giao chính: trạng thái, version hoặc ngày không phải bằng chứng phê duyệt/baseline. Cần thể hiện ranh giới giữa trạng thái workflow và bằng chứng phê duyệt để tạo giá trị giải thích.
assets/diagrams/08-business-rules-state-and-decision-analysis-020-7bf1579b.mmd — REVISE — Chuyển tiếp InReview --> SentToSupplier suy ra hành động gửi đã xảy ra và tạo trạng thái SentToSupplier; section chỉ chứng minh nút còn khả dụng. Cần biểu diễn khả năng gửi tại InReview, không khẳng định chuyển trạng thái hoặc kết quả chưa quan sát.; Nút kết thúc SentToSupplier --> [*] khẳng định quy trình kết thúc sau khi gửi; section không cung cấp bằng chứng về vòng đời sau gửi. Cần bỏ kết thúc không được hỗ trợ.; Nhãn Send to supplier vẫn khả dụng trộn điều kiện giao diện với sự kiện chuyển trạng thái. Cần dùng nhãn cụ thể, phân biệt sendToSupplierAvailable = true với hành động người dùng thực hiện.; Sơ đồ bỏ ranh giới bất định quan trọng: chưa biết việc cho gửi khi InReview là lỗi hay chủ ý, và chưa có kết quả phê duyệt. Cần thể hiện giới hạn quan sát hoặc tránh mô hình hóa kết quả chưa xác minh.
assets/diagrams/08-business-rules-state-and-decision-analysis-021-2e655d61.mmd — REVISE — IN_REVIEW --> APPROVED và IN_REVIEW --> REJECTED mô tả chuyển trạng thái và kết quả chưa được phần Current Behavior xác nhận; dữ liệu còn không lưu quyết định chấp thuận hoặc từ chối. Xóa các nhánh này hoặc chỉ thể hiện chúng khi prose xác nhận hành vi hiện hành.; reviewer marks approved và reviewer marks rejected gán quyền hành động cho reviewer dù phần prose chỉ xác nhận reviewer_user_id, không xác nhận quyền quyết định. Dùng actor và điều kiện đã được xác minh.; requester edits amount mâu thuẫn với prose: bất kỳ người có quyền sửa đều có thể thay đổi dữ liệu. Đổi actor thành người dùng có quyền sửa.; edits amount quá hẹp và không phản ánh sự kiện thực tế gồm sửa quantity, unit_price hoặc supplier_id. Ghi rõ nhóm thay đổi tài chính hoặc các trường được hỗ trợ.; APPROVED --> [*] và REJECTED --> [*] biến hai trạng thái thành kết thúc quy trình dù section không xác nhận đây là trạng thái cuối hoặc không còn chuyển tiếp. Bỏ trạng thái kết thúc hoặc bổ sung bằng chứng trong prose.; Sơ đồ nằm dưới Current Behavior nhưng trộn hành vi hiện hành với vòng đời giả định. Giới hạn sơ đồ ở hành vi đã quan sát: gửi sang IN_REVIEW, gán reviewer và sửa dữ liệu vẫn giữ IN_REVIEW.
assets/diagrams/08-business-rules-state-and-decision-analysis-022-1996be4d.mmd — REVISE — QC_RELEASED --> ALLOCATED biến sự kiện cấp phát thành trạng thái toàn lô. Case chỉ cấp phát 500 KG từ 1,000 KG; phần còn lại vẫn có thể dùng. Cần giữ trạng thái QC độc lập với số lượng cấp phát hoặc thể hiện cấp phát như kết quả, không phải trạng thái kết thúc của lô.; Thiếu nhánh trọng tâm: PRD-REQ-20260807-001 lúc 10:00 gặp QC_PENDING và phải bị từ chối, không trừ tồn kho. Cần thể hiện yêu cầu bị từ chối và lô vẫn ở QC_PENDING.; Thiếu kết quả từ chối cấp phát khi lô ở QC_REJECTED, dù BR-NF-LOT-004 quy định rõ lỗi nghiệp vụ và không trừ tồn kho. Cần thêm nhánh yêu cầu cấp phát bị từ chối, giữ nguyên trạng thái.; QC_REJECTED --> [*] và ALLOCATED --> [*] ngụ ý vòng đời lô kết thúc, nhưng prose không quy định đóng, tiêu hủy, dùng hết hoặc kết thúc sau một lần cấp phát. Cần bỏ trạng thái kết thúc hoặc chỉ dùng khi có quy tắc kết thúc được hỗ trợ.; PRD-REQ accepted thiếu ID cụ thể và điều kiện lotStatus = QC_RELEASED. Cần dùng nhãn cụ thể, song song với nhãn sự kiện QC và nêu rõ điều kiện chấp nhận.
assets/diagrams/08-business-rules-state-and-decision-analysis-023-d088818a.mmd — REVISE — Thiếu phụ thuộc /01-curriculum/01_CURRICULUM_ARCHITECTURE.md, dù prose xác định luồng phụ thuộc bắt đầu từ cả tệp này và /01-curriculum/CHAPTER_MANIFEST.md; bổ sung nguồn này vào luồng.; Nhãn TEMPLATE_MANIFEST thiếu đường dẫn canonical /01-curriculum/TEMPLATE_MANIFEST.md; dùng đường dẫn đầy đủ để tránh mơ hồ.; Cạnh H --> F ngụ ý handbook tạo hoặc cấp dữ liệu cho Template hoặc artifact hạ nguồn, trong khi prose chỉ nói handbook diễn giải cách dùng và giữ liên kết; chỉnh quan hệ để thể hiện artifact tham chiếu ID và nguồn canonical, không nhận nguồn sự thật từ handbook.; Nhãn Template hoặc artifact hạ nguồn quá rộng và không thể hiện ranh giới trách nhiệm: template không tự cấp ID, registry cấp ID; làm rõ hai vai trò này trong quan hệ hoặc nhãn.
assets/diagrams/08-business-rules-state-and-decision-analysis-024-84b2bb95.mmd — REVISE — Missing BR-ID–AC-ID link. Both BR and AC rows require reciprocal traceability; add edge between BR and AC.; Missing REQ-ID–DATA-ID/API-ID link. DATA/API row requires linkage to REQ-ID; add edge from REQ to DATA/API.; Arrow direction can imply workflow or derivation, while prose defines traceability links. Clarify relationship semantics in edge labels or use non-directional links.; "Registry" and "Registered test artifact" are less concrete than named sources in prose. Use TRACEABILITY_ID_REGISTRY for NEED, REQ, AC, and registered TC references.; "DATA-ID / API-ID" ambiguously combines alternatives. Match prose wording, DATA-ID hoặc API-ID, or represent both identifiers separately.
assets/diagrams/08-business-rules-state-and-decision-analysis-025-47a0bebc.mmd — REVISE — "Đăng version" không khớp yêu cầu "ghi version" và có thể bị hiểu là phát hành artifact; cần đổi thành hành động ghi nhận version.; "Chặn dùng bản liên quan" mơ hồ về đối tượng bị chặn; cần chỉ rõ artifact hoặc phiên bản hạ nguồn chịu ảnh hưởng.; Luồng "QA traceability" đến "Giữ trạng thái IN_REVIEW" ngụ ý QA luôn dẫn đến trạng thái này, trong khi prose chỉ xác định trạng thái của v0.9.0 và cảnh báo không được hiểu thành APPROVED, BASELINED, compliant hoặc production-ready; cần giới hạn kết quả cho v0.9.0 hoặc thể hiện tiêu chí chuyển trạng thái nếu có trong nội dung.; Diagram không thể hiện rủi ro sử dụng nội dung đang review như quyết định ERP thật, dù đây là hậu quả trọng yếu giải thích lý do phải chặn; cần biểu diễn hậu quả hoặc điều kiện ngăn sử dụng.
assets/diagrams/08-business-rules-state-and-decision-analysis-026-33eac552.mmd — REVISE — PENDING_CREDIT_REVIEW --> READY_FOR_FULFILLMENT: authorized review outcome recorded invents an authorized approval path while section says final approval authority remains unverified. Remove this transition or label it as requiring a verified approval rule and verified owner.; Diagram omits explicit handling when verifiedCreditLimit is missing or unverified. Add a guarded path that keeps order in DRAFT or moves it to PENDING_CREDIT_REVIEW; never allow READY_FOR_FULFILLMENT without verified limit data.; missing or corrected credit data combines different events. Missing data requires safe holding or return to DRAFT; corrected data requires recalculating totalExposure against verifiedCreditLimit. Separate conditions or state required reassessment concretely.
assets/diagrams/08-business-rules-state-and-decision-analysis-027-d6247f62.mmd — REVISE — Các trạng thái DRAFT, APPROVED và các chuyển tiếp liên quan chưa được phần văn xuôi xác định; cần bổ sung căn cứ trong phần văn xuôi hoặc loại bỏ khỏi sơ đồ.; Nhãn quyết định hợp lệ mơ hồ: không nêu quyết định gì, tiêu chí hợp lệ hoặc ai chịu trách nhiệm; cần dùng điều kiện hoặc kết quả cụ thể được phần văn xuôi hỗ trợ.; Chuyển tiếp REVERSED --> [*] khẳng định quy trình kết thúc sau đảo bút toán, nhưng phần văn xuôi chỉ yêu cầu giữ lịch sử; cần xác nhận kết cục này trong văn xuôi hoặc bỏ chuyển tiếp kết thúc.; Sơ đồ không thể hiện khả năng xử lý sau REVERSED; nếu trạng thái này cho phép tạo lại, sửa hoặc tham chiếu chứng từ, cần thể hiện nhánh được xác nhận để tránh hiểu sai ranh giới phục hồi.
assets/diagrams/08-business-rules-state-and-decision-analysis-028-191975e5.mmd — REVISE — Nhánh VerificationRequired --> DraftRule: bổ sung bằng chứng chưa đủ điều kiện phục hồi: bằng chứng có thể vẫn thiếu thẩm quyền, quyết định hoặc liên kết truy vết. Yêu cầu thể hiện chỉ chuyển tiếp khi đủ bằng chứng nguồn và thẩm quyền; nếu chưa đủ, giữ VerificationRequired.; Nhánh DraftRule --> TraceableRule dùng nguồn + quyết định + artifact liên kết nhưng bỏ chủ thể quyết định. Yêu cầu ghi rõ quyết định thuộc Business Owner; Accounting Owner xác nhận khi công thức liên quan số liệu kế toán.; Kết thúc tại TraceableRule dễ bị hiểu thành đã phê duyệt, trái ranh giới không đổi nội dung thành “đã phê duyệt” khi chưa đủ kiểm soát. Yêu cầu phân biệt rõ trạng thái truy vết được với trạng thái phê duyệt/canonical.; Sơ đồ bỏ ranh giới vận hành quan trọng: dừng cấu hình gây tác động và giữ nội dung trong IN_REVIEW hoặc Verification required. Yêu cầu thể hiện boundary này trong trạng thái, điều kiện hoặc ghi chú của sơ đồ.; Nhãn artifact liên kết mơ hồ. Yêu cầu nêu cụ thể artifact kiểm soát và liên kết tới canonical rules cùng traceability registry như phần văn xuôi.
assets/diagrams/08-business-rules-state-and-decision-analysis-029-8e4d0b8c.mmd — REVISE — Sơ đồ thiếu chủ thể thực hiện và chủ thể quyết định. Cần thể hiện Senior BA xác minh, so sánh, ghi khuyến nghị; Business Owner, Accounting Owner, Legal Owner, Security hoặc Architect quyết định theo phạm vi.; Nhánh “Có” kết thúc ở “Ghi khuyến nghị cùng bằng chứng”, chưa thể hiện việc chuyển quyết định đến đúng thẩm quyền và ghi trạng thái quyết định. Cần thêm bước bàn giao cho chủ thể có thẩm quyền và kết quả chờ duyệt, phê duyệt hoặc từ chối.; Gateway “Quyết định thuộc một thẩm quyền?” mơ hồ. Cần diễn đạt cụ thể là quyết định thuộc một vai trò hay cần nhiều vai trò đồng phê duyệt.; “Escalate gói quyết định liên vai trò” trộn tiếng Anh, không nêu nơi nhận hoặc kết quả. Cần dùng nhãn tiếng Việt cụ thể và chỉ rõ các vai trò có thẩm quyền liên quan.; Nhánh thiếu bằng chứng chỉ dẫn đến “Không cấu hình quy tắc”, nhưng prose còn yêu cầu ghi nguồn hoặc dữ liệu thiếu, giữ trạng thái hiện tại và yêu cầu đúng owner xác nhận. Cần thể hiện các bước này để tránh biến dừng cấu hình thành kết quả không có đường xử lý tiếp.; Sơ đồ không thể hiện rủi ro còn lại, giả định, lựa chọn bị loại và tiêu chí so sánh trong gói khuyến nghị dù prose xác định đây là thành phần bắt buộc của khuyến nghị có thể phòng vệ.
assets/diagrams/08-business-rules-state-and-decision-analysis-030-aee4818d.mmd — REVISE — Sơ đồ thêm CANONICAL_DATA_DICTIONARY và TEMPLATE_MANIFEST, nhưng đoạn văn chỉ xác nhận rõ CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY là nguồn canonical. Chỉ giữ các artifact được bảng Quick Reference xác nhận hoặc bổ sung căn cứ trong prose.; Nhãn nguồn tra template dự kiến mơ hồ về trạng thái, thẩm quyền và quan hệ với chapter. Làm rõ đây là nguồn hiện hành hay kế hoạch; nếu chỉ dự kiến, không trình bày như dependency đã tồn tại.; Sơ đồ không thể hiện quyết định cốt lõi: chapter chỉ tham chiếu artifact canonical và không thay catalog. Thể hiện rõ ranh giới này để tránh hiểu chapter là nguồn chân lý.; Sơ đồ bỏ trạng thái IN_REVIEW và có thể khiến rule hoặc artifact bị hiểu là đã phê duyệt. Thể hiện trạng thái chưa xác minh hoặc giới hạn phạm vi sơ đồ.; Sơ đồ bỏ phân quyền: Principal IT Business Analyst / Technical Curriculum Author quản trị; Business Owner, Quality Owner và Architect quyết định phần thuộc thẩm quyền. Thể hiện ownership hoặc ghi rõ sơ đồ chỉ mô tả dependency, không mô tả approval.; Nhu cầu gồm nơi ghi quyết định, nhưng sơ đồ chỉ chỉ ra nguồn rule, ID, dữ liệu và template. Bổ sung nguồn canonical cho quyết định nếu prose và Quick Reference có xác nhận; nếu không, thu hẹp tuyên bố của sơ đồ.
assets/diagrams/08-business-rules-state-and-decision-analysis-031-4226abc1.mmd — REVISE — Nhánh “Không” đi thẳng tới “Đủ điều kiện handoff review” sau hai bước đối chiếu, nhưng section còn bắt buộc kiểm tra version v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, dữ liệu Nova Foods, template, rule, data dictionary và các mục Verification required. Bổ sung gateway hoặc bước xác nhận toàn bộ điều kiện bắt buộc trước kết quả handoff.; Nhãn “Escalation đúng owner” mơ hồ và có thể làm mất yêu cầu escalation cho toàn bộ owner liên quan khi rule chạm nhiều miền. Nêu rõ phải chuyển tới tất cả owner có thẩm quyền liên quan; Principal IT Business Analyst / Technical Curriculum Author chỉ lập gói truy vết.; Luồng sự cố kết thúc tại “Giữ IN_REVIEW, không gọi approved hay baselined” nhưng bỏ điều kiện đóng issue và kết quả sau xác minh. Thể hiện issue tiếp tục mở cho tới khi có bằng chứng hoặc approval/baseline reference hợp lệ, rồi mới đánh giá lại handoff.; Gateway gộp “mâu thuẫn” và “cần thẩm quyền chuyên môn” nhưng nhánh xử lý dùng “open issue hoặc Verification required” không chỉ rõ tiêu chí chọn. Phân biệt mâu thuẫn cần open issue với nội dung chưa được owner xác minh cần nhãn Verification required; cho phép cả hai khi cùng áp dụng.; Sơ đồ không thể hiện ranh giới quan trọng: handoff chỉ chuyển chapter, bảng issue và bằng chứng để review; không tạo approval, baseline, compliance hoặc trạng thái production-ready. Bổ sung kết quả handoff cụ thể để tránh diễn giải “đủ điều kiện” thành được phê duyệt.
assets/diagrams/09-functional-specification-writing-001-ead38d22.mmd — REVISE — Gateway Mã hàng, lô, số lượng hợp lệ? bỏ qua đơn vị tính dù Object, Artifact và bảng phạm vi dữ liệu đều yêu cầu xử lý đơn vị tính. Bổ sung đơn vị tính vào điều kiện kiểm tra.; Nhãn hợp lệ không nêu tiêu chí kiểm tra và có thể bị hiểu như quy tắc nghiệp vụ đã xác nhận, trong khi nguồn canonical còn IN_REVIEW. Gắn Verification required hoặc diễn đạt rõ đây là điều kiện cần được nguồn có thẩm quyền xác nhận.
assets/diagrams/09-functional-specification-writing-002-78aaa6f4.mmd — REVISE — Nhánh “Có” bỏ qua điều kiện nghiệp vụ trọng yếu: kiểm tra mã hàng, mã lô và số lượng; số lượng không lớn hơn 0 phải không tạo nhận hàng và trả lỗi; dữ liệu hợp lệ mới tạo giao dịch và cập nhật tồn. Cần thể hiện gateway, nhánh lỗi và nhánh thành công này.; Gateway “Functional Specification nêu điều kiện?” mô tả chất lượng tài liệu thay vì quyết định nghiệp vụ khi gửi nhận hàng. Cần dùng điều kiện kiểm tra dữ liệu cụ thể được nêu trong phần văn xuôi.; Nhãn “Developer build theo hành vi xác định” và “QA kiểm tra kết quả mong đợi” còn trừu tượng, không cho biết hành vi hay kết quả nào. Cần gắn nhãn với chặn giao dịch không hợp lệ, trả lỗi, tạo giao dịch và cập nhật tồn.; “Traceability giữ nguồn và thẩm quyền” mơ hồ, thiếu chủ thể và nguồn cụ thể. Cần nêu việc truy vết quy tắc tới /01-curriculum/CANONICAL_BUSINESS_RULES.md và dữ liệu tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md, hoặc bỏ bước nếu sơ đồ chỉ mô tả luồng xử lý nhận hàng.; Nhánh “Không” khẳng định tuyến tính rằng thiếu điều kiện sẽ dẫn tới lỗi ở review hoặc UAT rồi rework. Văn xuôi mô tả đây là rủi ro có thể xảy ra, không phải kết quả tất định. Cần diễn đạt như rủi ro hoặc khả năng, tránh quan hệ nhân quả tuyệt đối.
assets/diagrams/09-functional-specification-writing-003-bd487999.mmd — REVISE — Thứ tự C → D mâu thuẫn đặc tả: sơ đồ gán unit_price_vnd trước khi xác nhận, trong khi bảng nêu giá được sao chép khi người dùng xác nhận đơn. Cần thể hiện thao tác xác nhận kích hoạt tra cứu và gán giá.; Sơ đồ không thể hiện kết quả quan trọng sau xác nhận: thay đổi Price List không tự sửa unit_price_vnd của đơn đã xác nhận. Cần bổ sung trạng thái giá đã khóa hoặc nhánh thay đổi bảng giá sau xác nhận.; Nhãn “Tìm Price List hiệu lực” thiếu tiêu chí đã nêu: customer_id, item_id và ngày tạo Sales Order. Cần ghi đủ điều kiện tra cứu hoặc gắn chúng với bước tìm giá.; Nhánh không có giá chỉ thể hiện chặn và báo lỗi, bỏ kết quả xử lý được nêu: người dùng sửa dữ liệu hoặc chuyển xử lý theo quy trình đặc tả. Cần thể hiện chủ thể và hướng xử lý ngoại lệ.
assets/diagrams/09-functional-specification-writing-004-752cd148.mmd — REVISE — Gateway “Có nguồn kiểm tra được?” quá rộng: có nguồn không tự động biến phát biểu thành Verified fact. Nguồn phải xác định, phù hợp, đủ chứng minh, có thời điểm và phạm vi kiểm tra. Sửa điều kiện để phản ánh các tiêu chí này.; Nhánh F -->|Không| H[Verification-required claim] phân loại mọi phát biểu không có nguồn, không do stakeholder cung cấp và không cần tạm dùng thành verification-required claim. Loại này chỉ áp dụng cho claim 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. Bổ sung điều kiện tác động và nhánh xử lý phát biểu không thuộc năm loại.; Sơ đồ ngụ ý Stakeholder input, Project assumption và Verification-required claim phải đi qua gateway Decision mới vào Functional Specification. Bảng quy định cả ba đều được ghi trong Functional Specification với nhãn, bằng chứng và giới hạn tương ứng; verification-required claim không được trở thành requirement bắt buộc. Sửa luồng để tách “được ghi có truy vết” khỏi “được chuyển thành rule bắt buộc”.; Gateway “Có phương án và authority ghi nhận?” thiếu tiêu chí lựa chọn và artifact quyết định, dù section định nghĩa Decision cần phương án, tiêu chí, authority và artifact. Bổ sung đủ điều kiện hoặc dùng nhãn bao quát chính xác.; Luồng từ E, G và H cùng vào Decision làm mờ nguyên tắc không đổi nhãn bằng cách viết lại. Decision là phát biểu lựa chọn có thẩm quyền, không phải trạng thái thay thế tự động cho input, assumption hoặc claim; các phát biểu gốc vẫn cần giữ truy vết. Thể hiện Decision như bản ghi riêng liên kết với nguồn đầu vào.; Nhánh Verified fact đi thẳng tới “Functional Specification có truy vết” nhưng không thể hiện yêu cầu nêu nguồn, ngày kiểm tra và phạm vi. Bổ sung outcome hoặc điều kiện truy vết cụ thể.; Nhãn “Không viết thành rule bắt buộc” chỉ xuất hiện sau gateway Decision, trong khi giới hạn này đặc biệt áp dụng ngay cho stakeholder input và verification-required claim chưa được xác nhận. Đặt ràng buộc tại đúng nhánh để tránh hiểu rằng assumption hoặc input mặc nhiên có thể thành rule nếu quy trình phân loại bị bỏ qua.
assets/diagrams/09-functional-specification-writing-005-b2baaed7.mmd — REVISE — Nhánh F --> DE gắn nhãn Exit Analysis sai vị trí: Analysis đã kết thúc trước Functional Specification. Đổi thành gate vào Delivery hoặc exit của bước đặc tả, phù hợp điều kiện “Functional Specification mô tả hành vi quan sát được”.; Nhánh O --> D chỉ cho phép quay về Discovery, trong khi bảng quy định nhu cầu đổi hành vi quay về Discovery hoặc Analysis. Bổ sung nhánh có điều kiện tới Analysis để không làm mất đường xử lý đã được nêu.; Nhãn mục chưa rõ gắn Verification required hoặc project assumption nhập nhằng giữa điều chưa được xác minh và giả định dự án. Dùng đúng hệ nhãn trong prose, đặc biệt verification-required claim, và nêu điều kiện dùng project assumption nếu giữ nhãn này.; Gate Entry Analysis chỉ nêu phạm vi, mục tiêu và stakeholder input, nhưng bảng còn yêu cầu câu hỏi mở và nguồn đầu vào được ghi nhận. Bổ sung các điều kiện này hoặc rút nhãn về mức không tuyên bố đầy đủ gate.; Nhãn Entry Specification tạo cảm giác Specification là giai đoạn có gate riêng, trong khi bảng chỉ định nghĩa các giai đoạn Discovery, Analysis, Delivery, Testing, Release và Operations; Functional Specification là artifact/vai trò. Làm rõ đây là kết quả của Analysis, không phải giai đoạn lifecycle độc lập.
assets/diagrams/09-functional-specification-writing-006-428b0b8c.mmd — REVISE — Thiếu handoff Downstream: Release/Operations tới Release Manager và Operations Owner, gồm artifact thay đổi có truy vết và ảnh hưởng vận hành. Bổ sung luồng này để không làm mất owner và ranh giới phát hành.; Thiếu ranh giới thẩm quyền BA đối với production readiness và quyền production. Thể hiện owner có quyền quyết định thay vì để sơ đồ ngầm kết thúc tại BA, Developer hoặc QA.; Nút ESC gộp Business Owner, Legal, Accounting, Security và Architect thành một owner mơ hồ. Tách hoặc gắn điều kiện escalation cụ thể cho quyết định nghiệp vụ, dữ liệu cá nhân, kế toán/hóa đơn, bảo mật và kiến trúc.; Luồng Architect trả “Ràng buộc kỹ thuật” cho BA chưa được mô tả như handoff trong bảng. Chỉnh nhãn theo nội dung được hỗ trợ, như quyết định kiến trúc sau escalation, hoặc bỏ luồng.; Thiếu escalation khi mục tiêu mâu thuẫn, quy tắc hoặc dữ liệu xung đột với nguồn canonical, tiêu chí không kiểm thử được, và test phát hiện mâu thuẫn. Bổ sung nhánh ngoại lệ hoặc thể hiện rõ đây là phạm vi bị lược bỏ.
assets/diagrams/09-functional-specification-writing-007-7f6cabce.mmd — REVISE — Bốn gate, tiêu chí Có/Không và vòng lặp sửa lại không được phần prose xác lập; bỏ các gateway/nhánh này hoặc bổ sung prose nêu rõ đây là kiểm tra chất lượng minh họa, không phải baseline hay phê duyệt ERP thực.; Các chi tiết “Cấu hình”, “Đối chiếu test basis”, “Đưa thay đổi theo kiểm soát”, “sự cố, phản hồi” và vòng Operations quay lại Discovery vượt quá nội dung được hỗ trợ; bỏ hoặc giải thích từng bước và quan hệ trong prose.; Nhãn trộn tiếng Việt với “requirement” và “test basis”, làm giảm tính song song và cụ thể; dùng thuật ngữ nhất quán với ngôn ngữ tài liệu.; Gateway không nêu chủ thể chịu trách nhiệm đánh giá, trong khi hình thức gate dễ gợi ý quyền phê duyệt; nêu owner nếu section muốn mô tả governance, nếu không thì tránh biểu diễn như cổng quyết định chính thức.
assets/diagrams/09-functional-specification-writing-008-16453d65.mmd — REVISE — Quan hệ D[Canonical ID ổn định] --> E[Functional Specification] mô tả Canonical ID như đầu vào nội dung độc lập, trong khi prose định nghĩa ID là cơ chế liên kết ổn định giữa các artifact. Cần thể hiện Canonical ID gắn với artifact nguồn và hỗ trợ truy vết, không song song với kiến thức, bằng chứng và artifact như nguồn nội dung.; Nhãn Hành vi chức năng có truy vết mơ hồ về đối tượng được truy vết. Cần nêu rõ hành vi trong Functional Specification được liên kết về nhu cầu nghiệp vụ, quy tắc, định nghĩa dữ liệu và nguồn có thẩm quyền.
assets/diagrams/09-functional-specification-writing-009-1d862629.mmd — REVISE — Gateway “Có ID và đường dẫn canonical?” áp cho mọi input, trái với bảng phân loại gồm nguồn official, nguồn legal và project assumption không nhất thiết có đường dẫn canonical. Sửa điều kiện thành kiểm tra nhận diện và nguồn gốc phù hợp với từng loại nguồn.; Luồng chưa kiểm tra đủ các điều kiện đã quyết định: quality result, verification status và khả năng truy vết. Bổ sung gateway hoặc thể hiện rõ các điều kiện này trước trạng thái “Đủ điều kiện làm evidence”.; Nhãn “Freshness và owner đủ?” mơ hồ. Sửa thành điều kiện cụ thể về ngày kiểm tra còn hiệu lực và owner có thẩm quyền xác nhận.; Nhãn “Escalation đúng owner” không nêu owner theo phạm vi thẩm quyền. Làm rõ chuyển đến Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA tùy vấn đề.; Gateway chỉ nêu “Mâu thuẫn nguồn canonical”, trong khi BA phải nêu mọi mâu thuẫn nguồn ảnh hưởng requirement. Bỏ giới hạn “canonical” hoặc giải thích vì sao chỉ loại mâu thuẫn này tạo cổng dừng.
assets/diagrams/09-functional-specification-writing-010-e381c52b.mmd — REVISE — Nhãn "Nguồn canonical và nguồn ngoài" quá rộng; cần phân biệt artifact canonical với nguồn pháp lý và thể hiện yêu cầu nguồn còn hiệu lực.; Gateway "Đủ bằng chứng và đúng thẩm quyền?" thiếu tiêu chí nguồn còn hiệu lực; cần phản ánh đủ ba điều kiện: nội dung đủ, nguồn còn hiệu lực, đúng thẩm quyền xác nhận.; Sơ đồ bỏ qua chủ thể xác nhận dù Authority phân vai Legal Owner, domain owner, Business Owner, Architect và Accounting Owner; cần thể hiện việc chuyển nội dung chưa chắc chắn tới đúng owner thay vì chỉ gắn trạng thái.; Nhánh "Không" gộp mọi trường hợp thiếu bằng chứng, nguồn hết hiệu lực và thiếu xác nhận; cần cho thấy các trường hợp này đều dẫn tới VERIFICATION REQUIRED và không được tạo business rule, data field hoặc thời hạn lưu giả định.; Kết quả "Không viết rule bắt buộc" hẹp hơn Decision; cần bao quát cả việc không tạo data field và thời hạn lưu giả định.
assets/diagrams/09-functional-specification-writing-011-8ca98b29.mmd — REVISE — Thiếu điều kiện số lượng đạt > 0. Gateway B chỉ kiểm tra có số lượng, nên số lượng 0 hoặc âm vẫn có thể đi tới cập nhật tồn. Bổ sung kiểm tra giá trị lớn hơn 0 trước khi tạo nhận kho.; Nhãn Lệnh sản xuất hợp lệ chưa cụ thể bằng prose, vốn nêu kiểm tra trạng thái lệnh. Ghi rõ trạng thái lệnh phải hợp lệ để tạo test basis rõ.; Nhánh C thất bại dùng ERP từ chối giao dịch nhưng Decision yêu cầu lỗi hiển thị theo trường. Thể hiện lỗi tại trường lệnh sản xuất hoặc số lô và xác nhận không lưu.
assets/diagrams/09-functional-specification-writing-012-fc397372.mmd — REVISE — Các mũi tên từ Functional specification đến ba artifact biểu thị cập nhật vô điều kiện, trái với điều kiện trong bảng: registry chỉ cập nhật khi cần cấp hoặc liên kết ID; catalog chỉ cập nhật khi làm rõ quy tắc; từ điển chỉ cập nhật khi có dữ liệu hoặc kiểm tra mới. Cần thể hiện rõ từng điều kiện hoặc quan hệ phụ thuộc thay vì luồng cập nhật bắt buộc.; Hướng mũi tên không hỗ trợ câu “chỉ rõ artifact nguồn trước khi mô tả chức năng”: sơ đồ đang thể hiện Functional specification dẫn đến các nguồn canonical. Cần sửa hướng hoặc ký hiệu quan hệ để cho thấy nguồn canonical chi phối và cung cấp căn cứ cho specification.; Nút Change history mơ hồ và sai phạm vi: bảng yêu cầu lịch sử thay đổi cho cả Functional specification và từng artifact, nhưng sơ đồ chỉ nối ba artifact canonical vào một nút chung, dễ hiểu thành một lịch sử tập trung và bỏ lịch sử của specification. Cần thể hiện lịch sử gắn với từng artifact hoặc ghi rõ đây là yêu cầu lịch sử riêng cho mỗi artifact.; Sơ đồ gần như lặp lại các tên artifact trong bảng nhưng bỏ các điều kiện cập nhật, owner, trạng thái IN_REVIEW, cấm tự cấp ID và giới hạn rằng change history không thay thế phê duyệt. Cần bổ sung giá trị giải thích bằng quan hệ và điều kiện chính xác, không chỉ liệt kê liên kết.
assets/diagrams/09-functional-specification-writing-013-8bf56faa.mmd — REVISE — Gateway “Đủ dữ liệu bắt buộc?” chưa nêu đủ tiêu chí đã xác định trong prose: mã lô, ngày sản xuất, mã mặt hàng và số lượng lớn hơn 0. Cần ghi điều kiện cụ thể để người đọc không tự đoán.; Nhánh “Không” chỉ nói “báo trường thiếu”, nên bỏ sót trường hợp số lượng bằng 0 hoặc âm: dữ liệu có mặt nhưng không hợp lệ. Cần bao quát cả trường thiếu và giá trị số lượng không hợp lệ.; Kết quả “Đầu vào truy vết và kiểm thử” gộp hai mục đích khác nhau, chưa thể hiện liên kết qua TRACEABILITY_ID_REGISTRY và test basis như prose yêu cầu. Cần làm rõ đây là kết quả đọc xuống dòng, không phải bước xử lý hệ thống.
assets/diagrams/09-functional-specification-writing-014-5109c63c.mmd — REVISE — Gateway conditions omit required checks for clarity, traceability, correct artifact identity, authority boundaries, and change history. Required correction: represent all gate conditions or reference complete quality-gate criteria without implying evidence and contradiction checks alone are sufficient.; Flow C --> E implies IN_REVIEW follows readiness as new state. Section says status remains IN_REVIEW before and after gate. Required correction: show IN_REVIEW as unchanged status, not subsequent outcome.
assets/diagrams/09-functional-specification-writing-015-359e9d64.mmd — REVISE — Nhãn "Test case và kết quả test" bổ sung "kết quả test" nhưng phần văn xuôi chỉ nêu QA lập test case, kiểm tra dữ liệu và xác định test basis; cần bỏ kết quả test hoặc bổ sung căn cứ trong nội dung.; Nhãn "Đối chiếu giá trị nghiệp vụ" rộng hơn nội dung được hỗ trợ, vốn chỉ nêu đối chiếu rule với nhu cầu và truy ngược kết quả về nhu cầu ban đầu; cần dùng nhãn cụ thể theo nội dung.; Các cạnh từ Functional Specification đến actor không thể hiện output nào được actor nào sử dụng, làm mất quan hệ nhiều-nhiều và mục đích sử dụng đã nêu trong bảng; cần biểu diễn output hoặc nhóm output làm trung gian.; Sơ đồ gần như lặp lại danh sách consumer nhưng ít chi tiết hơn bảng, nên chưa tạo thêm giá trị giải thích; cần làm rõ luồng chuyển giao từ output đến consumer rồi đến hoạt động hoặc kết quả.
assets/diagrams/09-functional-specification-writing-016-8e13452f.mmd — REVISE — Luồng escalation kết thúc tại BA, dễ hiểu BA là người xử lý cuối. Thêm đích đến là vai trò có thẩm quyền kết luận; giữ BA ở vai trò duy trì traceability.; Thiếu kết quả sau escalation: quyết định được ghi nhận hoặc gắn nhãn Verification required khi nguồn hay thẩm quyền chưa đủ. Bổ sung nhánh kết quả này.; Nhãn thiếu rule hoặc API boundary không khớp đầy đủ điều kiện của Developers; API boundary cũng mơ hồ hơn nội dung thay đổi API liên hệ thống. Dùng điều kiện cụ thể, đúng phạm vi.; Nhãn security hoặc integration risk gộp nhiều loại escalation của Architect và bỏ các ranh giới trọng yếu như system boundary, dữ liệu cá nhân, xác thực và tính sẵn sàng. Thể hiện nhóm điều kiện cụ thể hoặc ghi rõ đây là ví dụ.; Nút Escalation package không thể hiện thành phần tối thiểu quyết định đang bị chặn, bằng chứng, lựa chọn, tác động và vai trò cần kết luận. Bổ sung nội dung cốt lõi hoặc nhãn tham chiếu rõ tới gói tối thiểu trong prose.
assets/diagrams/09-functional-specification-writing-017-e03e5fa5.mmd — REVISE — Kết quả “Người nhận dùng đầu ra đã làm rõ” dễ bị hiểu là được phép triển khai. Cần nêu rõ việc làm rõ không đổi trạng thái IN_REVIEW và không tạo baseline, approval, cấu hình ERP hay quyền triển khai.; Nhãn “Escalate đúng owner” không cụ thể và trộn ngôn ngữ. Cần xác định owner chuyên môn theo vấn đề hoặc dùng nhãn tiếng Việt thể hiện rõ trách nhiệm chuyển cấp.; Luồng thiếu kết quả khi owner chưa xác minh hoặc vấn đề chưa được giải quyết. Cần giữ trạng thái chưa xác minh, như Verification required, thay vì luôn hội tụ vào đầu ra đã làm rõ.; Bước “BA ghi nhận giả định hoặc vấn đề” chưa phân biệt giả định với vấn đề cần xác minh. Cần thể hiện cách ghi nhận phù hợp và duy trì truy vết trong artifact.
assets/diagrams/09-functional-specification-writing-018-37cdcf57.mmd — REVISE — Sơ đồ khẳng định thứ tự thao tác tuyến tính: chọn kho, nhập dòng 1, xem 80 thùng, nhập dòng 2, xem 60 thùng. Phần văn xuôi chỉ xác nhận các giá trị xuất hiện theo từng dòng, không cung cấp bằng chứng về thứ tự nhập hoặc thời điểm hiển thị. Cần loại bỏ hàm ý tuần tự chưa được chứng minh hoặc ghi rõ đây là trình tự quan sát được.; Nhãn “Chọn Kho Bình Dương” mô tả hành động chưa được phần văn xuôi xác nhận; dữ liệu chỉ xác định Kho Bình Dương là kho giao mô phỏng. Cần dùng trạng thái kho giao đã xác định hoặc bổ sung bằng chứng cho thao tác chọn kho.; Luồng tuyến tính không làm rõ điểm kiểm tra chính: dòng 1 thiếu 40 thùng theo số đang hiển thị, dòng 2 bằng số lượng đặt, nhưng hệ thống vẫn lưu toàn bộ đơn. Cần thể hiện quan hệ so sánh từng dòng và kết quả lưu chung mà không biến số 80 thành tồn kho khả dụng.
assets/diagrams/09-functional-specification-writing-019-a51d0455.mmd — REVISE — Nhãn "Chặn lưu dòng phiếu" không khớp nhất quán với phạm vi kiểm soát: phần Decision nêu "lưu hoặc xác nhận", còn Business rule chỉ nêu "khi xác nhận". Cần dùng đúng trigger đã được thống nhất hoặc thể hiện riêng hai sự kiện.; Nhánh lô quá hạn kết thúc tại "Không trừ tồn, không tạo bút toán" nhưng bỏ bước bắt buộc người dùng chọn lô hợp lệ khác, dù Underlying Need nêu rõ yêu cầu này. Cần thêm trạng thái quay lại chọn lô.; Sơ đồ trình bày quy tắc như hành vi đã chốt, trong khi artifact đang IN_REVIEW, v0.9.0 và chưa có authorized decision. Cần ghi rõ đây là luồng đề xuất hoặc điều kiện áp dụng sau phê duyệt.; Chuỗi "Chặn lưu" rồi "Hiện..." rồi "Không trừ tồn..." khiến các kết quả kiểm soát trông như hành động tuần tự. Cần thể hiện thông báo lỗi, phiếu chưa xác nhận, tồn không đổi và không sinh giao dịch là các kết quả cùng nhánh chặn.
assets/diagrams/09-functional-specification-writing-020-23b31aff.mmd — REVISE — Sơ đồ trình bày 409 INSUFFICIENT_AVAILABLE_STOCK và không tạo InventoryReservation như hành vi đã quyết định, trong khi section chỉ ghi đây là khuyến nghị IN_REVIEW, chưa được Business Owner và Architect phê duyệt. Cần gắn rõ luồng là khuyến nghị/chưa phê duyệt.; Nhãn Chili=150; Fish=70 không dùng định danh canonical của scenario. Cần dùng SKU-NF-CHILI-500=150 và SKU-NF-FISH-500=70 để tránh mơ hồ.; Bước So sánh với 120 và 80 không nêu điều kiện quyết định. Cần ghi rõ kiểm tra đủ tồn cho toàn bộ dòng và xác định 70 < 80 theo BR-INV-002.; Thông điệp xác nhận không thể hiện interface đã đặc tả. Cần gắn POST /api/v1/sales-orders/SO-20260807-001/confirm thay cho nhãn chung Confirm SO-20260807-001.
assets/diagrams/09-functional-specification-writing-021-b4899df7.mmd — REVISE — Hai node "Test artifact downstream" và "Build/API artifact downstream" không được phần văn xuôi xác định cụ thể. Xóa chúng hoặc bổ sung nội dung nguồn chứng minh các artifact này cần đầu ra của Functional Specification.; Nhãn "Template dự kiến" không khớp bảng, nơi Functional Specification dùng "Template phù hợp để ghi đặc tả". Sửa nhãn theo nội dung canonical.; Các cạnh không có nhãn nên chưa phân biệt rõ quan hệ "làm nguồn đầu vào" với "cần đầu ra". Gắn nhãn quan hệ hoặc dùng cách thể hiện khác để nghĩa chiều mũi tên không mơ hồ.
assets/diagrams/09-functional-specification-writing-022-9176281e.mmd — REVISE — Liên kết DATA --> TC không được phần văn bản hỗ trợ; bảng chỉ yêu cầu TC liên kết AC và REQ. Xóa liên kết này.; Thiếu liên kết trực tiếp REQ --> TC, dù bảng quy định TC phải liên kết cả AC và REQ. Thêm liên kết này.
assets/diagrams/09-functional-specification-writing-023-1a9a5022.mmd — REVISE — "Review theo thẩm quyền" đưa thêm khái niệm thẩm quyền không được phần văn xuôi xác lập; cần bỏ yếu tố này hoặc bổ sung căn cứ trong văn xuôi.; Các nhánh "Functional Specification", "API hoặc Data mapping" và "Acceptance Criteria và Test Case" là tên artifact, không thể hiện hành động bắt buộc rà soát nội dung đã diễn giải từ nguồn; cần làm rõ đây là các đối tượng phải rà soát.; Ba nhánh phạm vi ảnh hưởng có thể bị hiểu là danh sách đầy đủ, trong khi văn xuôi còn nêu dữ liệu, quy tắc, giao diện, định danh, requirement và cấu hình; cần thể hiện phạm vi mở hoặc bao quát mọi nội dung phụ thuộc.; Luồng kết thúc ở cập nhật liên kết truy vết nhưng không thể hiện kết quả cập nhật nội dung bị ảnh hưởng, version và lịch sử thay đổi; cần bổ sung hoặc làm rõ kết quả kiểm soát thay đổi theo văn xuôi.
assets/diagrams/09-functional-specification-writing-024-3be9bdf2.mmd — REVISE — Nhánh “Không” kết thúc tại IN_REVIEW nhưng không thể hiện bước nhận câu trả lời, đối chiếu lại hoặc quay về gateway; bổ sung vòng làm rõ để trạng thái có lối ra.; Bước “QA rà soát lại test basis” đưa vào actor QA và thuật ngữ test basis chưa được section xác lập; dùng owner và artifact được prose hỗ trợ hoặc bổ sung chúng trong prose.; Bước cập nhật thiếu yêu cầu ghi impact analysis trước khi sửa và cập nhật artifact trong cùng change record; thể hiện hai điều kiện này trong luồng.; Luồng không nêu kết quả khi rà soát thất bại hoặc đạt; bổ sung gateway cùng nhánh sửa tiếp và hoàn tất để tránh kết thúc mơ hồ.; Các bước đầu không có owner dù trách nhiệm quan trọng; xác định vai trò thực hiện từ prose hoặc giữ nhãn trung tính nhưng không gán actor mới.
assets/diagrams/09-functional-specification-writing-025-d9c6dcfb.mmd — REVISE — Gateway B thiếu hai điều kiện cảnh báo được prose quy định: hạch toán sai và phát hành sai. Bổ sung đủ điều kiện kích hoạt hoặc dùng nhãn bao quát chính xác.; Bước D không nêu người có trách nhiệm dừng xử lý. Xác định actor hoặc vai trò được quyền chặn giao dịch.; Bước D giả định mọi sự cố đều xử lý bằng chặn giao dịch, không phù hợp rõ ràng với lộ dữ liệu hoặc phát hành sai. Phân nhánh biện pháp ngăn chặn theo loại sự cố.; Bước G dùng nhãn mơ hồ “theo quyền”; bước H dùng “được thẩm quyền xác nhận” nhưng không xác định ai có thẩm quyền quyết định. Nêu vai trò phê duyệt khôi phục, đảo hoặc điều chỉnh.; Ranh giới khôi phục chưa đủ: diagram không phân biệt dữ liệu được sửa với dữ liệu phải giữ làm bằng chứng. Nêu rõ hai nhóm và cấm sửa hoặc xóa bằng chứng.; Diagram không thể hiện các kiểm tra bắt buộc quanh đơn bán: trạng thái đơn, giao dịch phát sinh sau đơn, tồn kho, hóa đơn và log kiểm toán. Bổ sung chúng vào đánh giá hậu quả và kiểm tra sau khôi phục.; Gateway F “Có giao dịch hậu quả?” mơ hồ. Dùng điều kiện cụ thể về giao dịch phát sinh sau đơn và tác động liên quan.; Bước I “Kiểm tra lại” không nêu đối tượng, tiêu chí hoặc người kiểm tra. Ghi rõ kiểm tra tính nhất quán của đơn, tồn kho, hóa đơn và audit log trước khi đóng.; Bước J trộn tiếng Việt với “traceability” và không nêu bằng chứng đóng sự cố. Dùng nhãn tiếng Việt cụ thể, yêu cầu liên kết defect, quyết định, thay đổi dữ liệu và log kiểm toán.
assets/diagrams/09-functional-specification-writing-026-cc83d0ba.mmd — REVISE — Luồng dừng tại lỗi đầu tiên, khiến năm loại lỗi trông loại trừ lẫn nhau dù một requirement có thể mắc nhiều lỗi. Cần cho phép kiểm tra và ghi nhận độc lập cả năm loại.; Gateway “Có bằng chứng authority?” quá rộng và mơ hồ. Cần giới hạn kiểm tra vào các khẳng định về phê duyệt, baseline, nghĩa vụ pháp lý hoặc quyết định nghiệp vụ, đồng thời yêu cầu approval reference hoặc owner xác minh.; Gateway “Có liên kết ID canonical?” làm yếu tiêu chí truy vết. ID canonical đơn lẻ không đủ; cần kiểm tra liên kết tới source, rule, decision, acceptance criteria và test basis theo prose.; Gateway “Ký pháp đúng chuẩn đã nêu?” thiếu phạm vi áp dụng và có thể buộc mọi requirement draft phải chứa ký pháp. Cần nêu rõ kiểm tra này chỉ áp dụng khi artifact dùng sơ đồ hoặc ký hiệu.; Các nhãn “authority chưa xác minh”, “notation misuse” và “traceability break” không song song với năm thuật ngữ tiếng Việt đã định nghĩa. Cần dùng nhất quán “khẳng định thẩm quyền không có chứng cứ”, “dùng sai ký pháp” và “đứt truy vết”.; Kết quả “Đủ điều kiện review” gây lệch logic vì sơ đồ bản thân là bước review. Cần dùng kết quả cụ thể như không phát hiện năm loại lỗi trong lần kiểm tra này, không hàm ý phê duyệt.
assets/diagrams/09-functional-specification-writing-027-b5b7a00c.mmd — REVISE — Nhánh “Có” kết thúc tại “Ghi rule, nguồn, phạm vi, authority”, bỏ thiếu điều kiện quyết định hợp lệ: artifact kiểm soát phải ghi người có thẩm quyền, căn cứ và trạng thái phù hợp. Bổ sung điều kiện này trước khi rule được coi là quyết định hoặc baseline.; Nút “Đủ để kết luận rule?” mơ hồ về tiêu chí và chủ thể kết luận. Làm rõ bằng chứng đã được xác minh và Decision authority đã quyết định; BA không tự kết luận rule.; Nút cuối “Giữ trạng thái IN_REVIEW đến khi có bằng chứng” ngụ ý có bằng chứng là đủ để thoát IN_REVIEW, trong khi prose còn yêu cầu quyết định có thẩm quyền và trạng thái artifact phù hợp. Sửa điều kiện thoát trạng thái để gồm cả xác minh và quyết định được ghi nhận.; Luồng “Không” chỉ định Decision authority nhưng không thể hiện bước authority quyết định hoặc kết quả xác minh quay lại đánh giá rule. Bổ sung gateway kết quả xác minh/quyết định và đường quay lại hoặc kết thúc bằng trạng thái chưa quyết định.; Sơ đồ bỏ thiếu hậu quả nếu giả định sai, dù section coi đây là trường ghi nhận quan trọng. Thêm kết quả/rủi ro tương ứng như duyệt sai cấp, chặn mua hợp lệ hoặc tạo kiểm soát tài chính chưa được xác nhận.
assets/diagrams/09-functional-specification-writing-028-af0b0489.mmd — REVISE — Nút D thêm owner và quality gate, nhưng phần văn xuôi không xác nhận TEMPLATE_MANIFEST chứa hai trường này. Chỉ giữ thông tin được nguồn xác nhận.; Nút G thêm trạng thái IN_REVIEW và hành động yêu cầu đăng ký, nhưng phần văn xuôi không quy định trạng thái hoặc quy trình đăng ký này. Xóa hoặc bổ sung căn cứ trong văn xuôi.; Nút F Tham chiếu TEMPLATE_MANIFEST mơ hồ trong nhánh không có template: chưa nêu tham chiếu manifest nhằm ghi nhận thiếu canonical template, không phải dùng manifest như template. Làm rõ mục đích.
assets/diagrams/09-functional-specification-writing-029-b448345b.mmd — REVISE — "Section 12 checklist" is unsupported by surrounding prose; replace it with supported activity "Tra cứu chapter" or remove node.; "Canonical catalogs" is ambiguous and hides two distinct dependencies; show CANONICAL_BUSINESS_RULES and CANONICAL_DATA_DICTIONARY separately.; "filled artifact" is not established by surrounding prose; remove it or provide supporting prose.; Diagram omits shared IN_REVIEW status, v0.9.0 version, and 2026-08-07 date, which define critical boundary for every artifact.; Diagram omits required outcome: link only registered IDs and paths, and do not call content baseline, approved, or operational rules.; Diagram omits actor identified by prose, "người học", leaving ownership of checks unclear.; Labels mix English and Vietnamese and use vague terms such as "rule và data reference"; use concrete, parallel labels tied to named artifacts.
assets/diagrams/09-functional-specification-writing-030-e3a395d2.mmd — REVISE — Luồng kiểm tra thiếu /00-research/00_SOURCE_MAP.md và kiểm tra testability, dù bảng quy định cả hai là dependency bắt buộc. Bổ sung hai bước kiểm tra.; Nhánh Có áp dụng Verification required cho mọi lệch hoặc thiếu evidence, nhưng bảng còn yêu cầu dừng handoff, xóa hoặc chuyển nội dung vượt phạm vi, và giữ IN_REVIEW. Tách outcome theo loại lỗi hoặc nêu điều kiện xử lý tương ứng.; Luồng kết thúc tại Giữ nhãn Verification required nhưng không thể hiện việc log mọi lỗi chặn, nêu owner theo vai trò, rồi kiểm tra lại trước handoff. Bổ sung gateway xác nhận đủ điều kiện handoff và vòng kiểm tra lại.; Nhãn Escalate đúng owner mơ hồ, không thể hiện ownership theo loại vấn đề. Nêu các vai trò escalation tương ứng hoặc dẫn rõ tới ma trận owner bên dưới.; Handoff IN_REVIEW dễ bị hiểu là approval hoặc baseline vì sơ đồ bỏ ranh giới được prose nhấn mạnh. Ghi rõ handoff không tạo approval, legal/accounting sign-off, baseline hoặc quyền production.; Sơ đồ không thể hiện kiểm tra tính nhất quán của v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND, dù đoạn kết đặt đây là điều kiện bắt buộc. Bổ sung bước hoặc gateway kiểm tra metadata.; Actor BA bị lược bỏ trong các hành động kiểm tra, log và escalation. Gắn BA với luồng hoặc dùng động từ chủ động có chủ thể rõ.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-001-896e1721.mmd — REVISE — Nhãn “Trong 3 giây hoặc lỗi rõ ràng” tạo logic lựa chọn sai: lỗi rõ ràng có thể bị hiểu là không chịu ngưỡng thời gian. Cần thể hiện cả kết quả thành công hoặc lỗi rõ ràng đều được trả trong không quá 3 giây.; Ngưỡng 3 giây thiếu điều kiện “tải kiểm thử được thống nhất”, khiến sơ đồ biến ngưỡng có điều kiện thành cam kết tuyệt đối. Cần bổ sung điều kiện đo.; Nhánh “Lưu phiếu và dòng hàng cùng nhau” xuất hiện như bước luôn xảy ra, trong khi yêu cầu chỉ áp dụng nếu lưu thành công. Cần gắn nhánh với trạng thái lưu thành công.; Sơ đồ bỏ sót outcome “mã tham chiếu duy nhất” của lần lưu thành công. Cần thể hiện cùng outcome lưu thành công.; “Kiểm tra quyền xem giá vốn” mô tả cơ chế xử lý, không mô tả yêu cầu bảo mật. Cần thể hiện kết quả cụ thể: vai trò không được cấp quyền không xem được giá vốn.; Nhu cầu không mất dữ liệu khi mạng lỗi không có nhánh lỗi hoặc trạng thái toàn vẹn tương ứng. Cần thể hiện ngoại lệ mạng lỗi và outcome không mất hoặc không lưu dở dữ liệu liên kết.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-002-bdda48cf.mmd — REVISE — C --> F lacks condition label, so success and error paths are ambiguous. Label branch with concrete outcome such as validation or authorization failure.; Save failure has no branch from D, despite surrounding table emphasizing partial-save failure, transaction integrity, known result state, and safe retry behavior. Add explicit save-failure outcome.; D --> G presents NFR concerns as downstream process outcome. Show NFRs as constraints or annotations on relevant steps and handoffs instead.; G lists integrity, performance, and security but omits error handling and testability, both central risks in surrounding table. Cover all stated quality concerns or narrow label without implying completeness.; Diagram places NFR concern only after save, contradicting prose saying quality gaps occur at every handoff. Mark relevant boundaries across request receipt, validation and authorization, persistence, and response.; E and F use ambiguous labels: “rõ ràng” and “có thể xử lý” lack observable states. Name concrete outcomes such as saved confirmation, rejected request, unchanged data, and retry guidance.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-003-ff94179d.mmd — REVISE — Nút quyết định “Có NFR xác định?” quá mơ hồ: không cho biết NFR nào hoặc điều kiện nào được xác định. Cần nêu rõ phạm vi kiểm tra gồm phản hồi giao diện, lỗi có thể hành động và xử lý gửi lặp.; Nhánh “Có” bỏ sót xử lý gửi lặp, dù đây là rủi ro trung tâm trong bảng và đoạn kết. Cần thể hiện kết quả khi người dùng thử lại: hệ thống ngăn hoặc xử lý lặp theo quy tắc đã định, để QA xác minh nguy cơ đơn trùng.; Nhánh “Có” chỉ nêu hiển thị kết quả hoặc lỗi, chưa thể hiện tiêu chí lỗi không làm mất dữ liệu nhập. Cần bổ sung trạng thái hoặc kết quả này vì section dùng nó làm Decision Criteria.; Kết quả “QA kiểm tra được hành vi đã mô tả” còn chung chung. Cần gắn việc kiểm tra với điều kiện quan sát cụ thể: phản hồi, lỗi và gửi lặp.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-004-f33779c6.mmd — REVISE — Nhánh Có nguồn kiểm tra được? chưa đủ để kết luận Fact đã xác minh; phải kiểm tra nguồn controlled hoặc chính thức cùng URL/artifact ID, phiên bản và ngày truy cập.; Gateway Đã có authority chọn phương án? không khớp nhãn nhánh Có record; phải dùng cùng tiêu chí hoặc thể hiện đủ authority và decision record.; Đường đến Decision bỏ thiếu phương án và tiêu chí lựa chọn, dù prose yêu cầu cả phương án, tiêu chí, authority và record.; Verification required bị mô tả như phần dư sau khi loại stakeholder input và project assumption; prose còn áp dụng trạng thái này cho khẳng định thiếu bằng chứng hoặc thuộc thẩm quyền chuyên môn khác, kể cả khi stakeholder cung cấp.; Các đường từ mọi trạng thái bằng chứng đến gateway quyết định ngụ ý fact, input, assumption hoặc claim đều có thể tự chuyển thành decision; phải làm rõ decision là lựa chọn được authority ghi nhận, không phải trạng thái nâng cấp tự động của phát biểu.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-005-ea7c4337.mmd — REVISE — Nhãn D --> A dùng Entry nhưng nằm trên chuyển tiếp giữa hai giai đoạn, nên không rõ đây là entry gate của Analysis hay exit gate của Discovery. Sửa nhãn để thể hiện đúng exit Discovery: nhu cầu được phân loại Project assumption hoặc Verification required, chưa phải requirement cuối.; Nhãn A --> DE chỉ nêu NFR đo được, traceable, thiếu acceptance criteria, phương pháp kiểm chứng, nguồn và ID canonical khi registry cho phép. Sửa thành exit gate Analysis cụ thể, phù hợp bảng.; Nhãn DE --> T nói build và cấu hình có bằng chứng nhưng bỏ điều kiện bằng chứng nội bộ phải liên kết NFR và thiếu bằng chứng không được coi là đạt. Bổ sung ràng buộc liên kết hoặc diễn đạt ngắn nhưng không làm mất điều kiện này.; Nhãn T --> R chỉ nêu kết quả test so với acceptance criteria, thiếu outcome bắt buộc: pass/fail, defect hoặc risk acceptance record. Sửa nhãn để thể hiện các kết quả hợp lệ, không ngụ ý mọi kết quả đều dẫn thẳng đến Release.; Nhãn R --> O nói release record và monitoring sẵn sàng, nhưng bảng yêu cầu readiness gồm giám sát, cảnh báo, rollback, quyền vận hành; release record phải liên kết NFR và known risk; IN_REVIEW không phải approval. Sửa nhãn để không thu hẹp hoặc làm sai release gate.; Luồng tuyến tính Testing --> Release --> Operations không thể hiện điều kiện quyết định release và ngoại lệ khi test fail, có defect hoặc chưa được phê duyệt. Bổ sung gateway hoặc nhãn điều kiện để tránh ngụ ý chuyển giai đoạn tự động.; Nhãn các cạnh không song song: Entry, Exit và Evidence trộn ba loại ý nghĩa; traceable trộn tiếng Anh với tiếng Việt. Chuẩn hóa nhãn theo cùng cấu trúc gate/kết quả và dùng thuật ngữ nhất quán.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-006-c046af98.mmd — REVISE — Luồng OPS --> BA bỏ Business Owner, trong khi handoff “Vận hành sang cải tiến” có downstream owner là “BA và Business Owner”. Bổ sung Business Owner vào luồng phản hồi.; Nút ESC[Escalation Owner] không được xác định trong prose hoặc bảng và gom nhiều thẩm quyền khác nhau thành một chủ sở hữu mơ hồ. Thay bằng các owner có thẩm quyền được bảng nêu hoặc biểu diễn escalation tại từng handoff.; Chỉ BA có nhánh escalation, trong khi bảng quy định điểm escalation cho mọi handoff. Bổ sung các nhánh hoặc ranh giới escalation quan trọng để không ngụ ý BA là điểm escalation duy nhất.; Nhãn QA -->|bằng chứng kiểm thử| REL thiếu lỗi mở và rủi ro còn lại, hai đầu vào quyết định release quan trọng. Bổ sung các vật bàn giao này.; Nhãn REL -->|runbook, ngưỡng giám sát| OPS thiếu cách rollback, điều kiện vận hành quan trọng và điểm escalation rõ trong bảng. Bổ sung rollback.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-007-74daaf88.mmd — REVISE — Các vai trò Architect, QA, Release Owner và Operations cùng trách nhiệm tương ứng không được phần văn xuôi xác lập. Bổ sung căn cứ về quyền sở hữu vào văn xuôi hoặc bỏ các liên kết vai trò không có căn cứ.; Nhãn G-R "quyết định phát hành thuộc thẩm quyền" mơ hồ: không nêu thẩm quyền nào, tiêu chí nào hoặc bằng chứng nào. Xác định chủ thể và điều kiện quyết định, đồng thời giữ rõ đây là cổng kiểm soát chứ không phải trạng thái phê duyệt.; Liên kết Release Owner "quyết định phát hành" dễ tạo approval ngầm định, trái với giải thích rằng sơ đồ không tạo approval ngầm định khi artifact đang IN_REVIEW. Đổi thành trách nhiệm chuẩn bị hoặc ghi nhận quyết định có điều kiện, hoặc bổ sung căn cứ quản trị rõ ràng trong văn xuôi.; Các cổng dùng cấu trúc chưa song song: G-D, G-A, G-DE và G-T mô tả điều kiện hoặc bằng chứng, còn G-R mô tả thẩm quyền. Chuẩn hóa các nhãn thành tiêu chí kiểm soát cụ thể, kiểm chứng được.; Vòng phản hồi Operations về Discovery gộp "Sự cố, số liệu hoặc thay đổi nhu cầu" nhưng không chỉ rõ điều kiện kích hoạt hay cách phân loại đầu vào. Làm rõ đây là các sự kiện kích hoạt tái khám phá, không phải mọi số liệu vận hành.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-008-6fbd1426.mmd — REVISE — Luồng E[Bằng chứng mô phỏng] --> B[BA hiểu loại nhu cầu chất lượng] sai quan hệ: bằng chứng xác lập cơ sở của nhu cầu, không giúp BA hiểu loại nhu cầu. Cần nối bằng chứng tới trạng thái thể hiện nhu cầu có dữ kiện hỗ trợ.; Nhãn Traceability mơ hồ và không song song với nhãn tiếng Việt còn lại. Cần dùng nhãn cụ thể, thể hiện artifact nguồn được liên kết bằng Canonical ID.; Kết quả NFR có cơ sở chưa thể hiện đủ điều kiện trong câu kết: BA chỉ ghi NFR khi đủ hiểu biết, dữ kiện, artifact nguồn và Canonical ID. Cần làm rõ đây là điều kiện cho phép ghi NFR, không phải NFR tự phát sinh.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-009-3ccd07db.mmd — REVISE — Gateway Có ID, nguồn và owner? áp dụng ID cho mọi input, nhưng prose chỉ yêu cầu ID với CONTROLLED_INTERNAL. Sửa điều kiện để kiểm tra cơ quan phát hành hoặc nguồn gốc, owner chịu trách nhiệm và bằng chứng; chỉ kiểm tra ID khi loại nguồn yêu cầu.; Luồng bỏ sót tiêu chí có đủ bằng chứng không, dù prose coi đây là điều kiện đầu vào. Thêm gateway hoặc gộp rõ tiêu chí đủ bằng chứng trước kết quả Đủ điều kiện phân tích NFR.; Nhánh Có thẩm quyền quyết định? -- Không dẫn tới Escalate đúng owner, trong khi prose quy định thiếu owner có thẩm quyền thuộc VERIFICATION_REQUIRED, chặn quyết định và lập điểm xác minh. Sửa nhánh để phản ánh trạng thái và xử lý này.; Nhãn Có thẩm quyền quyết định? không nêu chủ thể có thẩm quyền: nguồn phát hành, owner hay người phân tích. Sửa nhãn thành điều kiện cụ thể, nhất quán với owner có thẩm quyền trong prose.; Nhãn STOP: thiếu truy vết bị dùng chung cho nguồn cũ, sai phạm vi và thiếu thẩm quyền; các trường hợp này không đều là thiếu truy vết. Tách hoặc đổi outcome để nêu đúng lý do chặn.; Sơ đồ không thể hiện phân loại nguồn, dù prose đặt Phân loại nguồn làm cơ chế quyết định cách dùng và giới hạn. Bổ sung bước xác định nhãn nguồn hoặc giới hạn rõ sơ đồ chỉ kiểm tra điều kiện trước phân loại.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-010-670dca1d.mmd — REVISE — Nút "NFR có truy vết" mô tả kết quả chưa được section hỗ trợ; bảng chỉ là inventory đầu vào và nhiều nguồn chưa baseline hoặc chưa xác minh. Cần thể hiện đây là đầu vào dự kiến cho truy vết, không phải NFR đã có truy vết.; Luồng "Bảng input NFR" đến "NFR có truy vết" bỏ qua bước lập, liên kết và xác minh NFR. Cần bổ sung điều kiện hoặc bước trung gian được prose hỗ trợ, hoặc bỏ kết quả này.; Nút "Điểm Verification required giữ nguyên nhãn" mơ hồ và tạo cảm giác mọi điểm xác minh có cùng trạng thái. Cần gắn yêu cầu xác minh với đúng nguồn, đúng phạm vi và owner nêu trong bảng.; Nút "Nguồn chuẩn và pháp lý" gộp chuẩn quốc tế, khuyến nghị, good practice và nguồn pháp lý có thẩm quyền xác minh khác nhau. Cần tách hoặc đặt nhãn bao quát mà không làm mất phân loại và rủi ro áp dụng.; Sơ đồ bỏ qua boundary quan trọng: dữ liệu Nova Foods là dữ liệu tổng hợp, còn yêu cầu pháp lý suy ra phải được Legal Owner và khi phù hợp Domain Owner xác minh. Cần biểu diễn rõ boundary này.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-011-f35f14b6.mmd — REVISE — Nút B không nêu chủ thể và có thể hiểu BA tự chọn phân vị 95%. Phải thể hiện Business Owner xác nhận mức chấp nhận, Technical Architect xác nhận tính khả thi, QA Lead xác nhận phương pháp đo; BA chỉ ghi nhận.; Nút C thiếu phạm vi quan trọng: POST /sales-orders, 50 dòng hàng và môi trường kiểm thử mô phỏng. Phải bổ sung điều kiện này để không ngụ ý kết quả áp dụng cho production.; Gateway E ghi Ít nhất 95 phản hồi <= 3 giây? nhưng Decision yêu cầu phản hồi thành công. Phải nêu rõ tiêu chí thành công và mẫu số đo để tránh tính phản hồi lỗi như phản hồi đạt thời gian.; Các nút G và H thiếu chủ thể; Escalate cũng không nhất quán ngôn ngữ. Phải xác định ai phân tích, ai báo cáo lên Technical Architect và Business Owner.; Nhánh I quay thẳng về B tạo quy trình không được phần văn xuôi hỗ trợ và sai với lựa chọn điều chỉnh giải pháp hoặc ngưỡng: điều chỉnh giải pháp cần chạy lại kiểm thử, còn đổi ngưỡng cần tái xác nhận thẩm quyền. Phải tách hai đường xử lý.; Nhánh đạt chỉ ghi bằng chứng, chưa thể hiện ranh giới rằng kết quả chỉ xác nhận điều kiện mô phỏng, không xác nhận production, tuân thủ hoặc phê duyệt. Phải thể hiện giới hạn này tại kết quả.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-012-5158e5d5.mmd — REVISE — Nút Business need hoặc risk đưa risk vào nhưng phần văn xuôi không xác định risk là nguồn của NFR. Bỏ risk hoặc bổ sung cơ sở rõ trong văn xuôi.; Nhãn Thiết kế và test basis gộp hai đích khác loại, dùng tiếng Anh không nhất quán và không thể hiện đúng nghĩa liên kết truy vết tới thiết kế và kiểm thử. Tách hoặc đặt nhãn cụ thể, song song với các đích được bảng nêu.; Nút Downstream review mơ hồ: không có actor, đối tượng review, điều kiện hay outcome tương ứng trong phần văn xuôi. Thay bằng bước review cụ thể được prose hỗ trợ hoặc bỏ nút.; Luồng Liên kết truy vết và Bằng chứng đánh giá dự kiến cùng dẫn tới Thiết kế và test basis làm sai quan hệ: bằng chứng xác định cách QA kiểm tra NFR, còn liên kết truy vết nối NFR với nhiều loại nguồn và đích. Biểu diễn hai chức năng riêng, không hội tụ như cùng tạo một đầu ra.; Sơ đồ bỏ owner và ranh giới trách nhiệm quan trọng giữa BA, QA Lead và vai trò chuyên môn. Thêm ownership phù hợp để tránh hiểu BA sở hữu cả phương pháp kiểm tra.; Sơ đồ không thể hiện trạng thái IN_REVIEW và dễ khiến Downstream review bị hiểu như phê duyệt hoặc readiness, trái với cảnh báo rõ trong prose. Gắn trạng thái hoặc giới hạn outcome để không ngụ ý APPROVED, BASELINED, production-ready, compliant hay user-accepted.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-013-1f314025.mmd — REVISE — Sơ đồ bỏ sót các trường bắt buộc trong bảng: phạm vi chức năng, tác nhân và tải, điều kiện kích hoạt, ràng buộc, và nhãn xác minh. Bổ sung chúng vào anatomy hoặc giới hạn rõ sơ đồ chỉ mô tả một phần luồng truy vết.; Nhãn "Tiêu chí đo" không thể hiện đủ chỉ số, ngưỡng, đơn vị và khoảng quan sát. Làm rõ nội hàm đo lường.; Nhãn "Test basis" dùng tiếng Anh giữa các nhãn tiếng Việt và chưa có định nghĩa trong bảng. Đổi thành thuật ngữ tiếng Việt cụ thể, nhất quán với "Bằng chứng mong đợi" hoặc giải thích quan hệ khác biệt.; Nhãn "Liên kết rule và dữ liệu" hẹp hơn "Liên kết nguồn", vốn gồm artifact canonical, rule và nguồn ngoài. Sửa nhãn để không loại bỏ nguồn hợp lệ.; Nhánh kết thúc tại "TRACEABILITY_ID_REGISTRY" khiến một registry cụ thể trông như đích bắt buộc duy nhất, trong khi bảng cho phép nhiều nguồn canonical hoặc nguồn ngoài. Thể hiện đây là ví dụ hoặc khái quát thành loại liên kết nguồn.; Luồng tuyến tính từ yêu cầu đến bằng chứng không thể hiện giả định chưa xác minh, dù phần prose coi đây là thành phần bắt buộc để truy vết. Bổ sung trạng thái xác minh và quan hệ với yêu cầu hoặc bằng chứng.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-014-9c6c2c40.mmd — REVISE — Thiếu điều kiện nhất quán nội bộ với CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY; phải thể hiện kiểm tra này trước gateway.; Nhánh Không gộp mọi lỗi thành Trả về cập nhật có truy vết, trái với ngoại lệ Dừng; cần làm rõ nguồn canonical khi có mâu thuẫn nội bộ; phải tách kết quả dừng khỏi luồng cập nhật thông thường.; Nhãn gateway Đủ bằng chứng và đúng thẩm quyền? quá rộng, không phản ánh đủ sáu điều kiện gate; phải làm rõ rằng quyết định bao gồm nhận diện, truy vết nguồn, tính kiểm tra được, ranh giới thẩm quyền, lịch sử thay đổi và nhất quán nội bộ.; Nút Review không tạo approval hoặc baseline được vẽ như bước xảy ra sau review readiness, trong khi prose nêu ranh giới của gate và còn loại trừ compliance cùng production readiness; phải thể hiện đầy đủ ranh giới này như constraint, không như bước quy trình.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-015-5e1f1df3.mmd — REVISE — Các mũi tên từ BA có thể bị hiểu là luồng bàn giao hoặc phê duyệt, trái với giải thích rằng việc đọc hoặc review không tạo approval. Cần ghi rõ quan hệ là sử dụng đầu ra NFR, không phải trình tự hay quyền phê duyệt.; Sơ đồ gán BA làm nguồn hoặc chủ sở hữu NFR, nhưng đoạn văn chỉ mô tả các consumer và cách họ dùng đầu ra. Cần bổ sung căn cứ về ownership trong prose hoặc dùng artifact NFR làm nguồn trung tâm.; Nhãn hành động quá khái quát: “xây dựng”, “kiểm thử”, “ưu tiên”, “đánh giá giá trị” làm mất quyết định, đầu ra và giới hạn trách nhiệm đã nêu trong bảng. Cần dùng nhãn cụ thể, song song và phù hợp từng consumer.; Sơ đồ gần như lặp lại cột Consumer của bảng, không thể hiện loại đầu ra, quyết định, dependency hoặc ranh giới trách nhiệm. Cần bổ sung quan hệ giải thích hữu ích hoặc bỏ sơ đồ nếu không thêm thông tin.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-016-6a6094a1.mmd — REVISE — Nhánh “Có” cho phép dùng artifact làm test basis hoặc thiết kế, nhưng phần văn xuôi xác định artifact IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 chưa phải baseline hay phê duyệt; cần thể hiện giới hạn sử dụng hoặc không dẫn tới kết quả ngụ ý artifact đã đủ thẩm quyền.; Gateway “Có bằng chứng đo được và phạm vi rõ?” thêm tiêu chí không được nêu trong phần văn xuôi; cần liên kết tiêu chí này với nội dung xung quanh hoặc bỏ khỏi sơ đồ.; Các bước “Ghi câu hỏi làm rõ”, “BA giữ traceability” và “chuyển đúng owner” thêm quy trình và trách nhiệm chưa được phần văn xuôi hỗ trợ; cần bổ sung căn cứ trong nội dung hoặc loại bỏ.; Vòng lặp từ F về A ngụ ý BA gửi lại artifact sau khi chuyển owner, nhưng không có bước nhận câu trả lời, cập nhật artifact hay kiểm tra lại; cần làm rõ sự kiện và điều kiện quay lại.; Sơ đồ bỏ qua rủi ro cốt lõi là người nhận suy diễn phần chưa được ghi và không thể hiện trạng thái chưa baseline/chưa phê duyệt; cần đưa các ranh giới này vào luồng.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-017-2e79ee89.mmd — REVISE — Nhãn phản hồi Pricing Service có “chiết khấu”, nhưng phần prose chỉ xác nhận tính giá bán. Bỏ “chiết khấu” hoặc bổ sung bằng chứng trong prose.; Nhãn yêu cầu Inventory Service chỉ nêu itemCode và warehouseCode, dễ thể hiện sai hợp đồng giao tiếp vì kiểm tra khả dụng còn phụ thuộc quantity và unitOfMeasure trong payload. Đổi thành nhãn trung tính như “Kiểm tra tồn kho cho dòng hàng”, không khẳng định interface chưa được xác nhận.; Sơ đồ trình bày chuỗi gọi dịch vụ như sự thật kỹ thuật đã xác nhận, trong khi prose nói đây là suy luận từ dữ liệu mô phỏng và chưa được Architect xác nhận. Gắn rõ trạng thái “suy luận/current behavior chưa xác nhận nguyên nhân kỹ thuật” trong sơ đồ hoặc chú thích sát sơ đồ.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-018-1eb6265b.mmd — REVISE — Nhãn 409 Conflict là chi tiết chưa được phần văn xuôi hỗ trợ. Phần văn xuôi chỉ yêu cầu mã nghiệp vụ và không lộ chi tiết DB; cần bỏ mã HTTP cụ thể hoặc dùng nhãn phản hồi lỗi nghiệp vụ.; Nhánh Any write fails không bao quát lỗi kiểm tra số lượng và phân bổ lô, trong khi quyết định yêu cầu lỗi tại bất kỳ bước nào phải rollback toàn bộ. Cần đổi điều kiện thành lỗi kiểm tra hoặc lỗi ghi dữ liệu.; Thông điệp API->>DB: Validate quantity and lot allocations gán hoạt động kiểm tra cho DB nhưng phần văn xuôi không xác định DB là chủ thể thực hiện. Cần thể hiện API kiểm tra trong phạm vi giao dịch hoặc ghi rõ DB constraint nếu đó là chủ đích.; Nhãn issue not posted chưa thể hiện yêu cầu lỗi trả bằng mã nghiệp vụ và không lộ stack trace hoặc chi tiết DB. Cần dùng nhãn kết quả cụ thể phù hợp quy tắc chất lượng.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-019-f6ca4bf3.mmd — REVISE — Thiếu bước gửi bearer token và kiểm tra vai trò tại API. Bổ sung ranh giới xác thực/phân quyền, nhánh HTTP 403 khi token không có vai trò WarehouseOperator hoặc ProductionPlanner.; Chỉ thể hiện nhánh requestedQuantity <= availableQuantity. Bổ sung nhánh đối lập với canIssue=false và ERP không cho tiếp tục tạo phiếu xuất.; Phản hồi availableQuantity=2100, canIssue=true không thể hiện Inventory Service áp dụng BR-INV-001. Bổ sung bước tính 5000 - 2500 - 400 = 2100 và so sánh 1200 <= 2100.; Không thể hiện ràng buộc chất lượng gắn với lời gọi API. Gắn P95 ≤ 2 giây tại tải 50 yêu cầu đồng thời và phạm vi khả dụng tháng ≥ 99,5%, hoặc ghi rõ sơ đồ chỉ mô tả luồng chức năng và không chứng minh hai NFR này.; Nhãn Tạo xuất 1200 KG RM-SUGAR-001 mơ hồ và không khớp thuật ngữ quanh sơ đồ. Đổi thành hành động cụ thể Yêu cầu tạo phiếu xuất 1200 KG RM-SUGAR-001.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-020-311427b9.mmd — REVISE — Nhãn template dự kiến không được prose hỗ trợ; sửa thành vai trò cụ thể như template ghi NFR, tiêu chí đo và evidence.; Các nút nguồn chỉ nêu tên artifact, trong khi quy tắc yêu cầu ID + đường dẫn canonical + mục đích liên kết; bổ sung đường dẫn canonical và làm rõ mục đích liên kết cho từng phụ thuộc.; Mũi tên trực tiếp từ artifact vào chapter có thể bị hiểu là sao chép nội dung; làm rõ chapter chỉ tham chiếu artifact canonical và giữ phạm vi ảnh hưởng, lý do phụ thuộc.; Nhãn không nhân bản nguồn gốc mơ hồ; dùng khái niệm đúng từ prose: không sao chép nội dung gốc hoặc không tạo nhiều nguồn chân lý.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-022-2b3f8285.mmd — REVISE — Cạnh CANONICAL_BUSINESS_RULES → CANONICAL_DATA_DICTIONARY khẳng định quan hệ phụ thuộc không được phần văn bản nêu. Cần bỏ cạnh này hoặc bổ sung căn cứ trong văn bản.; Nhãn "DATA/API contract" gộp hai khái niệm nhưng không xác định đây là một hay nhiều artifact. Cần dùng tên artifact cụ thể, nhất quán với nguồn canonical.; Nhánh thay đổi im lặng từ CANONICAL_DATA_DICTIONARY chỉ nêu API đọc hoặc gửi trường sai, bỏ tác động đến requirement, test case và truy vết đã được văn bản mô tả. Cần thể hiện đủ phạm vi lan truyền hoặc giới hạn rõ nhánh này là một ví dụ.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-023-3c0c8495.mmd — REVISE — Nút E rẽ nhánh nhưng không nêu điều kiện. Cần thể hiện rõ: đủ bằng chứng thì tạo test basis; thiếu bằng chứng thì xác minh nguồn hoặc ghi giả định.; Nhãn “Viết lại khi thiếu bằng chứng” sai hành động sửa trong bảng. Viết lại không tạo bằng chứng; cần đổi thành “Xác minh nguồn hoặc ghi giả định”.; “QA và Architect” gán vai trò Architect không được phần văn xuôi xác lập. Cần bỏ Architect hoặc bổ sung căn cứ ngoài sơ đồ; “Test basis cho QA” đã được hỗ trợ trực tiếp.; Nhãn “Đặt điều kiện đo được” chưa bao quát đủ ngưỡng, phạm vi, tải và cách đo. Cần dùng nhãn cụ thể hơn để tránh biến NFR thành con số thiếu bối cảnh.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-024-8e844e50.mmd — REVISE — Nhãn “Escalate kèm bằng chứng” không cụ thể và không song song ngôn ngữ với các nhãn còn lại; đổi thành hành động tiếng Việt nêu rõ chuyển bằng chứng cho người có thẩm quyền.; Nhánh “Không” kết thúc tại bước chuyển cấp nhưng không thể hiện trạng thái chờ quyết định hoặc tiếp tục quy trình sau khi được phê duyệt; bổ sung ranh giới dừng/chờ và đường quay lại bước xử lý khi có quyết định.; Nhãn “Thực hiện xử lý được ghi nhận” mơ hồ, có thể bị hiểu là tự sửa dữ liệu hoặc chạy lại tích hợp trái cảnh báo; nêu rõ chỉ thực hiện phương án do người có thẩm quyền quyết định và phải lưu dấu vết.; Sơ đồ không thể hiện yêu cầu cô lập bản ghi nghi trùng trước khi đối soát, dù đây là ranh giới khôi phục an toàn trong bảng; bổ sung bước cô lập bản ghi mà không sửa dữ liệu nghiệp vụ.; Kết quả “Kiểm tra không tạo giao dịch mới” chỉ kiểm tra phát sinh giao dịch mới, bỏ sót yêu cầu bảo toàn dấu vết kiểm toán và xác nhận trạng thái sau xử lý; bổ sung kết quả xác minh không tạo giao dịch trùng và dấu vết xử lý được lưu giữ.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-025-599b1f9d.mmd — REVISE — Nhánh lỗi tích hợp bị bỏ sót. Thêm nhánh từ bước tích hợp đến kết quả tạo bản ghi lỗi có thể truy vết, đúng ngoại lệ trong requirement.; Nhãn “Đồng bộ tồn kho” mơ hồ và có thể bị hiểu là đã chọn cơ chế đồng bộ. Đổi thành bước trung tính mô tả cập nhật số lượng tồn kho; cơ chế phải do Architect xác nhận.; “Ghi mốc thời gian” không nêu mốc nào. Làm rõ đây là thời điểm giao dịch chuyển sang trạng thái POSTED.; Điểm kết thúc chưa đủ chính xác. Làm rõ thời điểm API truy vấn trả về số lượng mới, không chỉ “API trả số lượng mới”.; “escalation” không có quy trình, đích nhận hoặc Owner hỗ trợ trong phần prose. Bỏ thuật ngữ này hoặc nêu đúng Owner và luồng xử lý đã được section xác lập.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-026-6f74efd7.mmd — REVISE — Gateway “Đủ tiêu chí đo và owner?” gộp hai điều kiện khác nhau và dùng “owner” mơ hồ. Cần tách hoặc làm rõ: Business Owner xác định mức chấp nhận, Architect xác nhận khả thi, QA xác nhận cách đo và test basis.; Nhánh “Có” dừng tại “Soạn NFR kiểm thử được”, bỏ thiếu bước xác nhận thẩm quyền trước khi biến ngưỡng thành acceptance criterion. Cần thể hiện việc chốt bởi đúng decision owner và ghi nhận quyết định.; Luồng chưa thể hiện các nội dung bắt buộc của khuyến nghị khi còn bất định: tác động khi giả định sai và điều kiện cập nhật. Cần bổ sung trước khi chuyển decision owner.; “Đề xuất phương án cùng bằng chứng” dễ hiểu rằng đã có đủ bằng chứng, trái ngữ cảnh đang thiếu bằng chứng để chốt NFR. Cần ghi cụ thể rằng đề xuất dựa trên bằng chứng hiện có, kèm assumption, uncertainty và giới hạn.; Kết quả “Ghi kết quả hoặc giữ IN_REVIEW” gộp hai outcome nhưng không nêu điều kiện phân nhánh. Cần chỉ rõ khi nào ghi quyết định đã xác nhận và khi nào tiếp tục giữ IN_REVIEW.; Sơ đồ không thể hiện yêu cầu traceability với TRACEABILITY_ID_REGISTRY, dù đây là bước quản trị cụ thể trong artifact. Cần thêm bước liên kết quyết định với registry và không tự tạo ID ngoài registry.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-027-ac599ec1.mmd — REVISE — Node G invents an owner and quality-gate review absent from surrounding prose. Remove it or support both actor and review requirement in prose.; No branch ends with ambiguous "Giữ liên kết nguồn canonical". Prose requires chapter not be linked to any template until ID and path are registered. Replace outcome with that explicit condition.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-028-1e78e6bb.mmd — REVISE — Thiếu gateway kiểm tra đủ ba điều kiện: xác định được nguồn, phạm vi nguồn khớp claim, và ví dụ không vượt thẩm quyền mô phỏng. Bổ sung bước quyết định trước kết quả giữ claim.; Thiếu nhánh ngoại lệ khi không tìm thấy ID, file hoặc bằng chứng nguồn. Bổ sung kết quả loại bỏ hoặc đánh dấu claim để xác minh; không cho phép tự suy diễn.; Nhãn “Giữ IN_REVIEW” nhập nhằng giữa trạng thái corpus và quyết định giữ claim. Tách trạng thái học liệu IN_REVIEW khỏi kết quả xử lý claim.; Nhánh pháp lý, kế toán và an toàn thực phẩm thiếu yêu cầu có Legal Owner, Accounting Owner hoặc domain owner. Bổ sung kiểm tra owner cùng nhãn Verification required.; Nhãn “Tra primary source” chưa đủ cụ thể so với bảng nguồn. Nêu nhóm nguồn tương ứng hoặc chỉ rõ tra nguồn canonical trong Quick Reference.; Các nhánh phân loại chưa bao quát rõ mục tiêu chất lượng và trade-off từ /01-curriculum/CHAPTER_MANIFEST.md. Bổ sung loại claim này hoặc làm rõ nó thuộc nhánh canonical.
assets/diagrams/10-nonfunctional-requirements-and-quality-attributes-029-4a55fc56.mmd — REVISE — Nhãn “Soạn chapter section 12” không được đoạn văn xác lập; sửa thành hoạt động rà soát chapter trước bàn giao, không gắn số section.; Bước “Đối chiếu manifest và registry” bỏ sót ba nguồn canonical: TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY; liệt kê đủ năm nguồn hoặc dùng nhãn bao quát rõ ràng.; Gateway “Metadata và ID khớp?” quá mơ hồ; nêu đủ tiêu chí phải khớp: ID, đường dẫn, trạng thái, version, source boundary và thẩm quyền.; Sơ đồ không thể hiện các giá trị kiểm tra bắt buộc: IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh, Nova Foods là mô phỏng giáo dục và dữ liệu tổng hợp; bổ sung vào bước hoặc điều kiện kiểm tra.; Gateway “Có kết luận pháp lý, kế toán, bảo mật, kiến trúc?” đưa thêm phạm vi không được đoạn văn hỗ trợ và không phản ánh đúng bốn mức cấm đã nêu; thay bằng kiểm tra chapter có nâng dữ liệu thành baseline, approval, compliance hoặc production-ready hay không.; Các bước “Ghi open issue và escalation”, “Ghi verification-required” và “lập gói vấn đề” không có căn cứ trong đoạn văn; bỏ hoặc thay bằng kết quả xử lý được nguồn prose xác lập.; Vai trò “Principal IT Business Analyst / Technical Curriculum Author” không được đoạn văn giao quyền sở hữu; bỏ vai trò hoặc bổ sung căn cứ prose trước khi dùng.; Hai nhánh lỗi metadata và vượt thẩm quyền bị gộp vào cùng một xử lý chưa được xác lập, còn nhánh thành công luôn bàn giao IN_REVIEW dù chưa kiểm tra đủ giá trị canonical; sửa luồng để mọi tiêu chí bắt buộc đều được kiểm tra trước kết quả bàn giao.
assets/diagrams/11-data-modeling-and-master-data-001-3e6a4a2a.mmd — REVISE — Các kiểu string và decimal đưa ra quyết định kiểu dữ liệu dù prose nói mô hình chưa quyết định kiểu cột. decimal ordered_quantity còn ngầm cho phép số lượng lẻ, quy tắc chưa được section hỗ trợ. Cần bỏ kiểu vật lý hoặc đổi thành domain logic trung lập và nói rõ đây không phải kiểu DB.; Cardinality o{ khẳng định một sản phẩm có thể không được dòng bán nào tham chiếu. Section chỉ hỗ trợ mỗi dòng bán phải tham chiếu đúng một sản phẩm và một giá trị chủ có thể được nhiều giao dịch tham chiếu; chưa xác nhận trường hợp 0 dòng. Cần bổ sung quy tắc nghiệp vụ này trong prose hoặc dùng cardinality không khẳng định tính tùy chọn chưa được xác nhận.
assets/diagrams/11-data-modeling-and-master-data-002-c66911da.mmd — REVISE — Luồng A → B → C mô tả nhân viên chọn ProductID trực tiếp trên master data rồi master data chuyển bản ghi sang đơn bán hàng. Prose quy định nhân viên chọn ProductID cho giao dịch, còn đơn bán hàng chỉ lưu ProductID và tham chiếu master data. Cần thể hiện Nhân viên bán hàng → Đơn bán hàng, cùng quan hệ Đơn bán hàng → Master data sản phẩm bằng ProductID.; Nhãn B → C chứa cả mã, tên và đơn vị tính, dễ hiểu rằng đơn bán hàng lưu toàn bộ thuộc tính. Prose nói giao dịch chỉ lưu ProductID; tên hiển thị lấy từ master data. Cần gắn nhãn quan hệ bằng nội dung như “tham chiếu ProductID” và giữ ProductName, UoM trong nút master data.; Luồng C → D không cho thấy báo cáo cần kết hợp giao dịch với master data để hiển thị tên chuẩn. Cần thể hiện rõ báo cáo dùng ProductID từ đơn bán hàng và tên chuẩn từ master data, tránh ngụ ý đơn hàng tự cung cấp tên chuẩn.
assets/diagrams/11-data-modeling-and-master-data-003-65ec6825.mmd — REVISE — Nhãn "ProductID không chuẩn" mơ hồ: chưa phân biệt mã không tồn tại, mã không canonical hoặc tên tự do. Cần dùng điều kiện cụ thể được nêu trong prose.; Chuỗi "Không xác định bản ghi sản phẩm" đến "Kho xử lý sai đối tượng" thiếu nhánh logic: không xác định có thể khiến kho từ chối xử lý, còn gắn nhầm sản phẩm xảy ra khi tích hợp đoán bản ghi. Cần thể hiện bước đoán theo tên hoặc đổi kết quả cho phù hợp.; Quan hệ "Master data được kiểm soát" đến "Đơn bán hàng" làm sai hướng tham chiếu. Prose xác định giao dịch tham chiếu định danh master data; cần biểu diễn đơn bán hàng tham chiếu master data bằng ProductID chuẩn.; Hai nhánh dùng cấu trúc không song song: nhánh lỗi bắt đầu từ đơn bán hàng, nhánh đúng bắt đầu từ master data. Cần cùng điểm xuất phát hoặc cùng mô hình điều kiện-kết quả để so sánh rõ.
assets/diagrams/11-data-modeling-and-master-data-004-00995df5.mmd — REVISE — Luồng “Chứng từ mua hàng” đến “Cập nhật giao dịch tồn kho” ngụ ý chứng từ mua hàng trực tiếp làm thay đổi tồn kho, nhưng phần prose chỉ nói phiếu mua, nhận hàng và tồn kho cùng tham chiếu master data. Cần dùng loại giao dịch trung tính hoặc nêu đúng sự kiện nhận hàng trước bước cập nhật tồn kho.; Gateway “Đơn vị tính hợp lệ?” chưa thể hiện tiêu chí đã nêu: đơn vị cơ sở hoặc bản ghi quy đổi hợp lệ cho đúng vật tư. Cần làm nhãn điều kiện cụ thể để tránh hiểu rằng mọi đơn vị hợp lệ toàn cục đều được chấp nhận.; Nút “Chặn hoặc xử lý ngoại lệ dữ liệu” mơ hồ về hành vi sau khi không đạt kiểm tra. Cần dùng đúng hai kết quả được prose hỗ trợ: chặn giao dịch hoặc chuyển vào hàng đợi xử lý dữ liệu.
assets/diagrams/11-data-modeling-and-master-data-005-ff6b221f.mmd — REVISE — Nhánh “Có bằng chứng kiểm tra được?” đi thẳng tới “Fact đã xác minh”, bỏ bước kiểm tra bằng chứng thuộc artifact hoặc nguồn chính thức; cần thể hiện tiêu chí nguồn và trạng thái xác minh.; “Verification-required claim” chỉ xuất hiện khi nguồn không phải stakeholder và không cần giả định, trái phần prose: mọi phát biểu thuộc pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật đều có thể cần vai trò có thẩm quyền kiểm tra, bất kể nguồn; cần tách điều kiện này khỏi nhánh nguồn.; Các nhánh “Stakeholder input”, “Project assumption” và “Verification-required claim” đều dẫn tới “Decision được ghi nhận”, ngụ ý đánh giá luôn tạo ra decision; cần có kết quả không trở thành decision hoặc gateway xác định có quyết định hay không.; “Decision được ghi nhận” thiếu tiêu chí và thẩm quyền được prose yêu cầu, đồng thời có thể bị hiểu là approval; cần nêu việc ghi nhận tiêu chí, thẩm quyền và ranh giới không đồng nghĩa approval.; “Project assumption” thiếu điều kiện vô hiệu; cần thể hiện yêu cầu ghi nhận điều kiện làm giả định mất hiệu lực.; “Đánh giá bằng chứng và thẩm quyền” mơ hồ về chủ thể, kết quả và tiêu chí; cần làm rõ vai trò có thẩm quyền kiểm tra claim nào và đánh giá dẫn tới trạng thái nào.
assets/diagrams/11-data-modeling-and-master-data-006-ea95475f.mmd — REVISE — Luồng Release → Operations bỏ qua điều kiện quan trọng: phiên bản chỉ vào vận hành theo quyết định có thẩm quyền. Bổ sung điều kiện này để bằng chứng phát hành không bị hiểu thành approval hoặc production authorization.; Nhãn exit của Analysis chỉ nêu khả năng truy vết, bỏ điều kiện không biến assumption thành rule và giữ nhãn cho điểm chưa xác minh. Bổ sung ràng buộc này hoặc tránh trình bày nhãn như exit gate đầy đủ.; Nhãn exit của Testing chỉ nói kết quả được ghi nhận, thiếu trạng thái pass, fail hoặc blocked và khả năng truy defect về requirement hoặc thiết kế. Làm nhãn cụ thể hơn để khớp exit gate.; Nhãn Release dùng cụm “bằng chứng phát hành” mơ hồ hơn prose “gói phát hành có bằng chứng kỹ thuật”. Đổi sang ngôn ngữ cụ thể và giữ ranh giới không đồng nghĩa với phê duyệt.
assets/diagrams/11-data-modeling-and-master-data-007-8fa570a0.mmd — REVISE — Luồng BA --> DO bỏ Architect khỏi bên nhận mô hình logic; thêm handoff từ BA đến Architect theo bảng.; Luồng DO --> AR mô tả Data Owner là nguồn duy nhất của quy tắc dữ liệu, nhưng bảng giao quyền này cho cả Data Owner và Business Owner, đồng thời xác định BA, Architect là bên nhận; thể hiện đủ chủ thể và bên nhận.; Luồng QA --> OPS với nhãn Lỗi, bằng chứng không có trong bảng. Bảng chỉ nêu QA sở hữu chiến lược và bằng chứng kiểm thử; không xác lập QA bàn giao lỗi trực tiếp cho Operations. Xóa hoặc thay bằng handoff được prose hỗ trợ.; Luồng OPS --> DS đảo quan hệ vận hành dữ liệu trong bảng: Data Steward và Operations Owner cùng tạo artifact cho Operations; bảng không nói Operations giao sự cố cho Data Steward. Sửa hướng và vai trò theo handoff đã nêu.; Các luồng DS --> DO và DO --> BO biến điều kiện escalation thành tuyến chuyển tiếp cố định, dù prose không quy định nơi nhận escalation. Chỉ giữ nếu section xác định rõ tuyến escalation; nếu không, bỏ.; Nút OPS[Operations] nhập nhằng với Operations Owner, trong khi bảng phân biệt downstream Operations và quyền quyết định của Operations Owner. Dùng đúng actor cho từng trách nhiệm.; Sơ đồ bỏ các điều kiện nhận bàn giao, giới hạn thẩm quyền và escalation quan trọng, nên chuỗi tuyến tính tạo ấn tượng mọi handoff tự động được chấp nhận. Thể hiện ranh giới hoặc điều kiện nhận nếu sơ đồ nhằm mô tả handoff có kiểm soát.
assets/diagrams/11-data-modeling-and-master-data-008-66def2bd.mmd — REVISE — Các pha Discovery, Analysis, Delivery, Testing, Release và Operations cùng đầu ra chi tiết chưa được phần văn xuôi xác lập; cần bổ sung căn cứ trong nội dung hoặc loại bỏ chi tiết không được hỗ trợ.; Nhánh G4 Không đạt quay về Delivery, bỏ qua Analysis và không nêu tiêu chí chọn điểm sửa; cần xác định vòng lặp theo nguyên nhân hoặc đổi về bước được văn xuôi hỗ trợ.; Từ Gate dễ bị hiểu là điểm phê duyệt, trái với lưu ý rằng cổng không xác nhận phê duyệt hay baseline; cần thể hiện rõ giới hạn này ngay trong sơ đồ.; Nhãn Có, Thiếu, Không đạt thiếu song song và chưa nêu kết quả kiểm tra cụ thể; cần dùng điều kiện nhất quán, gắn trực tiếp với tiêu chí từng cổng.; Sơ đồ không chỉ ra chủ thể chịu trách nhiệm đánh giá đầu ra tại mỗi cổng; cần thêm owner nếu phần này coi ownership là yếu tố vận hành bắt buộc, hoặc nêu rõ sơ đồ chỉ mô tả trạng thái dữ liệu.; Các thuật ngữ mapping, đặc tả giao diện, cấu trúc triển khai, bằng chứng kiểm tra và gói vận hành dữ liệu chưa được định nghĩa trong phần văn xuôi; cần định nghĩa hoặc thay bằng nhãn đã được nội dung hỗ trợ.
assets/diagrams/11-data-modeling-and-master-data-009-d1ee76f8.mmd — REVISE — Sơ đồ đặt "Kiến thức nghiệp vụ", "Bằng chứng nguồn" và "Artifact kiểm soát và canonical ID" thành ba đầu vào ngang hàng, trong khi phần văn bản yêu cầu BA bắt đầu từ bằng chứng nguồn. Cần thể hiện bằng chứng nguồn là cơ sở xác minh đối tượng và liên kết tên–mã.; Sơ đồ bỏ qua điều kiện quan trọng: khi chưa có bằng chứng liên kết tên và mã, BA phải giữ hai tham chiếu chưa xác minh thay vì gộp thành một đối tượng. Cần thể hiện nhánh xác minh và kết quả khi thiếu liên kết.; Nhãn "Artifact kiểm soát và canonical ID" mơ hồ, ghép loại tài liệu với định danh nhưng không nêu vai trò của từng thành phần. Cần dùng nhãn cụ thể, song song và bám vào chức năng kiểm soát hoặc tham chiếu ổn định.; Điểm cuối "CANONICAL_DATA_DICTIONARY" không cho biết đây là kế hoạch từ điển dữ liệu logic tại đường dẫn canonical, nên có thể bị hiểu là tên mô hình hoặc sản phẩm đầu ra hoàn chỉnh. Cần làm rõ quan hệ giữa mô hình dữ liệu logic và artifact canonical.
assets/diagrams/11-data-modeling-and-master-data-010-2c7845b7.mmd — REVISE — STOP — PLAN REWORK REQUIRED đưa thêm trạng thái và yêu cầu rework không có trong phần văn xuôi; đổi thành kết quả được hỗ trợ như Dừng phân tích — thiếu điều kiện tối thiểu.; Có owner đúng thẩm quyền? dễ hàm ý owner có quyền phê duyệt quyết định, trái với định nghĩa owner chỉ chịu trách nhiệm xác nhận nội dung; đổi thành điều kiện cụ thể như Có owner chuyên môn xác nhận nội dung?.; Nhánh nguồn không còn mới kết thúc tại Không suy diễn thành rule hoặc quyết định nhưng chưa thể hiện rõ không được dùng để quyết định khi bằng chứng chưa đủ; cần nối tới kết quả dừng phân tích hoặc bước xác minh trước khi tiếp tục.
assets/diagrams/11-data-modeling-and-master-data-011-44a32f82.mmd — REVISE — Luồng D → E ngụ ý Supply Chain Owner và Product Owner trực tiếp cập nhật CANONICAL_DATA_DICTIONARY, trái với phân quyền trong prose: hai owner xác minh, BA ghi nhận truy vết. Cần tách bước xác minh của owner khỏi bước BA ghi nhận và cập nhật artifact dự kiến.; Gateway "Đơn vị tồn đã xác minh?" chỉ có nhánh "Chưa", nên không thể hiện kết quả khi đã xác minh và làm gateway thiếu logic. Cần thêm nhánh kết quả được hỗ trợ bởi prose: chọn đơn vị chuẩn hoặc giữ hai đơn vị cùng tỷ lệ quy đổi, rồi mới cập nhật artifact.; Diagram bỏ Decision Criteria quan trọng: quy cách đóng gói, cách đếm kho, chứng từ bán hàng mô phỏng và owner nghiệp vụ mô phỏng. Cần thể hiện các bằng chứng này làm đầu vào cho bước xác minh.; Nhãn "Unresolved verification item" pha ngôn ngữ và chưa nêu trạng thái quyết định cụ thể. Cần dùng nhãn tiếng Việt, concrete: chưa chọn đơn vị chuẩn; cần xác minh đơn vị tồn, đơn vị bán và tỷ lệ quy đổi.; Diagram không thể hiện hậu quả nếu quyết định sai: tồn kho, giá vốn, số lượng bán và báo cáo có thể dùng đơn vị khác nhau. Cần bổ sung rủi ro hoặc boundary kiểm soát để tránh làm luồng trông như cập nhật artifact thuần túy.
assets/diagrams/11-data-modeling-and-master-data-012-3a8cf3e5.mmd — REVISE — Nhánh thiếu evidence gộp sai Verification required và Unresolved: prose dùng Verification required cho fact thiếu nguồn, còn case đơn vị tồn kho giữ Unresolved vì chưa đủ evidence để quyết định. Cần tách điều kiện và kết quả tương ứng.; Nút Lập entity, thuộc tính, quan hệ bỏ qua khóa, business identifier, system identifier và rule-to-field mapping thuộc các bước 4–5. Cần thể hiện đủ phạm vi hoặc đổi nhãn để không mô tả thiếu quy trình.; Nút Quality review không nêu actor BA và QA reviewer mô phỏng, tiêu chí kiểm tra, hoặc lỗi chặn. Cần chỉ rõ actor và ít nhất boundary chặn handoff khi có mâu thuẫn nguồn, ID trùng hoặc dữ liệu nhạy cảm chưa phân loại.; Luồng từ Quality review sang handoff vô điều kiện, trong khi prose yêu cầu mỗi entity và rule liên kết evidence hoặc Unresolved, đồng thời package phải có open issue và escalation record. Cần thêm gateway đạt quality gate hoặc nhánh quay lại xử lý/escalation.; Nhãn Escalate owner đúng thẩm quyền mơ hồ và thiếu owner của case: Supply Chain Owner và Product Owner mô phỏng. Cần nêu owner hoặc quy tắc định tuyến theo domain.; Nút handoff chỉ nêu trạng thái và phiên bản, bỏ ngày 2026-08-07, package gồm model, dictionary, issue log, traceability, và boundary IN_REVIEW không phải baseline hay approval. Cần bổ sung các điều kiện kiểm soát này.; Sơ đồ không thể hiện rủi ro trọng tâm của case: chọn sai đơn vị khiến tồn kho và báo cáo cộng các đơn vị khác thước đo. Cần gắn hậu quả này với quyết định hoặc nhánh unresolved để giữ lý do kiểm soát.
assets/diagrams/11-data-modeling-and-master-data-013-f2d19617.mmd — REVISE — Nhánh "Có" dùng "Cập nhật CANONICAL_DATA_DICTIONARY", hàm ý thay đổi artifact đã được chấp thuận; phần prose chỉ hỗ trợ đề xuất mục từ và corpus vẫn ở trạng thái IN_REVIEW. Đổi nhãn thành kết quả đề xuất hoặc ghi nhận trạng thái review, không hàm ý approval.; Luồng thiếu bước review liên chức năng cho Business Owner, Architect, Accounting Owner, Legal Owner hoặc Security. Thêm bước review trước gateway để các vai trò và việc phát hiện mâu thuẫn có nguồn trong quy trình.; Nhánh thành công thiếu kết quả "Log quyết định còn trạng thái review". Thêm outcome này để phản ánh trạng thái, vấn đề, người xử lý và nguồn.; Bước "Phân loại nguồn tạo và nguồn tiêu thụ" bỏ tiêu chí một nguồn chân lý và trách nhiệm sở hữu dữ liệu. Làm rõ việc xác định nguồn tạo, cập nhật, tiêu thụ và nguồn sở hữu.; Gateway "Đủ bằng chứng và không mâu thuẫn?" khiến mọi mâu thuẫn đều escalation nhưng không thể hiện điều kiện mâu thuẫn liên quan nghiệp vụ, kế toán, pháp lý, bảo mật hoặc kiến trúc. Làm cụ thể điều kiện gateway hoặc nhánh escalation.; Nhãn "Security" không song song với các vai trò Owner còn lại và có thể chỉ đội ngũ thay vì vai trò chịu trách nhiệm. Dùng tên vai trò bảo mật nhất quán với mô hình sở hữu được curriculum định nghĩa.
assets/diagrams/11-data-modeling-and-master-data-014-467d0951.mmd — REVISE — Các mũi tên CANONICAL_DATA_DICTIONARY --> TRACEABILITY_ID_REGISTRY và CANONICAL_DATA_DICTIONARY --> CANONICAL_BUSINESS_RULES thể hiện quan hệ tạo sinh hoặc phụ thuộc tuần tự không được phần văn bản xác lập. Cần biểu diễn ba artifact như các đầu ra được kiểm soát từ hoạt động mô hình dữ liệu, hoặc chỉ nối chúng khi văn bản quy định rõ quan hệ phụ thuộc.; Nhãn Data modeling findings mơ hồ và không khớp đầu vào hay hoạt động cụ thể trong phần văn bản. Cần dùng khái niệm được phần này xác lập, như hoạt động mô hình dữ liệu và master data.; Sơ đồ cho thấy chỉ TRACEABILITY_ID_REGISTRY và CANONICAL_BUSINESS_RULES đi vào Downstream review, nên ngụ ý CANONICAL_DATA_DICTIONARY không được review trực tiếp. Điều này mâu thuẫn với quality gate áp dụng cho mỗi artifact. Cần đưa cả ba artifact vào gate hoặc downstream review.; Sơ đồ bỏ qua quality gate nằm giữa artifact và downstream review: đúng ID, đường dẫn canonical, trạng thái, phiên bản, ngày, trường bắt buộc, đăng ký ID, nguồn quy tắc và lịch sử thay đổi. Cần thể hiện gate hoặc điều kiện hội tụ trước review.; Nhãn Downstream review không thể hiện kết quả giới hạn của gate. Cần làm rõ đây chỉ là đủ đầu vào để review, không phải approval, baseline hay production readiness.
assets/diagrams/11-data-modeling-and-master-data-015-165a10a1.mmd — REVISE — Các thuộc tính product_type và traceability_level không được phần văn xuôi định nghĩa hoặc minh họa. Bổ sung định nghĩa, miền giá trị và quy tắc chất lượng trong từ điển dữ liệu, hoặc loại khỏi sơ đồ.; traceability_level dễ bị hiểu nhầm là traceability tới yêu cầu, rule hoặc quyết định, trong khi phần văn xuôi yêu cầu liên kết qua TRACEABILITY_ID_REGISTRY. Làm rõ đây là thuộc tính nghiệp vụ khác, hoặc thay bằng liên kết traceability đúng nguồn chân lý.; Cardinality ||--o{ khẳng định mỗi PRODUCT_MASTER bắt buộc thuộc đúng một UNIT_OF_MEASURE và đúng một PRODUCT_GROUP, nhưng phần văn xuôi chỉ nêu uom_code tham chiếu Unit of Measure và không xác nhận tính bắt buộc hay cardinality của nhóm hàng. Ghi rõ quy tắc cardinality trong văn xuôi hoặc chỉnh cardinality theo quy tắc đã xác minh.; Nhãn quan hệ base_uom_code và product_group_code chỉ lặp tên khóa ngoại, không diễn đạt quan hệ nghiệp vụ. Dùng nhãn cụ thể mô tả vai trò quan hệ.
assets/diagrams/11-data-modeling-and-master-data-016-3ace4595.mmd — REVISE — Các trạng thái Draft, Rework và tên trạng thái IN_REVIEW không được phần văn xuôi định nghĩa; cần bổ sung căn cứ trong văn xuôi hoặc loại bỏ khỏi sơ đồ.; Các chuyển tiếp Draft --> Rework, Rework --> Draft và IN_REVIEW --> Rework đưa vào quy trình sửa lỗi, lịch sử thay đổi và phản hồi reviewer chưa được phần văn xuôi hỗ trợ; cần bổ sung quy tắc tương ứng hoặc loại bỏ.; Nhãn đủ Quality Gate mơ hồ và không song song với nhánh thiếu bằng chứng; cần dùng điều kiện cụ thể như đạt hoặc không đạt tiêu chí bằng chứng, khả năng truy vết và khả năng phản biện.; Sơ đồ không thể hiện ranh giới quan trọng: vượt Quality Gate chỉ cho phép đi vào review, không tạo APPROVED, BASELINED, compliant, production-ready hoặc user-approved; cần biểu đạt giới hạn này để tránh suy diễn sai outcome.; Sơ đồ không nêu chủ thể kiểm tra Quality Gate. Nếu chủ thể quan trọng trong quy trình, phần văn xuôi phải xác định owner trước khi thêm vào sơ đồ.
assets/diagrams/11-data-modeling-and-master-data-017-e2cfa491.mmd — REVISE — Sơ đồ lặp nguyên quan hệ artifact–consumer đã có trong hai cột đầu của bảng nhưng bỏ mất “Cách dùng trực tiếp”, nên không thêm thông tin giải thích. Xóa sơ đồ hoặc đổi mục đích trực quan để thể hiện quan hệ có ý nghĩa chưa được bảng trình bày, chỉ dùng dữ kiện được section hỗ trợ.; Nhãn “Operations / Specialist Owners” dùng dấu “/”, dễ hiểu là lựa chọn thay vì hai nhóm cùng tham gia như “Operations và specialist owners” trong bảng. Đồng bộ ngữ nghĩa nhãn với prose.
assets/diagrams/11-data-modeling-and-master-data-018-42ed5a1e.mmd — REVISE — Các mũi tên từ mọi người nhận đến Escalation package ngụ ý mọi đầu ra đều phải escalation. Phải thể hiện mỗi vai trò quyết định trong phạm vi được giao và chỉ escalation khi điều kiện trong cột Phải escalation khi xảy ra.; Nhãn scope trade-off gây sai nghĩa: PM/Product Owner có thể chấp nhận trade-off trong phạm vi được giao. Phải đổi điều kiện escalation thành trade-off làm thay đổi business rule hoặc ảnh hưởng phạm vi pháp lý, kế toán, an toàn thực phẩm hay cam kết vận hành.; Các nhãn technical gap, operational impact và specialist authority quá rộng, không phản ánh điều kiện cụ thể trong bảng. Phải dùng nhãn điều kiện rõ ràng hoặc gom bằng gateway mang nghĩa vượt phạm vi/thẩm quyền.; Sơ đồ bỏ qua bằng chứng bắt buộc trước quyết định hoặc escalation. Phải thể hiện Escalation package chứa vấn đề và bằng chứng, đồng thời quyết định trong phạm vi cũng dựa trên bằng chứng.; Sơ đồ chỉ có nhánh escalation, thiếu outcome quyết định hợp lệ trong phạm vi vai trò. Phải bổ sung outcome này để không mô tả escalation như kết quả duy nhất.
assets/diagrams/11-data-modeling-and-master-data-019-6df88b71.mmd — REVISE — Nhánh “Không” kết thúc tại “Đọc phạm vi, nguồn, trạng thái” nhưng không nêu kết quả bàn giao hoặc cách xác nhận không có suy diễn. Bổ sung kết quả cụ thể được section hỗ trợ.; Bước “Đặt câu hỏi làm rõ” bỏ các thành phần bắt buộc: trường, nguồn, chủ sở hữu quyết định và hậu quả nếu hiểu sai. Sửa nhãn hoặc thêm bước thể hiện đủ bốn nội dung.; Gateway “Có đủ bằng chứng và đúng thẩm quyền?” gộp hai điều kiện nhưng không chỉ rõ cách xử lý khi thiếu bằng chứng, sai thẩm quyền hoặc cả hai. Tách hoặc ghi nhánh rõ để tránh hiểu mọi trường hợp đều chỉ chuyển cho owner chuyên môn.; Nhãn “Escalate owner chuyên môn” hẹp hơn prose, vốn yêu cầu escalation cho Legal Owner, Accounting Owner, bảo mật, kiến trúc tích hợp, quyền vận hành và thay đổi canonical ID. Dùng nhãn bao quát vai trò có thẩm quyền.; Nhánh có đủ bằng chứng kết thúc ở “Liên kết artifact canonical” nhưng bỏ yêu cầu kiểm tra ID, đường dẫn canonical, trạng thái/version, định nghĩa hoặc quy tắc liên quan và vai trò có thẩm quyền. Thể hiện tiêu chí bằng chứng tối thiểu hoặc dẫn đến bước xác nhận các tiêu chí này.; “Ghi vấn đề và traceability” chỉ xuất hiện sau escalation, tạo ấn tượng trường hợp được giải đáp bằng bằng chứng canonical không cần lưu traceability. Làm rõ việc ghi nhận áp dụng cho quyết định làm rõ hoặc chỉ rõ giới hạn nếu section chủ ý chỉ yêu cầu ghi khi escalation.
assets/diagrams/11-data-modeling-and-master-data-021-5dd06cdb.mmd — REVISE — ItemMaster.base_uom_code được đánh dấu FK nhưng sơ đồ không nối thuộc tính này với UomMaster; bổ sung quan hệ để thể hiện đơn vị cơ sở phải tồn tại trong danh mục đơn vị.; Quan hệ ItemMaster ||--o{ ItemUomConversion cùng nhãn cho phep don vi khiến danh sách đơn vị hợp lệ chỉ gồm bản ghi chuyển đổi, trong khi dữ liệu bảng chỉ có THUNG nhưng prose và JSON cho phép cả CHAI; làm rõ CHAI được phép nhờ base_uom_code hoặc phải có bản ghi factor 1 trong ItemUomConversion.; Khóa item_code + uom_code không cho lưu nhiều phiên bản factor theo thời gian, dù prose yêu cầu giữ lịch sử khi factor đã có giao dịch tham chiếu; mô hình cần hỗ trợ phiên bản hiệu lực hoặc bỏ effective_from nếu không quản lý lịch sử.; Tiêu chí C4 yêu cầu truy vết người thay đổi nhưng sơ đồ không có thuộc tính audit tương ứng; bổ sung trường người thay đổi hoặc thể hiện dependency tới cơ chế audit.; Nhãn quan hệ cho phep don vi và dinh nghia don vi thiếu dấu, chưa cụ thể về vai trò; dùng nhãn rõ nghĩa, phân biệt đơn vị giao dịch được phép với đơn vị được tham chiếu từ danh mục.
assets/diagrams/11-data-modeling-and-master-data-022-94770c2e.mmd — REVISE — Các mũi tên từ ba dòng nguồn vào RM-FLOUR-0001 thể hiện việc hợp nhất như luồng đã xác lập, trái với SYN-RULE-MD-004 và trạng thái chưa được phê duyệt. Cần thể hiện toàn bộ ánh xạ và tổng 2.500 KG là mô phỏng đề xuất, chưa phải cập nhật dữ liệu lịch sử.; Nút Quy đổi đề xuất chưa nêu điều kiện Inventory Owner phải xác minh 1 BAO = 25 KG. Cần gắn điều kiện xác minh hoặc ranh giới phê duyệt trước khi dùng quy đổi.; Luồng PO-SYN-20260807-003 đi thẳng vào mã đề xuất làm mất mã nguồn BMT-DA-DUNG và có thể bị hiểu là mã đã được thay thế. Cần phân biệt bản ghi nguồn với ánh xạ đề xuất sang mã chuẩn.; Kết quả Tồn quy đổi mô phỏng 2.500 KG thiếu cảnh báo rằng tổng chỉ hợp lệ nếu quy đổi được xác nhận và việc hợp nhất lịch sử được cho phép. Cần ghi rõ điều kiện này tại kết quả hoặc nhánh trước kết quả.
assets/diagrams/11-data-modeling-and-master-data-023-084d0c23.mmd — REVISE — Nhãn Section 9 không được phần văn bản xung quanh xác nhận và mâu thuẫn với tiêu đề hiển thị Core; sửa thành tên section đúng hoặc bỏ định danh section.; Nút Downstream handbook sections, templates, QA artifacts gộp nhiều đầu ra nhưng văn bản chỉ hỗ trợ việc chỉ dẫn đến template; bỏ các đầu ra không được xác nhận hoặc ghi rõ từng đầu ra có căn cứ.; Cạnh H --> OUT mô tả dependency downstream chưa được prose hoặc bảng giải thích; bổ sung căn cứ trong prose hoặc bỏ cạnh.
assets/diagrams/11-data-modeling-and-master-data-024-9a2030b7.mmd — REVISE — Outcome label failed test basis is ambiguous and conflicts with nearby example where tests may still pass against old rules. Replace it with concrete outcomes supported by section, such as tests validating old rules or broken traceability evidence.; Flow presents Update traceability links as mandatory before revising every dependent artifact. Section supports traceability maintenance but does not establish this universal sequence. Show traceability updates and artifact revisions as coordinated impact actions, or avoid implying unsupported order.; Canonical source changed is broader than prose example and table categories. Use concrete source types supported by section, such as data definition, business rule, persistent ID, source classification, or API version.
assets/diagrams/11-data-modeling-and-master-data-025-5d5f2e6e.mmd — REVISE — Luồng đặt bước Purchase order lưu supplier_code trước bước API kiểm tra mã tồn tại, trái với yêu cầu API kiểm tra dữ liệu đầu vào. Sửa thứ tự để API xác thực supplier_code với supplier master trước khi đơn mua hàng được lưu.; Nhãn Supplier master canonical không mô tả hành động hoặc vai trò, còn mũi tên từ API sang master rồi sang báo cáo tạo cảm giác master là một bước xử lý tuần tự. Sửa nhãn và quan hệ để thể hiện API tra cứu supplier master, còn báo cáo đọc đơn mua hàng và nhóm theo supplier_code.; Sơ đồ chỉ nói UI hiển thị hai trường, chưa thể hiện quyết định UI tạo supplier_display_name từ supplier_code và supplier_name. Bổ sung bước tạo giá trị hiển thị nhưng không gửi hoặc lưu chuỗi ghép.; Sơ đồ không thể hiện ranh giới giữa UI, consumer API, purchase order và supplier master, khiến nơi tạo giá trị hiển thị, nơi xác thực và nơi lưu khóa bị mơ hồ. Phân tách các thành phần hoặc gắn nhãn giao diện rõ ràng.
assets/diagrams/11-data-modeling-and-master-data-026-4d648752.mmd — REVISE — Nhánh “Có” chỉ khóa thay đổi và giao dịch mới, nhưng không dừng interface liên quan như bảng yêu cầu. Bổ sung bước dừng interface trong phạm vi ảnh hưởng.; Bước “Data Owner quyết định sửa, hợp nhất hoặc giữ nguyên” áp dụng một chủ sở hữu cho mọi loại lỗi, trong khi bảng yêu cầu thêm Procurement Owner, domain owner và legal verification trong các trường hợp cụ thể. Thể hiện gateway hoặc điều kiện chuyển cấp theo loại rủi ro.; Bước “Mở lại phạm vi đã kiểm tra” thiếu tiêu chí và ngoại lệ an toàn. Bổ sung điều kiện không mở lại khi còn cờ rủi ro từ Security, Legal hoặc Procurement Owner; với lỗi truy xuất lô, cần domain-owner và legal verification.; Nhánh “Không” đi thẳng đến “Đính chính bản ghi qua change log”, bỏ qua xác minh và phê duyệt trước chỉnh sửa. Bổ sung đối chiếu bản ghi và quyết định của chủ sở hữu phù hợp; change log chỉ ghi nhận thay đổi, không thay thế kiểm soát.; Sơ đồ không thể hiện ranh giới cấm xóa, tự gộp, đổi mã đã có giao dịch hoặc sửa trực tiếp số dư. Bổ sung guardrail tại bước quyết định sửa để tránh diễn giải quy trình như cho phép các hành động này.
assets/diagrams/11-data-modeling-and-master-data-027-992f8912.mmd — REVISE — Nhánh D -- Không --> E cho phép “giả định dự án”, trái với Decision đã chọn phương án (3). Kết quả phải giữ LotCode ở mức thuộc tính logic và đánh dấu mọi rule định dạng, lưu giữ là Verification required.; Gateway D dùng nhãn chung “authority”, làm mất ranh giới thẩm quyền. Cần nêu Business Owner, Food-safety Owner hoặc Legal Owner; Principal IT Business Analyst / Technical Curriculum Author chỉ giữ governance.; Nhánh F -- Không --> G yêu cầu “Sửa tên sơ đồ”, nhưng section chỉ hỗ trợ sửa nhãn và khôi phục liên kết tới artifact canonical. Cần thay hành động không có căn cứ này.; Kết quả “Đủ điều kiện review” mơ hồ và dễ bị hiểu nhầm với trạng thái IN_REVIEW hoặc approval. Cần nêu rõ điều kiện đạt kiểm tra governance, không đồng nghĩa đã phê duyệt.; Luồng thiếu kết quả an toàn khi không có canonical source hoặc ID: không được tạo rule pháp lý, approval, baseline hay cấu hình ERP. Cần thể hiện ranh giới này hoặc kết thúc rõ tại Verification required.
assets/diagrams/11-data-modeling-and-master-data-028-ebca3616.mmd — REVISE — Gateway “Quyết định thuộc authority nào?” ngụ ý chỉ một authority, trái quy tắc escalation khi đề xuất thuộc từ hai authority trở lên. Cần hỗ trợ chọn nhiều authority và thêm nhánh escalation.; Nhánh “Không” đi thẳng từ ghi khoảng trống đến recommendation, nhưng không xác định owner chịu trách nhiệm verification. Cần thể hiện chuyển yêu cầu xác minh đến authority phù hợp trước khi ghi khuyến nghị có điều kiện.; Nút “Legal/Accounting/Food-safety Owner” gộp nhiều authority độc lập, che mất ranh giới thẩm quyền và điều kiện escalation. Cần tách các owner hoặc biểu diễn rõ đây là lựa chọn đa authority.; Luồng chưa tách rõ inference khỏi evidence và decision như nguyên tắc mở đầu. “Phân tích lựa chọn và tác động” cần được nhận diện là suy luận, còn recommendation không được thể hiện thành approval hay quyết định chuyên môn.; Sơ đồ kết thúc tại “Ghi recommendation có điều kiện” nhưng thiếu outcome lưu traceability và thiếu trạng thái chờ verification hoặc quyết định của owner, dù prose nhấn mạnh BA giữ traceability và không thay kết luận chuyên môn.
assets/diagrams/11-data-modeling-and-master-data-029-08cc920e.mmd — REVISE — Gateway tác động bỏ sót security và food traceability, dù phần prose yêu cầu escalate ngay. Bổ sung hai nhóm rủi ro này vào điều kiện escalation.; Luồng bỏ sót hai ngưỡng escalation rõ ràng: tỷ lệ bản ghi không map được vượt 1% mẫu migration và hai owner đưa rule trái ngược. Thể hiện các điều kiện này trong gateway hoặc nhánh escalation.; Nhãn "Escalate đúng owner" mơ hồ. Nêu owner theo loại tác động: Business, Data, Architect, Legal, Accounting hoặc Security Owner.; Bước "Đối chiếu CANONICAL_DATA_DICTIONARY" có thể khiến người đọc hiểu tài liệu là baseline. Làm rõ artifact đang IN_REVIEW, v0.9.0 và chỉ dùng làm bằng chứng rà soát, không phải nguồn đã phê duyệt.; Nhánh không escalation đi thẳng từ rà soát đến ghi nhận quyết định nhưng không thể hiện xử lý exception về migration legacy, party dùng chung, supplier item reference, dữ liệu cá nhân và snapshot chứng từ. Thêm điểm kiểm tra exception hoặc phạm vi áp dụng trước khi ghi nhận quyết định.
assets/diagrams/11-data-modeling-and-master-data-030-f65d221d.mmd — REVISE — Nhánh "Không" gộp assumption với Verification required và bỏ trạng thái unknown. Tách rõ assumption, unknown và yêu cầu xác minh để khớp bốn loại ghi nhận trong phần prose.; Gateway "Evidence đủ cho claim?" chưa nêu claim nào và tiêu chí đủ là gì. Làm rõ bằng chứng có nguồn, trạng thái, phiên bản, ngày và phạm vi hỗ trợ claim.; Luồng đi thẳng từ fact hoặc assumption đến recommendation, bỏ bước inference và residual uncertainty trong chuỗi bằng chứng. Thêm bước ghi phần suy ra và phần chưa được nguồn phủ trước khuyến nghị.; Nhãn "Record authority needed" quá chung, không phân biệt quyền quyết định với vai trò xác minh. Nêu Decision authority hoặc Verification owner phù hợp phạm vi Business, Architecture, Accounting, Legal, Security hay Compliance.; Kết quả cuối áp dụng IN_REVIEW cho mọi nguồn và quyết định, trong khi prose chỉ yêu cầu giữ thuộc tính hoặc quy tắc ở IN_REVIEW khi chưa có authority record. Giới hạn kết quả cho artifact hoặc đề xuất đang được quản trị.
assets/diagrams/11-data-modeling-and-master-data-031-0b73bb8e.mmd — REVISE — Bước F[Điền template theo quality gate] đưa vào quality gate không được phần văn xuôi định nghĩa hoặc xác nhận. Đổi thành hành động chỉ dựa trên nội dung đã nêu, như điền template đã đăng ký.; Nhánh E -->|Không| G kết thúc ở lệnh cấm, không nêu kết quả sử dụng được khi thiếu ID hoặc file. Bổ sung hướng xử lý phù hợp source boundary: không coi template chưa đăng ký là completed artifact và tham chiếu worked example tại /02-handbook/11-data-modeling-and-master-data.md, mục ## 8. Detailed Worked Example, khi mục đích là dùng artifact của chapter.; Nhãn D[Tham chiếu canonical artifact] quá chung, trong khi văn xuôi xác định rõ artifact, vị trí và giới hạn sử dụng. Làm rõ nguồn được tham chiếu để tránh hiểu worked example là template master-data được phê duyệt hoặc cấu hình ERP.; Sơ đồ bỏ qua trạng thái và giới hạn quan trọng của worked example: IN_REVIEW, v0.9.0, ngày 2026-08-07 không biểu thị baseline, approval, compliance hoặc production-ready. Thể hiện boundary này tại nhánh dùng artifact để ngăn diễn giải sai.
assets/diagrams/11-data-modeling-and-master-data-032-3e0beffd.mmd — REVISE — Sơ đồ tự mô tả nhu cầu tra dữ liệu chapter 11 nhưng bỏ nhánh tra cấu trúc 12 mục tại chính chapter; bổ sung lựa chọn và đích tương ứng.; Sơ đồ bỏ nguồn /00-research/00_SOURCE_MAP.md, nên không thể hiện ranh giới sử dụng nguồn pháp lý, chuẩn và good practice; bổ sung nhánh tra nguồn và safe use boundary.; Gateway Cần nguồn canonical? dẫn tới CHAPTER_MANIFEST và TEMPLATE_MANIFEST, trong khi bảng mô tả hai tệp này là danh mục, không phải nguồn canonical; đổi gateway hoặc tách nhánh để phân biệt nguồn canonical với danh mục.; Nhãn Phạm vi chapter hoặc template gộp hai nhu cầu có quy tắc khác nhau; tách thành nhánh phạm vi chapter và nhánh template dự kiến, đồng thời nêu rõ template đã đăng ký không đồng nghĩa artifact đã hoàn tất.; Nhánh Nova Foods chỉ dẫn tới Mục 8 nhưng bỏ điều kiện sử dụng quan trọng: mô phỏng, dữ liệu tổng hợp, không phải ERP thực tế, template vận hành, baseline hoặc approval; thể hiện ranh giới này trong nhãn hoặc trạng thái kết quả.
assets/diagrams/11-data-modeling-and-master-data-033-d46a525e.mmd — REVISE — "Draft section 12" không được phần văn bản xác lập và có thể mâu thuẫn với phạm vi chapter; thay bằng phạm vi được nêu rõ là chapter trước bàn giao.; Các bước "Mở open issue", "Escalate đúng owner" và "Gắn Verification required" tạo quy trình, owner và trạng thái không có trong phần văn bản; bỏ hoặc bổ sung căn cứ trong prose.; Nhánh có mâu thuẫn vẫn dẫn đến "Chapter handoff IN_REVIEW", trong khi prose chỉ cho phép bàn giao khi chapter giữ đúng trạng thái và bằng chứng canonical; sửa outcome để không ngụ ý mâu thuẫn chưa xử lý vẫn được bàn giao.; Kiểm tra bằng chứng còn thiếu ngày 2026-08-07, tình trạng chưa có baseline hoặc approval, và ranh giới template với completed worked example tại mục 8; thể hiện các điều kiện này hoặc gom trong nhãn cụ thể, không dùng "source boundary" mơ hồ.; "Gắn kết quả self-review" không nêu kết quả nào được gắn, ở đâu hoặc tiêu chí đạt; đổi thành outcome cụ thể được prose hỗ trợ.; Nhãn pha trộn tiếng Việt không dấu với tiếng Anh và chưa song song về cấu trúc; dùng nhãn tiếng Việt rõ, nhất quán, giữ nguyên các giá trị kỹ thuật như IN_REVIEW và v0.9.0.
assets/diagrams/12-api-and-integration-analysis-002-83e67c0d.mmd — REVISE — Thiếu nhánh lỗi từ Hub dù phần văn xuôi yêu cầu phản hồi thành công hoặc lỗi và xác định outcome là deliveryId hoặc lỗi. Bổ sung nhánh phản hồi lỗi và cách ERP ghi nhận lỗi.; 201 Created là chi tiết HTTP cụ thể chưa được phần văn xuôi xác lập. Bỏ mã trạng thái này hoặc bổ sung căn cứ trong nội dung trước khi dùng.; trạng thái gửi mơ hồ, không phân biệt thành công với thất bại. Đổi thành trạng thái cụ thể theo từng nhánh, phù hợp yêu cầu nhân viên phải biết đơn đã gửi thành công hay chưa.
assets/diagrams/12-api-and-integration-analysis-003-48951d3a.mmd — REVISE — Hai tác nhân Nova Foods ERP và Nova Delivery Hub không được xác lập trong phần văn bản; cần dùng tác nhân đã nêu hoặc bổ sung ngữ cảnh xác nhận các hệ thống này.; Nhãn Mã đơn khác cách hiểu mơ hồ và thiếu cấu trúc song song; cần diễn đạt cụ thể việc hai hệ thống diễn giải orderId khác nhau.; Kết quả Nguy cơ giao trùng không được phần văn bản nêu hoặc chứng minh; cần thay bằng hậu quả có trong phần Core hoặc bổ sung lập luận hỗ trợ.; Nhánh Trường bắt buộc không khớp dẫn đến Yêu cầu bị từ chối đưa vào điều kiện và kết quả chưa được phần văn bản mô tả; cần bỏ nhánh hoặc bổ sung nội dung nguồn.; Nhánh lỗi không thể hiện nơi ghi nhận lỗi và chủ sở hữu xử lý, dù đây là ranh giới trọng yếu được phần văn bản nhấn mạnh; cần thể hiện hoặc giới hạn sơ đồ rõ ràng vào nhóm rủi ro dữ liệu.
assets/diagrams/12-api-and-integration-analysis-004-44252e24.mmd — REVISE — Nhánh "Chưa tồn tại" dùng "ERP-->>API: Tạo đơn ERP" như phản hồi, làm mơ hồ actor và thứ tự hành động. Cần thể hiện ERP tạo đơn rồi trả kết quả cụ thể.; Thiếu nhánh từ chối hoặc lỗi dù prose yêu cầu ERP trả kết quả nhận hoặc từ chối, quy định phản hồi HTTP và mô tả cách xử lý lỗi. Cần thêm điều kiện từ chối/lỗi cùng kết quả HTTP cụ thể.; Nhãn "Kết quả nhận đơn" và "Không tạo đơn mới" không nêu trạng thái HTTP, mã đơn ERP hoặc cách bên gửi phân biệt đơn mới với đơn trùng. Cần dùng kết quả cụ thể, song song giữa các nhánh.; Luồng chỉ kiểm tra rồi tạo, không thể hiện kiểm tra trùng và tạo đơn phải bảo đảm quy tắc tối đa một đơn ERP cho mỗi externalOrderId. Cần tránh mô tả gây hiểu rằng hai yêu cầu đồng thời đều có thể vượt qua bước kiểm tra.
assets/diagrams/12-api-and-integration-analysis-005-aad27cd2.mmd — REVISE — Gateway "Có artifact hoặc nguồn kiểm soát đối chiếu?" makes artifact existence sufficient for "Verified fact". Section supports verification only when claim can be matched to designated source content. Require evidence content and source match, not mere artifact existence.; Classification order can mislabel authority-recorded stakeholder choices as "Stakeholder input" because stakeholder-origin test occurs before decision-authority test. Ensure recorded choice by proper authority reaches "Decision" regardless of origin.; Gateway "Được authority ghi nhận lựa chọn?" is ambiguous about required authority. Specify relevant authority: Architect for technical option, Business Owner for business priority, Security for data controls, and Legal/Compliance when personal-data obligations apply.; Diagram omits critical distinction between review status and approval. Add condition preventing IN_REVIEW or missing approval reference from reaching "Decision" or any approved state.; Branch from impact gateway to "Verification-required claim" implies only legal, accounting, security, or operational claims need verification. Unsupported technical or business claims may also require verification. Base this outcome on missing evidence requiring confirmation, with impact controlling escalation or required reviewer.; "Project assumption" branch lacks explicit temporary and unapproved status. Clarify that this outcome applies when evidence or authority confirmation is absent and must not be treated as decision.
assets/diagrams/12-api-and-integration-analysis-006-0276ab59.mmd — REVISE — Cạnh Delivery → Testing ghi "deployment evidence available", nhưng phần văn xuôi chỉ yêu cầu build artifact có thể kiểm tra và ghi nhận sai khác. Bỏ "deployment evidence" hoặc thay bằng điều kiện được hỗ trợ: build artifact và test basis có sẵn.; Cạnh Operations chỉ quay về Discovery, trong khi exit gate cho phép quay lại Discovery hoặc Analysis. Thêm nhánh Operations → Analysis với điều kiện incident hoặc change signal đã đủ thông tin.; Cạnh Testing → Release thiếu residual risk, thành phần bắt buộc của exit gate và đầu vào quyết định release. Bổ sung residual risk vào nhãn.; Cạnh Testing → Release có thể khiến người đọc hiểu test evidence tự động cho phép release, nhưng văn xuôi yêu cầu quyết định release đúng thẩm quyền được ghi nhận. Thể hiện gateway hoặc điều kiện quyết định release trước Release.; Nhãn Operations → Discovery dùng "metric" quá mơ hồ và không phản ánh điều kiện exit là incident hoặc change signal được ghi nhận đủ. Thay bằng điều kiện cụ thể, đồng thời giữ metric như tín hiệu đầu vào nếu cần.
assets/diagrams/12-api-and-integration-analysis-007-98297bd0.mmd — REVISE — Thiếu Accounting Owner cho escalation về giá trị hóa đơn, hạch toán, thuế và chứng từ. Bổ sung actor cùng luồng escalation từ BA.; Thiếu Delivery Lead trong escalation sự cố sau release gây mất hoặc nhân bản đơn. Bổ sung owner này cùng Operations Owner và Solution Architect.; Luồng Security Owner → Solution Architect không phản ánh bảng, nơi BA cung cấp escalation package cho Security Owner và có thể cho Legal/Compliance Owner. Sửa hướng và quan hệ để thể hiện BA escalation đến đúng owner.; Luồng Legal/Compliance Owner → Business Owner với nhãn “Xác minh cần thiết” mơ hồ và không được section xác lập. Thay bằng luồng escalation từ BA đến Legal/Compliance Owner cho dữ liệu cá nhân, tuân thủ, kế toán hoặc thuế khi cần.; Thiếu nhánh test fail do acceptance criteria thiếu: Business Owner và BA xử lý requirement, QA Lead điều phối test evidence. Bổ sung điều kiện test fail, owner và kết quả mong đợi.; Thiếu ranh giới cấm BA tự quyết định: trạng thái ERP, kiến trúc API, kết luận tuân thủ, diễn giải luật, sửa expected result và tự chạy lại dữ liệu. Thể hiện boundary hoặc ghi rõ sơ đồ chỉ mô tả routing escalation.; Luồng DEV → Operations Owner với nhãn “Build và cấu hình” không được bảng escalation hỗ trợ và dễ gán Operations Owner trách nhiệm nhận build. Xóa hoặc thay bằng quan hệ sự cố sau release có owner và bằng chứng đúng.; Nhãn “Contract và lỗi dự kiến” và “Xác minh cần thiết” thiếu đối tượng, điều kiện hoặc đầu ra cụ thể. Đổi thành nhãn cụ thể, song song với các artifact trong bảng.; Hai luồng BA escalation chỉ đến Business Owner và Solution Architect làm sai phạm vi owner. Bổ sung Security Owner, Legal/Compliance Owner, Accounting Owner, Operations Owner và Delivery Lead theo từng điều kiện.
assets/diagrams/12-api-and-integration-analysis-008-160b0626.mmd — REVISE — Mũi tên nét đứt O → D mang nhãn "Sự cố hoặc thay đổi", nhưng phần giải thích quy định mũi tên nét đứt biểu thị vật bàn giao giữa các pha. Đây là sự kiện kích hoạt hoặc phản hồi, không phải vật bàn giao. Cần đổi cách diễn đạt trong prose hoặc dùng ký hiệu khác cho vòng phản hồi.; Nhãn "API contract, mapping, lỗi" không song song và "lỗi" mơ hồ: có thể là lỗi đã xảy ra, mã lỗi hoặc quy tắc xử lý lỗi. Cần ghi cụ thể vật bàn giao, như "API contract, mapping, quy tắc và mã lỗi".; Các cặp mũi tên liền và nét đứt chạy song song giữa cùng hai pha dễ bị hiểu thành hai luồng độc lập. Cần làm rõ nét đứt là vật bàn giao gắn với bước chuyển pha, không phải luồng công việc thứ hai.
assets/diagrams/12-api-and-integration-analysis-009-01651d45.mmd — REVISE — Nhãn "Need trao đổi dữ liệu" pha tiếng Anh–Việt và không cụ thể; đổi thành nhãn tiếng Việt mô tả nhu cầu trao đổi dữ liệu.; Bước "Canonical ID" mơ hồ: có thể chỉ định danh artifact hoặc ID liên kết dữ liệu. Cần phân biệt rõ hai khái niệm theo prose.; Luồng tuyến tính ngụ ý mọi phân tích đều đi qua một "Canonical ID", nhưng prose chỉ yêu cầu xác định ID giữ liên kết không đổi và bằng chứng có định danh. Cần thể hiện đúng điều kiện hoặc quan hệ này.; "Artifact nguồn" thiếu các thuộc tính bằng chứng bắt buộc: nguồn, định danh, đường dẫn và ranh giới sử dụng. Cần thể hiện hoặc gọi tên ranh giới bằng chứng.; Sơ đồ bỏ qua ranh giới quan trọng: CANONICAL_DATA_DICTIONARY chỉ mô tả nghĩa logic, không phải schema DB hoặc JSON API; CANONICAL_BUSINESS_RULES là nguồn tham chiếu, không phải nội dung để sao chép và sửa nghĩa.; Sơ đồ gần như lặp lại prose dưới dạng chuỗi hộp, chưa giải thích thêm quan hệ giữa nguồn bằng chứng, nghĩa dữ liệu, ID liên kết và đầu ra phân tích. Cần bổ sung giá trị giải thích thay vì chỉ tuần tự hóa câu chữ.
assets/diagrams/12-api-and-integration-analysis-010-1c617584.mmd — REVISE — Thiếu kiểm tra “kết luận nào được phép rút ra”, dù đây là một trong năm câu bắt buộc trước khi input đủ điều kiện phân tích. Bổ sung gateway này trước trạng thái “Đủ điều kiện phân tích”.; Nhánh “Owner xác minh hoặc ghi giả định?” gộp hai kết quả không tương đương rồi cùng dẫn đến “Đủ điều kiện phân tích”. Giả định chỉ lấp khoảng trống tạm thời, không thay thế xác minh cho quyết định bắt buộc và không được trở thành business rule. Tách nhánh xác minh khỏi nhánh ghi giả định; nhánh giả định phải giới hạn loại kết luận được phép.; Nhãn “Còn mới theo ngưỡng?” đưa vào khái niệm ngưỡng nhưng phần văn xuôi không xác định ngưỡng nào. Đổi thành điều kiện được phần này hỗ trợ trực tiếp, hoặc bổ sung định nghĩa ngưỡng trong văn xuôi.; Trạng thái “STOP: không phân tích” quá tuyệt đối so với văn xuôi: input thiếu năm câu vẫn có thể dùng làm tham khảo, nhưng không đủ để viết yêu cầu, mapping dữ liệu hoặc quyết định tích hợp. Sửa kết quả để thể hiện đúng giới hạn sử dụng.
assets/diagrams/12-api-and-integration-analysis-011-b14229bb.mmd — REVISE — Hai nhánh "ERP core mô phỏng" và "Middleware mô phỏng" không được phần văn xuôi xác nhận là các hệ đích khả dĩ. Xóa các lựa chọn chưa có nguồn hoặc biểu diễn chung trạng thái "Hệ đích cần xác minh".; Nút quyết định dùng hình thoi nhưng các nhánh không có điều kiện hay tiêu chí, khiến sơ đồ ngụ ý lựa chọn loại trừ giữa ERP core và middleware. Chỉ dùng gateway khi có các điều kiện nhánh được section hỗ trợ.; Nhóm "Business Owner / Architect / Security Owner" cùng xác minh hệ đích làm sai thẩm quyền: Business Owner xác nhận mục tiêu nghiệp vụ, Solution Architect xác nhận topology và contract, Security Owner xác nhận kiểm soát bảo mật. Tách trách nhiệm hoặc giới hạn liên kết xác minh hệ đích cho Solution Architect.; Legal Owner bị bỏ sót dù section giao trách nhiệm xác nhận nghĩa vụ dữ liệu cá nhân khi áp dụng. Bổ sung nhánh có điều kiện hoặc thể hiện rõ phạm vi pháp lý chưa xác định.; Sơ đồ chỉ thể hiện bất định về hệ đích, bỏ các điều kiện chặn contract: hệ nguồn, ID chống trùng, chủ sở hữu dữ liệu, bảo mật và lỗi nhận đơn. Bổ sung trạng thái kiểm chứng các đầu vào này nếu sơ đồ nhằm giải thích quyết định dừng ở inventory.
assets/diagrams/12-api-and-integration-analysis-012-c59429fb.mmd — REVISE — Thứ tự G → H trả thành công trước khi ghi liên kết orderNumber với mã đơn ERP. Nếu bước H thất bại, cổng đã nhận kết quả thành công nhưng yêu cầu traceability chưa đạt. Chuyển việc ghi liên kết trước phản hồi thành công hoặc thể hiện tạo đơn và liên kết là một kết quả nguyên tử.; Nhánh tạo đơn chỉ có kết quả thành công. Thiếu kết quả quan sát được khi ERP không thể tạo đơn, dù phần prose yêu cầu lỗi truy vết được và phản hồi phải phản ánh việc ERP từ chối. Bổ sung nhánh lỗi xử lý với phản hồi xác định và bằng chứng lỗi, không tự đặt mã HTTP khi nguồn chưa quy định.; Nhãn Trả kết quả không tạo đơn trùng chưa cụ thể về kết quả quan sát được. Nêu rõ đây là phản hồi trùng xác định và không tạo đơn mới; chỉ thêm mã trạng thái nếu hợp đồng hoặc nguồn canonical quy định.
assets/diagrams/12-api-and-integration-analysis-013-0aa7a512.mmd — REVISE — Traceability Record must link directly to business need, but diagram only shows an indirect path through Integration Context Map. Add dependency from Business need to API-INT-TRC-001.; Label "Error Catalogue" conflicts with canonical artifact name "Error and Exception Catalogue". Use full canonical name.; Arrows lack defined meaning and can imply a mandatory linear creation sequence. Label or otherwise clarify them as artifact dependencies or traceability links.; All artifacts have state IN_REVIEW, but diagram omits state and may imply completed or approved outputs. Show IN_REVIEW or add explicit scope note covering all artifact nodes.
assets/diagrams/12-api-and-integration-analysis-014-88c2db0f.mmd — REVISE — Các nhãn Nova Foods ERP, Partner API, POST /v1/purchase-orders, partnerOrderId, purchaseOrderNo và các mã 201, 400, 409, 401 không được phần văn bản xác nhận; cần đối chiếu nguồn canonical hoặc thay bằng nội dung đã được section định nghĩa.; Bốn response đang xuất hiện như các bước liên tiếp, trong khi chúng là kết quả loại trừ nhau; cần biểu diễn bằng nhánh alt với điều kiện cụ thể.; Sơ đồ thiếu Interface IDINT-NF-001, nên không đáp ứng yêu cầu liên kết artifact và không chứng minh được traceability.; Nhãn lỗi chưa nêu hành động của caller, receiver hoặc kết quả sau lỗi; cần bổ sung owner và outcome cho từng nhánh nếu các chi tiết này có nguồn hỗ trợ.; Sơ đồ không thể hiện trigger, xác thực trước lời gọi hoặc dữ liệu nghiệp vụ gửi đi; cần bổ sung các yếu tố bắt buộc nếu mục tiêu là mô tả cam kết trao đổi dữ liệu.
assets/diagrams/12-api-and-integration-analysis-015-f092b213.mmd — REVISE — Nhãn Rework --> Draft: cập nhật có lịch sử đưa thêm yêu cầu lưu lịch sử nhưng phần prose không quy định yêu cầu này. Bỏ điều kiện có lịch sử hoặc bổ sung quy định và bằng chứng tương ứng trong prose.; Nhãn Draft --> Ready_for_downstream_review: đủ quality gate mang tính vòng tròn, không nêu điều kiện cụ thể từ bảng. Thay bằng nhãn thể hiện artifact đáp ứng điều kiện ready và có đủ bằng chứng bắt buộc.; Nhãn Draft --> Rework: thiếu evidence hoặc mâu thuẫn trộn thuật ngữ Anh–Việt và dùng mâu thuẫn rộng hơn các điều kiện fail đã nêu. Dùng thuật ngữ nhất quán và giới hạn nhãn theo thiếu bằng chứng hoặc vi phạm điều kiện fail trong bảng.; Luồng không thể hiện ai thực hiện việc đưa artifact từ Rework về Draft; reviewer chỉ xuất hiện ở nhánh phát hiện lỗi. Xác định owner nếu section có quy định, hoặc dùng nhãn hành động không ngụ ý ownership chưa được hỗ trợ.
assets/diagrams/12-api-and-integration-analysis-016-209ed340.mmd — REVISE — Diagram duplicates table as simplified actor-to-use mappings and adds no explanatory relationship. Remove diagram or make it show artifact-to-consumer dependencies not visible in table.; "BA outputs" is ambiguous because diagram omits named outputs such as API contract, data mapping, error catalogue, sequence flow, and retry rule. Name relevant artifacts or group them under concrete artifact categories.; "Build integration," "Test basis," and "Specialist review" are too generic to preserve section meaning. Use concrete, parallel outcomes covering contract implementation, request/response and boundary testing, and domain-specific review.; Diagram hides shared artifacts and cross-role dependencies. Show which outputs serve multiple consumers if diagram remains; this overlap is main relationship table does not visualize.; "BA outputs" implies single ownership not established by prose. Use wording that describes analysis outputs without assigning unsupported ownership.
assets/diagrams/12-api-and-integration-analysis-017-2c8a07be.mmd — REVISE — SPO -->|specialist conclusion| ESC contradicts table: specialist owners may make specialist conclusions; escalation applies when mandatory requirements lack specialist verification. Replace trigger with concrete unverified-obligation condition.; ESC --> BA invents BA as universal escalation recipient. Section defines escalation conditions but not destination or ownership. Remove return edge or document supported escalation owner.; ESC[Escalation package] invents artifact not defined in surrounding prose. Use escalation state/action already supported, or define package and required contents in prose.; Developer escalation label omits critical privacy exposure and breaking-consumer change triggers. Represent those conditions or use concrete inclusive wording.; PM/Product Owner escalation label scope or authority boundary obscures explicit legal, accounting, food-safety, and over-budget risks. Use supported risk and authority conditions.; Diagram omits review-status boundary: outputs are IN_REVIEW, not approved baseline, ERP configuration, legal conclusion, or production decision. Show this boundary because diagram otherwise presents unrestricted distribution from BA output package.
assets/diagrams/12-api-and-integration-analysis-018-56ddceba.mmd — REVISE — Bước BA->>BA: Ask exact clarification question không xác định người trả lời hoặc chủ sở hữu quyết định. Cần thể hiện BA gửi câu hỏi đến đúng owner hoặc escalation khi chưa xác định được owner.; Nhãn Updated traceable interpretation mơ hồ: không cho biết diễn giải được truy vết tới quyết định, bằng chứng hay acceptance criteria nào. Cần nêu đầu ra kiểm chứng được và nguồn phê duyệt.; Luồng tuyến tính BA → Developer → QA → Operations làm bàn giao trông như chuỗi một chiều, trong khi nội dung mô tả khác biệt cách hiểu và vòng phản hồi giữa nhiều vai trò. Cần thể hiện điểm phát hiện mơ hồ và vòng xác nhận trước khi cập nhật cơ sở phát triển, kiểm thử hoặc vận hành.; Diagram chỉ thể hiện Missing business outcome or duplicate record, bỏ các rủi ro trọng yếu khác trong bảng: nhầm nghĩa status, sai khóa canonical, hiểu HTTP 200 là thành công, và lỗi chỉ ghi log. Cần biểu diễn các nhóm ngoại lệ hoặc dùng nhãn tổng quát bao phủ đầy đủ.; Architect và PM/Product Owner có trách nhiệm trong các hiểu nhầm về idempotency và xử lý lỗi nhưng không xuất hiện. Cần thêm owner liên quan hoặc tránh mô hình hóa diagram như luồng vai trò đầy đủ.; Diagram không thể hiện bằng chứng kiểm tra được hoặc nơi escalation dù đoạn dẫn xác định đây là đầu ra BA phải tạo. Cần thêm bước ghi nhận bằng chứng và điều kiện escalation.
assets/diagrams/12-api-and-integration-analysis-019-e2da0759.mmd — REVISE — Sơ đồ bỏ qua kiểm tra JSON và kiểm tra sơ bộ customerCode trước khi đưa bản ghi vào hàng đợi. Bổ sung các bước này đúng thứ tự để không hàm ý mọi payload đều được xếp hàng.; Nhãn Thành công hoặc lỗi gộp hai kết quả quan trọng nhưng không thể hiện nhánh tạo đơn và nhánh ghi lỗi nội bộ. Tách nhánh thành công/thất bại, gồm kết quả tương ứng.; Sơ đồ bỏ qua hành vi người dùng gửi lại và nguy cơ tạo đơn trùng—rủi ro chính của phần này. Thể hiện lần gửi lại và ghi rõ nguy cơ là suy luận do chưa biết cơ chế nhận diện externalOrderId trùng.; Hai participant NOVA-ERP API và NOVA-ERP có thể gây hiểu nhầm thành hai hệ thống độc lập, trong khi phần văn chỉ xác nhận API và tiến trình nền thuộc ERP. Làm rõ ranh giới nội bộ hoặc dùng participant không hàm ý hệ thống riêng.
assets/diagrams/12-api-and-integration-analysis-020-1aec4459.mmd — REVISE — Nhánh thành công trả 202 Accepted nhưng prose và bảng quy tắc không quy định mã phản hồi cho BR-API-DEL-004. Cần xác nhận mã này trong nội dung hoặc bỏ khỏi sơ đồ.; Nhãn đơn không hợp lệ gộp hai điều kiện khác nhau: salesOrderId không tồn tại và đơn không ở READY_TO_SHIP. Cần tách thành hai nhánh cụ thể, song song với BR-API-DEL-002 và BR-API-DEL-003.; Bước thành công chỉ nêu lưu eventId và cập nhật DELIVERED, bỏ occurredAt, trackingNumber, proofReference dù đây là dữ liệu bắt buộc theo Underlying Need và BR-API-DEL-004. Cần thể hiện đầy đủ dữ liệu được lưu.; Nhánh salesOrderId không tồn tại phải thể hiện lưu lỗi kỹ thuật để xử lý vận hành theo BR-API-DEL-002; sơ đồ hiện chỉ trả lỗi.; Luồng API->>ERP yêu cầu ERP kiểm tra nhưng không có phản hồi từ ERP về kết quả kiểm tra trước khi API trả HTTP. Cần thể hiện kết quả kiểm tra hoặc đặt điều kiện xử lý tại đúng actor để tránh quan hệ nhân quả mơ hồ.; Endpoint /api/v1/delivery-events không được xác lập trong prose hay bảng quy tắc ngoài chính sơ đồ. Cần có nguồn hỗ trợ trong nội dung hoặc dùng nhãn giao diện không khẳng định URL chưa được xác nhận.
assets/diagrams/12-api-and-integration-analysis-021-199a09cd.mmd — REVISE — HTTP 202 không được phần văn bản xác định; phải bỏ mã cụ thể hoặc dùng kết quả phản hồi đã được đặc tả.; Kiểm tra BR-INT-WH-001 đến BR-INT-WH-005 gộp sai trách nhiệm và che mất điều kiện: BR-INT-WH-001 chi phối lúc ERP phát sự kiện, còn BR-INT-WH-002 yêu cầu Portal chống xử lý lặp. Phải đặt từng kiểm tra tại đúng actor.; Thiếu nhánh từ chối payload khi thiếu trường, sai status, sai thời gian, sai tiền tệ hoặc sai số tiền theo BR-INT-WH-003 đến BR-INT-WH-005; phải thể hiện kết quả lỗi, không chỉ luồng thành công.; Thiếu nhánh phát hiện bản ghi trùng theo tổ hợp warehouseIssueId và status; phải thể hiện Portal không xử lý lần hai.; Thiếu retry có kiểm soát khi timeout dù đây là rủi ro chính của OPT-INT-WH-002 và lý do tồn tại của BR-INT-WH-002; phải thể hiện retry hoặc ghi rõ phạm vi luồng chỉ mô tả lần gửi thành công.; API->>Portal: Lưu trạng thái CONFIRMED không nêu khóa chống trùng hay ranh giới ghi dữ liệu; phải làm rõ Portal chỉ lưu sau khi kiểm tra hợp lệ và chưa xử lý tổ hợp nghiệp vụ.; Luồng không gắn yêu cầu xác thực API đang ở trạng thái Verification required; phải đánh dấu phụ thuộc chưa xác minh hoặc tránh tạo cảm giác giao diện đã đủ điều kiện vận hành.
assets/diagrams/12-api-and-integration-analysis-022-329a2d74.mmd — REVISE — Các cạnh BR --> API và DD --> API tạo quan hệ trung gian không được section xác nhận. Bảng mô tả CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là nguồn upstream mà chapter trực tiếp liên kết; sửa thành BR --> CH và DD --> CH.; TEMPLATE_MANIFEST bị gộp vào OUT như artifact downstream, trái với bảng mô tả đây là nguồn canonical dùng để xác định template được phép. Thêm node TEMPLATE_MANIFEST --> CH và bỏ "template" khỏi OUT.; Nhãn "Section 9" không có căn cứ trong phần prose được cung cấp và có thể sai khi cấu trúc chapter đổi. Bỏ nhãn này hoặc thay bằng tên section được nguồn canonical xác nhận.; OUT gộp requirement, acceptance criteria, test và template dù chúng có quan hệ khác nhau. Sau khi bỏ template, giữ nhóm downstream hoặc tách node nếu cần thể hiện nguồn canonical tương ứng.
assets/diagrams/12-api-and-integration-analysis-023-18207e19.mmd — REVISE — Nhãn “NEED đã đăng ký”, “REQ đã đăng ký”, “AC đã đăng ký” và “TC đã đăng ký” mâu thuẫn trực tiếp với trạng thái “Chưa đăng ký”. Cần thể hiện các loại artifact chưa có ID, không khẳng định đã đăng ký.; Nhãn “BR trong CANONICAL_BUSINESS_RULES” ngụ ý BR cụ thể đã tồn tại trong catalog, trong khi section chỉ xác nhận catalog canonical và nói rule cụ thể chưa được seed cấp. Cần phân biệt catalog tồn tại với BR cụ thể chưa đăng ký.; Nhãn “DATA/API trong CANONICAL_DATA_DICTIONARY” nhập nhằng giữa data dictionary canonical và API contract cụ thể. Section xác nhận dictionary tồn tại nhưng không xác nhận API ID, schema hoặc endpoint cụ thể. Cần thể hiện ranh giới này.; Các cạnh từ TRACEABILITY_ID_REGISTRY đến mọi node có thể bị hiểu là mọi artifact đã có ID được registry kiểm soát. Cần biểu đạt registry là nơi phải đăng ký trước khi liên kết, không phải bằng chứng đăng ký hiện tại.; Sơ đồ trình bày chuỗi truy vết như trạng thái đã thiết lập, bỏ mất điều kiện chỉ được liên kết sau khi có ID registry và xác nhận từ owner phù hợp. Cần thể hiện đây là chuỗi cần kiểm tra hoặc mô hình đích có điều kiện.; Sơ đồ không thể hiện ranh giới thẩm quyền: BA duy trì truy vết; Business Owner, Architect và QA Owner xác nhận nội dung tương ứng; chưa có approval. Thiếu ranh giới này làm luồng dễ bị hiểu là đã được xác nhận.; Sơ đồ gần như lặp lại các quan hệ trong bảng nhưng bỏ trạng thái governance, bằng chứng và hành động. Cần bổ sung giá trị giải thích riêng hoặc loại bỏ sơ đồ nếu không thể hiện rõ khoảng trống.
assets/diagrams/12-api-and-integration-analysis-024-702eb02b.mmd — REVISE — Nút REQ BR AC DATA/API TC phụ thuộc đưa vào các loại artifact không được phần văn xuôi xác nhận và thiếu động từ. Chỉ giữ phạm vi artifact phụ thuộc hoặc bổ sung văn xuôi định nghĩa các loại này.; Nút Record thay đổi theo Asia/Ho_Chi_Minh mơ hồ: múi giờ chỉ quy định cách ghi thời gian, không thể hiện version, lý do, phạm vi tác động và consumer bị ảnh hưởng. Nhãn phải nêu cụ thể nội dung cần ghi nhận; giữ múi giờ như điều kiện cho timestamp.; Luồng kết thúc sau khi ghi nhận thay đổi nhưng không thể hiện cập nhật bằng chứng kiểm tra, trong khi văn xuôi coi đây là điều kiện an toàn. Phải thêm bước hoặc kết quả cập nhật bằng chứng kiểm tra.; Sơ đồ có thể khiến người đọc hiểu hoàn tất luồng đồng nghĩa với baseline hoặc approval. Phải thể hiện rõ kết quả không tự động mang nghĩa phê duyệt, hoặc đặt chú thích giới hạn này cạnh sơ đồ.
assets/diagrams/12-api-and-integration-analysis-025-22dc01da.mmd — REVISE — Tên "Nova Foods ERP" và "Kho WMS mô phỏng" không được phần văn xuôi xác lập. Cần thay bằng actor đã được định nghĩa trong ngữ cảnh hoặc bổ sung nguồn xác nhận actor.; Endpoint POST /shipments, trường shipmentId, phản hồi 202 Accepted và cơ chế callback đều là chi tiết chưa được phần văn xuôi hỗ trợ. Cần dẫn chiếu contract hoặc loại bỏ chi tiết chưa có căn cứ.; Nhãn "Callback trạng thái xử lý" mơ hồ: thiếu endpoint, trạng thái cụ thể, owner gọi callback và phản hồi của ERP. Cần mô tả interface và outcome có thể kiểm tra.; Bước kiểm tra shipmentId không thể hiện hai kết quả "đã xử lý" và "chưa xử lý". Cần thêm nhánh thể hiện hành vi chống trùng và trạng thái trả về cho từng trường hợp.; Luồng chỉ thể hiện happy path. Cần thể hiện hoặc dẫn chiếu các nhánh lỗi quan trọng được phần văn xuôi yêu cầu: xác thực, dữ liệu sai, timeout, trùng lặp, retry và phục hồi.; Sơ đồ không xác định trigger, nguồn chân lý, owner trạng thái đồng bộ hoặc điều kiện hoàn tất. Cần làm rõ các boundary và ownership này nếu sơ đồ nhằm minh họa hợp đồng tích hợp.
assets/diagrams/12-api-and-integration-analysis-026-817a718d.mmd — REVISE — Luồng gửi lại dùng same idempotency key, nhưng yêu cầu POST ban đầu chỉ ghi sourceTransactionId; cần thể hiện idempotency key được gửi từ yêu cầu đầu tiên.; Retry once thêm giới hạn số lần thử không có trong phần văn bản; cần bỏ once hoặc bổ sung quy tắc này trong văn bản.; API-->>ERP: Timeout mô tả timeout như phản hồi từ Partner API; cần biểu diễn đây là sự kiện phía ERP khi không nhận được phản hồi.; Mark reconciled thêm trạng thái và hành động nghiệp vụ không được phần văn bản xác lập; cần dùng kết quả được hỗ trợ trực tiếp, như không gửi lại sau khi xác nhận bên nhận đã xử lý.; Nova Foods ERP, shipment, và trạng thái Processed/Not found là chi tiết cụ thể không được đoạn văn xung quanh hỗ trợ; cần thay bằng vai trò, yêu cầu và kết quả trung tính hoặc bổ sung ngữ cảnh xác lập các chi tiết này.
assets/diagrams/12-api-and-integration-analysis-027-99970f2c.mmd — REVISE — Nút Nhu cầu nghiệp vụ không nối tới Traceability record, trái yêu cầu nối nhu cầu, dữ liệu, quy tắc, API, kiểm thử và nguồn canonical. Bổ sung quan hệ truy vết từ nhu cầu.; Chuỗi Quy tắc canonical → Dữ liệu canonical → OpenAPI contract thể hiện phụ thuộc tuần tự mà phần văn bản không xác lập. Chỉ giữ quan hệ có căn cứ hoặc biểu diễn các artifact cùng liên kết với bản ghi truy vết.; Nhãn Test basis mơ hồ và không song song ngôn ngữ với các nhãn còn lại. Đổi thành nhãn tiếng Việt cụ thể, như Cơ sở kiểm thử, phù hợp nội dung phần.; Sơ đồ không thể hiện nguồn canonical cụ thể gồm CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY, nên làm yếu thông điệp không tự tạo ID. Gắn các artifact canonical liên quan hoặc làm rõ chúng trong nhãn.
assets/diagrams/12-api-and-integration-analysis-028-6685f579.mmd — REVISE — Luồng tuyến tính ngụ ý mọi bằng chứng đều đủ để đi đến quyết định. Cần thể hiện nhánh đánh giá chất lượng bằng chứng: bằng chứng đủ hỗ trợ khuyến nghị; bằng chứng yếu dẫn đến câu hỏi, nêu rủi ro và trạng thái Verification required.; Sơ đồ bỏ qua trade-off giữa các phương án tích hợp. Cần thể hiện bước so sánh phương án theo độ trễ, tải hệ thống, retry, xử lý trùng, tính khả dụng và hậu quả nghiệp vụ trước khi owner quyết định.; Nhãn Owner có thẩm quyền quá chung và che ranh giới thẩm quyền. Cần phân biệt Business Owner, Architect, Security Owner, Accounting Owner hoặc Legal Owner theo loại quyết định.; Sơ đồ ngụ ý owner luôn có thể ra quyết định ngay. Cần thể hiện escalation khi thiếu contract, xung đột data ownership, thiếu xác minh pháp lý hoặc lỗi có hậu quả nghiêm trọng.; Nhãn Quyết định ghi trong artifact không phân biệt Decision đã được phê duyệt với khuyến nghị, giả định, IN_REVIEW hoặc Verification required. Cần thể hiện trạng thái và mức chắc chắn.; Nhãn Bằng chứng thiếu tiêu chí nguồn, quyền sử dụng, khả năng kiểm soát và độ tin cậy. Cần làm rõ bằng chứng được đánh giá, không chỉ được thu thập.; Sơ đồ gần như lặp lại nguyên văn chuỗi khái niệm trong đoạn mở đầu, nên chưa tạo giá trị giải thích riêng. Cần trực quan hóa nhánh quyết định, ngoại lệ, ownership hoặc vòng xác minh mà prose mô tả.
assets/diagrams/12-api-and-integration-analysis-029-b5d273a6.mmd — REVISE — "Ghi khoảng trống và escalation" introduces actions not stated in surrounding prose; remove them or support them in prose.; "Quality gate theo owner" invents both gate and owner absent from surrounding prose; remove it or define gate and responsible owner in prose.; No-template branch omits supported critical outcome: do not invent template IDs or infer completed-artifact filenames. Show this prohibition as branch outcome.; "Tham chiếu TEMPLATE_MANIFEST" is incomplete because manifest is only planning evidence with status IN_REVIEW, not registered API-specific template source. Make limitation explicit.
assets/diagrams/12-api-and-integration-analysis-030-45c69fa2.mmd — REVISE — Gateway E thiếu điều kiện trạng thái. Prose yêu cầu đồng thời xác minh đúng ID, filename và trạng thái trong manifest; sửa điều kiện để gồm đủ ba tiêu chí.; Gateway E dùng “đường dẫn canonical” nhưng prose kết luận chưa có filename hoặc artifact ID được xác minh và quy tắc tra cứu nêu filename, không chỉ đường dẫn. Dùng đúng thuật ngữ canonical: ID, filename và trạng thái.; Bước B ghi “manifest và registry” quá mơ hồ. Cần chỉ rõ TEMPLATE_MANIFEST xác minh filename và trạng thái, còn TRACEABILITY_ID_REGISTRY xác minh canonical ID.; Bước C “Đối chiếu rule, data, source” dùng nhãn rộng, không nêu đối tượng hoặc tiêu chí đối chiếu. Cần gắn với canonical business rules, data dictionary và source map hoặc bỏ bước nếu không thuộc quyết định liên kết artifact.; Nhánh “Có” chưa thể hiện chỉ liên kết khi cả ba điều kiện cùng đạt; nhánh “Không” chưa nói thiếu bất kỳ điều kiện nào đều giữ Verification required.
assets/diagrams/13-process-design-workflows-and-approvals-001-034fc648.mmd — REVISE — Nhãn "Actor thực hiện action" và "Object thay đổi" quá trừu tượng, đồng thời trộn actor, action, object và outcome; cần dùng ví dụ cụ thể trong prose để từng thành phần nhận diện độc lập.; Gateway "Điều kiện workflow" không nêu điều kiện được kiểm tra; hai nhánh "Đạt" và "Không đạt" vì vậy không thể kiểm chứng. Cần ghi tiêu chí quyết định cụ thể và dùng nhãn nhánh song song.; Nhánh thành công chỉ ghi "trạng thái tiếp theo", không thể hiện chuyển trạng thái từ PENDING_APPROVAL sang APPROVED như prose.; Nhánh từ chối gộp "chặn hoặc từ chối" dù đây có thể là hai outcome khác nhau; cần tách hoặc xác định chính xác outcome.; Luồng approval thiếu người hoặc vai trò ra quyết định và thiếu bằng chứng phải lưu như người duyệt, thời điểm duyệt; omission làm sơ đồ không phản ánh đầy đủ phạm vi section.
assets/diagrams/13-process-design-workflows-and-approvals-002-cd47a13c.mmd — REVISE — Quan hệ Outcome → Status không khớp định nghĩa: Outcome đã có thể là trạng thái hoặc đầu ra, còn Status là nhãn giai đoạn của Object. Cần bỏ quan hệ này hoặc thể hiện Status như một loại Outcome hay trạng thái của Object.; Nhãn “tạo hoặc đổi” thiếu đối tượng bị tạo hoặc thay đổi, nên không đáp ứng công thức Actor–Action–Object–Outcome. Cần dùng quan hệ cụ thể, nêu rõ Action tạo Outcome hoặc làm Object chuyển trạng thái.; Sơ đồ gần như lặp lại công thức đọc tối thiểu trong văn bản, chưa bổ sung quan hệ hay cách đọc mới. Cần tạo giá trị giải thích rõ hơn thay vì sao chép tuyến tính.; Chuỗi hiện tại có thể bị đọc thành Actor tác động lên Object, Object tự tạo Outcome, rồi Outcome tự tạo Status; cách đọc này làm sai chủ thể hành động. Cần giữ Actor gắn với Action và thể hiện Outcome là kết quả của hành động trên Object.
assets/diagrams/13-process-design-workflows-and-approvals-003-019a00ee.mmd — REVISE — Nhãn "Gửi duyệt" thiếu actor, trong khi phần prose xác định Người tạo/Nhân viên kho thực hiện bước này. Cần ghi rõ "Nhân viên kho gửi duyệt" để ownership nhất quán và tránh hiểu Quản lý kho hoặc hệ thống thực hiện.
assets/diagrams/13-process-design-workflows-and-approvals-004-9279b544.mmd — REVISE — Nhãn “Người tạo sửa và gửi lại” gộp hai hành động nhưng chuyển thẳng từ Rejected về Draft. “Gửi lại” phải đưa yêu cầu sang PendingApproval. Sửa nhãn Rejected --> Draft thành “Người tạo sửa yêu cầu”; giữ Draft --> PendingApproval cho hành động gửi.; Luồng không thể hiện yêu cầu bị từ chối có thể kết thúc hay chỉ bắt buộc sửa và gửi lại. Phần prose yêu cầu làm rõ khi nào yêu cầu kết thúc. Cần xác nhận quy tắc nghiệp vụ và thêm nhánh kết thúc nếu yêu cầu có thể bị hủy hoặc đóng; không tự suy diễn nhánh này.
assets/diagrams/13-process-design-workflows-and-approvals-005-9838f0cb.mmd — REVISE — Nhãn người tạo sửa và gửi lại không khớp đích DRAFT: gửi lại phải chuyển sang PENDING_APPROVAL; đổi nhãn thành người tạo sửa hoặc thêm bước gửi lại riêng.; Luồng thiếu điều kiện trọng yếu ngăn người tạo tự phê duyệt; bổ sung guard hoặc ghi rõ người phê duyệt phải khác người tạo trên hai chuyển trạng thái từ PENDING_APPROVAL.; Luồng chưa thể hiện quyền sửa sau khi gửi, dù đây là rủi ro được nêu trong Facts và phần trước thiết kế; bổ sung quy tắc khóa sửa tại PENDING_APPROVAL hoặc nhánh sửa có kiểm soát phù hợp quyết định nghiệp vụ.; APPROVED --> [*]: đủ điều kiện tạo đơn mua dùng trạng thái kết thúc để biểu diễn điều kiện tích hợp, dễ gây hiểu rằng tạo đơn mua kết thúc vòng đời yêu cầu; thể hiện rõ đây là điều kiện cho hành động tạo đơn mua, không phải hành động đã xảy ra.
assets/diagrams/13-process-design-workflows-and-approvals-006-69dbd487.mmd — REVISE — Nhánh “Có nguồn kiểm tra được?” gán thẳng “Verified fact”, nhưng section yêu cầu nguồn canonical và cảnh báo tài liệu IN_REVIEW không phải baseline hoặc approval. Sửa điều kiện để phân biệt nguồn kiểm tra được với nguồn canonical đã được xác nhận.; Gateway “Có lựa chọn do authority ghi nhận?” không nêu authority nào có thẩm quyền. Sửa nhãn hoặc nhánh để thể hiện Business Owner, Accounting Owner và Legal Owner xác nhận đúng phạm vi; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability.; Các trạng thái Stakeholder input, Project assumption và Verification required đều có thể đi thẳng tới Decision, làm mờ yêu cầu xác minh và nguy cơ biến assumption thành decision. Sửa luồng để Decision chỉ xuất hiện sau xác nhận có thẩm quyền và bằng chứng phù hợp.; Nhánh từ Verification required tới gateway quyết định ngụ ý nội dung chưa xác minh vẫn có thể thành Decision chỉ vì authority “ghi nhận”. Thêm bước xác minh hoặc kết quả giữ trạng thái chờ xác minh trước khi xét quyết định.; Sơ đồ bỏ sót ranh giới quan trọng: không đặt ngưỡng VND, không tạo mandatory rule và giữ trạng thái IN_REVIEW Version v0.9.0. Thể hiện kết quả áp dụng hoặc giới hạn này để tránh diễn giải sai.; Nhãn “authority” và “Có lựa chọn” mơ hồ, không nói ai thực hiện hành động, lựa chọn nào được ghi nhận hoặc bằng chứng nào đủ. Dùng nhãn chủ động, cụ thể và song song.
assets/diagrams/13-process-design-workflows-and-approvals-007-ac378066.mmd — REVISE — Sơ đồ bỏ toàn bộ entry gate dù phần Core xác định mỗi pha có entry gate và exit gate. Cần thể hiện điều kiện vào tối thiểu cho từng pha hoặc chỉ rõ sơ đồ chỉ mô tả lifecycle, không mô tả đầy đủ gate.; Nhãn Exit: input phân loại mơ hồ và thiếu yêu cầu Discovery: stakeholder input phải được phân biệt với verified fact, chưa gọi là rule hoặc decision. Cần dùng tiêu chí exit cụ thể này.; Nhãn Exit: luồng và criteria kiểm tra được không khớp exit gate của Analysis: workflow draft phải có, còn business rule, data và authority chưa xác minh phải giữ nhãn Verification required hoặc Project assumption. Cần phản ánh cả bằng chứng và trạng thái chưa xác minh.; Nhãn Exit: thực thi được làm sai nghĩa exit gate của Delivery. Build hoặc cấu hình chỉ cần có thể trình diễn theo workflow draft; thay đổi thiết kế phải được ghi nhận. Cần thay bằng tiêu chí đó.; Nhãn Exit: kết quả test ghi nhận bỏ điều kiện pass, fail, blocked và việc phân loại lỗi ảnh hưởng gate trước Release. Cần nêu kết quả có trạng thái và lỗi gate đã được phân loại.; Nhãn Exit: phạm vi phát hành ghi nhận không thể hiện bản phát hành mô phỏng đã được ghi nhận và ranh giới không suy diễn production approval hoặc compliance sign-off. Cần làm rõ outcome và boundary.; Nút Operations chỉ ghi Theo dõi vận hành, bỏ các tín hiệu cụ thể gồm volume, thời gian xử lý, exception, rework và phản hồi người dùng. Cần dùng nhãn cụ thể hơn nếu sơ đồ nhằm tóm tắt hoạt động pha.; Vòng lặp Sai lệch hoặc nhu cầu mới đúng hướng nhưng bỏ outcome bắt buộc: tạo input Discovery mới và không tự sửa business rule trong Operations. Cần thể hiện ranh giới này.
assets/diagrams/13-process-design-workflows-and-approvals-008-a0ce59a7.mmd — REVISE — Bàn giao thiết kế chỉ đi từ BA đến Solution Architect, bỏ Security Owner dù bảng xác định cả hai là downstream owner. Cần thể hiện Security Owner nhận workflow, decision log và traceability để đánh giá bảo mật.; Bước cấu hình/xây dựng bỏ Delivery Lead khỏi upstream ownership. Cần thể hiện Delivery Lead cùng Solution Architect bàn giao thiết kế đã review và backlog cho Delivery team.; Nhánh escalation từ BA đến nút gộp "Legal / Accounting / Security Owner" gây sai quyền sở hữu: bảng yêu cầu Architect hoặc Security Owner cho thay đổi tích hợp, phân quyền và dữ liệu nhạy cảm; Business Owner cho mục tiêu, ngân sách, rule và phạm vi; owner chuyên môn phù hợp cho pháp lý, kế toán, an toàn thực phẩm. Cần tách escalation theo điều kiện và đúng owner.; Luồng kiểm thử không thể hiện acceptance criteria trong artifact bàn giao, cũng không thể hiện escalation lỗi rule, số tiền VND mô phỏng hoặc quyền approval đến Business Owner và BA. Cần bổ sung artifact và nhánh ngoại lệ này.; Luồng phát hành bỏ rủi ro còn lại khỏi bàn giao và không thể hiện Operations Owner có quyền quyết định vận hành trong phạm vi được giao. Cần nêu rõ artifact, giới hạn quyền và escalation rủi ro production, rollback hoặc dữ liệu đến Release Manager và Operations Owner.; Nhãn "Rule cần xác nhận" và "Escalation" thiếu điều kiện, artifact và phạm vi quyết định. Cần dùng nhãn cụ thể, nhất quán với các trường hợp escalation trong bảng.; Luồng vận hành quay thẳng từ Operations Owner về BA, bỏ Business Owner là downstream đồng nhận và không thể hiện BA chỉ đề xuất thay đổi, không tự đổi rule. Cần thể hiện cả hai owner và giới hạn quyền.
assets/diagrams/13-process-design-workflows-and-approvals-011-65087eae.mmd — REVISE — Nút S ghi "Dừng: thiếu định danh canonical" nhưng nhận cả nhánh thiếu nguồn/owner và nguồn chưa được kiểm tra lại. Tách trạng thái dừng theo đúng lý do.; Nhánh "Kiểm tra lại nguồn" luôn dẫn đến dừng. Thêm kết quả kiểm tra lại: đạt thì tiếp tục, không đạt thì dừng hoặc giữ VERIFICATION_REQUIRED và không dùng làm kết luận.; Thiếu kiểm tra phạm vi và nhánh từ chối suy rộng sang pháp lý, kế toán hoặc production.; Thiếu kiểm tra truy vết trước kết quả cuối. Phải xác nhận ID hoặc tham chiếu canonical đã đăng ký và không mâu thuẫn; nếu không thì dừng liên kết.; Gateway "Thuộc thẩm quyền BA?" thu hẹp sai điều kiện "owner có đúng loại quyết định". Đổi thành kiểm tra thẩm quyền của owner và thể hiện escalation tới Business Owner, Legal Owner, Accounting Owner, Architect, Security hoặc QA theo loại quyết định.; Kết quả "Dùng làm evidence có truy vết" khẳng định truy vết dù sơ đồ chưa kiểm tra registry hoặc mâu thuẫn ID.; Sơ đồ chưa thể hiện phân loại nguồn PRIMARY_OFFICIAL, CONTROLLED_CORPUS, PROJECT_ASSUMPTION, VERIFICATION_REQUIRED, dù đây là cơ chế cốt lõi quyết định mức thẩm quyền và giới hạn sử dụng.
assets/diagrams/13-process-design-workflows-and-approvals-012-a8c29d92.mmd — REVISE — Diagram restates table categories and verification label without adding relationships, decision logic, provenance boundaries, or review flow; remove diagram or replace it with visual showing supported source-to-verification logic.; Labels "Artifact canonical," "Nguồn chuẩn hoặc pháp lý," and "Bằng chứng Nova Foods tổng hợp" are broad and not fully parallel; use concrete, parallel source-category labels matching table classifications.; Flow into "Bảng đầu vào workflow" implies all rows fit only three source groups, but table also includes corpus metadata, document status, identifier registry, business-rule catalog, data dictionary, BA guidance, and process-modeling guidance; represent these supported categories or avoid misleading aggregation.; Outcome shows only "VERIFICATION REQUIRED," while table also records verified metadata and unresolved items without that status; show both supported verification outcomes and preserve unresolved-item distinction.; Diagram adds no owner, review boundary, dependency, condition, or consequence beyond nearby prose, making it decorative rather than explanatory.
assets/diagrams/13-process-design-workflows-and-approvals-013-47d5e508.mmd — REVISE — DRAFT --> CANCELLED và SUBMITTED --> CANCELLED gán quyền hủy cho Requester, nhưng bảng thực thi không xác định quyền, điều kiện hoặc bằng chứng hủy. Bổ sung nguồn hỗ trợ trong prose hoặc bỏ các chuyển trạng thái này.; DRAFT --> SUBMITTED: đủ trường bắt buộc thiếu actor và điều kiện quyền quan trọng: Requester gửi yêu cầu do mình tạo. Nhãn cần thể hiện hành động của Requester cùng điều kiện hợp lệ.; SUBMITTED --> IN_REVIEW chỉ bao phủ trường hợp tổng vượt 20.000.000 VND; không thể hiện kết quả khi tổng bằng hoặc thấp hơn ngưỡng. Cần nêu nhánh còn lại hoặc xác định rõ sơ đồ chỉ mô tả riêng PR-2026-0817.; IN_REVIEW --> APPROVED: Trưởng mua hàng chấp nhận mơ hồ và bỏ điều kiện quyết định trong bảng: thông tin đủ, nhu cầu hợp lệ theo quy tắc đã được Business Owner xác nhận. Nhãn cần dùng điều kiện cụ thể.; IN_REVIEW --> REJECTED: ghi lý do từ chối không nêu Trưởng mua hàng là actor quyết định. Cần giữ actor và yêu cầu lý do từ chối trong cùng nhãn.; PURCHASE_ORDER_CREATED được trình bày như trạng thái workflow dù danh sách trạng thái chuẩn chỉ gồm DRAFT, SUBMITTED, IN_REVIEW, APPROVED, REJECTED, CANCELLED. Cần phân biệt đây là outcome/event tạo đơn mua, không phải trạng thái PR, hoặc có prose xác nhận nó là trạng thái.
assets/diagrams/13-process-design-workflows-and-approvals-014-a8f425f8.mmd — REVISE — TR-PR-001 chỉ nhận liên kết từ WF-PR-001, DT-PR-001 và RM-PR-001, nên không thể hiện nguồn nhu cầu và rule mà prose yêu cầu truy vết. Bổ sung node nguồn đầu vào và liên kết tới TR-PR-001.; Workflow activity là nhãn mơ hồ và các cạnh hiện tại ngụ ý hoạt động chỉ trực tiếp tạo ba artifact đầu, dù section xác định cả năm artifact là output được tạo hoặc cập nhật. Làm rõ phạm vi node hoặc quan hệ tạo/cập nhật mà không biến dependency thành trình tự quy trình.; Cạnh RM-PR-001 tới TR-PR-001 chưa được prose mô tả cụ thể trong nội dung tối thiểu của traceability matrix. Chỉ giữ cạnh nếu section xác định responsibility linkage cần truy vết; nếu không, bỏ cạnh.
assets/diagrams/13-process-design-workflows-and-approvals-015-fa376ff3.mmd — REVISE — Nhánh “Có” chỉ dừng ở trạng thái “Chờ Trưởng phòng Mua hàng xử lý”, thiếu hành động phê duyệt, gateway kết quả và các outcome phê duyệt/từ chối; bổ sung luồng quyết định cùng kết quả tương ứng.; Nhánh “Không” đi thẳng tới “Quyết định được ghi nhận” dù không có quyết định nào được thực hiện; đổi trạng thái hợp nhất thành outcome áp dụng cho cả hai nhánh hoặc không hợp nhất hai luồng.; Ngưỡng “50.000.000 VND”, vai trò “Trưởng phòng Mua hàng” và bước “đặt hàng” không được prose xác lập; thêm nguồn/quy tắc hỗ trợ trong nội dung hoặc loại khỏi sơ đồ.; Các bước “Kiểm tra tổng tiền”, “Chuyển sang bước đặt hàng” và “Quyết định được ghi nhận” thiếu owner; gắn actor khi ownership ảnh hưởng handoff hoặc trách nhiệm.; Sơ đồ bỏ ngoại lệ và ranh giới phạm vi nhưng prose coi đây là anatomy tối thiểu; thể hiện ngoại lệ quan trọng, điểm kết thúc và handoff hoặc ghi rõ chúng không áp dụng trong ví dụ.
assets/diagrams/13-process-design-workflows-and-approvals-016-5d50a56d.mmd — REVISE — IN_REVIEW --> [*]: chuyển downstream review mâu thuẫn luồng: vào IN_REVIEW đã là chuyển sang downstream review. Sửa nhãn hoặc trạng thái kết thúc để thể hiện kết quả review được prose hỗ trợ; nếu section không định nghĩa kết quả đó, bỏ transition.; Draft --> Draft: thiếu bằng chứng hoặc traceability chỉ bao phủ hai trong sáu điều kiện bắt buộc và làm sai lệch các nhánh thất bại còn lại như sai định danh, phạm vi chưa rõ, vượt thẩm quyền và dữ liệu không an toàn. Sửa điều kiện để bao quát mọi trường hợp không đạt cổng chất lượng hoặc thể hiện đầy đủ từng kết quả.; Draft --> IN_REVIEW: đủ cổng chất lượng chưa cụ thể. Sửa thành điều kiện concrete, như đạt tất cả điều kiện bắt buộc của cổng chất lượng.; IN_REVIEW --> Draft: reviewer phát hiện lỗi gom mọi kết quả review thành quay lại Draft, nhưng section chỉ mô tả hậu quả khi không đạt cổng trước review, không định nghĩa workflow xử lý lỗi trong review. Bỏ transition hoặc bổ sung prose hỗ trợ trước khi giữ.; Diagram thiếu boundary quan trọng: cổng chất lượng không xác nhận approval, baseline, tuân thủ pháp lý, cấu hình ERP hay production readiness. Thể hiện boundary này trong visual nếu diagram tiếp tục mô tả ý nghĩa cổng.
assets/diagrams/13-process-design-workflows-and-approvals-017-0da7a052.mmd — REVISE — Nút "PM/Product Owner: ưu tiên và phạm vi" đưa vào actor và trách nhiệm không được phần văn xuôi xác lập. Loại bỏ nút hoặc bổ sung căn cứ trong prose.; Nút "BA output" mơ hồ về chủ thể và thẩm quyền, dễ ngụ ý BA sở hữu quyết định. Làm rõ đây là gói output liên kết do Principal IT Business Analyst / Technical Curriculum Author duy trì traceability, không thay thế Business Owner, Architect, QA hoặc Specialist owner.; Các mũi tên không có nhãn nên không phân biệt quan hệ tiêu thụ output, bàn giao hay phê duyệt. Gắn nhãn quan hệ đúng theo prose; không thể hiện các actor như cùng nhận một loại quyền quyết định.; Nhãn "rule" không cụ thể và không song song ngôn ngữ với các thành phần còn lại. Dùng "quy tắc nghiệp vụ" để khớp Decision và artifact canonical.; Sơ đồ chỉ thể hiện phân phối một chiều, bỏ mất ranh giới thẩm quyền trọng yếu giữa Business Owner, Architect, QA, Specialist owner và vai trò traceability của BA. Bổ sung ranh giới này hoặc thu hẹp sơ đồ để không ngụ ý BA là nguồn canonical duy nhất.; Sơ đồ không thể hiện liên kết giữa luồng quy trình, quy tắc nghiệp vụ, từ điển dữ liệu và acceptance criteria dù đây là trọng tâm của Decision. Thể hiện quan hệ liên kết hoặc sơ đồ còn là bản liệt kê consumer.
assets/diagrams/13-process-design-workflows-and-approvals-018-e595ad13.mmd — REVISE — Gateway chỉ kiểm tra "trong thẩm quyền" nhưng bảng còn yêu cầu escalation khi thiếu bằng chứng, quy tắc mơ hồ, không có owner xác nhận, có rủi ro hoặc vượt các ngưỡng cụ thể. Cần thể hiện đầy đủ điều kiện escalation hoặc đổi gateway để bao quát cả thẩm quyền, bằng chứng và rủi ro.; Nhãn "owner chuyên môn" thu hẹp sai đích escalation. Đích có thể là Architect, PM/Product Owner, Business Owner hoặc Specialist owner tùy vấn đề. Cần dùng nhãn owner có thẩm quyền phù hợp hoặc thể hiện định tuyến theo loại vấn đề.; Nhánh E --> R bỏ qua bước owner được escalation xem xét và ra quyết định. Cần thể hiện quyết định thuộc owner có thẩm quyền trước khi ghi quyết định và traceability.; Kết quả Ghi quyết định và traceability có thể bị hiểu là phê duyệt hoặc baseline, trái giới hạn IN_REVIEW. Cần ghi rõ quyết định vẫn thuộc đầu ra review, không phải phê duyệt, baseline, cấu hình ERP hoặc chỉ dẫn production.
assets/diagrams/13-process-design-workflows-and-approvals-019-d6363160.mmd — REVISE — Thiếu trạng thái Verification required giữa lúc BA ghi câu hỏi và lúc các owner trả lời; bổ sung trạng thái này để thể hiện quyết định kiểm soát suy diễn.; Nhãn Quy tắc đã rõ có nguồn gộp ý nghĩa nghiệp vụ, ảnh hưởng kế toán và vị trí thực thi thành một loại quy tắc; đổi nhãn hoặc tách kết quả để không biến quyết định kiến trúc thành quy tắc nghiệp vụ.; Thiếu bước ghi câu trả lời cùng nguồn, owner và trạng thái vào artifact kiểm soát; bổ sung trước khi chuyển kết quả thành test basis hoặc thiết kế kỹ thuật.; Thiếu liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; bổ sung các dependency canonical được Artifact yêu cầu.
assets/diagrams/13-process-design-workflows-and-approvals-020-6dac2e3c.mmd — REVISE — Thứ tự A → B mâu thuẫn dấu thời gian: ERP được tra lúc 16:35, còn số 1.164 chai được hai nhân viên đếm lại lúc 16:42. Cần thể hiện tra ERP trước bước đếm lại.; Nhãn “Nhân viên kho đếm 1.164 chai” dùng số ít, trong khi bảng fact xác nhận hai nhân viên kho đếm lại. Cần sửa actor thành hai nhân viên kho hoặc nêu đúng hai ID nếu cần.; Sơ đồ chưa phân biệt lần kiểm đếm phát hiện ban đầu với lần đếm lại lúc 16:42. Cần gắn số 1.164 chai với bước đếm lại để tránh suy diễn sai sự kiện.
assets/diagrams/13-process-design-workflows-and-approvals-021-68546cbb.mmd — REVISE — Nhánh quyết định bỏ bước nhập lý do bắt buộc của BR-NF-CREDIT-002 và phần payload. Cần thể hiện Finance Manager chọn quyết định và nhập decisionReason trước khi hoàn tất APPROVED hoặc REJECTED.; CREDIT_REJECTED được trình bày như trạng thái đơn nhưng không được định nghĩa trong bảng quy tắc, ma trận trạng thái hay prose. Cần dùng kết quả REJECTED đã được hỗ trợ hoặc bổ sung định nghĩa trạng thái ngoài sơ đồ trước khi dùng.; Chuyển sang RELEASED sau phê duyệt chưa được quy tắc nào xác định rõ; prose chỉ nói ERP tự chuyển trạng thái và đưa đơn trở lại luồng kho. Cần xác nhận RELEASED là trạng thái đích trong STM-NF-SO-001 hoặc dùng trạng thái đã được xác định rõ.; Sơ đồ không thể hiện bản ghi quyết định phải lưu người quyết định, thời điểm và lý do theo DC-02. Cần thể hiện cập nhật APR-NF-CREDIT-001 trước khi đơn tiếp tục hoặc kết thúc luồng.
assets/diagrams/13-process-design-workflows-and-approvals-022-2afc3fdf.mmd — REVISE — Nhánh ngân sách không đủ vẫn đi đến APPROVED_FOR_PO và cho Buyer tạo PO, trái BR-NF-APP-002. Sau khi đủ hai phê duyệt, nhánh Không phải kết thúc ở trạng thái chặn PO do thiếu 228.000.000 VND; chỉ nhánh ngân sách đủ mới được đến APPROVED_FOR_PO.; Hai nhánh Có và Không của cổng ngân sách hội tụ ngay vào cùng trạng thái, làm điều kiện ngân sách mất tác dụng. Giữ kết quả ngân sách đến quyết định phát hành PO hoặc kiểm tra lại ngân sách trước APPROVED_FOR_PO.; Sơ đồ trình bày luồng như quy trình đã được phép áp dụng, trong khi workflow và hai quy tắc còn IN_REVIEW, chưa có Authorized Decision. Gắn rõ Proposed / IN_REVIEW v0.9.0 trong sơ đồ.; Nhãn Finance Manager approve? và Plant Director approve? trộn tiếng Anh với nội dung tiếng Việt. Đổi thành nhãn cụ thể, song song như Finance Manager phê duyệt? và Plant Director phê duyệt?.
assets/diagrams/13-process-design-workflows-and-approvals-023-f70abd4c.mmd — REVISE — Diagram names BR-NF-APP-002, but surrounding section supports only BR-NF-APP-001. Remove unsupported ID or add canonical prose evidence outside diagram.
assets/diagrams/13-process-design-workflows-and-approvals-024-6cbc6f23.mmd — REVISE — Nút gộp AC-NF-AP-001 đến AC-NF-AP-003 và TC-NF-AP-001 đến TC-NF-AP-003 che mất ánh xạ một-một giữa từng AC và TC trong bảng. Tách từng AC, TC hoặc ghi rõ ba cặp liên kết.; Cạnh API --> TC ngụ ý API-NF-AP-001 phụ thuộc hoặc liên kết với cả ba test case, trong khi bảng chỉ gắn API với AC-NF-AP-003 và TC-NF-AP-003. Giới hạn cạnh API vào luồng AC-NF-AP-003–TC-NF-AP-003.; Cạnh DATA --> API không thể hiện điều kiện chỉ đề nghị hợp lệ mới được gửi. Thể hiện quan hệ qua AC-NF-AP-003 hoặc gắn nhãn điều kiện hợp lệ để tránh hiểu rằng có supplier_id là đủ cho mọi lần gọi API.
assets/diagrams/13-process-design-workflows-and-approvals-025-6d58c991.mmd — REVISE — Nhánh CANONICAL_BUSINESS_RULES → Báo cáo kiểm soát không được phần văn bản giải thích hoặc minh họa; cần bỏ nhánh hoặc bổ sung nội dung nguồn hỗ trợ.; Quan hệ CANONICAL_DATA_DICTIONARY → Quy trình phê duyệt không được ví dụ hoặc lập luận cụ thể hỗ trợ; cần bỏ quan hệ hoặc giải thích dữ liệu định nghĩa cách workflow định tuyến hay đánh giá phê duyệt.; Nhãn “Đặc tả API hoặc cấu hình” gộp hai artifact khác loại, trong khi văn bản chỉ nêu hợp đồng API; cần dùng artifact được phần văn bản hỗ trợ hoặc tách quan hệ nếu cả hai có căn cứ.; Nhãn “Yêu cầu và acceptance criteria” gộp hai artifact, làm mờ dependency mà test case dựa vào acceptance criteria cũ; cần tách hoặc đổi thành nhãn cụ thể phù hợp chuỗi lan truyền được mô tả.
assets/diagrams/13-process-design-workflows-and-approvals-026-0daac4bb.mmd — REVISE — Bước “ERP kiểm tra dữ liệu bắt buộc” và điều kiện “Thiếu dữ liệu/Đủ dữ liệu” chưa được phần prose xác lập; cần bỏ hoặc nêu rõ đây là giả định chờ xác minh.; Nhãn “Approver” không xác định vai trò chịu trách nhiệm, trái tiêu chí phải nêu rõ ai chịu trách nhiệm; cần dùng vai trò được Business Owner xác nhận hoặc ghi rõ vai trò này đang chờ xác minh.; Kết quả “Đơn sẵn sàng cho bước tiếp theo” còn mơ hồ, không cho Development và QA biết hành động nào được phép; cần nêu trạng thái hoặc hành động cụ thể đã được xác minh.; Sơ đồ không thể hiện ràng buộc ngăn ERP xuất hóa đơn khi rule chưa xác minh hoặc đơn bị từ chối; cần thể hiện rõ hai nhánh này không được dẫn tới xuất hóa đơn.; Phụ thuộc vào Accounting Owner để xác nhận tác động chứng từ bị bỏ sót; cần thể hiện điểm xác nhận này trước mọi kết quả liên quan đến hóa đơn hoặc chứng từ.
assets/diagrams/13-process-design-workflows-and-approvals-027-0fa37648.mmd — REVISE — Nhãn chuyển sang APPROVED chỉ yêu cầu “Có quyết định được ghi nhận”, không xác nhận quyết định phê duyệt đến từ vai trò có thẩm quyền. Cần nêu rõ quyết định phê duyệt hợp lệ của người có thẩm quyền.; Nhãn chuyển sang REJECTED không xác định người ra quyết định. Cần nêu rõ quyết định từ chối của vai trò có thẩm quyền để tránh ngụ ý mọi bản ghi từ chối đều hợp lệ.; Nhánh HOLD chưa thể hiện đầy đủ safe recovery boundary: dừng tự động hóa, giữ bằng chứng, không sửa đè lịch sử, không tự tuyên bố phê duyệt và chuyển cho vai trò có thẩm quyền. Cần biểu diễn các điều kiện hoặc hành động khôi phục trọng yếu này.; Chuyển HOLD --> IN_REVIEW chỉ nêu bổ sung dữ liệu và giữ audit trail, nhưng bỏ sót xử lý lỗi định tuyến và bàn giao cho vai trò có thẩm quyền. Cần nêu điều kiện quay lại phù hợp cho cả hai nguyên nhân vào HOLD.
assets/diagrams/13-process-design-workflows-and-approvals-028-777d611f.puml — REVISE — Gateway Threshold and authority verified? chỉ kiểm tra trạng thái xác minh, không kiểm tra giá trị đơn có đạt ngưỡng hay không. Thêm gateway riêng cho điều kiện áp dụng sau khi rule được xác minh, gồm nhánh cần duyệt và không cần duyệt.; Luồng đã xác minh mặc định đưa mọi đơn tới Route to named approver; điều này mâu thuẫn nhu cầu phân biệt đơn nào cần duyệt. Chỉ route đơn thỏa điều kiện rule.; Set request status to Rejected tạo trạng thái và kết quả nghiệp vụ chưa được section hoặc canonical artifact xác nhận. Đánh dấu kết quả này Verification required hoặc chỉ dùng trạng thái đã có bằng chứng.; Continue purchase workflow mơ hồ vì có thể biểu thị cả đơn được duyệt lẫn đơn không cần duyệt. Gắn nhãn kết quả cụ thể, song song cho từng nhánh.; named approver không nêu owner hoặc nguồn xác định approver. Liên kết bước route với authority/rule đã xác minh, không mặc nhiên biến chức danh chưa xác minh thành cấu hình workflow.; Sơ đồ không thể hiện traceability tới business rule và canonical data dù đây là decision criterion bắt buộc. Thêm tham chiếu rule ID và trường dữ liệu dùng để đánh giá ngưỡng sau khi các ID được xác nhận.
assets/diagrams/13-process-design-workflows-and-approvals-029-02ed4eaf.mmd — REVISE — Gateway “Có rule nguồn hoặc bằng chứng?” gộp mọi bằng chứng thành nhánh hợp lệ, trái phân loại mạnh, trung bình, yếu và mâu thuẫn. Cần phân biệt bằng chứng đủ làm cơ sở quyết định với bằng chứng cần xác minh hoặc escalation.; Nhánh “Có” dẫn thẳng tới owner quyết định, bỏ bước BA nêu facts, inference, unknowns, phương án và tiêu chí quyết định. Cần thể hiện bước chuẩn bị recommendation trước khi chuyển owner.; Gateway “Vấn đề thuộc thẩm quyền nào?” ngụ ý chỉ một thẩm quyền, trong khi section yêu cầu đồng quyết định hoặc xác nhận chéo như Business Owner với Accounting Owner. Cần hỗ trợ nhiều owner cho vấn đề giao thoa.; Danh sách thẩm quyền bỏ Data Owner dù bảng giao Data Owner quyền với trường hợp thiếu dữ liệu. Cần thêm nhánh Data Owner hoặc nhóm thẩm quyền bao phủ rõ vai trò này.; Nhãn hành động không song song: “quyết định” và “xác nhận” dùng lẫn nhưng section phân biệt thẩm quyền quyết định, xác nhận và approval. Cần dùng động từ phản ánh đúng vai trò, nhất quán giữa các nhánh.; Nhánh “Không” kết thúc ở “Không biến thành system rule” nhưng không chỉ ra yêu cầu xác minh, dữ liệu còn thiếu hoặc escalation khi nguồn mâu thuẫn. Cần thể hiện trạng thái chờ xác minh và đường xử lý bằng chứng mâu thuẫn.; Diagram bỏ luồng ngoại lệ có điều kiện, owner cấp quyền, thời hạn, bằng chứng và đối soát sau ngoại lệ. Vì section coi ngoại lệ là ranh giới kiểm soát trọng yếu, cần biểu diễn hoặc giới hạn rõ phạm vi diagram chỉ cho thay đổi workflow thông thường.
assets/diagrams/13-process-design-workflows-and-approvals-030-fe48b3e4.mmd — REVISE — Nhãn “Đủ để kết luận?” không nêu tiêu chí đủ bằng chứng hoặc mức chắc chắn; cần thể hiện rằng thiếu bằng chứng ngăn kết luận thành business rule nhưng không ngăn khuyến nghị có điều kiện.; Nhánh “Không” dẫn thẳng từ “Assumption hoặc Verification required” đến decision authority, bỏ bước lập reasoning bridge, nêu điều chưa biết, rủi ro nếu giả định sai và điều kiện thay đổi; cần bổ sung các kiểm soát này trước khi chuyển quyền quyết định.; “Assumption hoặc Verification required” gộp hai loại ghi nhận khác nhau thành lựa chọn mơ hồ; cần tách điều kiện dùng Assumption và trường hợp bắt buộc Verification required, nhất là pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc.; “Đúng decision authority” không phải hành động cụ thể và không chỉ rõ chủ thể; cần thể hiện Senior BA ghi nhận traceability, Business Owner quyết định chính sách, Accounting Owner xác nhận nội dung kế toán và Architect xác nhận giải pháp theo phạm vi.; Luồng ghi mọi kết quả vào artifact IN_REVIEW nhưng không thể hiện kết quả quyết định hoặc vòng cập nhật có truy vết sau xác minh; cần chỉ rõ artifact vẫn IN_REVIEW cho đến khi thẩm quyền xác nhận và thay đổi được ghi nhận.; Kết quả “Không gọi là approved hoặc baselined” chỉ diễn đạt điều cấm, chưa nêu trạng thái tích cực cần duy trì; cần dùng nhãn cụ thể như giữ IN_REVIEW khi chưa có approval hoặc baseline.
assets/diagrams/13-process-design-workflows-and-approvals-031-cfb1dc29.mmd — REVISE — Nút "Owner kiểm tra quality gate" tự thêm actor và bước kiểm tra không được đoạn văn xác lập. Xóa nút này hoặc bổ sung căn cứ trong prose về owner, quality gate và trách nhiệm kiểm tra.; Luồng "Dùng đúng template registered" mô tả nhánh giả định dù trạng thái hiện tại đã xác định compact dependency chưa cung cấp ID và filename. Cần thể hiện rõ đây là điều kiện tương lai hoặc chỉ mô tả kết quả hiện tại: không tạo ID hay filename mới.; Kết quả "Artifact giữ IN_REVIEW" nhập nhằng đối tượng. Prose chỉ xác nhận TEMPLATE_MANIFEST đang IN_REVIEW; không chứng minh Chapter 13 content hay template artifact phải giữ trạng thái đó sau quality gate. Đổi nhãn thành trạng thái cụ thể của TEMPLATE_MANIFEST và không trình bày nó như hệ quả của bước kiểm tra.; Nhãn pha trộn Việt-Anh như "template registered", "quality gate" và "Artifact" làm giảm tính cụ thể, song song và nhất quán. Dùng thuật ngữ Việt hoặc tên định danh chính xác đã có trong prose.
assets/diagrams/13-process-design-workflows-and-approvals-032-c1cb7b39.mmd — REVISE — Nhánh “Không” đi thẳng đến handoff mà không giữ nhãn Verification required, trái với yêu cầu mọi package handoff phải mang nhãn này.; Điểm kết thúc chỉ nêu “đủ điều kiện handoff review” nhưng bỏ điều kiện package phải gồm chapter, bảng issue, evidence path và nhãn Verification required; bổ sung đầy đủ điều kiện handoff.; Sơ đồ không thể hiện issue vẫn mở sau escalation và không được đóng bằng suy đoán; làm rõ escalation không đồng nghĩa resolution hay approval.; Nhãn “Escalate đúng owner” mơ hồ về ownership; chỉ rõ owner được chọn theo loại evidence hoặc domain trong bảng escalation.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-001-c01d73cb.mmd — REVISE — Quan hệ Q --> U gây hiểu sai rằng QA trực tiếp dẫn đến thao tác của người dùng; cần thể hiện QA kiểm tra UI/hành vi do Developer xây hoặc bỏ quan hệ này.; Nhãn trường, nút, lỗi, outcome mơ hồ và trộn tiếng Việt với tiếng Anh; cần dùng các chi tiết đã nêu: Số lượng nhận, đơn vị kg, nút Ghi nhận, lỗi dữ liệu không hợp lệ và phản hồi lưu thành công.; Sơ đồ bỏ qua Business review, dù phần prose xác định wireframe cho phép business xem hành vi trước khi code; cần thể hiện nhánh review nếu mô tả luồng giá trị của wireframe.; Sơ đồ không thể hiện các điều kiện quan trọng đã nêu: để trống, 0, nhập chữ và số dương; cần thể hiện validation hoặc gom thành nhãn cụ thể mà không tạo luồng xử lý chưa được prose hỗ trợ.; Hai nhánh Developer và QA cùng hội tụ vào Người dùng thao tác nhưng không thể hiện UI đã build, kết quả kiểm thử hay điều kiện sẵn sàng; cần sửa quan hệ để tránh ngụ ý kiểm thử tự tạo ra trải nghiệm người dùng.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-002-3d3694b0.mmd — REVISE — Trạng thái Co_the_xac_nhan không có hành động Xác nhận đơn; sơ đồ chỉ cho phép Gửi duyệt. Thêm nhánh xác nhận được prose hỗ trợ hoặc đổi tên trạng thái để không ngụ ý hành động bị thiếu.; Luu_nhap được vẽ như trạng thái kết thúc, trong khi prose chỉ nói dữ liệu được giữ và vẫn cho lưu nháp. Không mô tả lưu nháp là kết thúc quy trình. Cần thể hiện kết quả lưu nhưng còn khả năng tiếp tục chỉnh sửa, hoặc tránh ký hiệu kết thúc.; Sơ đồ không thể hiện chủ thể và ranh giới màn hình: Nhân viên Kinh doanh thao tác tại NF-ERP-SO-01, còn Quản lý Kinh doanh phê duyệt hoặc từ chối tại NF-ERP-SO-02. Cần làm rõ owner và boundary nếu sơ đồ bao quát luồng gửi duyệt.; Nhánh Canh_bao_vuot_han_muc --> Gui_duyet kết hợp hai quy tắc riêng thành khẳng định rằng đơn vượt hạn mức luôn được gửi duyệt. Section không xác nhận trực tiếp điều kiện này. Cần bỏ nhánh hoặc bổ sung điều kiện được prose hỗ trợ.; Sơ đồ thiếu kết quả UI cốt lõi của nhánh vượt hạn mức: khóa Xác nhận đơn, giữ dữ liệu, hiện banner và lý do, vẫn bật Lưu nháp. Cần biểu diễn ít nhất các hành vi quyết định nhằm tránh hiểu Canh_bao_vuot_han_muc chỉ là cảnh báo.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-003-0299c79d.mmd — REVISE — Nhánh Verification-required claim bị mô hình hóa thành phương án loại trừ sau stakeholder input và project assumption. Theo bảng, đây là nhãn có thể đồng thời áp dụng cho phát biểu thuộc các loại đó khi ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc cấu hình và chưa đủ bằng chứng. Cần thể hiện kiểm tra độc lập hoặc khả năng gắn thêm nhãn.; Gateway dẫn đến Verification-required claim không kiểm tra mức ảnh hưởng hoặc nhu cầu xác nhận chuyên môn. Cần bổ sung điều kiện pháp lý, kế toán, bảo mật, vận hành, cấu hình hoặc nguồn chưa đủ.; Gateway quyết định hỏi cả lựa chọn và authority, nhưng nhánh Có record chỉ kiểm tra record. Cách ghi này có thể phân loại thành Decision dù thiếu authority. Cần yêu cầu đồng thời phương án, tiêu chí, authority và record như phần prose.; Luồng biến mọi loại bằng chứng thành ứng viên quyết định mà không nêu lựa chọn giữa các phương án theo tiêu chí. Cần làm rõ các trạng thái này chỉ cung cấp đầu vào cho quyết định, không tự chuyển thành quyết định.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-004-22a6528a.mmd — REVISE — Nhánh Operations chỉ quay về Discovery, trái với exit gate quy định thay đổi quay lại Discovery hoặc Analysis. Bổ sung nhánh Operations → Analysis cho thay đổi đã đủ đầu vào phân tích.; Nhãn “Entry Analysis: phạm vi sơ bộ” thiếu stakeholder input và dữ liệu sơ bộ, nên không thể hiện đúng entry gate của Analysis. Sửa nhãn để phản ánh đủ ba điều kiện hoặc dùng nhãn trung tính không tuyên bố đây là toàn bộ entry gate.; Nhãn Analysis → Delivery ghi “Exit: traceability, giả định, điểm xác minh” nhưng bỏ yêu cầu mỗi thành phần phải liên kết tới nhu cầu, rule, data hoặc Verification required. Sửa thành điều kiện cụ thể này; không trình bày “giả định” như điều kiện ra độc lập.; Nhánh Testing → Release chỉ yêu cầu kết quả kiểm thử được ghi nhận, trong khi Release còn cần danh sách lỗi và quyết định phát hành của vai trò có thẩm quyền. Bổ sung các điều kiện này để tránh mô tả sai gateway phát hành.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-005-cdfa33bf.mmd — REVISE — Các luồng BA đến UX/UI Designer, Solution Architect, QA/Test Analyst và Operations Owner không được đoạn văn xác lập; cần loại bỏ hoặc bổ sung căn cứ trong nội dung.; Các luồng Solution Architect và QA/Test Analyst đến Owner chuyên môn phù hợp tạo thêm trách nhiệm escalation không có trong đoạn văn; cần loại bỏ.; Sơ đồ thiếu điều kiện escalation cốt lõi: UI buộc chọn giữa hai cách hiểu nghiệp vụ trong khi artifact upstream chưa quyết; cần thể hiện rõ điều kiện này.; Nhãn "Vấn đề vượt quyền" quá rộng; cần giới hạn thành quyết định nghiệp vụ chưa được owner có thẩm quyền xác nhận.; Nhãn "Owner chuyên môn phù hợp" không xác định owner nào chịu quyết định; cần dùng owner có thẩm quyền đối với rule hoặc compliance đang tranh chấp.; Sơ đồ thiếu các hành động BA được phép làm: làm rõ, ghi giả định và giữ liên kết với artifact nguồn; cần thể hiện trước hoặc cùng escalation.; Sơ đồ thiếu ranh giới BA không được tự cấp quyền, đặt ngưỡng, diễn giải luật hoặc xác nhận compliance; cần thể hiện boundary hoặc kết quả escalation.; Nhãn "Source và canonical artifacts" trộn ngôn ngữ và chưa cụ thể; cần dùng thuật ngữ nhất quán, chỉ rõ artifact upstream chứa ID, rule và data boundary.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-006-32188582.mmd — REVISE — Nhánh Testing ghi “Đối chiếu hành vi với wireframe” khiến wireframe có vẻ là chuẩn xác nhận hành vi, mâu thuẫn với tuyên bố wireframe không phải yêu cầu hay bằng chứng kiểm thử. Cần thể hiện việc kiểm thử dựa trên yêu cầu hoặc tiêu chí chấp nhận đã phê duyệt; wireframe chỉ là tài liệu tham chiếu giao diện.; Ba phụ thuộc CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY không được prose giải thích về vai trò, phạm vi hay lý do liên kết. Cần bổ sung căn cứ trong prose hoặc bỏ các liên kết không được hỗ trợ.; Vòng phản hồi từ Operations về Discovery chỉ nêu “Phản hồi thay đổi màn hình”, không chỉ rõ điều kiện kích hoạt, chủ thể tiếp nhận hoặc kết quả mong đợi. Cần làm rõ ranh giới phản hồi để tránh ngụ ý mọi phản hồi vận hành đều khởi động lại vòng đời.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-007-289210d1.mmd — REVISE — Artifact nguồn + canonical ID gộp hai vai trò khác nhau: artifact nguồn chứa bằng chứng, còn canonical ID dùng để nối artifact. Cần tách hoặc thể hiện canonical ID là cơ chế liên kết, không phải đầu vào đồng cấp.; Thành phần UI có thể truy vết không nêu đích truy vết. Cần chỉ rõ thành phần UI truy ngược về bằng chứng hoặc artifact nguồn.; Wireframe có căn cứ còn trừu tượng. Cần dùng nhãn cụ thể phản ánh wireframe được tạo từ kiến thức nghiệp vụ tối thiểu, bằng chứng và artifact nguồn.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-008-446f2d4a.mmd — REVISE — Gateway D merges freshness and consistency despite different required outcomes. Split them: stale input requires labeling and verification; conflict with canonical artifact requires stopping affected scope.; Gateway C checks whether Owner is clear, not whether Owner has maintenance authority or business decision belongs to correct role. Add explicit authority check and escalation outcome.; Safety-of-interpretation check is missing. Add gateway for legal, accounting, tax, and food-safety claims; unverified claims must receive Verification required status.; Success outcome allows use as evidence before all six input-quality criteria pass. Route success only after identification, provenance, freshness, authority, consistency, and interpretation-safety checks pass.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-009-b6e09c89.mmd — REVISE — Gateway “Có nguồn canonical cho screen, role, data, rule?” mơ hồ: không nêu phải có đủ cả bốn loại nguồn và đã xác minh. Sửa điều kiện thành yêu cầu nguồn canonical đầy đủ, phù hợp phạm vi và đã xác minh.; Nhánh “Có” dẫn thẳng đến “Soạn wireframe có traceability” bỏ qua các nguồn bắt buộc khác trong bảng: luồng thao tác, quyền/segregation of duties, interface contract và xác minh Legal, Accounting, Compliance hoặc domain owner. Bổ sung điều kiện xác minh tương ứng hoặc giới hạn rõ wireframe chỉ ở phần đã đủ nguồn.; Sơ đồ chỉ có hai trạng thái “Có/Không”, trong khi bảng phân biệt đã ghi nhận, đang xem xét, thiếu nguồn và cần chuyên gia xác minh. Thêm nhánh cho nguồn có nhưng chưa xác minh để tránh coi sự tồn tại của artifact là đủ điều kiện.; Nhãn “Giữ mục chưa xác minh” không nêu nơi ghi nhận, owner hoặc bước xử lý tiếp theo. Làm rõ kết quả: đánh dấu cần xác minh, giao owner xác minh và không suy diễn hành vi UI.; “Canonical IDs and rule/data catalogs” có thể khiến người đọc hiểu catalog đã cung cấp dữ liệu dùng được, trái với bảng cho biết chưa có ID, rule, entity hoặc field cụ thể. Đổi nhãn để thể hiện đây là catalog plan đang xem xét, chưa phải nội dung canonical đã xác minh.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-010-8679584e.mmd — REVISE — Thiếu sự kiện kích hoạt kiểm tra phía giao diện. Thêm bước hoặc nhãn thể hiện kiểm tra khi người dùng rời trường Số lượng nhận, đúng với phương án đã chọn.; Thiếu luồng sửa lỗi. Các nút lỗi C, E và K đang kết thúc luồng; cần quay lại thao tác chỉnh Số lượng nhận rồi kiểm tra lại.; Ranh giới giao diện–máy chủ chưa rõ. Phân biệt kiểm tra phía giao diện với kiểm tra lại phía máy chủ để thể hiện hai lớp kiểm soát bắt buộc.; Gateway Máy chủ xác thực lại? không khớp nhãn nhánh Không hợp lệ và Hợp lệ. Đổi gateway thành điều kiện kết quả cụ thể, ví dụ Dữ liệu hợp lệ phía máy chủ?, với hai nhánh song song Không và Có.; Thiếu phụ thuộc dữ liệu dùng để kiểm tra. Thể hiện số lượng đơn mua, số lượng đã nhận và số lượng còn mở là dữ liệu hiển thị hoặc đầu vào của phép kiểm tra, tránh làm quy tắc không vượt số lượng còn mở thành giá trị không rõ nguồn.; Hiển thị lưu thành công chưa được nêu trong section. Cần bổ sung căn cứ trong prose hoặc bỏ outcome này khỏi diagram.; Luồng G -- Không --> H[Không gửi phiếu nhận] chưa thể hiện trạng thái nút theo yêu cầu về ma trận trạng thái. Cần làm rõ nút bị vô hiệu hóa hay thao tác gửi bị chặn, không để hai cách hiểu.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-011-fec97eb6.mmd — REVISE — Trạng thái Drafted không được định nghĩa trong phần văn xuôi hoặc registry được dẫn chiếu. Xóa trạng thái này hoặc chỉ dùng trạng thái đã được nguồn quản trị xác nhận.; Sơ đồ dừng ở IN_REVIEW nhưng không thể hiện ranh giới quan trọng: trạng thái này không đồng nghĩa approved, baselined, production-ready hoặc user-accepted. Bổ sung ghi chú hoặc nhánh thể hiện rõ giới hạn trạng thái mà không bịa trạng thái canonical mới.; Nhãn ghi metadata và lịch sử thay đổi chưa phản ánh yêu cầu lịch sử tối thiểu gồm version, ngày, múi giờ, người ghi nhận, phần thay đổi, lý do, artifact nguồn bị ảnh hưởng và trạng thái sau thay đổi. Làm nhãn hoặc ghi chú đủ cụ thể để không làm nhẹ kiểm soát bắt buộc.; Vòng lặp cập nhật có truy vết quá mơ hồ và không thể hiện cấm sửa im lặng nội dung đã được review. Nêu rõ cập nhật phải ghi lịch sử thay đổi.; Sơ đồ không cho biết ai chịu trách nhiệm ghi nhận thay đổi, dù section chỉ định owner. Gắn owner vào hành động hoặc thêm chú thích trách nhiệm.; Sơ đồ gần như lặp lại văn xuôi nhưng bỏ phần lớn điều kiện và ranh giới kiểm soát. Chỉ giữ sơ đồ nếu nó làm rõ vòng đời review và kiểm soát thay đổi tốt hơn phần chữ.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-012-bed4932d.mmd — REVISE — Sơ đồ bỏ sót UI rule, dù đây là thành phần cốt lõi của output và có nhiệm vụ ràng buộc hiển thị, thao tác theo business rule. Bổ sung UI rule cùng liên kết từ business rule và tới wireframe hoặc screen behavior.; Mũi tên từ Wireframe tới Traceability record khiến truy vết trông như kết quả riêng của wireframe. Thể hiện traceability record liên kết business rule, data element, screen behavior, field specification, UI rule và wireframe.; Nhãn Field specification chưa xuất hiện rõ trong phần văn xuôi hoặc bảng output anatomy. Dùng thuật ngữ đã xác lập trong phần này hoặc định nghĩa Field specification trước sơ đồ.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-013-fe76677e.mmd — REVISE — Diagram omits mandatory “Không mâu thuẫn” gate covering CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, and TRACEABILITY_ID_REGISTRY. Add explicit pass/fail check before readiness outcome.; Flow implies sequential gate evaluation, while prose requires all conditions collectively and defines no evaluation order. Present checks as parallel mandatory conditions or clarify that order has no procedural meaning.; Return for correction invents failure handling not stated in section. Replace with supported outcome: output is not labeled Ready for downstream review, unless surrounding prose defines correction workflow.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-014-74e1594d.mmd — REVISE — Nút "Build review" không được phần văn bản xác lập; cần xóa hoặc thay bằng kết quả/hoạt động có căn cứ trong phần này.; Các cạnh từ mọi vai trò đến cùng "Build review" ngụ ý tất cả cùng tham gia một bước duyệt bản build; phần văn bản chỉ mô tả mục đích sử dụng hoặc phạm vi kiểm tra khác nhau. Cần thể hiện đúng hành vi riêng của từng vai trò hoặc không biểu diễn bước hội tụ.; Nhãn "Build review" mơ hồ, không nêu đối tượng, chủ sở hữu, điều kiện hay kết quả; cần dùng nhãn cụ thể được phần văn bản hỗ trợ.; Sơ đồ không thể hiện các liên kết có điều kiện tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY, dù đây là phần quan trọng của output wireframe; cần bổ sung nếu sơ đồ nhằm mô tả luồng sử dụng đầy đủ.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-015-0e71b2b8.mmd — REVISE — Nút W bỏ sót "hành vi màn hình", trong khi section xác định ba loại đầu ra: wireframe, hành vi màn hình và quy tắc UI. Bổ sung loại đầu ra này.; Nhãn "Developer: hiện thực" dễ diễn giải thành lệnh build, trái với quy tắc đầu ra chỉ hỗ trợ quyết định. Đổi thành quyết định "cách hiện thực UI".; Nút "Operations/Specialist" gộp hai nhóm có thẩm quyền, bằng chứng và điều kiện escalation khác nhau. Tách Operations owner khỏi Specialist owner; thể hiện phạm vi Accounting, Legal, Security và Food Safety.; Gateway "Mơ hồ hoặc vượt thẩm quyền?" không bao quát rõ các trigger được nêu: xung đột, không kiểm thử được, nguy cơ mất dữ liệu, thay đổi contract hoặc kiến trúc, dữ liệu nhạy cảm, quyền truy cập và chặn vận hành. Dùng điều kiện cụ thể hơn hoặc thêm nhánh rủi ro/xung đột cần escalation.; Kết quả escalation chỉ nói "giữ traceability", bỏ các thành phần bắt buộc của gói: ID yêu cầu, rule liên quan, ảnh màn hình, dữ liệu tổng hợp, phương án và tác động. Thể hiện tối thiểu rằng package phải đủ các bằng chứng bắt buộc.; Sơ đồ không thể hiện ranh giới quan trọng: wireframe không chứng minh API tồn tại, quyền hợp lệ, tuân thủ hay phê duyệt. Thêm boundary hoặc ghi chú giới hạn bằng chứng để tránh suy diễn sai.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-016-0291fb99.mmd — REVISE — Các bước “Đối chiếu nguồn canonical” và “Escalate kèm bằng chứng” không được phần văn xuôi xác lập; cần bỏ hoặc bổ sung căn cứ, chủ thể và điều kiện tương ứng trong nội dung.; Nút “Xung đột hoặc vượt thẩm quyền?” đưa vào khái niệm thẩm quyền chưa xuất hiện trong phần văn xuôi; cần bỏ hoặc nêu rõ phạm vi quyết định và chủ thể có thẩm quyền.; Nhãn “Nhận đúng phạm vi artifact” mơ hồ, pha trộn Việt-Anh và không mô tả kết quả kiểm chứng được; cần dùng kết quả cụ thể phù hợp với giới hạn của wireframe.; Nhánh “Escalate kèm bằng chứng” không có điểm kết thúc hoặc kết quả xử lý; cần thể hiện kết quả được phần văn xuôi hỗ trợ.; Sơ đồ không nêu chủ thể thực hiện hỏi, đối chiếu và chuyển cấp dù trách nhiệm hành động ảnh hưởng trực tiếp đến quy trình; cần xác định chủ thể nếu phần nội dung có căn cứ.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-017-8344a626.mmd — REVISE — Sơ đồ bỏ sót hai giới hạn quan trọng sau khi lưu: không yêu cầu lý do chênh lệch và không xác định “Lưu thành công” là lưu nháp hay hoàn tất nhận kho. Bổ sung hai kết quả này từ nút F.; Nhãn “Không hiện trạng thái lô hoặc kiểm tra chất lượng” gộp hai khái niệm bằng “hoặc”, làm mơ hồ đối tượng không hiển thị. Tách thành trạng thái lô và trạng thái kiểm tra chất lượng, hoặc dùng nhãn cụ thể phù hợp nội dung đã quan sát.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-018-b5085275.mmd — REVISE — Các định danh USR-WH-014, PO-NF-2026-000184, RM-SUGAR-001 và GRN-NF-2026-000771 không được phần văn xuôi xác nhận; bỏ chúng hoặc bổ sung căn cứ trong văn xuôi.; Nhánh “Không” dẫn đến “Hiển thị lỗi” là hành vi chưa được phần văn xuôi mô tả; bỏ nhánh hoặc nêu rõ hành vi này trong văn xuôi.; Nhãn “Số lượng > 0?” mơ hồ; phải chỉ rõ đây là receivedQuantity để khớp thuật ngữ trong văn xuôi.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-019-d339795c.mmd — REVISE — Nhánh IN_REVIEW --> REJECTED thiếu điều kiện quyền DAR_APPROVE; sửa nhãn để thể hiện đồng thời quyền hợp lệ và rejectionReason từ 10 đến 500 ký tự.; Nhãn tồn đủ mơ hồ; thay bằng điều kiện cụ thể availableQty >= requestedIncreaseQty theo BR-UI-DAR-002.; Sơ đồ bỏ qua ngoại lệ 409 Conflict khi trạng thái đã đổi đồng thời; bổ sung nhánh giữ nguyên hoặc tải lại trạng thái thay vì ngụ ý mọi thao tác đều kết thúc thành công.; Hai trạng thái kết thúc bỏ qua BR-UI-DAR-005: sau thao tác thành công, màn hình phải tải lại trạng thái và nhật ký audit từ server; thể hiện bước này trước điểm kết thúc.; Mũi tên [*] --> IN_REVIEW ngụ ý mọi yêu cầu khởi tạo trực tiếp ở IN_REVIEW, nhưng phần văn bản chỉ xác nhận trạng thái của case hiện tại; sửa ranh giới đầu vào hoặc ghi rõ đây là phạm vi màn hình duyệt.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-020-98295f45.mmd — REVISE — Nút "UI artifact / scenario evidence" gộp hai khái niệm khác nhau và tạo bước trung gian không được phần văn bản xác định. Cần tách theo artifact có nguồn hỗ trợ hoặc nối wireframe trực tiếp tới các nhóm review.; Nút "Downstream BA, UX, Architect, QA review" thêm BA nhưng bảng chỉ xác định UX/UI design, Architect và API design, QA và test design. Cần bỏ BA hoặc bổ sung vai trò BA trong phần văn bản.; Các nút TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TEMPLATE_MANIFEST không ghi đường dẫn canonical như bảng. Cần dùng đường dẫn đầy đủ để ranh giới nguồn chân lý nhất quán và cụ thể.; Luồng downstream gom mọi nhóm vào một quan hệ chung, làm mất khác biệt nguồn phụ thuộc: UX dùng wireframe và upstream; Architect cần data dictionary, rule catalog và API artifact khi tồn tại; QA cần scenario, rule, data definition và registry. Cần biểu diễn các phụ thuộc riêng hoặc thu hẹp nhãn thành tổng quan không tuyên bố chuỗi artifact.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-021-460617db.mmd — REVISE — Cạnh WF --> AC ngụ ý wireframe tạo hoặc quyết định acceptance criteria, trái với yêu cầu chỉ tham chiếu artifact requirement canonical. Đảo thành AC --> WF để thể hiện AC chi phối trạng thái thành công, lỗi và biên dữ liệu.; Nhãn DATA/API trong CANONICAL_DATA_DICTIONARY gộp sai hai nguồn canonical. Data field thuộc CANONICAL_DATA_DICTIONARY; API operation thuộc OpenAPI đã đăng ký. Tách nguồn hoặc sửa nhãn để nêu đủ hai nguồn.; Cạnh AC --> TC chỉ thể hiện TC kiểm tra AC, trong khi bảng yêu cầu ghi TC cho luồng và lỗi có rủi ro. Bổ sung quan hệ với hành vi wireframe hoặc đổi cấu trúc để không thu hẹp phạm vi TC.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-022-c05c6a23.mmd — REVISE — Bước "Ghi nhận thay đổi và phạm vi tác động" thiếu version, lý do và danh sách artifact cần kiểm tra; bổ sung đủ bốn nội dung mà phần văn xuôi dùng để phân biệt thay đổi được kiểm soát với thay đổi im lặng.; Nút "Review tính nhất quán" không thể hiện kết quả review trong trạng thái IN_REVIEW; bổ sung nhánh đạt để cập nhật traceability và nhánh không đạt để sửa các artifact bị ảnh hưởng rồi review lại.; Nhãn "Requirement, business rule, data/API, test artifact" trộn loại artifact và quan hệ phụ thuộc trong một cụm chưa song song; chuẩn hóa thành các nhóm artifact cụ thể, nhất quán với "Wireframe và UI rules".
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-023-083924c8.mmd — REVISE — Bước D thiếu điều kiện nhập, hành động người dùng và phản hồi hệ thống; bổ sung đủ điều kiện vào, hành động, thành công, lỗi, tải và quyền như prose yêu cầu.; Luồng không thể hiện nhánh khi chưa có nguồn canonical; thêm quyết định nguồn đã tồn tại hay chưa và ngăn dữ liệu ví dụ trở thành business rule.; Luồng thiếu owner xác minh quyền; thêm Security hoặc Business Owner tại bước rà quyền.; Bước E gộp acceptance criteria, UI và test basis nhưng không thể hiện rà tác động hoặc cập nhật artifact liên kết; làm rõ hành động kiểm tra và cập nhật consumer.; Trạng thái IN_REVIEW không được prose định nghĩa rõ; bỏ nhãn hoặc giải thích điều kiện vào, owner và kết quả của trạng thái.; Luồng bỏ qua ngoại lệ lưu lặp trong cảnh báo; thể hiện dừng thao tác lặp, đối chiếu mã tham chiếu và chuyển owner nghiệp vụ cùng kỹ thuật xác minh.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-024-8a154322.mmd — REVISE — Trạng thái DaGhiNhan không thể hiện nội dung UI bắt buộc Đã ghi nhận yêu cầu xuất kho và mã giao dịch tổng hợp. Dùng nhãn trạng thái cụ thể, gồm thông báo và mã giao dịch.; Nhánh LoiGui --> NhapThongTin: Kiểm tra rồi gửi lại gộp kiểm tra và gửi lại nhưng đích là trạng thái nhập thông tin, gây sai trình tự. Tách bước người dùng kiểm tra mã giao dịch khỏi sự kiện gửi lại; sự kiện gửi lại phải chuyển sang DangGui.; Nhãn Phản hồi hợp lệ chưa nêu hệ thống nhận phản hồi, còn Chọn Xác nhận xuất kho thiếu chủ thể người dùng. Bổ sung chủ thể nơi trách nhiệm hành động hoặc sự kiện cần rõ.; Trạng thái lỗi chỉ có tên LoiGui, chưa thể hiện yêu cầu hiển thị lỗi trước khi cho phép gửi lại. Gắn nhãn cụ thể cho kết quả lỗi và điều kiện kiểm tra mã giao dịch.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-025-4fd687d0.mmd — REVISE — A --> S ngụ ý authority evidence trực tiếp tạo trạng thái IN_REVIEW; section chỉ dùng IN_REVIEW cho phục hồi khi sai. Cần tách trạng thái liên kết hiện tại Verification required khỏi trạng thái phục hồi IN_REVIEW.; Authority evidence quá mơ hồ và chỉ nối từ business rule. Cần thể hiện đúng phạm vi xác nhận: Business Owner cho chính sách xuất kho, Accounting Owner cho ảnh hưởng chứng từ, Architect cho nguồn dữ liệu và tích hợp.; Business rule canonical và Data element canonical không cho biết chúng chưa được xác nhận. Cần biểu đạt rule canonical, ngưỡng, nguồn số lượng khả dụng và ngoại lệ quyền là dependency bắt buộc trước build.; Test basis ngụ ý đã có cơ sở kiểm thử hoàn chỉnh, trái với facts nêu thiếu rule ID và test basis. Cần ghi trạng thái chưa xác nhận hoặc điều kiện chỉ hình thành test basis sau khi canonical rule được duyệt.; Sơ đồ bỏ quan hệ truy vết tới TRACEABILITY_ID_REGISTRY.md và vai trò BA chỉ duy trì truy vết. Cần thể hiện registry hoặc bỏ sơ đồ nếu không mô tả được giá trị truy vết cụ thể.; Sơ đồ không thể hiện kết quả nghiệp vụ trọng yếu: chặn Xác nhận xuất kho, hiển thị lý do và không tạo chứng từ khi dịch vụ tồn kho trả trạng thái không đủ. Cần thêm luồng điều kiện và outcome nếu mục tiêu là giải thích hành vi màn hình.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-026-d33504bb.mmd — REVISE — Nhánh “Không” dẫn đến “cập nhật manifest theo governance” không được section quy định như bước bắt buộc. Section chỉ cho phép ghi tham chiếu quản trị và nêu vai trò duy trì manifest. Cần bỏ quan hệ bắt buộc này hoặc thể hiện cập nhật là hành động riêng theo governance.; Nhánh “Có” chỉ kiểm tra ID và filename rồi chuyển sang QA, nhưng bỏ qua boundary xác nhận nội dung của Business Owner, Architect và QA Reviewer trong phạm vi thẩm quyền. Cần thể hiện kiểm tra này hoặc giới hạn rõ diagram chỉ mô tả kiểm tra đăng ký template.; Diagram không thể hiện outcome/risk khi dùng tệp chưa đăng ký: tạo bản sao nguồn chân lý, mất traceability hoặc bị hiểu là requirement đã phê duyệt. Cần thêm trạng thái chặn hoặc kết quả cảnh báo để nhánh ngoại lệ không bị giảm thành thao tác quản trị vô hại.; Nhãn “Chỉ ghi tham chiếu quản trị” chưa chỉ rõ tham chiếu đến /01-curriculum/TEMPLATE_MANIFEST.md và artifact canonical đã xác minh. Cần dùng nhãn cụ thể để giữ source boundary.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-027-84eff02b.mmd — REVISE — Sơ đồ lặp lại tuyến tính nội dung bảng và đoạn văn nhưng không thể hiện quan hệ kiểm soát hoặc quyết định mới; cần bổ sung giá trị giải thích rõ, chẳng hạn luồng xác minh, điểm không đạt và nơi phải cập nhật.; Nhãn "Giữ liên kết source map" mơ hồ, không nêu hành động kiểm tra ranh giới nguồn; cần diễn đạt cụ thể việc đối chiếu nguồn và không gán nghĩa vụ chưa được nguồn chính thức xác minh.; Nhãn "Đối chiếu ID registry, rules, data dictionary" gộp ba kiểm tra khác loại; cần làm rõ từng dependency và tiêu chí đạt tương ứng.; Sơ đồ bỏ sót kiểm tra TEMPLATE_MANIFEST, cấu trúc 12 H2, kiến trúc curriculum và bộ metadata v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND; cần thể hiện hoặc xác định rõ phạm vi sơ đồ hẹp hơn.; Sơ đồ chỉ nêu kết quả IN_REVIEW nhưng bỏ các điều kiện đạt khác và không có nhánh xử lý khi kiểm tra thất bại; cần thể hiện kết quả đạt/không đạt cùng hành động cập nhật nguồn canonical rồi liên kết lại.; Không có owner cho hành động kiểm tra và sửa artifact; cần nêu actor nếu sơ đồ nhằm mô tả quy trình quản trị.; Nhãn bước chưa song song: "Tra cứu", "Kiểm tra", "Đọc", "Đối chiếu", "Giữ" và một câu trạng thái cuối; cần dùng cấu trúc hành động hoặc trạng thái nhất quán.
assets/diagrams/14-wireframes-screen-behavior-and-ui-rules-028-da157eb1.mmd — REVISE — “Đối chiếu manifest và registry” omits CANONICAL_BUSINESS_RULES and CANONICAL_DATA_DICTIONARY; label must cover all five named sources.; Gateway “Có mâu thuẫn?” is ambiguous; condition must specify inconsistency in ID, file name, status, version, source scope, or authority boundary.; “Ghi open issue” and “Escalation đúng owner” introduce unsupported workflow, owner, and escalation behavior; remove them or support them in surrounding prose.; Diagram omits explicit outcome that chapter must not claim baseline, approved, compliant, or production-ready.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-001-79c6532d.mmd — REVISE — Nhãn "Outcome: quyết định cải thiện dịch vụ" mâu thuẫn với định nghĩa bốn thành phần: phần văn xuôi xác định outcome là kết quả quan sát được, như tỷ lệ giao đúng hạn; cần đặt "tỷ lệ giao đúng hạn" ở Outcome hoặc làm rõ quyết định là hành động quản trị sau KPI.; Chuỗi từ "thời điểm giao thực tế" đến "tỷ lệ giao đúng hạn" thiếu ngày giao cam kết, tập đơn đã giao, kỳ báo cáo và phép so sánh; cần thể hiện các đầu vào tối thiểu để tránh ngụ ý một thời điểm đơn lẻ đủ tạo KPI.; Nhãn "quyết định cải thiện dịch vụ" mơ hồ, không nêu người ra quyết định hoặc hành động cụ thể; cần dùng quyết định cụ thể được phần văn xuôi hỗ trợ hoặc bỏ nút này.; Sơ đồ không thể hiện mẫu số chỉ gồm đơn đã giao, dù đây là ranh giới quan trọng và ngoại lệ được nhấn mạnh trong ví dụ; cần thể hiện điều kiện phạm vi này nếu sơ đồ mô tả cách hình thành KPI.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-002-3d196950.mmd — REVISE — Luồng B và C cùng vào D không thể hiện rõ điều kiện AND; cần biểu diễn đơn chỉ đạt OTIF khi vừa đúng hạn vừa đủ số lượng.; Sơ đồ chuyển từ “Đơn đạt OTIF” thẳng sang KPI-OTIF-DAILY, bỏ bước hệ thống đếm đơn đạt và tính tỷ lệ theo ngày; cần thể hiện phép tổng hợp này.; Nhãn “Đơn giao hàng tổng hợp” mơ hồ, không khớp trực tiếp với Object “đơn giao hàng”; cần dùng nhãn cụ thể và tách việc tổng hợp theo ngày thành bước xử lý.; Actor thực hiện Action là hệ thống bị thiếu; cần thể hiện hệ thống đánh giá, đếm và tính tỷ lệ, còn Điều phối giao nhận dùng kết quả.; Outcome “nhận biết ngày giao nhận lệch mục tiêu” chưa xuất hiện; cần thể hiện việc Điều phối giao nhận dùng tỷ lệ OTIF để nhận biết ngày lệch mục tiêu.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-003-48d62de3.mmd — REVISE — Nhánh "Traceability và quản trị thay đổi" quá mơ hồ, không thể hiện chuỗi truy ngược được nêu trong phần văn xuôi: artifact, dữ liệu nguồn, phiên bản định nghĩa và người có thẩm quyền thay đổi. Cần biểu diễn rõ các thành phần này và quan hệ với định nghĩa KPI hoặc báo cáo.; Luồng quản trị thay đổi đi thẳng từ "Định nghĩa KPI" đến "Báo cáo quản trị", dễ ngụ ý quản trị thay đổi trực tiếp tạo báo cáo. Cần thể hiện quản trị thay đổi kiểm soát phiên bản và phê duyệt định nghĩa trước khi tính toán hoặc phát hành.; Sơ đồ không thể hiện điều kiện định nghĩa KPI phải được chốt ở mức nghiệp vụ trước khi xây dựng và kiểm thử. Cần thêm trạng thái hoặc điểm quyết định phê duyệt, đồng thời tránh đồng nhất IN_REVIEW với phê duyệt.; Nhãn "Kiểm tra kết quả" chưa nêu đối tượng kiểm tra. Cần làm rõ kiểm tra kết quả tính theo định nghĩa KPI đã được phê duyệt, không chỉ kiểm tra hệ thống thực thi công thức.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-005-7339d1db.mmd — REVISE — Thứ tự gateway làm các loại bằng chứng thành loại trừ lẫn nhau theo nguồn gốc. Quyết định hoặc giả định do stakeholder cung cấp sẽ bị phân loại thành Stakeholder input trước khi xét vai trò thực tế. Cần phân loại theo trạng thái bằng chứng và chức năng của phát biểu, không chỉ theo nhánh tuần tự.; Gateway Có nguồn kiểm soát kiểm tra lại? chưa đủ tiêu chí cho Verified fact. Phần prose yêu cầu phát biểu đã được chứng minh bởi nguồn kiểm soát và có thể kiểm tra lại. Cần thể hiện cả bằng chứng xác minh, không chỉ sự tồn tại của nguồn.; Gateway Đã chọn phương án bởi authority? dùng cấu trúc bị động, không tự nhiên và bỏ tiêu chí, trạng thái ghi nhận, approval reference. Cần nêu authority đã quyết định giữa các phương án theo tiêu chí và không ngụ ý phê duyệt khi thiếu approval reference.; Nhánh mặc định Verification required quá rộng. Prose giới hạn loại này cho nhận định có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc KPI nhưng chưa đủ bằng chứng hoặc thẩm quyền. Cần thêm điều kiện ảnh hưởng và thiếu bằng chứng/thẩm quyền.; Sơ đồ bỏ owner hoặc nguồn cần kiểm tra cho Verification required, owner xác minh và điều kiện hết hiệu lực cho Project assumption, cùng authority và trạng thái cho Decision. Cần thể hiện các ranh giới này hoặc tránh trình bày sơ đồ như cây phân loại đầy đủ.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-006-875379c8.mmd — REVISE — Nhãn Entry đặt sai quan hệ: mỗi nhãn mô tả entry gate của nút nguồn nhưng nằm trên mũi tên sang pha kế tiếp. Chuyển entry gate vào đúng pha hoặc đổi nhãn mũi tên thành exit/điều kiện chuyển pha tương ứng.; Các nút Exit gate không nêu tiêu chí, kết quả hay đường đi tiếp nên chỉ lặp khái niệm trong bảng và không giải thích luồng. Gắn từng exit gate với tiêu chí cụ thể và kết quả đạt/không đạt, hoặc bỏ các nút này.; Luồng Operations chỉ quay về Discovery, trái bảng cho phép quay về Discovery hoặc Analysis. Thể hiện hai nhánh theo loại lệch: nhu cầu mới về Discovery; lệch dữ liệu hoặc công thức về Analysis.; Điều kiện Testing bị rút thành bản build và test basis tồn tại, thiếu thành phần bắt buộc của test basis: định nghĩa KPI, dữ liệu test tổng hợp và expected result. Bổ sung đủ điều kiện.; Điều kiện Release kết quả test đạt hẹp hơn bảng: lỗi chặn release có thể được authority quyết định xử lý theo kiểm soát. Diễn đạt điều kiện release gồm test evidence và quyết định có thẩm quyền, không đồng nhất mọi trường hợp với test đạt.; Điều kiện Delivery thiếu yêu cầu không có công thức mơ hồ. Bổ sung để tránh thể hiện đặc tả chưa rõ vẫn đủ điều kiện build.; Sáu nhánh từ pha sang Exit gate kết thúc cụt, không thể hiện đạt gate dẫn tới đâu hoặc không đạt quay lại đâu. Nối gateway với kết quả và luồng xử lý cụ thể.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-007-7ea65086.mmd — REVISE — Luồng Data Owner chỉ tới BA, bỏ quan hệ bắt buộc với Data/BI Owner. Cần thể hiện Data/BI Owner là bên nhận nguồn, ý nghĩa trường, chất lượng và quyền truy cập.; Luồng downstream từ BA bỏ Data/BI Owner dù bảng xác định Architect, Data/BI Owner và QA cùng nhận KPI definition. Cần bổ sung ranh giới bàn giao này.; Nhãn Accounting Owner "Xác minh khi có chỉ tiêu tài chính" không phản ánh đầu vào cụ thể gồm cách hiểu chỉ tiêu tài chính và giả định cần kiểm tra. Cần dùng nhãn bám đúng phạm vi này.; Luồng Release tới Operations với nhãn "Runbook và ownership vận hành" gán sai nguồn bàn giao. Bảng quy định Operations Owner tạo runbook, lịch làm mới, cảnh báo lỗi và kênh hỗ trợ; QA bàn giao test basis và acceptance criteria cho Release/Operations. Cần sửa hướng và trách nhiệm.; Sơ đồ bỏ người dùng báo cáo mô phỏng là bên nhận đầu ra từ Operations Owner. Cần thể hiện outcome vận hành này.; Escalation chỉ nối từ BA bằng điều kiện chung, trong khi bảng quy định nhiều trigger cụ thể tại Business Owner, Domain Owner, Data Owner, Accounting Owner, Architect, QA và Operations Owner. Cần thể hiện các điểm escalation hoặc chỉ rõ nhánh tổng quát áp dụng cho mọi owner.; Nhãn "Escalation tới owner chuyên môn" mơ hồ vì không xác định owner theo loại xung đột. Cần gắn escalation với trigger và owner có thẩm quyền tương ứng.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-009-5785c7b0.mmd — REVISE — Luồng tuyến tính K → E → A → I không được phần văn bản hỗ trợ. Kiến thức nghiệp vụ, bằng chứng, artifact nguồn và định danh canonical được mô tả là các đầu vào hoặc quan hệ tham chiếu, không phải các bước tuần tự; cần thể hiện đúng quan hệ phụ thuộc.; Quan hệ E → A đảo hoặc làm mờ ý nghĩa: artifact nguồn là tệp được kiểm soát chứa bằng chứng, không phải kết quả được tạo ra sau bằng chứng; cần thể hiện quan hệ chứa hoặc nguồn của bằng chứng.; Quan hệ A → I ngụ ý định danh canonical được tạo từ artifact. Văn bản chỉ nói mã giữ nguyên để nhận diện đúng đối tượng khi được tham chiếu từ nhiều nơi; cần thể hiện vai trò nhận diện ổn định, không suy diễn trình tự.; Nhãn “Need: quyết định nghiệp vụ” pha tiếng Anh và mơ hồ về loại quan hệ với kiến thức nghiệp vụ; cần dùng nhãn tiếng Việt cụ thể, phù hợp với “mục tiêu quyết định”.; Sơ đồ bỏ mất các đầu vào nghiệp vụ cụ thể gồm quy trình tạo sự kiện, đối tượng đo, đơn vị đo và ngoại lệ. Nếu giữ mức khái quát, cần tránh khiến “Kiến thức nghiệp vụ” trông như một bước không có tiêu chí.; Kết quả “Định nghĩa KPI có thể truy vết” được hỗ trợ, nhưng sơ đồ chưa thể hiện cầu nối suy luận từ nguồn nói gì đến KPI suy ra gì và lý do; cần thể hiện quan hệ này để tính truy vết có căn cứ.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-010-cf5fb23c.mmd — REVISE — Nhánh kết thúc chỉ cho phép “phân tích có nhãn IN_REVIEW”, nhưng phần văn xuôi phân biệt hai trường hợp: dừng định nghĩa KPI khi dùng cho quyết định nghiệp vụ, tài chính hoặc tuân thủ; chỉ tiếp tục cho ví dụ học liệu với nhãn project assumption. Thêm gateway theo mục đích sử dụng và hai kết quả tương ứng.; Nhãn “Freshness trong ngưỡng?” giả định có ngưỡng đã xác định, trong khi section không cung cấp ngưỡng hoặc baseline reference. Đổi điều kiện thành kiểm tra freshness có căn cứ canonical và tiêu chí chốt được xác nhận; nếu chưa có thì STOP.; Gateway “Owner đúng thẩm quyền?” gộp nhiều trách nhiệm và làm mờ xác nhận bắt buộc. Thể hiện Business Owner, Accounting Owner, Data Owner và Legal Owner khi có nội dung pháp lý; không ngụ ý Principal IT Business Analyst / Technical Curriculum Author có quyền phê duyệt.; Sơ đồ không kiểm tra approval reference dù Facts và Decision Criteria nêu rõ chưa có approval và đây là lý do KPI chưa được gọi là đã phê duyệt. Thêm kiểm tra trạng thái/phê duyệt trước mọi kết quả cho phép dùng KPI chính thức.; Kết quả cuối “Đủ điều kiện phân tích có nhãn IN_REVIEW” không nêu giới hạn cấm công bố hoặc cấm dùng làm căn cứ vận hành/production. Bổ sung ranh giới sử dụng để tránh diễn giải IN_REVIEW thành đủ điều kiện nghiệp vụ.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-011-9d5de66e.mmd — REVISE — Nhãn "Artifact quản trị" mơ hồ; cần dùng tên loại đầu vào cụ thể đã được xác định trong bảng hoặc phần văn xuôi.; Nhãn "Điểm chưa xác minh" không được phần văn xuôi xác lập là đầu vào của định nghĩa KPI; IN_REVIEW và v0.9.0 chỉ được nêu là không phải baseline hay phê duyệt. Cần bổ sung căn cứ trong nội dung hoặc loại bỏ quan hệ này.; Các mũi tên thể hiện quan hệ phụ thuộc và trình tự tạo báo cáo, nhưng phần văn xuôi chỉ nói bảng là tập đầu vào. Cần xác nhận rõ quan hệ từ từng nhóm dữ liệu đến định nghĩa KPI và từ định nghĩa KPI đến báo cáo.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-012-4babb500.mmd — REVISE — Nhánh kiểm tra ngày giao thiếu kết quả Có/Không. Luồng hiện tại cho phép đơn giao muộn nhưng đủ số lượng đi tới "Đúng cả hai" và bị đếm vào tử số. Cần tách kết quả ngày xác nhận giao không muộn hơn ngày cam kết; mọi trường hợp sai ngày hoặc sai số lượng chỉ vào mẫu số.; Điều kiện mẫu số chưa đủ. Sơ đồ thiếu kỳ 01/07/2026–31/07/2026, múi giờ Asia/Ho_Chi_Minh và ngoại lệ đơn hủy trước giao. Cần thể hiện ranh giới lọc này trước khi đếm mẫu số.; Grain chống đếm lặp bị bỏ sót. Nguồn là dữ liệu đơn bán hàng tổng hợp nhưng KPI yêu cầu một dòng cho một đơn giao hoàn tất, không cộng lặp theo dòng hàng. Cần thể hiện bước chuẩn hóa về cấp đơn.; Bước "Đối chiếu Business Owner và Data Owner" nhập nhằng trách nhiệm. Cần ghi riêng Business Owner xác nhận ý nghĩa KPI và Data Owner xác nhận nguồn, khả dụng, chất lượng dữ liệu.; Nhãn "Escalate đúng thẩm quyền" dùng tiếng Anh pha trộn và không nêu đích xử lý. Cần dùng nhãn cụ thể như "Chuyển mâu thuẫn ý nghĩa cho Business Owner; mâu thuẫn dữ liệu cho Data Owner".; Truy vết nguồn chưa được thể hiện dù là nhu cầu cốt lõi. Cần liên kết bước xác nhận dữ liệu với CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-013-f7c5a0e8.mmd — REVISE — Nhãn "Nguồn dữ liệu tổng hợp Nova Foods" đưa thêm tổ chức và loại nguồn dữ liệu không được phần văn xuôi hỗ trợ. Xóa nút này hoặc thay bằng quan hệ cụ thể đã nêu: trường logic, nguồn và quy tắc chất lượng liên kết với KPI.; Các nhãn "Điều kiện tính KPI" và "Liên kết truy vết" mơ hồ, đồng thời lặp lại nội dung vốn đã nằm trong CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY. Dùng nhãn quan hệ cụ thể hoặc bỏ các nút trang trí này.; Mũi tên một chiều từ bảng định nghĩa KPI tới ba artifact không thể hiện đúng nghĩa vụ liên kết và tác động hai chiều khi dữ liệu hoặc quy tắc thay đổi. Biểu diễn rõ quan hệ truy vết và ảnh hưởng tới công thức, kỳ so sánh, số liệu lịch sử.; Sơ đồ bỏ qua owner, trạng thái IN_REVIEW và nghĩa vụ lưu lịch sử thay đổi, dù đây là ranh giới kiểm soát cốt lõi của phần văn xuôi. Bổ sung các yếu tố kiểm soát này nếu sơ đồ nhằm tóm tắt mô hình artifact.; Sơ đồ gần như sao chép ba liên kết trong bảng nhưng không làm rõ luồng kiểm soát, trách nhiệm hoặc vòng đời thay đổi. Thiết kế lại mục đích giải thích để hình cung cấp thông tin vượt quá danh sách artifact.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-014-5d684a1a.mmd — REVISE — KPI-TRACE-NF-001 chỉ nhận liên kết trực tiếp từ DATA-MAP-NF-001 và RPT-SPEC-NF-001, trong khi anatomy yêu cầu truy vết cả KPI ID và câu hỏi nghiệp vụ. Cần thể hiện liên kết trực tiếp từ KPI-DEF-NF-001 tới KPI-TRACE-NF-001.; KPI-TRACE-NF-001 yêu cầu rule/assumption ID và kiểm tra đối chiếu, nhưng sơ đồ không thể hiện hai đầu vào này. Cần bổ sung nguồn quy tắc/giả định và bước hoặc artifact kiểm tra đối chiếu, hoặc giới hạn rõ sơ đồ chỉ mô tả quan hệ giữa bốn artifact chính.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-015-ddd1c1b3.mmd — REVISE — Luồng kiểm tra bỏ sót điều kiện “Không có lỗi kiểm soát”; bổ sung bước kiểm tra TODO, TBD, ellipsis, omitted rows, fabricated quotation và fabricated clause trước gateway.; Nhãn “Không đủ bằng chứng” không bao quát mọi nguyên nhân dẫn đến RETURN_FOR_REWORK, như sai định danh, sai metadata hoặc lỗi kiểm soát; đổi thành nhãn bao quát như “Không đạt điều kiện, không vượt thẩm quyền”.; Nhãn “filename” không nhất quán với thuật ngữ “tên tệp” trong bảng; dùng “tên tệp” để giữ ngôn ngữ và thuật ngữ nhất quán.; Nhánh thành công chưa thể hiện ranh giới quan trọng của READY_FOR_DOWNSTREAM_REVIEW: vẫn giữ IN_REVIEW, không phê duyệt, không tạo baseline và không cho phép production; bổ sung ghi chú hoặc nhãn biên ngắn để tránh diễn giải sai trạng thái.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-016-0d9eff93.mmd — REVISE — Các actor PM / Product Owner, Architect, Operations và Specialist owners không được phần văn xuôi xác lập. Bổ sung mô tả vai trò và mục đích sử dụng tương ứng trong văn xuôi, hoặc bỏ các actor và liên kết này.; Các liên kết Report specification → Developer, Data-source mapping → Developer và Acceptance criteria → QA nêu quan hệ sử dụng cụ thể nhưng văn xuôi chỉ minh họa Developer và QA qua KPI definition. Bổ sung căn cứ trong văn xuôi, hoặc bỏ các liên kết chưa được hỗ trợ.; Nhãn “BA outputs” quá rộng và lặp lại ý danh sách artifact. Đổi thành nhãn phạm vi cụ thể được văn xuôi hỗ trợ, hoặc bỏ nút trung gian nếu không biểu đạt quan hệ bổ sung.; Sơ đồ không thể hiện mục đích sử dụng khác nhau của từng vai trò, dù đây là luận điểm chính của đoạn văn. Bổ sung nhãn quan hệ hoặc cấu trúc thể hiện Developer xây logic, QA kiểm thử và Business Owner đọc ý nghĩa quản trị.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-017-50d91435.mmd — REVISE — Bước “QA đối chiếu mẫu tính tay” không được phần văn bản hỗ trợ. Văn bản yêu cầu QA chuẩn bị ca kiểm thử khi hai thời điểm khác nhau; cần sửa bước theo đúng test basis này.; Nhánh escalation nối từ Architect và QA làm phát sinh điều kiện escalation không được nêu rõ. Văn bản chỉ xác định BA duy trì gói escalation khi ý nghĩa nghiệp vụ chưa được quyết; cần thể hiện điều kiện và chủ sở hữu này.; Sơ đồ bỏ trạng thái quyết định IN_REVIEW, khiến luồng từ xác định sự kiện đến xây dựng trông như đã được phê duyệt. Cần thể hiện điểm chờ Business Owner quyết định trước khi Developer xây dựng.; Sơ đồ không thể hiện lựa chọn giữa thời điểm xác nhận chứng từ, thời điểm xe đến kho khách, hoặc tách hai KPI. Đây là gateway nghiệp vụ cốt lõi; cần thể hiện hoặc giới hạn rõ sơ đồ chỉ mô tả trách nhiệm sau quyết định.; Nhãn “xác nhận nguồn và luồng dữ liệu” rộng hơn nội dung “xác nhận khả năng lấy dữ liệu”. Cần dùng nhãn bám sát thẩm quyền kỹ thuật đã nêu.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-018-49904b91.mmd — REVISE — Bước đối chiếu artifact nguồn thiếu các kiểm tra bắt buộc: định danh, trạng thái IN_REVIEW, phiên bản v0.9.0 và ngày 2026-08-07. Bổ sung tiêu chí này và thể hiện rõ IN_REVIEW không đồng nghĩa đã baseline hoặc phê duyệt.; Gateway thiếu đơn vị đo và thẩm quyền quyết định, dù prose xác định đây là nguồn hiểu sai chính. Bổ sung hai tiêu chí này.; Nhánh E --> BA ngụ ý mọi quyết định đều quay về BA, trái với bảng khi owner có thể là Architect, PM/Product Owner, Business Owner hoặc specialist owner. Chuyển tới owner có thẩm quyền, rồi quay lại bước đối chiếu artifact đã cập nhật.; Nhãn Tiêu thụ đầu ra theo vai trò quá mơ hồ. Nêu kết quả cụ thể: dùng artifact trong phạm vi vai trò và trạng thái hiện tại.; Nhãn khi cần quyết định không chỉ rõ điều kiện escalation. Gắn escalation với câu hỏi cần quyết định vượt thẩm quyền người nhận hoặc BA.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-019-3a12a041.mmd — REVISE — Hai actor Sales Manager và Warehouse Manager không được section xác nhận; prose chỉ nêu quản lý. Đổi thành actor được hỗ trợ hoặc bổ sung evidence trong prose.; Hai bước export bỏ mất điều kiện lọc quan trọng: Sales Order List theo tháng của Requested Delivery Date và Delivery Note List theo Actual Delivery Date. Ghi rõ điều kiện trong nhãn bước.; Nhãn XLOOKUP theo Sales Order ID không thể hiện giới hạn chỉ lấy một dòng khi đơn có nhiều Delivery Note ID. Thêm trạng thái hoặc chú thích giới hạn này để tránh mô tả sai dependency dữ liệu.; Nhãn Đếm dòng Y và Y mơ hồ và bỏ mất cách tính được chứng minh trong prose. Ghi rõ đếm dòng có On Time = Y và In Full = Y, dùng năm đơn export làm mẫu số, cho kết quả 2/5 = 40%.; Diagram không thể hiện các giá trị On Time trống cho đơn chưa giao và các trường hợp chưa có rule canonical. Thêm boundary hoặc chú thích rằng đây là thao tác thủ công hiện thời, không phải business rule canonical.; Diagram gần như lặp lại tuần tự prose nhưng chưa trực quan hóa rủi ro kiểm soát chính: chỉnh sửa thủ công, thiếu dấu vết nguồn, thời điểm export, phiên bản công thức và kiểm tra độc lập. Bổ sung boundary kiểm soát hoặc risk note để tạo giá trị giải thích.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-020-f00c4839.mmd — REVISE — Thiếu điều kiện kỳ báo cáo. Nhánh mẫu số phải chỉ nhận Sales Order hoàn tất trong khoảng 2026-07-01 00:00:00 đến 2026-07-31 23:59:59 theo Asia/Ho_Chi_Minh; hiện đơn hoàn tất ngoài kỳ vẫn có thể đi tới mẫu số.; Thiếu nguồn ordered_quantity. Gateway “Đủ toàn bộ lượng đặt hàng?” cần thể hiện dữ liệu từ Sales Order Line hoặc ghi rõ tổng ordered_quantity của Sales Order.; Thiếu điều kiện chỉ dùng Delivery Note hợp lệ. Phép cộng delivered_quantity và MAX(actual_delivery_date) phải loại chứng từ không hợp lệ theo BR-KPI-OTD-001.; Thiếu nhánh loại trừ đơn hủy trước hoàn tất. Đây là ngoại lệ được nêu rõ trong định nghĩa mẫu số.; Nhãn actual_completion_date = ngày giao cuối chưa đủ chính xác. Phải là MAX(actual_delivery_date) của các Delivery Note hợp lệ cho đơn đã giao đủ.; Thiếu ranh giới thẩm quyền. Diagram nên nhận diện logic là khuyến nghị đang chờ Business Owner, Sales Operations Owner và Data Owner xác nhận, tránh trình bày như quy tắc đã được phê duyệt.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-021-b3b08c13.mmd — REVISE — Thiếu cổng xác định mẫu số theo BR-KPI-OTIF-002. Thêm kiểm tra requested_delivery_date nằm trong kỳ báo cáo và delivery_status != CANCELLED; dòng ngoài phạm vi phải bị loại, không đi vào Không đạt OTIF hoặc mẫu số.; Nhánh đạt chỉ đi qua Đếm tử số, dễ hiểu sai rằng dòng đạt không được tính vào mẫu số. Mọi dòng đủ điều kiện phải được đếm vào mẫu số; dòng đạt đồng thời được đếm vào tử số.; Nhãn Ngày giao <= ngày hẹn? thiếu quy tắc múi giờ. Ghi rõ so sánh ngày địa phương của actual_delivery_timestamp tại Asia/Ho_Chi_Minh với requested_delivery_date.; Nhãn DELIVERED? mơ hồ về trường nguồn. Ghi cụ thể delivery_status = DELIVERED? để khớp BR-KPI-OTIF-001.; Công thức OTIF = tử số / mẫu số thiếu nhân 100 và làm tròn hai chữ số thập phân theo BR-KPI-OTIF-003. Sửa nhãn kết quả cho đủ công thức.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-022-3ea766ea.mmd — REVISE — Thiếu phụ thuộc /01-curriculum/TEMPLATE_MANIFEST.md dù phần văn xác định đây là nguồn canonical cho template dự kiến. Bổ sung nguồn này vào chuỗi phụ thuộc.; Nhãn KPI definition and report output ngụ ý chapter tạo định nghĩa KPI, trái với tuyên bố chapter không sao chép định nghĩa KPI-OTIF-001. Đổi nhãn để thể hiện chapter liên kết nguồn canonical, tính và trình bày kết quả.; Bước Consumer decision or follow-up không được phần văn hỗ trợ. Xóa bước này hoặc bổ sung nội dung xác định rõ người dùng, quyết định hay hành động tiếp theo.; Ba nhãn nguồn canonical bỏ tiền tố /01-curriculum/, làm đường dẫn kém cụ thể và không song song với CHAPTER_MANIFEST.md. Dùng đường dẫn đầy đủ như phần văn.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-024-0bea3db2.mmd — REVISE — Hai cạnh nét đứt A -. không thông báo .-> D và A -. không cập nhật .-> F mơ hồ: chúng có thể bị hiểu là phụ thuộc trực tiếp từ từ điển dữ liệu đến dashboard và test case, trong khi luồng chính đi qua đặc tả KPI, API và Acceptance Criteria. Cần biểu diễn rõ đây là kiểm soát thay đổi bị thiếu trên chuỗi phụ thuộc, không phải luồng dữ liệu song song.; Sơ đồ chỉ nêu thiếu thông báo và cập nhật, nhưng phần văn xuôi định nghĩa thay đổi im lặng còn thiếu version mới, lịch sử thay đổi và đánh giá tác động. Cần thể hiện đủ các điều kiện kiểm soát trọng yếu hoặc giới hạn rõ sơ đồ chỉ minh họa một phần.; Sơ đồ chưa thể hiện hậu quả cốt lõi: dashboard vẫn chạy nhưng KPI OTIF đổi nghĩa và số liệu sai vẫn có vẻ hợp lý. Cần làm rõ trạng thái hoặc kết quả này để chuỗi lan truyền giải thích đúng rủi ro.; Nhãn không cập nhật thiếu đối tượng và chủ thể, nên không rõ artifact nào phải cập nhật tham chiếu, version hoặc test case. Cần dùng nhãn cụ thể, song song với không thông báo.; Nhãn trộn tiếng Việt và tiếng Anh (Acceptance Criteria, Test case) làm giảm tính nhất quán. Cần dùng thuật ngữ nhất quán với văn phong và thuật ngữ của chương.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-025-5a31a49e.mmd — REVISE — Luồng Kiểm thử dữ liệu tổng hợp chỉ dẫn tới báo cáo, bỏ trạng thái kiểm thử không đạt. Bổ sung nhánh đạt/không đạt; nhánh không đạt quay lại định nghĩa hạt dữ liệu, điều kiện lọc hoặc công thức.; Nhãn Định nghĩa KPI quá rộng so với tiêu chí bắt buộc trong phần văn bản. Làm rõ định nghĩa gồm tên đo được, đơn vị, kỳ đo, ngưỡng, múi giờ, thời điểm chốt và người chịu trách nhiệm.; Luồng không thể hiện bước kiểm tra tử số, mẫu số, tập bị loại và lý do loại trước khi công bố tỷ lệ. Bổ sung nội dung này vào bước kiểm thử hoặc thành bước kiểm tra riêng.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-026-3488d4da.mmd — REVISE — Nhánh “Không” kết thúc tại sửa artifact nhưng không nêu giới hạn BA chỉ được sửa mô tả, liên kết và cách trình bày; cần thể hiện ranh giới không tự xác nhận kế toán, pháp lý, tuân thủ hoặc approval.; Bước “Xác định owner có thẩm quyền” quá mơ hồ; cần chỉ rõ điều kiện chuyển Accounting Owner, Legal/Compliance Owner hoặc Privacy Owner theo loại KPI và dữ liệu.; Bước “Đính chính định nghĩa hoặc nguồn dữ liệu” không nêu actor, dễ hiểu BA được tự sửa nội dung cần xác nhận; cần gắn hành động với owner phù hợp hoặc thể hiện owner xác nhận trước khi đính chính.; Luồng kết thúc sau “Tính lại và ghi phiên bản thay đổi”, bỏ thiếu yêu cầu giữ công thức cũ và mới, không ghi đè artifact kiểm soát, và tái phát hành có ghi thay đổi khi sửa số lịch sử.; Không có điều kiện cho KPI liên quan VND, doanh thu, chi phí, biên lợi nhuận, thuế, hóa đơn hoặc dữ liệu cá nhân; cần thể hiện ngoại lệ bắt buộc xác minh với owner chuyên trách.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-027-5f05f9fd.mmd — REVISE — Cạnh Requirement ID --> Business Rule ID khẳng định quan hệ phụ thuộc có hướng nhưng phần văn xuôi chỉ yêu cầu KPI liên kết với requirement và business rule; không xác lập requirement tạo ra business rule. Cần bỏ hướng suy diễn hoặc chỉ biểu diễn quan hệ được nguồn xác nhận.; Sơ đồ không thể hiện liên kết trực tiếp giữa KPI Definition ID và Requirement ID, dù bảng yêu cầu KPI liên kết requirement, rule, data field và test. Cần biểu diễn đủ liên kết truy vết này.; Các nhãn Requirement ID, Business Rule ID và Data Field ID không cho biết ID phải là ID canonical từ các registry được nêu. Cần làm rõ tính canonical hoặc gắn registry tương ứng để tránh chấp nhận ID cục bộ.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-028-5cda2314.mmd — REVISE — Nút quyết định “Đủ thẩm quyền và bằng chứng?” gộp hai điều kiện độc lập, nên nhánh “Có/Không” không xử lý trường hợp chỉ thiếu một điều kiện. Cần tách hoặc biểu đạt rõ yêu cầu đồng thời có đủ bằng chứng và quyết định có thẩm quyền.; Nút “Ghi assumption hoặc Verification required” nhập nhằng hai trạng thái khác nhau và cho phép dùng assumption thay cho xác minh. Cần ghi nhận assumption chưa xác minh đồng thời nêu verification required khi thiếu bằng chứng hoặc thẩm quyền.; Sơ đồ bỏ thiếu các chủ thể xác minh nêu trong bảng: Business Owner, Architect và Accounting Owner khi KPI ảnh hưởng ghi nhận doanh thu. Cần thể hiện đúng owner theo loại nội dung cần xác minh.; Nhánh “Khuyến nghị có căn cứ” chưa thể hiện điều kiện hiệu lực bắt buộc: nguồn dữ liệu, quy tắc tính và chủ thể quyết định phải được ghi nhận trong artifact kiểm soát. Cần gắn điều kiện này trước kết quả sử dụng KPI.; Sơ đồ không thể hiện ranh giới quan trọng giữa candidate definition dùng cho học liệu và KPI vận hành chính thức. Cần cho thấy nhánh thiếu xác minh chỉ cho phép minh họa có điều kiện, không cho phép công bố KPI chính thức.; Nhãn “Tham chiếu quyết định được ghi nhận” chưa xác định quyết định nằm trong artifact nào hoặc có approval/baseline hay không. Cần dùng nhãn cụ thể phù hợp yêu cầu artifact kiểm soát và quyết định có thẩm quyền.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-029-d91b5052.mmd — REVISE — Nhánh “Không” yêu cầu “Dùng artifact canonical làm nguồn tham chiếu”, nhưng phần văn xuôi không xác nhận có artifact canonical và còn cấm gọi bản nháp là canonical. Sửa nhánh này để chỉ dùng nguồn đã được cấp, không gán trạng thái canonical.; Nhãn “Ghi Verification required cho template mới” mơ hồ, trộn ngôn ngữ và giả định có template mới. Sửa thành hành động cụ thể, phù hợp nội dung: ghi nhận rằng ID và filename cần được xác minh trước khi sử dụng.; Sơ đồ thiếu kết quả kiểm soát quan trọng của nhánh “Không”: không tự tạo Template ID và không suy diễn artifact đã hoàn tất. Thêm kết quả này để tránh hướng dẫn sai.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-030-dac2500b.mmd — REVISE — Các nhãn "Tra manifest chapter", "Tra ID, rule, data canonical" và "Đối chiếu nguồn và boundary" dùng thuật ngữ mơ hồ, pha trộn Việt-Anh và không được phần văn xuôi định nghĩa; cần thay bằng tên artifact, trường hoặc nguồn kiểm soát cụ thể đã nêu trong section.; Sơ đồ không thể hiện các điều kiện xác nhận quan trọng: Section 12, trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07, locale vi-VN và múi giờ Asia/Ho_Chi_Minh; cần thể hiện tiêu chí kiểm tra hoặc kết quả đạt/không đạt.; Luồng chỉ có chuỗi tuyến tính, không có nhánh khi metadata, trạng thái hoặc nguồn kiểm soát không khớp; cần bổ sung gateway và hành động xử lý sai lệch nếu checklist nhằm xác nhận tính đúng.; Bước đầu và bước cuối đều mô tả đọc chapter artifact/artifact Nova Foods nhưng không làm rõ khác biệt; cần phân biệt artifact hướng dẫn với artifact đã điền tại Section 12.; Sơ đồ gần như lặp lại câu mô tả checklist nhưng không làm rõ owner, quyết định, boundary hay kết quả xác nhận; cần bổ sung giá trị giải thích thay vì chỉ tuần tự hóa thao tác.
assets/diagrams/15-reporting-biometrics-and-kpi-definition-031-dbd228b3.mmd — REVISE — Nhánh G --> E ngụ ý mọi xác minh đều dẫn đến trạng thái sẵn sàng handoff. Cần thể hiện kết quả xác minh: mâu thuẫn được xử lý thì quay lại đối chiếu hoặc đi tiếp; chưa được xử lý thì tiếp tục chờ và không handoff.; Nhãn owner escalation đưa thêm vai trò owner không được section xác định. Cần dùng vai trò có trong prose, như người có thẩm quyền, hoặc bổ sung định nghĩa owner vào prose.; Bước Đánh dấu sẵn sàng handoff review chưa nêu rõ đây không phải phê duyệt. Cần dùng nhãn kết quả loại trừ cách hiểu APPROVED, BASELINED, compliant hoặc production-ready.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-001-16ef7d09.mmd — REVISE — Gateway chỉ có nhánh “Không”; thiếu nhánh “Có” và trạng thái kết thúc tương ứng, làm luồng quyết định không đầy đủ.; Gateway đối chiếu với “phiếu mua 10.000 kg”, trong khi Facts xác định chênh lệch so với phiếu nhận hàng GRN-SIM-260807-01; cần ghi rõ chứng từ và điều kiện đối chiếu nhất quán.; Bước “Ghi giao dịch điều chỉnh có lý do” không nêu actor hoặc thẩm quyền thực hiện; cần gắn với vai trò được section hỗ trợ và không ngụ ý Trưởng kho có quyền phê duyệt quy tắc vận hành.; Kết quả “Cập nhật số lượng được xác minh” mơ hồ, có thể bị hiểu là sửa bản ghi ban đầu; cần thể hiện bản ghi ban đầu được giữ nguyên và số lượng sổ kho thay đổi qua giao dịch điều chỉnh riêng.; Diagram chỉ mô tả O2, không thể hiện đây là khuyến nghị BA chưa được Business Owner phê duyệt; cần thể hiện ranh giới khuyến nghị hoặc trạng thái chưa phê duyệt để tránh biến đề xuất thành workflow có hiệu lực.; Diagram không biểu diễn điều kiện xác minh thất bại, thiếu chứng từ hoặc chênh lệch chưa được chấp nhận; cần có nhánh ngoại lệ để tránh ngụ ý mọi yêu cầu đều dẫn tới điều chỉnh.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-002-1c28f73e.mmd — REVISE — Sơ đồ chỉ thể hiện chuỗi bước tuyến tính, nhưng bỏ các nhánh phương án cốt lõi được nêu trong đoạn văn: sửa trực tiếp và tạo giao dịch điều chỉnh. Cần thể hiện các phương án được so sánh.; Nhãn “Đánh giá theo tiêu chí” quá chung chung. Cần nêu các tiêu chí được đoạn văn hỗ trợ: lý do điều chỉnh, người xác minh, dữ liệu phải lưu và khả năng bảo toàn truy vết.; Nhãn “Khuyến nghị có truy vết” mơ hồ vì không rõ truy vết thuộc khuyến nghị hay phương án được chọn. Cần diễn đạt rõ khuyến nghị ưu tiên phương án bảo toàn dấu vết thay đổi, người thực hiện, thời điểm, lý do và chứng từ.; Sơ đồ bỏ rủi ro trọng yếu khi chọn sửa trực tiếp: dữ liệu có thể khớp vật lý nhưng mất dấu vết kiểm soát. Cần thể hiện rủi ro hoặc kết quả này trong luồng đánh giá.; Hai bước “Xác định vai trò có thẩm quyền” và “Quyết định được ghi nhận bởi vai trò có thẩm quyền” lặp ý nhưng chưa phân biệt người xác minh với người phê duyệt hoặc ra quyết định. Cần làm rõ trách nhiệm theo đúng các vai trò được phần nội dung xác định, không tự đặt tên vai trò mới.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-003-d7297420.mmd — REVISE — Gateway Có Delivery Priority? mơ hồ: không rõ hỏi có trường hay có giá trị; hai nhánh Trước: ghi chú tự do và Sau: giá trị có cấu trúc không phải câu trả lời song song cho gateway. Cần dùng điểm tách so sánh trước/sau hoặc điều kiện có/không có dữ liệu ưu tiên có cấu trúc.; Luồng sau bỏ qua bước chuyển Delivery Priority từ đơn bán sang danh sách xử lý kho. Đây là ranh giới giao diện và rủi ro chính của section: trường có thể xuất hiện tại bán hàng nhưng không tới kho. Cần thể hiện bước truyền dữ liệu hoặc kết quả truyền thất bại.; Nhãn Kho thấy Delivery Priority gộp giao diện, trạng thái dữ liệu và kết quả quan sát, nên che mất điều kiện kiểm tra bằng đơn bán và danh sách kho. Cần phân biệt dữ liệu trên đơn bán với dữ liệu xuất hiện trong danh sách kho.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-004-af0f8f1d.mmd — REVISE — Gateway B equates presence of a source or checkable evidence with verified fact. Require evidence already checked against an identified source.; Flow treats Fact, Stakeholder input, Project assumption, and Verification-required claim as mutually exclusive residual categories. Prose allows stakeholder input to retain its type while being traced or verified; model classification dimensions without forcing unsupported exclusivity.; Path to Verification-required claim is wrong. Prose defines it by potential impact on rule, compliance, architecture, or operations plus missing authoritative verification, not by failure to qualify as stakeholder input or temporary assumption. Add those criteria.; Project assumption path omits mandatory verification condition, verification owner, and impact if false. Show these controls or indicate assumption remains incomplete until recorded.; Decision gateway omits comparison between options and defined criteria. Replace generic 'Có lựa chọn' condition with decision requirements supported by prose: options, criteria, recorded choice, and defined authority.; All four information categories feed Decision directly, implying any item can become a decision. Show them as inputs or evidence for option evaluation, not direct predecessor states.; Decision outcome omits explicit boundary that decision is not approval and that IN_REVIEW does not prove baseline, approval, production readiness, or compliance. Add boundary where diagram could otherwise imply authorization.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-005-6f909252.mmd — REVISE — Nhãn Entry: nhu cầu được ghi nhận đặt trên chuyển tiếp Discovery → Analysis nhưng mô tả entry gate của Discovery. Sửa nhãn chuyển tiếp thành điều kiện vào Analysis: có problem statement và phạm vi tác động sơ bộ.; Chuyển tiếp Analysis → Delivery dùng recommendation có evidence, chưa thể hiện recommendation phải đi qua cơ chế quyết định dự án; IN_REVIEW không phải approval. Sửa nhãn để không hàm ý recommendation tự động cho phép Delivery.; Nhãn Testing → Release ghi kết quả test đạt gate release, trong khi section chỉ yêu cầu kết quả test cho biết đáp ứng hay không đáp ứng tiêu chí và Release còn cần quyết định release theo governance. Sửa nhãn để gồm bằng chứng test và quyết định release, không mặc định test đạt.; Nhãn Release: Đưa vào môi trường phát hành mơ hồ và gần như lặp tên pha. Sửa thành kết quả cụ thể được section hỗ trợ: thay đổi được phát hành theo quy trình áp dụng.; Các nhãn chuyển tiếp không song song: nhãn đầu dùng Entry, các nhãn sau dùng Exit, còn vòng phản hồi không dùng gate. Chuẩn hóa theo điều kiện chuyển pha để ranh giới lifecycle rõ.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-006-992e6b1b.mmd — REVISE — Nút "Legal/Accounting Owner" gộp hai thẩm quyền độc lập. Tách thành Legal Owner và Accounting Owner; nối từng nhánh theo đúng phạm vi quyết định.; Nhánh "kiểm thử" tới QA Lead gây hiểu rằng QA sở hữu mọi quyết định kiểm thử. Thể hiện QA Lead sở hữu kết quả kiểm thử; Process Owner và Delivery Lead xử lý test basis mơ hồ hoặc behavior lệch rule.; Luồng BA tới Delivery Lead ghi "sau quyết định được ghi nhận" nhưng không có đường từ gateway quyết định trở lại luồng giao hàng. Nối kết quả quyết định đã ghi nhận với handoff sang Delivery Lead.; Chuỗi Delivery Lead tới QA Lead tới Release Manager tới Operations Owner không có nhãn, nên thiếu artifact, điều kiện và ranh giới thẩm quyền. Gắn nhãn handoff tương ứng: traceability và acceptance criteria; kết quả kiểm thử và known issues; trạng thái phát hành và runbook reference.; Release Manager xuất hiện như điểm quyết định duy nhất trước vận hành, trong khi Business Owner sở hữu quyết định release và BA không được phép release. Thể hiện Business Owner trong release decision package và Release Manager trong vai trò phát hành.; Luồng bỏ Test Analyst và Service Desk dù bảng xác định họ là downstream receiver. Thêm hai actor tại handoff tương ứng hoặc thu hẹp sơ đồ rõ ràng thành sơ đồ định tuyến thẩm quyền thay vì mô tả toàn bộ lifecycle.; Luồng bỏ các escalation quan trọng về dữ liệu cá nhân, tiền, tồn kho, truy xuất lô, quyền dữ liệu và sự cố vận hành. Thể hiện các nhánh ngoại lệ cùng owner liên quan hoặc giới hạn phạm vi sơ đồ để không ngụ ý coverage đầy đủ.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-007-dafdbb90.mmd — REVISE — Section supports only lifecycle positioning of solution-options work; diagram invents detailed stages, four gates, loopbacks, release criteria, and operational feedback without prose support. Add prose defining each flow element or remove unsupported elements.; Gate wording implies formal decision points despite disclaimer that diagram does not confirm approvals. Rename them as non-approval review questions or state explicitly in prose that gates are illustrative checks, not governance approvals.; No actors or owners appear for analysis, option comparison, testing, release, or operations. Identify responsible roles where ownership matters or state that role assignment is intentionally outside diagram scope.; Failure branches are incomplete and potentially misleading: failed testing and failed release readiness return only to Delivery, although causes may require Analysis or option reassessment. Support this routing in prose or show applicable return paths.; Labels such as "đủ rõ", "so sánh được", "bản kiểm thử", and "cho phép phát hành" lack concrete criteria. Define measurable conditions or replace them with criteria grounded in surrounding section.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-008-ffe83c3c.mmd — REVISE — Nhãn “Bằng chứng mô phỏng” không được phần văn xuôi định nghĩa và dễ mâu thuẫn với yêu cầu bằng chứng có xuất xứ xác định. Cần dùng nhãn chỉ loại bằng chứng được nêu rõ: hiện trạng, nhu cầu, quy tắc, dữ liệu hoặc giới hạn.; Chuỗi mũi tên biểu thị “Bằng chứng mô phỏng” tạo ra “Artifact nguồn”, rồi artifact tạo ra “Canonical ID”. Phần văn xuôi mô tả artifact là vật chứa bằng chứng và Canonical ID là mã định danh ổn định của artifact, không phải các bước chuyển đổi tuần tự. Cần thể hiện đúng quan hệ chứa/định danh hoặc đổi nhãn bước để làm rõ hành động của BA.; “Hiểu nghiệp vụ tối thiểu” thiếu chủ thể và tiêu chí hoàn thành. Cần làm rõ BA thu thập đủ hiểu biết nghiệp vụ để nhận diện và kiểm tra bằng chứng, thay vì ngụ ý đây là trạng thái đầu vào tự có.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-009-0fe7c968.mmd — REVISE — Luồng thiếu kiểm tra «Đủ bằng chứng»: claim phải nối được với nguồn và reasoning bridge; không đạt phải loại claim khỏi so sánh hoặc dừng khi cần xác minh input.; Luồng thiếu các điều kiện dừng đã nêu: hai nguồn canonical mâu thuẫn; giả định bị biến thành fact; người ghi nhận không có quyền nhưng bị gán Authority. Bổ sung gateway và nhánh STOP tương ứng.; Gateway «Freshness và owner rõ?» gộp hai tiêu chí khác nhau, làm mất trường hợp owner tài liệu bị nhầm với authority chuyên môn. Tách kiểm tra freshness, ownership và authority.; Gateway «Claim vượt authority pháp lý, kế toán, bảo mật, kiến trúc?» không khớp điều kiện dừng. Claim không «vượt authority»; vấn đề là kết luận bắt buộc thuộc phạm vi pháp lý, kế toán, thuế, dữ liệu cá nhân hoặc an toàn thực phẩm nhưng chưa được authority phù hợp xác minh. Sửa phạm vi và điều kiện cụ thể; không tự thêm kiến trúc thay cho các phạm vi đã nêu.; Luồng thiếu kiểm tra safe use boundary, gồm licensed-text verification và giới hạn không diễn giải luật thành tư vấn pháp lý. Bổ sung gateway; vi phạm phải dừng claim và yêu cầu vai trò chuyên môn xác minh.; Kết quả «Được dùng làm evidence có nhãn» quá rộng. Chỉ cho phép khi claim nằm trong ranh giới sử dụng, đủ bằng chứng và không còn yêu cầu xác minh; nêu điều kiện này trong nhãn hoặc luồng trước kết quả.; Nhánh escalation luôn đi thẳng tới STOP nhưng không thể hiện trạng thái IN_REVIEW được yêu cầu khi authority chưa phù hợp. Bổ sung trạng thái này trước hoặc cùng kết quả STOP.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-010-52890c98.mmd — REVISE — Luồng từ Điểm cần xác minh vào So sánh phương án có traceability gây hiểu rằng NF-VERIFY-001 đến NF-VERIFY-003 được dùng để chấm phương án. Phần văn xuôi yêu cầu không chấm FEFO, không tuyên bố khả năng tích hợp hóa đơn điện tử và không thiết kế workflow khi chưa xác minh. Cần thể hiện điều kiện chặn hoặc tách các mục này khỏi đầu vào chấm điểm cho đến khi owner xác minh.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-011-0bea27f1.mmd — REVISE — Sơ đồ trình bày O2 như quy trình vận hành đã có hiệu lực, trong khi phần văn xuôi giới hạn quyết định ở trạng thái IN_REVIEW. Cần thể hiện rõ ranh giới này để tránh ngụ ý O2 đã được phê duyệt.; Gateway Quy tắc hoặc lô bị chặn? gộp hai điều kiện khác loại và không nêu điều kiện kiểm tra cụ thể. Cần tách hoặc làm rõ kiểm tra vi phạm quy tắc cấp phát và trạng thái lô bị chặn.; Nhánh Escalate Business Owner và Solution Architect gán đồng thời hai owner cho mọi ngoại lệ, trái với phân quyền trong bảng: Business Owner xác nhận quy tắc; Solution Architect xác nhận khả năng ERP và tích hợp. Cần định tuyến theo loại vấn đề.; Node J không có kết quả tiếp theo, nên ngoại lệ lô bị chặn hoặc quy tắc chưa xác nhận kết thúc mơ hồ. Cần thể hiện kết quả như chờ quyết định, từ chối cấp phát hoặc quay lại chọn lô sau xác nhận.; Nhánh đổi lô đi thẳng tới ghi cấp phát nếu gateway trả lời Không, nhưng không thể hiện kiểm tra tồn của lô thay thế. Điều này có thể ngụ ý hệ thống cho phép xuất vượt tồn, trái với tiêu chí quyết định. Cần thêm kiểm tra tồn khả dụng trước khi ghi cấp phát.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-012-0218cd3b.mmd — REVISE — Nhánh PENDING hoặc FAIL hẹp hơn khuyến nghị O2 là chặn mọi trạng thái khác PASS. Sửa điều kiện thành khác PASS, hoặc bổ sung căn cứ xác nhận chỉ tồn tại ba trạng thái.; Bước QC cập nhật trạng thái lô và vòng lặp về gateway tạo quy trình xử lý sau khi chặn nhưng section không xác nhận trigger, trách nhiệm thao tác hoặc luồng cập nhật này. Xóa bước và vòng lặp, hoặc bổ sung bằng chứng quy trình tương ứng trong prose.; Gateway ProductionLot.qc_status không diễn đạt hành động kiểm tra. Đổi nhãn thành điều kiện cụ thể như qc_status = PASS? để hai nhánh rõ, song song và không nhập nhằng.; Diagram trình bày PASS, PENDING, FAIL như trạng thái đã chốt, trong khi prose gọi chúng là giá trị dự kiến và chưa được QA/QC Owner xác nhận. Gắn rõ tính dự kiến hoặc tránh mô tả chúng như baseline đã phê duyệt.; Diagram không thể hiện ngoại lệ dù khả năng xử lý ngoại lệ là tiêu chí quyết định và prose cảnh báo chặn quá rộng có thể làm chậm giao hàng hợp lệ. Bổ sung nhánh ngoại lệ cần review, hoặc giới hạn rõ diagram chỉ mô tả luồng mặc định.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-013-ebc4bd8e.mmd — REVISE — Luồng chỉ thể hiện ba nhóm kiểm tra, bỏ sót điều kiện Quyết định và phần lớn điều kiện Truy vết; bổ sung gateway cho lý do khuyến nghị, giới hạn authority, ngày, người ghi nhận, lý do thay đổi và artifact bị ảnh hưởng.; Gateway “Đủ ID, phiên bản, lịch sử?” quá gộp và không bao quát tên tệp, Status: IN_REVIEW, ngày 2026-08-07, Asia/Ho_Chi_Minh, artifact canonical và TRACEABILITY_ID_REGISTRY; dùng nhãn cụ thể theo điều kiện Nhận diện.; Gateway “Evidence và giả định phân biệt?” bỏ sót fact, nguồn, điểm cần xác minh và rủi ro suy diễn nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm; mở rộng điều kiện theo hàng Nguồn gốc.; Gateway “Tiêu chí áp dụng đồng đều?” bỏ sót phạm vi, tác động, giới hạn, chi phí, rủi ro, dependency và consequence; nêu đủ cơ sở so sánh bắt buộc.; Outcome “Trả về soạn thảo” không được section quy định; thay bằng outcome không đạt cổng hoặc bổ sung prose xác lập việc trả về soạn thảo.; Các nhánh không đạt hội tụ vào X nhưng không chỉ rõ điều kiện thất bại và hậu quả tương ứng; giữ nguyên lý do không đạt hoặc tạo outcome cụ thể cho từng nhóm kiểm tra.; Nhãn trộn tiếng Anh và tiếng Việt như “Evidence” làm giảm tính nhất quán; dùng “Bằng chứng” và giữ wording song song giữa các gateway.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-014-6405dd57.mmd — REVISE — Sơ đồ chỉ lặp lại danh sách consumer trong bảng và bỏ toàn bộ quan hệ giữa từng consumer, output tiêu thụ và cách dùng; cần thể hiện mapping này để tạo giá trị giải thích.; Nhãn "BA: option analysis output" nhập nhằng giữa owner và artifact; cần tách hoặc đặt tên cụ thể cho artifact phân tích phương án.; Các cạnh không có nhãn nên không cho biết nội dung nào được chuyển cho từng consumer; cần dùng nhãn cụ thể, song song với cột "Output tiêu thụ chính".; Ranh giới thẩm quyền của Specialist owners bị mất; cần thể hiện họ chỉ review evidence thuộc chuyên môn và không biến khuyến nghị BA thành kết luận chuyên môn.; Ràng buộc Developers không tự đổi rule nghiệp vụ bị mất; cần thể hiện boundary này nếu sơ đồ mô tả cách consumer sử dụng output.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-015-46c13655.mmd — REVISE — Luồng C --> BA --> E thể hiện mọi câu hỏi làm rõ đều dẫn đến escalation. Cần thêm điều kiện: BA tự làm rõ trong phạm vi thẩm quyền; chỉ escalation khi câu trả lời vượt thẩm quyền hoặc chạm pháp lý, kế toán, an toàn thực phẩm, bảo mật, kiến trúc hay vận hành thực tế.; Nút Escalation nếu vượt thẩm quyền không nêu owner nhận escalation hoặc kết quả cần ghi nhận. Cần chỉ rõ specialist owner phù hợp và trạng thái Verification required theo quy tắc của phần văn bản.; Nhãn Tiếp tục dùng mơ hồ và có thể khiến đầu ra IN_REVIEW, v0.9.0 bị hiểu như quyết định đã phê duyệt. Cần nêu hành động cụ thể, giới hạn ở việc dùng artifact cho bước công việc tiếp theo mà không coi là phê duyệt.; Gateway chỉ kiểm tra phạm vi, tiêu chí, giả định, nhưng quy tắc còn yêu cầu bằng chứng và vai trò trả lời. Cần đưa đủ các điều kiện này vào điểm kiểm tra hoặc nhánh làm rõ.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-016-52a05118.mmd — REVISE — Gateway "80 CTN đủ 120 CTN?" chỉ có nhánh "Không", nên ký hiệu quyết định gây hiểu nhầm rằng luồng còn thiếu nhánh "Có". Thêm kết quả khi đủ hàng hoặc đổi gateway thành bước kiểm tra tuyến tính cho case cố định này.; Nhãn "Không có nơi ghi 40 CTN từ LOT-ALM-260803-B" quá rộng, có thể bị hiểu là hệ thống không có nơi ghi nhận ở mọi ngữ cảnh. Nêu đúng ranh giới: không thể ghi thêm 40 CTN từ lô thứ hai trên cùng dòng xuất trong cùng lần xuất.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-017-f51bc882.mmd — REVISE — Sơ đồ thể hiện Finance Manager tham gia luồng mở chặn như quyền đã xác lập, trong khi phần Authority ghi quyền này chưa được xác định và chưa có phê duyệt. Cần biểu thị đây là vai trò đề xuất, phụ thuộc Business Owner và Accounting Owner phê duyệt trong artifact được kiểm soát.; Gateway “Có quyết định ngoại lệ hợp lệ?” dùng thể bị động và không nêu chủ thể, tiêu chí hợp lệ hoặc nguồn thẩm quyền. Cần gắn quyết định với người có thẩm quyền đã được xác lập và audit trail bắt buộc.; Luồng bắt đầu tính và khóa dựa trên Credit Exposure nhưng bỏ qua điều kiện tiên quyết rằng Accounting Owner phải xác minh công thức và nguồn dữ liệu trước cấu hình. Cần thể hiện ranh giới hoặc dependency xác minh này để tránh mô tả giả định dự án như quy tắc ERP đã duyệt.; Nhãn “Mở chặn đơn và lưu audit trail” chưa nói rõ ai thực hiện; chủ thể quan trọng vì quyền mở chặn đang là vấn đề kiểm soát. Cần dùng nhãn chủ động, cụ thể và phù hợp trạng thái thẩm quyền.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-018-364b9758.mmd — REVISE — Gateway lọc thiếu điều kiện availableQuantityKg > 0 từ BR-INV-003; bổ sung điều kiện này.; Bước sắp xếp thiếu quy tắc hòa lotCode tăng dần từ BR-INV-002; bổ sung tiêu chí phụ.; Luồng không kiểm tra tổng lượng đủ requiredQuantityKg; bổ sung gateway đủ/không đủ và kết quả INSUFFICIENT_ELIGIBLE_STOCK theo BR-INV-004.; Luồng mô tả OPT-02 nhưng bỏ nhánh ghi đè và yêu cầu lưu lý do; bổ sung nhánh nhân viên chấp nhận hoặc ghi đè kèm overrideReason.; Nhãn Không dẫn riêng tới LOT-COC-260720-C khiến gateway tổng quát trông như chỉ loại lô này; đổi thành bước loại mọi lô không đủ điều kiện, có thể ghi C như ví dụ.; Sơ đồ chưa thể hiện đây là đề xuất IN_REVIEW, chưa được Business Owner và Quality Owner xác nhận; thêm ranh giới hoặc trạng thái xác minh để tránh ngụ ý quy trình đã được phê duyệt.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-019-f304125e.mmd — REVISE — Cạnh SM --> CM không được prose hỗ trợ. /00-research/00_SOURCE_MAP.md là nguồn canonical độc lập mà handbook dẫn nguồn trực tiếp, không phải upstream của /01-curriculum/CHAPTER_MANIFEST.md. Sửa thành SM --> H.; Nhãn Template hoặc artifact delivery dùng liên kết mơ hồ, trộn hai loại đầu ra và không nêu liên kết tới nguồn canonical nào. Cần dùng nhãn cụ thể, song song với prose, hoặc bỏ node nếu không thể hiện dependency riêng.; Cạnh H --> T có thể khiến người đọc hiểu handbook là nguồn canonical cho template hoặc artifact delivery. Cần làm rõ handbook chỉ hướng dẫn dùng và giữ liên kết tới nguồn canonical, không cung cấp định nghĩa thay thế.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-020-d62c69d3.mmd — REVISE — Thiếu liên kết trực tiếp REQ --> TC dù bảng nêu REQ được truy vết tới TC và TC liên kết với REQ. Bổ sung liên kết này.; Thiếu quan hệ giữa DATA/API và AC dù hàng DATA/API nêu AC là đích sử dụng. Bổ sung liên kết phù hợp và giữ hướng mũi tên nhất quán với quy ước truy vết.; NEED được bảng mô tả liên kết tới REQ và quyết định phương án, nhưng sơ đồ chỉ thể hiện REQ. Bổ sung nút quyết định phương án cùng liên kết, hoặc giới hạn rõ phạm vi sơ đồ nếu quyết định phương án nằm ngoài mô hình.; Hướng mũi tên chưa được prose định nghĩa rõ: bảng mô tả nguồn canonical và đích sử dụng, không xác nhận mọi quan hệ là chuỗi phụ thuộc một chiều. Thêm chú thích quy ước mũi tên hoặc điều chỉnh hướng theo nghĩa truy vết canonical.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-021-bf619038.mmd — REVISE — Nhãn "REQ BR AC DATA/API TC review" mơ hồ và không song song; thiếu TRACEABILITY_ID_REGISTRY, OpenAPI contract và nguồn pháp lý hoặc chuẩn. Cần thể hiện đầy đủ các dependency phải rà soát hoặc dùng nhãn khái quát có phạm vi rõ.; Luồng không thể hiện owner bắt buộc cho thay đổi dữ liệu nhạy cảm và nguồn pháp lý: Architect, Security, Legal, Accounting, Compliance hoặc domain owner. Cần gắn owner vào bước review tương ứng.; Nhánh "Consumer cập nhật hoặc ghi no-impact evidence" gộp hai kết quả nhưng không có điều kiện phân nhánh. Cần biểu diễn gateway giữa có tác động và không tác động.; Nhánh đổi im lặng chỉ bắt đầu từ canonical source, trong khi bảng còn nêu OpenAPI contract, AC và registry như dependency nguồn có thể đổi. Cần mở rộng điểm phát sinh để tránh hiểu sai phạm vi.; Các hậu quả thiếu link chết, coverage giả, lộ dữ liệu nhạy cảm và release gate sai; đây là rủi ro trọng yếu trong bảng. Cần bổ sung hoặc gom dưới nhãn hậu quả đủ bao quát.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-022-a3f9ceb0.mmd — REVISE — Nhánh “Thiếu bằng chứng” quay về “Liệt kê phương án” sai logic. Thiếu bằng chứng cần dẫn tới thu thập bằng chứng hoặc điều chỉnh tiêu chí trước khi so sánh lại.; Luồng bỏ qua bước kiểm tra phương án theo thứ tự được nêu rõ: thay đổi quy trình, cấu hình chuẩn, báo cáo chuẩn, tích hợp hiện hữu, rồi mới phát triển.; Luồng không thể hiện việc tách từng decision point, dù section xác định gộp nhiều quyết định là anti-pattern.; Bước “So sánh trade-off” không bao gồm consequence và impact nếu chọn sai. Đây là phần kiểm soát rủi ro trọng yếu của section.; Nhãn “Cập nhật artifact và traceability” mơ hồ và trộn tiếng Anh không cần thiết. Cần nêu cụ thể hồ sơ quyết định và liên kết truy vết nào được cập nhật.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-023-7b07a6ff.mmd — REVISE — Nhãn DungCauHinh mơ hồ và không phải trạng thái được nêu trong phần văn xuôi; đổi thành trạng thái cụ thể phản ánh việc chưa chọn phương án hoặc chưa được phê duyệt.; Nhánh ChoXacNhan --> DuocGhiNhan chỉ yêu cầu “quyết định được ghi nhận”, nhưng bỏ qua thẩm quyền quyết định; điều kiện phải thể hiện Business Owner quyết định, Warehouse Owner xác nhận quy trình kho và Architect đánh giá khả thi kỹ thuật.; Sơ đồ không thể hiện ba phương án cần cân nhắc: cảnh báo, chặn cứng và override có ghi nhận. Bổ sung nhánh lựa chọn hoặc giới hạn sơ đồ rõ ràng thành vòng đời phê duyệt đề xuất.; Sơ đồ kết thúc tại DuocGhiNhan nhưng không phân biệt quyết định, baseline reference và approval reference; sửa kết quả cuối để không hàm ý ghi nhận đồng nghĩa phê duyệt.; Sơ đồ bỏ mất kết quả bắt buộc khi thiếu bằng chứng: không sửa dữ liệu kho, không phát hành cấu hình và không gọi phương án là đã phê duyệt. Thể hiện ranh giới này tại trạng thái chờ quyết định.; Chuyển tiếp DeXuat --> ChoXacNhan: có nhu cầu kiểm soát không mô tả hành động hay sự kiện rõ ràng; dùng điều kiện cụ thể như hoàn tất phân tích phương án và tiêu chí để chuyển sang chờ quyết định.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-024-ca19a523.mmd — REVISE — Nhánh “Ký pháp được gọi đúng chuẩn?” và hành động “Sửa nhãn hoặc vẽ lại” không được phần văn xuôi hỗ trợ; xóa khỏi sơ đồ hoặc bổ sung căn cứ trong phần văn xuôi.; Sơ đồ không thể hiện quyết định cốt lõi: chọn phương án C, giữ ngưỡng 30 ngày dưới dạng project assumption và không cấu hình chặn xuất kho; bổ sung nhánh và kết quả này.; Sơ đồ bỏ sót ranh giới thẩm quyền: Principal IT Business Analyst / Technical Curriculum Author chỉ quản trị artifact, còn Business Owner và Food-safety/Legal Owner xác minh quy tắc; ghi rõ owner tại bước chuyển xác minh.; Các nút C, E, G, I và K là điểm cụt, không cho biết artifact tiếp tục ở IN_REVIEW, quay lại review hay dừng cấu hình/test; nối mỗi nhánh tới trạng thái hoặc hành động kết thúc được phần văn xuôi quy định.; Nhãn “Có một cách hiểu?” mơ hồ; đổi thành điều kiện cụ thể về việc requirement chỉ cho phép một diễn giải vận hành.; Nhãn “Nối được tới rule data decision test?” thiếu từ nối và không ánh xạ rõ các artifact canonical; ghi cụ thể liên kết tới business rule, data dictionary, decision, test và traceability ID.; Sơ đồ bỏ sót biện pháp khôi phục an toàn: dừng cấu hình hoặc test dựa trên câu mơ hồ, giữ dữ liệu mô phỏng, ghi Verification required, chuyển câu hỏi cùng bằng chứng nguồn cho đúng owner và không sửa lịch sử; thể hiện các hành động này trên nhánh thiếu căn cứ.; Kết quả “Đủ điều kiện review” có thể gây hiểu nhầm vì artifact đã ở IN_REVIEW; đổi thành kết quả phù hợp với trạng thái, chẳng hạn đủ bằng chứng để owner review, nhưng không hàm ý phê duyệt, baseline hoặc tuân thủ.; Sơ đồ không thể hiện hậu quả và ngoại lệ quan trọng: nguy cơ chặn nhầm lô, xuất nhầm lô hoặc tạo bằng chứng phê duyệt/tuân thủ giả; bổ sung ranh giới cảnh báo hoặc kết quả rủi ro tại nhánh suy đoán.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-025-76ceb586.mmd — REVISE — Nhãn “Escalate đúng decision authority” mơ hồ và trộn tiếng Anh–Việt; cần nêu BA chuyển quyết định tới owner có thẩm quyền theo loại vấn đề, như Business Owner, Architect, Legal Owner, Accounting Owner, Security hoặc QA.; Gateway “Xung đột mục tiêu hoặc vượt thẩm quyền BA?” chưa bao quát các điều kiện escalation quan trọng đã nêu: ảnh hưởng dữ liệu cá nhân, bút toán, hóa đơn, truy vết thực phẩm, phân quyền, tích hợp và xung đột quy tắc canonical. Cần thể hiện hoặc dẫn chiếu rõ các điều kiện này.; Bước “Ghi quyết định hoặc trạng thái chưa quyết định” có thể khiến khuyến nghị của BA bị hiểu thành quyết định. Cần phân biệt quyết định của owner có thẩm quyền với trạng thái IN_REVIEW hoặc chưa quyết định.; Luồng kết thúc tại cập nhật traceability nhưng bỏ các nội dung bắt buộc của decision record: phương án bị loại, lý do loại, dữ liệu còn thiếu, owner cần quyết định và hậu quả nếu giả định sai. Cần thể hiện đầu ra này hoặc đặt nó trong nhãn bước ghi nhận.; Nhánh không escalation đi thẳng tới khuyến nghị có điều kiện nhưng không làm rõ giới hạn: BA chỉ tự xử lý khi có đủ evidence, nằm trong phạm vi được giao và phù hợp quy tắc canonical. Cần bổ sung điều kiện để tránh hiểu rằng mọi vấn đề không xung đột đều thuộc quyền BA.
assets/diagrams/16-solution-options-tradeoffs-and-recommendations-026-c46f2979.mmd — REVISE — Cổng kiểm tra chỉ xác nhận template ID và tệp, nhưng prose yêu cầu đủ sáu trường: ID, tệp canonical, mục đích, Owner, người dùng đầu ra và cổng chất lượng. Bổ sung toàn bộ tiêu chí vào quyết định hoặc các bước kiểm tra.; Nhánh "Không" vẫn chuyển đến "Owner kiểm tra quality gate", dù template chưa được đăng ký và chưa có Owner hoặc quality gate xác định. Nhánh này phải dừng chuyển giao hoặc dẫn đến xử lý thiếu đăng ký được section hỗ trợ.; Nhãn "Người dùng tra cứu artifact" mơ hồ, không thể hiện đúng người dùng đầu ra và kết quả chuyển giao. Dùng vai trò người dùng đầu ra cùng hành động, kết quả cụ thể.; "Chapter 16 section 12" và thao tác "Tra TEMPLATE_MANIFEST" không được prose cung cấp rõ. Xác nhận chúng từ ngữ cảnh tài liệu hoặc thay bằng điểm bắt đầu và nguồn canonical được section hỗ trợ.; Sơ đồ không thể hiện hậu quả khi thiếu trường: không xác định đúng biểu mẫu, trách nhiệm hoặc điểm dừng chuyển giao. Thể hiện điều kiện dừng thay vì nhập lại luồng hợp lệ.
assets/diagrams/17-implementation-readiness-and-handoff-pack-001-ef95311a.mmd — REVISE — Nhãn action “xác nhận xuất” làm mất chi tiết được nêu rõ trong prose: “xác nhận số lượng đã xuất”. Cần dùng đúng hành động này.; Nhãn outcome “dữ liệu bàn giao có cấu trúc” thu hẹp sai phạm vi: section mô tả gói handoff gồm dữ liệu, quy tắc, vai trò, giả định, điểm cần xác minh và truy vết artifact. Cần thể hiện outcome là gói handoff có cấu trúc, không chỉ dữ liệu.; Luồng tuyến tính bỏ qua trạng thái kiểm soát quan trọng IN_REVIEW, v0.9.0, chưa baseline và yêu cầu owner chuyên môn xác minh. Cần thể hiện ít nhất trạng thái chưa được phê duyệt/baseline và điểm xác minh trước sử dụng thực tế.; Diagram gần như lặp lại actor–action–object–outcome đã được prose giải thích, nhưng không làm rõ ranh giới giữa nội dung đã biết, giả định, điểm cần xác minh và quyền quyết định. Cần bổ sung giá trị giải thích về luồng handoff có kiểm soát.; Nhãn “Consumer: đội triển khai và QA” gộp hai vai trò nhưng không thể hiện khác biệt trách nhiệm: đội triển khai dùng gói để cấu hình/phát triển, QA dùng basis để kiểm thử, còn owner chuyên môn giữ quyền xác nhận. Cần tránh hàm ý consumer có quyền phê duyệt.
assets/diagrams/17-implementation-readiness-and-handoff-pack-002-45818985.mmd — REVISE — Nút H dùng câu bị động và nhãn mơ hồ: “Điểm chưa rõ được escalation” không cho biết ai dừng, ai chuyển vấn đề, hoặc chuyển tới đâu. Cần thể hiện đội nhận dừng tự suy diễn và chuyển vấn đề tới owner có thẩm quyền như Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance.; Nhánh Có chỉ nêu “owner” nhưng bỏ ranh giới quyền quyết định, trong khi phần văn xuôi xác định đây là rủi ro chính. Cần làm rõ owner có quyền quyết định và BA không tự xác nhận cấu hình ERP, kế toán, pháp lý, bảo mật, tuân thủ hoặc khả năng production.; Hai nhánh chưa song song về kết quả: nhánh Không kết thúc bằng hậu quả, còn nhánh Có kết thúc bằng hoạt động escalation. Cần kết thúc nhánh Có bằng kết quả thực thi có kiểm soát hoặc xử lý điểm chưa rõ bởi đúng owner.
assets/diagrams/17-implementation-readiness-and-handoff-pack-003-fef1e2c6.mmd — REVISE — Nhánh “Có” bỏ mất owner xử lý điểm mở, dù ownership là mục tiêu và tiêu chí quyết định cốt lõi. Cần thể hiện điểm mở được gán cho owner có thẩm quyền.; Nhãn “Điểm mở giữ nhãn cần xác minh” chỉ mô tả trạng thái, không thể hiện điều kiện phải xác minh trước khi cấu hình hoặc kết luận kiểm thử. Cần làm rõ ranh giới này.; Nhãn “Developer, QA, owner nhận đúng phạm vi” dùng “owner” mơ hồ và không nói họ nhận artifact, đầu vào, đầu ra hay trách nhiệm nào. Cần dùng vai trò hoặc trách nhiệm cụ thể được section hỗ trợ.; Nhánh “Không” kết thúc ở “Khác cấu hình hoặc test basis”, nhưng nhãn thiếu chủ thể và quan hệ cụ thể. Cần nêu Developer cấu hình khác cách hiểu của BA hoặc QA thiết kế kiểm thử trên cơ sở khác.
assets/diagrams/17-implementation-readiness-and-handoff-pack-004-58bd627f.mmd — REVISE — Nhánh Có nguồn kiểm tra được? gán thẳng Verified fact, nhưng nguồn tồn tại chưa chứng minh đã đối chiếu, còn truy xuất được và có bằng chứng tối thiểu. Sửa điều kiện để yêu cầu đã xác minh với nguồn xác định và bằng chứng truy xuất được.; Nhánh mặc định từ Không cần tạm dùng để lập kế hoạch sang Verification-required claim phân loại quá rộng. Loại này chỉ áp dụng cho nhận định chưa đủ bằng chứng hoặc thẩm quyền 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. Thêm điều kiện tác động tương ứng; không ép mọi thông tin còn lại vào loại này.; Điều kiện tạo Project assumption chỉ hỏi nhu cầu lập kế hoạch, thiếu lý do, chủ sở hữu xác minh và điều kiện hết hiệu lực. Bổ sung tiêu chí hoặc thể hiện yêu cầu ghi nhận chúng trước khi dùng giả định.; Gateway Có lựa chọn được authority ghi nhận? chưa đủ để kết luận Decision. Quyết định còn cần phương án, tiêu chí, authority, ngày và artifact. Sửa gateway để phản ánh đủ bằng chứng tối thiểu.; Luồng I -- Có --> J[Decision] làm mất loại và nguồn gốc ban đầu, trong khi prose yêu cầu phân biệt loại thông tin và không tự biến fact thành quyết định. Thể hiện quyết định như artifact riêng có traceability tới fact, input, assumption hoặc claim hỗ trợ nó.; Nhãn Giữ loại ban đầu và traceability mơ hồ, trộn tiếng Việt và tiếng Anh, không nêu hành động hay kết quả cụ thể. Dùng nhãn cụ thể về việc giữ nguyên phân loại và lưu liên kết nguồn/bằng chứng.
assets/diagrams/17-implementation-readiness-and-handoff-pack-005-aef24807.mmd — REVISE — Luồng Operations chỉ quay về Discovery, trong khi exit gate cho phép quay về Discovery hoặc Analysis. Bổ sung nhánh Operations → Analysis với điều kiện phân loại phù hợp.; Entry Testing không khớp gate trong bảng: sơ đồ dùng “test basis không mâu thuẫn” nhưng bỏ yêu cầu test basis gồm requirement, rule, data, acceptance criteria và môi trường hoặc đối tượng kiểm thử sẵn sàng. Sửa nhãn theo các điều kiện được nêu.; Entry Delivery bỏ điều kiện nội dung chưa quyết định phải được đánh dấu và không được suy đoán. Bổ sung điều kiện này để bảo toàn ranh giới thẩm quyền.; Entry Release bỏ known limitation, trong khi bảng yêu cầu ghi nhận cùng phạm vi release và bằng chứng test. Bổ sung known limitation.; Entry Operations bỏ phạm vi thay đổi và kênh xử lý sự cố, đồng thời dùng “rollback hoặc xử lý sự cố được bàn giao” không song song với gate trong bảng. Căn chỉnh nhãn với phạm vi thay đổi, hướng dẫn vận hành và kênh xử lý sự cố.
assets/diagrams/17-implementation-readiness-and-handoff-pack-006-5fba9b7e.mmd — REVISE — Thiếu Delivery Lead trong hai điểm bàn giao: nhận đầu ra phân tích cùng Solution Architect và đồng sở hữu đầu ra thiết kế sang QA. Bổ sung actor và thể hiện đúng quyền sở hữu.; Nhãn Giải pháp và build note gán toàn bộ bàn giao cho Solution Architect, trong khi bảng quy định Delivery Lead và Solution Architect bàn giao build note, cấu hình mô phỏng, API contract nếu có và traceability. Sửa actor và nhãn artifact.; Nhánh BA quay về Business Owner chỉ nêu mâu thuẫn nghiệp vụ, bỏ điều kiện ưu tiên thay đổi. Bổ sung cả hai điều kiện escalation.; Nhánh escalation từ Solution Architect dùng rủi ro kiến trúc hoặc bảo mật, không khớp điều kiện trong bảng: đề xuất đổi ý nghĩa nghiệp vụ, dữ liệu hoặc kiểm soát bảo mật. Thay bằng điều kiện được prose hỗ trợ.; Nhánh QA dùng nhãn mơ hồ rủi ro chất lượng, trong khi bảng quy định escalation khi thiếu tiêu chí chấp nhận kiểm thử được hoặc môi trường không tái hiện được. Dùng điều kiện cụ thể.; Thiếu escalation tại bước kiểm thử sang phát hành cho defect ảnh hưởng dữ liệu, bảo mật, tài chính hoặc truy xuất thực phẩm. Bổ sung nhánh từ QA hoặc điểm bàn giao tương ứng.; Thiếu escalation do Release Manager thực hiện trước hoặc trong phát hành, dù đây là boundary có rủi ro nghiêm trọng trong bảng. Thể hiện owner escalation rõ.; Nhánh Operations chỉ nêu incident vượt runbook, bỏ trường hợp cần đổi quy tắc nghiệp vụ. Bổ sung điều kiện còn thiếu.; Nhãn artifact Test evidence và defect bỏ trạng thái defect và rủi ro còn lại; Release note và runbook bỏ known limitation. Bổ sung để không làm sai điều kiện nhận bàn giao.; Đích Owner có thẩm quyền mơ hồ, không xác định owner hay nơi escalation như định nghĩa handoff yêu cầu. Dùng owner cụ thể nếu section xác định được; nếu chưa, prose phải xác định trước khi diagram tham chiếu.
assets/diagrams/17-implementation-readiness-and-handoff-pack-007-7a2cb36b.mmd — REVISE — Nhãn "runbook, ownership, known limits" bổ sung đầu vào cụ thể cho Release nhưng phần văn xuôi không nêu các nội dung này; cần bỏ nhãn hoặc bổ sung căn cứ tương ứng vào văn xuôi.; Nhãn "hỗ trợ vận hành và escalation" đưa thêm cơ chế escalation không được phần văn xuôi xác lập; cần bỏ "escalation" hoặc bổ sung căn cứ tương ứng.; Hai cạnh I đến DV biểu diễn cùng quan hệ bằng cả mũi tên lifecycle và mũi tên nét đứt, làm ranh giới giữa thứ tự giai đoạn và quan hệ cung cấp đầu vào thiếu rõ; cần phân biệt rõ ý nghĩa hoặc bỏ cạnh trùng.
assets/diagrams/17-implementation-readiness-and-handoff-pack-008-5de90333.mmd — REVISE — Nút “Kiến thức BA tối thiểu” mô tả kiến thức của người đọc, trong khi prose xác định input là thông tin BA nhận trước khi lập pack. Cần đổi thành input được prose hỗ trợ hoặc loại bỏ nút.; Nút “Artifact nguồn có kiểm soát” dùng thuộc tính “có kiểm soát” chưa được định nghĩa; prose chỉ yêu cầu bằng chứng nguồn và loại trừ ghi nhớ, trao đổi miệng không ghi nhận, suy đoán cấu hình. Cần dùng điều kiện cụ thể từ prose.; Kết quả “Delivery, QA, Operations dùng cùng ngữ cảnh” đưa thêm ba nhóm sử dụng và outcome chưa được section xác nhận. Cần bổ sung prose chứng minh actor và outcome hoặc thu hẹp kết quả về khả năng truy ngược kết luận tới bằng chứng nguồn.; Sơ đồ chưa thể hiện điều kiện quan trọng rằng metadata upstream đang IN_REVIEW, chưa có baseline reference và approval reference. Nếu sơ đồ chỉ mô tả quan hệ thông tin, cần biểu đạt hoặc ghi rõ ranh giới trạng thái này để tránh người đọc hiểu handoff pack đã sẵn sàng hay được phê duyệt.
assets/diagrams/17-implementation-readiness-and-handoff-pack-009-b657ff0c.mmd — REVISE — Thứ tự sai prose: diagram kiểm tra định danh trước phân loại nguồn, trong khi section yêu cầu phân loại nguồn trước rồi mới kiểm tra chất lượng. Đổi thứ tự hai gateway.; Nhánh F -- Không --> G[Ghi project assumption hoặc giới hạn sử dụng] nhập nhằng và có thể biến VERIFICATION_REQUIRED thành PROJECT_ASSUMPTION. Giữ nguyên phân loại nguồn; chỉ ghi giới hạn sử dụng, hoặc chỉ ghi PROJECT_ASSUMPTION khi đó vốn là phân loại được gắn nhãn rõ.; Nhánh thành công U[Dùng làm evidence có traceability] bỏ qua giới hạn sử dụng theo từng phân loại nguồn. Bổ sung gateway hoặc outcome thể hiện nội dung chỉ được dùng cho mục đích mà phân loại cho phép; không dùng PROJECT_ASSUMPTION hay CANONICAL_INTERNAL như approval, baseline hoặc fact vận hành.; Diagram không thể hiện yêu cầu năm kiểm tra phải có kết quả ghi nhận trước khi input được dùng có điều kiện. Bổ sung bước ghi nhận kết quả Identity, Completeness, Consistency, Freshness và Authority.; Điều kiện dừng chưa bao phủ rõ việc dùng artifact IN_REVIEW như baseline/approval và requirement không truy ngược được evidence. Bổ sung các gateway hoặc outcome STOP tương ứng.; Gateway Có ảnh hưởng quyết định handoff? quá rộng, không nêu tiêu chí từ prose. Làm rõ rằng phải dừng khi vấn đề ảnh hưởng requirement, build/test basis, mapping/interface, tích hợp, hoặc quyết định handoff.
assets/diagrams/17-implementation-readiness-and-handoff-pack-010-fd92c4fa.mmd — REVISE — Nút A ghi “Nguồn canonical” nhưng bảng gồm cả controlled artifact và external primary source. Sửa nhãn để bao quát mọi input có nguồn được phân loại.; Nút B bỏ “phân loại nguồn”, dù prose yêu cầu giữ nguyên ID, đường dẫn, phân loại nguồn và trạng thái xác minh. Bổ sung tiêu chí này.; Nhánh “Không hoặc CẦN XÁC MINH” gộp thiếu bằng chứng với yêu cầu xác minh chuyên môn, làm mờ hai trạng thái và cách xử lý khác nhau. Tách điều kiện hoặc nêu rõ trạng thái nào chặn sử dụng.; Nút F “Dừng quyết định thuộc thẩm quyền owner chuyên môn” mơ hồ và không áp dụng đồng đều cho mọi dòng; một số điểm cần licensed text, baseline hoặc đăng ký ID, không chỉ owner chuyên môn. Sửa outcome theo loại điểm chưa giải quyết và owner ghi nhận.; Luồng không thể hiện điều kiện sử dụng cốt lõi: chỉ dùng dòng khi giữ nguyên đủ bốn thuộc tính bắt buộc. Thêm outcome từ gateway thể hiện rõ điều kiện này.
assets/diagrams/17-implementation-readiness-and-handoff-pack-011-906723bb.mmd — REVISE — Nhánh F -- Có --> H dừng ở việc tham chiếu quyết định, không nêu trạng thái hoặc bước bàn giao tiếp theo. Cần thể hiện rằng baseline và approval reference chỉ cho phép xử lý theo quyết định đã được chủ thể có thẩm quyền ghi nhận, không tự động đồng nghĩa với production, cấu hình, kiểm thử hoặc go-live.; Nhãn escalation đúng authority mơ hồ và không phản ánh ranh giới thẩm quyền quan trọng trong bảng. Cần chỉ rõ việc chuyển đến owner theo phạm vi như Business Owner, Architect, QA, Legal, Accounting hoặc Security.; Nhãn artifact kiểm soát không có đối tượng tương ứng rõ trong phần prose. Cần dùng tên artifact đã được section hỗ trợ hoặc xác định cụ thể loại hồ sơ chứa quyết định và approval reference.
assets/diagrams/17-implementation-readiness-and-handoff-pack-012-5179c7a7.mmd — REVISE — Nhãn "BA" không khớp owner quản trị được nêu cụ thể là "Principal IT Business Analyst / Technical Curriculum Author"; cần dùng đúng vai trò hoặc tách rõ người thực hiện và owner quản trị.; Bước "Giữ ID filename status version" thiếu metadata bắt buộc gồm ngày, múi giờ, locale, quốc gia và tiền tệ mô phỏng; cần thể hiện đầy đủ nghĩa vụ đồng bộ metadata hoặc giới hạn rõ bước này chỉ nói về quản trị định danh.; Bước "Chuyển sang review có kiểm soát" mơ hồ và gợi ý chuyển trạng thái dù mọi artifact đã có trạng thái IN_REVIEW; cần mô tả outcome được section hỗ trợ, không ngụ ý workflow hay state transition chưa được định nghĩa.; Diagram bỏ ranh giới authority trọng yếu: owner giữ tính toàn vẹn artifact nhưng không có quyền xác nhận legal, accounting, security, architecture, business decision, baseline, approval hoặc production use; cần thể hiện boundary này nếu diagram mô tả handoff/review.; Diagram gần như lặp nguyên chuỗi nghĩa vụ trong prose mà không làm rõ dependency, quyền sở hữu, boundary hoặc kết quả; cần bổ sung giá trị giải thích thay vì chỉ tuần tự hóa câu chữ.
assets/diagrams/17-implementation-readiness-and-handoff-pack-013-a57d5a42.mmd — REVISE — Nhãn "Upstream controlled artifacts" quá khái quát; cần thể hiện các nhóm nguồn canonical/manifest được bảng xác định để dependency có thể truy vết.; Nhãn "Reviewable content" mơ hồ; cần phản ánh payload cụ thể gồm requirement, rule, logical data, test basis và open verification label.; Luồng gộp vào "Downstream review" ngụ ý traceability và content là đủ để review, nhưng bỏ review entry point gồm canonical links và câu hỏi review cụ thể.; Sơ đồ bỏ evidence boundary và trạng thái chưa xác minh; cần thể hiện nội dung pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật chưa được owner có thẩm quyền xác minh không trở thành yêu cầu bắt buộc.; Sơ đồ bỏ change record dù đây là thành phần bắt buộc cho impact review; cần thể hiện version, date, change description, affected artifact và traceability link.; Sơ đồ không thể hiện ranh giới kết quả: handoff hỗ trợ review nhưng không xác nhận ERP operation, baseline, approval hoặc production readiness.; Sơ đồ chủ yếu lặp lại quan hệ nguồn–gói–review đã có trong prose và bảng, chưa bổ sung logic kiểm tra, boundary hoặc trạng thái giúp người đọc hiểu quy trình.
assets/diagrams/17-implementation-readiness-and-handoff-pack-014-c93fa657.mmd — REVISE — Chuyển từ READY_FOR_DOWNSTREAM_REVIEW sang [*] sau nhãn “chuyển reviewer” gây hiểu nhầm rằng quy trình hoặc vòng đời artifact kết thúc. Phần văn bản chỉ xác lập khả năng bàn giao để downstream review, không xác lập trạng thái kết thúc. Cần bỏ trạng thái kết thúc hoặc thể hiện ranh giới downstream review mà không suy diễn approval.; Nhãn “chuyển reviewer” thiếu chủ thể và kết quả cụ thể. Cần nêu rõ ai bàn giao và đây là bàn giao cho downstream review, không phải phê duyệt.; Nhãn “đủ quality gate” không đủ cụ thể so với năm kiểm tra bắt buộc trong bảng. Cần diễn đạt điều kiện là đạt toàn bộ kiểm tra bắt buộc để tránh hiểu quality gate như một bước phê duyệt.; Nhánh quay lại chỉ nêu “phát hiện thiếu hoặc mâu thuẫn”, trong khi bảng còn loại trừ TODO, TBD, ellipsis, dòng thiếu, sai metadata, thiếu traceability và suy diễn pháp lý hoặc kế toán. Cần dùng điều kiện bao quát mọi trường hợp không còn đạt quality gate.
assets/diagrams/17-implementation-readiness-and-handoff-pack-015-07c4d575.mmd — REVISE — Các nút kết quả không phản ánh đầy đủ và song song cột “Kết quả họ cần tạo”: Developers thiếu thiết kế kỹ thuật, mã nguồn và unit test; QA thiếu test cases và defect record; Architect thiếu architecture decision record và integration design; Business Owner thiếu quyết định nghiệp vụ; Operations thiếu operating procedure và support readiness input. Cần dùng nhãn kết quả bao quát đúng các đầu ra hoặc thể hiện riêng các đầu ra quan trọng.; Nhãn “Build or configure” mô tả hoạt động, trong khi các nhánh khác chủ yếu mô tả kết quả. Cần đổi sang nhãn kết quả cụ thể, nhất quán với cấu trúc các nhánh còn lại.; Sơ đồ không thể hiện ranh giới quan trọng rằng handoff pack chỉ là test basis, không tự tạo phê duyệt hoặc baseline. Cần biểu diễn rõ giới hạn này để tránh hiểu các mũi tên là chuyển giao có hiệu lực phê duyệt.; Nhãn “BA handoff pack” gắn ownership cho BA nhưng đoạn văn chỉ xác định output của Implementation Readiness And Handoff Pack. Cần dùng tên output trung lập hoặc bổ sung ownership trong prose nếu BA thực sự là owner.
assets/diagrams/17-implementation-readiness-and-handoff-pack-016-0d38b0a5.mmd — REVISE — Nhánh “Không” dẫn tới “Tiếp tục review hoặc thực hiện” cho phép suy diễn quyền thực hiện từ artifact IN_REVIEW/v0.9.0, trái với cảnh báo rằng trạng thái này không cho phép suy ra quyền triển khai. Tách review khỏi thực hiện hoặc thêm điều kiện phê duyệt và quyền triển khai có bằng chứng.; Gateway “Vượt thẩm quyền BA?” tự gán BA làm ranh giới thẩm quyền, trong khi prose chỉ yêu cầu “vai trò có thẩm quyền”. Đổi tiêu chí sang việc câu hỏi có cần quyết định từ vai trò có thẩm quyền hay không.; Bước “Đối chiếu artifact canonical và bằng chứng” không thể hiện đầy đủ bốn nguồn trả lời trong prose: artifact, nguồn canonical, vai trò có thẩm quyền và quyết định được ghi nhận. Bổ sung hoặc phân nhánh đủ nguồn.; Kết quả “Ghi rõ cách hiểu trong artifact” chỉ lưu cách hiểu, không bảo đảm đó là làm rõ đã được xác nhận hoặc quyết định được ghi nhận. Yêu cầu ghi kết luận có căn cứ, nguồn canonical hoặc quyết định có thẩm quyền.; Nhánh “Người nhận diễn giải khác? — Không” bỏ qua khả năng chưa phát hiện hiểu nhầm và không tạo bằng chứng bằng câu hỏi kiểm chứng. Làm rõ tiêu chí xác nhận cách hiểu thay vì coi không có khác biệt là đủ.
assets/diagrams/17-implementation-readiness-and-handoff-pack-017-6258ab83.mmd — REVISE — Nút quyết định Thủ kho tự chọn lô phân nhánh sang hai lô như hai lựa chọn loại trừ, trong khi tình huống yêu cầu lấy đồng thời 150 THUNG từ LOT-NF-260701-A và 90 THUNG từ LOT-NF-260715-B. Cần thể hiện đây là phân bổ nhiều lô, không phải lựa chọn một trong hai.; Nút cuối ERP không bắt buộc lưu mã lô mô tả hạn chế hệ thống nhưng bỏ kết quả/rủi ro chính của Current Behavior: lịch sử lô có thể thiếu hoặc sai và ERP không chứng minh được đơn đã xuất từ lô nào. Cần thể hiện kết quả này.; Nhãn Ghi phiếu giấy thiếu chủ thể và dữ liệu được ghi. Cần nêu cụ thể thủ kho ghi số lượng xuất theo lô trên phiếu giấy để khớp prose và bảng.
assets/diagrams/17-implementation-readiness-and-handoff-pack-018-6ff84389.mmd — REVISE — Nhánh QA chấp nhận không thể hiện trường hợp QA chỉ chấp nhận một phần từ 0 đến 500 kg; cần thể hiện kết quả số lượng được chấp nhận trở thành khả dụng và cách xử lý phần không được chấp nhận.; Chuyển tiếp RELEASED --> [*]: Có thể cấp phát sản xuất biến quyền cấp phát thành sự kiện kết thúc vòng đời. Cần giữ RELEASED như trạng thái cho phép cấp phát hoặc dùng sự kiện kết thúc cụ thể được phần prose hỗ trợ.; Chuyển tiếp REJECTED --> [*]: Không được cấp phát bỏ mất kết quả đã nêu là lô chờ quy trình xử lý tiếp theo. Cần thể hiện ranh giới này thay vì ngụ ý vòng đời kết thúc.; Nhãn QA chấp nhận và trạng thái RELEASED mơ hồ khi số lượng chấp nhận bằng 0 hoặc nhỏ hơn 500 kg. Cần làm rõ trạng thái áp dụng cho toàn lô hay cho số lượng được chấp nhận.
assets/diagrams/17-implementation-readiness-and-handoff-pack-019-3dd24258.mmd — REVISE — Nhánh D -->|Có| H sai nghĩa: lô đạt ngưỡng không cần quyết định ngoại lệ và không bị giới hạn bởi phạm vi quyết định. Cần outcome phân bổ chuẩn riêng.; Gateway Có quyết định ngoại lệ được ghi nhận? gộp quyết định chấp thuận và từ chối. Quyết định từ chối phải tiếp tục chặn; chỉ chấp thuận hợp lệ mới mở chặn theo phạm vi quyết định.; Diagram không thể hiện Business Owner là vai trò quyết định ngoại lệ theo policy đã xác minh. Cần gắn actor này với bước quyết định để tránh ngụ ý mọi quyết định được ghi nhận đều có thẩm quyền.; Diagram trình bày luồng như hành vi ERP đã xác lập, trong khi rule, field mapping, cấu hình và recommendation đều IN_REVIEW hoặc chưa xác minh. Cần đánh dấu đây là luồng đề xuất thuộc OPT-IRH-003/IRH-PACK-001 v0.9.0, không phải production behavior.
assets/diagrams/17-implementation-readiness-and-handoff-pack-020-83196ec3.mmd — REVISE — Bốn dependency 00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE, CHAPTER_MANIFEST và TEMPLATE_MANIFEST không được prose xác nhận. Cần bổ sung căn cứ trong prose hoặc loại các cạnh tương ứng.; Nhãn /02-handbook/17-implementation-readiness-and-handoff-pack.md không khớp FILE 02-handbook/17-implementation-readiness-and-handoff-pack.md; bỏ dấu / đầu nếu đây là đường dẫn tương đối.; Nhãn ID persistent mơ hồ và không song song với các nhãn tiếng Việt còn lại. Cần dùng nhãn cụ thể, nhất quán với khái niệm ID bền vững trong curriculum.
assets/diagrams/17-implementation-readiness-and-handoff-pack-022-2430584c.mmd — REVISE — Quan hệ CANONICAL_BUSINESS_RULES --> CANONICAL_DATA_DICTIONARY không được phần văn xuôi xác lập; cần bỏ quan hệ này hoặc bổ sung căn cứ trong văn xuôi.; Nhánh CANONICAL_DATA_DICTIONARY --> API contract --> Test case đưa vào interface và phụ thuộc không được phần văn xuôi nêu rõ; cần bỏ hoặc mô tả các phụ thuộc này trong văn xuôi.; Quan hệ Sai lệch không phát hiện --> Test case mơ hồ: sai lệch là rủi ro/kết quả, không phải đầu vào rõ ràng của test case; cần thể hiện test case giữ nghĩa cũ và dẫn tới handoff pack báo sẵn sàng dựa trên bằng chứng sai.; Nhánh thay đổi im lặng chỉ bắt đầu từ catalog quy tắc, trong khi định nghĩa áp dụng cho mọi nguồn phụ thuộc; cần biểu diễn phạm vi tổng quát hoặc ghi rõ đây chỉ là ví dụ về thay đổi quy tắc.
assets/diagrams/17-implementation-readiness-and-handoff-pack-023-bc147bbc.mmd — REVISE — Nhánh “Không” đi thẳng từ gửi câu hỏi đến rà soát handoff, khiến artifact chưa được xác nhận vẫn có thể vào QA và delivery. Cần thể hiện owner trả lời, BA cập nhật artifact, rồi kiểm tra lại mức đủ thông tin trước khi handoff.; Bước “Cập nhật artifact và liên kết” bỏ thiếu chuỗi kiểm soát thay đổi đã nêu trong bảng: ghi thay đổi, xác định artifact phụ thuộc và rà soát tác động. Cần thể hiện các việc này trước khi handoff lại.; Nhãn “Khoanh ID artifact bị ảnh hưởng” không rõ là xác định một ID hay toàn bộ artifact phụ thuộc. Cần dùng nhãn cụ thể, bao quát artifact gốc và artifact phụ thuộc.; Nhãn “chuyển đúng owner” mơ hồ về trách nhiệm và đầu ra. Cần nêu owner xác nhận thông tin hoặc quyết định nghiệp vụ, phù hợp loại câu hỏi.
assets/diagrams/17-implementation-readiness-and-handoff-pack-024-0a76bdc7.mmd — REVISE — Luồng thiếu bước sửa mapping giữa xác nhận cơ chế quy đổi và kiểm thử lại; thêm bước sửa mapping có ghi nhận thay đổi để phản ánh phương án (2) và yêu cầu traceability.; Nhánh B -- Không --> I suy diễn chênh lệch không ảnh hưởng là lỗi trình bày; nội dung không cung cấp kết luận này. Đổi thành kết quả trung tính, có căn cứ, hoặc bỏ nhánh nếu không có quy trình tương ứng trong phần văn bản.; Nhãn không dùng warning diễn đạt sai quyết định. Văn bản cho phép cảnh báo giữ trạng thái dừng nhưng không cho phép dùng cảnh báo làm bằng chứng lỗi đã sửa; sửa nhãn để giữ đúng phân biệt này.; Kết quả Tiếp tục handoff có kiểm soát còn mơ hồ; nêu rõ chỉ tiếp tục import hoặc handoff sau khi bằng chứng đối soát và kiểm thử nhất quán.; Luồng chưa thể hiện yêu cầu ghi nhận liên kết tới mapping, kết quả kiểm thử và quyết định của vai trò có thẩm quyền; thêm điểm ghi nhận bằng chứng trước khi tiếp tục handoff.
assets/diagrams/17-implementation-readiness-and-handoff-pack-025-54ad324f.mmd — REVISE — Nút A gọi đầu vào là “Fact” trước khi E phân biệt fact, assumption và inference. Đổi phạm vi đầu vào thành bằng chứng hoặc thông tin từ artifact/dữ liệu mô phỏng; chỉ xác nhận fact sau bước kiểm tra nguồn và phân loại.; Gateway “Quyết định thuộc thẩm quyền BA?” gây hiểu rằng BA có thể phê duyệt option. Prose chỉ cho BA lập recommendation; Business Owner, Architect, QA, Legal, Accounting, Security hoặc Compliance quyết định khi thuộc thẩm quyền tương ứng. Cần tách quyền lập recommendation khỏi quyền chấp nhận rủi ro hoặc phê duyệt.; Nhánh “Có” đi thẳng đến ghi recommendation nhưng không thể hiện khoảng trống bằng chứng, mức chắc chắn và owner quyết định trước baseline hoặc cấu hình. Bổ sung outcome này để khớp mẫu recommendation có thể phòng vệ.; Nút “Chuyển owner có thẩm quyền” quá mơ hồ và kết thúc không có outcome. Cần chỉ rõ owner phù hợp theo loại quyết định và trạng thái chờ xác minh hoặc quyết định; không ngụ ý escalation đồng nghĩa phê duyệt.; Luồng so sánh option bỏ tiêu chí trade-off, tác động nghiệp vụ, ngoại lệ và rủi ro còn lại trước gateway thẩm quyền. Cần thể hiện các đầu vào quyết định này vì section coi chúng là điều kiện suy luận hợp lệ.; Sơ đồ không biểu diễn ranh giới bắt buộc Verification required cho pháp lý, kế toán, bảo mật, production, an toàn thực phẩm và compliance. Cần thêm nhánh escalation cho các phạm vi BA không được tự xác nhận.
assets/diagrams/17-implementation-readiness-and-handoff-pack-026-8a43a64a.mmd — REVISE — Luồng tuần tự từ nội dung Chapter 17 đến consumer không được đoạn văn xác lập; cần bỏ hoặc chỉ giữ quan hệ tham chiếu được nêu rõ.; Các bước "Kiểm tra tệp controlled" và "Áp dụng quality gate" không có tiêu chí, chủ thể hoặc kết quả trong đoạn văn; cần bổ sung căn cứ trong prose hoặc loại khỏi sơ đồ.; "Consumer dùng artifact" đưa vào actor và outcome chưa được prose hỗ trợ; cần xác định consumer, cách dùng và điều kiện bàn giao hoặc loại bỏ.; "ID canonical" và "tệp controlled" là nhãn mơ hồ, pha trộn Việt–Anh và không nêu nguồn kiểm soát; cần dùng thuật ngữ cụ thể, nhất quán với prose.; Sơ đồ bỏ qua ranh giới quan trọng: chapter chỉ tham chiếu template và artifact nguồn, không tạo ID, tệp, baseline hoặc approval; cần thể hiện ranh giới này nếu sơ đồ mô tả readiness hoặc handoff.
assets/diagrams/17-implementation-readiness-and-handoff-pack-027-53b93586.mmd — REVISE — Luồng bỏ sót bước đối chiếu nguồn canonical tại CANONICAL_BUSINESS_RULES.md và CANONICAL_DATA_DICTIONARY.md; cần thể hiện bước tham chiếu hai nguồn này mà không sao chép hoặc nâng nội dung thành quyết định vận hành.; Kết quả “đủ điều kiện tra cứu” mơ hồ và rộng hơn bằng chứng được phép; cần giới hạn kết quả thành xác nhận đúng vị trí, phiên bản, trạng thái, định danh và đủ 12 mục H2.; Sơ đồ không thể hiện ranh giới quan trọng: checklist không xác nhận chất lượng, baseline, approval, tuân thủ pháp lý, cấu hình ERP hoặc sẵn sàng production; cần biểu diễn giới hạn này để tránh diễn giải sai.; Sơ đồ lặp nguyên trình tự tuyến tính đã có trong hai bảng, chưa bổ sung quan hệ, nhánh quyết định hoặc ranh giới giúp người đọc hiểu nhanh hơn; cần tạo giá trị trực quan ngoài việc tóm tắt prose.
assets/diagrams/17-implementation-readiness-and-handoff-pack-028-fdfde639.mmd — REVISE — Các bước “Ghi kết quả self-review”, “Ghi open issue hoặc Verification required” và “Escalate đúng owner” không được phần văn xuôi xác lập; cần bổ sung căn cứ trong văn xuôi hoặc loại bỏ khỏi sơ đồ.; Nhãn “đúng owner” không xác định vai trò chịu trách nhiệm hoặc quy tắc chọn owner; cần nêu owner cụ thể hay cơ chế phân công được phần văn xuôi hỗ trợ.; Kết quả “Handoff chương ở trạng thái IN_REVIEW” biến trạng thái corpus thành trạng thái handoff chương; cần xác nhận hai trạng thái đồng nhất hoặc sửa nhãn để tránh suy diễn.; Sơ đồ không nêu actor thực hiện rà soát, ghi nhận và escalation dù trách nhiệm ảnh hưởng luồng; cần xác định actor trong phần văn xuôi và sơ đồ.; Nhánh “Không” cho phép handoff ngay sau self-review nhưng không nêu tiêu chí hoàn tất rà soát liên tệp; cần thể hiện điều kiện kiểm tra yêu cầu, ID, trạng thái và giới hạn thẩm quyền đã nhất quán.
assets/diagrams/18-testing-fundamentals-for-ba-001-e6137ebb.mmd — REVISE — Nhánh hợp lệ bỏ sót trạng thái phiếu dù phần mở đầu yêu cầu ERP lưu cả số lượng nhận và trạng thái phiếu; cần thể hiện việc lưu hoặc kiểm tra trạng thái theo requirement.; Nhãn "trả kết quả" mơ hồ, không xác định kết quả quan sát được; cần nêu kết quả hiển thị hoặc phản hồi cụ thể theo test basis.; Gateway "Dữ liệu hợp lệ" không gắn với hai test condition đã quyết định là 100 và -1; cần làm rõ các nhánh tương ứng mà không suy diễn thêm business rule.
assets/diagrams/18-testing-fundamentals-for-ba-002-ffc42b93.mmd — REVISE — Nút "Kiểm tra theo test basis" mơ hồ và trộn kiểm tra nghiệp vụ trong hệ thống với hoạt động testing. Cần thể hiện cụ thể kiểm tra số lượng nhận không âm trước khi lưu.; Hai nhánh cùng đi vào "Kiểm tra kết quả thực tế" gây hiểu sai: nhánh hợp lệ cần kiểm tra giao dịch và tồn kho; nhánh không hợp lệ cần kiểm tra hệ thống từ chối lưu và hiển thị lỗi.; Kết quả "Phát hiện chênh lệch trước luồng sau" không phù hợp với nhánh không hợp lệ khi hệ thống xử lý đúng và không có chênh lệch. Cần tách kết quả đạt kỳ vọng khỏi kết quả phát hiện sai lệch.; Sơ đồ bỏ chủ thể nhân viên kho tại bước nhập và không xác định ai thực hiện kiểm tra kết quả. Cần gắn chủ thể cho các hành động nơi trách nhiệm quan trọng.
assets/diagrams/18-testing-fundamentals-for-ba-003-cefca164.mmd — REVISE — Gateway C trộn điều kiện nghiệp vụ với mức độ rõ của test. Việc có expected result không tự làm hệ thống ngừng tạo tác vụ xuất. Cần thể hiện expected result là tiêu chí so sánh, còn actual result là hành vi hệ thống quan sát được.; Hai nhánh "Không có test rõ" và "Có expected result" không song song, không phải hai kết quả loại trừ của cùng một quyết định. Cần dùng nhánh dựa trên kết quả quan sát so với expected result, như khớp hoặc không khớp.; Nhánh D kết thúc ở phát hiện lệch nhưng bỏ bước ghi actual result, kết luận fail và chuyển câu hỏi quy tắc cho Business Owner. Đây là xử lý ngoại lệ và quyền quyết định được phần văn bản nhấn mạnh.; Nhánh E mặc định "Không tạo tác vụ xuất" là hành vi thực tế, trong khi văn bản chỉ xác định đây là expected result của case học liệu và nói quy tắc vận hành chưa được phê duyệt. Cần phân biệt rõ expected result với actual result.; Sơ đồ bỏ trạng thái pass/fail sau khi so sánh expected result và actual result. Cần thể hiện cả hai kết quả vì phần văn bản yêu cầu đủ bằng chứng trước khi kết luận.; Nhãn "Kiểm tra điều kiện xuất" mơ hồ về chủ thể và đối tượng kiểm tra. Cần nêu rõ đây là bước QA kiểm tra actual result của dòng số lượng 0 theo expected result đã ghi.
assets/diagrams/18-testing-fundamentals-for-ba-004-4483b045.mmd — REVISE — Gateway “Có bằng chứng artifact kiểm tra được?” đồng nhất bằng chứng tồn tại với verified fact. Section nêu artifact có thể ở trạng thái IN_REVIEW, không có baseline hay approval reference. Sửa gateway và nhánh để phân biệt artifact truy vết được với test basis đã được authority phê duyệt.; Nhánh Decision nằm sau câu trả lời “Không” về bằng chứng artifact, nhưng Decision hợp lệ phải là lựa chọn được authority ghi nhận và truy vết. Sửa luồng để yêu cầu decision record hoặc approval reference thay vì cho phép Decision phát sinh từ nhánh không có bằng chứng.; Nhãn “authority” mơ hồ và bỏ ranh giới trách nhiệm quan trọng. Sửa nhãn để nêu Business Owner quyết định vận hành; domain owner và Legal Owner xác minh khẳng định domain/legal; QA chỉ xác định cách kiểm thử sau khi có test basis hợp lệ.; Nhánh Verified fact dẫn thẳng tới “Viết test condition theo decision”, dù fact không đồng nghĩa decision hay business rule được duyệt. Sửa outcome để chỉ viết expected result bắt buộc khi fact hoặc decision tạo thành test basis hợp lệ cho hành vi cần kiểm thử.; Luồng không thể hiện trạng thái cần dùng trong artifact: stakeholder input hoặc Verification required, không phải canonical rule. Sửa outcome tương ứng để giữ đúng ranh giới ghi nhận.; Diagram bỏ ngoại lệ cốt lõi của tình huống: chưa chọn phương án chặn, cảnh báo kèm override, hay kiểm soát ngoài ERP. Sửa luồng để Decision chỉ dẫn tới test condition của phương án đã được ghi nhận, không ngầm mặc định hành vi chặn.
assets/diagrams/18-testing-fundamentals-for-ba-005-b1cce202.mmd — REVISE — Exit-gate artifacts such as "build note", "deployed test environment", "defect status", "residual-risk record", "release record", "rollback readiness", "communication record" and "incident and feedback evidence" lack support in surrounding prose; remove them or establish them in prose.; Section defines both entry gate and exit gate, but diagram shows only exit gates; add entry-gate representation or narrow prose/diagram scope explicitly.; Solid phase arrows and dotted exit-gate arrows duplicate each transition, making gate role ambiguous; distinguish lifecycle flow from gate condition without parallel competing edges.; Diagram omits stated IN_REVIEW boundary: readiness for review does not create baseline, approval or production authority; show this limitation if diagram represents gate semantics.; Labels "evidence" and "traceability" lack concrete objects or completion criteria; use specific, prose-supported outcomes.
assets/diagrams/18-testing-fundamentals-for-ba-006-b19f48f9.mmd — REVISE — Luồng tuyến tính BA → Delivery Lead / Developer → QA → Release Manager → Operations Lead không được phần văn xuôi xác lập. Cần bỏ các bước và artifact không có căn cứ, hoặc bổ sung văn xuôi nêu rõ chuỗi handoff, owner và quyền quyết định.; Các nhãn “Build, thay đổi, test basis”, “Kết quả test, defect, rủi ro” và “Release package” đưa thêm artifact và trách nhiệm chưa được mô tả. Cần chứng minh từng interface trong văn xuôi hoặc loại khỏi sơ đồ.; Sơ đồ gán Release Manager và Operations Lead nhưng phần văn xuôi chỉ nói BA không có quyền quyết định release, không chỉ định hai vai trò này. Cần xác định owner trong văn xuôi hoặc không gán.; Nhánh Accounting Owner / Legal Owner gộp hai chuyên môn thành một điểm nhận, làm mờ quyền hạn riêng. Cần tách owner hoặc ghi rõ cơ chế chuyển đúng owner.; Nhánh Security / Architect gộp hai miền quyết định khác nhau. Cần tách owner bảo mật và owner kiến trúc để tránh hiểu một vai trò có quyền kết luận cả hai.; Các ngoại lệ bảo vệ dữ liệu, an toàn thực phẩm và thuế được văn xuôi nêu rõ nhưng không có owner hoặc đường quay lại tương ứng. Cần thể hiện domain owner phù hợp hoặc giới hạn phạm vi sơ đồ rõ ràng.; Sơ đồ chỉ thể hiện vài đường quay lại của BA và QA, chưa thể hiện nguyên tắc chung rằng mỗi handoff phải có owner xử lý khi artifact thiếu hoặc mâu thuẫn. Cần biểu diễn đường quay lại cho các handoff được giữ lại.; Nhãn “Mâu thuẫn rule hoặc thiếu thẩm quyền” và “Expected result chưa có quyết định” trộn Việt-Anh và không song song với các nhãn khác. Cần dùng thuật ngữ cụ thể, nhất quán và nêu rõ điều kiện chuyển trả.
assets/diagrams/18-testing-fundamentals-for-ba-008-953bfe29.mmd — REVISE — Mũi tên Kiến thức nghiệp vụ và kiểm thử --> Test basis mâu thuẫn phân loại trong prose: kiến thức nền giúp hiểu và suy luận, còn test basis là tập bằng chứng. Cần thể hiện kiến thức hỗ trợ việc xây dựng test case hoặc diễn giải test basis, không biến kiến thức thành test basis.; Mũi tên Artifact nguồn được kiểm soát --> Test basis làm mờ vai trò của bằng chứng có thể truy về artifact nguồn. Cần phân biệt artifact chứa thông tin với bằng chứng được trích dẫn và dùng làm test basis.; Sơ đồ bỏ qua trạng thái IN_REVIEW và giới hạn sử dụng quan trọng: liên kết được phép ghi nhận nhưng nội dung chưa được nâng thành quyết định vận hành hoặc kết luận production. Cần thể hiện điều kiện hoặc ranh giới này.; Nhãn Bằng chứng kết quả chưa rõ là kết quả quan sát được hay bằng chứng thực thi test. Cần dùng nhãn cụ thể, phù hợp với việc đối chiếu kết quả quan sát với test basis.
assets/diagrams/18-testing-fundamentals-for-ba-009-e74eebb2.mmd — REVISE — Gateway "Có ID, tệp, version, status?" áp dụng đồng loạt tiêu chí "tệp" cho mọi nguồn, trong khi primary source có thể được định danh bằng tên tài liệu và URL đã xác minh. Cần diễn đạt tiêu chí định danh phù hợp loại nguồn, không bắt buộc tên tệp khi nguồn không phải tệp.; Gateway "Còn mới và có owner?" gộp freshness với ownership, làm mất điều kiện owner phải có đúng thẩm quyền xác nhận nội dung. Cần tách hoặc ghi rõ freshness, owner và giới hạn thẩm quyền.; Nhánh không đạt ownership dẫn thẳng đến "STOP: thiếu truy vết", trái với xử lý "Chỉ ghi nhận, không kết luận" và không chính xác vì thiếu thẩm quyền không đồng nghĩa thiếu truy vết. Cần dùng kết quả phù hợp từng nguyên nhân.; Sơ đồ bỏ tiêu chí phạm vi sử dụng không vượt ranh giới nguồn. Cần thêm kiểm tra scope trước kết quả "Dùng làm test basis".; Kết quả cuối chưa thể hiện rằng project assumption không được nâng thành nghĩa vụ, IN_REVIEW không phải approval/baseline, và nguồn "Verification required" cần xác nhận chuyên môn. Cần thể hiện giới hạn sử dụng theo nhãn nguồn.
assets/diagrams/18-testing-fundamentals-for-ba-010-10e81459.mmd — REVISE — Thiếu nhánh BLOCKED cho môi trường hoặc dữ liệu không dùng được. Thêm điều kiện trước thực thi hoặc trước đánh giá actual result, rồi ghi BLOCKED và lưu lý do.; Nhánh D -- Không --> F[Ghi FAIL, defect hoặc clarification] trộn kết quả không khớp với rule chưa rõ. Chỉ ghi FAIL khi expected result đã xác định; chuyển rule thiếu hoặc xung đột nguồn sang nhánh clarification và BLOCKED trước khi kết luận PASS/FAIL.; Luồng không thể hiện ngoại lệ tại đúng ngưỡng hạn mức. Thêm nhánh kiểm tra expected result có rule canonical hay chưa; nếu chưa, escalate Business Owner và không tự suy luận > hoặc >=.; QA phân loại lỗi và trả nhóm triển khai tạo actor và handoff không được section xác định. Bỏ trả nhóm triển khai hoặc bổ sung nguồn prose xác nhận owner và giao diện bàn giao này.; Nhánh escalation đi thẳng tới controlled handoff nhưng không nêu trạng thái chờ làm rõ hoặc kết quả phân loại. Gắn trạng thái BLOCKED/clarification pending vào test execution record để tránh hiểu rằng escalation đã hoàn tất test.
assets/diagrams/18-testing-fundamentals-for-ba-011-ed5ecc90.mmd — REVISE — Thiếu Test data set dù đây là output bắt buộc và phải liên kết với test case tương ứng; bổ sung artifact cùng quan hệ truy vết.; TRACEABILITY_ID_REGISTRY chỉ nhận liên kết từ test case và execution, trong khi prose yêu cầu quan hệ test basis–test case–execution–defect; bổ sung liên kết từ test basis và defect/clarification record.; Hai execution cùng trỏ tới một Defect or clarification record, ngụ ý luôn tạo chung một record cho cả hai lần chạy; tách quan hệ hoặc dùng nhãn/điều kiện thể hiện record chỉ phát sinh khi có sai lệch hay nhu cầu làm rõ.; Các mũi tên không có nhãn nên không phân biệt quan hệ dựa trên test basis, thực thi, phát hiện sai lệch và đăng ký truy vết; thêm nhãn quan hệ cụ thể.
assets/diagrams/18-testing-fundamentals-for-ba-012-59925095.mmd — REVISE — Sơ đồ chỉ thể hiện PASS và FAIL, nhưng phần văn bản quy định thêm NOT_RUN và BLOCKED. Bổ sung nhánh hoặc trạng thái để không ngụ ý mọi test execution đều kết thúc bằng so sánh Actual–Expected.; Nhãn FAIL evidence and defect link ngụ ý mọi kết quả FAIL đều phải có defect link, trái với quy định chỉ ghi liên kết khi defect đã được tạo. Tách evidence bắt buộc khỏi defect link có điều kiện.; Gateway Actual = Expected? không áp dụng cho trường hợp chưa chạy hoặc bị chặn. Đặt điều kiện về khả năng thực thi trước bước so sánh kết quả.
assets/diagrams/18-testing-fundamentals-for-ba-013-b0bf63aa.mmd — REVISE — Node E uses ambiguous actor "QA hoặc vai trò nhận output review". Section names QA reviewer as testing-quality evaluator. Replace label with concrete supported actor "QA reviewer đánh giá chất lượng testing".; Node F says "Review finding hoặc quyết định thuộc thẩm quyền", leaving authority and outcome unclear and potentially implying approval. Section explicitly states no role in example self-grants approval. Separate supported review finding from any decision, and state that downstream review does not grant production approval.
assets/diagrams/18-testing-fundamentals-for-ba-014-9c095b07.mmd — REVISE — Sơ đồ bỏ sót Defect record dù đây là output testing chính trong bảng; bổ sung output này cùng quan hệ sử dụng phù hợp.; Sơ đồ chỉ nối Architect, PM/Product Owner, Business Owner, Operations và Specialist owner với Test execution evidence, trong khi bảng cho biết các vai trò này còn dùng test scenario, test case, traceability matrix hoặc defect record; thể hiện đúng các quan hệ hoặc thu hẹp rõ phạm vi sơ đồ.; Nhãn "BA chuẩn bị test basis" gom nhiều output thành khái niệm mơ hồ, còn các nhánh sau chỉ nêu một phần output; dùng các output cụ thể và quan hệ nhất quán.; Evidence bridge trong prose liên kết test case với requirement, business rule và test data, nhưng sơ đồ bỏ toàn bộ liên kết này; bổ sung requirement, business rule và test data để trực quan hóa luận điểm chính.; Luồng BA → QA → Test execution evidence có thể gây hiểu rằng mọi test basis chỉ đi qua QA trước khi các vai trò khác sử dụng, trái với bảng mô tả nhiều vai trò đọc trực tiếp từng output; sửa cấu trúc để tránh phụ thuộc tuần tự sai.; Các nhãn hành động không song song: "dùng", "đọc", "theo dõi", "chuẩn bị", "kiểm tra" mô tả mức quan hệ khác nhau; chuẩn hóa nhãn theo mục đích sử dụng cụ thể.
assets/diagrams/18-testing-fundamentals-for-ba-015-d3c380ae.mmd — REVISE — "Consumer" và "Authorized owner" không xác định vai trò cụ thể trong bảng; cần chỉ rõ người nhận quyết định trong thẩm quyền và owner tương ứng với loại boundary.; Gateway "Expected result clear?" chưa bao quát trường hợp expected result rõ nhưng mâu thuẫn test basis, business rule hoặc nguồn canonical; cần thể hiện nhánh escalation cho xung đột này.; Gateway boundary bỏ sót API/integration contract, dữ liệu và quyền production, accessibility, food safety, traceability, release risk, cam kết khách hàng; cần bổ sung các boundary và ngoại lệ trọng yếu được nêu trong bảng.; "business boundary" quá rộng, không thể hiện quyết định làm thay đổi business outcome, giá, doanh thu, chính sách hoặc xung đột giữa đơn vị nghiệp vụ; cần dùng điều kiện escalation cụ thể.; Luồng "Authorized owner gives decision" bỏ sót yêu cầu "Verification required" trước production đối với Legal, Accounting, Security và Food-safety; cần thể hiện điều kiện xác minh này.; Sơ đồ không thể hiện nguyên tắc người nhận không tự đổi nguồn canonical; cần biểu diễn giới hạn này trước khi ghi nhận quyết định.
assets/diagrams/18-testing-fundamentals-for-ba-016-7981484f.mmd — REVISE — Nút C chỉ kiểm tra thiếu nghĩa, dữ liệu và quyền quyết định, nhưng bỏ phạm vi quyết định, trạng thái IN_REVIEW và điều kiện chưa baseline/chưa phê duyệt. Bổ sung các điều kiện này vào gateway làm rõ.; Nút D dùng nhãn mơ hồ “Tiêu thụ artifact theo vai trò”, có thể khiến người đọc dùng artifact IN_REVIEW như nội dung đã được phê duyệt. Đổi thành kết quả cụ thể, giới hạn việc sử dụng theo trạng thái và vai trò.; Gateway F hỏi “Câu trả lời vượt thẩm quyền người trả lời?” không chính xác về logic: quyết định hoặc nội dung cần xác nhận mới thuộc hay vượt thẩm quyền. Sửa nhãn để kiểm tra thẩm quyền xác nhận quyết định.; Nút G bỏ yêu cầu ghi câu trả lời vào artifact kiểm soát phù hợp. “Ghi rõ nguồn và quyết định” chưa nêu nơi ghi nhận, trạng thái kiểm soát hoặc liên kết truy vết.; Luồng kết thúc tại G, không thể hiện kết quả sau khi làm rõ: người nhận tiếp tục sử dụng artifact theo vai trò và giới hạn trạng thái. Nối G đến kết quả sử dụng có kiểm soát.; Nút H chỉ định “owner chuyên môn”, hẹp hơn prose và bảng, nơi escalation có thể đến Architect, Business Owner, PM/Product Owner hoặc owner có thẩm quyền khác. Dùng nhãn owner có thẩm quyền quyết định.
assets/diagrams/18-testing-fundamentals-for-ba-017-9ab425c4.mmd — REVISE — Nhãn "Sales Executive mở đơn SO-20260807-001" mô tả mở đơn có sẵn, trong khi kịch bản nói người dùng tạo đơn; sửa nhãn để phản ánh thao tác tạo đơn hoặc trạng thái Draft được hỗ trợ.; Nhãn "Không kiểm tra hoặc hiển thị hạn mức trong kịch bản" suy diễn hệ thống không kiểm tra nội bộ; bằng chứng chỉ xác nhận màn hình không hiển thị hạn mức và luồng quan sát không chặn 15%, không yêu cầu lý do, không tạo yêu cầu phê duyệt. Sửa thành hành vi quan sát được.; Sơ đồ không thể hiện kết quả cụ thể "Lưu nháp thành công" và thông báo tương ứng, dù đây là outcome chính của Current Behavior; bổ sung outcome này.; Sơ đồ không thể hiện ranh giới bằng chứng: hành vi thuộc ERP mô phỏng và chưa được xác minh cho ERP thực tế. Bổ sung nhãn hoặc note để tránh biến quan sát giả định thành fact vận hành.; Luồng gần như lặp nguyên văn chuỗi thao tác và phép tính trong prose, chưa bổ sung cấu trúc quyết định, ranh giới hoặc quan hệ giúp hiểu thêm; cần làm rõ giá trị phân tích mà sơ đồ mang lại nhưng không viết lại nội dung ngoài fact đã có.
assets/diagrams/18-testing-fundamentals-for-ba-018-46e11b7d.mmd — REVISE — Gateway WH-HCM-01 = 80? hỏi phép so sánh bằng, nhưng nhánh Đủ tồn đòi so sánh tồn khả dụng với số lượng yêu cầu 100. Sửa điều kiện thành phép kiểm tra đủ hoặc thiếu so với yêu cầu; giữ các nhánh song song và loại trừ lẫn nhau.; Nhánh Đủ tồn dẫn đến Tạo phiếu giao đủ số lượng, nhưng section chỉ đặc tả test case thiếu tồn 80/100; kết quả và trạng thái sau nhánh đủ tồn chưa được nêu. Bỏ nhánh này hoặc bổ sung test basis được prose hỗ trợ trước khi giữ.; Nút Theo khuyến nghị OPT-NF-003 chưa thể hiện chính sách đang IN_REVIEW, chưa có approval reference và cần Business Owner cùng Warehouse Manager xác nhận. Gắn rõ trạng thái dự thảo để tránh trình bày khuyến nghị như luồng đã phê duyệt.; Kết quả cuối chỉ nói giữ 20 thùng chưa giao, chưa thể hiện đơn không bị đánh dấu hoàn tất toàn bộ như TC-NF-INV-001. Sửa trạng thái cuối thành kết quả cụ thể gồm số còn chờ và trạng thái chưa hoàn tất.
assets/diagrams/18-testing-fundamentals-for-ba-019-28a6daa4.mmd — REVISE — Gateway số lượng thiếu điều kiện requestedQuantity > 0 của BR-NF-INV-001. Sửa nhãn để kiểm tra đồng thời requestedQuantity > 0 và requestedQuantity <= availableQuantity, hoặc thêm nhánh từ chối riêng có kết quả được prose hỗ trợ.; Hai nhánh lỗi chỉ nêu HTTP status và mã lỗi, bỏ hệ quả bắt buộc của BR-NF-INV-003: không tạo allocation và không thay đổi availableQuantity. Bổ sung trạng thái này vào kết quả lỗi.; Gateway ngày không thể hiện ranh giới so sánh theo ngày YYYY-MM-DD tại Asia/Ho_Chi_Minh. Bổ sung ranh giới này để tránh hiểu thành so sánh timestamp hoặc múi giờ khác.
assets/diagrams/18-testing-fundamentals-for-ba-020-31ee95ff.mmd — REVISE — Các cạnh SM --> CA --> CM không thể hiện quan hệ dependency đã nêu trong bảng: 00_SOURCE_MAP, 01_CURRICULUM_ARCHITECTURE và CHAPTER_MANIFEST đều là upstream trực tiếp của section 9. Cách vẽ hiện tại còn ngụ ý CHAPTER_MANIFEST phụ thuộc vào architecture nhưng không phụ thuộc vào handbook. Cần biểu diễn rõ quan hệ của từng artifact với H, chỉ giữ chuỗi giữa các artifact nếu section xác nhận chuỗi đó.; Nút Test artifact và template liên quan gộp hai downstream có vai trò và boundary khác nhau: Test case và test evidence dùng nguồn để xác định test basis và expected result; Template test dùng persistent ID. Cần tách thành hai nút downstream với nhãn cụ thể.; Nhãn chuỗi học không diễn đạt vai trò được mô tả trong bảng: architecture xác định testing nhận test basis từ requirement, rule, data và acceptance criteria. Cần dùng nhãn concrete phản ánh dependency này.; Sơ đồ bỏ mất các boundary quan trọng: không tự tạo business rule, không tự cấp ID, payload không thay data dictionary, manifest không đồng nghĩa template đã hoàn chỉnh hoặc được approval. Nếu sơ đồ chỉ nhằm thể hiện dependency, cần làm rõ phạm vi đó để không khiến các cạnh bị hiểu như bảo đảm nội dung hoặc approval.
assets/diagrams/18-testing-fundamentals-for-ba-022-45e528cb.mmd — REVISE — Luồng kiểm soát thiếu thông báo cho bên giữ artifact phụ thuộc, dù phần prose xác định đây là thành phần bắt buộc để tránh thay đổi im lặng. Bổ sung bước thông báo hoặc xác nhận tiếp nhận.; Bước "Ghi nhận version và lịch sử thay đổi" đặt sau cập nhật và kiểm tra, khiến các bước trước có thể dùng nội dung chưa được định danh phiên bản. Đặt việc ghi nhận version tại thời điểm canonical artifact thay đổi và kiểm tra liên kết với đúng phiên bản đã được xem xét.; Nhãn "Kiểm tra liên kết và test basis" chưa thể hiện tiêu chí cốt lõi: liên kết phải trỏ đến đúng phiên bản nội dung. Làm rõ kiểm tra phiên bản đích của liên kết.; Sơ đồ không thể hiện bên giữ artifact phụ thuộc hoặc trách nhiệm cập nhật, tạo khoảng trống ownership quan trọng.
assets/diagrams/18-testing-fundamentals-for-ba-023-5267d7b3.mmd — REVISE — Nhãn "So expected result" mơ hồ và thiếu tự nhiên; cần nêu hành động cụ thể là đối chiếu kết quả thực tế với expected result đã xác định.; Nhánh "Khớp" dẫn thẳng đến "Pass có bằng chứng" nhưng không thể hiện bằng chứng bắt buộc trong tình huống: response, thông báo và xác nhận không có đơn hợp lệ được tạo.; Nhánh "Không khớp" luôn dẫn đến "Ghi defect"; section yêu cầu liên kết defect với requirement hoặc acceptance criteria và không tự tạo rule mới, nên cần thể hiện bước xác nhận test basis trước khi kết luận defect.; Bước "Sửa và đánh giá tác động" không có actor, thẩm quyền hoặc quy trình sửa lỗi được section hỗ trợ; cần bỏ bước này hoặc giới hạn diagram ở ghi nhận defect và chạy lại sau khi có bản sửa được xác nhận.; Diagram bỏ qua trạng thái "chưa đủ bằng chứng" và hành động phục hồi an toàn là bổ sung expected result rồi chạy lại trên dữ liệu test kiểm soát.; Diagram không thể hiện ranh giới trách nhiệm quan trọng giữa BA, QA và Business Owner, dù section quy định rõ quyền duy trì test basis, thực thi kỹ thuật và xác nhận ý nghĩa nghiệp vụ.
assets/diagrams/18-testing-fundamentals-for-ba-024-4db856b9.mmd — REVISE — Nút “Đặt warning” không thể hiện bốn phần bắt buộc trong prose: đối tượng rủi ro, hậu quả, bằng chứng thiếu và hành động chặn. Cần làm rõ đủ bốn phần.; Các bước “Giữ bằng chứng hiện có, không sửa im lặng”, “Chuyển đúng owner có thẩm quyền” và “Chỉ cập nhật artifact khi có quyết định được ghi nhận” bổ sung quy trình quản trị chưa được section xác lập. Cần bổ sung prose hỗ trợ hoặc bỏ khỏi diagram.; Nhãn “đúng owner có thẩm quyền” mơ hồ; section chỉ nêu Security review trong ví dụ. Cần chỉ rõ owner theo loại rủi ro hoặc giới hạn nhãn về Security trong phạm vi ví dụ.; Nhánh “Không” dẫn đến “Ghi lỗi tài liệu hoặc làm rõ bình thường” tạo kết luận chưa được prose hỗ trợ và bỏ qua trường hợp dùng kết quả quá phạm vi nhưng chưa thuộc bốn nhóm hậu quả liệt kê. Cần xác định tiêu chí xử lý từ section.; Gateway liệt kê mất dữ liệu, sai tiền, lộ dữ liệu và kết luận pháp lý, trong khi prose chỉ trực tiếp minh họa rủi ro bảo mật và kết luận security. Cần bổ sung căn cứ trong prose hoặc thu hẹp phạm vi gateway.
assets/diagrams/18-testing-fundamentals-for-ba-025-26379d43.mmd — REVISE — Gateway “Có rule canonical và authority?” mơ hồ và dễ coi catalog IN_REVIEW là bằng chứng phê duyệt. Cần phân biệt nguồn canonical hợp lệ với xác nhận từ owner có thẩm quyền.; Bước “Chuyển đúng owner xác nhận” không thể hiện ranh giới thẩm quyền giữa Business Owner, Accounting Owner, Legal, Architect và QA. Cần chỉ rõ owner theo nội dung cần xác nhận.; Bước “Requirement có điều kiện đo được” bỏ thiếu trạng thái phiếu và ngoại lệ kiểm thử được, dù đây là tiêu chí quyết định bắt buộc trong prose.; Chuỗi “Acceptance criteria” đến “Test case và expected result” có thể ngụ ý QA được tạo expected result trước khi ngưỡng và công thức có nguồn hợp lệ. Cần thể hiện test chỉ xác minh xử lý cấu hình sau khi nguồn hợp lệ tồn tại.; Nhãn “Liên kết registry kiểm tra” không cụ thể: không rõ registry nào, đối tượng liên kết nào, hay thao tác kiểm tra gì. Cần nêu rõ liên kết truy vết tới registry và nguồn quản trị liên quan.; Sơ đồ không thể hiện nhánh xử lý khi test basis thiếu hoặc sai: dừng dùng expected result, đánh dấu test không hợp lệ, giữ lịch sử thay đổi và lấy xác nhận owner. Thiếu nhánh này làm mờ recovery an toàn được prose nhấn mạnh.
assets/diagrams/18-testing-fundamentals-for-ba-026-65f072aa.mmd — REVISE — Gateway chỉ kiểm tra ID và filename, trong khi Decision Criteria yêu cầu cả owner và trạng thái có bằng chứng canonical. Sửa điều kiện để bao gồm đủ ID, filename, owner và trạng thái.; Nhánh Có cho phép dùng artifact ngay nhưng không kiểm tra artifact canonical hiện có hoặc phân biệt template với completed artifact. Bổ sung kiểm tra tương ứng với cả hai loại artifact.; Sơ đồ bỏ trạng thái quan trọng: chưa có template testing hoặc completed artifact testing được seed xác nhận. Thể hiện rõ kết quả này trên nhánh Không.; Sơ đồ bỏ giới hạn nội dung không được hàm ý approval. Bổ sung điều kiện hoặc kết quả nêu artifact không mặc nhiên được phê duyệt.; Nhãn "Escalate" không đồng nhất ngôn ngữ và không nêu mục đích hành động. Đổi thành nhãn tiếng Việt cụ thể, như "Yêu cầu Principal IT Business Analyst / Technical Curriculum Author xác minh manifest".; Sơ đồ bỏ hậu quả trọng yếu khi chọn sai nguồn: sai source of truth, sai owner hoặc bị hiểu nhầm là artifact đã phê duyệt. Bổ sung outcome cảnh báo phù hợp.
assets/diagrams/18-testing-fundamentals-for-ba-027-4472c56b.mmd — REVISE — Thiếu nhánh khi template hoặc filled artifact chưa có entry trong TEMPLATE_MANIFEST. Bổ sung gateway kiểm tra đăng ký và outcome “Chưa có location đã xác minh; không tạo ID, path, filename hoặc artifact thay thế”.; Nhãn “Tra rule và data canonical” mơ hồ, gộp hai dependency khác nhau. Tách hoặc ghi rõ CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY.; Điều kiện “ID và path đã đăng ký” chưa đủ cho completed artifact. Bổ sung các thuộc tính section yêu cầu xác minh: filename, location, owner, consumer và trạng thái.; Luồng bỏ qua kiểm tra trạng thái quản trị IN_REVIEW, v0.9.0, 2026-08-07, tạo nguy cơ diễn giải sai thành approved hoặc baseline. Bổ sung bước hoặc điều kiện giữ nguyên trạng thái nguồn.
assets/diagrams/18-testing-fundamentals-for-ba-028-442263c6.mmd — REVISE — IN_REVIEW là trạng thái không được phần văn xuôi xác lập; bỏ trạng thái này hoặc bổ sung căn cứ trong văn xuôi.; Ghi open issue và evidence thêm artifact và bước xử lý chưa được mô tả; cần bỏ hoặc bổ sung quy trình tương ứng.; Escalate đúng owner thêm hành động và vai trò mơ hồ; cần chỉ rõ chủ thể có thẩm quyền theo từng loại kết luận hoặc bổ sung định nghĩa owner trong văn xuôi.; Nhánh Không dẫn thẳng đến handoff nhưng không thể hiện việc duy trì nhãn Verification required cho kết luận chưa được xác minh; cần bảo đảm điều kiện này áp dụng độc lập với việc có mâu thuẫn.; source boundary và Chapter testing draft chưa cụ thể, không dùng thuật ngữ được định nghĩa rõ trong phần văn xuôi; cần đổi thành artifact hoặc ranh giới dữ liệu cụ thể.
assets/diagrams/19-black-box-testing-techniques-for-ba-001-1f11466d.mmd — REVISE — Gateway “Đầu vào thỏa rule mô phỏng?” mơ hồ và buộc người đọc tra prose. Cần nêu trực tiếp điều kiện: Lot Code bắt buộc, dài 1–12 ký tự, chỉ gồm A-Z, 0-9 và dấu gạch ngang.; Nhãn nhánh “Có” và “Không” không chỉ rõ nhóm dữ liệu. Cần dùng nhãn song song, cụ thể như “Hợp lệ” và “Không hợp lệ”.; Kết quả “hiển thị lỗi quan sát được” quá chung, không cho biết lỗi tương ứng với rỗng, quá dài hoặc sai ký tự. Cần thể hiện ít nhất các nhóm từ chối đã nêu trong prose, không tự đặt nội dung thông báo lỗi.
assets/diagrams/19-black-box-testing-techniques-for-ba-002-4c0b074a.mmd — REVISE — Nhánh dữ liệu không hợp lệ bỏ sót số nguyên âm, dù phần prose nêu rõ cần kiểm tra số âm và quy tắc chỉ chấp nhận từ 1 đến 500. Bổ sung số âm vào điều kiện dẫn đến “Từ chối và báo lỗi”.
assets/diagrams/19-black-box-testing-techniques-for-ba-003-70175c8c.mmd — REVISE — Gateway Có nguồn quan sát được hoặc artifact kiểm soát? đánh đồng khả năng truy nguồn với xác minh nội dung. Stakeholder input cũng có nguồn quan sát được nhưng không thành verified fact. Sửa tiêu chí thành nội dung đã được artifact có thẩm quyền xác nhận hay chưa, đồng thời giữ provenance riêng.; Gateway Được chọn bởi thẩm quyền ghi nhận? mơ hồ và dùng bị động. Sửa thành tiêu chí cụ thể về quyết định: Thẩm quyền phù hợp đã phê duyệt hoặc ghi nhận lựa chọn này?.; Nhánh Verification-required claim thiếu bước chuyển Business Owner, Legal Owner, Accounting Owner, Architect hoặc QA phù hợp để xác minh. Bổ sung owner xác minh trước kết quả Không tạo expected result.; Nhánh Decision đi thẳng tới Test condition nhưng thiếu điều kiện quyết định phải liên quan hành vi, trong khi nhánh fact có điều kiện này. Áp dụng cùng điều kiện để tránh tạo test condition từ quyết định không chi phối hành vi.; Kết quả Phân tích thêm không nêu hành động bắt buộc trong prose: ghi nguồn input và hỏi phạm vi, ngoại lệ, ưu tiên lô. Đổi thành kết quả cụ thể, không để trạng thái mở mơ hồ.; Sơ đồ không thể hiện ngoại lệ quan trọng Chưa có quyết định dẫn tới Không tạo expected result cho partial shipment. Bổ sung ranh giới này để tránh diễn giải thiếu quyết định thành project assumption có thể dùng cho test tạm.
assets/diagrams/19-black-box-testing-techniques-for-ba-004-c95f2520.mmd — REVISE — Nhãn Entry: mục tiêu, actor, sự kiện trên luồng Discovery → Analysis không khớp entry gate của Analysis: phạm vi hành vi và nguồn đầu vào truy vết được. Cần sửa nhãn theo gate này hoặc thể hiện đây là đầu vào của Discovery.; Luồng Delivery → Testing chỉ nêu bản triển khai và thay đổi, nhưng entry gate của Testing còn yêu cầu test basis, môi trường và dữ liệu tổng hợp. Cần thể hiện đủ các dependency này.; Luồng Testing → Release chỉ nêu kết quả Pass Fail Blocked có evidence, nhưng entry gate của Release còn gồm lỗi đang mở và tiêu chí release đã ghi nhận. Cần bổ sung để tránh mô tả sai điều kiện phát hành.; Luồng Operations chỉ quay về Discovery, trái với prose và exit gate cho phép insight quay lại Discovery hoặc Analysis. Cần thêm nhánh Operations → Analysis với evidence.; Các nhãn luồng trộn Entry, Exit và sự kiện không theo cấu trúc song song. Cần dùng nhất quán loại gate hoặc mô tả đầu ra chuyển giao giữa các giai đoạn.
assets/diagrams/19-black-box-testing-techniques-for-ba-005-c1ac76e2.mmd — REVISE — Luồng "BA -->|Quyet dinh nghiep vu| QA" mâu thuẫn phân quyền: BA không đưa ra quyết định kinh doanh cuối cùng. Xóa luồng này hoặc đổi thành nội dung BA thực sự sở hữu, như "Làm rõ ý nghĩa nghiệp vụ".; Sơ đồ bỏ thiếu Data Owner và luồng bàn giao test data từ BA, Data Owner sang QA Tester, gồm dữ liệu tổng hợp, phân loại dữ liệu và điều kiện biên.; Sơ đồ bỏ thiếu ranh giới quyền đối với dữ liệu: QA không dùng dữ liệu cá nhân thật, BA không cấp quyền môi trường.; Luồng xử lý defect chưa thể hiện Business Owner quyết định chấp nhận rủi ro nghiệp vụ; hiện sơ đồ có thể khiến BA hoặc Developer bị hiểu là owner quyết định.; Luồng "DEV -->|Technical constraint| ARCH" thiếu BA trong escalation về tính khả thi kỹ thuật và ảnh hưởng tích hợp, trong khi phần prose yêu cầu Solution Architect và BA cùng tham gia.; Luồng "QA -->|Security or data risk| SEC" quá rộng và thiếu điều kiện cụ thể. Gắn escalation với dữ liệu nhạy cảm hoặc quyền truy cập quá mức; đồng thời thể hiện nguồn bàn giao liên quan là BA, Data Owner.; Sơ đồ bỏ thiếu escalation cho lỗi giá, thuế, kế toán và an toàn thực phẩm tới owner chuyên môn phù hợp.; Nhãn không dấu như "Rule va uu tien" và "Quyet dinh nghiep vu" kém nhất quán với nội dung tiếng Việt có dấu. Dùng nhãn có dấu, cụ thể và song song.
assets/diagrams/19-black-box-testing-techniques-for-ba-006-6489ae81.mmd — REVISE — Nút Release thêm điều kiện “theo quyết định có thẩm quyền”, trong khi phần văn xuôi tuyên bố không xác nhận approval hoặc quyền đưa vào production. Bỏ điều kiện này hoặc bổ sung văn xuôi xác lập rõ đây là nguyên tắc kiểm soát chung, không phải trạng thái approval của case study.; Luồng Operations → Discovery chỉ thể hiện sự cố hoặc nhu cầu mới, chưa thể hiện luận điểm kỹ thuật hộp đen tiếp tục tạo bằng chứng sau phát hành. Bổ sung luồng phản hồi từ Operations tới Analysis hoặc Testing với bằng chứng quan sát, sai lệch kết quả hoặc điều kiện kiểm tra cần cập nhật.; Chuỗi mũi tên liền tạo cảm giác quy trình stage-gate tuyến tính từ Discovery đến Operations, dễ bị hiểu là quy trình ERP thực tế dù phần văn xuôi phủ nhận điều đó. Phân biệt rõ vòng đời khái niệm với workflow, baseline và approval thực tế.
assets/diagrams/19-black-box-testing-techniques-for-ba-007-b1482b04.mmd — REVISE — Nhãn “Kết quả chạy: pass, fail hoặc blocked” nêu ba trạng thái không được phần văn xuôi định nghĩa hoặc giải thích. Bổ sung căn cứ trong văn xuôi hoặc bỏ các trạng thái khỏi sơ đồ.; Sơ đồ không thể hiện Canonical ID được giữ nguyên qua các artifact, dù đây là cơ chế truy ngược trọng tâm của phần. Thể hiện ID xuyên suốt hoặc quan hệ truy vết từ test condition về nguồn.; Nhãn “Nguồn gốc: requirement, rule, data” mơ hồ: “data” có thể là dữ liệu nguồn, dữ liệu kiểm thử hoặc bằng chứng. Dùng nhãn cụ thể, song song với các loại test basis được văn xuôi xác nhận.
assets/diagrams/19-black-box-testing-techniques-for-ba-008-5979db96.mmd — REVISE — Nhãn ID + nguồn + ngày + owner bỏ sót version, status, ranh giới sử dụng và kiểm tra thẩm quyền; sửa điều kiện chuyển sang Qualified để phản ánh đủ tiêu chí chất lượng trong bảng.; Nhánh Qualified --> Stop: mâu thuẫn hoặc nguồn cũ dùng nguồn cũ quá rộng; prose chỉ yêu cầu dừng khi có bản mới chưa được đánh giá. Sửa nhãn thành điều kiện cụ thể này và giữ escalation cho trường hợp mâu thuẫn.; Nhánh VerificationRequired --> Stop biến trạng thái chờ xác minh thành kết thúc bắt buộc, trong khi prose cho phép gắn nhãn, chờ owner xác nhận và chưa tạo expected result bắt buộc. Cần thể hiện khả năng quay lại đánh giá sau khi có đủ bằng chứng hoặc owner xác nhận.; Trạng thái Stop gộp ba kết quả khác nhau: dừng vì bản mới chưa đánh giá, dừng và escalation vì mâu thuẫn, và chờ owner quyết định. Tách hoặc đặt nhãn kết quả cụ thể để không làm sai hành động và trách nhiệm.; Sơ đồ không thể hiện ranh giới quan trọng: Qualified chỉ xác nhận độ tin cậy và khả năng kiểm thử, không xác nhận nội dung đúng cho production. Cần làm rõ giới hạn này trong trạng thái hoặc nhãn chuyển tiếp.
assets/diagrams/19-black-box-testing-techniques-for-ba-009-319d8312.mmd — REVISE — Bước "BA kiểm tra ID và trạng thái" không có kết quả hoặc nhánh xử lý khi ID chưa đăng ký, artifact thiếu, hoặc trạng thái chưa cho phép sử dụng. Thêm gateway và nhánh dừng/xác minh tương ứng.; Gateway "Có rule và dữ liệu canonical?" chưa bao quát yêu cầu về ID canonical, đường dẫn nguồn, miền dữ liệu và kết quả mong đợi. Sửa điều kiện để phản ánh đủ bằng chứng tối thiểu cần cho thiết kế test.; Nhãn "STOP cho ca test cần rule chưa xác minh" chỉ đề cập rule, trong khi nhánh "Không" có thể do thiếu dữ liệu canonical, thuộc tính dữ liệu, miền giá trị hoặc kết quả mong đợi. Dùng nhãn kết quả bao quát đúng mọi nguyên nhân.; Luồng "Có" đi thẳng tới thiết kế test dù trạng thái nguồn có thể là IN_REVIEW và cần Business Owner, Data Owner, Legal Owner hoặc Accounting Owner xác nhận. Thể hiện ranh giới: có thể thiết kế test dự thảo nhưng không được coi là đã phê duyệt hoặc sẵn sàng production.; Nhãn "Artifact nguồn" và "rule" chưa nhất quán, chưa đủ cụ thể trong ngữ cảnh tiếng Việt. Dùng thuật ngữ cụ thể, song song như "artifact nguồn canonical" và "quy tắc nghiệp vụ".
assets/diagrams/19-black-box-testing-techniques-for-ba-010-3976ac6b.mmd — REVISE — Gateway E gộp hai điều kiện độc lập: có quy tắc nguồn và kết quả khớp. Nhãn nhánh Có mơ hồ. Tách kiểm tra nguồn quy tắc khỏi so sánh kết quả, hoặc đổi nhãn thành điều kiện đầy đủ.; Luồng Blocked chỉ thể hiện thiếu quy tắc nguồn, bỏ sót hai nguyên nhân được nêu trong bảng: thiếu môi trường và thiếu dữ liệu. Bổ sung các điều kiện Blocked này.; Nhánh Fail mặc định chuyển QA reviewer, trong khi phần prose yêu cầu chuyển đúng vai trò có thẩm quyền. Thể hiện QA reviewer soát xét sai lệch và chuyển Business Owner, Accounting Owner hoặc Legal Owner khi phạm vi quyết định yêu cầu.; Luồng không thể hiện ranh giới thẩm quyền với quy tắc ảnh hưởng hạch toán, hóa đơn hoặc nghĩa vụ pháp lý. Bổ sung nhánh xem xét bởi Accounting Owner hoặc Legal Owner khi có tác động tương ứng.; Nhãn Controlled handoff trộn ngôn ngữ và không nêu đích bàn giao. Đổi thành nhãn tiếng Việt cụ thể, xác định artifact và vai trò nhận.
assets/diagrams/19-black-box-testing-techniques-for-ba-011-d553fa61.mmd — REVISE — Luồng C --> E bỏ qua phụ thuộc dữ liệu kiểm thử. Thêm quan hệ từ Test data set đến Test execution log để thể hiện lần chạy sử dụng dữ liệu đã xác định.; Traceability matrix phải liên kết trực tiếp với quy tắc nguồn, nhưng sơ đồ chỉ nối gián tiếp qua test condition. Thêm quan hệ từ Quy tắc nguồn hoặc giả định có nhãn đến Traceability matrix.; Nhãn Issue register khi có Fail thu hẹp điều kiện tạo issue thành trạng thái Fail, trong khi prose quy định tạo liên kết issue khi phát hiện sai lệch và cấm gọi defect đã xác nhận trước QA. Đổi điều kiện sang sai lệch được ghi nhận và giữ ranh giới xác nhận của QA.; Sơ đồ bỏ qua TRACEABILITY_ID_REGISTRY, dù đây là nguồn kiểm soát ID cho mọi artifact và có ngoại lệ bắt buộc khi chưa cấp canonical ID. Thể hiện registry như phụ thuộc kiểm soát cùng trạng thái Verification required — chưa cấp canonical ID.; Sơ đồ không thể hiện ranh giới trách nhiệm quan trọng: BA chuẩn bị artifact, QA reviewer review độc lập và sở hữu execution log cùng issue register. Bổ sung actor hoặc swimlane để tránh ngụ ý chuỗi artifact tự vận hành.
assets/diagrams/19-black-box-testing-techniques-for-ba-012-3ba31a36.mmd — REVISE — Luồng bỏ qua Test objective và Preconditions dù đây là thành phần bắt buộc chi phối phạm vi, trạng thái ban đầu và khả năng tái lập test case; cần thể hiện chúng trong quan hệ truy vết hoặc xác định rõ sơ đồ chỉ mô tả luồng đối chiếu kết quả.; Expected result đang được suy ra từ Test steps qua nhánh D --> E, trong khi prose quy định expected result phải có căn cứ từ requirement, business rule, acceptance criterion hoặc contract; cần nối Test basis với Expected result.; Nút So sánh thiếu điều kiện Expected result = Actual result và Expected result != Actual result; cần thể hiện gateway cùng hai nhánh kết quả.; Nhãn Test result hoặc defect reference mơ hồ và che mất quy tắc chỉ tạo Defect reference khi actual result khác expected result; cần tách Pass khỏi Fail và Defect reference.; Actual result và evidence gộp hai thành phần có vai trò khác nhau; cần thể hiện Evidence reference là bằng chứng hỗ trợ Actual result, không phải cùng một kết quả.
assets/diagrams/19-black-box-testing-techniques-for-ba-013-1a1218f7.mmd — REVISE — Trạng thái Draft và chuyển tiếp Draft --> IN_REVIEW không được phần văn xuôi hỗ trợ; cần loại bỏ hoặc bổ sung căn cứ trong phần văn xuôi.; Nhánh IN_REVIEW --> Rework_required mâu thuẫn với quy tắc “Nếu thiếu một tiêu chí, giữ trạng thái IN_REVIEW”; cần giữ trạng thái IN_REVIEW khi thiếu bằng chứng hoặc traceability, không tạo trạng thái mới.; Điều kiện chuyển sang Ready_for_downstream_review chưa thể hiện yêu cầu mọi điểm chưa xác minh phải được gắn nhãn rõ; cần bổ sung điều kiện này vào nhãn chuyển tiếp.; Nhãn “Đạt mọi tiêu chí gate” chưa đủ cụ thể vì bỏ sót hai điều kiện bắt buộc riêng: mọi tiêu chí bắt buộc đạt và mọi điểm chưa xác minh được gắn nhãn rõ.
assets/diagrams/19-black-box-testing-techniques-for-ba-014-92034e8b.mmd — REVISE — Architect bị nối chỉ từ EX, trong khi bảng quy định nhận test condition liên quan tích hợp, test data, execution result và test summary. Cần thể hiện cả đầu vào từ TC.; PM/Product Owner bị nối chỉ từ EX, làm mất traceability—đầu ra được nêu rõ trong bảng. Cần thể hiện traceability hoặc phạm vi liên kết yêu cầu/backlog item.; Specialist owners nhận EX trong sơ đồ, nhưng bảng chỉ quy định test condition và expected result thuộc chuyên môn. Cần bỏ đầu ra không được prose hỗ trợ.; QA không nhận test basis trong sơ đồ dù bảng quy định đầu ra này. Node BA chứa test basis nhưng không nối tới QA; cần thể hiện quan hệ đó.; TC --> EX mơ hồ về actor thực thi và có thể ngụ ý test case tự sinh execution result/test summary. Cần ghi rõ hoạt động hoặc owner tạo kết quả.; Node EX gộp execution result và test summary, khiến mọi consumer nối tới node này trông như nhận cả hai; Developers và Operations chỉ được bảng quy định execution result, không phải test summary. Cần tách hai artifact hoặc giới hạn quan hệ chính xác.; Sơ đồ không thể hiện trạng thái bắt buộc IN_REVIEW, phiên bản v0.9.0, ngày, múi giờ và ranh giới không tạo phê duyệt, baseline, xác nhận tuân thủ hay quyền production. Ít nhất cần thể hiện ranh giới trạng thái/quyền nếu sơ đồ nhằm mô tả luồng bàn giao artifact.
assets/diagrams/19-black-box-testing-techniques-for-ba-015-7a073e84.mmd — REVISE — Branch Q -- No --> B stops after clarification. Add outcome returning clarified canonical behavior to QA for test-basis update, as prose explicitly requires.; Developer and QA decide fix or retest merges distinct authority and actions. Developer fixes or requests clarification; QA records defects, evaluates results, and runs regression. Separate or relabel ownership.; Cross-domain impact? is vague and narrower than escalation criteria. Use concrete conditions covering interface, schema, access rights, integration, data loss, security, operations, legal, accounting, and food safety.; Escalate specialist owner or Architect conflates different escalation targets. Route architecture changes to Architect, operational or production risks to Operations, and regulated domain questions to relevant specialist owner.; R -- No --> P[PM/Product Owner prioritizes] implies every non-cross-domain result requires PM prioritization and places prioritization after Developer/QA action. Show PM/Product Owner only when release priority, scope, commitment, cost, deadline, or owned risk requires decision.; Diagram omits unresolved-oracle and unstable-condition paths assigned to QA, plus production-operation and rollback boundaries assigned to Operations.; Evidence package lacks concrete required contents. Label or expand it to show reproducible steps, synthetic input, expected and actual results, environment, and requirement traceability.
assets/diagrams/19-black-box-testing-techniques-for-ba-016-3d0b1f88.mmd — REVISE — Nhánh “Không” luôn chuyển tới “Owner có thẩm quyền trả lời”, trong khi prose chỉ yêu cầu escalation tới owner chuyên môn khi câu trả lời làm đổi rule, phạm vi API, dữ liệu cá nhân, hạch toán, truy xuất nguồn gốc thực phẩm hoặc quyền vận hành. Cần thể hiện gateway kiểm tra tác động và phân biệt xử lý thông thường với escalation chuyên môn.; Bước “Consumer xác nhận phạm vi dùng” không được prose quy định rõ, đồng thời “Consumer” và “phạm vi dùng” mơ hồ. Cần dùng actor và artifact hoặc quyết định cụ thể có căn cứ trong section, hoặc bỏ bước này.; Sơ đồ không thể hiện ràng buộc quan trọng rằng IN_REVIEW và v0.9.0 không cấu thành approval, baseline, xác nhận tuân thủ hay quyền triển khai. Cần thể hiện boundary này trước outcome thực thi để tránh ngụ ý artifact chưa được phê duyệt đủ quyền cho hành động.; Outcome “Thực hiện quyết định trong phạm vi vai trò” quá chung, không chỉ rõ actor, điều kiện cho phép hoặc loại quyết định. Cần làm rõ chủ thể và giới hạn quyền dựa trên prose.
assets/diagrams/19-black-box-testing-techniques-for-ba-017-cb0408be.mmd — REVISE — Sơ đồ lặp lại gần như nguyên vẹn chuỗi bước trong bảng Current Behavior, không bổ sung quan hệ hoặc thông tin giải thích mới; cần dùng sơ đồ để làm rõ ranh giới UI, API và lưu trữ, hoặc bỏ sơ đồ.; Các nhãn không xác định chủ thể xử lý: POST tạo đơn bán, API trả HTTP 201 Created và Lưu dòng hàng quantity = 0 nằm trong cùng luồng dù thuộc các lớp khác nhau; cần thể hiện rõ actor hoặc boundary UI, API và nơi lưu dữ liệu.; Thứ tự API trả HTTP 201 Created trước Lưu dòng hàng quantity = 0 có thể gây hiểu rằng phản hồi thành công được gửi trước khi lưu; cần thể hiện thứ tự thực tế nếu đã có bằng chứng, nếu chưa thì không khẳng định trình tự này.
assets/diagrams/19-black-box-testing-techniques-for-ba-018-9ec5bbb6.mmd — REVISE — Nhánh C -- Không gộp <= 0 và > 100 nhưng kết quả ghi vượt phạm vi nhận, gây hiểu sai giá trị <= 0. Cần tách hai nhánh biên hoặc đổi nhãn kết quả thành Từ chối: ngoài phạm vi 1 đến 100.
assets/diagrams/19-black-box-testing-techniques-for-ba-019-bfcedddd.mmd — REVISE — WH_USER_01 không được phần xung quanh xác nhận là actor thực hiện yêu cầu; cần dùng actor đã được định nghĩa trong section hoặc bỏ ID actor.; ISS-2026-000731 là mã chứng từ cụ thể không được bảng hỗ trợ; bảng chỉ yêu cầu tạo transactionCode. Cần thay bằng kết quả tạo transactionCode không gắn giá trị cố định.; POSTED không xuất hiện trong kết quả mong đợi; cần bỏ trạng thái này hoặc bổ sung nguồn quy tắc xác nhận.; Nhánh sai định dạng gộp vào ISSUE_QUANTITY_INVALID, nhưng BBT-011 chỉ nêu lỗi định dạng số lượng. Cần dùng đúng lỗi đã xác nhận hoặc tách mã lỗi nếu rule nguồn quy định.; Sơ đồ khẳng định thứ tự kiểm tra số lẻ, giá trị dương rồi tồn khả dụng, trong khi bảng chỉ xác nhận điều kiện và kết quả, không xác nhận thứ tự. Cần tránh biểu diễn thứ tự bắt buộc hoặc dẫn nguồn rule hỗ trợ thứ tự đó.
assets/diagrams/19-black-box-testing-techniques-for-ba-020-692a31f4.mmd — REVISE — Hai cạnh B --> C và B --> D đảo chiều dependency, ngụ ý BA Activities tạo CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY; sửa để nguồn canonical cung cấp đầu vào cho BA Activities hoặc trực tiếp cho test design.; CHAPTER_MANIFEST có trong bảng dependency nhưng bị bỏ khỏi sơ đồ; thêm dependency này với vai trò kiểm soát filename và phạm vi chapter, hoặc giới hạn rõ sơ đồ chỉ mô tả luồng tạo test artifact.; Nhãn Mục 4 Input cần thiết, Mục 5 BA Activities, Mục 6 Output thu được chỉ tham chiếu vị trí, chưa mô tả input, hoạt động và output cụ thể; thay bằng nhãn hành động hoặc artifact cụ thể, có thể giữ số mục làm ngữ cảnh.; Cạnh E --> H ngụ ý test design tạo ra mục worked example, trong khi prose chỉ cho biết đây là vị trí trình bày ví dụ; đổi quan hệ thành ví dụ minh họa hoặc hiện thực hóa test design.; Cạnh I --> G không cho biết TEMPLATE_MANIFEST xác định template dự kiến chứ không xác nhận template đã tạo, baseline hoặc approved; làm rõ điều kiện này trong nhãn quan hệ hoặc node.
assets/diagrams/19-black-box-testing-techniques-for-ba-021-26faa409.mmd — REVISE — Missing direct REQ → DATA/API path. Section defines REQ/BR → DATA/API; add REQ dependency or otherwise show both supported sources.; Label "DATA/API canonical" overstates source status. DATA uses canonical data dictionary, while API uses registered API artifact; distinguish them or use wording covering both statuses.; Combined "DATA/API" node hides distinct evidence and interfaces: DATA requires fields, types, and constraints; API may require contract, inputs, outputs, error codes, and HTTP responses. Separate paths or clarify combined scope.
assets/diagrams/19-black-box-testing-techniques-for-ba-022-4c573fd3.mmd — REVISE — Nhãn "DATA/API and test-data review" đưa API vào dù phần văn bản không đề cập API; bỏ API và chỉ giữ việc xem lại dữ liệu kiểm thử.; Các viết tắt "REQ", "AC" và "TC" làm nhãn kém cụ thể; dùng tên artifact đầy đủ như trong phần văn bản.; Nhãn "Canonical source changed" thu hẹp "nguồn phụ thuộc" thành nguồn chuẩn hóa dù phần văn bản chỉ nêu catalog quy tắc như ví dụ; đổi nhãn để phản ánh mọi nguồn phụ thuộc.; Bước "Traceability evidence updated" chưa được phần mô tả chuỗi tác động xác lập rõ; liên kết truy vết, version, lịch sử và thông báo review chỉ xuất hiện như thuộc tính bị thiếu của thay đổi im lặng. Cần giới hạn bước cuối theo nội dung được nêu rõ hoặc bổ sung căn cứ trong văn bản.; Sơ đồ gần như lặp nguyên chuỗi artifact đã được mô tả bằng văn xuôi; cần bảo đảm hình thể hiện quan hệ phụ thuộc hoặc phạm vi tác động rõ hơn thay vì chỉ chuyển danh sách thành luồng.
assets/diagrams/19-black-box-testing-techniques-for-ba-023-01344961.mmd — REVISE — Gateway “Expected result có nguồn?” đặt sau “Chạy test”, trái với prose yêu cầu liên kết TC tới REQ, AC hoặc rule canonical và xác định expected result trước khi chạy. Chuyển kiểm tra nguồn sang trước thiết kế hoặc trước chạy test; chỉ chạy khi test basis và oracle đã đủ.; Nhánh “Không” chỉ ghi gap và dừng kết luận, bỏ thiếu bước chuyển Business Owner hoặc owner phù hợp xác nhận. Bổ sung owner và kết quả xác nhận trước khi tiếp tục thiết kế hoặc kết luận.; Nhãn “Test basis có ID” hẹp hơn prose: test basis có thể là requirement, business rule, acceptance criteria hoặc đặc tả giao diện/API; prose yêu cầu liên kết nguồn canonical nhưng không khẳng định mọi nguồn đều có ID. Đổi nhãn để diễn đạt test basis có nguồn truy vết, hoặc làm rõ ID áp dụng cho REQ/AC.
assets/diagrams/19-black-box-testing-techniques-for-ba-024-09c2c2db.mmd — REVISE — Gateway B đưa thêm “sai tiền” và “lộ dữ liệu”, nhưng tình huống không xác lập hai rủi ro này; thay bằng tiêu chí được nêu rõ: tồn âm, ảnh hưởng giao dịch kho, sai truy vết và chưa rõ phạm vi đồng bộ.; Nhánh “Không” không phù hợp với tình huống đã xác nhận tồn âm và quyết định TC-OUT-014 = Fail; bỏ nhánh này hoặc biểu diễn điều kiện xử lý khác có căn cứ trong phần prose.; Nút C thiếu kết quả bắt buộc TC-OUT-014 = Fail; thêm trạng thái này cùng cảnh báo và dừng test phụ thuộc.; Nút D ghi “input, output, thời điểm, ID” quá chung và thiếu bằng chứng đã yêu cầu; nêu request, response, ảnh màn hình, thời điểm 2026-08-07 theo Asia/Ho_Chi_Minh và liên kết defect record.; Nút F không thể hiện điều kiện hoàn tác chỉ trong môi trường test và bằng chức năng hệ thống đã được xác định; bổ sung hai ranh giới này.; Luồng thiếu quyền hạn và phối hợp owner: QA Lead xác nhận kết quả, Business Owner xác nhận hành vi, Architect xác định phạm vi tích hợp, Accounting Owner quyết định phục hồi khi có tác động kế toán; không được suy diễn thành phê duyệt production.; Nút G “Tạo dữ liệu tổng hợp sạch và chạy lại” chưa được Decision cam kết sau hoàn tác; bỏ bước hoặc bổ sung prose làm căn cứ và điều kiện chạy lại.; Các hành động không nêu actor dù quyền hạn là ranh giới trọng yếu; gắn actor phù hợp cho xác nhận kết quả, xác định đồng bộ và quyết định phục hồi.
assets/diagrams/19-black-box-testing-techniques-for-ba-025-7083d902.mmd — REVISE — Nhánh sau “Có Rule ID canonical?” bỏ qua các điều kiện bắt buộc: ngưỡng, toán tử so sánh, vai trò duyệt, trạng thái trước/sau và kiểm tra không mâu thuẫn IN_REVIEW. Bổ sung các điều kiện này trước bước thiết kế test.; Nhãn “Có authority và trạng thái ghi nhận?” gộp nhiều khái niệm, không xác định authority là nguồn xác nhận hay vai trò duyệt, và không nêu trạng thái trước/sau. Tách hoặc đổi thành các gateway cụ thể, song song với Decision Criteria.; Kết quả khi thiếu test basis chưa nêu quyết định quan trọng: TC-ORD-017 không được kết luận pass hoặc fail. Bổ sung outcome này vào nhánh thiếu dữ liệu.; Bước “Verification required từ Business Owner” dùng nhãn pha Anh–Việt và thiếu hành động cụ thể. Đổi thành “Yêu cầu Business Owner xác nhận rule nghiệp vụ”.; Luồng đạt điều kiện chưa thể hiện test artifact chỉ liên kết nguồn canonical, không sao chép rule chưa xác minh. Làm rõ ranh giới này tại outcome liên kết.
assets/diagrams/19-black-box-testing-techniques-for-ba-026-2347cb9d.mmd — REVISE — TRACEABILITY_ID_REGISTRY không được phần văn xuôi xác lập nhưng sơ đồ thể hiện như dependency bắt buộc. Xóa dependency này hoặc bổ sung nguồn chứng minh trong nội dung.; Luồng tuyến tính ngụ ý mọi test case đều cần template mới được đăng ký. Cần thể hiện ranh giới giữa artifact canonical đã có và biểu mẫu mới phải yêu cầu đăng ký trước khi dùng.; Sơ đồ bỏ vai trò BA trong yêu cầu đăng ký template, làm mờ ownership được nêu rõ trong văn xuôi. Cần gắn BA với bước yêu cầu đăng ký.; Nhãn Kết quả và traceability ghép outcome với thuộc tính kiểm soát, thiếu tính song song và cụ thể. Cần tách hoặc đổi thành trạng thái đầu ra rõ ràng.; Template được đăng ký mô tả trạng thái nhưng không thể hiện bước yêu cầu đăng ký khi chưa có template canonical. Cần phân biệt điều kiện kiểm tra manifest, yêu cầu đăng ký và trạng thái được phép sử dụng.
assets/diagrams/19-black-box-testing-techniques-for-ba-027-fb38344a.mmd — REVISE — Luồng thiếu nhánh kiểm tra khi test case không đủ input, precondition, expected result quan sát được, nguồn rule hoặc requirement, dữ liệu tổng hợp, hoặc canonical ID; cần thể hiện kết quả Verification required và không bù bằng giả định.; Nhãn Đối chiếu artifact canonical mơ hồ; cần nêu rõ artifact hoặc nguồn canonical phải tra theo bảng Quick Reference.; Bước Đối chiếu dữ liệu và trạng thái nhập nhằng giữa trạng thái dữ liệu và trạng thái tài liệu; cần phân biệt định nghĩa dữ liệu với nhãn quản trị IN_REVIEW, v0.9.0, ngày 2026-08-07.; Kết quả Giữ traceability trong artifact không quan sát được và không phản ánh yêu cầu canonical ID không biến thể; cần mô tả kết quả kiểm tra cụ thể.; Luồng không thể hiện ranh giới phê duyệt: artifact và business rule chưa baseline không được coi là nghĩa vụ vận hành hoặc bằng chứng phê duyệt.; Sơ đồ gần như lặp lại chuỗi tra cứu trong văn xuôi nhưng bỏ các tiêu chí quyết định và ngoại lệ quan trọng; cần bổ sung logic kiểm tra để tạo giá trị giải thích.
assets/diagrams/19-black-box-testing-techniques-for-ba-028-de0d49f6.mmd — REVISE — Luồng quyết định bỏ qua nguồn canonical: B nối trực tiếp tới H, còn C–G kết thúc riêng. Phải nối kết quả đối chiếu từ các nguồn canonical vào gateway H.; Nhãn Verification required không được section xác lập. Phải bỏ nhãn hoặc bổ sung căn cứ canonical trong prose.; Bước Escalation đúng owner thêm hành động và owner không có trong section. Phải bỏ bước hoặc nêu rõ owner và quy tắc escalation trong prose.; Nhánh Không ghi handoff IN_REVIEW nhưng không nói rõ IN_REVIEW chưa phải phê duyệt, tạo đúng rủi ro section cảnh báo. Phải làm rõ trạng thái chưa phê duyệt.
assets/diagrams/20-uat-planning-defects-and-regression-001-f9886044.mmd — REVISE — UAT comparison lacks branch for results matching expected outcomes. Add supported pass path so diagram does not imply only mismatches produce outcomes.; Regression step says only "kiểm tra lại vùng ảnh hưởng", while prose requires retesting both defect and identified affected areas. Correct label to include both checks.; "Sửa đổi hoặc cấu hình lại" is ambiguous and implies every recorded defect proceeds directly to correction. Add defect evaluation/disposition step supported by prose, or limit transition to defects accepted for correction.; "Kết quả UAT có bằng chứng" after regression misleadingly treats regression evidence as complete UAT outcome. Connect evidenced UAT result to both pass path and completed defect/regression path.
assets/diagrams/20-uat-planning-defects-and-regression-002-e774caa7.mmd — REVISE — Nhánh "Có" chuyển thẳng sang ghi defect, nhưng section yêu cầu kiểm tra test basis, khả năng tái hiện và tính hợp lệ của dữ liệu trước khi phân loại tạm thời; cần thể hiện gateway phân loại hoặc điều kiện này.; "Đội phát triển phân tích và sửa" bỏ qua vai trò BA làm rõ ảnh hưởng nghiệp vụ và QA quản lý kiểm thử; cần thể hiện đúng owner tại các bước liên quan.; "Retest defect" là nhãn mơ hồ, không nêu actor, hành động và kết quả; cần ghi QA kiểm tra bản sửa và có nhánh đạt/không đạt.; Luồng kết thúc sau regression nhưng không nêu kết quả regression hoặc xác nhận UAT của người dùng nghiệp vụ theo thẩm quyền; cần thêm outcome và owner kết thúc.; Không có luồng khi retest thất bại hoặc regression phát hiện lỗi; cần thể hiện quay lại xử lý defect thay vì ngầm định mọi bản sửa đều đạt.; Sơ đồ gần như lặp lại chuỗi đã mô tả trong đoạn văn và chưa làm rõ thêm ownership, gateway phân loại hoặc vòng phản hồi; cần tăng giá trị giải thích mà không thêm факт ngoài section.
assets/diagrams/20-uat-planning-defects-and-regression-003-f0d783a7.mmd — REVISE — Nút defect thiếu "kết quả mong đợi", dù phần văn bản xác định đây là thành phần bắt buộc cùng bước tái hiện, dữ liệu và bằng chứng. Bổ sung thành phần này vào nhãn.; Luồng coi mọi kết quả không khớp là defect. Phần văn bản yêu cầu BA phân biệt lỗi cấu hình, lỗi dữ liệu mô phỏng, lỗi yêu cầu và đề xuất thay đổi. Bổ sung bước xác nhận và phân loại trước quyết định xử lý.; Thiếu quyền sở hữu governance: ai xác nhận lỗi, ai phân loại tác động và ai chấp nhận rủi ro còn lại. Gắn actor hoặc vai trò quyết định vào các bước tương ứng.; Nút "Sửa hoặc quyết định xử lý" gộp hành động kỹ thuật với quyết định governance và không nêu tiêu chí hay kết quả. Tách hoặc làm rõ nhánh sửa, xử lý khác và chấp nhận rủi ro.; Luồng không thể hiện trường hợp không sửa hoặc chấp nhận rủi ro còn lại; mọi nhánh đều đi qua retest và regression. Bổ sung kết quả phù hợp cho từng quyết định xử lý.
assets/diagrams/20-uat-planning-defects-and-regression-004-9d1be2c4.mmd — REVISE — Nhánh B -->|Có| F đưa test case đạt thẳng vào regression, trong khi quyết định chỉ yêu cầu regression sau khi sửa lỗi hiển thị. Cần bỏ nhánh này hoặc nêu rõ căn cứ trong phần văn xuôi.; Nhánh G -->|Không| C coi mọi lỗi regression là cùng defect ban đầu. Regression có thể phát hiện lỗi mới; cần phân biệt mở lại defect cũ với ghi defect mới theo kết quả quan sát.; Nhãn Đóng lỗi theo quy trình thiếu chủ thể và điều kiện thẩm quyền. Phần văn xuôi giao QA xác nhận kết quả và Business Owner quyết định chấp nhận nghiệp vụ; cần thể hiện ranh giới này hoặc dùng kết quả không hàm ý phê duyệt.; Luồng không thể hiện tiêu chí liên kết test case, defect ID, bản build và bằng chứng retest, dù đây là điều kiện kiểm soát chính của phần văn xuôi. Cần đưa điểm kiểm soát này vào bước ghi lỗi hoặc xác nhận kết quả.
assets/diagrams/20-uat-planning-defects-and-regression-005-274671c0.mmd — REVISE — Nhánh Có nguồn canonical kiểm tra được? chuyển thẳng sang Fact đã xác minh, nhưng nguồn tồn tại chưa đủ chứng minh phát biểu đúng. Cần thể hiện bước đối chiếu nội dung nguồn và, khi có diễn giải kế toán hoặc pháp lý, xác minh bởi Accounting Owner hoặc Legal Owner.; Gateway Có quyết định thẩm quyền ghi nhận? mơ hồ: không nêu quyết định gì và ai có thẩm quyền. Cần gắn Business Owner với chính sách xuất kho, Accounting Owner với ảnh hưởng kế toán, Legal Owner với diễn giải pháp lý.; Sơ đồ không thể hiện tiêu chí phân loại defect cốt lõi: hành vi hiện tại có mâu thuẫn requirement hoặc test basis đã kiểm soát hay không. Cần có nhánh dẫn đến defect khi có mâu thuẫn đã truy vết; nếu chưa đủ bằng chứng, dẫn đến Verification required.; Nút Decision là kết quả quá chung và không phản ánh outcome trong phần văn xuôi: không tạo defect xác nhận, không đổi cấu hình, hoặc ghi nhận quyết định nghiệp vụ có thẩm quyền. Cần dùng outcome cụ thể.; Nút Chỉ định owner xác minh và điều kiện đóng bỏ qua yêu cầu liên kết CANONICAL_BUSINESS_RULES, nguồn pháp lý nếu có, và cấm tự tạo rule ID, approval reference hoặc baseline reference. Cần thể hiện boundary quản trị này hoặc giới hạn rõ phạm vi sơ đồ.
assets/diagrams/20-uat-planning-defects-and-regression-006-d71b3507.mmd — REVISE — Nhãn Release exit mâu thuẫn bảng: kết quả UAT, defect còn lại và đánh giá rủi ro là cổng vào Release; cổng ra phải là phiên bản, phạm vi phát hành và điều kiện theo dõi được ghi nhận. Đổi đúng loại cổng và tiêu chí.; Nhánh R -- Không --> U ép mọi trường hợp chưa đủ điều kiện Release quay lại UAT. Thiếu sót có thể cần quay về Delivery để sửa defect hoặc Analysis khi requirement và acceptance criteria chưa đủ. Sửa nhánh để phản ánh đúng điểm cần xử lý.; Cổng Release bỏ danh sách defect còn lại và quyết định theo artifact kiểm soát, làm thiếu điều kiện rủi ro quan trọng. Bổ sung điều kiện này vào nhãn hoặc trạng thái trước Release.; Nhánh A -- Không --> D ngụ ý mọi test basis chưa đủ đều quay về Discovery. Claim cần xác minh, business rule, dữ liệu, ngoại lệ hoặc acceptance criteria chưa rõ thuộc Analysis. Phân biệt việc tiếp tục Analysis với trường hợp problem statement cần làm rõ lại.
assets/diagrams/20-uat-planning-defects-and-regression-007-7db8d1a3.mmd — REVISE — Nhãn Business Owner delegates mơ hồ và sai vai trò; đổi thành Business Owner delegate để khớp bảng.; Bàn giao Delivery sang Testing ghi deployment note, trong khi bảng yêu cầu release note và known limitation; sửa nhãn theo artifact được hỗ trợ.; Bàn giao Testing sang UAT thiếu UAT scenario; bổ sung artifact này.; Bàn giao UAT sang Release dùng Accepted scenarios or UAT defects, không khớp UAT defect disposition và acceptance decision record; thay bằng tên artifact cụ thể trong bảng.; Nhánh escalation từ Testing gom severity, scope, security or rule conflict nhưng section không xác định cùng một tuyến hoặc cùng thẩm quyền cho các điều kiện này; tách và gắn đúng owner được nêu: BA, Delivery Lead, Architect hoặc Business Owner.; Nút Escalation authority không có owner cụ thể và làm mờ nơi escalation; thay bằng các đích vai trò cụ thể được bảng quy định.; Diagram thiếu escalation từ Delivery khi build thiếu phạm vi đã truy vết sang BA và Delivery Lead.; Diagram thiếu escalation từ Release sang Operations cho sự cố vận hành và sang Security, Legal Owner khi có dữ liệu nhạy cảm.; Luồng Discovery sang Analysis với artifact Business need, scope issue không có hàng bàn giao hoặc điều kiện nhận tương ứng trong section; cần được section hỗ trợ rõ hoặc bỏ khỏi diagram.; Các bàn giao không thể hiện điều kiện nhận dù prose quy định mỗi handoff phải có điều kiện nhận; bổ sung điều kiện cụ thể hoặc giới hạn rõ diagram chỉ mô tả luồng và để bảng chứa điều kiện.
assets/diagrams/20-uat-planning-defects-and-regression-008-e0aadf52.mmd — REVISE — Luồng UAT thiếu dữ liệu kiểm thử dù phần văn xuôi xác định dữ liệu là đầu vào cần thiết. Bổ sung dữ liệu vào bằng chứng chuyển tới Testing.; Vòng đời defect bị rút thành nhãn chung defect, không thể hiện các bước phân loại, sửa và kiểm tra lại đã nêu trong văn xuôi. Thể hiện chuỗi trạng thái hoặc luồng này.; Regression testing chỉ xuất hiện dưới dạng regression evidence, không thể hiện mục tiêu kiểm tra thay đổi không làm hỏng chức năng đang chạy đúng. Làm rõ hoạt động và kết quả hồi quy.; Các nhãn Go-live package, rollback evidence và release note đưa thêm đầu ra không được phần văn xuôi thiết lập. Loại bỏ hoặc bổ sung căn cứ tương ứng trong nội dung.; Nhãn học lại mơ hồ, không chỉ rõ đầu vào, hành động hoặc kết quả. Thay bằng thuật ngữ cụ thể phù hợp với phản hồi vận hành.; Phản hồi Operations về Analysis ghi Defect trend, change request nhưng bỏ sự cố vận hành, nguồn đầu vào được phần giải thích nêu rõ. Bổ sung sự cố vận hành hoặc đổi nhãn để bao quát chính xác.; Hai cạnh từ Release tới Operations dễ gây nhầm: cạnh liền biểu thị dòng công việc, cạnh đứt lại gắn Incident/change evidence, trong khi sự cố và thay đổi thường phát sinh ở Operations. Chỉnh hướng hoặc nhãn để phản ánh nơi phát sinh và nơi nhận bằng chứng.
assets/diagrams/20-uat-planning-defects-and-regression-009-45bbd253.mmd — REVISE — Quan hệ Canonical ID → Nhu cầu nghiệp vụ hoặc quy tắc đảo logic nguồn: ID dùng để định danh và liên kết, không tạo ra nhu cầu hoặc quy tắc. Cần biểu diễn artifact canonical chứa bằng chứng về nhu cầu, quy tắc hoặc dữ liệu; ID giữ liên kết truy vết.; Quan hệ Defect hoặc bằng chứng chấp nhận → Canonical ID tạo vòng phản hồi không được phần văn bản hỗ trợ. Phần văn bản chỉ yêu cầu giữ ID canonical để nối requirement, rule, test và defect; không nói defect hoặc bằng chứng chấp nhận cập nhật hay sinh ID.; Nhãn Nhu cầu nghiệp vụ hoặc quy tắc gộp hai loại đầu vào khác nhau và bỏ qua dữ liệu logic, registry ID, phạm vi chapter cùng giới hạn nguồn đã nêu trong bảng. Cần thể hiện đúng các nhóm test basis hoặc dùng nhãn bao quát, cụ thể.; Nhãn Test case và kết quả thực thi gộp thiết kế kiểm thử với kết quả sau thực thi, làm mờ thứ tự và trạng thái. Cần tách test case khỏi kết quả thực thi nếu sơ đồ mô tả luồng UAT.; Nhánh Defect hoặc bằng chứng chấp nhận thể hiện hai kết quả thay thế nhưng không có điều kiện quyết định. Cần nêu điều kiện kết quả không đạt hoặc đạt, hoặc tránh mô tả gateway chưa được phần văn bản xác lập.; Sơ đồ biến nội dung về đầu vào và truy vết thành quy trình UAT hoàn chỉnh nhưng phần văn bản chưa xác định actor, bước thực thi, tiêu chí đạt, xử lý defect hay vòng đời approval. Cần giới hạn sơ đồ ở quan hệ nguồn–ID–test basis–expected result–traceability.
assets/diagrams/20-uat-planning-defects-and-regression-010-1eb48df2.mmd — REVISE — Thiếu cổng kiểm tra thẩm quyền của Owner. Bổ sung quyết định xác nhận Owner đúng phạm vi; Owner vượt thẩm quyền phải dẫn đến STOP — PLAN REWORK REQUIRED.; Nhánh D -- Không --> E cho phép đầu vào không còn mới tiếp tục đến kiểm tra khả năng kiểm thử sau khi chỉ gắn Verification required. Điều này mâu thuẫn với điều kiện dừng khi có bản mới chưa đối chiếu. Chỉ cho đi tiếp sau khi đối chiếu xong; nếu chưa đối chiếu, dẫn đến STOP.; Cổng Nguồn và Owner rõ? không bao quát trường hợp nguồn mâu thuẫn. Bổ sung tiêu chí nguồn nhất quán hoặc nhánh nguồn mâu thuẫn dẫn đến STOP.; Thiếu ngoại lệ bắt buộc xác minh chuyên môn cho yêu cầu pháp lý, kế toán và an toàn thực phẩm. Bổ sung cổng xác minh bởi Legal, Accounting hoặc chủ thể chuyên môn phù hợp trước khi dùng làm UAT test basis.; Nhãn Đủ điều kiện kiểm thử? quá rộng so với tiêu chí trong bảng. Làm rõ điều kiện gồm dữ liệu, hành động, kết quả mong đợi và nguồn tham chiếu.
assets/diagrams/20-uat-planning-defects-and-regression-011-eb1e6923.mmd — REVISE — Gateway Có test basis và dữ liệu synthetic? gộp hai điều kiện độc lập, làm mất trường hợp chỉ thiếu một đầu vào. Cần tách hoặc nêu rõ cả test basis cụ thể và dataset canonical đều phải đủ.; Nhãn Có có thể ngụ ý dữ liệu synthetic giả định trong bảng đã đủ để lập test case, trong khi bảng xác định chưa có dataset canonical, masking rule, owner dữ liệu và expected result cụ thể. Cần thể hiện dữ liệu giả định không phải đầu vào đã xác minh.; Bước Đánh dấu Verification required hoặc UNRESOLVED không nêu tiêu chí chọn trạng thái. Cần phân biệt thiếu xác minh nguồn với thiếu artifact hoặc bằng chứng.; Nhánh lập test case kết thúc tại expected result, bỏ ranh giới giữa lập kế hoạch và quyền chạy UAT. Cần thể hiện test case được lập không đồng nghĩa được chạy UAT, kết luận pass/fail hoặc sign-off.; Sơ đồ bỏ phụ thuộc vào ID đã đăng ký và các xác nhận Legal/Domain Owner khi yêu cầu truy vết được dùng làm test basis. Cần biểu diễn hoặc giới hạn rõ phạm vi sơ đồ để không ngụ ý mọi artifact canonical đều đủ điều kiện.
assets/diagrams/20-uat-planning-defects-and-regression-012-c73eece1.mmd — REVISE — Thiếu bước xác nhận yêu cầu giao hàng được sinh và liên kết đơn–giao hàng truy vết hai chiều. Bổ sung bước, bằng chứng và nhánh Fail tương ứng giữa chạy đơn đủ tồn và chạy trường hợp thiếu tồn.; Nút “Kết quả khớp mong đợi?” mơ hồ vì không nêu kết quả nào: tạo đơn, giữ tồn hay sinh yêu cầu giao hàng. Tách hoặc ghi rõ điều kiện kiểm tra theo expected result có nguồn.; Luồng từ “BA kiểm tra phạm vi và nguồn truy vết” sang chạy test là vô điều kiện, bỏ trường hợp thiếu hoặc mâu thuẫn nguồn. Bổ sung gateway chặn chạy hoặc phân loại Blocked, cùng route đến Business Owner hoặc Data Owner.; Nút “Business Owner hoặc Delivery Lead xử lý blocker” gộp hai loại blocker và làm mờ quyền sở hữu. Tách rule thiếu đến Business Owner, blocker môi trường đến Delivery Lead; giữ route lỗi kỹ thuật đến QA Lead.; Các nhánh Fail và Blocked đều quay về rà soát rồi handoff vô điều kiện. Bổ sung quality gate yêu cầu đủ bằng chứng và route xử lý; không thể hiện phạm vi accepted khi Fail hoặc Blocked chưa có quyết định đúng thẩm quyền.; Thiếu route đến Architect cho nghi vấn cấu hình hoặc tích hợp. Bổ sung route ngoại lệ này theo bảng.; “BA ghi Pass và bằng chứng” sau riêng trường hợp thiếu tồn dễ ngụ ý toàn bộ UAT đã Pass. Ghi rõ kết quả của từng điều kiện, rồi tổng hợp Pass/Fail/Blocked ở bước rà soát.
assets/diagrams/20-uat-planning-defects-and-regression-013-a279ebc7.mmd — REVISE — Nút A khẳng định expected result đã có nguồn, khiến nhánh "Không có nguồn" tại C mâu thuẫn và không thể xảy ra. Sửa A thành đầu vào trung lập, không khẳng định có nguồn.; Nhánh "Có và khác actual" đi thẳng đến DEFECT_LOG_NF_ERP nhưng bỏ trạng thái Fail và vai trò QA Lead quản lý defect. Bổ sung ghi Fail trước hoặc cùng bước tạo/quản lý defect.; Nhánh Blocked kết thúc sau khi Business Owner xác nhận rule, bỏ kết quả sau xác nhận. Bổ sung đánh giá lại actual theo rule đã xác nhận để chuyển sang Pass hoặc Fail.; Dẫn từ defect đến cập nhật REGRESSION_SCOPE_NF_ERP là vô điều kiện, trong khi prose chỉ ghi REG-001 nếu rule tồn kho được xác nhận sau này. Thêm điều kiện xác nhận rule và dùng đúng artifact REG-001, hoặc bỏ bước không được hỗ trợ.; Diagram bỏ ownership quan trọng: UAT Tester ghi kết quả, BA duy trì traceability, Business Owner xác nhận rule, QA Lead quản lý defect. Gắn actor vào bước tương ứng.
assets/diagrams/20-uat-planning-defects-and-regression-014-b3fa39ac.mmd — REVISE — Nhánh Pass hoặc Retest pass gộp hai kết quả khác ngữ cảnh. Pass UAT ban đầu không tự tạo Regression result; regression là lần chạy lại test liên quan sau thay đổi. Tách Pass khỏi luồng regression và chỉ dẫn tới regression khi có thay đổi kích hoạt.; Defect status history không được mô tả trong bảng anatomy hoặc prose. Bỏ bước này hoặc bổ sung nội dung nguồn trước khi đưa vào sơ đồ.; Thiếu kết quả Blocked dù bảng yêu cầu UAT execution record và regression result ghi Pass/Fail/Blocked. Thêm nhánh Blocked cùng kết quả phù hợp.; Luồng từ Defect record đến regression thiếu điều kiện thay đổi kích hoạt regression. Thể hiện dependency này thay vì nối Pass UAT ban đầu trực tiếp tới Regression result.; Regression evidence dễ gây hiểu rằng chỉ regression cần evidence, trong khi cả UAT execution record và defect record đều có evidence reference. Sửa nhãn hoặc cấu trúc để phản ánh evidence áp dụng cho cả ba artifact.
assets/diagrams/20-uat-planning-defects-and-regression-015-09d262a0.mmd — REVISE — Gateway thiếu điều kiện bắt buộc Nội dung kiểm thử đủ dùng, gồm phạm vi, điều kiện vào, bước test, kết quả mong đợi, kết quả thực tế nếu đã chạy và bằng chứng hoặc vị trí bằng chứng. Bổ sung điều kiện này trước trạng thái Ready for downstream review.; Luồng Downstream review → Không suy ra approval, baseline hay production readiness gắn giới hạn diễn giải sai vị trí. Chính quality gate và trạng thái Ready for downstream review không xác nhận các trạng thái đó; downstream review vẫn có thể tạo kết quả review riêng. Gắn giới hạn trực tiếp với quality gate hoặc trạng thái ready.; Nhãn Đủ ID, metadata, traceability, history? dùng từ ID kém cụ thể hơn yêu cầu Canonical ID và không thể hiện liên kết artifact nguồn. Đổi nhãn để giữ đúng tiêu chí định danh và truy nguồn.
assets/diagrams/20-uat-planning-defects-and-regression-016-d06593ae.mmd — REVISE — Các actor Architect, Operations và Specialist owner không được hỗ trợ bởi section; xóa các node và luồng tương ứng.; Luồng QA nêu UAT plan, regression pack và traceability, nhưng section chỉ xác định liên kết UAT-TC-SO-014 dùng để chọn phạm vi regression; thay bằng đầu ra cụ thể được section hỗ trợ.; Luồng PM/Product Owner nêu UAT plan, nhưng section chỉ nêu trạng thái defect và tác động đến kế hoạch UAT; bỏ UAT plan hoặc ghi đúng thông tin này.; Luồng Developer thiếu bước tái hiện, dữ liệu tổng hợp, kết quả mong đợi và kết quả thực tế; bổ sung vì đây là nội dung cốt lõi của phương án được chọn.; Nhãn Business test result mơ hồ; thay bằng kết quả mong đợi trong test case và thông tin sai lệch cần Business Owner review.; Nhãn nguồn UAT output quá rộng so với artifact đang phân luồng; dùng đối tượng cụ thể như DEF-SO-027 kèm UAT-TC-SO-014.; Diagram chưa thể hiện ranh giới authority: phân luồng output IN_REVIEW, không phải phê duyệt defect, quyết định release hoặc xác nhận quy tắc thật; thêm boundary hoặc ghi chú rõ để tránh hiểu sai.
assets/diagrams/20-uat-planning-defects-and-regression-017-76188819.mmd — REVISE — Nhánh escalation chỉ xuất phát từ "Không đủ bằng chứng", trái bảng: nhiều trường hợp phải escalation dù bằng chứng đầy đủ, như Blocker, rủi ro bảo mật, thay đổi schema, tranh chấp ưu tiên, thay đổi phạm vi và diễn giải luật hoặc thuế. Cần thể hiện gateway bao gồm cả thiếu bằng chứng và điều kiện vượt thẩm quyền hoặc ngưỡng rủi ro.; Nhãn "Đủ bằng chứng?" mơ hồ vì không nêu bằng chứng đủ cho quyết định nào hoặc theo tiêu chí nào. Cần gắn mức đủ bằng chứng với quyết định và thẩm quyền của từng người nhận.; "Owner có thẩm quyền kết luận" không xác định owner phù hợp theo loại vấn đề. Cần phân biệt ít nhất Business Owner, PM/Product Owner, Architect và Specialist owner theo các ranh giới quyết định trong bảng.; Nhánh "Có" dẫn thẳng tới quyết định trong thẩm quyền nhưng bỏ kiểm tra phạm vi thẩm quyền, rủi ro và điều kiện escalation bắt buộc. Cần thêm điều kiện xác nhận quyết định vẫn nằm trong thẩm quyền và không chạm ngưỡng escalation.; Sơ đồ không thể hiện trạng thái IN_REVIEW tại v0.9.0 ngày 2026-08-07 không tạo quyền phê duyệt, baseline hoặc triển khai. Cần thể hiện ranh giới này nếu sơ đồ mô tả luồng ra quyết định từ đầu ra UAT.
assets/diagrams/20-uat-planning-defects-and-regression-018-4ae998c3.mmd — REVISE — Gateway "Bên nhận hiểu phạm vi?" dùng nhận thức chủ quan, trong khi prose yêu cầu kiểm tra bằng chứng. Cần đổi tiêu chí gateway thành kiểm tra đủ nguồn canonical, ID truy vết, phiên bản, trạng thái, người có thẩm quyền và câu hỏi chưa đóng.; Nhãn "Có bằng chứng ID, trạng thái, nguồn" bỏ sót phiên bản, người có thẩm quyền và câu hỏi chưa đóng. Cần thể hiện đủ điều kiện bằng chứng nêu trong prose.; Nhánh "Thực hiện phần việc" có thể khiến người đọc hiểu artifact IN_REVIEW được phép dùng như baseline hoặc approval. Cần nêu giới hạn thực hiện hoặc kết quả không được xem là quyết định đã xác nhận.; Luồng escalation dừng tại "Escalate đúng owner", không thể hiện quyết định được ghi nhận và quay lại handoff với traceability cập nhật. Cần bổ sung kết quả sau escalation mà prose hỗ trợ: owner có thẩm quyền xử lý câu hỏi chưa đóng, trạng thái và bằng chứng được giữ nguyên.; Nhãn "Cần quyết định chuyên môn?" và "đúng owner" mơ hồ. Cần xác định tiêu chí là quyết định cần người có thẩm quyền xác nhận, không chỉ quyết định chuyên môn.; Sơ đồ bỏ sót cảnh báo cụ thể rằng IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline hay approval. Cần thể hiện ranh giới này tại trạng thái hoặc trước bước thực hiện.
assets/diagrams/20-uat-planning-defects-and-regression-019-805f0883.mmd — REVISE — Nhánh C -- Không --> H[Chặn tạo phiếu] không được bằng chứng trong section hỗ trợ; case chỉ quan sát tổng tồn đủ. Xóa nhánh này hoặc bổ sung bằng chứng kiểm thử hành vi khi tổng tồn không đủ.; Sơ đồ bỏ qua ranh giới giao diện quan trọng: payload không có lotId, nên người dùng không thể chọn lô. Bổ sung điểm này để thể hiện nguyên nhân ERP tự chọn lô và phân biệt dữ liệu nhập với xử lý nội bộ.
assets/diagrams/20-uat-planning-defects-and-regression-020-89727f04.mmd — REVISE — Nhánh Không bỏ sót kết quả bắt buộc inventory_commitment = 0; cần thể hiện không tạo cam kết tồn kho cùng trạng thái DRAFT và lỗi ERR-LOT-NOT-RELEASED.; Nút C{Người dùng xác nhận đơn} dùng hình gateway nhưng không có nhánh quyết định; cần biểu diễn đây là hành động/sự kiện kích hoạt, còn D mới là gateway.; Nhãn Mọi lô có quality_status = RELEASED? diễn đạt tương đương logic nhưng chưa làm rõ kiểm tra mọi lô đã phân bổ; cần ghi rõ phạm vi này để tránh hiểu là mọi lô trong kho hoặc đơn.; Chuỗi Giữ đơn DRAFT rồi Trả ERR-LOT-NOT-RELEASED có thể làm mất quan hệ đồng thời giữa ba kết quả thất bại; cần thể hiện chúng là cùng kết quả của nhánh không đạt.
assets/diagrams/20-uat-planning-defects-and-regression-021-0a13b1f6.mmd — REVISE — States DRAFT, READY_FOR_CONFIRMATION, and CONFIRMED are not defined as ERP status values in surrounding prose. Define them in prose or replace them with explicitly supported states or outcomes.; Normal-path condition exposureAmount <= creditLimitAmount and resulting READY_FOR_CONFIRMATION state are inferred, not stated by BR-CR-001. Document this branch or remove it.; Diagram omits critical blocked-confirmation event: Sales Order Clerk attempts confirmation while order is ON_HOLD_CREDIT, system blocks action, and returns CR_LIMIT_EXCEEDED. Add this event and outcome.; Release transition omits required credit decision and recorded reason represented by CREDIT_OVERRIDE_UAT. Show release occurs after credit decision, with Credit Controller as owner.; Label Credit Controller release lacks active, parallel wording. Use actor-action wording consistent with confirmation labels.; Diagram presents proposed workflow as settled behavior despite BR-CR-001 being unapproved and corpus status IN_REVIEW. Mark rule or diagram as proposed and pending owner approval.
assets/diagrams/20-uat-planning-defects-and-regression-022-4010442d.mmd — REVISE — Nhãn Section 9 không được phần văn bản xác nhận và mâu thuẫn với ngữ cảnh ### Core; sửa thành tên section chính xác hoặc bỏ phần này.; Các phụ thuộc 00_SOURCE_MAP --> 01_CURRICULUM_ARCHITECTURE và 01_CURRICULUM_ARCHITECTURE --> CHAPTER_MANIFEST không được văn bản xung quanh giải thích; bổ sung căn cứ trong prose hoặc bỏ các cạnh.; Đường dẫn node UAT có dấu / đầu chuỗi, khác đường dẫn file được cung cấp 02-handbook/20-uat-planning-defects-and-regression.md; dùng đường dẫn canonical thống nhất.; Mũi tên không nêu loại quan hệ, nên có thể bị hiểu là trình tự thay vì phụ thuộc nguồn chân lý; thêm nhãn quan hệ cụ thể hoặc chú giải.
assets/diagrams/20-uat-planning-defects-and-regression-023-1f0846e7.mmd — REVISE — Các mũi tên REQ --> BR, REQ --> DATA và REQ --> API thể hiện mọi requirement luôn có đủ ba liên kết, trong khi bảng chỉ yêu cầu nguồn phù hợp và nêu API là tùy điều kiện nếu đã đăng ký; cần biểu thị quan hệ tùy áp dụng hoặc điều kiện tồn tại.; Nhãn Bằng chứng kết quả quá mơ hồ so với yêu cầu bằng chứng của TC; cần thể hiện tối thiểu kết quả, người thực hiện và thời điểm Asia/Ho_Chi_Minh.; Quy tắc REQ phải liên kết ít nhất một TC không được thể hiện rõ vì sơ đồ chỉ cho các đường gián tiếp qua AC, BR, DATA hoặc API; cần làm rõ quan hệ truy vết bắt buộc REQ–TC mà không ngụ ý mọi nguồn trung gian đều bắt buộc.
assets/diagrams/20-uat-planning-defects-and-regression-024-7736fec7.mmd — REVISE — Nút "Ghi nhận thay đổi có kiểm soát" quá mơ hồ; cần thể hiện các thông tin kiểm soát được đoạn văn yêu cầu: version, phạm vi tác động, người chịu trách nhiệm và kết quả rà soát.; Các nút "REQ / BR / AC bị ảnh hưởng" và "DATA / API bị ảnh hưởng" chỉ mô tả trạng thái phát hiện, chưa thể hiện yêu cầu đánh giá lại artifact nhận tham chiếu; cần làm rõ bước rà soát hoặc cập nhật tương ứng.; Sơ đồ bỏ sót nguyên tắc không sao chép nguồn canonical vào UAT plan để sửa riêng; cần biểu diễn ranh giới tham chiếu hoặc kiểm soát ngăn thay đổi tách rời nếu sơ đồ nhằm mô tả đầy đủ lan truyền thay đổi.
assets/diagrams/20-uat-planning-defects-and-regression-025-e8da0d2a.mmd — REVISE — Nhánh IN_REVIEW --> Logged: thiếu dữ liệu tái hiện mâu thuẫn hướng dẫn giữ hoặc đặt defect ở IN_REVIEW rồi bổ sung bằng chứng. Sửa trạng thái đích hoặc bổ sung prose xác nhận việc trả defect về Logged.; Nhãn có bản sửa xác định chưa đủ cụ thể. Phải nêu bản build và môi trường kiểm thử đã được nhận diện, phù hợp rủi ro retest sai phiên bản.; Nhãn lỗi còn hoặc điều kiện khác mơ hồ. Thay điều kiện khác bằng các trường hợp được section hỗ trợ, như build, môi trường, dữ liệu hoặc quyền khác.; Sơ đồ thiếu nhánh xử lý khi defect đã bị đóng nhưng không có bằng chứng retest hoặc không chứng minh đúng build. Thêm chuyển trạng thái mở lại hoặc quay về trạng thái chờ retest theo quy trình dự án.
assets/diagrams/20-uat-planning-defects-and-regression-026-d4d55101.mmd — REVISE — Thiếu nhánh ngoại lệ khi tái hiện có nguy cơ mất dữ liệu, lộ dữ liệu cá nhân, sai số dư mô phỏng hoặc che audit trail. Bổ sung gateway rủi ro và luồng dừng thao tác, bảo toàn bằng chứng, ghi giới hạn, chuyển owner phù hợp.; Nút "Owner có thẩm quyền quyết định" không nêu quyết định gì hoặc kết quả nào được ghi nhận. Đổi thành bước cụ thể: owner xác nhận phần thuộc thẩm quyền, rồi BA ghi quyết định, bất định và bằng chứng vào artifact IN_REVIEW.; Luồng hiện tại ngụ ý mọi trường hợp đều kết thúc bằng quyết định owner. Nội dung cho phép kết quả vẫn là Verification required hoặc giữ defect mở khi bằng chứng chưa đủ. Bổ sung kết quả này.; Nhãn "Bằng chứng phân biệt được kỳ vọng và kết quả?" chưa phản ánh tiêu chí chính: bằng chứng phải nối kỳ vọng canonical, bước tái hiện, dữ liệu, kết quả thực tế và phần chưa biết. Làm rõ gateway mà không ngụ ý bằng chứng quan sát đủ xác định nguyên nhân.; Nhãn dùng lẫn tiếng Việt và tiếng Anh như "uncertainty", "requirement", "rule", "test evidence". Dùng thuật ngữ nhất quán hoặc giữ mã trạng thái và tên artifact khi cần.
assets/diagrams/20-uat-planning-defects-and-regression-027-18a0f40c.mmd — REVISE — Nhánh không có test basis chỉ ghi Verification required nhưng thiếu kết quả bắt buộc không gán lỗi sản phẩm; bổ sung trạng thái này.; Nhánh không tái hiện và không có rủi ro chỉ dừng ở Thu thập thêm bằng chứng; thiếu ngưỡng escalation sau 2 lần tái hiện độc lập hoặc trên các môi trường UAT khác nhau.; Gateway Rủi ro mất dữ liệu, bảo mật, an toàn? quá mơ hồ và bỏ sót sai quyền truy cập, lộ dữ liệu, sai sổ sách, an toàn thực phẩm và traceability; dùng điều kiện rủi ro cụ thể, đúng phạm vi ngoại lệ trong bảng.; Bước Phân loại defect hoặc change request thiếu căn cứ so sánh trực tiếp với acceptance criteria đã truy vết; bổ sung tiêu chí phân loại.; Gateway Chặn UAT exit hoặc ảnh hưởng liên miền? dùng nhãn ảnh hưởng liên miền không được định nghĩa và làm sai lệch ngưỡng escalation; thay bằng các điều kiện được nêu: tính toàn vẹn dữ liệu, không có workaround an toàn, hoặc tranh chấp làm đổi phạm vi, chi phí, lịch phát hành hay kiểm soát nghiệp vụ.; Luồng không thể hiện kiểm tra regression sau khi sửa defect, gồm defect gốc, luồng liên quan và tính nhất quán dữ liệu; bổ sung nhánh sau sửa cùng ngoại lệ cho thay đổi chỉ có nhãn hiển thị.; Luồng không thể hiện bảo toàn nguồn chân lý khi artifact canonical mâu thuẫn hoặc cần diễn giải pháp lý, kế toán, bảo mật; bổ sung trạng thái dừng quyết định rule, gắn Verification required và chuyển đúng owner.; Kết quả Theo dõi trong UAT defect log gộp defect và change request vào cùng đích, trái yêu cầu tách hai loại; thể hiện outcome riêng hoặc định tuyến change request tới quy trình phù hợp.; Owner chỉ xuất hiện dưới nhãn chung owner có thẩm quyền; với quyết định thuộc Legal, Accounting, Security hoặc QA, sơ đồ cần thể hiện chuyển tới đúng authority và Senior BA không tự quyết.
assets/diagrams/20-uat-planning-defects-and-regression-028-773f5f58.mmd — REVISE — Thiếu bước ghi Assumption và ảnh hưởng, dù đây là một trong bốn loại thông tin cốt lõi của section. Bổ sung bước hoặc nhánh ghi Assumption mà không biến giả định thành business rule.; Nhãn “Phân biệt defect, configuration hay requirement gap” ngụ ý BA có thể kết luận phân loại ngay khi evidence đủ tái hiện. Evidence tái hiện chỉ chứng minh hành vi quan sát được; sửa nhãn để giữ phân loại ở trạng thái cần xác minh bởi owner phù hợp.; “Chuyển đúng decision authority” quá mơ hồ và bỏ mất ownership quan trọng. Nêu rõ Business Owner quyết định phương án và ưu tiên, Legal Owner diễn giải nghĩa vụ pháp lý, Food Safety Owner xác nhận phạm vi nghiệp vụ, QA Lead xác định tiêu chí đóng defect.; Kết quả “Ghi decision record hoặc giữ IN_REVIEW” gộp hai trạng thái đối lập nhưng không có gateway hay điều kiện. Tách nhánh: có quyết định được ghi nhận thì tạo decision record; chưa có bằng chứng quyết định thì giữ IN_REVIEW.; Nhánh evidence không đủ vẫn đi thẳng tới khuyến nghị mà không thể hiện giới hạn và thời hạn chờ của Unknown. Bổ sung người cần trả lời, hạn chờ và điều kiện của khuyến nghị.
assets/diagrams/20-uat-planning-defects-and-regression-029-e93f80a8.mmd — REVISE — Nút C thêm bước "kiểm tra quality gate" nhưng phần văn xuôi không nêu quality gate, tiêu chí kiểm tra hoặc nguồn quy định; bỏ bước này hoặc bổ sung căn cứ trong văn xuôi.; Nút F đưa vào actor "Consumer", hành động dùng artifact và điều kiện "theo phạm vi" nhưng phần văn xuôi không xác định actor, phạm vi hoặc kết quả này; bỏ nút F hoặc bổ sung các thông tin tương ứng trong văn xuôi.; Nhãn "Tham chiếu TEMPLATE_MANIFEST" chưa nói rõ mục đích và dễ làm người đọc hiểu manifest là nguồn template; đổi thành nhãn cụ thể thể hiện manifest chỉ là danh mục kế hoạch, không cung cấp ID hoặc filename đã đăng ký.
assets/diagrams/20-uat-planning-defects-and-regression-030-49c05e50.mmd — REVISE — Nút “Đối chiếu manifest và registry” bỏ sót bốn nguồn canonical bắt buộc trong bảng: CANONICAL_BUSINESS_RULES.md, CANONICAL_DATA_DICTIONARY.md, TEMPLATE_MANIFEST.md và 00_SOURCE_MAP.md. Cần thể hiện phạm vi đối chiếu đủ sáu nguồn hoặc dùng nhãn bao quát chính xác.; Nhánh “Có” đi từ ghi issue, escalation thẳng tới bàn giao IN_REVIEW, dù bảng yêu cầu kết quả bắt buộc trước bàn giao. Cần thêm điều kiện xác nhận lệch đã được xử lý hoặc được ghi nhận theo tiêu chí bàn giao; không được mô tả escalation như đủ để bàn giao.; Nhãn “Escalate đúng owner” mơ hồ và đưa vào owner không được section xác định. Cần nêu owner canonical cụ thể nếu nguồn có quy định, hoặc giữ hành động ở mức ranh giới thẩm quyền được section hỗ trợ.; Gateway chỉ hỏi “ID, trạng thái, nguồn hoặc thẩm quyền”, chưa bao phủ version, đường dẫn, nhãn xác minh, locale, ngày, tiền tệ, business rule, data term, template status và giới hạn trích dẫn. Cần dùng tiêu chí đủ phạm vi tự-review.; “Ghi open issue hoặc Verification required” gộp hai kết quả khác nhau nhưng không có điều kiện chọn nhánh. Cần chỉ rõ trường hợp dùng từng nhãn hoặc tách quyết định.
assets/diagrams/21-change-control-traceability-and-baselining-001-ded54764.mmd — REVISE — Nhánh chấp nhận không thể hiện điều kiện có hoặc không có baseline reference. Nút “Mốc baseline nếu được ghi nhận” dễ khiến người đọc hiểu baseline luôn là kết quả cuối. Cần thể hiện hai kết quả rõ: tạo baseline khi có baseline reference; tiếp tục ở trạng thái IN_REVIEW khi chưa có.; Traceability được mô tả quá chung bằng một nút “Liên kết truy vết”. Phần prose yêu cầu liên kết hai chiều: đề nghị thay đổi dẫn tới artifact bị ảnh hưởng, và artifact dẫn ngược về lý do thay đổi. Cần thể hiện rõ hai hướng hoặc quan hệ hai chiều này.; Sơ đồ không thể hiện trạng thái thực tế tại v0.9.0: IN_REVIEW, chưa được approval và chưa có baseline reference. Cần thêm ranh giới hoặc kết quả hiện tại để tránh ngụ ý nội dung đã được chấp nhận hay baseline hóa.
assets/diagrams/21-change-control-traceability-and-baselining-002-114f4b2c.mmd — REVISE — "Thay đổi ghi rải rác" không được phần văn xuôi nêu hoặc giải thích; cần thay bằng trạng thái được hỗ trợ trực tiếp như không phân biệt được làm rõ với mở rộng phạm vi.; "Cập nhật artifact liên quan" dùng từ chung và pha ngôn ngữ; cần nêu cụ thể tài liệu, cấu hình và kiểm thử.; "Kiểm tra bản đã thay đổi" mơ hồ về đối tượng và tiêu chí kiểm tra; cần chỉ rõ kiểm tra tính nhất quán với mốc tham chiếu và liên kết truy vết.; Nhánh "Có" bỏ bước so sánh yêu cầu hiện hành với yêu cầu đã được kiểm soát, dù đây là mục đích chính được văn xuôi nêu.
assets/diagrams/21-change-control-traceability-and-baselining-003-0742e6f9.mmd — REVISE — Thứ tự gateway làm sai phân loại Decision: mọi phát biểu do stakeholder cung cấp đều dừng tại Stakeholder input, kể cả quyết định có authority và artifact. Kiểm tra tiêu chí Decision trước nguồn phát biểu, hoặc cho nhánh Stakeholder input tiếp tục kiểm tra authority và artifact.; Nhánh cuối biến mọi phát biểu còn lại thành Verification-required claim. Prose chỉ áp dụng loại này cho khẳng định có thể ảnh hưởng pháp lý, kế toán, bảo mật, vận hành hoặc cấu hình nhưng thiếu chứng cứ. Thêm gateway kiểm tra phạm vi ảnh hưởng; không gán mặc định khi không đạt tiêu chí.; Gateway “Dùng tạm để lập kế hoạch?” hẹp hơn định nghĩa Project assumption, vốn dùng để tiếp tục phân tích. Đổi điều kiện để bao quát “tiếp tục phân tích hoặc lập kế hoạch khi thiếu bằng chứng”.; Nhánh Verified fact chỉ hỏi có nguồn kiểm soát, chưa thể hiện đã đối chiếu trực tiếp. Sửa gateway để yêu cầu cả nguồn kiểm soát và việc đối chiếu trực tiếp.
assets/diagrams/21-change-control-traceability-and-baselining-004-885f907d.mmd — REVISE — Hai cạnh song song giữa mỗi cặp giai đoạn gây mơ hồ: cạnh liền biểu thị chuyển tiếp không điều kiện, còn cạnh nét đứt biểu thị exit gate. Cần thể hiện một luồng chuyển tiếp duy nhất gắn với gate hoặc phân biệt rõ quan hệ giữa luồng và điều kiện.; Sơ đồ nói mỗi giai đoạn có entry gate nhưng không thể hiện entry gate nào. Cần bổ sung điều kiện vào tương ứng hoặc giới hạn rõ sơ đồ chỉ mô tả exit gate.; Nhãn Discovery Exit: nhu cầu, phạm vi, giả định không khớp exit gate trong bảng: phạm vi khám phá, nguồn và câu hỏi chưa xác minh. Cần dùng điều kiện exit chính xác.; Nhãn Analysis requirement có ID và liên kết bỏ các điều kiện bắt buộc: nguồn, tiêu chí chấp nhận dự kiến, tác động và trạng thái IN_REVIEW. Cần phản ánh đủ gate hoặc chỉ rõ đây là bản tóm tắt không đại diện toàn bộ gate.; Nhãn Delivery build/deployment evidence đưa deployment evidence vào trước Testing, trong khi bảng chỉ hỗ trợ bằng chứng build hoặc cấu hình mô phỏng. Cần bỏ deployment hoặc dùng đúng thuật ngữ trong bảng.; Sơ đồ không thể hiện ranh giới quan trọng rằng exit gate không phải approval và không xác nhận baseline. Cần biểu đạt giới hạn này để tránh suy diễn chuyển giai đoạn là phê duyệt hoặc baselining.; Nhãn dùng lẫn tiếng Việt và tiếng Anh, đồng thời không song song về số và cấu trúc. Cần chuẩn hóa thành các cụm danh từ cụ thể, nhất quán với bảng.
assets/diagrams/21-change-control-traceability-and-baselining-005-8390177e.mmd — REVISE — Gateway “Cần quyết định chuyên môn?” thiếu nhánh “Không”, nên luồng không xác định khi thay đổi không cần quyết định chuyên môn. Thêm nhánh dẫn tới bước xử lý phù hợp hoặc bỏ gateway nếu mọi thay đổi đều cần thẩm quyền chuyên môn.; Chuỗi cố định Delivery → Testing → Release → Operations không được đoạn văn xác lập đầy đủ; “Release Owner” cũng không xuất hiện trong prose. Chỉ giữ owner và quan hệ được section hỗ trợ, hoặc bổ sung prose làm căn cứ.; Luồng không thể hiện change control có ghi nhận, liên kết traceability, hay điều kiện baselining cần thẩm quyền phù hợp ghi nhận. Bổ sung bước hoặc nhãn thể hiện ghi nhận thay đổi, duy trì liên kết và quyết định baseline.; Trạng thái mẫu IN_REVIEW tại v0.9.0 ngày 2026-08-07 chưa là baseline hay approval không xuất hiện, làm mất ngoại lệ trọng yếu. Thể hiện rõ IN_REVIEW không dẫn tới baseline hoặc approval.; Vai trò BA bị thể hiện chủ yếu như điểm phân tích, chưa thể hiện ranh giới “giữ liên kết và gói thay đổi, không tự quyết”. Gắn trách nhiệm này với BA và đặt quyết định tại owner có thẩm quyền.; Nhãn “Tác động rule, data, scope” trộn tiếng Anh-Việt và chưa bao quát artifact, quyết định cùng tác động như prose. Dùng nhãn cụ thể, song song với thuật ngữ section.
assets/diagrams/21-change-control-traceability-and-baselining-006-a7cd8429.mmd — REVISE — Baseline không xuất hiện trong luồng dù section mô tả baselining là chủ đề cốt lõi. Bổ sung mốc baseline được kiểm soát và quan hệ của mốc này với thay đổi artifact.; Nhãn “Traceability cập nhật xuyên suốt” chỉ nối từ Analysis đến Discovery, Delivery, Testing và Release, bỏ Operations; cách vẽ cũng khiến Analysis trông như nguồn duy nhất của traceability. Thể hiện truy vết giữa các bằng chứng xuyên suốt toàn vòng đời, gồm phản hồi vận hành.; Nhãn “requirement, rule, data” cụ thể hơn prose hỗ trợ. Giữ thuật ngữ bằng chứng đã được section nêu hoặc bổ sung prose xác lập các loại artifact này.; Luồng không phân biệt trạng thái kiểm soát thay đổi với pha delivery lifecycle. Làm rõ đây là các điểm kiểm soát bằng chứng, tránh ngụ ý mọi change request tự động đi thẳng tới Delivery và Release.
assets/diagrams/21-change-control-traceability-and-baselining-007-ed26c52b.mmd — REVISE — Diagram omits “Bằng chứng,” one of four input types explicitly required by prose. Add it as distinct input or show its relationship to “Artifact nguồn.”; “Kiến thức nghiệp vụ” is broader than prose’s “Kiến thức tiền đề,” weakening category alignment. Use label matching defined category.; Flow “Đề xuất thay đổi” to “Liên kết truy vết” implies traceability link is produced automatically, but prose only states canonical IDs connect artifacts. Clarify supported relationship without implying unsupported process or outcome.; Diagram mostly repeats nearby list and does not explain distinction between evidence, source artifact, and canonical ID. Add relational value, especially that artifact stores evidence and canonical ID provides stable cross-artifact linkage.
assets/diagrams/21-change-control-traceability-and-baselining-008-159db06b.mmd — REVISE — Cổng kiểm tra đầu vào thiếu Status, ngày cập nhật, phạm vi và ranh giới thẩm quyền. Bổ sung đủ tiêu chí được nêu trong prose.; Nhãn Freshness đủ ngày 2026-08-07? mơ hồ và biến một ngày cụ thể thành tiêu chí không được prose giải thích. Đổi thành kiểm tra ngày cập nhật và tiêu chí freshness đã được xác định.; Sơ đồ thêm ID dù prose không nêu đây là điều kiện chấp nhận đầu vào. Bỏ ID hoặc bổ sung căn cứ trong prose.; Sơ đồ bỏ qua phân loại primary-source, controlled-planning và project-assumption, nên không thể hiện giới hạn suy luận theo từng nguồn. Thêm cổng phân loại nguồn và kết quả sử dụng tương ứng.; Nhánh Có mâu thuẫn hoặc Verification required? gộp hai điều kiện có cách xử lý chưa được xác định là giống nhau. Tách điều kiện hoặc nêu rõ xử lý mâu thuẫn trong prose.; Kết quả không quyết định không phản ánh chính xác giới hạn đã nêu: không chuyển Verification required thành rule, cấu hình ERP hoặc tiêu chí nghiệm thu. Dùng kết quả cụ thể này.; Sơ đồ không thể hiện IN_REVIEW không phải APPROVED hay BASELINED. Thêm kiểm tra trạng thái và chặn việc dùng sai mức phê duyệt.
assets/diagrams/21-change-control-traceability-and-baselining-009-aa4c7828.mmd — REVISE — Nhãn “Đủ bằng chứng?” mơ hồ: không nêu bằng chứng nào, tiêu chí nào hoặc owner nào xác minh. Cần gắn quyết định với trạng thái xác minh và các điểm chưa xác minh trong bảng.; Nhánh “Có” có thể bị hiểu là đã phê duyệt hoặc baseline, trái với cảnh báo rằng IN_REVIEW không mang hai nghĩa này. Cần nêu rõ đầu ra chỉ đủ điều kiện đưa vào phân tích, không phải approval hoặc baseline.; “Gắn Verification required” chưa thể hiện bước chuyển cho đúng owner như Business Owner, Architect, Accounting Owner hoặc Legal Owner. Cần thể hiện trách nhiệm xác minh theo loại điểm còn mở.; “Dừng kết luận bắt buộc” không rõ kết luận nào bị dừng và diễn đạt thiếu tự nhiên. Cần nêu cụ thể rằng không được kết luận nghĩa vụ, quy tắc vận hành hoặc tác động thật khi chưa xác minh.; Luồng thiếu kết quả sau khi owner cung cấp bằng chứng: không có đường quay lại kiểm tra. Cần bổ sung vòng tái xác minh hoặc chỉ rõ đây là điểm kết thúc chờ bằng chứng.
assets/diagrams/21-change-control-traceability-and-baselining-010-fc09e090.mmd — REVISE — Nhánh F -- Rejected/Deferred --> H đưa trạng thái Deferred vào dù bảng chỉ mô tả phê duyệt hoặc từ chối; tách Deferred với trạng thái chờ, điều kiện xử lý tiếp và owner, hoặc xóa trạng thái này.; Nhánh B -- No --> D --> J đóng CR không hợp lệ, trong khi bước 1 yêu cầu trả lại CR chưa rõ để bổ sung; thể hiện vòng quay lại bước tiếp nhận hoặc tách rõ Rejected khỏi Returned.; Nút F[CCB Review & Decision] thiếu ngoại lệ CCB không đạt quyết định và tuyến leo thang đến Project Sponsor hoặc Steering Committee; bổ sung gateway hoặc nhánh leo thang.; Nút G[Update Baseline & Traceability] bỏ sót việc thực hiện thay đổi trên tài liệu và hệ thống đã được phê duyệt; sửa nhãn để phản ánh đầy đủ phạm vi bước 5.; Nút I[Communicate & Handoff] thiếu quality gate các bên liên quan xác nhận đã nhận và hiểu thay đổi, cùng ngoại lệ chuyển Project Manager khi không đồng ý hoặc hiểu lầm; bổ sung gateway xác nhận và nhánh leo thang.; Các bước cần ownership nhưng sơ đồ không nêu actor: BA tiếp nhận, phân tích, đề xuất, cập nhật và bàn giao; CCB ra quyết định. Gắn actor vào nhãn hoặc swimlane để tránh mơ hồ trách nhiệm.
assets/diagrams/21-change-control-traceability-and-baselining-011-34d639d5.mmd — REVISE — Nhãn "CR Hứng/Nhận diện" sai hoặc không rõ nghĩa; sửa thành thuật ngữ cụ thể, phù hợp bước tiếp nhận CR.; "BA Tiếp nhận & Đăng ký" dùng nút quyết định nhưng không có điều kiện hay nhánh; đổi thành nút hoạt động.; "CCB/Stakeholder Phê duyệt?" làm mờ thẩm quyền; phần văn xuôi quy định CCB ra quyết định, gồm Business Owner, PM, Tech Lead và BA. Ghi đúng CCB.; "BA & QA Xác minh Giải pháp", "UAT đạt?" và vai trò "QA Lead" không được phần văn xuôi hỗ trợ; loại bỏ hoặc bổ sung căn cứ trong nội dung trước khi dùng.; Luồng được duyệt bỏ sót thực hiện thay đổi hệ thống theo CR; bước 5 yêu cầu cập nhật cả tài liệu và hệ thống, không chỉ tài liệu và baseline.; Nhánh "Gửi lại đề xuất / Từ chối CR" gộp hai kết quả khác nhau nhưng không chỉ ra điều kiện, chủ sở hữu hoặc đường quay lại; tách kết quả và nối luồng cụ thể.; Các trạng thái E, I và M không có đường đóng hoặc quay lại xử lý; bổ sung kết quả cuối hoặc vòng phản hồi được nội dung hỗ trợ.; Subgraph "Lộ trình Leo thang" không mô tả leo thang đúng nghĩa: các cạnh dẫn tới bước xử lý bình thường thay vì actor nhận escalation. Thể hiện actor đích theo bảng, như PM/Business Owner, Senior BA/Architect, Product Sponsor/Steering Committee và Configuration Manager/Senior BA.; Các ánh xạ escalation hiện tại mâu thuẫn hoặc thiếu căn cứ: "C -- PM --> E", "D -- Tech Lead/SME --> F", "G -- Project Sponsor --> I", "H -- QA Lead --> J" và "K -- Business Owner --> M" không khớp điều kiện escalation trong bảng.; Sơ đồ gần như lặp lại sơ đồ quy trình ngay phía trên nhưng thêm bước xác minh, UAT và escalation không được hỗ trợ; cần tạo giá trị riêng bằng cách trực quan hóa case Nova Foods hoặc các điểm kiểm soát đã nêu, không phát minh quy trình mới.
assets/diagrams/21-change-control-traceability-and-baselining-012-3a6d6355.mmd — REVISE — Phần văn xuôi chỉ xác nhận luồng hoạt động BA và điểm leo thang; không hỗ trợ cụ thể các vai trò CCB, Stakeholder, PM, Tech Lead/SME, Project Sponsor, QA Lead, Business Owner hoặc quyền quyết định của họ. Bổ sung căn cứ trong nội dung hoặc loại bỏ các vai trò không được định nghĩa.; Nút "BA Tiếp nhận & Đăng ký" dùng hình thoi dù là hoạt động, không phải quyết định. Đổi sang nút quy trình.; Các cạnh trong "Lộ trình Leo thang" dẫn đến cùng nút của luồng chính nên thể hiện chuyển bước thay vì leo thang. Nêu điều kiện kích hoạt, người nhận leo thang và kết quả riêng cho từng điểm.; Nhãn "CCB/Stakeholder Phê duyệt?" gộp hai chủ thể có thẩm quyền không rõ ràng. Xác định bên phê duyệt theo quy trình hoặc mô tả quy tắc lựa chọn.; Nhãn "BA Đề xuất Giải pháp & Phân tích" mơ hồ và lặp ý với "BA Phân tích Tác động". Nêu đầu ra phân tích khác biệt hoặc gộp bước.; Nhánh không đạt tại xác minh/UAT dừng ở "Ghi nhận lỗi / Yêu cầu Điều chỉnh" mà không quay lại phân tích, triển khai hoặc xác minh. Bổ sung vòng xử lý và điểm kết thúc phù hợp.; Các kết quả từ chối hoặc yêu cầu làm rõ không có trạng thái tiếp theo hay điểm kết thúc rõ ràng. Tách kết quả hoặc nối yêu cầu làm rõ về bước tiếp nhận.; Sơ đồ đặt "Thiết lập Baseline" trước xác minh và UAT nhưng phần văn xuôi không xác nhận thời điểm này. Làm rõ loại baseline và điều kiện thiết lập, hoặc điều chỉnh thứ tự theo nội dung.; Nhãn dùng viết hoa không nhất quán như "Tiếp nhận", "Đăng ký", "Phân tích Tác động", "Vòng đời Thay đổi". Chuẩn hóa kiểu viết câu và giữ cấu trúc động từ song song.
assets/diagrams/21-change-control-traceability-and-baselining-013-9110b3c0.mmd — REVISE — Nút quyết định đánh giá sơ bộ chỉ có nhánh "CR: Có Khả thi"; thiếu kết quả cho CR không khả thi. Bổ sung nhánh từ chối, yêu cầu bổ sung hoặc đóng phù hợp với nội dung prose.; Nhánh Defer đi từ trạng thái DEFERRED sang "Hoàn tất & Đóng CR" với trạng thái CLOSED, làm mất nghĩa tạm hoãn và mâu thuẫn trạng thái. Giữ CR ở DEFERRED để theo dõi hoặc bổ sung sự kiện tái xem xét được prose hỗ trợ.; Nhánh Reject cũng đi vào bước đóng cuối vốn được prose giới hạn cho CR đã triển khai và chấp nhận. Tách kết thúc bị từ chối khỏi luồng hoàn tất sau UAT hoặc sửa prose để xác định quy tắc đóng mọi CR.; Các chi tiết "NF-CR-xxxx-xxx", "NF-CR-xxx-ImpactAnalysis.md", FSD, Traceability Matrix, CR Log, ước tính nhanh, thiết kế giải pháp, Biên bản UAT, CR Final Report và các mã trạng thái không được phần giải thích hỗ trợ. Xóa hoặc bổ sung prose xác nhận từng artifact, bằng chứng và quy ước trạng thái.; Lý do Reject "Không phù hợp, chi phí cao" và ví dụ "Giám đốc Sản xuất" là dữ kiện riêng không có trong prose. Xóa hoặc nêu rõ trong prose.; Nhãn "Cập nhật Artifacts Đường cơ sở" trộn Việt-Anh và kém tự nhiên. Dùng thuật ngữ nhất quán, cụ thể như "Cập nhật tài liệu đường cơ sở".
assets/diagrams/21-change-control-traceability-and-baselining-014-9ad50662.mmd — REVISE — Luồng APPROVED → IMPLEMENTED gắn nhãn "Bắt đầu thực hiện" nhưng IMPLEMENTED biểu thị đã thực hiện xong. Cần thêm trạng thái đang thực hiện hoặc đổi sự kiện chuyển trạng thái thành hoàn tất thực hiện.; Luồng IMPLEMENTED → CLOSED gắn nhãn "Hoàn tất thực hiện, đóng" trộn hai sự kiện và làm mơ hồ ranh giới giữa IMPLEMENTED với CLOSED. Cần xác định IMPLEMENTED là hoàn tất triển khai và dùng điều kiện đóng cụ thể.; Luồng SUBMITTED → IN_REVIEW dùng "Chờ CCB xem xét", mô tả trạng thái chờ thay vì sự kiện chuyển trạng thái. Cần dùng hành động cụ thể đưa yêu cầu vào quy trình xem xét.; Luồng DEFERRED → SUBMITTED với nhãn "CCB xem xét lại" không khớp trạng thái đích: xem xét lại phù hợp với IN_REVIEW, còn SUBMITTED cần sự kiện gửi lại. Cần sửa trạng thái đích hoặc nhãn theo quy trình thực tế.; Biểu đồ không thể hiện điểm bắt đầu và điểm kết thúc của vòng đời. Cần thêm trạng thái khởi đầu và kết thúc nếu Quick Reference nhằm mô tả vòng đời đầy đủ.; Phần cung cấp không có prose giải thích quy tắc chuyển trạng thái, điều kiện đóng, quyền của CCB hoặc ngoại lệ. Vì vậy các actor, nhánh và điều kiện trong biểu đồ chưa có căn cứ để xác nhận.
assets/diagrams/21-change-control-traceability-and-baselining-015-9600a61e.mmd — REVISE — Nút C và D dùng hình gateway nhưng chỉ có một nhánh đi ra; bổ sung các lựa chọn, kết quả không được chọn và tiêu chí dẫn đến quyết định, hoặc đổi chúng thành bước xử lý tuần tự.; Bước phê duyệt chỉ thể hiện điều kiện APPROVED, không có nhánh bị từ chối, yêu cầu sửa hoặc đánh giá lại; bổ sung các kết quả này và điểm quay lại tương ứng.; Nhãn "Thẩm quyền: Nghiệp vụ, Kỹ thuật, Pháp lý" không xác định ai đề xuất, ai đánh giá và ai phê duyệt; ghi rõ trách nhiệm của từng bên theo nội dung nguồn.; Luồng đặt baseline trước triển khai nhưng không thể hiện baseline nào được phê duyệt, cách kiểm soát thay đổi sau baseline hoặc kết quả triển khai; bổ sung trạng thái và đầu ra được prose hỗ trợ.; Các chi tiết "Lựa chọn 2", "Bảng dữ liệu tham chiếu", ba thẩm quyền và danh sách artifact không được chứng minh trong đoạn văn được cung cấp; đối chiếu với phần ví dụ trước đó và xóa hoặc sửa mọi chi tiết không có nguồn.; Nhãn dùng danh từ trừu tượng và viết hoa không nhất quán như "Nhu cầu", "Lựa chọn", "Tiêu chí"; dùng nhãn hành động cụ thể, song song và nhất quán.; Cụm "Tạo Tạo phẩm" lặp từ; sửa thành "Tạo phẩm" hoặc dùng động từ cụ thể mô tả việc tạo/cập nhật từng artifact.
assets/diagrams/21-change-control-traceability-and-baselining-016-c607cfd7.mmd — REVISE — Nhánh D -- Không và F -- Không đi qua E rồi tới H[Giá Cuối cùng: 51.300 VND], nên sơ đồ thể hiện giảm giá cho POS-STORE hoặc đơn ngoài thời gian khuyến mãi. Sửa kết quả nhánh E thành 54.000 VND; chỉ nhánh đủ ba điều kiện mới đạt 51.300 VND.; Nhánh đủ điều kiện chỉ ghi Áp dụng BR-PNM-002, bỏ bước tính 54.000 VND bằng BR-PNM-001 trước khi giảm 5%. Thể hiện rõ BR-PNM-001 tính giá bán lẻ, sau đó BR-PNM-002 giảm 5% trên giá này.; Gateway dùng Ngày giao dịch, trong khi quy tắc và payload dùng Order_Date/OrderDate. Đổi nhãn thành OrderDate trong [2026-09-01, 2026-09-30]? để giữ đúng trường dữ liệu và biên ngày bao gồm.; Nút I[Giá Cuối cùng] gộp kết quả có giá trị khác nhau nhưng không cho biết giá nào được trả về. Tách hoặc gắn nhãn kết quả cụ thể cho SKU mục tiêu có khuyến mãi, SKU mục tiêu không khuyến mãi và SKU khác.
assets/diagrams/21-change-control-traceability-and-baselining-017-2a923509.mmd — REVISE — Nút “Tiêu chí chấp nhận” và /02-handbook/yy-acceptance-criteria.md không được phần văn xuôi hoặc danh sách Artifact hỗ trợ. Xóa nút này hoặc bổ sung nguồn và tiêu chí chấp nhận tương ứng trong nội dung.; Sơ đồ dùng đường dẫn mẫu xx, yy, 00X thay vì liên kết cụ thể REQ-SALES-007 và TC-SALES-015, làm mất truy vết cấp mục. Gắn nhãn bằng ID hiện có và đường dẫn thực.; Chuỗi tuyến tính ngụ ý mọi Test Case luôn truy vết qua tài liệu tiêu chí chấp nhận riêng, trong khi phần văn xuôi chỉ xác lập quan hệ DD-PROD-001 → BR-SALES-010 → REQ-SALES-007 → TC-SALES-015. Chỉnh quan hệ để không tạo phụ thuộc chưa được chứng minh.; Sơ đồ không thể hiện thay đổi QC Passed, điểm kiểm soát cốt lõi của quyết định. Thêm điều kiện hoặc nhãn truy vết QC Passed để chuỗi không biến thành sơ đồ tài liệu chung, tách khỏi tình huống Nova Foods.
assets/diagrams/21-change-control-traceability-and-baselining-018-1d80db15.mmd — REVISE — Nút NF-DESIGN-0078 là tạo tác và mã định danh không được phần văn bản xác lập. Xóa nút này hoặc bổ sung nguồn trong văn bản; không suy diễn mã thiết kế.; NF-CR-0015 trong văn bản là thay đổi Quy trình Kiểm soát Thay đổi, nhưng sơ đồ thể hiện CR này trực tiếp cập nhật NF-REQ-0123. Sửa quan hệ hoặc dùng đúng CR nghiệp vụ cho thay đổi yêu cầu.; Nhãn D -- KHÔNG cập nhật --> C gán hành vi không cập nhật cho Change Request, trong khi văn bản xác định BA quên cập nhật test case. Cần thể hiện BA là chủ thể hoặc dùng trạng thái cụ thể như NF-TC-0045 chưa được cập nhật.; Sơ đồ bỏ qua kiểm soát cốt lõi của quyết định: BA cập nhật danh sách tạo tác và Traceability Matrix; QA Lead kiểm tra truy vết; Project Manager và QA Lead đồng phê duyệt. Cần thể hiện các bước và chủ sở hữu này nếu sơ đồ mô tả quy trình kiểm soát.; Nút Sản phẩm sai lô/HSD vẫn xuất ra nhập nhằng và vượt quá tình huống đã nêu. Văn bản mô tả xuất lô gần hết hạn do thiếu kiểm tra hạn sử dụng, không xác lập sản phẩm sai lô. Đổi thành kết quả cụ thể được hỗ trợ bởi văn bản.; Nhánh A_new đến C_new chỉ thể hiện hành động lẽ ra phải làm, nhưng không nối với Traceability Matrix, kiểm tra đầy đủ hoặc quyết định duyệt CR. Cần phân biệt rõ luồng lỗi hiện tại và luồng kiểm soát được chọn.
assets/diagrams/22-operations-support-and-post-go-live-analysis-001-dec11893.mmd — REVISE — Nút quyết định "Ưu tiên & Gán trách nhiệm" chỉ có một nhánh ra, nên không thể hiện điều kiện hay lựa chọn. Đổi thành bước xử lý thông thường hoặc bổ sung các nhánh theo mức ưu tiên và bộ phận chịu trách nhiệm đã nêu: IT, Nghiệp vụ, nhà cung cấp.; Luồng "Sau" biến mọi sự cố thành RCA rồi tạo CR. Phần văn bản chỉ nêu RCA trong các cuộc đánh giá định kỳ và CR-NF-QLDHTD-003 là một trường hợp cụ thể. Thể hiện điều kiện chuyển sang RCA/CR và nhánh xử lý, đóng sự cố không cần CR.; Các bước "Đội Phát triển/Vận hành (triển khai sửa lỗi)", "Kiểm thử & Xác minh" và "Cập nhật tri thức" không được phần văn bản xác lập đầy đủ về chủ thể hoặc quy trình. Loại bỏ hoặc bổ sung căn cứ trong văn bản trước khi giữ chúng.; Vòng lặp "Phát hiện lỗi tiềm ẩn" quay về "Người dùng báo lỗi" mâu thuẫn về nguồn phát hiện: lỗi tiềm ẩn từ phân tích xu hướng không phải lỗi do người dùng báo. Đưa kết quả cải tiến về bước tạo hành động khắc phục/CR phù hợp hoặc nêu rõ sự kiện mở sự cố chủ động.; Nhánh "Có" từ "Xử lý vấn đề tạm thời?" quay thẳng về bước người dùng báo lỗi nhưng không ghi điều kiện tái diễn. Gắn nhãn kết quả như sự cố tái phát hoặc thể hiện trạng thái xử lý tạm thời trước khi quay lại.; Luồng chưa thể hiện việc họp đánh giá sau triển khai định kỳ và phân tích các sự cố tồn đọng, dù đây là cơ chế chính trong phần văn bản. Bổ sung ranh giới hoặc bước đánh giá định kỳ trước phân tích xu hướng và RCA.; Nhãn trộn tiếng Việt và tiếng Anh như "Ad-hoc", "Operation Support Team" và "Incident Management" làm giảm tính song song. Chuẩn hóa ngôn ngữ, chỉ giữ thuật ngữ Anh trong ngoặc khi cần.
assets/diagrams/22-operations-support-and-post-go-live-analysis-002-fb462f23.mmd — REVISE — Cạnh phản hồi từ Vận hành chỉ quay về Khám phá, trong khi nội dung nêu đề xuất cải tiến gửi về Khám phá/Phân tích. Cần thể hiện cả hai đích hoặc ghi rõ điều kiện chọn giai đoạn.; Vòng tự nối tại Vận hành mang nhãn "Bao gồm Hỗ trợ Vận hành & Phân tích sau Triển khai", nhưng nhãn mô tả thành phần, không mô tả chuyển trạng thái, sự kiện hay tính liên tục. Cần bỏ cạnh này hoặc đổi cách biểu diễn để thể hiện hai hoạt động thuộc giai đoạn Vận hành và diễn ra liên tục.
assets/diagrams/22-operations-support-and-post-go-live-analysis-003-ce19bfc8.mmd — REVISE — Sơ đồ thêm Quản lý Dự án/Sản phẩm, Đội Phát triển, Đội QA và Quản lý Release cùng chuỗi phát triển–kiểm thử–phát hành; phần Quick Reference không xác định vai trò, bàn giao, thẩm quyền hoặc quy trình này. Xóa chuỗi không được hỗ trợ hoặc bổ sung nội dung nguồn trước khi dùng.; Luồng "D -- Tư vấn Pháp lý --> K" đảo ngược trách nhiệm. IT BA gửi báo cáo phân tích hoặc yêu cầu tư vấn cho Pháp chế/Tuân thủ; Pháp chế/Tuân thủ mới cung cấp tư vấn pháp lý. Sửa nhãn và chiều luồng.; Luồng "E -- Phê duyệt Nghiệp vụ --> G" và "F -- Phê duyệt Kỹ thuật --> G" chỉ định Quản lý Dự án/Sản phẩm làm bên nhận, nhưng bảng không xác định bàn giao này. Chỉ giữ bên nhận được phần nguồn hỗ trợ.; Luồng "J -- Triển khai Production --> C" mô tả Quản lý Release triển khai vào Vận hành IT, nhưng phần nguồn không nêu owner triển khai, cổng phát hành hoặc bàn giao production. Xóa hoặc bổ sung nguồn.; Các điểm leo thang không đầy đủ so với bảng: thiếu Helpdesk đến IT BA; Vận hành IT đến Quản lý IT và Trưởng nhóm Phát triển; IT BA đến Quản lý Dự án; Business Owner đến CEO; Tech Lead đến Quản lý Phát triển; Legal/Compliance đến Trưởng phòng Pháp chế và Ban lãnh đạo. Thể hiện đủ hoặc giới hạn rõ phạm vi sơ đồ.; Sơ đồ gộp luồng bàn giao và leo thang bằng các cạnh trùng D–K, D–E và D–F nhưng không phân biệt điều kiện, loại quan hệ hoặc kết quả. Dùng nhãn cụ thể và cách thể hiện riêng cho bàn giao thường lệ với leo thang.; Nhãn "Phê duyệt Kỹ thuật" không khớp đầu ra cụ thể của Tech Lead là "Phê duyệt thiết kế kỹ thuật" và "Kế hoạch triển khai". Dùng thuật ngữ chính xác từ bảng.; Sơ đồ không thể hiện giới hạn thẩm quyền, dù đây là nội dung trọng tâm: IT BA không phê duyệt production hoặc quyết định nghiệp vụ/kiến trúc; Business Owner không quyết định kỹ thuật; Tech Lead không quyết định nghiệp vụ. Bổ sung ranh giới quyết định hoặc thu hẹp mục tiêu sơ đồ để tránh hiểu sai.
assets/diagrams/22-operations-support-and-post-go-live-analysis-004-01241f8f.mmd — REVISE — Thiếu giai đoạn ngừng hoạt động dù phần văn bản xác định vòng đời kéo dài đến khi hệ thống ngừng hoạt động. Bổ sung trạng thái hoặc nhánh kết thúc này.; Nút G dùng hình thoi nhưng không thể hiện quyết định, điều kiện hoặc nhiều nhánh. Đổi sang nút hoạt động hoặc bổ sung điều kiện và kết quả cho từng nhánh.; Nút G gộp Hỗ trợ Vận hành và Phân tích Sau triển khai, làm mờ quan hệ giữa hai hoạt động. Tách hoạt động hoặc thể hiện rõ dữ liệu từ hỗ trợ vận hành đi vào phân tích sau triển khai.; Luồng Kiến nghị cải tiến luôn quay về Khám phá, bỏ qua khả năng tiếp tục vận hành hoặc ngừng hoạt động. Thể hiện các kết quả được phần văn bản hỗ trợ, gồm cải tiến và kết thúc vòng đời.; Nhãn Thiết kế & Phát triển - Design & Delivery không song song về nghĩa: Phát triển tương ứng Development, không phải Delivery. Đồng bộ hai ngôn ngữ.; Nhãn Dữ liệu, Vấn đề vận hành mơ hồ và không song song. Dùng nhãn cụ thể, viết thường nhất quán, nêu rõ dữ liệu vận hành và vấn đề vận hành.
assets/diagrams/22-operations-support-and-post-go-live-analysis-005-2dce6213.mmd — REVISE — Nhánh E -- Không --> G -- Không --> F mâu thuẫn: Input chưa đủ nhưng kết thúc với trạng thái "Input đã đủ". Cần tách kết quả dừng khi không còn nguồn mới, nêu rõ Input còn thiếu và quyết định xử lý hoặc chấp nhận rủi ro.; Các bước "Xác định Chủ sở hữu và Nguồn", "Thu thập Input theo định dạng chuẩn" và "Kiểm tra Chất lượng và Độ tươi mới Input" dùng nút quyết định dù không phải câu hỏi phân nhánh. Cần dùng nút quy trình; chỉ E và G nên là gateway.; Điều kiện "đủ", "chất lượng", "độ tươi mới" và "định dạng chuẩn" chưa có tiêu chí cụ thể trong phần được cung cấp. Cần liên kết hoặc nêu tiêu chí kiểm tra được.; Quy trình không nêu ai chịu trách nhiệm thu thập, kiểm tra và quyết định dừng. Cần xác định actor hoặc vai trò nếu phần prose có quy định.; Nhánh D -- Không đạt --> C tạo vòng lặp nhưng không nêu hành động sửa, bổ sung hoặc yêu cầu lại Input. Cần thêm trạng thái xử lý rõ ràng trước khi kiểm tra lại.
assets/diagrams/22-operations-support-and-post-go-live-analysis-006-07ea482f.mmd — REVISE — Không có văn xuôi mô tả quy trình ngoài chính sơ đồ, nên chưa thể xác minh các nguồn NF-TXN-ERP-001, NF-LOG-SYS-001, NF-INC-REP-001, NF-PERF-MET-001, NF-BRD-ERP-001, NF-BPM-PROC-003, NF-BPM-PROC-004 và NF-CONF-SYS-001; cần bổ sung hoặc đối chiếu từng nguồn với nội dung mục.; Bốn hoạt động xác minh chưa có căn cứ trong văn xuôi được cung cấp; cần xác nhận nội dung mục hỗ trợ từng hoạt động hoặc loại bỏ hoạt động không được nêu.; Nhãn “Xác nhận Quyền sở hữu & Độ tươi mới Nguồn Dữ liệu” mơ hồ vì không nêu chủ sở hữu, tiêu chí cập nhật hoặc ngưỡng chấp nhận; cần dùng thuật ngữ cụ thể theo văn xuôi.; Sơ đồ không thể hiện chủ thể chịu trách nhiệm phân tích, xác minh và phê duyệt báo cáo; cần thêm chủ thể nếu mục quy định quyền sở hữu hoặc trách nhiệm.; Luồng gộp mọi nguồn và hoạt động vào PA mà không thể hiện điều kiện thiếu dữ liệu, sai định dạng, đối chiếu thất bại hoặc cách xử lý ngoại lệ; cần bổ sung nhánh nếu văn xuôi quy định các trường hợp này.; Đầu ra “Đề xuất Cải tiến & Báo cáo” không khớp hoàn toàn với nút chỉ mang tên “Báo cáo Phân tích Vận hành”; cần làm rõ đề xuất cải tiến nằm trong báo cáo hay là đầu ra riêng.
assets/diagrams/22-operations-support-and-post-go-live-analysis-007-b39719b2.mmd — REVISE — Bước 1 vẽ BA gửi yêu cầu sang BO, nhưng bảng chỉ nêu BA thu thập dữ liệu từ SAP, WMS, vận hành kho và BRD; không xác định BO là nguồn hoặc bên nhận. Cần bỏ giao tiếp BA->>BO hoặc dùng đúng nguồn dữ liệu được nêu.; Bước 4 vẽ SME chuyển escalation sang TL, trong khi quy trình quy định PM và Technical Lead là tuyến escalation khi RCA không thuyết phục hoặc quá phức tạp. Cần thể hiện đủ PM và TL, không tự gán SME làm bên khởi tạo nếu prose không xác định.; Bước 5 chỉ thể hiện BA và DEV, bỏ Business Owner khỏi nhóm phát triển phương án. Nhánh escalation chỉ tới SO, bỏ PM dù quy trình quy định cả PM và Solution Architect.; Bước 6 bỏ Development Team khỏi hoạt động đánh giá giải pháp, dù đây là actor được chỉ định. Nhánh escalation chưa thể hiện Business Owner là bên có thẩm quyền cùng PM.; Bước 7 thu hẹp stakeholder thành BO mà không có căn cứ đầy đủ; ví dụ Nova Foods nêu Quản lý kho và nhân viên kho. Cần thể hiện đúng nhóm phản hồi hoặc dùng nhãn stakeholder cụ thể, đồng thời giữ đủ BO và PM trong tuyến escalation.; Bước 8 dùng SC phù hợp ví dụ Nova Foods, nhưng nhánh escalation chỉ tới PM và bỏ Business Owner theo quy trình chung. Cần phân biệt người phê duyệt trong ví dụ với tuyến escalation chuẩn.; Bước 9 thêm DEV->>BO: Đào tạo người dùng, nhưng prose nói BA bàn giao cho IT và đội vận hành kho để đào tạo; không nói DEV đào tạo BO. Cần bỏ quan hệ này hoặc thể hiện đúng đội vận hành/người dùng và trách nhiệm đào tạo.; Bước 10 bỏ Project Team khỏi hoạt động PIR và ghi kết quả chung chung 'Chênh lệch tồn kho giảm', trong khi ví dụ nêu kết quả cụ thể dưới 2%. Cần giữ đủ actor và tiêu chí kết quả.; Các nhánh alt chỉ mô tả escalation, không thể hiện luồng tiếp tục, điều chỉnh hoặc quyết định sau escalation. Vì vậy gateway trông như điểm kết thúc dù prose yêu cầu giải quyết bất đồng, tinh chỉnh, phê duyệt hoặc xem xét tác động.; Sơ đồ gần như lặp lại nguyên thứ tự 10 bước của bảng; giá trị bổ sung chủ yếu là giao tiếp và escalation, nhưng nhiều giao tiếp đang thiếu owner hoặc không được prose hỗ trợ.
assets/diagrams/22-operations-support-and-post-go-live-analysis-008-153a59d9.mmd — REVISE — Nhánh D -- Thấp --> F --> O kết thúc quy trình mà không khắc phục, xác minh, đóng sự cố hoặc review sau sự cố. Sửa nhánh mức độ thấp để xếp lịch rồi quay vào điều tra/xử lý, hoặc thể hiện rõ trạng thái hoãn cùng điều kiện đóng.; Gateway Phê duyệt Phương án? không nêu chủ thể phê duyệt dù phần prose xác định Trưởng phòng Kế toán, Đại diện pháp lý, Trưởng phòng IT và BA Trưởng dự án ERP. Bổ sung owner hoặc nhóm thẩm quyền tại bước phê duyệt.; Bước Triển khai Khắc phục (Dev, QA) gộp phát triển, kiểm thử và triển khai thành một bước mơ hồ. Tách hoặc đổi nhãn để thể hiện đúng trình tự thực hiện thay đổi, QA và triển khai.; Nhánh K -- Thất bại --> J đưa lỗi xác minh thẳng về triển khai, bỏ qua phân tích nguyên nhân và điều chỉnh phương án. Chuyển nhánh thất bại về bước điều tra hoặc cập nhật phương án.; Quyết định chọn cả tái cấu hình API và error handler, đồng thời ưu tiên tái cấu hình API trước, nhưng sơ đồ chỉ liệt kê hai giải pháp trong cùng một nhãn. Thể hiện thứ tự ưu tiên và việc thực hiện cả hai phương án.; Phương án tiếp tục xử lý thủ công xuất hiện trong phân tích nhưng không có trong luồng đánh giá hoặc quyết định. Bổ sung như phương án bị loại/tạm thời, hoặc giới hạn sơ đồ rõ là luồng sau khi phương án 1 và 2 đã được chọn.; Các artifact bắt buộc cho truy vết gồm NF-IAR-20260807-001, đặc tả điều chỉnh API và thiết kế error handler không được tạo hoặc cập nhật trong luồng. Bổ sung bước tạo/phê duyệt artifact tương ứng.; Nhãn Đã tìm ra gốc rễ? dùng từ không nhất quán với Nguyên nhân gốc. Đổi thành Đã xác định nguyên nhân gốc? để cụ thể và song song.; Bước Đóng sự cố đứng trước Review sau sự cố, khiến review và cập nhật tài liệu nằm ngoài điều kiện đóng. Làm rõ đóng kỹ thuật trước review hay chuyển đóng sự cố sau review và cập nhật tài liệu.
assets/diagrams/22-operations-support-and-post-go-live-analysis-009-0956c725.mmd — REVISE — Các chuyển trạng thái tuần tự không được phần văn bản xác lập; cần bổ sung quy tắc chuyển trạng thái trong văn bản hoặc giới hạn sơ đồ ở quan hệ đã được xác nhận.; Nhãn QA xác nhận đưa thêm vai trò và thẩm quyền của QA, trong khi phần văn bản chỉ nêu BA phụ trách và các nhóm hỗ trợ/phát triển; cần xác lập QA là bên xác nhận hoặc bỏ vai trò này.; Nhãn Người báo cáo đồng ý đặt điều kiện đóng sự cố chưa được mô tả; cần bổ sung tiêu chí và thẩm quyền đóng hoặc bỏ điều kiện.; Luồng CLOSED --> NEW và điều kiện nếu lỗi chưa dứt điểm chưa được phần văn bản hỗ trợ, đồng thời làm mất lịch sử trạng thái xử lý khi mở lại; cần xác lập chính sách reopen và trạng thái đích phù hợp.; Sơ đồ chỉ có luồng thuận, không thể hiện kết quả kiểm thử không đạt hoặc sự cố cần xử lý lại; cần xác lập nhánh ngoại lệ quan trọng này nếu sơ đồ đại diện quy trình vận hành.; Nhãn Hoàn thành sửa/fix trộn ngôn ngữ và không nêu kết quả kiểm chứng được; cần dùng nhãn tiếng Việt cụ thể, nhất quán với các nhãn còn lại.
assets/diagrams/22-operations-support-and-post-go-live-analysis-010-df710b69.mmd — REVISE — BA->>INV_MOD: Tạo Yêu cầu Thay đổi gán module hệ thống làm bên nhận CR. Phần prose chỉ xác nhận BA ghi nhận quyết định trong CR NF-REQ-20260801-001; cần thể hiện BA tạo/ghi nhận CR trong kho tài liệu hoặc không chỉ định bên nhận.; INV_MOD->>DEV: Yêu cầu thay đổi cấu hình biến module thành chủ thể giao việc. Không có luồng này trong prose; cần dùng chủ thể có thẩm quyền giao việc hoặc bỏ bước.; DEV->>ERP: Cập nhật tham số, DEV->>DEV: Thực hiện Kiểm thử nội bộ và ERP-->>P: Cảnh báo HSD D-3 mô tả triển khai, kiểm thử và kết quả vận hành đã xảy ra, trong khi prose chỉ ghi quyết định được phê duyệt cùng yêu cầu thay đổi và yêu cầu kiểm thử. Cần dừng tại CR/yêu cầu kiểm thử hoặc phân biệt rõ trạng thái dự kiến.; Nhãn Kiểm thử nội bộ không khớp artifact. Prose yêu cầu xác minh cảnh báo tại D-3 theo NF-TC-20260801-001, không xác định đây là kiểm thử nội bộ hay do DEV thực hiện.; Trình tự cập nhật trước kiểm thử rồi phát cảnh báo thiếu bước triển khai/phát hành vào vận hành. Luồng hiện tại làm mờ ranh giới giữa thay đổi cấu hình, kiểm thử và hành vi production.; Hai participant ERP và INV_MOD có quan hệ hệ thống–module nhưng sơ đồ dùng cả hai như tác nhân độc lập, không thể hiện ranh giới hay quan hệ chứa. Cần tránh mô hình hóa module như actor tự giao việc.
assets/diagrams/22-operations-support-and-post-go-live-analysis-011-d341c141.mmd — REVISE — Phần mô tả chỉ xác định ví dụ đơn giản về xử lý sự cố cấp 1; sơ đồ tự bổ sung hệ thống hỗ trợ, mẫu Ticket ID, phân loại lỗi, BA, DEV/OPS, Chủ sở hữu Nghiệp vụ/Sản phẩm và quy trình sửa lỗi mà không có nội dung hỗ trợ. Bổ sung các chi tiết này vào phần mô tả hoặc loại khỏi sơ đồ.; Phạm vi Level 1 Support không rõ: sơ đồ giao trực tiếp cho BA hoặc DEV/OPS nhưng không thể hiện tác nhân L1, bước sàng lọc, tiêu chí chuyển tuyến hay ranh giới trách nhiệm. Làm rõ chủ thể L1 và điều kiện chuyển xử lý.; Gateway “Hệ thống hỗ trợ ghi nhận?” mơ hồ về hành động, kết quả và nguyên nhân nhánh “Không”. Đổi thành điều kiện kiểm chứng cụ thể, đồng thời nêu cách ghi nhận thủ công bảo toàn thông tin sự cố.; Gateway “BA xác định nguyên nhân và đề xuất” và “DEV/OPS xác định nguyên nhân và đề xuất” thiếu dạng câu hỏi và không có nhánh khi chưa xác định được nguyên nhân. Xác định điều kiện Có/Không cùng bước điều tra hoặc chuyển tuyến tiếp theo.; Bước “Đánh giá và Quyết định bởi Chủ sở hữu Nghiệp vụ/Sản phẩm” dùng cấu trúc bị động, gộp hai vai trò thay thế nhau và không nêu tiêu chí quyết định. Chỉ rõ chủ thể chịu trách nhiệm, tiêu chí và quyền phê duyệt.; Nhánh “Không sửa” dẫn thẳng đến đóng phiếu, bỏ qua lý do, thông báo người báo cáo, chấp nhận rủi ro hoặc phương án xử lý thay thế. Thêm kết quả quyết định và trách nhiệm thông báo trước khi đóng.; Nhánh “Sửa” triển khai trước khi thể hiện kiểm thử, phê duyệt phát hành, quản lý thay đổi hoặc phương án hoàn tác. Bổ sung các kiểm soát cần thiết nếu quy trình này bao gồm triển khai production.; Bước “Kiểm tra lại, xác nhận giải quyết” không nêu ai kiểm tra, ai xác nhận và điều gì xảy ra khi kiểm tra thất bại. Gán chủ thể, tiêu chí xác nhận và vòng lặp xử lý lại.; Nhãn dùng từ không song song và thiếu nhất quán: “Lỗi dữ liệu/Quy tắc”, “Lỗi hệ thống/Kỹ thuật”, “Dữ liệu, Quy tắc, Kịch bản”, “Log, Code, Infra”. Chuẩn hóa thuật ngữ tiếng Việt và cấu trúc nhãn.; Sơ đồ chỉ có hai loại sự cố nhưng không có nhánh “khác” hoặc trường hợp phân loại chưa đủ thông tin. Thêm ngoại lệ hoặc xác nhận rõ phạm vi phân loại là đầy đủ.
assets/diagrams/22-operations-support-and-post-go-live-analysis-012-2aa30c39.mmd — REVISE — Hai nút hạ nguồn Artifact QA / Đánh giá và Chương kế tiếp không trỏ tới artifact đã xác định; thay bằng artifact chính tắc có bằng chứng trong chapter hoặc loại bỏ.; Nhãn Artifact QA / Đánh giá mơ hồ, không nêu artifact, chủ sở hữu hay loại quan hệ phụ thuộc; dùng tên artifact cụ thể và quan hệ được section xác nhận.; Nhãn VD: 23-continuous-improvement trình bày ví dụ giả định như phụ thuộc thực; xác minh tên và đường dẫn chính tắc hoặc loại bỏ cạnh C22 --> NextChapter.; Biểu đồ lặp gần như nguyên vẹn bảng phụ thuộc ngay bên dưới, nên giá trị trực quan còn thấp; chỉ giữ nếu sơ đồ làm rõ cấu trúc hoặc quan hệ mà bảng không thể hiện.
assets/diagrams/22-operations-support-and-post-go-live-analysis-013-14245f5a.mmd — REVISE — Chuỗi BR → REQ → thiết kế CSDL trình bày quan hệ tuyến tính không được phần văn bản xác lập; cần bỏ quan hệ này hoặc chỉ giữ quan hệ phụ thuộc được nêu rõ.; Nhánh thiết kế CSDL mới → REPORT không có căn cứ trong ví dụ thay đổi mô hình dữ liệu; cần bỏ REPORT hoặc bổ sung căn cứ trong văn bản.; Nhánh thiết kế CSDL mới → Test Case mâu thuẫn với ví dụ số 4, nơi Test Case phụ thuộc vào Requirement/Acceptance Criteria thay đổi; cần nối REQ thay đổi với TC tương ứng hoặc bỏ nhánh.; Ký hiệu -X không diễn đạt rõ quan hệ 'không được cập nhật' và có thể không phải cú pháp cạnh kết thúc bằng dấu chéo hợp lệ trong Mermaid; cần dùng cú pháp Mermaid hợp lệ cùng nhãn quan hệ cụ thể.; Các nút API, UI, REPORT và TC đều được tô đỏ như chắc chắn bị hỏng, trong khi văn bản chỉ nêu khả năng lỗi hoặc hiển thị sai khi không cập nhật; cần thể hiện điều kiện 'không được cập nhật'.; Nhãn Thiết kế CSDL MỚI quá chung và không phản ánh thay đổi cụ thể PRODUCT.quantity_on_hand: INT → DECIMAL; cần dùng nhãn cụ thể để liên kết trực tiếp với ví dụ.; Chú giải X tạo nút riêng nhưng không khớp rõ với ký hiệu trên cạnh, làm ý nghĩa điểm hỏng mơ hồ; cần đồng nhất ký hiệu và chú giải.
assets/diagrams/22-operations-support-and-post-go-live-analysis-014-a2190301.mmd — REVISE — Gateway "Có Test Plan Hồi Quy / Rollback?" gộp hai điều kiện độc lập, khiến câu trả lời "Có" mơ hồ khi chỉ có Test Plan hoặc chỉ có Rollback Plan. Tách điều kiện hoặc yêu cầu rõ cả hai.; Bước kiểm thử chỉ có nhánh "Đạt & Rollback OK"; thiếu nhánh kiểm thử không đạt và hành động dừng triển khai, sửa bản vá hoặc khôi phục. Bổ sung gateway kết quả kiểm thử cùng nhánh thất bại.; Nhãn "Production Cập Nhật An Toàn" khẳng định an toàn tuyệt đối dù kiểm thử chỉ giảm rủi ro. Đổi thành trạng thái cụ thể như triển khai production sau khi kiểm thử đạt.; Nhánh lỗi hồi quy kết thúc tại thiệt hại, bỏ mất Safe Recovery Boundary quan trọng: kích hoạt Rollback Plan và quay về phiên bản ổn định. Bổ sung luồng khôi phục.; Sơ đồ bỏ toàn bộ quyền quyết định và trách nhiệm của Operations Manager, Development Lead và BA. Gắn chủ thể vào các bước yêu cầu hotfix, đánh giá tác động, phê duyệt hoặc triển khai khi trách nhiệm ảnh hưởng quyết định.; Nhãn "Rollback OK" đưa vào việc xác nhận rollback thành công, trong khi phần văn xuôi chỉ yêu cầu xây dựng và tuân thủ Rollback Plan. Đổi thành kiểm tra mức sẵn sàng của kế hoạch hoặc bổ sung bước diễn tập nếu nội dung văn xuôi xác nhận việc đó.
assets/diagrams/22-operations-support-and-post-go-live-analysis-015-5fc4b1ff.puml — REVISE — Mô hình sai dùng cả diamond "Xử lý đơn hàng" và gateway if (Hợp lệ), nên lỗi ký hiệu bị pha với một điểm quyết định hợp lệ. Bỏ gateway hợp lệ khỏi mô hình sai hoặc thể hiện rõ hình thoi Xử lý đơn hàng bị dùng sai như activity.; Nhãn Hợp lệ mơ hồ, không nêu điều kiện nghiệp vụ và không song song với Tồn kho đủ?. Đổi thành điều kiện tồn kho cụ thể nếu vẫn cần gateway.; Các bước Xác nhận đơn hàng và Thông báo khách hàng không được phần văn xuôi xác lập. Bỏ chúng hoặc bổ sung căn cứ trong văn xuôi trước khi giữ trong sơ đồ.; Hai partition chưa nêu rõ đây là hai phương án độc lập của cùng quy trình, dễ bị đọc như hai đoạn liên tiếp. Tách luồng trực quan hoặc ghi rõ ranh giới so sánh.
assets/diagrams/23-capstone-nova-foods-delivery-pack-001-45df7a02.mmd — REVISE — Sơ đồ tạo dữ kiện không có trong phần văn xuôi: Trưởng phòng Vận chuyển: "Có thể cập nhật app". Xóa nội dung này hoặc thay bằng đầu vào đã nêu từ Trưởng phòng CS.; Sơ đồ tạo giả định Hiệu năng hệ thống; phần văn xuôi chỉ nêu giả định về tính sẵn có và độ chính xác của EstimatedDeliveryDateTime. Thay bằng giả định đã được mô tả.; Sơ đồ biến Tích hợp API bên thứ 3 từ một phương án thành Tuyên bố cần xác minh. Giữ nó là Phương án 3 và chỉ đánh dấu các phụ thuộc chưa xác minh cụ thể nếu phần văn xuôi cung cấp.; Các bước Khảo sát khách hàng và Kiểm thử không được phần văn xuôi xác lập. Xóa hoặc bổ sung căn cứ trong nội dung trước khi đưa vào sơ đồ.; Nút đánh giá phương án bỏ hai tiêu chí đã nêu: Tính tuân thủ và Chất lượng dữ liệu; đồng thời đổi Lợi ích thành tiêu chí cụ thể Mức độ cải thiện trải nghiệm khách hàng/giảm cuộc gọi CS.; Sơ đồ không thể hiện rủi ro quyết định quan trọng: dữ liệu thiếu hoặc sai có thể tăng phàn nàn, gây mất uy tín và tăng áp lực CS. Thêm nhánh rủi ro hoặc điều kiện kiểm soát chất lượng dữ liệu trước kết quả.; Nhãn Yêu cầu/Thông tin mới và Phân loại? quá chung. Dùng đối tượng cụ thể đang được xem xét và các nhóm phân loại nhất quán với nội dung.
assets/diagrams/23-capstone-nova-foods-delivery-pack-002-e6f0bd46.mmd — REVISE — Nhãn đầu vào “Ý tưởng/Vấn đề mới” không khớp prose: Discovery bắt đầu từ “vấn đề kinh doanh hoặc cơ hội kinh doanh”. Thay “Ý tưởng” bằng “Cơ hội kinh doanh”.; Chuyển tiếp Phân_Tích → Triển_Khai_Phát_triển chỉ nêu thiết kế được duyệt, nhưng prose yêu cầu đồng thời baseline yêu cầu và phê duyệt thiết kế. Bổ sung cả hai điều kiện.; Chuyển tiếp Triển_Khai_Phát_triển → Kiểm_Thử chỉ nêu code hoàn tất, bỏ điều kiện unit test nội bộ đã qua. Bổ sung điều kiện này.; Chuyển tiếp Triển_Khai_Chính_thức → Vận_Hành dùng “Triển khai thành công”, nhãn mơ hồ và bỏ kết quả cụ thể: giải pháp chạy trên production, người dùng truy cập được, kiểm tra sau triển khai hoàn tất. Dùng điều kiện cụ thể phù hợp prose.; Kết_Thúc_Sử_dụng không nối tới trạng thái kết thúc [], khiến vòng đời ngừng sử dụng trông như trạng thái còn tiếp diễn. Nối trạng thái này tới [].; Cách viết hoa trong tên trạng thái không nhất quán: “Khám_Phá”, “Triển_Khai_Phát_triển”, “Triển_Khai_Chính_thức”, “Kết_Thúc_Sử_dụng”. Chuẩn hóa viết hoa song song.
assets/diagrams/23-capstone-nova-foods-delivery-pack-003-32f0400e.mmd — REVISE — Nút "Nova Foods Dev/QA Lead" gộp hai vai trò không được phần Core định nghĩa. QA Lead có trách nhiệm phê duyệt Test Plan, Test Results và QA Sign-off; Dev chỉ xuất hiện trong ví dụ bàn giao source code. Cần tách QA Lead khỏi Dev và không gán trách nhiệm ngoài nội dung đã nêu.; Các luồng từ Product Owner, Solution Architect và QA vào "Tập hợp Delivery Pack" bỏ qua hành động phê duyệt thuộc trách nhiệm chính của từng vai trò. Cần thể hiện rõ phê duyệt nội dung nghiệp vụ, thiết kế kỹ thuật và kết quả kiểm thử trước khi tập hợp pack.; Operations Lead chỉ xuất hiện sau Release Manager, khiến sơ đồ bỏ mất trách nhiệm phê duyệt Runbook và Deployment Guide của Operations Lead. Cần thể hiện Operations Lead đóng góp hoặc phê duyệt các artifact này trong Delivery Pack.; Nhãn "Pack đủ, đúng" mơ hồ và có thể hiểu Release Manager phê duyệt tính đúng của nội dung nghiệp vụ hoặc kỹ thuật, trái giới hạn thẩm quyền. Cần giới hạn nhãn vào kiểm tra tính đầy đủ, nhất quán và xác nhận sẵn sàng triển khai.; Luồng "Pack triển khai được" trực tiếp dẫn đến "Hệ thống vận hành Nova Foods" biến xác nhận khả năng vận hành thành hành động triển khai thành công. Phần Core không xác định chủ thể triển khai, quyết định phát hành hay kết quả go-live; cần bỏ kết quả này hoặc bổ sung đúng gateway và chủ sở hữu đã được prose hỗ trợ.; Sơ đồ bỏ cơ chế Review và Sign-off bắt buộc cho mỗi bàn giao dù prose nêu rõ yêu cầu này. Ghi chú ponytail không đủ để tránh hiểu sai luồng hiện tại; cần biểu diễn ít nhất các điểm kiểm tra và chấp nhận.; Sơ đồ không thể hiện các giới hạn thẩm quyền và điểm leo thang quan trọng, nên luồng tuyến tính ngụ ý mọi vấn đề đều đi tiếp. Cần thể hiện nhánh ngoại lệ hoặc ranh giới phê duyệt liên quan khi quyết định vượt thẩm quyền.
assets/diagrams/23-capstone-nova-foods-delivery-pack-004-3321bd3c.mmd — REVISE — Nút S[Kết quả kiểm thử Pass, báo cáo lỗi"] có dấu ngoặc kép thừa, có thể làm Mermaid lỗi cú pháp; bỏ dấu " sau lỗi.; Phần xung quanh chỉ chứa sơ đồ, không có văn xuôi xác nhận actor, bước, cổng duyệt, artefact, nhánh lặp hoặc điều kiện; cần bổ sung nguồn mô tả hỗ trợ hoặc loại bỏ chi tiết chưa được chứng minh.; Các nút Entry Gate nằm cuối từng giai đoạn và mô tả điều kiện hoàn tất giai đoạn trước; đổi thành Exit Gate hoặc đặt chúng tại đầu giai đoạn kế tiếp với tiêu chí vào rõ ràng.; Nhãn Handoff: SME, Product Owner và Handoff: BA, Product Owner không nêu ai phê duyệt, ai tư vấn, ai nhận bàn giao; cần ghi owner và trách nhiệm quyết định cụ thể.; Nhánh W -- Không --> U chỉ quay lại lập kế hoạch nhưng chú thích nói Rollback or retry; sơ đồ không thể hiện rollback, trạng thái Production hoặc owner quyết định. Cần vẽ rõ rollback/retry và kết quả tương ứng, hoặc bỏ tuyên bố rollback.; Nhánh kiểm thử thất bại quay thẳng về thiết kế kỹ thuật K, bỏ qua phân loại lỗi và khả năng sửa tại bước xây dựng L hoặc cập nhật yêu cầu F; cần thể hiện tiêu chí định tuyến và owner xử lý.; Nút S[Kết quả kiểm thử Pass, báo cáo lỗi] trộn kết quả đạt với báo cáo lỗi, tạo trạng thái mơ hồ; cần tách bằng chứng đạt kiểm thử khỏi danh sách lỗi tồn đọng và nêu tiêu chí chấp nhận.; Nhãn Tính năng "Delivery Pack" hoạt động trực tiếp không cụ thể; cần dùng trạng thái vận hành đo được như đã triển khai Production và vượt kiểm tra sau triển khai.; Luồng kết thúc tại CC nhưng không thể hiện đóng vòng đời, ngừng vận hành hoặc xử lý sự cố không thuộc nhóm lỗi lớn; cần bổ sung nhánh ngoại lệ quan trọng hoặc giới hạn phạm vi sơ đồ.
assets/diagrams/23-capstone-nova-foods-delivery-pack-005-a12fcbb6.mmd — REVISE — Gateway "Số lượng vỏ hợp lệ?" không có tiêu chí xác định hợp lệ trong phần prose. Cần nêu quy tắc đối chiếu cụ thể hoặc bỏ gateway.; Nhánh "Không hợp lệ" vẫn chuyển thẳng sang cập nhật ERP, không thể hiện số lượng nào được ghi nhận, ai chấp nhận chênh lệch, hoặc trường hợp nào phải dừng và leo thang. Cần làm rõ kết quả xử lý ngoại lệ.; Các bước "Xác nhận thu gom với khách hàng" và "Vỏ chai về kho Nova Foods" không được mô tả trong yêu cầu, quyết định, hay ví dụ thực thi. Cần bổ sung căn cứ nghiệp vụ trong prose hoặc loại khỏi diagram.; Chủ thể cập nhật "ERP di động" không rõ. Cần gắn bước này với nhân viên giao hàng và xác nhận đây là giao diện của ERP, không phải ứng dụng độc lập đã bị loại.; Bước cập nhật tồn kho không thể hiện ranh giới giữa xác nhận kiểm đếm tại kho và đồng bộ vào ERP. Cần nêu chủ thể, dữ liệu được cập nhật, và cách xử lý khi số lượng kho khác số lượng tài xế ghi nhận.; Luồng thiếu ngoại lệ quan trọng khi khách hàng từ chối xác nhận, ERP di động không khả dụng, hoặc kho phát hiện chênh lệch. Cần thể hiện nhánh xử lý hoặc ghi rõ các ngoại lệ nằm ngoài phạm vi diagram.
assets/diagrams/23-capstone-nova-foods-delivery-pack-006-1493468e.mmd — REVISE — Sơ đồ dùng các dữ kiện không được phần mô tả xác lập: ORD-20260715-001, SKU-NF-SP007, Kho_ĐôngLạnh_NF, TàiXế_NF_007. Cần bỏ hoặc thay bằng nhãn nghiệp vụ tổng quát; nếu giữ, phải bổ sung nguồn xác nhận trong phần mô tả.; Điểm bắt đầu là đơn hàng đã xác nhận, nhưng Luật quyết định yêu cầu thể hiện từ khi đơn hàng được tiếp nhận. Cần thêm sự kiện tiếp nhận đơn và bước xác nhận, hoặc điều chỉnh phạm vi đã nêu.; Điều kiện thanh toán/ký nhận ghép hai trạng thái khác nhau trong một cổng quyết định, trong khi phần mô tả không xác lập phương thức thanh toán. Cần tách điều kiện có ý nghĩa nghiệp vụ hoặc chỉ giữ điều kiện nhận hàng được hỗ trợ.; Các kết quả hủy đơn do hết hàng và do khách từ chối được trình bày như quy tắc cố định nhưng không có luật nghiệp vụ hỗ trợ. Cần dẫn chiếu quy tắc hủy hoặc mô tả kết quả trung tính như chuyển xử lý ngoại lệ.; Phân công vai trò chưa đáp ứng yêu cầu mỗi bước thuộc một vai trò cụ thể. Các bước bắt đầu, quyết định tồn kho, thông báo khách hàng, xử lý từ chối và các trạng thái kết thúc thiếu hoặc có chủ sở hữu mơ hồ; Driver & Sales_Team còn gộp hai chủ sở hữu cho một bước. Cần xác định một vai trò chịu trách nhiệm cho từng bước và vai trò phối hợp nếu có.; Các cạnh từ bước quy trình sang nút vai trò không tạo swimlane và dễ bị hiểu như luồng nghiệp vụ dẫn sang tác nhân. Cần dùng cách thể hiện quyền sở hữu không lẫn với luồng tuần tự.; Sơ đồ không thể hiện ranh giới phạm vi đã nêu: sản phẩm đông lạnh, giao trong 24 giờ, khu vực TP. Hồ Chí Minh. Cần đưa các điều kiện phạm vi quan trọng vào nhãn hoặc chú thích.; Nhánh giao không thành công chỉ mô tả khách từ chối, bỏ các ngoại lệ dễ gây hiểu sai như không liên hệ được hoặc giao không thành công vì vận hành. Cần giới hạn rõ nhánh này chỉ áp dụng cho từ chối nhận, hoặc biểu diễn luồng ngoại lệ tổng quát phù hợp bằng chứng As-Is.
assets/diagrams/23-capstone-nova-foods-delivery-pack-007-64e42092.mmd — REVISE — Các trạng thái và bước IN_DEV, IN_TEST, DONE, REJECTED, BLOCKED, tích hợp mã nguồn, QA thông qua, xử lý dependency và triển khai không được phần văn bản xác định. Cần loại bỏ chúng hoặc bổ sung căn cứ rõ ràng trong nội dung xung quanh.; Luồng IN_TEST --> REJECTED kết thúc tại REJECTED, không thể hiện bước sửa lỗi hoặc quay lại kiểm thử. Cần xác định trạng thái tiếp theo và chủ thể chịu trách nhiệm nếu quy trình này có căn cứ.; Nhãn Thiếu dependency bên ngoài mơ hồ, không nêu dependency, điều kiện chặn hoặc chủ thể xử lý. Cần dùng điều kiện cụ thể có căn cứ hoặc bỏ nhánh.; DONE --> [*]: Tính năng đã triển khai đồng nhất việc QA thông qua AC với triển khai sản phẩm, trong khi phần văn bản nói rõ READY_FOR_DEV không biểu thị production readiness. Cần tách hai mốc nếu có căn cứ hoặc dừng sơ đồ tại READY_FOR_DEV.; IN_TEST --> DONE: Tất cả ACs được QA thông qua bổ sung phê duyệt QA không có trong cổng chất lượng; cổng chỉ yêu cầu BA xem xét và ít nhất một SME phản hồi phi chính thức. Cần sửa phạm vi sơ đồ theo đúng cổng này.; Bảng cho NF-FCR-007 ở IN_DEV và NF-FCR-008 ở NEW, nhưng văn bản không định nghĩa quy tắc chuyển chúng sang các trạng thái sau. Cần tránh trình bày vòng đời đầy đủ như quy trình đã được xác lập.
assets/diagrams/23-capstone-nova-foods-delivery-pack-008-2990f296.mmd — REVISE — Bỏ sót BA Lead tại bước kiểm tra nội bộ. Sửa nhãn C để thể hiện BA tự kiểm hoặc Senior BA/BA Lead kiểm tra chéo.; Gateway "Artifact hoàn thành bản nháp?" chỉ có nhánh "Có". Thêm nhánh "Không" quay về bước soạn thảo/cập nhật, hoặc bỏ gateway nếu không cần thể hiện nhánh này.; Nhãn "Đạt tiêu chí" chưa chỉ rõ sáu tiêu chí cổng chất lượng trong phần văn bản. Liên kết nhãn với các tiêu chí đã liệt kê hoặc ghi rõ "Đạt đủ tiêu chí cổng chất lượng".; "Ghi nhận thiếu sót" không nêu chủ thể xử lý. Làm rõ BA ghi nhận và cập nhật artifact để trách nhiệm trong vòng lặp không mơ hồ.
assets/diagrams/23-capstone-nova-foods-delivery-pack-009-9ce9089a.mmd — REVISE — Nút B và E dùng hình thoi dù nội dung không mô tả quyết định, điều kiện hoặc nhánh xử lý. Đổi sang nút tác vụ.; Nhãn E gán việc kiểm tra cho "Kho/Hỗ trợ", trong khi nội dung chỉ giao bộ phận kho kiểm tra lịch sử xuất hàng và đề xuất phương án xử lý. Ghi rõ chủ thể là bộ phận kho.; Nút E không mang lớp manual dù prose xác định kho kiểm tra thủ công. Áp dụng kiểu manual cho E.; Luồng từ E đến F lược mất phương án xử lý như giao bù hoặc hoàn tiền. Thể hiện kết quả kiểm tra và phương án xử lý trước khi CSKH cập nhật trạng thái.; Nhãn D không nêu rõ hai địa chỉ nhận email, làm mờ giao diện và bên nhận. Ghi cụ thể warehouse@novafoods.vn và support@novafoods.vn hoặc phân biệt người nhận xử lý với người nhận thông báo.; Nút F chỉ ghi "cập nhật Excel", chưa thể hiện trạng thái khiếu nại trong cột Status. Đổi nhãn thành hành động cụ thể.; Sơ đồ không thể hiện rõ ranh giới bàn giao giữa khách hàng, CSKH và kho. Bổ sung phân vùng hoặc cách nhóm chủ thể để làm rõ quyền sở hữu từng bước.
assets/diagrams/23-capstone-nova-foods-delivery-pack-010-cc050a7f.mmd — REVISE — DELIVERY_FAILED và PENDING_REATTEMPT vừa chuyển tiếp vừa kết thúc nhưng không nêu điều kiện phân nhánh; bổ sung điều kiện cụ thể cho trường hợp giao lại và trường hợp dừng.; Nhãn "Kết thúc, cần xử lý nghiệp vụ" mơ hồ và mâu thuẫn: luồng kết thúc nhưng vẫn còn xử lý; thay bằng kết quả nghiệp vụ hoặc trạng thái kết thúc cụ thể đã được Business Owner xác nhận.; Chuyển đổi CREATED --> PENDING_PICKUP mang nhãn "Chờ tài xế nhận", mô tả trạng thái đích thay vì sự kiện gây chuyển đổi; đổi thành sự kiện cụ thể, dùng cách đặt nhãn song song với các chuyển đổi khác.; Chuyển đổi PENDING_PICKUP --> READY_FOR_DELIVERY mang nhãn "Tài xế đã xác nhận nhận hàng" nhưng tên READY_FOR_DELIVERY chưa làm rõ hàng đã được lấy hay chỉ sẵn sàng giao; thống nhất tên trạng thái với ý nghĩa nghiệp vụ được Business Owner phê duyệt.
assets/diagrams/23-capstone-nova-foods-delivery-pack-011-d0375886.mmd — REVISE — C4 và C5 dùng cạnh phụ thuộc trực tiếp, nhưng bảng chỉ nói OWASP ASVS và OpenAPI Specification "có thể" định hình hoặc xuất hiện trong Delivery Pack. Cần biểu diễn phụ thuộc có điều kiện hoặc bỏ cạnh nếu chưa xác nhận.; D5 không thể hiện trạng thái TBD và vị trí chưa quyết định, khiến "Hướng dẫn Triển khai" trông như artifact hạ nguồn đã xác lập. Cần ghi rõ TBD trên nhãn hoặc dùng cạnh thể hiện trạng thái dự kiến.; D4 thiếu đường dẫn hoặc phạm vi "/02-handbook/ (khác)" đã nêu trong bảng. Cần thêm thông tin này để phân biệt tài liệu hạ nguồn với chính chapter hiện tại.; Sơ đồ gần như lặp nguyên danh sách trong bảng. Cần tăng giá trị giải thích bằng cách thể hiện rõ phụ thuộc bắt buộc, phụ thuộc có điều kiện và đầu ra dự kiến mà bảng đang mô tả.
assets/diagrams/23-capstone-nova-foods-delivery-pack-012-22bf9e82.mmd — REVISE — Cú pháp nhãn cạnh A --> F: ... không phải cú pháp flowchart Mermaid chuẩn và có thể không render đúng. Dùng cú pháp nhãn cạnh Mermaid hợp lệ.; Sơ đồ lặp lại đúng bảy quan hệ đã có trong bảng truy vết ngay bên dưới nhưng bỏ mất ID yêu cầu, loại liên kết và mục đích chi tiết. Giữ sơ đồ chỉ khi bổ sung góc nhìn riêng, như nhóm phụ thuộc theo PACK-23-09-RC-MAP, PACK-23-09-RC-TBL, PACK-23-09-RC-PROP hoặc thể hiện lan truyền thay đổi.; Nhãn Nguồn gốc tham chiếu chưa diễn đạt quan hệ cụ thể với 00_SOURCE_MAP.md. Nêu rõ artifact này dùng để truy nguồn và đánh giá thay đổi nguồn.; Sơ đồ chưa thể hiện yêu cầu giải thích lan truyền thay đổi gắn với PACK-23-09-RC-PROP, dù đây là quan hệ riêng trong bảng và liên quan trực tiếp đến rủi ro lỗi thời. Bổ sung quan hệ hoặc cơ chế lan truyền thay đổi nếu sơ đồ nhằm bao quát Phần 9.
assets/diagrams/23-capstone-nova-foods-delivery-pack-013-cb32eded.mmd — REVISE — Sai quyền sở hữu quy trình: sơ đồ giao Logistics Team cập nhật CBR, kiểm tra TIR và thông báo thay đổi; phần Authority giao Principal IT Business Analyst ghi nhận, cập nhật truy vết và thông báo. Sửa actor theo đúng trách nhiệm đã nêu.; Thiếu Technical Lead và bước xác minh ảnh hưởng đến hệ thống, dù Decision và Authority yêu cầu xác minh hệ thống phụ thuộc. Bổ sung actor và bước xác minh trước hoặc sau cập nhật SSAPI.; Nhánh Silent Change mâu thuẫn Current Behavior: prose nói thay đổi chỉ nằm trong tài liệu nội bộ và không được ghi vào CBR; sơ đồ lại cập nhật CBR và nhận version mới. Sửa nhánh để thể hiện thay đổi không vào CBR, hoặc đổi điều kiện theo tình huống được prose hỗ trợ.; Cấu trúc luồng gây hiểu sai: luồng thành công chạy trước rồi alt Silent Change chạy như tình huống tiếp theo. Đặt luồng thành công và luồng thay đổi im lặng thành hai nhánh loại trừ nhau trong cùng alt/else.; Logistics Team->>SSAPI: Thông báo thay đổi gửi thông báo cho hệ thống thay vì đội phát triển hoặc Technical Lead. Dùng actor con người chịu trách nhiệm nhận và xử lý thông báo.; SSAPI->>SSAPI: Cập nhật code và Triển khai phiên bản mới gán hành động kỹ thuật cho API, đồng thời thiếu chủ thể phê duyệt/xác minh. Gán hành động cho đội phát triển và Technical Lead.; Triển khai phiên bản mới của SSAPI dễ bị hiểu thành version API mới, trong khi Decision chọn Option 2 chứ không chọn Option 3. Ghi rõ triển khai bản sửa đổi dịch vụ mà không thay đổi contract, hoặc bỏ chi tiết không được section xác nhận.; CBR-->>Logistics Team: Xác nhận cập nhật, version mới mô tả CBR như hệ thống tương tác và tự xác nhận, nhưng artifact chỉ được mô tả là file Markdown. Thể hiện cập nhật artifact do Principal IT Business Analyst thực hiện; không phát minh phản hồi hệ thống.; Order App->>Nova Foods dùng participant chưa khai báo và phát minh giao diện thanh toán giữa ứng dụng với doanh nghiệp. Thay bằng outcome được prose hỗ trợ, không biểu diễn message hệ thống nếu không có tương tác tương ứng.; Yêu cầu tính phí chỉ nêu Quận 1, trong khi mở đầu nói quy tắc dựa trên khu vực và trọng lượng. Bổ sung trọng lượng đầu vào nếu nó ảnh hưởng phép tính, hoặc giới hạn rõ ví dụ này là mức phí tiêu chuẩn không phụ thuộc trọng lượng.
assets/diagrams/23-capstone-nova-foods-delivery-pack-014-bb91d8cc.mmd — REVISE — Nút B dùng hình thoi nhưng không biểu diễn quyết định, điều kiện hoặc nhánh. Đổi sang nút quy trình/trạng thái, hoặc bổ sung các nhánh có điều kiện được prose hỗ trợ.; Nhãn "BA thiếu xác nhận" làm mờ chủ thể xác nhận. Prose nêu thiếu xác nhận từ Business Owner; cần ghi rõ yêu cầu chưa được Business Owner xác nhận.; Nhãn "Dev triển khai sai" thiếu cụ thể và không khớp bảng, nơi xác định Developer A. Cần nêu Developer A triển khai phí cố định 20.000 VND do yêu cầu không chỉ rõ công thức.; Nút F nêu chi phí rework và trì hoãn dự án nhưng section không cung cấp sự kiện hoặc hậu quả này. Xóa nút, hoặc bổ sung căn cứ trong prose trước khi giữ.; Chuỗi bỏ qua chênh lệch cốt lõi giữa phí cố định và nhu cầu tính theo khoảng cách, trọng lượng, loại hàng. Cần thể hiện trạng thái này để giải thích vì sao UAT thất bại.
assets/diagrams/23-capstone-nova-foods-delivery-pack-015-4d8ac001.mmd — REVISE — Nhãn "GPS/ảnh" thêm yêu cầu ảnh không có trong phần văn xuôi. Bỏ "/ảnh" ở cả ranh giới phục hồi và luồng đúng.; Cổng "Tài xế nhận hàng?" chỉ có nhánh "Có", làm thiếu kết quả khi "Không". Thêm nhánh ngoại lệ được phần văn xuôi hỗ trợ hoặc bỏ cổng quyết định nếu phạm vi không mô tả nhánh này.; Hai cạnh E_RuiRo --- F_PhucHoi và E_RuiRo -- Kích hoạt --> F_PhucHoi biểu diễn cùng quan hệ, trong đó cạnh không nhãn gây mơ hồ. Giữ một cạnh có hướng, có nhãn.; Chuỗi phục hồi F_PhucHoi -> G_QuyTrinhMoi -> H_XacNhan tách rời luồng đúng và lặp lại hai thay đổi hệ thống thay vì thể hiện ranh giới phục hồi rõ ràng. Nối thay đổi với trạng thái tương ứng trong luồng đúng hoặc bỏ chuỗi trùng lặp.; Nhãn chuyển trạng thái dùng chủ thể ngầm như "Ghi Đã giao" dù tài xế là tác nhân quan trọng. Ghi rõ "Tài xế ghi..." để trách nhiệm không mơ hồ.; Sơ đồ không thể hiện Business Owner Nova Foods là chủ thể có thẩm quyền quyết định cập nhật ERP. Bổ sung quyền phê duyệt hoặc ranh giới quyết định nếu sơ đồ tiếp tục mô tả quá trình phục hồi.; Kết quả rủi ro chỉ nêu sai tồn kho, khiếu nại và không truy vết; bỏ hậu quả trọng yếu về thanh toán hoặc hóa đơn sai. Bổ sung ít nhất hậu quả tài chính này để phản ánh nhu cầu gốc và tiêu chí quyết định.
assets/diagrams/23-capstone-nova-foods-delivery-pack-016-f113d9a3.mmd — REVISE — Nhánh “Không” tại B chuyển thẳng yêu cầu kỹ thuật/khác sang phân tích mà không kiểm tra nguồn gốc và truy vết, trái với yêu cầu chung về xác định nguồn gốc yêu cầu; cần bổ sung bước xác minh phù hợp hoặc giới hạn rõ phạm vi kiểm tra SRC-ID/BR-ID.; “Accounting” là chủ thể không được phần văn bản xác lập; cần bỏ hoặc thay bằng vai trò có thẩm quyền được dẫn nguồn trong nội dung.; ID không nhất quán: đầu vào dùng “NF-REQ-XXX”, còn trường dữ liệu dùng “REQ-NF-XXX”; cần dùng một quy ước ID.; “Yêu cầu kỹ thuật/khác?” dùng dạng câu hỏi trong nút hành động nhưng không có nhánh điều kiện; cần đổi thành trạng thái/hành động cụ thể hoặc mô hình hóa thành gateway có các nhánh.; Luồng thiếu kết quả khi không lấy được xác nhận hoặc không xác định được thẩm quyền; cần thể hiện trạng thái chặn, từ chối hoặc chờ xử lý để tránh ngụ ý mọi yêu cầu đều tiếp tục phân tích.; “Tìm Legal/Accounting/Business Owner” không nêu ai chịu trách nhiệm escalation; cần gắn chủ thể thực hiện nếu phần nội dung xác định được owner.
assets/diagrams/23-capstone-nova-foods-delivery-pack-017-be8ece66.mmd — REVISE — Nút D chỉ có nhánh “Không có thẩm quyền”, thiếu nhánh khi đã xác định đúng Decision Maker. Bổ sung đường dẫn từ D đến bước trình bày và ra quyết định.; Nhánh B “Rõ ràng, không mâu thuẫn” đi thẳng đến đề xuất rồi tiếp tục thiết kế, bỏ qua thẩm quyền và quyết định. Mọi đề xuất nghiệp vụ vẫn cần đúng người quyết định, căn cứ quyết định và ghi nhận trách nhiệm.; Điều kiện “Có xung đột/Ngoại lệ/Bằng chứng yếu” gộp ba tình huống có cách xử lý khác nhau và ngụ ý tất cả đều cần escalation. Tách hoặc đổi thành bước xử lý phù hợp: phân tích ngoại lệ, xác minh bằng chứng, điều phối xung đột; chỉ escalation khi vấn đề vượt thẩm quyền hoặc không thể dung hòa.; Nhánh vấn đề không nhắc trade-off chưa được chấp nhận dù trade-off là trọng tâm phần prose. Bổ sung trade-off hoặc rủi ro chưa được chấp nhận vào điều kiện cần quyết định.; Nút F thiếu facts, giả định, lựa chọn và hậu quả, trong khi prose yêu cầu BA trình đủ các nội dung này. Sửa nhãn để phản ánh đầy đủ gói thông tin quyết định.; Nút C “Ghi nhận yêu cầu, đề xuất giải pháp” mơ hồ về actor và outcome. Làm rõ BA ghi nhận phân tích và trình khuyến nghị; Decision Maker mới chấp thuận phương án.; Luồng không thể hiện việc ghi nhận căn cứ quyết định. Nút G cần gồm quyết định, người quyết định và căn cứ.; Ngoại lệ được dùng như điều kiện chuyển nhánh nhưng không thể hiện điều kiện kích hoạt, actor xử lý, hành động, dữ liệu tác động, outcome, bằng chứng và đường escalation như prose yêu cầu. Thêm bước hoặc tham chiếu rõ đến hồ sơ phân tích ngoại lệ.
assets/diagrams/24-capstone-review-and-evaluation-001-86cb3618.mmd — REVISE — Nhãn "Trước Capstone Review" mơ hồ: có thể chỉ giai đoạn trước review, không phải kịch bản không review như phần dẫn. Cần ghi rõ "Không có Capstone Review".; Luồng có review khẳng định các kết quả không được phần prose bảo đảm: "Yêu cầu rõ ràng", "Triển khai Go-Live thành công", "Người dùng hài lòng", "Tuân thủ được xác minh". Cần thể hiện đây là kết quả có điều kiện hoặc mức rủi ro giảm, không phải hệ quả tất định.; "Phát triển theo kế hoạch" không có căn cứ cụ thể trong phần prose và không đối xứng với "Phát triển riêng lẻ". Cần dùng trạng thái được hỗ trợ, như kiểm tra liên module trước Go-live.; Sơ đồ bỏ mất rủi ro tích hợp cốt lõi giữa mua hàng, kho và kế toán, gồm lệch dữ liệu tồn kho-kế toán và sai định dạng hóa đơn. Cần có nhánh review tích hợp và kết quả điều chỉnh tương ứng.; Nhánh tuân thủ chỉ xuất hiện sau Go-live ở kịch bản không review, nhưng prose nêu kiểm tra yêu cầu pháp lý và trường bắt buộc trước Go-live. Cần thể hiện review phát hiện hoặc xác nhận tuân thủ trước quyết định sẵn sàng.; Các nút "Phát triển riêng lẻ" và "Phát triển theo kế hoạch" dùng hình thoi dù không phải quyết định. Cần dùng nút tiến trình; giữ hình thoi cho điểm quyết định có nhánh điều kiện.; "Capstone Review" chưa có tiêu chí hoặc kết quả quyết định rõ ràng. Cần thể hiện gateway sẵn sàng/không sẵn sàng, với nhánh điều chỉnh quay lại review trước Go-live.
assets/diagrams/24-capstone-review-and-evaluation-002-c0a38871.mmd — REVISE — Gateway "Báo cáo tiến độ \"Xanh lá cây\"?" chỉ có nhánh "Có"; thêm nhánh "Không" với kết quả được phần prose hỗ trợ hoặc bỏ gateway.; Gateway "Bàn giao & Đóng dự án?" không khớp nhãn nhánh "CÓ/KHÔNG Capstone Review"; đổi gateway để hỏi trực tiếp việc thực hiện Capstone Review hoặc đổi nhãn nhánh thành câu trả lời cho gateway.; Nhánh "Đóng dự án chính thức" sau khi xác nhận giá trị mâu thuẫn với tình huống dự án đã bàn giao và đóng trước Capstone Review; thể hiện Capstone Review như đánh giá sau triển khai, không như điều kiện đóng dự án, trừ khi prose quy định lại quy trình đóng dự án.; Quy trình thiếu chủ sở hữu quan trọng: Ban Giám đốc và PMO là thẩm quyền triển khai Capstone Review; gắn trách nhiệm phê duyệt hoặc điều phối vào bước phù hợp.; Sau "Tái đánh giá hiệu quả sau cải tiến" không có điều kiện kết thúc, lặp cải tiến hoặc báo cáo kết quả; thêm gateway/kết quả được prose hỗ trợ để tránh luồng cụt.; Cụm "rework ẩn" không xuất hiện và không được chứng minh cụ thể trong prose; thay bằng hậu quả đã nêu như kiểm đếm thủ công, chi phí kiểm kê tăng, quyết định mua hàng sai hoặc mất niềm tin.
assets/diagrams/24-capstone-review-and-evaluation-003-13a7972c.mmd — REVISE — Các nút quyết định chỉ có nhánh thành công, làm sai nghĩa gateway. Bổ sung nhánh không đạt cho từng cổng, thể hiện quay lại xử lý, bổ sung bằng chứng hoặc dừng dự án.; Vai trò BA bị bỏ khỏi luồng dù phần prose xác định BA dẫn dắt, thu thập bằng chứng, tổ chức đánh giá và tổng hợp phản hồi. Thể hiện rõ BA là chủ trì quy trình.; Nhãn "Delivery - Triển khai" dễ nhầm với Release và không khớp nội dung giai đoạn thiết kế giải pháp. Đổi phần tiếng Việt sang thuật ngữ chỉ hoạt động chuyển giao hoặc phát triển giải pháp, không phải triển khai production.; Nút "Kết thúc vòng đời/Cải tiến" thêm khả năng kết thúc vòng đời không được phần prose hoặc bảng hỗ trợ. Chỉ thể hiện báo cáo sau triển khai và kế hoạch cải tiến; nếu có cải tiến, nối lại chu trình phù hợp.; Các gateway lược bỏ phần lớn tiêu chí đánh giá trọng yếu như tính khả thi, traceability, phù hợp kiến trúc, xử lý lỗi, sẵn sàng truyền thông và quản lý tác động. Bổ sung tiêu chí đủ để giải thích điều kiện qua cổng, không chỉ lặp tên đầu ra.; Nhãn "Lợi ích đạt? Bài học học được?" không song song và dùng từ lặp. Dùng tiêu chí cụ thể, song song về lợi ích kinh doanh, hiệu suất và bài học kinh nghiệm.
assets/diagrams/24-capstone-review-and-evaluation-004-73699ece.mmd — REVISE — No surrounding prose supports stated lifecycle, UAT completion event, GO/NO-GO conditions, release outcome, or return from NO-GO to Delivery; add prose support or remove unsupported elements.; Decision gateway lacks owner and explicit evaluation criteria; identify who makes decision and what conditions produce GO versus NO-GO.; "UAT Hoàn thành" is ambiguous because completion could mean execution finished or acceptance passed; use concrete state supported by prose.; NO-GO path returns only to Delivery, omitting analysis, testing, and repeat-review paths that label "Cần sửa đổi/Tái kiểm thử" implies; show supported remediation and re-entry flow.; "Capstone Review & Evaluation" breaks bilingual labeling pattern used by other nodes; apply consistent Vietnamese-English wording.
assets/diagrams/24-capstone-review-and-evaluation-005-70bb8150.mmd — REVISE — Nhánh UAT thất bại chỉ ghi “Chủ sở hữu Nghiệp vụ”, thiếu “Project Manager” theo quy trình và bảng. Bổ sung cả hai chủ thể leo thang.; Cổng kiểm thử “Test Critical/High Passed?” bỏ điều kiện “không còn lỗi tồn đọng có tác động lớn”. Sửa nhãn để thể hiện đồng thời test Critical/High đều Passed và không còn lỗi Critical/High chưa giải quyết.; Cổng chuẩn bị “Tài liệu Đủ?” bỏ tiêu chí đúng phiên bản. Sửa thành điều kiện tài liệu đầy đủ và đúng phiên bản.; Cổng cuối “Mọi phê duyệt Hoàn tất?” không thể hiện Quality Gate do Project Manager sở hữu. Bổ sung hoặc đổi cổng thành xác nhận Project Manager phê duyệt triển khai sau khi đủ chữ ký.; Nhánh thiếu phê duyệt ghi chung “Các bên Liên quan”, làm mất điều kiện leo thang tới stakeholder đang thiếu phê duyệt. Làm rõ “Stakeholder còn thiếu phê duyệt”.
assets/diagrams/24-capstone-review-and-evaluation-006-08800c39.mmd — REVISE — Nhánh E -- Có Phát hiện P1, P2? --> G đặt câu hỏi trên cạnh nhưng không có nhánh Không, sau đó G lại hỏi gần cùng nội dung. Gộp thành một gateway có hai nhánh rõ: có phát hiện quan trọng và không có phát hiện quan trọng.; Nút H[Xử lý Vấn đề & Thay đổi] là bước xử lý nhưng mang hai điều kiện đầu ra. Thêm gateway xác nhận vấn đề đã được giải quyết; chỉ chuyển sang báo cáo sau khi kết quả được kiểm tra.; Luồng từ xử lý P1/P2 sang báo cáo bỏ qua tái đánh giá hoặc xác thực thay đổi. Thêm bước xác thực yêu cầu, phát triển và kiểm thử đã hoàn tất trước khi lập báo cáo.; Nút K{Báo cáo chấp thuận?} không nêu chủ thể phê duyệt. Gắn Business Owner, Project Manager và bên có thẩm quyền phù hợp với quyết định; Lead BA chỉ điều phối khi áp dụng.; Nút L[Bàn giao Chính thức] bỏ thiếu điều kiện thành công: Business Owner, Project Manager, Lead BA và đại diện Vận hành/Hỗ trợ ký xác nhận; không còn câu hỏi mở; hồ sơ được lưu trên DMS với quyền truy cập phù hợp. Thể hiện các điều kiện này bằng quality gate trước kết thúc.; Luồng L --> M[Kết thúc] cho phép kết thúc ngay sau hành động bàn giao, dù bàn giao có thể bị từ chối hoặc còn vấn đề lớn. Thêm nhánh thất bại dẫn đến Project Manager triệu tập cuộc họp cấp cao và kết quả trì hoãn bàn giao hoặc tái cấu trúc một phần dự án.; Nút J[Leo thang: Điều chỉnh Kế hoạch] --> M_Adjust[Kết thúc (Kế hoạch Điều chỉnh)] mô tả điều chỉnh kế hoạch như trạng thái kết thúc. Prose yêu cầu xử lý, trì hoãn hoặc tái cấu trúc; luồng phải quay lại bước xử lý, xác thực hoặc bàn giao tương ứng.; Nút F[Leo thang Khẩn cấp] --> M_Error[Kết thúc (Lỗi)] tạo kết quả kết thúc lỗi không được prose hỗ trợ và làm mất quy trình giải quyết. Nối leo thang đến quyết định hoặc hành động khắc phục có chủ thể, không kết thúc mặc định.; Các nhãn Thông báo & Sửa chữa, Xử lý Vấn đề & Thay đổi, Báo cáo & Đề xuất mơ hồ về chủ thể, đầu ra và tiêu chí hoàn tất. Dùng động từ cụ thể, nêu actor nơi trách nhiệm quan trọng và gắn artifact tương ứng.; Biểu đồ không thể hiện các artifact bằng chứng quan trọng của tình huống và bàn giao, gồm issue log, change request log, SRS cập nhật, biên bản quyết định và handoff sign-off hoặc email xác nhận. Bổ sung đầu ra tại các bước liên quan.; Luồng không thể hiện nhóm Vận hành, nhóm Hỗ trợ và các bên duy trì hệ thống là bên nhận bàn giao. Bổ sung giao diện bàn giao và trách nhiệm xác nhận của các nhóm này.
assets/diagrams/24-capstone-review-and-evaluation-007-7e18e97d.mmd — REVISE — Nhánh B -- Không kết thúc tại D dù nhãn ghi "Quay lại A". Thêm liên kết D --> A để thể hiện vòng lặp.; Nhánh M -- Không kết thúc tại O dù nhãn ghi "Quay lại C". Thêm liên kết O --> C để thể hiện vòng rà soát lại.; D ghi "Cập nhật yêu cầu" khi điều kiện lỗi là gói Review chưa hoàn chỉnh. Đổi hành động thành hoàn thiện hoặc cập nhật gói tài liệu rà soát, phù hợp Bước 1.; J dùng tuyến leo thang "Product Owner/BA Senior", nhưng Bước 2 quy định "Product Owner / Trưởng phòng BA". Sửa đúng chủ thể.; C chỉ nêu BA chủ trì; Bước 2 xác định BA, Business Owner, QA Lead và Dev Lead tham gia. Thể hiện đủ diễn viên hoặc ghi rõ nhóm rà soát.; Gateway M dùng điều kiện mơ hồ "Yêu cầu sẵn sàng cho Phát triển?" và bỏ tiêu chí quyết định. Gắn điều kiện với phê duyệt nghiệp vụ, tuân thủ pháp lý, AC kiểm thử được và xử lý đầy đủ vấn đề.; Luồng QA bỏ cổng chất lượng "ít nhất 80% AC kiểm thử được và không có AC mơ hồ". Bổ sung điều kiện đạt/không đạt trước khi ban hành.; Luồng phê duyệt nghiệp vụ bỏ ngoại lệ xung đột pháp lý hoặc yêu cầu hiện có và tuyến leo thang đến Giám đốc Vận hành. Bổ sung nhánh không đạt cùng chủ thể leo thang.; N chưa thể hiện điều kiện mọi thay đổi và quyết định đã được tích hợp chính xác, trong khi đây là quy tắc ban hành ở Bước 5. Bổ sung kiểm tra trước Baseline.
assets/diagrams/24-capstone-review-and-evaluation-008-1715c295.mmd — REVISE — Nhánh “Không” tại “Kiểm tra chất lượng cần thiết?” cho phép nhập kho không qua QA, mâu thuẫn với quyết định tích hợp QA tự động và nhu cầu bảo đảm tuân thủ trước nhập kho. Loại bỏ đường bỏ qua hoặc nêu điều kiện miễn kiểm tra được phần prose hỗ trợ.; Gateway “QA hệ thống trả kết quả?” dùng nhánh “OK” và “Lỗi”, không khớp câu hỏi có/không. Đổi gateway thành trạng thái kết quả kiểm tra, với điều kiện song song và cụ thể như đạt/không đạt.; Không thể hiện trường hợp hệ thống QA không phản hồi, lỗi tích hợp hoặc hết thời gian chờ. Bổ sung nhánh ngoại lệ nếu quy trình tuyên bố sẵn sàng review; nếu chưa có quyết định xử lý, ghi rõ đây là khoảng trống cần giải quyết trước review.; Không có pool hoặc lane nên không xác định chủ thể nhận lô, gửi yêu cầu QA, nhập kho và chuyển hàng lỗi. Bổ sung ownership được nguồn nghiệp vụ xác nhận.; Mermaid graph TD là flowchart, không phải mô hình BPMN 2.0.2 và không chứng minh tuyên bố “tất cả ký hiệu BPMN chuẩn”. Dùng nguồn BPMN thực tế cho cổng chất lượng hoặc đổi mô tả để không gọi hình này là BPMN.; Luồng hàng lỗi kết thúc ngay sau “Chuyển sang khu vực hàng lỗi”, không thể hiện trạng thái kiểm soát hoặc bàn giao tiếp theo. Xác nhận đây là điểm kết thúc phạm vi có chủ đích và nêu owner; nếu không, bổ sung kết quả xử lý được prose hỗ trợ.
assets/diagrams/24-capstone-review-and-evaluation-009-ed3b80fa.mmd — REVISE — Nhánh BA tự quyết theo phạm vi chưa được phần văn xuôi xác lập; cần bổ sung căn cứ về quyền quyết định của BA hoặc bỏ nhánh này.; Các vai trò "Owner chuyên môn", "Owner/Stakeholders" và "cấp quản lý cao hơn" không có định nghĩa hoặc ranh giới thẩm quyền; cần xác định chủ thể quyết định cụ thể cho từng loại vấn đề.; Điều kiện "đa chuyên môn" mơ hồ; cần nêu tiêu chí phân biệt với vấn đề thuộc một chuyên môn.; Nhánh leo thang kết thúc tại J mà không quay lại bước ra quyết định, cập nhật artifact và thông báo; cần thể hiện kết quả sau leo thang.; Hai đường E và G hội tụ tại H nhưng H không thể hiện ai chịu trách nhiệm cuối cùng; cần dùng nhãn chủ thể cụ thể, nhất quán.; Nhãn trộn tiếng Việt và tiếng Anh như "artifact", "Owner", "Stakeholders", "Escalate" làm giảm tính nhất quán; cần Việt hóa hoặc định nghĩa thuật ngữ.; Nhánh BA tự giải quyết chỉ nêu cập nhật artifact, còn nhánh quyết định khác có thêm thông báo; cần làm rõ yêu cầu truyền thông áp dụng cho cả hai hay chỉ một nhánh.
assets/diagrams/24-capstone-review-and-evaluation-010-9cfa0331.mmd — REVISE — Nhánh rủi ro cao bị thiếu. Thêm điều kiện vi phạm pháp luật, mất dữ liệu hoặc ảnh hưởng nghiêm trọng doanh thu; thể hiện BA leo thang đến bên có thẩm quyền, nhận quyết định, rồi ghi quyết định và lý do.; Bước BA->>Stakeholders: **Câu hỏi làm rõ cụ thể?** mơ hồ và dùng Markdown có thể hiển thị không ổn trong Mermaid. Đổi nhãn thành hành động cụ thể, như đặt câu hỏi kiểm chứng giả định, tiêu chí và ngoại lệ.; Sơ đồ chỉ yêu cầu ví dụ, chưa thể hiện yêu cầu bằng chứng như Senior Lens. Thêm yêu cầu và phản hồi về bằng chứng hoặc ví dụ.; Bước Duy trì traceability không diễn đạt đúng yêu cầu ghi quyết định và lý do. Đổi thành ghi quyết định, lý do và liên kết truy vết vào artifact quản trị.; Đường dẫn 01-curriculum/TRACEABILITY_ID_REGISTRY.md thiếu / đầu so với prose. Dùng /01-curriculum/TRACEABILITY_ID_REGISTRY.md.; Bước cập nhật 01-curriculum/CANONICAL_BUSINESS_RULES.md không được section hỗ trợ và đang áp dụng vô điều kiện. Bỏ bước này, hoặc chỉ giữ nếu prose nêu rõ artifact và điều kiện cập nhật quy tắc nghiệp vụ.; Nhánh Handoff thành công lặp lại hành động chuyển giao nhưng không nêu tiêu chí thành công. Đổi kết quả thành bên liên quan xác nhận đủ rõ để thực hiện công việc.
assets/diagrams/24-capstone-review-and-evaluation-011-e21aeb77.mmd — REVISE — Nút quyết định dùng “Sản phẩm còn đủ HSD?” nhưng yêu cầu áp dụng cho lô hàng. Đổi đối tượng thành lô hàng và nêu điều kiện HSD theo quy tắc đã ghi nhận.; Bước “Kiểm tra lại lô hàng” chưa được phần văn bản xác lập như hành vi hệ thống, hành động người dùng hay quy trình xử lý ngoại lệ. Cần bổ sung căn cứ trong nội dung hoặc bỏ bước khỏi sơ đồ.; Nhánh không đạt kết thúc tại “Kiểm tra lại lô hàng” nhưng không thể hiện kết quả kiểm tra lại hoặc quay về quyết định HSD. Cần nối lại luồng đánh giá hoặc thể hiện trạng thái kết thúc cụ thể.; Sơ đồ không nêu chủ thể thực hiện yêu cầu xuất kho, kiểm tra lại lô và nhận thông báo lỗi. Cần thể hiện owner hoặc ranh giới WMS/người dùng khi trách nhiệm ảnh hưởng diễn giải luồng.; Điều kiện “đủ HSD” chưa chỉ ra quy tắc hoặc ngưỡng quyết định, tạo gateway mơ hồ. Cần liên kết nhãn với quy tắc HSD được ghi nhận trong BRD/FS.
assets/diagrams/24-capstone-review-and-evaluation-012-0eac9662.mmd — REVISE — Sơ đồ áp dụng chiết khấu chỉ theo loại khách hàng và nhóm sản phẩm, nhưng dữ liệu quy tắc còn có ngày hiệu lực 2026-09-01 và trạng thái ACTIVE. Bổ sung điều kiện kiểm tra ngày giao dịch thuộc thời gian hiệu lực và quy tắc đang hoạt động trước khi áp dụng 5%; nhánh không đạt phải dùng giá niêm yết.; Nhãn Áp dụng Chiết khấu 5% viết hoa không nhất quán. Đổi thành Áp dụng chiết khấu 5% để giữ cách diễn đạt song song với Áp dụng giá niêm yết.
assets/diagrams/24-capstone-review-and-evaluation-013-ee7097ce.mmd — REVISE — Nhánh dữ liệu nối trực tiếp từ CANONICAL_BUSINESS_RULES.md đến DATA-INV-001 nhưng bỏ qua 01-curriculum/CANONICAL_DATA_DICTIONARY.md. Bổ sung kho dữ liệu chuẩn làm nơi cập nhật DATA-INV-001 khi định nghĩa dữ liệu bị ảnh hưởng.; Nhãn "Hậu Quả Thay Đổi Thầm Lặng (Thực tế)" khẳng định sự việc đã xảy ra, trong khi phần văn chỉ mô tả rủi ro và hậu quả có thể xảy ra. Đổi "Thực tế" thành nhãn thể hiện kịch bản hoặc rủi ro.; Các chi tiết "Hệ thống ERP", "mua hàng chậm", "Nova Foods" và quan hệ với BR-WH-005 không được phần văn xác lập. Loại bỏ hoặc bổ sung căn cứ trong phần văn.; Nhánh hậu quả chỉ thể hiện tác động nghiệp vụ và QA, bỏ hẳn tác động Development gồm broken builds, production bugs, rework và missed deadlines. Bổ sung nhánh phát triển hoặc thu hẹp tuyên bố phạm vi của sơ đồ.; TRACEABILITY_ID_REGISTRY chỉ nhận liên kết từ C, D, E, F và G; quyết định thay đổi B không được ghi nhận dù phần văn yêu cầu mọi thay đổi phải được ghi nhận. Nối bản ghi thay đổi hoặc quyết định B với registry.; Nhãn "KHÔNG cập nhật" không nói rõ đối tượng bị bỏ qua dù phần văn nêu ba kho tài liệu. Ghi rõ không cập nhật quy tắc, từ điển dữ liệu nếu liên quan, và registry.
assets/diagrams/24-capstone-review-and-evaluation-014-874bc537.mmd — REVISE — Nhánh Product ID trùng lặp đi vào bước gắn cờ "Định dạng không hợp lệ". Nhãn sai nguyên nhân; cần phân biệt lỗi trùng lặp với lỗi định dạng.; Quyết định chọn tự động kiểm tra và chuẩn hóa, nhưng sơ đồ chỉ gắn cờ và kết thúc. Cần thể hiện bước chuẩn hóa hoặc xử lý ngoại lệ, kiểm tra lại, rồi ghi dữ liệu hợp lệ hoặc từ chối dữ liệu.; Ranh giới phục hồi yêu cầu ERP từ chối Product ID không hợp lệ hoặc không duy nhất; sơ đồ không nêu rõ kết quả từ chối và không cho thấy dữ liệu lỗi không được ghi vào ERP.; Luồng kết thúc ngay sau thông báo, không thể hiện trạng thái phục hồi an toàn: Product ID hợp lệ, duy nhất và được ghi thành công; hoặc bản ghi bị từ chối và giữ trong hàng đợi.; Bước cập nhật NOVA-FOODS-RISK-LOG.xlsx không được phần văn xuôi hoặc danh sách Artifact hỗ trợ. Cần bỏ bước này hoặc bổ sung căn cứ rõ ràng trong nội dung.; Nhóm BA nhận thông báo không được quy trình Quick Reference xác định; phần này chỉ yêu cầu thông báo Data Owner. Cần bỏ nhóm BA hoặc nêu rõ trách nhiệm thông báo trong văn xuôi.; Không có actor thực hiện kiểm tra, chuẩn hóa và xử lý hàng đợi. Cần xác định hệ thống tự động kiểm tra và Data Owner hoặc bên có thẩm quyền xử lý ngoại lệ.
assets/diagrams/25-ai-assisted-ba-workflow-001-f7754dca.mmd — REVISE — Các nút B, D, F, H, J, L biến Entry Gate thành quyết định Có/Không, trong khi bảng mô tả điều kiện đầu vào bắt buộc, không phải lựa chọn có dùng AI hay không. Đổi cách biểu diễn thành trạng thái đầu vào hoặc cổng kiểm soát; không cho đi tiếp khi chưa đạt cổng.; Các nhánh “Không” cho phép bỏ qua hoạt động AI-assisted BA và chuyển thẳng sang giai đoạn kế tiếp, trái với mục đích mapping hoạt động AI ở từng giai đoạn và làm mất ý nghĩa kiểm soát của Entry Gate. Thể hiện quay lại bổ sung/làm rõ đầu vào hoặc bỏ nhánh nếu prose không quy định xử lý.; Thứ tự nút sai logic cổng vào: sơ đồ đặt giai đoạn trước Entry Gate, ví dụ Khám phá --> Yêu cầu cấp cao, trong khi yêu cầu cấp cao là đầu vào của Khám phá. Đặt Entry Gate trước hoạt động tương ứng.; Sơ đồ bỏ toàn bộ Exit Gate và outcome cụ thể như yêu cầu thô, User Stories, mô hình dữ liệu, tài liệu thiết kế, test plan, user guide và báo cáo vận hành. Bổ sung đầu ra trước khi chuyển giai đoạn.; Các nhãn AI-assisted BA (Discovery) và tương tự quá chung, không cho biết hoạt động được bảng mô tả. Dùng nhãn hành động cụ thể, song song, như phân tích tài liệu, chuyển yêu cầu thành User Story, gợi ý test case hoặc tổng hợp phản hồi.; Sơ đồ bỏ Owner của từng giai đoạn, gồm BA, Technical Lead / Solution Architect, QA Analyst và Product Owner / Support Lead. Bổ sung swimlane, subgraph hoặc nhãn trách nhiệm để không làm mờ ranh giới sở hữu.; Vòng AI_BA_O --> A khẳng định mọi đầu ra vận hành quay thẳng về Khám phá. Prose chỉ nói đề xuất cải tiến cho các vòng lặp sau, không xác định luôn quay về Discovery. Gắn điều kiện cụ thể hoặc biểu diễn feedback loop không khóa vào một giai đoạn duy nhất.; Các điều kiện “Có/Không” mơ hồ vì không nêu tiêu chí đạt, người phê duyệt hoặc hậu quả khi không đạt. Dùng trạng thái cụ thể như “đã baseline”, “đã phê duyệt”, “Release Candidate sẵn sàng”, kèm đường xử lý thiếu điều kiện.
assets/diagrams/25-ai-assisted-ba-workflow-002-821b074d.mmd — REVISE — Luồng kết thúc tại "Kết thúc / Cải tiến" nhưng không nối cải tiến về Khám phá hoặc Phân tích. Cách thể hiện mâu thuẫn với tên "chu trình" và nội dung Vận hành có "Lập kế hoạch cải tiến"; cần thể hiện vòng phản hồi hoặc đổi nhãn thành kết thúc tuyến tính.; Nhãn "AI: Thu thập dữ liệu" gán cho AI hoạt động rộng hơn bảng, vốn chỉ nêu phân tích tài liệu, tóm tắt và tìm kiếm thông tin. Cần dùng phạm vi hỗ trợ đúng với bảng, tránh ngụ ý AI tự thu thập dữ liệu.; Các cạnh "BA ..." dẫn từ giai đoạn sang nút AI khiến AI trông như bước kế tiếp thay vì công cụ hỗ trợ BA trong từng giai đoạn. Cần làm rõ quan hệ hỗ trợ, không mô tả bàn giao công việc từ BA sang AI.; Nhãn chưa song song và chưa thống nhất thuật ngữ: "ACs", "Acceptance Criteria", "Log", "Feedback" cùng xuất hiện. Cần chọn thuật ngữ nhất quán với bảng và giáo trình.; Nút Kiểm thử bỏ hỗ trợ về ca kiểm thử biên và rà soát độ phủ, trong khi đây là nội dung cụ thể của bảng. Cần bổ sung hoặc dùng nhãn khái quát bao quát đủ các hỗ trợ kiểm thử.
assets/diagrams/25-ai-assisted-ba-workflow-003-55d43563.mmd — REVISE — Thiếu end cho subgraph Metadata & Định Danh (Canonical IDs); thêm end sau H[CANONICAL_DATA_DICTIONARY] để Mermaid hợp lệ và ranh giới nhóm rõ ràng.; Tên nhóm Metadata & Định Danh (Canonical IDs) không khớp nội dung: CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là kho nội dung chuẩn, không chỉ ID; đổi tên nhóm hoặc tách kho ID khỏi artifact chuẩn.; Các quan hệ Tham chiếu, Gắn kết, Xác nhận, Định nghĩa mơ hồ và thiếu song song; dùng nhãn cụ thể, nhất quán để nêu artifact nào được đăng ký, truy vết, chuẩn hóa hoặc dùng làm bằng chứng.; Luồng chỉ thể hiện một số liên kết tùy ý, nhưng không giải thích vì sao biên bản họp liên kết quy tắc còn luật không liên kết quy tắc, hoặc vì sao đặc tả API không liên kết từ điển dữ liệu; bổ sung quan hệ được phần prose xác nhận hoặc nêu rõ đây chỉ là ví dụ.; Phần prose cung cấp không xác nhận chủ thể chịu trách nhiệm, tiêu chí chuẩn hóa, ngoại lệ hoặc kết quả của các liên kết; bổ sung giải thích quanh sơ đồ hoặc loại bỏ các khẳng định quy trình không được hỗ trợ.
assets/diagrams/25-ai-assisted-ba-workflow-004-a8a48980.mmd — REVISE — Các kết quả "Từ chối" không được phần mô tả hỗ trợ; portal chỉ được nêu là áp dụng validation khi nhập. Cần thể hiện chặn gửi hoặc yêu cầu bổ sung nếu đó là hành vi dự kiến, hoặc bổ sung căn cứ trong prose.; Nhãn "BPCR hoàn chỉnh?" mơ hồ. Cần gắn với thông tin bắt buộc hoặc quy tắc cụ thể trong /06-qa/NF-INPUT-VALIDATION-RULES.xlsx.; Điều kiện "Thông tin nhất quán với nguồn chuẩn Nova Foods?" đưa thêm phụ thuộc chưa được định nghĩa trong section. Cần xác định nguồn chuẩn và cách đối chiếu trong prose, hoặc bỏ bước này.; Hai bước "BPCR hoàn chỉnh?" và "BPCR theo đúng định dạng?" có nguy cơ trùng với validation có cấu trúc của portal. Cần phân biệt rõ kiểm tra trường bắt buộc với kiểm tra định dạng dữ liệu.; Sơ đồ thiếu điểm tương tác với portal và xác thực qua hệ thống đăng nhập tập trung, dù đây là cơ chế chính của quyết định. Cần thể hiện ranh giới hoặc bước này để tránh ngụ ý BA tự xác thực nguồn.; Nhãn "chuyển BA/AI" gộp hai đích có vai trò khác nhau và không xác định thứ tự. Prose nói kiểm tra trước khi đưa vào phân tích AI; cần chỉ rõ chuyển cho BA, AI, hoặc BA dùng AI theo workflow đã mô tả.
assets/diagrams/25-ai-assisted-ba-workflow-005-613c5d6c.mmd — REVISE — Cổng bước 1 chỉ kiểm tra mục tiêu và độ đầy đủ tài liệu; thiếu tính nhất quán, tuân thủ chính sách AI và rủi ro bảo mật. Bổ sung đủ điều kiện hoặc thể hiện nhánh leo thang tương ứng.; Cổng bước 2 dùng điều kiện yếu «Bản nháp AI tạo ra?», trong khi prose yêu cầu đầu ra liên quan, đúng định dạng và dùng được làm bản nháp. Đổi điều kiện để phản ánh cổng chất lượng này.; Nhánh lỗi bước 2 chỉ ghi «Technical Support»; prose quy định «Technical Support / AI Tool Administrator». Bổ sung AI Tool Administrator.; Cổng bước 3 «Bản nháp BA chính xác nghiệp vụ?» bỏ tiêu chí độ chính xác từ 90% trở lên, không mâu thuẫn nguồn và không có lỗi ngữ pháp hoặc logic cơ bản. Ghi điều kiện cụ thể.; Nhánh «Không» tại bước 3 luôn leo thang Lead BA, trái prose: chỉ leo thang khi AI liên tục tạo sai lệch nghiêm trọng và không thể sửa hiệu quả. Thể hiện vòng hiệu chỉnh cho lỗi có thể sửa và chỉ leo thang khi đạt điều kiện ngoại lệ.; Cổng bước 4 chỉ hỏi Business Owner phê duyệt; prose còn yêu cầu SME xác minh, mọi bên liên quan đồng ý và không còn yêu cầu quan trọng chưa giải quyết. Bổ sung các điều kiện này mà không biến SME thành chủ thể phê duyệt nếu prose không quy định.; Các nút leo thang đều là điểm cụt, không cho biết kết quả sau xử lý: quay lại bước nào, dừng quy trình hay thay đổi phạm vi/công cụ. Bổ sung trạng thái hoặc luồng tiếp theo được prose hỗ trợ; nếu prose chưa xác định, ghi rõ quy trình tạm dừng chờ giải quyết thay vì ngầm kết thúc.; Nhãn trộn Việt–Anh như «Escalate», «Technical Support», «Dev/QA» làm giảm tính song song và cụ thể. Dùng thuật ngữ song ngữ nhất quán với prose, đồng thời nêu rõ chủ thể nhận leo thang.
assets/diagrams/25-ai-assisted-ba-workflow-006-c8d597ad.mmd — REVISE — Bước 5 «Xác nhận & Tinh chỉnh Yêu cầu» và bước 6 «Bàn giao Tài liệu Yêu cầu Chuẩn» không được mô tả trong phần văn bản cung cấp; xóa chúng hoặc bổ sung nội dung nguồn trước khi đưa vào biểu đồ.; Các nhãn giai đoạn «Giai đoạn chuẩn bị dữ liệu», «Giai đoạn Khai thác & Phân tích» và «Giai đoạn Kiểm tra & Tinh chỉnh» không được xác lập trong bảng; chỉ dùng khi phần văn bản định nghĩa cách phân nhóm này.; Luồng tuyến tính bỏ qua cổng chất lượng và lộ trình leo thang của từng bước, khiến bước sau có vẻ luôn bắt đầu dù chưa được PM, Product Owner, Security Expert, BA hoặc SME xác nhận; thêm gateway và nhánh leo thang được bảng hỗ trợ.; Biểu đồ không thể hiện ranh giới trách nhiệm giữa BA, công cụ AI, Data Specialist, PM, Product Owner, Security Expert, SME và các bên xử lý leo thang; thêm swimlane hoặc nhãn chủ thể nếu biểu đồ nhằm giải thích quy trình vận hành.; Quan hệ phụ thuộc giữa đầu ra và đầu vào chưa cụ thể: corpus đã chuẩn hóa phải cấp cho bước 3, còn danh sách yêu cầu thô và báo cáo mâu thuẫn phải cấp cho bước 4; ghi rõ artifact trên các luồng.; Nhãn «Kết thúc Quy trình» khẳng định một kết quả không được phần văn bản hỗ trợ, vì nội dung được cung cấp dừng tại bước 4; xóa hoặc liên kết với bước kết thúc đã được mô tả.; Biểu đồ hiện chủ yếu lặp lại số thứ tự và tên hoạt động, không biểu diễn quy tắc quyết định, bằng chứng, rủi ro AI hoặc ngoại lệ; bổ sung logic kiểm soát được bảng mô tả để tạo giá trị giải thích.
assets/diagrams/25-ai-assisted-ba-workflow-007-e25d9628.mmd — REVISE — Nút J là hoạt động “BA Trình Phê duyệt & Bàn giao” nhưng đồng thời có nhánh “No” và được tô kiểu cổng quyết định. Thêm cổng riêng sau J với điều kiện “Business Owner phê duyệt chính thức?”; nhánh Có tới kết thúc, nhánh Không tới Giám đốc dự án rồi quay lại bước 5.; Cổng bước 3 dùng “Yêu cầu thô Hợp lý?” quá mơ hồ, không phản ánh quy tắc yêu cầu phải có căn cứ từ tài liệu gốc và cổng kiểm tra chéo 10–20%. Đổi nhãn thành điều kiện cụ thể về truy vết nguồn và kết quả kiểm tra chéo.; Các cổng bước 1–4 bỏ chủ thể kiểm soát chất lượng: Trưởng nhóm BA ở bước 1–3, SME ở bước 4. Gắn đúng chủ thể review vào cổng hoặc nhãn luồng để giữ rõ quyền sở hữu quyết định.; Đầu ra bước 5 thiếu Ma trận truy vết dù bảng quy định đây là đối tượng bàn giao và Artifact chính. Bổ sung Traceability Matrix vào nhãn đầu ra bước 5.; “FRL Phê duyệt” xuất hiện trên luồng trước khi cổng phê duyệt được thể hiện rõ, làm trạng thái đầu ra sai thứ tự. Chỉ ghi FRL đã phê duyệt sau kết quả Có của cổng phê duyệt.; Nhãn nhánh “Yes/No”, “Object”, “Escalation” trộn tiếng Anh với nội dung tiếng Việt. Dùng “Có/Không”, “Đối tượng”, “Leo thang” nhất quán; giữ thuật ngữ chuẩn như FRL, SME khi cần.
assets/diagrams/25-ai-assisted-ba-workflow-008-3715e5c8.puml — REVISE — Sơ đồ dùng ký pháp sequence diagram nhưng Artifact ID, tên tệp và tiêu đề gắn nhãn BPMN; cần đổi nhãn thành sequence diagram hoặc dùng đúng ký pháp BPMN.; Thông điệp "Gửi email xác nhận đến Khách hàng" đi từ ERP đến Sales, mâu thuẫn với người nhận ghi trong nhãn; cần thêm Khách hàng hoặc dịch vụ email làm participant và nối thông điệp đến đúng bên nhận.; Điều kiện "nếu có email" bị giấu trong nhãn thông điệp; cần thể hiện thành nhánh điều kiện rõ ràng để phân biệt trường hợp có và không có email.; Bước lưu vào Cơ sở dữ liệu được biểu diễn bằng self-message của ERP, làm mờ ranh giới hệ thống và phụ thuộc dữ liệu; cần thêm participant Cơ sở dữ liệu hoặc ghi rõ đây là xử lý nội bộ nếu phạm vi không mô hình hóa DB.; Các chi tiết tự động sinh Mã Khách hàng, gửi email và ví dụ lỗi MST chưa được phần mô tả hoặc tham chiếu trích dẫn xác nhận trực tiếp; cần đối chiếu với NF-US-SALES-001 và NF-BR-LEGAL-005 hoặc loại bỏ chi tiết không có nguồn.
assets/diagrams/25-ai-assisted-ba-workflow-009-d1c61a19.mmd — REVISE — Nút D dùng hình thoi nhưng mô tả hành động, không phải gateway. Đổi sang nút xử lý và ghi rõ chủ thể: "NF_LegacyPO gửi email kèm PDF".; Sơ đồ bỏ phụ thuộc quy tắc BR_NF_PO_001 tại bước gửi phê duyệt. Bổ sung quy tắc này vào nhãn bước hoặc quan hệ phụ thuộc.; Kết quả "Approved" và "Rejected" bị gộp thành "PO có trạng thái mới", che mất hai nhánh điều kiện và trạng thái đầu ra khác nhau. Tách hai nhánh cùng trạng thái tương ứng.; Nút B và F dùng hình thoi dù không biểu diễn quyết định. Dùng hình chữ nhật cho hành động hoặc sự kiện.; Nhãn "Người phê duyệt" chỉ là tác nhân, không thể hiện hành động xem PDF trước khi trả lời. Ghi rõ "Người phê duyệt xem PDF".; Sơ đồ không thể hiện email trả lời là bằng chứng duy nhất và việc cập nhật thủ công gây thiếu audit trail, sai trạng thái, chậm trễ và thiếu kiểm soát. Bổ sung chú thích rủi ro tại các điểm liên quan nếu sơ đồ nhằm giải thích vấn đề của quy trình hiện tại.
assets/diagrams/25-ai-assisted-ba-workflow-010-a4ef7844.mmd — REVISE — Sơ đồ chưa thể hiện BR_INV_005: điều kiện mặt hàng thuộc nhóm Thực phẩm dễ hỏng phải có số lô hợp lệ tại thời điểm nhập kho. Bổ sung ràng buộc hoặc chú thích cụ thể về nhóm áp dụng, tiêu chí số lô hợp lệ và thời điểm kiểm tra.; Quan hệ INV_ITEM ||--o{ INV_LOT cho phép mặt hàng dễ hỏng không có lô, trái quy tắc bắt buộc khi nhập kho. Thể hiện tính bắt buộc có điều kiện hoặc ghi rõ giới hạn của ERD.; is_perishable và item_category tạo hai nguồn xác định phạm vi quy tắc nhưng không nêu quan hệ giữa chúng. Chọn một nguồn chuẩn hoặc mô tả điều kiện nhất quán với nhóm Thực phẩm dễ hỏng.; PROD_ORDER_MATERIAL chứa cả item_id và lot_id nhưng không bảo đảm lot_id thuộc đúng item_id. Dùng khóa ngoại ghép hoặc bỏ item_id dư thừa để ngăn liên kết sai lô.; PROD_ORDER_MATERIAL không có khóa chính hoặc ràng buộc duy nhất, nên không xác định được bản ghi tiêu thụ và có thể tạo dòng trùng. Bổ sung định danh hoặc khóa ghép phù hợp.; Nhãn quan hệ INV_ITEM–PROD_ORDER là "sản xuất" khiến INV_ITEM có vẻ là chủ thể sản xuất. Đổi sang nhãn cụ thể như "là thành phẩm của" hoặc "tạo thành phẩm" theo đúng chiều đọc.; Các thuộc tính quantity, expiry_date, prod_date và consumed_quantity vượt quá thông tin được nêu trực tiếp trong đoạn văn. Xác nhận chúng thuộc FSD hoặc loại khỏi sơ đồ nếu không có nguồn hỗ trợ.
assets/diagrams/25-ai-assisted-ba-workflow-011-0cfe9254.mmd — REVISE — Nút E thiếu nhánh “Không” dẫn đến kết quả phân bổ đủ; luồng hiện tại không có đường kết thúc khi số lượng cần phân bổ về 0.; Vòng lặp J → E không cập nhật hoặc loại lô đã dùng; bước F có thể chọn lại lô đã hết. Thêm bước cập nhật tồn lô hoặc chuyển sang lô kế tiếp.; Thiếu nhánh xử lý khi đã duyệt hết lô nhưng vẫn còn số lượng cần phân bổ; thêm điều kiện kiểm tra còn lô và kết quả “Không đủ nguyên liệu”.; Điều kiện B “Có nguyên liệu yêu cầu?” mơ hồ và không tương ứng chắc chắn với kết quả “Không đủ nguyên liệu”; đổi thành điều kiện cụ thể về tồn tại lô khả dụng hoặc bỏ nút nếu kiểm tra này trùng với truy vấn tồn kho.; Nhãn “Phân bổ đủ từ lô” không nêu rõ đủ số lượng còn thiếu; sửa thành “Phân bổ đủ số lượng còn thiếu từ lô hiện tại” để phân biệt với việc dùng hết lô.
assets/diagrams/25-ai-assisted-ba-workflow-012-b0a73c82.mmd — REVISE — Các bước NF-REQ-SYS-TAX-001, thiết kế ERP, VAT_Calculator.py, NF-TC-TAX-005 và báo cáo/hóa đơn không được bảng hoặc phần văn xuôi xác nhận; cần bổ sung nguồn hỗ trợ trong nội dung hoặc loại khỏi sơ đồ.; Các cạnh B --> D, D --> E, E --> F, F --> G lặp quan hệ đã có trong chuỗi nội bộ, tạo hai đường lan truyền giống nhau; cần giữ một đường duy nhất với nhãn quan hệ rõ.; Cạnh G --> H ngụ ý test case tạo hoặc dẫn tới báo cáo/hóa đơn, trong khi F -- "Tạo ra" --> H gán kết quả này cho code; cần sửa quan hệ và xác định đúng nguồn tạo đầu ra.; Nhãn Dựa trên, Thực hiện bởi, Triển khai trong không mô tả nhất quán chiều dependency; cần dùng nhãn cụ thể, song song và đúng chủ thể.; Sơ đồ không thể hiện tác động/rủi ro khi thay đổi VAT như tính sai thuế hoặc vi phạm pháp luật, dù đây là thông tin cốt lõi của bảng; cần thể hiện outcome hoặc phạm vi tác động.; Ranh giới Regulatory Body chứa văn bản pháp luật thay vì cơ quan quản lý, làm lẫn actor với artifact; cần đổi tên ranh giới hoặc thêm actor được nội dung xác nhận.
assets/diagrams/25-ai-assisted-ba-workflow-013-ba36d9bf.mmd — REVISE — Các nút A, B và C không có liên kết A --> B --> C, nên sơ đồ không thể hiện luồng từ đầu vào cũ/thiếu đến bản nháp AI và bước đánh giá. Bổ sung các cạnh theo đúng trình tự.; Gateway "BA chỉ chỉnh sửa bề mặt?" không hỗ trợ nhánh "KHÔNG (Xác minh với Business User)": không chỉnh sửa bề mặt không đồng nghĩa đã xác minh. Cần thể hiện bước xác minh nghiệp vụ riêng hoặc đổi điều kiện gateway thành câu hỏi trực tiếp về xác minh.; Nhãn "Requirement CHÍNH XÁC" khẳng định độ chính xác tuyệt đối, trong khi phần văn bản chỉ yêu cầu xác minh và phê duyệt. Cần dùng trạng thái cụ thể, có thể kiểm chứng như đã xác minh và được phê duyệt.; Chuỗi "Requirement được phê duyệt" đến "Triển khai thành công, hiệu quả" thể hiện quan hệ tất định không được phần văn bản hỗ trợ. Cần tránh ngụ ý xác minh yêu cầu tự động bảo đảm thành công triển khai.; Các kết quả "Hệ thống ERP triển khai không hiệu quả" và "Thiệt hại tài chính" không được phần Quick Reference cung cấp trực tiếp. Cần bỏ hoặc bảo đảm phần văn bản xung quanh nêu rõ các kết quả này.; Sơ đồ chỉ thể hiện xác minh với Business User, bỏ qua chuyên gia nghiệp vụ và đối chiếu nguồn đáng tin cậy được nêu trong bảng. Cần phản ánh đủ phạm vi kiểm chứng nếu sơ đồ đại diện cho quy trình lạm dụng AI nói chung.
assets/diagrams/tmpl-ops-002-operations-runbook-001-6515ff73.mmd — REVISE — Gateway Tổng khả dụng đủ 240 chai? thiếu nhánh Không; thêm kết quả xử lý thiếu tồn hoặc phân bổ nhiều lô, phù hợp DR-WH-03 và TD-WH-004.; Điều kiện gateway dùng Tổng khả dụng nhưng nhánh Có phân bổ toàn bộ từ một lô; đổi thành điều kiện một lô FEFO đủ 240 chai hoặc thể hiện bước cộng và phân bổ nhiều lô.; Actor Nhân viên kho nhập yêu cầu và Thủ kho xác nhận lấy hàng không được phần văn bản, bảng hay payload xác lập; bỏ actor hoặc bổ sung căn cứ ngoài sơ đồ.; Bước ERP giảm tồn khả dụng và tăng tồn đã phân bổ đặt sau khi tạo phiếu nhưng payload được mô tả là đầu vào cho thao tác phân bổ; cần làm rõ ranh giới giữa tạo phiếu, giữ tồn và phân bổ để tránh trình tự trạng thái mơ hồ.; Bước ERP ghi nhận xuất kho 240 chai thiếu trạng thái kết thúc và hậu quả tồn kho sau xuất; phân biệt tồn khả dụng, tồn đã phân bổ và tồn vật lý theo nội dung được xác nhận.
assets/diagrams/tmpl-ops-003-support-readiness-001-8c6d7d59.mmd — REVISE — Nút “ERP tra cứu đơn, tồn kho và nhật ký đồng bộ” gán hành động cho hệ thống thay vì chủ thể thực hiện; cần xác định Tier 1 tra cứu trên ERP hoặc mô tả rõ tra cứu tự động nếu phần văn bản có căn cứ.; Tra cứu “tồn kho và nhật ký đồng bộ” không có bằng chứng tương ứng trong bảng hoặc payload; cần bỏ khỏi sơ đồ hoặc bổ sung nội dung hỗ trợ trong phần văn bản.; Nút “Tier 2 phân tích nguyên nhân kỹ thuật” vượt quá kết quả được mô tả là tái tạo và phân loại vấn đề; cần giới hạn kết quả theo nội dung này, không ngụ ý đã phân tích nguyên nhân kỹ thuật.; Luồng bỏ qua bước Tier 1 kiểm tra và ghi nhận các trường bằng chứng trước khi đính kèm; cần thể hiện bước thu thập hoặc xác minh dữ liệu nếu muốn mô tả đúng quy trình tạo gói bằng chứng.
assets/diagrams/diagram-cheatsheets-001-8b79a421.puml — REVISE — Mã trộn cú pháp biểu đồ tuần tự (participant, thông điệp giữa participant, Sales is) với cú pháp biểu đồ hoạt động (start, if, stop, end), nên không thể hiện BPMN hoặc swimlane chuẩn và có nguy cơ không biên dịch đúng. Chọn cú pháp PlantUML activity với swimlane/partition nhất quán hoặc công cụ hỗ trợ BPMN; giữ nguyên nội dung nghiệp vụ.; Biểu đồ gọi các participant nhưng không gán rõ từng tác vụ vào pool/lane BPMN. Thể hiện mỗi tác vụ trong lane của Khách hàng, Bán hàng, Kho hoặc Kế toán để làm rõ chủ sở hữu.; Sự kiện bắt đầu SO-REQ-001 không khớp bảng ánh xạ EVT-START-001; sự kiện kết thúc cũng thiếu EVT-END-001. Đồng bộ ID giữa biểu đồ và bảng.; Gateway Tồn kho đủ? thiếu ID GW-WH-001. Thêm ID và đồng bộ điều kiện với quality gate; bảng dùng Tồn kho thực > số lượng yêu cầu, còn khái niệm đủ hàng thường cần >=.; Thông điệp Khách hàng gửi đơn dùng SO-REQ-001, trong khi bảng ánh xạ dùng MSG-SO-001. Đồng bộ ID hoặc phân biệt rõ đối tượng yêu cầu và message flow.; Nhánh Thanh toán thành công? = Không đi qua Theo dõi Công nợ rồi nhập vào cùng end, khiến đơn thất bại thanh toán trông như hoàn tất. Thêm kết quả kết thúc riêng hoặc vòng xử lý rõ ràng; chỉ nhánh đã giao và đã thanh toán được nối với EVT-END-001.; Nhánh hết hàng dùng tác vụ gộp Thông báo KH / Hủy ĐH, làm mơ hồ hành động, quyết định và chủ thể phê duyệt hủy. Tách thông báo khỏi hủy hoặc ghi rõ điều kiện hủy và kết quả kết thúc.; Luồng bắt đầu vừa có activity Đơn hàng Khách hàng đặt vừa có message Gửi Đơn hàng mới, tạo hai biểu diễn gần trùng nhau nhưng không làm rõ event, task và message. Phân biệt rõ sự kiện phát sinh đơn với thông điệp chuyển đơn.; Các màu luồng đỏ, xanh lá, xanh dương, tím không có chú giải và xung đột với skinparam monochrome true. Bỏ màu hoặc thêm quy ước có ý nghĩa nghiệp vụ.; Tham chiếu Nghị định 123/2020/NĐ-CP đặt tại bước xác nhận đơn hàng, còn nội dung liên quan hóa đơn phù hợp hơn với bước lập hóa đơn. Chuyển tham chiếu tới tác vụ liên quan hoặc giải thích quan hệ.; Nhãn ĐH, KH, REQ-INV và INV mang nghĩa không nhất quán: INV được dùng cho tồn kho lẫn hóa đơn. Dùng nhãn đầy đủ và ID không nhập nhằng.
assets/diagrams/lifecycle-artifact-map-001-8f08a118.puml — REVISE — Nhánh phê duyệt mâu thuẫn bảng ánh xạ: sơ đồ chỉ có Quản lý Mua hàng phê duyệt, trong khi NF-QG-002 yêu cầu hai cấp cho đề xuất trên 50.000.000 VND, gồm Quản lý Mua hàng và Kế toán trưởng. Bổ sung điều kiện ngưỡng giá trị, Kế toán trưởng và kết quả từng cấp phê duyệt.; Vòng chỉnh sửa đề xuất dùng -> Bộ phận Mua hàng tạo Đề xuất Mua hàng; nhưng không biểu diễn rõ việc quay lại hoạt động tạo đề xuất rồi tái phê duyệt. Dùng cấu trúc vòng lặp PlantUML rõ ràng để nối lại bước tạo/chỉnh sửa và cổng NF-QG-002.; Điều kiện tồn kho không khớp đầy đủ với NF-BR-005: sơ đồ hỏi tồn kho hiện tại có đủ cho kế hoạch, còn bảng dùng tồn kho thực tế cộng số lượng đang đặt so với ngưỡng tối thiểu. Sửa nhãn kiểm tra và gateway để nêu đúng dữ liệu đầu vào cùng tiêu chí của quy tắc.; Luồng NF-QG-003 ghi nhận PO vào ERP trước khi xác nhận dữ liệu hợp lệ, rồi thêm một hoạt động cổng chất lượng và một gateway gần như trùng nhau. Thể hiện một gateway duy nhất tại thời điểm nhập ERP, với điều kiện gồm kiểm tra NF-BR-012, ràng buộc dữ liệu và kết quả ghi nhận.; Nhánh lỗi NF-QG-003 dừng sau thông báo, không nêu trạng thái PO hay quyền sở hữu xử lý tiếp theo. Bổ sung kết quả cụ thể như PO không được ghi nhận và chuyển Bộ phận Mua hàng sửa dữ liệu hoặc hủy xử lý.; Hiện vật DD-PO-ITEM-QUANTITY trong bảng không được ánh xạ vào bước hoặc kiểm tra nào trên sơ đồ. Gắn định danh này với kiểm tra dữ liệu PO tại NF-QG-003, hoặc bỏ tuyên bố rằng mọi hiện vật trong bảng đều liên kết với luồng.; Nhãn NCC kém cụ thể hơn thuật ngữ dùng trong bảng. Đổi thành Nhà cung cấp để tránh phụ thuộc vào chữ viết tắt.