evidence-reconciliation git:20260905.f7824baA

Immutable. This exact content is served forever at /api/v1/blob/403217bde59a381c.

---
name: evidence-reconciliation
description: "Resolve stale facts and authority conflicts."
---

# Evidence Reconciliation

Use this skill when a conclusion, plan, document update, vendor comparison, operational rule, price, timeline, limit, or capability depends on a material source conflict, authority ambiguity, stale state or mismatched scope—or when unusually high factual integrity calls for that reconciliation. Multiple consistent sources alone do not require a separate workflow.

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 capacity or time claims, record the relevant units, population/system boundary, limiting dimensions, operating assumptions and clock anchor. Apply sender, allowance, trial and warmup dimensions only to commercial/outbound claims, using the capacity/timeline sub-ledger in the protocol. A conclusion must satisfy every applicable limit and prerequisite.

## 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.

For operating decisions and prescribed behavior, use this default authority order unless the project defines another. For empirical truth, direct evidence, method, scope and freshness control; user or document authority cannot make a false claim true:

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.

A rewrite must preserve or improve useful decision content, exceptions and evidence. Shorter wording is acceptable when it loses no required substance; record source-to-destination mapping for substantive relocation. Do not replace requested complete content with an unrequested summary.

## 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.

Instruction authority sets objectives and operating rules; it does not establish empirical truth. Evaluate factual claims using direct evidence, method, source quality, scope and freshness even when a claim comes from the user or a governing file.