# 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

| Activity | Weekly minutes |
|---|---:|
| Weekly forecast review | 5 |
| BUN delivery receipt | 6 |
| POTATO delivery receipt | 4 |
| GREENS delivery receipt | 6 |
| SODA delivery receipt | 2 |
| Inventory exception review | 5 |
| Invoice exception review | 5 |
| Capacity/fallback review | 5 |
| Supplier messages | 6 |

**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.