Skip to main content

​
Validation

Validation is how the LLMO protocol distinguishes truth from noise. Without validation, a truth pack is just another JSON file. With validation, it is a verifiable artifact.

​
Source weighting

Not all sources are equal. Source weighting assigns relative trust based on:
FactorDescription
AuthorityIs this source the canonical origin for this type of claim?
ProximityHow close is the source to the actual fact? First-party > third-party > aggregator
RecencyWhen did the source last confirm or update this claim?
ConsistencyDoes this source contradict itself or other authoritative sources?
Track recordHas this source been historically reliable?

​
Source hierarchy

  1. Regulatory and legal filings (SEC, patent offices, government registries)
  2. First-party authoritative (company documentation, official APIs, signed statements)
  3. Third-party verified (auditors, certification bodies, accredited reviewers)
  4. Third-party unverified (press, analyst reports, community references)
  5. Aggregated and derived (directories, review sites, knowledge graph fragments)
  6. Unattributed (scraped content, anonymous mentions, synthetic sources)
Higher-tier sources override lower-tier sources in conflict resolution.

​
Claim validation

A claim is validated by checking:
  1. Source support: Does at least one source of adequate trust tier support this claim?
  2. Consistency: Do multiple sources agree, or are there conflicts?
  3. Freshness: Is the claim within its declared freshness window?
  4. Supersession: Has this claim been superseded by a newer authoritative claim?
  5. Verification level: Is the stated verification level (self-attested, third-party, signed) accurate?
A claim that passes all checks is valid. A claim that fails any check is flagged with the specific failure reason.

​
Freshness checks

Every claim has a freshness window: the period during which the claim is considered current without re-verification. Freshness logic:
  • If now - last_verified < freshness_window: claim is fresh
  • If now - last_verified >= freshness_window and no supersession exists: claim is stale (flag for re-verification)
  • If a superseding claim exists: original claim is superseded regardless of freshness
Stale claims are not automatically invalid. They are flagged. The consuming system decides whether to use a stale claim based on its risk tier and error bound.

​
Conflict resolution

When multiple sources make contradictory claims about the same entity attribute:
  1. Apply source hierarchy. Higher-tier source prevails.
  2. If same tier, prefer the more recent source.
  3. If same tier and same recency, flag as ambiguous and escalate.
  4. Log all conflicting claims and their sources for audit.
Conflict resolution must never silently discard a claim. All conflicts are logged.

​
Supersession rules

Supersession is directional and constrained:
  • A superseding claim must come from a source of equal or greater authority than the claim it replaces
  • Supersession creates an ordered chain: claim-v1 -> claim-v2 -> claim-v3
  • The supersession log records the old claim, the new claim, the reason, and the timestamp
  • Superseded claims are retained in the record (not deleted) for audit and historical reference

​
Ambiguity handling

Some claims are genuinely ambiguous. The validation system handles this by:
  • Marking the claim status as ambiguous
  • Recording the nature of the ambiguity (conflicting sources, vague original statement, context-dependent truth)
  • Routing ambiguous claims to human review in orchestration workflows
  • Never resolving ambiguity by choosing the more fluent or confident-sounding claim

​
Machine-readable validation output

Validation results are structured and machine-readable: 
{
  "claim_id": "claim-001",
  "validation_status": "valid",
  "checks": {
    "source_support": "pass",
    "consistency": "pass",
    "freshness": "pass",
    "supersession": "pass",
    "verification_level": "pass"
  },
  "validated_at": "2026-04-02T00:00:00Z"
}
For failed validations: 
{
  "claim_id": "claim-004",
  "validation_status": "failed",
  "checks": {
    "source_support": "pass",
    "consistency": "fail",
    "freshness": "pass",
    "supersession": "pass",
    "verification_level": "pass"
  },
  "failure_details": {
    "consistency": "Source-002 and Source-005 conflict on this claim. Source-002 (trust_tier: authoritative) states 'yes'. Source-005 (trust_tier: reliable) states 'no'."
  },
  "validated_at": "2026-04-02T00:00:00Z"
}