候选输入要携带哪些上下文
完整处理链设想接收时间戳、磁测通道、可能的环境参考点，以及道闸动作形成的候选时间线。但道闸时间并不是重启真值，且不同 OPM 架构输出形式不同；若采用总场标量型，就不能假定输入天然包括独立 Bx、By、Bz。当前网页能读取的是 CSV 中明确定义的合成列，不是实体设备连续数据流。
同步首先是数据质量问题
若未来存在闸机时钟、采集时钟和多测点时钟，需要明确定义同一时间基准、偏移估计、缺失处理和允许误差。没有这些条件，所谓“前后峰值对齐”可能只是错位叠加。现有时间窗滑块仅允许在0至3秒的合成记录内选择观察范围；它没有实现跨设备同步，更没有接入车辆状态的独立时间依据。
基线、特征与参考比较的界线
拟议处理可计算窗口前基线、相对变化、局部峰值、斜率、持续时间和窗口内平方和。平方和只是数值计算量，不能当作发动机机械能或实际磁场能量。参考差分也不是把两个任意探头相减就有效，测点方向、位置与共模关系必须先检验；因此网页目前不提供自动去噪和故障分数。
状态机应当先检查适用性
设计顺序是“等待候选窗口—检查事件条件—检查测量质量—检查场源混叠—展示可解释形态或弃判”。没有发动机重启真值可核时，状态要保留不确定；强干扰、相邻车辆或超量程时不能强行归类。这样的状态机是建议的数据逻辑，不是已经烧录在 GR-Edge 上、能对车流逐辆作判断的程序。
输出为什么需要带上证据等级
未来输出若包含事件区间与特征，至少应附通道定义、时间来源、环境条件、窗口边界及无法判断的原因。现在真正可用的结果是 GR-Insight 的合成波形浏览和选段 CSV 导出，不是实时告警、API 推理、远程运维或车辆维修报告。保持这些层级分开，才能让后续实验明确要补齐哪一段链路。
与硬件和界面的职责分界
GR-OPM 的工作是提出传感架构及可测范围，GR-01 讨论物理容纳和安装边界，GR-Edge 定义事件处理顺序，GR-Insight 负责向访客解释可见曲线。对外展示的模块图已经形成，但采集协议、处理硬件、质量阈值与实际部署均未完成验证。本次记录的成果是可审阅的处理链设计与网页演示接口说明。