Edge 系统地图：Variables、Pipeline 与 Data Model

本页是新人理解 Edge 的底图。它回答三个问题：规则能读取什么变量、报价与订单经过哪些阶段、Order/Decision/Execution 数据怎样关联。

三张参考图分别解决什么

页面	用途	不应该用来做什么
Variables	查变量的类型、范围、Scope、更新时间和用途	证明某张历史订单的变量值
Pipeline flows	理解 Quote flow 与 Order flow 的处理阶段	代替单笔 Decision/Execution 记录
Data model	理解表、字段、主外键、1:1 与 1:N 关系	猜测页面没有显示的历史数据

Variables：条件构建器能读取什么

Variables 是只读的系统变量注册表。这些变量可用于 Routing、Order policy、Automation 和 Alerts 的 condition builders。

页面把变量分为：

• MCB model outputs：M_add、C_add、B_coeff、B_spread_x、Manual_adj、Final_Slippage 等；
• Order context：Symbol、Volume、Side、Order_type；
• Client attributes：Tier、Tag、Region、Channel、Account、Group；
• Event / market state：Event.active、severity、name、symbol、phase；
• System / LP health：LP.status、Engine_latency、Breach_rate；
• Behavior detection metrics：Toxic_pct、hold_time_ratio、stale_rate、markout_t10、burst_ratio 等。

为什么 Update 很重要

变量更新频率不同：有些 per order 或 real-time，有些 every tick / every minute，有些 T+1 batch，还有些只在 change 时更新。因此，相邻两张订单的 M 或 B 可能不同，而 C/Tier 可能仍保留上一次批量评分结果。

调查规则是否可能匹配时，必须同时核对 Type、Scope、Update，不能只看变量名称。

Pipeline flows：Quote 与 Order 是两条不同路径

Quote flow

LP raw price → Symbols/Sessions → Liquidity → Quote rules → Pricing overrides → Client bid/ask

• Symbols/Sessions 决定品种及时间门控；session closed 时不发布报价；
• Liquidity 负责 maker symbol、maker pool 和 quote filter；
• Quote rules 把条件与客户 Stream 连接；
• Pricing overrides 在 Stream 上叠加临时参数；
• 最终 client bid/ask 发布到交易平台，并开始 QV 计时。

Quote flow 是 stateless：每个 tick 独立处理，配置变化可在下一个 tick 生效。因此，调查历史报价必须用 Ticks 和带时间的记录，不能只看当前配置。

Order flow

Client order → Session check → Routing → STP / B-Book / Reject

• Session 外的订单立即 Rejected，Pipeline 页面说明此情形不会写 decision_log；
• Routing 从上到下首个匹配，决定 STP、B-Book 或 Reject；
• STP 直接进入 LP execution，MCB coefficients 不应用；
• B-Book 进入 Order rules，再按订单类型选择 Direct、MCB、BFC、Market 等；
• Reject 写入拒绝路由的 decision_log，但没有 execution row。

只有 B-Book 且 exec_mode = MCB 才进入完整 MCB slippage pipeline。新人不能看到 Decision 有 M/C/B 列名，就假定每张订单都应用了 MCB。

Data model：三张表的真实关系

ORDER
1 row per order1 : 1DECISION_LOG
不可变决策快照1 : NEXECUTION
成交或超时终态

Order

保存原始订单事实。摄入时写入，随着 execution 完成更新 remain 与 status；不包含 MCB 或评分字段。

remain = volume - SUM(execution.fill_volume)。由此形成 Filled、Partial、Pending、Rejected 等状态。

Decision log

每张进入决策阶段的订单一条不可变快照，冻结当时的 Tier、Tags、M/C/B、事件上下文、matched route、route target、matched policy、exec mode 与计算结果。它写入一次、不再更新，所以是历史调查的主证据。

需要注意页面文档同时说明：正常订单的 order → decision_log 为 1:1；但 Session check 在路由前直接拒绝时不会写 decision_log。新人遇到“Order 有、Decision 没有”时，应先检查是否属于 session-stage rejection，而不是立即判断数据丢失。

Execution

一张 Order 可有 1..N 条 execution。部分成交、failover 会产生多条记录；每条记录都是 completed fill 或 timeout 的终态，没有 in-progress 状态。B-Book fill 的 counterparty 使用 broker name；A-Book/STP 才有 LP 相关字段。

用数据关系判断“为什么查不到”

现象	首先检查
有 Order，没有 Decision	是否在 Session check 阶段被拒绝；再查日志
有 Decision，没有 Execution	Route 是否 Reject；若非 Reject，查 System/Execution 日志
一张 Order 有多条 Execution	是否 partial fill、failover 或 timeout + 后续尝试
STP Decision 的 MCB 字段为空	属于设计路径，不应自动判定数据缺失
Order remain 与单条 Execution 数量不一致	汇总同一订单所有 execution.fill_volume
当前变量/配置与 Decision 不同	Decision 是历史冻结快照，Variables/Controls 是当前参考

实战任务：Ticket 47891893 为什么有两条 Execution

任务：用 Data model 与 Pipeline flows 解释：为什么两条 Execution 不代表有两张客户订单，以及调查时应该怎样汇总。

展开参考答案

Order 与 decision_log 是订单级记录，而 Order → Execution 是 1:N。部分成交、不同 LP 尝试或 failover 都可产生多条 Execution。同一 Ticket `47891893` 下应读取全部 execution rows，按 attempt、Counterparty、Pool、Filled、Latency、Status/Reason 记录，并汇总 fill volume 后与 Order 的 volume/remain/status 对账。不能只引用第一条 Execution，也不能把第二条当成另一张客户订单。

新人记忆法

Variables 告诉你“规则能读什么”；Pipeline 告诉你“数据经过哪里”；Data model 告诉你“证据存在哪张记录”；真正回答历史订单时，以 Decision、Execution、Order、Ticks 和 Logs 为准。