解决方案 · ILCD 校验与转换

ILCD 数据包进来。错误定位。没有字段被静默丢弃。

Cortex Cowork 对 ILCD 数据包进行 schema 校验，并在 ILCD 与 JSON-LD 之间互转——按位置和严重程度报告每个错误，并在修改任何字段前记录每条映射选择。

Cortex 能做什么

§ I

校验与转换。两项操作，均有完整审计路径。

ILCD 数据包的失败模式是可预测的：缺少必填字段、单位引用错误、schema 版本不匹配，以及仅在转换为其他格式时才暴露的结构问题。Cortex 系统性地将这些问题浮出水面——不是通过/不通过的一句话，而是从业者可以逐条处理的结构化清单。

Cortex 对 ILCD 数据包运行 schema 校验，并返回结构化报告：Error、Warning 与 Info 的数量，以及每条记录的位置（文件名 + XPath 或 JSON 路径）、描述与修复建议。总结明确说明数据包是否可发布、需要修复，还是有警告但可用。

Cortex 支持 ILCD 与 JSON-LD 之间的双向转换。交付内容包括：使用的映射规则、所有被丢弃、合并或默认填充的字段，以及将转换结果反向校验的报告。在条件允许时，执行双向转换校验（A → B → A），确认是否无损。

校验报告

§ II

校验报告按严重程度组织结果。Error 是硬性失败——数据包违反了 schema 的必要条件。Warning 是影响互操作性或信号数据不完整的问题。Info 是不需要处理的观察，但可能对提交上下文有参考价值。

每条记录包含文件名与问题所在的 XPath 或 JSON 路径、通俗的问题描述，以及具体的修复建议。报告以总结结论收尾：数据包是否可以原样提交、需要修复后才能提交，还是有警告但对目标用途可接受。

在一个数据包中出现的问题，往往在同一来源的其他数据包中重复出现。在校验会话结束时，Cortex 识别任何系统性规律——始终缺失的字段、始终格式错误的值——并将其写入项目记录，让来自同一厂商的下一个数据包跳过发现阶段。

转换

§ III

ILCD 与 JSON-LD 在结构上不同。一次没有报错的转换，仍然可能丢失或改变了源文件中存在的字段——多语言标签处理、继承的 flow property 引用和扩展字段是信息损失的常见位置。

Cortex 记录每个字段组使用的映射规则，列出每个做出了选择的字段（保留原样、合并、默认填充或丢弃），并说明该选择的后果。当后果较为重大——目标注册机构要求的字段在源格式中以不同方式编码——Cortex 在继续前暂停并询问。

转换完成后，将输出结果反向校验，验证其符合目标 schema。在条件允许时，运行双向转换校验：将转换后的结果转换回来，与原始文件进行对比。经历完整往返不变的字段是无损的；未能经历的字段标记为需要人工审核。

强制检查点

§ IV

静默修复是造成下游损害最大的失败模式——数据包看起来没问题，但字段已被悄悄改动或丢弃。Cortex 不静默修复，它停止、指明问题，并将决定交回给从业者。

§ 01

硬性错误——不自动修复

校验发现 Error 时，Cortex 停止并逐条呈现：位置、严重程度与建议修法。由用户决定是修还是接受风险。不静默修复。
§ 02

警告——按后果分类

警告分两类呈现：影响与其他系统互操作性的（建议修）和风格问题（可选修）。区分很重要——接受风险的从业者需要知道风险具体是什么。
§ 03

转换时结构不对齐

ILCD 的某些构造无法干净地映射到 JSON-LD——多语言字段、继承的 flow property、特定 schema 版本的扩展字段是常见来源。出现不对齐时，Cortex 指明字段名称、说明映射选择以及将会损失的信息，不静默丢字段。
§ 04

schema 版本需明确

ILCD 1.1 与 EF 3.0 使用不同的映射规则。当目标版本对提交注册或校验有影响时，Cortex 在应用转换规则前询问确认。

每个错误已定位。每条映射选择有记录。

Cortex Cowork 本地运行。ILCD 数据包留在你的机器上。每次校验会话发现的已知陷阱累积在项目记录中。