Corrections.
How to flag a wrong fact, missing capability, or outdated status.
Five fields.
Anything verifiable against vendor docs, the project's repository, the vendor's pricing page, or a first-party announcement. Useful corrections include:
- URL The page on Data Stack Index where the issue appears.
- Field Which schema field is wrong (e.g.
pricing_starts_at_usd,has_oss_self_host,warehouse_native_support). - Current value What the catalog currently says.
- Corrected value What it should say.
- Source A link to the vendor doc, pricing page, repo, or announcement that establishes the fact.
One email.
Email corrections@datastackindex.com with the subject line [correction] Tool Name. A GitHub Issues form on a public repo is planned but not yet live.
Five business days.
Acknowledged within five business days. Merged or declined within fourteen business days. Declined corrections come with a reason — usually that the source provided does not establish the claim, or that the field in question is editorial rather than factual and falls under methodology.
The audit ledger.
Accepted corrections are logged here in reverse chronological order. Each entry records date, tool, field, prior value, new value, and source.
No corrections yet.
This list grows as the catalog matures.
Methodology questions route differently.
Disagreement with a tool's cluster strength score, with which fields the schema includes, or with the catalog's selection criteria. These are methodology questions and go to email, not the corrections process. They are welcome — they're just routed differently because they may change the schema rather than a single field.
The audit trail.
Every change to the catalog can be traced to a source. The corrections log is the public side of that ledger.