Completes the Wave M B3.5 consolidation slice (b–e), built on #728. B3.5-b — calibration as a first-class evidence subject (`calibration_class`, address `calibration:<class_name>`): RightInspector projection + Evidence Chain Rail semantics (serving-discipline evidence, not runtime truth). B3.5-c / B4a — nullable `LeewayEvidence` read model threaded through turn, replay, cognition-proposal, and math-proposal surfaces, with a shared absence-honest card. B4 is gated correctly: the tuple exists in typed data but no producer populates it, so the card renders absence (verified: no non-null producer in workbench/core/chat). B3.5-d/e — UI-UX-GUIDE.md, b4-leeway-feasibility-gate.md, phase-a-residue-ledger.md. Practice artifact — earn-it-for-real (runner-reproducible). The committed `report.json` (additive earns PROPOSE @0.861, 95/5/50) is now emitted by a deterministic runner rather than copied from the queue. `propose_runner` gains `regenerate_practice_artifacts()`, which runs ONE sealed `resolve_pooled` practice pass and writes BOTH report.json (the per-class ledger the calibration reader consumes) and ratification_queue.json — two projections of one ledger, coherent by construction and byte-reproducible. `runner.main()` delegates to it (lazy import, no cycle), so both entry points produce the identical pair. This closes the gap where a hand-copied report.json agreed with the queue but no runner produced it. `resolve_pooled` is the aggressive sealed PROPOSE-regime scorer (proposal-only/HITL, unsafe for serving, legitimate for attempt-and-eliminate); wrong=5 is the sealed-practice learning signal, NOT the serving wrong=0. No serving/derivation/reliability_gate source touched; the practice lane is not in the serving-frozen SHA gate. Validated: - python -m pytest tests/test_workbench_{calibration,journal,replay,schemas}.py -> 31 passed - python -m pytest tests/ -k "workbench or propose or learning_arena or practice" -> 190 passed (3 failing tests in test_adr_0175_phase2_practice_lane.py are PRE-EXISTING reds on clean origin/main: stale 4/0/46 assertions on build_report, which this change does not touch) - report.json + ratification_queue.json: deterministic (run1==run2) and reproduced byte-identically by both `python -m ...runner` and `...propose_runner` - pnpm build green; 144 UI tests across calibration/leeway/evidence/replay/ doctrine-gates/routes-docs-drift all pass
1.6 KiB
Wave M B3.5-c — B4 Leeway Feasibility Gate
Date: 2026-06-13 Status: B4a read model created; full B4 annotations not yet admitted
Finding
B4 needs a tuple that explains why approximation or leeway was granted:
class_namelicense:PROPOSE | SERVE | blocked | unknownthetaclaim_disclosure:approximate | verified | proposal_only | nonesource_digestcalibration_evidence_ref
Before this slice, that tuple was not present in ChatTurnResult,
TurnJournalEntry, ProposalDetail, or MathProposalDetail. Any UI card that
named class/license/theta would have had to infer calibration state in the
frontend.
B4a Read Model
workbench/schemas.py::LeewayEvidence is now the only lawful tuple shape for
B4 explanations. It is nullable on:
ChatTurnResultTurnJournalEntrySchemaTurnReplayComparisonProposalDetailMathProposalDetail
Frontend mirrors live in workbench-ui/src/types/api.ts. The shared
LeewayEvidenceCard renders the tuple when present and renders explicit absence
when it is null or missing.
Gate Result
B4 UI annotations may start only when a backend producer populates
LeewayEvidence from engine-owned calibration evidence or a lawful backend join.
Until then, Proposals and Replay can show "No leeway evidence recorded."; they
must not explain leeway from frontend-only class/license inference.
Follow-Up
Next PR: B4 producer wiring. Candidate sources are the turn/proposal creation
paths that already know whether a claim is approximate, plus the calibration
reader's calibration:<class_name> evidence subject.