From requirements to a design you can test
Write the acceptance tests before the prose. Failure has to be pointable.
Engineering design starts from requirements, not from the look of the finished object. A requirement has to become a test. "Sound more professional" is not a requirement. "For this question, the answer must include these three facts and their sources" is.
Design chooses among requirements. Length, readability, and citability crowd each other. Write the choice down: this piece drops the anecdote opening and puts the definition and boundary in the first paragraph, because acceptance is restatement, not time on page. Unwritten choices let everyone reject the draft with a private standard.
Models, prediction, and tests here are sampling and annotation. You predict that the engine will grab the definition and the comparison table, then check with the annotation demo. If the prediction fails, change the design. Do not regenerate the same piece unchanged. Test once before publishing and once after. The questions may differ. Both rounds still face the original requirement.
Failure is part of the design. A rejection is not an accident. It is a negative test. Keep it: which evidence was missing, which paragraph the model skipped. A process with no failure record cannot tell luck from design.
The smallest design sheet has four lines: the question, the facts that must appear, the claims that must not, and how acceptance will be judged.