builtbykev/vyndr
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

docs: lock-line persistence unblocks the staleness audit (migration 033, lock_lines)

Browse Source 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VsztNChZ7vEvSR61AuMhD1
This commit is contained in:
Kev
2026-07-29 02:49:02 -04:00
parent c7067c80c4
commit 3a05447f77
2 changed files with 15 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
outputs/VYNDR-COMPLETION-MATRIX.md
+2
View File
@@ -183,3 +183,5 @@ Gates the champion's over-CLV signal (partial r=0.375, p≈0.003, n=62 takeable
- This is one significant result among many computed this session — do not overstate. - This is one significant result among many computed this session — do not overstate.
**What would strengthen it:** retain multi-book at lock (enables the sharp/consensus lock-staleness check), and accrue more settled takeable MLB-over rows. Held: no promotion, no served p_win/ev, no capture fix — diagnosis only. **What would strengthen it:** retain multi-book at lock (enables the sharp/consensus lock-staleness check), and accrue more settled takeable MLB-over rows. Held: no promotion, no served p_win/ev, no capture fix — diagnosis only.
**UPDATE 2026-07-29 (commit c7067c8): the lock-multi-book gap is now CLOSED.** New `lock_lines` table (migration 033, applied+tracked) persists each graded prop's per-book lines at the lock moment (`lockLineCapture` in `snapshotService`, fenced RLS-service-role-only, grade byte-identical proven). This unblocks the staleness audit for FUTURE rows — it does NOT retroactively fix the existing 62. Confirmation still needs weeks of accrued lock+close+outcome. Populates from the next snapshot tick.
specs/STATE.md
+13
View File
@@ -61,6 +61,19 @@
> thin n; Phase-2 lock-staleness check BLOCKED (no multi-book retained AT LOCK — `bookprices` > thin n; Phase-2 lock-staleness check BLOCKED (no multi-book retained AT LOCK — `bookprices`
> is Redis current-only); pinnacle sharp ref only n=8 (+3.17pt, hint). Fix that would > is Redis current-only); pinnacle sharp ref only n=8 (+3.17pt, hint). Fix that would
> strengthen it (NOT built): retain multi-book at lock + accrue sample. Promotion HELD. > strengthen it (NOT built): retain multi-book at lock + accrue sample. Promotion HELD.
> ## 🔓 LOCK-LINE PERSISTENCE shipped 2026-07-29 (commit c7067c8): unblocks the staleness audit
> The audit's BLOCKED check (was our locked line stale-high vs consensus AT LOCK?) is now
> being unblocked. New `lock_lines` table (migration 033, applied+tracked) — the lock-time
> analog of `closing_captures`. `lockLineCapture.buildLockRows` persists each graded prop's
> per-book lines (both odds + a lock timestamp) from the in-memory `props` at the lock
> moment (`ts`, no Redis re-read → no TTL race), in `snapshotService` right after
> `enriched`. FENCED: RLS-no-policies (service-role only) + a grep test — read by nothing on
> the grade path; grade byte-identical proven (runSnapshot grades identical with persist
> on/off). **Accrues FUTURE rows only — does NOT retroactively fix the existing 62; the
> confirming audit still needs weeks of settled lock+close+outcome rows.** Volume ~1.5-3k
> rows/day. Populates on the next snapshot tick (14:00 UTC); no promotion, no served edge,
> no capture-of-close change. Next: let it accrue, then re-run the staleness audit.
- **Redirect EXISTS + WIRED:** `closingCapture.buildCaptureRows`→`closing_captures` (append-only, - **Redirect EXISTS + WIRED:** `closingCapture.buildCaptureRows`→`closing_captures` (append-only,
provenance: captured_at/book/line_type/both-prices/missed_reason) via `intradayRefreshService:221` provenance: captured_at/book/line_type/both-prices/missed_reason) via `intradayRefreshService:221`
+ internal endpoint; `ledgerService.attachClosingProb`→`closing_prob` (de-vigs both raw sides, + internal endpoint; `ledgerService.attachClosingProb`→`closing_prob` (de-vigs both raw sides,