Preface

From One to Many

ShopBot was no longer answering queries. It was answering people.

That sentence had ended Book 3. By the time it was written, zUdyog Fashion's chatbot had served forty-eight thousand campaign-week queries at p50 latency of 277 milliseconds and ₹0.0148 per query. The system worked. The customers came back. The architecture, which had been a chain in Book 1 and a chain-with-branches in Book 2, had become a routed graph in Book 3 — and the graph held.

Three months later, the system was still one tenant.

That was the part of the Book 3 closing Krishna had let stand without comment but had not let stand without remembering. zUdyog Fashion was one boutique chain with five hundred products. The architecture they had built was — by every measure that mattered for one tenant — finished. By every measure that mattered for a business growing past one tenant, it had not started.

The Surat saree house Krishna had mentioned at the end of Book 1 had signed on in week one after the campaign. The Jaipur boutique with three hundred products had finished onboarding in week three. The national retailer with eleven thousand SKUs had completed a pilot in week six and signed for general availability in week eight. By the end of the third month, there were six tenants in the system. Some weeks the queries across all of them combined hit one hundred thousand in a single day.

The architecture that had been built for one tenant did not fail at six. It groaned in ways that, on a Tuesday morning in May, Arjun could no longer pretend not to hear.

The chai he had poured at six had cooled by the time the third tenant's dashboard finished loading. He did not lift it.

What he was reading on the dashboard that morning was not a system in trouble — every tenant was answering customers correctly, every latency target was being held — but it was a system that was, in ways he could feel before he could name, no longer the system he had built.

The Six Things That Had Changed Underneath

Six tenants in one Qdrant cluster meant six tenants' embeddings in one index. A query about a wedding saree from zUdyog Fashion in Bengaluru and a query about a wedding saree from the Surat saree house produced very similar embeddings. The retriever, asked to return the top three chunks for one of those queries, would happily return chunks from either tenant if the configuration did not stop it. Nobody had asked the configuration to stop it. The configuration was not stopping it. So far, by luck, no customer had received another tenant's product in their answer; the cross-encoder rerank had usually preferred the on-tenant chunks for irrelevant cross-tenant reasons. Luck was not a load-bearing piece of architecture.

A GDPR deletion request had arrived two weeks earlier from a customer in Frankfurt who had used the Jaipur boutique's chatbot. The request was reasonable, the regulation was clear, the architecture had no way to honour it. Delete this customer's data required knowing which customer's data was where — in chunks, in cached answers, in session state, in audit logs — and the system did not currently know. Arjun had answered the request by hand. He could not answer the next one by hand. He could not answer the hundredth.

The inference container that held the cross-encoder rerank service plus the INT8 embedder for zUdyog Fashion was 280 megabytes. Each tenant wanted, eventually, its own fine-tune of the embedder — a Surat-trained model would retrieve sarees more precisely than zUdyog's fashion-general model could. Six tenants meant six embedder models in six containers, or one orchestrator that loaded the right model per request. The architecture had been built around a single model loaded at container start. It was not yet built for six.

Vastralaya — Draupadi's twelve-boutique chain across Bhopal, Indore, Nagpur, Raipur, and Nashik — had a different shape of catalog. Her higher-end pieces were as much image as text. A customer asking do you have anything that looks like the saree my mother wore at my brother's wedding was asking a question the text-only embedding model from Book 1 Chapter 3 could not begin to answer. The text-only assumption had been correct for zUdyog. It was incorrect for Vastralaya, and Vastralaya was, by every measure Krishna cared about, the most important tenant in the system.

And on the call with Draupadi the previous Thursday, her operations head — a man named Sanjaya, who had filled half a notebook with single-line entries while saying almost nothing — had asked a single question that none of the other tenants had asked.

"If a customer files a complaint and a regulator asks why ShopBot recommended a product to them, can we tell them exactly which catalog chunks were retrieved, when, by which version of the model, and on which path through your graph?"

Arjun's honest answer was no. The system kept enough logs to debug failures the development team noticed. It did not keep enough to reconstruct, six months later, exactly what one customer had seen and why. Audit trails Sanjaya can inspect was the phrase Krishna had written in his notebook later that evening. The phrase had stayed there for a week before Arjun understood that it was, by itself, the fifth line on a whiteboard that had not yet been drawn.

What This Book Will Build

The five categories are different in kind from anything the previous three books addressed. Books 1 through 3 built a Pramana — an honest retriever, a Pramana that reaches, a Pramana that scales, a Pramana that grades itself by route. All three books had one tenant.

Book 4 is what happens when the Pramana has to become a fleet of Pramanas, each one valid for its own tenant, each one isolated from the others, each one auditable on its own terms, and each one able to honour the deletion requests, the compliance regimes, and the modalities the tenant's customers actually use.

The Pramana Framework, by the end of this book, will not only retrieve honestly and reach differently and grade itself by route. It will also know whose Pramana it is — because in a multi-tenant system the answer to what is true depends on which tenant is asking, and the answer to who is allowed to know depends on which jurisdiction the asking happens in.

The five lines on the whiteboard Krishna will write in the morning are not, this time, four architectural moves and a cost line. They are five different shapes of responsibility — and each one is what makes the system fit not just for the developer who built it but for the regulator who might one day inspect it, the customer who might one day ask for their data back, and the operations head who needs to know, exactly, what the system said and why.

This is the book about what happens when the Pramana stops being a property of the code and starts being a property the business has to defend in writing.

Chapter 1 — One Pramana, Six Tenants — opens with Draupadi and Sanjaya in the Bengaluru office on the Monday after the GDPR letter arrived. Krishna writes five lines on the whiteboard, and for the first time in four books, one of the lines was suggested by someone who is not Arjun and not Krishna.