← Selected systems

Case study 01 · Sanitized private system

Job Search Command Center

A privately operated system that turns inconsistent ATS feeds into a normalized, cost-aware application workflow with explainable recommendations.

Ownership

System design, adapters, data model, evaluation contracts, dashboard, deployment, and operations

PythonSQLiteATS APIsLLM evaluationFastAPITelegram

The problem

What needed to change

Job leads arrived from different applicant-tracking systems with inconsistent fields and duplicated lifecycle work. Generic keyword matching obscured seniority, location, compensation, and application-plausibility risks. Model calls also needed explicit cost controls.

I designed and built the ingestion adapters, normalized data model, evaluation contracts, application-state workflow, operational dashboard, scheduled pipeline, Telegram digest, private deployment, and test coverage.

System map

One request, traced end to end.

  1. 01ATS sourcesAshby · Greenhouse · Lever
  2. 02Adaptersretrieve · normalize · deduplicate
  3. 03SQLiteraw jobs · evaluations · lifecycle
  4. 04Evaluatorschema · scoring · cost telemetry
  5. 05Interfacesdashboard · Telegram digest
3ATS adapters
89 + 2tests and subtests
1durable source of truth

Key decisions

Designed for trust and operability.

01

Keep source quirks at the edge

Each ATS owns its retrieval and normalization logic. Downstream evaluation consumes one source-agnostic contract instead of accumulating vendor conditionals.

02

Put deterministic state around model output

Deduplication, eligibility, lifecycle transitions, and cost gates remain deterministic. LLM output is schema-validated and stored with model, latency, token, prompt-version, and cost telemetry.

03

Treat cost as a product constraint

Already-evaluated, applied, closed, incomplete, or implausible records are filtered before model use. The dashboard cannot trigger paid evaluation.

04

Design an operational surface, not a demo

The dashboard exposes recommendations, run health, service state, and application lifecycle while keeping ingestion and scheduler controls outside the UI.

Tradeoffs

What this design optimizes—and what it does not.

  • SQLite favors operational simplicity over horizontal scale.
  • A private network and shared token fit a single-user threat model; this is not multi-tenant authentication.
  • Explicit workflow boundaries add code but reduce accidental spend and state corruption.

Verification

Private does not mean unverifiable.

  • 89 tests plus 2 subtests pass in the private repository.
  • Three independently implemented ATS integrations use a common normalized contract.
  • Evaluation output is schema-constrained and recorded with per-run telemetry.
  • The private service is monitored through health and administration views.

Interview walkthrough

Ask me to trace the system live.

I can provide a guided, sanitized walkthrough of the workflow, representative code, architecture, automated tests, failure modes, and the changes required at larger scale.