How to Design a Solicitation That's Easy to Evaluate

A-Frame CEO David Zhang, a former federal Contracting Officer, laid this out in a lessons-learned session at NCMA World Congress 2026, drawing on the CIO-SP4 Phase 1 evaluation. It is not a theory: it comes from validating more than 33,000 self-scored examples across 1,150 proposals on CIO-SP4, one of the largest governmentwide acquisition contracts in the federal market. In its Phase 1 self-scoring evaluation, offerors claimed their own points on a form, and every claim was validated against authoritative federal data. At that scale, the patterns are unmistakable, and they all point to the same conclusion: the submission format is the evaluation design.

When the form is ambiguous, the data breaks

The most common problems traced back to the same root cause: the form asked for something the evaluators could not reliably use. A few examples:

• Undefined fields invite the wrong answer. A field labeled only "Project Value," with the real definition buried in the solicitation text, led offerors to enter contract ceiling instead of obligated funded value. Validators then had to check each claim by hand to tell which one it was. The fix is one word on the form: a clearly named, defined field.
• If it affects the score, it needs a field. Whether a company was prime or subcontractor changed how points were calculated, and missing details meant zero points, yet the form had nowhere to capture the prime contract number, subcontract number, or subcontract type. The requirement lived in an admin volume, not on the form the validators actually used.
• Format ambiguity creates duplication. With no way to claim one project across multiple task areas, offerors physically copied the same example into every section, inflating proposals past 2,000 pages. A multi-select field lets one example be claimed once.
• Untraceable claims become disputes. The form asked for a total score per section but no per-example breakdown, so when a validated score differed from a claimed score, there was no way to trace the difference to a specific example. That ambiguity is exactly what drives protests.
• Implicit content fails silently. Some offerors used PDF highlights and comments to signal relevance instead of writing it into the proposal body, where it was easy for a validator to miss entirely.

When verification is an afterthought, the process fights itself

The other half of the problem was created by leaving verification to the review stage. Federal and commercial experience earned the same points but were held to different verification standards. The solicitation required screenshots of a federal database, which can be altered, so validators re-ran every lookup independently anyway. And because a federal database returns the prime contractor's amount, it structurally cannot confirm a subcontract value. In each case, the common thread was the same: verification had been left to review, when it should have happened at submission.

What the cleanest proposals had in common

The data also showed what worked. The proposals that validated fastest and cleanest were not the longest. They shared three habits, and none of them was required by the solicitation:

• They built for scoring, not for volume. Every proposal was structured around the rubric so a validator could find each claim quickly.
• They made every claim traceable. Each example, task area, and point claimed was laid out plainly, often with a points-mapping table the solicitation never asked for.
• They anticipated verification. They used values that matched the authoritative record, reconciled against their own files first, and volunteered the details evaluators would need.

In short, they put themselves in the validator's chair. They got scored first, and cleanest. The lesson for the buyer is to design the form so that every proposal is forced to do this, rather than hoping the good ones will.

The takeaway: structure and validate at submission

If you design solicitations, the practical rule is short: build the fields that capture what you actually intend to score, and move verification into the submission moment rather than the review process. A standardized electronic portal with validated form fields would have prevented most of the problems in the CIO-SP4 dataset. Required fields, defined formats, per-example entries, and authoritative-source checks at submission turn a wall of PDFs into structured, comparable data before a reviewer ever opens it.

How ArcProcure puts this into practice

ArcProcure, the AI-powered e-procurement module of ArcSuite AI, is built on exactly this principle. Instead of a solicitation that ships as a document with attachment templates, it lets a buyer build a structured solicitation with AI assistance and collect responses as structured, validated data:

• AI-assisted solicitation building drafts the solicitation section by section, including the exact fields vendors must complete, so scoring-relevant information has a defined home from the start.
• Structured response forms let vendors respond into required, typed fields instead of assembling a 2,000-page PDF.
• Compliance and validation at submission enforce required fields, defined formats, and completeness when the response is submitted, not weeks later during review.
• Evaluation factors tied to the response keep every claim traceable to the rubric, so scoring is structured and defensible from the start.

The result is the portal the CIO-SP4 lessons describe: the structure that prevents the errors, and the validation that removes the duplicated verification work, built into one workflow.