Automate a Restaurant Recipes: Recipe Discovery Guide

Keep one known dish available as a control

The official game description says players experiment with ingredients to discover recipes and then create dishes for customers. Keep one combination that is already working in service before testing a new one. It gives you a stable input and output to compare against if the new attempt produces no visible result or interrupts the restaurant.

Separate the question from the production work. A recipe experiment asks whether a precise set of inputs produces a visible dish; it does not answer which dish earns the most, which ingredient is rarest, or which upgrade is always best.

Change one variable at a time

Start with the exact ingredients you observed, then alter only one ingredient or one stated condition for the next run. Avoid changing the ingredients, cooking setup, and service route together. When several things move at once, even a real result cannot tell you which change mattered.

1. State the combination you intend to test.
2. Run it without changing the stable line.
3. Record the dish or message the game actually displays.
4. Restore the baseline before trying a different change.

This is a player research method, not a hidden formula. It lets the record remain useful while public sources do not yet support a complete recipe table.

Record an observation another player can repeat

Each entry in the Recipe Discovery Tracker should answer what went in, what came out, and how certain the result is. Use consistent ingredient names, record the displayed dish exactly, and include a short note when a storage, cooking, or co-op condition could have affected what you saw.

Do not fill the note with invented rarity, sale price, yield, or success-rate values. Precision without a source makes a useful observation look like a verified database entry. Keep unsupported values unknown until the game or a repeatable source visibly supplies them.

Classify the result before sharing it

Repeat a clear result before calling it Confirmed. Use Needs repeat when the first run was visible but has not been reproduced, and use Unknown when the inputs or output were not clear enough to support a claim. A failed or unclear test is still useful when its record stops the next player from repeating the same ambiguity.

Share the observation in its exact scope: “this combination showed this dish in our restaurant” is actionable. “This is the best recipe” requires named alternatives, comparable conditions, and a reliable source that does not yet exist. The progression guide shows how to keep testing beside a stable production line.

Protect rare ingredients from a failed test

The official description confirms rare-ingredient hunting, but it does not publish a complete source list, respawn timing, or recipe value table. Do not consume the only copy of a newly found ingredient until you know how you will restore it or have enough stock for a second test.

Reserve a separate slot for the experiment and keep ordinary crops feeding the restaurant. If a rare input produces a visible result, save the exact observation first; if it does not, mark the test for a repeat instead of inventing an unlock condition or hidden requirement.

Compare a record with one controlled experiment

Use the searchable recipe catalog to find existing community records and the crops catalog to name the input you can restore. Their Community source and Needs verification states are evidence labels, not recipe formulas or a global ranking.

Keep a catalog result separate from the exact output you observe. A new or changed value needs a repeat test and, for update claims, an official source rather than a guessed probability, price, or multiplier.