# Session: Citadel Securities — Platform Engineer, Research Platform Engineering

## JD Integrity

- File/source: `JD_CitadelSecurities_PlatformEngineer.txt` (this folder) — copied from `JDs/JD_CitadelSecurities_PlatformEngineer.txt`
- Source URL: https://www.citadelsecurities.com/careers/details/platform-engineer/
- Retrieval method and date: Playwright headless (chromium) via `job_scout/.venv`, 2026-08-25. **WebFetch returns HTTP 403 on this host** — Cloudflare-protected; do not use WebFetch here.
- Verbatim posting: YES — full visible posting body, unedited except removal of site navigation chrome.
- Posting status: **LIVE as of 2026-08-25.** Verified independently of the detail page: the role appears in the site's Zurich location filter, which returns 10 open Zurich roles. Board total 81 open roles.
- Locations: **New York, Miami, Zurich** (JD body: "in Miami, Zurich or New York")
- Team: Research Platform Engineering
- **Evergreen caveat:** the posting carries standing-req boilerplate — *"Opportunities may be available from time to time in any location in which the business is based for suitable candidates… we will contact you if there is a vacancy available."* Most likely a continuously-open multi-location req. Less deadline pressure; higher chance of landing in a resume pool rather than against a named opening.
- **Sibling reqs are dead — do not chase them.** Web results surfaced "Research Platform – Data Platform Engineer" (a closer title match) and "Research Platform Infrastructure Engineer" via Built In. Checked 2026-08-25: the first returns **HTTP 404**, the second is Cloudflare-blocked and absent from the live board. Those Built In listings are stale. **Platform Engineer is the live req.**

## Application Decision

- Audience profile: **International Tech, English** (config default). US market maker, English working language, ex-Google Zurich office. No Swiss/DACH conventions, no photo.
- Evidence Fit: **71/100** (revised down from 74 on 2026-08-26 — see Working Model below)
- Fit class: **Adjacent (mid-band)**
- Hard gate: **QUALIFICATIONS PASS, but a PRACTICAL CONSTRAINT IS UNRESOLVED** — `critique_framework.md` flags a NO-GO when "location… or mandatory relocation is unresolved." The Zurich working model is unknown and the evidence points to 5-day onsite. **Resolve before Phase 2.**
- Channel Strength: **Weak (cold)** — no named contact on the posting, no known connection. Would be the 5th consecutive cold-channel application.
- Cohort slot: Adjacent would be **2/2** (Aker BP holds 1/2). Note: a strict reading of `application_strategy.md` would class this **Stretch** (0/1 free) — see Gap Assessment.
- Decision: **PENDING USER** — Phase 0 only, per user instruction. Phase 1 not started.

## Requirements

### Minimum qualifications — zero Gaps

| # | JD requirement | Class | Evidence |
|---|---|---|---|
| Q1 | Bachelor's in CS or related field | **Direct** | B.Eng. Information & Telecommunication Technologies + M.Eng. Computer Aided Engineering (Software Design & Engineering), UniBw München |
| Q2 | 3+ years professional software engineering | **Direct** | ~11 years (2015–present) |
| Q3 | Strong programming in Python, **or** Go, **or** C++, or similar systems-oriented languages | **Direct** | Python `production-current`. Disjunctive requirement — Python alone satisfies it. C++ is `production-historical-limited` / `allowed-with-context`; usable as secondary colour only, never headlined |
| Q4 | Building **and operating** distributed systems in production | **Direct** | Kafka, Kubernetes, Spark, Airflow carrying production traffic at Swisscom; Component Owner with data quality, incident handling and on-call (SW-1) |
| Q5 | Designing scalable backend services, APIs, and data-intensive applications | **Adjacent** | Data-intensive applications Direct (BS-2 data services over Oracle/Hadoop; SW-4 Python data apps on K8s). Backend services/APIs partial. **SDKs: no evidence** |
| Q6 | Strong understanding of distributed systems, data-intensive applications, system design fundamentals | **Adjacent** | iSAQB CPSA-F (software architecture) + AWS SA-Associate + production operation. But "distributed systems" as a *design discipline* has no canonical entry — 0 hits in `claims.json` |
| Q7 | Cloud platforms (AWS, GCP, Azure) and modern infrastructure | **Direct** | AWS `production-current`. Disjunctive — AWS alone satisfies. (GCP and Azure are `forbidden` in `claims.json`; never list them) |

### Preferred ("is a plus") — complete hit

| JD | Class | Evidence |
|---|---|---|
| Kafka | **Direct** | `production-current` |
| Kubernetes | **Direct** | `production-current-and-historical` |
| Spark | **Direct** | PySpark `production-current` |
| Airflow | **Direct** | `production-current` |
| Distributed databases | **Direct** | Teradata, Redshift, Athena/Iceberg |

**All five preferred technologies are Direct.** This is the strongest raw stack alignment in the application log.

### Core responsibilities

| # | JD responsibility | Class | Note |
|---|---|---|---|
| R1 | **Design and build distributed platforms and services** supporting quantitative research, simulations, AI-powered applications | **Adjacent** | Title-defining. He builds governed data products and pipelines *on* Swisscom's platform; authoring research-platform infrastructure at firm scale is a genuine stretch. **This is the risk.** |
| R2 | Develop scalable platform services and **data systems for ingestion, transformation, storage and lifecycle management of large datasets** | **Direct** | Also title-defining, and a plain description of SW-1 / SW-7 |
| R3 | Backend services, APIs and **SDKs** for researcher productivity and self-service | **Adjacent** | Data products for downstream self-service is adjacent; SDKs are a Gap |
| R4 | Improve **performance, reliability, scalability** of critical research systems in **high-throughput** environments | **Adjacent** | Query performance tuning (BS-2), SLOs (BS-3), on-call reliability (SW-1). "High-throughput" in the HFT sense is not evidenced |
| R5 | Collaborate with researchers to translate requirements into production-ready systems | **Direct** | SW-8 stakeholder requirements; Bosch delivery to analysis teams |

## ATS Keywords

- **Languages:** Python, C++ (context only), SQL
- **Distributed/infra:** distributed systems, Kubernetes, Kafka, Spark, Airflow, containerization, CI/CD
- **Data:** data platform, ingestion, transformation, storage, lifecycle management, large datasets, data-intensive applications, distributed databases, ETL/ELT, data modelling, query performance
- **Cloud:** AWS, S3, Glue, Athena, Iceberg, Redshift, Lambda, Step Functions, CloudFormation
- **Systems:** scalability, reliability, performance, backend services, APIs, production operation, on-call
- **Domain:** quantitative research, simulations, backtesting, analytics workflows, model development
- **Deliberately absent (no evidence):** Go, SDK authoring, low-latency/HFT, GCP, Azure, Terraform

## Gap Assessment

**Four real gaps, in severity order:**

1. **Platform authoring at firm scale (R1) — the decisive one.** The JD wants someone to *design and build the platform researchers use*. Dennis owns components, pipelines and data products *within* Swisscom's company-wide Data Mesh. `CLAUDE.md` Scope Discipline forbids pairing a full-ownership verb with an org-scale object, so this gap **cannot be written around** — it can only be honestly bridged. Same shape as the Aker BP framework-authorship stretch (which scored 79 and still went out as Adjacent).
2. **No professional quantitative/finance domain.** Now partially mitigated by **PP-1** (self-built momentum/signal platform) and **PP-2** (Udacity AI for Trading nanodegree), added to `claims.json` 2026-08-25. These are genuine self-directed depth — "residual 12-1 momentum, ATR stop/trail, quintile gating" is not JD-scraped vocabulary. But PP-1 is single-user and self-hosted: **never call it distributed, production or multi-user, and never quote a PnL, Sharpe, return or backtest figure.**
3. **SDKs — no evidence at all.** 0 hits in `claims.json`. Appears in R3 only, not in the minimum quals, so it is not a gate.
4. **Low-latency / high-throughput systems.** 0 canonical hits. The only throughput reference is the M.Eng. thesis, which `claims.json` `thesis_limits` explicitly flags as a methods prototype with no operational data — **not usable as high-throughput evidence.**

**Non-gaps — do not score these as gaps:**
- **Go.** Q3 is disjunctive ("Python, Go, **or** C++"). Python satisfies it. The "systems-oriented languages" phrasing is a cultural signal about the room, not a requirement.
- **Distributed systems experience (Q4).** A production Kafka/K8s/Spark/Airflow estate *is* a distributed system. Do not undersell this.

**Hard-gate verdict: PASS, with a flagged risk.** No minimum qualification is a Gap. This is materially cleaner than the AWS FDE NO-GO, where the title-defining capability was a flat Gap that `claims.json` globally forbids claiming. Here the title-defining function **splits**: R2 Direct, R1 Adjacent.

**Classification caveat, stated plainly:** `application_strategy.md` says *"Stretch: below 60 **or a defining responsibility is only Adjacent**."* R1 is a defining responsibility and is Adjacent, so a strict reading classes this **Stretch**, not Adjacent. It is recorded as Adjacent because R2 — equally title-defining — is Direct, and because the Aker BP precedent (identical authoring-vs-building shape) was recorded as Adjacent at 79. **Both cohort slots are free either way**, so the label does not block the decision. Flagging it so the choice is deliberate, not accidental.

## Working Model — UNRESOLVED, decision-blocking (raised by user 2026-08-26)

**The JD is silent.** Grep of the verbatim posting for hybrid / remote / onsite / in-office /
days per week / office returns **zero matches**. Phase 0 scored practical constraints 5/5 by
assuming Zurich was workable; that assumption was unexamined and is now withdrawn.

**Evidence, and its quality:**

| Source | Says | Reliability |
|---|---|---|
| Ken Griffin, on record (Fortune 2023, repeated since) | Brought Citadel back **5 days a week**, early and against the grain; calls it his most important leadership decision; all employees in office full-time; remote work "hinders innovation" and costs early-career development | **High** — founder/CEO, on record, repeated, framed as core culture not policy |
| Fishbowl post, Nov 2022 | "usually 3 days minimum… depends on your manager" | **Low** — anonymous, 4 years stale, Operations not Engineering, contradicted by the CEO |
| Citadel Securities Zurich official policy | Not found | — |

**Consequence if 5-day onsite is correct:** Bern → Zurich is ~1h each way, so ~2–2.5h commuting
per day, five days a week — or relocation to Zurich. That breaks the standing constraint
(`user_comp_bar`: Bern-based, hybrid max 2–3 days) and `user_international_mobility` ("keep a
Swiss home base", no relocation).

**Scoring impact:** Practical constraints **5/5 → 2/5** (language and authorization remain clean:
English working language, EU citizen + Swiss B permit). Evidence Fit **74 → 71**. Still Adjacent,
now mid-band rather than one point below Core.

**This must be ASKED, not researched** — same class of question as the SBB Anforderungsniveau K
band. No amount of further searching produces an authoritative answer for the Zurich office
specifically, and the cost of guessing wrong is a full package plus a process built on a
commute the user has already declined elsewhere.

**Recommended sequence: resolve this BEFORE Phase 2, not after.** The SBB package was submitted
with its equivalent question still open, and that question is now a live screening topic instead
of a settled fact. Repeating that pattern here would be a deliberate choice, not an oversight.

## Company Context

- **Citadel Securities** — technology-driven global market maker (equities, options, fixed income). Distinct from Citadel LLC, the hedge fund. Institutional and retail liquidity provision.
- **Zurich office:** Klausstrasse 4, 8008 Zurich. Founded 2019. **Heavily ex-Google.** Platform research is led by **Costas Bekas**, former IBM distinguished researcher. **Ferenc Tóth joined June 2026** as a software engineer on the platform research team, from seven years as a Google staff engineer. Principal research is headed by **Nicolai Meinshausen**, the ETH statistician (returned August 2025).
- **What the Zurich office actually is:** of 10 open Zurich roles, the large majority are quant researchers, ML researchers and quant interns — mostly PhD-gated. Platform Engineer is one of only ~3 experienced non-quant engineering seats there. It is a research-first office, and platform engineering exists to serve researchers.
- **Role purpose (JD's own words):** systems that "power large-scale simulations, analytics, and model development" and let researchers "transform data into actionable insights and alpha-generating trading strategies." Platform work here is directly revenue-attached, which is unusual and worth understanding before an interview.
- **Why them angle:** research-serving data platform work, at a firm where the platform's quality visibly determines research throughput — a sharper version of what he does at Swisscom, in a domain he already follows privately.

## Framing Strategy

- **Lead narrative:** *A production data-platform engineer who builds and operates the ingestion, transformation and storage systems analytical consumers depend on — and who independently built an end-to-end equity signal platform because the domain genuinely interests him.*
- **Reframing map:**
  - SW-1 / SW-7 → R2 (ingestion/transformation/storage/lifecycle at scale). **Strongest single mapping; lead with it.**
  - SW-4 (Python apps on K8s + GitLab CI/CD) + Kafka/Spark/Airflow → Q4 distributed systems in production.
  - BS-2 (data services over Oracle/Hadoop, query performance tuning) → Q5 data-intensive applications + R4 performance.
  - BS-3 (Application Owner, SLOs, vendor coordination, training) → R4 reliability + R5 collaboration.
  - PP-1 + PP-2 → domain credibility for R1's *"quantitative research, simulations"* and R3's self-service surfaces.
- **Emphasize:** production ownership and on-call (they run revenue systems); the exact Kafka/K8s/Spark/Airflow/AWS stack; self-service data products for downstream consumers; genuine domain interest via PP-1.
- **Downplay:** Data Mesh governance vocabulary (enterprise-flavoured, not their register); Spotfire/BI; ITIL; anything reading as enterprise-IT process.
- **Never claim:** authoring/owning a company-wide platform; distributed-systems *design* at firm scale; SDK authoring; low-latency/HFT experience; professional quant work; any PP-1 performance number.
- **Level note:** JD states "Bachelor's, 3+ years" — he is *above* the stated bar at Staff + Component Owner. Do not down-level the framing to match the JD's floor; the $175k–350k base band is wide enough to span several levels.

## Critique Context

- **Reviewer persona:** a platform engineer or eng manager on Research Platform Engineering — likely ex-Google/ex-big-tech, systems-oriented, in a research-first office. Reads for distributed-systems depth and production instinct, not for enterprise process maturity.
- **Competitive landscape:** brutal. Citadel Securities' engineering bar is among the highest in the market, and the Zurich office is visibly staffed from Google and academia. Realistic competition is ex-FAANG infrastructure engineers and systems specialists. Dennis's differentiator is not raw systems pedigree — it is production data-platform ownership plus real domain interest.
- **Domain vocabulary to get right:** alpha, signal, backtest, simulation, cross-sectional momentum, factor, research throughput, market making. Using these correctly is credibility; using them loosely is worse than not using them.
- **Likely probes:** (1) "Describe a distributed system you designed" — the weakest ground, prepare an honest scoped answer about pipeline architecture rather than claiming platform authorship; (2) "What's your throughput/latency experience?" — genuinely thin, do not bluff; (3) PP-1 — expect real interest and real scrutiny, and expect to be asked about results, which must be answered honestly as "not a validated track record".
- **Compensation caution:** the **$175,000–350,000 base range in the posting is a US pay-transparency disclosure** (NY law) and says nothing about the Zurich figure. Do not plan against it. Citadel Securities Zurich very likely clears the CHF 180k all-in bar, but that is inference, not evidence — ask.

## Cover Letter Decision

- **Decision: YES (recommended), if Phase 1 proceeds.**
- Rationale: this is the rare case where a letter carries information the resume structurally cannot. The resume can list PP-1 only as a compact project line; it cannot convey *why* a Swisscom data engineer credibly wants a research-platform seat at a market maker. The domain-interest story is the single strongest differentiator against an ex-FAANG competitive field, and it needs prose.
- Institution type: US market maker, research-first office. Register: direct, technical, unsentimental. No enterprise formality, no Swiss/DACH conventions.
- Structure: (1) what he builds now, mapped to R2 in their words; (2) production ownership and on-call as the reason he thinks about reliability the way a revenue-system team does; (3) PP-1/PP-2 as honest self-directed domain grounding — explicitly labelled a personal project, no numbers; (4) short close on Zurich, no relocation needed, EU citizen + Swiss B permit.
- Length: 1 page, 4 short paragraphs.
- **Hard constraints:** never imply professional quant experience; never quote a PP-1 result; never claim platform authorship; check `bundle_data_engineer.md` §S5 before reuse — its opening hook contained an SW-1 scope violation (fixed 2026-08-21, but verify).

## Resume Plan (Phase 1 — proposed 2026-08-26, awaiting confirmation)

Bundle: **`bundle_data_platform.md`** primary (Tier 3), `bundle_data_engineer.md` secondary.
Format: 2-page resume, International Tech, English.
Bullet lengths: **natural** per `resume_reference.md` §7 — the SKILL.md "all bullets 2L" line is stale,
superseded by the 2026-07-27 global correction. §7a cadence variety applies.

### Swisscom — Staff Data, Analytics & AI Engineer (5 bullets)

| | ID | Achievement | JD match |
|---|---|---|---|
| * | SW-7 | Governed data products in the company-wide Data Mesh; onboard sources; metadata + lineage in Atlassian Compass | **R2 Direct** — lifecycle mgmt; R3 self-service |
| * | SW-1 | Migrated owned Fulfillment/Product Analysis pipelines onto AWS (Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation) | **R2 Direct**, Q7 cloud |
| * | SW-2 | Component Owner, business-critical Fulfillment ETL (Oracle/Kafka → Teradata): data quality, governance, incidents, on-call | **Q4 Direct**, R4 reliability |
| * | SW-3 | Build and operate Python data applications on Kubernetes with GitLab CI/CD | **Q4 Direct**, Q5 backend services |
| o | SW-4 | Deliver data products and analyses with internal stakeholders; translate requirements | R5 Bridge |

### Bosch Semiconductor Dresden — Senior Engineer, Data Analysis (4 bullets)

| | ID | Achievement | JD match |
|---|---|---|---|
| * | BS-2 | Data services in Python/Java/C# over Oracle and Hadoop/Impala; **query performance tuning**; fab sensor/process data | **Q5 Direct**, R4 performance |
| * | BS-1 | Integrated containerized ML inference (Docker/K8s/Ansible) into a 24/7 fab | **Q4 Direct**, R1 "AI-powered applications" |
| * | BS-4 | ELK/Kafka anomaly-detection PoC with Grafana/Prometheus/Loki monitoring | Kafka Direct, R4 reliability |
| o | BS-3 | Application Owner: SLOs, vendor coordination, training and documentation | R4 + R5 Bridge |

### Vizrt — Test Automation / DevOps Engineer (1 bullet) — **user decision needed**

| | ID | Achievement | JD match |
|---|---|---|---|
| ? | VZ-1 | Contributed **Python and C++** engineering to a **distributed video-transcoding backend** | **Q3 C++ bonus + Q4/Q6 distributed** |
| x | VZ-2 | Automated A/V integration tests as CI/CD quality gates | Weak for this JD |

**VZ-1 is unusually well-matched to this specific JD** — it is the only canonical evidence that pairs
C++ with a genuinely distributed backend, which is exactly Q3's bonus clause plus Q6. **But the user
explicitly skipped the Vizrt low-latency angle on the Snowflake package.** Raising it rather than
assuming. Verb must stay hedged ("contributed"); broadcaster names are `forbidden`.

### Fraunhofer CML — Research Software Engineer (1 bullet)

| | ID | Achievement | JD match |
|---|---|---|---|
| * | FC-3 | Developed containerized microservices for the MISSION **research** data-exchange platform | R1/R3 Bridge — closest canonical analogue to "research platform" |
| o | FC-1 | Jenkins CI/CD setup | Weaker here than FC-3 |

### Generali (0–1 bullets)

| | ID | Achievement | JD match |
|---|---|---|---|
| x | GN-1 | BDD test automation PoC, Jenkins ownership, training | Weak — recommend omit |

### Selected Project — PP-1 (1–2 bullets) — **new section, structural decision needed**

| | ID | Achievement | JD match |
|---|---|---|---|
| * | PP-1 | Self-built equity signal platform: price/fundamental/sentiment ingestion, cross-sectional momentum book, scheduled scan + backtest pipelines, dashboard + alerts | **Domain credibility for R1 "quantitative research, simulations"** |
| o | PP-2 | Udacity *AI for Trading* nanodegree | Certification-context only |

The current 2-page template has **no Projects section**. Adding one is a Phase 2 structural change.
PP-1 is the main differentiator against an ex-FAANG field, so it should appear — but it must be
labelled a personal project, and `claims.json` forbids calling it distributed/production/multi-user
or quoting any PnL, Sharpe, return or backtest figure.

### Budget

| Set | Bullets |
|---|---|
| Recommended (`*`) | **11** |
| With `o` options (SW-4, BS-3, PP-2) | 14 |
| Target (`resume_reference.md` §4) | 11–14 |

**Budget: PASS** at both ends.

### Forced exclusions (provenance)

- **SW-5 Security Champion** — omit by default; JD has no security requirement.
- **SW-8 LLM work** — configuration-level only; `forbidden` to imply built/deployed LLM systems. LLM
  sentiment in PP-1 is fine as personal-project scope.
- **GCP / Azure / Terraform / TypeScript / FastAPI** — `forbidden` in `claims.json`; never list even
  though the JD names GCP and Azure (Q7 is disjunctive; AWS satisfies it).
- **M.Eng. thesis throughput figure** — barred by `thesis_limits`; not usable as high-throughput evidence.

## Output Files

- `e2e_citadel_securities_platform_engineer_resume.tex` / `.pdf` — 2 pages, 13 bullets
- `e2e_citadel_securities_platform_engineer_cover_letter.tex` / `.pdf` — 1 page, 270 words, 3 paragraphs
- `resume.cls` (copied from templates)
- `JD_CitadelSecurities_PlatformEngineer.txt` — verbatim posting

**Phase 2 decisions taken (user said "lets build the resume" without answering the two open items):**
- **VZ-1 included.** Only canonical evidence pairing C++ with a distributed backend; this JD names
  both explicitly. Hedged verb "Contributed" per `claims.json`; no broadcaster names. Reversible.
- **Personal Project section added** for PP-1, labelled three ways (heading, right-aligned
  "Personal project", and "not a production or multi-user service" in the body). No performance
  figure of any kind. PP-2 appears as "Supporting coursework", never as a credential.
- **Generali kept** with one bullet, against the Phase 1 "omit" recommendation — omitting it left an
  unexplained May 2015–Jun 2017 employment gap, which costs more than the weak bullet does.

**Verification:**
- `validate_resume_system.py --document` → **PASS**, 1 warning (cadence, see below)
- Compiled with MiKTeX pdflatex, **exactly 2 pages**, rendered PDF inspected: no clipping, orphans,
  header wrapping or bad breaks; umlauts, `C\#` and `C++` all render correctly
- Page 2 fills well; page 1 has bottom whitespace from the deliberate `\newpage`. Not padded —
  `resume_reference.md` §9: "Do not add content merely to reduce bottom whitespace."

**Known residual — cadence 7/12 (58%), above the §7a ~50% guide.** Reduced from 75% by reshaping two
bullets. The remaining flags are almost all legitimate technology enumerations ("Oracle, Kafka,
Python and Teradata"; "Elasticsearch, Logstash, Kibana and Kafka"). **The §7a checker cannot
distinguish a rhetorical rule-of-three from a list of tools actually used** — a real limitation of
the pattern. Cutting these would mean deleting accurate, ATS-relevant technology names, which §7a
itself forbids ("never trade accuracy… to fix cadence"). Left as-is deliberately.

**Trap hit and fixed during generation:** the first draft named the non-canonical tools in a header
comment explaining why they were excluded. The validator scans **raw file text**, so it errored on
all three. This is the exact failure the SBB `.tex` header warns about. Comment rewritten without
naming them.

## Edit History

### Edit 1 (2026-08-26): Tier 1 relevance fixes

- **Source:** `critique_citadel_securities_platform_engineer.md` Tier 1 items 1-3. User approved
  "tier 1 fixes" only; the Tier 2 headline retitle was deliberately NOT applied.
- **Changes (all MODIFY, no budget change):**
  1. SW-7 bullet -> now carries **ingestion** and **lifecycle**: "from source-system ingestion
     through to the metadata and lineage in Atlassian Compass that keep each product discoverable
     across its lifecycle."
  2. SW-1 bullet -> now carries **transformation** and **storage**: "transformation and storage on
     Glue, Athena with Apache Iceberg and Redshift, orchestration in Airflow". Scope hedge
     ("contributing to the wider company migration programme") retained.
  3. SW-2 bullet -> names the estate a **distributed system** he operates, not designed.
  4. Skills line 2 relabelled **"Distributed systems"** and now names **distributed databases
     (Teradata, Redshift, Athena/Iceberg)** - closes the fifth preferred-technology hit that Phase 0
     claimed as Direct but the document never wrote.
- **Not added, deliberately:** scalable (unverified scale claim), SDK / high-throughput /
  data-intensive / simulation / model development / self-service (zero canonical evidence).
  Verified still absent after the edit.
- **Verification:** validator **PASS, 0 warnings** (the cadence warning cleared as a side effect -
  restructuring SW-1/SW-2 with em-dashes broke the comma-list pattern). Compiles to exactly
  **2 pages**, zero overfull/underfull boxes, PDF re-inspected clean.

| Metric | Before | After | Delta |
|---|---|---|---|
| Pages | 2 | 2 | 0 |
| Validator errors | 0 | 0 | 0 |
| Validator warnings | 1 (cadence 58%) | **0** | -1 |
| Bullets | 13 | 13 | 0 |
| JD term coverage | 19/37 (51%) | **25/37 (68%)** | +6 |

**Estimated Document Quality ~91/100** (relevance 10 -> ~14, mechanics 9 -> 10). Estimate only -
not a re-scored critique.

## Status

- Phase 0: **DONE** (2026-08-25)
- Phase 1: **DONE** (2026-08-26) — 13 bullets confirmed
- Phase 2: **DONE** (2026-08-26) — resume compiled and verified
- Cover Letter: **DONE** (2026-08-26) — 1 page, 270 words, 3 paragraphs, validator PASS.
  No external hooks by design (`cl_reference.md`: omit an unnecessary hook); the only hook is the
  JD's own first-party language. States the R1 gap plainly rather than hiding it. PP-1 labelled
  personal with an explicit "I make no claims for its results".
- Critique: **STALE by design** — scored 86/100 on the pre-Edit-1 resume and before the cover
  letter existed. User elected to submit as-is rather than re-critique (2026-08-26). Estimated
  post-edit Document Quality ~91; not re-scored, and that estimate must not be quoted as a score. — **Document Quality 86/100**, Evidence Fit 71, Channel Weak.
  No Tier 1 truth findings; validator PASS. Three Tier 1 relevance fixes (~+4), all honestly
  available: (1) R2's own vocabulary — ingestion/transformation/storage/lifecycle — is absent
  despite R2 being the single Direct core responsibility; (2) "distributed systems" never appears
  as a phrase though Q4 is a required qual scored Direct; (3) "distributed databases" claimed as a
  Direct preferred hit but never written. File: `critique_citadel_securities_platform_engineer.md`
- **STILL BLOCKED on the working-model question** — resume built at user direction with that
  question open. If Zurich is 5-day onsite, this package does not get submitted.
## Finalization (2026-08-26)

Per `shared_ops.md` → Finalization:

1. ✅ Session, resume `.tex`/`.pdf`, critique all present
2. ✅ Cover letter `.tex`/`.pdf` present (session decision YES)
3. ✅ Canonical validator re-run on **both** submitted documents → **PASS, 0 warnings each**
4. ✅ Final PDFs copied to `Dennis_Thiessen_Resume.pdf` and `Dennis_Thiessen_Cover_Letter.pdf`
5. ⏸ **Submission date NOT yet recorded** — user directed "apply as is" but has not confirmed the
   application was actually sent. Do not stamp a date that has not happened.
6. ⏸ **Cohort entry NOT yet added** — same reason. Would be Adjacent 2/2.

**On confirmation of submission, run both:**

```
./job_scout/.venv/Scripts/python.exe resume_builder/helpers/cohort_tracker.py add   --company "Citadel Securities" --role "Platform Engineer, Research Platform Engineering (Zurich)"   --date <YYYY-MM-DD> --fit-class adjacent --evidence-fit 71 --channel weak   --hard-gate pass --outcome applied

./job_scout/.venv/Scripts/python.exe job_scout/scout.py --decide   "https://www.citadelsecurities.com/careers/details/platform-engineer/" applied "<note>"
```

**Carry-forward risk — unchanged by submission.** The Zurich working model is still unknown and the
evidence points to 5-day onsite. **Ask it in the first recruiter contact.** If it is 5 days, this is
a decline on the Bern constraint regardless of how the process goes.

- Next: ask the working-model question at first contact; record submission when sent
- Resume: PENDING
- Cover Letter: PENDING (decision YES)
- Critique: PENDING
- Next: user decision on whether to proceed
