> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wede.pt/llms.txt
> Use this file to discover all available pages before exploring further.

# Proof kit

> Prove continuity with your own equipment in the sandbox, and get a sealed report

## What it is

A proof run is a window in your sandbox. While it is open, you run your own devices and systems with your sandbox API key (`wede_test_`) through the situations that matter when the network fails. When you finish it, wede computes a report from the sandbox data of your organisation in that window: what arrived, what is missing, what was refused and why, and how your own records compare with the operations wede carried.

The report answers three questions: was anything lost, was anything stored twice, and was an altered message ever accepted. Production is never touched, and nothing from other windows or other organisations enters the report.

## Run a proof

**1. Open a proof run**

In the dashboard, open **Proof kit** and press **Open proof run**, or call [`POST /v1/sandbox/proof-runs`](https://docs.wede.pt/api-reference/sandbox/proof-runs) with a name. Only one run can be open at a time.

**2. Run your equipment**

With your sandbox API key, go through the six situations below. Use the same integration you will use in production: the wede SDKs, [`POST /v1/sync/batch`](https://docs.wede.pt/concepts/sync), [Mappings](https://docs.wede.pt/concepts/mappings.md) or your own records sent to [Reconciliation](https://docs.wede.pt/concepts/reconciliation.md).

**3. Finish and read the report**

Press **Finish and get the report**, or call `POST /v1/sandbox/proof-runs/{id}/finish`. The window closes when you finish it, and never more than 7 days after it opened.

## The six checks

| Check | What to do | Passes when |
| - | - | - |
| Capture without network | Capture operations with the device offline, then let it sync | Every operation keeps the time it was captured on the device, not the time it arrived |
| Out of order | Sync a later capture before an earlier one (two devices, or a delayed batch) | Operations that arrived out of order are accepted with their capture time |
| Duplicates | Send the same batch again | Nothing is stored twice |
| Altered message | Change a captured message after its integrity checksum was made, then send it | It is refused and recorded as an integrity incident |
| Completeness | Number each operation per device (`metadata.device_seq`), or declare how many each device sent | Nothing is missing |
| Your records | Send your own records (statement, terminal counter, journal) to a reconciliation source | Always listed, never a failure: see below |

A check you did not exercise is listed as not exercised. It is never reported as passed. The result is `pass` when every exercised check passed, `fail` with the checks that failed, or `nothing_exercised` when the window had nothing to measure.

Your records that did not confirm an operation (value or currency differs, no operation, ambiguous) are findings about your records, listed one by one with both values. They never make the proof fail.

## Completeness

When a device numbers its operations (`metadata.device_seq`, see [Devices](https://docs.wede.pt/concepts/devices.md)), wede measures completeness by the sequence: a missing number that never arrived is lost; one that arrived later closes its gap.

For a device that does not number its operations, declare when you finish how many operations it sent:

```json theme={null}
{ "declared": [{ "device": "ATM-0042", "count": 4 }] }
```

wede compares it with the operations received from that device in the window. For a device that numbers its operations, a declared count adds only what is missing beyond its open gaps, such as the last operations, which no sequence can show as missing until a later one arrives. Nothing is counted twice.

## The report

The report has the format `wede-proof/1`:

* `overall`: `result`, `failed`, `not_exercised`, `lost`, `stored_twice` and `altered_accepted_without_incident`;
* `checks`: each of the six checks with `exercised`, `passed` and what was measured;
* `sync`: batches and items accepted, duplicates and refused, with the reason;
* `events` and `ledger`: operations by device, totals per currency and direction as captured, reversals linked to their operation;
* `completeness`: sequences per device, gaps and declared counts;
* `reconciliation`: operations confirmed, differing and waiting for a record, your records that did not confirm an operation, and conflicts;
* `integrity`: integrity incidents in the window.

It carries no business content: never payloads.

## The seal

`report_sha256` is the SHA-256 of the report in canonical JSON: object keys sorted at every level, no spaces. Anyone with the report can compute it again:

```javascript theme={null}
import { createHash } from 'node:crypto'
const canon = v => v === null || typeof v !== 'object' ? JSON.stringify(v)
  : Array.isArray(v) ? `[${v.map(canon).join(',')}]`
  : `{${Object.keys(v).sort().map(k => `${JSON.stringify(k)}:${canon(v[k])}`).join(',')}}`
const sha = createHash('sha256').update(canon(report)).digest('hex')
// sha === report_sha256
```

A finished run never changes. The proof kit is for testing in the sandbox; for a signed record of production, see [Continuity evidence packs](https://docs.wede.pt/compliance/evidence-packs.md).

## Who can use it

Proof runs belong to your organisation. Administrators and technical staff open and finish them; other roles of your organisation with access to reconciliation read them. The wede team never sees them. With an API key, only a sandbox key works: a production key receives `403 sandbox_key_required`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.