Strategy as a Document — The Seventh Chapter

Chapter 6 — Strategy as a Document, Not as Code

We arrive at the insight that, more than any other, recurs in the story of those who have built RAG since 2023 as "the thing I wish I had understood from day one".

Traditional frameworks treat search strategy as Python code. Do you want, for technical catalogs, to search first by product code, then by keywords, then by semantic vectors, and only as a last resort generate the answer? Write a function. Do you want, for photo albums, to skip traditional semantic search altogether and rely on a specialized reranker for images? Write another function. Do you want, for corporate videos, to separate the audio from the visual track, transcribe them separately, treat them as distinct sources, and then recompose them in the final answer? Yet another function. Every type of content, every domain, every client ends up generating a branch of code that diverges from the others, to the point where modifying a strategy requires a software release, a code review, a test cycle, a deploy. The time between "I have an idea on how to improve search on technical manuals" and "the idea is in production" is measured in weeks. For every idea.

The alternative insight is simple to state and profound in its consequences: search strategy is not code. It’s a document. A JSON — a structured text format that any editor, with half an hour of training, can read — that says: "first try this, then that, if the first fails move to the third, rerank like this, respond with this model." This document lives in a database, not a repository. It is modified from an interface, not from a pull request. It is versioned, copied, and specialized by domain. A strategy for technical catalogs, one for photo albums, one for installation manuals, one for videos, one for audio, one for legal contracts, one for financial statements. All coexisting in the same system. All editable in real time.

Those who have worked with this approach – let's call it, without too much imagination, Meta-RAG – report a change in speed that goes beyond engineering. A typical customer request like "add a specific search for product codes containing acronyms like CMP40M or RH1M" is no longer a two-week development ticket. It's a new step added to a JSON procedure, hot-tested on a staging environment, promoted to production in an afternoon. The question "what changes if we use a different reranker for photos, keeping the current one for text?" is answered by modifying a line of configuration. The experiment costs nothing, the rollback costs nothing (simply restore the previous version of the document), and the accumulated knowledge – what works well for a certain type of content – becomes a versioned and transferable asset, not the tacit knowledge of whoever wrote that particular branch of code and is now on vacation.

There's also an interesting social effect that emerges in organizations that adopt this approach. With strategies as documents, the boundary between "developer" and "power user" shifts. A digital librarian, a corporate archivist, a domain expert — the head of the technical office, the documentation manager, the product manager who knows the customers' real questions better than anyone — can read a strategy, understand what it does, suggest changes, and sometimes write them directly. They don't have to go through the development ticket funnel, they don't have to explain things to a developer that the developer doesn't know (because it's not their job to know them). RAG stops being a product you consume and becomes a tool you model on your organizational knowledge. This, in the experience of those who have tried it, changes the morale of the project before even the numbers of the metrics.

It’s not magic, and it has its costs. You need an engine to execute these strategy-as-document approaches efficiently and securely. You need a description language rich enough to cover real-world cases, yet poor enough not to become another Turing-complete system in disguise. You need tools for versioning, testing, and rollback. But all of this is a problem for those building the engine — once, and for all users. The individual end customer only sees one thing: the ability to evolve their search strategy at the speed of thought, rather than at the speed of the software release cycle. And for those involved, this is a silent revolution that hasn't yet found its name in industry magazines.

Closure — Chapter seven, in a few months

At the beginning of 2026, adding up the lessons from the previous chapters — the tables that were lost, the lying rerankers, the inherited hallucinations, cloud bills growing faster than the value, promising but rigid frameworks — someone in Italy started building a different RAG server. Written in Python, designed to run on accessible hardware, capable of talking to cloud models when it makes sense and with local models when privacy requires it or the cost doesn't add up. A server where search strategies are editable documents, the reranker is a local process on GPU, tables are not lost because they are treated as first-class citizens, photos do not inherit objects from dusty archives of other eras, and the cost per query — both in money and in data exfiltrated to third parties — is known and controllable to the penny.

We won't name the project. This isn't the piece to do so, and we don't want to turn an investigation into an advertisement. But if the previous chapters have made you recognize a situation you're experiencing – a corporate chatbot confidently answering incorrect questions, a RAG project that hasn't taken off in months, a cloud bill growing faster than the utility it produces, a growing doubt that your confidential documents are traveling to places you don't know – then it's worth knowing that there is another path, one that has been taken by someone in Italy, and that in 2026 began to deliver the first answers that were expected in 2023.

The good news is that corporate AI is finally moving out of the demo phase. The less good news is that it's doing so carrying with it all the scars of the journey: bloated frameworks, provider dependencies, monolithic architectures, dirty data, silent bugs, and a certain tendency in the industry to sell solutions before even understanding the problem. We've told you about them in six chapters. The seventh – the story of what happens when someone finally does things right, with patience, in Italian and in open source – we will write soon, with less caution about names and more numbers on the table.

Meanwhile, if you've made it this far, you've already done more post-mortem analysis than 90% of the decision-makers who are currently signing a contract for a corporate chatbot without asking any of the questions you asked while reading these chapters. It's a better starting point than where they started. And in the coming months, the difference between those who asked these questions and those who didn't will become very visible on invoices — and on the answers your AI will give to your customers.

This investigation was drafted in April 2026, based on eighteen months of experience designing, building, and optimizing corporate RAG systems between the end of 2024 and the beginning of 2026.