Skills discovery over a résumé corpus

A consultancy's hardest internal question is embarrassingly simple: who here has done this before? The evidence exists (hundreds of résumés, years of projects), but it is scattered across systems, written in inconsistent vocabulary, and searched today by asking a colleague who might remember. The goal was to let someone preparing a proposal find plausible candidates faster and more broadly than that manual process, with every result traceable to approved evidence rather than to a model's impression.

Details of the organization, the people involved, and the corpus are deliberately omitted here: this is live internal work concerning several hundred real employees' documents. It is a working proof of concept, not a shipped product. What follows is the engineering.

• —A PostgreSQL schema across sixteen plain-SQL migrations covering roster and identity, document parsing, search, provenance, content readiness, canonical document assignment, extraction-run accounting, atomic experience observations, human adjudication of those observations, and retrieval evaluation
• —An authoritative employee roster imported transactionally, keyed on a stable identifier and never merged by name
• —An ingestion CLI rather than a queue service: the smallest thing that could process a corpus and be inspected when it went wrong
• —Retrieval over exact terms and PostgreSQL full-text search, with the vector approach kept as a separately measured alternative
• —A human adjudication path, so extracted claims can be confirmed or rejected by a person and the outcome stored as data
• —Around ninety-seven test files, with integration tests running against a Dockerised database

• —A two-key interlock before real data reaches a model provider. Processing anything real requires two independent environment settings to agree: the provider selection and an explicit approval flag. One misconfigured variable cannot send hundreds of employees' documents to a third party. The safety property is structural, so it holds regardless of who runs the script or how tired they are.
• —Keyword and full-text search as the baseline, before any vector ranking. The fashionable move is to embed everything and let cosine similarity sort it out. Doing that first means never learning whether it helped. The baseline shipped first; the vector approach is evaluated against it as a separate question with its own measurement.
• —Ranking uses exactly two signals, and adding a third requires measured motivation. Ranking functions accumulate heuristics until nobody can explain a result. Fixing the signal count and requiring evidence to change it keeps every result explicable, which matters enormously when the output is a list of your colleagues.
• —Deterministic identity matching with quarantine, never fuzzy auto-merge. Two people with similar names do not get silently combined. Ambiguity is held aside for a human instead of resolved by a confidence score. Getting this wrong attributes one person's work to another, which is unrecoverable in a system whose whole purpose is credit.

The judgment I'd point at first, though, is upstream of all of them. I had an independent adversarial review run against my own plan. It concluded that the proof of concept was trying to validate eight hypotheses at once (that résumés parse reliably, that they represent expertise, that a model can extract defensible claims, that a taxonomy can normalize vocabulary, that hybrid search ranks people usefully, and so on), and that this was not a proof of concept but a small product program.

It was right. The plan was rewritten around it: one user and one workflow instead of six, the phase split into a narrow credibility prototype and a separate scale demonstration, a retrieval baseline before ranking sophistication, atomic evidence observations instead of a premature universal graph, and — the part most plans omit — explicit stop criteria alongside the success criteria. Commissioning a review that can tell you your plan is too big, and then actually shrinking it, is cheaper at the planning stage than at any later point, and it is the least glamorous thing in this case study.