Assumption Gap Detector

List what the SOW depends on and does not say, then decide which of those items become numbered assumptions, exclusions, or client obligations before the document goes out. That is the whole job. Scope fights rarely start because a line item was forgotten. They start because both sides treated something as obvious and never wrote it down.

This pass is not a clause factory and it is not a rewrite of legal terms. You want a short list a partner can accept, reject, or take to the client as an exclusion they have to see. If the draft came from SOW drafter from discovery transcript, treat this as the next pass, not a second draft of the same document. The drafter fills structure. This pass looks for absence.

A model that only sees the SOW will invent generic consulting gaps, or it will miss the ones your team already heard and failed to write down. Attach both: the current Word or Google Doc, and the discovery notes, transcript excerpts, email recap, or parking-lot list from the scoping calls.

Use a general LLM in the document when that is where the draft lives. Copilot in Word, ChatGPT or Claude against an exported copy: one prompt, two sources, a required output shape. Contract-review tools such as Harvey or Spellbook can sit in the same slot as a reviewer. They are not the system of record. Do not let them become the place the signed SOW lives, and do not ask them to redline indemnities, liability caps, or governing law.

Each flag should name the assumption in one sentence, where it showed up in discovery, where the SOW is silent, the dispute it tends to produce, and a treatment: numbered assumption, exclusion, client obligation, or drop.

Cap the first pass. Thirty flags means the review will not happen. Ask for the gaps most likely to cause a delivery dispute or a change order, plus an "already explicit" note for items already in the draft. Paste accepted flags into the SOW by hand. Do not auto-merge model text into a client-facing document.

Prompt for these categories by name. Ask the model to check each one against both sources, not to free-associate a longer list.

• Data access. Who extracts the legacy system, in what format, with what completeness, by what date, and who signs that the extract is fit for the work. Silence becomes "you should have known our data was a mess" in week six.
• Client FTE. Named roles, hours per week, and what happens when that person is pulled onto a launch. "Client will provide subject-matter expertise" has not staffed the project. Later effort estimation from historical actuals will bake in a client-side load the SOW never committed.
• Decision rights. Who accepts a deliverable, who can expand scope, and whether chat approval counts. Discovery often names a sponsor. The SOW often names a steering committee that has never met.
• Environments. Sandbox freshness, production access, identity provider, and who provisions them. "We'll work in your sandbox" is not an environment plan.
• Travel. On-site workshops, go-live coverage, whose budget, whose policy. If the SOW is silent, the client assumes you fly; your controller assumes you do not.
• Iterations. Number of review cycles, what constitutes acceptance, and what happens after the last included round. "We'll iterate until it's right" in the notes and "two UAT cycles" in the SOW is a third-round dispute.

Past SOWs for the same problem type show whether you usually write these down. Comparable past scope retriever is that lookup: which assumptions this firm already learned to print, not hours from a different client.

After the gaps are named, scope risk classifier scores remaining ambiguity, dependencies, and client readiness. Do not merge the two jobs. This pass lists what is unstated. That pass scores what is already on the page.

Illustrative only. No measured outcome.

A partner is about to send a twelve-week CRM implementation SOW. The document looks complete: workshops, configuration, data load, training, two weeks of hypercare. Exclusions cover "ongoing support after hypercare" and "custom integrations not named in Appendix A."

Discovery notes from two calls tell a different story. The sponsor said "we'll get you the Salesforce extract," with no system owner and only "probably needed" for attachments and five years of history. The ops lead who would be day-to-day was not on either call. UAT was "iterate until sales leadership is happy," while the SOW still says two cycles. Go-live "in the room" was assumed; travel is unmentioned; the team is in two cities. IT said the sandbox is a stale copy; the SOW says "client provides a non-production environment." Procurement emailed that all changes go through legal; the sponsor said they would approve extras in chat.

Run the model on both files. A useful output names a handful of assumptions, not a rewrite of Appendix A:

1. Data extract owner, contents, and who signs it as fit: delay and rework attributed to the firm.
2. Named client FTE and backfill unstated: workshops slip, then the timeline is treated as a commitment.
3. Acceptance split between sponsor chat and procurement legal: work proceeds on a verbal yes and gets rejected later.
4. Sandbox currency unstated: configuration against dead data, then replayed.
5. Travel for go-live unstated: an unbudgeted cost, or a no-show called a quality miss.
6. Iteration cap disagrees with the notes: a third UAT round billed as scope, or absorbed as goodwill.

The partner accepts 1, 2, 4, 5, and 6 as numbered assumptions or exclusions. They reject 3 as a relationship issue for kickoff, which is a legitimate reject. Write the reject down. If you do not, it returns as a delivery argument.

The model will not flag that the sponsor is leaving before go-live, and that the incoming VP did not choose this CRM. That is a political assumption. Models miss politics unless someone wrote the politics down. Put it in the notes if you know it, or it never appears on the list.

Models are good at finding absence. Absence is everywhere. "Timely feedback," "reasonable access," "standard reports," "as required" will all light up. If every hedge in the template becomes a finding, the partner stops reading after the third item and sends the SOW anyway. Drop stylistic flags. "The tone of section 4 is inconsistent" is not an assumption gap.

The human pass is mandatory. A junior consultant must not paste flags into the client draft. A partner, or the engagement manager they have deputized, accepts or rejects each one. Accepted items become assumptions, client obligations, or exclusions in the firm's language, not in the model's. Rejected items stay off the page, with a one-line note in the working file so the next reviewer does not re-open them.

If a gap survives into delivery, you are no longer in scoping. Scope creep detector is the later check against the signed SOW. It cannot recover an assumption you declined to write down. It can only show that a new request sits outside what you did write.

None of this matters if the partner will not take the accepted gaps to the client. A SOW can list data-extract fitness, named FTE, an iteration cap, and a travel budget, and still get signed as if those lines were decoration. Clients push. Partners who want the signature drop the exclusion on the call. The detector did its job. The firm still owns the delivery.

Use the list as the agenda for that call, not as a document dump. Pick the two or three assumptions that would actually stop work, say them in plain language, and get a yes or a written waiver. The rest can live as numbered assumptions the delivery team can point at later.

If the partner will not have that conversation, do not spend cycles refining prompts. You already know how the engagement will feel in week six.