Taking vendors at face value
A thing about working in government is that everyone's always so damn busy. There's always some fire drill (and occasionally an actual fire), data call or time-consuming process, a suddenly urgent item that sat around for months before it needed to get done ASAP, or it's just crunch time due to some statutorily mandated deadline. Folks have things to do, y'all.
A problem with this is that—in between the running around to get stuff done—errors are made.[1] When errors happen, someone often loses.
Most of the time, people just accept the errors and move on. Sometimes, people are able to intervene and correct the situation.[2] And, sometimes, when it matters a lot, they sue!
Contractors are also always so damn busy! They're dealing with multiple unhappy Goldilockses and, for the love of god, they need to hit their numbers this quarter! So they make errors, too!
It can be a hilarious combination when a contractor makes an error and the government doesn't catch it. Why hilarious? Because occasionally, the person on the losing end of this error will argue that the government should have done a better job in preventing the contractor's error! Haha! The government's got its own problems!
Here is one recent example. A company called Kizano Corporation submitted a bid to the Department of Veterans Affairs (VA), listing a company called "Alaris Advisors, LLC" as a subcontractor. Kizano thought it was in super good shape because its subcontractor was a certified service-disabled veteran-owned small business (SDVOSB). But then this happened:
The agency responds that ... Kizano’s subcontractor was not listed as a verified SDVOSB in the VetBiz database, nor was it registered as small in SAM under the applicable NAICS code. Indeed, the contracting officer represents that he checked these two databases and “Alaris Advisors, LLC was not found in either VetBiz or SAM.gov as an active or inactive record.” The contracting officer further explains that he also searched under the Data Universal Numbering System (DUNS) number listed in Kizano’s proposal but the search similarly yielded no results because the DUNS number provided by Kizano was incorrect; the contracting officer notes that it included one additional digit.
How could this be? How could Kizano's SDVOSB sub, Alaris, not be listed in the government databases?! Surely there's an error, right?
Kizano disputes the agency’s position, stating that the VA failed to produce any specific document showing that the alleged database searches provided no results. In support of its allegations, Kizano submits a letter, issued by the VA’s Center for Verification and Evaluation (CVE) to Alaris Advisers, LLC, rather than Alaris Advisors as provided in its proposal, on July 9, 2019, stating that Alaris is a verified SDVOSB. According to the letter, that verification was valid for three years. Kizano argues that Alaris was listed in the VetBiz database as an SDVOSB at the time Kizano submitted its proposal on February 26, 2021, and that the RFP did not require offerors’ to be verified SDVOSBs at the time of award.
Whoopsie daisy! Alaris was in SAM and VetBiz! Or rather, Alaris Advisers was in the databases, but Kizano listed them incorrectly as Alaris Advisors and (spoiler alert) Kizano lost the contract and protest.[3]
Here's another recent example, also involving the VA and two SDVOSBs (V3Gate and AATD):
V3Gate contends that the VA failed to meaningfully consider whether purchasing Lenovo products from AATD complied with FAR clause 52.204-25, which prohibits agencies from contracting for certain telecommunications equipment. In this regard, V3Gate broadly argues that the Lenovo computers quoted by AATD “fall within [the] expansive definition” of covered equipment found in FAR clause 52.204-25, as equipment linked to the Chinese government. The protester asserts that the agency was required to analyze whether issuing a delivery order to AATD complied with FAR clause 52.204-25.
In response, the agency asserts that it fully complied with the applicable regulatory prohibition. Specifically, the VA explains that it included the pertinent FAR clauses in the solicitation, and requested that vendors self-certify whether they provide covered telecommunications equipment in their quotations. The VA maintains that the contracting officer here reasonably relied on AATD’s representation that it did not provide covered equipment or services.
The VA wanted some Lenovo computers, AATD said it could do that, and V3Gate objected that basically everyone knows that Lenovo computers are super not ok under section 889. In response, the VA basically shrugged: "how were we supposed to know that? AATD said it was fine!"
To which, V3Gate channeled its best Gob Bluth "Oh, come on!" impression. V3Gate argued that "in light of the 'well-known connection between Lenovo and the Chinese Government,' the VA should have investigated the truthfulness of AATD's representation that its quoted products were not prohibited telecommunications equipment".
In the end, though, GAO wasn't having it:
We see no merit to the protester’s contentions. While the protester cites to a number of publications, including a 2019 Department of Defense Inspector General report and the 2015 cybersecurity alerts issued by the Department of Homeland Security, which warn of cyberespionage risks associated with Lenovo products, there is no evidence that the contracting officer was aware of these sources or should have been. Accordingly, we do not find that this information gave rise to an obligation to investigate AATD’s FAR clauses 52.204-24 and 52.204-26 representations.
Nor do we agree with V3Gate’s allegation that the contracting officer was required to investigate “whether or not the Secretary of Defense . . . belie[ves that Lenovo was connected to the government of China, by] contacting the [Department of Defense] or reviewing other published lists of such published entities.” We find no such a requirement in the existing regulations. This protest ground is denied.
Now, some folks have expressed dismay at this outcome and worrying that it will affect the enforceability of section 889. I mean, cyberespionage risks are pretty scary stuff! It's not especially awesome that the government just relies on contractors.
But, really, any one could see this one coming, right? No one actually expects a contracting officer to, I guess, pick up the phone and call SECDEF and say like "Hi, I need some Lenovo computers. I hear that the CCP is all up in Lenovo's business. Can I buy this laptop or what? Thanks, bye!"
After all, people in the government are busy! Contractors are busy! Errors are made. And the government needs laptops!
If a contractor makes an error, it's expecting a lot to require the government to fix it. I suppose you could add Yet Another Database To Check to the procurement checklist? I mean, what could possibly go wrong with that?
[1] I am being pedantic with the use of the word "error" instead of the more common passive-voice verbiage: "mistakes were made". There's a difference between slips and mistakes and people often mean to say "slips" when they say "mistakes", and that's erroneous. I get it, though: "slips were made" sounds very weird.
[2] For example, I saw this delightful nugget on LinkedIn the other day where the contractor was late (wrong) in submitting an equitable-adjustment request and the contracting officer denied the request. But the contract didn't include a timeliness provision (maybe wrong?), so the contracting officer's decision was wrong. Who says two (or three) wrongs don't make a right?
[3] For those playing at home, the algorithm you're searching for is called Hamming Distance (not Levenshtein distance like I previously wrote).