Summary Table

• Maintainer(s): Valueflows collaborators (https://valueflo.ws)
• Domain: Economic networks
• License: Creative Commons Attribution-ShareAlike 4.0
• Maturity: Version 1.0.0, Production (limited) and In-process
• Governance: Informal consensus
• GitHub/Docs: https://codeberg.org/valueflows/valueflows

1. The Problem It Solves

On many farms these days, there are lots of software applications that can’t be integrated with each other.  Also farm applications can’t just send information or requests to other organizations in their network, for example marketplaces or food hubs or suppliers.  In more and more countries, every link in a supply chain will need to feed data into a trace of what has gone into their products, sometimes called a Digital Product Passport.  That’s hard when software applications don’t talk to each other or the data is not compatible.  People in ag are often the best stewards of their land, but it is hard with existing software, which doesn’t have ways to integrate ecological data with farm data so that eaters can see the provenance of their food and its effects on our world.

The bottom line: Valueflows is designed to connect resource flows of all types wherever they lead, backwards or forwards, to provide the data needed to coordinate the flows, and understand what went into our food and what effects we have on the earth our home.

2. What Valueflows Is

Valueflows is an ontology (vocabulary) for the distributed networks of the next economy, to coordinate the creation, distribution, and exchange of economic resources. It plans and records resource flows connecting many agents (people, organizations, ecological agents). It pays extra attention to experimental and solidarity economic networks, while still fully supporting conventional businesses and supply chains.  For example, it is designed to support

• coordination of economic activity both inside and between organizations, an enterprise is not assumed;
• reciprocity with or without money, money is not assumed;
• ecological agents as part of the network; externalities documented as resource flows.

Valueflows uses a general economic model, but is very much suited to food and ag, including farm operations and food distribution.  As a flow-oriented model, Valueflows can coordinate whole networks as easily as operations of one organization, including regions and circular economies.  But it also works well for individual farms and other organizations.

The effort came out of a “movement” among software developers around 2015 called the open app ecosystem, which emphasized smaller open source apps that could be assembled into suites of software for organizations and networks, with interoperability.  A group of developers interested in economic software got together and birthed Valueflows as one piece of the glue for that puzzle.

A core influence is the REA (Resources, Events, Agents) ontology developed in academia starting in 1982.  REA provides a simple and elegant model for planning and recording real-world economic activity with any material or service flow, as opposed to only those flows that are monetized – expenses, income, assets and liabilities –  although those can be derived. To REA we have added some concepts found in various economic groups (for example recipes for planning work, offers and requests), and ecological accounting, as well as made the ontology more implementation-ready and friendly to distributed protocols.

3. Why It Matters: For Farmers and Supply Chain Players

• Time savings and data accuracy due to interoperability within food/ag networks, like the rest of the standards here.
• Supports creating a library of “recipes” combined into “blueprints” by type of farm, to help farmers get going with Valueflows-based operational software; farmers can feed back into the library too, building a shared commons.
• Supports connected resource flows from the beginning to the end of the value chain, giving “provenance” information for food products at any stage, for health tracing and for information eaters want to know (locality, sustainability, etc.).
• Able to track ecological flows along with production and distribution flows, also can be integrated with a sensor ontology, giving better feedback for regenerative farming.
• Supports supply chains well, because of the connected resource flow information.

4. Why It Matters:  For Developers and Product Owners

• Valueflows does not seek to compete with existing farm or food hub software, nor existing food ontologies, rather to help with interoperability.  One specific case: there is farm software under development (see GrowGood below) which will have a Valueflows api, and aims to be interoperable with the GOAT community of applications and standards.
• Valueflows can add flexible track/trace capability to existing food ontologies, and supports any configuration of network or supply chain.  It can also support farm-adjacent economic flows, such as farm equipment, or non-food products created on-farm like soap or textiles.
• We propose a renewed mapping between Valueflows and DFC, first for creation of a translation layer, and then for mutual enhancement by considering how to blend the vocabularies  (We did a mapping a few years ago, it needs updating.)  The same could apply to FarmOS / CFC, where there are differences with DFC.  We would like to contribute to strengthening the semantic interoperability across the broader open agricultural technology ecosystem.

5. Getting Started (The “Toolbox”)

• Main website with specification and supporting documentation
• Fun introduction to Valueflows, the pie story (yum!)
• Repo is on codeberg, also mirrored on github
• Issues welcome on codeberg
• Say hello or ask questions in the matrix element welcome channel

6. Governance and Alignment

During the initial years of heavy development, generally 5 – 15 volunteer contributors made decisions with informal consensus.  The people were drawn together by a desire to support more fair and sustainable economic experiments on the ground, and to help facilitate the open source software commons for these groups.  Once the first versions were published, the focus turned to getting experience by helping new Valueflows-based software projects, which has been a slow process.  Bob Haugen and Lynn Foster of Mikorizal have been the primary maintainers in recent years, bringing back learnings to the ontology, with the help of its open source community.  Several cycles of learning occurred before the first stable release in Feb. 2026, v1.0.0, with more to come.

We look forward to bringing more formal governance and organization, bringing together maintainers, users, and developers working in separate technical ecosystems.

7. The Ecosystem

This page in the Valueflows appendix lists most of the open source implementations.  It includes more kinds of applications than food/farm apps.

Most relevant apps for food/ag:

• GrowGood, an operational farm app with integrated sensor data, with plans to network within food networks using Valueflows and JSON-LD (in development), and plans to develop the farm blueprint library mentioned above.  We have talked with OFN, and would like to be able to interoperate with OFN as a farm source.
• New York Carbon Farm Network, a textile supply chain from farm (sheep/alpaca) to yarn for a textile designer cooperative, planning video (28 minutes)
• ThePivot.Earth is coordinating a project just starting in the Fraser Lowland bioregion, focused on food and regeneration.  We expect this to solidify a part of Valueflows left out of v1.0.0 as not tested enough: support for bioregional and community level planning and analysis for food anti-fragility.

The Problem It Solves

The agricultural sector faces a significant challenge: data is often collected and stored in diverse, incompatible formats across different farms, organizations, and software tools. This fragmentation makes it difficult to:

• Share data effectively: Collaborating on projects, reporting to funders, and participating in research initiatives becomes cumbersome and error-prone.
• Integrate systems: Connecting different farm management software, analysis tools, or data platforms requires custom, time-consuming development of APIs.
• Ensure data quality: Without common standards, validating data consistency and accuracy is difficult.
• Gain broader insights: Aggregating data for regional analysis, benchmarking, or developing predictive models is often impractical.

What are Common Farm Conventions

Common Farm Conventions provide a solution by establishing a shared data model on how to structure and describe agricultural data for specific purposes. Think of them as blueprints for data exchange.

Instead of rigid, one-size-fits-all global standard, Conventions offer a flexible approach:

1. Built on a Common Foundation: They leverage the robust and widely adopted farmOS data model for the core concepts (Assets, Logs, etc.).  This model is proven to work for a very wide range of agricultural applications.
2. Leveraging JSON Schema: Conventions are defined using JSON Schema, a powerful standard for describing the structure and constraints of JSON data. This provides technical advantages like programmatic data validation across most programming languages.
3. Modularity and Extensibility: The “base” Common Farm Convention broadly describes many typical farm records (planting, harvest, etc.) so each group isn’t reinventing the wheel.  However, groups can then create “child” conventions, inheriting from and extending that base, tailoring it to specific needs without losing compatibility.

Why It Matters

For Project Managers & Data Managers:

• Improved Data Quality: Built-in validation rules ensure data consistency and completeness from the start.
• Simplified Collaboration: Easily share and receive data with partners who adhere to the same conventions.
• Streamlined Reporting: Standardized data formats make aggregation and reporting more efficient.
• Clear Documentation: Conventions come with human-readable documentation generated directly from the schemas.

For Developers & Technical Teams:

• AI Ready: Modern LLMs are extensively trained to generate, modify, and test JSON Schema and can accurately create synthetic data to test edge cases.  A great mix of human and machine readable.
• Robust Validation: Leverage JSON Schema tooling for automatic data validation in applications.
• Interoperability: Easier integration between systems that understand the same conventions. Reduces the need for custom data mapping.
• Machine Readability: JSON Schema provides a clear, machine-understandable definition of the data structure.
• Auto-Generated Documentation: Reduce the burden of writing and maintaining data format documentation.
• Extensibility: Create project-specific conventions that build upon the common base, promoting reuse and reducing redundant effort.
• Alignment with Modern Practices: Uses well-established web standards (JSON, JSON Schema).

Getting Started (The “Toolbox”)

Ready to adopt or contribute? Here’s where to start:

• Documentation & Wiki: The Common Farm Conventions Wiki walks through the rationale, structure, and usage of conventions, including guides for both adopters and contributors.
• Browse Existing Conventions: The project already includes conventions for common farm activities: field definitions, plantings, tillage, harvest, fertilizer and lime applications, irrigation, seed treatments, soil lab tests, mowing, grazing, solarization, and more. Browse them in the Conventions section (this is the “field” convention) of the wiki.
• Create Your Own Convention: The wiki includes a guide on both “How to Convention” (the very human process of data consensus) and how to set up a convention (the technical process of building and deploying a convention)  you actually create a convention.
• Join the Community Call: The Common Farm Convention community meets on alternate Thursdays at 1:00pm EST, right after the farmOS developer call. Meeting link: https://meet.jit.si/farmos-dev. Check the farmOS forum for the latest schedule and notes, or just post to introduce yourself and your needs.
• Contribute: As a GPL-3.0 project hosted on GitLab, contributions are welcome — whether that’s proposing a new convention, refining an existing schema, improving documentation, or building tooling. Open an issue or submit a merge request on the project repository.

Community-Driven, Practically Governed

Common Farm Conventions grew out of a practical need: organizations in the OpenTEAM ecosystem wanted to share data. Rather than imposing a top-down specification, the conventions process is collaborative and iterative — shaped by the developers, researchers, and agricultural organizations who actually use the data.

The Common Farm Convention “Base” model is managed by Our Sci in partnership with Mike Stenta and the FarmOS community.  While it is heavily influenced by the FarmOS data model, and often what makes sense for FarmOS also makes sense for the Common Farm Convention “Base” model, that isn’t required.  Ongoing discussion happens on the farmOS community forum and biweekly Convention calls. Proposals for new conventions or changes to existing ones are discussed in community meetings, tracked as issues on GitLab, and refined through merge requests. The goal is to keep the process lightweight enough that real-world projects can move quickly, while maintaining enough rigor that the conventions remain useful and trustworthy across organizations.
 

The Ecosystem

Common Farm Conventions are currently used by or integrated with the following projects and platforms:

• farmOS – The open-source farm management platform whose data model provides the foundation for all conventions.
• SurveyStack – A data collection platform by Our Sci that uses conventions to structure farm data entry and push records into farmOS.
• Pasa Sustainable Agriculture – Pasa’s Soil Health Benchmark Study uses SurveyStack and farmOS conventions to collect standardized management records from 150+ farms across the Eastern US.
• Point Blue – Point Blue is using conventions along with FarmOS for their Range C and Crop C Programs, and evaluating its use in additional data sharing opportunities.

The Problem It Solves: Standardizing Data Practices and Enhancing Trust

Shared data is critical to understanding the complex agroecological systems at the heart of producers’ activities and livelihoods. It should be stewarded with care, for the benefit of the producers and organizations who provide it, and often data should not be openly shared at all. However, for organizations and researchers who collect and use this data, there is no particular standard of care; instead, there is a patchwork of regulations and practices which are difficult for producers to understand and trust. The result is a default lack of trust, which slows the crucial collection of accurate data that is necessary to understanding these systems.   .

The Better Deal for Data provides a shared set of principles that can be adopted by and between nonprofits, government agencies, socially minded for-profits, and the people and communities they work with. It prescribes a practical set of norms for safeguarding their data, and using it to their benefit, not to exploit or harm them. A straightforward set of commitments, made to individuals and organizations by those who collect and use their data is at its core. It provides a standard not just for agricultural data, but one that can be used across sectors by any organization holding the sensitive data of its community.

In adopting the Better Deal for Data standard, organizations demonstrate that their data stewardship is worthy of the trust of individual producers and their communities. With widespread adoption, it will become a recognized standard for ethical data practices,enhancing trust by signifying an organization which can be depended upon to act in producers’ interests.
 

What the Better Deal for Data Is

In our work around the globe, Tech Matters heard repeated stories of data being misused to the detriment of producers: to charge them more for inputs, to pay them less for outputs, as the basis of a legal suit, or to provide negotiating leverage in land transactions. As we explored the problem, we recognized that this issue isn’t unique to agriculture; there is a widespread need to protect sensitive data from misuse.

At the same time, agricultural researchers were expressing the difficulty of obtaining producer trust – trust critically needed to collect the data essential to better understanding the relationship between farm practices and outcomes. The activities of “big tech” in extracting and monetizing user data have only increased the suspicions of individual producers.

The Better Deal for Data provides a set of commitments which can be adopted by data stewards to signal trustworthiness while legally binding them to ethical practices. It is based around the idea of “no surprises”: if someone provides you with data in the context of your activities and relationship, they should not be surprised by how you are using that data. This requires both transparency and community dialog.

The BD4D Standard comprises seven commitments, made by an organization to those whose data it touches, together with explanatory text providing additional nuance and explanation for each. The commitments, by design, are simple:

• Purpose. We are using Your Data to benefit You, your community, humanity, and the planet, not for private gain or profit.
• Ownership. We don’t claim ownership of Your Data.
• Control. We will delete Your Data, correct it, or transfer it to You if You ask.
• Monetization. We will not monetize Your Data by providing it to third parties for compensation.
• Protection. We will steward Your Data with care, and comply with applicable data privacy laws.
• Research. If we or a trusted partner do research based on Your Data, we will follow best practices around the anonymization of personal data, and published research papers or reports will be made available to You for free.
• Binding. We will be legally bound by these Commitments, and anyone we share Your Data with will be similarly bound.

Why It Matters: For Farmers and Supply Chain Players

Producers can use the Better Deal for Data to:

• Rapidly identify organizations which can be trusted to receive and hold their data.
• Use BD4D adoption as a signal of an opportunity to reduce the burden of careful attention to the fine print of privacy policies and software licenses.
• Start a conversation with any potential data partner: If you haven’t adopted, why not? What are you doing with my data that would surprise me?
• Ensure that if they want to back out of a data sharing relationship, they can do so – they have the right to get a copy of their data and then have it deleted.

Why It Matters:  For Developers and Researchers

Many software developers and agricultural researchers will already have goals and practices that align to the Better Deal for Data. Adopting the BD4D standard provides the framework to intentionally assess these practices, allowing these organizations to:

• Clearly communicate their values and commitments to their users/research partners.
• Receive data from other BD4D adopters when community goals are aligned.
• Share data with other BD4D adopters when community goals are aligned.
• Spark internal discussions to align values with legal agreements and commitments.

Getting Started (The “Toolbox”)

Interested in adopting the Better Deal for Data?  There are a variety of resources to help you:

• Primary website: bd4d.org provides the primary entry point for all resources.
• BD4D Standard: the full text of the current version of the BD4D standard can be browsed (HTML) – or downloaded (PDF) from a button at the bottom of that page.
• BD4D Playbook: the Playbook provides an operational guide for any organization considering adoption, including:
  • Sample Use Cases
  • Adoption Guide (Readiness, Implementation, BD4D in Practice, Adopter Resources)
  • Snapshots from adopters
  • Glossary
• Research Publications: includes both Research Papers, reviewing and contextualizing academic work in data stewardship and data governance, and Major Questions essays, exploring some of the thornier questions raised by the BD4D community.
• Community: join the mailing list to get the latest information and track updates to the Standard and the availability of additional resources.
• Events: meet other adopters and BD4D maintainer staff at various events.
• FAQ: the Frequently Asked Questions section provides additional information about BD4D.
• Contributions / Help: reach out via email with your ideas, or ask and we’ll answer any questions or connect directly!

Governance and Alignment

Version 1.0 of the Better Deal for Data Standard was co-created through a collaborative community process led by Tech Matters, a California nonprofit. This coalition comprised more than 50 individuals and organizations. The Standard was released under a Creative Commons license for all to use. Funding for BD4D has come from:

• Foundation for Food & Agriculture Research
• The Patrick J. McGovern Foundation
• Okta for Good
• OpenTEAM (with support from USDA)
• Schmidt Futures
• The Skoll Foundation
• Splunk

Tech Matters actively seeks feedback and suggestions from all. As adoption proceeds, we hope to more formally include the adopter community in governance.
 

The Ecosystem

The Playbook contains snapshots of BD4D adoption, including:

• Terraso Privacy Policy and Terms of Service
• The Soil Inventory Project Data Use Policy

The BD4D Blog also provides stories of community engagement, including:

• Why Cadasta is Endorsing (link to Cadasta blog)

The Problem It Solves

Small-scale farmers and short supply chain platforms operate in a state of “forced isolation.” While industrial food systems use massive, centralized databases, local food systems are fragmented across dozens of independent tools (the many competing CSA, foodbox, ecommerce, and food hub / farmers markets apps, currently used across the sector).

This creates a cooperation tax: every time a producer joins a new platform, they must manually re-enter their entire catalogue. For developers, connecting two platforms requires expensive, custom-coded bridges. This fragmentation doesn’t just waste time, it limits the ability of the “local food and farming” economy to compete with industrial giants.

The Data Food Consortium (DFC) exists to drive a change of scale for short supply chains. By providing an open technical infrastructure, we allow operators to cooperate more effectively, pool their resources, and reduce their overhead. Our mission is to move from a collection of silos to a coherent digital system where producers can find new markets easily and share or reuse their data as they see fit.
 

⚡ The Bottom Line: We shouldn’t have to choose between digital efficiency and local autonomy. Interoperability turns a collection of silos into a resilient, distributed network.

What the DFC Standard Is

Born in 2017 from a collective of French food-tech pioneers, and spearheaded by the Open Food Network, the DFC Standard is a technical infrastructure for the Digital Commons. It is more than an API; it is a shared “Ontology”, a specialized vocabulary that allows different software to understand exactly what a “producer,” “product,” and “offer” are in a local food context.

By using Semantic Web (Linked Data) principles, DFC enables a “Distributed Web” for food. It allows data to flow securely (utilizing OpenID Connect to secure all data exchanges) between platforms while letting each platform maintain its own unique business model and technical stack.

Why It Matters: For Farmers and Supply Chain Players

• End the Data Entry Loop: Update your price or availability once on your “home” platform and have it sync automatically with every other DFC-compatible marketplace you use.
• From Lock-in to Sovereignty: You are no longer “trapped” in a piece of software because your data is stuck there. DFC makes your data portable, giving you the power to switch tools without losing your history.
• Strength in Numbers: By joining a DFC-aligned network, you become part of a larger ecosystem. Small producers gain the logistical efficiency of a large distributor while remaining independent.

Why It Matters: For Developers and Product Owners

• Built for Decentralization: DFC was designed specifically to bridge the gap between “closed-software” and “open-source” models, allowing diverse projects to cooperate at the infrastructure level.
• Semantic Foundations: Built on Linked Data principles, the DFC ontology ensures your data is both human-readable and machine-processable
• Pragmatic Semantic Web: Leverage the power of RDF and ontologies without the steep learning curve. DFC provides the “Shared Vocabulary” so you don’t have to reinvent the food supply chain model from scratch.
• Reduce Integration Debt: Instead of maintaining ten different API integrations for ten different partners, you implement the DFC standard once to connect with the entire consortium.

🔧 Get Started: View the DFC Ontology and Connector Libraries on GitHub.

Getting Started (The “Toolbox”)

Ready to stop building silos and start building the ecosystem? Use these resources to get started:

• The Technical Standard & Ontology: Explore the formal definition of the DFC data model and semantic rules on the Official DFC Standard Documentation.
• The “Quick Start” Connector: If you are a developer for an existing platform, don’t start from scratch. Use the DFC Connector Library (available in Ruby, PHP, and JavaScript/TypeScript) to interface your application with the DFC network.
• Explore Our Taxonomies: Browse and search our collaborative taxonomies (in English) through the DFC ShowVoc platform. To request changes to our taxonomies, create an issue here
• Connect with the Community: The DFC is a living project. Engage with the maintainers and other platform owners via the Data Food Consortium GitHub, join our Slack workspace; or contact us by email.
• Join a Working Group: We welcome you to join our recurring coordination meetings: General Coordination (FR): Bimonthly, Thursdays @ 11:00 CET; Global Governance (EN): Every 4 weeks, Thursdays @ 12:00 CET.; Ontology Team (EN – Technical): Bimonthly, Tuesdays @ 15:00 CET.
• Contribute: As an AGPL-3.0 project, we welcome pull requests. Whether you are fixing a bug in a connector or suggesting an update to the ontology, your contribution strengthens the Digital Commons.

The “Codesocial”: Democratic Commons-based Governance

The DFC began with a simple question: “How can we make cooperation easier between value-driven projects?” Unlike industrial standards like GS1 (which are governed by global corporations and impose requirements designed for industrial-scale logistics, like mandatory barcoding) the DFC is a Digital Commons.

It is governed by an association of developers, producers, researchers, and grassroots food-system leaders. This ensures the standard remains a “public good,” prioritizing the needs of short supply chains and ecological transitions over the interests of large-scale industrial incumbents. You can find our charter here. Consult the Getting Started (The “Toolbox”) section for details on how to raise issues, make contributions to the taxonomies, or propose feature/functionality requests or improvements.

The Ecosystem

Currently the following platforms have integrated into the DFC standard ecosystem:

• Socleo
• Open Food Network
• Shopify (see DFC Shopify apps repo here)
• Big Barn
• Ooooby (in progress, paused)
• Ordle by Cambridge Organics (in progress)
• Provisions.coop
• LiteFarm
• Locavora