An Indian startup dataset audit should begin before you calculate a single percentage. Freeze the exact resource you used, record its publisher and access date, separate the catalogue description from the downloadable file, test the file's structure and granularity, and preserve every transformation. Then check whether the resulting claim says only what that source can support. If the resource is aggregate, it cannot verify an individual startup. If its time coverage is unclear, it cannot support a precise current-state claim.
This workflow is for founders preparing market slides, analysts building ecosystem maps, journalists checking context, and researchers who need another person to reproduce the result. It does not certify that a dataset is complete or suitable for legal, investment, tax, or compliance decisions.
Define the claim before opening the file
A large spreadsheet can make a weak question look scientific. Start by writing the sentence you expect the analysis to support. Examples include:
- the number of records in a named resource for a stated period;
- the distribution of records across the categories present in that file;
- the change between two comparable releases;
- the share of rows that meet an explicitly documented filter.
Now write what the result will not prove. A state-wise count of recognised startups does not establish that a particular company is recognised, active, funded, safe, or still operating. A portal search result does not establish the completeness of an aggregate dataset. Keeping those limits beside the intended claim stops scope from expanding after an interesting number appears.
For entity-level checks, use the separate Indian startup verification workflow. The method here is about dataset provenance and analysis, not company due diligence.
Treat the catalogue and resource as different evidence
A government open-data page can contain at least two layers:
- the catalogue record, which describes the subject, publisher, jurisdiction, and related resources;
- the resource, such as a CSV, spreadsheet, XML file, or API response containing the observations.
The Open Government Data Platform's DPIIT-recognised startup catalogue, checked on 3 September 2026, describes counts by year, sector, and state. That wording identifies aggregate dimensions; it does not promise a row for every recognised entity.
Record the catalogue URL and the exact resource URL separately. Also record separate dates when the page exposes them. A catalogue can be edited without replacing a file, and a resource can be refreshed while the surrounding description remains unchanged. Quoting one date as though it applies to both creates false precision.
The platform's publishing help lists metadata such as title, description, jurisdiction, access method, reference URLs, frequency, and granularity. Use those fields as audit inputs, not decoration. If a material field is missing or ambiguous, add that limitation to the analysis instead of guessing.
Freeze a reproducible source snapshot
A citation to a live page is necessary but not sufficient for reproducible analysis. The underlying file may change after publication. Create a compact source record at download time:
| Field | What to preserve |
|---|---|
| Catalogue | Public catalogue URL and title |
| Resource | Direct file or API URL |
| Publisher | Named ministry, department, or data owner |
| Accessed at | Date, time, and timezone |
| Resource date | The date shown for that specific file, if present |
| Format | CSV, XLS, JSON, XML, or other format |
| File identity | Filename, byte size, and SHA-256 checksum |
| Parameters | API filters, page size, sort order, and pagination |
| Licence | Licence shown in the dataset metadata |
A checksum is a file fingerprint. It does not prove accuracy, but it lets another reviewer confirm that they are testing the same bytes. If the source is an API, save the raw response plus the request path and non-secret parameters. Never publish an API key, access token, or private identifier in the evidence bundle.
Check granularity before counting
Granularity answers, “What does one row represent?” It might be a year, a state-year pair, a sector-state pair, or an individual entity. Determine that from both the metadata and the columns. Do not infer company-level coverage from a title containing the word “startups.”
Run four boundary checks:
- Unit: What is the observation represented by one row?
- Coverage: Which dates, jurisdictions, sectors, or statuses are included?
- Measure: Is a numeric field a count, percentage, cumulative total, or something else?
- Exclusions: Are blanks, suppressed values, unknown categories, or unavailable periods explained?
This step prevents double counting. For example, adding a cumulative total across years would repeat earlier observations. Adding state totals and an all-India total from the same table could count the same population twice. Do not calculate across groups until the dimensions and measure are explicit.
Run six file-integrity checks
1. Preserve headers exactly
Save the original column names before renaming them for code. A cleaned field called state may have started as “State/UT,” which carries a different interpretation. Keep a small mapping from original header to analysis name.
2. Inspect types without forcing them
Look for dates stored as text, numeric columns containing commas or footnotes, identifiers converted to scientific notation, and leading zeros removed by spreadsheet software. Type conversion should be an explicit transformation, not an invisible import side effect.
3. Count blanks and special values
Distinguish an empty cell from 0, NA, “not reported,” and a suppressed value. The OGD help guidance discusses machine-readable formats and metadata for explaining raw and derived data. Your analysis should preserve the source's distinction instead of turning every non-number into zero.
4. Test duplicate keys
Define the columns that should uniquely identify a row, such as year plus state plus sector. Report duplicate keys before aggregation. Duplicate rows may be legitimate revisions or separate subgroups, so inspect them rather than deleting them automatically.
5. Test category drift
Compare spelling, capitalisation, punctuation, and “Other” categories across releases. Merge labels only with a documented rule. A renamed sector is not automatically the same historical category.
6. Reconcile totals carefully
When a file supplies subtotals or grand totals, calculate your own total at the same grain and compare. A mismatch is a finding to investigate, not a number to hide. Preserve both values and the rule used to exclude total rows from later calculations.
Cross-check interpretation with another official surface
Independent corroboration does not mean finding a blog that repeats the same figure. Use a source with a different function. The Startup India startup search exposes a DPIIT-recognised filter and other discovery fields. It is useful for understanding what the portal labels at the entity-discovery level, while the OGD catalogue describes aggregate data.
Do not expect the two surfaces to produce the same count without proving that their scope, update point, filters, and unit are identical. Instead, use the comparison to test interpretation: are you analysing entities or aggregates, recognition or another status, a snapshot or a cumulative series? If those questions remain unresolved, narrow the claim.
Preserve every transformation
A reproducible result needs a short transformation ledger. Record each operation in order:
- imported the named raw resource without editing it;
- standardised whitespace while preserving original labels;
- parsed specified date or number fields;
- filtered rows using an exact rule;
- excluded supplied total rows before aggregation;
- grouped by named dimensions;
- calculated the displayed measure and rounding rule.
Keep raw input read-only and write cleaned output to a separate file. A spreadsheet user can maintain the same discipline with separate Raw, Clean, and Analysis sheets. A code user should keep the script and dependency versions beside the source record.
Cite the result, not just the portal
The OGD Platform's terms of use say reproduced material should be accurate, not misleading, and prominently acknowledge the source; they also advise checking updated information with the concerned department or source. Its policies page links the governing open-data policy and licence documents. Check the licence metadata on the individual record because the terms point users to that field.
A useful citation note contains:
- dataset and resource title;
- publisher or data owner;
- direct URL;
- resource date, when stated;
- access date;
- relevant filter and unit;
- transformation note;
- limitation.
Write “Calculated from the named resource after excluding supplied total rows” rather than “According to government data” when the final value is your own calculation. Never imply that the publisher endorses your analysis, product, or conclusion.
A 20-minute dataset audit checklist
Before publishing a chart, market slide, directory claim, or article:
- Write the exact claim and its exclusions.
- Identify the data owner, catalogue record, and exact resource.
- Record separate catalogue, resource, and access dates.
- Save the raw file or response and calculate its checksum.
- Record format, API parameters, pagination, and licence metadata.
- Identify the unit, dimensions, measure, time coverage, and exclusions.
- Inspect headers, data types, blanks, special values, and duplicate keys.
- Check category drift and reconcile supplied totals.
- Compare the interpretation with another appropriate official surface.
- Preserve the transformation ledger, code or formulas, and rounding rule.
- Cite the calculated result with its scope and limitation.
- Stop if the source cannot support the intended sentence.
Researchers can browse SuperLaunch's Indian startup directory as a discovery surface, then return to primary sources for material claims. Founders who want their own current evidence reviewed can submit a startup. SuperLaunch's editorial policy explains how sourcing, corrections, independence, and commercial separation are handled.
The practical rule
A reproducible dataset claim connects one sentence to one frozen input and one visible chain of transformations. The portal page tells you where the data came from; the resource tells you what was measured; your ledger explains what you changed. Keep those three layers separate, and do not publish a conclusion broader than the weakest documented layer.
