# Delivery proof model

Separate the trigger, affected cohort, expected notification, possible action, and impact.

Canonical URL: https://ekko.zone/docs/delivery-proof-model/
Reviewed: 2026-09-06
Availability: Product concepts and scope; not a release-availability statement

A useful notification helps someone understand a position, opportunity, or problem in time to decide what to do. This model gives a Team five fields for examining a missed opportunity or explaining a notification result.

## Trigger: what happened?

The onchain or product state that made a user or operator message relevant. Record the observed change and when it occurred.

## Affected cohort: who needed to know?

The wallets, accounts, users, or operators within the chosen monitoring scope. State that scope explicitly rather than implying universal coverage.

## Expected notification: what message should exist?

The useful information the person needed, together with the intended channel, pacing, suppression, approval, and provenance context. This model does not assert that every channel or control is available in a particular release.

## Counterfactual action: what might a response have changed?

The decision the person could have made with timely information, including deciding not to act. This is a hypothesis to investigate, not proof that a notification caused an outcome. Ekko may prepare an action; the person controls its execution.

## Impact: what did silence cost?

Assess the missed user benefit or operational risk when a relevant message was absent, suppressed incorrectly, or late. Separate observed evidence from estimated effects. More messages and clicks alone do not demonstrate value.

<h2 id="evaluation-path">Current public evaluation path</h2>

Visit the [hosted app](https://app.ekko.zone/), read the [integration overview](https://ekko.zone/docs/integrations/), or [contact support](mailto:support@ekko.zone?subject=Ekko%20delivery%20proof) for rollout-specific help. Ask which results can be verified for the release you are evaluating. A rendered demo is not evidence of successful live delivery.