Agents will not message Rob in Payroll to ask what a field means. The meaning HR analysts carried in their heads now has to be written down, owned and kept current, and that is knowledge management work as much as data work.
Every HR data team I have worked with has a Rob.
Rob sits in Payroll. He has been there eleven years. When an analyst finds a field called TERM_RSN_07 and cannot work out why it shows up for people who never left the company, they message Rob.
Rob writes back in four minutes. "That one is a transfer to the Canadian entity. We code it as a termination on the US side so the payroll file closes out. Leave them out of attrition. It has been that way since the 2019 migration."
The analyst says thanks, adds one line to a query, and moves on. The answer now lives in Rob's head and in a filter in a notebook nobody else will open.
Multiply that exchange by twenty years and a few hundred fields and you have the current state semantic layer approach of most HR functions. It was and in many cases still is a person. The analyst sat between the data and the answer and translated, every time, without anyone writing down what they knew.
That arrangement held up for as long as it was another person who was the one asking the question and could pester Rob at the water cooler. However, it breaks the day an agent asks instead, because an agent picks the most plausible reading of TERM_RSN_07, counts every one of those transfers as an exit, and reports US attrition two points higher than it is. Then confidently proclaims that it got the answer right (of note, I've met plenty of business leaders that do this too).
The analyst was the semantic layer
At Ikona we call people like Rob human APIs: the people who carry data between systems that do not talk to each other, and who vouch for it when it arrives. They gatekeep, they validate, and they translate. Translation is the part that matters here.
Translation is knowing that "termination date" means last day worked in one system and last day paid in another. It is knowing that people on leave longer than 90 days drop out of headcount in the board report and stay in for the workforce plan, and that the second report is the one Finance trusts.
Every workforce number your team has ever trusted passed through a person who knew those things and this is still largely the role of many People Analytics leaders today. Before anyone can act on a number, someone has to know which definitions shaped it and whether it is the authoritative version. Michael Polanyi described this kind of knowledge, tacit knowledge, in The Tacit Dimension in 1966 saying: "we can know more than we can tell."
In most HR teams, those answers never made it into a system. They lived in the analyst. The analyst asked Rob, remembered what Rob said, and applied it next time without being asked.
That is why this work never showed up on a roadmap. Its cost was buried inside the cost of analysis. Nobody funded "write down what Rob knows" because the analyst was already absorbing it, one request at a time. When a leader asked why a simple headcount question took a week, the real answer was that most of the week went to translation.
Agents do not call Rob

In all three tests, the jump came from writing the business context down.
Databricks named this shift in a September interview with Richard Tomlinson, Director of Product Marketing. "For decades, enterprise data architecture has operated on an implicit assumption: if you organize the data correctly, an intelligent user can figure out what it means," he said. "AI agents break that assumption because there may be no knowledgeable human sitting between the data and the decision." In HR, that knowledgeable human was the analyst (with a "Rob" behind them).
Two things change when agents start answering workforce questions:
The first is who is asking. Today a request reaches your people analytics team, someone with context picks it up, and the answer comes back days later with caveats attached. Soon a manager asks an assistant in Teams or Slack and gets an answer in seconds, with no caveats unless someone wrote them down. The volume goes from what one team can field to whatever every manager thinks to ask, and most of those managers do not know which numbers to distrust.
The second is what happens after the answer. For most of HR's history an insight had to pass through several people before anything happened, and those people absorbed the cost of thin context. Bad context produced, at worst, a bad slide that someone caught. Agents are starting to route cases and flag teams as retention risks. When the action happens seconds after the question, nobody is in the room to catch it.
The published research points one way. In 2023, researchers at data.world gave GPT-4 43 business questions about an insurance company's database, first against the raw tables and then through a knowledge graph that described the business concepts behind them. On the questions that needed many tables, accuracy went from zero to more than a third.
This year Databricks' own data platform team said its internal analytics assistant was formerly "a coin toss" on business questions until metric definitions, fiscal calendars and exclusion rules were written into governed definitions. Anthropic's data team saw the same jump once it wrote down which sources to use and the gotchas a senior analyst would flag.
Each test had its own setup, and all three found the jump came from writing the business context down. Anthropic's team also found that the gain decays. Accuracy drifted from about 95% at launch to about 65% within a month, because the data model kept changing and the written guidance did not.
We have heard "semantic layer" before
If you have worked in HR data for more than a few years, this pitch is familiar. BI vendors have sold semantic layers since the early 1990s. Every few years a new tool promises one place where "headcount" is defined once and every report agrees. Most HR teams got partway there: a handful of certified metrics in the dashboard tool, and everything else still in someone's head.
In the same Databricks interview, Richard Tomlinson is candid about why. Semantic layers and knowledge graphs "have delivered real value, particularly for business-critical concepts," he said. "The problem comes when organizations try to manually model the entire enterprise."
The stall made sense. A semantic layer competes for budget against things leaders can see, and HR always had a cheaper fallback in the analyst and in Rob.
HR also never had a forcing function. We made this point in Context is all you need: finance writes its definitions down because regulators and auditors make it, and HR has no equivalent (or at least didn't until recently). Nobody audits whether two of your business units mean the same thing by "manager." HR definitions also move with every reorg and every policy change, so whatever did get written down went stale without anyone noticing.
What changes now is the fallback. Once agents answer questions directly, Rob is no longer one message away and they answer employees instantly with that stale context. The semantic layer becomes the only place the meaning can come from, and without one, the agent supplies its own. That is what I mean by no longer negotiable.
What an HR semantic layer has to hold
An HR semantic layer holds three kinds of knowledge. Most people picture only the first.
Definitions. What does this word mean here? "Regrettable attrition," for example, means voluntary exits of people rated strong or above in the last cycle, with internal transfers excluded. Today that usually lives on a steering committee slide from three years ago, and in the analyst's memory.
Business rules. Which exceptions and dates change the answer? Leaves longer than 90 days drop out of headcount. The Canadian transfer code is excluded from attrition. "Manager" means the manager in place on the day the person left. Today these live in filters inside individual queries and dashboards, and in Rob.
Authority. Which source wins, who owns the definition, and when was it last confirmed? The HRIS is the source of record for hire date, and the ATS for offer date. Total Rewards owns "total cash," confirmed after the March reorg. In most HR teams I have worked with, this lives nowhere.
Definitions are what vendors demo, and they matter. Business rules are where HR is harder than other functions. Almost every workforce number depends on a date, because people move and the org chart gets redrawn. "Who was this person's manager?" has at least two right answers, and which one is right depends on the question being asked (talent, performance, comp, or EL/LR each have their own reasons and perspectives). An agent cannot work that out from the field name.
Mars ran into exactly this. Its people analytics team has been building Associate 360, a hire-to-retire data model for more than 140,000 associates that HR business partners can question in plain language, and presented it at Databricks' Data + AI Summit in June. Afterward, Rachel Belino, Mars's HR Data Officer, wrote that a time-phased link table was the single biggest unlock for accuracy. That is the date problem, solved in the data model. Her hardest lesson, she wrote, was that "a clean data model isn't enough. AI on top of messy context still hallucinates." Getting the semantics right, she added, is "where the real work lives."
Authority is the part almost nobody builds, and it is the reason the other two decay. A definition with no owner and no confirmation date is a guess with good formatting. Databricks' guidance for its own context layer gives human-reviewed definitions precedence in a conflict, because they are "human-asserted and reviewed" and so "carry more authority than inferred context."
Anthropic's drift came from a changing data model, and the team fixed it by making every model change ship with a matching documentation change. HR definitions break when a reorg or a new leave policy lands, and nothing in the data model announces either one. Someone has to own each definition and know when to check it again.
The semantic layer sits between analytics and knowledge management

Analytics builds and enforces the layer. Knowledge management supplies the meaning.
The semantic layer usually gets filed under data engineering. I think that is half right, and the missing half is why so many of these projects stall.
Analytics teams are very good at encoding a definition once someone has settled it. They can build the metric, test it, version it, and make every dashboard use it. What they have rarely been asked to do is find out what the definition should be when it lives in four people's heads and two of them disagree. Getting it out of your local "Robs", checking it against what Total Rewards believes, writing it down with a source, and getting someone to own it is knowledge management work. That work is built from interviews, sourced claims, named owners and review dates, with stale content retired on a schedule.
Both disciplines feed the same layer. One supplies the meaning, and the other builds and enforces it.
Anthropic's write-up points the same way. The team tried having a model generate metric definitions automatically from raw tables and query logs. In their words, it "produced plausible-looking definitions that encoded the very ambiguities we were trying to eliminate," and it scored worse on their evaluations than a smaller set curated by people. Their recommendation is to let AI draft the documentation and have a human own the definition, and they are plain about who does the upkeep: "the curation and ownership are managed by humans." They also run a scheduled agent that scans stakeholder channels for corrections ("you're missing the fraud filter"), drafts a one-line fix to the relevant reference doc, and sends it to that domain's owner for review.
This is the work Ikona does. The Ikona Systems Diagnostic runs structured interviews as part of our semantic layer acceleration projects across an HR organization and turns what people say into discrete, sourced facts that people and machines can both query. We have called the result an HR context layer. The definitions and business rules an HR semantic layer needs are some of the most valuable facts in it, because they already exist and almost nobody has written them down.
People analytics spent twenty years learning to make numbers trustworthy. The same discipline now has to be applied to meaning. Rob's eleven years of answers get his name on them, with a source and a date, and the next analyst can read them instead of messaging him. They can still message him, but let's let him enjoy a new conversation. He deserves it.
Where to start this quarter
The first version of an HR semantic layer covers fewer definitions than people expect, and it has to get those exactly right. Richard Tomlinson's advice in that Databricks interview is to "model the head and learn the tail": humans "explicitly define and govern the small set of concepts that cannot be wrong," and the tail is learned from how the organization operates. In HR the head is bigger than it looks, because nearly every definition that touches pay, performance, leave or exits belongs in it. Six steps get you started.
Write down the 25 questions leaders actually ask. Pull them from the last two quarters of requests to people analytics and the HRBP inboxes. They set the scope of your first definitions, and they become your test set.
Find your Robs. For each question, ask the analyst who they message when the number looks wrong. That list is your map of human APIs. It also tells you whose knowledge leaves with them when they retire or change jobs.
Interview them and record sourced claims. One rule per line, attributed to a person and a role, with a date. Where two people disagree, record both and flag it. The disagreement is a finding, and usually an expensive one.
Decide authority before you encode anything. For each definition, name the source of record, the owner, and the event that triggers a review, such as a reorg or a system migration.
Encode it in whatever semantic layer you run. The platform matters less than the rule that agents and dashboards both read from the same place.
Test it the way you would test a model. Rerun the 25 questions after every reorg and policy change. Treat every correction someone makes ("that number should exclude contractors") as a candidate fix, routed to the owner of that definition.
Someone in HR has to own this. The technology function will help encode it, but as my co-founder Ian O'Keefe put it in The Hidden Data Deficit, IT "will not interview a benefits administrator about the seven exceptions she handles every Friday that never touch a ticket." In most companies I would give it to whoever leads HR technology and workforce systems, with people analytics and HR operations running the interviews and the encoding.
Before Rob retires
Most HR roadmaps I see now have agents answering workforce questions sometime in 2027. Far fewer say where those agents will get the meaning of the words in the question.
Rob has eleven years of answers in his head and a retirement date he has not told you about. Getting those answers out of him, and into a layer every agent reads from, is the half of this work your data team cannot do alone.
If you want a place to start, pull your 25 questions this month and count how many of them only Rob can answer.
Sources
Research and industry
Databricks, Data Ontology defined: The context layer your AI agents are missing, interview with Richard Tomlinson, Director of Product Marketing, September 15, 2026
Databricks, Operationalizing Genie Ontology in Your Data Stack, Srujan Alase and Richard Tomlinson, September 1, 2026
Databricks, Supercharging Genie Performance With Metric Views, talk by Krishna Bhupatiraju, Databricks data platform team, 2026
Juan Sequeda, Dean Allemang and Bryon Jacob, A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases, data.world, 2023
Anthropic, How Anthropic enables self-service data analytics with Claude, June 3, 2026
Rachel Belino, HR Data Officer, Mars, LinkedIn post on Associate 360, June 24, 2026
Databricks Data + AI Summit, Building Workforce Intelligence With Unity Catalog and Databricks Genie, Mars session, June 2026
Michael Polanyi, The Tacit Dimension, 1966
From Ikona
"Human APIs": The Real Labyrinth of HR Transformation, January 2026
Context is all you need, August 2026
Why HR Needs a Context Layer to Win the Next Wave of AI, July 2026
Ian O'Keefe, The Hidden Data Deficit That Will Sink Your HR AI Strategy, June 2026
Written by
Richard Rosenow
Richard Rosenow is Co-Founder and Chief Product Officer of Ikona Analytics, where he owns the ISD (Ikona Systems Diagnostic) methodology, client delivery, and product. He started as an HR business partner at Citi and spent 15 years in People Analytics at GE, Meta, Uber, Nike, and Argo AI, then as VP of People Analytics Strategy at One Model. He created the Workforce Systems Leader and People Data Supply Chain frameworks, and is an HR Tech 100 honoree.
Learn more about our team