The product problem was never “search”
Hirivo started from a frustration with modern job search. Candidates spend significant time searching through hundreds of listings, while most platforms still behave more like search engines than recommendation systems. The interface may look modern. The underlying model is still: type a query, skim results, guess fit, repeat.
The opening question was more ambitious than better filters:
Can a system continuously discover jobs and surface only the opportunities that are genuinely relevant to a candidate?
That question sounds like an AI pitch. In practice, it forced a more boring and more important commitment: prove an end-to-end pipeline before chasing a perfect recommendation model. The first goal was not brilliance. It was a loop we could run, inspect, and improve.
- ingest jobs
- store them reliably
- create a candidate profile
- retrieve potentially relevant jobs
- rank those jobs
- measure whether the recommendations are actually useful
Without that loop, every sophisticated retrieval idea would have been an untestable opinion. With it, Hirivo could learn from reality instead of from demos.
First approach: Greenhouse, Postgres, and a transparent baseline
Greenhouse was the first job source. Jobs were ingested and stored in Postgres, which remained the system of record for companies, sources, jobs, candidates, and later match results. That choice was deliberate. Job matching produces entities and relationships that want constraints, joins, and durable identity. Document flexibility can live at the edges. The core record should not.
The first recommendation system was intentionally simple:
- skills: 50%
- title: 30%
- location: 20%
Matching was primarily substring-based. That is not a sophisticated recommendation system. It was a baseline that could be tested before introducing BM25, embeddings, hybrid retrieval, or graph-like relationships.
The value of a simple baseline is easy to underestimate. A weighted substring approach is easy to reason about, easy to debug, and easy to beat. If a later system cannot outperform it on labeled candidate-job pairs, the later system is not progress. It is complexity wearing a better vocabulary.
The flaw that changed the architecture
The first version exposed a key failure mode:
A job can look relevant while still being unusable for the candidate.
Examples include sponsorship requirements, employment type, geography, relocation expectations, salary constraints, seniority floors, and required skills. Soft similarity can still give those jobs a confident-looking score. The product then surfaces “almost” matches that should never have entered the feed.
That observation forced a design split that still governs Hirivo:
- Eligibility — hard constraints that determine whether a job should be considered at all.
- Fit — a ranking problem applied only after eligibility is satisfied.
Once those concerns were separated, debugging changed. A skip caused by a missing required skill stopped looking like slightly worse neighborhood recall. A location miss stopped hiding inside the same number as a title paraphrase. Soft similarity was no longer allowed to paper over a hard constraint.
This was one of the most important product decisions in Hirivo, because it redefined what “AI-native” meant. AI-native did not mean “embed everything and sort by cosine.” It meant building a recommendation system whose failure modes could be named, enforced, and measured.
From one ATS feed to source discovery
Greenhouse was enough to prove ingestion. Workday made it clear that ingestion alone was not the product boundary. A valid Workday source may require host, tenant, and career site. Discovery therefore became part of the architecture.
The source pipeline evolved toward:
discovery → validate → promote → sync
Supporting concepts included companies, source candidates, and job sources. Other providers considered or planned included Zoho Recruit, iCIMS, and Phenom. At that point the problem was no longer “pull jobs from an API.” It became source discovery, identity, validation, normalization, and synchronization.
This is where Hirivo’s connector work started to look like infrastructure rather than a one-off integration. Each external system can disagree about authentication, discovery, pagination, schemas, identifiers, validation rules, rate limits, and failure modes. The underlying question became:
How do we make external integrations consistent without pretending that every provider behaves the same way?
A generic lifecycle began to emerge from the real work: discover → validate → configure → sync → normalize → monitor. Potential common capabilities included provider interfaces, credentials, sync state, retries, rate limits, checkpoints, source identity, normalization, and observability. The concept remained driven by real integrations rather than by a speculative platform program — but the pattern was already visible.
Bad ingestion creates ranking theater. The recommendation system can look sophisticated while ranking incomplete, stale, or inconsistently normalized jobs. Source quality is recommendation quality upstream.
Retrieval evolution: find a plausible set, then decide
With more jobs in the system, retrieval strategy became the next bottleneck. Hirivo explored title retrieval, preferred location, BM25, vector search, hybrid retrieval, KNN, graph retrieval, and structured filters.
Different retrieval modes fail differently. Lexical retrieval and BM25 are strong for titles, exact skills, and sparse keyword intent. Vector search helps when vocabulary drifts — neighboring roles, paraphrases, alias-heavy skill language. KNN and hybrid approaches help compose those strengths. Graph-like relationships and metadata filters help when neighborhood similarity is not enough and structure matters.
The architectural conclusion was:
Retrieval and ranking should be separate systems.
Retrieval should optimize recall: find a broad but plausible candidate set. Rules and eligibility should eliminate invalid candidates. Ranking should select the best remaining options. Explanation should make the decision inspectable. Collapsing all of that into one embedding score is how demos survive and products drift.
The working pipeline became:
retrieve → filter → rank → explain
The technical case for why vector similarity alone cannot carry that pipeline is covered separately in Why Vector Search Alone Wasn't Enough for Job Matching.
Matching v2: from a score to an explanation
The next ranking design moved toward a more structured fit model. It introduced required skills, preferred skills, skill aliases, title normalization, seniority, domain relevance, confidence, scoring caps, eligibility gates, immutable match snapshots, and match run identifiers.
The objective changed with the model. Hirivo was no longer trying to emit a single number that felt right in a room. It was trying to produce an explainable recommendation — something that could justify a strong apply, an apply, a review, or a skip without requiring tribal knowledge of the weight file.
That shift also clarified where LLMs belong. Generation can help extract, normalize, or explain. It is expensive and unstable as the primary search index, and hard to regress when recommendation quality is the product claim. In Hirivo, model calls stayed off the critical retrieval path for a reason: ranking had to remain measurable.
Evaluation as product infrastructure
To avoid subjective tuning, Hirivo began defining a benchmark approach: multiple candidate profiles, hundreds of jobs, labeled candidate-job pairs, and repeatable matching runs. The goal was straightforward and demanding — determine whether a ranking or retrieval change actually improved recommendation quality.
Without that loop, every prompt tweak, weight change, or embedding swap is hard to defend. Soft launch feedback helps, but it arrives late and biased. Offline fixtures make the system honest earlier.
Evaluation is not a side notebook for Hirivo. It is how the recommendation system earns the right to change. If Rank, Fit, and Confidence are separable in the product, they also need to be separable in the measurement.
What “AI-native” means in this system
It is tempting to market any job product with embeddings as AI-native. Hirivo’s work points to a stricter definition. An AI-native job discovery system continuously discovers sources, normalizes noisy ATS data, retrieves a plausible set, enforces eligibility, ranks with explicit components, explains the recommendation, and measures whether changes improved outcomes.
Search is part of that. Generation may assist at the edges. Neither is the whole product.
Current direction
The system can be viewed as a continuous path:
ATS discovery → ingestion → normalization → retrieval → eligibility → ranking → explanation → application
The current focus is not “more search features.” It is recommendation quality — eligible opportunities, ranked with separable signals, explained in language a human can trust, and measured when the system changes. That is the difference between a job board with AI branding and a recommendation system that can survive ATS noise, profile gates, and the first angry “why did you show me this?” message.
Hirivo is still a product under active construction. The architecture is clear enough to publish because the decisions were earned in the pipeline, not invented for the case study.