Traceability

Decision traceability: the record behind a treatment decision

Definition

Decision traceability is the ability to reconstruct, after the event, exactly how a pest-management decision was produced: which images it rested on, who held rights to them, which model version and calibration ran, which threshold policy applied, which reviews occurred, and what was exported. Without that record a field action can be neither defended nor corrected.

This page sets out what a decision record contains, why versioning is kept separate from model code, and what traceability does not give you.

Published: August 6, 2026
Last updated: August 6, 2026

What is decision traceability?

It is the property that any past decision can be reopened and understood without relying on anyone's memory. Every input, version, and human intervention that shaped the outcome is retained with the decision itself.

Traceability is often mistaken for logging. Logs record that something happened; a decision record reconstructs why a specific outcome was reached, which means it has to link the outcome to the exact assets, model, calibration, and policy that produced it — not to whatever versions are current when someone later goes looking.

What belongs in a decision record?

Nine classes of information, from the agreement that permitted the imagery through to what was exported. Each is recorded as an immutable reference rather than a copied value, so the chain cannot silently drift.

Intended contents of a decision record
Element	What it establishes
Agreement and data rights	That the imagery was permitted for this use, under a recorded agreement.
Capture session	Farm, field, crop, date, rig, calibration state, and capture geometry.
Source assets	The specific images or frames the decision rests on, by immutable reference.
Quality assessment	The measured image quality that qualified the assets as valid inputs.
Annotations and adjudication	Human biological labels and how disputes over them were resolved.
Dataset and model version	The trained model that ran, and the dataset lineage behind it.
Calibration	Camera and confidence calibration in force at the time of inference.
Threshold policy version	The exact rule set applied, including which stages and measures counted.
Outcome and export	Treat, no-treat, or abstain; the reason; and the treatment zone exported.

Why does a pest treatment decision need an audit trail?

Because the consequences are physical, regulated, and delayed. A decision that turns out to be wrong is only correctable if you can find out which part of the chain was wrong, and a decision that turns out right is only repeatable for the same reason.

Correction: if a model or policy is later found to be faulty, the affected decisions can be identified rather than guessed at.
Accountability: a grower, adviser, or auditor can see what the decision rested on instead of taking a vendor's word for it.
Research validity: an evaluation result is only meaningful if the data and versions behind it are pinned down.
Improvement: patterns in abstentions and reversals are only visible when the reasons are recorded.
Disputes: where a treatment is questioned after the fact, the record is the only account that does not depend on recollection.

How are model and policy versions handled?

They are versioned independently and both are pinned to the decision. Threshold policy is held apart from detector code so biology can be reviewed and revised without retraining, and so a policy change is visible as a policy change.

Bundling the two is the common shortcut and it destroys traceability in a specific way: once a biological rule is embedded in model code, no one can tell whether an outcome changed because the model learned something or because someone altered a threshold. Separating them keeps that question answerable.

Versions are referenced, never copied. A decision that stored a threshold value rather than a policy version would lose the surrounding rationale, review, and authorship.

Can a past decision be re-evaluated?

That is the point of retaining the chain. Because assets and versions are pinned, an earlier decision can be replayed against a newer model or a revised policy and the two outcomes compared.

Re-evaluation does not rewrite history. The original decision, its versions, and its outcome remain as recorded; a replay is a new evaluation that references the original. Anything else would make the record unreliable exactly when it matters most.

What does traceability not provide?

It does not make a decision correct, and it is not a compliance certification. A fully traceable decision can still be wrong; traceability only guarantees that being wrong is discoverable.

It is not evidence of accuracy. A complete record of a poor model is a complete record of a poor model.
It is not regulatory approval, certification, or an attestation by any agency or institution.
It does not substitute for the grower's own application records, which remain their responsibility.
It does not interpret pesticide labels or determine whether an application was lawful.

Inputs, outputs, limitations, and evidence status

Inputs

Immutable references to source assets rather than copies of them.
Recorded data-rights and agreement state for every asset.
Capture-session registration and calibration state.
Annotation and adjudication history for biological labels.
Model, dataset, calibration, and threshold-policy version identifiers.

Outputs

A machine-readable decision record per decision, including abstentions.
The reason recorded alongside every abstain outcome.
A reconstructable chain from exported zone back to source imagery.
Review history, including who resolved an ambiguous label and how.
Replay results that reference, rather than overwrite, the original decision.

Limitations

Traceability records how a decision was made; it does not make it correct.
It is not a certification, accreditation, or regulatory approval of any kind.
Retention depends on the imagery having been registered at capture; it cannot be reconstructed afterwards.
It does not replace the grower's statutory application and pesticide records.

Evidence status

The decision-record structure described here is the intended platform design.
No third-party audit, certification, or independent assessment of these controls is published.
Interfaces shown elsewhere on this site are illustrative and labeled as such.
No customer, deployment, or decision-volume figures are published.

Terms used on this page

Definitions are shared site-wide. The full list is in the glossary.

Decision traceability: The ability to reconstruct after the fact exactly how a decision was produced, from source imagery through model, calibration, and policy to the exported output. Traceability is what makes a decision correctable as well as defensible.
Decision record: The durable, machine-readable artefact retained for each decision: source assets, rights status, capture context, model and calibration versions, policy version, uncertainty, review history, outcome, and export. It is the object an audit reads.
Provenance: The verifiable origin and handling history of an image: where and when it was captured, by what equipment, under what agreement, and what has happened to it since. Provenance is established at capture, not reconstructed later.
Model version: The specific, immutable identifier of the trained model that produced a detection, together with the dataset and training run behind it. Without a recorded model version, a past result cannot be reproduced or re-examined.
Dataset lineage: The record of which assets, annotations, and adjudications composed a training or evaluation dataset, and which models were built from it. Lineage is what allows a suspect result to be traced back to its data.
Adjudication: Review of a disputed or uncertain biological label by a qualified reviewer, producing a recorded resolution rather than an averaged guess. Adjudication decisions are retained as part of dataset lineage.