The value is in the relationship

Allostatik gives you a working relationship with your AI that compounds — each session builds on the last instead of resetting with every conversation. It's a folder of plain files you own, plus the routines that keep them true. AI can hand one person the leverage that used to take a team — but only when it's integral to how you work. It has to see how you work, what you've decided, where things stand, and carry that across time; every decision it can't see, it will happily contradict. Out of the box it can't carry any of it in a form you control. Every window opens from zero, or from a summary you never wrote: you re-establish your preferences, re-derive your patterns, re-explain what you're building. Every time. If that cycle is familiar, this is for you, specifically — not for someone evaluating AI, for someone already deep in it. You've probably built the fix once already: a rules file. A , a Cursor rules file, a filled-in Project Instructions field. The instinct is exactly right — context you author, in plain text, where you can read every line. Now look at yours. It still says something you stopped believing three weeks ago. It's been steering every session since, and nothing told you. That's a config file: written once, wrong quietly. Nothing checks it for freshness, and it has no way to tell you a rule went wrong — a bad rule doesn't announce itself, it gets enforced, agreeably, until you notice the work bending. Allostatik is that rules file, grown into a control system, with you as the gate on every change. The rest of this is why that shape. Even the context you keep is being edited Resets are only half of it. Long conversations get compacted — a polite word for summarized by something that wasn't in the room when the decision was made. That edit you never see at all. Memory features synthesize what to keep about you — those you can read and prune, but you didn't write them, and neither editor asked what mattered. Call it the invisible hand: an editor you didn't hire, working on the one document you can least afford to have edited badly. Sometimes it drops something you'd have kept. Worse, it preserves a decision you already reversed. At its worst it infers one — takes an offhand remark for a standing preference and writes it down as a fact about you. The problem was never that AI has no context. It's that you don't control the part it has. Where the compounding comes from The routines run at the edges of every session, against files that live in your project — plan, decisions, observations, project instructions; one file, one job. Open: load the files, check every deployed copy against the canonical one, reconcile before work starts. Work: the files are the source of truth, and stale content gets flagged rather than followed. Close: update them, re-deploy, hand off with pointers instead of copies. Every session ends where the next one begins — that's the compounding. It's a rhythm, not a service: the files act only when your AI reads them, and nothing runs in the background. No process, no account. Why not just write three markdown files? You could. You should be asking that. The files aren't the invention — they're markdown, and you could write your own folder this afternoon. But you can't write a standard. The value of the convention is that it's the same one in your next project too. And the version you write will have the files and not the routines. Everyone builds the capture half; almost nobody builds the maintenance half — the close, where updating the record is the same act as ending the session, so it actually happens; and the drift-check, which compares what's canonical against what's actually deployed. That's where the living part comes in: capture writes the files once; maintenance is why they stay true. It's also the half that decays first, and the half with no error message. Write the files without it and you've built the rules file again. It will rot the same way. Files that live like this look different from files written once. These rows are from the of the project this post was written in (abridged, marked): Decision Choice Rationale Acceptance test: one actually-published artifact (s1) The layer is not working until it has produced one published piece. […] A layer built for extensibility with zero output is architecture masquerading as progress; this test is cheap, observable, and fails loudly. Publish before building the port (s2) The plan's sequence was inverted: item 4 (one published artifact) is being executed before item 1 (the canonical→derived port) […] Designing the port before deriving a piece once is guessing at requirements […] Canonical publishing surface is this repo (s1) [AMENDED 2026-08-21 — see "Canonical source vs canonical publication (s4)"] A published piece is a markdown file in comms; syndicated copies derive from it. […] POSSE's actual invariant is one canonical source you own with copies deriving from it […] Session numbers, an amendment where reality pushed back, the reasoning kept next to the choice. That's what a working relationship looks like on disk: not prose about the project — a record the next session opens from. What you get If you want to read exactly what your AI loads — it's files you own. Readable, versioned, portable. No account, no server, nothing lost when a subscription ends. If you want to know your context is still true — freshness is checked, not assumed. A cheap comparison runs at every session edge, canonical against deployed. Catching a one-line divergence at a boundary costs nothing. Building on one costs a lot. If you want the window spent on what matters — the window is a budget, not a bucket. A stale convention still sitting in context outvotes the new one you mentioned once. So files load by manifest, knowledge is pointed at rather than pasted, and each close distills the session to a few durable lines. If you want to switch tools without starting over — your context is the core; Claude Code, Cursor, Desktop are ways of reaching it. A new surface is one adapter, not a restart. If you want to stay in the loop — automate the mechanical, gate the meaningful. Nothing rewrites your files without your sign-off. If you want rules that evolve when they stop fitting — a thermostat is homeostatic: fixed target, corrects you back. Allostasis is when the target itself can move, because the right setpoint depends on the season. Stray from a principle once and the files correct you back; stray the same way repeatedly and it asks whether the principle is still right. That last one is the hard part. Ask a model cold whether one of your rules still fits and it has no grounds to answer; left alone, an AI is homeostatic by default, because correcting you back is the only move it can justify. What changes that is history it can reason over: three sessions of the same correction is evidence, one is noise — and it can only tell the difference if the record exists outside the conversation that produced it. None of the engineering is exotic. If you build software, you'll recognize the load-bearing conventions underneath — separation of concerns, don't-repeat-yourself, you-aren't-gonna-need-it, ports and adapters — applied to context instead of code. The rhythm underneath is MAPE-K — Monitor, Analyze, Plan, Execute, over a shared Knowledge base, a control loop from autonomic computing — run as ritual rather than software, with Execute gated on you. Which means it is not, strictly, autonomic anymore. That's the point. The name reads out of that loop: allostat + I + K, the interpretive human gate and the knowledge base. The name's derivation is in the repo's why.md; the fuller design reasoning in concepts.md. The trade Two minutes to install, another fifteen or so to get the files saying true things about your project, then a few minutes at each session edge. Weigh that against what the alternative already charges: an hour lost hunting an old conversation for where a decision got made, work r