Keep the data fixed when an LLM explains it

An application can produce a structured result and then ask a language model to explain it. That creates two different responsibilities: preserving the result and generating an interpretation of it.

If both responsibilities are placed inside a single model response, the application may display an explanation of data that has quietly changed.

This matters for symbolic diagrams, calculations, imported reports, and other interfaces where the user should be able to inspect the original input.

For an illustrative six-line diagram, an input object might look like this:

{ "question": "What should I examine before making this choice?", "lineOrder": "bottom-to-top", "lines": ["solid", "broken", "solid", "solid", "broken", "broken"] }

The ordering is explicit. The original object belongs to the application. The model is asked to explain it, not to regenerate or correct it.

In the UI, render the diagram from that original object. If an explanation needs to refer to a line, use a reference to the original line rather than accepting another copy of the whole diagram from the model.

A response schema can ask for a summary, the input references used, and questions the reader might consider. It does not need to include a replacement for the original data.

{ "summary": "...", "references": [1, 4], "reflectionQuestions": ["...", "..."] }

Validate the structure before rendering it. Are the references valid for this input? Is the response in the requested language? Did the model return a usable explanation at all?

Those checks do not establish that the interpretation is true. They answer a smaller, useful question: does the response have the shape the application expects, and does it refer to data that exists?

Keep user text separate from application instructions

A person's question is input data. It may contain instruction-like language, so it should not be treated as authority to change application behavior.

Separating instructions from input and limiting what the application accepts are useful boundaries. A prompt alone is not a complete security control. Validate the model response and escape content before showing it in the UI.

Show the source and the explanation separately

A polished explanation can make it difficult to see which parts came from the application and which parts were generated. Separate visual sections help: original data in one area, model interpretation in another.

If generation fails, the original result should still be available. If the user disagrees with an interpretation, they should be able to return to the same input and examine it again.

The design principle is modest: a language model can explain an application-owned result without becoming the source of truth for that result. That boundary is useful well beyond symbolic diagrams.

Disclosure: This article was drafted with AI assistance. The JSON objects are illustrative design examples, not extracts from a deployed system or evidence of a security audit.