feat(citadel): cover letter, and fix SW-1 scope traps in two more bundles

Cover letter: 1 page, 270 words, 3 paragraphs, validator PASS. Carries the one thing the resume structurally cannot - why a Swisscom data engineer credibly wants a research-platform seat at a market maker, which against an ex-FAANG field is the main differentiator. Deliberately uses no external hooks. cl_reference.md says to omit an unnecessary hook rather than spend words proving company familiarity, so the only hook is the JD's own language, scraped verbatim and first-party. No named executives: nothing to verify, and nothing that reads as name-dropping. The letter also states the R1 gap plainly rather than hiding it, because a technical reviewer will find it in the first question anyway and owning it is stronger than being caught by it. PP-1 appears with its personal-project label and an explicit "I make no claims for its results". Separately, loading the bundles for this letter surfaced two live scope traps. The 2026-08-21 correction that fixed the SW-1 violation in bundle_data_engineer.md ended with "check the other four bundles for the same pattern". That sweep was never done, and two of them carried it: bundle_data_platform.md - the S5 cover-letter hook read "migrating Swisscom's legacy ETL stack to a cloud-native AWS platform", and its narrative thread said "migrating an entire ETL infrastructure". Both pair a full-ownership framing with a company-scale object, which claims.json SW-1 forbids outright. bundle_ml_ai_engineer.md - the SW-1 reframing row read "Built cloud-native data infrastructure on AWS ... the scalable data layer", which is both a full-ownership verb on an org-scale object and an unverified scale claim. Both rewritten to the scoped form with inline scope warnings, matching the data_engineer fix. bundle_analytics_engineer.md and bundle_semiconductor.md were checked and are clean. These were loaded traps: any future cover letter built from either bundle would have started from a sentence claims.json forbids. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MHtzyTKBcg6BWhD5qFegtK
2026-08-26 09:31:39 +02:00
parent c94edbce44
commit f8b4cd3473
3 changed files with 67 additions and 3 deletions
@@ -0,0 +1,57 @@
+% Citadel Securities — Platform Engineer, Research Platform Engineering (Zurich)
+% Cover Letter Decision: YES — domain transition needs explaining; the resume can carry PP-1
+% only as a compact block and cannot show why a Swisscom data engineer wants this seat.
+% Industry format per cl_reference.md: 3 short paragraphs, 200--300 words.
+% Hooks: JD text only (first-party, scraped verbatim). No named executives — cl_reference.md
+% says omit an unnecessary hook rather than spend words proving company familiarity.
+% Every claim traceable to the resume. PP-1: no performance figure, labelled personal.
+
+\documentclass[11pt,a4paper]{article}
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage{lmodern}
+\usepackage[a4paper,left=0.85in,right=0.85in,top=0.7in,bottom=0.7in]{geometry}
+\usepackage{parskip}
+\usepackage{xcolor}
+\usepackage{hyperref}
+\hypersetup{hidelinks}
+\pagestyle{empty}
+\setlength{\parindent}{0pt}
+
+\begin{document}
+
+{\Large\bfseries Dennis Thiessen, M.Eng.}\par
+Bern, Switzerland $\vert$
+\href{mailto:dennis@thiessen.io}{dennis@thiessen.io} $\vert$ +41 795 955 585 $\vert$
+\href{https://linkedin.com/in/dennis-thiessen}{LinkedIn}
+
+\vspace{1.5em}
+Research Platform Engineering\\
+Citadel Securities\\
+Zurich, Switzerland
+
+\vspace{1em}
+26 August 2026
+
+\vspace{1em}
+\textbf{Application for Platform Engineer, Research Platform Engineering}
+
+\vspace{0.8em}
+Dear Hiring Team,
+
+The posting describes data systems for ingestion, transformation, storage and lifecycle management of large datasets, built so that researchers can work without fighting their infrastructure. That is my day job. At Swisscom I am Component Owner for business-critical Fulfillment ETL -- a distributed system across Oracle, Kafka, Python and Teradata -- and I build the governed data products that analytics and AI teams consume. I carry the data quality and the on-call pager for that estate, which is a different relationship to a system than having built it and moved on.
+
+What draws me to research platform work specifically is that I already build this kind of system for myself. Outside work I built a self-hosted equity signal platform: it ingests daily prices, fundamentals and sentiment, runs a long-only cross-sectional momentum book through scheduled scan and backtest pipelines, and surfaces the gated setups to a dashboard. It is a personal system, not a production service, and I make no claims for its results. But it is the reason I understand what a researcher actually needs from a platform -- fast iteration, reproducible runs, and trust that the data underneath is right -- rather than knowing it only as a requirements document.
+
+I should be straightforward about the shape of my experience: I have built and operated data products and pipelines on a platform, not authored a research platform at firm scale. That step is the reason the role interests me, and the operational judgement I would bring to it is real. I am based in Bern, hold EU citizenship and a Swiss B permit, and need no sponsorship.
+
+\vspace{0.8em}
+I would welcome the chance to talk.
+
+\vspace{1em}
+Kind regards,
+
+\vspace{1.5em}
+Dennis Thiessen
+
+\end{document}
@@ -106,11 +106,18 @@ Kubernetes, Docker, AWS (S3 · Glue · Athena · Redshift · CloudFormation), Ka
 **Institution type:** Cloud-first tech company, scale-up with AWS-heavy stack, enterprise platform team, or data infrastructure consultancy

 **Opening hook pattern:**
-> "Across my career at Swisscom and Bosch, I've owned data infrastructure at two ends of the spectrum: migrating Swisscom's legacy ETL stack to a cloud-native AWS platform (CloudFormation, Glue, Athena with Iceberg, Airflow) while operating Kubernetes-deployed Python applications with GitLab CI/CD — and containerizing ML inference into a 24/7 semiconductor production line at Bosch using Docker, Kubernetes, and Ansible. In both cases, the infrastructure had to be production-grade with no tolerance for downtime. [Tie to their platform challenge]."
+> "Across my career at Swisscom and Bosch, I've owned data infrastructure at two ends of the spectrum: migrating my own domains' pipelines onto Swisscom's AWS platform (CloudFormation, Glue, Athena with Iceberg, Airflow) as part of its wider cloud programme, while operating Kubernetes-deployed Python applications with GitLab CI/CD — and containerizing ML inference into a 24/7 semiconductor production line at Bosch using Docker, Kubernetes, and Ansible. In both cases, the infrastructure had to be production-grade with no tolerance for downtime. [Tie to their platform challenge]."
+
+> **Scope warning (corrected 2026-08-26).** This hook previously read "*migrating Swisscom's legacy
+> ETL stack to a cloud-native AWS platform*" — a full-ownership framing on a company-scale object,
+> contradicting `claims.json` SW-1 (`forbidden`: "migrated the company warehouse", "led the migration
+> of the legacy warehouse"). Same defect fixed in `bundle_data_engineer.md` on 2026-08-21; this
+> bundle was missed by that sweep. Never pair a full-ownership verb with a company-scale object.
+> See CLAUDE.md → Scope Discipline.

 **Key narrative thread:**
 1. **Production Kubernetes** — SW-3 + BS-1: K8s at two employers, in different contexts (data apps at Swisscom, ML inference at Bosch). Cross-employer K8s ownership is a strong signal.
-2. **Full AWS platform stack** — SW-1: Not just using one AWS service — migrating an entire ETL infrastructure to AWS with CloudFormation/IaC shows platform-level thinking.
+2. **AWS platform breadth** — SW-1: not just one AWS service — migrating his own domains' pipelines with CloudFormation/IaC, inside the wider company programme, shows platform-level thinking. **Never write "an entire ETL infrastructure" or any company-scale object here** (corrected 2026-08-26).
 3. **Observability initiative** — BS-4: Self-initiated ELK + Prometheus + Grafana PoC shows platform engineer mindset (monitoring is not optional).
 4. **Operational accountability** — use Component/Application Owner evidence. Security Champion is optional and never a substitute for production ownership.

@@ -59,7 +59,7 @@
 |----|----------------|--------------------|--------------------|
 | BS-1 | ML inference containerization | **LEAD bullet** — "Designed and deployed ML inference pipeline (Docker, K8s, Ansible) into 24/7 semiconductor fab; automated image-based defect classification" | Production ML in constrained 24/7 environment |
 | SW-3 | K8s + GitLab CI/CD | "Deployed and operated ML-ready Python applications on Kubernetes with GitLab CI/CD automation — production-grade containerized delivery" | K8s ownership = MLOps infrastructure |
-| SW-1 | AWS migration | "Built cloud-native data infrastructure on AWS (S3, Glue, Athena/Iceberg, Redshift, Airflow) — the scalable data layer that ML models depend on" | AWS data lake for ML workloads |
+| SW-1 | AWS migration | "Migrated his domains' pipelines onto Swisscom's AWS platform (S3, Glue, Athena/Iceberg, Redshift, Airflow) — the data layer ML workloads depend on" — **corrected 2026-08-26**, previously read "Built cloud-native data infrastructure… the scalable data layer", pairing a full-ownership verb with an org-scale object (SW-1 `forbidden`) and asserting unverified scale | AWS data lake for ML workloads |
 | SW-2 | Component Owner | "Owned business-critical ETL pipelines (Oracle/Kafka → Teradata) — reliable data supply for downstream ML and analytics" | Data reliability for ML input |
 | FC-2 | ARTUS NLP | "Contributed ML and speech recognition components to ARTUS — Fraunhofer research project targeting automatic sea rescue transcription" | Applied NLP in safety-critical domain |
 | BS-4 | ELK PoC | "Delivered anomaly detection PoC: ELK + Kafka pipeline with Grafana/Prometheus monitoring — ML-adjacent signal processing" | Anomaly detection / observability |