HBAI adapter: read office:value — full precision, display text as a consistency guard - #73
Merged
Conversation
The #44 follow-up sol flagged on the #48 gate: the adapter kept the DISPLAYED text (rates rounded to whole percents, counts to 0.1M) while the workbook stores the unrounded value in the ODS office:value attribute — e.g. 75.875 behind a displayed "75.9", 0.15911572... behind the published 16% headline. Mechanism: cells become Cell(str) — string identity keeps every label, regex, and repetition read untouched — carrying (office:value, value-type) when numeric. parse_value prefers the stored value (percentage-typed cells align fraction -> display scale so the one kind conversion applies to both types) and REQUIRES the display text to be its rounded rendering at the text's own precision: a mispaired cell aborts the run, never emits. The adapter's 13 headline checks become rounds-to assertions (the publication's figures are the rounded renderings); all pass, structural completeness gates unchanged. Regenerated: data/externals/hbai-poverty.json (13,056 rows, identical shape, values unrounded) and the DB re-ingested (same accounting 15,851/1,073/1,829; anchors identical; zero of 6,528 rate claims still sit at exact 2dp — previously all did). annotations.json rounding-precision note updated: the DISPLAY is rounded, these values are not. Tests: 7 added to tests/test_hbai_adapter.py alongside the original completeness suite (mechanism, percentage alignment, the rounded-rendering guard both ways, text-only fallback, emitted-file precision with a regression-proof threshold, and the vendored 75.875 cell). Suite: 243. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Aug 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The #44 follow-up from the #48 gate (sol round 1, finding 9b): the adapter
parsed the displayed text — DWP renders rates to whole percentage points and
counts to 0.1 million — while the workbook stores the unrounded value in each
cell's office:value attribute (75.875 behind "75.9"; the 16% headline is
0.15911572...).
Cells are now Cell(str) objects carrying the stored value; parse_value prefers
it (with percentage-typed fraction alignment) and requires the display text to
be its rounded rendering — a mispaired text/attribute aborts the run. The 13
inline headline checks become rounds-to assertions and all pass; the
completeness gates are untouched.
Artifacts regenerated: hbai-poverty.json (13,056 rows, same shape, unrounded
values) + the DB re-ingested (accounting and anchors identical; zero of 6,528
rate claims still sit at exact 2dp — previously all did). Per sol's ruling on
#48: claim ids are value-independent, no HBAI comparisons exist yet, so this
lands cleanly before any are run.
Dual gate: fable review done; sol pass next.
🤖 Generated with Claude Code