Ask me anything mid-cook — substitutions, what to do with an ingredient, how to fix a step. Keep it quick.
HOW TO USE THIS · 60S BRIEFING
0:00
LIVE TASKS
— tap to view
▸
SERVE COUNTDOWN
30:00
STANDBY — SET DISHES AND ENGAGE
TIME FRAMEMIN
ADD DISH
Each dish auto-ignites at the exact moment it needs to start cooking so every dish finishes together, at SERVE. Longest dishes go first — you don't have to do that math mid-service.
ANTHROPIC YACHT SYSTEMS // INTERFACE STANDARD
JARVIS HUD DESIGN SYSTEM
The visual language behind the Multi-Dish Ignition Sequencer — a heads-up-display aesthetic built for high-stakes, glanceable readouts under pressure. Angular clipped panels, targeting-reticle corners, and a cyan/gold signal language borrowed from arc-reactor tech.
01One signature, everywhere. The clipped corner + reticle bracket is the single identity marker. Don't introduce a second corner treatment — reuse .hud-panel.
02Color means state, not decoration. Cyan = standby/idle. Gold = active/in-progress. Green = complete. Red = critical/time-critical. Never assign these colors arbitrarily.
03Orbitron is for numbers and titles only. It's illegible at body-copy sizes and in long strings — never set instructions or paragraphs in it.
04Motion signals "live," not decoration. Scanlines and pulsing dots should only appear on elements actively updating in real time — a static panel should never scan or blink.
05Glow is a state, not a default. Reserve text/box glow for the current focal readout (master clock, active step). Overusing glow flattens the hierarchy.
YACHT GALLEY OS // ORIGIN FILE
WHY THIS EXISTS
This isn't marketing copy. This is the true rationale behind the Multi-Dish Ignition Sequencer — the actual brief it was built to answer, and the reasoning behind every decision that followed from it.
◆ THE ORIGINAL BRIEF, VERBATIM
"A Michelin-trained chef, stranded with minimal gadgets on a tech-loaded yacht, has 30 minutes to cook a full multi-dish meal for 20 hungry people — chicken, island vegetables, seafood — before a rescue ship arrives."
01THE SITUATIONwhy the constraints matter
No brigade. No mise en place laid out by a prep team. One galley, one chef, three dishes that all need to be hot at the same moment, and a rescue ship's ETA acting as a hard stop that doesn't negotiate. Twenty people are waiting to eat once, not in shifts. That's the whole scenario — and it's deliberately unforgiving: not enough time to cook things one after another, not enough hands to cook them all "at once" without a plan.
02THE CORE PROBLEMwhy a stopwatch doesn't solve this
Chicken skewers, charred vegetables, and a seared catch don't take the same amount of time to cook. Start them all "now" and hope, and something finishes cold and waiting, or something else gets rushed and undercooked right as the ship pulls in. A normal countdown answers "how much time is left." This situation needed the opposite question answered, per dish: "when does THIS need to start so it's still hot the moment everything else is"? That's a scheduling problem, not a timer problem — and it's the reason this exists instead of a stock kitchen-timer app.
03THE SOLUTION CONCEPTreverse-scheduling, in one sentence
Pick one shared SERVE time. For every dish, subtract that dish's own cook duration from SERVE to get its IGNITION time — the exact moment it has to start. The longest dish ignites first, the shortest last, and all of them land on the pass together. The chef doesn't do that math under pressure; the app already did it the moment the dishes and the time frame were set. That mechanic — one deadline, many dishes, back-calculated start times — is the entire idea behind "Multi-Dish Ignition Sequencer."
04WHY THE HUD AESTHETICform follows the scenario, not fashion
A "tech-loaded yacht" and a rescue-ship deadline read like mission control, not a recipe blog — so the interface was built to be glanced at across a hot, chaotic galley under time pressure, not read closely like a cookbook. Cyan for standby, gold for active, red for critical, green for done: color carries the state so a half-second glance tells the chef what needs attention. See the DESIGN SYSTEM page (top right) for the full token set — it exists for the same reason this page does: nothing here is decoration without a reason.
05FEATURE EVOLUTIONwhat got added, and the problem each one answers
01Galley AI. Mid-cook questions ("my chicken looks undercooked, what do I do?") can't wait for a phone search. A chat panel gives a fast, specific answer without the chef stepping away from the pass.
02LIVE TASKS ticker. A full recipe card is too much to scan while hands are busy. The ticker distills every dish down to the one step that matters right now, with a checkbox that appears intuitively as each step comes up in real time — merged directly into the SERVE COUNTDOWN panel, so the clock and the task list it drives live in one place instead of two.
03Docked player rail. A 60-second spoken briefing that can be listened to hands-free while prepping, instead of another thing to read before starting the clock.
04DECK / STICKY / BANDED layouts. Different galley setups need different glanceability — a wide command-deck view, a sticky rail that follows scroll, or a compact banded view that surfaces the recipes without excess scrolling.
06THE THREE COMMAND VIEWSwhy deck, sticky, and banded exist — not just that they do
A yacht galley isn't one fixed workstation — it's a countertop the chef stands at, a rail they glance at while their hands are elsewhere, and, with the ship close, a screen they need to triage in half a second. One layout can't serve all three. DECK / STICKY / BANDED (toggle, top right) are three different bets on where the chef's eyes and hands actually are, each backed by an established interaction-design principle, not a personal preference.
DECK — the whole counter
Nothing on a yacht behaves like a second monitor. Deck spreads every dish, Galley AI, and the SERVE COUNTDOWN — with LIVE TASKS merged straight into it, clock and task list as one panel — across one wide sweep so the chef never changes screens to know the state of the cook — Visibility of System Status[1] taken literally: state that isn't visible costs a click, and three minutes from serve, a click is time nobody has.
STICKY — the pinned reference
Once the chef has scrolled down into a recipe's steps or a Galley AI answer, the clock can't scroll away with them. Sticky pins the whole countdown panel — LIVE TASKS and ENGAGE included, since they're one panel now — to a rail so they're always the same short reach away — the target-distance logic behind Fitts's Law[4] — in a pinned-sidebar pattern the chef has already used in a hundred other dashboards without thinking, per Jakob's Law[5].
BANDED — the triage view
With the rescue ship close, there's no time to scroll past a tall header to find out what needs attention. Banded compresses the rail, the merged countdown/LIVE TASKS panel, and Galley AI into a compact bento strip, then groups dishes into COOKING NOW vs STANDBY below it — fewer, sorted options instead of an equal scan of everything, per Hick's Law[6] — and puts the recipes where eyes land first in the F-shaped scan pattern people already read pages in [7].
Across all three, the goal is the same: minimize what has to be held in working memory while hands are busy with something else [2][3]. Secondary controls — the timeframe picker, ingredient lists, the design-system link — stay tucked away until asked for, the same progressive disclosure logic [8] that keeps a 20-minute countdown from turning into a 20-tab cockpit.
07CURRENT STATEwhere the build stands today
Every piece on this page is live in the app you're using right now — the reverse-scheduling engine, the HUD design system, Galley AI, the ticker, the narration rail, and the three desktop layouts. This page exists so that reasoning stays attached to the product instead of living only in a chat log: the brief above is the actual "why," and everything else in Galley OS is the "how."