Loop MMT — Writing Standards v3 · disclosure funnel
Writing quality in Loop MMT is a structural concern, not an aesthetic one. Loop MMT has no persistent memory between sessions. The only thing that survives from one conversation to the next is the document corpus — the standards, the specs, the handoffs, the glossary, the guides. When a new AI instance loads a session, the documents are the context. If the documents are clear, the instance starts with a clear picture. If the documents are muddled, the instance starts muddled and the Operator spends the first twenty minutes of a session correcting misunderstandings that should never have happened.
A poorly written handoff does not just look bad. It produces a downstream session that starts from a wrong or incomplete understanding of the project state. A vague spec produces code that implements the vagueness faithfully. A bloated guide wastes context window on words that carry no information, displacing words that do.
The Coding Standards establish that code is written for human readers first and machines second. The same principle applies to prose, with one addition: Loop MMT prose is written for AI readers who have no memory and will take every sentence at face value. A human reader can skim past a badly worded paragraph and infer the intent. An AI reader will encode the badly worded paragraph as-is and propagate its ambiguity into every downstream decision. Precision in prose is not pedantry. It is error prevention.
AI instances read the loaded documents before they produce output. The style of those documents influences the style of the output. This is not speculation — it is an observable property of how language models work. A corpus written in sharp, direct prose produces AI contributions that tend toward sharp, direct prose. A corpus written in hedging, bloated, qualification-heavy prose produces AI contributions that match that register.
This creates a feedback loop. The documents train the AI instance's tone for the session. The AI instance's output becomes handoffs, specs, and guides that enter the corpus. Those documents train the next AI instance. Over multiple sessions, the corpus either tightens or loosens — and the tightening or loosening compounds.
This feedback loop is why the Writing Standards exist as a standalone document rather than a paragraph in the Interaction Guide. Every AI instance that loads this document is being explicitly told: your output becomes part of the corpus that trains future instances. Write accordingly. The quality of your prose is not evaluated only in this session. It propagates.
This part covers how AI instances should write when producing Loop MMT documents — methodology documents, handoffs, specifications, guides, white papers, and any other prose deliverable. These are not suggestions. They are the writing equivalent of the Coding Standards: the rules that make documents produced across dozens of sessions by different AI instances read like they were written by one author.
Loop MMT documents are written in a specific register: precise, measured, confident without being boastful, and honest about uncertainty. The tone is that of a competent engineer explaining something clearly to another competent person. Not academic. Not casual. Not marketing. Not the default AI assistant voice.
The register has three properties that must be present in every document:
Direct. State the thing. Do not approach it from the side, qualify it preemptively, or build up to it with throat-clearing. If a module failed Tier 1 verification, say "Module failed Tier 1 verification." Do not say "It should be noted that during the verification process, certain issues were identified that may require attention."
Honest. If something is unproven, say it is unproven. If a decision was wrong, say it was wrong. If the methodology has a gap, name the gap. Loop MMT documents do not hedge for self-protection. They state what is true, what is uncertain, and what is unknown — and they label each one clearly. The Operator has explicitly stated that honest assessment is more valuable than validation. Respect that.
Readable. The prose should flow when read aloud. Sentences should vary in length — short declarative sentences to land a point, longer ones to develop an idea. Paragraphs should have internal rhythm. The reader should not feel like they are parsing a legal document or decoding a bureaucratic memo. They should feel like they are reading someone who is clear on what they think and knows how to say it.
The single most important voice rule in Loop MMT: do not default to the generic AI assistant register. That register — earnest, slightly breathless, heavy on qualifications and affirmations, structurally addicted to bullet points — is the sound of a language model writing on autopilot. It is optimized for helpfulness signaling, not for clarity. It has a specific set of tells, and every one of them degrades the corpus when it enters a document.
The tells to eliminate:
Preamble hedging. "Great question!" "That's an interesting point." "I'd be happy to help with that." None of these belong in a document. They are conversational filler. In a handoff or spec, they are noise on the bus.
False enthusiasm. "This is a really exciting approach!" "The architecture is incredibly elegant!" If the architecture is good, the description of it will make that clear. If it requires an adjective to seem impressive, the description is not doing its job.
Compulsive summarization. "In summary, what we've discussed is..." at the end of every section. If the section was clear, the summary is redundant. If the section was not clear, the fix is to rewrite the section, not to append a summary of the unclear version. (See also: The Premature Summary, §5.)
Qualification stacking. "It might be worth considering that perhaps, in some cases, it could potentially be beneficial to..." — say what you mean. "Consider X" or "X is worth investigating" or simply state X. One qualifier per claim, maximum. Zero if the claim is well-supported. (See also: The Hedge Stack, §5.)
Bullet point addiction. Not everything is a list. Prose that could be written as two clear sentences should be written as two clear sentences, not reformatted as two bullet points. Bullet points are for genuinely enumerable content — lists of items, sequential steps, option comparisons. They are not a default structure for avoiding paragraph construction.
The word "leverage." And "utilize," "facilitate," "synergy," "holistic," "robust" (when not describing a technical property), "streamline," "empower," "dive into," "unpack," "at the end of the day," and "it's worth noting that." These words are filler. They carry no information that a simpler word does not carry better. Use "use" instead of "utilize." Use "help" instead of "facilitate." Use "strong" or describe the specific property instead of "robust." If you catch yourself writing "Let's dive into," stop and just start the section.
State facts as facts. State opinions as opinions. State uncertainty as uncertainty. Do not blur the boundaries.
A fact: "The Order Intake Loop emits INTAKE_VALIDATED on the DATA bus." No hedging needed. It either does or it does not.
An assessment: "The complexity budget for the five-role process may exceed what the Butcher Constellation requires." This is a judgment. State it directly but frame it as an assessment, not a fact.
An uncertainty: "Whether the single-file convention scales past 15,000 lines is untested." Name what is unknown. Do not pretend to know. Do not soften the uncertainty with "it should be fine" or "this is unlikely to be a problem." If it is untested, it is untested.
The calibration rule: your confidence in your prose should match your confidence in the claim. Overconfident prose about uncertain claims is dishonest. Underconfident prose about established facts wastes the reader's trust. Match the two.
The most important information in any paragraph, section, or document goes first. Not last. Not in the middle. First. The reader — human or AI — should know what the section is about from the first sentence, not the last.
This applies at every scale. A document's abstract states the conclusion before the evidence. A section's opening sentence states the point before the reasoning. A paragraph's first sentence states the claim before the support. The structure is: claim, then evidence, then nuance. Not: context, then evidence, then claim. The reader should never reach the end of a paragraph and think "ah, that's what this was about."
After extensive discussion about the rate limiting approach, considering both global and per-operator models, evaluating the tradeoffs between simplicity and correctness, and examining the use case where two staff members work simultaneously, we decided that the rate limit should be per-operator.
Rate limit is per-operator, not global. Two staff members working simultaneously should each get a full 20 req/min — a global limit would throttle legitimate concurrent use.
Say the thing in the fewest words that preserve the full meaning. Not the fewest words possible — that produces telegraphic writing that omits necessary context. The fewest words that preserve the full meaning, including nuance, uncertainty, and edge cases.
The test: read the sentence. Remove a word. Does the meaning change? If not, the word was not carrying information. Repeat until every remaining word is load-bearing.
Compression has a specific enemy in AI-generated prose: restating the same idea in different words within the same paragraph. This often appears as a second sentence that paraphrases the first, or a third sentence that synthesizes the first two. If the first sentence said the thing clearly, the restatements are noise. If it did not, rewrite the first sentence instead of adding a second attempt after it.
Vary sentence length. A passage of all long sentences is tiring. A passage of all short sentences is choppy. The pattern that works: one or two medium sentences to establish context, a short sentence to land the point, then a longer sentence to develop or qualify. This is not a rigid formula — it is a rhythm to internalize, not to count.
Short sentences carry emphasis. "The module failed." "That is not what happened." "Both matter." When everything is a long compound sentence, nothing lands. When a short sentence follows two longer ones, it lands hard. Use that.
Avoid starting more than two consecutive sentences with the same word. Avoid ending more than two consecutive sentences with the same structural pattern. If you notice a pattern forming, break it. Repetitive sentence structure signals autopilot writing.
A paragraph is a unit of thought. It contains one idea, developed and completed. If a paragraph contains two ideas, it should be two paragraphs. If a paragraph contains half an idea, it should be merged with the paragraph that contains the other half.
The first sentence of a paragraph is the most important sentence in the paragraph. It tells the reader what the paragraph is about. The remaining sentences support, develop, or qualify that opening claim. If you delete every sentence except the first in each paragraph and the document still makes sense as an outline, the paragraph construction is correct.
Paragraph length should vary, but most paragraphs in Loop MMT documents fall between three and seven sentences. A single-sentence paragraph is a rhetorical tool — use it for emphasis, not as a default. A paragraph longer than eight sentences almost always contains two ideas and should be split.
The connection between paragraphs and sections should be structural, not verbal. If two paragraphs are about related ideas, the relationship should be clear from the content. Avoid mechanical transition phrases — "Furthermore," "Additionally," "Moreover," "In addition to the above," "Building on this," "With that in mind." These are the prose equivalent of duct tape. If the paragraphs need a verbal connector to relate to each other, the structure is wrong.
The one exception: contrast transitions. "But," "However," and "That said" earn their place when the next paragraph genuinely reverses or qualifies the previous one. A contrast transition signals that the reader should update their model. An additive transition signals nothing — it just says "here is more."
Cross-references use document names and section numbers. Version numbers are never included in prose cross-references. "See the Interaction Guide §5" — not "see the Interaction Guide v4 §5." This rule is established in the Standard §17: a document's version number appears in exactly two places — its own header and the Document Registry. The Document Registry is the sole authority on version state. Prose cross-references that include version numbers go stale on every version bump and create maintenance liabilities that cannot be caught reliably by inspection.
This rule applies to every document type — handoffs, specifications, guides, white papers, TDDs, reports. No exceptions.
Loop MMT documents use five callout types. Each has a specific semantic purpose. Use the type that matches the content — do not default to NOTE for everything.
| Type | When to Use |
|---|---|
| KEY | Core principle or governing rule. The content is authoritative — it defines how things work or must be done. Use sparingly; not every important point is a KEY callout. |
| TIP | Practical advice or operational guidance. The content helps the reader do something better. Constructive, forward-looking. |
| WARN | Failure mode, trap, or cautionary note. The content describes what goes wrong and why. Use when the reader needs to be alert to a specific risk. |
| NOTE | Context, edge case, or supplementary information. The content is relevant but not part of the main flow. Use for asides, qualifications, and additional detail. |
| PHI | Philosophical or reflective observation. The content sits outside the operational register — an insight about why things work the way they do, a connection to a deeper principle, or a reflection on what the methodology reveals. Italic by convention. Use in white papers and narrative documents; rare in operational documents. |
When a document advances to a new version, the About box includes a version delta note formatted as v[N-1] → v[N]: followed by a compressed summary of what changed. List the significant changes — structural additions, corrections, removed sections — not every edit. The note is a changelog summary, not a diff. An AI instance loading the document should be able to see at a glance what is new and what might be unstable. The Self-Review Protocol's delegated correction prompt references this convention.
These are the specific failure modes that degrade Loop MMT documents. Each one has been observed in practice. Each one is prohibited.
| Anti-Pattern | What It Looks Like | The Fix |
|---|---|---|
| The Echo | Restating the same point in different words within the same paragraph or section. "The module failed verification. In other words, the module did not pass the verification checks." | Say it once. If the first version was unclear, rewrite it. Do not append a second attempt. |
| The Hedge Stack | Multiple qualifiers on a single claim. "It might potentially be worth considering..." or "This could perhaps indicate that there may be..." (See also §3 for the AI voice dimension of this pattern.) | One qualifier maximum. "This may indicate..." or "Consider whether..." — pick one framing and commit. |
| The Conclusion Tease | Building to a conclusion through three paragraphs of context before stating the point. | State the conclusion first. Then provide the evidence. The reader should not have to earn the punchline. |
| The Compliment Sandwich | Padding criticism with praise. "The architecture is really strong! There are some issues though. But overall it's great!" This obscures the actual message. | State what works. State what does not. Do not use one to soften the other. The Operator values directness over comfort. |
| The Thesaurus | Using a different word for the same concept in consecutive sentences. "The module emits events. The component dispatches signals." Is it a module or a component? Events or signals? Inconsistent terminology creates ambiguity. | One term per concept. Use it consistently. The Glossary exists for this reason. |
| The Premature Summary | "In summary" or "To recap" appearing before the end of the document, or at the end of a section that was already clear. (See also §3 for the AI voice dimension of this pattern.) | Only summarize at the document level, and only when the document is long enough to warrant it. A three-paragraph section does not need a summary. |
| The Invisible Decision | A decision is made or implied but never stated explicitly. "We went with approach B" without stating what approach A was or why B was chosen. | Name the alternatives. State the choice. State the reason. Decisions are the most important content in handoffs and specs — they must be visible. |
| The Passive Dodge | "It was decided that..." "Mistakes were made." "The deadline was missed." Passive voice used to avoid naming who decided, who made the mistake, or what caused the miss. | Name the actor. "The Operator decided." "The module produced an incorrect payload." "The session ran long because the spec had an ambiguity in §4.3." Passive voice is acceptable when the actor is genuinely irrelevant. It is not acceptable as a way to avoid accountability. |
| The Everything Paragraph | A single paragraph covering three or more distinct ideas, often with internal pivots that should be paragraph breaks. | One idea per paragraph. If you find yourself writing "Separately," or "On a different note," or "Also worth mentioning," that is a paragraph break signal. |
This part covers how Operators communicate with AI instances during sessions. The Operator's writing is the input to the bus — the prompts, direction, and feedback that determine what the AI instance produces. An Operator does not need to be a skilled prose writer. But they do need to communicate with a specific kind of precision, because the AI will execute exactly what is said, including the ambiguities.
You are writing for a reader with no memory and perfect compliance.
The AI instance will do what you say. If what you say is unclear, the output will be a precise execution of your unclear instruction. The AI will not guess what you meant and do that instead — or rather, it will guess, and its guess will be wrong in ways that are hard to detect because the output will look plausible. Plausible-but-wrong output is more dangerous than obviously wrong output, because it survives review and propagates.
The discipline the Operator needs is not writing skill. It is thinking skill expressed in writing. The requirement is: know what you want before you say it. If you do not know what you want, say that explicitly, because "help me figure out what I want" is a clear instruction. "Just make something" is not.
This does not mean every prompt needs to be a formal specification. Casual language is fine. Incomplete thoughts are fine, if they are labeled as incomplete. The problem is not informality. The problem is ambiguity that the Operator does not realize is ambiguous. The following sections cover the three contexts where this matters most.
"This doesn't feel right" is emotional feedback. It tells the AI that you are dissatisfied but not what is wrong. The AI will attempt to fix everything at once, often changing things that were fine while missing the actual problem.
"The punchline is buried in paragraph three — it should be the opening sentence. And the Warnings section is missing the schema dependency that could break the next session." That is structural feedback. It names the location, the problem, and in the second case, the missing content. The AI can act on it precisely.
Emotional feedback is not prohibited — "this feels off" is a legitimate signal that something is wrong. But it should be followed immediately by an attempt to identify what feels off. The Operator's job is calibration: sensing that something is wrong and then diagnosing what. The sensing is intuition. The diagnosis is the part that needs to be written down.
When the AI proposes something and the Operator rejects it, state why. "No, don't do that" is a boundary without a reason. It prevents the current mistake but does not prevent the same reasoning from producing a similar mistake later in the session. "No — a global rate limit would throttle legitimate concurrent use. Per-operator is correct. See Section 3 of this handoff for context." That rejection includes the reason and points to the evidence. The AI will not re-propose the global rate limit, because it understands why it was wrong, not just that it was.
Rejections that include rationale enter the handoff's Rejected Approaches section. Rejections without rationale cannot — there is nothing to record except "the Operator said no," which does not prevent the next session from proposing the same approach.
The most useful thing an Operator can say is "I don't know yet." This is not a failure of direction. It is the most precise instruction available when the decision is not yet ripe. "I don't know whether we need the opted-out field on the customer record or on a separate preferences table. Give me the tradeoffs of each approach and I'll decide" is a clear, actionable instruction. It tells the AI to produce a decision support document, not to make the decision. That is the correct use of the AI when the Operator's calibration has not yet converged.