判定内核

要解决什么问题

一个「每天定时判指标有没有问题」的系统，听起来只差一条 if。 真正难的是下面四个失败模式——它们的共同点是从外面全都看不出来。

内核的立场由此推出：判定是关于某一时刻的事实记录，不是可随手改的配置。 下面五个设计决定，分别把上面五个根因堵死。

条件语言：安全由构造

规则条件住在 decisions.yml 里，是不可信输入，所以它永远不会遇到 eval()。取而代之的是一个刻意做小的语言：手写词法分析器 expr.py:346 _tokenize 加递归下降解析器 expr.py:369 _Parser， 文法只有七条产生式（写在模块 docstring 里），求值阶段只能从调用方给的 scope 字典里读值—— 能力上限 = 能读几个变量，没有别的。

更关键的是两套闭集：标识符闭集 expr.py:70 VARIABLES 和函数闭集 expr.py:104 FUNCTIONS。 写了一个闭集外的名字——哪怕只是拼错——是解析错误，写入时就被 lint 拒掉， 而不是一个静默的「未知值」让规则永远不响。未注册的 trend() 保持保留状态： 半成品函数比没有函数更危险。

解析结果按条件文本缓存（AST 不可变，调度器每个 tick 都会重解析），但解析错误不缓存—— 一条正在被修的规则要保持可修。解析入口收一个 variables 参数， 每个域带自己的一套闭集：结果域的 validator 检查用 expr.py:92 VALIDATOR_VARIABLES， SQL 域的 guard 断言用 guards.py:55 GUARD_VARIABLES ——同一台解析器，多套词，缓存键里带着词表，各域之间永远不会共享一份缓存。

Kleene 三值：判不了是第三种答案

条件求值的结果不是 True / False，而是 True / False / Unknown。 这是对更早的告警 DSL（jobs/alerts.py）的刻意修正：那份契约「未知 → False，绝不抛异常」 对一条裸比较是对的，但 not 一进语言就错了——缺基线时 not (x > y) 会被两值逻辑判成真，在无数据上误报。

实现里有两个值得看的细节。其一，Unknown 是单例，它的 __bool__ 会抛异常——任何一处不小心的 if value: 都是一个响亮的 bug，而不是把三值静默塌成二值。其二，跨类型比较（数字与字符串）返回 Unknown 而不是 False，理由与上面同源：False 会在 not 下翻成误报，而「类型对不上」 的诚实答案就是「判不了」。

对外的触发契约收敛为一个窄口： expr.py:520 evaluate_condition 只有在条件确定为真时才返回 True，Unknown 一律不触发——没有假阳性。 而 validator 与 guard 两档不走这个函数：它们直接取三值，因为「判不了」与「违反」 对断言型检查是两件事——判不了绝不拦。

一条判定的完整管线

flowchart TB
    Y["decisions.yml · 规则
（语义模型的词汇）"]:::entry --> W["窗口解析
自然语言窗口 → 当前期 + 基期"]:::entry
    W --> C["语义编译 build_and_compile
权威 SQL · 零 LLM"]:::gen
    C --> X["只读执行
connectors.execute · 单条超时"]:::exec
    X --> J["judge 纯函数
逐组行卡 · 三值求值"]:::gate
    J --> G{"触发？"}:::gate
    G -->|"否"| OK["记录证据
status = ok"]:::entry
    G -->|"是"| APP["附录逐层叠加（按声明）
显著性门 → 因果梯 → 分析桥"]:::entry
    APP --> V["消息 + 证据 → 判定记录
不可编辑 · 相邻 diff"]:::entry

    classDef entry fill:#71717a14,stroke:#71717a59,stroke-width:1px;
    classDef gen fill:#6366f114,stroke:#6366f199,stroke-width:1.5px;
    classDef exec fill:#14b8a614,stroke:#14b8a699,stroke-width:1.5px;
    classDef gate fill:#f59e0b14,stroke:#f59e0b99,stroke-width:1.5px;
    linkStyle 6 stroke:#f59e0b,stroke-width:1.5px

窗口解析复用提问链路的同一入口（parse_time_range）：「本月」在用户提问和规则触发时 必须是同一个跨度，两处各写一套解析，迟早不一致。基线按 baseline.kind 由同一份窗口推出 （上期 / 同比 / 字面值），推不出就硬错，绝不猜。 service.py:449 _resolve_window

编译把 subject（metric / dimension / filter——与 /v1/semantic/query 同一种形状） 编到语义模型上：先编一遍拿锚定数据集，再按指标的 agg_time_dimension 解析时间字段，带上窗口条件编第二遍。 时间条件是半开区间（< 结束日 + 1 天），与归因引擎共用同一个生成函数——闭区间会在 timestamp 列上 丢掉窗口最后一天，而触发后的分析附录必须与判定看到同一批天。 service.py:484 _compile

执行走连接器的只读通道（ConnectorRegistry.execute 拒绝任何非 SELECT）， 每条 SQL 有各自的超时预算——一次卡死不该把另一次的额度也吃掉。方言（dialect）解析不出来是硬错： 「猜一个方言」编译出的错 SQL，在没人读的定时任务里是最坏结果。 service.py:1205 _run

求值是一个模块级纯函数 service.py:155 judge： 逐组生成行卡（current / baseline / delta / delta_pct / contribution / triggered / matched）， 条件在每组作用域里三值求值。emit 决定规则上报哪些触发的组 （any / all / top_k），但行卡保持原样——对 all 规则，你恰恰需要看到哪些组没触发， 改写它们会掩盖这个信息。这个纯函数边界还有一个直接回报：what-if 回放（因果与模拟） 就是在假想的数字上重跑同一条内核——「模拟与判定不漂移」由此不是承诺，是构造。

判定的产物是一条带完整证据的记录：

失败必响：error 是判定历史的一等公民

与告警系统有意不同的一条纪律：判定层所有「判不了」都以错误示人， 绝不静默变成「本次无触发」。原因写在模块 docstring 里——一条静默不触发的定时任务， 与一条健康的任务从外面看没有区别。

入口 service.py:1286 evaluate 把上述每一类异常折成一条 error 判定：运行记录里 status=error， 证据里带着错误原因与当次规则指纹——「哪一版规则开始报错」是排障的第一个问题，所以失败也记 digest。 失败永远不是通知，也永远不是一行空记录。

不可编辑的记录，相邻的 diff

判定记录 verdicts.py:46 VerdictRecord 没有编辑、没有回滚：判定是关于某一时刻的陈述（「2026-10-01，聚合口径说 X」）， 编辑它就是编辑历史；存证据的全部意义在于，后来的分歧是对着记录争论，而不是对着一行可改的数据。 相邻 diff verdicts.py:180 diff_verdicts 是两条记录之上的派生视图，从不落库；旧记录缺字段时，每一处比较都退化为「说不出」， 而不是发明一次变化（比如「幅度突变」是展示阈值 10 个百分点，源码里明说它不是统计主张）。

这里有两把尺，各管一层。整份 decisions.yml 的字节指纹（digest）对文件敏感； 单条规则的内容版本 rules.py:868 rule_rev 是这条规则规范序列化的前 16 位，对其他规则的编辑无关。 渲染「规则被改过」时以 rev 为准——这是修过的真实教训：编辑 B 规则会让 A 规则的相邻两条也亮起 「digest 变了」，两把尺混用时审计线会集体误报。两个字段都缺时不报变化： 「没记录版本」不是「版本变了」。

查询预算：顺序即优先级

一次判定的查询有硬上限，而且账是公开的： budget.py:34 DecisionBudget 把预算分成 judge(2) > significance(2) > causal(4) > bridge(4)，总额 12。 阶段按这个顺序执行、先到先得：判定本身永远排第一，预算不足时让路的永远是往后阶段，绝不反过来。 让路不是静默的——yield_ 记账进 evidence.budget， 用源码里的话说：「过严的护栏会被绕过，那连观测都没有了」。

还有一个逐字节的兼容纪律：只有显式声明才花钱——没有声明显著性 / 因果 / 桥的规则， 连账本都不进证据，输出与引入预算之前逐字节相同。老规则的老行为，是升级不翻车的先决条件。

怎么用

规则住在 .trove/kb/<datasource>/decisions.yml——KB 树本身就是 git 仓库， 所以每次改规则都是一次可评审的提交。一条完整的规则长这样：

version: 4
rules:
  - id: loan-drop
    name: 贷款余额异常下降
    severity: warning
    window: 本月                    # 与提问链路同一个时间解析器
    baseline: {kind: prev_period}   # 由窗口推出上期
    subject:                        # 与 /v1/semantic/query 同一种形状
      metrics: [loan_balance]
      filters: [{field: region, op: "=", value: North}]
    conditions: ["delta_pct < -0.1"]  # 闭集变量 + 三值逻辑
    recommendation: 联系区域负责人核对口径
    priority: 2

写入路径上有三重门：lint 的结构检查（单 metric、闭集取值、静默死形状）、 试编译（subject 真的编一次——lint 的硬门就是这个测试）、 以及文件版本上界守卫：比当前内核更新的 schema 版本拒绝读取， 因为管理端整份文件保存会把读不懂的字段悄悄删掉——拒绝读，好过静默读少了。

定时触发走任务系统：Job 指向规则 id，runner 里的决策腿 runner.py:174 _run_decision 从不进入 NL 管线——判定的产出不依赖任何一次模型调用，这正是它能被质问的底气。 语义模型按任务的 datasource 现取现用：启动时绑定默认源的做法，会让一个任务静默地用错模型编译 SQL。

取舍

已知边界，也如实列在这里：判定永远读当前的语义模型——模型被改，下一次判定就换了尺子； 历史记录靠 rev 保住可解释性，但不会用旧模型重算。证据行有上限（截断有旗）。 规则条件不做跨行的事——这是上面「闭集」的代价，也是下一步能力（如果做）要先回答的问题。

优势在哪

• 可复算。输入（规则版本、窗口、语义模型）确定后，输出就是同一批行——证据里连 SQL 都在，争议可以回到数字本身。
• 可审计。不可编辑的记录 + 相邻 diff + 按规则版本分桶的质量回评；「规则被改过」有精确的一把尺（rev），而不是含混的一把（digest）。
• 不会静默死。写入时有 lint 拒掉静默形状，运行时有「失败必响」——所有「判不了」都是 error run。一条死掉的任务不会伪装成健康任务。
• 安全面为零。无 eval、闭集语法、只读执行通道、零 LLM——判定层没有可以被注入的输入面，也没有可以被模型带偏的环节。
• 成本有界且可解释。12 条查询的硬上限、顺序即优先级、让路有账——开着一队定时判定，不需要担心成本失控。

一句话总结内核的取向：判定层是能被质问的——每一次触发都能拉出它据以判断的 SQL 与行， 每一次「没触发」都有记录，每一次「判不了」都以错误示人。

继续读