India AI is a decision-intelligence problem

IBegin with the decision

Consider a briefing for a sector review. The person preparing it has to establish what changed, check the figures, explain the implications, and identify anything that requires a decision. An AI-generated summary may help, but its usefulness depends on how well it supports that work.

Was the latest source used? Are the figures comparable? Does the summary distinguish a reported fact from an inference? Can the reviewer trace a claim without starting the research again? These questions determine whether the brief can be used.

That is what I mean by decision intelligence: helping someone assemble and understand the evidence needed for a particular decision. It gives us a practical way to judge AI projects in government and other public institutions, alongside the necessary discussion about models, computing capacity, and investment.

IIWork already has a structure

Institutional decisions usually pass through established documents and responsibilities. A note may require supporting annexures. A proposal may need consultation with another department. A figure may have an approved source, and a draft may be confidential even when the subject itself is public.

Those requirements shape what an AI tool can usefully do. A fast answer is of limited help if nobody can establish where it came from or who should review it. A drafting tool must fit the language and purpose of the document while preserving the evidence on which it rests.

India's public institutions differ considerably in their work and technical capacity. A system for a ministry's policy team may have little in common with one used at a hospital or a local authority. The design has to account for the people, records, languages, and review process of the place where it will be used.

IIIWhat the tool needs to make visible

A useful system should make it easy to see the evidence behind an answer. That can mean showing a source document beside a summary, retaining the date of a figure, or distinguishing a confirmed fact from an estimate. Where sources disagree, the disagreement belongs in the explanation.

It also needs to respect authority. Finding information, drafting a note, recommending an action, and carrying it out are different tasks. A person should be able to understand what the tool has done and what still requires a decision.

These are design and operating questions as well as technical ones. Retrieval determines which material reaches the model. The interface determines whether the reviewer can examine it. Permissions determine what the system can access or change. Together, those choices affect how much confidence someone can reasonably place in the result.

IVWhy I started with energy

Oil and gas offers a useful subject for this work because its information is closely connected. A change in crude prices can prompt questions about refining, imports, taxation, and retail prices. Infrastructure and shipping matter alongside market figures, while the relevant public sources update at different intervals.

I built Sanjaya as a public dashboard for exploring those connections. It brings dated market series, fuel prices, infrastructure, trade, petroleum volumes, and company data together. The aim is to help a reader form an initial picture and then inspect the underlying sources.

Sanket, an earlier cyber-risk project, explores another part of the sector. It brings public reports and illustrative energy-sector scenarios together with a browser security check. Its public information and browser observations cannot establish the security of an organisation's internal systems. That limit is part of what a reader needs to understand.

These are independent projects. They let me work on questions of explanation, evidence, and interaction; they do not, by themselves, establish that a system is ready for institutional deployment. That would require testing against the intended institution's work and requirements.

VTest it against the work

A promising place to begin is a recurring task with a recognisable result: preparing a briefing, comparing successive reports, or finding the guidance that applies to a question. The people who do that work can help define what a useful result would contain and where mistakes would matter.

The evaluation should follow from that task. For a briefing tool, it might examine omitted facts, unsupported claims, source dates, and the time a reviewer needs to make the document usable. For a search tool, it might examine whether the relevant record is found and whether an outdated version can be mistaken for the current one.

This also makes failures easier to investigate. A poor answer might result from a missing document, an ambiguous instruction, a model error, or an interface that conceals a qualification. Each needs a different response. Merely changing the model leaves the other causes untouched.

VIThe work I want to pursue

My background in communications, HR, and public policy shapes my interest in this area. Much of the challenge is deciding what a person needs to know, expressing it clearly, and understanding the organisation in which they will act. Learning to build software has given me another way to work on those questions.

I see an opportunity for AI tools that help Indian institutions use their knowledge more effectively. That will take detailed work with the people preparing documents, maintaining records, and making decisions. It will also require care over access, review, and responsibility as projects move beyond an individual experiment.

The question I want to keep asking is quite specific: when someone has a decision to prepare, does this tool help them understand the evidence and the choices in front of them? That is a standard a project can be built around and tested against.