Entities Built for Your Company: How Mosaic Learns Your Hiring Language
A “sales person” at an enterprise software company and a “sales person” at a medical device distributor are different jobs. Most matching systems can't tell them apart. Mosaic is built so it has to.
The Taxonomy Trap
Nearly every talent platform on the market starts from the same place: a universal skills taxonomy. Tens of thousands of pre-defined skills and job titles, assembled by the vendor, applied identically to every customer. Your resumes and jobs are forced into that fixed vocabulary, whether it fits or not.
The problem is that hiring language isn't universal. “Account executive,” “implementation,” “case management,” “producer” — these words mean materially different things across industries, and even across companies in the same industry. A universal taxonomy averages those differences away. What's left is a match that's technically correct and practically useless.
Entities, Discovered From Your Data
Mosaic takes the opposite approach. When it connects to your ATS, it reads your resumes and job descriptions and identifies the concepts that actually appear in your hiring: the skills, roles, tools, certifications, industries, responsibilities, and qualifications that your jobs ask for and your candidates offer. We call these entities.
Entities aren't picked from a list. They're discovered. If your organization hires “territory managers” who must know a specific regulatory process, that process becomes an entity in your Mosaic instance — even if no off-the-shelf taxonomy has ever heard of it. If your engineering jobs consistently distinguish between building a system and operating one, Mosaic's entities reflect that distinction, because your documents do.
Two consequences follow:
- Your instance is yours. A hospital network and a logistics company running Mosaic end up with different entity sets, automatically. There's no implementation project to map your world onto someone else's categories — the categories come from your world.
- Entities carry context. Every entity Mosaic learns keeps a connection to the language it was learned from. “Sales” at your company isn't an abstract label; it's grounded in how your jobs describe selling — the deal sizes, the buyers, the motion. That grounding is what lets a match reflect your reality instead of a generic one.
Why This Matters for Matching
Consider that sales person. At company A, the job is outbound prospecting, short cycles, high volume. At company B, it's navigating a nine-month enterprise procurement process with a technical evaluation committee. A universal taxonomy scores both resumes as “Sales — match.” Mosaic's entities, learned from each company's own jobs and resumes, encode what selling means there — so the ranking reflects the difference your hiring managers already know exists.
This is also why Mosaic requires no taxonomy maintenance. As your business changes — new products, new markets, new role types — new language flows in from your ATS, and the entity set evolves with it. Nobody has to notice the change and file a ticket. The system learns it the same way it learned everything else.
The Bottom Line
Matching quality is decided before any match is ever computed — at the moment a system decides what concepts exist. Universal taxonomies decide once, for everyone. Mosaic decides from your data, for you.