`unlock` was reported STALE("source data stale 6 business days (as_of 2026-07-15)")
while BOTH its sources were fresh: the Bybit warehouse ran through 2026-07-23 (654
symbols, all features) and the DefiLlama calendar held 1438 future cliffs.
Root cause (systematic debugging, not the calendar): the unlock sleeve shorts only
in the 10-day window BEFORE a qualifying cliff, and `UnlockShortRunner.run()` emits
no row for a day with no position. Inside the LIQUID universe (62 symbols) the last
qualifying cliff was ARB on 2026-07-16 -> last position day 2026-07-15, exactly where
the series stops. Later eligible cliffs (DBR 07-18, KAITO/ZRO 07-20, APR 07-23) are
all OUTSIDE the liquid 62. So the track is correctly FLAT; `as_of` not advancing is
the strategy having no position, not stale input.
forward_health assumed every `recompute` track books a return daily, so it read a
lagging as_of as a source fault. That is a false alarm — and a costly one: it trains
the operator to ignore the unlock=STALE line, which is exactly how a REAL staleness
would later slip through.
Fix: registry marks unlock `definition.event_driven = True`; compute_health exempts
such tracks from the as_of-staleness axis ONLY, reporting HEALTHY with an honest
"flat since <date> (no qualifying event in the window)".
This opens no blind spot — the underlying failures are caught better elsewhere:
* a frozen warehouse trips the CONTINUOUS sleeves (xsfunding/positioning/bybit_4edge),
which do book a return every day and go STALE;
* a frozen calendar turns the weekly unlock_calendar_refresh asset RED (fail-loud).
Everything else still applies to event-driven tracks: no anchor, zero data since
inception, and missing reconciliation ref are all still surfaced.
16 health tests green, including a guard that a CONTINUOUS track with the identical
lag is still STALE (the exemption must not leak) and that an event-driven track with
no anchor is still flagged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Jeroen Grusewski
c58a514d77