paper 执行链路：风控预检 → 通道抽象 → 账本更新（拒绝也要可解释）
很多团队做 paper（模拟交易）时，会把它当成“回测的另一种形式”。
但真正把系统做成平台后你会发现：paper 的价值不在“模拟成交”，而在“验证交付链路”：
- 策略信号是否能形成下单意图？
- 风控是否按团队口径生效？
- 通道是否能统一接入与扩展？
- 成交与资金/持仓是否形成可审计的账本？
结论先行：EasyQuant 的 paper 链路按生产思路设计：先风控预检，再通道执行，最后账本落地；并且所有拒绝都必须结构化可解释，才能形成可运维的交付能力。
一、为什么 paper 不是“玩具”？
如果 paper 只是“随机撮合一下给你看”，它无法回答团队最关心的问题：
- 真实上线后，策略会不会因为风控/通道原因大量拒单？
- 策略频繁下单是否会触发额度/仓位限制？
- 多策略组合运行时，资金与敞口是否会互相影响？
paper 的真正价值是：把“上线前的失败”提前暴露在可控环境里，并让原因可解释、可统计。
二、链路拆解：三段式最稳定
把执行链路拆成三段，有两个好处：可扩展、可诊断。
1）风控预检（Risk Pre-check）
风控不是“下单后再拒绝”，而是下单前的统一入口：
- 额度限制：单笔、单日、单标的、组合敞口
- 仓位约束：最大持仓、净敞口、集中度
- 数据质量：价格新鲜度、bars/tick 是否可信
- 策略约束：重复下单、频率限制
输出必须是结构化的：允许/拒绝 + 原因码（RISK_REJECTED）+ 明细。
2）通道抽象（Broker Gateway）
通道是平台的扩展边界：
- paper 通道：模拟撮合，用于联调与验证
- 准生产/实盘通道：未来可替换接入
关键点：策略侧不应该关心通道细节。
策略只关心“我发出了下单意图”，平台负责“用哪个通道执行”。
3）账本更新（Ledger）
执行结果必须落到可审计的账本体系里：
- 订单与成交（order/fill）
- 持仓变化（position）
- 资金流水与净值（capital ledger / NAV）
只要你想做多策略组合运行，账本就不是可选项，而是平台基础设施。
三、拒绝也要可解释：它决定了系统是否可运维
真实运行中，“拒绝”是常态而不是异常：
- 风控拒绝：额度/仓位/数据质量
- 通道拒绝：参数校验、不可交易状态、价格异常
如果系统只返回一句“下单失败”，团队就会陷入无休止的沟通与排障。
因此 EasyQuant 强调：
- 拒绝必须有原因码：RISK_REJECTED / BROKER_REJECTED
- 原因必须可聚合统计：Top 拒绝原因、趋势变化
- 原因必须能指向下一步：调整风控参数？补数据？修改策略节奏？
这与 03 的 Blocking Reasons 体系形成闭环：让“没发生”变成可定位的问题。
四、paper 如何服务“准入流程”？
在团队交付里，paper 最重要的产品形态之一是“策略准入”：
- 策略作者提交版本（激活版本）
- 在固定数据窗口与固定成本口径下回测（可复现）
- 进入 paper 验证一段时间（验证执行链路、风控口径、稳定性）
- 通过准入后再进入更接近生产的环境
如果 paper 链路缺少风控/账本/解释能力，这条准入流程就无法建立。
五、一个验收：同一策略触发信号，但被风控拒绝
用一个常见场景验收 paper 的交付价值：
- 场景：策略频繁下单，触发单日订单数上限
- 期望：系统明确给出 RISK_REJECTED，并标注命中的风控项（哪条规则、阈值是多少、当前值是多少）
- 进一步：系统状态页能统计“风控拒绝 Top（24h）”，指导团队调整策略节奏或风控口径
如果这条验收能通过，paper 就不再是“玩具”，而是交付与运维体系的一部分。
结语：paper 的价值是验证“交付链路”，不是模拟“市场细节”
回测验证策略逻辑，paper 验证交付链路。
当你的 paper 链路能做到：风控可解释、通道可替换、账本可审计、拒绝可统计，你的平台就具备向准生产演进的基础。
下一篇（10）我们会进入回测内核：组合回测如何复用信号引擎，以及时间线、状态与成本模型如何影响最终结果。