What is interaction-ready data?

Most organizations that try to put AI in front of their people start with their documents. They connect a model to the policy library or the sales playbook and expect it to hold up its end of a conversation. It can usually talk. What it struggles to do is play the procurement lead who already has a cheaper quote on the desk, or tell a receptionist what changed in the visiting policy this week, in words the people who own that conversation would sign off on.

The model is rarely the problem. The data behind it was written for a different job. Documents are written to be read, and a conversation needs roles, turns and context on top of them. This post defines the term we use for that missing layer, interaction-ready data, and walks through what goes into it, what stays out, and how to tell whether yours is ready.

What is human-facing AI?

Human-facing AI is AI that a person talks to or works beside in the moment: a practice partner that plays a customer, a briefing that tells staff what changed, or a robot at a front desk. Because it sits inside a conversation, it has to handle roles, turns, wording, tone and context, so it needs data structured for that interaction, not only the documents behind it.

Compare it with AI that works in the background, such as a model that routes support tickets or forecasts demand. Background AI is judged on its output, often days later. Human-facing AI is judged in the moment, by a person who notices at once when it gets the role, the policy or the tone wrong.

Here is the sentence we use to describe our own company, because it shows the whole idea in one line:

PokaMind is a human-facing AI platform that structures an organization's own playbooks, policies and practice conversations into interaction-ready data, then builds what its people need on top, starting with AI roleplay practice, on a screen or on a robot.

How PokaMind describes what it does

Read it as a data pipeline. The playbooks, policies and practice conversations are the inputs. Interaction-ready data is what they become. Roleplay practice, on a screen or on a robot, is what runs on top.

What does interaction-ready mean?

Interaction-ready data is an organization's knowledge and conversation signals, structured for one specific human-facing use, so that an AI can act on it and a person can check it.

Two parts of that definition carry most of the weight. The first is "one specific human-facing use". Data can only be ready for AI in relation to a specific use. A policy handbook is ready for a search box as it stands. It is not ready for an AI that plays an employee asking about parental leave, because that AI also needs to know who the employee is, what they want, what they are likely to push back on, and which passage of the handbook answers them.

The second is "a person can check it". Structure that only a model can read does not help the people who have to stand behind it. If a scenario brief says the buyer has a cheaper quote and a boss who wants savings, a sales manager can read that line and say it is wrong for their market. If a passage of knowledge keeps its source, a reviewer can open the original and confirm it. Being checkable is what lets an organization put its name on what the AI says.

Why do human-facing AI projects stall on data?

The same three problems come up almost every time an organization tries to turn its material into something its people talk to.

• Documents are written for reading. A call script assumes the rep already knows the account. A policy assumes the reader will look up the exception on page 14. Neither says how the conversation opens, what the other person wants, or where it tends to go wrong.
• The knowledge that matters most lives in people. The best account managers know which objection follows the price question. The reception lead knows which sentence settles a waiting room and which one starts an argument. None of that is in the files, so a model given the files never sees it.
• Nobody has written down what good sounds like. Most organizations can name a good outcome: a renewal signed, a complaint closed. Few have described the conversation on the way there, such as the question asked before the price, the pause after the ask, or the sentence that names the customer's concern before answering it.

A bigger model or a longer prompt fixes none of these. What fixes them is structuring the material for the one conversation it has to support, with the people who own that conversation involved from the start.

What are the four layers of an interaction model?

We organize interaction-ready data into an interaction model with four layers, always in the same order: people, knowledge, moments and signals. One example makes them concrete: a sales renewal that has gone quiet. The contract expires in three weeks, and procurement has stopped replying.

People

Who is on each side, what they want, and how hard they push. In the renewal, the AI plays Alex Renner, a procurement lead who has been told to cut supplier spend this quarter and already has a cheaper quote. The learner plays the account lead. Five behavior dials, each set from 1 to 5, decide how hard Alex pushes: aggression, flexibility, information sharing, pressure tactics and relationship focus. The same scenario can be a gentle first run for a new hire or a hard one for a senior rep.

Knowledge

What your documents say, split into passages that keep their source. For the renewal, that is the pricing and discount policy, the objection-handling guide and the notes from deals the team has lost. Each passage stays tied to the file it came from, so a reviewer can trace what the scenario says back to the page that says it. One document of up to 100,000 characters can become a planned course of 1 to 10 modules.

Moments

The situations, how they open, how they turn, and the techniques that work. Alex opens in character: "I have a cheaper quote on my desk and a target to cut supplier spend this quarter. Tell me why we should renew." From there the conversation moves through stages. Alex pushes back, widens the objection, tests a solution with conditions attached, and then commits or does not. This layer also names the techniques the team is meant to use, such as asking what changed on the buyer's side before talking about price.

Signals

What can be observed in practice sessions: words, voice, face and body, described with 31 named communication styles. When the account lead runs the renewal, the platform analyzes what they said, their pace and pauses, their eye contact and expression, and their posture. It describes the session with styles such as direct, measured, acknowledging, pausing and investigative, each calibrated against the person's own baseline in that session, so a naturally quiet speaker is compared with themselves and not with the loudest person on the team.

Every record keeps three kinds of field apart. Measured fields are computed from the signal. Interpreted fields are written by a language model from the transcript and the measured signals, such as the session scores and the written breakdown. Missing fields are recorded as missing. Keeping them apart means a reviewer can always tell a measurement from a model's judgment.

What counts as a signal, and what does not?

A signal is something anyone in the room could have observed: what was said, tone of voice, pace, pauses, expression, eye contact, posture and gesture. Feelings are not signals, and neither is identity. An interaction model can record that someone paused for three seconds after naming a price. It does not record why.

European law draws the line in the same place. Recital 18 of the EU AI Act says emotion recognition does not include "the mere detection of readily apparent expressions, gestures or movements, unless they are used for identifying or inferring emotions." The Commission's guidelines on prohibited AI practices give the plainest example: "The observation that a person is smiling is not emotion recognition." Concluding from that smile that the person is happy would cross the line.

PokaMind is designed to stay on the observable side of that line. It is designed not to infer emotions, inner states or personality, and it does not identify anyone from their face or voice. A signal that was not captured is recorded as missing, never as zero, and the person sees it marked as not captured instead of as a low score. If the camera never saw someone's face, the record says so instead of showing a low score.

This is not legal advice. It is how we read the text, and it is the reason the platform is built the way it is.

How do you check structured data before people use it?

Structure only helps if it is checked before it reaches anyone. We apply one rule to everything PokaMind authors or publishes: the model proposes, code checks, a person decides. Three examples show what each step does.

1. A course from one document. A planner splits the document into modules. A validator checks that every idea is covered exactly once. Your reviewer approves the plan.
2. A scenario goes live. The model drafts the character, the opener and the stages. The platform refuses to publish with a missing or placeholder field. The author test-runs it and publishes it.
3. A briefing quotes a policy, a feature that is in development. The model drafts at most five items. Code checks every quote against the source file and drops items with none left. A person sends or skips the edition.

Where no person can check each answer in the moment, the rule becomes refusal. The session breakdown is checked by code before it is shown, and the robot's policy answers, in development, quote the organization's documents or say they could not find an answer.

Where does interaction-ready data run?

Once a situation is structured, the same interaction model can run on more than one surface. On a screen, it runs as AI roleplay practice, drills and a team view. The person who practiced gets the full written breakdown. In PokaMind, managers see each person's practice activity and session scores over time, never the conversation, the transcript or the written breakdown.

On a robot, it runs as EMORI, a small Reachy Mini robot in pilot at Badalona Serveis Assistencials, a public healthcare provider in Catalonia, under the EU ARISE program. EMORI runs the same practice by voice for reception staff who rarely get time away from the desk to train, and it is built to publish its interaction data on ROS4HRI, a set of open robotics conventions whose founding paper I co-authored (IEEE/RSJ IROS 2021). The details are in our post on how EMORI publishes practice data on ROS4HRI.

Three questions to scope your first situation

Interaction-ready data is built one situation at a time, so the first decision is which one. Three questions do most of the work.

1. Which conversation costs you most? Pick one where a bad outcome is both expensive and frequent: the renewal that stalls, the first call with a new account, the patient who has waited too long.
2. What material already describes it? Playbooks, call scripts, policies and training material are enough to start. Where the knowledge lives in people instead of files, we structure it with them in a workshop.
3. Who owns it? Someone on your side has to read the scenario briefs and say what is wrong with them. Without that person, the data is structured but nobody has checked it.

If you can answer all three, you have a scoped situation. That is where every PokaMind build starts.