DEV Community: Aritro Bag

I Trained an Open Tabular AI to Catch the 72-Hour Fall Foliage Peak (So You Can Keep Your Phone in Your Backpack)

Aritro Bag — Mon, 12 Oct 2026 05:14:30 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Every autumn, millions of outdoor enthusiasts scramble to catch peak fall foliage. It is one of the most breathtaking natural spectacles on earth—and one of the most frustrating to time. The window of true peak vibrancy lasts roughly 72 hours before cold rains and wind strip the canopy bare.

To catch it, hikers currently face two bad options:

Coarse, paywalled tourism maps: Coarse statewide county-level blobs sponsored by regional hotel boards that completely ignore elevation, microclimate valleys, and specific tree canopy species.
Screen-addicted trail apps: Outdoor apps that demand you keep staring at a glass rectangle on the trail, buzzing with notifications, draining battery in cold weather, and demanding constant GPS screen time.

I built Wander: an open phenology forecaster and zero-screen trail companion.

Wander is designed around a radical Zero-Screen Philosophy:

< 30 seconds on screen: Open the web app, let the tabular foundation model calculate the exact 72-hour peak color window calibrated to trail elevation and canopy mix.
At the trailhead: Listen to a 45-second natural audio briefing outlining terrain, weather conditions, and tree species to look out for.
On the trail: Carry a 1-page printable pocket field card folded into your shirt pocket. Your phone stays zipped away inside your backpack.

The best technology for the outdoors is the one that gets out of the way.

Demo

Live Web App: https://wander-web-rg30.onrender.com
API Documentation & Healthcheck: https://wander-api-7t4f.onrender.com/docs · /health

Code

dev-Aarish / wander

Wander 🥾

Open Phenology, Fall Peak Foliage Forecaster & Zero-Screen Trail Companion

Built for the DEV Hacktoberfest 2026 Challenge: Week 1 — Touch Grass (#hf26challenge)
"The best builds here should make the screen the shortest part of the experience."

💡 The Problem & The Zero-Screen Solution

Every autumn, millions of hikers scramble to catch the elusive 72-hour peak foliage window. Existing solutions are either:

Coarse, paywalled tourism statewide maps that lack elevation accuracy.
Clunky smartphone apps that require constant screen checking on the trail, ruining the immersion of nature.

Wander is built on a radical Zero-Screen Philosophy:

< 30 seconds on screen: TabPFN computes the exact 72-hour peak window from micro-weather physics, elevation, and canopy species.
At the trailhead: Listen to a 45-second ElevenLabs audio briefing outlining terrain, weather, and key species.
On the trail: Carry a 1-page printable pocket field card. Your phone stays…

View on GitHub

The Biophysical Phenology Engine

Plant phenology (the timing of cyclical biological events like autumn leaf senescence) isn't a text generation problem. It is an environmental physics problem governed by thermal chill hours, solar photoperiod shortening, elevation lapse rates, and drought stress.

Rather than asking an LLM to guess dates, Wander couples TabPFN (Prior Labs) with calibrated bioclimatic formulas derived from U.S. Forest Service and NOAA meteorological datasets:

# backend/app/services/phenology_model.py:107
# Base day of peak for baseline temperate hardwood forest calibrated to mid-October
base_peak_doy = 285.0

# Hopkin's Bioclimatic Law: ~0.8 days shift per degree north, ~0.9 days per 500m elevation
lat_shift = (latitude - 42.0) * 0.8
elev_shift = ((elevation_m - 500.0) / 500.0) * 0.9

# Species thermal sensitivity offset (Aspen vs Sugar Maple vs Red Oak vs Larch)
species_offset = (
    (canopy.quaking_aspen_pct * -1.0) +
    (canopy.alpine_larch_pct * -2.0) +
    (canopy.sugar_maple_pct * 0.0) +
    (canopy.paper_birch_pct * -0.5) +
    (canopy.red_oak_pct * 2.0) +
    (canopy.american_beech_pct * 1.5)
) / total_canopy_weight

# Chill hours acceleration threshold (~350 hours cumulative below 7°C)
chill_hours_norm = weather.chill_hours_cumulative / 350.0
chill_factor_shift = (chill_hours_norm - 1.0) * 1.5

target_peak_doy = base_peak_doy - lat_shift - elev_shift + species_offset - drought_shift - chill_factor_shift

As the peak approaches, chlorophyll $a/b$ decays along a Gompertz sigmoid curve while anthocyanin (fiery reds and purples) and carotenoid pigments peak:

# backend/app/services/phenology_model.py:163
# Chlorophyll & Anthocyanin decay curves
if foliage_pct <= 100.0:
    chlorophyll_pct = round(max(5.0, 100.0 - (foliage_pct * 0.95)), 1)
    anthocyanin_pct = round(min(98.0, (foliage_pct / 100.0) ** 1.6 * 95.0), 1)
else:
    chlorophyll_pct = round(max(0.0, 5.0 - (foliage_pct - 100.0) * 0.4), 1)
    anthocyanin_pct = round(max(20.0, 95.0 - (foliage_pct - 100.0) * 3.5), 1)

How I Built It

Architecture Overview

graph TD
    subgraph Client ["Zero-Screen Client Tier (React 18 + Vite + Tailwind)"]
        UI["Trail Explorer & Peak Timeline (<30s Screen Time)"]
        PrintCard["1-Page Printable Pocket Field Guide"]
        AudioPlayer["Trailhead Audio Player"]
    end

    subgraph BackendGateway ["Backend API (FastAPI on Render)"]
        Router["REST & Hybrid Search Endpoints"]
        CardEngine["Naismith Rule Pocket Card Generator"]
        ElevenLabsService["ElevenLabs Natural Voice Briefing Engine"]
        TabPFNEngine["TabPFN Tabular Regressor Engine"]
        TigerClient["Tiger Data Vector Store Client"]
    end

    subgraph Storage ["Database & Vector Store"]
        TigerDB[("Tiger Data: PostgreSQL + pgvector")]
        TrainingData[("USFS & NOAA Phenology Ground Truth")]
    end

    subgraph DurableOrchestration ["Durable Orchestration (Temporal)"]
        SyncWorkflow["FoliageSyncWorkflow"]
        WeatherAct["fetch_micro_weather_activity"]
        TabPFNAct["batch_tabpfn_inference_activity"]
        DbSyncAct["sync_tiger_db_activity"]
    end

    UI --> Router
    PrintCard --> CardEngine
    AudioPlayer --> ElevenLabsService

    Router --> TabPFNEngine
    Router --> TigerClient
    Router --> ElevenLabsService
    Router --> CardEngine

    TabPFNEngine --> TrainingData
    TigerClient --> TigerDB

    SyncWorkflow --> WeatherAct
    WeatherAct --> TabPFNAct
    TabPFNAct --> TabPFNEngine
    TabPFNAct --> DbSyncAct
    DbSyncAct --> TigerDB

The stack is FastAPI, TabPFN, Tiger Data (PostgreSQL + pgvector), Temporal, ElevenLabs, and React 18.

TabPFN (Prior Labs) Tabular Regressor: Traditional gradient boosted trees (XGBoost/LightGBM) overfit severely on small seasonal datasets without tedious hyperparameter tuning. TabPFN acts as a foundation model for tabular data, running Bayesian neural inference over 11 micro-features (elevation_m, latitude, day_of_year, chill_hours_cumulative, solar_radiation_mj, drought_stress_index, and 5 canopy percentage features) in milliseconds with zero hyperparameter tuning.
Tiger Data (PostgreSQL + pgvector): Stores trail metadata, elevation profiles, and vector embeddings of forest canopy descriptions. Hikers can run natural language semantic queries (e.g., "golden aspens reflection in high alpine lake"), combining cosine similarity with relational filters (elevation > 2500m).
Temporal Durable Workflows: Cold fronts and sudden temperature drops shift foliage timelines overnight. A Temporal FoliageSyncWorkflow runs background synchronization: polling NOAA weather stations, recomputing TabPFN predictions in batch with automated retry backoffs, and atomically synchronizing updated peak dates to Tiger Data.
ElevenLabs Audio Briefings: Generates a concise 45-second pre-trail briefing at the trailhead with natural, human cadence (using Brian/Adam nature guide voices) so hikers don't have to read their phones in bright sunlight.
1-Page Printable Pocket Card Engine: Uses Naismith's Rule to calculate estimated hiking time based on ascent and distance, laying out key elevation checkpoints and canopy identification notes onto an origami-foldable field sheet.

Why Does Open Innovation Matter?

This project exists because open science and open-weight tabular AI make decentralized tools viable without relying on closed APIs or corporate walled gardens:

Verifiable Ecological Physics vs. Black-Box Tourism: Closed commercial foliage maps are opaque marketing assets meant to boost hotel bookings. By building on open USFS/NOAA citizen science data and TabPFN, anyone can inspect the biophysical equations governing chill hours and elevation shifts.
Backcountry Privacy (Zero Telemetry): Commercial hiking and fitness trackers routinely upload hiker location history and trails to remote ad trackers. Wander's zero-screen philosophy ensures that your hike stays completely unmonitored: check the model, print the card, and leave no digital footprint on the mountain.
Zero-Cost Inference Without Token Billing: Foundation tabular models like TabPFN run in-memory inference without recurring per-query LLM token costs. Outdoor tools can be hosted affordably by small trail associations and community conservancies.

Prize Categories

Best Use of TabPFN (Featured): TabPFN is the core intelligence engine of Wander, performing tabular regression over 11 bioclimatic features to predict chlorophyll breakdown %, peak color window (72h), and days-to-peak without overfitting.
Best Use of Render (Featured): Wander's full stack is configured and hosted on Render via Infrastructure-as-Code (render.yaml), powering the FastAPI Web Service backend and Vite/React Static Site.
Best Use of Tiger Data: Uses Tiger Data (PostgreSQL + pgvector) to index trail geospatial data and run natural language semantic vector search over forest canopy compositions.
Best Use of Temporal: Implements a durable FoliageSyncWorkflow with retry policies to orchestrate periodic micro-weather updates, batch TabPFN model recalculations, and database syncs.
Best Use of ElevenLabs: Generates 45-second natural audio pre-trail briefings to deliver key elevation, weather, and species details hands-free at the trailhead.
Best Use of Entire: The complete interactive agent session documenting the design, implementation, and deployment iterations is embedded directly in this submission.

I Reverse-Engineered 3 Years of Exam Papers on localhost (With Wi-Fi Off)

Aritro Bag — Sun, 04 Oct 2026 20:04:12 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Every AI study tool wants your lecture PDFs. Uploading copyrighted course material to a stranger's inference endpoint is a trade-off, and the friend I built this for wasn't willing to make it.

So I built Gist, a study partner that never makes that trade. It runs entirely on the laptop. PDFs are parsed, embedded, and searched locally, the LLM runs locally in Ollama, and the app works with the Wi-Fi switched off. There is no API key in the codebase because there is no API involvement.

The core of Gist isn't another generic chatbot wrapper. It is an intelligent past question paper analyser. You drop in 3+ years of past university exam PDFs, and Gist reverse-engineers the exam pattern:

Which questions and variations repeat.
What each topic is actually worth in total marks weightage.
How frequently each concept appears across semesters.
How your personal quiz drills cross-reference against that weightage.

Demo

Product page: https://gist-landing.onrender.com

Demo Video: https://youtu.be/QMNTq5FTj8k
disclaimer: i'm not a good speaker

Code

dev-Aarish / gist

Turn your lecture notes and past papers into an offline exam training ground. Grounded RAG with page citations, historical mark weightages, high-yield weak spot detection, and timed mock exams. Runs 100% locally on open-weight LLMs via Ollama — zero cloud, zero API keys.

Gist

Gist is an offline, privacy-first AI study partner powered by local open-weight large language models (LLMs) via Ollama, FastAPI, and React. It combines page-grounded document Q&A with an exam intelligence engine that analyzes past question papers, detects topic marks weightages, prioritizes high-yield weak spots, and conducts timed mock exams ("Grill Me" mode).

Architecture Overview

graph TD
    subgraph UserInterface ["Frontend Client (React 18 + Vite - Dark Theme)"]
        UI["Web Interface: Chat, Past-Paper Workbench, Priority Matrix, Quizzes, Timed Mock Exams"]
    end
    subgraph BackendGateway ["Backend API (FastAPI)"]
        API["REST & SSE Gateway (Port 8000)"]
        Ingest["Document Ingestion Engine (PyMuPDF)"]
        Analyzer["Past-Paper Analyzer Engine"]
        RAG["Grounded RAG Pipeline"]
        Quiz["Adaptive Quiz & Instant Bank Engine"]
        Exam["Mock Exam Simulator ('Grill Me' Engine)"]
    end
    subgraph StorageLayer ["Local Persistent Storage"]
        Chroma["ChromaDB: Vector Embeddings"]
        SQLite["SQLite (tracker.db): Papers, Question Bank, Mastery & Attempt History"]
        Uploads["PDF Storage (data/uploads)"]
    end

    subgraph LocalLLM ["Local Inference Engine (Ollama)"]
        EmbedModel["Embedding Models: nomic-embed-text / bge-m3"]
        ChatModel["Dynamic Open-Weight Models: Gemma

…

View on GitHub

The parsing rules are the part I'd walk through first. Marks appear in university papers as [10], (5 marks), 15M, or a bare 4 + 6 + 2 = 12 breakdown, and getting this wrong means every downstream percentage is wrong:

# backend/analyzer.py:134
m_single = re.search(
    r'(?:\[|\()?\b(\d{1,2})\s*(?:marks?|mark|m|pts?)\b(?:\]|\))?|\[(\d{1,2})\]',
    line,
    re.I,
)

Mark weightage is the input to the entire priority model, so it has to come out of the PDF exactly, not approximately.

How I Built It

Everything runs on the user's machine. No network calls leave the host, which makes the privacy claim checkable rather than a policy promise.

Pipeline

The stack is FastAPI, PyMuPDF, ChromaDB, SQLite, and Ollama on the backend, React on the front. About 4,700 lines of Python now, up from 2,000 when the quiz was the main feature.

Resources I took help of:

Antigravity(CLI)
Opencode
Freebuff
Skills(frontend-design, ui-ux-pro-max, emil-design-eng, impeccable, documentation-writer)

Why the Analyser is Rules-First, LLM-Second

My first prototype sent the entire exam paper to an LLM asking for structured JSON. It was sluggish, expensive on local compute, and hallucinated marks.

The current architecture is a three-stage hybrid pipeline:

Deterministic Regex Parse: Splits questions on structural boundaries (Q1(a), 2., (i)), groups MCQ sub-options under their parents, filters boilerplate university headers, and extracts marks per line. Runs in milliseconds with 100% fidelity.
Keyword Topic Inference: A domain-specific ontology maps question vocabulary to canonical syllabus topics (bcnf, 3nf, attribute closure → Normalization; precedence graph, 2pl, dirty read → Transactions). Using deterministic mapping prevents small 7B models from inventing arbitrary topic names.
Micro-LLM Pass for Edge Cases: Only unclassified questions falling through to the generic category are sent to Ollama, batched at ≤ 12 snippets with num_predict=200. Full LLM extraction is reserved strictly as a fallback for unstructured, legacy scanned layouts.

A canonical topic dictionary folds all variations back into fixed buckets so percentages aggregate cleanly without fragmentation.

Turning Weightage into a Ranked Study Plan

Two mathematical formulas drive the recommendation engine:

Exam Importance measures how heavily a topic features across years, with frequency acting as a credibility multiplier on total marks share:

exam_importance = marks_pct * (0.6 + 0.4 * (frequency_pct / 100))

(Multiplication ensures a topic worth 15% across all past papers ranks significantly higher than a topic appearing in only one isolated year).

Composite Priority scales exam weight against your personal weakness:

priority = exam_importance * ((100 - accuracy) / 100) * 1.5

Why Open Innovation Matters

This project exists solely because open weights and local runtimes are now viable on standard consumer laptops. A closed, cloud-only model would have compromised the project in three fundamental ways:

Verifiable Privacy: No keys to leak, no remote database to breach, and no data harvesting. Anyone can audit the 4,700 lines of Python and verify that zero packets leave localhost.
Zero-Cost Feedback Loops: Prompt tuning and evaluation loops take seconds. Tweaking extraction prompts and re-running against local weights is free, reproducible, and immune to upstream provider deprecations or rate limits.
Hybrid Architecture Viability: A deterministic rules-first pipeline that saves LLM calls only makes architectural sense when local execution is unmetered.

My Agent Session

Here is the interactive session trace detailing the design iterations behind the local-first architecture, the 3-stage hybrid parsing engine, and the priority formula:

Building Gist: Local-First Offline Exam Intelligence & 3-Stage Hybrid Parser

You

How can we build Gist as a 100% local, offline exam intelligence engine so that no university course PDFs ever leave the student's laptop?

Agent

We design an entirely local architecture powered by Ollama for local open-weight LLMs (Gemma 2 / Llama 3.2), FastAPI for the backend gateway, PyMuPDF for deterministic extraction, ChromaDB for local vector search, and SQLite for persistent tracking. Zero API keys, zero network telemetry.

▸ run_command cat << 'EOF' > backend/architecture_spec.md # Local-First Architecture: 1. Do...

Input

$ cat << 'EOF' > backend/architecture_spec.md
# Local-First Architecture:
1. Document Ingestion: PyMuPDF (Local)
2. Vector Indexing: ChromaDB (Local SQLite/DuckDB)
3. Topic Classifier: Regex heuristics + Keyword Ontology + Ollama fallback
4. Storage: SQLite tracker.db
EOF

Output

Architecture spec initialized.

You

The LLM is hallucinating marks and taking too long when parsing entire exam PDFs at once. How do we make question and marks extraction deterministic and fast?

Agent

We replace full-paper LLM generation with a 3-Stage Hybrid Parser:
1. Deterministic Regex Parsing: Extract question boundaries (e.g. Q1(a), 2.) and mark tags ([10], (5 marks), 15M) in milliseconds with 100% fidelity.
2. Keyword Ontology Inference: Map question keywords directly to syllabus topics (e.g. 'bcnf', '3nf' -> Normalization).
3. Micro-LLM Pass: Only send leftover, unclassified questions to Ollama in small batches with low token limits.

▸ write_to_file # backend/analyzer.py regex pattern matching m_single = re.search(r'(?:\[|\()...

Input

# backend/analyzer.py regex pattern matching
m_single = re.search(r'(?:\[|\()?\b(\d{1,2})\s*(?:marks?|mark|m|pts?)\b(?:\]|\))?|\[(\d{1,2})\]', line, re.I)

Output

Updated backend/analyzer.py with deterministic parsing rules.

You

How do we turn the extracted topic mark weightage and student quiz accuracy into an actionable revision priority matrix?

Agent

We compute Exam Importance using question frequency as an amplifier over marks share, then multiply by student weakness:
- exam_importance = marks_pct * (0.6 + 0.4 * (frequency_pct / 100))
- priority = exam_importance * ((100 - accuracy) / 100) * 1.5
Untested topics are penalized with an assumed 75% weakness rather than 0% accuracy to prioritize high-risk unknowns safely.

Prize Categories

Best Use of Gemma: Gist is built on Google's open-weight Gemma 2 (gemma2:9b and lightweight gemma2:2b), running locally via Ollama to power the micro-LLM topic classification pass, grounded RAG answering, and automated mock exam grading.
Best Use of Render: The interactive product landing page and live web preview are deployed on Render at https://gist-landing.onrender.com (configured via render.yaml).
Best Use of Entire: The agent session transcript behind Gist's local-first architecture and hybrid parser design is embedded directly in this write-up.