表与勾稽
这些表之间是怎么对上的 —— 六条恒等式,十一个事例。
十一个事例
点一个看它在各张表里怎么落账、哪些数会变、哪几条勾稽要被检查。
六条恒等式
每一条都是 v_schema_invariants 里的一句 SQL,不成立就报警。
- 恒等式 1run 守恒 i
count(runs) = 计策略分的 + 不计策略分的 - 恒等式 2系数表的分母不是 run 总数 i
coefficients.n = count(runs WHERE counts_against_policy = true) - 恒等式 3第二本账不重不漏 i
每条不计策略分的 run,恰好在一个第二账本里落一次 - 恒等式 4档案小时数对得上 i
rcsn_units.total_hours = Σ passport_events.hours_delta - 恒等式 5权利可审计 i
公共表里的行数 = rights_basis ∈ (rc_funded, api_granted, shared) 的 run 数 - 恒等式 6背书冻结 i
attestations → run_sets.digest 必须与重算一致
一次 run 的完整轨迹
一次 18 秒的抓取,在系统里留下 7 条记录。示意
| # | 发生了什么 | 写进哪张表 | 这一行的内容 |
|---|---|---|---|
| 1 | 预约到一个格子 | orders | order_7731 · Verified Report · 3 本体 · 共享数据 · $9,400 |
| 2 | 装好这一台的配置 | bodies | body_014 · xArm7 + WujiHand2 · 20 DoF · 安装 740mm · config_version 1 |
| 3 | 机器动起来,录制完成 | runs | run_8f2a41 · seed 0x5F3A9C21 · 4200K · μ0.42 · reset 42s · op 2.4min · 只记发生了什么 |
| 4 | 判分器给结论 | judgments | jd_5c19 · rc-judge-v1 · attempt ✓ · success ✗ · grasp.slip · conf .91/.86 |
| 5 | operator 复核 | operator_labels | Operator 07 · 11s · 与判分器一致 → 不进校准集 |
| 6 | 裁决 | run_outcomes view | 不是一张表 —— 按"仲裁 operator > 首位 operator > 最新判分器"现算 |
| 7 | 并入公共表 | coefficients | cf_4471 · body_014 × Policy A × pick_place · n +1 · success 分母 +1 |
第 3 行和第 4 行分开,是整套设计的枢纽。i
数据怎么流
数据怎么流 · 一个事件进几本账
最容易记错的三件事
分母 ≠ 总数
跑了 520 次,扣掉不计策略分的 27 次,分母是 493。每份报告两个数都印。i
一个事件两本账,但不是两笔
硬件故障从策略分里剔除、记进设备档案 —— 同一个事件在两个视角下各记一次。i
历史不可改写
判分器升版、换夹爪、修正分类法 —— 全部是新增行,没有一个是 UPDATE。i
贯穿全部设计的一条不对称
在只增不改的账本上,少记可以补,多记补不回来。所以策略轴宁可多计,身体轴宁可少计。
| 标记 | 轴 | 错的方向 | 有没有待办 |
|---|---|---|---|
exclusion_ambiguous | 策略 | 可能多算 | 无 —— 保守解法当场生效,不留尾巴 |
body_charge_deferred | 身体 | 可能少记 | 有 —— 这台设备欠着一条档案记录,挂在人工补录队列上 |
为什么两条轴反着处理,为什么两个名字故意不对称
策略轴宁可多计 —— 归因不确定时算模型头上,因为弱证据不能拿来买豁免;身体轴宁可少计 —— 不确定时不写故障,进人工补录队列。一条这台臂没赚到的故障记录,会永久压低它的残值和租金报价,而且删不掉。这就是为什么 env.* 的去向不是"有个标志位挡着",是在结构上根本写不进设备档案。
两个标记来自同一个原因(判分粒度降级),但只有一个留下了待办。叫 deferred 是因为它暗示有个队列;叫 ambiguous 什么也不暗示。如果两个都叫 ambiguous,读的人会以为两条轴对称失败 —— 然后把一条欠着的档案记录当成分母噪声,永远不去清那个队列。账单会在两年后以「一台出租设备上有一次没记录的碰撞」的形式到达。