Project Philosophy

Why this document exists

Research is not only code and numbers. Behind every project there are a few simple ideas that guide how the work is done. This document explains the ideas that guided this project. It does not explain the methods again. It explains the way of thinking behind them.

Start with the question, not the method

We chose the question first, then the method. Each notebook began with one clear question, and only then did we pick a tool to answer it. We did not start with a method and look for a place to use it. For example, clustering was not used because it looks advanced. It was used because we wanted to know if states form natural types.

Evidence before opinion

Every conclusion came from the data first. Only after showing the numbers did we say what they might mean. In the reports, the numbers come first, and the interpretation comes after, in a separate part. Where the data did not support a claim, we did not make the claim.

Never guess

This was the core rule of the project. When something was missing or unclear, we left it as it was instead of filling it in.

• Missing values were kept as gaps. They were never filled with made-up numbers.
• Only two of Porter's four parts were measured, because only those had good data. The other two were not forced.
• The project points to priority areas, but it does not prescribe policies.
• The scenarios show "what if", but they do not predict the future.

A wrong number is worse than a missing one.

Simple methods are not weak methods

We chose simple methods on purpose. A complicated method is not automatically a better one. If a simple method answers the question clearly, it is the right choice. Min-Max scaling, equal weights and a simple average are all easy to explain, and a reader can check them at once. That is a strength, not a weakness.

Every notebook answers one question

Each notebook has one job. This kept the work from overlapping or drifting. One answer led naturally to the next question, so the whole project reads like a clear chain, from exploring the data to the final report.

Every limitation is written down

We wrote down what the project cannot do, not just what it can. Two parts of the framework are missing. Demand is only described with income figures. The scenarios are not forecasts. Saying these things openly makes the work more trustworthy, not less.

Reproducibility matters

If someone else takes the same data and the same code, they should get the same result. The whole project is built from official data and open code, so it can be repeated. This is why each step is saved and each choice is written down.

Documentation is part of research

Many people write code. Fewer people explain it. In this project, the explanation is treated as part of the work. Every notebook has a plain-language note, and every big choice has a written reason. A reader can understand the project without running a single line of code.

Research grows by revision

We changed our minds when the evidence asked us to. This is normal and healthy.

• The power indicators were split into supply and losses when one label became confusing.
• The gap work separated two ideas that were first mixed.
• The scenario method was changed to close the biggest gap, instead of using a fixed amount.
• The income reference year was fixed when the newest year was found to be missing for Gujarat.

Changing a decision after seeing evidence is a strength, not a mistake.

Respect the boundary of the data

We said only as much as the data allowed, and no more. The index measures what it measures. It is a starting point for understanding state competitiveness, not a full measure of development. Pushing the numbers to say more than they can would break the trust the project is built on.

In the end

We did not try to build the biggest project. We tried to build one that is honest, easy to understand and easy to check. If someone repeats the work and reaches the same conclusions, then the project has done its job.