Setting the Scene¶
Vendor Intelligence: A Problem Worth Solving
Kessel Run put its name on the map by taking operational data scattered across multiple systems, manually synthesized under time pressure, and turning it into software that helps people make better decisions faster. That pattern continues across every portfolio today.
Federal vendor research is the same class of problem.
Before a contract is awarded, acquisition professionals need to answer a set of hard questions about every potential vendor. Can we buy from them: do they have an existing contract vehicle like a GSA Schedule, GWAC, or IDIQ, or would this require open-market procurement? Should we buy from them: do they have relevant past performance with agencies of similar mission, at similar scale? Are they eligible: registered in SAM, not excluded or debarred, and correctly certified for any socioeconomic set-asides? And what risks need to surface before anyone signs a recommendation?
Today, answering those questions means checking at least three separate government systems and often more. USAspending.gov tracks $6.75 trillion in annual federal obligations across 2.1 million awards. SAM.gov holds 2.68 million entity registrations and 167,000+ exclusion records. Contract opportunities live on a third system. GSA eLibrary holds schedule holder and contract vehicle data on yet another. Each has its own search interface, its own data format, and its own conventions.
The consequences of getting this wrong are documented. In 2020, the DoD Inspector General found $876.8 million in SDVOSB set-aside contracts awarded to 16 ineligible contractors over just two fiscal years. DoD had relied entirely on self-certification in SAM.gov with no additional verification. Seventeen of the 29 audited contractors had already been denied SDVOSB verification by the VA, but no one checked. The data existed. It sat in separate systems that no single tool brought together.
The information needed for vendor due diligence already exists in public, accessible APIs. USAspending.gov publishes award history, spending by agency, NAICS breakdowns, contract vehicle types, and time series data with no authentication required. SAM.gov provides entity registration, socioeconomic certifications, active solicitations, and the exclusions database. Between them, they cover registration and eligibility, past performance indicators, contract vehicle pathways, competitive landscape, and risk flags. The data is there. It is just scattered across systems that do not talk to each other.
That is where you come in.
Your team is going to build a Federal Vendor Intelligence Tool: a modernization prototype that consolidates data from multiple government contracting systems into one view. Type a vendor name, see the answers to the questions that matter. Award history by agency and NAICS code for past performance assessment. Contract vehicle breakdown showing how the government buys from this vendor today. SAM registration status and eligibility verification. Socioeconomic certifications for set-aside strategy. Active solicitations in their space for competitive landscape. Exclusion and debarment checks. An AI-generated due diligence summary that synthesizes it all into a recommendation. One tool instead of four separate systems.
You are building for the DoD acquisition community: the program managers, contracting officers, financial managers, and small business specialists who research vendors every day. The people right here at Hanscom, inside AFLCMC, who live this problem.
How the Challenges Work¶
Your team will go through four challenges. Each challenge builds on the last. You never start over. Here's how they work:
- Your team builds one thing together. One project, one demo at the end. For this first challenge, everyone is working in a chat tool, so spread out: each person can experiment, explore different approaches, and get practice prompting on their own. Then come back together as a team, compare what you found, and combine the best parts into one product. Starting in Challenge 2, you'll move into a shared codebase where your team should mob (everyone around one screen) until you have clear swim lanes for parallel work.
- Each challenge builds on the last. What you create in Challenge 1 carries forward into Challenge 2, 3, and 4. You'll add real data, new features, and eventually deploy it live.
- Baseline capabilities and stretch goals. Every challenge has a set of baseline capabilities everyone should aim for, plus stretch goals for teams that get there and want to push further.
- The goal is learning, not finishing. Understanding what you built and why it works matters more than checking every box. Help your teammates. Talk through decisions. Celebrate the wins together.
The Most Important Thing¶
You're about to use AI to build something real. Here's the one thing that will make the biggest difference in what you learn today:
Build one piece at a time.
The temptation will be to write out everything you want in one massive prompt and let AI handle it all at once. Don't. That's not how you learn this skill.
If you paste a wall of requirements and accept whatever comes back, you'll have output, but you won't understand it. You won't know what worked, what didn't, or how to fix it. You won't develop the judgment for when AI nails it and when it needs a nudge. And that judgment is the whole point.
The value is in the back-and-forth. Write a user story. Send it. Look at what comes back. Does it match your acceptance criteria? If not, tell your AI tool exactly what to change. That cycle (prompt, evaluate, refine) is the skill that transfers to everything you'll do with AI after today.
Build incrementally. Verify as you go. Discuss as a team.