Draft for owner review · November 2026. The project’s legal operator, contact address and applicable jurisdiction must be confirmed before a public production launch.

Information we store

Your kitchen contains the food names, quantities, optional measured weights, prices, opened/prepared dates, storage notes, use/discard/undo records, shopping lists, purchase confirmations, meal plans with recipe snapshots, cooking confirmations, favourites, private recipe notes, version-bound feedback and household preferences you enter. Contact forms collect your name, email, interest, message and consent time. Do not enter sensitive personal information in your pantry.

Anonymous browser sessions

A strictly functional HttpOnly cookie identifies your anonymous kitchen for up to 30 days. The server stores a hash of this random token, rather than the token itself. The anonymous kitchen is not a registered account and has no cross-device recovery. Separately, Genspark sign-in can provide access to invited shared kitchens; those never merge anonymous records automatically.

Storage and access

The hosted website stores records in Cloudflare D1. Development previews use a separate local D1 database. Kitchen records are isolated by anonymous session, and contact submissions have no public read endpoint. Project operators with infrastructure access can access stored records.

Optional shared households and reminders

Genspark authenticates shared-kitchen members. The application stores a hashed stable user identifier, membership permissions and hashed invitation email addresses. Names and avatars are not stored or shown publicly. Shared-kitchen members can see and export that kitchen’s food, cooking, purchase, recipe-note, feedback and pilot records. Recipe feedback is not published as public reviews. The owner manages access and deletion. Membership removal stops future access but cannot recall files a member already exported.

Email reminders use your signed-in email, stored only after explicit opt-in. When configured, the email provider receives that address and a minimal kitchen check-in message. An external scheduler triggers dispatch; it does not receive household records. Email-provider acceptance is not proof of inbox delivery. You may disable reminders in account settings or through the unsubscribe link. No email is sent while delivery services are unconfigured.

Receipt processing and pilot consent

Receipt images and raw OCR text are processed in your browser, not uploaded or stored by this app. Only reviewed food entries are submitted. The locally served OCR engine and language model are downloaded to your device. OCR can be inaccurate; verify every field and avoid saving personal receipt information.

Pilot participation is opt-in. The application stores period dates, daily occupancy, meals, unusual-day flags and measurement quality. Pilot exports use a random study code and omit food names, emails and account identifiers, but dates and occupancy can still be identifying when combined with other information. Exports are private by default, not automatically published or shared with researchers. Withdrawal erases pilot enrollment and daily confirmations, not ordinary household food/waste records.

Third-party requests

Fonts are loaded from Google Fonts and images from Genspark’s image proxy. These services receive ordinary network request information. The application does not add advertising trackers or third-party analytics.

Retention and deletion

Session access expires after 30 days; expiration does not automatically delete the underlying records. Settings provides two explicit actions. CLEAR removes pantry, activity, shopping, meal plans and legacy shop-demo records while retaining preferences, session and linked contact messages. DELETE removes those records plus preferences, linked contact messages and the session. Unlinked legacy messages and signups cannot be identified from the session and require an owner request. Complete JSON export includes all session-owned records but no access tokens. Contact records remain pending an owner-approved retention schedule.

Use the contact form to request review or deletion of a submitted message. Automated identity verification and deletion workflows are not implemented in this preview. A production launch must establish an operator contact and retention policy.

Abuse prevention

Contact submissions are rate-limited using a hashed IP-and-hour key. No raw IP address is stored by this application for that purpose. Expired rate-limit keys are cleaned when subsequent accepted submissions arrive.