Commit Graph

2 Commits

Author SHA1 Message Date
builtbykev 3f7aa368c4 The seam never ran: an undeclared variable, and a bare catch that hid it
LIVE was switched on in production and nothing happened, because
`snapshotGating.stripModelPrice` contained

    try { rows = require(...).applyToRows(rows); } catch { }

`rows` is not declared in that function — the parameter is `grades`. Under
'use strict' that is a ReferenceError on every call, and the empty catch
swallowed it. For an entire release the seam was dead, the status surface
reported LIVE ON, and every row was served raw.

Two failures, and the second is the one that mattered: a silent catch turned a
hard crash into nothing at all. It now names the failure in the log and degrades
to uncalibrated rows explicitly.

The entitled branch also returned `grades` — the original array — so even a
working seam would have had its output discarded for exactly the tier meant to
receive it. Both fixed; `grades` is threaded through.

MY TESTS COULD NOT SEE IT. They called `applyToRows` directly and grepped the
source for the require line. Neither exercises the boundary, and a source grep
is not proof a line runs: the dead wiring contained that exact require. The new
tests call `stripModelPrice` and assert on its RETURN VALUE, entitled and
unentitled, plus a throwing-seam case that requires the warning.

Verified on real production rows through the real entitled path:
  0.706 -> 0.625 CERTIFIED, EV recomputed 8.7 -> -3.7, grade B unchanged
  0.858 -> unavailable UNCERTIFIED, its value:true WITHDRAWN, grade B+ unchanged
  rbi   -> untouched
  free tier -> model fields still stripped

Found only because the live acceptance measured real rows instead of trusting a
green suite.

Suite 407/407, 5,697 passed. Teeth 48/48 + 10/10 + 23/23.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CQJeAG8vcDoL5zkiaJyVb8
2026-09-04 22:45:43 -04:00
builtbykev 84f1fc075c The live machinery ships dark, behind two gates that cannot substitute for each other
ATTRIBUTION RECEIPT (cohort 27ce152f, writer 94f7c3c, 01:02:19Z): 2,316 non-hits
rows — certified 0, numeric 0, and artifact_id / estimator / certification
version / source / knot / curve ALL ZERO. The hits slice held: 209 published,
201 certified, curve mismatches 0/201, artifact identity deviations 0, support
violations 0, raw erased 0. Shadow tranche frozen.

AUTHENTICATED NON-LEAK: obtained through the owner magic-link flow — the real
auth system, no bypass, no stored password, token never printed, session
discarded. /api/ledger, /api/ledger/accuracy, /api/preferences, /api/accuracy
and the authenticated /api/snapshot/mlb (677KB, full model fields) carry zero
shadow keys. One scanner hit adjudicated: `served_grade.calibrated` is false on
all 504 rows — servedGrade's hardcoded constant from before this work, a name
collision with my keyword list, not the shadow.

A REAL MONITOR DEFECT, asked for and found. The row floor alone let 400
observations from ONE slate reach HEALTHY or DRIFT — one correlated draw wearing
the costume of four hundred. The monitor now also requires settled DATES, and
the floor is not invented: it reads
`fitPolicy.POLICY_V1.certification.eval_block_dates`, the 3-date fold the
walk-forward was actually certified with. One date and two dates now return
INSUFFICIENT_SAMPLE regardless of row count.

That fix had a bug of its own that a test caught: `scored` never carried `date`,
so the distinct-date count read `undefined` for every row and always returned 1.
The gate looked correct while measuring nothing.

THE SEAM. EV, Kelly and VALUE are produced in exactly one place at grade time,
all from p_win, and every served row passes exactly one boundary on the way out
(`snapshotGating.stripModelPrice`, used by the snapshot route, hero route,
topGraded and props). So `servedProbability.applyToRows` sits there — one place,
not four call sites and four chances to miss one. Consumers never see the
artifact, the curve, the support region or the environment; a test forbids
`applyCurve`, `applyIsotonic`, `artifactRegistry` and `served_curve` in all three
serving consumers.

Placed BEFORE the tier strip deliberately: calibration decides what the number
IS, entitlement decides who may see it. Reversed, it would calibrate fields that
had already been removed.

TWO GATES, NEITHER SUFFICIENT. The artifact is promoted APPROVED_FOR_LIVE — stage
only, same id, same source/knot/curve digests, same cutoff, no refit. Behaviour
is still OFF because PROBABILITY_CONTRACT_LIVE is unset. Flag without approval:
OFF. Approval without flag: OFF. Both: ON. Live OFF returns rows byte-identical
and consults no artifact.

Two teeth had to be rewritten rather than satisfied: they pinned "artifact
unapproved" as the safety property, which would have blocked the deliberate
promotion. The property is that live BEHAVIOUR is off, and they now test that.
And my own splice while fixing one of them silently deleted ten newly-added
teeth — caught by counting ids, not by the runner going green.

Suite 406/406, 5,681 passed. Teeth 41/41 + 10/10 + 23/23. Live OFF.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CQJeAG8vcDoL5zkiaJyVb8
2026-09-04 06:36:11 -04:00