dennisthiessenandClaude Opus 5 ec5be5f2ed feat(citadel): Phase 0 for Citadel Securities Platform Engineer, Zurich
Evidence Fit 74/100, Adjacent at the top of the band, hard gate PASS
with one flagged risk. Phase 1 not started - user asked for Phase 0 only.

The stack alignment is the best in the log: zero Gaps across all seven
minimum qualifications, and all five preferred technologies (Kafka,
Kubernetes, Spark, Airflow, distributed databases) are Direct and
production-current.

What holds it at 74 is that the title-defining function splits. R2 -
ingestion, transformation, storage and lifecycle management of large
datasets - is Direct and describes SW-1/SW-7 almost word for word. R1 -
design and build the distributed research platform itself - is Adjacent,
the same authoring-vs-building shape as Aker BP, and it cannot be
written around: Scope Discipline forbids pairing a full-ownership verb
with an org-scale object, so it can only be honestly bridged.

Recorded the classification conflict rather than hiding it.
application_strategy.md says a defining responsibility that is only
Adjacent makes the role Stretch; that strict reading applies to R1. It
is filed as Adjacent because R2 is equally title-defining and is Direct,
and because Aker BP set that precedent at 79. Both cohort slots are free
either way, so the label changes nothing operationally.

Corrections the user was right about, now recorded so a later run does
not repeat them: Go is NOT a gap, because Q3 is disjunctive and Python
satisfies it outright; and a production Kafka/K8s/Spark/Airflow estate
IS a distributed system, so Q4 is Direct rather than a stretch.

Two traps written down explicitly. The $175,000-350,000 base range is a
US pay-transparency disclosure under NY law and says nothing about the
Zurich figure - it must be asked, not assumed. And the sibling reqs that
web search surfaces as closer title matches (Research Platform - Data
Platform Engineer, Research Platform Infrastructure Engineer) are dead:
404 and Cloudflare-blocked, absent from the live board. Those Built In
listings are stale.

JD saved verbatim via Playwright; WebFetch returns 403 on this host.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MHtzyTKBcg6BWhD5qFegtK
2026-08-25 23:24:02 +02:00

Evidence-first resume kit

This repository turns verified career evidence into role-specific LaTeX resumes and, when useful, cover letters. It is designed to prevent a common failure mode of AI-assisted applications: making a document sound closer to the job description by silently overstating skills, scope, titles, or outcomes.

The workflow separates three questions that should never be confused:

  1. Evidence Fit: does the candidate actually meet the role, including hard gates?
  2. Document Quality: does the resume communicate the supported evidence clearly?
  3. Channel Strength: is the application cold, referred, or supported by a warm contact?

A polished resume cannot repair a failed qualification gate. A strong fit can still be hidden by a weak document. The system records both.

Source hierarchy

source documents
    -> structured extractions
    -> canonical claims registry
    -> experience records and role bundles
    -> session plan
    -> generated resume / optional cover letter

resume_builder/canonical/claims.json is the highest-authority career source. Generated files under output/ are never treated as evidence. historical_outputs.json records whether an older package is safe to consult, must be revalidated, or must not be reused.

Default application strategy

  • Target Staff/Senior Data Engineering first.
  • Use ML Platform/MLOps, data platform, analytics, and semiconductor profiles only where direct evidence covers the actual requirements.
  • Treat direct LLM engineering, formal model evaluation, Terraform-heavy SRE, and similar missing required experience as gates rather than keyword opportunities.
  • Build application cohorts with roughly 70% core, 20% adjacent, and 10% deliberate stretch roles.
  • Add a warm-channel action for core applications.

The default document is a two-page International Tech resume for US-tech/FAANG-style roles in Europe. A Swiss/DACH policy overlay is available for employers that expect local conventions. Cover letters are conditional, not automatic.

Workflow

Add evidence

  1. Put employment records, project material, papers, or notes under knowledge_base/.
  2. Run setup-extract to create a source-grounded extraction.
  3. Review it, then run setup-build-kb to update canonical claims, experience files, bundles, and support data.

Apply to a role

  1. Run make-resume with the real JD.
  2. Review the requirement table and fit gate before approving content generation.
  3. Generate and validate the LaTeX resume.
  4. Run make-cl only when the session records a justified YES decision.
  5. Run critique for separate Evidence Fit, Document Quality, and Channel Strength findings.
  6. Run edit-resume for approved repairs.

The skills live in .agents/skills/. Each application receives a session file under output/<Role>/ that preserves the JD, fit decision, claim IDs, content plan, validation results, and application status.

Validation

Validate the knowledge system:

python resume_builder/helpers/validate_resume_system.py

Validate a generated document:

python resume_builder/helpers/validate_resume_system.py --document output/Role/resume.tex

Track the active 7/2/1 cohort:

python resume_builder/helpers/cohort_tracker.py summary

Character counts are available only as readability diagnostics. There are no fixed character bands, equal-length bullet rules, or page-fill quotas.

Output and prerequisites

The system writes .tex source only. Compile locally with a LaTeX distribution such as MiKTeX, TeX Live, or MacTeX. Generated resumes should also be checked through PDF rendering and text extraction before submission.

See DOCS.md for the architecture and policy reference.

License

MIT; see LICENSE.

S
Description
No description provided
Readme MIT
11 MiB
Languages
TeX 76.2%
Python 23.8%