Critical Validation Rules for Accepted Claims in Claude-Obsidian

Accepted claims in Claude-Obsidian must carry a valid review timestamp, fresh non-synthetic evidence, and—when flagged as high-risk—independent corroboration from at least two distinct sources.

The claude-obsidian repository implements a structured knowledge management system that stores factual assertions as claims within wiki/meta/ledgers/claim-ledger.json. When a claim’s assessment field is set to "accepted", the validate_claim_ledger function in claude_obsidian/ledgers.py enforces seven strict invariants to ensure only verified, traceable, and well-supported statements enter the knowledge graph.

Temporal Validation Requirements

Before any claim achieves accepted status, the validator verifies that temporal metadata is present and logically consistent.

Reviewed-At Date Presence

The most fundamental check occurs at lines 31-39 of validate_claim_ledger, where the code asserts that every accepted claim contains a non-null ISO-8601 reviewed_at date:

if assessment == "accepted" and reviewed_date is None:
    # ValidationError: accepted claims require explicit review timestamps

This requirement ensures that accepted claims represent deliberate human review rather than automated ingestion.

Future Date Prevention

The validation routine prevents forward-dated reviews at lines 40-45. The reviewed_at timestamp must not exceed the current audit date (as_of), protecting the ledger against claims that appear reviewed but lack actual completed verification:

if reviewed_date is not None and reviewed_date > today:
    # ValidationError: review date cannot be in the future

Evidence Quality Standards

Claims reach accepted status only when backed by current, trustworthy source material referenced in wiki/meta/ledgers/source-ledger.json.

Fresh Active Support Requirement

At lines 106-112 and 121-126, the validator constructs a fresh_support set and mandates that accepted claims maintain at least one supporting source meeting four criteria:

• Active status in the source ledger
• Non-synthetic origin (not AI-generated or simulated)
• Non-stale data (within validity window)
• Dated on or before the claim’s review date

fresh_support = [e for e in evidence if e.is_active and not e.is_synthetic 
                 and e.date <= reviewed_at and not e.is_stale]

if assessment == "accepted" and not fresh_support:
    # ValidationError: accepted claims require fresh supporting evidence

Dual-Source Rule for High-Risk Claims

High-risk assertions face heightened scrutiny. Lines 128-132 enforce that any accepted claim with risk: "high" must demonstrate support from at least two independent groups:

if assessment == "accepted" and risk == "high" and _independent_group_count(fresh_support) < 2:
    # ValidationError: high-risk acceptance requires two independent sources

Independence is determined by differing origins, content hashes, or explicitly declared independence keys within the source metadata.

Contradiction and Documentation Policies

The validation system requires transparency when evidence conflicts.

Mandatory Justification for Conflicting Evidence

When fresh contradictory sources exist alongside an accepted assessment, lines 134-149 require non-empty notes fields or a contested reassessment:

fresh_contradictions = [e for e in evidence if e.relation == "contradicts" and e.is_fresh]

if assessment == "accepted" and fresh_contradictions and not (notes and len(notes.strip()) > 0):
    # ValidationError: accepted claims with contradictions require explanatory notes

This prevents silent suppression of disconfirming evidence without human-written justification.

Structural Integrity Checks

Evidence Record Schema Validation

Before applying business logic, lines 60-76 validate that each evidence entry contains:

• A valid source_id matching the src- identifier pattern via _safe_ledger_id checks
• A relation field of "supports", "contradicts", or "context"

Invalid entries are rejected during the initial parsing phase before the critical validation rules for accepted claims are applied.

Vault Path and Anchor Verification

Location integrity is enforced in two stages. Lines 68-80 validate that location.path is a canonical vault-relative wiki path, while lines 84-99 verify that any specified anchor exists within the target markdown file. The validator raises errors if the page is missing or the anchor cannot be resolved, ensuring every accepted claim traces back to concrete vault content.

Implementation Example

A valid high-risk claim record demonstrating compliance with these critical validation rules appears as follows:

{
  "schema": "claude-obsidian.claim-ledger.v1",
  "generated_at": "2024-10-01T12:00:00Z",
  "claims": {
    "clm-001": {
      "text": "Carbon-dioxide levels exceeded 420 ppm in 2023.",
      "risk": "high",
      "assessment": "accepted",
      "confidence": "high",
      "location": {
        "path": "wiki/climate/2023.md",
        "anchor": "CO2-levels"
      },
      "reviewed_at": "2024-09-15",
      "notes": "Reviewed by climate-science team; contradictory industry report noted but deemed less reliable.",
      "evidence": [
        {
          "source_id": "src-3a5b9c7d8e9f0a1b2c3d",
          "relation": "supports"
        },
        {
          "source_id": "src-4e5f6a7b8c9d0e1f2g3h",
          "relation": "supports"
        }
      ]
    }
  }
}

Omitting the second source would trigger the high-risk independence violation:

claims.clm-001.assessment: high-risk acceptance requires two independent sources

Summary

• Review timestamps are mandatory: Accepted claims must include a non-null reviewed_at date that does not exceed the audit date.
• Fresh evidence is required: All supporting sources must be active, non-synthetic, and current as of the review date.
• High-risk claims need dual corroboration: Two independent sources are required when risk is set to "high".
• Contradictions require documentation: Fresh contradictory evidence necessitates explanatory notes or contested status.
• Locations must resolve: Paths must be canonical vault paths with verifiable anchors.

Frequently Asked Questions

What happens if an accepted claim lacks a reviewed_at date?

The validate_claim_ledger function in claude_obsidian/ledgers.py raises a validation error at lines 31-39. Accepted claims must carry an explicit ISO-8601 timestamp indicating when human review occurred.

How does claude-obsidian define "independent" sources for high-risk claims?

Independence is calculated by the _independent_group_count helper function, which groups sources by distinct origins, content hashes, or declared independence keys. Two sources sharing the same origin or hash count as a single group, failing the high-risk validation at lines 128-132.

Can synthetic sources support an accepted claim?

No. According to the fresh_support construction logic at lines 106-112, accepted claims explicitly require non-synthetic evidence. Sources flagged as synthetic are excluded from the fresh support set, causing validation failure if no valid alternatives exist.

What file contains the validation logic for accepted claims?

The primary validation routine resides in claude_obsidian/ledgers.py, specifically within the validate_claim_ledger function. This file references wiki/meta/ledgers/source-ledger.json for source metadata and validates entries in wiki/meta/ledgers/claim-ledger.json.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}