The draft that passes the read-aloud test and fails review

A four-week operational assessment for a mid-sized logistics client. Two site visits, eleven stakeholder interviews, a warehouse management system export, and the client's own internal review deck from the previous year. The engagement lead has all of it. What she needs is a 28-page assessment report: current state, findings, root causes, recommendations, a prioritised roadmap.

She pastes the interview notes into a chat window and asks for a findings section. Forty seconds later she has eight paragraphs of clean, confident, well-structured consulting prose. It reads exactly like a consulting report. She reads it twice, and then she deletes it, because she cannot find a single sentence in it that she could defend in the closeout meeting.

This is the failure mode that matters, and it is not a writing failure. The prose is good. The problem is that the report has been generated from the shape of a consulting report rather than from the evidence of this engagement. Everything downstream of that is wrong in ways that are hard to spot and expensive to fix.

We built SkyDraft for exactly this document type, and the first months of pilot were largely an exercise in cataloguing how generic AI fails at it. Five failures came up repeatedly. Each one turned into a specific design decision.

Failure 1: findings that are actually observations

Ask a general-purpose model for a findings section and it will give you descriptions. “The warehouse operates three shifts with limited handover documentation.” That is an observation. It is probably true. It is not a finding.

A finding in a consulting report has a specific internal structure: an observation, the evidence that supports it, the consequence for the client, and usually a severity or priority signal. “Handover between the three warehouse shifts is undocumented (observed on both site visits, confirmed by four of eleven interviewees), which we assess as the primary cause of the 6.2% pick-error rate on the first two hours of each shift.” That is a finding. It carries evidence and it carries a claim.

Generic AI produces observations because it has no idea what a finding is at your firm. Some firms want a severity rating on every finding. Some want an explicit evidence citation. Some want findings numbered so the recommendations can reference them.

What fixed it: putting that structure in the template rather than in a prompt. A findings section in SkyDraft carries its own guidelines and a required-information list, so the section knows it needs evidence and a consequence before it can be considered complete. When the source material does not support a consequence claim, the section says so instead of inventing one. We wrote about the underlying idea in templates as institutional memory: the definition of a good finding is a firm asset, and it should live somewhere the tool can execute.

Failure 2: recommendations detached from findings

This one is subtle and it is the single most common reason a draft gets rejected in review. Generic AI drafts a findings section, and then drafts a recommendations section, and the two are only loosely related. The recommendations are generically sensible (“implement a structured handover process”, “invest in staff training”, “establish KPIs and review cadence”) rather than being the specific consequence of the specific findings above them.

The reason is structural. Each request to a chat window is effectively a fresh start. Even when you paste the findings section in as context, the model treats it as reference text rather than as a set of commitments it now has to answer. So it answers the general question (“what would you recommend to a logistics operation?”) instead of the specific one (“what follows from these seven findings?”).

A client reading a report notices this instantly, even if they cannot name it. They read the findings, form an expectation of what comes next, and then get boilerplate. That is the moment the report stops being worth what they paid for it.

What fixed it: section-by-section generation where each section receives the actual approved text of every prior section, including your edits. When the recommendations section is drafted, it is drafted against your final findings, not against a generic understanding of the industry. If you rewrote finding four during review, the recommendations answer the rewritten version. We covered the mechanics of this in section-by-section vs one-shot drafting.

Failure 3: quantitative claims that came from nowhere

The pick-error rate in the example above is 6.2%. If that number is in the WMS export, the report can cite it. If it is not, the report must not contain it.

Generic AI will produce numbers of this kind willingly, because a consulting report with numbers in it looks more like a consulting report than one without. The numbers are plausible. They sit in plausible ranges. They are formatted correctly, to one decimal place, with a percentage sign. And they are frequently invented, because the model is completing a pattern rather than reading a spreadsheet.

This is the failure with the worst consequences. A voiceless paragraph costs you an hour of rewriting. A fabricated metric in a report you signed costs you the client relationship, and possibly more than that if the client acts on it. And it is the hardest failure to catch in review, because it is surrounded by accurate sentences.

What fixed it: two things. First, generation is grounded in the source documents you attach to the specific document, so the model is reading your WMS export rather than recalling what a logistics operation typically looks like. Second, when a section needs a figure the sources do not contain, the clarifications loop surfaces the gap as a question you answer before the section is written. The full test for whether a tool actually behaves this way is in source-grounded AI vs hallucinated AI.

Failure 4: the executive summary written first

Ask any generic tool to draft a report and it will start at the top, which means the executive summary is the first thing written and therefore the only section written with no knowledge of the report's actual content.

This is backwards, and every experienced consultant knows it. The executive summary is a synthesis. It exists to tell a partner or a board member the three things they need to know, and you cannot know what those three things are until the analysis is done. An executive summary drafted first is a summary of your expectations going into the engagement, which is precisely the bias the engagement was supposed to correct.

The practical symptom: the summary promises a report that does not exist. It gestures at “significant opportunities in inventory management” when the actual findings landed on shift handover and system configuration. Someone then rewrites the summary at the end, from scratch, which means the forty seconds the AI saved cost twenty minutes.

What fixed it: sections do not have to be generated in document order. In practice the workflow that works is to draft the body, review it, and then generate the executive summary last, at which point it has every prior section as context and is genuinely synthesising rather than predicting. The template still renders the summary at the top of the document. Generation order and document order are separate concerns.

Failure 5: one report, four voices

On a four-week engagement with three consultants contributing, generic AI produces a report where the current-state section sounds cautious and academic, the findings sound blunt, and the roadmap sounds like a vendor pitch. Each contributor prompted differently, so each section came back in a different register.

A client does not experience this as three people's writing styles. They experience it as a report that was assembled rather than written, which invites the question of how carefully anything in it was checked. Consistency of voice is a proxy for consistency of rigour, fairly or not.

What fixed it: brand voice, glossary, and author identity as workspace-level assets rather than per-prompt instructions. Every section of every document drafted in the workspace is generated against the same voice definition, so the register does not drift between contributors or between Tuesday and Friday. If your firm says “engagement” and never “project”, the glossary enforces it in section one and section twenty-two alike. There is more on the distinction between voice and identity in why your firm needs an AI-author identity.

What the fixed version of that engagement looks like

Same logistics assessment. Same eleven interviews, same WMS export, same 28-page target. The workflow that came out of the five fixes above:

Setup, once: the firm's assessment-report template is captured from a previous report. Section structure, per-section guidelines, the firm's definition of a finding, the required-information list, voice and glossary. This happens once and applies to every assessment after it.
Sources attached: interview notes, the WMS export, the client's prior internal review deck, the engagement SOW. These are the evidence base the report is allowed to draw on.
Clarifications answered up front: the questions the sources cannot answer surface as questions. Which of the three sites is in scope for the roadmap. Whether the pick-error figure is the client's own metric or ours. Whether the previous review's recommendations are treated as history or as commitments.
Body drafted section by section: current state, then findings, then root cause, then recommendations, then roadmap. Each one reviewed before the next begins, each one seeing the approved version of everything before it.
Executive summary last: generated with the full body as context, then edited by the engagement lead, who is the person whose judgement the client is actually buying.

The time saving is real but it is not the interesting part. The interesting part is that the failure modes above are now structurally hard to hit rather than something a reviewer has to catch. A finding without evidence does not get written. A recommendation that ignores the findings does not get written. A metric that is not in the sources becomes a question instead of a sentence.

What we did not fix, on purpose

The judgement stays yours. Which findings matter most, how hard to push a politically difficult recommendation, whether the roadmap is realistic given what you saw on site, what to leave out: none of that is a drafting problem and none of it is delegated. The engagement lead still owns the argument the report makes.

This is also why there is no button that produces a finished report unattended. Every section completes and stops. You can run through all of them in sequence, but the gate between sections is not optional, for the reasons set out in the case for human-in-the-loop drafting. A report you did not review is not a report you can sign.

How to test this on your own reports

Take the last assessment or engagement report your firm delivered. Give a generic AI tool the same source material and ask for the findings section. Then run three checks on what comes back.

First, count how many of its findings carry evidence rather than just an observation. Second, check every number against the sources, one by one. Third, hand the output to whoever reviewed the real report and ask how long it would take to get it to signable. That last number is the one that matters, and it is usually much larger than the forty seconds the draft took.

If you want to see the grounded version on your own material, we are onboarding pilot workspaces now. Bring one previous report and one live engagement. See the how-it-works walkthrough for the technical detail, or the use cases for the document types we support today.