Evidence is the record your application submits to show what happened during fulfillment. Paybond stores the signed evidence binding alongside the intent so a release, refund, or dispute decision can be reviewed later.
What evidence should contain
- The factual outcome of the work.
- The fields your completion rule (predicate) or managed policy expects.
- Stable identifiers that help operators or partners trace the action later.
- Optional artifact hashes for receipts, logs, PDFs, or other supporting records stored outside Paybond.
Evidence submission checklist
- Evidence is accepted only within the authenticated tenant.
- Each submission targets one
intent_id. - The payee signs the canonical evidence binding (
EvidenceSignV1,version = 2, bincode 2 standard encoding). - Retries should reuse the same idempotency key for the same request body.
Upgrade Paybond Kit to a release that matches Harbor's bincode 2 wire format before submitting evidence against an updated Harbor deployment. Signatures from older Kit releases (EvidenceSignV1.version = 1) are rejected after cutover.
Artifact handling
Artifacts are referenced by hash, typically BLAKE3 hex strings. Harbor stores the hashes and the signed binding, while the raw bytes stay in your own storage or document systems.
This keeps the settlement record portable without turning Harbor into a general-purpose file store.
Retry safety
Harbor supports idempotency-key on the relevant write routes. Reusing a key with the same request body is safe. Reusing it with different content returns 409 Conflict.
Design tips
- Model evidence as structured facts rather than free-form prose whenever possible.
- Keep large files out of band and reference them by hash.
- Include only the fields you are willing to preserve for audit, support, or dispute review.
- Use the same evidence shape consistently so downstream review remains predictable.
See also
- Disputes and evidence evaluation — predicate evaluation path, dispute vs chargeback, and when predicate failure is a business outcome