The Algorithm
A seven-phase engine that turns a vague ask into a testable spec and climbs toward it.
Most tools do what you ask and stop. The Algorithm does something more disciplined: it takes a vague request, turns it into a spec you can test, and climbs toward that spec one checked step at a time. It runs at every scale, from a typo fix up to a company launch, because the shape of the work is always the same.
Why it exists
A request is almost never as clear as it sounds. “Make the page faster” hides a dozen questions: faster for whom, measured how, at what cost, judged against what baseline. Skip past those and start building, and you build the wrong thing well.
The Algorithm forces the questions first. It reverse-engineers what you actually want into Ideal State Criteria — small, binary claims that are each either true or false. Once done is written down that way, it can’t drift. You either meet the criteria or you don’t, with no room to call something finished because you got tired of it.
That discipline covers the whole range of work. When the result is checkable (a code change, a deploy), the criteria are literal tests. When it’s a judgment call or a piece of writing, the criteria describe what a right answer would have to do, so even soft work gets a hard target.
How it works
The engine runs in seven phases: Observe reverse-engineers the request and sets the effort, Think hunts for risks and prior work, Plan picks the approach, Build stages the pieces, Execute does the work and checks off each criterion, Verify proves every one with evidence, and Learn feeds the lessons back.
Every run also carries a checklist of its own quality. The criteria have to be granular enough that each maps to a single probe, and a harder tier demands more of them before the build can start. Under-specified work doesn’t proceed; it goes back and gets split until each piece is one testable thing.
Effort scales to the task. A quick lookup runs a compressed path in under ninety seconds; a hard cross-system design gets the full engine and up to two hours of budget. You never pick the level yourself, and the system can only floor up, so a hard question can’t slip through as a shallow one.
Verify is where most tools cheat and this one won’t. Every criterion marked done needs a live-probe behind it: command output, an HTTP response, a screenshot, a diff. “Should work” counts as a failure, and at the deepest tiers a model from another vendor reads the work too, since same-family models share the same blind spots.
Where it fits
This is the engine at the center. Current State to Ideal State is the idea; the Algorithm is how that idea happens on a given task. Everything else in LifeOS exists to serve it: skills give it capabilities, hooks hold it to the rules, the router sets its effort, memory carries what it learned.
Each run binds to an ISA, the one document that holds the ideal state and its test criteria, plus the running record of everything that happened. And every run makes the next one better. What the system learns about your work and about itself gets captured and fed back, so the Algorithm keeps upgrading its own behavior.
What it feels like
You ask for something fuzzy, and instead of a fast guess you get a short list of exactly what the answer has to satisfy. Then the work comes back with each box checked and the evidence attached, so you read the proof instead of taking “done” on faith. On the hard stuff it feels less like handing a task to a tool and more like working with something that won’t call a job finished until it actually is.