Decision 背后的规则：Buckets、Routing、VMD 与 MCB¶
本页回答一个核心问题：Decision 行中的 Buckets、Rule、Route、Mode、Base VMD、M、C、B 是怎样连接起来的？
这些 Controls 页面解释当前规则结构，但历史订单仍以 Decision 中保存的命中结果为准。不要用今天看到的配置覆盖订单发生时的记录。
从检测到最终决策¶
只分类流量→ROUTING
选择 STP / B-Book / Reject→ORDER RULES
按订单类型选择 Mode→BASE VMD + M/C/B
形成参数组成→DECISION
保存实际命中结果
Detection buckets：只负责分类¶
页面明确说明：Bucket 只做 classification，不决定 disposal；同一订单可以同时命中多个 Bucket，Bucket 本身没有优先级。命中后的处理由 Routing、Order rules 和 VMD 通过 Buckets 条件决定。
每条 Bucket 需要一起读：
| 字段 | 用途 |
|---|---|
| Bucket name | Decision 中可能出现的分类名称 |
| Range | 该检测适用的账户组、品种或其他范围 |
| Aggregation | 按 Account、Client、Group、Broker、Symbol、Side 等怎样聚合 |
| Window | 指标累计的时间窗口 |
| Metrics & thresholds | 达到什么组合条件才命中 |
| Status | Active、Shadow 或 Inactive |
Shadow 不能简单翻译为“无效”。页面中的说明显示 Shadow bucket 仍可作为分类结果出现，但是否参与具体治理要看下游规则。调查时记录状态，不自行推断影响。
Routing：选择订单去哪里¶
Routing rules 从上到下匹配，first match wins。未命中任何规则的订单会被拒绝。Target 的含义在页面中明确为：STP 路由到 LP，B-Book 内部化，Reject 阻止订单。
Routing 条件可以读取 Bucket membership。因为一个订单可同时处于多个 Buckets，组合条件需要用多条 AND 条件表达；最终仍由规则顺序决定，不由 Bucket 决定优先级。
例：Force STP — T5 条件为 Tier = T5，Target 为 STP。这与 DEC-89234 的 Rule 和 Route 完全对应。
Order rules：同一路由下怎样处理不同订单类型¶
Order rules 同样从上到下匹配、first match wins，未命中会拒绝。页面按订单类型分别给出处理 Mode：Open Limit、Open Stop、Open Mkt、Close TP、Close SL、Close Mkt、Close SO。
页面列出的 Mode 包括 Direct、MCB、BFC、Market、Market (worst-of)、Reject。此外还应核对 Quote check、VMD lot、Bypass 和 Status。不能只看 Rule name 就假定所有订单类型采用相同 Mode。
例如 Scalper detected 的条件是 Tag = Scalper OR Tag = LatencyArb，不同订单类型分别可能采用 BFC、MCB 或 Market (worst-of)。这解释了为什么 Decision 必须把 Rule 与 Mode 一起读。
Base VMD：规则选择哪个参数 Profile¶
Base VMD 的 Rules 页同样按从上到下、first match wins。每条规则引用一个 VMD profile，而实际的 per-symbol 参数定义在对应 profile 中。当前核实到的示例包括：
GoTrading — tight spread：Broker = GoTrading → Tight execution；IB-2088 / IB-3021 channels：Group 命中指定渠道 → IB size-discouraging。
调查历史订单时，Decision 的 Base VMD 是当次记录；Controls 中当前 Rule/Profile 只能用于理解结构或检查现状。
Market (M)：订单当时的市场组成¶
页面公式显示 M_add 为各 M module 结果之和并受全局上下限约束，M_delay 为各模块 delay 之和并受 1000ms cap；模块会按 request 采样其配置区间。
当前页面显示的模块包括实时区间评分 M_micro 和日历/事件 M_evt，并支持有 Scope、Reason、Activated、Expires、Triggered by 的 Emergency override。因此调查异常 M 值时，不只看模块，还要检查当时是否有 override。
Client scoring (C)：UID 评分映射到 Tier、C_add 和 C_delay¶
页面显示这是 UID-level scoring：Score A、B、C 合成 Client Risk Score，再映射到 Tier、C_add / C_delay。保存配置不会立刻重算现有 UID score，要等下一次 scoring refresh；这对调查“配置刚改但客户 Tier 没变”非常重要。
Tier mapping 同时给出 Score range、C_add、C_delay、Routing hint 和 Description。例如 T5 对应最高区间、C_add +1.00、较高 delay 范围及 Force A-Book hedge 提示。Routing hint 是提示，实际订单 Route 仍以 Decision 命中结果为准。
Behavior tags (B)：人工标签与系统标签进入同一管线¶
Manual tags 可由用户在 Client 页面或 CRM webhook 管理；System tags 由已部署 detector 注册，检测逻辑由 engineering 管理，而业务属性可在此配置。两类标签都进入 B_coeff / B_spread_x / B_delay 管线。
新人需要区分：
- 标签来源：Manual 还是 System；
- Effect mode；
- B_coeff、B_spread_x、B_delay；
- System detector 的 Schedule、Trigger 与 Status；
On与Shadow状态。
例如 Decision 中出现 LOCKCHURN B4 / PSEUDOSCALP B4 时，可在此理解标签配置，但应到 Client detail 和 Decision 记录核对客户当时实际携带的标签。
完整阅读规则¶
看到一张 Decision 时，按以下方式追溯：
Buckets / Readings at hit：当时命中了什么流量分类及读数；Rule / Route：哪条 Routing rule 首先匹配，订单去向是什么；Mode：Order rule 对该订单类型选择了什么处理方式；Base VMD：当次记录引用什么基础配置；M / C / B：市场、客户评分、行为标签分别贡献了什么；Spread / Slippage / Delay / Final / Cost / Status：最后形成并记录了什么结果。
实战任务：比较两张 Decision¶
比较 DEC-89234 与 DEC-89240：解释为什么前者显示 Force STP — T5 / STP，后者显示 Scalper detected / B-Book / BFC，并指出哪些内容是历史事实、哪些 Controls 只能帮助理解当前配置。