Ghi chú minh bạch quan trọng: Phiên làm việc này không nhận được các file nguồn được nhắc tới trong brief (Project Master V12–V15, file Markdown gốc, các bộ khung governance/knowledge/ecosystem riêng lẻ...). Người phụ trách dự án đã xác nhận: "Tự bạn phát triển" — tức là toàn bộ nội dung dưới đây được Claude xây dựng từ đầu, dựa trên (1) bối cảnh đã lưu về OriginVN (mô hình GHI NHẬN → XÁC MINH → QUẢN LÝ → TRUY XUẤT, các vai trò trong hệ sinh thái), (2) chính cấu trúc/yêu cầu chi tiết mà người dùng đưa ra trong prompt này, và (3) kiến trúc nghiệp vụ chuẩn cho một nền tảng traceability nông nghiệp. Do đó gần như toàn bộ nội dung mang nhãn SUY LUẬN KIẾN TRÚC hoặc ĐỀ XUẤT, không phải THEO TÀI LIỆU NGUỒN — vì không có tài liệu nguồn nào tồn tại trong phiên này để tham chiếu. Các mục có mâu thuẫn số liệu mẫu (45 ngày / 6–7 tháng...) nêu trong brief gốc không xuất hiện vì không có tài liệu thật để đối chiếu; thay vào đó, mọi con số/thời lượng trong tài liệu này đều được đánh dấu CẦN CHỐT vì chưa có baseline thật để dựa vào. Khi có các file nguồn thật (V12–V15, v.v.), tài liệu này cần được chạy lại quy trình hợp nhất — Phần X (Traceability Matrix) đã để sẵn khung cho việc đó.
Executive Overview — OriginVN là gì?
SUY LUẬN KIẾN TRÚC DỰA TRÊN BỐI CẢNH ĐÃ LƯUBản chất
OriginVN (tên thương hiệu thay thế: Origin Trace VN) là một nền tảng dữ liệu và vận hành nông nghiệp xuyên suốt — không phải một ứng dụng nhật ký nông nghiệp đơn lẻ. Nền tảng số hoá toàn bộ chuỗi từ vùng trồng đến tay người mua, theo mô hình lõi:
Mô hình 4 bước này là nội dung THEO NGƯỜI DÙNG NÊU trong bối cảnh dự án đã lưu trước đó.
Vấn đề cần giải quyết
Với HTX / Nông dân
Thiếu công cụ ghi nhận canh tác có cấu trúc; khó chứng minh nguồn gốc, khó tiếp cận tài chính vì không có hồ sơ sản xuất đáng tin cậy.
Với Doanh nghiệp / Buyer
Khó xác thực nguồn gốc và chất lượng trước khi mua; rủi ro chuỗi cung ứng không minh bạch, không truy vết được khi có sự cố.
Với Nhà nước / Tổ chức tài trợ
Thiếu dữ liệu vùng trồng tổng hợp, đáng tin cậy để hoạch định chính sách, cấp tín dụng nông nghiệp, hoặc xác nhận tiêu chuẩn ESG/Carbon.
Người dùng
Nông dân/thành viên HTX, người lao động thời vụ, kỹ sư nông nghiệp (xác minh), quản lý HTX, thủ kho, kế toán, quản lý chất lượng, quản lý Farm, lãnh đạo HTX/doanh nghiệp, buyer/doanh nghiệp thu mua, ngân hàng, bảo hiểm, đơn vị chứng nhận, quản trị hệ thống, quản trị tri thức, và AI như một "tác nhân" tạo khuyến nghị. Danh sách vai trò THEO NGƯỜI DÙNG NÊU, chi tiết quyền tại Phần I.
Giá trị cốt lõi
| Đối tượng | Giá trị mang lại |
|---|---|
| HTX / Nông dân | Hồ sơ sản xuất số hoá → cơ sở vay vốn, bán giá tốt hơn nhờ truy xuất; giảm công sức ghi chép thủ công |
| Kỹ sư nông nghiệp | Công cụ xác minh từ xa + tại chỗ, giảm thời gian đi thực địa nhờ bằng chứng số |
| Doanh nghiệp/Buyer | Truy xuất minh bạch tới tận lô/mùa vụ, giảm rủi ro chuỗi cung ứng, hỗ trợ tiêu chuẩn xuất khẩu |
| Ngân hàng/Bảo hiểm | Dữ liệu sản xuất thực tế thay thế hồ sơ giấy — cơ sở thẩm định tín dụng/bảo hiểm nông nghiệp |
| Nhà nước/Đối tác ESG | Dữ liệu vùng trồng tổng hợp phục vụ chính sách, xác nhận carbon credit |
Phạm vi
ĐỀ XUẤT Phạm vi tài liệu này bao trùm 4 giai đoạn sản phẩm (GĐ1–GĐ4, xem Phần K), từ hệ thống kiểm soát canh tác lõi đến nền tảng hệ sinh thái đầy đủ (marketplace, carbon, tài chính chuỗi cung ứng, open API). Tài liệu phục vụ đồng thời Chủ dự án, Product/Business, và toàn bộ đội kỹ thuật (Backend, Frontend, Mobile, QA, Data, AI, DevOps) cũng như đối tác triển khai.
Tầm nhìn
ĐỀ XUẤT
Trở thành lớp hạ tầng dữ liệu tin cậy cho nông nghiệp Việt Nam — nơi mọi vùng trồng, mùa vụ, lô hàng đều có "hộ chiếu dữ liệu" xuyên suốt từ đất tới bàn ăn, làm nền cho tín dụng nông nghiệp, thương mại nông sản, và các cam kết ESG/carbon có thể kiểm chứng được.
3 trụ cột chiến lược
1. Kiểm soát dữ liệu canh tác
Ghi nhận — Xác minh — Truy xuất làm nền tảng không thể thoả hiệp. Không có dữ liệu xác minh, không có gì phía sau (tài chính, marketplace, AI) có giá trị.
2. Vận hành doanh nghiệp nông nghiệp
Số hoá vận hành thực tế của HTX/Farm: kho, vật tư, nhân sự, kế toán, hợp đồng — biến OriginVN thành công cụ quản trị hàng ngày, không chỉ ghi chép.
3. Trí tuệ & Hệ sinh thái
Biến dữ liệu đã tích luỹ thành khuyến nghị AI, kết nối thị trường, và dịch vụ tài chính/carbon — giá trị compound theo thời gian sử dụng.
Bức tranh hệ thống — One-Page System Map
SUY LUẬN KIẾN TRÚCĐây là xương sống của toàn bộ tài liệu — mọi phần khác (Data Model, Workflow, Permission, AI) đều tham chiếu ngược lại chuỗi này. Bấm vào từng nút để xem chi tiết object, quan hệ, và workflow liên quan.
Chuỗi lõi: HTX → Thành viên → Vùng trồng → Lô → Mùa vụ → Kế hoạch → Công việc → Nhật ký → Vật tư → Sâu bệnh/Sự cố → Xác minh → Thu hoạch → Truy xuất → Chi phí → Đầu ra → Doanh nghiệp → Giao dịch → Dữ liệu → Phân tích → AI → Hệ sinh thái. THEO NGƯỜI DÙNG NÊU (đúng nguyên văn chuỗi lõi trong yêu cầu xây dựng tài liệu).
Business Model
ĐỀ XUẤTOriginVN vận hành theo mô hình nền tảng hai phía có dữ liệu làm lõi (data-core two-sided platform): phía cung (HTX/Farm) được số hoá vận hành và xác thực chất lượng; phía cầu (Buyer/Doanh nghiệp/Tài chính) trả phí để tiếp cận dữ liệu đã xác minh và các dịch vụ dựa trên dữ liệu đó.
Nguồn giá trị đầu vào
- Dữ liệu canh tác đã xác minh (nhật ký, xác minh kỹ sư)
- Hồ sơ truy xuất gắn QR cho từng lô hàng
- Lịch sử vận hành HTX (chi phí, kho, nhân sự)
Nguồn giá trị đầu ra
- SaaS vận hành cho HTX/Farm
- Dữ liệu/truy xuất cho Buyer & đối tác chuỗi cung ứng
- Sản phẩm tài chính dựa trên hồ sơ sản xuất (GĐ1: hồ sơ vay vốn → GĐ4: supply chain finance)
- AI & Analytics nâng cao (GĐ3+)
- Hoa hồng giao dịch Marketplace, phí xác nhận Carbon (GĐ4)
Chi tiết dòng doanh thu: xem Revenue Model. Phân biệt Finance theo từng giai đoạn: xem Phần P.
Owner × Dev Bridge — Hai góc nhìn song song
SUY LUẬN KIẾN TRÚCMọi module/workflow trong tài liệu này (Phần K, M) đều được trình bày theo cả hai lăng kính dưới đây, để Chủ dự án và Dev cùng đọc một nội dung nhưng trích ra đúng thứ mình cần.
Chủ dự án cần hiểu
- Chức năng làm gì — mô tả nghiệp vụ bằng ngôn ngữ thường
- Tại sao cần — vấn đề nào được giải quyết
- Ai dùng — vai trò/kênh sử dụng
- Giá trị — tác động tới HTX/doanh thu/vận hành
- Kết quả — output cụ thể sau khi chạy workflow
- Chi phí/phạm vi — độ lớn triển khai (định tính GĐ nào)
- Phụ thuộc — cần gì trước đó mới chạy được (xem Phần L)
- Nghiệm thu — tiêu chí "xong" theo nghĩa kinh doanh
Dev cần hiểu
- Object — thực thể dữ liệu liên quan (Phần E)
- Database/Relation — quan hệ 1–N, N–N
- State — trạng thái theo State Machine chuẩn (Phần J)
- Permission — theo ma trận vai trò (Phần I)
- API/Action — hành vi hệ thống cần expose
- Validation — quy tắc chất lượng dữ liệu (Phần G)
- Event/Audit — log bắt buộc cho truy vết
- Integration — hệ thống ngoài liên quan (IoT, blockchain, thanh toán...)
- Acceptance criteria — Definition of Done kỹ thuật (Phần V)
Từ điển Nông nghiệp ↔ Phần mềm
SUY LUẬN KIẾN TRÚC| Khái niệm | Nghĩa nghiệp vụ | Object hệ thống | Quan hệ | Dữ liệu chính | Dùng tiếp ở đâu |
|---|---|---|---|---|---|
| HTX | Hợp tác xã / tổ chức sản xuất | Cooperative | 1–N Thành viên, 1–N Vùng trồng | Mã, tên, đại diện, gói dịch vụ | RBAC, Governance, Finance |
| Thành viên | Nông dân/hộ sản xuất thuộc HTX | Member | N–1 HTX, N–N Công việc | Họ tên, SĐT, lô phụ trách | Công việc, Nhật ký |
| Farm | Vùng trồng / khu canh tác | GrowingRegion | N–1 HTX, 1–N Lô | Toạ độ, diện tích, loại đất | Truy xuất, Chứng nhận vùng |
| Vùng trồng | Đồng nghĩa Farm trong ngữ cảnh HTX nhỏ | GrowingRegion | Như trên | Như trên | Như trên |
| Lô | Đơn vị canh tác nhỏ nhất | LandPlot | N–1 Farm, 1–N Mùa vụ | Ranh giới GPS, cây trồng hiện tại | Truy xuất tới cấp lô |
| Mùa vụ | Chu kỳ canh tác cụ thể | Season | N–1 Lô, 1–N Kế hoạch/Thu hoạch | Giống, ngày xuống giống, dự kiến thu hoạch | Kế hoạch, Chi phí mùa vụ |
| Kho | Nơi lưu trữ vật tư/nông sản | Warehouse | 1–N Vật tư, 1–N Lô hàng (GĐ2+) | Tồn kho, vị trí, người quản | Logistics, Chi phí |
| Sự cố | Sâu bệnh/bất thường | Incident | N–1 Lô, 1–1 Xác minh | Loại, mức độ, bằng chứng | Cảnh báo, Khuyến nghị AI |
| Xác minh | Kiểm tra độc lập bởi kỹ sư | Verification | 1–1 Nhật ký/Sự cố | Kết luận, bằng chứng bổ sung | Truy xuất, Tài chính |
| Thu hoạch | Ghi nhận sản lượng thực thu | Harvest | N–1 Mùa vụ, 1–N Lô hàng | Sản lượng, ngày, phân loại | Truy xuất, Chi phí |
| Lô hàng | Gói sản phẩm sau thu hoạch để bán | TraceabilityLot | N–1 Thu hoạch, 1–N Đơn hàng | Mã QR, khối lượng, lịch sử liên quan | Truy xuất công khai, Giao dịch |
| Chất lượng | Kết quả phân loại/kiểm định | QualityRecord | N–1 Lô hàng | Cấp loại, tiêu chuẩn áp dụng | Marketplace, Giá bán |
| QR | Mã truy xuất công khai | QRCode | 1–1 Lô hàng | Link truy xuất công khai (Lớp 5) | Public Web |
| Chi phí | Chi phí canh tác/mùa vụ | CostEntry | N–1 Mùa vụ | Loại chi phí, số tiền | Hồ sơ tài chính, Phân tích |
| Đơn hàng | Yêu cầu mua từ Buyer | Order | N–1 Buyer, N–1 Lô hàng | Số lượng, giá, trạng thái | Giao dịch |
| Buyer | Doanh nghiệp thu mua | Enterprise | N–N HTX qua Đơn hàng | Ngành hàng, lịch sử giao dịch | Marketplace, Đánh giá |
| Giao dịch | Mua bán thực tế đã chốt | Transaction | N–1 Đơn hàng, N–1 Lô hàng | Giá trị, đối soát, thanh toán | Doanh thu, Phân tích |
| Cảnh báo | Thông báo bất thường cần hành động | Alert | N–1 Rule/Model, N–1 đối tượng liên quan | Mức độ, căn cứ, người nhận | AI Decision Loop (Phần O) |
| Khuyến nghị | Đề xuất hành động từ AI/Kỹ sư | Recommendation | N–1 Alert/Phân tích | Nội dung, độ tin cậy, căn cứ | Công việc mới |
| Risk Score | Điểm rủi ro tổng hợp (mùa vụ/HTX) | RiskScore | N–1 HTX/Mùa vụ | Điểm số, yếu tố cấu thành | Tài chính, Bảo hiểm (GĐ3) |
| AI | Lớp suy luận/khuyến nghị tự động | AIInference | N–1 Phân tích | Model version, confidence | Knowledge System |
| Carbon | Tín chỉ carbon từ canh tác bền vững | CarbonCredit | N–1 Mùa vụ/HTX | Khối lượng CO2e, phương pháp tính | Marketplace Carbon (GĐ4) |
| Đối tác | Nhà cung cấp dịch vụ/vật tư/tài chính | Partner | N–N HTX qua Ecosystem | Loại hình, đánh giá, lịch sử | Phần Q |
| Hồ sơ tài chính | Hồ sơ hỗ trợ vay vốn/bảo hiểm | FinancialProfile | 1–1 HTX | Tổng hợp chi phí, doanh thu, risk score | Ngân hàng/Bảo hiểm |
Master Data Model
SUY LUẬN KIẾN TRÚCMaster Object Map — nhánh canh tác
HTX ├── Thành viên ├── Farm (Vùng trồng) │ └── Lô │ └── Mùa vụ │ ├── Kế hoạch │ ├── Công việc │ ├── Nhật ký ── (dùng) ── Vật tú │ ├── Sự cố ── (tạo) ── Xác minh │ ├── Xác minh │ ├── Thu hoạch │ └── Chi phí
Nhánh thương mại (sau Thu hoạch)
Nhánh dữ liệu → trí tuệ
Vòng lặp Feedback quay ngược vào Knowledge System (Phần O) để cải thiện rule/model — không phải đường một chiều.
Bảng Object tổng hợp
| Object | Key field | Parent | Children | Ghi chú |
|---|---|---|---|---|
| Cooperative (HTX) | coop_id | — | Member, GrowingRegion | Chủ thể dữ liệu Lớp 1–2 |
| Member | member_id | Cooperative | Task (qua phân công) | 1 member có thể phụ trách N lô |
| GrowingRegion | region_id | Cooperative | LandPlot | Có ranh giới GPS |
| LandPlot | plot_id | GrowingRegion | Season | Đơn vị truy xuất thấp nhất |
| Season | season_id | LandPlot | Plan, Task, Harvest, CostEntry | Có trạng thái riêng (đang canh tác/đã kết thúc) |
| Plan | plan_id | Season | Task (dự kiến) | Có versioning |
| Task | task_id | Season / Plan | Diary (1–1 khi hoàn thành) | Có thể phát sinh từ Incident |
| Diary (Nhật ký) | diary_id | Task | Verification | Bắt buộc GPS + timestamp + ảnh |
| Input (Vật tư) | input_id | Warehouse | — (được tham chiếu bởi Diary) | Có PHI (thời gian cách ly) |
| Incident (Sự cố) | incident_id | LandPlot/Season | Verification, Recommendation | Nguồn: người dùng hoặc AI |
| Verification | verify_id | Diary / Incident | — (gate cho Harvest/Traceability) | Thực hiện bởi Kỹ sư |
| Harvest | harvest_id | Season | TraceabilityLot | — |
| TraceabilityLot (Lô hàng) | lot_id | Harvest | QualityRecord, QRCode, Order | Điểm hội tụ toàn bộ lịch sử canh tác |
| CostEntry | cost_id | Season | — (tổng hợp lên FinancialProfile) | — |
| Order / Transaction | order_id / txn_id | TraceabilityLot, Enterprise | — | GĐ2+ |
Data Lifecycle
SUY LUẬN KIẾN TRÚC| Trạng thái | Ý nghĩa | Ai tác động | Chuyển tiếp hợp lệ |
|---|---|---|---|
| Tạo | Bản ghi vừa khởi tạo trong hệ thống | Người ghi nhận | → Nháp |
| Nháp | Đang chỉnh sửa, chưa gửi | Người ghi nhận | → Kiểm tra |
| Kiểm tra | Chạy Data Quality tự động (Phần G) | Hệ thống | → Đã gửi (pass) hoặc quay lại Nháp (fail) |
| Đã gửi | Sẵn sàng cho xác minh | Hệ thống | → Chờ xác minh |
| Chờ xác minh | Trong hàng đợi của Kỹ sư | Kỹ sư | → Cần bổ sung hoặc → Đã xác minh |
| Cần bổ sung | Kỹ sư yêu cầu bằng chứng thêm | Kỹ sư → Người ghi nhận | → Gửi lại |
| Gửi lại | Người ghi nhận đã bổ sung | Người ghi nhận | → Chờ xác minh |
| Đã xác minh | Kỹ sư xác nhận đạt | Kỹ sư | → Được sử dụng |
| Được sử dụng | Đưa vào hồ sơ truy xuất/tài chính | Hệ thống | → Chia sẻ theo quyền |
| Chia sẻ theo quyền | Hiển thị cho bên liên quan theo 5 tầng (Phần H) | Hệ thống + chủ dữ liệu | → Phân tích |
| Phân tích | Đưa vào Analytics/AI | Hệ thống | → Lưu trữ |
| Lưu trữ | Archive, vẫn truy vấn được, không sửa | Hệ thống | → Kết thúc vòng đời |
Data Quality
SUY LUẬN KIẾN TRÚCBộ quy tắc chạy tự động ở bước Kiểm tra trong Data Lifecycle (Phần F), áp dụng cho mọi object ghi nhận từ hiện trường (Nhật ký, Sự cố, Thu hoạch).
| Quy tắc | Logic phát hiện | Hành động khi vi phạm |
|---|---|---|
| Thiếu dữ liệu | Trường bắt buộc rỗng (ảnh, GPS, vật tư...) | Chặn gửi, yêu cầu bổ sung tại chỗ |
| Sai thời gian | Timestamp ghi nhận lệch bất thường so với thời điểm submit | Gắn cờ cảnh báo, cho Kỹ sư xem xét |
| Thời gian tương lai | Timestamp > thời điểm hiện tại của hệ thống | Chặn gửi |
| Vị trí sai | GPS ghi nhận nằm ngoài ranh giới Lô đã đăng ký (+ sai số cho phép) | Gắn cờ, yêu cầu Kỹ sư xác minh tại chỗ |
| Ảnh không phù hợp | Ảnh trùng với ảnh cũ (hash trùng) hoặc không khớp loại hoạt động (đối chiếu AI thị giác, GĐ3+) | Chặn gửi hoặc gắn cờ tuỳ mức độ |
| Trùng bản ghi | Cùng Task + cùng khung giờ đã có Diary | Cảnh báo trùng, cho gộp hoặc huỷ |
| Sai lô | Task gắn Lô khác với Lô đang canh tác của Member | Cảnh báo, yêu cầu xác nhận |
| Sai mùa vụ | Ghi nhận ngoài khoảng ngày bắt đầu–kết thúc Mùa vụ | Chặn gửi |
| Vật tư không hợp lệ | Vật tư không có trong danh mục hợp lệ / đã hết hạn đăng ký | Chặn gửi |
| Liều lượng bất thường | Liều lượng ghi nhận lệch khỏi khuyến nghị nhà sản xuất quá ngưỡng | Gắn cờ, tạo Khuyến nghị xem xét |
| Thời gian cách ly (PHI) | Ngày thu hoạch dự kiến < ngày sử dụng vật tư + PHI | Cảnh báo mạnh tới Kỹ sư + Quản lý HTX |
| Quyền nhập liệu | Người ghi nhận không thuộc danh sách được phân công cho Lô/Task đó | Chặn ghi nhận (kiểm tra tại tầng Permission) |
Data Governance
SUY LUẬN KIẾN TRÚC| Hạng mục | Nguyên tắc |
|---|---|
| Chủ thể dữ liệu | HTX là chủ thể dữ liệu sản xuất của mình; Thành viên là chủ thể dữ liệu cá nhân; OriginVN là bên xử lý/lưu trữ (data processor), không mặc định là chủ sở hữu |
| Quyền sở hữu / quản lý | Quản lý HTX có quyền quản trị dữ liệu cấp HTX; Thành viên quản lý dữ liệu cá nhân + dữ liệu Lô được giao |
| Quyền truy cập | Theo ma trận Role × Permission (Phần I) kết hợp 5 tầng chia sẻ (dưới đây) |
| Quyền sửa | Chỉ người tạo bản ghi được sửa khi còn ở trạng thái Nháp/Cần bổ sung; sau khi Đã xác minh, dữ liệu bất biến (immutable) — sửa = tạo bản ghi mới + link tới bản cũ |
| Quyền xác minh | Chỉ Kỹ sư được cấp quyền cho đúng Vùng trồng/HTX phụ trách |
| Quyền chia sẻ | Chủ thể dữ liệu (HTX) quyết định chia sẻ ra Lớp 3 (Buyer) trở lên; Lớp 5 (công khai) chỉ gồm dữ liệu truy xuất đã được duyệt hiển thị |
| Mục đích sử dụng | Mỗi lượt chia sẻ phải gắn mục đích (giao dịch / thẩm định tín dụng / nghiên cứu / công khai truy xuất) |
| Thời hạn | CẦN CHỐT thời hạn lưu trữ hoạt động vs. lưu trữ lạnh cho từng loại dữ liệu (đề xuất: dữ liệu canh tác lưu tối thiểu vòng đời truy xuất sản phẩm + quy định pháp lý ngành hàng liên quan) |
| Audit | Mọi hành động tạo/sửa/xác minh/chia sẻ đều ghi log bất biến: ai, khi nào, thao tác gì, giá trị trước/sau |
| Backup / Restore | ĐỀ XUẤT backup tăng dần hàng ngày + backup đầy đủ định kỳ; restore có quy trình kiểm thử định kỳ (không chỉ backup mà không kiểm tra được) |
| Incident (sự cố dữ liệu) | ĐỀ XUẤT quy trình phản ứng sự cố lộ dữ liệu/mất dữ liệu: phát hiện → cô lập → đánh giá phạm vi → thông báo chủ thể liên quan → khắc phục → báo cáo hậu kiểm |
| Account lifecycle | Tạo → Kích hoạt → Hoạt động → Tạm khoá → Vô hiệu hoá; dữ liệu cá nhân được ẩn danh hoá khi tài khoản vô hiệu hoá, dữ liệu canh tác liên quan vẫn giữ để không phá vỡ truy xuất |
| HTX rời hệ thống | CẦN CHỐT chính sách khi HTX chấm dứt hợp đồng: dữ liệu giao dịch/truy xuất đã phát hành công khai (Lớp 5, đã có QR lưu hành) không thể thu hồi; dữ liệu nội bộ được xuất cho HTX và xoá khỏi hệ thống vận hành sau thời hạn lưu trữ pháp lý |
| Xuất dữ liệu | HTX/Thành viên có quyền yêu cầu xuất toàn bộ dữ liệu của mình (định dạng máy đọc được) bất kỳ lúc nào |
5 tầng quyền dữ liệu
| Lớp | Mô tả | Ai xem | Ai chia sẻ (quyết định) | Chia sẻ trường nào | Mục đích | Thời hạn | Ghi lịch sử? |
|---|---|---|---|---|---|---|---|
| Lớp 1 Dữ liệu riêng | Nhật ký, sự cố, chi phí nội bộ chưa xác minh | Người tạo, Quản lý HTX, Kỹ sư phụ trách | Không chia sẻ mặc định | Toàn bộ | Vận hành nội bộ | Không giới hạn (theo vòng đời tài khoản) | Có |
| Lớp 2 HTX cho phép chia sẻ | Dữ liệu đã xác minh, HTX đồng ý dùng nội bộ đối tác gần (ngân hàng thẩm định...) | Bên được HTX cấp quyền cụ thể | Quản lý HTX | Theo lựa chọn của HTX mỗi lượt cấp quyền | Thẩm định tín dụng/bảo hiểm, kiểm toán | Theo thời hạn cấp quyền, có thể thu hồi | Có |
| Lớp 3 Phục vụ giao dịch | Dữ liệu Lô hàng gắn với một Đơn hàng cụ thể | Buyer trong giao dịch đó | Hệ thống (tự động khi giao dịch được xác nhận) | Chất lượng, nguồn gốc, chứng nhận liên quan tới Lô hàng đó | Hoàn tất giao dịch mua bán | Trong thời gian giao dịch + lưu trữ hồ sơ giao dịch | Có |
| Lớp 4 Dữ liệu tổng hợp | Số liệu đã ẩn danh/tổng hợp theo vùng, ngành hàng | Đối tác nghiên cứu, cơ quan nhà nước, nội bộ OriginVN | OriginVN (theo chính sách đã công bố) | Chỉ số tổng hợp, không định danh cá nhân/HTX cụ thể | Hoạch định chính sách, báo cáo ngành | Không giới hạn (đã ẩn danh) | Có (ở mức tổng hợp) |
| Lớp 5 Dữ liệu công khai | Trang truy xuất công khai qua QR | Bất kỳ ai quét QR | HTX duyệt hiển thị khi tạo Lô hàng | Tập trường đã được duyệt hiển thị công khai (không gồm chi phí, thông tin cá nhân nhạy cảm) | Minh bạch với người tiêu dùng cuối | Vĩnh viễn (gắn với sản phẩm đã lưu hành) | Có (bản ghi gốc, không sửa được) |
Role & Permission Matrix
SUY LUẬN KIẾN TRÚC| Vai trò | Xem | Tạo | Sửa | Xác minh | Duyệt | Xuất | Chia sẻ |
|---|---|---|---|---|---|---|---|
| Nông dân (thành viên) | Lô/mùa vụ của mình | Nhật ký, Sự cố | Bản ghi Nháp của mình | — | — | Dữ liệu cá nhân | — |
| Người lao động | Công việc được giao | Nhật ký (công việc được giao) | Bản ghi Nháp của mình | — | — | — | — |
| Kỹ sư | Toàn bộ dữ liệu vùng phụ trách | Xác minh, Khuyến nghị | Kết luận xác minh của mình | ✔ Nhật ký/Sự cố | — | Báo cáo xác minh | Lớp 2 (đề xuất) |
| Quản lý HTX | Toàn bộ dữ liệu HTX | Kế hoạch, phân công | Thông tin HTX, thành viên | — | Kế hoạch, chi phí | Toàn bộ dữ liệu HTX | Lớp 2 (quyết định chính) |
| Thủ kho | Tồn kho, vật tư | Phiếu nhập/xuất kho | Phiếu kho chưa chốt | — | — | Báo cáo tồn kho | — |
| Kế toán | Chi phí, công nợ, giao dịch | Chứng từ, hồ sơ tài chính | Chứng từ chưa khoá sổ | — | Thanh toán | Báo cáo tài chính | Lớp 2 (với ngân hàng/bảo hiểm) |
| Quản lý chất lượng | Lô hàng, kết quả kiểm định | Bản ghi chất lượng | Bản ghi chất lượng chưa chốt | ✔ Chất lượng lô hàng | Lô hàng đạt chuẩn | Chứng nhận chất lượng | Lớp 3 (khi có giao dịch) |
| Quản lý Farm | Toàn bộ vùng trồng phụ trách | Vùng trồng, Lô mới | Thông tin vùng/lô | — | Kế hoạch mùa vụ | Báo cáo vùng trồng | — |
| Lãnh đạo (HTX/DN) | Toàn bộ báo cáo tổng hợp | — | — | — | Quyết định chiến lược, chia sẻ Lớp 2+ | Toàn bộ báo cáo | Lớp 2 (quyền cao nhất trong HTX) |
| Buyer / Doanh nghiệp | Lô hàng trong giao dịch (Lớp 3), Marketplace công khai | RFQ, Đơn hàng | Đơn hàng của mình (khi chưa xác nhận) | — | Xác nhận đơn hàng | Lịch sử giao dịch của mình | — |
| Ngân hàng | Hồ sơ tài chính được HTX cấp quyền (Lớp 2) | — | — | — | Phê duyệt khoản vay (ngoài hệ thống) | Hồ sơ được cấp quyền | — |
| Bảo hiểm | Risk score, lịch sử sự cố (Lớp 2, GĐ2+) | — | — | — | Phê duyệt bồi thường (ngoài hệ thống) | Hồ sơ được cấp quyền | — |
| Đơn vị chứng nhận | Dữ liệu vùng trồng liên quan tiêu chuẩn | Chứng nhận | Chứng nhận do mình cấp | ✔ Tiêu chuẩn (VietGAP/GlobalGAP...) | Cấp/thu hồi chứng nhận | Chứng nhận | Lớp 3–4 |
| Quản trị hệ thống | Toàn hệ thống (kỹ thuật) | Tài khoản, cấu hình | Cấu hình hệ thống, RBAC | — | — | Log hệ thống | — |
| Quản trị tri thức | Bộ quy tắc, danh mục tri thức | Quy tắc mới, phiên bản kiến thức | Quy tắc hiện có | — | ✔ Duyệt phiên bản quy tắc (Phần O) | Bộ tri thức | — |
| AI | Dữ liệu đã qua Data Quality (Phần G) | Cảnh báo, Khuyến nghị (luôn ở trạng thái chờ duyệt) | — | — | — | — | — |
CẦN CHỐT Phân quyền chi tiết ở cấp field-level (ví dụ: Kế toán có xem được toạ độ GPS chi tiết không) cần Chủ dự án xác nhận theo từng ngành hàng triển khai.
State Machine (thống nhất toàn hệ thống)
SUY LUẬN KIẾN TRÚCÁp dụng cho mọi object cần xác minh (Nhật ký, Sự cố, Chất lượng, Chứng nhận). Không được tạo trạng thái tuỳ tiện ở từng module — mọi state mới phải map vào state machine này hoặc được đề xuất bổ sung có kiểm soát.
DRAFT
↓
SUBMITTED
↓
PENDING_VERIFICATION
├── NEED_MORE_INFO
│ ↓
│ RESUBMITTED
│ ↓
│ PENDING_VERIFICATION
│
└── VERIFIED
↓
USED
Trạng thái nghiệp vụ chung (Task / Order / Incident...)
Nhánh rẽ khác từ bất kỳ trạng thái đang mở: Hủy (chủ động dừng), Từ chối (không được chấp thuận ở bước duyệt), Đóng (kết thúc vòng đời, có thể đạt hoặc không đạt).
4 Giai đoạn phát triển sản phẩm
SUY LUẬN KIẾN TRÚCTimeline tổng thể (tuần tự, không chạy song song giữa các GĐ)
Mục tiêu: thiết lập nền tảng kiểm soát dữ liệu canh tác không thể thoả hiệp — nếu GĐ1 không vững, GĐ2–4 không có gì để xây trên đó (xem Phần L).
Module (theo đúng yêu cầu gốc — giữ nguyên danh sách, không rút gọn)
1. Farm Management
Quản lý Vùng trồng/Farm: ranh giới GPS, diện tích, loại đất, nguồn nước.
2. Land Plot
Quản lý Lô — đơn vị truy xuất thấp nhất, gắn mùa vụ.
3. Cultivation Diary
Ghi nhận nhật ký canh tác có bằng chứng (ảnh, GPS, thời gian).
4. Engineer Verification
Quy trình kỹ sư xác minh độc lập nhật ký/sự cố.
5. QR Traceability
Tạo lô hàng, mã QR, trang truy xuất công khai (Lớp 5).
6. Blockchain (ghi dấu vết bất biến)
ĐỀ XUẤT — áp dụng để kịp tiến độ 15 ngày Chỉ ghi hash của bản ghi đã VERIFIED lên chain (không lưu toàn bộ dữ liệu thô trên chain) — phạm vi nhỏ nhất đủ để chống sửa đổi ngược, khả thi trong 15 ngày. Mở rộng phạm vi (nếu cần) để sau, đầu GĐ2.
7. Financing Dossier
Hồ sơ hỗ trợ vay vốn — tổng hợp dữ liệu sản xuất đã xác minh thành hồ sơ chuẩn cho ngân hàng.
8. Standards (Tiêu chuẩn)
Quản lý tiêu chuẩn áp dụng theo vùng/lô (VietGAP, GlobalGAP...).
9. Dashboard
Bảng điều khiển tổng hợp cho Quản lý HTX/Lãnh đạo.
10. RBAC + Warehouse/Input
Phân quyền theo vai trò (Phần I) + quản lý kho/vật tư cơ bản.
CẦN CHỐT Brief gốc nêu mâu thuẫn mẫu "9 module" vs "Module 1→10" — vì không có tài liệu thật, danh sách trên được xây lại từ đầu với 10 module rõ ràng; cần Chủ dự án đối chiếu với danh sách gốc thật khi có.
Trình tự dựng trong 15 ngày ĐỀ XUẤT
Để 10 module kịp trong 15 ngày, bắt buộc chạy song song 3 mũi (không làm tuần tự từng module) — mũi A là đường găng (critical path), B và C có thể chồng lấn với A ngay từ ngày 1.
| Mũi | Ngày 1–5 | Ngày 6–10 | Ngày 11–15 |
|---|---|---|---|
| A — Chuỗi lõi (critical path) | Farm, Lô, RBAC nền | Cultivation Diary + Engineer Verification (mobile+web) | QR Traceability + kiểm thử chuỗi Nhật ký→Xác minh→QR trên dữ liệu pilot thật |
| B — Hồ sơ & tiêu chuẩn | Thiết kế Financing Dossier + Standards (song song, không phụ thuộc A) | Nối Financing Dossier/Standards vào dữ liệu đã xác minh khi A xong Diary | Hoàn thiện, kiểm thử xuất hồ sơ |
| C — Vận hành & hạ tầng | Warehouse/Input cơ bản | Dashboard (khung + số liệu giả lập) | Blockchain hash-anchor (phạm vi rút gọn ở trên) + Dashboard nối dữ liệu thật |
Nếu tới ngày 15 mũi B hoặc C chưa xong hoàn chỉnh, ưu tiên giữ đúng hạn cho Mũi A — đó là phần bắt buộc để pilot 100ha chạy được (không có Mũi A thì không có gì để Mũi B/C dùng, xem Cross-Stage Dependency Phần L áp dụng logic tương tự trong nội bộ GĐ1).
Mục tiêu: mở rộng từ kiểm soát canh tác sang vận hành doanh nghiệp nông nghiệp đầy đủ.
IoT & Irrigation
Cảm biến đất/thời tiết, hệ thống tưới tự động/bán tự động.
Alerts (cảnh báo vận hành)
Cảnh báo rule-based (chưa cần AI phức tạp — xem khác biệt với GĐ3 ở Phần O).
Warehouse & Logistics
Quản lý kho đầy đủ, vận chuyển, giao nhận.
Orders
Quản lý đơn hàng B2B đầy đủ vòng đời.
Receivables / Payables
Công nợ phải thu/phải trả.
Contracts
Quản lý hợp đồng với thành viên, buyer, nhà cung cấp.
HR
Quản lý nhân sự HTX/Farm (người lao động thời vụ, cố định).
Social Insurance & Tax
Hỗ trợ nghĩa vụ bảo hiểm xã hội, thuế cho lao động chính thức.
Documents
Quản lý văn bản, chứng từ tập trung.
Accounting
Sổ sách kế toán cơ bản cho HTX/Farm.
Insurance (bảo hiểm nông nghiệp)
Kết nối hồ sơ sản xuất với sản phẩm bảo hiểm.
Mục tiêu: biến dữ liệu tích luỹ từ GĐ1+GĐ2 thành trí tuệ chủ động. GĐ3 không tự tồn tại độc lập — xem ràng buộc phụ thuộc tại Phần L.
AI Alerts
Cảnh báo dựa trên model, không chỉ rule tĩnh như GĐ2.
Disease Detection
Phát hiện sâu bệnh qua ảnh (computer vision).
Explainable AI
Mọi output AI phải kèm căn cứ — bắt buộc theo AI Decision Loop (Phần O).
Optimization
Tối ưu hoá lịch tưới/bón phân dựa trên dữ liệu lịch sử.
Risk Forecasting
Dự báo rủi ro mùa vụ (thời tiết, sâu bệnh, thị trường).
Financial Support (AI-driven)
Risk score tự động hỗ trợ thẩm định — khác Financing Dossier GĐ1 (là hồ sơ tĩnh).
Season Planning
Gợi ý kế hoạch mùa vụ dựa trên dữ liệu lịch sử + dự báo.
Risk Scoring
Điểm rủi ro tổng hợp cấp HTX/Mùa vụ.
Virtual Assistant
Trợ lý hội thoại cho nông dân/kỹ sư — không thay thế Verification.
Smart Camera
Camera giám sát tích hợp AI thị giác tại vùng trồng.
BI (Business Intelligence)
Báo cáo phân tích nâng cao cấp quản lý/lãnh đạo.
Feedback Loop
Vòng lặp cải thiện model/tri thức từ kết quả thực tế (Phần O, Phần 16).
Mục tiêu: mở nền tảng thành hệ sinh thái đầy đủ. GĐ4 không tự tồn tại độc lập — Marketplace/Carbon/Finance/Open API phải dùng nền dữ liệu & quy trình các GĐ trước.
Drone & NDVI
Giám sát viễn thám sức khoẻ cây trồng trên diện rộng.
Marketplace
Chi tiết vòng đời giao dịch tại Phần Q.
Carbon
Chi tiết tại Phần R.
Open API
Chi tiết tại Phần S.
White-label
Đóng gói nền tảng cho đối tác vận hành dưới thương hiệu riêng.
DaaS (Data as a Service)
Cung cấp dữ liệu Lớp 4 (tổng hợp) dưới dạng dịch vụ trả phí.
Supply Chain Finance
Tài chính chuỗi cung ứng dựa trên giao dịch đã xác minh (khác Financing Dossier GĐ1 và Risk Scoring GĐ3).
Insurance (nâng cao)
Sản phẩm bảo hiểm parametric dựa trên dữ liệu thời gian thực.
Wallet
Ví điện tử nội bộ hệ sinh thái cho giao dịch/thanh toán.
Community
Không gian kết nối nông dân, chia sẻ kinh nghiệm.
Government Cooperation
Kết nối dữ liệu tổng hợp (Lớp 4) với cơ quan quản lý.
ESG
Báo cáo ESG dựa trên dữ liệu canh tác + Carbon đã xác minh.
Cross-Stage Dependency
SUY LUẬN KIẾN TRÚCData Foundation→ GĐ2
Operational Data→ GĐ3
Intelligence→ GĐ4
Ecosystem
GĐ3 không được tự tồn tại độc lập
AI (cảnh báo, dự báo rủi ro, tối ưu hoá) bắt buộc lấy dữ liệu huấn luyện/suy luận từ GĐ1 (dữ liệu canh tác đã xác minh) + GĐ2 (dữ liệu vận hành: chi phí, kho, đơn hàng). Triển khai GĐ3 trước khi GĐ1 đủ dữ liệu xác minh ổn định sẽ cho ra model không đáng tin cậy — vi phạm nguyên tắc Explainable AI ở Phần O.
GĐ4 không được tồn tại độc lập
Marketplace cần Lô hàng đã truy xuất (GĐ1) + Đơn hàng/Giao dịch đã vận hành ổn định (GĐ2). Carbon credit cần dữ liệu canh tác đã xác minh nhiều mùa vụ (GĐ1) để tính toán đáng tin cậy. Supply Chain Finance cần lịch sử giao dịch thật (GĐ2) + Risk Score (GĐ3). Open API chỉ nên mở khi có dữ liệu Lớp 3–4 đã ổn định về governance (Phần H).
| Giai đoạn | Phụ thuộc bắt buộc vào | Cung cấp nền tảng cho |
|---|---|---|
| GĐ1 | — (điểm khởi đầu) | Toàn bộ GĐ2–4 (dữ liệu canh tác đã xác minh, RBAC nền) |
| GĐ2 | GĐ1 (Farm/Lô/Mùa vụ/Nhật ký/Xác minh) | GĐ3 (dữ liệu vận hành), GĐ4 (lịch sử giao dịch/kho) |
| GĐ3 | GĐ1 + GĐ2 (không được thiếu vế nào) | GĐ4 (Risk Score cho Supply Chain Finance/Insurance) |
| GĐ4 | GĐ1 + GĐ2 + GĐ3 | Hệ sinh thái mở (bên thứ ba qua Open API) |
Full Business Workflows
SUY LUẬN KIẾN TRÚCTheo đúng nguyên tắc "không phải cứ nhiều workflow/card là đầy đủ" — dưới đây là 3 chuỗi nghiệp vụ lớn, đầy đủ logic 5 lớp (Nghiệp vụ / Giao diện / Hệ thống / Dữ liệu / Đầu ra) thay vì hàng trăm thẻ rời rạc. Các workflow khác trong hệ thống đều là biến thể của 3 chuỗi gốc này.
1. Nhật ký & Công việc → Xác minh → Sử dụngChuỗi lõi GĐ1
A. Nghiệp vụ
- Người thực hiện: Nông dân/Người lao động (ghi) → Kỹ sư (xác minh)
- Mục tiêu: chuyển hành động canh tác thực tế thành dữ liệu có bằng chứng, đủ tin cậy để dùng cho truy xuất và tài chính
- Điều kiện bắt đầu: tồn tại Task ở trạng thái Chưa xử lý/Đang xử lý, người ghi có quyền trên Lô đó
- Hành động: thực hiện công việc ngoài đồng → mở app → chọn Task → nhập loại hoạt động, vật tư, chụp ảnh, hệ thống tự lấy GPS/thời gian → gửi
- Điều kiện kết thúc: Nhật ký đạt trạng thái VERIFIED (hoặc REJECTED nếu Kỹ sư từ chối — quay lại NEED_MORE_INFO)
B. Giao diện
- Kênh: Mobile (Nông dân/NLĐ) · Mobile+Web (Kỹ sư) · Web/CMS (Quản lý HTX xem báo cáo)
- Màn hình: Danh sách công việc → Chi tiết công việc → Form ghi nhật ký → Hàng đợi xác minh (Kỹ sư)
- Trường nhập: loại hoạt động, vật tư sử dụng + liều lượng, ảnh (bắt buộc ≥1), ghi chú
- Nút hành động: "Gửi nhật ký", "Yêu cầu bổ sung" (Kỹ sư), "Xác nhận đạt" (Kỹ sư)
- Thông báo: đẩy tới người ghi khi có kết quả xác minh; đẩy tới Kỹ sư khi có nhật ký mới trong hàng đợi
- Trạng thái hiển thị: Nháp / Đã gửi / Chờ xác minh / Cần bổ sung / Đã xác minh
- Trường hợp lỗi: mất kết nối khi gửi → lưu offline, đồng bộ lại; thiếu ảnh/GPS → chặn nút Gửi kèm cảnh báo tại chỗ
C. Hệ thống
- API/action:
diary.create,diary.submit,verification.review,verification.approve/reject - Business rule: không cho Submit nếu thiếu trường bắt buộc hoặc vi phạm Data Quality (Phần G)
- State: theo State Machine chuẩn (Phần J): DRAFT → SUBMITTED → PENDING_VERIFICATION → (NEED_MORE_INFO ↔ RESUBMITTED) → VERIFIED → USED
- Permission: theo ma trận Phần I (Nông dân: Tạo/Sửa Nháp; Kỹ sư: Xác minh)
- Validation: toàn bộ 12 quy tắc Data Quality (Phần G) áp dụng ở bước Kiểm tra
- Audit: log tạo/sửa/xác minh với timestamp, actor, giá trị trước/sau
D. Dữ liệu
- Object: Task, Diary, Input(Vật tư), Verification
- Field chính: diary_id, task_id, activity_type, inputs[], photos[], gps, timestamp, verify_status
- Quan hệ: Diary N–1 Task; Diary N–N Input; Diary 1–1 Verification
- Nguồn dữ liệu: nhập tay + GPS/camera thiết bị (không cho nhập tay toạ độ)
- Chất lượng dữ liệu: gate bởi Phần G trước khi chuyển SUBMITTED
- Lịch sử thay đổi: giữ toàn bộ phiên bản Nháp → Gửi lại (không ghi đè)
E. Đầu ra
- Kết quả: Nhật ký ở trạng thái USED, sẵn sàng làm bằng chứng truy xuất
- Dữ liệu mới: bản ghi tiêu thụ Vật tư (trừ kho), bản ghi Chi phí liên quan
- Workflow tiếp theo: tổng hợp vào hồ sơ Mùa vụ → dùng khi tạo Lô hàng (Workflow 2)
- Báo cáo: tiến độ công việc theo Mùa vụ cho Quản lý HTX
- Cảnh báo: nếu vi phạm PHI/liều lượng → tạo Incident tự động
- AI: dữ liệu đã VERIFIED là input huấn luyện cho Disease Detection, Optimization (GĐ3)
2. Mùa vụ → Thu hoạch → Truy xuất → Giao dịchChuỗi lõi GĐ1–GĐ2
A. Nghiệp vụ
- Người thực hiện: Quản lý Farm/Nông dân (thu hoạch) → Quản lý chất lượng (phân loại) → Kế toán (giao dịch)
- Mục tiêu: chuyển sản lượng thực thu thành Lô hàng có thể bán, có truy xuất đầy đủ
- Điều kiện bắt đầu: Mùa vụ đạt ngày dự kiến thu hoạch VÀ không có Incident PHI đang mở (thời gian cách ly chưa đủ)
- Hành động: kiểm tra điều kiện cách ly → ghi nhận thu hoạch → phân loại/kiểm định chất lượng → hệ thống tự tạo Lô hàng + mã QR
- Điều kiện kết thúc: Giao dịch được xác nhận và đối soát xong với Buyer
B. Giao diện
- Kênh: Mobile+Web (thu hoạch) · Web/CMS (chất lượng, kho) · Partner Portal (Buyer đặt hàng) · Public Web (quét QR)
- Màn hình: Xác nhận thu hoạch → Phân loại & chất lượng → Trang chi tiết Lô hàng (nội bộ) → Trang truy xuất công khai (quét QR) → RFQ/Đơn hàng (Buyer) → Đối soát (Kế toán)
- Trường nhập: sản lượng, đơn vị, phân loại sơ bộ, kết quả kiểm định, khối lượng đóng gói
- Nút hành động: "Xác nhận thu hoạch", "Tạo Lô hàng", "Phát hành QR", "Xác nhận đơn hàng", "Xác nhận giao dịch"
- Thông báo: nhắc Quản lý Farm khi tới ngày dự kiến thu hoạch; báo Buyer khi Lô hàng mới khớp yêu cầu đã đăng ký
- Trạng thái: Chưa thu hoạch / Đã thu hoạch / Đã phân loại / Đã phát hành QR / Đã bán / Đã đối soát
- Trường hợp lỗi: thu hoạch khi chưa đủ PHI → chặn cứng, yêu cầu Quản lý HTX xác nhận ngoại lệ có ghi lý do
C. Hệ thống
- API/action:
harvest.create,lot.generate,qr.issue,order.create,transaction.confirm - Business rule: Lô hàng chỉ tạo được từ Thu hoạch có Mùa vụ với 100% Nhật ký liên quan ở trạng thái VERIFIED hoặc USED
- State: Harvest (Draft→Confirmed); Lot (Created→Published→Sold→Reconciled); Order (theo state machung chung Phần J)
- Permission: theo Phần I (Buyer chỉ thấy Lớp 3 của Lô hàng trong giao dịch của mình)
- Validation: đối chiếu PHI, đối chiếu sản lượng khai báo với diện tích Lô (phát hiện bất thường)
- Audit: log toàn bộ chuỗi từ Harvest tới Transaction, không sửa được sau khi Lô hàng Published
D. Dữ liệu
- Object: Harvest, TraceabilityLot, QualityRecord, QRCode, Order, Enterprise, Transaction
- Field chính: lot_id, qr_code, quality_grade, quantity, linked_diaries[], linked_verifications[]
- Quan hệ: Lot N–1 Harvest; Lot 1–N Order; Order N–1 Enterprise; Transaction N–1 Order
- Nguồn dữ liệu: kế thừa toàn bộ Nhật ký/Xác minh của Mùa vụ (Workflow 1) + nhập mới ở bước thu hoạch/chất lượng
- Chất lượng dữ liệu: Lô hàng không được publish nếu chuỗi Nhật ký nguồn chưa đầy đủ xác minh
- Lịch sử thay đổi: Lô hàng bất biến sau khi Published (Phần H — quyền sửa)
E. Đầu ra
- Kết quả: Giao dịch hoàn tất, đối soát xong
- Dữ liệu mới: bản ghi Doanh thu, cập nhật Chi phí mùa vụ → tính lợi nhuận biên (Đầu ra/Output)
- Workflow tiếp theo: dữ liệu Giao dịch nạp vào Phân tích → Risk Score (GĐ3), Marketplace/Supply Chain Finance (GĐ4)
- Báo cáo: hiệu quả mùa vụ (Phần T — Measurement)
- Traceability: trang công khai Lớp 5 hiển thị toàn bộ hành trình canh tác đã xác minh
- Marketplace: Lô hàng dư/chưa bán có thể đưa vào Marketplace công khai (GĐ4, Phần Q)
3. Dữ liệu → Cảnh báo → Hành động → FeedbackChuỗi AI, GĐ2–GĐ3
A. Nghiệp vụ
- Người thực hiện: Hệ thống/AI (phát hiện) → Người nhận cảnh báo (Nông dân/Kỹ sư/Quản lý) → Kỹ sư (xác minh kết quả xử lý)
- Mục tiêu: chuyển tín hiệu bất thường trong dữ liệu thành hành động khắc phục kịp thời, có đo lường hiệu quả
- Điều kiện bắt đầu: dữ liệu mới thoả điều kiện Rule (GĐ2) hoặc vượt ngưỡng tin cậy Model (GĐ3)
- Hành động: hệ thống tạo Alert kèm căn cứ → gửi người nhận phù hợp theo mức độ → người nhận xử lý → ghi nhận kết quả
- Điều kiện kết thúc: Alert ở trạng thái Đóng, có kết quả xử lý được xác minh
B. Giao diện
- Kênh: System Automation (tạo alert) · Mobile (nhận + xử lý) · AI Console (Quản trị AI theo dõi hiệu năng) · Web/CMS (Quản lý HTX xem tổng hợp)
- Màn hình: Danh sách cảnh báo → Chi tiết cảnh báo (kèm căn cứ/độ tin cậy) → Form ghi nhận hành động xử lý → Đánh giá kết quả
- Trường nhập: hành động đã thực hiện, ảnh/bằng chứng sau xử lý, đánh giá đúng/sai của cảnh báo
- Nút hành động: "Xác nhận đã xử lý", "Báo cảnh báo sai" (phản hồi cho Feedback Loop)
- Thông báo: đẩy ngay khi Alert mức độ cao; tổng hợp hàng ngày cho mức độ thấp
- Trạng thái: Mới / Đang xử lý / Đã xử lý / Đã xác minh kết quả / Đóng / Đánh giá sai (false positive)
- Trường hợp lỗi: người nhận không phản hồi trong SLA → leo thang (escalate) lên Quản lý HTX
C. Hệ thống
- API/action:
alert.create,alert.acknowledge,alert.resolve,feedback.submit - Business rule: Alert bắt buộc có trường "căn cứ" (rule_id hoặc model_version + confidence) — không cho phát Alert "trống căn cứ"
- State: New → Acknowledged → InAction → Resolved → Verified → Closed (song song: → FalsePositive)
- Permission: theo vai trò được cấu hình nhận loại cảnh báo tương ứng vùng phụ trách
- Validation: không tạo Alert trùng cho cùng nguyên nhân trong cùng khung thời gian (chống spam)
- Audit: log toàn bộ vòng đời Alert + phản hồi đúng/sai để tính chỉ số chất lượng model
D. Dữ liệu
- Object: Alert, Recommendation, Incident (nếu leo thang), FeedbackRecord
- Field chính: alert_id, source(rule/model), basis, confidence, recipient_role, resolution, is_correct
- Quan hệ: Alert N–1 Analytics/Model; Alert 1–N Recommendation; Alert 1–1 FeedbackRecord
- Nguồn dữ liệu: Dữ liệu tổng hợp đã qua Data Quality (Phần G) — AI không được đọc dữ liệu chưa qua kiểm tra
- Chất lượng dữ liệu: confidence score bắt buộc hiển thị; dưới ngưỡng cấu hình → không tự động gửi, chờ Kỹ sư duyệt trước (Phần O)
- Lịch sử thay đổi: toàn bộ phản hồi đúng/sai được giữ lại làm tập huấn luyện lại model
E. Đầu ra
- Kết quả: vấn đề được xử lý hoặc được xác nhận là cảnh báo sai
- Dữ liệu mới: FeedbackRecord nạp lại vào Knowledge System (Phần O, Phần 16)
- Workflow tiếp theo: nếu cần hành động canh tác → tạo Task mới (quay lại Workflow 1)
- Báo cáo: tỷ lệ cảnh báo đúng/sai theo loại rule/model — chỉ số chất lượng AI (Phần T)
- AI: cải thiện model/ngưỡng confidence theo chu kỳ (Phần O — bước "Cải thiện tri thức/Model")
Kênh sử dụng: Mobile / Web / CMS / Admin / Partner Portal / Public Web
SUY LUẬN KIẾN TRÚC| Vai trò | Kênh chính | Lý do |
|---|---|---|
| Nông dân / Người lao động | Mobile | Ghi nhận tại hiện trường, cần camera + GPS |
| Kỹ sư | Mobile + Web/CMS | Xác minh tại chỗ (mobile) và xử lý hàng đợi/báo cáo (web) |
| Quản lý HTX / Quản lý Farm | Web + Mobile | Quản trị hàng ngày (web) + giám sát di động (mobile) |
| Kế toán / Thủ kho | Web/CMS | Nghiệp vụ bàn giấy, cần màn hình lớn, bảng biểu |
| Quản trị hệ thống | Admin Console | Cấu hình, RBAC, giám sát kỹ thuật |
| Quản trị tri thức | AI Console | Quản lý rule/knowledge base, duyệt phiên bản model |
| Buyer / Doanh nghiệp | Partner Portal / Web | Đặt hàng, theo dõi giao dịch, không cần cài app |
| Người tiêu dùng cuối | Public Traceability (Web) | Quét QR, không cần đăng nhập |
| Hệ thống IoT | System Automation | Không có giao diện người dùng, giao tiếp qua API/sensor |
| AI | AI Engine / Console | Xử lý nền, kết quả hiển thị qua các kênh khác (Alert, Recommendation) |
AI Decision Loop & Knowledge System
SUY LUẬN KIẾN TRÚCAI không được thiết kế như một chatbot đơn thuần. Mọi output AI trong OriginVN bắt buộc đi qua vòng lặp đầy đủ dưới đây, có con người xét duyệt trước khi thành hành động:
Knowledge System
Nền tảng tri thức đứng sau lớp Rule/Model — không phải một danh sách tĩnh mà có vòng đời xét duyệt riêng:
Thành phần
- Bộ tri thức (kiến thức nông học nền)
- Danh mục sâu bệnh, tình huống thường gặp
- Quy tắc cảnh báo (rule) gắn điều kiện cụ thể
- Căn cứ & kết luận kỹ sư cho từng tình huống đã xử lý
- Đánh giá đúng/sai của từng cảnh báo đã phát (Feedback)
Quản trị phiên bản
- Mỗi thay đổi rule/model tạo một phiên bản mới, không ghi đè
- Người duyệt quy tắc: Quản trị tri thức (xem Phần I)
- Phiên bản cũ vẫn giữ để so sánh hiệu năng (A/B) và để audit quyết định lịch sử
- Rollback được khi phiên bản mới cho kết quả tệ hơn
Finance theo từng giai đoạn
SUY LUẬN KIẾN TRÚCKhông gộp chung thành một khối "Finance" — 4 giai đoạn có bản chất tài chính khác nhau:
| Giai đoạn | Bản chất Finance | Dữ liệu đầu vào | Đối tượng phục vụ |
|---|---|---|---|
| GĐ1 | Hồ sơ hỗ trợ vay vốn (Financing Dossier) — hồ sơ tĩnh, tổng hợp thủ công theo yêu cầu | Nhật ký đã xác minh, thông tin Vùng trồng/Mùa vụ | Ngân hàng thẩm định |
| GĐ2 | Quản lý chi phí, công nợ, dòng tiền, bảo hiểm — vận hành tài chính hàng ngày của HTX/Farm | Chi phí, Đơn hàng, Giao dịch, Hợp đồng | Kế toán, Quản lý HTX |
| GĐ3 | Risk Forecasting + Financial Support — mô hình dự báo rủi ro tự động hỗ trợ thẩm định, không thay hồ sơ tĩnh GĐ1 | Toàn bộ dữ liệu GĐ1+GĐ2, model rủi ro | Ngân hàng/Bảo hiểm (thẩm định nhanh hơn) |
| GĐ4 | Supply Chain Finance + Wallet + tài chính nâng cao — tài chính dựa trên giao dịch thực tế đang diễn ra | Giao dịch Marketplace đã xác nhận, Risk Score | HTX (vốn lưu động), Buyer, tổ chức tài chính đối tác |
Marketplace / Ecosystem
SUY LUẬN KIẾN TRÚCKhông phải "danh bạ đối tác" — Marketplace là một chuỗi giao dịch có quản trị đầy đủ, tích hợp quyền dữ liệu (Phần H):
"Gợi ý phù hợp" ở cuối chuỗi quay lại đầu (Kết nối có quản lý) cho lượt giao dịch sau — đây là closed loop, không phải danh sách tĩnh. Quyền xem thông tin đối tác trong Marketplace tuân theo 5 tầng dữ liệu (Phần H): Buyer chỉ thấy dữ liệu Lô hàng ở Lớp 3 trừ khi HTX chủ động nâng cấp chia sẻ.
Carbon
SUY LUẬN KIẾN TRÚCTín chỉ carbon (GĐ4) được tính từ dữ liệu canh tác bền vững đã xác minh nhiều mùa vụ (GĐ1), không phải ước tính rời rạc. Quy trình: Dữ liệu canh tác đã xác minh nhiều mùa → Áp phương pháp tính CO2e CẦN CHỐT (phương pháp luận cụ thể cần đơn vị chứng nhận carbon xác nhận) → Hồ sơ Carbon Credit → Xác minh bởi đơn vị thứ ba → Niêm yết trên Marketplace Carbon → Giao dịch → Báo cáo ESG (liên kết Phần K/GĐ4).
Open Platform
SUY LUẬN KIẾN TRÚCOpen API + White-label + DaaS (GĐ4) cho phép bên thứ ba (đối tác công nghệ nông nghiệp, tổ chức nghiên cứu, chính phủ) tích hợp hoặc vận hành lại nền tảng dưới thương hiệu riêng. Chỉ expose dữ liệu Lớp 3–4 (Phần H) qua API có xác thực + giới hạn tốc độ (rate limit); không bao giờ expose trực tiếp Lớp 1–2. White-label dùng chung Master Data Model (Phần E) và State Machine (Phần J) để đảm bảo dữ liệu liên thông được giữa các instance.
Mô hình doanh thu
ĐỀ XUẤT| Nguồn doanh thu | Mô tả | Giai đoạn áp dụng |
|---|---|---|
| SaaS | Phí thuê bao theo gói cho HTX/Farm sử dụng nền tảng vận hành | GĐ1+ |
| Supply Chain Finance | Phí/chênh lệch lãi suất từ dịch vụ tài chính chuỗi cung ứng | GĐ4 |
| AI & Advanced Analytics | Phí truy cập tính năng AI nâng cao, BI | GĐ3+ |
| Integration | Phí tích hợp hệ thống (IoT, ERP đối tác, Open API) | GĐ2, GĐ4 |
| Specialist Support | Dịch vụ kỹ sư/chuyên gia đi kèm gói cao cấp | GĐ1+ |
| Marketplace-related | Hoa hồng/phí niêm yết giao dịch Marketplace | GĐ4 |
| Insurance | Phí giới thiệu/hoa hồng sản phẩm bảo hiểm nông nghiệp | GĐ2 (cơ bản), GĐ4 (nâng cao) |
| Partner services | Phí đối tác trong hệ sinh thái (đơn vị chứng nhận, logistics...) | GĐ2+ |
| DaaS | Bán dữ liệu tổng hợp Lớp 4 dưới dạng dịch vụ | GĐ4 |
Measurement & Value Loop
SUY LUẬN KIẾN TRÚCKhung KPI
| Trường | Bắt buộc có |
|---|---|
| KPI | Tên chỉ số, ví dụ: % nhật ký được xác minh trong 48h |
| Công thức | Cách tính rõ ràng, không mơ hồ |
| Nguồn dữ liệu | Object/bảng dữ liệu cụ thể |
| Kỳ đo | Ngày/tuần/tháng/mùa vụ |
| Phạm vi | Cấp Lô / Mùa vụ / HTX / Toàn hệ thống |
| Chất lượng dữ liệu | Ngưỡng tối thiểu dữ liệu hợp lệ để KPI đáng tin |
| Người chịu trách nhiệm | Vai trò sở hữu chỉ số |
| Lịch sử phiên bản | Thay đổi công thức KPI phải versioned |
Value Loop
Vòng lặp này là bằng chứng OriginVN tạo ra giá trị thực — không dừng ở "có dữ liệu" mà phải khép vòng về "cải thiện hệ thống".
Field Pilot 100ha
THEO NGƯỜI DÙNG NÊUBước 0 — Baseline (bắt buộc, làm trước khi số hoá) ĐỀ XUẤT — bổ sung theo yêu cầu đo lường giá trị
Tài liệu gốc chưa có bước này; bổ sung vì không đo "trước" thì không thể chứng minh OriginVN tạo giá trị gì ở Phần T (Value Loop). Đo 1 lần, trước ngày số hoá đầu tiên, trên chính 100ha pilot:
| Chỉ số baseline | Cách thu thập |
|---|---|
| Năng suất mùa vụ gần nhất (tấn/ha) | Phỏng vấn/hồ sơ giấy hiện có của hộ tham gia |
| Thời gian ghi chép thủ công hiện tại (phút/ngày/hộ) | Khảo sát trực tiếp trước triển khai |
| Tỷ lệ hộ từng tiếp cận vốn vay nông nghiệp | Khảo sát trực tiếp |
| Chi phí vật tư trung bình/ha mùa gần nhất | Hồ sơ/khảo sát hộ tham gia |
Khung mục tiêu pilot ĐỀ XUẤT
| Hạng mục | Mục tiêu đề xuất | Cách kiểm chứng |
|---|---|---|
| Tỷ lệ số hoá Lô/Mùa vụ | 100% diện tích pilot có hồ sơ Lô + Mùa vụ trên hệ thống | Đối chiếu diện tích đăng ký GPS vs. thực địa |
| Tỷ lệ nhật ký được xác minh | ĐỀ XUẤT ĐÃ ÁP DỤNG SLA xác minh ≤ 48 giờ — chọn mốc nhanh hơn khung 48–72h ban đầu vì Chủ dự án ưu tiên triển khai sớm; cần đủ kỹ sư trực hàng đợi mới giữ được mốc này khi vào mùa cao điểm | Báo cáo thời gian xử lý hàng đợi xác minh |
| Lô hàng có truy xuất QR | 100% sản lượng thu hoạch trong pilot được gắn Lô hàng + QR | Đối chiếu sản lượng khai báo vs. số Lô hàng phát hành |
| Hồ sơ hỗ trợ vay vốn | Số hồ sơ Financing Dossier được tạo từ dữ liệu pilot | Đếm hồ sơ hợp lệ đã xuất cho ngân hàng |
| Chất lượng dữ liệu | Tỷ lệ bản ghi vi phạm Data Quality (Phần G) giảm dần qua các đợt | Báo cáo tự động từ bước Kiểm tra trong Data Lifecycle |
Đầu ra pilot cụ thể (sản lượng thực tế, số hộ tham gia, kết quả tiếp cận tài chính...) CẦN CHỐT — cần lấy từ báo cáo pilot thật của Chủ dự án, không được suy diễn.
Acceptance / Definition of Done
SUY LUẬN KIẾN TRÚCMẫu chuẩn áp dụng cho mọi module — Dev dùng để xây dựng, Chủ dự án dùng để nghiệm thu.
| Trường | Nội dung bắt buộc |
|---|---|
| Actor | Vai trò khởi tạo hành động (theo Phần I) |
| Trigger | Sự kiện làm khởi phát workflow |
| Input | Dữ liệu/trạng thái tiền đề bắt buộc phải có |
| Validation | Quy tắc kiểm tra áp dụng (tham chiếu Phần G nếu có) |
| Process | Các bước xử lý chính, theo đúng thứ tư duy Business→Object→Data→Relation→State→Permission→Workflow→Screen→API→Output |
| State | Trạng thái trước/sau, map vào State Machine chuẩn (Phần J) |
| Output | Kết quả + dữ liệu mới tạo ra |
| Permission | Ai được phép thực hiện từng bước (Phần I) |
| Audit | Sự kiện bắt buộc ghi log |
| Exception | Trường hợp lỗi/ngoại lệ và cách xử lý |
| Next workflow | Workflow kế tiếp được kích hoạt |
| Test case | Kịch bản kiểm thử tối thiểu (happy path + 1 exception path) |
| Acceptance criteria | Điều kiện "Done" bằng ngôn ngữ nghiệp vụ, đo lường được |
Ví dụ áp dụng — Module Nhật ký canh tác (GĐ1)
| Actor | Nông dân / Người lao động |
| Trigger | Hoàn thành một Công việc ngoài đồng |
| Input | Task ở trạng thái hợp lệ, quyền ghi trên Lô, camera+GPS thiết bị hoạt động |
| Validation | 12 quy tắc Data Quality (Phần G) |
| Process | Chọn Task → nhập hoạt động/vật tư → chụp ảnh → hệ thống gắn GPS/timestamp → Kiểm tra tự động → Gửi |
| State | DRAFT → SUBMITTED → PENDING_VERIFICATION |
| Output | Bản ghi Diary mới, liên kết Task + Input |
| Permission | Chỉ người được phân công trên Lô đó (Phần I) |
| Audit | Log tạo bản ghi kèm actor, timestamp, giá trị nhập |
| Exception | Mất mạng → lưu offline, đồng bộ khi có mạng; thiếu trường bắt buộc → chặn Gửi |
| Next workflow | Xác minh bởi Kỹ sư (Workflow 1, Phần M) |
| Test case | (1) Gửi hợp lệ đầy đủ ảnh+GPS → SUBMITTED. (2) Gửi thiếu ảnh → bị chặn, hiển thị lỗi rõ ràng |
| Acceptance criteria | Nông dân ghi được nhật ký ngoài đồng không cần mạng; Kỹ sư nhận được đầy đủ bằng chứng để ra quyết định xác minh mà không cần đi thực địa trong đa số trường hợp |
Logic Audit — Cần Chủ dự án chốt
CẦN CHỐTToàn bộ điểm chưa đủ đặc tả trong tài liệu này, tổng hợp lại một chỗ — không tự quyết thay Chủ dự án. Sau buổi làm việc ngày 18/9/2026, một số điểm đã được Chủ dự án chốt hoặc được áp dụng mặc định để kịp tiến độ 15 ngày; các điểm này chuyển sang bảng "Đã xử lý" bên dưới — nhưng vẫn có thể điều chỉnh lại bất kỳ lúc nào.
Đã chốt / đã áp dụng mặc định (18/9/2026)
| # | Điểm | Quyết định | Loại |
|---|---|---|---|
| 1 | Thời lượng từng giai đoạn GĐ1–GĐ4 | GĐ1=15 ngày, GĐ2=30 ngày, GĐ3=60 ngày (Chủ dự án nêu trực tiếp); GĐ4≈120 ngày (suy theo quy luật, còn chờ xác nhận số chính xác) | ĐÃ CHỐT (GĐ4: ĐỀ XUẤT) |
| 2 | Phạm vi module GĐ1 | Giữ nguyên "bình thường" — đủ 10 module như đã liệt kê, không rút gọn; triển khai song song 3 mũi để kịp 15 ngày (xem trình tự ở Phần K) | ĐÃ CHỐT |
| 3 | Phạm vi áp dụng Blockchain GĐ1 | Chỉ hash bản ghi đã VERIFIED, không lưu dữ liệu thô trên chain — áp dụng mặc định để kịp 15 ngày | ĐỀ XUẤT ĐÃ ÁP DỤNG |
| 4 | Ngưỡng SLA xác minh nhật ký | ≤48 giờ — áp dụng mặc định, ưu tiên tốc độ; cần đủ nhân sự kỹ sư trực để giữ được mốc này | ĐỀ XUẤT ĐÃ ÁP DỤNG |
Còn lại — cần Chủ dự án chốt
| # | Điểm cần chốt | Vị trí trong tài liệu | Vì sao chưa chốt được |
|---|---|---|---|
| 5 | Rủi ro chấp nhận: 15 ngày cho đủ 10 module GĐ1 đòi hỏi làm song song 3 mũi ngay từ đầu — cần xác nhận có đủ nhân sự chia 3 mũi hay không, nếu không cần lùi mốc hoặc chấp nhận Mũi B/C trễ sang GĐ2 | Phần K | Phụ thuộc năng lực đội ngũ thực tế, ngoài phạm vi kiến trúc phần mềm |
| 6 | Số ngày chính xác GĐ4 (hiện suy đoán ~120 ngày theo quy luật nhân đôi) | Phần K | Chủ dự án chưa nêu số cụ thể ("vvv") |
| 7 | Số module chính xác GĐ1 (đối chiếu với danh sách gốc thật nếu khác 10, brief gốc có nêu mâu thuẫn mẫu "9 module" vs "Module 1→10") | Phần K | Tài liệu này dựng lại danh sách từ đầu, chưa đối chiếu được với bản gốc thật |
| 8 | Thời hạn lưu trữ hoạt động vs. lưu trữ lạnh theo từng loại dữ liệu | Phần H | Phụ thuộc quy định pháp lý ngành hàng cụ thể, cần Chủ dự án/pháp lý xác nhận |
| 9 | Chính sách dữ liệu khi HTX rời hệ thống | Phần H | Cần quyết định kinh doanh + pháp lý, không thể suy luận kiến trúc thuần tuý |
| 10 | Phân quyền field-level chi tiết theo ngành hàng (VD: ai xem GPS chi tiết) | Phần I | Cần khảo sát yêu cầu thực tế từng ngành hàng triển khai |
| 11 | Phương pháp luận tính CO2e cho Carbon Credit | Phần R | Cần chuẩn quốc tế/đơn vị chứng nhận carbon xác nhận, ngoài phạm vi kiến trúc phần mềm |
| 12 | Toàn bộ nội dung tài liệu này nói chung | Toàn tài liệu | Được dựng lại từ đầu do phiên làm việc không có V12–V15 và các file nguồn khác; cần chạy lại quy trình hợp nhất (Phần 33 của brief gốc) khi có đủ tài liệu thật |
Traceability Matrix
SUY LUẬN KIẾN TRÚCVì không có nhiều file nguồn để đối chiếu trong phiên này, ma trận dưới đây truy vết theo 3 nguồn thực tế đã dùng để xây dựng tài liệu — thay cho việc đối chiếu V12–V15 (chưa tồn tại trong phiên).
| Nguồn | Nội dung | Đã đưa vào đâu | Trạng thái |
|---|---|---|---|
| Bối cảnh OriginVN đã lưu (memory) | Mô hình GHI NHẬN→XÁC MINH→QUẢN LÝ→TRUY XUẤT; danh sách vai trò; quy tắc không nhận mockup là đã triển khai | Phần A, Phần I, toàn bộ nhãn tag | Đã hợp nhất |
| Yêu cầu xây dựng tài liệu (prompt người dùng) | Toàn bộ cấu trúc 37 mục, chuỗi lõi hệ thống, pilot 100ha Hàm Thuận Bắc, quy tắc nhãn ĐỀ XUẤT/CẦN CHỐT/THEO NGUỒN/SUY LUẬN | Toàn bộ Phần A–Y, cấu trúc nav, hệ thống nhãn | Đã hợp nhất |
| Suy luận kiến trúc Claude (không có file nguồn) | Data model chi tiết, workflow 5 lớp, state machine, permission matrix, AI loop, finance theo GĐ... | Phần E–T | Đã xây dựng mới, cần Chủ dự án đối chiếu với tài liệu thật khi có |
| Project Master V12–V15 (nêu trong brief) | — | Không có trong phiên này | CHƯA NHẬN ĐƯỢC — cần bổ sung để chạy lại hợp nhất |
| Các bộ khung governance/knowledge/ecosystem/đo lường riêng lẻ (nêu trong brief) | — | Không có trong phiên này | CHƯA NHẬN ĐƯỢC |
Duplication Audit
SUY LUẬN KIẾN TRÚCCác khái niệm cố ý xuất hiện ở nhiều phần — xác định rõ vai trò khác nhau ở mỗi nơi, không phải trùng lặp thừa:
| Nội dung | Xuất hiện ở | Loại | Cách xử lý |
|---|---|---|---|
| Nhật ký | Phần E (object), Phần F (lifecycle), Phần G (quality), Phần M (workflow) | Trùng bổ sung | Giữ — mỗi nơi mô tả một lát cắt khác nhau (cấu trúc dữ liệu / vòng đời / quy tắc kiểm tra / luồng nghiệp vụ đầy đủ). Không gộp vì mất chi tiết. |
| Xác minh | Phần E, Phần I (permission), Phần J (state), Phần M (workflow) | Trùng bổ sung | Liên kết chéo bằng anchor link thay vì lặp lại nội dung — Phần I/J tham chiếu ngược Phần M |
| Quyền / Permission | Phần H (Governance), Phần I (Role Matrix) | Trùng bổ sung | Một nguồn chuẩn: Phần I là ma trận chi tiết; Phần H chỉ nêu nguyên tắc quản trị — không lặp bảng |
| AI | Phần K–GĐ3 (danh sách tính năng), Phần O (AI Decision Loop + Knowledge), Phần P (Finance/Risk) | Trùng bổ sung | Tách lớp: GĐ3 = phạm vi tính năng theo lộ trình; Phần O = cơ chế vận hành AI; Phần P = ứng dụng AI riêng cho tài chính |
| Finance / Tài chính | Phần K (từng GĐ nêu sơ lược), Phần P (chi tiết theo GĐ), Phần Rev (doanh thu) | Trùng bổ sung | K nêu tên tính năng; P giải thích bản chất tài chính từng GĐ; Rev là góc nhìn doanh thu OriginVN — 3 góc nhìn khác nhau, giữ cả ba |
| Trạng thái / State | Phần F (Data Lifecycle), Phần J (State Machine) | Giống ý nhưng khác mức chi tiết | F = vòng đời dữ liệu tổng quát (12 bước); J = state machine kỹ thuật chuẩn hoá (DRAFT→...→USED) dùng để code. Giữ cả hai, J là "nguồn chuẩn" cho Dev implement |