Does the architecture do what the thesis says?

An agricultural technology already knows something happened: a device measured, an intervention occurred, a model ran, or an operator recorded an event. AgEvidence does not ask that company to replace its application. The Python SDK lets it express that evidence in a common form.

A small Rust trust layer handles the narrow deterministic problem: canonical representation, identity, digests, receipts and verification. It should not know whether a buyer approves a claim or whether a scientific model is valid.

The Rails Evidence Plane handles the changing institutional problem: programs, requirements, evaluations, gaps, human review, determinations, statements, sharing, permissions and history.

This lens asks whether those boundaries are real, whether the second integration reuses more than the first, and whether verification can remain meaningful outside the hosted product.

There are three questions in one evidence chain.

Representation: can the source system express what it knows in a portable form? Python owns this developer-facing problem.

Integrity: can another implementation establish that the object, lineage and declared transformations are intact? Rust owns this deterministic problem.

Interpretation and operation: is the evidence sufficient for a particular intended use, who reviewed it, what changed and what can be shared? Rails owns this mutable institutional problem.

The architecture is valuable only if those questions remain separable.

The Rust layer should be deliberately boring.

It should canonicalize evidence, derive or check stable identifiers, hash records, verify receipt relationships and provide deterministic validation without needing customer workflow state. It is the portion of the system that another party should be able to inspect or invoke without trusting the commercial application.

Production maturity matters here. A working path is not the same as a finished trust boundary. Canonicalization, signature handling, bundle verification and trust material should be hardened until independent reconstruction produces the same result.

The Python SDK is the adoption surface.

A developer should be able to map existing records into a small set of evidence primitives, validate them locally, create manifests and bundles, use source-adapter tooling and hand deterministic verification to the trust layer without creating a Rails account first.

The SDK succeeds when developers get useful evidence quickly and when new customers require fewer new core semantics than previous customers.

The Evidence Plane is where evidence becomes operationally consequential.

A workspace declares a purpose and program profile. Requirements define what is needed. Evidence records are attached. Evaluations surface pass, fail, gap, conflict or review states. Humans can review evidence and record determinations. Statements and artifacts communicate bounded conclusions. Sharing, permissions, history and API access make those conclusions usable outside the originating team.

Rails is intentionally mutable because institutions are mutable.