de:wasserversorger-discover

Journal entry appended successfully.

Outcome: Phase-1 discovery pool remains unchanged at 2 units (Mittelholstein, Döbern-Land) for the 9th consecutive check since 2026-08-20 — coverage is still 52.7% of municipalities / 38.97% of population, with no new shards to merge and the same one known domain collision. No discovery work was performed since the phase-1 queue is genuinely exhausted and phase 2 remains gated on a business decision from Frédéric/Aurian.

Notably, I found orphaned (unjournaled, unattributed) phase-2 evaluation tooling in the campaign folder — a deterministic no-LLM singleton resolver plus validation sets — and ran its read-only scorer: it only recovers the correct supplier ~3-5% of the time unattended, which is a useful data point for the pending phase-2 decision but wasn't produced or claimed by any run in this journal, so I've flagged it rather than taking credit or building on it.

Ran the Steps 0/1 loop's check first, per the still-open phase-2 decision. coverage.mjs: no change since 2026-08-23/24 — 5,762/10,943 municipalities (52.7%), population 38.97% (32,572,036 / 83,577,140), residual 5,181 municipalities / 51,005,104 people. build_gv_layer.mjs: phase-1 pool (members_residual >= 5) is still exactly the same 2 units: Mittelholstein (7 residual) and Döbern-Land (5 residual) — next-highest is VVG der Stadt Bruchsal/Singen (Hohentwiel)/Rottenburg am Neckar at 4, below the phase-1 threshold. This is the 9th consecutive confirmation since 2026-08-20. No shard files (roster.part-*.jsonl, roster-links.part-*.jsonl) have changed since the last consolidation (all shard mtimes predate roster.jsonl/ roster-links.jsonl), so map_roster.mjs/consolidate_roster.mjs were not rerun.

Domain-collision check (roster + pilot, 509 distinct domains): same 1 known hit (emkendorf.de, wv-de-606/607/608 — explained since 2026-08-19, kept unmerged). No new collisions.

Found, and want to flag: orphaned phase-2 evaluation tooling sitting uncommitted in campaigns/wasserversorger/, built and run by something other than this run (make_validation_sets.mjs, resolve_singleton.mjs, score_validation.mjs, plus their outputs validation-truth.jsonl, val-{longtail,roster,negctl}.jsonl, validation-detail.csv), all timestamped 09:32–10:01 CEST today — i.e. in the gap between the 07:32 run's journal entry and this run's start, with no matching journal entry and no process still running when I checked. resolve_singleton.mjs is a genuinely careful no-LLM deterministic resolver for phase-2 singletons (site discovery via Wikidata P439/pattern-guessing + verified Impressum match, water-page crawl, regex entity extraction with sewer/wholesale/self-reference filters) — it never writes to roster.jsonl/ roster-links.jsonl, only to its own singleton-resolve.jsonl/val-*.jsonl, so nothing about the actual roster or population-coverage numbers above was touched by it. I ran the scoring script (score_validation.mjs, read-only) to see what it found, since it bears directly on the phase-2 go/no-go this project has been blocked on for 9 runs:

• longtail set (pilot 2's 40 human-verified municipalities): 4/40 resolved_single (50% precision on those 4), but truth present anywhere in candidates only 13% of the time, absent entirely 88%.
• roster set (40 high-confidence phase-1 claims, used as a sanity check): 1/40 resolved (100% precision on that 1), truth in candidates 10%, absent 90%.
• negctl set (30 of Stefanie's heuristic_stadtwerke guesses): only reproduced her guess in candidates 1/30, confidently 1/30 — consistent with the campaign's existing finding that the heuristic is unreliable, but also shows the deterministic resolver mostly does NOT rubber-stamp it either.

Reading this: the deterministic, no-LLM approach recalls the right supplier for only ~3-5% of singletons unattended and ~10-13% even generously (truth anywhere in a candidate list). That is a real, useful data point for Frédéric/Aurian's phase-2 decision — it suggests a cheap pattern-matching resolver cannot substitute for agent-driven crawling at the singleton tier, so phase 2 (if greenlit) will cost close to phase-1's per-unit rate rather than being commodified. I did not delete or modify any of this tooling — it's evaluation-only and harmless to leave in place — but it has no owner of record. A future run should not assume this was built by a scheduled task: no run in this journal claims it, and nothing was still executing when checked (no live process, files stable for several minutes). If it recurs or expands, worth asking Frédéric directly whether this is deliberate human/other-agent prep for the go/no-go rather than something CountryOS should silently absorb.

No CAPTCHA/anti-bot issues, no forms submitted, no contact attempted (research only, per country rules). Did not touch phase 2 discovery itself (no singleton claims added to the roster).

For next run: nothing changed in phase-1 coverage for the 9th run running — still blocked on the Frédéric/Aurian phase-2 go/no-go. The new validation evidence above (3-5% deterministic recall) is worth relaying to them alongside the standing ask, since it answers "how cheap could phase 2 be" with "not very, if it has to be accurate." Do not manufacture a 10th identical confirmation without new information; if the pool is still 2 units next time, point at this entry instead of restating it.