Agri-Assist

Overview

Agri-Assist is a web application for small-scale chili farmers who need fast, practical guidance when visible plant symptoms appear. The application works as a decision support tool: users select observed symptoms, the backend evaluates likely diseases with a rule-based scoring engine, and the system returns practical treatment recommendations.

The project is currently a prototype, but the backend is designed to be modular enough for future expansion into AI-assisted image detection and weather-aware recommendations.

Problem

Small-scale chili farmers can lose time and yield when they misidentify diseases or pests. Diagnosis information may be difficult to access in the field, and a single incorrect assumption can lead to ineffective treatment or excessive chemical use.

Agri-Assist addresses this by turning observable field symptoms into structured backend input that can be evaluated consistently.

Goal

The backend goal is to provide a clear API layer for symptom selection, rule-based disease matching, treatment recommendations, and user feedback.

The system prioritizes:

• explainable diagnosis results
• maintainable disease and symptom rules
• practical treatment categories
• a data model that can support future AI and external API integrations

Architecture

This case study uses architecture in two scopes: the system-level flow between frontend, backend, and database, and the internal backend structure inside the Go service.

System architecture

Agri-Assist uses a client-server architecture. The frontend sends selected symptoms to the Go backend, and the backend handles diagnosis logic, database access, and response formatting.

User
  -> Frontend symptom checklist / text search
  -> Go Backend API
  -> Rule-based diagnosis engine
  -> PostgreSQL disease, symptom, rule, treatment data
  -> Ranked diagnosis results and treatment recommendations
  -> Frontend result view

The backend owns the matching rules so disease data and scoring logic can be updated without changing frontend behavior.

Backend architecture

The Go backend uses a simple hexagonal architecture to keep delivery, domain logic, and persistence concerns separated.

HTTP handlers / Echo routes
  -> application use cases
  -> domain diagnosis logic
  -> repository interfaces
  -> PostgreSQL persistence with GORM

This structure keeps the rule-based diagnosis engine closer to the domain layer instead of coupling it directly to HTTP handlers or database queries. It also makes future integrations, such as AI image detection or weather APIs, easier to add as external adapters around the core diagnosis flow.

Backend Data Model

The rule-based system is built around crops, diseases, symptoms, weighted disease-symptom relationships, treatments, and feedback.

crops
  -> diseases
      -> disease_symptoms <- symptoms
      -> treatments
      -> feedbacks

Core entities:

• crops: supported plants, currently focused on chili
• diseases: disease or pest records linked to a crop
• symptoms: visible physical symptoms grouped by category
• disease_symptoms: rule table that stores symptom weights per disease
• treatments: recommendations grouped by treatment category
• feedbacks: user feedback for future evaluation and data improvement

Technical Decisions

Rule-based diagnosis first

The first version uses a rule-based approach instead of AI image detection. This makes the prototype easier to validate, explain, and adjust while the domain data is still being refined.

Weighted scoring

Each selected symptom contributes a weight to related diseases. The backend sums matched symptom weights and normalizes the result against the maximum possible disease weight.

raw_score = sum(weight of selected symptoms for a disease)
final_score = raw_score / total_possible_weight_for_that_disease

Diagnosis results are shown when the final score is above the configured threshold. If no disease passes the confidence threshold, the system can still return the highest low-confidence possibilities and suggest further consultation.

Four treatment categories

Treatment recommendations are grouped into four practical categories:

• natural handling
• prevention steps
• organic fertilizer
• chemical treatment as a calculated option

This keeps the response easier to scan and avoids returning a single unstructured block of advice.

Challenges

• Keeping the diagnosis result explainable while still ranking multiple possible diseases.
• Modeling many-to-many relationships between diseases and symptoms without making rules hard to maintain.
• Designing the backend around a prototype scope while leaving room for AI image detection in a later phase.
• Keeping treatment guidance structured enough for farmers to understand quickly.

Solutions

• Used a dedicated rule relationship table with symptom weights.
• Normalized scores by disease so diseases with more symptoms do not automatically dominate results.
• Kept diagnosis logic in the backend so rules can be updated centrally.
• Modeled treatments separately from diseases so recommendations can be categorized and edited without changing diagnosis logic.
• Added feedback as a separate entity to support future evaluation of recommendation quality.

Result

The current implementation provides a backend foundation for symptom-based disease diagnosis and practical recommendations for chili farmers. It supports the project as a prototype while keeping the architecture open for future AI/ML and weather API integration.

Lessons Learned

• Rule-based systems are useful for early agricultural decision support because they are explainable and easier to debug than opaque model predictions.
• Data modeling is central to maintainability; disease, symptom, treatment, and feedback data need clear ownership and relationships.
• Future AI features should extend the diagnosis flow instead of replacing the current rule-based foundation immediately.

Links

• Backend repository