SR-SI: the methodology for AI that maintains context across a full product build

SR-SI is not a prompting technique. It is a context architecture for keeping AI coherent across a real product build.

In February 2026, I published the second version of the SR-SI research paper after months of using AI as the primary development collaborator across products such as Protocol, Gestalt, Neon Oracle, and Sila. The paper documents the problem I kept running into, the architecture that solved it, and the limits of what that architecture can honestly claim.

This is the accessible version of that work. The full paper and methodology material are available through the design-system AI pipeline resource.

The problem the methodology solves

Building with AI over an extended period produces a failure that most teams encounter and misdiagnose.

The early sessions feel coherent. The model understands the feature, the product language, the constraints, and the reason certain options have already been ruled out. A few weeks later, the output is still technically competent, but it starts to feel less specific. It remembers the task in front of it, not the product it belongs to.

Most teams respond by adding more context to the prompt: longer briefs, fuller instructions, larger examples, and more documents pasted into the same working window. That helps for a while, but it does not fix the architecture; it only makes the next prompt heavier.

The real problem is not prompt quality. It is the absence of a persistent structure for maintaining what the AI needs to know across sessions.

What SR-SI is

SR-SI stands for Simulated Recall via Shallow Indexing.

The name is literal. Instead of loading the AI with everything it might need, the system maintains a shallow, navigable index of what matters: decisions, constraints, terminology, priorities, known failure modes, and the specific parts of the system that should be consulted before work begins.

That matters because comprehensiveness and usefulness are not the same thing. A full archive can store everything and still fail to orient the work. A shallow index works because it tells the AI where to look and what to reconstruct for the task at hand.

The index is not a complete PRD, a full product spec, or a documentation dump. It is lean by design. At the start of a working session, the relevant slice of the index is surfaced, not the whole history of the project. That is the simulated recall mechanism: retrieve what matters now, then work from that recovered context.

What it produces

The measured work behind the paper showed an 85.5 percent reduction in net context-maintenance overhead, plus later modular findings that improved token coherence substantially as the index architecture matured. I care about that number less as a trophy metric than as a practical signal: the system reduced the amount of human energy spent reminding the AI where it was.

The practical meaning is simpler than the metric. Sessions that used to begin with re-explaining the product could begin with the work. The AI still needed direction, review, and judgment, but it did not need the entire project reintroduced every time.

Output quality also became more stable. The usual degradation pattern, where AI is sharp early and generic later, did not appear in the same way when the index was maintained. The model’s understanding of the product did not live inside a single conversation window; it lived in the external structure the model was forced to consult.

That same logic becomes more interesting at team level. When a shared index exists, the developer who has been on the product for a year and the developer who joined last month can start from a more comparable context base. The quality of AI output depends less on one person’s ability to brief well, and more on whether the team has built a usable context architecture.

Why this matters beyond individual productivity

The larger implication is not that one person can work faster with AI, although that is true. The larger implication is that product knowledge can be externalized in a way that both people and AI can use.

What does that look like in a team? Founding teams carry decisions implicitly, new hires inherit tickets without the reasoning, and AI inherits whichever slice of the product someone remembered to explain that day. The result is a system where knowledge exists, but it does not reliably move.

SR-SI gives that knowledge a structure. The decisions, constraints, naming logic, rejected paths, and unresolved tensions become part of an operating memory rather than a private understanding trapped inside a few people.

That is why I treat SR-SI as a methodology for AI workflow architecture, not a trick for better prompts. The goal is not to make the model sound more informed for one session; the goal is to make the product context reconstructable across the full lifespan of the work.

The AI Integration Workshop builds the foundation layer of that architecture with teams that already use AI, but still lack a shared workflow for making it consistent.