# Claim Assessment Types in claude-obsidian: A Complete Guide to the Five Canonical Values

> Explore the five claim assessment types in claude-obsidian: accepted, provisional, contested, unsupported, and deprecated. Learn how this Obsidian plugin standardizes claim evaluation for your knowledge base.

- Repository: [Agrici.Daniel/claude-obsidian](https://github.com/AgriciDaniel/claude-obsidian)
- Tags: how-to-guide
- Published: 2026-08-26

---

**The claude-obsidian repository defines five canonical claim assessment types—`accepted`, `provisional`, `contested`, `unsupported`, and `deprecated`—stored in the `CLAIM_ASSESSMENTS` constant within [`claude_obsidian/ledgers.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/ledgers.py) to standardize how claims are evaluated in the knowledge base.**

The **claim assessment** field serves as the core mechanism for expressing confidence and verification status within claude-obsidian's claim ledger system. These standardized values ensure consistent evaluation across the knowledge base, driving automated validation logic and determining what evidence standards apply to each claim. Understanding these five assessment types is essential for correctly configuring claim ledgers and ensuring data integrity in the `AgriciDaniel/claude-obsidian` repository.

## The Five Claim Assessment Types Defined in [`claude_obsidian/ledgers.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/ledgers.py)

The canonical assessment values reside in the `CLAIM_ASSESSMENTS` set defined at lines 41-47 of **[`claude_obsidian/ledgers.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/ledgers.py)**. Each type represents a specific state of evidentiary support and determines the validation rules enforced by the system.

### Accepted

An **`accepted`** claim indicates the claim has been fully verified and is considered true by the system. This assessment triggers the strictest validation requirements: the claim must possess a valid review date and, for high-risk claims, require at least two independent sources of support. The `accepted` status represents the highest confidence level in the knowledge base.

### Provisional

The **`provisional`** assessment marks a claim as tentatively accepted but potentially lacking full supporting evidence. This status accommodates claims awaiting further verification or those supported by preliminary evidence that does not yet meet the threshold for full acceptance. Claims with this assessment can remain in the ledger while investigators gather additional supporting materials.

### Contested

A **`contested`** claim signals active dispute, indicating the presence of contradictory evidence or unresolved questions about validity. This assessment requires either explicit contradictory evidence references or detailed adjudication notes explaining the nature of the dispute. The `contested` status prevents the claim from being treated as verified while preserving it for further investigation.

### Unsupported

The **`unsupported`** assessment applies to claims lacking sufficient evidence to warrant even provisional acceptance. This status distinguishes claims that have been evaluated and found wanting from those simply awaiting review. Claims marked `unsupported` remain in the ledger but carry explicit flags indicating their evidentiary deficiencies.

### Deprecated

**`Deprecated`** claims are no longer considered valid, typically because newer information has superseded them or subsequent review has revealed fundamental flaws. This assessment preserves the claim in the historical record while explicitly marking it as obsolete, preventing its use in current reasoning chains.

## How Assessment Types Drive Validation Logic

The assessment value directly determines the validation checks executed by the **`validate_claim_ledger`** function. Each type triggers specific constraint verification routines that enforce data quality standards across the claim ledger.

For **accepted** claims, the validator checks for fresh supporting evidence, correct review dates, and multiple independent sources when the claim carries high-risk designation. **Contested** claims require either evidence entries with `"relation": "contradicts"` or a populated `notes` field containing adjudication details. The validator treats **provisional**, **unsupported**, and **deprecated** assessments with appropriate relaxed or archival logic, ensuring each status maintains its semantic meaning.

The validation logic references the `CLAIM_ASSESSMENTS` constant to ensure only canonical values appear in the ledger, rejecting any claim records containing non-standard assessment strings.

## Implementing Claim Assessments in Practice

When constructing claim records in `claude_obsidian`, the assessment field must contain exactly one of the five canonical string values. Below are practical implementations demonstrating the `accepted` and `contested` assessments.

```python

# Example of a minimal claim record using the "accepted" assessment

{
    "claims": {
        "clm-abc123": {
            "text": "The Earth orbits the Sun.",
            "risk": "normal",
            "assessment": "accepted",
            "confidence": "high",
            "location": {"path": "wiki/astronomy.md", "anchor": "Solar System"},
            "reviewed_at": "2024-09-15",
            "evidence": [
                {"source_id": "src-001", "relation": "supports"},
                {"source_id": "src-002", "relation": "supports"},
            ],
        }
    },
    "schema": "claude-obsidian.claim-ledger.v1",
    "generated_at": "2024-09-16T12:00:00Z",
}

```

```python

# Example of a claim marked as "contested" with contradictory evidence

{
    "claims": {
        "clm-def456": {
            "text": "Vaccines cause autism.",
            "risk": "high",
            "assessment": "contested",
            "confidence": "low",
            "location": {"path": "wiki/health.md", "anchor": "Vaccines"},
            "reviewed_at": "2024-09-10",
            "evidence": [
                {"source_id": "src-010", "relation": "supports"},
                {"source_id": "src-011", "relation": "contradicts"},
            ],
            "notes": "Multiple high‑quality studies contradict the claim."
        }
    },
    "schema": "claude-obsidian.claim-ledger.v1",
    "generated_at": "2024-09-11T08:30:00Z",
}

```

The JSON schema definitions in **[`claude_obsidian/contracts.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/contracts.py)** formalize these structures, while **[`tests/test_ledgers.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/tests/test_ledgers.py)** and **[`tests/test_lint_engine.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/tests/test_lint_engine.py)** provide comprehensive test coverage ensuring each assessment type behaves correctly during validation and linting operations.

## Summary

- **Five canonical values**: The `CLAIM_ASSESSMENTS` constant in [`claude_obsidian/ledgers.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/ledgers.py) defines `accepted`, `provisional`, `contested`, `unsupported`, and `deprecated` as the only valid assessment types.
- **Validation-driven**: Each assessment type triggers specific logic in `validate_claim_ledger`, enforcing evidence standards appropriate to the claim's status.
- **Accepted requires rigor**: High-risk `accepted` claims require multiple independent sources and valid review dates.
- **Contested requires documentation**: Disputed claims must reference contradictory evidence or include explanatory notes.
- **Schema enforcement**: The claim ledger schema in [`contracts.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/contracts.py) ensures type safety, while test suites verify behavioral consistency.

## Frequently Asked Questions

### What file contains the claim assessment type definitions in claude-obsidian?

The **[`claude_obsidian/ledgers.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/ledgers.py)** file contains the canonical definitions, specifically the `CLAIM_ASSESSMENTS` set at lines 41-47. This constant enumerates the five permissible string values: `accepted`, `provisional`, `contested`, `unsupported`, and `deprecated`.

### What validation rules apply to accepted claims versus contested claims?

**Accepted** claims trigger validation checks for review dates and, when marked high-risk, require at least two independent supporting sources. **Contested** claims require either contradictory evidence entries or explicit adjudication notes explaining the dispute, ensuring disputed claims cannot be mistaken for verified knowledge.

### Can I create custom assessment types beyond the five canonical values?

No. The `validate_claim_ledger` function strictly enforces membership in the `CLAIM_ASSESSMENTS` set. Any claim record containing non-standard assessment strings will fail validation. To extend the system, you must modify the constant in [`claude_obsidian/ledgers.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/ledgers.py) and update the corresponding JSON schema in [`claude_obsidian/contracts.py`](https://github.com/AgriciDaniel/claude-obsidian/blob/main/claude_obsidian/contracts.py).

### How does the deprecated assessment differ from unsupported?

**Deprecated** indicates a claim was previously valid but has been superseded by newer information, preserving it as historical context. **Unsupported** indicates the claim never met evidentiary standards for acceptance. While both signal low confidence, `deprecated` implies prior acceptance, whereas `unsupported` implies the claim failed initial evaluation.