Proof kit

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

Open a proof run

In the dashboard, open Proof kit and press Open proof run, or call POST /v1/sandbox/proof-runs with a name. Only one run can be open at a time.

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, Mappings or your own records sent to Reconciliation.

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), 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:

{ "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:

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.

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.

Introduction

Core Concepts

Examples by Vertical

What it is

Run a proof

The six checks

Completeness

The report

The seal

Who can use it

​What it is

​Run a proof

​The six checks

​Completeness

​The report

​The seal

​Who can use it

What it is

Run a proof

The six checks

Completeness

The report

The seal

Who can use it