cron-delay-capture — capturing GitHub-Actions cron-delay telemetry as a forward stream: considered and REJECTED

status: dismissed · considered panel run 16 (2026-09-01), frontier scout, prompted by the displaced-cron week (research/2026-08-31_displaced_cron_regime.md) · verdict: fails three of the four capture bars

What was considered. The displaced-cron regime (scheduled runs firing 5.6–9.3h late since 08-26) made "record our own cron delays as a forward capture stream" the obvious candidate — and the single most likely re-proposal next time the scheduler misbehaves. Rejected on the bars:

Mechanism — fails outright. Runner-queue latency on GitHub's shared infrastructure is operations telemetry about our own scheduler, not market data. No counterparty, no channel by which it could carry cross-sectional equity signal. Conflating "affects our fills" with "predicts returns" is the category error.
Un-backfillable — fails. Workflow-run metadata (created_at vs scheduled time) is retrievable from the Actions API within its retention window — the 2026-08-31 audit built its delay table retroactively, which is the existence proof.
~Zero marginal cost — moot, but the legitimate ops value is already captured free: every audit memo and CAPTURES.md entry timestamps the delays in git.

Reopens if

(a) any consumer needs delay telemetry older than the Actions API retention window (~90 days) that git commit timestamps cannot reconstruct — commit times proxy run end, not queue time, and the proxy has known error; or
(b) a delay-conditioned trading or capture decision is ever proposed (e.g. "skip/resize when the run fires >X hours late"). At that point lateness stops being telemetry and becomes a decision input, and forward capture with pinned provenance becomes mandatory before the rule can be evaluated honestly.

Both are live tripwires future panels evaluate, not decoration. Absent either, re-proposing this stream is C0 relitigation.