The ISA
One document that captures what 'done' looks like — the testable spec the Algorithm climbs toward.
Before LifeOS builds anything hard, it writes down what done looks like. That document is the ISA, the Ideal State Artifact. It holds the ideal state of whatever you’re working on, in enough detail that you can test whether you got there.
Why it exists
Most work fails at the definition, not the doing. “Done” lives in your head as a vague picture, so you and a tool can both think you’re finished and mean two different things. Nothing catches the gap until it’s already shipped.
The ISA drags that picture into the open before any work starts. It writes the ideal state as a hard-to-vary explanation: every part does a job, and removing or weakening any part changes what done means. A vague spec lets you wiggle out of it later. A hard-to-vary one doesn’t, which is the whole reason it’s worth the effort.
How it works
The ISA is one document with twelve sections in a fixed order, running from Problem and Vision at the top down through Goal, Criteria, and finally Verification. That order is fixed on purpose. You state what’s wrong and what right looks like, then what you’re deliberately leaving out, all before you name the goal.
The heart of it is the Criteria section: the ISCs. Each is a single claim you check with one probe, phrased so it comes out either true or false, and they are the tests themselves with no separate acceptance suite bolted on later. The task is done when every ISC passes, so progress is something the document computes rather than something you assert.
Two more things keep it honest. Principles bind how the system thinks and Constraints bind what the solution may do, while anti-criteria turn the things you ruled out into testable proof that they stayed out. And ISC IDs never renumber once written, so a criterion you point at today still means the same thing three edits from now.
That’s why one document does several jobs at once: the written articulation of done, the test harness while you build, the done condition when you finish, and the long-lived record afterward. Read it through whatever lens the current phase needs. The ideal state and the test that proves it are the same object, so nothing drifts between what you meant and what you actually check.
Where it fits
Every Algorithm run binds to an ISA. When the seven phases execute, the ISA is what they read and write, from the first scaffold in Observe to the evidence checked in at Verify. The Algorithm is the motion; the ISA is the thing that persists after the motion stops.
It lives in one of two homes. Work with a lasting identity (an app, a library, your blog, the Algorithm itself) keeps a project ISA in its repo that grows across every session. One-shot work gets a task ISA under a work folder, created when the job starts and archived when it’s done.
What it feels like
You start a real piece of work and the first thing that exists is a checklist of what would make it right, written before any guessing begins. As the work goes, you watch boxes flip from open to done, each with its proof sitting next to it. When it’s over, you don’t have to wonder whether it’s over. The document already knows, because every criterion it holds is checked and every check has evidence behind it.