# The Rules That Keep AI Honest Outgrew the Context Window *Researchers fix models, engineers ship product, and the fresh content that governs AI grows faster than either side's tools assume. A year in the void in the middle.* > If your AI followed the rules while they fit on one page and lost the thread once they became a folder, you have already met the problem I spent 2026 inside. There are two kinds of people working on AI right now, taking two different approaches. The researchers are solving model problems. The engineers are using the models to ship product. I am on the product-engineering side, but I have spent 2026 obsessed with the void between the two, where the rules that make an AI trustworthy actually live, and where I watched those rules outgrow any context window within a year of adding a few partners. Rewriting everything to one convention worked and nobody adopted it. Pre-compiled context packs worked and became a maintenance nightmare. What held was smaller than I expected: a thin pointer to what to read and in what order, and the admission that trust with an AI, like trust with a colleague, is not one thing. It is built differently while you explore, plan, execute and validate, and it has to be measured that way. I do not claim that is universal. It is what leading human and AI teams has shown me. --- ## Summary — The Rules Outgrew the Window, and That Problem Falls Between Two Approaches If you have worked with AI seriously for more than a few months, you have felt this. The AI behaved when your instructions fit on one page. Then the page became a folder. Then a second project shared half the folder and overrode the other half. Then a partner organization brought its own rules, which inherited some of yours and contradicted others. Somewhere in there the AI started sounding confident about rules it had never read, and you went back to checking everything by hand. That is the problem I have been living inside since January 2026. The researchers and the product engineers are taking different approaches to it, and each approach has bright spots that clearly work. I am on the product-engineering side of that line, solving product-engineering problems, but the place I keep looking is the gap between the two: taking the bright spots from each and trying to apply them in a broader, more abstract way than either side needs for its own purposes. This essay is about what I found there. The short version: governance for AI is fractal and it compounds faster than any context, embedding or training run can keep up; the two approaches I tried first both worked and both failed for reasons that had nothing to do with the model; what survived was a small discipline rather than a big system, and a record that keeps its receipts; and the thing we call "AI trust" is at least four things, because trust during exploration is built differently from trust during validation. Why trust is the hinge at all is already written down in [the trust kernel](https://klappy.dev/page/canon/values/trust-kernel): collaboration hangs on trust, and trust is built by managing expectations. I am not going to restate it. I am going to tell you what it cost me to learn where the expectations actually live. --- ## When I Explain This, People Stare: It Is Still a Research Question, Not a Product When I explain this to people at the organizations I work with, they stare at me. They are interested; they just do not know what to do with it. They cannot see how to productize it, and they cannot see how to leverage it inside what they already run. I keep wanting to make it a product. And every time I try, the honest answer comes back the same: this is still a research project. It does not yet know its own shape. I said that out loud on October 7, 2026, on a call with a collaborator who works on the product side of the fence. Once it was said, I could stop describing the thing as a feature and start describing it as a question. So here is the question. How can we trust an AI to keep up with the rate of change of fresh content being created? How does it navigate content that is ever-changing, ever-populating, and has never been read before? If that sounds abstract, let me show you where it came from. --- ## The Rules Outgrew the Context Window Within a Year, and Every Kind of Fresh Content Does the Same Think about where governance lives in your own life. There are universal rules, then country rules, state, city, the HOA, the rules in your own house. At work there are company rules, department rules, rules for a vertical, rules a partner insists on. Every layer inherits from the one above and overrides some of it. Everything is fractally spread out. Now hand all of that to an AI and ask it to behave. This is what I wrote on October 7, trying to pin the thesis down: > "Basically for me to get AI to work for me and my organizations and the companies that I work with, the content has ballooned. The more people I work with, the more complexity, but we keep sharing parts of it and there's inheritance. But when you do that, there's just too much content to fit into any one context very quickly. Like within a year of just a few partners, the governance has far exceeded the amount that would fit inside of a session, let alone work well." Let me be precise about the tense, because [a status that cannot be placed in time is not a status](https://klappy.dev/page/writings/what-was-what-is-what-will-be). That was true by the fall of 2026, after roughly a year of partners. It was not true in mid-2025, when the whole problem was one project's growing pile of markdown files. The window did not shrink. The rules grew, and they grew by sharing and inheriting, which is exactly how rules grow between humans too. My working theory, and I hold it as a theory, is that this is the shape of the next decade. Most content people create from here on will be second brains, knowledge bases, the accumulated rules and context of teams and organizations. That content will be created faster than anyone can train a model on it, and faster than anyone can embed it. "Just put it in a RAG system" is the reflex, and it is a reasonable reflex when the content holds still. The strongest form of that answer is incremental indexing, re-embedding only what changed, and for content that changes daily it is a fine answer. I know, because I did exactly that, and I abandoned traditional RAG in late 2025 when it could not keep up with the rate at which my files were changing. The content I am describing does not hold still that long. By the time it is indexed, it has moved, and the index carries no record of which version of the rule it indexed. If a partner's rules ever settled back into one window after a year of sharing, I would have to retract the theory. So far they have not. Governance is the example I live in, but it is only one. Social media, email, messages, the notes a team leaves for itself: the kinds of fresh content that grow faster than they can be indexed are endless, and every one of them has the same shape. I think that is where the research turns from a personal itch into a prerequisite. The more people want local AI, and the more they want sovereignty over their own data instead of shipping it to someone else's index, the more they need tools that can read what they have, as it is, the moment it changes. You cannot promise comprehensive coverage of a person's own content without that. So the tools I went looking for had a strange constraint: no embeddings, no training, nearly deterministic, close to instant, and able to map content they had never seen before. Blazing fast ways to read fractals. That constraint is not where the industry is pointed, which is the first sign you are standing in a gap. --- ## What Failed and What Survived: Compiled Packs, oddkit's Convention, Cartographer's Map, and the Manifest Sidecar I did not arrive at that constraint by thinking. I arrived by failing, in public, with my own tools, more than once. The itch is older than 2026. By mid-2025 I had what most teams have now: one project with a growing pile of plain markdown files documenting it, and the expectation that the AI would read them and use them for everything it did. Solving that for one project is hard enough. I wanted to solve it for all of my projects at once, so that the next one never started from scratch. Models and harnesses have come a long way since then, and the across-projects part turned out to be ordinary architecture and engineering. The part that did not turn out to be ordinary is what the rest of this section is about. The first failure was before oddkit existed, back in January 2026, and it is where oddkit came from. The rules were already too big to read every time, so I compiled them: pre-packaged context packs meant to spare the model from reading everything. They worked, right up until the rules changed, and then the pack was lying until somebody rebuilt it. So I automated the compilation, rebuilding the pack on every change. That worked too, and it was slow, and the changes kept coming faster than the compile could keep up. Underneath the speed problem was a worse one: a pack is compiled for a purpose, and I could not predict every purpose a session would show up with. There were too many variations to build ahead of time. So the packs got small and stackable, parts that composed into whatever a task needed, and once the parts were small enough the natural next step was obvious: stop compiling ahead of time at all, and compose at the moment of reading, from live source, for the task actually at hand. That is what oddkit is. For most of 2026 oddkit has been the progressive-disclosure tool I use for all of my own governance: an agent reads a title, then a compressed argument, then a summary, then only the section it needs, and the full body last if ever, stopping as soon as it has enough to act. It works. It works really well, with one condition I underestimated. > "Oddkit requires a convention, a strict convention for it to work optimally. Yes, it can work without it, but it's not as optimal. I can't get anybody other than myself to adopt Oddkit. How am I going to expect that to be a standard for people to use?" Every document had to be reshaped to the convention before the ladder could be walked. I did that to my own knowledge base, hundreds of documents, and the result was worth it. Then I looked at the partners whose rules were now part of mine, and I knew with near certainty that none of them would ever rewrite their ontology to my template. Good discipline and good conventions work. I have the receipts. They also demand rework and maintenance that nobody else is going to sign up for, and a tool only I can use is a hobby. So the second thing was Cartographer: what if the tool were agnostic, a walker that could move through anybody's governance as it already is, no rewrite required? The idea was an agent that does not know what to search for but knows what it has been asked to do. It boards with nothing but a short framing, finds the right repositories and the right files, pulls in only the pieces it needs, and leaves itself a note that says, roughly, if I hit something in this category later, come back here. Dynamic walking, because a hard-coded map of everything is too expensive to maintain and drifts the day after you draw it. What fell out of testing the walker was not what I was building. It was the thing I had been circling for the better part of a year. > "What shook out of it during testing for Cartographer and the Walker for boarding was actually pretty powerful and really good hygiene and good discipline to shake out and shape out good definitions of what should be walked and when." A manifest. A sidecar to the content rather than a rewrite of it: a short list of what to read, in what order, plus a few lines of framing, handed to the agent at [boarding](https://klappy.dev/page/canon/bootstrap/any-seat-boarding-recipe). Go do your research, here is the pointer. Not a distillation. I want to be clear about that because the compilation packs above were distillation, and the lesson of the packs was that every time the rules moved the pack lied. The pointer does not lie, because it points at the live source. I am not going to describe how the pointer is built here. That part is still being measured, and the numbers belong on the ledger with their caveats, not in an essay. What I will say is that there were somewhere around a hundred experiments between January and October 2026 attacking this same problem again and again, across every epoch of the knowledge base, and many of them are failures worth citing: context cramming, context shaping, context engineering under several names. Each one worked until the content moved. The small thing is the one that survived the content moving. One of those failures deserves its own paragraph, because it is where the bright-spot habit, [borrow before you build](https://klappy.dev/page/canon/constraints/borrow-evaluation-before-implementation), paid for itself. Early on I was fairly sure the map would end up being generated: a small model running beside the main session, reading the repositories and folding what it found into a compact table of claims, each row a short statement with where it came from and how sure it was, that the main session could then read instead of the raw files. It is an attractive idea, and I had built the pieces for it. What disconfirmed it was looking harder at the tools that already worked. The coding agents I use every day are startlingly good at finding their way around a codebase they have never seen, and the reason is not clever: they list, they grep, they open the file, in a loop, and the tools underneath are the cheap deterministic ones that have shipped with every command line for decades. Paired with ordinary ranked text search, the same primitives found their way around governance just as well, for a cost that rounds to zero, with no model in the loop to drift or hallucinate the map. The generated map lost to that baseline. Note what did not lose: the manifest sidecar from a few paragraphs up is a different animal. It never tried to be the map. It is a hand-kept pointer, a few lines saying what to read first and in what order, sitting beside the content and leaning on the same cheap primitives to do the walking. The thing that failed was a model generating the map; the thing that survived was a human-sized hint that lets deterministic tools find the rest. So the rule I now hold is: the list-and-grep layer is the floor, everything else has to earn its place on top of it, and when a cheap deterministic approach is good enough, the expensive one has to prove it is better, not assume it. That is a working rule from my own runs, and the run numbers belong on the ledger, not here; I would revise it the day a generated map beats the floor on the same questions at the same cost. These tools assume a command line, and most of the places governance lives do not have one. That is the gap. --- ## The Record Has to Survive the Session: Kirigami Turned the Journal Into a Flight Recorder With Provenance and Resumability Reading was only half of it. The other half was the record, and I underrated it for longer. Everything above is about getting the right rules in front of an AI. Nothing above says what happens to what the AI and I decided once the session ends. In early 2026 the answer was: it evaporated, or it lived in a chat transcript nobody would ever open again, or it lived in a tidy summary that quietly dropped the one caveat that mattered. Then something would go wrong and nobody could say where. That is an expectations failure of the oldest kind, and [the trust kernel](https://klappy.dev/page/canon/values/trust-kernel) names it: expectations not maintained, not transferred. So [the journal](https://klappy.dev/page/writings/the-project-journal) became the flight recorder. Not prose. Rows. Every session leaves rows, and every row carries the same twelve fields, and four of them do the work: who contributed it, what kind of claim it is, how confident, and the relationships that tie it to the rows and sources it rests on. A dictation I gave on a walk, a ruling I made in a chat, a run a seat finished at three in the morning, all land in the same shape, and the shape is what makes them comparable later. The tool that folds raw material into those rows is called Kirigami, and it was not built for this. It was Cartographer's predecessor, an earlier attempt at the map, and I put it on ice when that attempt lost. Then it turned out to be exactly the right shape for something else: recording a turn-by-turn synthesis of each session in a form we could debrief, run a post-mortem on, and trace a failure back to its cause. Something like git blame for models. It has saved me countless hours of rework, because when a session goes wrong we can reliably see where. It also turned out to be a good way to harvest meeting transcripts and brain dumps, which nobody planned either, and that one changed how I work. Most of the direction for my system now comes from car rides and a two-to-three-hour run once a week, where I clear my head and talk. The system takes those recordings and pulls out, in a structured way, the [concepts, decisions, observations, learnings, constraints, handoffs, encodings and tensions](https://klappy.dev/page/canon/definitions/dolcheo-vocabulary) in them, and then runs derivative passes over that record to iterate the governance itself. That is how a single maintainer has produced well over a thousand governance artifacts in less than a year without typing most of them. There is one more bonus, and it matters more every month. Because the journal is the durable stream of the work rather than a transcript of it, anything that dies mid-task can be resumed from it: by any agent, on any account, in any harness, with any model. The rows carry what was decided and where things stood, without the bloat of the conversation that produced them. When a session dies, the next one picks up where the last row left off. Two of its rules matter more than its name. Folding is lossy on purpose, but discarding is not deleting: every row keeps a pointer back to the cold source it was cut from, so a claim can always be traced to the moment it was made. And synthesis is connective, never generative: a row may wire together things that already exist, and it is not allowed to invent a connection and call it a finding. That is the pattern with most of the failures on this list. They solved adjacent problems I had not set out to solve, and each time the system got better for it. This is why I can write "I said this on October 7" and mean it. The provenance block on this essay names the three dictations it was built from and the typed text it quotes. The ledger keeps the numbers I am not putting here. When the thing you are trusting is the record of a collaboration that is now months old and spread across many sessions and more than one partner, provenance is the only way the expectation you set back then is still checkable now. --- ## AI Trust Is Four Things, Not One: Exploration, Planning, Execution and Validation Each Earn It Differently Somewhere in those experiments the question changed on me. I had started out trying to validate AI work, which is where everyone starts. Can I trust the output? And I kept noticing that this was not how I trusted the people I work with. Think about a colleague you trust. Do you validate every one of their outputs? I do not. I expect to validate some, and I still find value in the rest, and I still trust the person. The trust was earned somewhere else: in the experience of exploring a problem with them, in watching how they plan, in how they tell me what they did and did not do. Output checking is one source of trust. It is not the only one, and for a good colleague it is not even the main one. That is why I think we have been measuring AI trust in too few places. In my own work there are four distinct modes a team gets into to produce anything, whether the thing is a scientific experiment, a product, or a piece of writing: exploration, planning, execution, validation. I did not invent them; they are already the spine of [the operating contract](https://klappy.dev/page/canon/bootstrap/model-operating-contract) every AI session in my system boards under, and that document says what each mode is for better than I will here. What I am adding is narrower. Each mode behaves differently, and trust in each mode is built and broken differently. > "I think AI trust pivots on evaluating the different steps differently because exploring an idea behaves differently than validating that something was done well." An AI that invents a possibility during exploration has done its job. The same invention during execution is a hallucination. A question in planning is diligence; the same question mid-execution is [a tax on my attention](https://klappy.dev/page/canon/constraints/mode-discipline-and-bottleneck-respect), the one resource that [does not scale with the tooling](https://klappy.dev/page/writings/your-context-window-needs-a-sabbath). A confident claim during validation is worth nothing until it carries evidence, checked by [someone other than the one who made the thing](https://klappy.dev/page/writings/the-same-rules-fresh-eyes); the same confident claim during exploration is just a candidate. If we measure all four with one yardstick, we end up either trusting a model that should have been checked or babysitting one that should have been left alone. I want to be careful here, in the same words I used on October 7: > "I don't want to claim this is universal, but I do believe in my experience, these are the four areas or modes that I've had to focus AI to operate differently in. And so any evaluation or metrics we would do when evaluating AI trust is evaluated differently for each of these modes." If your work has a fifth mode, or three, I would like to hear it. The claim I will defend is the smaller one: trust is not one number, and anyone selling you a single "AI trust score" has already collapsed something that should stay separate. --- ## The Void in the Middle: Researchers Fix Models, Engineers Ship Product, the Gap Between Them Is Where I Work Here is where I think I actually am, as of October 2026. On one side there are the AI scientists, the people doing real research on models. They are solving model problems, and the pace of that work is too slow for the problem I have. By the time a model change lands, my partners' rules have moved again. On the other side there are the engineers using the models to ship product, and that is my side; I have been one of them for most of my career. We are fast, and most of the time a bigger prompt and a vector store will get the product out the door, so the question of where the rules live rarely gets asked on its own. These two groups speak different languages, and they are taking different approaches. I am obsessed with the void in the middle. It is where governance has to be navigated rather than memorized, where trust has to be earned in four modes rather than scored once, and where the content keeps changing faster than either side's tools assume. I do not have the patience for pure research. What I do have is a product-engineering problem that the product side's usual answers stopped solving, and a habit of looking at the bright spots on both sides, the things that visibly work, and asking whether they can be applied more broadly and more abstractly than either side built them for. The only reason this gap holds my attention is that every experiment, including the failed ones, has been proving the gap is real. --- ## What I Am Asking You: Find Where Your Own Rules Outgrew the Window, and Start From the Kernel If you are the reader I have in mind, you already have a version of this problem, and you have probably been treating it as a prompt-engineering chore. I would ask you to look at it differently for a week. Where do your rules actually live right now, and how many of them does your AI read before it acts? When the rules moved last, who updated the summary the AI was reading, and how long was the summary wrong before anyone noticed? And when you say you trust or do not trust your AI, which mode were you in when the trust broke? If you have wondered why this site went quiet for most of 2026, this is half the answer. I was in the gap, running the experiments above instead of writing them up, which is its own small failure of [learning in the open](https://klappy.dev/page/writings/learning-in-the-open). The other half is the kitchen that grew up around them, the seats and rails and cookbooks that turned one maintainer into a crew, and that evolution is the next thing worth writing about. I do not have a product for you. As of today I have a research question, a pile of documented failures, a small discipline that has held up so far, and a way of splitting trust into four that I measure separately and do not claim is universal. If any of that is useful, [the kernel it hangs on](https://klappy.dev/page/canon/values/trust-kernel) is public and short, and [the contract that defines the four modes](https://klappy.dev/page/canon/bootstrap/model-operating-contract) is public too. Start there. Then write down where your own rules outgrew the window, because that is the moment the void opened under you, and it is the moment the usual tools look past.