DEV Community: Soumwadeep Guha

Dormant: an open-weight model read my Mac's Spotlight logs and found 71 GB I will never open again

Soumwadeep Guha — Wed, 21 Oct 2026 10:59:15 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Dormant answers one question about a file on my Mac: is this ever coming back?

Not "is this file important", which is a different and much harder question. Just this: the file has been shut for three weeks, will it be opened again inside ninety days? If the answer is no, it goes on a list. If I approve the list, Dormant moves those files out of the way.

The core is TabPFN, an open-weight tabular foundation model, running locally on CPU. No internet, no API key, no account, no bill. It was built and benchmarked on an 8 GB Apple M1, which is the kind of machine most of us actually have.

The chore it removes

I know exactly which folder is the problem. I have opened it eleven times, looked at four hundred file names, felt the cost of deciding about each one, and closed it. That is not a memory problem. It is a thousand small decisions problem, and no human with a deadline is going to make them on a Tuesday.

So the sloth part is literal. Dormant makes the thousand decisions overnight, in a form I can approve with one keypress.

What it found on my machine

Dormant found 519 files worth 71.0 GB it is 99% sure you will not reopen
inside 90 days. On the held-out slice it was right 99% of the time it said stop.

68.2 GB of that is one drone footage folder I have not opened since the week I filled it.

Three levels of letting go

The ladder is deliberately uneven, because the destructive rung should be harder to reach than the recoverable ones.

action	what happens	reversible by
Stage	moves files into a dated folder, writes a manifest	`undo`, from inside Dormant
Trash	moves files to the macOS Trash	Finder's Put Back, or `undo`
Delete permanently	the only path that calls `unlink`	nothing in this program

Permanent delete requires the caller to supply the literal word DELETE, writes the manifest of what is about to be lost before the first file goes, and undo refuses to touch a delete manifest. Stage and Trash are tested against a tripwire: os.remove, os.unlink and os.rmdir are patched to raise, so if they ever learn to delete, the suite fails.

And before any of it, there is a preview. Selecting six rows and pressing view shows the actual images, PDFs, text and video in a drawer, because the fastest way to trust a list of 519 files is to look at six of them and see that it is right.

Demo

The dashboard is a local FastAPI service plus one page of vanilla JavaScript. The three.js build is vendored into the repository rather than loaded from a CDN, because a product whose whole argument is "this never needs the internet" cannot afford to depend on one.

Run it locally

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

python cli.py scan      # index files from stat() and Spotlight metadata (~12s)
python cli.py brief     # the two-line morning brief
python cli.py top       # the files it thinks are dead
python cli.py bench     # the scoreboard, on your machine
python cli.py serve     # mission control on http://127.0.0.1:8712

See it without touching anyone's disk

The index contains file paths, sizes and the dates I opened things. That is personal, so the repository ships a synthetic corpus with the same shape and none of the names. Every screenshot in this post came from it.

python cli.py --demo demo && python cli.py --demo run --bench && python cli.py --demo serve

What the dashboard shows

Morning brief. Two lines. Every number in them is computed, never generated.
Dormancy field. A 3D plot where radius is a file's age and height is the model's dormancy score, so the shape of a neglected disk is visible before you read anything.
Volume forecast. A gauge, the growth curve, and the date the volume reaches a warning level.
Reclaim ledger. Gigabytes identified, files on the stop list, days bought at the current growth rate.
Model bench. The scoreboard below, plus a chart of how each model degrades as the labelled corpus shrinks.
Dormant register. The ranked list: filterable, sortable, multi-selectable, with preview, stage, trash and delete on the selection.
Agent console. One sentence in, validated tool calls out.

Code

https://github.com/soumwadeep/Dormant

GPL-3.0. Six commits, 43 tests, no build step.

dormant/
  scanner.py   two-pass ingestion: os.walk for the universe, mdls for history
  features.py  observation points inside each dormancy streak, and their labels
  dataset.py   time-split holdout and rolling-origin folds
  model.py     TabPFN provider, four baselines, the scarcity benchmark
  forecast.py  disk projection from measured snapshots or a reconstructed curve
  brief.py     the two lines, as a template over computed integers
  action.py    stage, trash, permanent delete, undo, preview metadata
  agent.py     a sentence in, validated tool calls out
  demo.py      the synthetic corpus
api/app.py     FastAPI service, bound to 127.0.0.1
cli.py         scan, brief, top, bench, run, preview, archive, trash, purge, undo, serve
web/           one page, vendored three.js, two themes, four accents, mobile tabs
tests/         43 tests: label leakage, evaluation integrity, file safety

How I Built It

The model, and why it is the right shape for this

TabPFN is not a language model doing arithmetic. It is a transformer trained once, offline, on millions of synthetic tabular datasets, which then does in-context inference: your labelled rows go in as context and a posterior comes out. No gradient step on my data, no training run, no per-token bill.

That matters here because a personal file corpus is small. This machine produced about seven thousand labelled rows from 669 personal documents. That is precisely the regime an in-context model is built for, and precisely the regime where "let me fine-tune something" is a bad afternoon.

The labels were already on my machine

This is the part that made the project possible in a week rather than a month. macOS records every date a document app opened a file.

mdls -name kMDItemUsedDates ~/Documents/tax.pdf
#   "2024-02-11 09:14:02 +0000",
#   "2024-09-27 18:30:00 +0000"

So I did not have to run a logger and hope. I read three years of my own file-open history on the first pass.

Turning that into a supervised problem

For a file created at C with recorded opens d1..dk, Dormant builds one observation row per sampled point inside each dormancy streak. A row's features are only ever what existed at that date: age, days since last open, days since modification, how many times it has been opened, mean and max gap between opens, size, extension, folder depth, weekday and hour.

label	rule
`1`	some later open falls within 90 days of the observation date
`0`	the next open is more than 90 days away, or never arrives, and the window has closed
dropped	the 90-day window is still open, because the outcome has not happened yet

That third row is the difference between an evaluation and a fiction. An unclosed window is censored, and Dormant throws the row away rather than guessing at it.

The split is on the observation date, never random. Two rows from the same file share a history, so a random split puts yesterday inside tomorrow. Validation is rolling-origin: train on all history up to a cut, score the slice immediately after it.

Two passes for ingestion

os.walk plus os.stat gives the whole universe in under two seconds. mdls is a subprocess round trip to the Spotlight daemon, so it only runs on personal files, in a thread pool, ten seconds.

My first version paid 180 seconds to ask eight thousand repository files whether they had been opened. That was both slow and wrong: nobody double-clicks a vendored PHP file, and a model trained on those rows learns that everything in a repository is dead weight, which is true and useless. Files under .git, node_modules, vendor, Pods, any build-system marker, or any directory that looks like a checkout are indexed but never scored.

The forecast is arithmetic, not a model

Free space comes from disk_usage(). The growth rate comes from a Theil-Sen fit, which is robust to the one day a phone backup lands. The projection is a line. TabPFN is offered a second, learned projection of the same series, because Prior Labs describes the product as forecasting, but the headline date is always the one you could check with a calculator. If the growth rate is below 0.05 GB a day, Dormant says "no measurable fill rate" instead of printing a date eighty years out, which is exactly what my first version did.

Previewing files is a new kind of exposure

The preview endpoints hand out the contents of real files, so they are not open to anything that can reach 127.0.0.1:8712. The server generates a token at startup and injects it into the page's own HTML; every content endpoint requires it and returns 403 without it. Another process, or a website your browser visits while the dashboard is open, gets nothing. There is a test for that too.

What it measured

Real index on this machine: 88,250 files walked in about 12 seconds, 12,719 openable files stored, 669 personal documents, 283 of them carrying recorded open history, 6,918 labelable observation rows. Time-split holdout of 4,842 train and 1,800 test rows, cut 2025-03-01, 10.6% positive.

model	AUC	precision	recall	GB reclaimed	wrong calls
rule: 90 days idle	0.378	0.862	0.704	3.9	181
logistic regression	0.821	0.959	0.714	45.0	49
random forest	0.920	0.985	0.758	44.4	19
HistGradientBoosting	0.962	0.988	0.895	45.3	18
TabPFN-2 (open weights, what ships)	0.956	0.987	0.885	45.1	19

The first row is the finding. "Archive anything untouched for ninety days", which is what I would have written by hand in an afternoon, scores worse than a coin flip. Ninety days idle is exactly what a file looks like in the week before a deadline drags it back. The model is not beating a strawman. It is beating the heuristic that motivated the product, and that heuristic was mine.

The second finding is less comfortable, so it is in here. I benchmarked the models as the labelled corpus shrinks, expecting the open-weight model to take over at small sizes. It does not:

labelled rows	TabPFN	hist gb	random forest	logistic
120	0.934	0.936	0.883	0.654
240	0.944	0.961	0.906	0.716
480	0.943	0.952	0.885	0.935
960	0.943	0.956	0.885	0.775
1,920	0.947	0.953	0.902	0.801

HistGradientBoosting wins at every corpus size on my machine. TabPFN still ships as the default for reasons that are not the last decimal: no training run, no feature engineering loop, no hyperparameters, 444 MB of RAM, and changing the question from 30 days to 90 is a constant and a re-run rather than a re-fit. The baselines stay in the scoreboard precisely so that claim can be checked, and this table is what happened when I checked it.

What went wrong, because that is the useful part

An orientation error worth 0.6 AUC. My first benchmark reported TabPFN at 0.33, which I briefly believed about my own model. The model predicts will reopen; the product decides is dormant; I had scored the complement as if it were the class.
A threshold that was not a decision. With 91% of rows dormant, a threshold of 0.03 "meets 95% precision" by flagging everything. That is a description of the majority class, not a model. There is now a test that refuses any operating point below 0.5.
A stale index. Rows from an earlier scan were never removed, so file types I had excluded kept appearing in the list. A full scan now prunes what it did not see, but only when the walk completed, so a capped scan cannot delete the half it never looked at.
Repo files on the stop list. Files found through Spotlight were labelled personal even inside a checkout, which is how a vendored asset ended up ranked first. Directory context is now derived while walking, and for index-only files, from the path.

Why Does Open Innovation Matter?

There is no upload path. The training set is my Spotlight database: every date I opened every file on this machine. A closed API cannot have that, not because of a policy I would object to, but because the product would have to ship my filesystem's behavioural history to someone else's server in order to do something that takes 444 MB of RAM locally. The privacy argument here is not a promise. It is an absence.

Per-user adaptation costs nothing and happens every run. The model is fitted to this machine's habits each time, in 0.3 seconds, because in-context inference is just putting the rows in the prompt. A hosted model would need my history on its infrastructure. A fine-tuned model would need a GPU and a training run. Neither is what a personal utility should ask for.

It fits the laptop that has to run it. This is an 8 GB M1 with about 65 GB free, which is the constraint the whole project lives inside. TabPFN-2's checkpoint is 28 MB and peaks at 444 MB of RSS. I tested the recommended TabPFN-3.5 first: its fast checkpoint is 334 MB, the full model 876 MB, and the package puts a licence-acceptance wall plus an account in front of it. So 3.5 is wired in behind one environment variable, DORMANT_TABPFN_MODEL=3.5-fast, and is not the default. A product about doing nothing should not require a signup.

Cost to run is zero, permanently. 2,500 predictions in about 10 seconds on CPU. No meter. I can run it nightly for three years and it will never become a bill.

Swapping the model is a config change, not a rewrite. dormant/model.py treats the predictor as a provider, and the baselines sit in the same scoreboard on purpose, so the open-weight claim stays falsifiable rather than decorative.

Where open beat closed in practice: the moment I changed what "dormant" means, from 30 days to 90, the whole thing stayed mine. That is a horizon constant and a re-run. With a hosted model I would be re-deciding what I was willing to upload every time I changed my mind.

My Agent Session

The engine, the dashboard and this post were built in one long agent session against a live index of my own machine, which is the fastest way I have found to check a claim: every number in this post came from a terminal, not from a paragraph I wrote first.

Two moments were worth the whole session.

The first was the go/no-go test before any architecture existed. Install TabPFN, load the smallest checkpoint, predict three thousand rows, watch peak RSS. Ninety seconds later I had the answer: 444 MB, fits, continue. If it had needed 4 GB there would have been no project, and I would have known in five minutes rather than five evenings.

The second was the orientation bug, which only surfaced because the baselines were already in the scoreboard. A model that reports 0.33 AUC next to a logistic regression at 0.82 is telling you something about your code, not about your model. Without the boring baseline sitting in the same table, I would have shipped it.

(DevRelay session embed goes here.)

The Lazy Payoff

I ran it on my own machine, so these are my numbers, not a projection of them.


Files identified as never coming back	519
Space they hold	71.0 GB, of which 68.2 GB is one folder
Decisions I made instead of four hundred	one, plus a preview of six files
Wrong calls, measured on a 1,800-row holdout	19
Full scan of 88,250 files	12 seconds
Cost	$0 and zero API calls, permanently
Recovery if it is wrong	`undo`, or Finder's Put Back, for anything but a typed DELETE

The honest part: only 283 of my 669 personal documents carry any recorded open history at all. The other two thirds are scored from age, size, type and folder alone, which is why the product is named after an animal that is in no hurry. Every night it runs, it converts more of that population from unknown to observed, and the cold start stops being a cold start. The disk projection is the same story: it needs two distinct days of snapshots before it will give you a date, and on a first run it says "no measurable fill rate" instead of inventing one.

I have not deleted anything yet. That is deliberate: the list is 519 files, I have previewed six of them, and the folder holding most of the weight is one I am ready to let go of. Staging it tonight, undo if I change my mind.

Prize Categories

Best Use of TabPFN. TabPFN is the product, not a dependency. The open-weight tabular foundation model is the thing that decides whether 71 GB of my disk is a library or a landfill. It runs locally on CPU in 444 MB of RAM from a 28 MB checkpoint, it is re-fitted to this machine's habits on every run with no training step, and it is benchmarked against logistic regression, a random forest, HistGradientBoosting and the naive 90-day rule on a leak-free, time-split holdout of my own file history. The recommended TabPFN-3.5 is supported behind one environment variable and documented, with the reason it is not the default stated plainly: 334 MB of weights and an account wall on an 8 GB laptop defeats the point.

Thanks for reading. If you want to run it against your own disk, the five commands are above, and python cli.py bench will tell you whether these numbers reproduce on your machine. They may not, and that is the interesting part: the model is fitted to whatever history your Mac happens to have kept, so the report is yours.

A 1B model isn't smart enough to read a contract. So I never asked it to.

Soumwadeep Guha — Wed, 14 Oct 2026 06:03:32 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

TL;DR — RedPen is an offline contract reviewer for freelancers. 65 open rules decide what is dangerous; a local Gemma 3 1B model only rewrites that into language you can send. Nothing uploads, nothing costs per review, and $19 once is a survivable price because the model runs on the user's own laptop.

What I Built

A developer who just received a nine-page MSA has three options: sign it unread, pay a lawyer $200–400 an hour, or spend an evening googling "is pay-when-paid enforceable".

RedPen is the fourth option. Drop in an agreement — PDF, DOCX, or pasted from an email — and it returns the clauses that will cost you money or time, quotes the exact words that triggered each one, gives you replacement wording, and drafts the negotiation email. It runs entirely on your laptop: open weights, open rules, no account, no API key, no upload.

The buyer is any independent who signs things. The pitch is one sentence: your client's NDA never leaves your machine, because it never goes anywhere.

Demo

Demo — the whole review, from drop to drafted email. Captured headlessly at
progressive points while Gemma streamed over loopback: the 36 findings land first
(the rule pass is ~20 ms), then the brief, then the explanations, then the email.
Reproducible with python3 scripts/build_demo.py.

Full-resolution MP4: assets/demo.mp4

A deliberately hostile agency MSA — 2 pages, 687 words:

36 findings, nine of them STOP. The strip under the gauge isn't the model guessing — it's the numbers the contract actually states, pulled out with regex: Net 90, no deposit, 7-day notice, unlimited revisions, Delaware.

Every finding cites its source, so you can check the tool's work against the page:

Then the local model writes the email you'd actually send:

And the result that matters most — a genuinely fair contractor agreement, which comes back empty:

A tool that cries wolf gets uninstalled the first time it wastes an evening on a good contract.

And an internship offer letter, where the header reads DOC OFFER LETTER OR EMPLOYMENT TERMS
and the amber panel counts fields nobody has filled in. Different document, different rules:

The top STOP finding on that page is "The start date is before the letter itself" — a date
anomaly no keyword rule could catch — and below it, that the employer holds the intern's
original degree certificates.

git clone https://github.com/soumwadeep/RedPen.git && cd RedPen
brew install llama.cpp && pip install -e .
redpen                       # opens http://127.0.0.1:8790

Code

github.com/soumwadeep/RedPen — MIT, 4,092 lines of app code and 2,200 lines of tests, 65 rules, 191 tests, no compiled bindings to break on install.

How I Built It

One decision drives everything: the model never decides what is dangerous.

Layer 1 — 65 open rules, no model. Plain Python in redpen/rules/, in three libraries: freelance agreements, offer letters and internships, NDAs. Each rule carries its own explanation, a counter-clause you can paste, and the sentence to say in the email. PyMuPDF extracts the text, segmentation recovers clause numbering and keeps a page number and character span for every clause, and every finding quotes verbatim words.

Layer 2 — Gemma 3 1B via llama.cpp, language only. It reads what layer 1 already found and rewrites it for this contract: a three-line brief, a per-finding explanation, the negotiation email, and one pass at vagueness patterns can't see.

That split isn't modesty about small models. A 1B model is not reliable enough to judge a clause, and a rules engine is not good enough to write a persuasive email to a client. Each layer does the half it is actually competent at — and the report is complete with the model switched off entirely.

It runs on an 8 GB Apple Silicon MacBook, no GPU, no Docker: 769 MB of weights, 2.3 s to load, 0.83 GB resident. The rule pass takes 12–28 ms; a full review with the model layer, 11–17 s. Findings render instantly and the model's work streams in over SSE, so nothing blocks on a small model composing an email.

Then I fed it my own paperwork

Everything above was built against synthetic contracts I wrote myself. Then I ran it on six real documents — two internship letters, an offer letter with an NDA, an onboarding checklist, a freelance agreement — and it failed in ways my own samples could not have produced.

What it got wrong	Why it matters
Silently discarded page 1 of an offer letter	Segmentation only emitted text after the first numbered clause. In real offer letters page 1 is unnumbered prose — so the unpaid training period and the 6-day, 11am–8pm schedule were never analysed. It scored a document whose worst terms it had thrown away.
Told an intern they had no deposit clause	Freelance rules ran on employment terms: no deposit, no late-payment interest, no right to suspend. True, worthless — and printed directly above the real finding, which was that the employer was holding their original degree certificates.
Missed impossible dates	One internship was offered on 29/06/2023 for a term that started 3-Jul-2022 and ended 28-Apr-2023 — finished before the offer was written. No keyword rule can see that, so dates are now parsed in six formats and cross-checked.
Missed disguised perpetuity	An NDA ended its obligations "until all Confidential Information becomes publicly known" — never. A search for `perpetual\
Flagged sane drafting	"The Freelancer will not incur new expenses without approval" fired the expense-denial rule, because an unanchored {% raw %}`no` matched inside `not`.
Read blanks as hostility	`[city, state] will have exclusive jurisdiction` scored at full severity. Unfilled fields are now counted, shown as their own panel, and any finding triggered by a blank is demoted — an unfinished draft is not a decision being made against you.

Six real documents, six bugs. That's the loop this architecture exists for: when it misjudges a document type, the fix is a rule, not a retraining run or a support ticket.

Guard-rails, all learned from the model failing

Failure	Guard
Cites a clause that doesn't exist	Resolved against real clauses, else dropped. It often answers with the vague word it spotted instead of a number, so that's resolved too — but only when the word appears in exactly one clause.
Drops three of your six asks	Coverage checked against the wording you were told to request. Format is not checked: my first validator rejected a perfectly good bulleted email for not being numbered.
Signs your email "Max"	Stripped and replaced with `[your name]`.
Claims to be a model it isn't	When I swapped weights to test model-independence, the UI still said "gemma" while Qwen had written it. The label was hard-coded; now it reads from the model that ran.
Returns junk, or no engine is running	Every role has a deterministic fallback, so the report is always complete.

Why Does Open Innovation Matter?

Four things a closed API structurally cannot offer.

1. The client's NDA never leaves the laptop. A freelancer's most sensitive document is the one describing work for the client who is already paying them. "We promise to delete it in 30 days" is not the same as "it was never transmitted." This is enforced in code, not policy: the HTTP client raises if a base URL isn't loopback, so a stray environment variable cannot turn a privacy tool into an uploader — there's a test for that. Uploads are parsed from bytes and never written to disk; the last eight reviews live in a bounded in-memory cache; the UI and exported brief contain no remote src or href.

scripts/offline_proof.sh runs a full review while sampling every socket the process holds:

· sockets observed during the run:
    19876 127.0.0.1:52704->127.0.0.1:8777
    7599  127.0.0.1:8777->127.0.0.1:52704
✓ PASS -- every socket was loopback. Review score 99/99, no request left the machine.

The first version of that script passed by observing nothing, because I built the PID list with literal parentheses and lsof never got a valid argument. A proof that looks at nothing proves nothing, so it now prints what it saw.

2. Zero marginal cost is what makes a one-time price survivable. I looked at hosting. A box big enough for the weights runs about $25/month for 2–5 tokens/second on shared CPU — slower than the user's own laptop, with every contract landing on a server they don't control. Worst of both. Locally, user #500 costs nothing extra, which is what lets this be $19 once instead of a subscription defending a per-seat API bill.

3. The rules are editable, which is the actual moat. If you edit video, "perpetual, all-media, universe-wide usage rights" is a red flag you know and no general API reliably flags. You add it as JSON in ~/.redpen/rules/ — no code, no approval:

[{
  "id": "all-media-perpetual-usage",
  "title": "Usage rights are unlimited",
  "category": "ip", "severity": 3,
  "why": "A perpetual all-media licence is a different price than a 12-month single-platform run.",
  "fix": "Usage is limited to one platform for 12 months; further usage is priced per the rate card.",
  "ask": "Which platforms, and for how long? That changes the fee.",
  "any_of": ["all media", "any media now known or hereafter devised", "perpetual licen"],
  "all_of": [["usage", "licen", "rights"]]
}]

With a closed model you cannot see the standard being applied, and you cannot change it. Here a lawyer could audit all 65 rules in an afternoon, and a community can maintain its own fork for its own trade.

4. Swapping models is a config line, so nobody's pricing page is my cost base. Verified: the same contract under Gemma 3 1B and Qwen 2.5 1.5B produced identical findings — same rules, same pages, same evidence — only the brief and the email changed. That's the payoff of keeping judgement out of the model: choosing weights becomes a wording preference, not a correctness risk.

Where open beat closed, specifically: a hosted API would have been better at prose and worse at the product. It cannot promise the document never left the machine, cannot let a user encode their own trade's traps, makes per-review cost non-zero, and its judgement is unauditable. The thing it was better at — writing — is the half I deliberately gave away.

Results, including the ones that hurt

Document	Type detected	Findings	Score
Hostile agency MSA (synthetic)	services	36	99
Typical design gig (synthetic)	services	12	83
Fair contractor deal (synthetic)	services	0	0
Internship offer letter (synthetic)	employment	20	97
One-way NDA (synthetic)	nda	11	77
Real offer letter (Skolar)	employment	12	90
Real internship letter (Pentonix)	employment	8	77
Real offer letter (Eubrics)	employment	12	85
Real NDA (Eubrics)	nda	11	77
Real onboarding checklist	not an agreement	0	refused
Real freelance template	services	3	18

Five synthetic fixtures, six real documents. The fair contract scoring zero and the
checklist being refused are the two rows I would defend hardest: an instruction list
makes no promises, and scoring it would have manufactured findings out of prose.

What two comments on this post changed

I published before this was as tested as it should have been, and two comments
in the first day were more useful than anything I had written myself.

@arhancanli pointed out that my six real documents had quietly become my
training set — every fix was written to make a document I had already opened come
out right — and suggested minimal pairs: the same clause asserted and refused, to
see which rules actually survive negation. That test is now
tests/test_negation_pairs.py, 30 pairs, and it found five over-flag bugs the
first time it ran. The best one: the negation look-back window was 52
characters, so in "Nothing in this Agreement shall make the Contractor's
liability unlimited" it scanned "othing", found no negator, and flagged a clause
that refuses the very thing it is being accused of. Fixing it properly meant
abandoning character windows altogether and cutting at clause boundaries —
punctuation and conjunctions — because "Nothing shall limit liability, which is
unlimited" contains a negator that governs the wrong verb.

They also noted that lsof sampling can miss a connection that opens and closes
between samples, which is true, and that my fair-contract result was one data
point. Both are now addressed: tests/test_offline_enforcement.py intercepts
socket.connect for the duration of a whole review and raises on any non-loopback
target, so the property is enforced rather than observed, and
tests/test_precision_variants.py holds eight fair drafts across five
jurisdictions, seven of them paired with a near-miss where one hostile clause is appended.

That second file immediately found four more gaps, all in the absence detectors:
a liability cap written as "is limited to the fees paid" was not recognised as a
cap, a deposit "payable on signature" was not recognised as a deposit, a
translation memory retained by the translator was not recognised as a tooling
carve-out, and a normal five-day week was being flagged as employee-style
control. Writing more good contracts turned out to be a better test than writing
more bad ones.

@phaz described the same failure in their own cold-email checker — a
small model inventing an opt-out that was not there — which is exactly why every
quote in RedPen must appear verbatim in the source document, asserted by a test
that walks every finding and checks the string exists in the text. Their question,
"do you run the rules against fair contracts to count false alarms, or mostly
against hostile ones?", had an uncomfortable answer when I wrote it down: mostly
hostile, and one fair file. It now has eight, plus a control case proving a clean
result is not just the rules being asleep.

One thing I did not do: quietly delete the cases the new tests could not pass.
Four limitations are now encoded as tests that fail if someone fixes them
without updating the list — statutory carve-outs read as unlimited liability,
legally mandated insurance, a negator two promises earlier in the same
comma-joined sentence, and the "nothing shall limit liability, which is
unlimited" construction above. A limitation you can see is worth more than one I
have quietly tuned away.

Limits, honestly. 8 GB RAM is the floor — 1–3B at Q4 fit, 7B doesn't. Scanned PDFs aren't supported: no selectable text, and RedPen won't send your pages to an OCR service, so it says so rather than returning an empty review. The model layer is a 1B model and its explanations are sometimes generic, which is why the library's own wording sits underneath it. A clean report is weak evidence — no rule matched is not a guarantee of fairness, and the UI says that out loud instead of letting a green gauge imply safety. And the library is written from a freelancer's and an intern's point of view: it flags commercial risk patterns, not legal validity, across jurisdictions it does not claim to know.

RedPen is a pattern-matching tool with an open rule library, not a lawyer.

My Agent Session

Built agent-assisted — the agent did the typing, I owned the claims. The work log is committed at docs/agent-session.md: every milestone mapped to a commit, and every mistake listed with the test that caught it.

Two things that log is honest about which a summary wouldn't be. The first architecture sketch assumed a hosted web version, and the cost and privacy math above is what killed it. And most of the bugs in the failure table were introduced by the agent during this session and caught by tests written in the same session — including a validation script that passed by observing nothing.

My First User

Shreshtha Das, a freelance developer who tests tools like this, ran RedPen on a real agreement. His feedback, verbatim:

As a freelance tester, I tested RedPen and found it to be a genuinely useful tool for freelancers who want to understand their contracts before signing them. I tried reviewing an agreement and was impressed by how clearly it highlighted potentially risky clauses, quoted the exact wording that needed attention, and suggested more freelancer-friendly alternatives. The negotiation email draft was another helpful feature, as it made it easier to communicate concerns professionally without spending hours figuring out what to say. I especially liked that RedPen works entirely offline, which is a major advantage when dealing with confidential client agreements and NDAs. Overall, RedPen makes contract review more accessible, saves valuable time, and gives freelancers more confidence when negotiating terms with clients. It's a practical tool that I can see myself recommending to other developers, designers, and independent professionals.

I'd rather keep two things in view than round them off. He reviewed one agreement, so this is a single data point, not validation — and the one thing I most wanted from him, a false positive, is the thing he didn't report. Precision is the claim this tool can least afford to get wrong, and it's the reason the fair-contract test exists.

What he did confirm is the part enforced in code rather than promised in a README: that the offline behaviour holds, and that it matters most exactly where he says it would — client agreements and NDAs.

Did he pay? Yes — ₹89, which is more than ₹0 and less than the $19 I'm asking. The honest read is that a friend paid something to be supportive, not that a stranger paid a price. The next test is someone with no reason to be kind.

A second voice — from someone who read the project, not someone who used it. The founding team of Actizant, which builds what they call intelligent operating systems for rural India, wrote this after reviewing the repo:

"Privacy should be a fundamental design principle, not an afterthought, especially when dealing with confidential client agreements, statements of work, and NDAs."

They also handed me a roadmap in three lines, which is more useful than praise: customisable risk rules per profession, jurisdiction-aware guidance, and transparent statements of what automated analysis cannot do. The first two are exactly what an open rule library is built for — a profession-specific rule set is a JSON file, and a jurisdiction profile is a second rule set with different safe-harbours. The third is why the UI says "no rule matched is not a guarantee of fairness" instead of showing a green tick.

Prize Categories

Best Use of Gemma. Gemma 3 1B (instruct) is the default and only shipped model — ggml-org/gemma-3-1b-it-GGUF, Q4_K_M, downloaded on first run and served by llama.cpp on loopback. It writes the brief, the per-finding explanations, the negotiation email and the ambiguity pass. It is the model small enough to fit in 8 GB of RAM and cost nothing per review, which is the precondition for the privacy promise being true rather than a policy.

MIT licensed. Model weights stay under their own licences — RedPen ships none, it downloads them for you.

🌱 I Built an AI That Wants You to Stop Using It — Meet TerraLens

Soumwadeep Guha — Tue, 06 Oct 2026 15:28:48 +0000

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

🌱 I Built an AI That Wants You to Stop Using It — Meet TerraLens

We are putting increasingly powerful AI into our pockets.

And then spending increasingly more time staring at those pockets.

Every app seems to want the same thing:

one more click, one more message, one more minute of attention.

So while thinking about the "Touch Grass" theme, I started with a slightly ridiculous question:

What if the best possible outcome for an AI app was that you stopped using it?

Not because it failed.

Because it succeeded.

That question became TerraLens.

TerraLens — AI that sends you outside.

TerraLens is an offline-first, open-weight AI field companion designed to help you notice more of the physical world while spending less time looking at a screen.

It gives you small real-world missions.

You put your phone away.

You walk.

You look.

You listen.

You discover something.

Then, and only then, you come back.

## What I Built

TerraLens turns an ordinary walk into an AI-guided expedition.

But I deliberately didn't build another chatbot.

There is no giant:

"What would you like to ask?"

box at the centre of the experience.

Instead, TerraLens asks:

Ready to go outside?

You choose an expedition style and duration.

For example:

🌿 Nature
📷 Photographer
🧭 Explorer
🎲 Surprise Me
😌 Chill

Then TerraLens gives you one real-world mission at a time.

Something like:

Find two leaves with visibly different edges.

Don't photograph the first thing you see.

Look around.

Compare.

Come back when you've found them.

And then you press:

GO FIND IT

That's when something unusual happens.

The application basically tells you to stop using the application.

📱 → 🌳 The TerraLens Loop

The whole product revolves around one simple loop:

Get a mission
      ↓
Put the phone away
      ↓
Explore the real world
      ↓
Notice something
      ↓
Capture an observation
      ↓
AI understands the context
      ↓
Get another physical-world action
      ↓
Put the phone away again

That last part matters.

The goal isn't:

AI → answer → another question → answer → another question

It's:

AI → action → world → discovery

🌱 Touch Grass Mode

I built a dedicated Touch Grass / Pocket Mode.

When you begin a mission, TerraLens intentionally removes most of the interface.

You might see:

YOUR MISSION

Find two leaves with
visibly different edges.

04:58 remaining


PUT YOUR PHONE AWAY 🌱

That's basically it.

No infinite feed.

No notifications asking you to come back.

No AI typing animation trying to hold your attention.

The mission is outside.

TerraLens will still be there when you return.

📷 🎙️ ✍️ Bring Back What You Discover

When you find something interesting, TerraLens lets you capture an observation as:

📷 A photo

See an interesting plant, leaf, flower, texture or object?

Capture it.

🎙️ A sound

Hear a bird call or an interesting environmental sound?

Record it.

✍️ A field note

Notice something that doesn't need a camera?

Write it down.

Those observations become part of your local nature journal and can be used by the Curiosity Engine to determine what you should investigate next.

🧠 The Curiosity Engine

This became one of my favourite parts of the project.

Most AI systems are optimized to answer.

TerraLens is optimized to create curiosity.

Suppose I photograph a flower.

A traditional assistant might respond with several paragraphs:

This appears to be Hibiscus rosa-sinensis. It belongs to the family Malvaceae...

Useful?

Absolutely.

But I'm still staring at my phone.

TerraLens should instead say something closer to:

Possible match: Hibiscus

Before I tell you more, look at the newest leaves near the end of the branch.

Are they the same colour as the older leaves?

Go check. I'll wait.

The difference is small technically but enormous conceptually.

One response makes me read.

The other makes me look.

And TerraLens keeps trying to turn information into physical actions:

LOOK

LISTEN

WALK

COMPARE

NOTICE

WAIT

SEARCH

REFLECT

The AI isn't supposed to become the experience.

It's supposed to trigger the experience.

🏆 Grass Score — Rewarding the Opposite of Screen Time

Then I ran into another interesting problem.

How should TerraLens measure success?

Normal software metrics didn't make sense.

Time in app?

Bad.

More sessions?

Not necessarily.

More clicks?

Definitely not.

So I created:

🌱 GRASS SCORE

A score from 0 to 1000 based on exploration behaviour.

For example:

GRASS SCORE

847 / 1000

🌱 EXPLORER


Outdoor time          42 min
Screen interaction     4 min
Distance               2.3 km
Observations               11
New discoveries             7
Missions completed          3

Screen Avoidance Bonus   +120

The important part:

Grass Score is NOT generated by an LLM.

It is deterministic.

Actual expedition events feed a scoring algorithm.

That means TerraLens can't simply ask AI:

"Give this person a score."

and magically produce 847.

The score has a visible breakdown and can be explained.

📊 Nature / Screen Ratio

I also wanted one metric that captured the entire philosophy of TerraLens.

So I added:

Nature / Screen Ratio

Suppose you explored for:

42 minutes

but interacted with TerraLens for only:

4 minutes

Your ratio is roughly:

10.5×

And in TerraLens:

higher is better.

Think about how strange that is for software.

The product is celebrating the fact that you barely used it.

That's exactly the point.

📴 What Happens When the Internet Disappears?

This was one of the biggest reasons I wanted an open and offline-first architecture.

Imagine this:

You're walking along a trail.

You finally find something interesting.

You open your "AI nature assistant."

And it says:

Network error.

That felt completely backwards.

Nature doesn't come with guaranteed Wi-Fi.

So TerraLens treats offline operation as a normal state rather than a failure state.

The app can be installed as a Progressive Web App.

The core expedition experience uses local browser storage.

Missions, observations, scores and the journal can continue locally.

When connectivity disappears, the philosophy is:

You're offline. Good. Keep exploring.

And when connectivity returns, queued work can synchronize again.

🤖 Why I Chose Gemma

The main prize category I'm entering TerraLens for is:

🏆 Best Use of Gemma

Gemma isn't here because I needed an AI logo on the architecture diagram.

It fits the fundamental problem.

TerraLens needs an intelligence layer that can be:

open-weight
replaceable
adaptable
deployable in different environments
moved closer to the user
eventually optimized for local inference

The Curiosity Engine therefore has an AI adapter instead of hard-wiring the entire product into one closed provider.

Conceptually:

Observation
     ↓
AI Adapter
     ↓
Gemma
     ↓
Structured understanding
     ↓
Curiosity Engine
     ↓
Physical-world action

Gemma helps turn an observation into context that TerraLens can use to produce the next outdoor action.

And because the model layer is abstracted, TerraLens isn't permanently tied to one inference environment.

Gemma can be served through compatible runtimes while the rest of the application continues speaking the same structured language.

🧠 AI That Is Allowed To Say "I Don't Know"

There was another rule I cared about:

Never fake intelligence.

If the model doesn't answer, TerraLens doesn't invent an answer.

If an integration isn't configured, TerraLens doesn't display a fake green checkmark.

If an evaluation hasn't run, it doesn't invent benchmark numbers.

If there isn't enough data for a prediction, it doesn't ask an LLM to manufacture a percentage.

This sounds obvious.

But it becomes incredibly important in AI demos.

TerraLens uses explicit integration states such as:

READY

DEGRADED

NOT RUN YET

UNVERIFIED

NOT CONFIGURED

UNREACHABLE

One of my rules while building the project became:

Configured ≠ working.

A key existing in an environment variable isn't proof that an integration works.

🔬 Fine-Tuning Curiosity with Tinker

Another category TerraLens explores deeply is:

🧪 Best Use of Tinker

There's an interesting AI problem hidden inside TerraLens.

Generic assistants are trained to be helpful by answering.

But TerraLens sometimes needs to be helpful by not answering yet.

Consider:

Generic response

This appears to be a mango tree. Mango trees belong to the family Anacardiaceae...

versus:

TerraLens response

Looks like a mango tree.

Find the newest leaves near the end of a branch.

Are they the same colour as the older ones?

Go look before reading anything else.

That behaviour can be adapted.

So TerraLens includes a dedicated Curiosity Adapter fine-tuning/evaluation workflow.

The training examples map:

Observation
+
Context
+
Generic response

        ↓

Desired outdoor response

The evaluation isn't simply:

"Does the model sound good?"

It looks at things like:

Outdoor Action Rate
Screen Dependency Rate
response length
safety compliance
mission relevance
action diversity

The question becomes:

Can we measurably make an AI better at getting humans away from the AI?

I love the contradiction in that experiment.

🎙️ ElevenLabs — Because Voice Means Less Screen

Another natural fit was ElevenLabs.

If TerraLens wants you to stop looking at your screen, making you read every mission isn't ideal either.

So Pocket Mode supports voice narration.

Imagine walking with your phone in your pocket and hearing:

You've been exploring for eight minutes.

Stop here.

Listen carefully for ten seconds.

Can you hear two different natural sounds?

You don't need to unlock the phone.

You don't need to scroll.

You don't even need to look down.

Voice isn't being added because voice AI is cool.

It's being added because audio reduces the amount of visual attention TerraLens needs from you.

If the external voice service isn't available, TerraLens can fall back to browser speech capabilities.

🧭 Mastra — The Field Agent

Individual observations aren't very interesting if the system forgets everything five seconds later.

TerraLens therefore includes a higher-level Field Agent architecture using Mastra.

Its responsibilities are separated conceptually into areas such as:

                FIELD AGENT
                     │
       ┌─────────────┼─────────────┐
       │             │             │
       ▼             ▼             ▼
 Observation      Mission        Safety
    logic          logic          logic
       │             │             │
       └─────────────┼─────────────┘
                     │
                     ▼
                Curiosity
                     │
                     ▼
                  Summary

This means an expedition can eventually be understood as a journey rather than a collection of unrelated AI calls.

⏳ Temporal — Because Outdoor Networks Fail

Imagine:

Start expedition
       ↓
Complete mission
       ↓
Record observation
       ↓
NETWORK DISAPPEARS
       ↓
Walk for 20 minutes
       ↓
Create more observations locally
       ↓
NETWORK RETURNS
       ↓
Synchronize
       ↓
Continue workflow
       ↓
Generate expedition recap

That's a very different environment from a normal web request.

So TerraLens uses a durable workflow architecture with Temporal for cloud-side work that should survive failures and process restarts.

The important idea is:

losing connectivity should pause cloud work, not destroy the expedition.

🔮 TabPFN — Predicting When Exploration Might Be Interesting

I also wanted TerraLens to eventually learn from structured outdoor observations.

That's where TabPFN fits.

Instead of asking an LLM:

"What are the chances I'll see birds this evening?"

and accepting whatever percentage it invents, structured information can be used.

For example:

Time
Temperature
Humidity
Season
Recent observations
Environment
Previous activity

↓

EXPLORATION FORECAST

Bird activity
HIGH

Insect activity
MEDIUM

Flower observations
HIGH

And if there isn't enough information?

TerraLens should simply say:

Not enough data yet.

"No prediction" is better than a fake prediction.

🗃️ MongoDB Atlas — Cloud Memory Without Making Cloud Mandatory

TerraLens stores the core expedition experience locally first.

That's deliberate.

But synchronized journals and cross-device history are useful too.

MongoDB Atlas provides the optional server-side observation layer.

The distinction matters:

DEVICE

Your current expedition
Your observations
Your score
Your journal

        ↓ optional sync

CLOUD

Backup / synchronized journal
Cross-device information
Agent context

Cloud storage enhances the experience.

It doesn't own the experience.

🐯 Tiger Data + pgvector — Nature Knowledge

Personal observations and nature knowledge aren't the same thing.

So TerraLens keeps those concerns separate.

Tiger Data / PostgreSQL + pgvector provides a retrieval layer for nature knowledge.

Conceptually:

Question / observation
        ↓
Embedding
        ↓
Vector similarity
        ↓
Relevant field-guide knowledge
        ↓
Gemma
        ↓
Grounded response

If vector retrieval isn't available, the architecture can fall back toward PostgreSQL text retrieval and ultimately bundled local knowledge.

Again:

degrade gracefully instead of simply breaking.

🧠 Backboard — Remembering the Explorer

Imagine TerraLens remembers:

Last weekend you spent most of your expedition photographing flowers.

Then next time it can say:

Last time you focused on colour.

Today let's ignore flowers for ten minutes.

Listen instead.

That's where long-term agent memory becomes interesting.

Backboard provides the integration path for richer long-term memory, while local memory remains available when the external service isn't configured.

🔎 SerpApi — Online Context, Not Online Dependency

Sometimes fresh web information is useful.

So TerraLens can optionally enrich observations using SerpApi.

But there's an important distinction in the UI:

LOCAL / MODEL RESULT

Possible identification:
...

ONLINE CONTEXT

Additional current information:
...

SerpApi isn't the identification engine.

It doesn't secretly turn TerraLens back into a cloud-only search wrapper.

The Internet enhances TerraLens.

The Internet doesn't enable TerraLens.

🔭 Sentry — Seeing What the AI Actually Did

AI systems become difficult to debug when all you know is:

"It felt slow."

So TerraLens includes observability designed around actual stages.

For example:

FIELD AGENT TRACE

Mission generation       320 ms
Gemma inference          1.8 sec
Safety check             120 ms
Mission update           190 ms
Voice generation         620 ms

Sentry provides the tracing/error path.

But TerraLens deliberately avoids sending things such as:

photographs
private field notes
precise coordinates

into telemetry by default.

Debugging shouldn't quietly become surveillance.

🔐 Privacy Isn't a Settings Checkbox

TerraLens supports three conceptual privacy modes:

LOCAL ONLY

Keep the experience on the device wherever possible.

HYBRID

Local-first processing with selected synchronization.

CLOUD ENHANCED

Allow configured online capabilities.

Precise location isn't required to go exploring.

Photos are processed with privacy in mind.

External credentials remain server-side.

And cloud media processing isn't silently enabled just because an API key exists.

For a field companion, this matters.

A personal nature journal should feel personal.

🛡️ Safety

There is another problem with letting AI create outdoor missions:

AI can occasionally suggest stupid things.

😅

So generated activities have safety constraints.

TerraLens should never intentionally ask someone to:

eat an unknown plant
eat an unknown mushroom
handle wildlife
approach dangerous animals
trespass
climb unsafe structures
enter dangerous water
cross unsafe roads
rely on AI identification for medical or food-safety decisions

The principle is simple:

Observe. Don't disturb.

Curiosity should make exploration better, not reckless.

🧪 Judge Mode & AI Lab

I also realized something while building this:

A hackathon judge might have only a few minutes.

Making them discover the architecture manually would be terrible UX.

So TerraLens includes a dedicated:

Judge Mode

It provides a short technical tour covering:

the idea
expeditions
offline behaviour
Gemma
Grass Score
Curiosity
architecture
integration status
privacy
open innovation

There's also an AI Lab for inspecting things like:

model state
evaluation
offline capabilities
observability
architecture

I wanted the technical work to be visible instead of hiding everything behind the landing page.

🏗️ How I Built It

The application is built as a mobile-first Next.js + TypeScript Progressive Web App.

At a simplified level:

                        TERRALENS
                            │
                   ┌────────▼────────┐
                   │   EXPEDITION    │
                   └────────┬────────┘
                            │
             ┌──────────────┼──────────────┐
             ▼              ▼              ▼
          MISSIONS      OBSERVATIONS     JOURNAL
             │              │
             └──────┬───────┘
                    ▼
             CURIOSITY ENGINE
                    │
            ┌───────┴───────┐
            ▼               ▼
       LOCAL RULES         GEMMA
            │               │
            └───────┬───────┘
                    ▼
              PHYSICAL ACTION
                    │
                    ▼
                POCKET MODE
                    │
                    ▼
               GRASS SCORE

When online, additional infrastructure can participate:

                    DEVICE
                       │
                       ▼
                  SYNC QUEUE
                       │
                       ▼
                   TEMPORAL
                       │
                       ▼
                MASTRA FIELD AGENT
                       │
        ┌──────────────┼───────────────┐
        ▼              ▼               ▼
     MONGODB        TIGER DATA       TABPFN
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
        BACKBOARD   SERPAPI   ELEVENLABS

And throughout the system:

SENTRY → observability

TINKER → model adaptation/evaluation

GEMMA → open-weight intelligence

The important thing is that the bottom diagram can disappear temporarily...

and the user can still go outside.

## Why Does Open Innovation Matter?

This is the question at the heart of the challenge.

For TerraLens, open innovation matters because of where the application is supposed to work.

Not inside a perfect office network.

Outside.

On a trail.

In a park.

In a garden.

On a village road.

Somewhere your connection may disappear completely.

A cloud-only AI architecture is incredibly powerful until the cloud becomes unreachable.

Open-weight AI gives us another direction.

We can move intelligence closer to the user.

We can change the runtime.

We can swap models.

We can inspect the behaviour.

We can fine-tune the model toward a strange objective like:

Stop answering so much and make the human investigate.

And we can design toward a future where more of that intelligence runs directly on the device.

There is also a privacy benefit.

A photograph doesn't automatically have to become an upload.

A field journal doesn't have to begin life on somebody else's server.

A user's exact location doesn't have to be the admission price for exploring nature.

And if an API disappears?

The entire idea doesn't have to disappear with it.

That's why open AI isn't decoration in TerraLens.

The environment TerraLens is designed for is exactly where open and local AI becomes most interesting.

## Demo

🌱 Live application

https://terralens.soumwadeepguha.com/

For the best experience, open TerraLens on a phone.

Try this:

Start an expedition.
Choose a mission.
Enter Touch Grass Mode.
Put the phone away.
Actually complete the mission.
Come back.
Capture an observation.
Continue exploring.
Finish the expedition.
Look at your Grass Score.
Check your Nature / Screen Ratio.
Browse the journal.

And yes:

actually take it outside.

That's where TerraLens makes sense.

## Code

TerraLens is open source.

💻 Source code

https://github.com/soumwadeep/TerraLens

The repository includes:

the Next.js application
PWA/offline infrastructure
IndexedDB persistence
expedition and mission engines
deterministic Grass Score engine
Curiosity Engine
Gemma adapter
Tinker workspace
Mastra Field Agent
Temporal worker
TabPFN prediction service
MongoDB integration
Tiger Data retrieval layer
ElevenLabs voice integration
Backboard memory
SerpApi enrichment
Sentry observability
unit/integration tests
Playwright E2E tests
CI configuration
deployment configuration

Everything is available under the project's open-source license.

## My Agent Session

AI-assisted development played an important role in building TerraLens. I used Qoder as my coding agent throughout development—not just to generate code, but to help iterate on the architecture, investigate implementation problems, review different approaches, and turn the original idea into a working product.

The development process covered everything from the offline-first PWA architecture and IndexedDB persistence to the Curiosity Engine, Gemma integration, Touch Grass Mode, Grass Score, safety rules, synchronization, agent workflows, sponsor integrations, testing, and deployment.

Rather than starting with a finished specification and asking an agent to generate a landing page, TerraLens evolved through repeated cycles of idea → implementation → testing → review → improvement.

## Prize Categories

Rather than listing technologies just because they're sponsors, these are the categories that correspond to meaningful parts of TerraLens.

🏆 Best Use of Gemma — Primary Category

This is the category TerraLens is most strongly built around.

Gemma provides the open-weight intelligence path behind observation understanding and the Curiosity Engine.

More importantly, Gemma represents the architectural idea behind TerraLens:

AI that can move closer to the user instead of forcing the user closer to the cloud.

🏆 Best Use of Tinker

Tinker is used for the Curiosity Adapter experiment: adapting model behaviour away from long generic answers and toward safe, useful physical-world actions.

The interesting evaluation question is:

Can fine-tuning make an AI measurably better at getting someone to stop interacting with the AI?

🏆 Best Use of TabPFN

TabPFN powers the structured prediction path for exploration forecasting.

Rather than asking an LLM to invent probabilities, TerraLens can use structured historical/environmental information to make actual predictions.

🏆 Best Use of ElevenLabs

ElevenLabs gives Pocket Mode a voice.

This isn't just narration for decoration.

Voice directly supports TerraLens's goal of reducing visual screen interaction during an expedition.

🏆 Best Use of Mastra

Mastra powers the Field Agent architecture that reasons across an expedition rather than treating each observation as an unrelated interaction.

🏆 Best Use of MongoDB Atlas

MongoDB Atlas provides optional synchronized journal and observation storage while the browser remains capable of supporting the core offline experience.

🏆 Best Use of Temporal

Temporal makes the online workflow durable so cloud processing can survive unreliable connectivity and continue when an expedition reconnects.

🏆 Best Use of Tiger Data

Tiger Data/Postgres + pgvector powers the extended nature-knowledge retrieval layer.

🏆 Best Use of Backboard

Backboard provides long-term Field Agent memory so future expeditions can learn from previous exploration behaviour.

🏆 Best Use of SerpApi

SerpApi adds optional fresh online context while remaining deliberately separate from TerraLens's core identification/intelligence path.

🏆 Best Use of Sentry Agent Tracing

Sentry provides observability into AI and workflow execution while TerraLens's telemetry rules keep private observation content out of tracing.

🏆 Best Use of GitHub Copilot

GitHub and AI-assisted development supported the engineering workflow, while CI validates formatting, types, linting, tests and production builds.

🌱 What I Learned

The biggest thing I learned while building TerraLens wasn't about model size.

It wasn't about vector databases.

It wasn't about agents.

It wasn't even about offline AI.

It was this:

Sometimes the most helpful thing an AI can do is stop talking.

If I ask about a leaf, maybe I don't need six paragraphs.

Maybe I need:

Turn it over.

If I hear a bird:

Close your eyes.

If I find a flower:

Find another one that looks completely different.

If I've been walking while staring at my phone:

Put it away.

AI is becoming extremely good at generating more things for us to consume.

More text.

More images.

One Last Thing

The funniest possible success metric for TerraLens would be this:

Someone opens the application.

Gets a mission.

Locks their phone.

Walks away.

And completely forgets TerraLens exists for the next thirty minutes.

For most apps, that would be terrible engagement.

For TerraLens?

That's a perfect session. 🌱

Ask once.

Look closer.

Listen longer.

Walk farther.

Put your phone away.

Go touch grass.

🌱 Try TerraLens:

https://terralens.soumwadeepguha.com/

💻 Source Code:

https://github.com/soumwadeep/TerraLens

TerraLens

AI that sends you outside.

I Built PingMe — An AI That Turns Your Messy Thoughts Into Tasks

Soumwadeep Guha — Sun, 04 Oct 2026 05:02:34 +0000

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

Meet PingMe 👋

Say it. Forget it. We'll remember.

Have you ever told yourself:

"I need to call Mom tomorrow morning."

Or:

"I have to send that presentation tonight, pay the electricity bill by Thursday, and prepare for my interview on Monday."

And then... completely forgotten about it?

I have. My friends have too.

The funny thing is, we already have calendars, reminder apps, note-taking apps, and to-do lists.

So why do we still forget things?

That question became the starting point for PingMe.

What I Built

I didn't want to build another to-do app.

There are already hundreds of them.

The problem I noticed was much simpler:

Our thoughts don't arrive as perfectly organized to-do lists.

They arrive like this:

"Tomorrow remind me at 10 to send my resume, I need to buy medicine in the evening, and my interview is Monday at 2."

A normal task app expects you to separate all of that yourself.

You create one task.

Choose its date.

Choose its time.

Save it.

Create another task.

Choose another date.

Save it.

Then create an event.

Then maybe create a reminder.

That's a surprising amount of work just to make sure you don't forget something.

So I built PingMe, an AI-powered memory companion where you can simply write what's on your mind.

PingMe figures out the rest.

🧠 Brain Dump

The main feature of PingMe is something I call Brain Dump.

Instead of filling out forms, you just type naturally.

For example:

"Tomorrow remind me at 10 to send my resume, buy medicine in the evening, and my interview is Monday at 2."

Then press:

✨ Sort My Brain

PingMe reads the whole thought and turns it into something useful:

Tomorrow — 10:00 AM

📋 Send resume

Tomorrow — Evening

📋 Buy medicine

Monday — 2:00 PM

📅 Interview

You don't need to tell PingMe which part is a task, which part is an event, or manually separate everything.

The AI handles that.

Why I Built It for a Friend

The theme of this challenge is Build for a Friend, and that shaped the entire idea behind PingMe.

I thought about how people actually remind each other about things.

A friend doesn't normally say:

"Please create a medium-priority task with a due date of October 5 at 10:00 AM."

They say:

"Bro, remind me tomorrow morning to send that email."

😄

And somehow we understand exactly what they mean.

That's the experience I wanted PingMe to have.

I wanted it to feel less like filling out a productivity form and more like telling a dependable friend:

"Hey, don't let me forget this."

That's also where the name came from.

Ping me when I need to remember.

It's Not Just About Creating Tasks

Once PingMe understands something, you remain in control.

You can:

✏️ Edit a task
🗑️ Delete something you don't need
✅ Mark tasks as completed
📅 See what's coming up
🧠 Add more thoughts using Brain Dump
🎙️ Listen to a spoken summary of your day

I intentionally kept the experience simple.

I didn't want PingMe to become project-management software.

No complicated workspaces.

No teams.

No boards with 20 different columns.

No account setup just to remember that you need to buy medicine tomorrow.

The goal is:

Capture the thought → understand it → remember it.

🔊 "Tell Me My Day"

This became one of my favorite parts of the project.

Sometimes you don't want to look through another screen in the morning.

So PingMe can tell you about your day.

Press Tell Me My Day, and PingMe creates a simple summary of what you have coming up.

For example:

"You have three things today. Remember to send your resume at 10 AM, buy medicine this evening, and prepare for your upcoming interview."

For the voice, I integrated ElevenLabs.

That turns PingMe from something you constantly have to check into something that can actually speak to you like an assistant.

This integration isn't there just to add another technology to the project.

It fits the original idea:

What would a helpful friend do?

They wouldn't hand you a JSON file. 😅

They'd probably say:

"Hey, you've got these things today. Don't forget."

That's what I wanted PingMe to feel like.

Demo

The complete application is deployed and working here:

👉 https://pingme.soumwadeepguha.com/

Try giving it something messy rather than writing a perfectly formatted task.

For example:

"I need to call Mom tomorrow morning, send the presentation tonight and pay the electricity bill before Thursday."

Then press:

✨ Sort My Brain

That's the best way to experience what PingMe is supposed to do.

Code

The project is open source and the source code is available on GitHub:

👉 https://github.com/soumwadeep/PingMe

The repository also contains information about the architecture, setup, AI integration, and how to run PingMe locally.

How I Built It

I wanted the technical side of PingMe to support one very simple experience:

Your messy thought
        ↓
     PingMe
        ↓
 Open-source AI
        ↓
Understand meaning
        ↓
Tasks / Events / Reminders
        ↓
     My Day
        ↓
  Don't forget! 🔔

Underneath that simple experience, several things are happening.

🧠 Gemma — The Brain Behind PingMe

The most important part of PingMe is understanding what the user actually means.

That's where Gemma comes in.

Gemma is used as the open-weight AI at the core of PingMe's understanding layer.

Imagine somebody writes:

"Need to send Shreshtha the deck tonight and remind me tomorrow morning to call Mom."

A computer normally just sees a sentence.

PingMe needs to understand that there are actually two separate commitments hiding inside it.

One is:

Send Rohan the deck — tonight

The other is:

Call Mom — tomorrow morning

PingMe sends the natural-language thought through its AI extraction layer.

The model identifies useful information such as:

What needs to be done
Whether something is a task or event
When it needs to happen
Whether a time was mentioned
How the sentence should be separated into individual commitments

The result is then converted into structured information that the rest of PingMe can understand.

One important thing I added here was validation.

AI output isn't blindly trusted.

The response is checked before PingMe turns it into something that appears in your day.

The user also gets the ability to edit or delete commitments afterward.

AI organizes. The human stays in control.

🗓️ Understanding Human Time

One surprisingly interesting challenge was time.

Humans rarely speak in database-friendly dates.

We don't normally say:

"Create this for 2026-10-05T10:00:00."

We say:

"Tomorrow morning."

"Tonight."

"Next Monday."

"Before Thursday."

For PingMe to feel natural, it has to understand those phrases in the context of today.

That means the AI receives the relevant date and time context so it can interpret relative phrases correctly instead of guessing blindly.

It's a small detail, but it makes a huge difference to the experience.

💾 Local-First by Design

Something else mattered to me while building PingMe:

These are personal thoughts.

A person's reminders can reveal a surprising amount about their life.

Appointments.

Family commitments.

Interviews.

Bills.

Work.

Travel.

Medication reminders.

Personal plans.

So I designed PingMe with a local-first approach for the user's stored commitments.

The application keeps the user's task data in browser storage rather than requiring an account and sending every saved task to a central database.

The AI still needs the Brain Dump text when you explicitly ask it to understand and organize that text, but the application doesn't need a giant cloud database containing everyone's personal task history just to function.

That separation was intentional.

☁️ Render — Where PingMe Lives

I deployed the application using Render.

Render gives PingMe its production environment and allows the application and its server-side functionality to be available as a real product instead of remaining a localhost hackathon demo.

The live version is available at:

https://pingme.soumwadeepguha.com/

Having the server side deployed is particularly important because sensitive service credentials shouldn't be placed directly inside frontend code.

PingMe can keep those integrations behind its server-side endpoints while the user gets a simple web interface.

🎙️ ElevenLabs — Giving PingMe a Voice

I used ElevenLabs for the voice experience behind Tell Me My Day.

PingMe first understands the user's commitments and builds a natural daily briefing.

ElevenLabs then turns that briefing into speech.

This creates a completely different way of interacting with the product.

Instead of:

Open app → scan tasks → understand schedule

you can simply ask PingMe to tell you about your day.

That was one of those features where, after getting it working, PingMe started feeling much more like a companion than a task manager.

The Tech Behind It

For anyone interested in the technical side, PingMe is built with a modern web stack including:

Next.js
React
TypeScript
Material UI
Gemma
IndexedDB / browser-side persistence
ElevenLabs
Render

But I deliberately tried to hide most of that complexity from the person using PingMe.

A non-technical user shouldn't need to know what model inference, structured output, IndexedDB, or an API route is.

They should only need to know:

Write what you're thinking. PingMe will organize it.

If the technology disappears into the experience, I think it's doing its job.

Why Does Open Innovation Matter?

This part of the challenge was especially interesting to me.

There are plenty of closed AI APIs that can understand a sentence.

So why care about open models?

Because I don't think AI should only exist as a black box that developers rent one request at a time.

Open-weight models such as Gemma give developers much more freedom to understand, experiment with, customize, optimize, and eventually run intelligence in environments that make sense for their users.

That matters particularly for a product like PingMe.

The information we give a memory assistant can be personal.

Today PingMe uses an AI inference layer to understand Brain Dumps, but an open-model architecture gives this idea somewhere much more interesting to go in the future:

Fully local AI.

Imagine downloading PingMe and having the intelligence itself running on your own device.

No account.

No sending your personal thoughts to an external AI service.

No internet connection required for understanding them.

Just:

You → your device → your AI.

Open innovation makes that direction possible.

And that's much more exciting to me than simply replacing one API endpoint with another.

What Was Harder Than I Expected?

At first, PingMe sounded simple.

"Take a sentence and turn it into tasks."

Then I started thinking about sentences like:

"My interview is Monday at 2, remind me Sunday evening to prepare and I also need to send my resume tomorrow."

Now we're dealing with:

an event
a preparation reminder
another task
three different times
relative dates
implied relationships between them

And humans can still understand that sentence almost instantly.

Teaching software to transform that messy human thought into clean, useful information—without making the user learn a special command format—was the interesting part of this project.

Another challenge was deciding what not to build.

It's very tempting during a hackathon to keep adding features.

Calendar.

Teams.

Projects.

Analytics.

Accounts.

Collaboration.

But every time I considered another feature, I came back to one question:

Does this make "don't let me forget this" easier?

If not, it probably didn't belong in this version.

What I Learned

This project reminded me that AI products don't always need to start with a chatbot.

Sometimes AI is more useful when it quietly removes a step.

Without PingMe:

Think → remember → open app → create task → choose type → choose date → choose time → save

With PingMe:

Think → say it

That's the experience I'm trying to build toward.

I also learned that the most interesting AI interface isn't necessarily a giant chat window.

The intelligence can sit between what a human naturally says and what software needs to understand.

That is exactly what PingMe does.

What's Next?

There are several directions I'd love to explore after the challenge.

🧠 More capable local AI

My biggest goal would be moving more of PingMe's intelligence directly onto the user's device.

🔔 Better reminders

Smarter reminders based on urgency and context rather than simply displaying a fixed notification.

🎙️ Voice-first Brain Dump

Instead of typing anything:

"PingMe, remind me tomorrow morning to..."

and you're done.

🔁 Recurring commitments

Things like:

"Remind me to call my parents every Sunday."

📅 Calendar integration

Allow confirmed events to optionally appear in the user's existing calendar.

📱 Mobile experience

Turn PingMe into an even faster always-available capture experience on phones.

But I want to keep one principle regardless of how much PingMe grows:

It should always be easier than creating the reminder manually.

Why PingMe?

I started this challenge thinking about what I could build for a friend.

I ended it thinking about what we actually expect from a good friend.

A good friend listens.

A good friend understands what you mean even when you don't phrase everything perfectly.

And occasionally...

A good friend says:

"Hey, don't forget that thing you told me about."

That's PingMe.

Not another productivity dashboard.

Not another chatbot.

Just a small AI companion designed around a very human problem:

We have too much on our minds.

So...

Say it.

Forget it.

We'll remember. 💜

Prize Categories

I'm submitting PingMe for the partner categories that directly correspond to technologies used in the working project:

🧠 Gemma

Gemma provides the open-weight AI foundation for understanding natural Brain Dumps and transforming them into structured commitments.

☁️ Render

PingMe's production application is deployed using Render and is available through its live domain.

🔊 ElevenLabs

ElevenLabs powers PingMe's spoken Tell Me My Day experience, turning daily briefings into natural voice output.

Each integration serves an actual part of the product rather than being included solely for the category.

Try PingMe 💜

Live:

https://pingme.soumwadeepguha.com/

Source Code:

https://github.com/soumwadeep/PingMe

Give it a messy thought.

Something you'd normally tell a friend not to let you forget.

Then hit Sort My Brain.

I'd love to know whether PingMe understood you. 🙂