GunSpec
Transparency

Fitment checks

Whether the compatibility engine offers the parts that really fit a firearm, where they really go, and refuses the ones that do not. A suite asks the production API questions a gunsmith could answer without it, holds every fit it reads to rules about the whole catalogue, and publishes the run here, failures included.

Under active development

The compatibility endpoints, and the mount data behind them, are still being built out. The results below test the logic, not the completeness of the catalogue.

Coverage
Many parts and firearms do not yet carry the mount data a fit needs. A part missing from a list is often a gap in the data rather than a refusal, and the catalogue is being uplifted to close it.
Tested on
A small, deliberately varied set of about thirty firearms, checked for reliability and compatibility on every run.
  • Rifles
  • Pistols
  • Shotguns
  • Battle rifles
  • Submachine guns
Before you buy
Check a fit with the maker before you buy or fit a part. A listed fit is where to start, not a guarantee.

Whether a part fits is not a field on a record. It is computed from several: the mount points a firearm exposes, what it inherits from its platform and its parent model, the adapters that can sit between the two, where on the gun the part may go, and the cartridges its maker rates it for. Every one of those records can pass its own checks while the answer they add up to is wrong, so the data quality pages, which test a record on its own, cannot see it.

So these checks are built on evidence rather than on the engine's own view of itself. Each scenario is a question a gunsmith can answer without the API, such as whether a rifle-length handguard goes on a carbine gas system. Each rule recomputes an answer from the published records and the maker's own statements, such as a suppressor's rated cartridges and minimum barrel length, and holds the API to it. A failure names the record or the rule responsible, so it can be corrected at its source.

The same answers are served by the API, the MCP server and the website. Checking them this way is how we know an answer about what fits a firearm is one we can stand behind, and it is how the gaps the catalogue still has are found and closed.

Scenarios are named cases with a known answer. A 4-16x scope goes on an AK-74M over the receiver through a side mount, never on the handguard. A SureFire SOCOM RC2 goes on an M4 through a SureFire muzzle device, never straight onto the thread. A bipod never goes on a Glock. A Yugo top-cover rail fits a Zastava M70 and not an AK-74M.

Rules are questions over every fit the run read, about thirty firearms across rifles, pistols, shotguns, battle rifles and submachine guns. Some hold the engine to its policies: no magnified optic forward of the receiver, no bipod on a handgun, no sight anywhere but over the bore. Some re-derive a fit from the published records: the bore of a suppressor against the bullet, its rated barrel length against the barrel, a part's requirements against the gun's mounts and the adapter's provides. And some ask one question of two endpoints: the fit list, the plain list, the confidence filter, the catalogue's fits filter, the interfaces endpoint and each standard's own list of firearms must all give the same answer, twice. Others sweep whole slices of the catalogue rather than the sampled guns: every firearm on a short-action stock or magazine standard must chamber a short-action cartridge, every magazine well must suit a cartridge its magazines are rated for, and every pistol named MOS or OSP must have an optic cut.

A rule with nothing to judge reads as unchecked, never as passing, and each rule is published with how many fits it judged, so a pass over five routes and a pass over two thousand are told apart.

Loading the latest run…

  • A rule that holds found no fit breaking it among the fits it judged. The count beside it is how many it judged, so a pass over five routes and a pass over two thousand are not read the same.
  • A rule that fails names the fits responsible. Each one is either a defect in the compatibility logic or a gap in the data, and both are corrected rather than hidden.
  • Unchecked means the run found nothing the rule applies to. It is not a pass.
  • The run is repeated every night and after every release of the API, so the page shows the answers the live API gives today.