Why ESInsight exists
Built in production, still delivering today
ESInsight was created to solve a problem observed inside a market-leading global executive-search firm: finding the right people quickly is impossible when the title data underneath the search cannot be trusted.
Built in the real world
The problem came before the product
The classification engine grew from millions of distinct job titles collected over decades of global executive-search work. This was not a tidy benchmark assembled for a model. It was the language people actually use in CRMs: abbreviations, combined remits, regional conventions, interim appointments, board positions, and titles that make sense only in their institutional context.
In that environment, classification is not an academic exercise. A consultant needs to find the right population quickly, understand why each person appears, and trust that an apparently precise filter is not quietly introducing incorrect results.
That operational requirement shaped ESInsight from the beginning. The goal is not to force every person into a category. The goal is to return structured information that is reliable enough to use.
The central philosophy
High-confidence matching, or nothing
When the evidence is insufficient, the endpoint returns no classification for that field. This restraint is a feature, not a failure.
Input
Regional Leadership Lead
- Management
- --
- Function
- --
- Standard roles
- --
- Employment
- Permanent
A system can always produce an answer. ESInsight is designed to know when that answer would not be dependable.
Why not classify everyone?
Coverage is easy to measure. Trust is harder to win back.
It is tempting to optimise a classifier for the percentage of records that receive a label. A general-purpose AI model will often produce a confident-sounding answer, even when a title is ambiguous or context is missing.
That can make a demonstration look comprehensive while weakening the data. Once incorrect classifications appear in search results, users stop trusting the filter and return to manual review.
ESInsight takes the opposite position. Precision matters more than artificial completeness. Deterministic rules make each match explainable and ensure that the same title under the same version produces the same result.
The engine becomes more capable through deliberate additions to its logic, not by lowering its confidence threshold. Unknown cases remain visible until the evidence for handling them is understood.
Design principles
An API shaped by how search actually works
Confidence before coverage
A classification is useful only when people can trust it. ESInsight returns nulls and empty arrays when the evidence is not strong enough, rather than filling gaps with a plausible guess.
Preserve every signal
Real titles contain overlapping responsibilities and statuses. Functions and standard roles can contain multiple values, while independent flags preserve details such as non-executive, partner, VP, and owner.
Build from real search behaviour
The taxonomy reflects how executive-search teams actually filter, segment, map, and shortlist people. Fields exist because they support a practical search decision.
Evolve without surprises
Logic is added deliberately, edge case by edge case. Every response identifies its taxonomy and pattern versions so changes remain visible, testable, and reproducible.
No information discarded
Real titles do not fit into one box
Chief Commercial & Strategy Officer
Multiple functions can coexist because a combined remit should remain searchable from either direction.
Group CEO & Non-Executive Director
Management, role, and non-executive status are independent signals. Capturing one never requires throwing another away.
See the philosophy in practice