Controlling LLM Prose

Tutorial · Lesson 3

Sharpen a Sloppy Spec

Turn ambiguous requirements into testable ones

Who this is for: Anyone who writes specs, tickets, or API docs that get misread.

What you’ll build: You will take a hand-wavy requirement and apply three precision controls until it has exactly one reading.

Engineering prose fails at its ambiguities—a dangling “it,” a scope-less “all,” a wishy-washy “should.” This lesson closes those gaps one at a time.

  1. 1

    Start with the ambiguous requirement

    Read this and count the ways it could be misimplemented.

    Ambiguous requirementAll requests should be validated, and if the token is invalid it should return an error to them.
  2. 2

    Fix the requirement level with RFC-2119

    “Should” hides how serious you are. Reserve MUST for absolute requirements and phrase each as a single testable statement.

    Reference: RFC-2119 Normative Keywords

    After RFC-2119The service MUST validate every request. If the token is invalid, it should return an error to them.
  3. 3

    Resolve the dangling reference

    “It” and “them” have no clear antecedent. Name them.

    Reference: Anaphora & Reference Resolution

    After reference resolutionThe service MUST validate every request. If the token is invalid, the service returns an error to the client.
  4. 4

    Pin the quantifier scope

    “Every request” is now unambiguous, but make the error concrete and the scope explicit so nothing is left to infer.

    Reference: Quantifier & Scope Precision

    Final: testableThe service MUST validate every incoming request. If a request’s token is invalid, the service MUST return HTTP 401 to the client.
Recap

Requirement level, reference, scope—three passes turned a sentence you could argue about into one you can test. Each pass corresponds to a reference concept you can reuse.