I Built an ML System to Model a Distributed American Food Supply

FoodMesh-ML uses machine learning, geospatial modeling, optimization, network routing, and simulation to ask whether lawns, community gardens, fruit trees, and local food hubs could form a resilient second layer of the U.S. food system

Code: github.com/Bodhi8/foodmesh-ml

The American food system is extraordinarily good at scale.

A relatively small number of highly productive agricultural regions grow enormous quantities of food. Processing plants aggregate production. National distributors consolidate inventory. Refrigerated trucks move perishable products thousands of miles. Warehouses, wholesalers, grocery chains, and logistics networks coordinate the final mile.

That system has generated astonishing productivity.

It has also created a particular kind of dependency. Most communities consume food they did not produce, processed by facilities they do not control, transported through networks they cannot influence, and replenished from supply chains that may extend across states, countries, and continents.

That does not mean centralized agriculture is a mistake.

It means efficiency and resilience are different optimization problems.

I wanted to know whether there was a useful second layer hiding inside the existing system.

Not a return to subsistence farming. Not a fantasy in which suburban lawns replace Kansas wheat fields. Not an argument that everybody should grow their own food.

Instead, a more technical question:

Could community gardens, residential land, fruit and nut trees, institutional property, urban farms, and local aggregation infrastructure be modeled as a distributed food-production network, and could machine learning tell us where such a network actually adds value?

That question became FoodMesh-ML, an open-source research framework for modeling a hybrid American food supply. The project is now public on GitHub.

The important part, however, is not the repository. It is the modeling problem underneath it.

The Wrong Question Is Whether Local Agriculture Can Replace Industrial Agriculture

The easiest version of this debate is also the least useful.

Ask whether backyard gardens can replace American industrial agriculture and the answer is almost certainly no. Staple agriculture benefits enormously from scale. Corn, wheat, soybeans, oilseeds, and animal feed are produced using mechanization, specialized logistics, storage, infrastructure, and yields that residential production is unlikely to match.

FoodMesh therefore begins with a different hypothesis. Distributed production may be most valuable where the conventional food system is structurally weakest:

• fresh produce
• highly perishable foods
• geographic food-access gaps
• short-cycle production
• supply-chain redundancy
• local shock response
• food that loses significant value as distance, time, handling, and storage accumulate

The repository states its research hypotheses explicitly, and they reflect that distinction directly:

1. Distributed production will not be competitive with industrial agriculture for most bulk calories, grains, and oilseeds.
2. It may be material for fresh produce, selected legumes, berries, fruit, nuts, and other perishables where proximity, waste reduction, and access have higher value.
3. An optimized hybrid system may trade some normal-state efficiency for greater redundancy and lower unmet demand under supply shocks.
4. Geographic targeting may produce larger welfare gains than uniform conversion, because food-access need and productive land are spatially mismatched.
5. Cold storage, aggregation, routing, and harvest synchronization may matter as much as biological yield.

The goal is not to replace the centralized system. The goal is to determine whether a hybrid system dominates a purely centralized one under some combinations of food type, geography, cost, and risk.

The Food System as a Machine-Learning Problem

A national distributed food network is not one prediction problem. It is a stack of interconnected problems.

We need to know where land exists. What that land could realistically grow. What yields to expect. What local demand looks like. Which crops should use limited land. How surplus gets routed. How spoilage and storage behave. And how the whole system responds when part of the conventional food network fails.

Trying to solve all of that with a single machine-learning model would be a category error.

FoodMesh is deliberately hybrid. It uses machine learning where relationships must be learned from data, mechanistic simulation where the physical process is known, and constrained optimization where the actual question is resource allocation.

Conceptually, the system looks like this:

LAND + POPULATION + FOOD ACCESS
              |
              v
      CROP INTELLIGENCE ML
              |
              v
    PRODUCTION FRONTIER
              |
              v
     LAND OPTIMIZATION
              |
              v
 PRODUCTION -> HUBS -> DEMAND
              |
              v
       SHOCK SIMULATION
              |
              v
ACCESS | DEPENDENCY | RESILIENCE

Each layer has a different job.

Layer 1: How Much Distributed Production Capacity Actually Exists?

Before predicting crop yields, there is a more basic question: where could food physically be grown?

Potential production land includes more than suburban lawns. FoodMesh is designed to consider residential open space, community gardens, vacant or underused urban land, schools, churches, institutional property, urban farms, fruit and nut trees, and eventually other perennial food landscapes.

But there is a trap here.

Satellite land-cover data can tell us that land is open. It cannot tell us that the land is socially, legally, physically, or agronomically available for food production.

A patch of grass may be a backyard. It may also be a highway median, drainage area, utility easement, sports field, contaminated lot, steep slope, or land whose owner has no intention of converting it.

So FoodMesh separates observed land cover from modeled plantability. That distinction is enforced in the code through explicit evidence classes:

[O] Observed
[D] Derived
[L] Learned
[C] Calibrated
[A] Assumption
[S] Simulated

If satellite data show that twenty hectares of developed open space exist inside a tract, that is observed or derived. If the model assumes 15 percent of that land is realistically convertible, that is an assumption until empirical evidence justifies something stronger.

That may sound like bookkeeping. It is actually one of the most important pieces of the model. Many large simulations become overconfident because assumptions gradually become indistinguishable from measurements. FoodMesh is designed not to allow that.

The geospatial layer (v0.2 in the repository) builds a tract backbone from Census ACS 2020–2024, USDA’s 2025 SNAP-authorized Retailer Access Map, TIGER/Line geography, Annual NLCD land cover, and gNATSGO soils, with a strict one-to-one GEOID join, a geography-vintage audit, and conservative, moderate, and upper-bound land-eligibility scenarios whose capture factors are labeled as assumptions rather than findings.

As the repo puts it, the resulting acreage is not yet a claim about nationally usable garden land. Version 0.2 exists specifically to expose the gap between measured land-cover classes and empirically validated plantable area.

Layer 2: Crop Intelligence

Once land capacity exists, the next problem is biological. What should grow where?

A crude system uses hardiness zones. A better system uses the interaction of crop traits and environmental conditions.

For crop c at location i, FoodMesh estimates:

Yield(i,c) =
f(
    crop traits,
    temperature,
    precipitation,
    growing degree days,
    frost exposure,
    extreme heat,
    soil,
    water,
    production system,
    geography
)

The first implementation uses tree-based gradient boosting, because the relationships are strongly nonlinear and interaction-heavy. The model does not merely ask whether a crop survives. It tries to estimate usable production.

And that creates an important validation problem.

Agricultural data are spatial. Nearby counties share weather. They share soils. They share agricultural practices. They may even share reporting processes. If observations from the same geographic region appear in both the training and test sets, a conventional random split can make a model look considerably better than it is.

FoodMesh therefore uses grouped spatial validation. The question is not:

Can the model predict another observation from somewhere it has effectively already seen?

The real question is:

Can it generalize geographically?

The framework also supports crop-aware transfer tests, including leave-one-crop-out evaluation, to examine whether the model learned transferable biological relationships rather than memorizing crop identity.

The public repository (v0.3) contains grouped spatial cross-validation, random-split leakage diagnostics, a grouped mean baseline, leave-one-crop-out transfer testing, and 5th/50th/95th conditional quantile models that produce lower, median, and upper yield estimates rather than one falsely precise number.

A Surprisingly Important Problem: A Bushel Is Not a Kilogram

One of the most useful things that happened while building FoodMesh was discovering how easy it would be to create a sophisticated-looking but meaningless crop model.

USDA agricultural yield observations are not reported in one universal unit. Different commodities appear as pounds per acre, hundredweight per acre, short tons per acre, kilograms per hectare, or commodity-specific bushels per acre.

Imagine fitting a multi-crop model where one row contains:

tomato yield = 320

and another:

corn yield = 185

Those numbers cannot be compared until we know what they mean. A model does not understand units. It will happily optimize nonsense.

So v0.4 added a normalization layer that converts supported observations into a common physical target:

kg / hectare

Ambiguous container units fail closed. Commodity-specific bushel weights require explicit conversions.

This is a small implementation detail with large consequences, and the lesson generalizes well beyond agriculture:

Machine learning is extremely good at fitting relationships inside badly constructed targets. Correcting the target may matter more than changing the algorithm.

Commercial Yield Is Not Backyard Yield

There is another domain-shift problem.

Suppose USDA reports that commercial tomato farms in a county produce some number of kilograms per hectare. That observation is useful. But it does not follow that a community garden, backyard plot, school garden, or urban farm will achieve the same result.

The systems differ in management, planting density, irrigation, labor, pest control, equipment, soil modification, crop selection, and harvest intensity.

So FoodMesh does not allow:

commercial yield
=
distributed yield

Instead:

commercial observations
        |
        v
learned environmental response
        |
        v
distributed-production calibration
        |
        v
distributed yield distribution

That calibration table ships empty by design. Until it is populated from defensible distributed-production evidence, the system does not treat distributed estimates as publishable national findings.

This is one reason I have not released a headline number claiming that American neighborhoods could produce X million tons of food. The code is further along than the empirical evidence, and the framework is intentionally designed to preserve that distinction.

Layer 3: The Production Frontier

Once the crop models exist, every tract effectively gets a menu.

TRACT 29095000100

Crop          Median yield   Low    High
------------------------------------------------
Tomatoes      ...
Potatoes      ...
Beans         ...
Greens        ...
Apples        ...
Berries       ...
Hazelnuts     ...

The tract x crop frontier is assembled from land, calibrated yield, edible fraction, harvest capture, and post-harvest retention, not from raw predicted yield.

The important result is not a single predicted crop. It is a production frontier. Each place has several possible futures.

Which means the next question is no longer predictive. It is an optimization problem.

Layer 4: Stop Maximizing Yield

A naive distributed food system would ask: what crop produces the most kilograms here?

FoodMesh asks a harder question. A community does not need maximum kilograms. It needs an appropriate food portfolio.

Tomatoes may yield extremely well. But a city consisting entirely of tomatoes is not a food system.

So the optimizer considers nutrition, calories, protein, water, labor, storage life, harvest timing, crop concentration, climate sensitivity, and correlated production risk:

maximize

nutrition
+ accessible food
+ local coverage
+ storage value
+ resilience

subject to

land
water
labor
climate
seasonality
crop concentration
logistics
cost

This is where the problem starts resembling portfolio theory.

Two crops are not independent assets merely because they have different names. If both fail during the same heat event, they are correlated. If several mature during the same two-week window, they create a synchronized logistics problem. If one stores for five months while another spoils within a week, identical annual yields may have radically different system value.

The optimal food portfolio therefore may not maximize expected production. It may reduce expected production slightly while producing much lower variance in food availability.

That is exactly the kind of tradeoff the optimizer is built to expose. That is why the repository evaluates a Pareto frontier rather than hiding value judgments inside one arbitrary objective weight.

Layer 5: Food Production Is Only Half the System

A garden producing excess zucchini is not automatically supplying a neighborhood. A fruit tree dropping forty kilograms of apples does not mean forty kilograms have entered the food supply.

Production must be captured. Stored. Aggregated. Processed. Matched with demand. And moved.

That turns FoodMesh into a graph.

PRODUCTION NODES

homes
gardens
urban farms
schools
orchards

        |
        v

AGGREGATION NODES

food hubs
community centers
markets
schools
cold storage
food banks

        |
        v

DEMAND NODES

households
institutions
restaurants
schools
food pantries

Edges carry distance, travel time, capacity, perishability, handling losses, and eventually reliability.

FoodMesh formulates this as a min-cost flow problem with hub capacity and retention. The objective is not merely minimum transportation cost:

minimize

transport
+ handling
+ spoilage
+ unmet demand
+ weighted unmet demand in high-need areas

This distinction became important while building the optimizer.

An early design could have made routes into high-need neighborhoods artificially cheaper. That would mix equity policy with transportation physics.

The better formulation keeps physical transport cost physical and changes the penalty associated with leaving demand unmet. That gives an interpretable policy parameter. We can ask:

How much system efficiency are we willing to trade for improved food access?

rather than silently embedding that decision inside a distance matrix.

Layer 6: Food Access Is Not the Same as Food Production

This matters most when the system is connected to actual food-access geography.

The USDA Food Access Research Atlas includes multiple measures of retail food accessibility, including its SNAP-authorized Retailer Access Map and Large Retailer Access Map. The 2025 SRAM uses 2020 Census geography and incorporates 2020–2024 ACS information alongside retailer and population datasets. [1]

FoodMesh therefore does not need to invent a generic concept of a “food desert.” It models spatial need using observed tract-level access indicators, and it deliberately preserves competing access definitions rather than collapsing them prematurely.

But that also exposes a likely mismatch: the communities with the largest amounts of convertible residential land may not be the communities with the greatest food-access need.

That is exactly why optimization and routing matter. A large suburban yard may be capable of producing food. The highest-value consumer of that surplus may live somewhere else.

Distributed production without coordination could reproduce existing inequality rather than reduce it.

Layer 7: The Conventional System Needs a Baseline Too

It would be easy to build a detailed model of local production and compare it against a cartoon of “industrial agriculture.” That would be unfair.

FoodMesh therefore includes a conventional freight baseline.

The Freight Analysis Framework produced by the Bureau of Transportation Statistics and Federal Highway Administration provides origin-destination estimates of U.S. freight flows across modes and 42 commodity categories. FAF6 uses 2022 as its benchmark year. [2]

FAF is not a tract-level grocery-routing system and should not be treated as one. But it gives FoodMesh a macro view of commodity movement against which localization and dependency can be measured.

One metric this makes possible is the Centralized Food Dependency Index:

CFDI =
external food requirement
/
total food demand

A tract could have:

CFDI_calories = 0.97

while having:

CFDI_fresh_vegetables = 0.58

That is precisely the distinction the project is designed to uncover. Distributed agriculture may barely move calorie dependency while materially changing fresh-produce dependency. Those are completely different claims.

Layer 8: Break the Food System

The most interesting part of FoodMesh may be what happens after the normal-state optimization, because resilience cannot be inferred from average performance. It has to be tested under failure.

The framework compares centralized and hybrid systems under shocks such as regional drought, extreme heat, crop failure, transport disruption, fuel-price shocks, distribution-center failure, and correlated regional events.

Local and centralized production are represented as different but correlated stochastic processes:

available food =
centralized supply x centralized shock factor

+

distributed supply x local shock factor

A trucking disruption might strongly reduce the first term while barely affecting the second. A severe regional heat wave might reduce both. A national input shock could affect commercial production differently from a low-input community system.

The relevant metric is not whether local production survives everything. Nothing does.

The question is whether diversification reduces unmet demand across the distribution of plausible failures. That is a resilience problem rather than a lifestyle argument.

The Experiment

The framework defines a set of canonical counterfactuals:

S0  Current centralized baseline

S1  Existing/local production layer only

S2  5% of eligible distributed land converted

S3  10% converted

S4  20% converted

S5  ML-informed, need-aware allocation
    using the same land budget as S3

S6  S5 plus aggregation, storage,
    and routing

S7  Centralized and hybrid systems
    repeated under shocks

The equal-land condition is critical. If S5 uses more acreage than S3, any improvement could simply be the result of using more land. FoodMesh constrains the comparison so the optimization layer has to create value from better decisions, not larger inputs. The national experiment runner records requested versus actually used land, so crop-concentration constraints cannot silently turn a nominal 10 percent scenario into a smaller intervention.

The v0.5 release goes further and compares random, proportional, yield-only, access-need, and access-need-plus-network strategies at a common land budget, rather than attributing all gains to “ML.”

That shared-capacity rule fixed another subtle bug. Suppose one tract has 100 hectares suitable for tomatoes, beans, and apples. A tract-by-crop table might contain:

Tomatoes   100 ha
Beans      100 ha
Apples     100 ha

Without a shared constraint, an optimizer could quietly allocate 300 hectares. The table would be mathematically valid. The geography would be impossible.

FoodMesh now enforces:

sum(crop area within tract)
<=
physical tract capacity

The modeling lesson is broader than food systems. Optimization will exploit whatever mathematical world you give it. If the constraints do not represent reality, the optimizer will become extremely efficient at violating reality.

Measuring the Value of Intelligence

This leads to the experiment I am most interested in. Instead of comparing only centralized vs. distributed, FoodMesh decomposes where the gain comes from:

VALUE OF LAND CONVERSION
S3 - S0

VALUE OF INTELLIGENT TARGETING
S5 - S3

VALUE OF NETWORK COORDINATION
S6 - S5

VALUE OF DISTRIBUTED REDUNDANCY
Shock(S6) - Shock(S0)

A future empirical result could look something like:

Total improvement in local fresh-food coverage

60%  additional distributed production
25%  better geographic allocation
15%  aggregation and routing

Those numbers are illustrative. I do not know what the actual decomposition will be.

That is the point. The purpose of FoodMesh is to discover the decomposition rather than assume it.

What Counts as Success?

A distributed system should not be judged by one metric.

More local food might require unreasonable water. More resilience might require excessive labor. Lower transportation distance might increase total cost. Higher crop diversity might reduce average yield.

FoodMesh therefore reports multiple outcomes:

• Local Food Coverage Ratio (LFCR): how much demand can be satisfied through local production
• Centralized Food Dependency Index (CFDI): how dependent an area is on external supply
• Nutritional Access Gap (NAG): how much required nutrition remains inaccessible
• Resilience Under Shock (RUS): how much demand remains satisfied after disruption
• Perishable Loss Rate (PLR): how much edible production is lost before consumption
• Local Supply Redundancy (LSR): how many independent pathways support demand
• Cost per incremental unit of nutrient access
• Land, water, labor, cost, and emissions requirements

The final answer probably should not be one “optimal” system. It should be a Pareto frontier, so a policymaker, city, nonprofit, or community can see the tradeoff among cost, land, water, labor, localization, nutrition, access, and resilience.

That is a much more honest representation of the decision.

Climate Is an ML Feature, Not a Footnote

Agriculture is fundamentally climate-conditioned. FoodMesh uses NOAA climate data to construct features for temperature, precipitation, frost exposure, heat days, anomalies, and growing-degree metrics.

NOAA’s nClimGrid-Daily product is particularly useful because it provides daily gridded temperature and precipitation plus area averages for multiple geographic units, including Census tracts and counties. [3]

But climate enters twice: first as an expected-yield predictor, second as a source of correlated risk.

Those are different jobs. An average-temperature feature helps estimate normal production. A simulated extreme-heat event helps estimate resilience. Treating them as separate model layers prevents the average-yield model from being mistaken for a full climate-risk model.

Why I Built Publication Gates Into the Code

One of the temptations with a project like this is obvious. You run a simulation. It produces a national number. The number looks interesting. You publish it.

But a national model can easily contain a chain like this: observed land, times assumed plantable fraction, times ML yield, times assumed backyard calibration, times assumed harvest rate, times assumed routing efficiency, times assumed demand, times assumed shock distribution.

By the end, the output may have five decimal places while resting on three poorly measured parameters.

So the repository contains fail-closed publication gates. FoodMesh will not label a national result publishable merely because the code ran. The gate requires adequate real training coverage, no synthetic training rows, a single physical target unit, grouped ML performance above a grouped baseline, complete crop x production-system calibration, comparable scenario budgets, and SHA-256-verified official source files staged locally.

v0.7 adds the execution layer for the first real-data run, recording exact official source endpoints in a source manifest and checking provenance before anything executes. As the README states plainly: a blocked run is a valid outcome. It means the repo is refusing to convert missing, synthetic, or assumption-only inputs into publication claims.

That is also why this article does not contain a headline like:

FoodMesh proves distributed agriculture can supply 27 percent of America’s produce.

I do not have evidence for that claim. The research system exists. The national empirical result does not. There is an important difference.

What Exists Today

FoodMesh-ML is a functioning open-source research prototype at v0.7. The repository contains:

• geospatial data architecture and a tract backbone with provenance auditing
• crop-yield ML with leakage-aware, spatially grouped validation
• yield-unit normalization to kg/ha with fail-closed ambiguity handling
• tract x crop production frontiers
• distributed-production calibration gates
• land-allocation optimization with explicit random and proportional baselines
• tract-level food-group demand accounting
• production -> hub -> demand min-cost flow routing
• food-access-weighted shortage penalties
• FAF6 freight-baseline ingestion and USDA local-food node normalization
• correlated centralized/local shock simulation
• an end-to-end S0-S7 national experiment runner
• reproducibility tests and fail-closed publication controls

Getting started takes about a minute:

python -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
python -m pip install --upgrade pip
pip install -e ".[dev]"
pytest -q

And to see whether the official empirical inputs are staged:

python scripts/check_empirical_inputs.py

Large government datasets are intentionally not vendored in Git.

The next research stage is straightforward conceptually and expensive operationally: stage the national datasets, build the crop training table, calibrate distributed production, run the tract-level frontier, construct demand, populate observed hubs, calibrate shocks, and run the complete national experiment.

That is future work. But building the framework first changed how I think about the problem.

The Real Insight: The Garden Is Not the System

I started this line of work thinking about fruit trees. The obvious question was how much food millions of residential trees might produce.

But the deeper I modeled the problem, the less important the individual tree became. The bottlenecks moved.

From yield to harvest timing. From harvest timing to storage. From storage to routing. From routing to demand. From demand to geography. From geography to resilience.

Eventually the object being modeled was no longer a garden. It was a network.

Which leads to what I think is the more interesting hypothesis:

The future alternative to an exclusively centralized food system is probably not millions of independent people gardening. It is a computationally coordinated hybrid network in which centralized agriculture continues doing what scale does exceptionally well, while distributed production does what proximity, redundancy, and geographic targeting do better.

The lawn is not the system. The fruit tree is not the system. The community garden is not the system. They are production nodes.

The system is the network that decides what gets planted, anticipates what will be harvested, matches surplus to demand, moves food before it expires, and maintains supply when part of the centralized network fails.

That is what FoodMesh-ML is designed to model. And it is a much more interesting machine-learning problem than asking whether everyone should grow tomatoes.

Open Source

FoodMesh-ML is available publicly on GitHub:

github.com/Bodhi8/foodmesh-ml

The current release contains the modeling framework, source code, documentation, test suite, scenario architecture, and empirical execution pipeline. The project is intentionally designed so assumptions can be replaced, challenged, calibrated, and rerun.

If the national model eventually shows that distributed production adds little resilience for its cost, that is a useful result. If it shows that certain food classes can be localized substantially while bulk calories remain centralized, that is useful too. If it shows that food hubs and routing matter more than gardens, perhaps that is the most useful result of all.

A model that begins by knowing the answer is not much of a model.

FoodMesh exists to find out.

References

[1] U.S. Department of Agriculture, Economic Research Service. Food Access Research Atlas and 2025 SNAP-authorized Retailer Access Map documentation. https://www.ers.usda.gov/data-products/food-access-research-atlas

[2] Bureau of Transportation Statistics and Federal Highway Administration. Freight Analysis Framework (FAF). https://www.bts.gov/faf

[3] NOAA National Centers for Environmental Information. nClimGrid-Daily. https://www.ncei.noaa.gov/products/land-based-station/nclimgrid-daily

[4] Curry, Brian. FoodMesh-ML: Machine learning, optimization, and simulation framework for modeling distributed food systems. https://github.com/Bodhi8/foodmesh-ml

The two assumptions I most want challenged are the plantable fraction of mapped open space and the commercial-to-distributed yield calibration. Both are currently labeled as assumptions in the code. Both would change every downstream number. Issues and pull requests are open.

About the Author

Brian Curry is a Kansas City–based AI and Machine Learning researcher, data scientist, and the founder of Vector1 Research, where he works on the intersection of cognitive AI architecture, causal inference, and economic systems. His research introduced Memory-Node Encapsulation (MNE), an original data structure for artificial episodic memory, and the NeoCortex-M architecture for memory-driven AI. He is the creator of Papilon, an open-source framework for complex system optimization with agentic orchestration, PyCausalSim, a Python framework for causal discovery through simulation, and Daedalus, a platform for causal and economic analysis.

His practitioner work focuses on building production intelligence systems — causal marketing analytics, agentic systems, and the serving infrastructure that makes them deployable inside enterprise environments. He writes about that work at vector1.ai and on Medium.