Reply draft v2 — knowledge-catalog #207 (leesharks000)
Revised after five-substrate review; fixture corrected first, prose second.
The corpus is ready, and it speaks the vocabulary settled in the thread: https://www.alexanarch.org/datasets/deletion-conformance-fixture/
111 cases across 17 classes, from the 2026-06-19 termination and its aftermath. Every case carries axes — validity, presence sparse exactly as settled (removed | never_landed, no marker for the default), edges separate from both — plus two things the review process forced on me: an axis_subject naming what each axis value is about (record-presence and target-presence turned out to be different questions, see below), and machine-readable expected blocks so an implementation can actually pass or fail. Validity is never derived from identifier survival; identifier cases carry unassessed unless something independent establishes a truth value. The reason objects do real work: 52 cases carry actor: host, reason: not_disclosed — truthfully, since no per-record rationale was ever provided — and 12 more attest a disappearance while withholding the actor, because the registration-erasure layer can't be attributed from probes.
Three findings. A registry_resolution_divergence class went 8 for 8 at build (2026-07-28): a GET of the DataCite record endpoint returned state: "findable", parsed and UTC-timestamped, while DOI resolution returned 410 in the same run. Not two authorities contradicting each other — one identifier with two subject-relative presences: the metadata record is retrievable, the target is gone. Second, never_landed proper appears once, clean: a registry asserted a body at a path where none existed, checkable where asserted, caught by a check, commit-hashed. Its inverse — content landed, registry update didn't — is retained as a separate class with presence deliberately unmarked, so the presence axis isn't made to carry transaction atomicity; if that direction deserves a name, that's your call, not my unilateral extension. Third, your removal/destruction split is embodied: two producer withdrawals where the removal-fact resolves publicly with its reason while the content was destroyed on the separate disclosed path.
Verification is offline by default (verify_offline.py: schema, counts, sparse-rule and subject invariants — it caught one of my own inconsistencies on its first run); live re-probing is a separate optional script that emits dated observation reports and never mutates expected results. The drift ledger between same-day versions is derived from the mapping-level diff, including a correction to my own v1 population figure. Dataset CC0, scripts MIT, manifest sealed with hashes and source commit, so it vendors without friction.
When your exporter ships, I'd like to run its shape against these cases and send you what breaks.
