Coordination cost gate

Gate 13 — Coordination Cost

Status: PROVISIONAL PASS ON DESIGN / empirical validation OPEN

The local-node architecture only works if independent suppliers remain easier to coordinate than the labour they replace.

The failure mode is simple:

> save three hours in food prep, then lose five hours to messages, shortages, invoices and supplier chasing.

Therefore coordination is treated as a measurable production cost.

Reference target

For a five-opening-day week with BUN, POTATO, GREENS and SODA nodes:

Routine owner/operator coordination target: <=45 minutes/week.

Current modeled reference budget: 44 minutes/week.

This target excludes genuine rare emergencies, but it does not exclude normal receiving, forecast approval or routine exception review.

If real routine coordination consistently exceeds 60 minutes/week, Gate 13 reopens.

If it exceeds 90 minutes/week, the node architecture receives a FAIL until simplified.

What the operator should NOT routinely do

The reference system should not require the family operator to:

• phone four suppliers every week;
• manually type recurring orders;
• maintain four incompatible spreadsheets;
• chase order acknowledgements;
• compare invoice lines by hand;
• manually update “burgers remaining” from supplier stock;
• ask suppliers repeatedly how much capacity they have.

Those tasks belong in a shared thin coordination layer.

Minimum coordination layer

This is not a marketplace.

It does not need to own:

• the supplier;
• the restaurant;
• the transaction relationship;
• a permanent percentage of trade.

It only needs to coordinate a small set of state transitions.

1. Forecast

100BAD publishes the next seven days of expected demand by node.

Example:

• BUN: 520 units
• POTATO: 78 kg finished-equivalent
• GREENS: 10.5 kg
• SODA: 35 L syrup

The forecast includes buffer but distinguishes:

• expected consumption;
• reserve;
• already-on-hand inventory.

2. Order

System converts approved forecast into a standing/rolling order.

Human approval may remain for:

• large quantity change;
• unusual price change;
• new supplier;
• exceptional holiday/event week.

3. Supplier acknowledgement

Supplier returns:

• accepted quantity;
• delivery window;
• exception if capacity is insufficient.

No operator message is needed when everything is normal.

4. Receipt

On delivery, operator performs one compact action:

• scan/select supplier;
• confirm quantity;
• confirm batch;
• flag condition only if wrong.

Target: <=2 minutes/delivery.

5. Inventory update

Receipt automatically updates projected days of cover.

6. Invoice match

Order + receipt + invoice should reconcile automatically.

Operator sees only mismatch.

7. Capacity publication

Supplier publishes:

• committed capacity;
• currently available additional capacity.

That becomes a Readable Market field.

Modeled weekly coordination budget

Total modeled routine operator time: 44 min/week.

The number is a design budget, not an observed fact.

Coordination cost per combo

At five opening days and 500 sold combos/week:

44 min / 500 combos = 0.088 operator min/combo

At an owner-time value of 200 DKK/hour:

147 DKK/week

or about:

0.29 DKK/combo

This cost belongs in the economic model once observed.

Exception architecture

Normal work should be automated.

Human attention is reserved for exceptions with reason codes:

• LATE
• SHORT
• QUALITY
• NO_ACK
• CAPACITY
• INVOICE
• TRACE
• TEMP
• SYSTEM

Every exception records:

• node;
• timestamp;
• quantity affected;
• resolution;
• human minutes;
• whether fallback was triggered.

This makes “supplier hassle” measurable instead of anecdotal.

Fallback principle

Every critical node needs a prevalidated fallback.

A fallback is not something invented after the bun delivery fails at 10:30.

Reference hierarchy:

BUN

primary local bakery -> backup bakery -> validated frozen emergency bun

POTATO

prep node -> second prep node -> whole-potato emergency process -> validated commercial fry input

GREENS

local grower -> second supplier -> functionally equivalent seasonal substitute

SODA

Zolazu-compatible node -> second syrup node -> commercial postmix -> temporary bottled mode

The purpose is resilience, not forcing every unit to use backup inventory every week.

Standing orders vs dynamic ordering

Most 100BAD demand is unusually readable because the sale ceiling is fixed.

Therefore the default should be:

standing base order + small dynamic correction

rather than:

• rebuild order from zero each week.

Example:

• bakery standing order: 500 buns/week
• system correction: +20 because reservations/seasonal demand indicate likely full sellout plus measured reserve needs

This lowers both supplier uncertainty and operator admin.

Shared delivery opportunity

Multiple small nodes should be allowed to share logistics where that reduces coordination burden without creating a controlling intermediary.

Example:

• bakery van may carry buns plus sealed greens crate from another nearby node;
• shared cold delivery route may serve three 100BAD units.

But logistics ownership should remain separable from market access.

A delivery company can charge for delivery. It should not become the compulsory owner of the farmer-baker-operator relationship.

Coordination dashboard — minimum visible state

The operator should be able to see, on one screen:

Today

• BUN on hand / next delivery
• POTATO on hand / next delivery
• GREENS on hand / next delivery
• SODA on hand / next delivery

Next 7 days

• projected demand
• accepted supply
• shortage risk
• supplier exceptions

Only alerts that need action

• no acknowledgement
• shortage
• quality rejection
• delivery delay
• invoice mismatch
• projected stockout

No “engagement feed,” no supplier chat noise, no marketplace upsell.

Supplier view

Each supplier sees:

• confirmed orders;
• next delivery;
• historical delivery accuracy;
• expected next-four-week demand;
• committed capacity;
• available extra capacity.

This gives the farmer/baker/grower/syrup operator useful demand visibility without handing them a platform dependency.

Human-time accounting

Coordination minutes must be split:

• routine operator minutes
• exception operator minutes
• supplier-side coordination minutes
• logistics minutes
• admin/bookkeeping minutes

The system only passes if it reduces total coordination effort across the network, not merely hides it from the burger operator.

Gate 13 PASS criteria

After four real operating weeks:

1. median routine operator coordination <=45 min/week;
2. no week >90 min without a genuine exceptional event;
3. delivery receipt median <=2 min;
4. >=90% of orders require no operator-supplier message after initial setup;
5. >=95% of invoices auto-match or are handled outside core service labour;
6. every critical node has a tested fallback path;
7. supplier capacity is visible without phone/email chasing;
8. supplier-side admin is acceptable to the supplier;
9. coordination cost is inserted into true per-combo economics;
10. no coordination layer takes compulsory ownership of the commercial relationship.

Falsification

Gate 13 fails if:

• local supply repeatedly causes stockouts;
• supplier diversity creates >90 min routine operator admin/week;
• automatic ordering produces waste because forecasts are poor;
• suppliers need so much system work that the burden has merely moved upstream;
• fallbacks are too expensive to be credible;
• one coordination platform becomes unavoidable and starts controlling access.

Current conclusion

PROVISIONAL PASS ON ARCHITECTURE.

The key insight is:

> Independence does not require manual coordination.

Independent nodes can share a thin common state protocol while still owning their own businesses and direct relationships.

The next research question is no longer “can five suppliers talk to one restaurant?”

It is:

> Can the shared state be simple enough that nobody needs to spend their day talking about routine state at all?

Next gate — Gate 14: Governance + Commons

Define who owns:

• the 100BAD protocol;
• brand/spec stewardship;
• software;
• supplier/operator registry;
• quality test suite;
• dispute process;
• fork rights.

The architecture must protect local ownership without allowing the shared protocol layer to become a conventional franchisor or toll booth.