Crop Cure connects a grape-leaf classifier to WhatsApp. A user chooses a language, sends a photograph, and receives a response based on the predicted class. The project supports English, Hindi and Marathi response flows.

The workflow

My work here spans the classifier integration and the surrounding application: getting an image from a message into the model, interpreting the output, and turning that output into a usable reply.

The model has four labels: black rot, esca, leaf blight and healthy. That is a deliberately narrow scope. It is not a general classifier for every crop or every possible leaf condition.

A threshold needs an honest description

The implementation uses a 0.98 confidence threshold. Predictions below it return Unclassified.

That number is not 98% accuracy. It is a threshold applied to a model output. A high softmax score can still be wrong, especially when the photograph differs from the data used to train the model. Lighting, background, camera distance and an unsupported plant all make the input harder to interpret.

The fallback gives the application a way to avoid returning a class for every image. Whether it rejects enough unsuitable images requires evaluation with representative photographs; the public repository does not establish field accuracy.

Where the prototype stops

The repository describes the project as under development and not actively maintained. It is best understood as a research prototype, rather than a deployed agricultural diagnostic service.

Language preferences currently live in an in-memory dictionary, so they do not survive a process restart. Inference also runs synchronously inside the message-handling path. If I continued the project, I would persist conversation state, move inference into a controlled worker path, and evaluate class-specific errors and rejection behaviour on a held-out field dataset.

The interesting engineering lesson is how much of the product sits around the model. The preprocessing contract, supported inputs, fallback behaviour and message flow all determine whether the prediction can be used sensibly.

Implementation details: model and preprocessing and WhatsApp application.

FreightSense is my prototype for that workflow. It puts a rules-based calculation beside an LLM assessment, records both, and leaves the final decision with the operator.

What I built

The application combines a Python/FastAPI API, a small browser dashboard, a deterministic evaluation layer, Groq-hosted LLM calls and SQLite records. The repository also includes Docker and Cloud Run deployment configuration.

Keep the arithmetic outside the prompt

The deterministic layer calculates delay and exposure before the model sees the request. Its risk score combines delay severity, historical context, financial exposure and margin. The recommendation itself follows separate business rules: no delay can mean NO_ACTION; a feasible and economically acceptable intervention can mean EXPEDITE; otherwise the result can be DISCOUNT or MONITOR.

That distinction matters. A risk score describes the situation. It does not, by itself, prove that paying to expedite is sensible. The code checks conditions such as the shipping mode and the estimated intervention cost.

The LLM receives these calculations as context. The application parses its response, checks the recommendation label and bounds the confidence value. It also handles several failure paths, including API errors and invalid JSON, by returning the deterministic result with the LLM marked unavailable.

Disagreement is useful information

A model disagreeing with the rules should be visible. FreightSense stores the two assessments and flags the mismatch instead of quietly replacing one with the other.

The override endpoint lets a person record a different decision, a reason and outcome notes. Multiple overrides are retained as separate entries. That history makes it possible to revisit why an operator intervened, rather than seeing only the latest choice.

What the prototype establishes

The repository demonstrates the complete evaluation-and-review path. It does not establish a measured reduction in shipping costs. The financial figures are estimates, and the model’s confidence is a self-reported value, not a calibrated probability of correctness.

For a production version, my next priorities would be durable shared storage, access control, stronger validation of model outputs, and a labelled evaluation set that includes expensive mistakes and ambiguous cases. Those are more useful next steps than adding another model to the comparison.

Implementation details: deterministic rules, LLM evaluation, and API routes.