Submitted 2026-08-26. Cohort entry added (Adjacent 2/2, cohort now
4/10, channel weak x3) and decision logged.
The finding that matters is not the submission. The application form's
preferred-work-location selector offered no Zurich, despite the JD body
reading "in Miami, Zurich or New York", the posting header listing
Zurich, and the site's own Zurich location filter returning this exact
req when checked on 2026-08-25. The careers site footer reads Citadel
Enterprise Americas LLC, so the likeliest explanation is a US-entity
apply flow with European seats routed elsewhere, or a Zurich seat that
is closed while the multi-location posting stands.
This partly supersedes the working-model risk that blocked Phase 2. If
no Zurich seat is reachable through that form, whether Zurich runs
hybrid or five-day onsite is moot, and the application may be sitting
against a US requisition - a hard no under the standing no-relocation
constraint.
Carry-forward rule recorded in both CLAUDE.md and the session file:
check the application form's location selector before investing in a
package. Two independent signals - the posting's stated locations and
the employer's own location filter - both proved unreliable as evidence
that a seat is actually reachable. Phase 0 treated the filter result as
confirmation that the req was live in Zurich; that inference was weaker
than it looked.
Package itself is finished and reusable: both documents cleared the
validator with zero warnings and the Tier 1 fixes lifted JD term
coverage from 51% to 68%. Nothing about the documents is the weak point.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MHtzyTKBcg6BWhD5qFegtK
application_cohort.json was caught by the blanket job_scout/state/*
ignore, so the cohort slot record (core/adjacent/stretch mix and every
application's fit class, evidence fit, hard gate and outcome) existed
only on one machine. decisions.json escaped the same rule only because
it had been tracked before the rule was added - an accident of history,
not a decision.
Both files are durable application history and belong in the repo. The
churny scan state (seen_jobs.json, last_scrape.json) stays ignored, as
does reports/ - all of it is regenerable by re-running the scout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MHtzyTKBcg6BWhD5qFegtK
dennisthiessenandClaude Opus 5