Make the system legible
What writing an explainer and building a useful dashboard have in common.
IFinding the information is part of the work
A price on a dashboard needs a date. A map needs a key. An explanation needs to tell the reader why a particular detail matters. These seem like small requirements until someone has to make a decision from what is on the screen.
That is the connection between the different projects on this site. The essays work through an argument; the interactive explainers let a reader explore its parts. Sanjaya, my public dashboard for Indian oil and gas, brings related information together so that people can examine it. In each case, I am trying to make a complicated subject easier to understand and use.
I use “legible” in that practical sense. Can someone find the information they need, understand what it means, and see enough of its source and limits to decide what to do with it?
IIInformation can be available and still be difficult to use
Consider someone preparing a briefing from a monthly report, a company filing, a spreadsheet, and yesterday's news. Each source may be perfectly useful on its own. Putting them together requires a different kind of work: checking periods and definitions, deciding which figures can be compared, and finding out whether an apparent change is significant.
People who know a subject well often do this almost automatically. Their colleagues rely on that judgement, including knowledge that may never have been written down. The difficulty becomes obvious when the expert is unavailable or a new person has to prepare the same briefing.
A useful tool should make some of those connections visible. It can show the observation date beside the figure, explain a category, or keep a link to the underlying document. It should also leave a gap when the information is unavailable. A complete-looking chart is a poor substitute for an honest one.
IIIWriting and design meet in the order of things
When I write an explainer, I have to decide what the reader needs first. A term may need defining before an argument can proceed. A comparison may explain more than another paragraph. Some detail belongs in the main account; some can wait until the reader asks for it.
A dashboard poses similar questions. Which view helps someone get their bearings? What should a click reveal? Can a chart be understood without a separate explanation? Where does a source link become useful?
The AI stack explainer is one way of working through that problem. It divides a large subject into layers that a reader can open separately, from applications down to chips and power. The arrangement is a simplification, but it gives the reader somewhere to begin and a way to investigate the connections.
IVWhat I am trying with Sanjaya
Indian oil and gas information appears across ministry publications, petroleum statistics, company disclosures, market data, and regulatory documents. Someone following the sector may need several of these sources to understand a single question.
Sanjaya brings market prices, fuel prices, infrastructure, trade, monthly volumes, and listed companies into one dashboard. The sections retain their observation dates and source links because the data arrives on different schedules. A market price and a monthly supply figure should not look as though they describe the same moment.
The aim is to reduce the work of assembling that first picture. A journalist, researcher, or interested reader should be able to find a series, understand what it covers, and follow it back to the source. Whether the dashboard does that well depends on those ordinary details: labels, dates, comparisons, navigation, and what happens when data is missing.
VConnecting AI to an existing system
An earlier project explored a related question in personal budgeting. The YNAB MCP Server, which is now archived and no longer offered, connected an AI assistant to the budgeting service YNAB. MCP, or Model Context Protocol, provides a way for an assistant to use external tools and data.
The useful starting point was the person's existing budget: their categories, balances, and transactions. An assistant working with those records can answer a more specific question than one given only a general description of the person's finances.
Access to records also creates responsibilities. The tool has to distinguish reading from changing something, make its permissions understandable, and give the person a way to check a proposed action. Clear explanation matters as much when the system takes action as when it displays information.
VIWhere this could help
There is room for this kind of work in Indian institutions whose knowledge is spread across documents, procedures, and experienced staff. The useful project will depend on the institution. It might be a way to find the latest approved guidance, compare reports on the same basis, or prepare a brief that keeps its sources attached.
Building it begins with understanding the work people already do. Which questions recur? Which terms cause confusion? What must remain private? Who is responsible for a decision, and what would they need to check before taking it?
Those questions are what draw my communications work and software projects together. I want the writing to explain a subject clearly and the tools to help someone use that understanding. The measure is whether a reader can find their way through the material and leave better equipped for the task they came to do.