Nemo12 Audit Standard — AS-01..AS-10 (v0.2)
Bộ tiêu chuẩn để audit toàn bộ hệ thống Nemo12: docs, sản phẩm, kiến trúc, dữ liệu, thuật toán, nội dung, bảo mật, vận hành, trải nghiệm, AI.
v0.2 nâng cấp v0.1 sau khi hai vòng phản biện độc lập chạy thật phần lớn "cách kiểm" đề xuất (không chỉ đọc) và đối chiếu với một sự cố production thật xảy ra ngay trong lúc soạn tài liệu này. Kết luận chính: giữ nguyên bất biến "mỗi chỉ báo chỉ PASS hoặc KHÔNG PASS", không thêm thang điểm — nhưng sửa cách chỉ báo được viết, cách 🔴 được gắn, và cách một lần KHÔNG PASS được đọc, để 44% không còn bị hiểu nhầm thành "hệ hỏng 57%".
10 bộ (AS-01..AS-10)
├── 9 bộ × 5 tiêu chí × 5 chỉ báo = 225 chỉ báo
└── AS-04 × 6 tiêu chí × 5 chỉ báo = 30 chỉ báo (mới: 4.6 Đối soát production)
─────────────
255 chỉ báo · PASS | KHÔNG PASS (nhị phân)Khác với Quality Gates — QG là cổng chặn thay đổi (từng PR/từng publish); AS là thước đo trạng thái toàn hệ tại một thời điểm. Bảng ánh xạ AS ↔ QG ở §14.
0. Mâu thuẫn với PRD-001 — cần chủ dự án quyết, tài liệu này không tự ý xử lý
Sửa audit-standard.md làm hai câu trong PRD-001 (ngoài phạm vi sửa của lần cập nhật này) trở nên không khớp 100% nữa. Ghi rõ ở đây thay vì im lặng:
- REQ-DOC-05 mô tả cấu trúc "10 bộ × 5 tiêu chí × 5 chỉ báo". Từ v0.2, AS-04 có 6 tiêu chí (lý do ở §1). Cần một bản sửa nhỏ ở PRD-001 khi có phiên chạm tới file đó — không phải việc của agent này trong lần chạy này.
- REQ-DOC-06 khoá ngưỡng mở thử người dùng thật ở "≥90% (225/250) chỉ báo PASS" — một số tuyệt đối gắn với mẫu số v0.1. Mẫu số v0.2 là 255, và bản thân REQ-DOC-06 cấm rõ "hạ chuẩn bằng cách sửa tiêu chuẩn thay vì sửa hệ" — nên tài liệu này cố ý không tự diễn giải lại con số 225 theo hướng có lợi. Đọc đúng luật hiện hành: sàn vẫn là 225 chỉ báo PASS tuyệt đối (tức ~88% của 255 — CHẶT hơn 90% của 250 một chút, không lỏng hơn) cho tới khi chủ dự án tự tay sửa con số trong PRD-001.
- Khoảng cách tới ngưỡng đó, đối chiếu thời gian còn lại: hệ đang ở 109/250 (44%, Audit #001). Audit #001 §4 tự ước lượng ~11 ngày-người chỉ để đóng 15/26 chỉ báo 🔴 gốc — chưa tính ~126 KHÔNG PASS còn lại. Bài học thực địa ghi nhận 2 ngày nữa là mở thử cho 10 phụ huynh thật. Về mặt toán, đóng thêm ~116 chỉ báo (109 → 225) trong 2 ngày là bất khả thi, không phải vì v0.2 làm khó thêm, mà vì khoảng cách đã tồn tại từ trước khi có v0.2.
- Tài liệu này không có thẩm quyền hạ REQ-DOC-06 để lách khoảng cách đó. Thay vào đó, §3.3 định nghĩa một Pilot Gate — một tập con hẹp (~18 chỉ báo, gắn 🚸) làm điều kiện bổ sung, không thay thế. Nếu chủ dự án chấp nhận mở thử khi Pilot Gate 100% PASS nhưng điểm hệ toàn phần chưa đạt REQ-DOC-06, đó phải là một quyết định tường minh của chủ dự án, ghi vào
open-questions/index.mdvới ✍️ hoặc phê duyệt trực tiếp — không phải điều audit-standard tự quyết thay.
2. Luật chấm
| Luật | Nội dung |
|---|---|
| L1 — Nhị phân | Mỗi chỉ báo chỉ có PASS hoặc KHÔNG PASS. Cấm "một phần", "gần đạt", "đang làm". Bất biến này không đổi từ v0.1. |
| L2 — Cấm N/A, bắt buộc mã lý do khi KHÔNG PASS | Không có trạng thái N/A. Nếu phần hệ thống liên quan chưa tồn tại, chỉ báo = KHÔNG PASS. Trong báo cáo (không phải trong bảng chỉ báo), mọi dòng KHÔNG PASS phải kèm đúng một mã: CX (chưa xây) / CM (chưa chứng minh) / HH (hỏng) — định nghĩa ở §1.1. |
| L3 — Không bằng chứng = KHÔNG PASS | Mỗi PASS phải kèm bằng chứng kiểm chứng lại được: file:line, output lệnh, query D1, hoặc ảnh màn hình. Không có bằng chứng thì mặc định KHÔNG PASS, mã lý do mặc định CM trừ khi người chấm chứng minh được đó là CX hoặc HH. |
| L4 — Một phản ví dụ là đủ | Chỉ báo dạng "mọi/không có…" chỉ cần một trường hợp vi phạm là KHÔNG PASS (và mã lý do khi đó luôn là HH — có phản ví dụ thật thì không thể là "chưa xây"). |
| L5 — Chấm hệ đang chạy | Chấm trên main + production thực tế, không chấm trên nhánh nháp hay ý định. |
| L6 — 🔴 chặn release, 🚸 chặn Pilot Gate — hai cổng khác tầng | 🔴 KHÔNG PASS chặn release nói chung bất kể tổng điểm cao bao nhiêu (không đổi từ v0.1). 🚸 là tập con của các chỉ báo (một số cũng 🔴, một số không) làm điều kiện go/no-go riêng cho đợt mở thử 2 ngày tới — xem §3.3. Hai cổng không thay thế nhau. |
| L7 — Ngoại lệ hạ tầng phải viết ngay tại chỗ | Chỉ báo nào đòi hạ tầng có thể không mua được (GitHub Pro, Cloudflare Access, API token scope riêng…) phải nêu nhánh thoát tường minh ngay trong cột "cách kiểm" của chính nó — không được im lặng để KHÔNG PASS vĩnh viễn vì lý do ngoài tầm kỹ thuật. |
| L8 — Không hồi tố | Chỉ báo mới hoặc chỉ báo đổi từ "toàn bộ lịch sử" sang "có mốc" chỉ tính từ mốc được nêu tường minh trong chính chỉ báo đó trở đi, trừ khi ghi rõ khác. |
3. Cách tính điểm
3.1 Công thức
- Điểm tiêu chí = số chỉ báo PASS / 5. Tiêu chí ĐẠT khi và chỉ khi 5/5. (đúng cho mọi tiêu chí — kể cả 6 tiêu chí của AS-04, mỗi tiêu chí vẫn luôn có đúng 5 chỉ báo).
- Điểm bộ = số chỉ báo PASS / (5 × số tiêu chí trong bộ). Với 9 bộ là /25; riêng AS-04 là /30.
- Điểm hệ = tổng chỉ báo PASS / 255.
| Tỷ lệ | Mức trưởng thành | Ý nghĩa |
|---|---|---|
| < 50% | Sơ khai | Hệ chạy được nhưng chưa kiểm soát được. |
| 50–69% | Đang dựng | Có khung, nhiều chỗ hở. |
| 70–84% | Vững | Kiểm soát được phần lớn; hở ở rìa. |
| 85–94% | Chín | Đủ chuẩn vận hành thật với người dùng thật. |
| ≥ 95% | Chuẩn mực | Có thể mở rộng quy mô mà không sợ vỡ. |
Điều kiện release (dài hạn): không có 🔴 nào KHÔNG PASS, và không bộ nào dưới 60%, và điểm hệ ≥ 70%. (REQ-DOC-06 đặt thêm sàn riêng cho lần đầu mở người dùng thật: ≥225/255 tuyệt đối — xem §0.)
3.2 Đọc điểm cho đúng — bắt buộc tách theo mã lý do
Một con số % một mình không đủ để đọc đúng. Mọi báo cáo phải kèm bảng tách KHÔNG PASS theo mã CX/CM/HH (mẫu ở § Mẫu báo cáo). Quy tắc đọc: %HH trong tổng KHÔNG PASS là chỉ số duy nhất phản ánh "hệ đang hỏng"; %CX phản ánh việc chưa xây (kỳ vọng cao ở giai đoạn này); %CM phản ánh nợ chứng minh (thường đóng được nhanh — chỉ cần đi rà/viết bằng chứng, không cần sửa code).
3.3 Pilot Gate — điều kiện mở thử 2 ngày tới
REQ-DOC-06 khoá "mở thử người dùng thật" vào điểm hệ toàn phần (≥225/255) — về toán, không đạt được trong 2 ngày từ mốc 109/250 hiện tại (§0). Pilot Gate là một cơ chế bổ sung, không thay thế: một tập ~18 chỉ báo 🚸 mà 100% phải PASS trước khi cho 10 phụ huynh thật + trẻ em thật vào hệ — chọn theo tiêu chí "chạm thẳng dữ liệu trẻ em thật, tiền thật, hoặc mất-dữ-liệu-không-hồi-phục-được". Danh sách đầy đủ + lý do từng dòng ở § Pilot Gate — danh sách đầy đủ. Nếu chủ dự án chọn mở thử khi Pilot Gate đạt 100% nhưng điểm hệ toàn phần chưa chạm 225/255, đây phải là quyết định tường minh ghi vào open-questions/index.md — không phải điều audit-standard tự diễn giải thay.
Các trang
Trước SRC-1322 (10.10.2026) toàn bộ Audit Standard nằm trong một file. Nay mỗi trang dưới đây đọc độc lập được; mọi mã chỉ báo AS-xx.y.z giữ nguyên chữ ở đúng một trang. Nội dung giữ nguyên chữ, chỉ đổi chỗ.
| Trang | Mục | Nội dung |
|---|---|---|
| Audit Standard · AS-01 tới AS-03 | AS-01, AS-02, AS-03 | Chỉ báo AS-01 tài liệu và đóng vết, AS-02 yêu cầu và sản phẩm, AS-03 kiến trúc và hợp đồng API, kèm ngoại lệ tường minh. |
| Audit Standard · AS-04 tới AS-06 | AS-04, AS-05, AS-06 | Chỉ báo AS-04 dữ liệu và migration (6 tiêu chí), AS-05 trí tuệ học tập và thuật toán, AS-06 nội dung và tri thức. |
| Audit Standard · AS-07 tới AS-10 | AS-07, AS-08, AS-09, AS-10 | Chỉ báo AS-07 bảo mật và riêng tư, AS-08 tin cậy và vận hành, AS-09 trải nghiệm và design system, AS-10 AI governance và chi phí. |
| Audit Standard · Chặn phát hành, Pilot Gate, quy trình và mẫu báo cáo | Danh sách 🔴, Pilot Gate, §13, §14, §15 | Danh sách 30 chỉ báo chặn phát hành, Pilot Gate đầy đủ, quy trình audit, ánh xạ AS và QG, mẫu báo cáo audit. |
| Audit Standard · Lịch sử quyết định | §1, Hướng dẫn chuyển đổi v0.1 → v0.2 | Đổi gì từ v0.1 sang v0.2 và vì sao, từng quyết định §1.1 tới §1.15, và cách đối chiếu điểm số giữa hai phiên bản. |
16. Trace
- Nguồn: SRC-108 (chỉ đạo 2026-08-15 — dựng tiêu chuẩn audit toàn hệ).
- Đáp ứng: REQ-DOC-05, REQ-DOC-06 (xem §0 cho phần chưa khớp 100%, cần chủ dự án xử lý ở PRD-001).
- Kiểm chứng chính bộ tiêu chuẩn này: QG-001 (tính toàn vẹn tài liệu), QG-002 (chất lượng yêu cầu).
- Lịch sử phiên bản: v0.1 (2026-08-15, chấm ở Audit #001, 109/250) → v0.2 (2026-08-15, cùng ngày — nâng cấp sau hai vòng phản biện chạy thật + một sự cố production thật xảy ra trong lúc soạn; xem §1).
Lịch sử quyết định
Đổi gì từ v0.1 sang v0.2, lý do từng thay đổi, và cách đối chiếu điểm giữa hai phiên bản: Lịch sử quyết định.