prathmeshadsod/PostHarvest-Llama-4-Scout-17B-16E-Instruct

HarvestOps: Post-Harvest Decision Support

A Llama 4 Scout LoRA that turns messy field observations into practical, resource-aware loss-reduction decisions.

Trained by Adaption AutoScientist on the 10,000-record PostHarvest dataset.

TL;DR

HarvestOps is designed for the moment before a small post-harvest problem becomes a large loss: mixed-condition lots, uneven heat or moisture, incomplete records, limited electricity, uncertain causality, and a decision that cannot wait for perfect information.

The model favors a straight answer, low-cost containment, traceability, representative checks, and a reversible trial. It was trained to distinguish observed facts from plausible causes and to avoid inventing pathogens, chemical doses, buyer rules, equipment, or guaranteed outcomes.

This repository is intended to contain a PEFT LoRA adapter, not a standalone Llama 4 Scout checkpoint. Upload and verify the adapter files before using the loading example below.

Contents

• The problem
• What HarvestOps learned
• Dataset adaptation
• Example
• Evaluation
• Model details
• Training configuration
• How to use
• Intended use
• Safety and limitations
• Reproducibility
• Citation

The problem

Post-harvest loss is rarely presented as a clean textbook exercise. An operator may know that one side of a store is warmer, that two shifts handled a lot differently, or that bruising appears only after the next transfer. They may not have calibrated sensors, laboratory access, complete timestamps, spare packaging, or enough electricity to cool every zone equally.

Useful guidance must therefore do more than repeat best practices. It must answer the immediate operational question, protect traceability, work within the tools actually available, identify what evidence would change the decision, and avoid converting a visual observation into a food-safety or pathogen claim.

HarvestOps targets that gap across farmers, cooperative leads, store managers, and packhouse supervisors.

What HarvestOps learned

Capability	Typical behavior
Mixed-lot triage	Keep traceable groups separate and avoid hiding condition differences by averaging the lot
Uneven-zone diagnosis	Compare representative locations before changing the entire store or route
Low-resource planning	Use shade, timing, segregation, airflow, handling, and existing tools before costly equipment
Handling-loss reduction	Connect delayed bruising to transfer, fill, stacking, compression, and route differences
Storage monitoring	Build simple observation maps and logs without inventing thresholds or instruments
Safety boundaries	Hold and label uncertain lots; do not identify pathogens or certify safety visually
Commercial boundaries	Ask for the current buyer or destination requirement instead of inventing one
Reversible experimentation	Pilot a change on one lot or zone and define what outcome would justify scaling it

Dataset adaptation

The training data has two distinct stages:

1. The HarvestOps source pipeline planned 12,000 deterministic capability slots and accepted exactly 10,000 validated prompt, response, and rationale records.
2. The 10,000 source records were uploaded to Adaption. For this run, the deliberately informal user prompts were kept as written so they continued to resemble direct requests from real field operators. Adaption concentrated its remastering on the completions, improving clarity, organization, actionability, and explanation quality.
3. AutoScientist selected the LoRA training configuration and trained the model on the adapted dataset.

This separation matters. The source pipeline contributed coverage, scientific boundaries, provenance, and natural raw requests. Adaption strengthened how the assistant answers those requests without turning the user side into a rigid template.

Example

The following example illustrates the intended interaction. The prompt retains its operational, time-pressured voice; the adapted response starts with the decision and then explains what to do.

User prompt

Hey, quick question on the tomato lot we're packing today. We've got breaker-stage fruit from three different farms that came in across two shifts. My team wants to run the whole lot through the same handling and cold-storage routine to save labor, but I'm not sure that's smart.

It is warmer near the entrance, stable in the center, and nobody recorded the back corner. Receiving notes were all done by the same person, so at least that is consistent. Damage only shows after the next handling step, mostly bruising, and we cannot afford to mix saleable with suspect fruit. Electricity is tight too, so we cannot just increase cooling everywhere.

Can we justify one routine, or do we need to split zones? I need a straight answer before the next shift starts.

Adapted assistant response, abridged

Straight answer: No. You cannot justify one routine for this lot. Split the zones.

Because bruising appears after the next handling step, combining farms and shifts now would destroy the traceability needed to identify where the loss originated. The uneven and partly unmeasured temperature pattern also makes a single treatment hard to defend.

Check and record the back-corner condition first. Keep farm and shift groups labeled and separate, direct the limited cooling effort toward the warmest verified zone, and retain a comparison group under the existing routine. Do not mix suspect and comparison fruit until the next handling check shows whether bruising differs by group.

The decision can be revisited once the missing corner measurement and post-handling observations are available.

The example is operational guidance, not a universal crop protocol. Local conditions, current buyer requirements, and qualified food-safety assessment still control high-stakes release decisions.

Evaluation

AutoScientist win rates

Evaluation slice	Base model	Adapted model
Evaluation on the PostHarvest dataset	7	93
Agriculture category evaluation	37	63

These are the whole-number preference labels displayed by Adaption for training experiment 31939707-0c1b-4d48-99f1-78ca3e2fd271. They show a large gain on the submitted dataset and a positive gain across the broader Agriculture category.

They are platform-reported preference results, not a claim that 93% of all agricultural recommendations are scientifically correct. The interface does not expose item counts, confidence intervals, or a public item-level test set.

Dataset adaptation result

Measure	Original data	Adaptive data
Quality score	8.0	9.0
Relative improvement	-	12.5%
Final quality grade	-	A

These measurements describe Adaption's assessment of the dataset transformation; they are not an external agronomy or food-safety benchmark.

The loss, learning-rate, and gradient-norm charts document optimization behavior. Training curves alone do not establish scientific validity, safety calibration, or performance in every crop, climate, market, or jurisdiction.

Model details

Field	Verified value
Release type	PEFT LoRA adapter
Training method	Supervised fine-tuning (SFT)
Data format	Chat
AutoScientist base model	meta-llama/Llama-4-Scout-17B-16E-Instruct
Base size reported by AutoScientist	109B total parameters
Trained model name	adaption_post_harvest_loss_guidance
Training experiment ID	31939707-0c1b-4d48-99f1-78ca3e2fd271
Fine-tune job ID	444c120f-dd58-402d-b7c8-d48833dd75ce
Dataset	prathmeshadsod/postharvest

An implementation-specific adapter base path is intentionally not listed yet. AutoScientist identifies the logical base model above, but the exact loading checkpoint must be read from the uploaded adapter's adapter_config.json after the adapter artifact is available.

Training configuration

The AutoScientist-selected configuration was used unchanged.

Parameter	Value
Epochs	3
Batch size	max
Evaluations	5
Learning rate	1e-4
Scheduler	Cosine
Scheduler cycles	0.5
Warmup ratio	0.1
Minimum LR ratio	0.1
Weight decay	0.01
Maximum gradient norm	1
LoRA rank	64
LoRA alpha	128
LoRA dropout	0
Train on inputs	false

Trainable modules:

q_proj, k_proj, v_proj, o_proj,
shared_expert.gate_proj, shared_expert.up_proj, shared_expert.down_proj,
feed_forward.gate_proj, feed_forward.up_proj, feed_forward.down_proj

How to use

First upload the complete PEFT artifact set, including adapter_config.json, adapter weights, tokenizer files, and chat template. Then let PEFT read the exact base path recorded by the adapter instead of copying a base path from another run.

pip install torch transformers peft accelerate bitsandbytes

import torch
from peft import PeftConfig, PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

ADAPTER = "prathmeshadsod/PostHarvest-Llama-4-Scout-17B-16E-Instruct"

peft_config = PeftConfig.from_pretrained(ADAPTER)
base_name = peft_config.base_model_name_or_path

base = AutoModelForCausalLM.from_pretrained(
    base_name,
    device_map="auto",
    torch_dtype=torch.bfloat16,
)
model = PeftModel.from_pretrained(base, ADAPTER)
tokenizer = AutoTokenizer.from_pretrained(ADAPTER)

messages = [{
    "role": "user",
    "content": (
        "We have mango crates from two farms in the same store. The doorway side "
        "is warmer and one group is softening faster. We only have a basic "
        "thermometer and cannot replace the crates. What should we do first?"
    ),
}]

text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)
inputs = tokenizer(text, return_tensors="pt").to(model.device)

with torch.inference_mode():
    output = model.generate(**inputs, max_new_tokens=700, do_sample=False)

new_tokens = output[0][inputs["input_ids"].shape[1]:]
print(tokenizer.decode(new_tokens, skip_special_tokens=True))

Use the tokenizer and chat template shipped with the final adapter. If the exported architecture requires a different Transformers auto class, follow the uploaded adapter/base configuration rather than forcing this generic text-only loading pattern.

Intended use

HarvestOps is intended for:

• post-harvest education and first-pass operational planning;
• smallholder, cooperative, village-store, packhouse, and market workflows;
• mixed-lot triage and traceability decisions;
• handling, packing, transport, sorting, storage, drying, and monitoring questions;
• low-resource loss-reduction planning;
• safety-aware clarification and escalation;
• research on narrow-domain instruction adaptation.

The model is an advisory language model. It does not inspect produce, measure a lot, verify a pathogen, issue a safety certificate, replace current buyer specifications, or authorize chemical treatment.

Safety and limitations

• Visual appearance, smell, heat, moisture, or damage patterns do not establish pathogen identity or food safety.
• Do not use the model to select fumigants, doses, exposure times, personal protective equipment, or legal treatment procedures. Follow current product labels, local rules, and trained authorized personnel.
• Buyer grades, export limits, certificates, and destination rules must come from current supplied documents.
• Advice must be adjusted for crop variety, maturity, route, climate, packaging, market, and available infrastructure.
• The dataset is synthetic and then adapted. It cannot cover every local storage system or failure mode.
• The model may still invent a threshold, tool, treatment, causal explanation, or guaranteed outcome. Verify important recommendations independently.
• The adapted completion examples were evaluated by Adaption, but the complete remastered file has not been certified as a substitute for agronomist, extension, laboratory, regulatory, or food-safety review.
• Use qualified local support for suspected contamination, illness risk, regulated treatment, or commercial release.

Reproducibility

Artifact	Identifier
Source production run	harvestops_production_10000_seed_20260806
Source planner seed	20260806
Source candidate slots	12,000
Source accepted rows	10,000
Source rule set	harvestops.rules.v1.0.0
Source prompt-author model	nvidia/nemotron-3-ultra-550b-a55b
Source response-teacher model	nvidia/nemotron-3-ultra-550b-a55b
AutoScientist experiment	31939707-0c1b-4d48-99f1-78ca3e2fd271
Source AutoScientist JSONL SHA-256	78d12c36256d5bb7d2b9195884251cc9afd9cf9874b12639539e5f66d7059106
Adapted dataset JSONL SHA-256	bb390a5b049a40074e4ede5d1f20640d964982834779198971fc5ff590d348f9

The source pipeline used one fixed prompt author and one fixed response teacher for the run, preserved raw attempts, and kept scenario blueprints separate from factual answer keys. The prompt author never received hidden answer-key fields or validator targets.

Citation

@misc{adsod2026harvestops,
  author = {Prathmesh Adsod},
  title = {HarvestOps: Post-Harvest Decision Support with Llama 4 Scout},
  year = {2026},
  note = {Adaption AutoScientist Challenge submission}
}

Acknowledgements

Built for the Adaption AutoScientist Challenge. Adaption remastered the completion side of the PostHarvest dataset, selected the training configuration, trained the LoRA adapter through AutoScientist, and produced the displayed quality and preference results. The HarvestOps source pipeline supplied the diverse field scenarios, source-grounded answer keys, safety boundaries, natural prompts, and independently validated release artifact.