Make the system legible

IThe through-line

The easiest way to misread this site is to think it is about several unrelated things: AI explainers, a budgeting MCP, essays on institutional adaptation, a public intelligence portal for Indian oil and gas.

It is really about one thing. I am trying to make complicated systems legible to the people who have to act inside them.

That is the through-line between the essays, the explainers, the tools, and Sanjaya. The subject changes. The actual job does not.

IIThe real scarcity is not information

Most serious institutions do not suffer from a total lack of information. They suffer from a lack of coherent surfaces.

The data exists somewhere. The PDF exists somewhere. The internal note exists somewhere. The person who understands the whole picture exists somewhere. What does not exist is a usable command surface that lets another person see the system in one place and understand what matters first.

So the daily reality becomes printouts, stitched-together spreadsheets, fragmented terminals, screenshots in messaging groups, or a senior person who carries the system in his head and then verbally compresses it for everyone else.

That works, until it doesn't. It works until the person is unavailable, the context is lost, the meeting is in fifteen minutes, or the outsider who needs to understand the system has no way in.

IIIGood explanation and good product work are closer than people think

People often treat writing and product-building as separate disciplines. I think that is mostly wrong for this class of work.

A good explainer and a good dashboard are trying to solve the same problem. Both have to answer: what should the user see first, what can be deferred, what terms need translating, what comparisons actually help, what sequence gets the user from confusion to action.

That is why I do not think of the explainers on this site as side content. They are interface work. They are prototypes for how a person should move through an unfamiliar system. The essays are where I test the argument. The explainers are where I test the structure of understanding.

IVWhat Sanjaya is actually testing

Sanjaya is not really a petrol-price website. It is a test of whether a public intelligence product can do for a sector what institutions usually do with private briefing packs and expensive terminals.

The Indian oil and gas sector has enormous amounts of information scattered across public disclosures, monthly petroleum tables, company filings, PNGRB orders, stock-market data, ministry updates, and the mental models of people who work in the system. What it does not have is one coherent public portal that says: here is how the system fits together; here are the important assets; here are the companies; here is how retail pricing works; here is what changed; here is why it matters.

That is the bet in Sanjaya. Not that one public dashboard can replace every specialised source. It cannot. The bet is that a well-built command surface can drastically lower the cost of understanding the system for journalists, researchers, market watchers, and even insiders who are tired of assembling the same morning picture from scratch.

VWhat the MCP tools are actually testing

The same logic shows up in the tools. The YNAB MCP Server is not valuable because it turns a language model loose on budgeting in the abstract. It is valuable because it connects the model to an actual system a person already uses and cares about.

The point is not generic intelligence. The point is legibility over a real substrate: your own categories, your own balances, your own spending history, your own budget mechanics. The wrapper is the product because the wrapper is what turns a vague capability into a usable surface over a real system.

This is also why I am interested in MCPs more broadly. They are one of the cleanest ways to test whether AI becomes more useful when it can sit on top of real systems instead of pretending the system does not exist.

VIWhy this matters in India

India has a particular abundance of expert systems that are poorly surfaced. Institutions are full of tacit knowledge, procedural knowledge, fragmented documents, and people who have built internal mental maps over years. The outside of those institutions often sees almost none of that structure.

That gap is a public problem and a product opportunity at the same time.

It is a public problem because sectors become harder to understand than they need to be. Journalists write around the system instead of through it. Researchers waste time on assembly instead of analysis. Citizens get narratives without mechanisms. Decision-makers rely on compression from subordinates because there is no better shared surface.

It is a product opportunity because many of these systems do not need magical new intelligence. They need a better command surface: cleaner structure, better retrieval, clearer explanations, better pathways through the data, and interfaces designed for the actual questions people ask.

VIIBuild the command surface

If I had to compress the product thesis of this site into one instruction, it would be this: build the command surface.

Not another pile of raw data. Not another newsletter that paraphrases other newsletters. Not another app that assumes the user already knows how the system works. Build the surface that makes the system navigable.

Sometimes that surface is a dashboard. Sometimes it is an explainer. Sometimes it is a connector that puts a model on top of a personal system. Sometimes it is a briefing that compresses the day into one page. The format is secondary. The command surface is the thing.

VIIIWhat this site becomes

That is why Products now sits alongside the essays and the explainers. The writing is the argument. The products are the proof.

The site I want to build over time is not a blog with some projects attached. It is a parent brand for explaining hard systems clearly and shipping products around that clarity. The essays tell you how I think. The explainers show how I structure understanding. The tools and products test whether that structure actually helps someone do something real.

If the work is any good, the family resemblance between those layers should become obvious. The subject matter may vary. The underlying move should remain the same.

Make the system legible. Then build from there.