evidence-reconciliation git:20260830.0196be9A

Immutable. This exact content is served forever at /api/v1/blob/6c3b487ef7dad0c9.

---
name: evidence-reconciliation
description: Resolve conflicting, stale, or ambiguous sources before answering, revising plans, or making claims; use when accuracy depends on distinguishing current fact, governing authority, inference, and recommendation.
---

# Evidence Reconciliation

Use this skill when a conclusion, plan, document update, vendor comparison, operational rule, price, timeline, limit, or capability depends on more than one source—or when a user asks for unusually high factual integrity.

Do not use it for simple writing that has no factual or source-conflict component.

## Outcome

Produce a conclusion or revision that is traceable to the right source, preserves the existing capability floor, and never turns a related fact into a different fact merely because it supports an appealing answer.

## First classify the request

Before answering or editing, separate each material statement into one of these states:

- **Governing current rule** — the newest controlling instruction, contract, configuration, or approved decision.
- **Verified current fact** — directly observed account, runtime, checkout, source, or official documentation state.
- **Historical source** — prior plan, old document, archived observation, or superseded draft.
- **Source-supported interpretation** — a conclusion reasonably drawn from evidence.
- **Recommendation** — a proposed choice, explicitly not yet adopted.
- **Assumption or unknown** — a gap that needs a source, test, or a visible decision.

Never collapse these categories. A trial credit is not automatically a send limit; a vendor marketing capacity is not a chosen operating capacity; a minimum is not a recommended target; an old plan is not the current rule.

For any capacity or time claim, record separately: approved population, active lead/contact ceiling, message or credit allowance, healthy daily sender capacity, selected operating path, trial lifecycle, and the clock anchor (trial start, purchase, delivery, warmup start, or first live send). A conclusion is valid only when every limiting dimension and prerequisite supports it.

## Establish authority before synthesis

For every material conflict, identify:

1. the exact claim at issue;
2. the source that controls it today;
3. the source that conflicts or appears to conflict;
4. whether the difference is factual, temporal, semantic, or a decision change;
5. the least disruptive correction.

Use this default authority order unless the project defines another:

1. the user's current explicit decision;
2. newest applicable governing source;
3. verified current live/account state;
4. primary official documentation;
5. validated historical plans and research;
6. secondary commentary, creator content, remembered context, and marketing claims.

If a newer source is less authoritative, do not silently let recency overrule control.

When a governing source contains both operating policy and dated vendor facts, follow the policy as controlling but recheck the dated vendor fact at an official or authenticated current surface before calling it current.

## Build a claim ledger for consequential work

For a wide, high-stakes, or document-revision task, read [the contradiction protocol](references/contradiction-protocol.md) completely and maintain a compact ledger before drafting. The ledger must cover every claim that can change scope, money, capacity, ownership, safety, timeline, outcome, or truthfulness.

Each claim ends in exactly one state: confirmed, conflict unresolved, superseded, proposed, conditional, or unknown. Do not write final language until each material claim has a state.

For commercial capacity, outbound, trial, or deadline claims, also maintain the capacity/timeline sub-ledger in the protocol. Do not combine mutually exclusive operating paths (for example, fresh versus pre-warmed) into one timeline or capacity statement.

## Answer without compliance bias

Do not agree just because the user proposes a number, interpretation, or solution. Do not reject it reflexively either.

When the user's statement is correct, say why and cite the controlling evidence. When it is inaccurate, state the exact correction plainly, including whether the error came from a prior assistant response. When evidence is mixed, state the controlling rule and the decision needed to change it.

Use short, direct wording:

> The current rule is X. Y is a different metric/source. Z can be proposed later, but it is not established yet.

Never use vague agreement such as “yes, exactly” when the evidence supports only part of the statement.

## Revision discipline

Before revising a standing plan, policy, or operating library:

1. inventory every source document and its unique job;
2. map source sections to destination sections;
3. preserve all useful detail unless a deliberate removal is recorded as superseded, duplicated, wrong, or out of scope;
4. keep legal, quick-reference, template, and long-form operating documents separate when they have separate use cases;
5. label future architecture as future rather than silently importing it into current policy;
6. recheck drift-prone vendor facts at the current official/account surface before including them as operating rules.

Do not summarize a complete source into a shorter “final” document unless the user explicitly asks for compression. A rewrite must preserve or improve the source's useful decision content, not merely restate its conclusion.

## Challenge pass

Before concluding, run these checks:

- **Semantic:** Did two similar numbers or terms refer to different things?
- **Temporal:** Is an older fact being used as current state?
- **Authority:** Did a noncontrolling source override the governing one?
- **Scope:** Did a proposed future capability become a current promise?
- **Economics:** Did a vendor price, usage charge, labor cost, or client-owned cost disappear?
- **Lifecycle/timeline:** Does the claimed date name its start point and survive trial expiry, conversion/upgrade behavior, delivery, authentication, warmup, ramp, and reply-operation gates?
- **Ownership:** Did the revision weaken client control, isolation, recovery, or handoff?
- **Completeness:** Did any document, source, exception, or user requirement get silently dropped?
- **Truth:** Does every strong claim have direct evidence at the claimed verification layer?

Repair the issue or label it unresolved. Do not move forward by averaging the conflicting claims.

## Report with a source map

For material work, report:

1. the controlling conclusion;
2. exact corrections and their source class;
3. documents/systems changed or intentionally retained;
4. unverified or approval-gated items;
5. the source-to-output mapping for any rewritten library.

Do not claim a source was read, a condition was verified, or a conflict was resolved unless that happened.