01
Storage
Files exist and can be retrieved if you know roughly where to look. The database is a place things go, not a place answers come from.
Filing
The People Data Layer
A decade of people data. Still nothing that answers a question.
Your firm has been collecting the raw material of talent intelligence since the day it opened — resumes, interview notes, rates, placements, who stayed and who didn't. It is all still there. It is just stored in a shape no system can reason about. The people data layer is the talent data infrastructure that makes it legible.
Sits under the systems you already run. Nothing to migrate, nothing to rip out.
Currently living in Your ATS A CRM Three job boards An assessment tool Payroll Shared drives Someone's inbox
A two-minute audit
Five questions your database probably can't answer
None of these are hard questions. They are the ordinary ones a client asks on a Tuesday afternoon. Try them against your own system — and notice how many end with someone opening a spreadsheet.
Which people we've already placed have both NetSuite and month-end close experience?
What did the last eleven roles like this one actually bill, in this market?
Who did we interview two years ago who would be senior enough today?
Which of our sources produce people who are still in seat after twelve months?
How many people in our database are genuinely available this quarter?
A keyword search can find you a document that mentions any of these. Not one of them is a question a document can answer.
The shift
Same information. Two completely different assets.
Nothing here is about collecting more. It is about what happens to the material you already own once it stops being filed and starts being structured.
What you have
A record store
- Documents you can search, one keyword at a time
- A separate copy of every person in every system
- Meaning locked inside prose and recruiter memory
- A schema your vendor designed and controls
- An "export" that arrives as a folder of PDFs
Depreciates quietly
What it becomes
A data layer
- Records you can query, filter, join and rank
- One resolved person, referenced everywhere
- Meaning captured in fields with a shared vocabulary
- An open schema you can read without permission
- An export that is the business, intact
Compounds every year
Anatomy
What actually sits inside the layer
Six groups of fields, one stable identifier per person, and the source and date attached to every value. That is the whole idea — the power comes from it being consistent, not from it being clever.
| Field group | What it holds | What it unlocks |
|---|---|---|
| Identity | One resolved person, deduplicated across every source system, with a stable ID | Stop counting the same candidate four times |
| Capability | Skills, tools and domains mapped to a shared taxonomy instead of free text | Search by what someone can do |
| Context | Industry, company stage, team size, language, time zone, work authorization | Match the situation, not just the skill |
| Commercials | Rate history, currency, contract type, notice period, availability window | Price a role from evidence, not instinct |
| Signal | Interviews, placements, tenure, client feedback and why a match did or didn't hold | Learn from outcomes instead of repeating them |
| Provenance | The source and timestamp behind every single field in the record | Know which version to trust |
Built for real data
It takes the mess, because the mess is what you have
No staffing firm has clean data waiting to be plugged in. The layer is designed around that fact: cleaning is the work it does, not a prerequisite you have to complete first.
Whatever format it's in ATS exports, PDF resumes, decade-old spreadsheets, notes typed into a free-text box at 6pm.
Duplicates resolved, not deleted Four partial records become one person with a full history — and you can still see where each field came from.
Vocabulary reconciled "AP clerk", "accounts payable specialist" and "cuentas por pagar" stop being three unrelated strangers.
Served back through an API Read and write from any tool you run today, or any tool you decide to build next year.
The ladder
Four stages between a filing cabinet and infrastructure
Most staffing firms are somewhere in the middle two, and have been for years. Moving up a rung is not a software purchase — it is a change in what the data underneath is capable of.
02
Search
Keywords and filters find documents that contain the right words. Recall depends on how the recruiter phrased it, and on luck.
Most firms
03
Structure
Key facts move into real fields with shared meaning. You can finally count, compare and report on the people you know.
The turning point
04
Infrastructure
The structured record is served to every system through an API, owned by you, and portable. Tools come and go; the asset stays.
The data layer
The series
Eight arguments, one conclusion
Written for owners, RecOps and data leads who suspect the bottleneck isn't the software. Start with the cornerstone, or pick the argument you're least convinced by.
Cornerstone
Why Every Staffing Company Will Eventually Need a People Data Layer
The full argument in one place: why structured people data behaves like compound interest, why the firms that start now build a lead that can't be bought later, and why "we'll fix the data when we replace the ATS" is the most expensive sentence in staffing.
Read the cornerstoneIndustry
The Missing Data Layer in the Staffing Industry
Staffing built plenty of applications and almost no shared plumbing. A look at the gap every vendor category quietly assumes somebody else already filled.
Infrastructure
Staffing Companies Don't Need More Software. They Need Better Data Infrastructure.
A new tool sitting on unstructured data inherits the same problem on day one. Why the next line item should go underneath the stack rather than beside it.
ATS data
From ATS Database to Talent Intelligence: Unlocking the Data You Already Have
Odds are you placed someone into a role just like this one three years ago. What it takes to make that history answerable instead of merely archived.
Data assets
Your Candidate Database Isn't a Database. It's an Untapped Data Asset.
A folder of resumes is storage. An asset is something you can value, query and act on — and that distinction shows up directly in margin.
APIs
The API-fication of Talent: Infrastructure for the Next Generation of Staffing
Once talent data is reachable through an endpoint, staffing stops being a chain of manual handoffs and starts behaving like a platform.
Fintech parallel
People Data as Infrastructure: What Staffing Can Learn From Fintech
Payments were fragmented, proprietary and manual until a data layer standardised them. The parallel to talent is closer than it looks — including who captured the value.
Portability
Why Talent Data Should Be Portable, Structured and Interoperable
Three properties that decide whether a decade of candidate history is an asset you own or a hostage held by whichever vendor you signed with last.
The bet
The firms that win the next decade of staffing won't be the ones with the best software. They'll be the ones whose data was ready when the software arrived.
Straight answers
The questions owners actually ask
Mostly variations on "does this mean another migration?" It does not.
So is this an ATS replacement?
No — it goes underneath one. Recruiters carry on working where they work. What changes is that the data they generate lands in a structured, reusable form, and stays with you if you ever swap the system on top.
How is a data layer different from an integration or a warehouse?
An integration shuttles records between two systems and leaves both versions in place. A warehouse copies records for reporting and is usually read-only. A data layer resolves identity, normalises meaning, and serves the result back into live workflows — it is the source of truth rather than a reflection of one.
Our data is a mess. Do we need to clean it first?
No, and you shouldn't try. Resolving duplicates, parsing free text and reconciling vocabularies is the work the layer exists to do. Firms that wait until the data is tidy wait forever.
What does "structured" mean in practice?
That the things you care about — skills, tools, seniority, languages, rate, availability, what happened after placement — live in defined fields with shared meaning, rather than inside sentences a keyword search has to guess at.
Who owns the data?
You do. Portability is the entire premise: an open schema, source and timestamp on every field, and a complete export whenever you ask for it. A layer you can't leave isn't infrastructure, it's a lock-in with better branding.
We're small. Is this only for large firms?
The opposite, usually. Smaller firms have less history to untangle and fewer systems to reconcile, so they get to a clean layer faster — and then compound the advantage while larger competitors are still scoping a migration.
Look at a real layer first
Explore structured, vetted talent data the way your systems would — fields, taxonomy, provenance and all. No sales conversation required to look around.
Or start with what you already hold
Tell us what's in your ATS and where else the rest of it lives. We'll walk through what a structured layer would make possible on top of it.
