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.
Example
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.
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).
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.