Work / 01

Rosalynn Ops Engine

AI event operations for a chef-led hospitality brand

Turning one event's details into every document the kitchen, floor and client need, without the model inventing a single menu item.

My role
CTO. I designed the architecture and built the intake form, the printable BEO template, and the generators for prep lists and packout checklists.
Context
Rosalynn, a chef-led hospitality brand in LA's Arts District running supper clubs, catering, pop-ups and corporate events. Small team, several events a week.
When
2025 to 2026
Stack
  • n8n
  • Notion
  • Claude skills
  • MCP
  • BlueBubbles
  • Pumble
  1. 01Intake formOne flat form per event. Menu, headcount, venue, dietary needs.(built by Jimmy)
  2. 02Notion event docThe single source of truth every generator reads.(built by Jimmy)
  3. 03GeneratorsClaude skills that write the prep list and packout checklist from that doc only.(built by Jimmy)
  4. 04n8n + MCP parsingRoutes a finished event doc to the right documents and people.(built by others or planned)
  5. 05Kitchen, floor and client BEOsPDF and email. The kitchen copy is built to be read mid-service.(built by others or planned)
MineOthers or plannedIntake to service. Filled steps are the ones I built; outlined steps are designed and waiting on clean recipe data.

The problem

Every event ran off documents built by hand: a banquet event order, a prep list, a packout list for the van. The goal was simple to say and hard to hit. Staff should be able to execute an event from the documents alone, without texting anyone a question.

There was no clean master data for recipes or ingredients. That one fact shaped every decision below.

Decisions

1. Templates first, automation second

It’s tempting to wire n8n on day one. I started with the kitchen BEO instead, the densest document, and designed it to be read at a glance in the middle of service. If the output isn’t right on paper, automating it only produces wrong documents faster.

Tradeoff: slower to a demo. Much faster to something the kitchen trusts.

2. A flat form beats a clever one

The first intake form used dynamic dropdowns fed from a recipe sheet. They broke inside conditional sections. I flattened the form. It’s less elegant, and it’s reliable enough to automate against.

Tradeoff: a little more typing per event, in exchange for input the pipeline can depend on.

3. The model may not invent anything

The generators read only the event’s Notion document. They produce a four-column prep list and a packout checklist with allergen flags and client-provided versus team-packed callouts, under a hard rule: never invent menu items, counts or equipment. When the doc is missing something, the output says so.

Equipment was the sneaky one. Explicit equipment fields kept missing items, so the generator infers them from technique: confit implies a heavy pot and a thermometer.

4. Decide what stays manual

Ordering can’t be automated until the menu is locked, and menu lock happens late. I mapped that dependency and left ordering manual instead of building a system that guesses.

What I’d point to

This is a sequencing story more than an AI story. Grounding rules, boring inputs and a clear line around what not to automate are what make an LLM safe to put in front of a line cook.