The section that always comes back with red ink

Think about the last proposal, SOW, or requirements document you shipped. Somewhere in it was a section that wasn't really prose at all. It was a list of things, each of which needed the same treatment: a deliverables table with a row per deliverable, a compliance matrix with a line per RFP requirement, a scope section describing each feature or workstream, a risk register with an entry per risk.

Those sections are the ones that come back from review with the most red ink. Not because the writing is bad, but because the coverage is uneven. The first three deliverables get a crisp two-sentence description; the last four get a fragment each, because whoever drafted it ran out of steam. One requirement is answered in detail; the next is answered with “Compliant.” and nothing else. And every so often an item is just missing, or one appears that nobody in the room ever agreed to.

This is the part of document drafting that feels most mechanical and turns out to be the most error-prone. It's also exactly where feeding the whole thing to a generic AI tool goes wrong in ways that are hard to catch.

What generic AI does with a list

Ask ChatGPT or Claude to “write the deliverables section for this engagement” and paste in a transcript, and you get one of three failure modes, usually a blend of all three.

It invents items. The model knows what a deliverables list for this kind of engagement usually contains, so it fills gaps with plausible entries. “Stakeholder engagement plan,” “change management framework”: reasonable-sounding deliverables that you never scoped and can't staff. In a compliance matrix this is worse, because a fabricated “we comply with clause 7.4” is a claim you are now contractually on the hook for.

It drops items. Bury fourteen requirements in a two-page brief and a one-shot draft will confidently return eleven of them, formatted beautifully, with no flag that three are missing. The output looks complete, which is precisely what makes the omission dangerous. Nobody re-counts against the source when the document reads as finished.

It flattens the treatment. Even when every item is present, a single generation pass tends to give the first entries more attention than the last. The model is optimising for a coherent-looking block of text, not for giving item nine the same rigour as item one. So you get a section that tapers: strong at the top, thin at the bottom, and no consistent structure across entries.

All three failures share a root cause. When a list is drafted as one undifferentiated block of prose, there is no point at which anyone (human or machine) checks each item against its source and gives it equal, structured treatment. The list is being treated as writing when it is actually bookkeeping.

Draft the list as a list, not as prose

The fix is structural, and it's the reason SkyDraft treats repeating content as its own section kind rather than a paragraph you happen to fill with bullet points. Alongside prose sections (free-form) and table sections (column-driven), a repeating section is one where the AI discovers the items from your sources first, then drafts one entry per item.

That ordering matters. The first job isn't writing; it's enumeration. Before a single sentence of the deliverables section is drafted, the system reads the transcript, the brief, and the scope notes and produces the list of deliverables it found. You see that list. If it found eight deliverables and you scoped nine, the gap is visible immediately, at the cheapest possible moment to fix it, before any prose has been written around it.

Only once the item list is settled does the drafting start, and it runs one item at a time. Each deliverable gets its own generation: the same structure, the same depth, grounded in the source material for that specific item. Item nine gets the same treatment as item one because item nine is its own drafting step, not the tail end of a paragraph that ran long.

A worked example: the RFP compliance matrix

Compliance matrices are the clearest case, because the failure modes above are the difference between a compliant bid and a disqualified one. A public-sector RFP lists, say, thirty-one mandatory requirements across security, delivery, and commercial terms. Your response has to address every single one, and procurement will check.

Drafted as a repeating section, the flow looks like this. The system parses the requirements schedule from the RFP pack and returns thirty-one items, each mapped back to where it appeared in the source. You confirm the count against the tender document. Then each requirement is drafted as its own row: the requirement restated, your compliance statement, and the evidence or approach that backs it, in the same shape every time.

When the system can't confidently substantiate a requirement from your sources, it doesn't paper over it with a generic “Compliant.” It surfaces a clarification: “Requirement 22 asks for ISO 27001 certification evidence. No certificate was found in the uploaded sources. Provide the certificate reference or confirm the status.” That question lands before the row is finalised, not after a bid manager spots the hole at 11pm the night before submission. It's the same clarifications loop that runs across the rest of the document, applied per item.

Where each shape wins

Not every list should be a repeating section, and knowing which shape fits which content is half the value.

Repeating prose fits deliverables with a paragraph each, feature descriptions in a scope section, workstreams, or risk entries that need narrative context. Each item is a small block of writing, and consistency of depth across items is what you're protecting.
Repeating tables fit requirements matrices, deliverable schedules with columns (owner, milestone, acceptance criteria), or any list where every item shares the same fields. The columns enforce the structure; the repeating pass enforces the coverage.
Plain prose is still right for the executive summary, the background, the approach narrative: sections that are genuinely one flowing argument rather than a set of like-shaped items. Forcing those into a list makes them worse.

The tell for a repeating section is simple: if you find yourself writing “for each” in your head (for each deliverable, for each requirement, for each risk), the content is a list and should be drafted as one.

Why this changes the review, not just the draft

The obvious benefit is a better first draft. The quieter, larger benefit is what it does to review. When a list is one block of prose, reviewing it means re-reading the whole thing and holding the source document in your head to check nothing is missing. That is slow and unreliable, which is why omissions slip through.

When the list is drafted item by item against an enumerated set, review becomes checking a set against a set. Thirty-one requirements in, thirty-one rows out, each traceable to its source line. You're no longer proofreading prose for gaps; you're confirming a count and spot-checking substance. That's a task a junior can do reliably, which matters, because the list sections are usually the ones handed to juniors in the first place.

It also composes with the rest of the workflow. Each item is drafted with the full document as context (the sections already written, your edits, your workspace voice and glossary), so a repeating section reads in your firm's language rather than generic vendor-speak. And on a full document run, the item discovery happens automatically as part of the sequence, so you don't have to trigger it by hand for every list in the document.

The principle underneath

There's a general lesson here that outlasts any one feature. Documents fail at their most structured, most repetitive parts, not their most creative ones, because the structured parts get treated as beneath attention. The list feels like typing, so it gets typed carelessly. Generic AI inherits that same carelessness and adds fabrication on top.

Drafting one item at a time is a small mechanical decision with an outsized effect: it turns a section that hides its errors into one that exposes them early and cheaply. It's the same principle behind treating a SOW differently from a proposal: match the workflow to what the content actually is, instead of running everything through one generic “write me a document” pass.

If your documents are full of lists (and if you write proposals, SOWs, tenders, or requirements specs, they are), the list sections are where you're losing the most time to rework and carrying the most risk of a missed or invented item. See the document types SkyDraft is built for, or read the full how-it-works walkthrough.