What a “conception of use” means?

It is a fair question: as long as we stay away from the mechanics, the idea remains abstract. So I would like to go into detail here and set out a few concepts drawn from a real development: Opaly, the software we built at SoScience to help put together European research proposals. At SoScience, we needed to offer a digital experience that would lead people not only to write a European grant application (the job they wanted to get done) but also to build impact into it (both what the Commission expects and SoScience's own mission). The way we responded to this rests on two design concepts, which I will call here world logic and information gates. I believe these concepts can help other projects with strong social impact, driven by clear values or a strong mission, to integrate generative AI with guardrails on those values.

A key notion in this kind of design is being able to describe the logic that will underpin the answers. Let me take an example that I think illustrates this perfectly: LLMs applied to video games.

At a recent conference at the French Academy of Technologies, David Louapre presented Ubisoft's work on non-player characters (NPCs), the characters we meet in every game who recite dialogue written in advance. It is easy to imagine how much more realistic the experience could become once LLMs are integrated into the game mechanics. The ambition is simple to describe: being able to talk to them in natural language, and having them act accordingly. Yet the difficulties of implementation quickly become apparent. You ask a character to come and check a corner of the map with you, they answer “Yes, I'm coming”, and they do not move. The problem is that the language model can respond plausibly, but it does not know what the character is capable of doing, what they are supposed to know, or even whether that corner of the map is an accessible place. What it lacks is a certain “world logic”.

A world logic

In November 2025, Ubisoft unveiled Teammates, a research prototype presented as its first truly playable generative AI project [2]. The player must infiltrate an enemy base, accompanied by two teammates, Sofia and Pablo, to whom they give orders by voice, in natural language. The player can, for example, ask them to cover their advance, open a gate when they arrive, or distract a guard. Here, the language model enables an interaction that was previously out of reach: talking to an NPC as one would talk to a human partner. The NPCs understand the intention and the context, and respond by acting as requested.

What did it take for Pablo to move as intended? The architecture Ubisoft has made public gives an idea of the scale of the work: a game engine, a language model at the heart of the conversational system, a software layer developed in-house, and more than twenty specialised models for speech recognition, speech synthesis and emotion detection. The language model is only one piece of the whole. The decisive element, the one that makes the experience credible, is the connection between the language model and the game mechanics. It is a formalised description of the world and of what can be done in the game.

When the player speaks, the system does not only send their order to the model. It also sends a description of the world: the places that exist, the available actions, what each character can or cannot do, the current situation. This description was produced by the teams behind the game: they formalised its places, its rules, the abilities of each character, what a teammate can accept and what they must refuse. Ubisoft itself describes its role in these terms: giving AI a framework.

This is what I will call here a world logic: an explicit logical system of what exists (the objects), of what is possible and who can do what (specific to each object), and of the relationships between these objects. The important point is that a language model, however powerful, cannot make up for a missing world logic. If the hill is not an accessible place, no phrasing will allow the character to reach it. The model can respond to the player's intention, but it is the world logic that determines whether the requested action exists. The model cannot guess this logical system: it does not appear in any training data.

Describing a world logic is work we did for Opaly. We had developed software to help scientists and their partners put together European research proposals with a particularly solid impact component. Technically, it relied on Mistral models, integrated through n8n, surrounded by entirely conventional code and by an interface that carried a large part of the system's intelligence, as we will see.

European grant applications run to several dozen pages and follow a demanding structure. A grant has its own internal logic, made of objects and the relationships between them. Problems, to which target groups are linked. Tasks, some of which produce deliverables and others outcomes. And above all an impact model, that is, a logical chain connecting what the project produces to what it changes for society. Results only become outcomes by going through dissemination, exploitation and communication (DEC) actions, before translating, further down the line, into impacts. Each object has its place in this logical system and must be handled accordingly: knowing that a DEC action can only produce an outcome from a result is what makes it possible to place it in the right part of the proposal, exactly as knowing that a character can run makes it possible to give them that order. Describing this logic is necessary for the text to be good, and not merely plausible.

Formalising all of this, making explicit what makes a good proposal, what connects an activity to an impact, what an evaluator looks for and what they penalise, was a major part of the solution. This knowledge was the raw material of the software, long before any line of AI-related code.

Up to this point, the two cases run in parallel: to make relevant decisions, the world logic must be explicit. A video game, however, has a considerable advantage: its world is finite and known in advance. It can be described in full. The existence of the hill, Pablo's abilities, the objects in the inventory: everything is perfectly known and can be passed on to the model. This is not the case for most uses of generative AI. For Opaly, we had the logical structure, but the content of each box depended on the project. Every new project has its own problem, its target groups, its geography, its consortium, and this information can only come from the user. So what do you do when the world is the real world and the amount of information is infinite?

This is where the problems begin.

Information gates

The difficulty that shapes everything else is this: the user does not know what they need to provide. They arrive with their idea, sometimes developed over years of highly specialised expertise, and they are in no position to know what matters for such a proposal. They rarely arrive with their target groups defined, their area of intervention delimited, their impact chain articulated.

Faced with this gap, a generative system has a natural tendency: to fill the holes with something plausible. This is what a raw model produces when asked to write a grant from an idea. It invents believable target groups, a geographical area, generic impacts. The text is credible, but it is the same soup served to everyone, and an evaluator who reads hundreds of proposals recognises it immediately.

To avoid producing this kind of mediocre content, we made a different technical choice: not answering as long as we did not know. This is the second concept I would like to set out, that of an information gate: formally defining which information is necessary, in what quantity and of what quality, before allowing the system to produce anything at all. As long as the gate has not been passed, the system does not generate. It asks, or it flags what it is missing.

Here is how this worked in practice in Opaly, and what each choice involved.

First, the gates themselves. Each production step was conditioned by go/no-go checks: the agent in charge of a part of the proposal was only activated if the information it needed existed. In our case, this check relied on conventional code backed by databases. The software knew where each piece of information was stored, so it could reliably establish whether it was present or not, with no AI involved in this mechanism. One could imagine another approach, in which the model itself would be asked to judge whether it knows enough to answer. It is an open avenue, but it amounts to trusting a model to measure its own ignorance, an exercise at which current models remain unreliable. We preferred a check that did not depend on that judgement.

Next, the specialised agents. A grant is not a homogeneous text: writing an introduction, describing the state of the art, formulating impacts and presenting a consortium are different exercises, with different rules and different pitfalls. Rather than a single system asked to do everything, Opaly assigned each part to a dedicated agent, with its own instructions and its own reference examples.

Then, orchestration. Specialised agents produce pieces, which must be assembled and checked for consistency: the impacts announced in one section must match the activities described in another. This assembly layer is also a matter of logic rather than generation, since it is the logical model of the grant that determines what must be consistent with what.

Finally, and this is perhaps the part most visible to the user, the refusal had to be seen. When a gate had not been passed, Opaly did not silently produce a degraded text: the interface showed it. Red, amber and green lights indicated what still needed to be improved for better generative work; buttons remained unclickable as long as elements were missing, with an indication of what needed to be completed. In essence, the software was saying: here is what I do not yet know about your project, and I will not invent it for you.

Claude recently adopted a similar principle: it began offering multiple-choice questions when it needed clarification or additional information. This is a conversational version of the information gate. The form matters less than the principle: the system does not act as long as it does not know, and it says what it is waiting for.

What the gates encode

Why build all this, rather than plugging in a model and letting it write?

The first answer is the quality of the output. It is impossible to write a good grant without going through the logical elements of the project: its precise problem, its actual target groups, its articulated impact chain. A proposal built without them produces text, not a real project. Information gates are therefore not decorative: they are the condition for what comes out of the system to be the most robust version of one specific project, and not a statistically plausible average project.

But quality does not explain all of our choices, and this is the point I would like to stress, because technical discussions about AI most often miss it: an architecture also encodes convictions.

Two examples, drawn directly from the values that drove SoScience.

The first: the scientist is the person best placed to know what they want to do. This is a position on who holds the intention in a research project. Translated into architecture, it gives the following: when a piece of information is missing, the system asks the user for it, it does not invent it. Software that fills the gaps in the scientist's place has implicitly decided that their intention does not matter. Ours was built on the opposite position: it is your project, it is up to you to say what you want to do, the tool assists you and does not take your place.

The second: impact must be real, not merely compliant with expectations. It is possible to win a European grant by answering exactly what the Commission asks for, and nothing more. Yet we had gates that went beyond these expectations, for example on the diversity of partners in the consortium. Nothing required checking it, and a winning proposal can be written without it. But fifteen years in the field had taught us that a project with diverse partners, particularly beyond academia, produces stronger impact. This gate did not serve compliance; it served what we believed to be a good research project with impact.

This is probably the most concrete definition I can give of conception of use: technical choices that make it possible to encode what matters (convictions, values, a required level of quality...).

What precedes obviously goes beyond European grants and video games. Every profession has its world logic: what exists, what is possible, what one needs to know before acting. It is what makes the difference between a superficial answer and a solid one, and it is its absence that forces us into endless prompts in which we try to rewrite, with every request, a professional logic that deserved to be formalised once and for all. Designing a tool that integrates generative AI without having laid down a world logic and a required amount of information means taking the risk of getting an average result, one in which values are not under control.

Public institutions also appreciated our software for the alignment between our technical choices and the values they carried. This kind of choice has its limits, and other teams are currently making other choices, with other logics and other convictions. I would be genuinely curious to read their version of this essay: how they decide what their system requires before answering, and why.

[1] Mélanie Marcel, “Sovereign models, imported uses?”, August 2026: https://melaniemarcel.com/essays/sovereign-models-imported-uses/

[2] Ubisoft, “Ubisoft Reveals Teammates – An AI Experiment to Change the Game”, November 2025: https://news.ubisoft.com/en-us/article/3mWlITIuWuu0MoVuR6o8ps/ubisoft-reveals-teammates-an-ai-experiment-to-change-the-game