RUAG C5I - AI Engineer C5I (Thun, app ID 18027): SUBMITTED 2026-08-27.
Evidence Fit 74/100, fit class Stretch, title-capability hard gate FAIL
(R1 build/operate the AI-LLM platform and R2 in-house LLM/retrieval are
Adjacent, not Direct) - all knowingly accepted under the user's explicit
Phase 0 override. Consumes the cohort's sole Stretch slot: cohort is now
6/10, Stretch 1/1.
Critique ran twice. Round 1 scored the documents 85/100 and raised three
Tier 1 items; Round 2, after the fixes, scores 93/100 with truth and
provenance 24/25 and zero Tier 1 findings. Evidence Fit did not move and
was not allowed to: PP-3 is a personal project and cannot convert an
Adjacent title-capability into a Direct one.
Documents (.tex is the deliverable; PDFs are gitignored):
- resume 2pp/13 bullets, letter 1pp/295 words, both validators PASS
- headline is now the canonical title "Staff Data, Analytics & AI
Engineer", which puts the req's own word above the fold
- PP-3 added as a Projekte section - the only current Linux/hardening
evidence, since BS-6 ended Dec 2022
- the letter names the AI-platform gap in one sentence, then connects
SW-5 to C5I's stated DevSecOps model
- "governte" -> "governance-konforme"; JD term coverage 18/22 -> 22/22
claimable, with all six gap terms still correctly absent
Two defects found and fixed that the first critique missed:
- the resume never loaded babel, so a German document was hyphenated
with English patterns (Hal-bleiterfertigung, Tran-skription). Fixed
with babel[ngerman] plus a Transkription exception; this also cleared
an overfull box. Check this on every future German package -
resume_template.tex likely has the same omission.
- IBM AI Engineering had no primary-source record. Certificate read
directly (IBM via Coursera, 4 Jun 2020, verify 3ZBZFVAL6A34), recorded
as entry #8; it also proves PyTorch, now evidence: certification.
Also included: the submitted Kdo Cy DevOps Engineer III package, the
Capgemini omit rule promoted into config.md, BW-1 canonicalized in
experience_bundeswehr.md, and a scout.py comment correcting the
telenorgroup slug from "near-empty" to a claimed board serving stale
phantom listings that DEMO_TITLES would not catch.
Compensation, PSP/project eligibility and role level were never resolved
before sending and are now live screening topics.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JMcHCsTKWvVzqyLChF5ckk
Rejected 2026-08-27, no interview, ~28 days after submission. Recorded
in all four places that track an outcome: cohort state, decision log,
the Active Sessions row and the session file's status block.
The cohort slot is not freed. A rejection consumes an attempt the same
way a submission does, so the Adjacent count stays 2/2 and the cohort
stays 4/10 - unlike the Google FDE III and AWS FDE no-gos, which were
declined before a package existed.
Recorded as rejected_no_interview on the evidence: nothing in the log
shows any contact after submission. Recruiter-vs-hiring-manager
disposition is a tracked cohort variable, so this is one edit away from
being corrected if a screen did happen.
The package was validator PASS with no Tier 1 truth findings and the
follow-up email to Per Olav Marthinsen was never actioned, making this a
pure cold submit. A cold-channel no-interview rejection does not
implicate document quality on its own. That is now 2 of 4 cohort
applications rejected without interview, both cold, which fits the
channel thesis already in the log - and application_strategy.md forbids
reacting to a single rejection, so no positioning or targeting changed.
The Norway lane is explicitly not closed. NATO JWC Stavanger is still
live and strong Norwegian employers remain in scope; both the row and
the decision note say so, because with Aker BP closed the earlier
Equinor note ("lane now reduced to the open Aker BP application") would
otherwise read as an implied closure.
Submission date left inconsistent on purpose: the contemporaneous
records say 2026-07-29, the retrospective ones 2026-07-30. Both now
carry a note pointing at the other rather than one being overwritten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JMcHCsTKWvVzqyLChF5ckk
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