1
0
Fork 0

docs(census): the two wiki corpora are measured, and the tightening is thinner than zero looked

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.
This commit is contained in:
Kjell Tore Guttormsen 2026-08-13 20:22:18 +02:00
commit be9759b4b3
3 changed files with 71 additions and 10 deletions

View file

@ -10,7 +10,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
Nothing yet.
## [0.7.0] — 2026-08-12
## [0.7.0] — 2026-08-13
### Added — `active:raw-html-link`, a click-required carrier class for raw HTML
@ -53,6 +53,37 @@ boolean could only express a narrowing, never a regrade. Left as a boolean, ever
carrier candidate would have measured equal to PRODUCTION — silently, and in the
direction that reads as "no change helps".
### Measured
`docs/rawhtml-census.py`, three populations, each at one corpus state and each
against its own denominator — the two wiki corpora share content and are never
summed. Documents that stop being `fail_secure` under `PRESET_USER_UPLOAD`, from
0.6.0 as shipped to 0.7.0, with the ceiling being the raw-HTML detector switched
off entirely:
| population | documents | 0.6.0 → 0.7.0 | ceiling | share of achievable |
|---|---|---|---|---|
| reference-corpus | 389 | 54 → 53 | 53 | 1 of 1 |
| vendor-harvest | 187 | 62 → 20 | 18 | 42 of 44 (95%) |
| generated-notes | 552 | 59 → 15 | 13 | 44 of 46 (96%) |
**Neither change alone is worth shipping, and the census is why they went out
together.** Alone, the split frees 8 documents in each wiki corpus and the
narrowing 21 and 23 — but 8+21 measures 42 and 8+23 measures 44. The residual is
**13 documents in both corpora**: the narrowing strips a document's `</a>` and
`<Frame>`, and what is left is the `<a href=...>` the split grades down, so each
change alone leaves the document blocked by the other's residue.
**Tightening, measured: 0 documents on both trust tiers, in all three
populations.** That zero is empirical and thinner than it looks — the split
*alone* tightens 13 documents on the trusted tier in vendor-harvest and 14 in
generated-notes, and the narrowing cancels each one. See `docs/LIMITATIONS.md`
for why it must not be read as "cannot happen".
The `PRODUCTION (as shipped)` row matched `C1 + D (0.7.0)` field for field in
every population, which is the check that the census and the shipped predicate
have not drifted apart.
### Known behaviour change
**`count` drops on documents containing `</a>`.** Through 0.6.1 an end tag was