> ## Documentation Index
> Fetch the complete documentation index at: https://wuweism.com/llms.txt
> Use this file to discover all available pages before exploring further.
# The Claim Ledger
> An auditable record of every hypothesis, observation, and counterfactual produced in Wu-Weism — with confidence scores, uncertainty labels, and provenance.
Scientific and legal work demands that claims be traceable: where did this conclusion come from, how confident is it, and what would it take to falsify it? The **Claim Ledger** is Wu-Weism's answer to that requirement.
Every hypothesis, observation, and counterfactual generated in Wu-Weism is automatically written to the Claim Ledger with a full provenance record — the session it came from, the feature that produced it, its confidence score, and whether it passed the epistemic gates designed to filter out unfalsifiable or redundant claims.
## What a claim is
A **claim** is a discrete, structured assertion produced during an analysis session. Claims are not informal notes — they are machine-readable records with specific fields that make them queryable, filterable, and auditable.
### Claim kinds
Wu-Weism produces three kinds of claims:
| Kind | Description | Produced by |
| ---------------- | ----------------------------------------------------------------- | --------------------------------------------- |
| `hypothesis` | A causal proposition that could in principle be tested | Causal Chat, Hybrid Synthesis |
| `observation` | A factual statement grounded in available evidence | All features |
| `counterfactual` | A claim about what would have happened under a different scenario | Causal Chat (intervene mode), Legal Causation |
### What a claim record contains
Each claim in the ledger includes the following fields:
| Field | Type | Description |
| ------------------- | ------ | --------------------------------------------------------------- |
| `id` | string | Unique identifier for the claim |
| `claim_kind` | string | `hypothesis`, `observation`, or `counterfactual` |
| `source_feature` | string | Which feature generated the claim: `chat`, `hybrid`, or `legal` |
| `status` | string | Current state of the claim in review |
| `confidence_score` | number | Numeric confidence from 0 to 1 |
| `uncertainty_label` | string | Human-readable uncertainty: `low`, `medium`, or `high` |
| `session_id` | string | The session during which the claim was produced |
| `trace_id` | string | Links the claim to a counterfactual trace, if applicable |
| `created_at` | string | ISO 8601 timestamp of claim creation |
### Uncertainty labels
The `uncertainty_label` translates the numeric confidence score into an actionable interpretation:
* **`low`** — The claim is well-supported. The causal structure is identified, the adjustment set is valid, and the evidence base is strong.
* **`medium`** — The claim rests on assumptions that are plausible but not fully verified. Treat with care before acting on it.
* **`high`** — Significant uncertainty remains. The claim may reflect an unidentifiable causal effect, missing confounders, or sparse evidence.
Uncertainty labels do not mean a claim is wrong. A `high` uncertainty counterfactual may still be the best available answer — it tells you how much epistemic confidence to place in it.
## How claims are created
You do not create claims manually. Wu-Weism generates them automatically at the end of each analysis:
Finish a **Causal Chat** session, run a **Hybrid Synthesis** analysis, or complete a **Legal Causation** analysis. Claims are not created mid-session — they are finalized when the session produces a governed output.
Before the claim is written to the ledger, two gates evaluate it:
* **Falsifiability Gate**: Is the claim testable in principle? Claims that cannot be falsified by any possible observation are flagged or rejected.
* **Novelty Gate**: Does the claim add something not already in the ledger? Redundant restatements of existing claims are identified and linked rather than duplicated.
The claim is written to the Claim Ledger with its full provenance record, including the SCM that was loaded, the session and trace IDs, and the gate decisions.
If the claim was generated with reference to source documents — uploaded PDFs, cited literature, or prior claims — those sources are linked to the claim record.
## Gate decisions
Every claim record shows whether it passed the two epistemic gates:
**Falsifiability Gate** — A claim passes if it can, in principle, be refuted by evidence. Unfalsifiable claims (e.g., "consciousness cannot be explained") are flagged with a gate decision of `failed` and a note explaining why the claim cannot be tested.
**Novelty Gate** — A claim passes if it is not a restatement of an existing ledger entry. If a similar claim exists, the new claim is linked to the prior entry and marked as a `duplicate` or `extension`.
Gate decisions are visible in the ledger and accessible via the API. They are part of the claim's permanent record.
## Viewing your claims
Navigate to **/claims** in the workbench to see the full ledger for your account. The claims view shows:
* All claims across all sessions, sorted by most recent
* Filter controls for source feature, session, and claim kind
* The confidence score and uncertainty label for each claim
* Gate decisions and any flags applied during evaluation
* Links to the originating session and, for counterfactuals, the counterfactual trace
## Evidence links
Each claim references the sources that support it. Evidence links connect a claim to:
* **Source documents**: PDFs or papers that informed the response
* **Prior claims**: Existing ledger entries that the new claim builds on or contradicts
* **Counterfactual traces**: The deterministic computation record for any `do(·)` intervention
Evidence links make it possible to trace a claim back through the chain of reasoning to the original inputs.
## Filtering claims via the API
The Claim Ledger is fully accessible via the API for programmatic auditing and integration.
```bash theme={null}
GET /api/claims
```
**Query parameters:**
The number of claims to return. Accepts an integer between `1` and `100`. Defaults to `20`.
```bash theme={null}
GET /api/claims?limit=50
```
Filter claims by the feature that produced them. Accepted values: `chat`, `hybrid`, `legal`.
```bash theme={null}
GET /api/claims?sourceFeature=legal
```
Return only claims from a specific session. Use the session ID from the workbench or the causal chat API response.
```bash theme={null}
GET /api/claims?sessionId=sess_abc123
```
Return the claim associated with a specific counterfactual trace. Each trace produces at most one counterfactual claim.
```bash theme={null}
GET /api/claims?traceId=trace_xyz789
```
### Example response
```json theme={null}
{
"claims": [
{
"id": "clm_01j8kq3p",
"claim_kind": "counterfactual",
"source_feature": "chat",
"status": "active",
"confidence_score": 0.74,
"uncertainty_label": "medium",
"session_id": "sess_abc123",
"trace_id": "trace_xyz789",
"created_at": "2026-03-14T09:22:11Z"
}
],
"total": 1,
"limit": 20,
"offset": 0
}
```
Use `traceId` filtering to cross-reference a claim with its counterfactual trace. The trace record contains the intervention details, adjustment set, and identifiability result that produced the claim. See [Counterfactual reasoning](/concepts/counterfactuals) for the trace schema.
## Related concepts
How claim kinds map to the three rungs of causal reasoning.
The traces that back counterfactual claims in the ledger.
The domain models that constrain what claims can be made.