The embedding models that power most search and recommendation systems today were trained with a single objective: make semantically similar text produce similar vectors. This works remarkably well for document retrieval and semantic search. It fails, often silently, the moment you ask it to represent a person.
The similarity trap
Consider a recruiting platform that uses off-the-shelf embeddings to rank candidates against roles. The system will reliably surface candidates whose resumes contain the same keywords as the job description. A posting for "Senior React Engineer" will return profiles that mention React, JavaScript, and frontend development.
But keyword overlap is not what predicts a successful hire. The candidates who stay longest and perform best are often those whose deeper traits, working style, growth trajectory, and cultural fit, align with the team and role in ways that surface-level text similarity cannot capture.
This is the fundamental gap, and it is worth stating precisely. A general-purpose embedding is a model of a document. What the recruiting problem actually requires is a model of a person. The first can be built from text alone. The second cannot.
What outcome-trained representations look like
Our approach starts from a different premise. Instead of training on text similarity, we train on labeled outcomes: hires that lasted, dates that converted to second dates, founders who closed term sheets with specific investors.
The training signal is not "these two texts are similar" but "this is what this person actually did." Behavior is the supervision. That produces a fundamentally different geometry, one that encodes how a person tends to act rather than what words appear near them.
This is why we describe the work as building foundation models of human behavior rather than building a matching engine. Matching is not the objective. It is the readout that makes the quality of the underlying representation legible, in the same way that a benchmark score makes the quality of a language model legible without being the point of the model.
Measuring the difference
On our internal benchmarks, representations trained on outcome data achieve 84.3% NDCG@10 on compatibility retrieval tasks, compared to 52–69% for leading general-purpose models including OpenAI, Gemini, and Voyage. The gap is not marginal. It reflects a structural difference in what the models have learned to represent.
Compatibility retrieval is a convenient way to measure this because the ground truth is unambiguous: the interaction either worked or it did not. But the same representation supports memory, recommendation, personalization, and simulation. Those are all downstream tasks reading from one model of the person.
Implications
For any platform whose product depends on understanding its users, the choice of representation is not a commodity decision. It determines whether your system knows a person or merely knows the words on their profile.
We are building that representation layer, trained on the outcomes that matter in each domain and deployable via API.