AgEvidence

AgEvidence is infrastructure for turning agricultural operational data into portable evidence that other organizations can inspect, evaluate, and rely on without forcing every buyer, auditor, program, or marketplace to integrate directly into the source system.

Of the 12 claims on the register, 3 rest on a record rather than an argument and 6 are still unresolved. Nothing here is stated more strongly than the evidence behind it allows.

The thirty-second explanation

Agricultural technology companies already produce measurements, intervention records, model outputs, machine events, farm records, and other operational data. The problem begins when that information has to leave the product that created it. A buyer may need provenance. A carbon methodology may need a particular monitoring record. An assurance practitioner may need the source, model version, uncertainty, corrections, and review history. A lender or processor may need a different subset again.

Today those transitions are frequently bespoke. AgEvidence is trying to create a common evidence layer between the technology that creates the information and the institution that needs to use it. Developers can structure evidence through a free SDK. A small deterministic trust layer preserves identity and integrity. A commercial Evidence Plane operates the changing requirements, reviews, statements, sharing, and history that make the evidence useful in production.

The problem in plain English

The same agricultural fact can become expensive every time it crosses an organizational boundary.

A methane measurement is useful inside a measurement product. It becomes a different problem when a retailer wants to use it in a value-chain program, when a methodology wants to test eligibility, when an assurance practitioner wants to inspect the source, or when a processor wants a versioned package it can retain. Each recipient asks a legitimate question, but the source company repeatedly rebuilds context around the same underlying evidence.

AgEvidence is an attempt to make the evidence portable before those downstream relationships become bespoke integrations.

What “evidence” means here

Evidence is not a synonym for data, and it is not a synonym for a claim.

A data point can say that a device measured a value. Evidence carries the information needed to understand what that value is: who or what produced it, when, under what method or calibration, which source record it came from, which model transformed it, what limitations are known, and how it relates to other events.

A claim comes later. A claim interprets evidence for a purpose. A determination records a bounded judgment about whether the evidence supports that purpose. A statement communicates that determination to another party. AgEvidence keeps those stages separate so historical evidence can remain intact even when methods, policies, or judgments change.

A concrete example

Imagine an agricultural technology company that helps a beef producer reduce methane.

The source system may know the intervention product and batch, the cohort that received it, when it was delivered, the dose, who recorded the event, the methane observations, and the model used to turn observations into an estimate. Inside the source product, those records may already be perfectly usable.

A downstream buyer, however, may need a supportable package showing intervention identity, measurement period, source provenance, model version, uncertainty, missing records, reviewer judgment, and qualifications. A methodology may ask for a different profile. A verifier may need to reproduce specific checks. AgEvidence’s intended role is to let the source company represent the evidence once and then evaluate the same historical record for multiple bounded uses without recreating the source history each time.

What AgEvidence is not

AgEvidence is not a farm management system, not a carbon marketplace, not a methodology owner, not an accredited verifier, and not a universal scientific authority.

It is designed to sit between source systems and downstream reliance. It can preserve source identity, lineage, declared model versions, deterministic integrity, explicit gaps, versioned requirements, review history, and bounded statements. It cannot make an inaccurate observation scientifically true, turn an out-of-domain model into a valid one, grant regulatory approval, or create a legal right to a claim.

How a single fact travels

1Something happens. A device measures, an intervention is delivered, a model runs, a producer records an event, or a machine performs an operation.
2The source system represents it. The SDK maps the event into explicit evidence primitives and records provenance rather than turning it immediately into a claim.
3Integrity is established. Canonical representation, hashes, identifiers, receipts, and verification rules make alteration and lineage inspectable.
4A purpose is declared. The same evidence is evaluated against a versioned set of requirements for a buyer, method, program, assurance process, or other intended use.
5Gaps stay visible. Missing, conflicting, stale, or out-of-domain information is surfaced rather than silently coerced into a pass.
6Judgment is attributable. A human or authorized process can review the evidence, record a determination, and state qualifications without rewriting the underlying history.
7A bounded artifact is issued. The recipient receives a package or statement with the purpose, evidence lineage, versions, limitations, review state, and integrity references needed to inspect why the artifact says what it says.

The company in one chain

The map shows the whole company in one chain: market pressure creates an evidence problem; research defines the constraints; a canonical evidence model gives source systems a common representation; the SDK makes that representation adoptable; the trust layer preserves integrity; the Evidence Plane operates institutional use; deployments test reuse; reliance creates the event the business can price; repeated adoption may eventually create a shared market convention.

Every node carries a status. The map is not a maturity diagram: some nodes are built, some demonstrated, some externally supported, and some still hypotheses.

Market pressure → method → system → programme → relianceScroll sideways · tap a node

MaddieScience & method

MatthewTechnology & execution

SarahVenture & systems

— inside one narrative· · across narrativeshighlighted = touches selection

Why the product has three layers

The product separates three questions that are often collapsed.

First: how does an existing agricultural technology represent what it already knows? That is the developer problem, addressed by the Python SDK and common evidence primitives.

Second: how can another party tell whether the represented object is the same object, with the same declared content and lineage? That is the deterministic integrity problem, addressed by the Rust trust layer.

Third: is this evidence sufficient for this buyer, program, methodology, assurance workflow, or statement today? That is an institutional operations problem, addressed by the Rails Evidence Plane through requirements, evaluation, review, determinations, statements, sharing, and version history.

Who pays

The organization creating the requirement does not have to be the first AgEvidence customer.

A retailer, processor, bank, assurance team, carbon program, or reporting entity may create the evidence pressure. The funded agricultural technology company is often the party with the immediate commercial problem: its product has to cross that institutional boundary in order to win a customer, enter a program, support a claim, or shorten an enterprise sales cycle.

The initial commercial thesis therefore starts with funded agtech as the payer and downstream institutions as requirement-setters and recipients. AgEvidence prices the value of making evidence usable across that boundary rather than treating API calls or stored records as the primary unit of value.

What is free and what is paid

The open/free layer exists to make compatibility inexpensive. It includes the evidence primitives, schemas, fixtures, developer tooling, and portable verification semantics needed for an external system to produce and inspect AgEvidence-compatible evidence.

The paid layer exists where recurring operational responsibility begins: maintained program profiles, continuous evaluation, human review, statements, controlled sharing, APIs, retention, integrity operations, policy or program updates, and enterprise support.

The commercial bet is that customers should not have to accept proprietary evidence custody in order to get a reliable managed product.

Current state — without promotional compression

AgEvidence is early.

The canonical evidence model and developer SDK exist. A trust-kernel/verifier path exists and can demonstrate deterministic integrity behavior, while technical diligence still identifies production-hardening work in parts of the trust boundary. The Rails Evidence Plane has been demonstrated as an end-to-end workflow for ingest, evaluation, review, determination, statement generation, and sharing. Verifier results in the commercial Rails app are currently placeholders; independent cryptographic verification is not yet wired into that product.

The market thesis is less mature than the product thesis. Reliance is still a hypothesis to be proven with external parties. Revenue is still a hypothesis; priced reliance is treated here as unproven. Optional portfolio experiments are proposed tests, not completed commercial proof. Standardization is an intended outcome, not a status the company already possesses.

Why Tenacious is in the room

Tenacious is relevant for more than capital because its portfolio spans many of the source and destination patterns AgEvidence eventually needs to serve. That creates a potentially useful early proving environment: different agricultural technologies, different evidence archetypes, and different customer relationships can test whether one narrow evidence contract actually reuses across heterogeneous systems.

The investment case must still stand without portfolio synergy. The portfolio is best treated as an option to accelerate validation, corpus formation, and product experiments — not as captive revenue.

Words used here, defined once

Canonical evidence: A stable structured representation of source facts and provenance intended to survive movement across applications and downstream uses.
Thin waist: A deliberately small shared layer between many heterogeneous source systems and many downstream uses. The goal is to keep the shared contract stable while differences live at the edges.
SourceRecord: A record identifying where evidence originated: a file, device output, system record, registry response, laboratory result, or other source.
Observation: Something measured or observed, together with the context needed to interpret the value.
InterventionEvent: A record that an action or treatment occurred, including identity, timing, subject, dose or other relevant context.
ModelRun: A record of a computational transformation, including model identity and version and the relationship between inputs and outputs.
OperationalEvent: A business or machine event that matters to the evidence chain, such as delivery, calibration, deployment, processing, or shipment.
Trust kernel: The small deterministic layer that establishes canonical representation, integrity, and receipt relationships. It is not the scientific or institutional authority.
Evidence Plane: The commercial operating layer for programs, requirements, evaluation, review, determinations, statements, sharing, APIs, history, and support.
Program profile: A versioned representation of the requirements for a particular methodology, buyer, program, assurance workflow, or other intended use.
Determination: A bounded recorded judgment about whether the evidence supports a particular intended use, including qualifications and limitations.
Reliance artifact: A versioned package or statement intended for an external party, preserving enough evidence lineage and context to inspect why the conclusion was reached.
Validity laundering: Treating a valid statement at one layer — such as cryptographic integrity — as if it proved a different statement such as scientific truth, methodology eligibility, or buyer acceptance.
Earned default: A market convention that emerges because repeated use becomes easier and more valuable, rather than because a vendor declares itself the standard.