| Both sides previous revisionPrevious revision | |
| provenance:privacy:cookie_syncing [2026/08/26 19:09] – Second review round: log rows 17-26, fix seven stale counts, close the bibliography accounting (and reject the unrecorded-route claim with evidence), record what the number guard cannot see. Authored by Claude karel.kubicek.claude | provenance:privacy:cookie_syncing [2026/08/26 19:11] (current) – Log rows 26-28; correct the whole-page unaccounted count and the windowed-guard claim; state precisely why a digit guard cannot see a stale quantity. Authored by Claude karel.kubicek.claude |
|---|
| - a ''DERIVED'' map, for the two figures this page computed itself from two verified ones (''17,496 / 33,584 = 52%'' and ''850 / 10,814 = 7.86%''), spelled out so a reader can redo the division rather than trust it. | - a ''DERIVED'' map, for the two figures this page computed itself from two verified ones (''17,496 / 33,584 = 52%'' and ''850 / 10,814 = 7.86%''), spelled out so a reader can redo the division rather than trust it. |
| |
| The shared ''check_page_numbers.mjs'' was run first, over the //Use in Publications// window, and passes. Over the **whole page** it reports 42 unaccounted figures, all of them per-paper or per-vendor — which is what the page-specific guard exists to resolve rather than to suppress. Current state: | The shared ''check_page_numbers.mjs'' passes over the //Use in Publications// window. Over the **whole page** it reports **48** unaccounted figures, all of them per-paper or per-vendor — which is what the page-specific guard exists to resolve rather than to suppress. It failed the windowed check once during the second review round, on a bare ''24'' where the report prints ''24.0%''; the figure was right and the prose formatting was not, and the prose now matches the table. Current state: |
| |
| <code> | <code> |
| $ node scripts/cookie_syncing_number_guard.mjs pages/draft/privacy_cookie_syncing.txt | $ node scripts/cookie_syncing_number_guard.mjs pages/draft/privacy_cookie_syncing.txt |
| figures checked: 174 | figures checked: 171 |
| OK — every figure traces to the report, to a verified quote literal, to a named external source, or to arithmetic on two verified figures. | OK — every figure traces to the report, to a verified quote literal, to a named external source, or to arithmetic on two verified figures. |
| </code> | </code> |
| |
| **The guard also let two stale figures through, and the re-review caught them.** After the 29→30 correction the page still said "the 83%" for a value that had become 80.0%, and "the seven rows sum to 29" for a column that summed to 30. Both passed because the digits ''83'' and ''29'' occur elsewhere in the report output — ''83.3%'' as a ''temporal.mode'' share, ''29'' in a dozen places. **A guard that asks "does this digit appear somewhere in the report" cannot ask "does it appear as //this// quantity"**, which is the documented blind spot of the shared ''check_page_numbers.mjs'' as well. The only defence found so far is to re-read the prose by hand after any denominator change; that is what the re-review did. | **The guard let two stale figures through, and the re-review caught them.** After the 29→30 correction the page still said "the 83%" for a value that had become 80.0%, and "the seven rows sum to 29" for a column that summed to 30. Both passed, and the reason is worth stating precisely because it bounds what either guard is worth: |
| | |
| | * ''83'' appears in the report twice, both times as something else — ''83.3%'' as a ''temporal.mode'' share, and ''75–83% accuracy'' as a classifier's accuracy range in one of the papers. The **shared** guard's word-boundary matching does not help: ''83'' really is there, as a whole token, in ''75–83%''. |
| | * ''29'' appears in the report in a dozen places. |
| | |
| | **A guard that asks "does this digit-string appear anywhere in the report" cannot ask "does it appear as //this// quantity."** That is not an implementation defect to fix; it is the ceiling of the technique, and it is the same ceiling the shared script's own comments describe. The only defence found is to re-read the prose by hand after any denominator change. Both stale figures were in prose, not in a table, which is where to look first. |
| |
| Running it during the first review caught nine figures with no pinned source, six of which were per-paper figures the quote check had never been told about; the generic reviewer then found fourteen more of the same kind that the guard could not see because they are //quotes// rather than digits. All are pinned now, which is what took the quote check from 42 literals at first draft to 80. | Running it during the first review caught nine figures with no pinned source, six of which were per-paper figures the quote check had never been told about; the generic reviewer then found fourteen more of the same kind that the guard could not see because they are //quotes// rather than digits. All are pinned now, which is what took the quote check from 42 literals at first draft to 80. |
| | 24 | citations-and-quotes (''sonnet'') | §1 says 7 bibliography entries, §11 says eight | **Accepted**, same fix as 20. This reviewer reached the opposite and correct conclusion about the pre-existing keys, having checked the live export | | | 24 | citations-and-quotes (''sonnet'') | §1 says 7 bibliography entries, §11 says eight | **Accepted**, same fix as 20. This reviewer reached the opposite and correct conclusion about the pre-existing keys, having checked the live export | |
| | 25 | citations-and-quotes | Independently verified the gclid figures and both of its denominators, the ''bekos2023_hitchhiker'' and ''dimova2021cname'' figures, the union/per-method arithmetic, Bashir's "partners" wording and the direction parenthetical, and re-ran all three scripts byte-identically. Confirms §4.2's coverage claim is now true | No action | | | 25 | citations-and-quotes | Independently verified the gclid figures and both of its denominators, the ''bekos2023_hitchhiker'' and ''dimova2021cname'' figures, the union/per-method arithmetic, Bashir's "partners" wording and the direction parenthetical, and re-ran all three scripts byte-identically. Confirms §4.2's coverage claim is now true | No action | |
| | 26 | figures-vs-script (''sonnet'') | See row 17 — the two reviewers overlap on the stale counts | — | | | 26 | figures-vs-script (''sonnet'') | Independently found the same stale counts as row 17, plus two the generic reviewer did not: the whole-page count in §4.5 had drifted from 42 to 48, and the shared ''check_page_numbers.mjs'' had started **failing** over the //Use in Publications// window on a bare ''24'' where the report prints ''24.0%'' — while §4.5 still narrated it as passing | **Accepted.** The prose percentages now match the table's own formatting, both guards pass, and §4.5 records the failure rather than the claim | |
| | | 27 | figures-vs-script | Explained precisely why the stale ''83%'' survived both guards: ''83'' occurs in the report as ''83.3%'' //and// as ''75–83% accuracy'', so even word-boundary matching finds it. Neither guard can distinguish "this digit-string exists" from "this quantity exists" | **Accepted and recorded in §4.5**, in the reviewer's own terms. This is the most useful thing either round produced about the tooling, as opposed to about the page | |
| | | 28 | figures-vs-script | Confirmed both scripts byte-identical to their committed output, every 30/25-denominator table correct, the dead-label diagnostic self-consistent at 3, and every ''DERIVED'' entry arithmetically correct | No action | |
| |
| |
