Ciarán KeoghCulinary systems

Ideas that are not work yet.

Everything in Work has been built and used. Everything here has not. These are the problems I keep turning over — some are half-designed, some are one good conversation away from being testable, and at least one may be wrong. They are marked so you can tell which is which.

SpeculativeAn idea with a shape. Nothing built.
DesignedWorked through in detail. Not tested with anyone.
PrototypedSomething exists and runs.
01 Speculative

The kitchen that answers back

An NFC tag on every appliance, shelf and rack. Tap it and you get exactly the thing you need at that spot — nothing else.

Every operation I have worked in stores its knowledge somewhere the person who needs it cannot reach. A folder in the office. A shared drive nobody has the login for. A laminated sheet that came off the wall in 2023. Most often, the head chef's memory — which works beautifully until they are on holiday.

The gap is not that the information does not exist. It is that reaching it costs more than guessing does. A cook standing at a combi with a tray in their hands is not going to walk to the office, find a folder and look up a regeneration class. They will make a reasonable guess, and sometimes the guess will be wrong.

So put the answer where the question is asked. A cheap NFC tag on the appliance itself. Tap a phone against it and you get the regeneration standard for that appliance — not the whole manual, not a login screen, not a search box. The five numbers and one prohibition that belong to that machine.

The tag on the walk-in door gives the cooling procedure and the current temperature log. The one on the tray rack gives the assembly spec for what is on it. The one by the sink gives the cleaning schedule and the chemical dilution. The one on the slicer gives the strip-down sequence, and a forty-second video of someone doing it correctly, because some things cannot be written down usefully.

Why a tag rather than an app

  • No aiming. QR codes need a camera, decent light and a steady hand — three things a kitchen at half past twelve does not reliably have. NFC needs proximity and nothing else.
  • No login. The tag opens a page. Nobody has to remember a password for a thing they use twice a week.
  • No power, no maintenance, no battery. A tag costs pennies and has nothing in it to fail.
  • It is physically indexed. You are not searching for the answer, you are standing at it — which removes the step where someone decides the search is not worth it.
  • It survives staff turnover completely. A new starter with a phone has the same access as a chef of ten years.

What would actually make this hard

  • Phones in kitchens. Some operations ban them outright and are right to. A tap-and-read interaction with clean hands is defensible; a cook scrolling at the pass is not, and the design has to make the first easy and the second pointless.
  • Durability. Tags near ovens and in wash-up need to survive heat, steam and cleaning chemicals. Solvable with the right encapsulation, but it is a real cost and a real failure mode.
  • Content ownership. A tag pointing at a stale document is worse than no tag, because it looks authoritative. Every tag needs a named owner and a review date, which is a process problem long before it is a technology one.
  • Device access. Not every kitchen porter has a smartphone, and locked-down company devices may block NFC entirely. A site tablet on a lanyard covers it, but that is a different, less elegant product.
  • It could easily become surveillance. Log every tap and you have a record of who stood where and when. That is exactly the kind of system that gets rejected by the people it is meant to help, and I would not build the logging.

Why I keep coming back to it

Because it inverts the thing that makes knowledge systems fail. Every system I have seen assumes the user will come looking. This one assumes they will not, and puts the answer in the place they are already standing.

It is also the natural end point of the regeneration work. Once several hundred dishes are classified and every appliance has a defined method, the remaining problem is purely delivery — getting the right card to the right pair of hands at the right moment. A tag is the cheapest solution to that I can think of.

What would make it real is one site, one appliance type, twenty tags and three months. That is a small enough experiment that being wrong costs almost nothing.

02 Designed

Encode the generator, not the output

A vinaigrette is not a recipe. It is a ratio. Most culinary knowledge is like this, and almost none of it is stored that way.

Three parts oil to one part acid. From that single ratio you can produce every vinaigrette there has ever been, adjust it for a sharper vinegar, scale it to any volume and teach it in one sentence. Store two hundred vinaigrette recipes instead and you have more data, less understanding, and a document nobody can hold in their head.

The same is true almost everywhere. Baker's percentages generate every bread formula. A brine is a percentage of the water weight. Custard is a ratio of egg to dairy. The major scale is a pattern of whole and half steps that generates all twelve keys — which is what led me into building a music theory tool without being able to play guitar.

Culinary software almost universally stores outputs. Recipe after recipe, each one a fixed instance, none of them connected to the rule that produced it. Scale one and it breaks, because the scaling is arithmetic applied to something that was never linear.

The regeneration classification is the same idea applied to heat. Five classes generated by two questions, rather than several hundred individual instructions. It is a smaller document that covers more ground and, crucially, tells you what to do with a dish nobody wrote a card for.

What this changes in practice

  • The document shrinks and its coverage grows at the same time, which almost nothing else does.
  • New items are handled by rule rather than by exception. A dish with no card is not a dead end — you ask the two questions and you have your answer.
  • It scales honestly. A ratio scaled is still correct; a recipe scaled is a guess with decimals.
  • It teaches. Somebody who learns the generator can reconstruct the outputs. Somebody who learns the outputs has learned only those.

Where it breaks down

  • Not everything has a generator. Some dishes are genuinely arbitrary, and pretending otherwise produces a rule with more exceptions than cases.
  • Finding the generator is expensive. It took several hundred dishes and a lot of arguing to get to five regeneration classes, and that only worked because I had the dishes in front of me.
  • It asks more of the reader. A ratio requires you to think; a recipe does not. In a high-turnover site that is a real cost, which is why the specification level has to be set per site rather than assumed.

Where I would take it next

A recipe system that stores the rule and derives the instance, rather than the other way round. Enter three parts to one and it gives you the vinaigrette at any volume, with the acid adjusted for what you actually have on the shelf.

The Spicy Noodle gestures at this and does not go far enough. The next version should be built on generators from the start, with fixed recipes as the exception rather than the default.

Next

If any of this describes a problem you have

The NFC idea in particular needs one site willing to try twenty tags on one appliance type for three months. If that sounds like your operation, I would like to talk about it.