Flockara / discovery & matching
Job Portal.
Relevance needs evidence, not just a score.
What it does
Job Portal searches fresh company job boards, ranks opportunities against a candidate’s resume, and sends selected roles directly into Tailorbird.
Why it matters
A long list of plausible matches is not a useful shortlist. People need filters, context, and a reason to trust the ranking.
What I owned
I defined the matching behavior, privacy boundaries, quality audits, product handoff, and self-hosted deployment.
Conceptual architecture illustration. No production account or client data.
From the idea to the interface
01 / THE PROBLEM
Start with the constraint.
A search result can look relevant while describing the wrong profession, seniority, or mandatory qualification. I wanted job discovery to explain the relationship between a role and the candidate’s actual evidence.
I designed the workflow around scheduled ingestion into SQLite, structured filters, and resume-aware ranking. The matching subsystem separates retrieval from evidence assessment and verdict policy, so a search score does not become an unsupported judgment.
02 / THE ARCHITECTURE
Under the hood.
- 01Scheduled ATS ingestion
- 02Normalized SQLite store + FTS5
- 03Filters + resume evidence
- 04Review shortlist → Tailorbird
A simplified view of the boundaries I designed.
03 / ENGINEERING DECISIONS
The details that matter.
A score is relative
TF-IDF similarity ranks a shortlist; it is not a hiring probability. The evidence engine separately evaluates requirements and can report that clarification is needed.
Separate missing proof from contradiction
A resume that does not demonstrate a skill is different from a resume that explicitly contradicts a hard requirement. The matching rules preserve that distinction.
Cache the inputs, not just the answer
I tied cached assessments to the resume version, posting content, and engine versions. When an input changes, the old verdict should stop being trusted.
Make partial failure operationally normal
The refresh logic originally expected every external board to succeed. I changed the trigger to a completed sync: a few failed boards should not prevent new postings from becoming searchable.
04 / TESTING & DELIVERY
Make the result accountable.
I used synthetic resumes and filter matrices to challenge the ranking: unrelated professions, weak evidence, stale listings, and exclusions. The failures became concrete requirements and regression cases instead of being explained away by a convincing score.
I used Claude Code to accelerate implementation while owning the requirements, architecture, prompt and context design, debugging, acceptance criteria, validation, and release decisions.
05 / OUTCOME & LESSON
Plausible rankings need adversarial examples. Test unrelated professions, ambiguous evidence, exclusions, and stale inputs, not only obvious matches.
A private discovery workflow that takes a candidate from fresh company postings to a focused shortlist, then carries selected roles into Tailorbird.
Open Job Portal ↗Evidence & provenance
Ingestion documentation, source, history, matching tests, synthetic evaluation fixtures, and the public interface reviewed. Shared v2 AI verification is an admin preview. The screenshot shows the public product preview. A signed-in interface reconstruction was prepared offline, but is not shown as a live account.