MittiGuard

Don’t sell blind: MittiGuard turns uncertain agri-input requests into evidence work, human review, and field memory.

Comment

Inspiration

I kept coming back to one simple situation: a farmer walks into an agri-input shop with yellow leaves, spots, or a crop that is not improving after rain. There is pressure to give an answer quickly, but the information is often incomplete.

It would have been easy to build a disease-diagnosis app that gives a confident recommendation. I felt that would be the wrong thing to do. If the field story is unclear, a confident-looking answer can lead to another unnecessary or ineffective sale.

So I built MittiGuard around a different idea: before selling anything, make sure the evidence is good enough.

What it does

MittiGuard Relay turns an unclear farm-input request into evidence work instead of a chemical recommendation.

The dealer records the field, crop, crop stage, farmer’s story, previous input outcome, soil-report date, optional field image, and weather context. Amazon Nova Pro turns the reviewed information into an editable evidence draft, but it cannot recommend a product, dose, or timing.

If important evidence is missing, the invoice is paused. MittiGuard creates exact tasks, such as collecting a current Soil Health Card, capturing a field image, or reviewing the outcome of a previous input. The case is then handed over to the right person for review.

The main safeguard is called Evidence Debt. If the same field had a similar unresolved issue before, the server detects it and blocks a repeat sale, even if someone clears the prior-failure checkbox in the browser.

How we built it

I built MittiGuard with Node.js, JavaScript, HTML, and CSS. The app has a server-side policy engine, a persistent demo ledger, Field Memory, an audit trail, mobile Field Capture links, and a Safety Bench.

Amazon Nova Pro through Amazon Bedrock powers the live evidence-draft path. I deployed the public demo on AWS Lightsail with HTTPS.

I used Codex and GPT-5.6 throughout the build to work through the product idea, design the workflow, implement the app, write tests, improve the demo experience, and prepare the project documentation.

Challenges we ran into

The biggest challenge was not calling a model. It was making sure that a good-looking model response could never become an unsafe business decision.

I had to separate “AI helps organize the information” from “the system decides what happens next.” The model is only allowed to create a constrained evidence brief. The policy engine runs on the server and controls the invoice state.

Another challenge was proving that the browser could not bypass the system. That is why I added a real bypass proof: the UI clears a dealer claim, but the server still finds unresolved field history and returns NOT_RELEASED.

Accomplishments that we're proud of

I am most proud that MittiGuard does not have an approved-sale state hidden behind the demo.

A model response, completing an evidence task, and recording a reviewer attestation all still leave the invoice as NOT_RELEASED. The app also includes:

  • Server-side Evidence Debt detection for repeat-risk cases
  • Owned evidence tasks with a handoff, SLA, and audit trail
  • One-time mobile Field Capture links that store bounded observations and image metadata, not raw image files
  • A visible 45-check Safety Bench for replaying policy and audit controls
  • A public live demo where judges can run the bypass proof themselves

What we learned

I learned that safety is not only about making an AI refuse a harmful prompt. It is also about designing the workflow so uncertainty cannot quietly turn into authority.

The useful role for AI here is helping people organize evidence. The important decisions should remain explicit, deterministic, and reviewable.

What's next for MittiGuard

MittiGuard is currently a synthetic jury demo, not a production system. The next step would be to test the workflow with real dealers, field workers, and extension teams.

For a real deployment, I would add proper user roles, secure authentication, a durable multi-user database, consent and retention controls for field evidence, and integrations with real dealer or extension workflows.

The core principle would stay the same: models create a brief; policy controls the sale. Don’t sell blind.

Built With

Share this project:

Updates