How a Polished Draft Hides an Unconfirmed Fact

Consider a fictional matter. Your client, a supplier, ended a contract with a distributor. The contract required 30 days' written notice before termination. The client told the team, "We sent notice on March 1." The team was under deadline, so a paralegal gave an AI drafting tool the client's account, the contract clause and an outline. The AI produced a clean motion arguing that termination was proper because notice was timely.

At review, the supervising attorney asked one question: "Where is the delivery record?" Nobody had checked. The client's statement about the notice date had never been compared with the courier receipt. The whole argument depended on that date, and the date was only something the client had said.

This is the failure pattern this course addresses:

1. The team moves fast.
2. The AI produces a polished draft.
3. Review shows that the argument rests on a fact nobody confirmed.

The draft was not badly written. Its foundation had never been inspected.

An AI drafting tool writes confidently from whatever you give it. If you write "notice was sent March 1," the AI treats that as true and builds on it. It usually does not stop to ask whether you checked, and it does not mark the sentence as uncertain.

In the finished draft, every sentence carries the same tone and the same polish. A proven fact, an assumption and an open question all read alike:

• Proven: "Section 12.2 requires 30 days' written notice." The contract is in the file.
• Assumed: "Notice was delivered on March 1." This came only from the client.
• Unknown: "The distributor received no earlier oral waiver." Nobody has asked.

A reviewer reading quickly sees three confident statements. Nothing in the text shows which one has support behind it. A human first draft often shows its doubts through brackets, notes or rough patches. A fluent AI draft can smooth those away.

The fix is not to distrust every sentence. It is to inspect the premises separately, before the prose covers them. A premise is a factual or legal statement the argument needs in order to hold.

A premise check is a short table you build before asking AI to draft. Each row is one premise. Each row has eight columns:

1. Premise: the statement, in one sentence.
2. Factual or legal: is it about what happened, or about what the law says?
3. Label: supported (backed by a source in the file), assumed (believed but not confirmed) or unknown (no one knows yet).
4. Source reference: the document, page or exhibit, or "none."
5. Jurisdiction or forum: where the premise has to hold, such as a particular state court.
6. Reason for the label: why you chose that label.
7. Importance to the argument: how much of the argument depends on this premise.
8. Next action: what someone will do about it, and who.

The notice-date row would read: Notice delivered March 1 | Factual | Assumed | Client email to team, no delivery record | State court, contract action | Only the client's account; no receipt in file | High: timeliness depends on it | Paralegal to request the courier receipt.

Later lessons cover each column in depth.

The label column matters most, because it records what the team actually knows.

• Supported: a source in the file backs the premise. The contract states the 30-day notice requirement, so that premise is supported, with the clause and page cited.
• Assumed: the team believes it, but no source confirms it yet. The client says notice went out March 1. That is a client statement, not a confirmed fact, so the label is assumed.
• Unknown: nobody knows. Did the distributor ever waive the notice period by phone? No one has asked, so the label is unknown.

A common slip is to label something supported because it appears in a document. The client's email saying "we sent it March 1" is a document, but it only records what the client believes. It does not show that delivery happened. Support means a source that actually establishes the premise. Later in the course you will apply the same test to allegations and to the other side's assertions.

When you are unsure, choose the more cautious label. Moving an item up to supported later is cheap. Discovering at review that it never was supported is not.

The premise check comes after you have planned the argument and before you ask AI to draft anything. It works on an outline, not on a finished draft.

The order matters. If you draft first, the polished text is already in front of everyone and the premises sit inside paragraphs. Pulling them back out is slower, and the confident prose makes them easier to accept. If you check first, the premises are bare and easy to question.

A practical sequence:

1. Outline the planned argument in a few lines.
2. Build the premise check from that outline. In the next lesson you will use AI to surface premises the team has not stated.
3. Act on the high-importance items marked assumed or unknown: confirm them, or decide to disclose them as open.
4. Give the premise check to the attorney for review.
5. Only then, draft.

The check is meant to be short. For one motion it may be a dozen rows. You are not organizing the whole matter file. You are inspecting what this one argument stands on.

A gap found at review means rewriting. If the notice date turns out to be wrong, the timeliness argument may not survive, and the sections that depend on it need to be rethought, not just edited. A short inspection before drafting costs much less than that.

There is a worse case. A gap found late may never be found at all. Review is often done under the same deadline that caused the rush, and a reviewer reading fluent prose may not ask the question the supervising attorney asked about the delivery record. A weak premise that slips through review can end up in a filing, in front of a judge or opposing counsel.

Use the sliders to compare the time with your own estimates for a typical motion. The numbers are yours, not research figures. The point is the comparison: a short inspection against a rewrite you may not even know you need.

A premise check holds the core facts of a matter, so where you build it matters.

• Use only tools your firm or department has approved for client information. If the matter is real and identifiable, it belongs only in an approved tool.
• If your policy allows practice in other tools, use a fictional matter or one stripped of names, dates and identifying details. Never paste privileged or confidential documents into an unapproved tool.
• Removing names may not be enough. An unusual set of facts can identify a client on its own. A regional supplier ending its only distributor contract in a small industry could be recognizable without any names. Change or generalize the details until the matter could belong to anyone.
• Check your own rules. Review your jurisdiction's professional conduct rules and your firm's policy on AI use. This course does not replace them.

For this course, the fictional supplier matter is a safe default. Use a real matter only inside an approved tool.