Data quality
This tab documents the quality programme behind the catalog: what every record is tested for, how those tests are defined, and what a passing result establishes. Each catalog has its own results page. This page sets out the methodology those pages apply.
Programme scope
The current size of the programme, read live at page load. These counts describe how much is measured, not how good the data is; the per catalog pages carry that.
| Measure | Current |
|---|---|
| catalogs measured | |
| checks run | |
| checks failing |
Objectives
A specification database is only suitable to build on when its completeness can be established rather than assumed. The programme is designed around four commitments.
- Publish the report we act on internally. The same figures drive our own remediation queue, and the summary is served without an API key so the claim can be independently verified.
- Report records rather than scores. A score indicates how far the data can be trusted. A list of identifiers tells an engineer or an automated process exactly what to correct. Every failure names the records responsible.
- Preserve the distinction between unknown and false. A value nobody has established remains null rather than receiving a default, because a default converts an open question into a settled answer and the record is never revisited.
- Report completeness and consistency separately. A combined index would allow a contradiction in the data to be offset by strong coverage elsewhere.
What is measured
Every page in this tab applies the same two measures, in the same order.
| Measure | Question | Example finding |
|---|---|---|
| What is missing | Whether a value is present at all. Null and empty string are both treated as absent, so a column of blanks is never reported as complete. | 594 manufacturers hold no website. This is an outstanding gap rather than an error in the data. |
| What contradicts itself | Whether a statement the catalog makes contradicts another statement it makes. | A company recorded as closing before it was founded, or a firearm attributed to a manufacturer the catalog does not hold. |
The two are reported separately by design. A catalog can be 98 percent complete and still record a company as closing eleven years before it opened, and a single combined figure would move for only one of those conditions.
Results pages
Results are published per catalog rather than in a single combined report, so an assessment of one dataset does not require reading the others.
Interpreting a result
Each check returns one of two verdicts. Neither says anything about whether the values themselves are accurate.
| Result | What it means |
|---|---|
| Pass | confirms that no record in the catalog fails the check. It does not establish that the values are correct. |
| Fail | indicates that at least one record does, and the affected identifiers are listed alongside it. Failures are published rather than suppressed, and most warrant review before correction, since the check itself is sometimes the stricter of the two. |
Coverage bars encode width only and carry no colour. Colour would grade a field as good or poor, and a description nobody has written yet is not a defect.
Sources
Every figure is read from the database when the page loads. The summary is public and needs no API key, so the claims on these pages can be verified directly. The two endpoints that return full identifier lists are the operational worklist and require an Enterprise plan. Each row links to its entry in the API reference.
| Endpoint | Plan | Returns |
|---|---|---|
GET/v1/data/gaps | Public | The complete report: coverage for every tracked field, the verdict for every check, and up to five identifiers behind each failure. |
GET/v1/data/gaps/history | Public | One row per day from the daily snapshot: how many checks ran and failed, how many records were behind those failures, and weighted field coverage. This is how the figures above are judged over time. |
GET/v1/data/gaps/records | Enterprise | The records missing a given field, returned as identifiers with pagination. This is the endpoint an automated pipeline consumes. |
GET/v1/data/gaps/checks/{checkId} | Enterprise | Every identifier failing a given check, returned in full rather than as a sample. |
GET/v1/data/coverage | Enterprise | Per-field completeness for each table as a single percentage. The same question the coverage tables above answer, in the shape a dashboard wants. |
GET/v1/data/confidence | Enterprise | The records whose confidence score falls below a threshold you set, so a sourcing run can start with the weakest. |
The trend endpoint returns this. No key, no signup, no sales call.
{ "success": true, "data": { "days": 90, "runs": [ { "ranOn": "2026-09-15", "ranAt": "2026-09-15 03:00:00", "scope": "all", "checksTotal": 8, "checksFailing": 1, "recordsFailing": 3, "coveragePct": 62.4 } ] }}Nothing on this tab is a build time snapshot, so a record corrected today is reflected the next time the page is opened.
Why this is public
Firearms specification data is fragmented, inconsistently recorded and frequently contradictory across sources. Any catalog built from it has gaps. Publishing ours is a deliberate position, and it rests on four things.
- The source material is the hard part. Specifications differ by year, factory, batch and market; manufacturers retire pages; importers and retailers restate figures they did not measure. A catalog that claimed to be complete would be describing a body of data that does not exist in that form.
- A vendor who will not say what is missing is not a vendor without gaps. Every dataset in this field has them, so the difference between suppliers is whether you find out before you build or afterwards.
- Every figure on these pages is served by a public endpoint. You can fetch the same report we act on, disagree with it, and hold us to it, without an account and without asking.
- The snapshot is daily and the history is published with it, so the claim is not that the data is perfect today. It is that the direction is visible and on the record.
What this does not tell you
- A filled field is not necessarily a correct one. Coverage records whether a value is present, never whether it is accurate. A firearm with the wrong founding year is counted as fully covered.
- These checks find records that disagree with each other. A record that is confidently, consistently wrong passes every one of them.
- Whether a cited website still resolves is not checked here. That needs a request per record and belongs in a scheduled job, which is not built yet.
- These figures are our own measurement of our own data and do not constitute a third party audit. The endpoints behind them are public so that the results can be verified rather than accepted.