# The Skeptic's Guide to DamageBDD Evidence

Ask what ran, what the record proves, which party controls the keys and what still needs testing.

Canonical HTML: <https://damagebdd.com/articles/skeptics_guide.html>



<a id="ask-for-a-reproducible-claim"></a>

## Ask for a reproducible claim

DamageBDD starts with a behaviour someone can describe, execute and inspect.
Its value is in reducing ambiguity about a specific result. A skeptic should
ask for the scenario, source revision, target, inputs and report, then examine
whether those assertions cover the requirement.


<a id="check-the-boundary-of-each-record"></a>

## Check the boundary of each record

-   A test reports observations for its execution; it can miss behaviour outside its scope.
-   A hash checks byte identity against a trusted reference; storage availability is separate.
-   A signature identifies a signing key; it does not prove the statement is correct.
-   A retrieved record needs provenance and relevance checks before supporting an answer.
-   A payment needs its own receipt and reconciliation, even when a test passes.


<a id="evaluate-one-useful-workflow"></a>

## Evaluate one useful workflow

Reproduce a known failure, make a change and inspect the new result. Compare
the effort and review quality with the team's existing process. Keep the
specification, both reports and any remaining failures together.

The [platform map](../platform.md) explains the wider stack; the
[capability matrix](features_current.md) records implementation and evidence.
The [solutions guides](../solutions/index.md) propose first demonstrations.
Claims of scale, security or automatic settlement need their own results.