AgEvidence · Investor Evidence Room

Agricultural evidence becomes expensive the moment it has to leave the system that produced it.

AgEvidence is building the narrow, portable evidence boundary that lets one measured fact cross into a buyer program, a methodology, an assurance process or a lender workflow without a new integration each time. This room is the complete investor record: what is built, what is claimed, what is unproven, and what would falsify it.

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.

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.

Where the company stands
  • Pre-revenue. Priced reliance is treated as unproven.
  • Reference implementation built and inspectable.
  • External institutional reliance not yet demonstrated.
01
Company

What AgEvidence is

What the company is

AgEvidence is two things deliberately kept apart. An openly licensed evidence substrate — a schema, an SDK and a verifier — that makes agricultural evidence portable and independently inspectable. And a commercial Evidence Plane that operates the institutional relationships, changing requirements and human judgements that sit on top of that substrate.

The substrate is designed to be boring, stable and cheap to adopt. The commercial plane is designed to be where recurring work, and therefore recurring revenue, accumulates. The company thesis stands or falls on whether that separation holds under real institutional pressure.

What the company is not

It is not a measurement company, a carbon project developer, a marketplace or a farm management platform. It does not compete with the technologies that generate evidence; it is the layer those technologies cross into destinations through.

It is also not a standards body. Standardization is a possible outcome of adoption, never a status the company claims to hold today.

Why this is an investable structure rather than a feature

Every new destination relationship in agriculture is currently priced as bespoke integration work. If one narrow contract can absorb that work, the marginal cost of the next destination falls and compatibility history accumulates as an asset that is difficult to reconstruct.

That is the entire wager: value accrues in reuse, compatibility history, program knowledge and institutional operations rather than in proprietary custody of data.

02
Workflow

How one fact crosses a boundary

01 EmitOpen substrate

Source technology

A robot, sensor, model, biological product or record system emits evidence through the free SDK, in the source system's own terms.

02 RepresentOpen substrate

Evidence model

The observation, its method, its uncertainty and its provenance are represented separately, so nothing downstream can silently collapse a measurement into a claim.

03 SealTrust layer

Trust kernel

The evidence history is made tamper-evident and independently verifiable without trusting AgEvidence's hosted state.

04 CrossEvidence Plane

Evidence Plane

A destination's profile is applied: eligibility, sufficiency, review and the human judgements the institution actually requires.

05 RelyEvidence Plane

Destination institution

A buyer program, methodology, processor, lender or assurance practitioner relies on the packaged evidence and retains an inspectable version of it.

06 ReuseEvidence Plane

Both sides

The same evidence history serves a second destination without a second integration. Reuse velocity is the load-bearing commercial measurement.

03
Maturity

What is built and what is not

LayerStatusEvidence heldWhat is missing
Evidence model and schemaBuiltImplemented, versioned and inspectable in the reference repositories.Has not yet been frozen under pressure from a materially different third source.
SDK integration surfaceBuiltWorking emit path with documented primitives.No unassisted external integration completed by an unrelated team.
Trust kernel and verifierBuiltIndependent verification path exists and runs outside hosted state.No third party has yet relied on a verification result in a consequential decision.
Evidence Plane workflowDemonstratedEnd-to-end workflow demonstrated through the reference console.Operated as a demonstration, not yet as a production institutional service.
Destination profilesDesignedProfile mechanism specified and exercised against sample destinations.No live destination has adopted a profile under its own governance.
Priced relianceUnprovenNo revenue. Willingness to pay is argued, not observed.One arm's-length paying destination is the decisive missing artefact.
RepeatabilityUnprovenNo second deployment against which to measure cost decay.Implementations two and three must be cheaper than the first.
04
Financing

Capital mapped to proof

  • Founder runway

    Architecture and product execution through the freeze decision

    Retires: Can the core stop changing at all?
  • Deployment lead

    Founder-independent customer execution

    Retires: Key-person concentration
  • External integrations

    Two unrelated source integrations, run in parallel

    Retires: Does the substrate survive heterogeneity?
  • Institutional operations

    One destination profile operated under real governance

    Retires: Is reliance operable, not just demonstrable?
  • Bounded specialists

    Scoped legal, security and assurance review

    Retires: Unquantified compliance exposure
  • Contingency

    The ability to survive one failed experiment

    Retires: Rescue-capital dependency
Underwriting posture
  • The round is sized to buy proof, not to buy time.
  • Every line must retire a named uncertainty on the claim register.
  • The plan must not assume a second round to finish customer obligations.
  • Assets bought must remain valuable if no second round occurs.
Open the round →

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
  1. 1Something happens. A device measures, an intervention is delivered, a model runs, a producer records an event, or a machine performs an operation.
  2. 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.
  3. 3Integrity is established. Canonical representation, hashes, identifiers, receipts, and verification rules make alteration and lineage inspectable.
  4. 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.
  5. 5Gaps stay visible. Missing, conflicting, stale, or out-of-domain information is surfaced rather than silently coerced into a pass.
  6. 6Judgment is attributable. A human or authorized process can review the evidence, record a determination, and state qualifications without rewriting the underlying history.
  7. 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
— 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.

Portfolio as a heterogeneous validation laboratory

AgEvidence must demonstrate that the same narrow evidence contract can survive materially different technologies and evidence classes. A heterogeneous portfolio can accelerate that test, because different agricultural technologies, different evidence archetypes and different customer relationships stress the same contract at once.

Portfolio access is treated as validation infrastructure rather than captive revenue. Portfolio-related revenue remains zero in the base case until a named payer exists, and investor-connected adoption is always weaker evidence than equivalent adoption by an unrelated external organization.

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.