The first question every operator asks when we show them the cabinet is some version of: how does it know? The tray goes in looking raw, comes out looking ready, and nothing touched it. There was no cook at the pass. There was no thermocouple probe reading the food's core temperature. Something decided it was done.
That something is a classification pipeline built on visual signal processing. What follows is a reasonably complete account of how it works, written for people who will deploy the cabinet, not people who build computer vision systems for a living.
What a camera sees that a timer cannot
A timer tells you that time has passed. It says nothing about what happened to the food during that time. A chicken breast loaded at 7 celsius into a cabinet that has been on for a service cycle is not the same as a chicken breast loaded at -2 celsius from a delivery that ran long. The physics differ. The doneness outcome at a fixed elapsed time differs.
A camera with a trained classification model sees something more directly relevant: the food's surface state right now. Colour channels, texture gradient, moisture expression. These are outputs of the cooking process that carry doneness information without requiring a sensor physically inserted into the food.
We are not saying timers are wrong. We use a timer as the second system in a two-system architecture. The point is that a timer alone is not sufficient to classify doneness, particularly when input conditions vary, which they do every shift in every operational environment Cook-e is designed for.
The three signals the model reads
When a tray is inside the cabinet and the vision module captures a frame, the classification model is processing three main signal channels simultaneously.
Colour channel analysis
Raw protein has a characteristic hue range. Cooked protein has a different one. The shift from translucent pink to opaque pale or from pale to golden depends on food type, but within a given food class the transition is reliable enough to use as a primary signal. The model was trained on per-food-type colour distributions at various doneness stages, so it has learned what "done" looks like for a chicken thigh versus a beef patty versus a pastry item. These are different profiles. The model handles them as separate classification targets.
The practical constraint is lighting consistency. If the illumination inside the cabinet changes, colour readings drift. We solved this by specifying the lighting configuration as part of the cabinet's hardware design, not as an afterthought. The LED array maintains a fixed colour temperature at the tray surface. The model was trained under that specific illumination.
Texture gradient
Beyond colour, the spatial texture of a food surface changes as it cooks. A raw sausage has a smooth matte surface. A cooked one has a firmer, slightly irregular texture with visible surface variation. The model processes these differences through a spatial feature layer that looks for texture sharpness and surface variance at multiple scales.
This signal is most useful for food types where the colour transition is ambiguous, or where sauces or glazes mask the protein colour underneath. Texture is more persistent than colour through moderate sauce coverage.
Steam and condensation scatter
Hot food produces water vapour. The rate and pattern of condensation on the tray surface and on the food itself changes as the food reaches and passes through its hold window. This is a weaker signal than colour or texture but serves as a useful corroboration input when the first two signals are borderline. The model weights it accordingly.
How the three signals combine into a classification
The output of the classification model is not a single yes/no answer. It is a probability distribution across three states: not ready, in hold window, past hold window. The system acts on the most probable state, but the full distribution is logged, which matters for the food safety audit record.
When the "in hold window" state exceeds a confidence threshold, the timing system locks. From that point, the elapsed-time counter runs until the upper bound of the safe hold window is reached, at which point the cabinet flags the tray for service staff to pull. This is the two-system architecture: vision tells us when the food entered the hold window, time tells us when it exits it.
We set the confidence threshold conservatively during early testing and have not moved it. The consequence of a false-negative (food classified as not ready when it actually is) is a slightly longer wait. The consequence of a false-positive (food classified as ready when it is not) is serving food that has not reached a safe core temperature. These consequences are not symmetric, so the threshold treats them asymmetrically.
What the system cannot reliably do
Two things the vision approach does not handle well, and we want to be clear about them.
First, food items that are entirely opaque from the outside throughout the cooking process. A sealed foil pouch, for example, gives the camera no information about what is happening inside. We have not deployed the cabinet with foil-sealed items as a primary food type and would not recommend it. The system needs visual access to the food surface.
Second, ambient lighting changes outside the cabinet that bleed through when the cabinet door is opened frequently. In high-footfall environments where users access the cabinet repeatedly in quick succession, the classification is triggered immediately after door close to ensure the internal lighting state has stabilised. There is a short re-acquisition window. It is not a problem in practice but it is a deliberate design choice, not something that resolved itself.
The training data question
A fair question for any operator evaluating the system: what was the model trained on, and does it match what I am serving?
The training set covers the core food types that appear across transit hub, office canteen, and late-night operator menus in European hospitality environments: chicken portions, beef patties, pastry items, eggs, fish portions, and sausage variants. It does not cover highly unusual regional preparations or foods with extreme colour profiles outside standard commercial kitchen ranges.
During commissioning, we run a calibration pass with the specific food types an operator plans to serve. If a food type produces classification outputs that do not match observed ground truth during that pass, we can tune the per-food-type weights. This is a normal part of deployment, not an indication that the base model is wrong.
Logging and auditability
Every classification event is timestamped and logged: the input frame, the probability distribution output, the resulting state, and the timing lock event if triggered. The log is exportable and structured to align with how food safety inspectors look at HACCP-style holding temperature records. We are not replacing a temperature probe log. We are adding a visual classification layer that sits alongside it.
An operator running a transit hub food concession asked us recently whether the vision log would hold up in an environmental health inspection. The answer is that the log provides a richer audit trail than a simple time-temperature log because it documents the classified state at each frame, not just that the holding temperature was within range. Whether that is formally sufficient depends on the inspector's jurisdiction and their reading of local food safety guidance, which varies. We are careful not to make compliance claims that go beyond what the system demonstrably does.
What the system demonstrably does: it reads doneness state from visual signal, it logs every classification event with timestamps, and it closes the loop to a timing control layer that holds food within a defined window. That is the signal chain. No cook required at the pass, and the record of what happened is there if anyone asks.