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 --> FThe 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 ReadyA 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:
| Dimension | What it asks |
|---|---|
| Grounding | Is the mission connected to what was actually observed? |
| Specificity | Does it contain concrete actions and observable details? |
| Safety | Does it avoid known hazards? |
| Executability | Can a person realistically perform it? |
| Outdoor Value | Does it require real-world observation instead of screen-only thinking? |
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
FieldMissionvalidation - 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.
Top comments (1)
Awesome job @suvendukungfu 👏🔥🔥