Salty Desk
Hands finishing a plate on a dark kitchen pass under brass service light

Salty & Clever · Host & dine suite

Commit the kitchenon purpose.

Salty Desk is the orientation surface for three independent tools. It tells you which one answers the question you actually have — then routes you there with the handoff stated out loud.

I'm hosting at homeI'm dining outWhat moves between tools?

Vanity is allowed. The oven still has to finish on time.

0
Case filesFirst-party restaurant records
0
RegionsCovered by Restaurant Intelligence
0
OccasionsSituation types the suite recognises
0
Booking pathwaysPhone, Resy, OpenTable, Tock, Direct, Walk-in
0
Stress axesBalance, make-ahead, service, equipment, freedom
0
Menu rolesArchitecture slots per menu

Routing intelligence

Answer four constraints. Get one entry point.

The desk does not sell you all three tools. It names the one that answers your question — and the ones that do not.

Triage console

Which tool do you actually need?

Four declared constraints. Deterministic and local — nothing is uploaded, nothing is inferred, no account. Your answers stay on this device and tailor the handoff map and the boundary page.

0 of 4 declared
01 · mode

Where does the night happen?

02 · covers

How many at the table?

03 · attention

How much attention do you actually have during service?

04 · runway

How much runway before the night?

Verdict

No verdict yet

Answer the four questions. The desk will name one entry point and say plainly which tools are wrong for it.

Nothing moves between tools until you choose a handoff.

  • Menu Builder

    Not this one · 40% fit

    Start here: settle whether the menu can be finished before sequencing anything.

  • Occasion Operating System

    Not this one · 34% fit

    Wrong tool: it sequences a night, it does not choose the food.

  • Restaurant Intelligence

    Not this one · 30% fit

    Wrong tool: it has no view of your kitchen or prep.

Run status · Idle

No run open. Six stages waiting.

The pipeline runs from declared constraints to the service window, gate by gate.

Open the console

Suite status

What each tool accepts right now

Build, contract version, and last change — with what the tool will and will not take today.

LiveSC-MB-001

Menu Builder

Build
Package 0.6.0 · Engine 0.4.3
Contract
Emits 1.1.0
Updated
2026-08-11

AcceptsDeclared occasion, guests, service style, attention, equipment

RejectsAllergen safety claims, recipes, pricing, cloud accounts

Full record
LiveSC-OOS-001

Occasion Operating System

Build
Host Planning Instrument V2
Contract
Receives 1.1.0
Updated
2026-08-11

AcceptsMenu Builder packets, host conditions, capacity and attention

RejectsSilent cross-app inference, allergen guarantees, forced accounts

Full record
LiveSC-RI-001

Restaurant Intelligence

Build
Case set 136
Contract
Reader-initiated
Updated
2026-08-11

AcceptsOccasion, party size, days-out, commitment ceiling, planning load

RejectsAggregator scores, resolved conflicts, unverified operating changes

Full record

Triage grid

Three tools. One question each.

If two tools seem to overlap, you're holding the wrong question. Read the decision line, not the feature list.

SC-MB-001

Menu Builder

Can this kitchen finish this menu on time?

Use whenYou know you're cooking, but not whether the menu survives service.

Wrong tool forDeciding whether to host at all, or where to eat instead.

Full record

SC-OOS-001

Occasion Operating System

What happens, in what order, and who is holding it?

Use whenThe menu is settled and the night still has to run itself.

Wrong tool forChoosing dishes, or ranking restaurants.

Full record

SC-RI-001

Restaurant Intelligence

Which room fits this occasion — and what must still be confirmed?

Use whenThe night is better off-site and the room still has to fit the occasion.

Wrong tool forCooking, prep sequencing, or menu construction.

Full record

Host decision suite

Before you commit the kitchen

Two decisions, in order: whether the menu can be finished, then whether the night can be run. Skipping the first makes the second a guess.

The commit moment

01

Can the menu be finished?

Menu Builder returns stress scores and hard stops. A hard stop is a refusal, not a warning.

02

Can the night be run?

Occasion OS sequences shop → prep → serve against your real attention and capacity.

03

Should you host at all?

If either answer is no, dining out is the correct outcome — not a failure.

Live· Standalone instrument · also layered inside Occasion OS as Architecture01 · SC-MB-001

Menu Builder

Menu architecture + stress test

Decision it serves

Can this kitchen finish this menu on time?

Use it when

You know you're cooking, but not whether the menu survives service.

Not this tool

Deciding whether to host at all, or where to eat instead.

Five-role architecture, stress meters, anchor locking, bounded simplification, and hard stops. Scores Balance, Make Ahead, Service Fit, Equipment Fit, and Host Freedom from your declared inputs — then hands a clean packet to Occasion OS.

Launch Menu Builder
5
Roles
5
Stress axes
1.1.0
Contract
0.4.3
Engine

Does

  • Five roles with congruence / contrast / balanced pairing modes
  • Operational stress test with hard stops (allergen boundary, plated capacity)
  • Anchor re-scoring when you lock a dish
  • Bounded budget-pressure simplification — additive, never formula-breaking

Refuses

  • AI menu generation
  • Allergen safety or cross-contact control
  • Recipes, pricing, or nutrition advice
  • Accounts or cloud sync

Out →Menu architecture + stress summary + anchor → Occasion OS

Live· Host Planning Instrument · local plan state02 · SC-OOS-001

Occasion Operating System

The night, sequenced

Decision it serves

What happens, in what order, and who is holding it?

Use it when

The menu is settled and the night still has to run itself.

Not this tool

Choosing dishes, or ranking restaurants.

Host shell with three layers: Plan (night route), Architecture (menu stress under the same chrome), and Card (table wording). Receives Menu Builder packets (contract 1.1.0) and keeps dietary categories as planning filters — never allergy guarantees.

Launch Occasion Operating System
2
Modes
3
Route stages
1.1.0
Receives
1.8.0
Build

Does

  • Layered host path: Plan · Architecture · Card under one visual system
  • Condition-driven host plan: guests, service style, attention, capacity
  • Controlled route — shop → prep → serve, without theater
  • In-app Architecture (SC-MB-001 engine) + contract 1.1.0 apply-to-plan
  • Food-safety boundary surfaced on every plan

Refuses

  • Allergen-safe guarantees
  • Silent cross-app inference
  • Star ratings or social proof
  • Forced accounts for core planning

In ←Menu Builder packet (contract 1.1.0)

Out →Optional occasion context → Restaurant Intelligence

Empty candlelit restaurant banquette in a dark green dining room

Dine decision suite

Before you book the room

Rank rooms by occasion fit and operating reality. Unknowns, conflicts, and confirm burden stay in the open.

Live· 136 first-party case files · unknowns preserved03 · SC-RI-001

Restaurant Intelligence

Dine out, with receipts

Decision it serves

Which room fits this occasion — and what must still be confirmed?

Use it when

The night is better off-site and the room still has to fit the occasion.

Not this tool

Cooking, prep sequencing, or menu construction.

Situation-aware ranking from first-party evidence only. Multi-layer findings, booking pathways, confirm burden, guest-constraint matrix, and official conflicts — so you choose the room that fits the occasion, not the photograph.

Launch Restaurant Intelligence
136
Case files
43
Regions
14
Occasions
6
Pathways

Does

  • Situation rank: occasion, party size, days-out, max commitment, planning load
  • Multi-layer findings (critical + watch) with confidence labels
  • Unknowns, thin fields, and official conflicts preserved — never collapsed
  • Booking pathways: Phone, Resy, OpenTable, Tock, Direct

Refuses

  • Star ratings or aggregator scores
  • Silent resolution of conflicting claims
  • Live menu scraping as gospel
  • Skipping direct confirmation on operating changes

In ←Optional occasion context (reader-initiated)

Out →First-party case file + evidence trail → Salt Notes records

Recommended sequence

The Host Path

Menu Builder → Occasion Operating System. Restaurant Intelligence is the dine-out alternative, not step three.

1SC-MB-001

Architect the menu

Declare occasion, guests, service style, host attention, and equipment. Lock an anchor if the table needs one. Simplify what will break.

2SC-OOS-001

Run the night

Carry the Menu Builder packet forward and build the shop → prep → serve route you can actually hold.

AltSC-RI-001

Or dine out instead

When hosting doesn't survive the stress test, rank rooms by situation and confirm the hard details live.

Open the full Host Path

Explicit handoffs only

What moves — and what stays

Tools stay independent. When you choose, a public-safe packet moves downstream. Nothing is uploaded and nothing is inferred across apps without your action.

PrimaryContract 1.1.0
Menu BuilderSC-MB-001Occasion Operating SystemSC-OOS-001

Why the packet existsSo the night can be sequenced against a menu that has already been stress-tested — not against a wish list. Primary path can run in-app (Architecture → Plan) or cross-origin from standalone Menu Builder.

Moves forward

  • Menu architecture (roles, dishes, pairing mode)

    Because: The prep route is built per dish role; without roles there is no sequence to build.

  • Stress summary across five axes

    Because: Occasion OS needs the pressure profile to know which step to protect first.

  • Locked anchor and its re-scoring effect

    Because: An anchor fixes one dish's timing; the route has to respect it, not re-litigate it.

Stays behind

  • Draft menus you discarded

    Withheld because: A rejected draft is not a decision. Sending it would let it be re-proposed.

  • Simplification history and budget pressure inputs

    Withheld because: These are reasoning, not output. Occasion OS has no job that needs them.

  • Anything you did not explicitly send

    Withheld because: There is no background sync. Silence is withholding, not consent.

The receiver can conclude

  • Which dishes need heat, hands, or the pass at the same moment
  • Where the plan is already at capacity before guests arrive

It cannot conclude

  • Why you chose this menu over another
  • That any dietary category is an allergy-safe claim

If drafts and simplification history travelled too, Occasion OS would route a menu you already rejected.

Answer the triage console on the desk to see this packet written against your own constraints.

OptionalReader-initiated
Occasion Operating SystemSC-OOS-001Restaurant IntelligenceSC-RI-001

Why the packet existsSo a room can be ranked against the same occasion you were planning — when hosting is no longer the right outcome.

Moves forward

  • Occasion type, party size, and date window

    Because: Capacity and booking fit cannot be ranked without these three.

  • Planning-filter dietary categories (never allergy claims)

    Because: Used to filter rooms worth calling — the confirm still happens live, with the kitchen.

Stays behind

  • Full host plan, prep route, and shopping state

    Withheld because: None of it has a reader job on the dine-out side.

  • Guest names and private notes

    Withheld because: Packets are public-safe. Guest identity never leaves the tool it was typed into.

  • Any inference about why you switched to dining out

    Withheld because: The desk does not build a motive record. The switch is a choice, not a signal.

The receiver can conclude

  • Which rooms can physically seat the party in the window
  • Which rooms are worth the confirm call for your filters

It cannot conclude

  • That a room is allergy-safe for anyone at the table
  • That hosting failed, or why

If the host plan travelled, a restaurant surface would hold your kitchen state for a night that is not happening.

Answer the triage console on the desk to see this packet written against your own constraints.

OptionalPublic-safe packet
Restaurant IntelligenceSC-RI-001Salt Notes recordsEditorial

Why the packet existsSo a night you actually had becomes a first-party record with its unknowns still visible.

Moves forward

  • First-party case file

    Because: What was observed at the source, dated, with the observer's position stated.

  • Evidence trail with confidence labels and open unknowns

    Because: A record without its unknowns reads as certainty it never had.

Stays behind

  • Your shortlists and rejections

    Withheld because: A rejection is private judgment, not evidence about the room.

  • Booking attempts and confirm burden notes

    Withheld because: Operational friction on your side says nothing durable about the venue.

The receiver can conclude

  • What was true at that room, on that date, from the source
  • Which questions were left open

It cannot conclude

  • A star rating or a 'best restaurant' ordering
  • Anything about rooms you considered but never visited

If shortlists and rejections travelled, the record would read as a ranking you never published.

Answer the triage console on the desk to see this packet written against your own constraints.

Standing rules

How the desk behaves

Reader-job-first
Every surface names the decision it serves before it shows a control.
Explicit handoffs only
Nothing moves between tools unless you choose to move it.
Educational planning only
Planning intelligence, not professional certification.
First-party evidence
Case files come from the source, with unknowns left visible.
No allergen guarantees
Dietary categories are filters. Safety stays with the kitchen.
Fail closed
Hard constraints stop the plan instead of quietly degrading it.

Shared boundary

Local-first, first-party, no forced account

  • SafetyNo allergen safety or cross-contact control
  • SafetyFail closed on hard stops: capacity, allergen boundary, official conflicts
  • Data movementNo silent movement of data between tools
  • Data movementNo forced account for core planning tools
  • EvidenceNo star ratings, social-proof collapse, or inferred “best restaurant” rankings
  • ScopeEducational planning only — not professional kitchen, medical, or legal advice
Read the boundary in full

Desk log

Recent to the desk

Dated, dry, and first-party. What changed in the suite, and which record it changed.

Suite vocabulary & build ledger