What ImportPreflight is, and why it exists
US import compliance runs through a small set of regulatory regimes that don't talk to each other. CBP enforces HTS classification and Entity List rules. FDA enforces its own import alerts and chapter-specific regulations. BIS owns export controls and a separate Entity List. UFLPA is layered on top, and it's been the fastest-growing enforcement priority of the last three years.
A broker working a normal day cannot manually verify every product against all four. Most don't try; the math doesn't allow it. Importers, for their part, often see the regulatory check as their broker's job — and brokers reasonably push back, because the broker isn't a forensic auditor of every supplier in every catalog.
ImportPreflight is the screen between catalog and broker. The product doesn't replace the broker, doesn't file with CBP, and doesn't try to be the system of record. It runs upstream of all of that — converting a raw product catalog into a triaged queue of what passes, what needs review, and what the broker should hold pending a closer look.
The architecture is deliberately narrow. We classify HTS using the USITC dataset, screen against bundled regulatory datasets that we refresh on a documented cadence, and produce structured output that exports cleanly into whatever ABI workflow already exists.
What ImportPreflight is not
It is not legal advice. The product is a screening tool. Final classification and admissibility decisions belong to a licensed customs broker, a trade attorney, or both.
It is not export-control classification. ECCN determination is a separate and harder problem; ImportPreflight does not attempt it.
It is not a CBP filer. ACE/ABI integration is not on the roadmap. Output exports to whatever filing workflow you already use.