Catalogue 002: Communal Foundation

What it is.

• Communal Foundation incubates proprietary technology systems.
• It publishes the Food API specification.
• It applies the Universe API.
• Argelys Samuel Oriach is the author and owner of both.
• It works with companies by inquiry: licensing, consulting, and acquisition.
• This page names no company. It is not a proposal to any company.

Distance is the cost.

Many meal delivery companies cook in a few large kitchens and ship far. Three things follow from that.

• Time and temperature. A meal that travels farther spends longer in transit. More can go wrong with the cold chain.
• Menus the kitchen cannot keep. A menu set far from the kitchen can promise meals that the kitchen cannot make that week.
• No local presence. The company has customers in a neighborhood. It has no standing there.

These follow from how the delivery area is drawn. They do not follow from the food.

Draw the map differently.

The Food API draws the delivery area as nodes. A node is one neighborhood. Each node belongs to the nearest kitchen hub that can reach it inside the delivery window.

For any address it answers one question. Which table is this, which kitchen serves it, and what can that kitchen send here this week?

Address→Node→Hub→Menu this week

Address→Node→No hub in reach→Waitlist. No menu.

What a company gets

1. Shorter runs. Each node is served by its nearest reachable hub. Distance is part of the rule.
2. Menus the kitchen can keep. A node's menu is what its hub can cook and deliver that week. No more. The hub reports its capacity and the menu follows it.
3. Meals are designed for ZIP codes. A neighborhood often spans several ZIP codes, and a region spans many. Every ZIP code a node covers gets at least one meal designed for it, and the node's menu draws on those meals.
4. A map for the next kitchen. A node with no hub in reach is a waitlist. It records demand where no kitchen reaches. A new hub turns the waitlist nodes in its ring into live nodes.
5. Local pages that stay true. Every neighborhood page is generated from the node's record. None is written by hand. The page cannot disagree with the kitchen, because both read the same record.
6. Pay that can be read. Each order names where every dollar goes. The ledger works out what each chef and each farm is owed from the orders.

That is the value proposition. One record per neighborhood. One kitchen per record. The menu follows the kitchen.

Six records

Everything else is built from them.

1. Node. One neighborhood. Its boundary, its hub, its delivery window, and its status: live or waitlist. Its ZIP codes and its region. Its AMI index, its Standard price cap, and its tier ratio.
2. Hub. One kitchen. Its location, weekly capacity, delivery reach, and the nodes in its ring.
3. Chef. One cook working from a hub. Their meals and their share of each order.
4. Meal. One dish. Its chef, ingredients, allergens, shelf life, and how many the hub can make. Its tier: Standard or Premium. The ZIP codes it is designed for.
5. Route. One delivery run from a hub to a set of nodes, on a set day.
6. Order. One purchase at a node. It names the meals, the route, and where each dollar goes.

Two tiers

Every meal is Standard or Premium. Each node caps its own Standard price.

The cap is indexed to the regional Area Median Income (AMI) that the node sits in. Every node in a region shares that baseline, so a neighborhood differs by its tier ratio and its hub. Premium has no cap.

standard_price_cap=ami_index×τ_threshold

No value of τ_threshold has been set.

Node record: added fields

ami_index	The regional Area Median Income (AMI) the node sits in, from the housing agency's published figure. The baseline.
standard_price_cap	The most a Standard meal can cost at the node. ami_index × τ_threshold.
target_tier_ratio	The share of the node's menu that must be Standard. Set from the node's purchasing power. For example, 60% Standard, 40% Premium.

Meal record: added fields

tier_class	STANDARD or PREMIUM.
ami_compliant	True when a Standard meal's price is at or below the node's standard_price_cap.

Built on the baseline

The Universe API sets six rules. The Food API follows each one.

1. Closed-loop systems. The hub reports what it can cook. The menu follows. The orders return to the kitchen.
2. Sovereign logic. Each node is governed by its own record. A central menu does not decide for it. The record sets the node's pricing from local AMI. Standard meals stay within reach of the neighborhood. Premium margin carries the network's overhead.
3. Asset-based leverage. The hub is the asset. Each new hub makes live the nodes in its ring.
4. First-principles engineering. One question per address. Which table, which kitchen, what this week.
5. Organic, unforced growth. A node with no kitchen is never sold a menu. It waits until a hub reaches it.
6. Infrastructure that compounds, not extracts. Every dollar of an order is named and paid to the chef and the farm. No neighborhood is priced out. A hub cannot fill a lower-AMI node's menu with Premium meals alone.

What it takes.

The model is simple. Running it is not. A company that already runs licensed kitchens and delivery routes has met most of this list. The Food API adds the model that joins them.

Deployment requires

Data	One unit for a neighborhood, with boundaries. Hub locations and weekly capacity. A chef roster. A menu with a limit per meal. The regional Area Median Income each node sits in.
Kitchens	Licensed commercial kitchens as hubs, with cold storage and a packing line.
Delivery	Couriers or vehicles for each route. Packaging that keeps food cold for the whole run.
Software	Ordering and payments. Route planning. A page generator for nodes. The six kitchen tools.
Compliance	Food safety permits for each hub. Allergen and date labels on every meal. Tax collection per state.
Economics	A measured break-even for each hub's ring: how many orders it must place each week to pay for the hub. That number is not known.

Six kitchen tools

What each hub runs. Each reads from the records and writes back to them.

• Production boardThe week's orders grouped by tier, meal, and chef, so the kitchen cooks to demand. Batches meet each node's tier ratio without yield waste.
• Label and packOne label per meal: node code, chef, ingredients, allergens, use-by date.
• Cold chain logTemperature recorded in storage and in transit, for every batch.
• DispatchGroups packed orders by node and puts the nodes in route order.
• Capacity feedThe hub reports what it can cook next week. Each node's menu updates from it. No Standard meal is listed above the node's standard_price_cap. A menu below its target_tier_ratio of Standard meals does not publish.
• LedgerWorks out what each chef and each farm is owed from the orders. It balances margin across the tiers. Standard orders run on volume and access. Premium orders run on margin. Every payout shows what came from each.

Three ways in.

• Technology licensing. The Food API and the Universe API. Terms by inquiry.
• Consulting. Communal Foundation applies the Universe API to a company's infrastructure. Terms by inquiry.
• Asset acquisition. Acquisition of a named asset. Terms by inquiry.

The smallest working unit is one hub and the nodes in its ring. A pilot is that unit. It measures the one number the specification does not have.

Known. Not known.

This page states what the specification says and what has been run. Nothing has been run.

Specification

System	Food API
Status	Specification. Not deployed.
Live endpoint	None
Metrics	None. Nothing is running.
Break-even per ring	Not known
τ threshold	Not set
Tier ratio per node	Not set
Author and owner	Argelys Samuel Oriach
Published under	Communal Foundation
Catalogue	Seven Eighty Three, entry 002
Rights	All rights reserved. No license is granted by this page.
Licensing and acquisition	By inquiry

Not affiliated with any meal delivery company. Nothing on this page is an offer.

Read the Food API specificationRead the Universe APICommunal Foundation