A Value the Visitor Never Gave Is Not Zero-Party Data

The rule, in one sentence

Zero-party data is data the visitor gave. A value the agent inferred is not, even when it is written into the profile as if it had been declared. It is an inference, with a different legal regime and a different commercial cost.

The difference is invisible on screen. It shows up on the first callback, when the salesperson opens with a budget the visitor never mentioned. Forrester's definition is about where a value comes from first, not how it was collected. European law already treats inferred data as data apart. And the only reliable way to keep the promise is to take the decision to write away from the model. It may propose a value; the code decides whether the value enters.

The call that opens with a question nobody asked

The visitor writes "I'm not sure where to start". The agent moves on to the next question. A field has just appeared in the profile: main objective, value "other". The visitor chose nothing, and does not know it.

Two days later, a salesperson calls. They read the field and state it as a fact. The first thirty seconds go into disproving data nobody produced. The only reliable information in that record is that the visitor did not know.

The turn did not happen by accident. The orchestrator had forced a write tool at that step, for a legitimate reason. Without that constraint, a visitor answering "we're a small shop of eight people" sometimes saw their free-text answer lost. The model, forced to call the tool, filled the field it was asking about with the only value left. The code demanded a write on a turn that was not an answer. The model complied.

So this is not a hallucination in the sense of a model inventing a fact about the world. It is a forced write where there was nothing to write. The distinction changes the fix: a stricter instruction does not repair a badly drawn tool contract.

A second path gives the same result. A visitor-type detection tool read the welcome message "I'm looking for a solution for my company" and sometimes filled objectives with "conversion". The engine, seeing the field filled, never asked the question again. A qualification step had disappeared, and the record carried an invented intent.

Two paths, one flaw: the model is used both to understand the visitor and to write the record. As long as those two roles sit in the same call, every improvement to one opens a gap in the other.

What "zero-party" means, and why the definition breaks

The salesperson who read "objective: other" was not fooled by a model. They read a field that does not say where its value came from. The missing word has a precise definition, and that definition is what makes the defect visible.

The term comes from Forrester. The definition has not moved since.

Two adverbs carry the meaning: intentionally, proactively. Forrester adds a sentence that settles it, about a beauty quiz. It is data a brand "can't infer, observe, or buy with certainty" [1]. What gives it value is precisely that it cannot be guessed. An automatic write destroys that property.

Most definitions found at the top of search results sort by interface: a poll, a quiz, a preference centre. The interface is a clue, not the property. A quiz pre-filled by a model is still a quiz on screen. None of those definitions says what happens when the form is not filled by the person reading it.

European law has already settled half of the question. Article 4(4) of the GDPR defines profiling as any form of automated processing of personal data consisting of evaluating personal aspects, in particular to analyse or predict them [2]. Deducing from a message that a visitor is preparing a purchase around €300,000 is exactly that. Profiling is not forbidden: it is lawful with a legal basis, correct information, and the right to object that comes with it. It is simply not declared data. The CNIL draws the same line around portability under Article 20. It sets data "provided by the person" against "inferred or derived data" [3].

Changing what the data is called changes the obligations attached to it. Accuracy, under Article 5(1)(d), requires data that is accurate and, where necessary, kept up to date. Access, under Article 15, gives the person the right to know what is held about them, including where the data came from when it was not collected from them. Rectification, under Article 16, assumes someone knows what to correct. And when an inference reveals health, origin or an opinion, it falls under the special categories of Article 9. Being inferred does not waive the conditions that regime requires: an inference is not, in itself, an exception [2].

Here is the concrete cost. A visitor exercises their right of access and asks where their budget bracket came from. If the profile files declared and inferred values in the same fields, the honest answer is: we do not know. The compliance side of this subject is covered in GDPR and progressive profiling. Here the question is narrower: what in a record still deserves the word "declared"?

Three ways to fill a field, only one keeps the promise

A field gets filled in three ways. They produce the same screen, the same export, the same CRM row. They do not produce the same record.

The third row needs no debate: no value should be written to satisfy a tool. The second requires a decision: inference can be useful, provided it does not take the place of declaration. Only the first deserves the word zero-party.

The defect was not born with language models. MultiWOZ 2.2, a reference dataset for booking agents, documents "hallucinated values". These are values present in the dialogue state that were never spoken. They came from human annotators who could see the rest of the conversation. The model had nothing to do with it, and the result is identical. The authors count 3,128 turns across 948 dialogues, and correct the dialogue state in 17.3% of user utterances, across 28.2% of the conversations [4].

Their typology is worth reading. The first cause is called "Early Markup": a value announced by the agent itself, which the visitor has not yet accepted. It must be excluded from the state. In our case the same defect took another form. The model wrote into the field it was asking about the value it had just suggested, and the code set it aside as a candidate. But the question step gave way to a confirmation, and the four-choice question stayed on screen without its chips. A refused write was enough to break the screen.

Their recommendation is not about writing style, but about the interface that receives the value. For a free-text field, accept only a value present in the conversation history, and reject the others [4].

Inference is not the problem, writing is

An agent that infers nothing understands nothing. Rewording a vague need, proposing two solutions from the catalogue, choosing the next question, spotting a refusal, handing over to a human. All of that is inference, and all of it is useful. None of those operations needs to write the record.

So the useful boundary is not "should the model infer". It is: at what point does an inference become a value in the record. Three palliatives circulate to hold that line.

The first is the most solid, and the most misunderstood. A structured output imposes a JSON schema on the model: Structured Outputs at OpenAI, response schema at Google, JSON outputs at Anthropic. It guarantees a conforming object, provided the provider accepts the schema. It says nothing about the truth of what the object contains. A 2026 benchmark covers 35 business documents and 12,867 annotated values. Six frontier models reach 51% well-formed outputs there, and 4.6% correct fields [5].

Your profile has six fields, not 369. The figure therefore does not say your agent will be wrong one time in two. It says that respecting a schema answers the question "is the shape right", never "did the visitor say it". Constrained mode lowered valid outputs from 51% to 37% in the same study, largely because several providers reject complex schemas [5]. A tool that guarantees the shape does not improve the substance, and can degrade it.

The second palliative is a sentence in the prompt: never invent a value. An instruction of that kind is probabilistic by construction, and cannot be tested: you cannot prove the absence of an invention on a turn you did not anticipate. Above all it loses the moment the code demands a write on a turn that is not an answer. The model has to call the tool, the tool requires a value, and the instruction has nothing left to oppose. That is the mechanism of the first incident told here. It is also the lesson of an earlier article on orchestrating a conversational agent: a code constraint holds where an instruction gives way.

The third is a second model asked to review the first model's extraction. It catches gross errors, it costs one more call per turn, and it risks sharing the first model's blind spot on a plausible value. A judge that finds "€300,000" consistent with the message will not flag it.

None of those three tools is useless. Each handles its own layer: shape, instruction, review. None makes a write traceable. All of them push the error further down the chain, where it costs more to find.

The code decides what enters the profile

The rule fits in one sentence: the model proposes, the code admits. Five mechanisms make it concrete.

It only holds for the fields the engine asks for itself. On a field nothing guards, a value written by the model enters with no check on its origin, and the rule protects nothing there. That limit is deliberate: a field with no stake can stay free, a field that decides a lead cannot.

So the boundary is not "important or not", everyone would answer important. It is "read by a decision or not". A field the objective lists, which weighs on the lead event or on routing, goes through the guard. A field nothing reads can stay free, and guarding it would cost a confirmation turn for nothing. The risk lies in drift: a free field that becomes a segmentation criterion without being listed. That is a configuration decision, to be revisited every time a new decision starts reading a field.

A button click is recorded before the model runs. The value sent by the chip is compared with the values the code proposed for the pending field. If it matches, it is written by the code, and the orchestrator decides on an already updated profile. The model has nothing left to record, and so nothing left to invent.

A value given before the question is not yet a filled field. The visitor who announces "I want to build a pool" in the first message has given the information: it is set aside, not counted. A value recognised word for word is admitted on that turn. A reworded value is put in the next question, then confirmed or discarded on the turn after. A plain yes records it without the model stepping in.

Grounding closes the third path, not every misunderstanding. A value written after a question must find support in the visitor's reply: one content word in common is enough, and every figure must appear. "Renovation" is supported by "renovate", but "40,000" is not supported by "20,000". The function's own comment says it plainly: a hint, not a proof. A negation fools it: "I don't want to renovate" contains "renovate". The word-for-word test reads it and refuses immediate recording, the support check stops at words. A misread refusal can therefore enter. The guard protects provenance, not meaning. A value with no support is not thrown away: it becomes a candidate, put to the visitor as long as a question remains. After the last ask it is refused and the field stays empty. The cost is there: a paraphrase with no common word, such as "refurbishment" for "renovation", loses a turn. An empty field costs less than a false one, because an empty field shows.

Confirmation is read in the code, not in the model. Two rules suffice. A list of phrasings counts as yes. And a sentence that starts with "yes" or "exactly" counts as yes, unless it contains a correction word. "Ok" and "all right" are not on the list. They acknowledge a message, they do not confirm a value, and the candidate may be the model's own inference. The price is deliberate: a visitor who answers "all right" to a confirmation loses the candidate and sees the question asked again.

An unconfirmed value is not a filled field. The application objective, the ask counter and the give-up rule only read the confirmed field. The CRM and the analytics then read the same thing, and that thing is what the visitor said.

The effect nobody expected comes next. The confirmation loop, the one that answers "can you confirm this is a repair?" to someone who has just written it, is the mirror image of invention. In both cases the model holds the value and is not sure of it: so it fills it, or it asks again. Take the value away from the model, and both symptoms fall.

We tried three rounds of prompt hardening before accepting that the problem was structural. Each lowered the frequency of the defect. None removed it. The two net gains came from code: the value written before the question discarded, the confirmation settled without the model. That is the rule we apply at Gamaro, on the fields the engine asks for: the profile accepts a value only if a turn of the visitor carries it.

What it changes for the integrator

The test is one question per field: which visitor turn carries this value? If the answer exists, the profile is defensible. If not, the field is the model's opinion, and it will eventually cost a meeting.

The profile does not keep that turn. The guard checks that it existed at the moment of writing; it does not archive it. Archiving this trace is separate work, and a guarded field remains defensible without it, since no value entered that field without a turn to carry it.

Three consequences. The first sales call starts from what the visitor said, not from a hypothesis to disprove. Segmentation can keep using inferred values, but as a separate signal. A segment built on an inference is a hypothesis, and a hypothesis gets checked. Finally, on a guarded field, a rectification request has an answer, because the value comes from a visitor turn, not from a guess.

Declared data is not true data: a visitor can be wrong, round up, or test your reaction. An honest profile therefore lets a correction replace a value, never average the two.

The confirmation mechanism has its own limit: a proposed and confirmed value is only declared if the question reuses what the visitor already said. "You mentioned a build, is that right?" after "I want to build a pool" tells them nothing new. "You're looking at around €300,000?" on a figure nobody spoke manufactures agreement, and agreement extracted from a suggestion is not a declaration.

Three questions are enough to assess an agent on this point, and none of them is about the model. Where does this value come from? Which visitor turn carries it, and did they say it or only confirm it? What happens to the field when I do not answer? An agent whose answer to all three is "the model understood it" is a form in disguise. An agent that can point to the turn is a profile, not a truth. It does not guarantee the visitor told the truth. It guarantees the record does not speak in their place.

Sources

1. Forrester (Stephanie Liu, Anna Hoskins), "Ask, Don't Interrogate: Best Practices For Collecting Zero-Party Data", 13 March 2025, forrester.com

2. Regulation (EU) 2016/679 (GDPR), Articles 4(4), 5(1)(d), 9, 15 and 16, consolidated text, EUR-Lex

3. CNIL (French data protection authority), "Droit des personnes et profilage : les spécificités du secteur de l'assurance", 16 July 2021, cnil.fr

4. Zang, X., Rastogi, A., Sunkara, S., Gupta, R., Zhang, J., Chen, J. (2020). MultiWOZ 2.2: A Dialogue Dataset with Additional Annotation Corrections and State Tracking Baselines. arXiv:2007.12720

5. Ferguson, N., Pennington, J., Beghian, N., Mohan, A., Kiela, D., Agrawal, S., Nguyen, T. H. (2026). ExtractBench: A Benchmark and Evaluation Methodology for Complex Structured Extraction. arXiv:2602.12247