Backstory: what the founder set out to do

Status: working document, 2026-10-04. Source: prompts/SESSION-PROMPTS.md (85 messages, 3–4 October 2026) read in full, against the repository at commit 83bfb91. Every claim here points to a message number (M1…M85) or a file. Where the founder's intent and a repository document disagree, this file says so instead of choosing quietly.

1. The founder's intentions, in their own terms #

1.1 Where it started (M1–M3) #

The session opened with a plan for fifi.cooking, a family collection of Egyptian home recipes: build a worldwide encyclopedia of cuisines, the top recipes of almost every country, filtered so that nothing haram (alcohol, pork, blood) gets in, with banner images, 24-language translations, nutrition and cost estimates, and searchable on web, phone, tablet and TV. The founder is a builder who ships: scripts, repos, pushes in chunks of fifty.

1.2 The turn to robots (M4–M11) #

Within forty minutes the question changed: how do cooking robots cook, and is there any standard, index or governance they share? There wasn't. The founder's response was not to build another product but to make fifi.cooking, then a new repo, the centralized, free index that any robot anywhere can use, with a standard that is "our invention" (M6), open source for every manufacturer (M7), with API specs, schemas, a CLI, GraphQL, and interoperability with other robots, humans, smart fridges and stoves, ordering and delivery, safety and notification systems (M9). The repo was created and named in minutes (M10), the domain registered the same evening (M13, M15).

1.3 The three goals (M23, M24, M47, M48) #

Stated plainly, and repeated:

1. Eliminate world hunger. "Everything in it should aim toward utilizing all platforms, intelligence, robots, ecosystem to … allow humans to eat, and to eat even if they cannot afford it," and let world food organizations run "a massive mega global workflow that allows all humans to be fed" (M23). Robots and the standard in "poor and areas of famine" (M47).
2. Make the world healthier. "The right organic food with the right and correct nutrition values that matches the age, health, weight, gender and other needs of individuals … the right amounts cooked the right way at the right time to the right person with the exact cost with the least amount of waste" (M24). Health organizations should "rely on this system, extend it and report on it" to change eating habits, "specially for poorer nations" (M48).
3. Put robots to work for people. Robots that command the directory and reason like a cook (M17), that work in teams (M17), in homes, restaurants, weddings, factories and relief kitchens (M46), and that learn and relearn "at quantum robot/AI speeds" (M47).

1.4 What the founder kept repeating #

1.5 Values and fears visible between the lines #

• Dignity in the household. The brainstorm asks about elderly and disabled family members, babies, sick people fed in their rooms, prayer, holding hands, music (M39). The robot is meant to fit the family, not the other way round.
• Safety first, always. Stove left on, smoke detectors, pets knocking things over, kids asking to disable guards, medication timing, allergies (M31, M33, M44, M50).
• Fear of waste more than fear of cost: waste of food, energy, time, plastic, trips (M45).
• Fear of being copied or blocked: patents (M14, M16), name recognition (M12).
• Impatience with hype in the other direction: the critiques were requested, not resisted, and the honest reframing of hunger was accepted (the action plan was approved and committed, M78).

1.6 Ideas the founder had that the repository does not yet reflect #

These come straight from the brainstorm and are the richest unbuilt material:

1. A machine-readable registry of household and robot context (the "enhanced payload", M31–M41). The repo describes 15 facet families in prose (PROTOCOL.md §4.1) and has a generic Facet object, but no vocab/facets.json, no per-facet privacy default, no derived-constraint transforms, and only five facets in the worked example.
2. Fleets: restaurants, weddings, donation kitchens and food factories (M46). Mentioned, never modelled or simulated.
3. The farm side of the loop: what to grow, when and where, from forward demand (M45). The city simulator models farms; the standard has no farm, harvest or demand-signal document.
4. Service and serving: reminders before food is ready, table setting, cultural eating style, serving to rooms, lunch boxes, packing for donation (M31). The recipe format has a service section; nothing executes it.
5. The robot's own standing: warranty, subscriptions, recalls, unpaid services that may stop (M31, M41). Partly in self facets; no credential or subscription model beyond prose.
6. Public figures and influencers who might care (M74). Deliberately not in the repo, because naming people reads as endorsement. See the tension in §4.6.
7. The WFP/WHO evaluation draft (M72–M73) and the stakeholder tracker (M74, M76): ACTION-PLAN.md refers to both ("the concept note", "the stakeholder tracker"), but neither file is in the repository. They need to be recreated or the references removed.
8. Twenty-four languages (M1): the standard carries en and ar; the other 22 fifi languages are planned as sidecars.
9. Recipes at scale: the 1,881 fifi recipes and the World Cuisines project (M1, M11). Zero have been converted; the index holds one example recipe.

2. How the idea evolved #

Decisions already made, and why (from the repository):

• Core small, profiles optional (CORE.md, concern C8): a device should implement Cookwala in a week. The Mission, market and relief layers stay experimental until two independent implementations exist.
• "Safety is local" (C5, C14): no safety function depends on the network or any message.
• Refusal instead of guessing (C9): sensor ladders; no oil thermometer means no deep frying.
• Temperatures in °C only, money as decimal strings (C10).
• Honest hunger claims (C4): "Cookwala contributes; it doesn't claim to end hunger alone".
• People without robots first (C20): the Humanitarian Profile works by SMS and CSV.
• The one-liner changed from "the world's first and largest robot cooking recipes index and CLI" to "the open standard for cooking safely: people, kitchens and robots" (STRATEGY.md §3). **The founder chose the first wording (M10); the strategy proposed the second and the website uses it. README.md and PLAN.md still open with the first.** This needs the founder's explicit confirmation (see §4.5).

3. Gap list: every intention mapped to the repository #

Legend: Done (exists and works), Spec (designed and documented, not implemented), Partial, Missing. The last column says what this engagement does about it.

3.1 Standard, index and tools #

3.2 The enhanced payload (M31–M42) #

3.3 Providers, trust, decisions, degraded operation (M43–M57) #

3.4 Simulators, critiques, presentation (M60–M84) #

4. Tensions, and how this engagement resolves them #

4.1 A full picture for providers vs privacy and dignity (M42 vs PROTOCOL.md §6) #

The founder wants the request to carry everything so providers "respond with full awareness". The same data (absences, children, health, religion, income) is a burglary plan and a profiling tool. Resolution: the full picture lives at home, in a local Household Context Profile. Providers receive derived constraints ("deliver 17:00–18:00 to the door", "no grapefruit"), never the facts behind them. Every facet type carries a default privacy class; secret for absences, children and layouts; sensitive for health, religion and culture; nothing leaves without consent, and everything is erasable. The founder's "rich, moderate or poor" becomes an owner-set budget posture, never inferred and never shared. No behavioural scoring of family members is ever produced. This is RFC-0001.

4.2 Ending hunger vs honest claims (M23 vs C4) #

Hunger is driven by poverty, conflict, climate and prices. Cookwala's contribution is real but partial. Resolution: the mission stays plainly stated ("help end hunger"), and the site shows the contribution path with evidence: kilograms rescued, meals served, nutrition pass rate, cost per meal, time to claim, safety incidents, each labelled measured, modelled or assumed. Cookwala never claims to end hunger alone. The world simulator already says where robots are not (Sub-Saharan Africa, South Asia) and that rescue covers a small share.

4.3 One standard vs "like bees" (M6 vs M49) #

A single index run by one company contradicts decentralization. Resolution: Cookwala is a narrow-waist standard plus a federation: anyone can run a catalog, a registry or a hub; cookwala.ai is one node; recalls and incidents spread through signed feeds; event logs use witnessed checkpoints so no party can rewrite history. Governance moves to a neutral foundation. RFC-0006 makes this concrete.

4.4 Robots vs jobs and dignity #

Resolution: prioritize uses that help people who cannot cook for themselves (older people, disabled people, care homes, community and disaster kitchens); humans can always cook; robots augment kitchen staff and never replace the cook's name on a recipe; a labour seat on the steering committee; the site names the new roles that appear (recipe engineers, food-robot technicians, certifiers) without promising numbers.

4.5 "The world's first and largest robot cooking recipes index and CLI" (M10) vs the new one-liner #

The founder named the project. The strategy retired the phrase because "largest" is false with one recipe and "first" needs verification. Resolution proposed: keep the founder's sentence as the origin and the goal ("started as…", "aims to become…") and lead with "the open standard for cooking safely: people, kitchens and robots". README.md and PLAN.md are updated to match the site. This needs the founder's confirmation.

4.6 Naming people and organizations (M74) vs no impersonation #

Listing CEOs, influencers or agencies on the site reads as endorsement. Resolution: organizations appear only as sources or as "who we want to work with", labelled as not contacted; no person is named as a supporter; the founder may keep a private outreach list outside the public repo.

4.7 "Blockchain signature" (M43) vs a transparency log #

Core 0.2 uses hash-chained event logs with witnessed checkpoints, which gives tamper evidence without a blockchain; public-chain anchoring is optional. A blockchain holding household data would conflict with erasure. Founder decision needed (open since PROTOCOL.md §15): transparency log only, or also optional public anchoring of checkpoint heads. The architecture review recommends the first for now.

4.8 Halal-only origin (M1) vs every cuisine #

fifi.cooking's content is halal-checked; the standard must serve every cuisine and every diet. Resolution: the standard is diet-neutral; dietary rules are rule packs that a household, program or venue turns on; the halal pack ships first because the corpus and the region call for it; no recipe is excluded from the standard, only filtered where a pack is active.

4.9 Personal nutrition for health conditions (M24) vs medical-device rules #

Resolution: general nutrition guidance only (sodium, free sugars, fats, fruit and vegetables, portion), with care variants for children, older people and pregnancy as food-safety rules; condition-specific diets only with a clinician's targets, entered locally; every rule pack names its reviewer and review status. Health content is written to be reviewable by dietitians and food-safety officers, and says what it does not do.

4.10 Demand signals for cities and farms (M45) vs competition law (C7) #

Resolution: signals are aggregated, delayed and never carry prices between competitors; the farm RFC designs the aggregation, and the site marks the whole area "next, after counsel review".

4.11 Everything at once (the brainstorm) vs adoption #

Resolution: the order stays "useful before robots": food banks, kitchens and device makers first; the Mission profile remains the long-term architecture, visible and experimental.

5. What needs the founder's own voice (TODOs carried into the work) #

1. The origin story, in their words (one paragraph for the home page and the whitepaper).
2. Confirmation of the one-liner change (§4.5).
3. Rights per fifi collection before any bulk conversion (EXPORT-FIFI.md §2).
4. Transparency log vs public anchoring (§4.7).
5. Whether a private outreach list of people and organizations should exist, and where.
6. Pricing of any future services (certification, hub software, dataset licences).
7. Partner names: none are used until a partner agrees in writing.