The Diabetes Coach
I built The Diabetes Coach to manage my own Type 2 Diabetes. It has run every day since 8 July 2026.
It works like a conversation. Every morning I tell it how the night went and what I ate, and it keeps the record, finds the patterns, and explains what it’s seeing.
Most diabetes apps are reactive. They tell you what your glucose is doing now, and maybe what it did this week. This one works the other way round. Everything that gets logged — a meal, an insulin dose, a session at the gym, a bad night’s sleep, a cold — is read against everything that came before it, never on its own.
The instruction the whole system is built around is three words.
Always think longitudinally.
Which means: never judge today on its own.
The goal isn’t better numbers. It’s understanding why my diabetes behaves the way it does, so that my own judgement keeps getting better — not just the system’s. It’s built to make me less dependent on it, not more.
01
What it is, and what it isn’t
It isn’t an app, a product or a service. And it isn’t just me chatting to an AI.
It’s a conversation with a rulebook behind it. The rules are written down in full, and when one of them changes, the change is recorded along with the reason — so the system can’t quietly drift into doing something different. The records don’t live in chat messages either; they live in proper databases, so nothing is lost when a conversation ends.
Every document it produces has to pass a set of automatic checks before I ever see it. If a report fails one, it gets deleted rather than handed over.
It never tells me what to do, and it never suggests an insulin dose. If something it notices doesn’t match what my care team has told me, it says so and stops there. It doesn’t try to settle it.
This is not medical advice and it is not a medical device. It is a personal system that helps me understand my own data. Every clinical decision remains with my care team.
02
How it’s built
Four parts. The split between the first two is the one that shaped everything else.
The rules
Written instructions the system follows. One long document covers how it should think about the medical side. A second, shorter one covers what it should actually do each morning. Splitting them was forced on me by a technical limit, and it turned out to be the best decision in the project: the thinking changes slowly, the daily routine changes constantly, and keeping them apart means changing one never disturbs the other. The second document has been rewritten more than sixty times since July.
The records
Four databases holding the day-by-day record: what happened each day, every report ever produced, a running list of faults still to fix, and a food reference. They sit outside the conversation, so nothing is lost when a conversation ends.
The documents
Around thirty small programs that turn those records into finished, printable reports — the kind of thing you could hand to a specialist without apologising for it.
The checks
Seven automatic tests. Nothing reaches me until it has passed all seven. A document that fails one is deleted on the spot rather than just marked as faulty, because a broken document left sitting on a disk eventually gets sent by somebody who didn’t read the warning.
03
How a day runs
The morning opens with a closed list of nine questions, asked one at a time, waiting for each answer. The list is closed in both directions: adding a tenth is a defect, and so is dropping one of the nine.
The rule behind it is the part worth stating. Every one of the nine asks for something that exists nowhere but in my possession — my phone, my body, my memory of the previous evening. Nothing on the list can be recovered from a database. That is the test a proposed tenth question has to pass, and almost nothing passes it. Anything else the system wants, it queries rather than asks.
The day is then written up as a Daily Clinical Record — covering the previous day, not the one just beginning. Two of its three sources only settle overnight: step counts keep accruing after an evening screenshot, and the full glucose trace is only visible in the following day’s logbook. A record written the night before is built on a partial day.
Every Monday runs a fixed sequence: the two weekly reports, a nutrition database check against the week’s food log, a report card, the document register, and finally a review of every outstanding development item. The ordering is deliberate throughout — the register runs second-to-last so that anything it surfaces enters the development review in the same sitting rather than waiting a week.
04
How the reports build on each other
Each level is built from the smaller reports that feed it — never by going back to the raw data.
The chain is never short-cut, for two reasons.
The first is that some of the most reliable figures only exist at one level. The best glucose measurement my sensor produces covers a week — there is no daily equivalent, only my own estimate read off a chart. Build a month straight out of days and it carries estimates where it should carry measurements.
The second matters more. Each level isn’t adding things up — it’s forming a judgement by reading a whole period together. The patterns, the ratings and the summaries are conclusions reached by looking at a full week or a full month at once. Rebuilding a month from its days would throw away reasoning that has already been done and already been checked.
Weeks run Monday to Sunday and months run to the calendar, so they almost never line up. A week that crosses from one month into the next contributes only the days inside the month being reported, and if that week’s own report doesn’t exist yet, those days come from the daily records instead — with the report saying plainly where each part came from.
All of this serves the three words at the top of this page. You cannot think longitudinally without something built to hold a month or a quarter the way a daily record holds a day. It is also what makes it possible to put a document in front of a specialist that stands up to being read closely.
05
Confirmed patterns, and withdrawn ones
What I’ve learned about how my own body reacts is kept in something called the Pattern Library. Nothing goes in on the strength of a single day. It has to happen again, with evidence behind it, and every report marks each pattern as new, strengthened, unchanged or weakened — against what the library said before that report was written.
Patterns come back out, too. When later evidence contradicts something the system believed, it is withdrawn on the record rather than quietly dropped.
Here’s a real one. For weeks the system held that eating a lot of carbohydrate late at night produced a long, difficult night, and it had good evidence for it. Then a night came along carrying far more than usual — and almost nothing happened. One day doesn’t overturn a pattern. But it does mean the pattern can’t be stated the way it was, so it now sits marked as needing revision, with the day that broke it recorded alongside it.
The same rule covers the system’s own list of faults still to fix. An item found to be wrong isn’t deleted — it’s marked withdrawn with the reasoning kept, because that reasoning is the only thing that stops the same wrong item being raised all over again.
It holds itself to the same standard it holds my body to. Most health advice is asserted once and then repeated forever. Here, being wrong gets written down and kept.
06
By the numbers
None of these are health numbers. There isn’t a glucose reading or a weight among them — those are between me and my care team, and they’re not what this page is about. What these measure is how carefully the thing was built.
The two I’d point at first look like failures. 208 faults raised, and 66 revisions to the rulebook in seven weeks. That isn’t the record of a system that worked; it’s the record of one that kept being wrong and kept writing it down. Almost every rule in that rulebook exists because something went wrong first — a report delivered with the wrong day in its footer, a check that passed when it shouldn’t have, a question put to me that the system could have answered itself. Twenty-nine of those faults are still open, and that number is meant to be visible rather than tidied away.
The rest describe what came out of that. Seven automatic checks every document has to pass before it reaches me. Forty-two scripts doing work I never have to think about. Five databases holding the record, so nothing important depends on a conversation being remembered. And 254 foods, up from 7 — the one figure here that’s simply the system learning.
One caveat, because a page like this shouldn’t pretend otherwise. These move: the day count every morning, the faults every week, the foods every Monday. They were right when they were written and they’ll drift afterwards — which is a small live demonstration of the exact problem those seven checks exist to solve.
07
A sibling project: Trainer PT
Trainer PT is a second system, built the same way. It plans my gym sessions and writes each one up as a Daily Training Report, which The Diabetes Coach reads the next morning.
Information crosses in one direction only. Trainer PT supplies the training data. The Coach works out what that training did to my glucose. Trainer PT never says anything about insulin.
That boundary isn’t tidiness — it’s the reason the two are separate at all. Cardio and resistance work push glucose in opposite directions, and a session’s effect can still be arriving many hours after it ends. Anything giving training advice without seeing the glucose data would be guessing. So the two stay apart, and only the record travels between them.
It earns its keep. One evening this month, a rise before dinner and an unusually settled night turned out to have the same single cause — a long session that trained the largest muscles in the body for the first time in over a week. Neither made sense until the training report was sitting beside the glucose trace.
08
What building it taught me
Most of what I’ve written above is not really about diabetes. It’s about what it takes to make a system tell you the truth when nobody is checking — naming a gap instead of leaving it blank, deleting the document that failed rather than noting it, measuring before looking, and removing the moment at which a step can be quietly skipped.
The constraint that produced the best design was the one I resented at the time: a character limit that forced two documents where I only wanted one. Splitting how it thinks from what it does each day turned out to be the decision everything else rests on, and I didn’t choose it.
And the discipline that has mattered most is the least technical one. The system exists to make my own judgement better, not to replace it — and after fifty days, that’s the part that has actually held.
The Nine Questions — the nine things it asks me every morning, and why.
