Beck — scope for replacing iris360

Written 2026-08-03, from a read of the full 188-file export.

Beck is the name Scott chose for the replacement, after Aaron Beck, who founded cognitive behavioural therapy. Throughout this document iris360 and iris refer to the product being replaced; Beck refers to what we would build.

1. What the product actually is

Calling iris360 a health tracker undersells it and points a rebuild in the wrong direction. Reading eight months of transcripts, it does four things, and only four:

Capture without friction. Scott types 142/92 p:100 and that becomes a structured entry with a timestamp, a context flag (pre-dose), and an ID. He never opens a form. This is why the interface is a chat window and not an app with fields, and it is why the average message is 180 characters.

Place the datum in its trend, immediately. This is the whole product. A representative reply:

Second day-1 evening reading in the same band: 14:04 was 132/80 p76, now 132/81 p85. Systolic settled after the 09:44 and 12:06 spikes, and the jitters-era pulse of ~100 is down to 85. Day 1 on 8mg reads tolerated.

One number in, the day’s arc back. Their own supervisor agent named it exactly right in a review: “the one thing a search engine can’t [do] — placed a single number inside the day’s trend.”

Keep a case file that survives. Long-term memory is markdown, curated by an agent, compressed when it grows. Month eight still knows what month one established. When blood-pressure.md hit 736 words the memory agent proactively offered to summarise July and keep only the current dose stretch verbatim.

Reach out first, with the right question. Check-ins are not reminders. Each one is briefed with yesterday’s open threads:

Morning check-in: pre-dose BP + pulse (day 4 on 8mg), and confirm jitters/tingling status — that one went unanswered yesterday.

Everything else in the product — the Guides library, the web UI, the charts — is packaging around those four.

The quality that is easy to miss and hard to copy

iris knows its lane, and corrects itself when it strays. From 31 July, six minutes after overreaching:

One correction on the pulse: I shouldn’t have called it not a concern or tied it to the candesartan step — that’s Giesecke’s read, not mine. What I can say is it’s above your recent 75-90 range.

It escalated (“that’s a call to Giesecke’s office, today”), accepted Scott’s decision to wait, set a concrete recheck time, and listed explicit red flags for when to stop waiting. Then it de-escalated cleanly once the numbers came down, without dropping the thread.

That discipline is the part a rebuild is most likely to lose, and losing it is the part that actually matters. A general-purpose assistant reaching for helpfulness will validate where iris noticed, and will reassure where iris said “I’m not going to guess at the cause.”

2. What the archive gives us

188 daily files · 735 conversations · 1.9 MB · 10.12.2025 → 03.08.2026. Gaps are real (a 27-day break across May, a handful of single days), consistent with days Scott did not use it.

Five agents are visible in the transcripts, along with the exact prompts passed between them:

The memory filesystem, reconstructed from references across the corpus:

/notes/
  identity.md                     who Scott is, baseline, what matters to him
  current-focus.md                the live picture — most-referenced file by far (149 mentions)
  autopilot.md                    check-in schedule, cadence, milestones, watch list
  summary.md
  topics/
    blood-pressure.md
    bathroom-anxiety-gi-patterns.md
    sleep-reflux-management.md
    right-shoulder-pain.md
    depression-antidepressant.md
  archive/
    gi-patterns-early-history.md

Custom tracking schemas are per-user and specific. His “LEAVING check-in” carries: bathroom routine beforehand (y/n), empty stomach (y/n), toilet urge (0–10), familiar destination (y/n), lemon squirt (y/n) — that last one because lemon juice is his own grounding technique, surfaced in onboarding on day one. A generic schema would never have that field, and the field is where the signal is.

Scale is not a problem. 952 user messages in eight months, roughly five a day, 180 characters each. 171 KB of input in total. Whatever makes this hard, it is not throughput.

3. Proposed architecture

Channel: Discord

Scott is already in the server, already talks to Obadiah, already has it on his phone. Reusing it deletes the largest single line item in any rebuild — no WhatsApp Business API, no auth, no app. #beck now exists (1533940602675396779) with Scott granted visibility; the bot allowlist is a separate layer and still needs /discord:access from Joshua’s terminal.

The cost is that Discord is not a health app and never will be. No charts inline, no export button, attachments are awkward. Phase 4 answers that with a web view; Phases 0–3 do not need one.

Store: SQLite, local

One user, tiny data, and the entire record is someone else’s health information. Local-first means there is no hosted database holding Scott’s medical history and no conversation to have about who is responsible for it. Nightly encrypted backup. Move to Supabase only when a web view genuinely needs it, and then push only what the view requires.

Memory: markdown in git

Mirror their structure directly, because it is good and because it makes seeding trivial. Git gives free history, diffs, and rollback, which is strictly better than what iris360 had. Scott can read his own case file, and correct it.

Agents: three, not five

• beck — the front door. Converses, logs through tools, always loads current-focus.md plus recent entries for the topic in play.
• curator — merges their memory_manager and tracking. After a conversation closes, writes the entries and updates the notes. Compresses when a file grows past a threshold.
• autopilot — merges their supervisor. Runs on cron. Decides whether to check in, writes the brief that gets injected into the check-in, and does a weekly review of whether any of this is still helping.

The five-way split reads like an artefact of their platform rather than a requirement. Three covers the same loop at lower cost and with fewer handoffs to get wrong.

Scheduling and the failure mode that matters

Cron already runs the smart-home jobs, so the mechanism exists. The thing to build carefully is the heartbeat: if no check-in has posted in 26 hours, alert Joshua. A silent cron failure during a dose titration puts a hole in the data at exactly the moment the data is load-bearing, and nobody would notice for a week. This is the most likely way a hobby rebuild quietly fails, and it is cheap to prevent.

4. Seeding — the part that makes this worth doing

A rebuild starting cold is a downgrade from what Scott has. A rebuild seeded with his history is better than iris360 on day one, because it also has eight months of how iris talked to him to calibrate against.

1. Transcripts → entries. Parse the 188 files into the entries table. The format is regular enough to parse mechanically: date header, numbered conversations, [HH:MM] ROLE: lines, and a RECAP: block closing most conversations.
2. Transcripts → tone. Their RECAP blocks include self-critique (“Quality notes”, “Worth watching”). That is a ready-made evaluation set: 735 worked examples of what good looked like, already labelled by the system that produced them.
3. The /notes/*.md files → memory, directly. Still to be exported. This is the highest-value remaining item and it needs Scott’s live session.
4. The Guides library → reference material the agent can cite.

5. Phasing

Phase 0 — stop the bleeding. This week. Scott is mid-titration with nowhere to log. A Discord channel, a hand-seeded current-focus.md, and an attentive agent. No database, no cron, no parsing. This buys weeks and is worth doing even if the answer to the big question turns out to be “just pay them.”

Phase 1 — capture and trend. SQLite, a log tool, entry IDs, and trend context loaded on every reply. This is where most of the product value lands.

Phase 2 — the case file. Curator agent, the notes structure, compression when files grow. Seed from the transcripts.

Phase 3 — autopilot. Cron check-ins with briefs, the weekly review, and the heartbeat monitor.

Phase 4 — web view, optional. scott-bp-log.pages.dev already exists and already does BP charting and a doctor-ready PDF. Fold it in rather than rebuild it. This phase is smaller than it looks.

6. Cost

At five user messages a day, plus a curator pass and two or three autopilot runs, this is a handful of Claude API calls per day against a context of a few thousand tokens. Order of magnitude: low single-digit dollars per month, less with sensible model routing (front door on a strong model, curator and autopilot on a cheaper one).

Cost is not the deciding factor in either direction. Build time is, and so is the ongoing attention any always-on system demands.

7. Risks worth taking seriously

It is medical, and the safety discipline is the hard part. Not the logging, not the charts. Getting escalation right — and getting de-escalation right without dropping the thread — is prompt and evaluation work, and it needs testing against real cases. The archive supplies those cases.

Sycophancy. A general assistant validates. iris noticed. The 31 July self-correction is the behaviour to design for and to test for explicitly.

Silent failure. Covered above. Heartbeat from day one of Phase 3.

Dependency, again. Building it internally moves the dependency from a startup to Joshua. If Joshua is travelling and it breaks, Scott is in the same position he is in tonight. Worth being honest that this trades one single point of failure for another.

Scope creep. iris360 is a funded product with a guides library and a web app. The daily loop is perhaps a tenth of it, and the daily loop is all Scott uses.

8. The decision, stated plainly

The technical question is answerable: yes, this is buildable, the archive makes it substantially easier than starting cold, and the infrastructure mostly exists.

The real question is different. If iris360 costs €15–30 a month and it works, paying is the rational move and the export is insurance. The rebuild case rests on four things, none of them technical:

• Scott’s health record stays in his own hands
• it can be shaped to him specifically, in ways a product serving thousands cannot
• it cannot be sunset, repriced, or paywalled by someone else’s runway
• Joshua wants to build it

Three of those four are real. The fourth is the one that actually decides it.

One thing the last two days settled on its own: a company that replaces every clinical reply with a billing link on day four of a blood-pressure titration has told you what it is. That is not an argument that the software is bad. It is an argument about what depending on it costs.

And Scott should be asked before any of this gets built. He is the user. He may want to pay and move on, and that would be a fine answer.