ERN-1 — the earnings-date-as-EXPECTED panel: scout run 1's one PROVISIONAL kill, migrated out of the frozen archive so its tripwire is visible to ls

status: dismissed (PROVISIONAL, inherited) — originally killed by PANEL scout run 1 on 2026-08-17; migrated into queue/dismissed/ by PANEL run 24 (2026-09-16) · class: records hygiene / forward-capture candidate · never occupied a row in queue/open/ · costs no open-queue slot and no trial-registry row · does NOT discharge the scout's 8-week cadence clock (fires ~2026-10-12)

Plain-language summary for an owner reading one paragraph. When the scout half of the frontier lens ran for the first time, it considered twelve possible new data captures and killed eleven of them outright. The twelfth — recording each company's expected earnings announcement date, as of the day we see it — was killed only provisionally, because the kill rested on "no free endpoint we can reach with credentials we hold", and the census had missed that this repository already holds an unused API key that plausibly serves exactly that endpoint. So the kill was made conditional on one question to you, answerable in about a minute. That question has never been asked, and 30 days have passed. Worse, the conditional kill was written only into research/RESEARCH_QUEUE.md — the frozen pre-migration archive — so after the queue became a directory, no future panel could find it by listing the tree. This file fixes that. It changes no verdict and asks for no work; it moves one adjudication to where the memory system can see it, and gives it a dated default so it cannot rot further.

What the idea is, and why it was not killed outright

Record, every day, the expected (not realized) next-earnings date for each name in the universe — the Johnson–So date-revision class. The un-backfillable part is the revision: a vendor's calendar shows today's best guess, and when the guess moves, the old guess is overwritten and gone. History can be bought; history of expectations cannot.

Honest mechanism sketch, as originally recorded: earnings-date revisions are watched closely by a small set of participants and ignored by most systematic flow, so a date that quietly slips is information about a company's own reporting process arriving before the event it describes. The counterparty is calendar-inattentive flow. That is a thesis, not proof — which is the right standard for buying an option rather than running a trial.

Why the kill is provisional — the unasked question

Verified again this run at HEAD 7fd0d74: FMP_API_KEY is wired into three workflows — paper-trading.yml:96, monthly-revalidation.yml:58, retrain-model.yml:48 — and is referenced nowhere in src/ (grep over the source tree returns nothing). It is vestigial but HELD, and FMP documents an earnings-calendar endpoint.

The original text (research/RESEARCH_QUEUE.md:2350, frozen archive) therefore reads: "this dismissal is PROVISIONAL: one-time owner check needed (is the secret live? does its tier serve the calendar endpoint?) — if yes, (9) converts to a live scout candidate for the full four-bar test; if no, the kill line completes as 'FMP key held but dead/insufficient-tier' and stands."

The frontier watch logged it as still-unrun on 08-18, 08-19, 08-20 and 08-21, then stopped mentioning it. No probe commit, no memo, no research/ file outside the archive mentions FMP or an earnings calendar.

The structural complaint, which is the reason this file exists. The 2026-08-21 queue-as-directory migration's whole memory guarantee is that a panel can ls research/queue/dismissed/ and see every adjudication with its tripwire attached. A conditional kill reachable only through a frozen archive is exactly the rot ops/RESEARCH_PANEL.md "What matters here" #2 names — a dismissal that future panels skip instead of evaluate. Same failure class as BTB-1: a recorded basis the shop's own artifacts cannot check.

The owner's one-line question

Is FMP_API_KEY still live, and does its tier serve the earnings-calendar endpoint? (One curl against the documented endpoint with the held key answers both.)

Reopen condition — with a dated default, so it cannot rot again

• If YES (key live and tier serves the calendar endpoint): this converts to a live scout candidate and must clear the full four-bar test (un-backfillable · ~zero marginal cost · mechanism sketch · activation pin AND sunset) on its own merits. It must additionally clear the same scout run's "exhausted large-cap event space" finding, which is what killed the Alpaca corporate-action announcement feed — a shared reason that does not disappear just because a credential turns out to work.
• If NO, or if UNANSWERED by 2026-10-12 (the scout's own cadence date): the kill line completes as "FMP key held but dead/insufficient-tier" and this dismissal stands permanently, with no further owner action required.

Related and not separately proposable before this resolves (C0): the IPO-calendar-as-expected sibling, recorded riding this same provisional kill in scout run 3 (2026-08-19).