> ## Content Index
> Fetch the complete content index at: https://machina.mmalc.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Compiling Dinner
- URL: https://machina.mmalc.com/compiling-dinner/
- Published: 2026-10-13T16:18:06.000Z
- Updated: 2026-10-13T16:21:53.000Z
- Description: I asked ChatGPT to make a recipe easier to follow. The conversation became a design for Nara, a system for coordinating a whole meal and the people preparing it — and raised bigger questions about human judgment, dependable software, and what AI should be allowed to decide.
- Author: mmalc Crawford

Apple’s new HomeView promises to turn web recipes into step-by-step cooking instructions, with ingredient tracking and hands-free timers. Having recently spent rather longer than intended thinking about software in the kitchen, that caught my attention. [MacRumors, 13 October 2026](https://www.macrumors.com/2026/10/13/homeview-for-kitchen/?ref=machina.mmalc.com)

But cooking has a habit of exposing questions that a tidy set of instructions leaves unanswered. Will the software warn you today that tomorrow’s dinner needs an overnight soak? Can it reconcile two dishes that need the same oven at different temperatures? What happens when the timer finishes but the beans are still hard?

The announcement doesn’t tell us how HomeView handles those situations, or what its software looks like underneath. They are, however, the kinds of questions that gradually took over a conversation I had started a month earlier, simply because I wanted to cook dal makhani.

What follows is an account of that conversation: how a request for an easier recipe to follow wandered into software architecture, and what the detours revealed about working with AI. The cream was supposed to stay in the refrigerator. Understanding why that proved surprisingly difficult is where the story gets interesting.

---

## It started with dinner

I wanted to make dal makhani. There was no proposed application, no architecture to discover, and certainly no intention of spending the conversation thinking about intermediate representations. My first question to ChatGPT was the difference between dal makhani and tarka dal. I wanted the dal to be the main course, which made the richer, slowly cooked dish attractive. Then came questions about keeping it, finding a recipe with some discernible spice, and making it without a pressure cooker. These were ordinary questions about dinner.

The recipe discussion settled on an adaptation using whole black urad and canned kidney beans, with a Vermicular Musui–Kamado for the long, gentle cooking. Those choices mattered in the modest way equipment and ingredients always matter: already-cooked kidney beans did not need the treatment intended for dried beans, and a particular pot affected how the method would be followed. At this stage, adaptation meant making a recipe suit a kitchen. It did not mean constructing a model of kitchens.

The next request was similarly unambitious: put the recipe on two printable pages, one for ingredients and one for the method. But the method should be more imaginative than a bulleted list. Bullets are easy to lose one’s place in. A separate ingredient list makes the cook keep looking away from the action to find the quantity associated with it. I wanted ingredients visibly connected to the steps that consumed them, perhaps through something like a flowchart.

That “something like” turned out to matter. The conversation looked at precedents for visual recipes, but a recipe could become too pleased with its own diagram. Charming pictures did not necessarily explain the process, and literal flowchart notation could demand more interpretation than it saved. The useful ambition was simpler: distinguish the actions, put them in a sensible temporal order, and show ingredients entering where they were needed. There was no particular reason that achieving this should require an app.

## Recipes are awful programs

Two familiar irritations sharpened the discussion. One was meeting an ingredient halfway through the method that had never appeared in the ingredient list. The other was an instruction that casually assumed an earlier operation had already happened: sauté this, add that, then incorporate something which has apparently been simmering for thirty minutes. The cook is standing there with a pan in progress when the recipe reveals that the necessary past has not occurred.

Here the familiar analogy between recipes and programs acquired a less flattering meaning. I had made this point in programming classes: recipes can illustrate why code demands precision partly because so many recipes are awful programs. The analogy works better once we notice the interpreter. A human cook resolves an ambiguous reference, remembers how much butter has already been used, supplies an omitted preparation, and rearranges instructions before they become impossible. “Meanwhile” can conceal another pan, another burner, and another claim on attention. A knowledgeable reader repairs all this so automatically that the repair work becomes almost invisible.

An ingredient list began to look like declarations, although declarations whose relationship to the rest of the document could not be trusted. “Remaining butter” was a reference to state established elsewhere. Reserved cooking liquid had to survive until a later use. “Until golden” asked for an observation; “ten minutes” offered an estimate that might or might not lead to it. A conventional recipe was better understood as an underspecified source document intended for a knowledgeable, fault-tolerant human interpreter. That formulation did not arrive as a theory imposed on dinner. It named the work we were asking a better presentation to stop quietly offloading onto the cook.

Even then, the next move was about presentation. Once the instructions might be read on a laptop, tablet, or phone, the two-page limit lost its purpose. It had been a printing constraint. There was no need to make a screen dense simply to keep the document short. One conceptual cooking state could occupy one screen, with type large enough to read from across the counter.

The analogy shifted from flowcharts to turn-by-turn navigation. At each point, the cook needed to know what to do, what was needed for it, what completion looked like, and what would follow. DONE WHEN gave observable completion a place of its own. CARRY FORWARD made persistent things explicit: the liquid, mixture, or prepared ingredient that must not disappear when the page changed. NEXT UP could warn that a leisurely interval was about to give way to something requiring a quick response. It was supposed to reduce surprise. If its apparently informational warning actually required preparation, that preparation would still have to be accounted for somewhere.

The strongest attraction was the promise of moving forward with confidence. Once a page was complete, nothing later should reveal an essential action omitted from it. If cooking liquid would be needed later, preserving it belonged before the instruction to move on. “No going back” sounded like a wonderfully clear principle. It would take more discussion to discover that we had packed two different meanings into it.

## Planning the whole meal

A kitchen deck for the dal was commissioned as an experiment in this form. While that work proceeded, the conversation wandered into the possibility of an application, despite my habitual skepticism about solving things by making another app. If these pages could be produced for one recipe, perhaps a system could check an arbitrary recipe for omissions and generate them. More ambitiously, it could combine several recipes into a meal, so the cook would not have to reconcile three separate accounts of what ought to happen next.

That was where the name Nara appeared, with the expansion “Not A Recipe App.” It was a joke with a useful distinction inside it. The emerging interest was in taking recipes as input and working out how to follow them. It was not primarily in collecting or publishing them. The conversation also made excursions into existing products and patents. Those excursions are part of its untidiness, but they did not supply the intellectual route that followed. Dinner kept producing more effective questions.

Combining recipes immediately made equipment and attention difficult to ignore. Two dishes might both want the oven at incompatible temperatures. Two individually sensible methods might demand continuous attention at the same moment. Even one person cooking one dish could leave a process underway while doing something else. The developing vocabulary included food states and transformations because “onion” was no longer enough: whole onion, chopped onion, and cooked onion enabled different actions. Dependencies described what had to exist before an action could begin. Resources described what an action occupied while it happened.

There was a temptation to treat every idle interval as an opportunity to insert another job. But a schedule could be feasible and thoroughly unpleasant. Breathing room before a delicate transition might be more useful than a slightly earlier finish. This led to the idea of cognitive slack, and then to a practical extension: could vegetables be chopped in the morning, or spices assembled before the final rush? Preparing a special meal might reasonably begin days before serving it. A plan that began at 5:40 for dinner at 7:30 had already made a consequential assumption about the available day.

Prep-ahead brought persistence with it. Producing an intermediate state early was useful only if that state could last until it was needed, under appropriate conditions. The conversation called this a holding contract. The term made sense while we were trying to keep track of what a human cook knew: something prepared earlier must be stored, remain suitable, and still be available when the next operation calls for it. Naming it made a hidden dependency discussable. Whether the eventual program needed an object with that name was not yet the question being asked.

## Making room for other cooks

Family participation widened the inquiry again. Could another adult take a task? Could a child do something worthwhile, with suitable preparation and supervision, and feel part of making the meal? “Make the masala” might be a useful instruction for one person but a poor unit of delegation. Measuring its spices could be a separate task; getting those spices down from a high shelf might be a prerequisite performed by someone else. Transformations could contain transformations. What counted as a step depended partly on who was doing it and why.

That exposed a mistake waiting inside the apparently modest phrase “one cook in V1.” The first version could have one available agent without encoding a different kind of recipe. The same underlying work could be decomposed and assigned differently later. Nor should the number of cards in a presentation become a fact about the food. A page boundary was a choice about explanation and attention, not culinary truth. The hierarchy could support different views without insisting that dinner inherently consisted of seventeen steps.

More than one participant also made it obvious that separate screens must not become separate accounts of dinner. One person’s phone, another person’s task sheet, and an overall view would need to refer to one authoritative execution state. A printed sheet would be a snapshot, capable of becoming stale. Looking at a task was different from performing it, and reporting it complete had consequences beyond the screen on which the report was made. The model was becoming richer, though each addition still seemed locally reasonable.

## The overnight surprise

Then we returned to the dal deck. By now there were plenty of abstractions available for explaining what it ought to do. The actual artifact was more revealing. On page 4, the inventory included “60 ml heavy cream (¼ cup).” Spices followed. Page 7 instructed the reader to “Gather the equipment,” including the Musui–Kamado, oven mitts, a kettle, bowls, and utensils. On page 8, under “Soak the urad,” came: “Cover; refrigerate for 8–12 hours.”

If you had taken the introductory sequence as preparation for the work immediately ahead, you could have cream and spices out, the equipment arranged, and the kettle ready before discovering that meaningful cooking resumed tomorrow. The oven mitts had arrived rather early for their appointment.

The inventory page did not literally instruct the cook to remove the cream from the refrigerator. But it led into explicit setup without first establishing what period of work we were preparing for. We had wanted pages that could be followed confidently, one after another. This sequence invited an absurd interpretation precisely when approached in that spirit.

Moving the overnight warning earlier would improve this particular document. It would not settle the underlying confusion. We had treated three different propositions as though they could share the same present tense: this will eventually be required; this is relevant to the next period of human work; this should be physically staged now. The cream belonged in the whole-meal inventory from the beginning. It might also belong in an inventory for the following day. Neither statement meant that it should be beside the cooker at the start of soaking, or even at the start of the following day’s cooking.

The deck had therefore failed as an experiment in decomposition and staging, not just page order. Its visual sequence was clear enough to reveal how poorly it understood the sequence of human engagement. The immediate correction was to take sessions seriously. Tonight’s job was to begin the soak and leave. Tomorrow’s work was something else. A screen saying that there was nothing further to do tonight would convey more useful information than several pages of equipment inventory.

The AI’s response went further: Session should become a first-class part of the model. This sounded plausible. The night-before work and the cooking-day work plainly were different experiences, and the richer vocabulary already included holding between periods of activity. The proposal grouped transformations into sessions and treated the overnight wait as their boundary. For a moment, it seemed we had found the missing structural concept.

## One cook, several things happening

Then concurrency broke that formulation. Ending the evening’s human work did not mean the soak had finished. The urad continued soaking after the person had gone away. The next period of preparation might begin while that process was still in flight. More generally, advancing to another instruction did not mean all earlier processes were complete. Resting, roasting, simmering, chilling, and preheating did not cease to exist when the cook’s attention moved elsewhere.

“Now we seem to be developing a parallel programming compiler,” I observed. But the useful correction was quite concrete: readiness for the next human action depended on that action’s prerequisites and timing, not on the completion of everything grouped into a preceding session. Taking out the cream should relate to its eventual use. It should not require an unrelated background process to have ended merely because of how the screens were grouped. In this dal, the intervening cooking and simmering also mattered; a soak nearing completion was not itself a reason to stage the finishing dairy.

Session survived, but in a weaker and more accurate role: a human-facing period of engagement, not a synchronization barrier. The active work of starting a soak could finish while the passive process continued. Conversely, “passive” did not mean resource-free. The bowl and refrigerator space could remain occupied even while human attention was released. Some processes would need intermittent checks rather than either continuous attention or none. One cook was mostly sequential; the meal was already parallel.

This was not the discovery of a requirement neatly absent from an initial list. We had just made the model more elaborate in a way that could have made it wrong. The correction came from imagining what would still be happening in the kitchen after the person stopped following one set of instructions. A useful abstraction had almost become a false fact about the world.

## You can’t uncook an onion

The Back button then needed similar treatment. It was sensible to promise that moving forward would not conceal a missed prerequisite. It was much less sensible to forbid looking backward. A cook might want to check a quantity, see when something started, or correct a mistaken completion report. With shared state, casual browsing could hardly be allowed to undo another person’s work. With concurrency, returning to an earlier card could not rewind the processes started from it.

“No Back button” became “forward-only execution, reversible navigation.” History could be read; changes to authoritative state would be explicit. Forward-only was a promise about avoiding retrospective ambushes, not a claim that the cook would never revise a report or abandon a plan. Correcting “done” meant acknowledging that the world was different from what had been recorded. It did not mean uncooking an onion.

Error recovery had already supplied a larger version of that problem. Suppose someone set the oven incorrectly and the potatoes were late, or burned. A timer could not tell the system what state they had actually reached. It would need an observation, then a decision about what remained possible. A later dinner, a changed method, or dropping a dish might be preferable to faithfully continuing an obsolete plan. The conversation even reached the joking prospect of abandoning the operation for a delivery from Passage to India. That was not a proposed integration. It was a reminder that loyalty to the original schedule was a poor substitute for dealing with dinner as it now existed.

The dal supplied the quieter version. If the urad was still firm when the estimated time elapsed, the next operation should not inherit a fiction of tenderness. The same applied to onions, whose cooking times in recipes seemed habitually optimistic in my experience. Expected state and observed state had to remain distinguishable. DONE WHEN was no longer merely a helpful caption. It expressed the reason a timer alone could not authorize every transition.

## A coffee maker changes the question

By this point, the explanatory model had accumulated food states, transformations, resources, agents, assignments, sessions, holding contracts, timing profiles, obligations, observations, execution state, and views. Each term had earned its place in a conversation. Taken together, they began to look suspiciously like a small administrative system for an onion.

That was when I introduced Jim Weirich’s Coffee Maker paper. The question was whether this increasingly rich model, useful from a human perspective, was really what would appear at the computer end. I knew enough about software engineering to remember that the example might be relevant. Its object-oriented and UML presentation was not how my mind naturally worked, and I did not find the paper entirely comfortable to follow. But discomfort with its presentation did not prevent recognizing a potentially useful question inside it.

Weirich makes the distinction unusually explicit. His initial diagram describes physical relationships and “may have little to do with the final software configuration.” Later, he explains that understanding the problem influences a software solution without dictating its structure. Solution-oriented classes enter the design, while analysis classes “may mutate or even disappear entirely.” \[1, pp. 3, 6\] The warning was not that understanding the domain had been wasted. It was that the vocabulary used to acquire that understanding had no automatic right to become the vocabulary of the implementation.

We did not need to copy his coffee-maker classes. Indeed, copying them would have missed what made the reference useful. The paper changed the question we were asking of our own accumulated material. Instead of asking how to implement Session, Holding Contract, and the rest, we could ask: what is the smallest machine representation from which the behaviours we cared about could be derived?

## A smaller model of dinner

The answer proposed in the next exchange was strikingly smaller: Facts + Operations + Constraints + Events, with provenance and confidence attached to assertions. This was a candidate representation, not a demonstrated minimum or a completed implementation. Its appeal lay in what no longer needed a separate named mechanism. Many concepts that had made the discussion intelligible could compile into these structures or reappear as views derived from them.

A fact could record that 200 g of urad was dry, that 60 ml of cream was in the refrigerator, or that the Musui was available. An operation described a possible change, with the conditions and resources it required. Starting the soak changed what was in flight; completing the relevant process established a state usable by later cooking. The distinction between those moments preserved what the session formulation had briefly obscured. Cooking the urad could produce both very soft beans and retained cooking liquid. Those outputs mattered more than whether the presentation called the work one step or five.

Constraints carried the relationships that had kept interrupting the conversation. The Musui could not perform incompatible jobs simultaneously. Continuous human attention could not be allocated twice. Cream staging had to precede finishing and occur within a useful window, rather than as an automatic consequence of cream existing. A completion report, start time, or correction could be recorded as an event. Accepted events updated the authoritative account from which the next available actions were derived.

The cream problem now had a much less grand solution than a new taxonomy of kitchen sessions. Its presence in the facts did not command its retrieval. Moving it from the refrigerator to the workstation was a separate operation, governed by its relationship to finishing the dal. The distinction still had to be encoded correctly; four nouns could not guarantee that. But the representation gave us somewhere precise to put it without confusing an inventory with an instruction.

The holding contract could become temporal and state constraints on how an intermediate persisted. Prep-ahead could become a scheduling consequence: an operation was movable because its prerequisites, storage conditions, and subsequent use permitted it. “Morning preparation” would explain that choice to a human. It did not have to be an intrinsic category understood by the execution engine. Likewise, a session could be a grouping of useful human work while background processes crossed its edges undisturbed.

Family participation also looked different at this level. Capabilities, availability, supervision constraints, decomposition, and assignment could express much of what the human description had made sound like a separate model. A helper able to measure spices but unable to reach them introduced an unsatisfied precondition, which another task could satisfy. The meaningful human goal of participation still belonged in the choices made by the system. It did not require a special species of recipe.

An obligation could become a compile-time diagnostic. If “remaining butter” could not be resolved from the available quantities and earlier uses, the plan was missing information it needed. Once resolved, the diagnostic need not travel through dinner as a permanent object. Much of the history used to estimate onion-cooking time could similarly live outside the minimal intermediate representation, or IR. The scheduler needed a usable estimate and its uncertainty; it did not need to carry every past onion around with it.

Nor did recursive decomposition have to mean a runtime full of presentation hierarchies. The compiler could expand work to expose the dependencies, resources, or assignable units needed for this execution. A coarser description could remain available for explanation. The information needed for later reassignment or recompilation would still have to be retained somewhere; making it unnecessary inside a minimal execution representation did not make it unnecessary to the whole system. The smaller proposal was a division of responsibilities, not the disappearance of complexity by decree.

Error recovery became updated facts and replanning, though “became” should not suggest that deciding how to rescue food was suddenly easy. The common mechanism was clearer: accept an observation, revise the state, reconsider feasible operations, and present the remaining choices. The difficult culinary knowledge had to come from somewhere. What disappeared was the need to pretend that recovery occurred in a separate universe from ordinary execution.

## What the human brought to the conversation

Looking back, the Coffee Maker intervention also changed what seemed interesting about the use of AI. It would be misleading to say that AI designed Nara. The conversation contained proposals, extensions, overstatements, counterexamples, corrections, and changes of subject. AI could rapidly carry an idea through several implications and then reconsider them under a new constraint. It could also make a premature abstraction sound settled. The promotion of Session was a useful example of both abilities.

My contribution was not limited to knowing what cooking felt like. It included remembering a software-design example at a moment when the model needed pressure from another direction. I did not need to be comfortable with every class diagram to ask whether its underlying distinction applied. AI’s useful response was to absorb that lens and revisit a substantial body of earlier discussion through it. The reference did not hand over the architecture; it loosened our attachment to the architecture the vocabulary seemed to imply.

There is a related distinction between verification and direction. Outside an area of expertise, a reader may be unable to verify every assertion independently. A read-through can still trigger a “Spidey-sense”: this seems suspiciously convenient; that assumption appears to carry a great deal of weight; these claims do not quite fit together. Such a reaction is not proof of an error. It is a way to choose the next question. The human does not have to possess the answer in advance to direct the inquiry productively, although direction must not be mistaken for having verified the result.

The deck offered something stronger than unease: a concrete counterexample. The Coffee Maker paper offered a conceptual association. The oven mistake offered a hypothetical that forced reality back into a model inclined to trust its own expectations. These contributions were different in kind. What they shared was an active human judgment about where the discussion should go next, rather than passive acceptance of whatever fluent answer had just appeared.

That makes “prompt engineering” a less mysterious activity than its name can suggest. No one-shot incantation extracted the final representation. Examples and context acted as constraints on reasoning. The dal deck required the abstractions to account for an embarrassing sequence. Weirich required us to reconsider whether the nouns in our explanation belonged in the software at all. His paper functioned as a lens rather than a template. Supplying it altered the question being optimized.

Would the conversation have reached the smaller representation without it? There is no controlled counterfactual available. The earlier discussion already contained graphs, constraints, and ideas about compilation. Perhaps it would have arrived there by another route. What the record does show is that introducing the paper was followed by an explicit shift from implementing human concepts to seeking a smaller machine representation. That observed change is interesting enough without claiming to know what would otherwise have happened.

## Putting limits on AI

One further irony had been developing alongside all this. Having used AI extensively to think about the software, we wanted the cooking-time machinery to depend on as little probabilistic interpretation as possible. I recalled a former colleague, an AI expert, warning broadly that programming with AI could have surprising failure conditions. Surprise was precisely what the cooking guidance was supposed to remove. The shorthand became “Compile with AI; execute deterministically,” and, more bluntly, “No hallucinations on the critical path.”

The distinction was not a judgment that AI was useful only before dinner began. Messy recipe prose was an obvious place for interpretation: an ambiguous reference, an old-fashioned expression, or an unstated preparation. A cook’s report could create the same need during execution. “The potatoes are dark and leathery outside but still hard” does not arrive as a tidy state update. AI might suggest candidate interpretations and possible recovery strategies. It might also notice a pattern across meals worth investigating, such as an oven whose behaviour did not match its setting.

Those were proposals. They should not silently change the authoritative execution state. A candidate interpretation had to cross a validation boundary: its form, relevant preconditions, resource claims, and constraints could be checked; uncertain observations or consequential culinary assumptions might require confirmation. A reported observation needed to remain distinguishable from an inferred diagnosis. Provenance answered where an assertion came from. Confidence recorded uncertainty, rather than conferring authority simply because a model supplied an impressive-looking number.

Once an update was accepted, ordinary software could apply the specified transition and recompute what was ready or what needed rescheduling. The stronger formulation was therefore that probabilistic interpretation may recur, while authoritative state transitions remain explicit, validated, and deterministic. Given the accepted state and inputs, the execution rules govern the change. This says nothing magical about physical cooking: the beans remain variable, observations can be mistaken, and a validator only checks what its rules and evidence support. A well-formed invented recipe is still an invented recipe. The boundary must protect meaning as far as the system can establish it, not merely check that a field contains a number.

A later discussion gave this principle a name: **“Probabilistic Advice, Deterministic Authority.”** AI could propose interpretations and actions; permission to act had to come from explicit rules and accepted evidence.

## Where these ideas had appeared before

Only afterward did it become useful to ask where this sat in computer science. The conversation had wandered into recognizable territory. Semantic parsing already translates natural-language expressions into executable logical representations; Cheng and colleagues’ neural semantic parser is a direct example. \[2\] Neuro-symbolic research more broadly combines neural learning with symbolic representation and reasoning, rather than treating the two as mutually exclusive. \[3\] Neither label by itself specifies Nara’s validation boundary, but both supply clear antecedents for separating flexible interpretation from an explicit representation.

The trusted-computing-base idea supplied a different lens. In its security meaning, it identifies the mechanisms relied upon to enforce a policy. \[4\] Applying that reasoning here meant asking which components had to be trusted to enforce the permitted execution transitions. Keeping the LLM outside that enforcement mechanism was a useful design aim. It was not a certificate that everything downstream was correct: the validator, operation definitions, accepted facts, and execution rules still carried their own obligations.

More recent work comes closer to the particular shape. Kambhampati and colleagues’ LLM-Modulo framework combines language models with external model-based verifiers in an iterative exchange, a useful relative of recurring proposals checked outside the model. \[5\] Harikumar’s 2026 PlanCompiler preprint describes typed plans over fixed primitives, static graph and type validation, and compilation of accepted plans into executable Python. Its studied setting is structured data workflows, not cooking, and its checks do not establish culinary truth. \[6\] The resemblance is architectural, not evidence that Nara has been implemented or validated by someone else’s results.

There is no single canonical pattern name established by these sources that means exactly “probabilistic interpretation followed by explicit validation and deterministic execution.” There are several overlapping traditions and newer designs with family resemblances. Nothing in this conversation establishes novelty for the separation. The more interesting fact is how naturally the need for it emerged from trying to make instructions dependable for a person with a pan on the stove.

## Back to dinner

The rich human model had not been a detour to regret. Without it, the smaller representation would have had little to preserve. We had needed words for holding, sessions, attention, and participation before we could see which distinctions were essential and which named objects might disappear. But usefulness in discussion was not a promise of permanence in implementation. Session was useful, then dangerous, then useful again once it stopped claiming to divide the meal’s actual processes.

The same applies to the conversation itself. Its value was not that every answer was correct when first given. It was that proposals remained available to be challenged, and that a kitchen irritation or a half-remembered paper could redirect a growing structure of thought. The outcome was a candidate machine model and a clearer boundary around what the machine should be allowed to trust. Neither had been on the menu at the beginning.

The architecture that emerged is the subject of a separate article, *Probabilistic Advice, Deterministic Authority*, which follows the idea beyond the kitchen.

The cream, meanwhile, could stay in the refrigerator until there was a reason to take it out. That was the sort of thing we had wanted help with all along.

## Sources

\[1\] Jim Weirich. OOAD Design Problem: The Coffee Maker. Supplied file coffee.pdf, 25 pages; last modified 28 December 1999, as recorded on page 25\. “Understanding the Problem,” p. 3, and “Design,” p. 6, are the passages cited. Pagination refers to the supplied PDF.

\[2\] Jianpeng Cheng, Siva Reddy, Vijay Saraswat, and Mirella Lapata. “Learning an Executable Neural Semantic Parser.” Computational Linguistics 45, no. 1 (2019): 59–94\. [https://aclanthology.org/J19-1002/](https://aclanthology.org/J19-1002/?ref=machina.mmalc.com)

\[3\] Artur d’Avila Garcez and Luis C. Lamb. Neurosymbolic AI: The 3rd Wave. arXiv:2012.05876, version 2 (2020). [https://arxiv.org/abs/2012.05876](https://arxiv.org/abs/2012.05876?ref=machina.mmalc.com)

\[4\] NIST Computer Security Resource Center. “Trusted computing base (TCB).” Glossary entry citing CNSSI 4009 and NIST SP 800-12 Rev. 1\. [https://csrc.nist.gov/glossary/term/trusted\_computing\_base](https://csrc.nist.gov/glossary/term/trusted%5Fcomputing%5Fbase?ref=machina.mmalc.com)

\[5\] Subbarao Kambhampati, Karthik Valmeekam, Lin Guan, Mudit Verma, Kaya Stechly, Siddhant Bhambri, Lucas Paul Saldyt, and Anil B Murthy. “Position: LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks.” Proceedings of the 41st International Conference on Machine Learning, PMLR 235 (2024): 22895–22907\. [https://proceedings.mlr.press/v235/kambhampati24a.html](https://proceedings.mlr.press/v235/kambhampati24a.html?ref=machina.mmalc.com)

\[6\] Pranav Harikumar. PlanCompiler: A Deterministic Compilation Architecture for Structured Multi-Step LLM Pipelines. arXiv:2604.13092, version 1 (8 April 2026), preprint. [https://arxiv.org/abs/2604.13092](https://arxiv.org/abs/2604.13092?ref=machina.mmalc.com)