Recognition is not acceptance: designing the reward boundary

Keep the three decisions separate

A recognition decision answers what the system thinks it sees. An acceptance event answers whether the selected physical process completed. Reward authorisation answers whether the project rules permit a ledger change. These are different questions. A green screen or a successful animation cannot substitute for the second or third decision.

Make retries explicit

For a proposed integration, include a unique event identifier, a device identifier and a versioned event type. The receiving service should be able to recognise a duplicate before changing the ledger. Test replay, timeout and out-of-order delivery independently. A local browser guard is useful for a demo but is not a production security boundary.

Design the uncertain path

Do not force an uncertain or interrupted session to look successful. Give the participant a clear state and the operator a reconciliation path. Keep equipment safety logic outside the website. The proposed software contract should consume verified events; it must not bypass safety interlocks or directly operate a mechanism.

Use a repeatable acceptance test

Prepare tests for a normal return, unsupported item, duplicate event and interrupted connection. Record expected UI, event and ledger outcomes separately. The Go demo on this site illustrates the state sequence only; it does not communicate with equipment or issue a real reward.

Put the reward after the confirmed event

Model four visible states: item presented, classification pending, physical intake confirmed and downstream programme response. A rejected item must not inherit a success message from an earlier recognition result. Give the confirmed event a stable ID so a retry cannot create a second reward. If an external ledger is unavailable, show a truthful pending or unavailable state rather than a fabricated credit.

Examine the moment a return fails

Imagine the camera identifies an eligible bottle, but the intake cannot take it because storage is unavailable. The visitor still has the bottle. That is a rejection or interrupted attempt, not a completed return, whatever the classification score said. The equipment record and screen need to agree about this outcome. If the visitor walks away with the item, an external ledger must not have already issued a benefit on the strength of recognition alone.

The reverse case also matters: a physical return completes, then the connection to the programme fails. The event needs a stable identity and a defined recovery path. The visitor message should state what is known and what remains pending. Keep a support route for disputes; do not ask the visitor to infer a financial outcome from a machine animation.

Test each boundary with different evidence

Use sample packaging to test classification, a physical return test to prove intake, and a ledger test to prove benefit authorisation. Record the expected and observed result at each boundary. This makes a failed trial actionable: the team can see whether to change packaging rules, hardware configuration, interface delivery or programme policy. One broad “pass” for the whole journey hides the fault when something goes wrong.

Use the reward reconciliation guide to define the programme side, then discuss event integration with the system owners.