0 Fork 0

Files

T

dennisthiessenandClaude Opus 5 f515a1e522 fix(kb): close all six Zeugnis discrepancies on the user's rulings

D1/D2 - Bosch title and promotion: CONFIRMED by the user. The promotion and its
timing are correct and came from a re-grading (Neueinstufung). The Zeugnis does
not contradict it - it names DEPARTMENTS ("Ingenieur" in Fertigungstechnologie
1/2/3) rather than job titles. Separately corrected a false provenance note that
claimed official_title was "the formal combined string on the Zeugnis"; it never
came from that document, it comes from the user and LinkedIn.

D3 - part-time from 2021-09: NOT recorded, by the user's decision. Noted for
completeness that tenure wording such as "over ten years" measures elapsed time
and is unaffected; it would only matter if a document claimed FTE years, and
none does.

D4 - French and Italian: the Swisscom Zwischenzeugnis says he uses both
professionally on a regular basis. The user reviewed the sentence and confirmed
it is an ERROR IN THE DOCUMENT. DE/EN only stands. Recorded in
identity.language_note so nobody rediscovers the line and acts on it, with the
practical warning that a reader of that Zeugnis may take it at face value.

D5 - the RUAG MSSQL rule-out: the DECISION stands (user does not want it
revisited), the REASONING is corrected. Two of its four premises were wrong:
MSSQL is not 0 (Fraunhofer SCEDAS ran on Microsoft SQL Server), and "his stack
is AWS cloud-native" was too narrow - the Swisscom Zeugnis documents component
ownership for ETL into the Teradata DWH. Talend and SAP S/4HANA remain genuinely
0, and the required line reads "Aufbau UND Betrieb" while he has documented
Betrieb only - so the skip is still defensible, it was just better than its
written justification. Both RUAG decision rows now carry the correction and a
standing rule for future DWH postings.

D6 - Vizrt end date: 2018-05 stands by the user's decision.

And the follow-through that matters: the data-warehouse, MSSQL and mentoring
evidence is now IN THE BUNDLES, not only in claims.json. BS-6 showed last week
that evidence which reaches no bundle cannot be selected - this is the same
failure mode, caught the same week. The DWH entry carries its scope limit
explicitly: documented Betrieb, not Aufbau.

Validator PASS, 37/37 tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM

2026-09-11 21:46:05 +02:00

12 KiB

Raw Blame History

Bundle: Data Platform / Infra

Target employers: Cloud-first companies, AWS-heavy orgs Tier: 3 — viable with careful framing Config key: bundle_data_platform.md

S1: Role Profile & Priority Matrix

Positioning: Dennis's platform evidence sits inside data-engineering roles rather than a dedicated Platform/SRE title: Kubernetes delivery at Swisscom and Bosch, scoped AWS migration work with CloudFormation, GitLab CI/CD, Dockerized ML inference and an observability proof of concept. Position as a data engineer with production-platform depth, not as a dedicated SRE, developer-platform or Terraform engineer.

Note on Tier 3: This bundle is viable but slightly less natural than Tier 1/2. The gap is: Dennis doesn't have a dedicated platform engineering title, and his infrastructure work is in service of data pipelines rather than standalone infrastructure. Frame accordingly — emphasize that his platform skills are production-proven, not academic.

Priority Matrix

Priority	Achievement IDs	Rationale
HIGH	SW-3, SW-1, SW-2, BS-1, BS-2, BS-3, BS-4, SW-5	K8s/GitLab, AWS/IaC, pipeline ownership, ML containerization, data services, ELK observability, DevSecOps
MED	SW-4, SW-6, FC-1, FC-3, VZ-2, BS-5	Automation, PySpark, CI/CD initiative, microservices, quality gates
LOW	FC-2, VZ-1, GN-1, GN-2, CA-1	Non-platform signals

2-page resume bullet allocation (typical):

Swisscom: 3–4 bullets (SW-3, SW-1, SW-2, SW-5)
Bosch: 3 bullets (BS-1, BS-2 or BS-3, BS-4)
Fraunhofer: 1 bullet (FC-1 — CI/CD initiative)
Vizrt: 1 bullet (VZ-2 — quality gates in CI/CD)
Generali: 1 bullet (GN-1 or omit)

S2: Summary Guide

Headline pattern:

"Data Platform Engineer | Kubernetes · AWS · Kafka | Cloud-Native Data Infrastructure, IaC & DevSecOps"

Building blocks:

"cloud-native data infrastructure" or "data platform ownership"
"Kubernetes-based containerized pipeline deployment"
"AWS IaC (CloudFormation)" — infrastructure-as-code signal
"AWS migration" — hands-on cloud platform experience
Security Champion is not a default positioning theme; use the 2025/2026 team role only when the JD explicitly requires security exposure
"ELK + Grafana + Prometheus monitoring" — never "delivered/built the observability stack" or "full monitoring suite": claims.json BS-4 is a proof of concept and forbids "built the observability platform" / "enterprise observability platform". Carry the PoC scope into any wording.

Scope warning (corrected 2026-09-04). The S3 row for BS-4 previously read "Designed and delivered observability stack … full monitoring suite for manufacturing infrastructure" and was labelled "Full observability stack implementation" — a delivered-capability claim over a PoC, and the same defect the 2026-08-21 log entry found in bundle_data_engineer.md §S5. That entry said to check the other four bundles; this is the one that had it. See CLAUDE.md → Scope Discipline.

Tone: Infrastructure-minded engineer who thinks about reliability, observability, and security — not just data throughput. Platform thinking embedded in data work.

Avoid:

Leading with analytics or BI framing
Overemphasizing test automation background
Positioning as SRE or pure DevOps (the role was data engineering with platform ownership)

S3: Achievement Reframing Map

ID	Default Framing	This Role's Framing	Key Metric / Signal
SW-3	K8s + GitLab	Lead bullet — "Deployed and operated Python data applications on Kubernetes with GitLab CI/CD; drove infrastructure automation in agile DevOps team"	K8s + CI/CD ownership = core platform signal
SW-1	AWS migration	"Migrated pipelines in his owned domains from legacy Teradata/Oracle processing onto Swisscom's AWS platform (Glue, Athena/Iceberg, Redshift, Airflow, CloudFormation)"	Scoped migration delivery plus AWS breadth
SW-2	Component Owner	"Owned Fulfillment ETL pipelines (Oracle/Kafka → Teradata) — platform reliability, Data Governance compliance, 2nd/3rd-level support and on-call duty"	Platform SLA + on-call = reliability engineer signal
BS-1	ML inference	"Containerized and orchestrated ML inference (Docker, K8s, Ansible) into a continuously operating 24/7 semiconductor production environment"	Production-grade containerization in an environment that cannot be paused. Do not write zero-downtime — canonical BS-1 evidences integration into continuous production, not a measured zero-downtime deployment property
BS-4	ELK PoC	"Built an anomaly-detection proof of concept on ELK + Kafka (Docker) with Grafana, Prometheus and Loki monitoring, validating centralized logging and alerting for 24/7 semiconductor production"	PoC-scoped observability breadth — the PoC framing is mandatory, not optional
SW-5	Security Champion	"2025/2026 team Security Champion; include only if the JD explicitly requires security or DevSecOps exposure"	Secondary team-role evidence, not ownership or certification
BS-6	Linux/Ansible	"Administered and automated Linux servers carrying the ML platform, Docker hosts and backend services at Bosch; wrote Ansible extensions including a credential plugin with local caching"	Infrastructure-as-Code and Linux operations evidence. Added 2026-09-11 (review F07): BS-6 existed in `claims.json` and `experience_bosch.md` since 2026-08-27 but appeared in NO bundle, so the selection paths could not see it. Currency limit: employer-side Linux/Ansible ended Dec 2022; `PP-3` (personal Debian server) carries the current half and must be named as personal. GitOps stays forbidden — execution was push-based from Jenkins/GitLab, not agent-reconciled
BS-2	Data services	"Built multi-language data services (Python/Java/C#) over OracleDB and Hadoop/ImpalaSQL — platform-layer data access for semiconductor analysis teams"	Enterprise DB + Hadoop infrastructure
BS-3	App Owner	"Application Owner for semiconductor analytics platform — SLOs, reliability, vendor management, on-call coverage"	Platform SLA ownership
FC-1	CI/CD initiative	"Independently introduced Jenkins CI/CD pipeline with quality gates at Fraunhofer CML — first build automation adopted by the research team"	Initiative: built CI/CD from zero

S4: Skills Guide

Bold tools (resume Technical Skills section): Kubernetes, Docker, AWS (S3 · Glue · Athena · Redshift · CloudFormation), Kafka, GitLab CI/CD

Must-include skills (ATS match):

Kubernetes, Docker, Ansible
AWS (S3, Glue, Athena, Redshift, CloudFormation, Airflow), Apache Iceberg
GitLab CI/CD, Jenkins
Kafka, Apache Airflow
Python, SQL
ELK Stack, Grafana, Prometheus
IaC / CloudFormation
DevSecOps

Nice-to-have (include if JD mentions):

Terraform (not evidenced — do NOT claim; flag if JD requires)
Loki (log aggregation — from Bosch PoC)
PySpark (distributed processing on platform)
Ansible (Bosch ML orchestration)
Oracle DB, Teradata (enterprise data platform experience)

Omit:

BDD, Selenium, HP Quality Center, UIPath (testing — irrelevant)
Tibco Spotfire, SAP BODS (application tools — irrelevant)
RPA/Camunda (process automation — irrelevant)

Certifications to highlight:

AWS Certified Solutions Architect – Associate → HIGH (platform credibility, architecture knowledge)
Data Engineering with AWS → supporting
iSAQB CPSA Foundation Level → MED (software architecture — relevant for platform design decisions)

S5: Cover Letter Guide

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 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:

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.
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).
Observability initiative — BS-4: Self-initiated ELK + Prometheus + Grafana PoC shows platform engineer mindset (monitoring is not optional).
Operational accountability — use Component/Application Owner evidence. Security Champion is optional and never a substitute for production ownership.

"Why them" angle to research:

What is their cloud stack? If AWS-heavy → your SAA cert + migration experience is directly relevant
Do they use Kubernetes in production? → Cross-employer K8s experience is the signal
Are they building their data platform from scratch vs. maintaining existing? → Tailor SW-1 (migration) vs. BS-4 (observability initiative) accordingly
Terraform vs. CloudFormation? → Note that your experience is CloudFormation; Terraform familiarity may need bridging