Brigade / Mise · product roadmap · proposed v2.2

From one recipe answer to an operating partner for the kitchen.

Mise earns trust by costing one recipe honestly. Brigade can then help existing ChefTec clients ingest recipes faster while compounding that trust into living kitchen truth, reversible decisions, simulations, sensory intelligence, conversational control, multi-location operations, and eventually approved purchasing work.

0 · TrustOne attributable recipe answer

0.5 · BridgeApproved recipe into ChefTec

1 · Book → MenuPlates assemble as recipes arrive

2 · GroundInvoices replace benchmarks

3 · ActApprove one bounded response

4 · ControlContextual Mise, one safe tool

5 · SimulateWhat-if without changing truth

6 · SenseProfile and swap direction

7 · ConverseBuild and save through dialogue

8 · LocateOne recipe, local truth

9 · R&DCompare and grade trials

10 · PurchasePrepare approved work

Value before setup

Answer first

Benchmark what is knowable, expose what is not, and let the chef improve the answer after receiving value.

Tools before agent

Certify each lever

Every action and simulation exists visibly and deterministically before conversation may operate it.

A living result

Close the cascade

Evidence changes recipes, plates, menu economics, decisions, and later operating work—with approval.

North-star: complexity should increase Brigade’s background work—not the chef’s setup burden. Every horizon ends in something Jeff can actually use.

Language contract · composition is not portfolio

Plate, menu item, menu assortment, and sales mix answer different questions.

One thing the guest buys

Sellable-item build

The versioned composition of one sellable unit. It connects recipe portions and sub-recipes to a guest-facing item. A plate build is the plated-food subtype and UX view—not the universal data name.

Steak Frites · one sellable servingThe menu item points to this versioned sellable-item build.

Steak · 1 portionA production recipe portion.

Fries · 6 ozA second production recipe portion.

Peppercorn sauce · 2 ozA sub-recipe that may be used by several dishes.

Garnish · openAn honest gap remains visible until specified.

Item economics: roll up only confirmed recipe versions, portions, yields, and eligible evidence. Tiramisu can have a quiet one-component item build; the chef never sees a plate builder unless composition needs attention.

What is offered

Menu assortment

The set of menu items, variants, bundles, sections, locations, channels, and prices the business offers.

EntréesSteak Frites

DessertTiramisu

ChannelDine-in

What actually sells

Sales mix

The proportion and volume of each menu item sold over a period. This is required for portfolio contribution, demand, capacity, and true menu engineering.

42%Item A

31%Item B

27%Other

Terminology decision

“Product mix” is overloaded. Use sellable-item build for one item’s composition, plate build for its plated UX, menu assortment for what is offered, and sales mix for what sells.

Capability maturity · the agent earns broader control

Each new intelligence layer operates the same visible, certified product tools.

Visible actionChef opens and approves one deterministic proposal

Pinned tool callMise retrieves or operates it in explicit context

Immutable what-ifTyped assumption creates a separate scenario result

Sensory evidenceThe same scenario gains qualified culinary direction

Draft editClear instruction updates a versioned formula or method

Goal + trialsOpen intent becomes bounded candidates and feedback

One shared progression

The interface proves the tool before conversation receives it

Action

Current base, permission, receipt, approval, rejection, compensating Undo.

Real mutation

Simulation

Pinned base, typed hypothetical, deterministic result, immutable revision, stale rerun.

No mutation

Sensory

Formula + method + source-backed direction + visible unknowns + chef correction.

Qualified claim

Conversation

Same IDs, tools, ledgers, versions, permissions, receipts, and stale-base rejection.

No shadow path

R&D

Typed candidate versions, deterministic comparison, trial selection, structured feedback.

Test + learn

Real checkpoint

The interaction, money, write, receipt, permission, and recovery path run against the bounded contract.

Authorized fixture

Sanitized or explicitly authorized data may prove the path; the behavior and dollars remain real and answer-keyed.

Prototype / non-live

Future screens may test comprehension, but mock values, simulated mutations, and unsupported outputs are labeled visibly.

Roadmap discipline

A horizon is not implementation authority. Each cross-cutting tool receives a bounded contract and independent gates.

Balanced destination: Menu is one projection. Simulations, sensory intelligence, locations, conversation, R&D, and purchasing all consume the same living kitchen truth.

J0 · trustworthy recipe answer · Gate A passed · Product Gate B correction

Earn the right to do more by answering one recipe honestly.

Recipe benchmark

Your recipe is costed

Known value arrives now. Assumptions and gaps remain attached to the result.

Ingredient costPoint estimate + eligible range

Current

CoverageCosted · assumed · open

Honest

One decision worth your time

Chef-meaningful choice ranked by its dollar impact.

Review the decision

Use the current benchmark

Concept screen · values supplied by engine at runtime

CaptureRead the recipe without setup

Cost silentlyReturn known result and range

Ask ≤3Only material culinary decisions

ReceiptShow recost, scope, memory, Undo

X-rayAttribute every line

MenuRead the same current projection

Chef promise

A useful partial result is better than a wall. Uncostable lines stay visible with context; uncertainty never becomes fake accuracy.

System promise

One server-owned projection supplies CostingProgress, Verify, Recipe View, X-ray, and today’s capital-M Menu recipe-portfolio screen. GET does not secretly recost; future MenuItem/Listing models remain distinct.

Attention promise

Rank decisions by expected dollar movement. Suppress catalog rows, arithmetic paths, and immaterial questions.

Current exit gate

Architecture Gate A passes. Product Gate B now requires canonical UI Undo, bounded chef-level options, one explicit cost basis, and honest readiness and partial-result language.

Jeff checkpoint J0: upload one recipe → receive payoff → resolve one decision → see receipt/Undo → inspect X-ray → return to a fast, consistent Menu.

CTB-001 · ChefTec capture bridge · discovery after J0

Use Brigade to eliminate recipe re-entry for existing ChefTec clients.

Recipe import · Park City ChefTec

Ready to send

The recipe is structurally valid for ChefTec. Costing can continue without blocking the import.

Vanilla ice creamNew recipe · 14 ingredient lines

Ready

Yield + serving unit3 gallons · 96 scoops

Confirmed

Cost coverage12 costed · 2 still open

Does not block

Send to ChefTec

Preview mapped fields

After approval: publish asynchronously, read the recipe back, then show ChefTec ID, site, warnings, and a reconstructible receipt.

Proposed · integration path not yet confirmed

CapturePhoto, PDF, or typed recipe

ValidateOnly import-required fields block

PreviewNew/update, target site, duplicates

ApproveChef explicitly sends

PublishAuthorized async connector

VerifyRead-back receipt

Immediate client value

Brigade handles handwriting, structure, units, and focused exceptions so a ChefTec client does not retype the recipe.

Two readiness states

ChefTec ready means required recipe fields are valid. Costing complete means evidence can support the economics. One does not impersonate the other.

Discovery gate

Confirm supported API/import utility versus direct SQL, hosting topology, source of truth, required fields, duplicates, subrecipes, reversal, and one pilot site.

Safety boundary

No model or browser request writes directly to a client database. Deterministic mapping, target validation, approval, idempotency, and read-back are mandatory.

Sequence: close ICE-001 first. Run CTB discovery immediately after. Build CTB-001A/B next only if a safe supported import path exists; otherwise continue invoice grounding while Architecture resolves the connector.

Thin composition foundation · before the first price action · proposed

Sellable-item building should feel like confirming Mise’s work—not starting a second project.

Tiramisu · recipe result

One-component item build

Mise matched a complete serving recipe to an imported/current menu item and quietly created a reversible draft.

Tiramisu12 portions · complete dish

High confidence

PriceNot set

Change how this recipe is used

Proposed · not live

Steak Frites · plate build

Four components found

Selecting a row opens one overlay to change the recipe or portion. No multi-step chooser.

Steak1 portion · costed

Linked

Fries6 oz · costed

Linked

Peppercorn sauce2 oz · benchmark

Estimate

GarnishQuantity not specified

Open

Confirm 4 components

Add another component

Proposed · not live

Direct dishes stay quiet

No “Would you like to sell this?” prompt for an explicit menu match or obvious complete dish. Create the one-component draft and show confidence plus correction.

Composed dishes stay inline

Add, remove, or resize a component inside Recipe View or Menu View. Cost refreshes in place with receipt and Undo.

Batch uploads become exception review

“7 dishes drafted · 9 prep recipes connected · 3 relationships need confirmation.”

Composition proof C0: support one versioned sellable-item build before J2 price actions. Broader draft-menu automation can grow incrementally and does not block J1 invoice learning.

J1a invoice review + J1b targeted payoff · proposed

Invoices replace market evidence with kitchen truth—and show the payoff immediately.

Invoice read · exception review

Three lines need you

24lines read

18ready to learn

3need attention

3fees / credits

Vanilla beansWhich product matches this line?

High impact

Heavy cream packPackage size needs confirmation

Show 18 ready lines

Proposed · not live

UploadImage or PDF first

ReconcileVendor, total, fees, credits

ResolveChef-level identity and package

ConfirmImmutable evidence event

RebuildOnly affected current projections

Grounding payoff

Five recipes and three menu items improved

Benchmark → kitchen

Eligible invoice evidence replaces aggregate market context line by line.

Recipe effect

Show old/new known cost or range, evidence source, and remaining gaps.

Item effect

Recalculate only sellable-item builds that consume the affected recipe version.

Menu effect

Refresh eligible listing economics without blanking or recomputing the full book on GET.

Progressive context

Collect location, service style, package preferences, vendor relationships, menu price, and volume after value—not as an onboarding wall.

Jeff checkpoint J1: confirm one authorized invoice and understand every learned relationship, affected recipe, sellable item, and remaining exception.

J2 · living action + pricing review · proposed

Recommend only as strongly as the menu and business evidence allow.

Steak Frites · price review

Review the menu price

The sellable-item build is current. The calculated action names its basis and missing context.

Current listed priceGross listed price before tax · dine-in

Known

Item cost basisFood + recorded recipe labor; absent labor is not modeled

Current

Calculated target priceAt the operator-selected food-cost target

Proposal

Review proposal

Keep current price

Packaging, commissions, discounts, and overhead: not modeled. No “profit” claim.

Concept screen · illustrative fields, not live values

1

Known plate cost

Versioned recipe portions and eligible evidence.

2

Target calculation

“At your selected target, calculated price is…”

3

Future: market context

Unavailable until eligible local, category, and service-style comparables exist.

4

Future: recommendation

Unavailable until labor, channel, positioning, and policy context support it.

Never jump from ingredient percentage to “optimal price.”

Demand, sales mix, capacity, discounts, fees, taxes, labor, overhead, and competitive positioning may be absent. Mise names the calculation basis and stops at the highest eligible claim.

First bounded action

Approve, reject, or change one deterministic menu-price proposal for one current, eligible sellable-item build.

Action safety

Fresh-base check, permissions, immutable receipt, application result, and compensating Undo.

Jeff checkpoint J2: one invoice-backed cost movement reaches the correct menu item and produces one understandable, reversible price-review action.

J4a · narrow contextual Mise · proposed

Test the agent premise early with one safe action and unmistakable context.

Visible interface

Steak Frites

Current plate buildSteak · fries · sauce · garnish open

Current

Price reviewOne proposal awaits approval

Action

EvidenceInvoice-backed at Park City

Scoped

Selecting a chat result highlights this exact visual object. The UI and conversation share one version.

Mise · Park City

Steak Frites

“Show me why this price review appeared.”

The invoice changed one plate component. I can open the attributable proposal; nothing changes without approval.

Open price proposal

Pinned: organization · location · menu item · version · projection

J4a

One certified action

Open or operate a server-certified price-review action. Preserve minimize/resume, explicit scope switching, stale rejection, receipt, and Undo.

Not yet a co-designer

No free-form formula mutation, sensory claims, uncatalogued tools, or arithmetic inside the model. Existing Ask Mise intents are not grandfathered in.

Why this comes early

It proves whether persistent context, UI convergence, permissions, and receipts work before the assistant receives broader culinary authority.

Jeff checkpoint J4a: ask one contextual question, open one real action, approve or reject it, minimize/resume, and see the same receipt in the interface.

S0 / J2.5 · immutable what-if simulations · proposed

Change an assumption without contaminating kitchen truth.

Scenario S-104 · fresh · base v18

Ingredient price what-if

Confirmed line + packageNormalized same-pack assumption

Pinned

Hypothetical ingredient priceUser-entered · no evidence changed

Input

Optional listed priceGross before tax · dine-in

Input

Batch + serving resultOld → new · deterministic range

Engine

Contribution basisFood + recorded labor; other components not modeled

Named

CoverageKnown, assumed, and open inputs preserved

Partial if needed

Create scenario revision

Nothing live changed · no Undo required

Proposed · illustrative fields, not live values

Pin baseFormula/item, evidence, projection, menu-price, policy

OverlayTyped user assumption

ComputeDeterministic low/point/high + ledger

PersistImmutable scenario revision

StaleAny pinned revision changes

RerunNew run supersedes old

First

Same-pack ingredient-price what-if; optional listed-price input only for a confirmed sellable unit.

Next: correct batch scaling

Linear ingredient quantities + repeated-batch labor count. No bulk-price, labor-efficiency, capacity, quality, or availability claim.

Later bounded calculators

Units to recover one named entered cost and selected-item per-unit contribution comparison.

Descriptive / unavailable

Confirmed ingredient overlap is descriptive. Actual break-even, menu fit, demand, capacity, savings, inventory, and purchasing remain unavailable.

S-104 · stale

Underlying evidence changed

Historical result stays readable but cannot create an action. Rerun with current data creates S-105 linked to S-104.

Mise uses the same result

“Scenario S-104 is stale. I can open it or rerun the certified tool; I cannot quote it as current.”

Jeff checkpoint S0: create one price scenario, revisit it, make its base stale, explicitly rerun it, and prove UI + Mise quote the same scenario ID and ledger. Applying a result forks a separately revalidated J2 action.

J3 · sensory foundation · proposed

Put culinary consequence beside cost—qualified, correctable, and source-backed.

Expected sensory profile

Vanilla ice cream

Directions, evidence, and dependencies—not a fabricated precision score.

Richness · higherQualified by fat/solids evidence · medium confidence

Directional

Sweetness · current bandFormula relationship · bounded basis

Supported

Body · unavailableDepends on missing overrun and freezing method

Needs method

Finish · unknownNo eligible claim for this formula/method version

Open

Correct this profile after a trial

Concept screen · illustrative profile, not a live prediction

Formula version

Exact ingredients, specifications, quantities, yield, and deterministic mass balances.

Method version

Time, temperature, equipment, aging, freezing, overrun, hardening, and serving conditions.

Knowledge + evidence

Versioned functional properties, qualified claims, dependencies, sources, and applicability.

Chef correction

Trial and tasting feedback becomes scoped memory; disagreement remains visible.

What-if + sensory result

Test one ingredient, see two consequences

Cost

Deterministic old/new cost, coverage, range, and source ledger.

Sensory

Qualified directional change with confidence, evidence basis, and process dependencies.

Live state

No formula changed. Applying the tested input to a versioned draft is a later, separately validated action.

Jeff checkpoint J3: inspect one bounded ice-cream profile, test one eligible ingredient/specification, receive cost + qualified sensory delta, and grade the prediction without silently changing the formula.

J4b · full conversational recipe control · proposed

Conversation becomes a control surface over visible, certified culinary tools.

Draft v4

Vanilla ice cream

FormulaStructured ingredients and quantities

Current draft

MethodAge · freeze · harden · serve

Versioned

CostCalculated from current draft

Engine

ProfileQualified against this formula + method

Directional

Save version to Recipe Book

Mise · draft v4

“Replace 50 g milk with 50 g cream. Keep yield and method fixed; show cost and qualified profile delta.”

Clear instruction parsed. The current draft, method, and yield remain pinned.

Proposed draft change

Structured tool result appears in the formula before saving.

Apply to draft

Keep current version

Conversation may

Capture intent, ask focused questions, invoke certified tools, update a versioned draft, explain results, and request a separate save action.

Conversation may not

Calculate money, invent evidence, infer permission, silently switch recipe/location, save by implication, or bypass stale-base validation.

Non-disruptive behavior

Small trigger, persistent drawer, minimize/resume, visible scope, explicit switching, direct links to affected interface objects.

Jeff checkpoint J4b: give one clear recipe instruction, watch formula/cost/profile update in the interface, save the version to the book, update existing uses through the canonical dependency path, and Undo without re-entry.

J5 · multi-location and openings · proposed

Keep one culinary intent while preserving each location’s commercial truth.

Shared

Base culinary recipe

Intent, approved formula, method, serving definition, quality requirements, and controlled inheritance.

Park City

Local evidence

Vendor offer, package, price, yield observations, menu listing, memory, and authorized overrides.

New opening

Inherited draft

Copy the approved base while keeping evidence unknown until the new location earns its own truth.

Compare variance by cause—not by a flattened average

Ingredient price

Same specification, different eligible local offer.

Commercial variance

Package / conversion

Different purchasable pack or confirmed conversion.

Evidence variance

Yield / method

Observed execution differs from the approved base.

Operational variance

Formula override

Intentional local adaptation remains explicit and versioned.

Culinary variance

Menu price / channel

Location and channel-specific listing economics.

Offer variance

Scope must exist earlier

Location-safe evidence, memory, plate builds, menu prices, scenarios, threads, and approvals are designed during invoice/action work—even though this interface ships later.

Jeff checkpoint J5

Compare one recipe and menu item across two authorized locations, understand the causes, and create a new-opening draft without contaminating either site.

J6 · goal-directed conversational R&D · proposed

Move from a culinary goal to testable versions—not one fluent guess.

GoalRicher, tangier, less sweet, lower cost, or fewer active steps

ClarifyAsk only variables that materially define success

Generate2–3 bounded candidate versions

CompareCost, qualified profile, method, assumptions, current offer if known

TrialSelect one explicit test version

GradeStructured tasting and execution feedback

Candidate version A

Closest to current

Formula: minimal delta.
Cost: deterministic current basis.
Profile: qualified direction.
Blocker: none shown only when validated.

Candidate version B

Cost-constrained

Formula: eligible substitution.
Cost: deterministic delta.
Offer: current if evidence exists; otherwise unknown.
Claim: no quality equivalence.

Candidate version C

Profile-forward

Formula: larger bounded change.
Profile: directional evidence.
Method: explicit dependency.
Blocker: unsupported axes stay open.

Difference from early simulation

S0 tests one explicit assumption. R&D interprets an open-ended goal and develops multiple formula/method candidates using the already-certified tools.

Difference from normal conversation

J4b executes clear instructions on one draft. R&D proposes testable alternatives and learns from structured trials.

Jeff checkpoint J6: give one real culinary goal, compare two or three attributable versions, select a trial, and record scoped tasting/execution feedback that becomes evidence for later work.

J7 · purchasing destination · discovery until truth exists

Prepare operating work only after demand, inventory, offers, and authority are real.

Demand planAuthorized forecast or explicit assumption

Recipe usageVersioned plate and prep requirements

InventoryCurrent stock, units, freshness

OffersVendor, package, availability, lead time, minimum

PolicyQuality, location, budget, approval

ProposalAttributable order plan—not automatic execution

First honest slice

One order proposal, one approval loop

Need

Derived from authorized demand, inventory, and versioned recipe usage.

Choice

Eligible vendor/package options with availability, minimum, lead time, and quality constraints.

Exceptions

Unavailable ingredients, stale counts, missing conversions, and policy conflicts stay visible.

Authority

Prepare → approve/reject → later transmit only under explicit organizational permission.

Discovery-only until inputs exist

Without actual demand and inventory, Brigade can demonstrate a sandbox calculator—not a functioning purchasing manager.

Unavailable shortcuts

Recipe quantities do not equal order quantities. Price history does not prove availability. A vendor catalog does not prove a purchasable offer. A model does not infer approval authority.

Jeff checkpoint J7

Using authorized or explicitly sandboxed demand and inventory, generate one attributable proposal, explain exceptions, and complete one real approval/rejection receipt. Vendor transmission remains labeled non-live until integrated.

Discover truthDemand plans, inventory snapshots, current offers

RecommendOrder guide and purchase quantities

CompareVendor/package options and exceptions

PrepareConsolidated order / PO draft

Transmit laterSeparate integration + authority contract

Build sequence · deployable value every step

The roadmap is a chain of usable proofs, not a long hidden build.

Now · J0

Trust spine: one current recipe answer, ≤3 decisions, receipt/Undo, X-ray, fast current portfolio.

Jeff costs one recipe

Conditional · CTB

ChefTec bridge: reviewed recipe → deterministic mapping → approved asynchronous publish → read-back receipt.

One client avoids re-entry

Parallel · C0

Thin composition seam: one versioned sellable build; direct dishes stay quiet; composed items connect inline.

One item assembles

J1a → J1b

Grounding: invoice exception review followed by targeted recipe/item payoff.

One invoice improves truth

J2

Action: one current sellable item receives one attributable price-review proposal.

Approve / reject / Undo

J4a

Narrow control: Mise operates one certified action in pinned context.

Agent premise tested

S0 / J2.5

Simulation: immutable ingredient/menu-price what-if, stale detection, explicit rerun.

What-if, no mutation

J3

Sensory: bounded profile, what-if delta, chef correction.

One prediction graded

J4b

Full conversation: clear formula/method instruction, cost/profile update, version save.

Recipe built in dialogue

J5

Locations: shared intent, local evidence, explicit inheritance and variance.

Compare two sites

J6

R&D: open goal → candidate versions → trial → scoped feedback.

Two versions tested

J7

Purchasing: real demand/inventory enable an approval-ready order proposal.

One loop closed

Build rule

A visible deterministic tool ships before it becomes an agent tool.

Data rule

Design location, identity, evidence, versions, and receipts early; expose surfaces when useful.

Roadmap rule

A horizon does not authorize implementation; each cross-cutting slice receives a bounded contract and gates.

Shared laws · what remains true as the product expands

The agent may become broader. The truth contract does not loosen.

1

Money is deterministic

No model-calculated costs, margins, target prices, scenario results, or order arithmetic. A model may propose typed inputs; certified tools compute.

2

No bare answers

Every number carries basis, evidence, versions, coverage, assumptions, and exclusions.

3

Partial still pays off

Show known values and bounded ranges; unavailable claims do not become an empty screen.

4

Attention follows dollars

The chef sees only decisions that materially change the result or operational action.

5

Memory is earned

Recipe truth, kitchen memory, location scope, correction, and Undo remain distinct.

6

Hypothetical stays hypothetical

Scenarios never contaminate evidence, canonical projections, recipes, listings, or actions.

7

Conversation shares the UI

One visible scope, one version, one action service, one receipt, and explicit switching.

8

Location is never implied

Evidence, offers, prices, memory, scenarios, threads, and approvals carry explicit scope.

9

Autonomy is earned

Prepare first, approve next, execute only with sufficient data, permissions, controls, and recovery.

Current gate

Gate A passes. Correct the visible Undo, primary choices, batch/serving labels, X-ray certainty, readiness, and zero-coverage payoff; then rerun the 430px journey.

Next seams

Discover the ChefTec publish path while validating one sellable-item build and planning one invoice payoff. CTB implementation is conditional, not assumed.

Simulation + sensory policy

Choose named cost basis, access, staleness, source standards, unsupported axes, and chef-correction measures.

Later truth requirements

Location contamination, R&D trial quality, and purchasing approval are tested only with authorized demand, inventory, and offer inputs.

Success: instrument every checkpoint—coverage gain, affected-artifact precision, action/Undo, scenario usefulness and rerun, sensory correction, context errors, location contamination, trials, and purchasing approval—while never pretending to know what the kitchen has not taught Mise.