For: an innovation or R&D lead deciding whether an AI workflow merits another development stage.
Outcome: a completed comparison brief, a traceable trial record and a go/rework/stop decision. Start with one defined application; finish with a justified next stage, not an automatic launch decision.
Scope: evaluation planning. This manual does not supply a food-safety protocol, a statistically powered study design or clinical guidance. Those requirements belong to the relevant qualified specialists and the organisation's procedures. The method is FoodEdge's proposed framework, not a validated protocol from the cited preprint.
Before you start
Required inputs: a defined development problem, the current workflow, a proposed tool, permitted data, an intended application and an accountable decision owner. Required roles: decision owner, formulation/operator lead, sensory or other relevant evaluation specialist, and a reviewer who can challenge the conclusion.
If the product need is undefined, use a product-discovery brief first. If the problem is clear but the relevant data cannot be used lawfully or confidentially in the tool, resolve the data route before entering them. If a candidate has not passed the organisation's required safety review, do not proceed to human consumption testing.
Step 1. Write one decision
Complete: “We will use this trial to decide whether ___ should proceed to ___ because it may improve ___.”
Choose one primary objective: exploration, development effort, product performance or another explicitly defined outcome. Additional observations can be secondary. Do not change the primary objective after seeing the result without recording that change and treating the new finding as exploratory.
Output: a one-sentence decision and one primary measure. Owner: decision owner.
Step 2. Set two references
Write the method reference, usually the existing development workflow or another justified alternative. Then write the product reference, if product performance is part of the decision. Explain why each is relevant.
If only a historical reference is available, record what differs between settings. Restrict the resulting inference accordingly; do not treat an uncontrolled comparison as a definitive improvement test.
Output: two references, their rationale and limitations. Owner: technical lead with evaluation specialist.
Step 3. Fix the constraints and the acceptance rule
Agree the conditions both routes must respect: ingredient restrictions, intended process, application, target cost boundary and other project requirements. Choose thresholds with the relevant specialists before running the trial. This manual intentionally supplies no universal numerical threshold or sample size.
For each primary measure, record its unit, method, acceptance rule and how uncertainty will affect the decision. If no credible acceptance rule can be agreed, the trial is exploratory and cannot support a purchase or launch claim based on passing that rule.
Output: signed-off evaluation brief. Owner: decision owner and specialist.
Step 4. Run and retain the whole workflow
Record generated candidates, selection decisions, human edits, reasons for rejection, resources used and deviations from the brief. Define the start and end points for any measure of time or cost. Apply the same accounting boundary to the comparator.
Keep records according to internal data controls. The aim is traceability, not unnecessary collection of personal or confidential data.
Output: candidate log and resource record. Owner: operator lead.
Step 5. Evaluate the permitted candidates
Only candidates cleared through the organisation's relevant safety and technical procedures enter the appropriate assessment. Use the agreed study design and analysis. Record missing observations and failed candidates; do not silently remove them from the account of the workflow.
If a material protocol deviation occurs, ask the evaluation specialist whether the intended inference survives. A demonstration may still be informative even when it cannot support the planned comparison.
Output: results with uncertainty, deviations and scope. Owner: evaluation specialist.
A useful challenge before the decision
Ask a reviewer who did not run the trial to read the brief and results together. Can they identify the conclusion without being told which route the team prefers? Can they trace the principal claim to the measure and see the contribution of human work? Where they cannot, narrow the claim or request the missing record.
The reviewer challenges interpretation; they do not create missing data or replace the safety and technical owners.
Step 6. Decide and name the next gate
- Go to the next stage: the prespecified criteria are met within an interpretable comparison; the next unresolved requirement is named.
- Rework: the result is inconclusive or a remediable issue prevents the intended comparison; specify the correction and the question it resolves.
- Stop this route: the defined decision rule is not met and further work is not justified under the agreed resource constraints. Retain useful learning.
Passing this evaluation does not authorise product launch. A next gate may concern reproducibility, processing, stability, application qualification or a different unresolved requirement.
Output: decision, reasons, owner and review trigger. Owner: decision owner after independent challenge.
Copyable trial worksheet
| Field | Enter before or during the relevant step |
|---|---|
| Decision and intended next stage | [Complete] |
| Intended user and product application | [Complete] |
| Primary objective and measure | [Complete] |
| Method reference / rationale | [Complete] |
| Product reference / rationale, or why not applicable | [Complete] |
| Constraints shared by both routes | [Complete] |
| Safety and data prerequisites / accountable reviewer | [Complete] |
| Measurement method, uncertainty and specialist-approved design | [Complete] |
| Acceptance rule fixed before results | [Complete] |
| Time/cost boundary and human-work accounting | [Complete] |
| Candidate and edit log location | [Complete] |
| Deviations, missing data and rejected candidates | [Complete] |
| Findings and allowed claim | [Complete] |
| Go / rework / stop, with reasons | [Complete] |
| Next unresolved gate, owner and date | [Complete] |
Example of a bounded result: “Under the recorded trial conditions, the combined workflow met our prespecified criterion for proceeding to an application test.” This is illustrative wording, not a result achieved by FoodEdge or any named company.
Check your interpretation
Case A, fictional: a candidate meets the agreed sensory criterion, but the team did not record comparable human effort for the existing workflow. The product result may support a next application test; it cannot support a claim that development labour fell.
Case B, fictional: the tool produces more candidates, but the team changes its acceptance threshold after seeing them. Record the change and treat the new interpretation as exploratory. A retrospectively easier threshold does not demonstrate success against the original brief.
Case C, fictional: the data route or required safety review is unresolved. Stop the dependent activity and resolve that prerequisite with its owner. A promising technical result does not authorise confidential-data entry or consumption testing.
These are logic checks for the framework. No experiment or real-company trial is being reported.
Basis: FoodEdge analysis informed by the distinction between workflow, comparator and outcome in the Tac and Kuhl preprint. This planning framework has not been field-tested with an R&D team. Record ambiguities during its first real use and review them before reusing the template. Recheck the source version if you use the preprint as the basis for a new claim.
Editorial process: Prepared with AI assistance from public sources. Publication approved by the Editor-in-Chief on 17 October 2026. No external expert review is claimed.
