Why Food-Waste Apps Need Outcome Evidence, Not Just Purchase History

Receipt-powered products often move too quickly from recognition to interpretation. A line item can establish that a product was probably acquired at a time and price. It does not establish who used it, how much remained, whether it was stored safely, whether it was shared, or whether it became waste. When a product silently fills those gaps, personalized guidance becomes a story built on unobserved household behavior.

The sharper model separates five layers: acquisition evidence, a bounded inventory episode, outcome evidence, intervention exposure, and evaluation. The operating invariant is simple: no item may be counted as consumed, wasted, or saved unless the corresponding outcome is observed or explicitly reported at the required confidence. Unknown is a valid state, not a defect to hide in an optimistic metric.

Normalize each useful receipt line into an acquisition record such as {acquisition_id, household_id, product_class, quantity_range, acquired_at, price, parse_confidence, source_ref}. Then open one or more inventory episodes with {episode_id, acquisition_id, estimated_amount, storage_context, opened_at, review_after, state, confidence}. Keep the source image and uncertain fields separate from corrected household truth so later extraction changes do not rewrite what the user accepted.

An episode can move through unconfirmed, available, partly_used, and a terminal outcome such as consumed, discarded, composted, shared, returned, or unknown_closed. These states should not pretend to reconstruct every meal. They exist only long enough to support a useful decision, capture a proportionate outcome, and retire stale assumptions.

WasteLess provides public portfolio context for a receipt-scanning concept that turns grocery purchases into personalized waste-reduction guidance and household savings feedback. Public project context: portfolio projects. This is a product-architecture example, not a claim about deployed households, measured waste reduction, savings, or production accuracy.

The existing receipt-intelligence lesson focuses on extraction uncertainty: preserving the difference between a captured line, a model interpretation, and an accepted correction. The outcome-evidence problem begins after that boundary. Even a perfectly recognized purchase is not proof of waste. A trustworthy product must therefore preserve uncertainty across the full journey from acquisition to household outcome and make its advice useful before the final outcome is known.

A recommendation should create an intervention receipt such as {intervention_id, episode_ids, policy_version, trigger, message_class, delivered_at, viewed_at, action_taken, expires_at}. This distinguishes a reminder generated by the system from one the household actually saw, and a viewed suggestion from an action. Examples include freeze-soon guidance, a use-first list, portioning advice, or a recipe pattern tied to items whose evidence is still current.

Do not label every later consumed item as waste prevented. The household may have planned to use it anyway, another person may have acted independently, or the inventory estimate may have been wrong. Evaluate observable product steps first: confirmation rate, correction rate, intervention relevance, action acceptance, outcome-report completion, and the share of episodes closed as unknown. Stronger causal claims need an explicit study design, appropriate comparison, and enough coverage to survive missing reports.

Household tracking fails when every useful insight demands continuous manual logging. Use progressive evidence: accept receipt capture as acquisition evidence, ask for correction only when extraction uncertainty changes advice, request a one-tap outcome near the decision window, and reserve detail for users who want it. Confidence and consequence should control interruption. A doubtful product class may justify a confirmation; a minor quantity difference may not.

The system should also support negative feedback such as 'not mine,' 'already used,' 'never remind me about this class,' and 'the quantity is wrong.' These responses are not engagement failures; they are evidence that prevents repeated bad advice. A quiet workflow with fewer but better-timed prompts can be more useful than a complete-looking pantry built from guesses.

Receipts can reveal location, routines, health-related purchases, family composition, and financial pressure. Keep raw images only as long as the product purpose requires, minimize merchant and payment data, isolate household identity from aggregate analysis, and let users delete or correct episodes without losing the explanation of derived metrics. Do not infer dietary, medical, religious, or household attributes merely because a product class appears on a receipt.

Aggregate reporting needs coverage labels. A household waste estimate should separate observed disposal, user-reported outcomes, modeled ranges, and unknown episodes. Population views should state participation and reporting bias rather than presenting app users as the whole community. The system can help households notice patterns without claiming omniscience about what happened behind a kitchen door.

Common failures include counting every expired estimate as discarded, generating reminders from corrected or already-consumed items, merging two purchases into one episode, treating composting as equivalent to avoidable disposal, and claiming financial savings from list price rather than verified changed behavior. Another failure is over-collection: demanding detailed meal logs that cost more attention than the guidance returns.

The evidence model adds state, expiry, reconciliation, and evaluation work. A simple shopping-list product may not need it. Use it when the product claims personalized reduction, savings, or household learning. When an extraction or policy error is found, mark affected episodes and interventions, recompute derived views from versioned evidence, withdraw unsupported claims, and keep the correction trace instead of silently replacing history.

Start with one high-frequency product class and one decision window. Define the minimum acquisition fields, the outcome states the household can report in one tap, the expiry rule for unknown evidence, and the single recommendation whose exposure you can verify. Run the diagnostic before expanding the catalog or claiming savings; this gives product and engineering teams a concrete next action without requiring a complete pantry model.

Test the workflow with eight synthetic cases: a correctly parsed item eaten without opening the app; a duplicate receipt; one purchase split across freezing and consumption; a user correction after a reminder; an item shared outside the household; composted scraps; an episode with no follow-up; and a recommendation viewed after the item was already gone. Inspect state, confidence, prompt timing, metric treatment, and recovery for each case.

The workflow passes only if acquisition never becomes an outcome by default, duplicate evidence does not inflate inventory, partial outcomes remain representable, stale interventions are suppressed, unknown episodes stay out of savings claims, and corrections propagate without erasing their provenance. If the team cannot explain which evidence supports a waste or savings number, which assumptions remain, and what the product actually influenced, it has receipt analytics but not a trustworthy food-waste feedback loop.