Recovering the issued levels

Measured 2026-09-03 across 139 closed rides Implemented in toRide() in src/ledger.ts

Mechanical R is only meaningful against the levels as promised, not as currently stored. A stop that has been ratcheted is a different number from the stop that was issued, and scoring against the ratcheted one measures nothing.

The desk does not keep the promise in one reliable place.

The four sources, weakest wins

packet_json.expected.target_pct        86   structured, typed, trustworthy
position_events entry note             11   append-only, immutable by construction
positions.target_price                 14   the mutable row
expected.thesis prose                 ~10   parsed out of free text
nowhere                                18   unscoreable, and marked so

provenance on IssuedPlan records which source was used, and the weaker of the stop and target sources is what the pair is worth. A ride whose stop is structured but whose target came from prose is a prose-grade ride.

The correction worth remembering

The structured field expected.target_pct is null on 88% of all rides, and that number was briefly reported as "the issued target is unrecoverable on 88% of rides". It is not. Those are different claims — the first is about a field, the second about an outcome — and only the first was tested. On closed real rides the target is recoverable 87% of the time (121 of 139).

The entry note

The entry event's note carries the plan in prose, written at entry:

position 172   "…the ticket's exits $19.27 → $20.5 on the row"
position 171   "…the ticket's exits $21.73 → $23 on the row"

It recovers 11 rides and adds zero coverage — every one of them also has the value on the row. What it adds is provenance: position_events is append-only, so a level read there was demonstrably the level at entry, while the row is merely one that nothing has happened to overwrite. It is preferred for that reason alone.

The row is safe only by accident

Reading positions.target_price is legitimate today because no target has ever been moved:

ride_events where event='door.moved':  12 rows, ALL door="stop", all from=null

That safety is a property of what has not been built yet. ratchet-stop recommendations already exist (16 of them), so ratcheting is a live concept. The day anything ratchets a target, this fallback dies retroactively for every ride at once — because a moved target and an issued one are indistinguishable in that column after the fact.

Persisting target_pct structurally is therefore not a repair of today's data. It is insurance against an unrecoverable break later.

Positions are not versioned

Checked explicitly, because it would solve the above if it were true:

• ride_context is exactly one row per ride (2,198 of 2,198), with v = 1 on every one. That v is a packet schema version and has never been incremented.
• No table anywhere carries version, revision, valid_from/valid_to or superseded_at.
• The only history is the append-only event log: position_events averages ~15 events per position (up to 78), plus ride_events.door.moved.

So there is a history of changes, but no "position as of time T" snapshot to read.

On adding created_at / updated_at

Asked 2026-09-03. Worth doing, for a narrower reason than it appears:

• updated_at earns its place for incremental scoring. closed_at catches newly-closed rides but misses rides amended after close — and those exist (position_events carries 3 data-correction rows). A corrected exit_price on an already-scored ride would never trigger a re-score.
• created_at would have disambiguated the LHAI bug — a row written at 12:00Z and stamped 13:30 is a timestamp bug; one written at 13:30 is a price bug. Opposite fixes, currently indistinguishable.
• It is not a tripwire for overwritten levels. It says something changed, not which field or what it was, and result_r/mfe_r/mae_r live on the same row, so it churns for reasons unrelated to levels.

If added: both columns, updated_at maintained by a trigger rather than application code so a new write path cannot forget it, and created_at backfilled from entered_at with that approximation recorded rather than implied.