一致性与测试
PurRDF 使用标准测试套件和第一方语料检验各个引擎。这些套件随库固化于仓库中并按字节冻结——从不手工编辑，在每次 make check 时进行 SHA-256 校验，因此任何静默的内容修改都会使构建失败。完整的实时记分板见 docs/CONFORMANCE.md；本章说明这套机制如何运作。
单一的一致性矩阵
原生 Rust W3C 测试框架与 Python rdflib 直接替换（drop-in）检查合在一起，作为同一个记分板报告：
make conformance # 把每个套件汇总到一张表中
汇总器按固定顺序运行每个套件，打印每个套件的通过 / xfail 或跳过 / 失败计数，并给出总体的 RED/GREEN 裁决。只要出现任何意外失败，它就以非零状态退出，而 docs/CONFORMANCE.md 中输出的矩阵本身也在 CI 中受漂移防护（若已提交的区块过时，检查即失败）。
把关范围
| 引擎 | 套件 |
|---|---|
| IRI（RFC 3987） | W3C IRI + RFC 3986 §5.4 解析向量 |
| 语法编解码器 | W3C rdf-tests（Turtle/TriG/N-Triples/N-Quads/RDF-XML） |
| CSVW | W3C RDF 转换与元数据验证清单，外加一个锁定版本的独立实现 |
| OBO Graphs | 官方 OBO Graphs 0.3.2 JSON Schema，外加损坏探测 |
| Research Object 载体 | 五个对抗性的原生测试夹具、一个 5×5 的稳定语义转码矩阵，以及随库固化的 Frictionless Data Package v1 schema |
| RDFC-1.0 | W3C rdf-canon 测试夹具 |
| SPARQL 1.1/1.2 | 完整的 W3C sparql11 + sparql12 + 蕴涵套件，外加第一方的 CONSTRUCT 与 DESCRIBE 语料 |
| SPARQL CDT（SEP-0009） | 随库固化的 awslabs/SPARQL-CDTs 语料——需结合 docs/CONFORMANCE.md 中记录的词法空间分歧来解读，任何上游向量都无法表达这一分歧 |
| SPARQL 执行 governor（执行调控器） | 一份第一方的冻结语料，包含上限区间用例与扩展点用例 |
| SHACL | W3C data-shapes + DASH SHACL-AF/规则 + 一份第一方冻结语料 |
| SHACL 1.2 | 随库固化的整套 W3C shacl12-test-suite：验证、节点表达式、推理规则与 SPARQL 1.2 RL |
| ShEx 2.1 | shexTest v2.1.0（验证、模式、负向语法/结构） |
| 蕴涵 | W3C SPARQL 蕴涵机制用例（经由 SPARQL 测试框架）、随库固化的 W3C OWL 2 套件（DL 相容性，入台账），以及 W3C 自己的 OWL 2 RL 蕴涵测试（规则表的独立判定依据（oracle），入台账） |
| GTS | 冻结的跨语言向量——39 个中有 38 个按字节精确折叠为其已提交的预期结果，第 39 个是一项入台账的分歧，所针对的上游预期结果与本读取器相矛盾 |
| rdflib 直接替换（drop-in） | rdflib 7.6 自身的、随库固化的测试 + 第一方对等性测试 |
撰写本文时，每个套件都是绿色的——例如，已尝试的 shexTest 验证用例 1,105/1,105、W3C SHACL 129/129、编解码器往返 264/264、W3C SPARQL 蕴涵机制用例 70/70，以及在随库固化的 W3C OWL 2 DL 相容性语料上 262/262 个裁决一致，带类型的 OWL 2 分歧为 0 个；SPARQL 台账条目为 0 个。其他套件中未通过的用例仍严格入台账。其中两个数字需要说明其范围：OWL 2 DL 语料是一个_子集_，即 W3C 所发布的 482 个相容性形态用例中的 262 个；而规则表覆盖并不等于蕴涵一致性——在这份随库固化的 W3C OWL 2 RL 蕴涵测试语料上，chase 得分 50/50，即正向 27 个中 27 个、负向 23 个中 23 个，后者意味着未发现不可靠性。请始终以 docs/CONFORMANCE.md 中的当前数字为准，而不是这份快照。
台账纪律
测试框架从不静默跳过。有四种机制保证记分板如实：
- 精确总数——每个测试框架都断言所发现测试的数量，因此语料漂移会显式报错失败。
- XFAIL 台账（预期失败台账）——每个已知缺口都连同原因字符串一起列出，而测试框架会断言它_仍然失败_。修复了缺口却不删除其台账条目会使构建失败（XPASS 纪律），因此这些台账同时也是路线图。
- 特性跳过（仅限 ShEx）——整个规范特性可以按清单中的特性标签跳过，并精确计数。该列表目前为空。
- 单调预算（棘轮）——一份已提交的基线记录每个套件允许入台账缺口的精确数量。实际数量更大时判为 RED（回归），而实际数量_更小_时同样判为 RED，直到把预算调低以锁定这一进步。预算只能向下修改，这使得「跳过列表只会缩短」成为一项机制上的保证，而不是一条惯例。
在本地运行这些套件
make conformance # 单一矩阵
cargo test -p purrdf-shex # 全部四个 ShEx 套件
cargo test -p purrdf-shapes --test w3c_conformance # W3C SHACL 记分板
cargo test -p purrdf-shapes --test w3c12_conformance # W3C SHACL 1.2 记分板
cargo test -p purrdf-sparql-conformance # W3C SPARQL
cargo test -p purrdf-rdf # RDFC-1.0 + 编解码器黄金数据
make projection-oracles # W3C CSVW + 独立的 CSVW/OBO 检查
cargo test -p purrdf-gts # GTS 向量
make check——完整的本地把关检查（fmt、clippy、构建、测试、卫生检查）——作为工作区把关的一部分运行 Rust 套件。
冻结就是冻结
vectors/ 中的 GTS 向量与其他语言的同源 GTS 引擎按字节精确共享，在本仓库中从不重新生成；线路格式由 gmeow-gts 管理。同样的「绝不手工编辑」规则适用于每一份随库固化的语料以及 generated/ 下的一切。