A recipe test is not a slot machine. If you move several ratios, swap an ingredient, and change your method in the same attempt, a higher score tells you almost nothing. The reliable route is to keep one best-known formula intact, make one explainable change, and use the Analysis result to decide the next paired adjustment.
This guide is written against the Early Access client as it stood on August 23, 2026. The newest named official update available in the research is v0.1.46. The three identified gameplay recordings supplied for this guide show v0.0.93, so they are useful for observing the test sequence but not for publishing a permanent Vitamin Water, soda, or juice formula. If your labels or numbers differ, trust your current client and the newest official Steam note.
Before another test, write the state you are actually changing
The tablet separates Recipe Test, production, and orders. Stay in Recipe Test until you can answer three questions: which drink family you are testing, which ingredient membership is still uncertain, and which ratio signal you intend to resolve. “Try something different” is not a test plan.
Use one compact record per attempt. It does not need to be a spreadsheet. A paper row works as long as it preserves the information the next attempt needs:
| Field | Record before the test | Reason it matters |
|---|---|---|
| Build | Version visible in your current client | Prevents an old notebook row from silently becoming “current.” |
| Drink and candidate name | For example, Soda A-04 | Keeps weak tests out of the production picker. |
| Ingredient set | Every ingredient included in this attempt | Separates a wrong component from a wrong amount. |
| Ratios | Every percentage, totaling exactly 100% | Makes the candidate reproducible. |
| Analysis readback | Score, correct ingredients, and each increase/decrease signal | Turns the next move into a constraint instead of a guess. |
The v0.0.93 tutorial capture bases a Recipe Test on 1,000 ml and refuses an incomplete total. That is a useful observed scale, not a promise that Early Access will keep every test vessel and UI value unchanged. The invariant is the on-screen contract: fill the exact live target and make the displayed percentage total 100% before confirming.
The candidate must survive four physical checkpoints
Confirming percentages on the tablet creates a job, not an analyzed drink. The captured workflow and official store media agree on a physical route through the lab. Treat each handoff as a checkpoint:
- Measure. Pick up the test container and fill each listed ingredient from the raw-material shelf. Watch the phone checklist rather than relying on how full the vessel looks.
- Blend. Place the container in the shaker and let the state reach its completed readback. The interaction can be accelerated by its minigame, but speed is optional; completion is not.
- Sterilize. Move the blended test into the sterilizing step. A blended mixture is not yet ready for analysis.
- Analyze. Start the analyzer only after the previous state is complete, then wait for the score and ingredient feedback.
The order matters because the analyzer is evaluating the prepared candidate, not the percentages in isolation. In the first supplied recording, rushing the state handoff eventually produced a “recipe is not prepared correctly” failure. The useful response is not to alter the ratios. First determine whether the container was fully blended, fully sterilized, placed at the correct station, and accepted by a healthy machine.
Do not double-trigger a station because its animation feels slow. One interaction starts the work; the machine state, progress display, and completion signal decide when the container can move. An impatient second input can create a process problem that looks like a recipe problem.
Read Analysis as constraints, not as a verdict
The official Prologue v0.0.82 note added helper arrows below analyzed ratios. Those arrows indicate whether an amount should move up or down, and the setting can disable them. A “correct” ingredient answers a different question: the component belongs. Keep those two types of evidence separate.
Suppose Analysis says ingredient A should increase while ingredient B should decrease. Do not increase A by five percentage points and leave the total at 105%. Transfer a small amount from B to A so the candidate remains at 100%. If ingredient C is already marked correct and has no reason to move, freeze it. That single paired change gives the next score a clear interpretation.
- One wrong ingredient: replace that component while holding the other members and the overall ratio shape as steady as the UI permits.
- Right ingredient, wrong direction: move it a small step in the indicated direction and compensate with one other unresolved ratio.
- Several unresolved ratios: choose the clearest opposing pair. Moving every slider destroys the evidence.
- No visible arrows: check whether ratio helpers are disabled in Settings before assuming the system provides no direction.
- Score rises but signals get less clear: save the higher-scoring candidate, then compare it against the prior row. Do not overwrite either state.
Small moves are valuable near a solution because the possible interval is already narrow. Large moves are appropriate only when Analysis is telling you that the current region is plainly wrong. There is no universal five-point or ten-point rule; the useful step is the smallest change that your current controls can reproduce and your notes can explain.
Keep a control formula beside every experiment
The first recording reached a 10-point soda candidate, then displayed several older candidates in later menus. That creates an operational risk: production can select a plausible name that is not the proven formula. Give the best-known candidate a distinctive control label and never reuse that label for an experimental branch.
A practical naming pattern is drink-build-score: for example, Soda-0146-9p4. If the client limits punctuation or length, shorten it, but keep the build and score recognizable. A recipe named “Soda 7” does not tell you whether it is the 6.4 attempt, the 9.4 attempt, or the control.
When you return after a patch, rerun the control before researching a new branch. Three outcomes lead to different actions:
- The control repeats. Continue from your best row.
- The score or arrows changed. Mark the old row as legacy and establish a new control in the current build.
- The screen or recipe will not open. Treat that as a client or machine-state problem, not a signal to change ingredients.
Official v0.0.98 specifically fixed cases where certain recipes would not open. If that symptom appears on a newer installation, first confirm the running version and restart the screen cleanly. Repeated failure on v0.1.46 or later deserves a reproducible report; it does not justify guessing a new formula.
Separate lab success from a production commitment
A strong Analysis result makes a candidate eligible for a pilot. It does not tell you to accept the largest available order or fill every container. Open production, select the exact control candidate, and verify that the ratios auto-filled to the values in your log. The older capture shows this auto-fill behavior, but Early Access patches may alter menu details; compare the live values rather than trusting the name alone.
Run enough liquid for the smallest useful proof. The goal is to check that the selected formula moves through the bulk blend, sterilizer, filler, case output, and delivery accounting without a mismatch. If the first case has the expected recipe identity and the production states are healthy, scale the remaining order. If it fails, stop the line while the cause is still isolated.
Use these failure signals to decide where to return:
- Analysis score is wrong: return to the ratio log.
- Production selected the wrong candidate: correct the production picker; do not retest a known formula.
- Machine says broken or never advances: use the repair workflow before questioning the recipe.
- Cases appear but the order does not count them: verify case identity, pallet placement, and the current delivery fixes.
- The prepared test is rejected: repeat the physical state chain without changing the candidate.
The companion production and order guide starts at this handoff and explains batch sizing, machine checkpoints, case inventory, and delivery readback. It intentionally does not repeat the Analysis search method.
When the lab looks stuck, preserve evidence before resetting
Early Access encourages experimentation, but a reset should not erase the clues that distinguish a recipe error from a software error. Before reloading, capture the current build, candidate name, full ratio set, machine state, and the last action that changed the screen. Then use the least disruptive recovery:
- Exit the focused station once and check whether the machine is busy, broken, dirty, or waiting for the previous state.
- Confirm that the phone lists the exact ingredient amounts required for the active candidate.
- Repair a machine that explicitly reports a fault; do not repair healthy stations at random.
- Repeat the same candidate through measure, blend, sterilize, and analyze without inserting another test.
- If the same clean sequence fails, use a separate save slot before testing a workaround.
Six separate saves arrived in official build v0.1.46, with the previous save migrated to Slot 1. Use that separation deliberately: preserve the career state that contains your control formulas, then reproduce a hard failure in another slot when possible. A bug report with a version, a candidate, and a four-step reproduction is actionable; “the recipe is broken” is not.
For stopped machinery, pallet physics, or delivery-count symptoms, follow the patch-aware pallet and machine recovery order. That guide maps known fixed symptoms to the safest current checks instead of treating every stall as a recipe failure.
A research session should end with a decision
Do not leave the lab merely because the day is ending. Mark the candidate as one of four states: control, promising, rejected, or unresolved due to process fault. Record the next single change for a promising candidate. Record the failed physical checkpoint for a process fault. Then stop.
This boundary protects both money and memory. The next session begins with a reproducible state instead of a row of mystery names, and production receives only a formula you can identify. That is the real advantage of Analysis Mode: not an instant answer, but a feedback loop that becomes reliable when each attempt preserves what the previous one proved.
Sources and version boundary
The official Steam listing supplies the identity, platform scope, Early Access date, and discovery-first design. Current patch boundaries come from the official Steam announcements for v0.0.98 through v0.1.46 and the separate Prologue v0.0.82 Analysis-arrow note. The three supplied InsideAgameR recordings were independently identified by title, author, upload date, and duration; because their visible build is v0.0.93, they were used only for observed UI sequence and failure checkpoints. No fixed recipe from an older build is published here.