LAST COOK · EXAMPLE ONLY
Masala egg wrap
- Changed
- medium-low heat
- Actual time
- 11 min
- Yield
- 3 wraps
“Less chilli worked. Toast 2 min longer.”
eaten1remaining2
Independent verdictVALIDATE FIRST
A cooking-memory experiment
Can cooking keep
its memory?
Cookify is a product concept for remembering what actually happened in the kitchen: the changes, the yield, what remains, and what to try next time.
Concept — no product exists yet. No app, recommendation engine, reminders, accounts, or agent connection is live.
CONCEPT STUDY / 01not product UI
Would this memory be worth recording every time?
01 / THE QUESTION
The unproven problem
The recipe is tidy.
The real cook rarely is.
A cook substitutes, changes heat, loses track of time, makes an unexpected amount, and puts the rest in a container. The useful details often end up in memory, a note, or nowhere.
The current workaround—memory, fridge inspection, notes, timers, or an existing app—may already be good enough. Cookify’s central question is whether linking the real cook to its real output makes repeat meals easier without becoming another bookkeeping chore.
02 / PROPOSED LOOP
One hypothesis, end to end
cook → yield → eat → correct
Each step preserves an actual, not an intention. This flow is proposed for prototype testing; none of it is implemented.
- 01
Run the real cook
Start from a template or prior session, then record only the substitutions, settings, timing, and notes that matter.
- 02
Name the actual yield
Record a household quantity—or mark it unknown. Unknown is not zero and creates no fictional prepared food.
- 03
Resolve what remains
Eating, discarding, and correcting are different outcomes. The proposed balance can never silently go negative.
- 04
Reuse the memory
A repeat cook begins with previous actuals while leaving the old session unchanged.
03 / INTERACTIVE PROTOTYPE
A proposed session model
Follow one meal
through the ledger.
Use the tabs to inspect three illustrative states. They demonstrate the workflow to test; they do not run product logic or save meal data.
ILLUSTRATIVE SCREENSession 04
Cooking now
Masala egg wrap
Started from previous actuals
Eggs3same as last time
Pan heatmedium-lowchanged
Timer08:42local session
Next proposed actionFinish and record what this cook made
ILLUSTRATIVE SCREENYield state
Cook complete
What did this make?
A proposed test of household quantity language.
Integrity boundary“I don’t know” creates a follow-up, not a made-up quantity.
ILLUSTRATIVE SCREENPrepared batch
Current record
2 wraps remain
Last checked after the cook. This is inventory memory, not a food-safety claim.
Try an illustrative outcomeNo meal data is stored by this prototype.
04 / DIFFERENCE TO PROVE
Not another recipe catalogue
The candidate wedge is memory of actuals.
Common centreCookify hypothesis
Ideal recipeWhat changed in this cook
Planned servingsActual yield, including unknown
A leftover labelEat, discard, and correction history
More browsingA few explained next actions
This is a positioning hypothesis, not a “first” claim. Hands-on audits of MealBoard, Paprika, and other current tools are still required.
05 / TRUST BOUNDARIES
Literal status, narrow authority
A food record should admit what it cannot know.
Constraint-aware, not “safe”
A future filter could exclude declared restrictions. It could not know temperature history, spoilage, cross-contamination, or allergen safety.
Actual, planned, and unknown stay separate
A plan is not an eating event. A queued action is not synced. An estimate is not verified. Unknown is not zero.
Private by default
No analytics, cookies, tracking pixels, or remote form submission exist on this local concept page. A future product privacy model is unresolved.
No medical or autonomous action
No diagnosis, treatment, guaranteed nutrition, purchasing, public publishing, shell, database, or unrestricted system access is proposed.
PROPOSED · DEFERREDMCP boundary sketch
Approved agent
READbounded contextDRAFTinert proposalWRITEapproval + receipt
No arbitrary SQL · shell · filesystem · purchase · publish
06 / AGENT CONNECTIONS
Later, only if the direct loop works
MCP is a permission model, not the product.
A future Cookify connection is proposed as narrow, typed tools: bounded reads, labelled drafts, and specific reversible writes with revalidation and receipts.
MCP is deferred. There is no server or integration today, and it should not be built before direct-app data proves useful and permission language is understood.
07 / VALIDATION
What happens next
Try to disprove it
before building it.
The reviewed plan calls for interviews, a lightweight diary, competitor task audits, and an accessible prototype study. The decisive test is whether people can close the loop—and prefer it to their current workaround—without the record becoming a burden.
- 8–12 discovery sessions proposed
- 8 target participants for the critical loop
- 0 critical safety or permission misunderstandings
These are proposed research gates, not achieved results.