Modern data engineering case study · 2026
Jobly is a stateful data pipeline and decision system built to answer a narrower question than “what matches these keywords?” It detects what changed, removes predictable noise, separates hard eligibility from career fit, and explains why a small number of roles deserve attention. Automation prepares the decision; the user decides whether and how to apply.
System
Stateful modern data pipeline
Logic
Deterministic gates · evidence-led scoring
Stack
Python · JavaScript · Neon Postgres · Vercel
Operations
Scheduled runs · checkpoints · run manifests
Public data
Fictional fixtures behind a source adapter
Demo run complete
Jobly
12
input
5
gated
5
review
Prioritised review queue
Changed evidence is re-evaluated; unchanged decisions retain state.
Beacon Cloud
London · Hybrid · £135k-£155k · added 1 day ago
9.0
overall
Professional Services and practice leadership. Target seniority and decision scope.
Published compensation clears the configured floor; validate the balance of delivery and commercial ownership.
Solace Commerce
London · Hybrid · salary not shown · added 3 days ago
7.7
overall
Enterprise and solution architecture with a material data and AI remit.
Compensation is not published and needs early confirmation.
AI Strategy Senior Manager · Meridian Advisory
Published salary range is below the configured floor.
3,483
listing histories retained in the private deployment
503
records normalised in one audited refresh
180
new or changed records evaluated in that run
2
roles entered the priority queue in that run
01 · The problem
Saved searches made discovery easy, but deciding which vacancies deserved attention remained repetitive manual work.
Titles are inconsistent. Salary and working pattern are frequently missing. Reposts look new, stale listings remain visible, and a keyword hit says nothing about whether mandatory credentials, functional depth or seniority make the role plausible.
The difficult part is state. A useful system must remember the vacancy already reviewed, recognise a material change, preserve a rejection, and avoid claiming that an unseen listing has disappeared when retrieval was incomplete. Without that history, every alert recreates the same work.
The product question
Can a recurring job-intelligence system turn a noisy stream into a fresh, explainable and prioritised application queue without automating away human judgement?
02 · Product proof
The product compresses a long advert into the substance of the role, the transferable evidence, the decisive gap and the next action.
Demo run complete
Jobly
12
input
5
gated
5
review
Prioritised review queue
Changed evidence is re-evaluated; unchanged decisions retain state.
Beacon Cloud
London · Hybrid · £135k-£155k · added 1 day ago
9.0
overall
Professional Services and practice leadership. Target seniority and decision scope.
Published compensation clears the configured floor; validate the balance of delivery and commercial ownership.
Solace Commerce
London · Hybrid · salary not shown · added 3 days ago
7.7
overall
Enterprise and solution architecture with a material data and AI remit.
Compensation is not published and needs early confirmation.
AI Strategy Senior Manager · Meridian Advisory
Published salary range is below the configured floor.
Sanitised product surface, not a conceptual mock-up
The records are fictional; the states, score dimensions, hard-gate reasons and interaction hierarchy mirror the implemented decision surface.
03 · System design
The architecture separates deterministic eligibility checks, evidence-led interpretation and the final human decision.
Adapt
Read a permitted feed or fixture behind one source boundary
→Validate
Reject incomplete runs before they can change production
→Normalise
Map each record into the canonical job schema
→Deduplicate
Merge conservative title, employer and location identities
→Enrich
Derive role family, substance, freshness and evidence
→Gate
Apply employment, geography, salary and scope constraints
→Rank
Score fit, upside, compensation confidence and interview risk
→Review
Present reasons, caveats and the next human action
→Track
Carry decisions and content hashes into the next refresh
Source-adapter boundary
class JobSource(Protocol):
def fetch(self) -> Iterable[Mapping[str, object]]: ...A permitted feed, public ATS adapter or fixture implements one narrow contract. The publication-safe build ships only the fixture adapter.
Gate before ranking
rejection = hard_gate(job, profile, now)
if rejection:
rejected.append({"reason": rejection})
else:
ranked.append(score_job(job, profile))Employment, geography, freshness and compensation constraints remain deterministic. Ranking only sees records that survive them.
01
Canonical record
Identity, location, work model, salary, posted date, status, provenance and content hash.
02
Decision state
New, updated, unchanged, not checked, saved, rejected, applied and last-shown hash.
03
Operational state
Run ID, stage, checkpoint, coverage, artifact hash, failure reason and deployment result.
04 · Business rules and agentic decisions
A single match score would hide the decision. Jobly keeps gates, component scores and uncertainty separate.
Hard gates
Permanent full-time, configured geography, active status, freshness, salary floor and minimum seniority.
Role interpretation
Title-led role family, responsibilities, mandatory versus desirable requirements and missing evidence.
Priority model
Fit 30% · career upside 23% · compensation confidence 18% · interview probability 17% · company scale 12%.
History
A rejection remains effective at the same content hash; a material change can return the role for review.
Worked comparison · synthetic data
8.9
fit
8.6
career upside
9.5
comp confidence
7.1
interview probability
Apply · Beacon Cloud
Direct Professional Services leadership evidence, EMEA scope and disclosed compensation clear every gate.
Do not queue · Meridian Advisory
The AI strategy title is attractive, but the published range ends below the configured salary floor. A strong keyword match cannot override a hard constraint.
05 · Daily refresh loop
Each refresh leaves a manifest, stage events, coverage evidence, hashes and a recoverable checkpoint.
Audited run · 12 Oct 2026
READYCheckpoint recovered
244 summaries · 60 detailed records preserved
Coverage validated
33 / 33 planned lanes complete
Master rebuilt
150 new · 30 updated · 313 unchanged
Decision surface
180 evaluated · 2 prioritised
Deployment verified
Previous production retained until READY
A scheduler starts the run, but later stages do not assume retrieval succeeded. The ingest is inspected, expected coverage is checked, identity is protected against partial cards, and the master only changes after those validations pass. Records not seen in a capped or incomplete run become not checked, not removed.
The same content hash controls repeated recommendations. An unchanged role already shown is suppressed; a changed description is reconsidered. Decisions stored across devices are imported before ranking and remain joined to reposts through alternate IDs.
The operational limitation matters
The local browser dependency was the least reliable stage. Durable recovery prevented corruption, but the run history does not support claiming unattended production reliability. Governed feeds are the next architectural step.
06 · Evaluation
The public evaluation verifies behaviour and reproducibility across twelve fictional vacancies. Real-world recommendation accuracy requires a larger labelled dataset.
Golden outcomes passed
12/12
8 / 8
demo tests
The fixture checks permanent and location gates, salary rejection, repost collapse, role-family scoring, an adjacent engineering role, missing compensation and output stability.
What it proves
The public pipeline reproduces its expected decisions, explanations and output hash on a controlled edge-case set.
What it does not prove
It is not top-k precision on live vacancies, evidence of employability or a statistically powered user study.
Reproduce it
07 · Responsible automation
The system limits automation at the points where personal judgement, source governance or sensitive data matter.
Jobly may retrieve, normalise, filter and prioritise. It does not submit applications or decide a person’s employability.
The published demonstration begins at a source-adapter boundary and uses fictional fixtures. Private connectors, copied vacancy text and account data are excluded.
Missing salary, incomplete descriptions and partial coverage are surfaced as uncertainty. They are never silently converted into confident scores.
Coverage checks, content hashes and durable checkpoints protect the last valid dataset. A failed run preserves the previous production surface.
Automation may
Automation must not
The user owns
08 · Next validation
The next validation is whether the first screen reliably contains the roles a person would choose to investigate.
The design lesson
Jobly made the repeated decisions in a job search observable, consistent and easier to review, while leaving each application decision with the user.
After operating Proply, Flightly and Jobly, I had three products with recurring data refreshes, autonomous decisions, business rules, retries and quality checks, but no shared control plane. That operational pattern became the starting point for the next project.
Discuss the system
The publication-safe demo is downloadable above. The private production connector and personal data remain deliberately excluded.