Context

LLM-generated content is written into persistent storage alongside human-verified data, and downstream features and users will read it. Some of it has been checked, most has not, and once stored the two look identical.

Examples

A meaning (a word paired with a translation) can exist at several trust levels: generated by Google Translate (unverified), verified by an LLM-Checking-LLM pass (auto-verified), implicitly accepted (a learner drilled it in an exercise without flagging it as wrong), or explicitly corrected by a trusted user, such as a teacher. Each level carries different confidence, and the system can make different decisions depending on the validation state: for example, only including explicitly confirmed translations in exercises, while using auto-verified ones for reading assistance where the stakes are lower.

Simplified articles carry a similar state, arrived at differently. Each stored version has a broken flag that keeps it out of what learners are offered, and it is set three ways: an automatic quality check at generation time, an audit tool that finds versions the LLM wrote in the wrong language, and readers themselves, since three reports mark an article broken.¹

What the state is for differs in each case. A meaning’s level is read on every exercise that might use it, and grades how the meaning may be used. A version’s flag is read when a reader asks for a level, and excluding a version is also what causes it to be replaced: the on-demand path calls the LLM only when it finds no usable version at that level. One gates use; the other gates use and triggers repair.

Problem

How can trusted and untrusted LLM-generated data be told apart after it lands in the database, so each is used according to its confidence?

Forces

• Unmarked data is silently trusted. Once stored, LLM output is indistinguishable from human-verified data, so without a marker downstream features treat unverified output as ground truth. (pushes toward tracking trust at all)
• Different consumers can tolerate different confidence. Reading assistance is fine with an unverified translation; a word promoted into drills should be confirmed first. Serving both well means distinguishing levels of trust, not just verified from unverified. (pushes toward a richer trust spectrum)
• Every level is state to maintain. Each level is another transition to model, set on write and update on every validation event, so too fine a spectrum is maintenance burden and false precision. (pushes toward the coarsest spectrum that still supports the decisions)

Solution

Maintain an explicit, queryable validation state for all LLM-generated content in the data model. Never let LLM-generated content silently become trusted data. The validation state may be a simple flag, but more often it is a spectrum or state machine reflecting different levels of trust (e.g., unverified → auto-verified → implicitly accepted → explicitly confirmed by a trusted user; alternatively, one could track the number of users that have validated a given content).

Every stored LLM-generated record carries a trust level, raised by the events above it. Each use reads only the levels it can tolerate: a low-stakes use accepts any level, a high-stakes one only confirmed records.

Consequences

• Each consumer can gate on trust. Exercises use only confirmed pairs, reading assistance can fall back to auto-verified ones, and unverified output never silently becomes ground truth.
• The data model carries an extra state to maintain. It must be set on every write and updated on every validation event, and the right granularity (a flag, a spectrum, or an agreement threshold: N independent users confirming before it counts as trusted) is a domain judgment.
• It pairs with provenance to describe any stored artifact. Where LLM Output Provenance records how an artifact was made, this records whether it has been confirmed; together they answer both questions about a stored artifact.

Known Uses

• Argilla, an open-source platform for annotating and reviewing model-generated data, gives every record an explicit status: a model suggestion starts as pending, becomes a draft and then submitted as someone works on it, and ends up validated or discarded. A suggestion is never treated as correct until a human has moved it to validated.
• Label Studio, another annotation tool, flags each item as ground truth or not and records whether it has been reviewed, so human-verified “gold” data stays clearly separate from unreviewed model predictions.
• Snorkel (Ratner et al., VLDB 2017) attaches probabilistic confidence to programmatically generated labels rather than treating them as ground truth: a confidence spectrum rather than a discrete state machine.

Together the three bracket the granularity this pattern turns on: a multi-state lifecycle (Argilla), a binary gold/not-gold flag (Label Studio), and a probabilistic score (Snorkel).

Note. The examples above are data-labeling platforms; a documented, in-product LLM-output trust-state lifecycle (as opposed to human-annotation state) remains thinly evidenced: one reason we keep this among the less-settled patterns.

Notes

• This pattern complements LLM Output Provenance. Together they answer two essential questions about any piece of LLM-generated data: how was it produced? and has anyone confirmed it’s correct? The right granularity of validation tracking depends on the domain: some systems may need binary (verified/not), others may need multiple validators with agreement thresholds, and others, like Zeeguu, benefit from a trust spectrum that reflects different forms of implicit and explicit user feedback.
• Implicit signals are weaker than explicit ones. A word drilled in exercises without ever being flagged is a positive signal, but a weak one, which is why it sits below a correction from a trusted user in the trust order.

---

← LLM-Checking-LLMDeterministic Postprocessing →

💬 Open an issue about this pattern

1. Article.broken, UserArticleBrokenReport, and available_simplified_versions in the zeeguu/api repository. ↩