AI work method
How Mothex grew, one failure at a time
Mothex was not designed in one go. It grew by running real work across many AI sessions, noticing what went wrong, and adding one habit at a time to answer it. This is that sequence, told as problems and the habits that answered them.
The question that started it
When work runs across many AI sessions at once, the most expensive question is the simplest one: what is actually done? Each time it came up, the answer meant scrolling through old chats, and part of every session went on proving again what had already been proved. The first requirement was modest: a way to run work across many sessions without losing context and without re-proving finished items.
One ledger, built on top of the notes that already existed
The first design did not replace the existing notes (a decision log, a one-page state summary, an archive index). It added one thing above them: a single table with one row per work item. Each row carried a status, a proof reference, the dependencies, an owner, the done-criteria and one next action. The point was to make the status of the whole program readable in one place.
Every session writes its own plan, and one session decides
A single ledger needs to know what each session is doing right now. So every working session writes its own local plan, once at the start and again whenever it finds something new to add. Sessions do not edit the ledger. They propose changes, and one designated session, the control session, is the only one that merges them. This is the rule that later became "one session controls; the rest propose".
Standard paperwork, so nothing is left to interpretation
Once sessions proposed changes, the proposals had to look the same every time. The method gained fixed documents for a session plan, a change proposal, a closing handoff and an opening bootstrap, plus an onboarding guide written to leave no room for ambiguity. A proposal also states which version of the ledger it was based on, so a stale proposal is caught at merge time instead of after it has done damage.
Standards travel inside every document
In my experience, an AI’s attention to an instruction can weaken over a long session, even when the instruction is still in view. So the standards that matter (what good means here, what the project is and is not, what counts as evidence) are written once and then repeated word for word in every bootstrap, plan and handoff, instead of being trusted to memory. The repetition is deliberate.
A seed is not the truth
The first ledger was a starter seed, and it was labeled as one: rows could not be marked proved until a proof reference was attached, and the whole ledger had to be reconciled against current evidence before its first real merge. The same rule applied to the rollout itself. If a required input was missing, such as a verified list of which sessions were live, the control session had to say so, ask for exactly one artifact and wait, instead of inventing the list.
A review that is allowed to finish
Open-ended review ("find issues") never ends, because it always finds something, and the reader cannot tell a real defect from a marginal one. The last addition was a conformance check with a fixed written list of yes/no items, a rule that a finding only blocks work if it can state the trigger, the wrong result and how someone would see it, and a findings freeze once the table is written. A table with no findings is a valid result.
What this history does not claim
The method was built by running it and recording what went wrong, one failure at a time. It was not designed in advance, it is not proven to work for everyone, and it does not change whether an AI makes mistakes. It gives mistakes a place to be seen.
Related
More from the journal
— Lizvo
General information only, not professional advice. See the disclaimers.