Genesis Forge

MagicMenu · first focused application

The foodservice proving ground for gdGraph.

MagicMenu is the first vertical execution system powered by Genesis Forge — and the first proof point for the broader platform thesis.

Built for institutional foodservice, MagicMenu is not an MVP or concept demo. It is fully functional software operating against real kitchen complexity: thousands of dietary, allergen, therapeutic, equipment, labor, capacity, preference, and compliance constraints that must resolve into an executable plan.

Institutional foodservice is a demanding proving ground because every menu decision cascades across ingredients, substitutions, shared equipment, sanitation paths, nutrition limits, staffing, and audit requirements. Raw AI can suggest options. MagicMenu turns those suggestions into validated, reviewable, lockable plans of record.

This is the Genesis Forge method in operation: AI proposes, deterministic logic decides, and the system builds auditable operational memory over time.

An institutional kitchen rendered as a control system: parallel dietary-variant production lines drawn as glowing nodes and arrows that converge on a central safety check and a lock before validated meals are served.

MagicMenu · working product

Real software, running the full operational loop.

The production application — intake to tray cards, recipes to purchase orders. The B2C configuration is in final beta, with updates shipped weekly. The B2B is ready for the first pilot evaluation, beginning in late August.

MagicMenu secure dietary-intake flow opened from an email magic link: date-of-birth verification, allergen selection, and medically-required diets.
Continued dietary intake: cultural and lifestyle preferences, IDDSI texture and liquid-thickness levels, free-text care notes, and a signed confirmation.
Group Members tray-card view: per-person serving, ingredient substitutions, cross-contamination steps, and dietary profile for a planned dinner.
Recipe library of institutional recipes showing cuisine, difficulty, batch tags, USDA sourcing, allergen flags, and ingredient counts.
Recipe ingestion screen: paste recipe text or upload a PDF, Word doc, or photo and have it parsed with AI into the collection.
Meal-planner match that finds a recipe already satisfying every group member's dietary profile, shown with full ingredients and instructions.
Recipe adaptation detecting group dietary conflicts and generating a compliant keto variant with ingredient substitutions and safety notes.
Weekly meal planner across breakfast, lunch, and dinner with adapted recipes, an aggregated shopping list, inventory reconciliation, and a generated purchase order.

Company relationship

Genesis Forge and MagicMenu

Genesis Forge is the cross-vertical parent company. It is building the Genesis Forge Platform and the underlying gdGraph (Generative Deterministic Graph) control layer for applying AI inside high-stakes, high-compliance operations — pharma, aerospace, chemicals, nuclear, defense, and food & beverage among them.

MagicMenu, Inc. is in the process of becoming a wholly owned subsidiary of Genesis Forge. It is the first focused application of the method and the proving ground where the base technology is hardened against a real, regulated, high-stakes operation.

The symbiotic relationship between Genesis Forge and MagicMenu Genesis Forge, the cross-vertical parent serving pharma, aerospace, chemicals, nuclear, defense, and food and beverage, sends its gdGraph deterministic control layer, platform IP, and R&D down into MagicMenu. MagicMenu, the institutional-foodservice proving ground, sends operational proof, real-world validation, and hardened patterns back up. Pharma Aerospace Chemicals Nuclear Defense Food & Bev GENESIS FORGE cross-vertical parent · gdGraph deterministic control layer gdGraph deterministic control platform · IP · R&D operational proof real-world validation hardened patterns MAGICMENU, INC. subsidiary (in process) · institutional foodservice proving ground
How the two companies reinforce each other: Genesis Forge sends the gdGraph deterministic control layer, platform IP, and R&D down into MagicMenu; MagicMenu sends operational proof, real-world validation, and hardened patterns back up to strengthen the platform for every other vertical. Illustrative; MagicMenu, Inc. is in the process of becoming a wholly owned subsidiary of Genesis Forge.

The creative engine

What the creative layer makes possible in the kitchen.

The deterministic kernel is what makes MagicMenu safe to ship. The creative layer is where the value lives: give it a messy, contradictory reality — hundreds of residents, allergens, textures, therapeutic limits, equipment, and cost — and it will search millions of plans you'd never have time to consider, then hand the trust layer its best, fully-formed candidates.

The creative layer is an agentic system: large language models, domain heuristics, simulation, and optimization solvers working together. It thrives exactly where a kitchen runs out of hours — on ambiguity and combinatorial explosion. Every figure below ends the same way: the creative layer proposes, explores, simulates, and optimizes; the trust layer is the only thing that validates, repairs, and locks the one plan allowed to run.

The creative engine, end to end

One engine. Millions of plans. The best ones — locked, shipped, and remembered.

GENERATIVE → DETERMINISTIC → LOCK · illustrativegenerativedeterministic
The end-to-end engine: generative exploration, a deterministic lock, validated outputs, and an operational-memory learning loop Messy inputs stream in on the left and propagate in real time into a large glowing generative engine that explores a fan of candidate plans. The top-ranked few cross a deterministic lock gate where they are validated and executed. Production sheets, purchase orders, and tray cards flow out, and every decision feeds an operational-memory node that loops back into the engine. MESSY REALITY MILLIONS OF PLANS EXPLORED VALIDATION & EXECUTION VALIDATED OUTPUTS Diet orders Census & cohorts Inventory Distributor prices Equipment state live — constraints propagate in real time THE CREATIVE ENGINE generate · simulate · optimize stress-test · counterfactual exploring millions of candidate plans LOCK boundary LOCK hashed · versioned only validated plans ship Productionsheets Purchaseorders (POs) Tray cardsper resident OPERATIONAL MEMORY approved · rejected · rationale · evidence learning loop · build the operational memory
Hover the inputs, the engine, the lock gate, an output, or the memory. The generative layer explores everything; the deterministic layer validates, locks, and remembers the one plan allowed to run.

End to end — generative engine → deterministic lock → validated outputs → operational memory. Messy reality streams in on the left and propagates in real time. The engine generates, simulates, optimizes, stress-tests, and reasons counterfactually across millions of candidate plans; the top few are validated and locked at the gate; production sheets, purchase orders, and tray cards flow out; and every decision is written to an operational memory that feeds the next service. Breadth is the point; the lock is the safeguard: only validated plans ship.

Each capability below is one slice of this loop. The pattern never changes: the generative layer proposes and ranks thousands of candidates; the deterministic layer validates, repairs, and locks the one that’s allowed to run — then remembers it.

Operator time saved

Stop doing menu-math by hand.

Cross-checking allergens, hand-building substitutions, recalculating cycle menus, writing tray cards, and reconciling orders eats a chef's week. The creative layer does the combinatorial drudgery so the culinary team spends time on food, not spreadsheets.

~18 hrs/week → ~3 hrs/week 15 hrs reclaimed tray cards auto-generated

What the chef approves becomes the trust layer's locked plan-of-record — with an audit trail of every change.

weekly time ledger · illustrativecreative
Weekly time ledger before and after MagicMenu A tall before-bar of menu-math tasks summing to about 18 hours per week collapses to a thin review-and-approve sliver of about 3 hours, freeing roughly 15 reclaimed hours. BEFORE · THE CHEF'S WEEK allergen4.0h subs4.0h cycle math3.5h tray cards3.5h reconcile3.0h ≈ 18 hrs / week on menu-math WITH MAGICMENU 15 hrs reclaimed — for food, not spreadsheets review &approve ≈ 3 hrs / week · tray cards auto-generated
Hover a task block, then press Run MagicMenu to collapse the week.
Time ledger, before / after. The before-bar is a tall stack of weekly tasks — allergen cross-checks, substitutions, cycle-menu math, tray cards, order reconciliation — summing to roughly 18 hours. Press Run MagicMenu and the stack collapses to a thin “review & approve” sliver while a flame-orange “reclaimed hours” block expands to fill the difference. ◇ Illustrative example — not a real plan menu-math / reclaimed review & approve

Whole-kitchen orchestration

Run the entire kitchen as one graph — then break it on purpose.

The creative layer doesn't just plan what to cook; it sequences how the kitchen executes — prep, cook stations, ovens, plating, and service windows as a single timed graph. Then it stress-tests that plan against a census spike, a late delivery, or an equipment failure, surfacing the bottleneck before service does.

6 stations · 1 timed graph 120 covers / service window bottleneck found before service

The trust layer enforces capacity and timing feasibility — it won't lock a plan the kitchen physically can't execute.

orchestration graph · illustrativecreative
Kitchen orchestration Gantt with a stress-test overlay Six station lanes with timed blocks connected as a directed graph. A stress scenario lights the combi-oven and plating blocks red and marks the plating bottleneck; a re-sequence proposal clears it. Scenario: +20% census + 1 oven down → plating bottleneck at 11:40 Re-sequenced: plating split across 2 stations — bottleneck cleared 10:00 10:30 11:00 11:30 12:00 12:30 Prep Combi Oven Range Cold Line Plating Service Veg prep Protein Roast b1 Roast b2 Sauces Salads + pureé Plate service Service BOTTLENECK 11:40 + 2nd plating station
Hover any block to inspect it. Try Stress test, then Re-sequence.
Orchestration Gantt + stress overlay. Six lanes — Prep, Combi Oven, Range, Cold Line, Plating, Service — carry timed blocks linked left-to-right by dependency connectors (a true DAG). The Stress test toggle overlays a “+20% census, one oven down” scenario: affected blocks light red, the critical-path plating bottleneck pulses, and the banner names the slip. Re-sequence shows the engine's proposed fix — a second plating station — that clears it. ◇ Illustrative example — not a real plan scheduled bottleneck re-sequenced

Capacity ROI · counterfactual search

Where one more oven buys you an hour — and pays for itself.

Because the kitchen is modeled as a graph, the creative layer can ask counterfactual questions: what if we add a combi oven? a second prep cook? an extra plating station? It quantifies the marginal throughput each change unlocks and estimates payback — turning capital decisions into evidence.

best next move: +1 combi oven +18 covers/hr est. payback ~7 mo

The trust layer validates that the modeled capacity gain holds under real constraints before anyone signs a purchase order.

marginal value · payback · illustrativecreative
Marginal-throughput and payback curve for capacity investments A diminishing-returns curve of throughput against added capacity. Three intervention points are marked with their throughput gain and payback; adding one combi oven is the highest-return next move. added capacity → throughput (covers/hr) ↑ now +oven +cook +station BEST NEXT MOVE +1 combi oven · +18/hr · ~7 mo
Hover each intervention to see its throughput gain and payback.
Marginal-value / payback curve. Throughput rises with added capacity along a diminishing-returns curve. Annotated steps — +1 combi oven, +1 prep cook, +1 plating station — each carry a throughput gain and an illustrative payback. The current operating point is marked, and the highest-ROI next investment glows flame-orange. ◇ Illustrative example — not a real plan best next move current point

Supply-aware cost optimization

Buy smarter across the whole catalog — automatically.

Menu demand becomes an ingredient demand list, which the creative layer prices against broadline distributor catalogs — comparing equivalent SKUs, pack sizes, availability, and substitutions to drive cost down without changing what lands on the plate.

1,240 line items priced 38 equivalent substitutions −9.2% food spend pack-size optimized

Substitutions are only proposals — the trust layer re-validates every swap against allergen and diet-order constraints (ABSENT / UNKNOWN / POSSIBLE / PRESENT) before it reaches a tray card.

catalog optimization · illustrativecreative
Ingredient demand priced and optimized across distributor catalogs A locked menu becomes ingredient demand, priced against two broadline catalogs plus a backup. Optimizing swaps SKUs for cheaper equivalents, reroutes a limited item, and tallies the savings. Locked menu plan-of-record Ingredient demand 1,240 line items Broadline catalog A equivalent SKUs Broadline catalog B pack-size options Catalog C · backup availability: limited → reroute Optimized cart −9.2% spend LINE-ITEM SUBSTITUTIONS food spend: baseline −9.2% · 38 substitutions Diced tomato · SKU 8841 · case/24 · $0.74/ea → SKU 9120 · case/30 · $0.62/ea (−$0.12) Olive oil · SKU 4417 · 1 gal · $19.40 → SKU 4419 · 3×1 gal · $17.85/ea (−8%) Frozen peas · SKU 5503 · Catalog A → reroute to Catalog C · same cost
Hover a node or line item, then press Optimize cart.
Catalog optimization flow. Left to right: locked menu → ingredient demand → distributor catalogs (two broadline plus a backup) → optimized cart. Pressing Optimize cart reveals where the engine swaps a SKU for an equivalent at lower unit cost or better pack size (highlighted flame-orange), reroutes a limited item to an alternate catalog, and tallies a running savings figure with a badge on the cart. ◇ Illustrative example — not a real plan ABSENT UNKNOWN POSSIBLE PRESENT

See the method behind MagicMenu.

MagicMenu is the first focused application. gdGraph is the deterministic control method Genesis Forge is developing for high-stakes operations.