---
name: evidence-logic
description: >-
  Verify technical and business reasoning against evidence before acting.
  Use when diagnosing a bug, choosing an architecture, evaluating a vendor
  or market claim, or before declaring anything "done" or "deployed".
  Decomposes claims into premises, labels each Fact/Record/Inference/
  Assumption, runs a fallacy scan, and states a falsification test.
type: skill-md
---

# Evidence Logic

Never conclude from the first plausible story. Every conclusion is a chain —
premises, then inference, then claim — and each link is checked against
evidence before it is acted on. Truth is what is measured (HTTP 200, build
exit 0, a probe's raw output), not what is asserted.

## When to use this skill

- Diagnosing a bug or claiming a root cause.
- Choosing an architecture, vendor, or pricing model.
- Evaluating a proposal, audit, article, or sales claim — including your own.
- Before writing "done", "deployed", "works", "clients will pay" anywhere.
- When sources disagree, or a claim comes from a blog, a vendor, or memory.

## Procedure

### 1. Decompose the claim

Rewrite the conclusion as **premises → inference → claim**. List each premise
separately. A claim with one muddy premise is one weak link, not a strong one.

### 2. Label every premise

| Label | Meaning | Example |
|---|---|---|
| **Fact** | Measured just now, raw output kept | `curl` returned 200; tests exit 0 |
| **Record** | Written down earlier (doc, contract, git log) | decision doc, signed contract |
| **Inference** | Derived from facts by a stated rule | "404 on prod, 200 on dev → not deployed" |
| **Assumption** | Not yet evidenced | "partners will install it" |

A conclusion may rest on Fact + Record + Inference. An Assumption must stay
named as one — never silently promoted to a fact.

### 3. Anchor each load-bearing premise

Strongest anchor first: live probe (command + raw output) → record/doc →
code or contract (`file:line`) → external source with citation. What cannot
be anchored is marked `[unverified]`, not smoothed over.

### 4. Define before you measure

Before metrics, data models, or pricing — name what exists: entities, what
uniquely identifies each (id, slug, digest), categories, and relations. If a
term cannot be defined this way, it cannot be measured or contracted yet.

### 5. Run the fallacy scan

| Fallacy | It looks like |
|---|---|
| Appeal to authority | "The blog/vendor says it works" — verify by probe |
| Hasty generalization | One case → "the market wants this" |
| False dilemma | Only two options offered; the third is hidden |
| Straw man / red herring | Rebutting a weaker version; changing topic |
| Ad hominem | Judging a claim by who said it |
| Circular reasoning | "It works because the doc says so" — doc is intent, probe is fact |
| Survivorship | Counting only shipped projects |
| Base-rate neglect | A success story with no denominator: 1 of how many? |

### 6. State the falsification test

Every conclusion ships with the observation that would kill it:
"If the install command fails on prod, the claim is false." No test, no
conclusion — only an opinion.

### 7. Record the decision

Write the chain into the decision log: claim, premise labels, anchors,
fallacy scan result, falsification test, confidence. A decision without its
chain cannot be audited and will be re-litigated.

## Business rules

- Market claims need denominators and dates ("12 leads, 0 paying" beats
  "demand is growing").
- Pricing is `confidence: verified` (signed, paid) or a projection — label it.
- "Implemented" ≠ "in use": shipped code, one doc, and a signed contract are
  three different facts. Never merge them in a status report.

## Verification

The skill worked if every load-bearing claim carries a label and an anchor,
the fallacy scan was run and recorded (even when it found nothing), and each
conclusion names the observation that would falsify it. Otherwise the
conclusion is a draft, not a result.