Reading the Builder.

Capture Corner is the premium BD intelligence companion to Mission Meets Tech. Public-record sourced. Independent analysis. Not a recommendation, not vendor advocacy, not capture material. Built for federal health BD, capture, and proposal leaders who need analytical depth, not headlines.

This issue is the operator's companion to the public piece, "Whose Hands Were on It." It turns the argument into the checks a source selection board, a capture lead, and a program manager run when the deliverable no longer reveals who made it: how to read the builder, how to demand the artifact instead of the assertion, how to tell a real expert in the loop from a name on an org chart, and how to keep the reps that build judgment from disappearing off your own team.

---

The public issue made the case: the build stopped carrying the builder. AI supplies fluency to anyone who asks, so the polished surface no longer tells you whether a capable person stood behind it. The signal moved off the artifact and onto the person. Capture Corner turns that into the checks you run this week, on the work you are evaluating, the experts you are trusting, and the team you are building.

One number sets the stakes. Veracode tested AI-generated code across a hundred-plus models and found about 45 percent of it carrying a security flaw, with the newer, more fluent models no safer than the old ones. The work reads finished. The protection underneath is missing in nearly half of cases, and nothing on the surface tells you which half you are holding. A separate governance scan of AI-assisted applications found the same hole from the other side, standard security controls simply absent across app after app. Every check below exists to get you under the surface.

---

1. Artifact, not assertion: the source-selection checklist

This is the public issue's core move, turned into a procurement procedure. For every capability a proposal or a vendor claims, the narrative is the assertion. Demand the artifact. A model writes a flawless description of a control it never built. It cannot produce the control itself, and the firm that built it can hand it over in an afternoon.

The claim on the page	The artifact that proves it	What an AI-built fake hands you instead
"FedRAMP-authorized tooling"	The FedRAMP marketplace listing or authorization ID for every tool in the pipeline, including the AI ones	A paragraph asserting FedRAMP compliance
"Tamper-evident audit logging of CUI access"	One real log entry tied to a user, an action, a timestamp, and the control that governed it	A description of the logging approach
"Least-privilege access controls"	The actual access control list or IAM policy, exported	A sentence about role-based access
"Continuous monitoring"	The alert configuration and one sample alert that fired	A bullet claiming round-the-clock coverage
"Cost-realistic labor build"	The basis of estimate, category by category, walked against a current schedule	A clean rate table with no build-up behind it
"Relevant past performance"	A reachable reference, the CPARS, or the actual prior deliverable	A polished narrative with no verifiable anchor

The rule for the board: score the claim only after the artifact is in hand. Treat a confident description with no underlying artifact as the weakest signal in the proposal, because it is the one a model produces most cleanly. The baselines behind these rows are public, not proprietary: FedRAMP authorization and tamper-evident logging for any tool that touches CUI, the NIST 800-171 control set that sits under CMMC, FAR 15.404-1 cost realism for the rate build, and OMB's M-25-22, which pushes agencies toward verifiable AI performance over paper description. And know the downside of skipping this. Where unverified AI output has reached federal decision-makers, it has drawn sanctions: tribunals have struck briefs and dismissed protests built on citations that did not exist. Verification is no longer diligence. It is self-protection.

---

2. The builder-read: evaluating the human when you cannot evaluate the build

When the deliverable is indistinguishable on its surface, stop reading the deliverable and start reading the person who produced it. The tell is narration. Someone who did the work can walk you through the judgment behind it. Someone who only generated it can re-describe the output and nothing more.

Run this on a teammate, a subcontractor, or a vendor's named author:

1. Walk me through what you checked, and why. A real builder names the things that could have gone wrong and what they did about each. A prompt-only builder restates what the document says.
2. What did you decide not to do, and why? Judgment lives in the rejected options. The person who made the calls can name them. The tool left no trace of any.
3. Where is this weakest? Every expert knows the soft spot in their own work. "It's solid" is the answer of someone who cannot see one.
4. Show me the thing you know that is not in the document. Tacit knowledge, the kind Polanyi described, cannot be fully written down and cannot be prompted in. The genuine expert has a reserve behind the page. The mimic has only the page.
5. What would you check next if you had another day? The real builder has a list. The output has no opinion about its own gaps.

Scoring: fluent answers about the content of the document tell you nothing, because the document is the part that is now free. Specific answers about the choices, the risks, and the things left unsaid are the signal that a person, and not just a model, is behind the work.

---

3. The expert-in-the-loop test: a real reviewer versus a name on an org chart

"Human in the loop" has become a line on a slide. The question is whether the human in that loop has the judgment to catch what the tool missed, and the authority to stop the work when they do. A name with neither is decoration.

Ask, and require evidence:

1. Name the reviewer, their years, and a loss they own. Reliable expert intuition, as Kahneman and Klein established, is built only from real cues and real feedback over time. A reviewer who has never lost has never been calibrated. A name with no scar is a credential, not a reviewer.
2. Show me the last three things this reviewer caught. A real gate produces a trail of catches. An empty trail means the gate is a signature line.
3. What does the review actually consist of? Read-and-initial is not review. Ask for the override log: what the reviewer changed, rejected, or sent back.
4. What is the reviewer empowered to stop? If they cannot kill a submission, halt a deployment, or refuse a rate, they are not in the loop. They are next to it.
5. What happens to the gate on the busy afternoon? The deadline is the test. A gate that bends under schedule pressure is the one that lets the error through, because the busy afternoon is exactly when the error ships.

Real expert in the loop	Name on an org chart
Years in the domain and a loss record	A title and a credential
A trail of specific catches	"Reviewed and approved" with nothing behind it
An override log that shows the work	An initial in a box
Power to stop the submission	Visibility with no authority
Holds the gate under deadline	Waves it through when it is tight

---

4. Protecting apprenticeship inside an AI-tooled team

This is the section that decides whether your firm can still judge anything in five years. The tool runs the exact reps that used to build judgment. Automate all of them and you get a team that produces fast and cannot tell when it is wrong. The erosion already shows up in the data: GitClear's read of 211 million changed lines found refactoring falling and duplicated, copy-pasted code climbing as the tools spread, the residue of work shipped without the reps that used to go into it. The seniors who can catch the errors were forged before the tool. The line behind them has to be protected on purpose.

The rep the tool now skips	What it used to build	The practice that protects it
Debugging your own mistake	Pattern recognition, the library an expert reads from	Periodic no-tool work; juniors solve it before they prompt it
Walking a labor rate by hand	Cost-realism instinct, the feel for what a seat costs	The junior builds the basis of estimate manually before AI drafts it
Reading a full solicitation cover to cover	Scope judgment, knowing what the SOW really asks	The human reads the SOW before any agent summarizes it
Writing the technical approach cold	Solution ownership, the architecture in the head	The SME drafts the spine; AI fills; the human owns the result
Sitting through a debrief or a loss	Calibration, the scar that tunes the next bid	Walk every loss by hand, and make the next cohort walk it too

The standard, written down:

• Earned reps are mandatory, not nostalgic. Reserve a defined share of work that juniors do without the tool, because those reps are the only known way to produce the next person who can check the tool.
• Review the builder, not just the build. In every review, ask the Section 2 questions. You are grading judgment, not surface.
• Track who can actually catch errors, and protect them. Name the people on your team who can tell a real system from a convincing one. They are your scarcest asset and your succession risk. Know who is behind them, and whether anyone is.
• An organization that automates away all of its own apprenticeships is buying speed today against its ability to judge anything later, and it will not feel the trade until the bill arrives.

---

5. What to do this week

1. Adopt the artifact-not-assertion rule on your next evaluation. For every claimed control or capability, write down the artifact that would prove it, and refuse to score the claim until the artifact is in hand.
2. Run the builder-read on one deliverable. Pick a recent AI-assisted work product and put the five questions in Section 2 to whoever produced it. The answers will tell you whether you have a builder or a forwarder.
3. Audit your "human in the loop." For each AI-assisted workflow, name the reviewer, pull their last three catches, and confirm they can actually stop the work. Any loop that fails this is a signature line, not a gate.
4. Reserve the reps. Pick one task your juniors now hand straight to the tool and require them to do it by hand first, on a defined cadence. Start the apprenticeship you are otherwise automating away.
5. Name your catchers, and your succession risk. Write down the people on your team who can tell a real build from a convincing one, and write down who is behind each of them. If a name has no one behind it, you have found next year's problem today.
6. Make verification hold on the busy afternoon. Put the last human read on the critical path, not after it, and protect it from the deadline crunch. The afternoon you are surest you can skip it is the one where skipping it costs you.

---

Editorial discipline note

Capture Corner is built to be useful, not provocative. It does not name preferred vendors. It does not recommend a build-or-buy choice for your firm. It does not characterize any vendor's product beyond what public records and the vendor's own claims support. It does not reveal nonpublic information, and it is not tied to any open solicitation. What it does is take the public issue's argument and turn it into the practitioner-level checks BD, capture, and source selection leaders actually have to run when the deliverable no longer reveals who made it. The 45 percent figure is Veracode's published result. The sanctions pattern is drawn from public tribunal decisions and the cited survey of them. Use it accordingly.

---

Mary

Mission Meets Tech Premium

The views expressed in this newsletter are my own and do not represent the official position of any organization. This content is for informational purposes only.

---

Sources

[CC1] Veracode, "2025 GenAI Code Security Report" (100+ models, 80 tasks; ~45% of generated code samples contained a security vulnerability; newer and larger models no more secure than older ones). https://www.veracode.com/blog/genai-code-security-report/

[CC2] Cloud Security Alliance, "Vibe Coding AI Governance Gap" research note (widespread absence of standard security controls in AI-assisted applications, including missing security headers and exposure to routine web attacks). https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/06/CSA_research_note_vibe_coding_ai_governance_gap_20260602-csa-styled.pdf

[CC3] Kiteworks, "AI Compliance for Federal Contractors" (identify every AI system that can reach CUI; operation-level access controls; tamper-evident audit logging; FedRAMP verification for every AI tool). https://www.kiteworks.com/regulatory-compliance/ai-compliance-federal-contractors/

[CC4] NIST, Special Publication 800-171 Revision 3, "Protecting Controlled Unclassified Information" (control baseline for CUI; underlies CMMC for defense contractors). https://csrc.nist.gov/pubs/sp/800/171/r3/final

[CC5] Federal Acquisition Regulation 15.404-1, "Proposal analysis techniques" (cost realism; the government may test whether a proposed price is realistic and downgrade a bid that is not). https://www.acquisition.gov/far/15.404-1

[CC6] Office of Management and Budget, M-25-22, "Driving Efficient Acquisition of Artificial Intelligence in Government," February 2025 (performance-based contracting, continuous performance evaluation, and verifiable oversight of AI in the delivery chain). https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-22-Driving-Efficient-Acquisition-of-Artificial-Intelligence-in-Government.pdf

[CC7] Burr & Forman, "Gen-AI Misuse in Procurement Litigation" (pattern of struck briefs and dismissed protests built on fabricated AI-generated citations across federal tribunals). https://www.burr.com/government-contracting/gen-ai-misuse-in-procurement-litigation

[CC8] Michael Polanyi, The Tacit Dimension (1966; University of Chicago Press reissue, 2009). "We can know more than we can tell." https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html

[CC9] D. Kahneman and G. Klein, "Conditions for intuitive expertise: A failure to disagree," American Psychologist, 64(6), 2009 (reliable expert intuition requires high-validity cues and prolonged practice with feedback; the conditions for recognition built from consequence). https://eric.ed.gov/?id=EJ859788

[CC10] GitClear, "AI Copilot Code Quality 2025" (211 million changed lines; refactored/moved code fell from ~25% of changes in 2021 to under 10% by 2024; copy-pasted code more than doubled; duplicated blocks up ~8x). https://www.gitclear.com/ai_assistant_code_quality_2025_research