The conformance oracle this repo depends on is being replaced, and nothing has been captured from it

[forkwright]

Finding

CLAUDE.md § Roadmap, Phase 2, states the plan's verification basis:

krites serves only as behavioural reference and its tests as a conformance oracle.

That oracle is a live tree in another repo, and it is being actively replaced right now. Nothing has been captured from it here.

The window closes in two independent ways, and neither reports itself:

1. From aletheia's side. The krites de-tether is rewriting modules to sovereign implementations; per the seat driving it, 68 of 210 ledger rows are already sovereign. Every module that flips stops being a witness to the vendored behaviour heurēma was going to check itself against.
2. From this side. The moment heurēma's own HNSW and BM25 land, krites stops being the only implementation of that behaviour — which is precisely the property that makes it usable as an oracle rather than as a second opinion.

Evidence

• krites has 55 test files at aletheia@origin/main under crates/krites/, including the FTS surface (src/fts/{ast,config,indexing,mod}.rs) and vector-search paths (src/data/program/search/{hnsw_normalize,lsh_fts}.rs).
• This repo has captured none of it. A tree listing of origin/main returns 47 files with zero matching conform|oracle|corpus|golden. Verified with a positive control so an empty result is not mistaken for a search that did not run: the same listing returns the six existing test files (api_smoke.rs, index_rrf_composition.rs, persistence_contract.rs, persistence_schema_closed.rs, rrf_correctness.rs, crates/atmis/tests/persistence_memory.rs).

So the verification basis named in this repo's canon exists only as a reference to a moving tree in a repo that is deliberately dismantling it.

Why this matters

Phase 2 writes HNSW and BM25 fresh, permanently — the ruling is replaced, not relocated. That makes a behavioural oracle more important than it would be for an extraction, not less: with no shared code, the only thing linking heurēma's implementation to the behaviour it is meant to supersede is a corpus of observed inputs and outputs. Without one, "reaches parity" is an assertion with nothing behind it, and CLAUDE.md's retirement condition — krites' callers repoint at heurēma once heurēma reaches parity — has no test that can be run.

The failure has a precedent worth naming because it is the same shape one level up. aletheia#6873 records that krites' own Wave 0.5 conformance recorder was never built, and that its precondition ("refuses to run against a tree where any module's status is not derived") now forbids building it, because the sovereign rewrite has already advanced. A guard written to prevent recording the wrong thing became the guarantee that the right thing can never be recorded. Here the window is still open, which is the entire reason to act now rather than later.

Desired correction

Capture the oracle while exactly one implementation of the behaviour still exists, and pin what it was captured from.

• Do NOT extract a corpus from krites' tests. An earlier revision of this issue proposed exactly that, on the reasoning that "data carries no provenance question." That reasoning was wrong and is withdrawn. Copyright protects expression rather than facts, and an individual test case is a fact — this input yields that output, a property of the algorithm. But a curated corpus is a compilation, and compilations carry thin copyright over their selection and arrangement: which cases were chosen, which edge conditions someone judged worth covering, how they are grouped. That judgment is authorial even when every element is factual. Ruled by the seat holding the fleet licence record; extracted test material is treated as derived.
• Primary path — property tests against the published algorithms. Behaviour learned by observing krites is fact; a corpus lifted from it is a compilation. Property tests depend on the published HNSW and BM25 definitions rather than on another repo's artifacts, which is both the safe answer and the smaller claim.
• Middle path, if property tests prove insufficient for parity — author the corpus fresh against this repo's own coverage needs, using krites as a behavioural oracle you run rather than a file you read. The distinction is load-bearing and is the same one that governs the sovereign-vs-derived rule: written against observed behaviour, not written having read the implementation.
• Pin whatever is captured. Any oracle artifact records the krites SHA it was observed against, or it cannot be re-derived or audited and becomes an assertion the moment krites moves.
• Pin the source SHA in the corpus itself. A corpus that does not say which tree it came from cannot be re-derived or audited, and becomes an assertion the moment krites moves.
• Record explicitly which behaviours are not covered. A partial corpus read as complete is worse than a small one known to be partial.

Done when:

• A conformance corpus exists in this repo with the krites SHA it was captured from recorded alongside it.
• Phase 2's HNSW and BM25 are checked against it, and that check is a test rather than a claim in a document.
• The uncaptured surface is named, so "reaches parity" means parity against something stated rather than against everything imagined.

Alternative worth considering rather than assumed away

If a corpus is judged not worth capturing, the honest outcome is to amend CLAUDE.md to stop naming krites' tests as the conformance oracle, and state what replaces them — property tests against the published HNSW and BM25 algorithms would be a defensible answer. What should not stand is the current state: canon citing an oracle nobody has captured and nobody can capture much longer. That is option 3 in aletheia#6873's framing — accepting there is no oracle — and it is fine as a decision and not fine as an omission.

Why the corpus question is stricter here than it looks

This repo is moving to an interop posture, so an obligation acquired here propagates to every consumer rather than staying contained the way it does in the repo that currently holds the material. The corpus would also be load-bearing for the parity claim that governs krites' retirement — material carrying a decision is the last place to accept an unexamined licence assumption. And the asymmetry is one-sided: a wrong "it's fine" authorises a violation that spreads, while a wrong "be careful" costs one alternative implementation.

This is an engineering determination rather than a legal opinion. If the parity claim ever becomes commercially load-bearing, the question deserves a real one.

[forkwright]

Hold on the proposed correction — I made a licensing claim in the issue body that I am not qualified to make.

The body says:

inputs and expected outputs as data, not as a copied test harness. Data carries no provenance question; a lifted harness would reintroduce the licensing one this repo's write-fresh ruling exists to avoid.

That sentence should not stand as written. Whether a curated test corpus extracted from MPL-2.0 sources is materially different from the code it was extracted from is a licensing judgment, and I asserted it as settled inside the reasoning for an action. "It's only data" is exactly the shape of argument that sounds obviously right and is worth checking before anyone relies on it.

Why it matters more here than it would elsewhere. This repo is moving to an interop posture — a library other repos are meant to depend on. An MPL obligation acquired here propagates outward to every consumer, rather than staying contained the way it does inside the repo that currently holds it. The fleet's governing rule (derived code is rewritten, sovereign code is abstracted, only the second is relicensable) is framed around implementation code. A conformance corpus is neither: it is material extracted from another repo's test suite, landing in a library, serving as the evidence base for the parity claim that governs that repo's retirement.

So this is the same hazard the licence work is watching for, arriving through a door nobody was watching — while attention is correctly on the HNSW implementation.

Referred to the seat that holds the licence record, and I am not acting on the proposed correction until it comes back. The finding itself is unaffected: the oracle this repo's canon names is being replaced, nothing has been captured, and the window is closing. Only the proposed remedy is on hold.

If extracted test material does carry the obligation, the alternative already stated in the body stands and becomes the primary path: property tests against the published HNSW and BM25 algorithms, with CLAUDE.md amended to stop naming krites' tests as the conformance oracle. That is a smaller claim and a cleaner one — it depends on published algorithms rather than on another repo's artifacts.