tech-debt-backlog §5.14: clarify near-zero polysemy column display

[jascal]

Summary

• Tabulates the mango (6) and papaya (7) entries in examples/larql-polysemantic-hierarchical.q.orca.md as ≈0.000 (1.1e-4) / ≈0.000 (6.2e-5) instead of bare 0.000, so a reader running compute_concept_gram_mps directly does not read the rounded display as exactly zero.
• Adds a short paragraph after the tier-summary line documenting the 3-decimal rounding convention and cross-referencing the demo's < 0.05 ASCII heatmap threshold.
• Marks §5.14 complete in openspec/changes/tech-debt-backlog/tasks.md with a resolution note.

Why these magnitudes

Verified against compute_concept_gram_mps on the parsed machine:

• mango (6) → 1.091e-04
• papaya (7) → 6.169e-05

Both round to 0.000 at 3-dp display. Other cross-group entries (strawberry, blueberry, car, bike at ~0.06) are above the rounding floor and keep their plain 0.063 / 0.055 form.

Scope

Doc-only — no code or test changes. The pipeline test tests/test_examples.py::TestExamples::test_larql_polysemantic_hierarchical_pipeline parses the machine and recomputes the Gram, so its tier assertions are unaffected.

Test plan

• pytest tests/test_examples.py::TestExamples::test_larql_polysemantic_hierarchical_pipeline — passes
• pytest tests/test_concept_gram_mps_contraction.py tests/test_examples.py — 58 passed, 1 skipped
• full suite: 1059 passed, 20 skipped

Source

2026-05-01 PR #48 self-review (recorded as §5.14 in tech-debt-backlog).

[jascal]

Code Review — Claude Sonnet 4.6

Verdict: LGTM — approve in spirit (comment-only). Accurate, well-scoped doc-only change that fixes a genuinely misleading display. I independently reproduced every numeric claim.

What this changes

• examples/larql-polysemantic-hierarchical.q.orca.md: mango (6) / papaya (7) polysemy cells go from bare 0.000 to ≈0.000 (1.1e-4) / ≈0.000 (6.2e-5), plus a clarifying paragraph documenting the 3-dp rounding convention and cross-referencing the demo's < 0.05 heatmap threshold.
• openspec/changes/tech-debt-backlog/tasks.md: marks §5.14 done with a resolution note.

Correctness — verified

I ran compute_concept_gram_mps against the parsed machine and confirmed the magnitudes to the digit:

• gsq[0,6] (mango) = 1.0908e-4 → rounds to 0.000 at 3-dp, 1.1e-04 at 2 sig figs ✓
• gsq[0,7] (papaya) = 6.1694e-5 → rounds to 0.000 at 3-dp, 6.2e-05 at 2 sig figs ✓
• The "left as-is" rows are also exactly right: strawberry 0.063, blueberry 0.055, car 0.063, bike 0.055 — all above the 3-dp floor, correctly untouched.

The cross-reference is accurate too: demos/larql_polysemantic_hierarchical/demo.py:85,91,99 defines the heatmap tiers as blank < 0.05, so mango/papaya (~1e-4) do render blank exactly as the new paragraph claims.

Tests & lint

• pytest -k larql_polysemantic_hierarchical → 1 passed. The pipeline test recomputes the Gram and asserts tier bands, so it is genuinely unaffected by prose/table edits — confirmed.
• pytest tests/test_concept_gram_mps_contraction.py tests/test_examples.py → 58 passed, 1 skipped, matching the PR's test-plan claim exactly.
• ruff check . reports 3 errors (tests/test_compiler.py:1755 unused cr_min, tests/test_examples.py:320 unused cr_min, tests/test_mcp_server.py:18 unused import os). None are introduced by this PR — the diff touches only two .md files, so these are pre-existing on main. Not a blocker here, but worth a separate cleanup pass.

Style

• The ≈ glyph is consistent with existing unicode in this file (≤ 0.14 on line 146, ≲ 0.09 on line 153), so it reads naturally.
• Good judgment showing the bracketed scientific magnitude only on the rows where the 3-dp display collapses to 0.000 — adding it to the 0.05–0.06 rows would be noise. The fix is precisely targeted at the actual ambiguity.

Minor observations (non-blocking)

1. The 0.055 rows sit right on the heatmap boundary. blueberry (5) and bike (9) compute to 0.055, which is just above the demo's < 0.05 blank threshold, so they render as . rather than blank. The new paragraph only claims mango/papaya render blank (correct), but a reader cross-checking the heatmap against the table might briefly wonder why the 0.055 entries aren't blank given how close they are to the floor. A half-sentence noting that 0.05 is a heatmap display tier (not a structural cutoff) could pre-empt that, but it's genuinely optional.
2. tasks.md note is thorough — the inline verification values and the rationale for leaving the ~0.06 rows alone make this self-documenting for the next reader. Nice.

No correctness, security, or performance concerns. This is the right fix for a low-severity display-accuracy issue, and the numbers are all reproducible.

This review was posted automatically by Claude Sonnet 4.6.