The federal exclusion list is public, it is 168,206 records long, and this Actor will hand you all of it. What it will not do is answer “is this vendor debarred?” — and that refusal is the most considered decision in the whole Actor.
What the exclusion list is
The record of parties excluded from federal contracting: debarments, suspensions and other prohibitions, with the agency, the dates, the classification and an address. Available as a separate exclusions dataset when maxExclusions is above 0, at $0.0005 per record.
As a dataset it supports real analysis: how many exclusions, by which agency, of what classification, over what period. Those are aggregate questions and the data answers them well.
The composition that makes matching unsafe
| Property of the list | Consequence |
|---|---|
| 63% of records are individuals | Most of the list is people, not companies. |
| Only about 20% of those carry a UEI | There is no reliable identifier to match on for four fifths of them. |
Put those two together and a lookup has only a name to work with, for the majority of the list. A name is not an identifier: it is shared, it is transliterated inconsistently, it is abbreviated, and it changes.
The cost of a false positive
This is why the decision is not a close call. A false positive in a debarment check does not produce a slightly wrong number — it produces the statement “this person is barred from federal contracting” about somebody who is not.
Why the feature is not offered
A “debarment check” would be the most requested feature in this Actor. It would also be the easiest to build — a string comparison — and the output would look authoritative in a way the method does not support.
That combination is the problem: a confident-sounding answer produced by a method that cannot be confident. It is the same reason the Naver Actor refuses reviewer identities and the coches.net Actor refuses private phone numbers: the harm lands on somebody who is not the customer.
What to do instead
- Match on an identifier where one exists. A UEI or CAGE code is a real match; a name is a lead.
- Treat a name match as a prompt for a human, verified against the official record on SAM.gov before any decision.
- Never automate an adverse decision on a name match. If a system can decline somebody without a person looking, the false positives are silent.
- Use the dataset for what it is good at: aggregate analysis, not per-party verdicts.
The general pattern
There is a recurring shape in this catalogue: the data is public, the join is technically easy, and the result would assert something about an identifiable person that the method cannot support. Every time that shape appears, the answer has been the same — ship the data, refuse the confident conclusion.
It costs a feature. What it buys is that nothing in these Actors produces an authoritative-looking claim about a person that nobody can stand behind.
