Rekon

The fix starts with a description. Before I ask what a file is, I ask what it's for. Not "a route handler," but the outcome it owes: this keeps the wrong person out of an account and reports it when it turns someone away. Describe every part of a codebase that way, by the outcome it owes rather than the shape of its code, and something useful falls out. You get one vocabulary that holds across the whole repo, and across any repo, no matter who or what wrote the code.

That consistency is the point. Rekon reads whatever it finds, clean or sloppy, hand-written or generated, onto the same set of terms, so it understands any codebase in the same language. And because that language lives in artifacts rather than in the model's working memory, it doesn't evaporate when the session compacts, and it doesn't reset when you switch models. The agent's private understanding is gone the moment you change the model underneath it. What the codebase says it is stays put. And what it says attaches to the capability, not the file. A capability carries its own name and owner, so when an agent splits a file, moves it, or rewrites it from scratch, the outcome the code owes is unchanged and still tracked. What gets named was never the file.

It isn't only for the agent. A description clear enough for a model to act on is clear enough for a person. A senior developer landing in the repo for the first time can read what each part is for and reason about it in minutes, instead of paging through a thousand-line file reconstructing intent from the code. Legibility for the machine and legibility for the human are the same property, and naming things by purpose is how you get both.

Rekon is the substrate that holds that vocabulary and keeps it true. It's a local-first TypeScript CLI, and at its core it does one thing: evidence in, typed artifacts out.

You point it at a repo. It observes the code and writes evidence, facts about what's there, each carrying a pointer back to where it came from. Some of that evidence is read from the source. Some of it comes from watching the code run. Every piece is tagged with its origin and how far to trust it, so a guess inferred from static structure and a fact observed at runtime are never mistaken for each other. It projects models from that evidence: what owns what, how the pieces connect, where the seams are, and what each part is for. It evaluates those models against rules and records findings. It indexes all of it into one snapshot of what the repo currently is. None of it is invented. Each layer is derived from the one beneath it and carries a pointer back to it, and because the whole picture is generated rather than asserted, it tracks the repo instead of drifting from a copy of it.

The substrate obeys one rule: lower layers feed upper layers, and upper layers never quietly become lower-layer truth. Evidence feeds the models, the models and their findings feed the answers, and the answers feed whatever gets published. A generated document is a publication, not the truth. The truth is the artifact trail beneath it, and anything that comes out wrong can be traced to the input that made it wrong, regenerated, and replaced.

Because that picture exists, you can ask it a real question at the moment one matters. Before an edit, you resolve the specific question the change raises, and the agent can do the same through the same CLI. I'm about to change the auth module to fix token refresh. What owns this? What does it owe the rest of the system? What breaks if I get it wrong? Rekon answers with a packet that carries its reasoning trace, where every claim points back to the evidence behind it. That's the difference between a map and an answer. A document guesses every question in advance and goes stale the moment it's written. Resolution asks the real question against the repo as it is right now, with the receipts attached. Getting the agent to ask is a matter of instruction: Rekon keeps the agent's own AGENTS.md and CLAUDE.md current with the directive to resolve before it edits.

Naming what a file is for is also what lets you hold it to it. A capability contract binds a file, a cluster of files, or a critical path to the outcome it owes, and says nothing about how that outcome is reached. The implementation underneath stays free. It can be refactored, improved, or rewritten from scratch by an agent, as long as the outcome it owes still holds.

The contract doesn't check anything on its own. What it does is tie a named purpose to the proof that the purpose is still met: the regression tests that exercise it, the schema that validates the data crossing its boundary, and the runtime signals that show it actually happening in a running system. That binding is the part that matters, because the most dangerous rewrite isn't the one that fails a test. It's the one that takes the test with it. An agent reshaping the code can delete the assertion that covered a behavior, rename the signal that watched it, or move the path that exercised it, and everything still goes green, because the thing that would have failed is gone. The contract is what makes that disappearance visible. A named purpose with no live proof becomes a finding.

Not all proof is equal, and Rekon is careful about the difference. A claim drawn from the static structure is an inference, held at less than full confidence. A claim confirmed by what the code actually executed is an observed fact. Thinking a thing works and watching it work are different kinds of knowledge, and every capability is labeled by which one it has: claimed but never seen to run, seen to run but never claimed, or claimed and verified by its own execution. The gap between what the code says and what it does is where purpose drifts, so the system watches it directly. An import never called at runtime, a call with no matching import, a capability running under a name nobody declared: each is the static story disagreeing with the running system, and each becomes a finding, the kind a green test suite will never show you, because the suite only reads what the code claims.

So the failure I started with stops being invisible. The rewrite that compiles, types cleanly, and has quietly stopped doing its job now has somewhere to surface, because the purpose it dropped was named and the proof it dropped was required. None of this promises every rewrite is correct, and the system won't fake a certainty it doesn't have. Where it lacks the evidence to judge, it says so instead of waving the change through. What it does hold to is narrower and more useful: a dropped purpose shows up as failed or unverified, never as a silent green.

Protecting purpose through a single edit is a moment. Protecting it across a codebase over time is a loop, and Rekon closes it. The same snapshot that answers a question is under constant governance: rules run against the models and raise findings, and findings have a life of their own. They get filtered, grouped into issues so the same problem doesn't surface five times, and carried across runs as accepted, ignored, or resolved, so the system isn't relitigating settled questions on every pass.

When something needs to change, the loop turns findings into work. Rekon writes a work order with the change to make and a verification plan with the checks that would prove it done, then runs those checks and records the outcome as its own artifact. Proof is something the system holds, not something you assert. What the team learns along the way, the corrections an operator makes and the preferences that turn out to matter, becomes memory that sharpens the next answer without rewriting the ownership, the rules, or the findings beneath it. And when a change is accepted, reconciliation applies it through explicit, permissioned steps, never a silent rewrite of your source.

Every one of those, evidence, models, findings, answers, publications, work orders, proof, memory, reconciliation, is an artifact with provenance, and every one can be inspected, regenerated, and replaced. That's what keeps a codebase coherent while it changes. Not a freeze on change, but a system that knows at every layer what the code is for and whether it still does it.

I built Rekon because the constraint in AI-assisted work has moved. The hard part is no longer writing code, or even changing it. The hard part is keeping a codebase coherent while it changes faster than anyone can hold in their head. The leverage over the next few years won't come from smarter models. It'll come from giving them, and us, a durable and shared understanding of what the code is for, so that purpose survives the speed.

That's a designer's problem as much as an engineer's. A system is only as good as the intent it preserves, and intent is the first thing lost when nobody writes it down. Rekon writes it down, in language a person and a model can both read, and holds the code to it. The code can change however it needs to. What it's for doesn't have to.

Rekon is open source, at https://github.com/drewlittrell/rekon