Agencies have grown tired of reading about capability. More solicitations now ask for something the offeror can show: a live demonstration against a challenge dataset, a technical exchange where engineers answer questions without a script, a working prototype delivered with the proposal, or an oral presentation where the government picks the scenario. This is good news for anyone who builds things and bad news for anyone who writes about building things. It is also a scoring event with knowable rules, and the difference between an Outstanding and an Acceptable is almost always decided weeks before the room.
This is written for the capture lead planning that event. The question is not whether to demonstrate; the solicitation has answered that. The question is what to build, who builds it, how long it takes, and what happens in the room when a government engineer asks the one question nobody rehearsed.
What the evaluators are actually scoring
A demonstration is scored against the same criteria as the written volume, applied to something the board can see. Read the instructions closely and the scored dimensions are usually four.
Does it work on their kind of data. A system that performs beautifully on a curated sample and falls apart on the messy extract is the thing evaluators are looking for, because they have all seen it. If a challenge dataset is provided, the result on that dataset is the score. If it is not, the offeror chooses the data, and the choice is itself evaluated: a public dataset with the same structure as the agency's records reads as serious, and a synthetic set generated to flatter the model reads as a warning.
Is the result measured or asserted. The demonstration should show a number produced in front of the audience, or at minimum a method the audience could reproduce. The offeror who says the system achieves high accuracy and shows three hand-picked cases has scored nothing. The offeror who shows the evaluation run, states the metric, names the baseline it beats, and then shows the cases where it fails has demonstrated engineering judgment, which is what the board is trying to assess.
Can it live inside the agency's boundary. A prototype running on a personal machine is not a deployment story. A demonstration running in a cloud environment the agency already accredits, with identity integrated, logs flowing to the right place and the infrastructure defined as code, answers the question every technical evaluator has: how long from award until this is real.
Can the team answer the hard question. The moment that decides many oral evaluations is unscripted. Someone on the government side asks what happens when the input is out of distribution, or how the audit record is constructed, or why this model rather than the obvious alternative. An engineer who built the system answers in twenty seconds. A presenter answers in ninety and says they will take it for the record.
What separates an Outstanding demonstration from an Acceptable one
Editorial weighting, illustrative rather than measured. The last row is deliberately low: polish is assumed and never scored.
The four kinds of demonstration, and what each demands
The instructions determine which of these the pursuit faces, and they demand different work. Reading them as if they were the same is the first mistake.
| Format | What is scored | Build time needed | Most common failure |
|---|---|---|---|
| Challenge dataset, scored offline | The number, plus the written method and reproducibility | 4 to 8 weeks, front-loaded on data work | Overfitting to the sample; unreproducible pipeline |
| Live demonstration to a board | Working software, the operator experience, failure handling | 6 to 10 weeks including environment access | Demonstrating slides because the build slipped |
| Oral technical exchange | Depth of the answers under unscripted questioning | Weeks of real building, days of rehearsal | Sending presenters instead of engineers |
| Prototype delivered with the proposal | Code quality, documentation, deployability from clean checkout | 8 to 12 weeks; the last two are packaging | Code that runs only where the author built it |
| Hybrid: written volume plus recorded demo | Consistency between the claim and the recording | 6 to 8 weeks, with a hard media deadline | Recording asserts what the volume cannot support |
Two of these have a hidden constraint worth naming early. A prototype delivered with the proposal usually carries a data rights consequence, so the assertion table has to be settled before the code is packaged. And a recorded demonstration is frequently subject to accessibility requirements, which means captions and an accessible player, decided in the schedule rather than discovered the night before upload.
What to build, in engineering terms
The instinct is to build the most impressive part. The right move is to build the thinnest path that touches every claim the volume makes, then deepen the one part the evaluators will probe.
Start from the record, not the model. The first week goes to the data. Find the closest available approximation of the agency's records: a published dataset from the same domain, a records schema in a public system of records notice, a prior year's release, or a synthetic generator built to match a documented schema rather than invented from scratch. Write down the record count, the fields, the missing rates and the oddities. That description alone becomes some of the strongest text in the technical volume.
Build the ingest as if it will run forever. Late-arriving records, corrections that supersede earlier rows, codes that changed meaning, fixed-width extracts with trailing whitespace. A pipeline that handles these is a few days more work than one that does not, and it is the difference between a demonstration that survives a second dataset and one that does not.
Establish a baseline before the model. The most persuasive slide in most technical demonstrations is the simple baseline: a rules approach, a keyword match, a logistic regression on obvious features. Then the proposed approach measured against it, on the same split, with the same metric. Evaluators who have sat through many demonstrations trust the offeror who shows what the easy answer achieves and how much the sophisticated one adds. Offerors who skip the baseline invite the question of whether the sophistication was necessary.
Make the evaluation a program, not a spreadsheet. One command that rebuilds the dataset split, runs the model, computes every metric, and writes a report with the confusion structure and the failure examples. Run it in front of the audience if the format allows. Its existence is evidence of engineering discipline that a slide cannot supply.
Build the operator's view, not just the model's output. What a reviewer sees. How a case is accepted, corrected or escalated. What the system shows when it is unsure. Where the audit record lives and what it contains. Most artificial intelligence demonstrations show a prediction; the ones that win show a person doing their job faster with the prediction in front of them.
Deploy into something real. Infrastructure defined as code, deployed to a cloud environment with the managed services the agency's accredited platform actually offers, identity through a standards-based provider, logs and metrics flowing, and encryption in transit and at rest. The demonstration then carries a sentence no competitor can copy: this runs today in the same class of environment the program will use, and here is the definition file.
The schedule, working backwards from the date
Demonstrations fail on calendar more often than on capability. Working backwards from the event, the pattern that holds is roughly this.
Ten to eight weeks out. Decide what will be demonstrated and write it as a one-page technical position with the claims the demonstration must support. Identify the data. Stand up the environment and get accounts, which takes longer than anyone plans. Settle the data rights posture if code will be delivered.
Eight to five weeks out. Build the ingest and the baseline. Produce the first measured number. This is the checkpoint that matters: if there is no number by the five-week mark, the scope should shrink now rather than later. Shrinking at three weeks produces a demonstration of slides.
Five to three weeks out. Build the proposed approach and the operator interface. Run the evaluation end to end. Write the technical volume text from what actually exists, which is the point where the volume gets its specificity for free.
Three to two weeks out. Freeze the build. Deploy it to the demonstration environment and leave it running. Everything from here is rehearsal, failure-case selection, and the accessibility and security review of anything being delivered or recorded.
Final two weeks. Rehearse with hostile questioning. The prime's chief engineer, and ideally someone who has served on a source selection board, asks the hardest questions available. Every answer that takes more than thirty seconds becomes either a better answer or a slide. Record a backup video of the full demonstration in case the room's network fails, and rehearse the version that works with no network at all.
Where the eight weeks before a demonstration are best spent
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a deck cannot rescue a build that slipped.
Rehearsing the hard question
Worth its own section, because it is where evaluations are lost by teams whose software was fine. Build a list of the twenty questions a competent government engineer would ask, and answer each one in writing before the rehearsal. The list is not mysterious.
- What happens when the input is unlike anything in training? The answer names a detection method, a routing path and a human queue, not a confidence percentage.
- How would we reproduce your number? The answer is a command, a data split definition and a version, not a description of a process.
- Why this approach rather than the simpler one? The answer is the baseline comparison you already ran.
- What does the audit record contain? Inputs, model version, output, confidence, the reviewer's action, and the timestamps, retained per the agency's schedule.
- How does this get authorized? Which controls are inherited from the platform, which are the system's own, and what the assessment evidence looks like.
- What happens when the model degrades in production? Named monitoring statistics, thresholds, an alert path, a retraining trigger and the person who owns the decision.
- Is the interface accessible? Built to the federal accessibility standard from the first screen, with the testing method stated.
- What breaks first at ten times the volume? A specific component, with the measured evidence and the remediation.
- Who on this call wrote the code? The correct answer is a person in the room, saying which parts.
Teams that write these answers down usually find two or three they cannot answer well. Those become the last two weeks of engineering work, which is exactly what the rehearsal is for.
Failure modes that cost the evaluation
The demonstration proves the wrong thing. A team builds an impressive model and the solicitation was scoring integration and operator workflow. Read the evaluation criteria first, map each claim to the thing that will show it, and build only those things.
The data was too clean. A curated sample produces a number that will not survive contact with the agency's extract, and an experienced board knows it. Choose data with real defects and describe how the pipeline handles them; the honesty is scored.
Nobody owns the environment. Accounts, network access and the deployment target are assumed to be somebody's job and turn out to be nobody's. Assign an owner in week one with a date.
The engineers are not in the room. A polished presenter reading an engineer's slides loses to an engineer explaining their own system, every time an unscripted question arrives. If the format permits engineers, send engineers.
The volume and the demonstration disagree. The written text claims a capability the demonstration does not show, or the demonstration reveals a design the text does not describe. Both are read as carelessness. The volume should be written from the build, in the last three weeks, for exactly this reason.
The build slips and the scope does not. The single most common cause of a slide demonstration. The five-week checkpoint exists to force this decision while it is still cheap.
How we build this with a prime
Precision Federal is a small business engineering firm that builds artificial intelligence, data platforms, software, cloud and full-stack systems and deploys them into production inside federal agencies. On a prime's pursuit we build the demonstration, and the engagement has a fixed shape.
Week one, we read the solicitation and the evaluation instructions and return a written technical position: what we would demonstrate, the claims it supports, the data we would use, the environment we would deploy into, and the risks with dates against them. Short enough to read in ten minutes and specific enough to disagree with.
Weeks two through four, we build the data pipeline, the baseline and the first measured result. The prime gets the number at the checkpoint, not a status update. If the number says the scope should change, we say so then, when changing it is cheap.
Weeks five through eight, we build the proposed approach, the operator interface and the deployment, and we write the technical volume text for our sections in the prime's template at the assigned page count, in the prime's voice. Our engineers attend the color team reviews and answer the chief engineer's questions directly.
The final two weeks are rehearsal. We prepare the hard-question list, answer it in writing, sit for hostile questioning, and record the backup. If the format allows subcontractor engineers in the room, ours are the people who wrote the system and they answer as themselves.
The prime keeps everything. The customer relationship is the prime's alone. The contract is the prime's. The demonstration code, the models, the infrastructure definitions and the evaluation programs are assigned to the prime, with only our named background tooling carved out and licensed back so nothing is a hostage. The past performance from the effort belongs to the program.
Pricing is fixed-price milestones tied to the checkpoints above, so the prime knows the cost of the demonstration before committing to it, and each milestone has acceptance criteria stated as numbers rather than adjectives. The first step is one email with a one-page brief: the solicitation, the demonstration format, the date, and the technical problem as you see it. We return a scoped, priced statement of work.
An illustrative worked example
Consider a prime facing an oral technical exchange on a document processing requirement at a civilian agency, eight weeks out, with a challenge sample of records to be provided two weeks before the event.
A weak plan waits for the challenge sample and builds afterward. Two weeks is not enough to build anything, so the team builds slides and hopes the sample is easy.
A strong plan builds the full pipeline in the first six weeks against a public dataset with the same document structure, measured against a keyword baseline, deployed to a cloud environment with identity and logging, with the operator interface built and the evaluation runnable by one command. When the challenge sample arrives, the team runs the existing evaluation against it, reports the result honestly including where it degraded, and shows the two-day change they made in response. That last part is the strongest thing that happens in the room, because it demonstrates the thing the government is actually buying: a team that can absorb real data and respond.
Bottom line
A demonstration is scored on whether it runs on realistic data, whether the result is measured against a stated baseline, whether it could live inside the agency's boundary, and whether the person answering the hard question built the thing. All four are decided by how the eight weeks before the event are spent, not by the presentation. Set a checkpoint at five weeks that requires a measured number, shrink the scope there if the number is missing, freeze the build with two weeks left, and spend those two weeks answering questions in writing and then out loud. Bring the engineers into the room.
Frequently asked questions
Four things. It runs on data with the structure and defects of the agency's real records rather than a curated sample. The result is measured live against a named baseline with the metric stated. It is deployed in an environment of the class the program will actually use, with identity, logging and infrastructure as code. And the person answering unscripted questions is the engineer who built it. Production polish is assumed and is rarely scored.
Six to ten weeks for a live demonstration, four to eight for an offline challenge dataset, and eight to twelve if working code is delivered with the proposal because packaging and documentation take the final two weeks. The binding constraint is usually environment access rather than engineering. Set a checkpoint five weeks out that requires a measured number, and shrink the scope there if it is missing.
Yes, deliberately. Evaluation boards have watched many demonstrations that showed only successes, and they discount them. Showing the failure cases, explaining why they fail, and showing the routing path that sends them to a human is evidence of engineering judgment. It also removes the risk of a government engineer finding the failure case first, which converts a strength into a weakness.
The closest public data with the same record structure and the same defects: a published dataset from the domain, a prior public release, or a generator built against a documented schema rather than invented. Write down the record count, field structure, missing rates and oddities. That description becomes strong technical volume text, and the choice of data is itself evaluated as a signal of how seriously the offeror takes the real records.
Engineers who built the system, if the instructions permit them. The moment that decides many oral evaluations is unscripted, and an engineer answers an out-of-distribution or audit-record question in twenty seconds while a presenter takes it for the record. Rehearse with hostile questioning beforehand: write the twenty hardest questions, answer them in writing, and turn every answer that takes more than thirty seconds into engineering work or a slide.