When the model makes things up: how LIA guards against it

The problem

A language model doesn't lie on purpose. It predicts the most likely continuation and, when a piece of information is missing, it replaces it with something plausible. In a simple conversation, that gives you a wrong detail. In an assistant that acts, the consequences are more concrete: a route that takes the name “Alex Martin” itself as its destination, or an invented explanation like “your calendar isn't configured”, which sends you looking for a fault that doesn't exist. Stated with confidence, such an error is more dangerous than a simple “I don't know”, because you act on it.

What I wanted

I wanted a simple rule: LIA only presents as a fact what it received from a tool, read in the conversation or computed. What can be repaired without guessing your intent is repaired. The rest is refused, with a message that helps the model correct itself.

Before acting

Invented options are removed. If the model adds an option that doesn't exist to a tool, like a sort order the tool doesn't know, it's removed before the call, and the plan goes on.
Numbers are brought back within their bounds. Asking for a hundred results from a tool that accepts twenty gives you twenty. A value that can't be corrected without inventing, like a date in an unreadable format, remains a reported error.
A name isn't an address. Parameters that expect an address or an email are checked just before the call. If they contain the name of a person mentioned in the conversation, the call is blocked before anything is spent, with a clear instruction: get the contact's address first. When in doubt, the check lets it through, so as not to get in the way of a legitimate request.
A missing value stays missing. When a step repeats an action over a list and an item lacks the expected field, the parameter is left empty: the tool doesn't receive the word “null” spelled out, and it applies its own default.
The plan is reviewed for what's missing. A reviewer easily sees what a plan contains, much less what it leaves out. So LIA's reviewer starts by listing each thing your request requires, then checks that a step covers each one, before giving its verdict.

In the answer

When LIA gives you a time, a date, a number, a name or an address, that value must appear in the turn's data, in recently consulted items or, word for word, in a previous message. Otherwise, it tells you the information is missing and offers to go and find it. The items it has just read remain available to it for a few turns: a follow-up question like “and what time does it start?” relies on the data itself.

What must be exact is computed. A model predicts text; it doesn't do arithmetic. A percentage, the number of days until a date or a currency conversion go through dedicated tools: an exact decimal calculation that says when it had to round, a duration counted between two real instants, clock changes included, and the European Central Bank's reference rate, with its date.

When something fails

When a tool fails, LIA tells the model through a single channel, which names the tool and gives the exact number of failed steps. So the model doesn't have to guess what happened. A half-successful plan gives you what worked and says what didn't.

Two other rules point the same way. A reviewer's verdict isn't enough to announce that something is blocked: a capability is only said to be blocked if it was never launched at all. And a prepared request, a pending confirmation and a saved change are three different states, which LIA doesn't mix up in its report.

When LIA chains tools on its own, in ReAct mode, every piece of information it set out to get ends up either obtained or declared missing, along with what it tried. A tool that doesn't understand a value refuses it and explains the expected format.

The limits

These protections reduce inventions without eliminating them. A model can still rephrase badly a piece of data it received correctly.
The name check only knows the people identified during the turn. Important actions go through your confirmation anyway.
If your administrator turns them on, labels on your emails (category, urgency, suspected scam) remain hints: the absence of a warning doesn't prove a message is safe.