AI79 Professional EA Framework #30

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư, chứng nhận hệ thống hoặc tín hiệu giao dịch.

Trả lời ngắn: AI79 Professional EA Framework là bản đồ năm tầng và mười mandatory gate để nối design, trading/risk engines, evidence, operations và release decision. Framework buộc mỗi gate có owner, artifact, kết quả và stop rule; nó không phải code template, chiến lược, chứng nhận production-ready hay lời hứa lợi nhuận.

Đọc xong, bạn sẽ hiểu:

• Cách gom 29 bài trước thành năm tầng có thứ tự.
• Cách dùng mười mandatory gate thay cho một checklist “có vẻ đủ”.
• Vì sao case EA30-RC1 all-pass vẫn chỉ sẵn sàng cho controlled demo canary.

1. AI79 Professional EA Framework là gì?

Framework là bản đồ giúp ra quyết định nhất quán. Framework này không viết thay EA và không chọn chiến lược. Nó hỏi năm việc: hệ thống được thiết kế ra sao, quyết định trading bị kiểm soát thế nào, evidence có cố phá giả định không, operations có giữ đúng identity/state không, và ai có quyền mở release.

Mỗi điều kiện bắt buộc gọi là mandatory gate. Một gate FAIL không được bù bằng chín gate PASS. Hãy nghĩ đến checklist cất cánh: ghế ngồi đẹp và nhiên liệu đủ không bù được một cửa chưa khóa. Phép ví này chỉ giải thích logic “mọi điều kiện bắt buộc”, không nói trading có tiêu chuẩn an toàn giống hàng không.

Hình 1 — Framework nối design đến release bằng owner, evidence và stop rule; không bảo đảm lợi nhuận.

Một dòng trong gate sheet cần:

• Gate ID và câu hỏi;
• owner chịu trách nhiệm;
• artifact/version được kiểm;
• evidence và timestamp;
• PASS, FAIL hoặc UNKNOWN;
• reason và next action;
• stop/exit rule.

UNKNOWN không phải “gần pass”. Nếu không xác minh được config hash, account identity hoặc kill state, new execution phải block theo contract bài.

Tôi từng gom mọi thứ vào một checklist dài; sai vì checklist không map owner/evidence thì chỉ là danh sách. Người tick ô có thể đang kiểm artifact khác, dùng report cũ hoặc tự duyệt chính thay đổi của mình.

Framework có hai ranh giới:

1. Technical eligibility: evidence cho artifact cụ thể đã đạt contract kỹ thuật.
2. Authority approval: đúng người/pháp nhân có quyền đã cho phép đúng scope.

Local tests không tự tạo authority. Demo evidence không tự tạo live-capital approval. All-pass cũng không biến strategy thành chắc thắng.

2. Bản đồ năm tầng nối toàn bộ series

Tầng 1 — Design Contract

Tầng này gom kiến trúc EA, tick/bar/event, state machine, position/order ownership và money management. Mục tiêu là biết component nào sở hữu state nào, event nào làm state chuyển và điều kiện nào bị cấm.

Invariant là điều phải luôn đúng. Ví dụ: mỗi request ID chỉ được xử lý một lần; position state không được suy ra chỉ từ một send return; kill state không được strategy tự xóa.

Tầng 2 — Trading + Risk Engines

Signal đề xuất; filter kiểm context; risk engine áp cap/invariant; session/news/volatility engines kiểm môi trường. Grid, DCA, hedging, basket, recovery và adaptive sizing đều là behavior cần bounded state, không phải cách né risk.

Tầng này hỏi: khi signal đẹp nhưng data stale, session cấm hoặc portfolio cap đầy, thành phần nào có quyền nói không? Câu đúng phải là independent control, không phải strategy tự giảm nhẹ rồi tự duyệt.

Tầng 3 — Adversarial Evidence

Adversarial evidence là bằng chứng được tạo bằng cách cố làm hệ thống sai: data gap, spread change, reordered result, duplicate request, parameter perturbation, window shift, latency và disconnect. Backtest, walk-forward, Monte Carlo, parameter/robustness test và live validation nằm ở đây.

Evidence tốt không chỉ cho đường chạy đẹp. Nó phải ghi rejection, failure và recovery path. 7/7 reject cases PASS thường có giá trị kiểm soát khác với thêm một equity curve.

Tầng 4 — Operations + Governance

Portfolio, VPS, multi-account, AI adapter và institutional architecture đi vào vận hành: release identity, config, account mapping, permission, heartbeat, monitoring, reconciliation, incident, rollback và approval.

NIST Zero Trust khuyên không cấp implicit trust chỉ vì user/service nằm trong mạng nội bộ, đồng thời nhấn mạnh identity và least privilege (NIST SP 800-207). Với EA, một worker “nội bộ” vẫn chỉ cần quyền đúng account và nhiệm vụ.

Tầng 5 — Release Decision

Tầng cuối không hỏi “có thích strategy không”. Nó hỏi đúng artifact có đủ mandatory evidence, owner, approval và exit criteria chưa. Exit criteria là điều kiện kết thúc test hoặc dừng rollout.

Hình 2 — Bài học chỉ có giá trị vận hành khi được map vào gate, owner và evidence chain.

AWS Well-Architected dùng các trụ như operational excellence, security và reliability để đánh giá workload; reliability gồm recovery khỏi disruption, còn operations cần quan sát và phản ứng sự kiện (AWS — Well-Architected pillars). Đây là nguồn kiến trúc chung, không phải trading regulation.

3. Mười gate từ design đến release

G1–G5: hệ thống có control path rõ không?

G1 Architecture/state ownership: module, event, state transition, forbidden transition và owner đã định nghĩa.

G2 Data/schema/session: data source, timezone, session, precision, missing/stale policy và schema version được khóa.

G3 Signal/filter separation: proposal tách khỏi filters; outcome có allow/reject/abstain reason.

G4 Risk invariants: account, position, exposure, portfolio cap, margin, kill state và recovery boundary được test.

G5 Execution/idempotency/reconciliation: request có idempotency; send, acknowledgement, transaction, fill và position được phân biệt; ledger reconcile expected/actual/delta.

MQL5 xử lý event tuần tự, và OnTradeTransaction arrivals không bảo đảm một thứ tự transaction giản đơn; account state còn có thể đổi trong lúc handler đang xử lý (MQL5 — Event Handling, MQL5 — OnTradeTransaction). Vì vậy, G5 không được giả định “send xong là state cuối”.

G6–G10: evidence và authority có cùng artifact không?

G6 Backtest integrity: dataset, modeling mode, spread/session/timezone, gap và build/config identity có evidence.

G7 Walk-forward/Monte Carlo/robustness: parameter freeze, out-of-sample windows và perturbation rule được định nghĩa trước khi xem kết quả.

G8 Shadow/live validation: chạy với data/runtime thật nhưng zero request; so sánh expected behavior, latency, reject mix và drift.

G9 Deployment/identity/observability/kill: VPS/account/release/config đúng; heartbeat, alerts, reconciliation và kill drill có owner.

G10 Approvals/release artifact: code, config, data fixture, schema, policy, test report và approvals cùng trỏ vào một release candidate.

Hình 3 — Gate chạy theo thứ tự; FAIL hoặc UNKNOWN rơi vào block, không dùng majority vote.

Evidence chain là chuỗi nối release candidate → artifact hashes → test run → result → approval → deployment scope. Release candidate là bộ artifact đang chờ quyết định; tên RC không có nghĩa đã được release.

FINRA Notice 15-09 là guidance cho member firms Mỹ và nêu independent QA, test controls, data/workflow validation, test record, môi trường test tách production, cùng monitoring/alerts/reconciliation sau deploy (FINRA 15-09). SEC Rule 15c3-5 áp dụng cho broker-dealer có market access tại Mỹ, với pre-set controls, authorized access, post-trade report và documented review (SEC — Market Access Rule). Hai nguồn giúp soi nguyên tắc; bài không tuyên bố chúng áp dụng trực tiếp cho mọi EA.

4. Case PF30: EA30-RC1 qua local evidence

Case giả lập:

• Contract PF30:RELEASE:V1
• Candidate EA30-RC1
• Build EA30-B7
• Config CFG30-C2
• Data DS30-20260726

Các count/threshold sau là lesson contract, không phải chuẩn ngành:

Hình 4 — All-pass chứng minh case đạt lesson contract; không tự biến demo eligibility thành live approval.

G5 reconcile:

delta = expected - actual = 24 - 24 = 0

G8 shadow chỉ quan sát; requests 0. Production orders 0. Verdict:

READY FOR CONTROLLED DEMO CANARY · NOT LIVE CAPITAL APPROVAL

Controlled demo canary là thử nghiệm trên demo với scope, duration, cap, monitoring và stop rule được khóa. Nó không phải chạy tiền thật. Trước khi bắt đầu demo canary, operator vẫn cần xác minh broker demo, account identity, symbol mapping, market hours và current release hash.

Theo contract case, 10 mandatory gates chắc chắn đều phải PASS. Nhưng ngoài đời, danh sách gate, sample size, threshold và authority còn phụ thuộc system, broker, asset, pháp nhân và regulation.

Nếu artifact đổi từ CFG30-C2 sang CFG30-C3, approval cũ không tự theo sang. Nếu alert delivery hoặc kill drill fail lúc preflight, trạng thái chuyển BLOCKED dù local ledger trước đó all-pass.

5. Sai lầm, giới hạn và rủi ro

Sai lầm 1: cộng điểm gate. Mandatory gates không phải bài thi 9/10. G5 FAIL không được G6 đẹp bù.

Sai lầm 2: report đúng, artifact sai. Test chạy build A nhưng deploy build B; evidence chain đứt.

Sai lầm 3: optimization thay risk. Parameter tốt hơn không thay position cap, margin guard hoặc kill.

Sai lầm 4: shadow pass nghĩa live pass. Shadow không gửi request nên chưa test acknowledgement, fill, slippage, reject và transaction timing thật.

Sai lầm 5: nhiều account nghĩa diversification. Các account có thể dùng cùng strategy, broker dependency, symbol và config bug.

Sai lầm 6: AI confidence thay invariant. Model score không được vượt schema, freshness, finite/bounds, account/risk và idempotency gates.

Residual risk là rủi ro còn lại sau controls: market gap, broker outage, unseen regime, human error hoặc failure kết hợp. Framework giảm uncertainty có cấu trúc; không xóa residual risk.

Rollback là quay về artifact đã biết và xác minh. Rollback không chỉ copy file cũ: cần config/account compatibility, state reconciliation và stop rule. Nếu state không tương thích, lựa chọn đúng có thể là halt thay vì rollback tự động.

Giới hạn:

• Framework không chứng minh strategy có edge tương lai.
• Count nhiều không bảo đảm test đại diện.
• Kill switch chưa drill có thể hỏng khi cần.
• High availability có thể nhân nhanh bad decision nếu risk sai.
• Regulation và broker behavior có thể thay đổi.
• Local validator không thay MetaTrader/broker runtime evidence.

Rủi ro vốn luôn tồn tại. Bài không cho entry, TP, SL, lot hoặc cấu hình chạy tiền thật.

6. Checklist capstone và bài tập 15 phút

a. Checklist trước demo canary

1. Khóa release candidate, build, config, schema, policy và dataset IDs.
2. Xác nhận G1–G5 có owner, exact evidence và reason.
3. Xác nhận G6–G8 dùng đúng artifact, time range và zero-request scope.
4. Xác nhận G9 account identity, heartbeat, alert delivery, reconcile và kill drill.
5. Xác nhận G10 Dev/Risk/Ops ký đúng candidate.
6. Không có UNKNOWN, missing report hoặc stale approval.
7. Demo scope có symbol/account/duration/cap rõ.
8. Exit criteria có latency, reject, delta, heartbeat và loss-of-control conditions.
9. Rollback/halt path không phụ thuộc component đang test.
10. Production order counter vẫn 0.

b. Bắt đầu từ đâu

Dùng Google Sheets, LibreOffice Calc hoặc giấy; 15 phút; chưa kết nối broker và chưa dùng tiền thật.

Tạo 10 hàng G1–G10, các cột: Owner, Artifact, Evidence, Result, Stop reason. Điền exact EA30-RC1.

c. Mẫu đối chiếu đã điền

Hình 5 — 10/10 PASS mở controlled demo canary; production orders vẫn bằng zero.

Kết quả đúng: 10/10 PASS, requests 0, production orders 0, verdict demo canary—not live capital. Nếu sheet trả “production ready”, conclusion gate đang vượt evidence.

7. Tổng kết

a. Năm ý chính

• Framework là bản đồ 5 tầng và 10 mandatory gates, không phải strategy hay code template.
• Design, risk, evidence, operations và release phải nối bằng cùng artifact identity.
• FAIL/UNKNOWN ở một mandatory gate chặn release; không majority vote.
• EA30-RC1 đạt exact lesson contract với reconcile delta 0, shadow requests 0 và kill drill 3/3.
• All-pass chỉ mở controlled demo canary; không tạo live-capital approval hay bảo đảm lợi nhuận.

b. Câu hỏi tự kiểm tra

• Vì sao checklist không có owner/evidence chưa đủ?
• G5 phân biệt những state nào?
• Shadow PASS chưa chứng minh điều gì?
• Tại sao đổi config hash phải xét lại approval?

c. Gợi ý đáp án

Xem gợi ý câu 1

Không biết ai chịu trách nhiệm, report kiểm artifact nào hoặc stop action ra sao. Xem mục 1.

Xem gợi ý câu 2

Request, acknowledgement, transaction, fill, position và reconciliation result không được nhập làm một. Xem mục 3.

Xem gợi ý câu 3

Shadow zero-request chưa test broker acknowledgement, fill, slippage, reject và live transaction timing. Xem mục 4–5.

Xem gợi ý câu 4

Config là một phần behavior của release artifact; hash mới làm evidence chain cũ không còn cùng candidate. Xem mục 3–4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• MQL5 — Event Handling
• MQL5 — OnTradeTransaction
• FINRA — Regulatory Notice 15-09
• SEC — Market Access Rule
• NIST — Zero Trust Architecture SP 800-207
• AWS — Well-Architected Framework pillars

f. Hoàn thành learning path

Bài trước, Building Institutional Trading Systems #29, cung cấp kiến trúc 8 lớp và release governance. Bạn đã hoàn thành 30 bài của EA & Algorithmic Trading Master Series. Hãy giữ gate sheet làm bản đồ review; đừng dùng nó như giấy phép chạy tiền thật.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư, chứng nhận hệ thống hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.