Skip to content

Proof-of-Completion Capture

Evidence-capture tool — instantiates Endpoint Fan-Out Fulfillment

Captures just enough verifiable evidence that an endpoint was actually served — a signature, photo, scan, or confirmation — proportionate to the stakes, so completion is provable without over-collecting.

Proof-of-Completion Capture is the interface that converts "we dispatched it" into "it was received" — a captured, verifiable record, taken at the moment of completion, that the endpoint's success condition was actually met. Its defining tension, and what makes it this mechanism rather than a generic logger, is proportionality: it collects enough evidence to be trustworthy against the stakes, and no more, because at the fan-out edge the thing being captured is often personal, sensitive, or collected from people in vulnerable circumstances. A signature scaled to a parcel, a biometric scaled to a cash grant — the mechanism's whole discipline is matching proof strength to what is genuinely at risk, so completion becomes provable without turning the endpoint into a surveillance point.

Example

A government cash-transfer program needs to know that payments actually reached beneficiaries and were not siphoned off in the last mile. At the point of disbursement, Proof-of-Completion Capture records evidence scaled to the stakes: a fingerprint or a countersigned voucher for a large one-off grant, a simple SMS confirmation for a small routine top-up. That is enough to deter phantom payments and prove receipt — but the program deliberately stops there, because building a rich biometric file on poor households for the sake of a five-dollar transfer would be a data-minimization[1] failure and a real safety risk to the people it serves. Beneficiaries who cannot produce the default proof (no phone, a failed fingerprint match) are offered an alternative, so the evidence requirement never becomes the reason someone is denied a payment they were owed.

The tool's output is a completion record trustworthy enough to audit and light enough not to endanger or exclude the recipient.

How it works

  • Define what proves "done" for this endpoint type — the specific evidence that shows the success condition was met.
  • Capture at the moment of completion, at the endpoint, so the record reflects the actual event rather than a later assertion.
  • Scale the evidence to the stakes — heavier proof for higher-value or higher-risk completions, lighter for routine ones.
  • Store, verify, and minimise — retain only what the stakes justify, for only as long as needed.

The distinguishing move is proportionate capture tied to the success condition: not maximal logging, but the least evidence that still makes completion trustworthy.

Tuning parameters

  • Evidence strength — from a self-attested tap to a third-party biometric. Stronger proof deters fraud but raises friction, cost, and privacy exposure.
  • Proportionality threshold — how stakes map to how much proof, the dial that keeps capture matched to risk rather than uniformly heavy.
  • Capture friction — how much effort proving completion demands of recipient and worker; too much and the proof step itself becomes a barrier to completion.
  • Retention period — how long evidence is kept, trading auditability against standing privacy liability.
  • Verification basis — self-attested versus independently witnessed, trading cost against trustworthiness.

When it helps, and when it misleads

Its strength is making completion auditable and deterring phantom completion — the dispatched-but-never-received gap that provider dashboards miss.

Its failure modes cluster around the capture itself. Heavy proof burdens recipients and frontline workers and can exclude people who cannot produce the required evidence, turning a verification step into an access gate. Captured data is a standing liability, and the classic misuse is capturing maximal evidence "for audit" — surveillance creep that collects far more than the stakes warrant — or its mirror, staff self-attesting completions that never happened. The discipline that keeps it honest is to scale proof to stakes, minimise and time-bound what is retained, and always offer an alternative proof so evidence never becomes the reason a legitimate endpoint goes unserved.

How it implements the components

  • completion_evidence — it produces the verifiable record that the endpoint's success condition was met; that record is this component.
  • endpoint_privacy_and_safety_guardrail — proportionality, minimisation, and alternative-proof paths make the capture safe and non-excluding for the people at the endpoint.

It does not define the success condition it captures evidence against — that is the endpoint success contract set by the Local Partner or Agent Network — nor does it aggregate completion into a metric or report, which is the Endpoint Completion Dashboard.

References

[1] Data minimisation — the principle, codified in data-protection regimes such as the GDPR, that you collect only the personal data actually necessary for a stated purpose and keep it only as long as needed. Applied to proof capture, it is what holds evidence to the least that still makes completion trustworthy, rather than the most an audit could imagine wanting. ↩