FND

More

What we’re researching, and how it’s built.

The case for coordinated local supply, and the technical approach underneath it.

The problem, plainly

Local food is full of data: what is being grown, where, how much, when it will be ready, what it costs to produce, what it cost to sell. The data exists. It just lives in seven file formats across forty disconnected spreadsheets, three POS exports, two newsletter inboxes, and a clipboard on a barn door.

Every existing answer to this is a platform. The producer enters their data into someone else's schema, which lives on someone else's server, which charges a subscription that grows with success. The data is no longer the producer's; it is the platform's. Most of these platforms close within five years and the data goes with them.

The other answer, file-shipping between operations, solves the wrong problem. You can't coordinate a local food system on PDF attachments. Files are snapshots. Coordination requires references that stay current, are understood the same way by every reader, and survive when any one participant changes their software.

Adjacency map - fragmented local food data sources

The approach, walked step by step

The thing FND is building is not a platform. It is a small, well-defined coordination grammar, a way of describing what a local food operation has and needs that is the same wherever it is read, plus a runtime that lets operations exchange references to each other's real-time state without giving up ownership of their data.

The grammar is self-describing. Anything written in it includes its own definitions, so a reader new to the system can interpret a message without consulting an external schema registry that may not exist next year. That part is the Mycelial Ontological Schema; the long-form is linked below.

The runtime is shape-addressed. A reference does not point at a row in a database; it points at a structure ("a Friday CSA slot for 12 customers in the 44106 zip code with the produce list still pending") and resolves to the operations that currently hold that shape. Operations come and go; the shape is stable.

The interoperability is structural rather than negotiated. Two operations do not need a bilateral integration agreement to talk; they need to speak the same grammar. The cost of joining the network is the cost of describing your own operation correctly, which you have to do anyway.

The result is that the local-food coordination layer can grow node-by-node without a central authority. The software is real today; the network it can become is being built toward one operation at a time, opt-in always.

Reinforcing loops in the coordination model

Further reading

Inline depth links. Each one is its own article in the archive.

Code and explainers

github.com/Fruitful-Network-Development

YouTube explainer videos are added as recordings exist; the GitHub org is the source of truth for the work that is shippable today.