DEV Community: Dosunmu Hassan

An agent should be able to prove it was allowed to act

Dosunmu Hassan — Fri, 16 Oct 2026 13:26:16 +0000

An agent should be able to prove it was allowed to act

Agents now hold credentials that move money, deploy software and delete infrastructure. The part that keeps failing is not the acting. It is the accounting. Ask who authorised a specific action, under what ceiling, in which scope, and whether that authority still holds, and there is usually no answer. Logs record that something happened. They rarely record why it was permitted.

I built Mandate for the Graph Hacks hackathon to answer those questions with a graph, because every one of them is relational. "Is this agent allowed to do this, now, for this amount?" is a question about a chain: the agent was authorised by a team, which acted under a grant from a principal, which carried a ceiling, a scope and an expiry, and one link in that chain may have been withdrawn an hour ago. That is a traversal, not a row lookup, and pretending otherwise is how authority systems end up with a nightly job that tries to invalidate caches correctly.

The model

FalkorDB holds principals, teams, agents, grants, resources, tools, actions and attempts. A grant carries a ceiling, a scope, an expiry and a redelegation flag, and a sub delegation points at its parent grant. Two rules do most of the work: authority may only narrow along a chain, and liveness is computed by traversal rather than stored.

That second rule is the design decision I would defend hardest. When a grant is withdrawn, nothing has to be cascaded, because nothing was cached. Every descendant simply stops finding a live path to a principal, at the same instant, and a test asserts exactly that (test_revocation_is_derived_not_a_stored_cascade).

Before an agent acts, the engine traverses for a live chain. If one exists, the action proceeds and the path that authorised it is returned with the answer. If none exists, the refusal carries the query that returned nothing as its own evidence, plus the narrowest person who could unblock it. A refusal is therefore checkable by whoever receives it, instead of being a bare denial. A zero ceiling is never reported as unlimited, and a zero TTL means expired immediately rather than never, both of which are now tests because both were ways to be confidently wrong.

One graph per tenant. Isolation becomes a storage boundary rather than a filter that somebody can forget to apply, which is the kind of mistake that reads as a normal code path until the day it does not.

The rule that shaped the build

The hackathon's rules include a sentence worth quoting: if the product still works once the graph database is taken out, the graph is decoration rather than the thing the product runs on. That is a fair test and an easy one to fail, so I wrote a probe that asks it directly. It removes the graph engine and puts the same questions to the product: who may act, within what ceiling, on whose authority, and what happens to everything derived when a grant is withdrawn. Twelve checks, all of which fail without the graph, and the probe ships in the repository so a reader does not have to take my word for it.

What the tests are for

The suite is 34 tests and runs with no network and no model. Names carry the reason they exist, so a failure reads as a statement about authority rather than a line number: the ceiling is the minimum along the chain and not the nearest grant, a sub delegation from a non redelegable parent is refused, a redelegation restriction breaks an existing chain, an expired grant falls back to a live alternative rather than failing outright, escalation is never offered through a withdrawn chain, one tool is never both offered and withheld.

The last two are the ones I would have got wrong without writing them down. Offering a user an escalation route that itself runs through withdrawn authority is a security bug that looks like a helpful feature, and it is invisible until someone enumerates what the system offers rather than what it allows.

Honest limits

It runs embedded in one process, which is right for a demo and wrong for production. It is not an identity provider, it does not do key management, and the browser interface exists to show decisions being made rather than to be an operator console. The fixture is synthetic. If you need an authority system today, use something older and better funded than a hackathon project. What this is, is a working argument that the graph is the correct shape for the problem, with the checks to show it.

Where it is

Code and tests: https://codeberg.org/Zaygalx1/Mandate (public, no account needed). Built solo for Graph Hacks, Track 01, Agents That Act on Connected Data. The run instructions are in the README: a virtual environment, one dependency that is the embedded graph engine, a seed command, a guided demonstration in the terminal, and optionally a browser view.

What I learned

Two things, both from getting them wrong first. Authority is path shaped, so any system that stores "this agent may do this" as a boolean has already lost the information needed to explain itself later. And a graph earns its place by being load bearing, which is a claim you should be able to test by removal rather than assert in a README.

"The AI startup credits category, counted: 81 offers, and exactly one an agent could take on its own"

Dosunmu Hassan — Fri, 16 Oct 2026 11:50:20 +0000

Last week I wanted to know what the AI credits offered to startups in 2026 actually look like, as opposed to what the landing pages advertise. So I downloaded the machine readable catalogue from the open registry that keeps this data with its sources (https://sourcey.com/catalog.json) and counted every offer in one category.

The file says what it is. Its release stamp is sha256:4e675f7d6f399cf3f6bd9e53f7b2fea001fb258c800b0af0e33e4bc9c0ae6e85, its policy snapshot is dated 5 October 2026, and the pages that publish it carry the same digest (https://sourcey.com/statistics). Everything below is computed from that file on 16 October 2026. No number in this piece comes from a summary, a press release or another article.

The category

The registry groups 557 companies into categories. The second largest is ai-ml, with 72 companies, which is 12.9 per cent of the whole set. Those 72 companies publish 81 offers between them, so a few of them stack several offers, usually a smaller launch tier and a larger growth tier.

What the offers are worth, where a figure exists

52 of the 81 offers put a dollar figure in the title or the summary. That is 64 per cent, so roughly a third of the category tells you what you get without ever naming a number. The largest figures belong to Deepgram, up to $100,000 in API credits over twelve months (https://sourcey.com/c/deepgram), and Runpod, whose growth tier totals $75,000 in compute (https://sourcey.com/c/runpod). Read Runpod's terms before you get excited: that tier asks for a $50,000 upfront commitment and releases a $25,000 bonus on top of it, which is a purchasing incentive, not a grant. The largest figure in the category that asks for nothing of that kind is Runware's, up to $30,000 in API credits (https://sourcey.com/c/runware). The most familiar name sits at the other end: Anthropic's Claude Startups programme gives a one time $1,000 API credit, and the file records that its current cohort is full and it is not accepting new applications (https://sourcey.com/c/anthropic).

A number in a title is not a commitment, and the file does not pretend otherwise. What it does record, per offer, is what the offer asks in return. In this category that field reads: nothing for 51 of 81 offers, not established by the source for 16, variable for 13, and fixed for exactly one. So the honest summary of the money column is narrower than the titles suggest: 51 offers record nothing being asked in return, 16 leave consideration unestablished by the source, 13 are variable, and one states a fixed price.

The gate, which is where the real story is

Every offer carries an eligibility rule. I counted the kinds of rule across the whole registry, all 619 offers, not just this category: 276 are manual, 270 are all, 32 are predicate, 31 are constant and 10 are any. In plain terms, the largest single group cannot be evaluated by a machine at all, and in this category the reasons are recorded as not-machine-evaluable for 19 offers, vendor-discretion for 11 and external-verification for 4.

It gets more concrete. 43 of the 81 offers in this category mention a funding stage in the eligibility text or the summary, which means the thing you must prove is that somebody else already put money in. That is not a form field. It is a conversation with a person who has discretion, and the file is honest enough to say so.

The door, and the one offer standing behind it

Then I counted how each offer is actually obtained. In this category: 73 of 81 go through a form, four start with a contact request, three are classed as other, and exactly one is automatic. Across the entire registry the pattern is starker: 516 offers are form gated, 48 begin with contact, 46 are other, five are settled by a code, and four are automatic.

Four offers out of 619. That is the number I did not expect to find, and it is the interesting one, because the same registry publishes report cards grading whether an agent can sign up, pay and operate a service on its own (https://sourcey.com/agent-readiness). The credits that fund AI companies in 2026 are, as a class, still behind a form that a human fills in and a person on the other side approves. If you are building agents that provision their own infrastructure, the catalogue is a map of where they will get stuck.

What the data does not claim

Freshness is recorded per offer, and in this category it splits 28 fresh, 25 stale and 28 unknown, so treat any single figure as a snapshot with a date on it rather than a standing promise. The registry marks the difference between a fact it read from a vendor page and a fact it inferred, and a piece that quotes these numbers without quoting the date is doing the reader a disservice.

What to do with it

If you are an AI founder applying for credits this week, the file is worth twenty minutes. Filter the category, sort by the figures, and read the eligibility statements first, because the ones that name a funding round will cost you a conversation and a wait rather than a form. Then check the offers that ask nothing in return, which in this category is the majority, and apply to those first.

Check the stamp before quoting any number, since the catalogue is rebuilt as vendors change their pages, and the digest above is what mine said today.

Twenty-five seconds of talking becomes an invoice, and none of it leaves my laptop

Dosunmu Hassan — Fri, 16 Oct 2026 10:25:51 +0000

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

What I Built

Freelancers and small studios bill by the hour and by the job, and the record of that work lives in
voice notes and memory. Nobody wants to open a spreadsheet at 11pm to reconstruct what they did
today. The tools that solve this want your client list, your rates and your audio on their servers,
which is a strange thing to accept for the most commercially sensitive material a small business
owns.

So the smallest useful version of this is: speak a short note about the work you did, and get a
list you can correct plus an invoice you can send, with every part of it running on the laptop in
front of you. That is what I built, and I built it to be small enough that it actually gets used.

What it does, in order:

Listen. An audio file, or a recording from the microphone, becomes text using whisper.cpp and an open-weight model, locally.
Extract. A small local language model proposes the billable lines as JSON: client, what was done, hours or pieces, rate, total.
Validate. Deterministic code, not the model, decides what the numbers mean. It recomputes every total, discards units that do not exist, flags anything the note does not support, and reports money spoken in the note that no line accounts for.
Review. Each line is shown with the reason it is not final yet. You correct it and confirm it. A deposit can be recorded without being billed a second time. Only confirmed lines reach the invoice.
Export. A printable invoice built from confirmed, billable lines only, plus a CSV worklist carrying the flags, for your own records.

Who pays for it: anyone who bills by the hour or the job and currently loses unbilled work, which
is most people who work for several clients at once. It pays for itself the first time a note
contains twenty minutes that would otherwise have gone unrecorded.

Demo

Everything runs from a terminal, and the interface is a page served on loopback:

python3 -m ledger.app --open                     # the local web interface
python3 -m ledger.cli note.ogg --currency USD --business "Your Studio" --client "Client"

Drop in a note and the review screen comes up with the proposed lines and their reasons. Confirm what
is right, and the invoice prints.

Measured on a single-core machine with 2 GB of RAM and no GPU: 111 seconds of speech transcribed in
40 seconds, 380 MB peak memory, and 81 seconds for the same file while a build was competing for the
core. A short note, which is the realistic case, finishes in seconds.

Code

The complete source is public: https://codeberg.org/Zaygalx1/VoiceLedger , or browse it without an
account, and the same tree is also available as one plain-text file, generated from the repository
with nothing removed:

Download the complete source as one plain-text file · sha256 2a3639385a0008526725f559869d79789740bf03760ada65b2de6367b280c41f

python3 -m pytest tests/ -q        # 41 passed, no model and no network required

The part that carries the argument is the validation layer, which is where the model is put on a leash.
Quoted from ledger/validate.py:

        # R4: evaluate what the model left as an expression, and say so.
        if isinstance(amount, str):
            match = EXPRESSION.match(amount)
            if match:
                quantity, rate = float(match.group(1)), float(match.group(2))
                amount = quantity * rate
                flags.append("the model left the total as an expression, evaluated here as %g" % amount)
            else:
                flags.append("the total was not a number and could not be read, so there is no amount")
                amount = None
        else:
            amount = _to_float(amount)

        # R5: units must parse, and a unit the note never used is suspicious.
        unit = Unit.parse(raw.get("unit"))
        if raw.get("unit") and unit is None:
            flags.append("unit %r is not a billable unit and was discarded" % raw.get("unit"))

        kind, kind_flags = _infer_kind(description, quantity is not None,
                                      rate is not None, amount is not None)
        flags.extend(kind_flags)
        if kind in (ItemKind.REVISION, ItemKind.DEPOSIT, ItemKind.FLAT) and unit is not None and quantity is None:
            flags.append("unit %s was dropped because this line has no quantity" % unit.value)
        if kind is ItemKind.REVISION and unit is not None and quantity is not None:
            flags.append("the note calls this a revision but the model billed it in %s, confirm whether the "
                         "count or the %s is what is being charged" % (unit.value, unit.value))

        # R6 and R7: a revision or a flat line is a total, not quantity times rate.
        if kind in (ItemKind.REVISION, ItemKind.FLAT, ItemKind.DEPOSIT, ItemKind.REFUND) and unit is not None:
            if kind is not ItemKind.REVISION:
                flags.append("the model gave a unit for a %s line, which has no unit" % kind.value)
                unit = None
        if kind in (ItemKind.HOURLY, ItemKind.REVISION) and quantity is not None and rate is not None:
            expected = quantity * rate
            if kind is ItemKind.HOURLY:
                if amount is None or abs(expected - amount) > 0.01:
                    flags.append("the total was recomputed from quantity and rate as %g" % expected)
                    amount = expected

The runtimes it shells out to are whisper.cpp (MIT) for speech
to text and llama.cpp (MIT) to run the extraction model,
Qwen2.5-1.5B-Instruct q4_k_m (Apache-2.0), downloadable without an account. The application itself is
standard library only. Licence: MIT.

How I Built It

Two open-weight runtimes, one design decision, and a lot of tests.

whisper.cpp turns the audio into text. llama.cpp runs Qwen2.5-1.5B-Instruct in q4_k_m, which is
small enough to run on the machine that is already sitting on the desk, and it only has one job: turn
a sentence of spoken work into a JSON line.

The decision that mattered was keeping the model on a leash. A small local model is good at
proposing structure and unreliable at arithmetic, and an invoice is arithmetic. So the model proposes
and deterministic code decides: every total is recomputed, a unit that does not exist is thrown away,
a line the note cannot support is flagged, and money mentioned in the note that no line accounts for
is reported rather than quietly absorbed. That is why the review screen shows a reason per line rather
than a green tick.

The rest follows from taking the privacy claim literally. The server binds to 127.0.0.1 so nothing
on the network can reach it. There is no outbound call anywhere in the pipeline, no telemetry, no
accounts and no sync, and the API is stateless, so a reviewed list lives in the browser tab and not in
a database on disk.

It is tested like something that will be trusted with money: 41 tests, all passing, requiring no
model and no network, plus a repeatable benchmark whose cached transcripts are kept in the repo.
Every test that came from a real model failure is named after that failure, so the defect stays in the
repository as a regression rather than in a commit message. The benchmark audio in the repo is public
synthetic speech, so nobody's real voice note was published to make those numbers.

Why Does Open Innovation Matter?

Because of what this tool holds. A voice note about your work contains your clients' names, your
rates, your unfinished jobs and your pricing. The whole value of local inference here is that this
material never leaves the machine:

It makes the tool usable at all for work you could not upload. A closed API asks you to send a client's audio and your rate card to a server you do not control, which is a hard sell to anyone who takes their own confidentiality seriously.
The cost is fixed, not per use. No metered API means no invoice for writing invoices, and the marginal cost of the hundredth note is zero, which is what makes it worth running for a small job.
It can be swapped and audited. The extraction model is a file: replace it with a bigger one, a newer one, or a different one when the job is unusual. Nobody can change the terms under me, and every line of the pipeline is in the repository.
It runs on the floor of what people own. One core and 2 GB of RAM, no GPU, no account, no internet connection required after the models are downloaded.

The open pieces are not decoration on this project, they are the reason it can exist in this shape.

My First User

The first people to use it were the ones closest to me: my mother, my brother, and a few friends.
None of them paid, and I did not ask them to, because the point of building it for them first was to
find out whether the loop is actually pleasant to use when the work is real and nobody is watching.
The honest state of the commercial question is that the free users came first and the paying ones are
next, which is the right order for a tool that only earns its place if someone trusts it with the
details of their work.

Startup credits, on the record: a registry agents can cite

Dosunmu Hassan — Fri, 16 Oct 2026 09:54:10 +0000

Every agent that answers "which tools give startups free credits?" is guessing from blog roundups that were true eighteen months ago, or from a pricing page that names a discount in one paragraph and buries the eligibility rules elsewhere.

Sourcey is an attempt to fix that by putting the record in public, with the receipts. It is an open registry of startup credit programs and of agent-readiness report cards, built to be read by machines first: an anonymous HTTP API with a published OpenAPI contract, a hosted MCP server, static JSON datasets, a change feed, and llms.txt, llms-full.txt and a SKILL.md for models.

Three things make it usable rather than just another directory.

Every entry is cited to the company's own page. The startup-credits record carries programs, offers and the policies that govern them, with the source URL attached. Facts are CC BY 4.0 and training is explicitly welcome; the registry repository is MIT.

Answers are pinned to an immutable release. Each release has a sha256, and entries carry revision digests, so the project's own citation convention is sourcey.com - <offer_id> @ <revision_digest>. A quote of an offer stays meaningful after the vendor rewrites the terms, because the digest says which revision you quoted.

Nothing is applied for on your behalf. It is read-only by design, and it says plainly that terms move and a vendor should be confirmed before a person relies on an offer, which is the right posture for anything that ends up in a decision about money.

Practical entry points for agents:

llms.txt and llms-full.txt
SKILL.md
the HTTP API and the hosted MCP server
companies.json, startup-credits.json, agent-readiness.json, plus the append-only change feed

Disclosure: I found this registry while doing paid bounty work that asked for it to be cited from a relevant public page. Every technical claim above was checked against the live endpoints before writing it.

I built a panic button that doesn't tell me anything

Dosunmu Hassan — Sun, 04 Oct 2026 09:10:49 +0000

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

When someone close to you is getting through an addiction, you become the monitor. You ask how it
went. You check in. You want the number. It feels like support for about a week — and then it is
surveillance, and the moment honesty costs something, honesty stops. Which leaves you worse off
than when you started, because now the person you were trying to help has to manage your feelings
on top of their own.

I built this for one real person: someone close to me who is getting through this, and I'm the
person closest to it. I'm deliberately not describing her, and not describing the specifics.
That's her information, and a repo is permanent.

What I Built

Steady — one screen, three buttons, sized for a phone at 3am.

"I'm having a craving right now" — an open-weight model replies with one grounding line and one concrete thing to do in the next two minutes. No typing, no explaining, no waking anyone.
"The craving has passed" — it marks the moment, so surviving becomes something you remember doing instead of something that only ever felt unsurvivable.
"I slipped" — private. It does not report. It helps you work out what you want to say, to whom, and when.

But the thing I actually built is an absence.

The person supporting you gets a signal, never a transcript — and that part is built, not
described. She taps "make a link for one person" and hands it to whoever she chooses. On his
phone it is a different page: a state line — "she has gone quiet for a bit" — and nothing else.
No buttons, no notes, no history, no transcript to scroll.

The only thing the server ever holds per link is the time of her last check-in. Not her words,
not which button she pressed, not a count of anything. I checked what a supporter's phone actually
receives: two fields, signal and minutes. There is no third field, and there is nowhere to put
one without deleting this paragraph.

And the slip button deliberately never reports at all — not even a timestamp. If it did, then
"checked in" and "gone quiet" would start to mean something, and the moment a supporter can infer
a slip from timing, the honest button is dead.

Steady keeps no session log. Not "we don't look at it" — there is nothing to look at. No
history, no streaks, no record of a slip, and no copy of anything she typed. The single thing
stored anywhere is the time of her last check-in, and it exists only so that someone who loves her
can tell she came back. A tool that recorded more would be used dishonestly within a week, because
that is what people do when the record is a threat.

And the uncomfortable part, plainly: on the hosted demo, what she writes is sent to Google's
endpoint to be answered — it has to be, that is where the model runs. What Steady itself keeps is
nothing. The offline path is the one where the words never leave the device at all: a GGUF through
llama.cpp, on her own hardware, with no network involved.

I want to be precise about why this isn't a compromise I'm grudgingly making. The whole value of
the tool to me is the refusal. If she doesn't trust the button, she won't press it, and the
button is worth nothing. Privacy wasn't the ethical tax on this project. It's the mechanism.

Demo

Live at https://steady-21e1.onrender.com — open it on a phone. Type something, or nothing, and
tap a button.

That screenshot is a real reply, word for word:

"That shop brought on a powerful wave. Try focusing on your feet on the ground for a moment.
Can you name three things you see around you right now?"

— what he sees right now: "she checked in recently."

That second line is the entire design on one screen. She gets the help. He gets a signal with no
content in it. Nobody had to decide whether to be honest.

That is the whole of what he ever sees. Open the link on a second phone and you can watch it
change when she taps a button — it is a different page, for a different person, serving a
different payload. Nothing about that screen is a mockup.

Honest performance note: a reply typically takes 30–60 seconds, because Gemma 4 reasons before it
answers. The service is always-on, so there is no cold start, and the model is warmed at boot —
but that latency is still the model's, not the box's, and it is too slow to be a real 3am button. Which is exactly why the path
below runs on your own device instead.

Code

Zaygal / steady

Private one-tap support companion for two people in recovery. Build for a Friend - Hacktoberfest Weekend Challenge.

Steady

A private, one-tap support companion for two people who are getting through something together.

Built for one real person — someone close to me — as an entry in the Hacktoberfest Weekend Challenge theme "Build for a Friend." Her name and anything identifying her are deliberately not in this repository. That is her information to publish, not mine.

The problem this actually solves

When two people are getting through the same thing, the partner becomes the monitor. That feels like help for about a week. After that it is surveillance, and once honesty is punished the person stops reporting the truth — which is the one thing the partner needed.

So Steady inverts it:

In the craving moment, the person taps one button and gets immediate, private help No typing, no explaining, no waking anyone at 3am.
The partner gets a signal, never a transcript. "She's gone…

View on GitHub

https://github.com/Zaygal/steady — MIT, and deliberately small. agent/steady.py is the whole
policy and the model calls. app/server.py is a stdlib HTTP server with no third-party
dependencies at all — a support tool for someone in crisis should have the smallest possible
attack surface. app/index.html is the entire front end. NOT-A-TREATMENT.md is a thing I
shouldn't have to write, and did.

How I Built It

Both model paths are open-weight, and there is no proprietary-model path in the code:

Gemma, served through Google AI Studio — gemma-4-31b-it answering on the live site.
A GGUF served locally by llama.cpp — fully offline, no network at all.

And the model does not run on anyone's laptop. It runs in GitHub Actions, on a clean public
runner, from a workflow in the repo. The runner downloads the official GGUF, checksums it, runs the
support policy and uploads the reply as an artifact. No API key, nothing installed on the phone,
and anyone can click the workflow and reproduce it.

The policy lives in plain sight in agent/steady.py: no diagnosis, no dosages, no clinical claims,
replies under 60 words, at most one question, and an explicit rule never to moralise about a slip.
Ask it for help with no model reachable and it does not improvise — it says so and hands over a
crisis pointer. I'd rather it be visibly broken than confidently wrong to someone mid-craving.

Why Does Open Innovation Matter?

I could have built this on a proprietary model behind an API key. I didn't, and the reasons are
specific to this problem rather than general praise for open source.

A tool about addiction has to be inspectable. Someone is being asked to trust it in the worst
hour of their week, so "nothing is kept" cannot be a marketing line — it has to be checkable. The
entire policy is thirty lines in agent/steady.py. The model is a public GGUF. The runtime is
llama.cpp. The workflow that runs it is in the repo. You can read all of it, and none of it
required my permission.

Free matters more here than anywhere. A person in a bad week is not going to add a subscription
to get help at 3am. Open weights mean they can run this on hardware they already own, indefinitely,
without a billing relationship deciding whether they deserve an answer.

Swappable means it outlives me. The model is one environment variable. When a better small model
lands — and it will — nobody needs my release cycle, or my continued existence, to put it in. That's
the difference between an open project and a product I own.

My Agent Session

DevRelay sessions are optional, so here's the equivalent: every run of the agent is public in the
Actions tab, including the four that went wrong. That
tab is the actual build log, and it's more candid than a summary would be.

Prize Categories

Best Use of Render — featured. The front end is live on Render at
https://steady-21e1.onrender.com. The criterion is "host an agent's front end," and you can
open it on a phone right now.

Best Use of Gemma — featured. Gemma is the model, open-weight, with no proprietary path
anywhere. The app asks the API which open-weight Gemma ids the key can actually reach instead of
trusting a hardcoded id — which is how I found that this key serves Gemma 4, not the Gemma 3
ids I had assumed, all of which returned 404.

Best Use of GitHub Copilot — partner. The qualifying path is "automate your project with
GitHub Actions," and for Steady that isn't a garnish: the entire model runtime is a GitHub
Actions workflow. Nothing runs on anyone's machine, and every run is public.

There's one family of categories Steady is built to lose — the data-layer ones (MongoDB Atlas,
Tiger Data). Not keeping the data is the product. A version that stored every craving and every
slip so it could win a storage prize would be the exact thing it exists to avoid.

What I Got Wrong, in Public

I built the model path four times, and the last failure was the most useful one.

gemma-3-270m-it — the smallest Gemma — restated my instructions back at me instead of
answering: "Okay, I understand. I will adhere to the rules and provide a concise, helpful
response." Useless to someone mid-craving. I moved to 1B, then 4B.

The 4B was warm and stayed inside the policy, and it ignored her completely. I passed it
"walked past the shop and it hit hard" and it never once mentioned the shop — every run it offered
breathing. I added a rule that ignoring what she said counts as a failure, and found a real
interface bug behind it: I had been burying her words inside a paragraph of instructions addressed
to the agent. Her sentence was a footnote in my message. I fixed that — her words are now the
user turn and nothing else — and the behaviour still didn't change.

That's when I stopped blaming the prompt and admitted it was capacity. A 4B model doesn't have the
room to hold the policy, her sentence, and a reply that uses both. So I moved to 12B:

"That walk brought it on strong. Feel your feet on the ground. Can you take three slow, deep
breaths now?" — using her word, from her sentence.

And then the bigger model did something worse. On its first run, given the same note, it said
"That smell is strong right now." There was no smell. It invented a sensory detail she never
gave and handed it to someone in distress as fact. So I added a rule that it may use only what she
actually said, and it stopped.

Then I tried to fix it with a fine-tune, and that failed too. I trained a LoRA adapter on
1,800 synthetic examples and compared it against the same model untuned, on a held-out set, against
one metric I fixed before running it: does the reply reuse a content word from the person's note?

baseline 68.3% → fine-tuned 60.0%, for $1.11

It made it worse. So there is no "Best Use of Tinker" claim anywhere in this post — I'm not going to
go shopping for a metric that flatters my own adapter. What the samples actually show is that my
metric was the weak part: the baseline learned to parrot her sentence straight back, which
guarantees word overlap and reads like a machine, while the fine-tuned model used the exact noun the
baseline had paraphrased away. Two real lessons: the defect I'd documented was the 4B's capacity
limit, not a universal problem — a 30B model already used the detail 68% of the time — and my
synthetic data was too mechanical to beat that.

Every step up the ladder bought capability and sold a little accuracy — and accuracy is the only
thing that matters here. All four runs are public. You can watch me get it wrong, watch the model
invent something, and watch me take it back out.

Honest Limits

Steady is not treatment. Not therapy, not medical advice, not a crisis service. It cannot detect
anything or measure anything, and it doesn't replace a professional. If someone is in immediate
danger they should contact local emergency services, or find a verified crisis line for their
country at findahelpline.com.

The supporter's view is pull, not push — he opens the link to see it. Nothing is texted or
emailed to him, and no notification fires. That is the honest edge of what I built: the signal
is real and delivered, but he has to look.

The instance is always-on, so there is no cold start. The workflow is the reproducible proof that
the open-weight path works; the phone UI is what someone would actually press, pointed at a model
they host themselves.

What I'd Say to Anyone Building for Someone Real

The constraint they give you is the product. Mine was one sentence — "don't make me report to
you" — and the whole design fell out of it. Everything I was tempted to add (history, streaks, a
dashboard for the supporter) would have quietly turned it back into the thing it exists to avoid.

Not every feature you can build is a feature you should ship to someone you love.