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.

Product note2 minute skim

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 classification returns no value for that field. This restraint is a feature, not a failure.

Input

Regional Leadership Lead

Low evidence
Management
--
Function mapping
--
Additional signals
--
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

Shaped by how search actually works

01

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.

02

Preserve every signal

Real titles contain overlapping responsibilities and statuses. Multi-value fields and independent signals preserve useful detail instead of forcing one simplified label.

03

Build from real search behaviour

The classification reflects how executive-search teams actually filter, segment, map, and shortlist people. Function mapping aligns with LinkedIn and established industry standards.

04

Evolve without surprises

Logic is added deliberately, edge case by edge case. Every response identifies its classification 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 remits preservedStructured output

Multiple responsibilities can coexist so a combined remit remains searchable without disclosing or duplicating the underlying mapping.

Group CEO & Non-Executive Director

Independent signalsNo information discarded

Classification attributes remain independent. Capturing one never requires throwing another away.

See the philosophy in practice

Test ESInsight with the titles you already know.