最小事件卡应包含哪些字段
工程师首先需要事件标识、相对时间窗、数据版本、通道质量、处理决定和弃判原因；若要进入真实运维，还需要独立的设备与车道标识、时间同步状态、维护日志和责任闭环。只有把“现有软件字段”与“未来业务字段”分开，事件卡才既可用又不误导。
当前V3真实文件提供scenario_id、time_s、通道数值与状态、synthetic和data_version等字段，JSON报告还有selection、computed features与decision。它们是模拟数据接口，不包含真实车牌、车主身份、故障维修工单或硬件UTC时间。
值守、工程与研究三类读者
传统停车场后台往往围绕放行事务设计，而磁事件研究的首要问题是“该如何解释一段短时变化”。两个系统的零点不同：道闸记录提供事件触发，磁通道提供相对样本，现场维护日志解释非车辆活动。若把三种时间完全等同，会在排障时把接口延迟误认为磁场峰值延迟。
不同岗位需要不同层级的信息。值守人员希望知道是否需要行动；设备工程师希望看到通道状态与时钟问题；研究人员需要追溯可复算的数据版本与窗口。事件卡可以默认展示最小摘要，再让授权人员展开详情，而不是把全部技术字段放在一行。
从SIM编号到质量与弃判原因
最小卡片分四段。第一段标识SIM编号和是否为Synthetic Scenario，避免把例子当现网告警；第二段说明相对时间窗口与采样数量；第三段展示Bx、By、Bz、reference是否VALID、SATURATED或LOST；第四段给出RENDER_EVENT或ABSTAIN及具体原因。
以SIM-12为例，参考通道存在LOST，decision.status是ABSTAIN；维护人员应首先看到“参考缺口，当前不可解释”，再点开报告查看哪段样本不可用。以SIM-03为例，问题是场景假设下道闸电机共同扰动；其弃判原因与失联完全不同。两张卡不能都只写“检测异常”。
现有CSV与未来运维系统的分工
CSV字段有固定15列，包括scenario_id、sample_index、time_s、bx_au/by_au/bz_au/reference_au、四个对应_status、timebase_status、unit、synthetic及data_version。数值列允许空值，状态列必须保留；前端展示缺失时不能调用默认归零的转换。
报告并不是直接复制CSV。selection定义窗口与点数，features_computed_from_csv存从样本计算的结果，decision含状态、标签及reasons，还明确is_trained_diagnostic_model为false。对于工程师而言，原因链比一个不透明的“风险分”更容易形成排查动作。
| 卡片信息 | 现有V3证据字段 | 真实运维仍需补充 |
|---|---|---|
| 身份与时段 | scenario_id、time_s、data_version | 真实车道ID和可信UTC |
| 质量与数据 | 四路_status、unit、synthetic | 现场校准与维护登记 |
| 结论与复查 | decision.status、reasons、报告路径 | 工单闭环和责任记录 |
本表区分现有V3软件字段与拟议运维字段；尚未建立真实物业系统的业务接入。
真实场地接入还需要场地 ID、安装点、设备固件、校准版本、时钟同步证据、维护记录和工单编号。这些不是当前 V3 合成 CSV 的十五列字段，属于未来外部业务系统的独立映射范围。
车库场景图和报告文件
编辑封面介绍停车场场景，磁源示意标出多种可能来源，原理图解释磁场测量。这些视觉元素不能被解释成真实设备或已经上线的运维界面截图。
配合[SIM-12参考缺失报告](/gaterestart/data/v3/reports/SIM-12.json)、[SIM-03报告](/gaterestart/data/v3/reports/SIM-03.json)和案例总览可看到质量与场景来源的不同字段。下载数据时仍须保留原15列的状态语义与a.u.单位。
数据字典与业务字段的证据来源
现有字段与质量状态可从 field_dictionary.json 和 report-schema.json 核对，数值来自合成案例及其分析结果。工程师工作台的页面结构、未来车道 ID 和工单闭环属于拟议应用设计，尚未接入真实物业业务系统。
QuSpin技术原理（SCI-001）解释磁测信号如何产生，应用环境说明（SCI-003）提示现场平台噪声的必要性，但它们不提供本项目的停车场业务字段设计。本文不宣称任何现实客户已经使用事件卡。
图版与结构细节
