0.7.0 shipped with its corpus numbers deliberately absent: the census had only
run on reference-corpus, which the 0.6.0 narrowing had already emptied of
raw-HTML drivers, so it bounded the change rather than showing it. Both wiki
corpora are now measured through the pinned instrument, in one session because
they are living populations.
Under PRESET_USER_UPLOAD, 0.6.0 as shipped -> 0.7.0, each population against its
own denominator (the two wiki corpora share content and are never summed):
reference-corpus 389 docs 54 -> 53 ceiling 53
vendor-harvest 187 docs 62 -> 20 ceiling 18 42 of 44 achievable
generated-notes 552 docs 59 -> 15 ceiling 13 44 of 46 achievable
PRODUCTION matched C1 + D field for field in every population, which is the
check that the instrument and the shipped predicate have not drifted.
Two things the measurement changed rather than confirmed:
The pair is superadditive by 13 documents in BOTH wiki corpora. Alone, the split
frees 8 in each and the narrowing 21 and 23; together they free 42 and 44.
Shipping either alone would have measured as barely worth the label.
The TIGHTENS column reads 0 on both tiers in all three populations, but that zero
is empirical and thin: the split measured ALONE tightens 13 documents on the
trusted tier in vendor-harvest and 14 in generated-notes, and the narrowing
cancels each one. LIMITATIONS now says so explicitly, so nobody reads the zero as
'cannot happen' -- the escalation is still constructed and pinned by
test_split_tightens_the_trusted_tier_when_both_carriers_are_present.
generated-notes counted 552 documents, not the 550 the scratchpad probe saw.
Living corpus, measured fresh.
791 passed; coverage 129/129, 6/6 documented gaps hold.
Kjell Tore Guttormsen
be9759b4b3