How to design a solution narrative with AI

Build a requirement-to-response spine

Start with the customer’s source material, not an empty document. Record each requirement, evaluation factor, constraint, question, and ambiguity with a stable identifier. Then assign an owner and response strategy.

For a synthetic request for an internal knowledge assistant, the spine could be:

| ID | Customer need | Proposed response | Owner | Evidence | | --- | --- | --- | --- | --- | | R-04 | Restrict access by existing permissions | Retrieve only content available to the signed-in user | Product lead | Current architecture note A-12 | | R-07 | Explain the origin of an answer | Display linked source passages | Engineering lead | Tested prototype record T-09 | | R-11 | Launch within eight weeks | Phased pilot subject to identity integration | Delivery lead | Draft plan D-03 |

The Federal Acquisition Regulation states that requests for proposals identify the information required from an offeror and the evaluation factors and their relative importance. Even outside government procurement, the discipline is useful: the narrative should respond to the actual decision criteria rather than a generic list of strengths.

Explain the mechanism, not just the feature

For each important need, describe the operating sequence: input, action, control, output, owner, and exception path. “Our assistant provides secure answers” is not a mechanism. A better synthetic passage is: “The service receives the signed-in user’s identity, applies the connected repository’s permissions during retrieval, returns answer passages with source links, and records failed retrievals for review.”

Every part of that sentence still requires validation. The architecture owner confirms current behavior, the security owner confirms the boundary, and the delivery owner confirms what will exist during the proposed phase. If the mechanism depends on a customer system or unresolved design, state the dependency beside the claim.

Maintain a claim ledger while drafting

Give AI only approved evidence and require every material sentence to carry a claim label:

A claim ledger for R-07 might record: “Prototype displayed a linked source passage in test T-09; production availability is not established; repository coverage depends on the customer connector.” This wording is less dramatic than “every answer is fully traceable,” but it tells reviewers what is known and what remains contingent.

NIST’s Generative AI Profile describes risk management actions across governance, mapping, measurement, and management. Use that kind of lifecycle thinking as a review prompt, not as an endorsement of the proposed solution. Ask who owns each risk, what is measured, and what happens when an output cannot be supported.

• verified current capability;
• proposed configuration;
• delivery assumption;
• customer dependency;
• external requirement;
• synthetic illustration.

Make trade-offs and exclusions part of the story

A credible narrative explains choices. The synthetic team may choose permission-aware retrieval and source display before broad repository coverage. That reduces initial scope and creates a dependency on identity integration, while making the first pilot easier to inspect. Record the rejected alternatives and the reason for the choice.

The principal failure is overpromising capability. A common example is turning a roadmap item into present tense: “The platform integrates with all enterprise repositories.” Repair it by naming currently supported interfaces, proposed work, dependencies, acceptance evidence, and who can authorize the commitment.

Run an owner-by-owner red review

The final review is not a general copy edit. Product checks capabilities and exclusions. Engineering checks architecture and technical dependencies. Security or risk checks control descriptions. Delivery checks sequence, resources, and dates. Commercial ownership checks that the response matches the customer’s evaluation frame. Each material claim is accepted, narrowed, supported, or removed.

Before release, verify that:

• every requirement and evaluation factor has a clear disposition;
• the proposed mechanism matches current architecture or is labeled future work;
• customer and third-party dependencies are visible beside affected commitments;
• proof refers to a retrievable record and does not imply a broader outcome;
• dates, scope, staffing, and acceptance conditions have accountable owners;
• trade-offs, exceptions, and unsupported requests are stated plainly.

Sources and scope

This is an educational proposal-writing method. The example is fictional and makes no claim about Two Prune’s product, a customer outcome, or compliance with a solicitation.

• Acquisition.gov, FAR Subpart 15.2: Solicitation and Receipt of Proposals and Information: used for the role of requested proposal information and stated evaluation factors.
• National Institute of Standards and Technology, AI Risk Management Framework: used for the governance, mapping, measurement, and management framing applied to AI risk review.
• National Institute of Standards and Technology, Generative AI Profile: used for current generative-AI risk context and review prompts.

Sources: [1] [2] [3]