I Built an AI That Wants You to Stop Using It

TrailLens — Look beyond the screen.

Most AI products are designed to keep you inside the interface.

TrailLens was designed to do the opposite.

You find something outside.

You capture it.

Local Gemma 3 4B helps understand it.

TrailLens turns that observation into a short, structured field mission.

And then it tells you:

PHONE DOWN.

The most important part of the experience begins when the screen stops being the center of attention.

🌿 What Is TrailLens?

TrailLens is a local AI field-experiment engine for outdoor exploration.

Its core loop is:

SEE
  ↓
GEMMA UNDERSTANDS
  ↓
MISSION READY
  ↓
PHONE DOWN
  ↓
EXPLORE
  ↓
RETURN
  ↓
REFLECT
  ↓
FIELD RECORD

The idea is intentionally simple:

Use AI to create curiosity, then get out of the way.

TrailLens is not trying to become another chatbot.

It is trying to give you a reason to look more closely at the physical world.

🧭 The Problem

A lot of digital products optimize for attention:

• more scrolling
• more notifications
• more interactions
• more time on the screen

But when you're outside, the interesting thing is usually already there.

A leaf.

A piece of bark.

A flower.

A stone.

A texture.

A pattern you normally walk past.

So I started with a simple question:

What if AI could help someone notice the physical world, then deliberately disappear from the experience?

That became TrailLens.

🌲 The TrailLens Experience

01 — SEE

You notice something interesting outside.

02 — CAPTURE

TrailLens uses the camera to capture the observation.

03 — GEMMA UNDERSTANDS

The image enters the local analysis pipeline.

Gemma 3 4B analyzes the visual input and produces structured information that TrailLens can turn into a field mission.

04 — MISSION READY

Instead of returning only an identification, TrailLens generates a structured FieldMission.

For example:

Find another nearby leaf with a similar shape and compare the number of lobes and the pattern of its main veins.

The important difference is:

the output becomes an action, not just an answer.

05 — PHONE DOWN

Once the mission starts:

PHONE DOWN.

Put your phone away.
Look.
Walk.
Notice.
Compare.

Pocket Mode intentionally minimizes the interface.

06 — EXPLORE

The user spends a short, bounded period investigating the physical environment.

07 — RETURN

When they come back:

What did you notice?

The reflection is written by the user.

Gemma does not invent the experience for them.

08 — FIELD RECORD

The session becomes a compact record containing the mission, session information, and the user's own reflection.

The application becomes a record of something the person actually did, rather than another chat transcript.

🧠 Why Gemma Matters

Gemma is not just an API call hidden somewhere inside the project.

It is the reasoning layer connecting:

VISUAL OBSERVATION
        ↓
LOCAL AI REASONING
        ↓
STRUCTURED FIELD MISSION

TrailLens uses Google Gemma 3 4B through Ollama for local inference.

That choice matters because the intended environment is the real world, where connectivity may be unreliable.

The local architecture allows the core AI inference path to run on the user's machine rather than depending on a remote AI inference service.

That gives TrailLens an architecture centered around:

• local inference
• reduced dependence on cloud AI availability for the core model step
• a privacy-oriented image-processing path
• an open-weight model that can run within a local stack

For this project, open innovation isn't just a licensing detail.

It changes the product architecture.

🏗️ System Architecture

flowchart LR
    U[User Outdoors]
    C[Camera]
    B[Browser]
    A[Next.js /api/analyze]
    V[Payload Validation]
    O[Local Ollama]
    G[Gemma 3 4B]
    M[FieldMission]
    S[Safety Gate]
    Q[Mission Quality]
    P[Pocket Mode]
    X[Outdoor Session]
    R[Reflection]
    F[Field Record]

    U --> C
    C --> B
    B --> A
    A --> V
    V --> O
    O --> G
    G --> M
    M --> S
    S --> Q
    Q --> B
    B --> P
    P --> X
    X --> R
    R --> F

The major boundaries are intentionally explicit:

Browser → Validation → Local Inference → Structured Mission → Safety → Quality → Outdoor Activity

🔬 What Happens After Gemma Responds?

I didn't want a naive:

MODEL OUTPUT
     ↓
SHOW IT TO USER

pipeline.

Instead:

sequenceDiagram
    participant User
    participant Browser
    participant Next as Next.js
    participant Ollama
    participant Gemma

    User->>Browser: Capture outdoor subject
    Browser->>Next: POST /api/analyze
    Next->>Next: Validate payload
    Next->>Ollama: Structured inference request
    Ollama->>Gemma: Multimodal analysis
    Gemma-->>Ollama: Structured FieldMission
    Ollama-->>Next: Model response
    Next->>Next: Safety validation
    Next->>Next: Mission quality evaluation
    Next-->>Browser: Analysis + Mission
    Browser-->>User: Mission Ready

A generated mission therefore passes through application-level validation before it reaches the user experience.

🛡️ Safety Is Part of the AI Design

An outdoor AI assistant shouldn't blindly turn every plausible model output into an activity.

TrailLens includes a deterministic safety layer that can reject unsafe challenge language and substitute a safe fallback.

The system explicitly accounts for categories such as:

• wild plant or mushroom ingestion
• harvesting or collecting specimens
• dangerous terrain
• inappropriate wildlife interaction

The principle is simple:

AI can create curiosity without creating unnecessary risk.

Safety is therefore treated as an application boundary, not as something the model is simply expected to get right.

🧪 A Plausible Mission Isn't Necessarily a Good Mission

One of the biggest lessons from building TrailLens was:

A mission sounding plausible does not mean it is a good field mission.

So I built a deterministic Mission Quality Evaluator.

Every mission can be evaluated across five dimensions:

Each dimension is scored from 0–20, for a total of 100.

The fixture suite contains 10 deterministic scenarios.

The benchmark produced an average score of 85.4 / 100, while Specificity was the weakest dimension at 14.6 / 20 average.

That result was valuable.

I did not change the rubric to make the numbers look better.

The failures showed exactly where generated missions still needed improvement.

That is the point of an evaluator.

⚙️ Engineering the Local Model

TrailLens includes a reproducible Gemma benchmark suite covering:

• cold vs. warm inference
• model residency
• token ceilings
• prompt compression
• image-resolution experiments
• structured output
• reproducibility

One repeated finding was the effect of keeping the local model resident:

Warm model-load overhead was in the tens of milliseconds in the tested runs, versus multi-second cold loading.

The project also makes an important distinction:

model-load latency is not the same thing as total end-to-end inference latency.

Absolute inference time varied across repeated runs on the same test machine, so the benchmark is documented as empirical testbed evidence rather than a universal performance guarantee.

✅ Verification

TrailLens is backed by a real automated verification suite.

Current project verification includes:

• 100 automated tests
• ESLint with zero errors
• successful Next.js production build
• deterministic safety tests
• Mission Quality fixture evaluation
• structured FieldMission validation
• local Gemma benchmark artifacts
• reproducibility evidence

The repository deliberately separates different forms of evidence:

Functional Correctness
        ↓
Contract Validation
        ↓
Safety Validation
        ↓
Mission-Quality Evaluation
        ↓
Performance Benchmarking
        ↓
Reproducibility
        ↓
Real-World Field Validation

That distinction matters.

A passing unit test is not the same thing as proving that a person enjoyed a field mission.

🌿 Why This Fits "Touch Grass"

The challenge is about using open-source AI to create something that gets people away from the screen and into the real world.

TrailLens was built around that requirement from the beginning.

Typical AI interaction

QUESTION
   ↓
AI ANSWER
   ↓
MORE QUESTIONS
   ↓
MORE SCREEN TIME

TrailLens

OBSERVATION
   ↓
GEMMA
   ↓
FIELD MISSION
   ↓
PHONE DOWN
   ↓
REAL WORLD
   ↓
REFLECTION

The screen is supposed to be the shortest part of the experience.

That is the product.

🏕️ What Makes the Idea Different?

The interesting part isn't simply:

"Gemma can identify a leaf."

The interesting part is:

What happens after the identification?

Instead of ending with:

"This is probably an oak leaf."

TrailLens can turn that observation into:

"Find another nearby leaf and compare its lobes and main veins."

That changes AI from an answer engine into a field-experiment trigger.

And then the phone is supposed to disappear from the experience.

📖 The Field Record

The end product is not a chat history.

It is a field record.

A compact memory of:

• what was investigated
• what mission was attempted
• session information
• what the user personally noticed

The reflection is intentionally user-authored.

TrailLens doesn't ask the model to fabricate what the person experienced.

🛠️ Built With

Frontend

• Next.js
• React
• TypeScript
• Tailwind CSS

AI

• Google Gemma 3 4B
• Ollama
• structured JSON / JSON Schema output

Engineering

• Zod
• Vitest
• ESLint
• Turbopack
• deterministic safety rules
• deterministic Mission Quality evaluation

📈 What I Actually Built

The project evolved through concrete engineering milestones.

M1 — Field Mission Contract

A structured contract between model output and physical-world activity.

M2 — Local Gemma Latency Engineering

Cold/warm benchmarking, model residency, prompt compression, token boundaries, resolution experiments, and structured output testing.

M2.1 — Reproducibility Evidence

A second complete benchmark run to separate reproducible engineering behavior from variable wall-clock latency.

M3 — Pocket Mode + Reflection + Field Records

The physical immersion and reflection loop.

M4 — Mission Quality + Grounding

A deterministic 5-dimension evaluator backed by a 10-fixture test suite.

Productization

An editorial field-guide interface, camera-pipeline hardening, SDLC documentation, contributor documentation, and engineering evidence.

🔍 What I Learned

The biggest lesson wasn't:

"Make the model smarter."

It was:

Design the system around what the model is good at — and explicitly constrain what it isn't.

That led to several architectural decisions:

• structured model output
• deterministic safety gates
• deterministic mission-quality evaluation
• performance benchmarking
• reproducibility checks
• Pocket Mode
• user-authored reflection
• explicit evidence boundaries

The result is less like a chatbot and more like an AI-powered field instrument.

⚠️ What TrailLens Does Not Claim

I want the project to be honest about its limits.

The Mission Quality system is a deterministic lexical and structural proxy. It is not a semantic judge of the physical world.

The 10-fixture benchmark is not a human user study.

Benchmark latency is measured on a specific local test environment and should not be interpreted as a universal hardware guarantee.

Actual outdoor engagement depends on people, terrain, weather, curiosity, and context.

Those limitations are documented deliberately.

Reproducibility is more useful than inflated claims.

🌎 Open Source

TrailLens is open source:

GitHub

https://github.com/suvendukungfu/traillens

The repository includes:

• application source
• architecture documentation
• SDLC documentation
• evaluation reports
• benchmark artifacts
• Mission Quality fixtures
• contributor instructions
• changelog

🚀 Run TrailLens Locally

Requirements

• Node.js
• Ollama

Install Gemma:

ollama pull gemma3:4b

Clone:

git clone https://github.com/suvendukungfu/traillens.git
cd triallens

Install dependencies:

npm install

Run:

npm run dev

Then open:

http://localhost:3000

🧭 The Philosophy

The entire project can be reduced to one sentence:

Use AI once. Then go outside.

Or even shorter:

AI is the bridge. The real product is outside.

That is why TrailLens exists.

🌱 Hacktoberfest 2026 — Touch Grass

TrailLens was built for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

The challenge asks builders to create something with open-source AI at its core that gets people away from the screen and into the world.

TrailLens was designed around exactly that constraint.

The most important screen in the product is the one that tells you:

PHONE DOWN.

Then the app gets out of the way.

🔗 Links

GitHub:

https://github.com/suvendukungfu/traillens

Hacktoberfest Week 1:

https://dev.to/challenges/hacktoberfest-week1-2026-10-05

License: MIT

Final Thought

Most AI assistants try to keep you talking to them.

TrailLens has a different goal:

Say something useful.

Give you something to investigate.

Then get out of the way.

🌿 Look beyond the screen.