The Ecosystem · 2025–present
Halo
A clinical protocol is a lived experience, not a document, care improves when the protocol becomes an inhabitable space.
A desktop system for living a year-long care protocol without having to hold it in your head.
Halo's Dashboard, a weight-projection chart with confidence bands over a twelve-month recovery window, beside cards for today's agenda, current weight, and protein intake.
The handover
The protocol arrives as a document. Recovery happens in days.
A care plan is written the way documents are written: complete, atemporal, addressed to no particular Tuesday. It is handed over at the one moment its recipient is least equipped to operationalise anything, and from then on it has to be converted, every morning, into what to eat, when to move, and in what order to do things. That conversion is the actual work. Nobody does it on paper.
-
Nothing shares a container
The plan is a document, the movement guidance is in a message thread, the daily list is on paper, the appointment is in a calendar. Answering one ordinary question means assembling four sources that were never designed to be read together.
-
Written without a today
A document describes every phase at once and leaves the reader to work out which paragraph applies on day nine. That is precisely the question being asked, and it is the only one the document will not answer.
-
Rules that interact
Some instructions are not independent of each other. Ordering one thing wrongly quietly degrades two. Getting it right is arithmetic across the whole shape of a day, and it has to be redone every time the day moves.
-
A trajectory with nothing to compare against
There is an expected curve, drawn from population data before anything begins. There is a scale in the bathroom. Nothing puts them on the same axis, so whether this is going as it should stays a feeling rather than a reading.
-
Bad days recalculate everything
On a day when the body will not cooperate, the plan does not adapt itself. Every domain has to be scaled down by hand, at exactly the moment there is least capacity to do it. So it tends to be abandoned instead.
-
Cold by convention
Software in this category is styled to look clinical, and clinical is not a register anyone wants to inhabit daily for a year. The tone becomes its own reason to stop opening it.
The contradiction underneath
The reframe
You cannot simplify the protocol. Only what it costs to follow.
The content of the plan is not negotiable, and it is not the system's to touch. It was authored by people with the standing to author it. What is negotiable is everything sitting between that plan and the day: the remembering, the phase arithmetic, the reassembly of four formats into one answer. Almost none of that is care. All of it is cost.
The person spends themselves on living the day. Knowing which day it is, what the rules are on it, and what the numbers say belongs to the system.
The second reframe: a protocol is a function of time
A document is the wrong container, and not because documents are old-fashioned. A care plan is not a body of reference to be consulted; it is a schedule that resolves differently on every date it is read. Model it as text and the reader has to do the resolving. Model it as a function of the day and the resolving becomes the system's job, which is the entire difference between a plan that is available and a plan that is present.
That one decision generates most of the architecture. Phases stop being headings and become states with transitions. Volumes, intervals and ceilings stop being table rows to look up and become values a date returns. The interface acquires a tense. It is about now, and it needs no index, because nothing has to be found.
What the space holds
Nine surfaces, six questions, none of them asked twice
Each of these removes a reconstruction, never a decision. Nothing here prescribes: the clinical content is authored elsewhere, by people qualified to author it, and the system's entire contribution is to make that authorship navigable, temporal, and possible to inhabit.
The day, already resolved
Opening the app answers the questions a day starts with: how far along this is, what the current phase asks for, what is scheduled, what comes next and when. None of it is looked up. Behind it, a timeline holds the fixed points of the year, so the horizon stays visible from the middle of it.
Dashboard · Timeline
A plan that changes shape
Nutrition is not one plan but a sequence of them, and the surface re-forms as the phase advances: volume per meal, interval between them, consistency, the schedule for the day, and the recipes that satisfy it. The day's log runs against the target and reports what is left rather than what is done.
Nutrition
Ordering as the hard constraint
Some items on a daily list are not independent, and the schedule exists to hold them apart. The day is rendered already ordered, with the separations applied and the exceptions marked as what they are: the weekly one, the one taken on an empty stomach. This is arithmetic nobody should be doing at seven in the morning.
Supplements
Effort that bends
Movement follows a progression with ceilings that rise as clearance is given. It also has a second mode: on a bad day a reduced protocol is already written for each domain, graded by how bad the day is, with a defined way back up. The plan scales down instead of breaking, which is the difference between a hard week and a lost one.
Activity
Measured against an expectation
A published model supplies an expected trajectory with confidence bands. Entries are logged against it and drawn on the same axis, smoothed by a rolling mean so a single day cannot impersonate a trend. From that: pace, weekly change, distance to the next goal, and an honest reading of whether the current rate arrives in time. Slower markers keep their own cadence, with their collection windows anticipated rather than remembered.
Weight · Measurements · Lab results
The part that is allowed to interrupt
One surface is deliberately loud. Warning signs are held by severity, each carrying the action it warrants and the person to contact: rest, call, or do not wait. Everything else here is built to stay quiet; this is the single place where being unmissable matters more than being calm.
Warning signs
Architecture
Three planes, and a protocol the system is not allowed to author
The shape follows from two facts. The clinical content comes from outside and has to stay outside the system's authority. Everything the person generates is theirs and stays on their own machine. What sits between them is an interface whose defining feature is knowing what day it is.
Three planes
The knowledge plane is reference data: phases, schedules, progressions, thresholds, the signs that warrant a call. It is transcribed from the clinical team's guidance rather than invented, and it is versioned in git, so a change to what the plan says is a change with a date and a diff attached. The system reads this plane. It does not write to it, and it does not reason past it.
The state plane is everything the person records: measurements, logs, what was done and when. It is written as plain files under their own home directory and goes nowhere else. No account, no sync, no server. That is less a privacy feature than the only defensible default for this category of data.
One protocol, phase by phase
A protocol is a state machine with a clock, and modelling it that way is what allows the interface to be about today. Nutrition moves through its phases; movement moves through its own; a bad day is a state as well, with defined ways in and a graded way back out. Every transition changes what all nine surfaces report, because each surface is asking the same question: what does this date return?
The detail that matters is that not every transition is automatic. Some are gated on clearance from the clinical team, and the system models the gate rather than routing around it. A date arriving is not permission. Encoding that distinction is how a piece of software stays an organiser instead of quietly promoting itself to an advisor.
The substrate
There is no database and no backend. Reference data is YAML in a repository; personal state is YAML in a directory the person owns. Both stay readable without the application, which matters more here than in most places, because a year of daily records should not be hostage to whether a desktop app still builds in 2031.
Above that sits a desktop shell of nine surfaces, one per domain, each reading its own files and rendering them against the current date. The material is glass and the light shifts with the hour. That is not decoration: it is the difference between something that feels like a chart and something that feels like a room.
- Dashboardthe day resolved: phase, agenda, trajectory
- Nutritionphase volumes, intervals, the day's schedule and log
- Supplementsthe ordered day, separations already applied
- Activityprogressions, ceilings, and the reduced protocol
- Measurementswhat is entered by hand, and kept
- Lab resultsslower markers and their collection windows
- Warning signsseverity, the action it warrants, who to call
- Timelinethe fixed points of the year
- Weightactual against expected, pace, distance to goal
What compounds
The phases pass. The record does not.
Every phase in this protocol is temporary by design: each one exists in order to be left behind. What accumulates underneath them is the opposite: a continuous, dated, first-person account of a year that would otherwise survive only as recollection.
A year spent inside this leaves three things behind. A trajectory: the curve begins as a prediction made about people in general and, entry by entry, becomes a description of someone in particular, which is what makes the later months legible in a way the first weeks could not be. A practice: phases install habits and then expire, and the habit is the part that stays. A record: dated, continuous, and complete enough to be read by someone else.
That last deposit is the one that changes something outside the software. A follow-up appointment normally runs on recollection: a person trying to summarise ten weeks from memory, in a room, under time pressure. With a record, it runs on data the person brought themselves. The professionals reason from what actually happened, and the person arrives as the best-documented participant in their own care rather than the least reliable witness to it.
None of which makes this a medical instrument, and the design is careful to keep saying so. Halo does not diagnose, does not advise, and does not adjust a plan on anyone’s behalf. It holds structure that came from elsewhere and makes it inhabitable. Knowing what not to claim is not a limitation bolted on at the end. It is the constraint the architecture was built around, and it is why the gates in the state machine wait for a human instead of a timer. An interface earns trust the same way a clinician does: partly by what it knows, and substantially by knowing where its authority stops.
The same instinct runs through the rest of the ecosystem. Ciclus sustains the person, Compass gets the work, Continuum does it. Each holds structure so that a person does not have to hold it themselves. Halo is that idea applied where the stakes are least abstract: a long recovery, a plan that has to be followed on days when following anything is hard, and a system whose entire job is to be already open to the right page. What it asks of the person is the only thing no system can do on their behalf, which is to live the day.