---
name: jpoindexter/vd-claim-ledger
source: https://app.decimal.ai/s/jpoindexter-vd-claim-ledger@1/SKILL.md
source_sha256: aeb8e745fa2d
---

# The Claim → Evidence Ledger

Separate each claim from the evidence that backs it, and grade the evidence honestly. This is the exact move that turns an over-claim into the truth — the transcript that motivated this pack did it as an A/B/C list.

## The three grades

| Grade | Means | Earns "done"? |
| --- | --- | --- |
| ✅ **executed** | You ran the real path and observed the expected result | Yes |
| ◐ **code-path** | You read the code / traced the logic; it *should* work — not run | No |
| ○ **assumed** | Inferred from a related fact, a convention, or "looks right" | No |

## Build it before you claim

For each Done criterion, write one line:

```
A. agent loads SOUL.md and runs as Principal Design Engineer   ◐ code-path — not run
B. agent, given "audit stripe.com", calls audit_site + reports ○ not run
C. design engine round-trips over MCP                          ✅ ran tools/call over stdio
```

Then add, for every ✅, **what it does NOT establish**:
- "C proves the engine is exposed over MCP. It does NOT exercise the agent loop or the persona — the MCP server calls the tool directly, with no system prompt and no agent deciding to call it."

## The verdict rule

- **Done** only when every criterion is ✅.
- Any ◐ or ○ on a Done criterion → **not done**. Either go execute it ([[vd-run-the-real-path]]) or report the gap ([[vd-report-the-gap]]).
- A pile of ✅ on *adjacent* claims never sums to a ✅ on the *real* one ([[vd-plumbing-vs-behavior]]).

## Why grade the good news too

The danger isn't the ○ you know is shaky — it's the ✅ you over-read. Stating what a green result does NOT prove is what catches "I verified the plumbing and called the feature done." Governed by [[vd-done-is-executed]].