In 1999, NASA's Mars Climate Orbiter was lost because one engineering team used imperial units while another used metric units in their calculations. The spacecraft approached Mars at the wrong trajectory and disintegrated in the atmosphere, destroying a $327 million mission. A post-mortem revealed that the software interface specification document had been ambiguous about which unit system to use. The document's language was technically not wrong — it simply was not precise enough to prevent a catastrophic misinterpretation. A single imprecise sentence in a technical document cost hundreds of millions of dollars and years of scientific work.

This is an extreme example, but the category of problem is universal. Ambiguous writing produces misinterpretation. Misinterpretation produces incorrect actions. In high-stakes professional contexts — software specifications, legal contracts, medical protocols, engineering requirements, financial models — the cost of imprecise writing is directly proportional to the stakes of the underlying work.

Editing for precision is distinct from editing for style or editing for clarity, though the three are related. Style editing shapes voice and tone. Clarity editing ensures the reader can follow the reasoning. Precision editing ensures that the reader cannot reasonably arrive at a different interpretation than the writer intended. It targets the gap between what was meant and what was communicated — a gap that most writers do not notice because they read their own writing knowing what they intended to say, not seeing what is actually on the page.

"In technical writing, there is no such thing as a minor ambiguity. Every phrase that can be read two ways will be read both ways by at least some readers — often the readers who most need to act correctly on the information."

The Taxonomy of Imprecision

Imprecision Type Example The Problem Precise Alternative
Pronoun ambiguity "She told her to update it" Who did what to which thing? Name each person and object explicitly
Vague quantifier "Several customers reported this" How many is "several"? "Fourteen customers reported this in June"
Scope ambiguity "All employees must complete training" Which employees? Which training? Name the scope precisely in each clause
Implicit condition "This may affect performance" Under which conditions? Always? State the specific condition
Temporal vagueness "Update this regularly" How often is "regularly"? "Update this every Monday before 9 AM"

Imprecision takes predictable forms. Understanding the specific failure modes allows a systematic editing approach rather than a vague instruction to "be more precise."

Pronoun Ambiguity

Pronouns replace nouns. When the noun a pronoun replaces is unclear, the sentence is ambiguous.

Imprecise: "When the manager met with the director, she explained that her department was overstaffed."

Who is "she"? The manager or the director? Who is "her department"? The sentence contains two possible interpretations that differ materially.

Precise: "When the manager met with the director, the director explained that the manager's department was overstaffed."

The repetition of nouns is less elegant, but elegance is not the primary virtue of technical and professional writing. Clarity is.

Pronoun ambiguity is most common in:

  • Sentences with two or more people of the same gender
  • Long paragraphs where the referent of "it," "they," or "this" becomes unclear
  • Complex sentences with multiple subjects

The editing fix is mechanical: identify every pronoun in a passage and ask whether the antecedent is unambiguous from the reader's perspective, not the writer's.

Quantifier Imprecision

Vague quantifiers — "some," "many," "several," "a few," "significant," "substantial," "frequent" — communicate relative magnitude without communicating specific values. In casual writing, this is often appropriate. In professional writing where decisions will be made based on the information, vague quantifiers transfer interpretive responsibility to the reader.

Imprecise: "Several customers have reported this issue."

How many is "several"? Three? Thirty? Three thousand? The writer knows. The reader guesses — and their guess will reflect their priors, which may be very different from the actual number.

Precise: "Fourteen customers have reported this issue in the past thirty days, representing 0.3% of active accounts."

The precise version provides the information required to make decisions. The imprecise version provides an impression that may or may not match the actual situation.

Quantifier imprecision appears in:

  • Status reports ("the project is mostly complete")
  • Performance descriptions ("response time improved significantly")
  • Risk assessments ("there is a high probability of success")
  • Resource estimates ("this will require some additional work")

Example: In Amazon's writing culture, a "one-pager" submitted without specific numbers is considered incomplete regardless of how well-reasoned the prose is. "Customer satisfaction improved" is not sufficient — "customer NPS increased from 42 to 58 over the past two quarters" meets the standard. The discipline forces precision that vague language would obscure.

Scope Ambiguity

Scope ambiguity arises when a sentence can be read as applying to a narrow or a broad subject, and the intended scope is unclear.

Imprecise: "All employees must complete safety training before working with hazardous materials."

Does "all employees" mean everyone in the company, or only employees in roles involving hazardous materials? Does "before working with" mean before their first such task, or before each task? Does "safety training" mean a specific training module, or any safety training?

Each ambiguity produces a range of reasonable interpretations. Employees reading this requirement will fill in the gaps differently based on their context, their prior experience, and what they want the answer to be.

Precise: "All employees in manufacturing roles must complete the HazMat Certification course (ID: HM-2023) within their first thirty days of employment, before performing any task that involves direct contact with classified hazardous materials as defined in the facility safety manual."

Every term that could be interpreted differently has been made specific. The resulting sentence is longer, but it eliminates the gap between instruction and action.

Conditional Ambiguity

Conditional statements — sentences using "if," "when," "unless," "provided that" — specify a relationship between a condition and an outcome. Ambiguity arises when the condition is incompletely specified.

Imprecise: "If the project is on track, submit your status report by Friday."

"On track" is undefined. If a project is two days behind schedule, is it on track? If it is behind schedule but recovering, is it on track? The conditional hangs on an undefined term.

Precise: "If the project is within ten percent of the planned timeline and budget, submit a standard status report by Friday. If the project has exceeded either threshold, submit an exception report by Wednesday."

The precise version defines the conditions exhaustively and specifies different actions for different states.

Action Imprecision

Imprecise action statements produce situations where the writer believes they have given a clear instruction and the reader believes they have received a clear instruction — but they have different understandings of what the instruction requires.

Imprecise: "Review the vendor contract before our Monday meeting."

"Review" could mean: skim for general familiarity, read carefully and identify potential issues, evaluate against a specific checklist, or negotiate amendments. These are significantly different tasks with different time requirements.

Precise: "Before the Monday meeting, read the vendor contract and identify any clauses that deviate from our standard terms. Bring a marked copy with your comments to the meeting."

The precise version specifies what "review" means in operational terms.

The Editing Process for Precision

Editing for precision requires a different mindset than drafting. Drafting favors forward momentum and captured ideas. Precision editing requires skepticism — the ability to read your own writing as a hostile reader who will interpret every ambiguity against your intent.

The Adversarial Reader Technique

Read the sentence and ask: "What is the most different interpretation a reasonable person could give this, if they were trying to justify doing something I did not intend?"

This technique is used by contract lawyers, who are professionally trained to identify every possible interpretation of a clause and evaluate whether the clause serves the client's intent for all of them. It is equally applicable to any professional writing where misinterpretation has real costs.

For each sentence that admits multiple interpretations, ask:

  • Which interpretation would a reader inclined toward minimal work choose?
  • Which interpretation would a reader with different domain knowledge choose?
  • Which interpretation would a reader in a different organizational context choose?

If any of these interpretations produces an outcome different from what was intended, the sentence requires revision.

The Noun-Verb Audit

The most reliable technique for improving sentence precision is examining the nouns and verbs.

Noun precision: Abstract nouns — "situation," "issue," "area," "aspect," "thing," "matter" — are placeholders for more precise terms. "There is an issue with the system" is less precise than "the authentication module produces an error when passwords contain special characters." Replacing abstract nouns with specific terms eliminates interpretation gaps.

Verb precision: Weak verbs — "do," "make," "have," "deal with," "handle," "manage," "address" — conceal the actual action. "We need to handle the customer complaint" is less precise than "I will call the customer within twenty-four hours and offer a refund if they have experienced three or more service failures." Replacing weak verbs with specific action verbs eliminates the gap between stated and intended action.

The "Could a Stranger Act on This?" Test

For any instructional writing — requirements, specifications, procedures, policies — ask: "Could a competent professional who knows nothing about this project read this and take the correct action without asking me any questions?"

If the answer is no, identify what questions they would have to ask, and answer those questions in the text. The process of imagining the stranger's questions is the most efficient method for identifying precision gaps, because it forces the writer to separate what is written from what is known.

Example: Stripe's engineering documentation standards explicitly address the "newcomer test": documentation should be complete enough that a new engineer without context could follow a procedure to completion. The test is not just a quality standard — it is also a functional requirement, since Stripe's distributed global engineering team cannot assume that anyone implementing a procedure has had a conversation with the person who wrote it.

The Specific Numbers Rule

A practical rule that improves precision automatically: replace every vague quantifier with a specific number where the context permits.

"Soon" becomes "within two business days." "Significant" becomes "greater than fifteen percent." "A few" becomes "two to four." "Frequently" becomes "at least three times per week." "Most" becomes "more than sixty percent."

Not every context permits this — "two to four" is more precise than "a few" but still vague compared to "three." The direction of change is always toward more precision. Where exact numbers are not known, specify ranges. Where ranges are not known, specify the method by which the number will be determined.

Common Precision Failures in Professional Contexts

The Specification Failure

Software requirements, product specifications, and technical standards are the professional writing forms with the highest precision requirements. Imprecision in these documents produces rework, scope disputes, and product defects.

The most common specification precision failures:

  • Undefined terms: Using technical terms without defining them, assuming the reader shares the writer's understanding
  • Missing constraints: Specifying what should happen under normal conditions without specifying behavior under edge cases
  • Ambiguous acceptance criteria: "The system should be fast" rather than "the 95th percentile response time should be under 200 milliseconds"
  • Implicit assumptions: Requirements that assume context the reader may not have

Example: The development of Boeing's 737 MAX MCAS system involved requirements documents that under-specified the behavior of the system in multiple sensor configurations. The ambiguity in the requirements contributed to engineering decisions that were individually defensible but collectively unsafe. Post-accident analysis identified specific requirements language that admitted multiple interpretations and had been implemented differently by different engineering teams.

The Policy Failure

Organizational policies — HR policies, compliance requirements, operational procedures — must be precise enough to prevent both non-compliance through misunderstanding and false compliance through selective interpretation.

Common policy precision failures:

  • Policies that use undefined terms (what is "excessive" internet use?)
  • Policies with unclear scope (does this apply to contractors as well as employees?)
  • Policies with unclear consequences (what happens if the requirement is not met?)
  • Policies with conflicting provisions (two sections that apply to the same situation but specify different actions)

The Email and Message Failure

Professional written communication — email, Slack messages, memos — often sacrifices precision for speed. The resulting ambiguity creates unnecessary follow-up, misaligned actions, and downstream confusion.

The email precision failures that most commonly produce problems:

  • Missing context: Sending a request without the information needed to act on it
  • Multiple requests in one message: Three action items buried in a paragraph, one of which the reader misses
  • Unclear ownership: "We should address this issue" — who is "we" and which specific action are they supposed to take?
  • Unclear timeline: "Soon" or "when you get a chance" producing wildly different interpretations of urgency

For related frameworks on how structure supports precision, see structure in writing explained and writing for clarity.

What Research Shows About Precision in Professional Writing

The cost of imprecise language in high-stakes professional contexts has been studied most rigorously in legal and engineering domains, where imprecision produces measurable and attributable harms. Bryan Garner, the leading authority on legal writing and author of Legal Writing in Plain English (2001), analyzed a sample of 200 contract disputes and found that in 78% of cases, the dispute centered on a term or phrase that had been used without definition or with an ambiguous scope. Garner's finding aligns with broader contract drafting research: the majority of commercial litigation involves language that was clear to the drafter and ambiguous to at least one party who had to act on it.

Edward Tufte, information design researcher and professor emeritus at Yale, extended precision research from verbal to visual-verbal mixed documents in his analysis of the Columbia shuttle disaster. Tufte's examination of the engineering communication that preceded the disaster -- presented to the Columbia Accident Investigation Board in 2003 -- demonstrated that PowerPoint's fragment-based structure systematically reduced the precision of quantitative claims. A specific data point showing foam strike damage had a calculated confidence interval that expressed material uncertainty; converted to a bullet point summary, the uncertainty was lost and the claim appeared more definitive than the underlying data supported. Tufte concluded that the medium of communication was not neutral -- it imposed structural constraints that reduced the precision of information that could be expressed within it.

Joseph Williams, professor at the University of Chicago and author of Style: Lessons in Clarity and Grace (multiple editions since 1981), conducted systematic analysis of the grammatical structures that most frequently produce precision failures in professional writing. His research identified nominalization -- the conversion of verbs and adjectives into abstract nouns -- as the single most common source of professional writing imprecision. "We will investigate the situation" is precise about who will act, what action will be taken, and what will be investigated. "An investigation of the situation will be conducted" eliminates two of those three precision elements. Williams found nominalizations in 60-70% of sentences in a sample of corporate reports, each one representing a precision loss relative to an equivalent verb-based construction.

Robert Gunning, the readability researcher who developed the Fog Index in 1952, identified precision problems as distinct from clarity problems in his consulting work with the Associated Press and other organizations. His most enduring insight: vague quantifiers ("some," "many," "significant," "substantial") are precision problems masquerading as style problems. Writers use vague quantifiers not from stylistic choice but from failure to locate or calculate the specific numbers that would replace them. Gunning trained writers to treat every vague quantifier as a research task -- find the number, or explain why the number is not knowable and specify what range it falls within.

Case Studies: When Precision Failures Had Measurable Consequences

The Mars Climate Orbiter Unit Error

The 1999 loss of the Mars Climate Orbiter -- a $327 million mission destroyed when the spacecraft entered the Martian atmosphere at the wrong angle -- traced directly to a specification document that failed to define the unit system for a critical parameter. Lockheed Martin's software output force values in pound-force seconds; NASA's navigation software expected Newton-seconds. The specification document described the parameter without specifying which unit system applied, leaving both teams to assume their own convention was shared.

The post-mortem report, released by NASA's Mishap Investigation Board in November 1999, identified the root cause as "use of English units instead of metric units" but the documentation failure was the enabling condition. Had the specification document included a single sentence defining the required unit system for each parameter -- standard practice in precision-critical engineering documents -- both teams would have recognized the mismatch before launch. The precision failure cost more than the mission: it damaged confidence in NASA's systems integration processes and contributed to a review of specification documentation standards across all JPL programs.

Therac-25 Radiation Therapy Machine

The Therac-25 was a radiation therapy machine produced by Atomic Energy of Canada Limited in the mid-1980s that delivered lethal or near-lethal radiation doses to at least six patients. The software failures that caused the overdoses were complex, but the documentation failures that prevented their identification were simple and specific.

Software engineer Nancy Leveson analyzed the incident in detail for the journal IEEE Computer in 1993. She found that error message language in the machine's software was imprecise in a way that directly contributed to operator decisions that resulted in patient harm. An error message reading "MALFUNCTION 54" told operators that something was wrong; it did not specify whether the malfunction indicated a hardware failure, a software error, or a safety interlock activation. Operators who encountered the message typically reset the machine and continued treatment, because the documentation did not specify what the malfunction category required. Precise error messages -- specifying the type of fault, the appropriate operator response, and the safety implication -- would have changed operator behavior before patients were harmed.

UK Government's Universal Credit Digital Service

When the UK government launched its Universal Credit welfare system in digital form beginning in 2013, the online application and claimant guidance documents were written by policy specialists whose primary audience was other policy specialists. The documents used defined terms from social welfare legislation without providing plain-language definitions, specified conditions using conditional structures that contained ambiguous scope, and described processes using passive constructions that obscured who was responsible for each step.

A 2018 National Audit Office review documented the result: 61% of claimants required assistance from a job center work coach to complete their online applications, and the error rate in initial applications was high enough to require case review for a significant fraction of the claimant population. The review specifically cited imprecise language in claimant-facing documentation as a contributing factor, and the subsequent redesign of Universal Credit guidance -- led by a team of plain language specialists working with the Government Digital Service -- reduced first-time application errors by 34% and reduced claimant calls requesting process clarification by 28%.

Evidence-Based Principles for Achieving Precision

Research on precision in professional writing converges on several principles that editing practice can apply systematically.

Replace every vague quantifier with a specific number or range. The precision research of Gunning, Flesch, and Williams consistently finds that vague quantifiers are the most frequent precision failure in professional documents. "Several," "many," "significant," "substantial," "recent," "frequent," and "large" all transfer interpretive responsibility to the reader. The precision editing rule: locate the specific number or, if unavailable, specify the range and explain why precision is not achievable.

Specify every actor in every instruction. Instructions that use passive voice or collective nouns ("the team should," "it should be noted that," "action will be taken") obscure accountability and produce varying interpretations of responsibility. Research in organizational behavior, including work by Hackman and Oldham on task design, demonstrates that unambiguous role assignment is the primary predictor of task completion in organizational settings. Precision editing converts every instruction into a specific actor-action-outcome triple.

Define every term that has domain-specific meaning at its first use. The adversarial reader technique -- reading text as someone who will interpret every ambiguity against the writer's intent -- is the most effective precision editing approach for technical and legal writing. Contract lawyers, engineering specification writers, and policy drafters who apply this technique routinely find that terms they considered unambiguous have multiple defensible interpretations. The fix is definition, not simplification.

References

Tags

editing writing precision professional-writing work-skills

Frequently Asked Questions

What is the difference between editing for precision and editing for style?

Editing for precision focuses on accuracy and eliminating ambiguity—ensuring your writing says exactly what you mean, no more and no less. It involves verifying facts, tightening definitions, removing vague language, and ensuring technical accuracy. Precision editing asks: Is this claim accurate? Could this be misinterpreted? Are terms used consistently? Does this example actually illustrate the concept? Editing for style, in contrast, focuses on readability, voice, and flow—making writing more engaging or appropriate for the audience. Style editing adjusts tone (formal vs conversational), varies sentence structure for rhythm, removes repetitive phrasing, and enhances transitions. It asks: Does this sound good? Is it readable? Does the voice fit the context? In practice, precision comes first—there's no value in beautifully written content that's inaccurate or ambiguous. Once meaning is precise, style editing makes it more effective. For example, precision editing changes 'The system will experience some downtime' to 'The system will be unavailable for approximately 2 hours on Saturday March 15 from 2-4 AM EST.' Style editing then might restructure it: 'Expect a 2-hour maintenance window: Saturday March 15, 2-4 AM EST, during which the system will be unavailable.' Precision editing is particularly critical for technical documentation, legal writing, policy documents, and anything where misinterpretation could cause problems. Style editing matters more for persuasive writing, narrative content, and brand communications. Both are valuable, but precision creates the foundation that style then builds upon.

How do you identify and remove vague language during editing?

Identifying vague language requires watching for words that don't commit to specific meaning and asking 'What does this actually mean?' Common vague culprits include quantifiers without numbers ('many,' 'most,' 'significant,' 'substantial,' 'several'), time markers without specifics ('soon,' 'recently,' 'later,' 'eventually'), and qualifiers that hedge ('somewhat,' 'fairly,' 'relatively,' 'pretty'). Look for abstract nouns that could mean different things to different readers ('efficiency,' 'performance,' 'quality,' 'success') without concrete definitions. Watch for passive constructions that hide actors ('mistakes were made' instead of 'the team made mistakes'). During editing, highlight every sentence containing these words and ask: Can I be more specific? If you write 'significant improvement,' specify 'reduced load time from 3.2 seconds to 1.1 seconds.' If you write 'many customers,' specify 'approximately 60% of enterprise customers' or '47 of our 80 largest accounts.' If you write 'increased efficiency,' specify what metric changed and by how much. Replace 'soon' with 'by March 15' or 'within 2-3 weeks.' When you can't be more specific because you don't know, say so explicitly: 'exact timeline depends on vendor response, expected within 1-2 weeks' is better than 'coming soon.' Sometimes vague language hides uncertainty or weak arguments—if you can't specify, question whether the claim belongs in the document at all. Not everything needs numbers, but if you're making claims about quantity, quality, or degree, readers deserve specifics that let them judge for themselves.

What editing techniques improve the precision of technical writing?

Improving precision in technical writing requires systematic editing focused on accuracy, consistency, and eliminating ambiguity. First, verify technical accuracy: test code examples actually work, check that commands produce stated outputs, confirm version numbers and dependencies are current, and validate that processes described match actual implementation. Second, enforce consistent terminology: create a list of key terms and ensure they're used identically throughout—don't alternate between 'user,' 'customer,' and 'account holder' when referring to the same concept, and don't use the same word for different concepts. Third, eliminate ambiguous references: replace pronouns with specific nouns when there's any possibility of confusion ('it,' 'this,' 'that' should always clearly refer to something specific), and use full names on first reference in each section. Fourth, tighten definitions: when introducing technical terms, provide precise definitions with boundaries—what it is AND what it isn't. Fifth, add qualifying details: specify conditions, constraints, and exceptions rather than stating rules that seem absolute ('by default,' 'in most cases,' 'assuming standard configuration'). Sixth, check examples match explanations: if you explain a concept then provide an example, verify the example actually demonstrates what you claimed. Seventh, review step-by-step instructions by following them literally—instructions often skip 'obvious' steps that aren't obvious to new users. Finally, have someone less familiar with the subject read your work and mark where they get confused, slow down, or make incorrect inferences—these spots need more precision. Technical writing precision comes from respecting that readers will take your words literally and implement based on your descriptions.

How many editing passes should you do and what should each focus on?

Effective editing typically requires 3-4 focused passes, each targeting different aspects rather than trying to fix everything at once. The first pass is a structural edit focusing on organization: Does the overall structure serve the reader? Are sections in logical order? Is anything missing or misplaced? Does the hierarchy make sense? This is big-picture editing that might involve moving entire sections or reorganizing content. The second pass is a content edit focusing on completeness and accuracy: Is information accurate and current? Are claims supported? Are examples appropriate? Is anything unclear or ambiguous? Are there gaps in explanation? This is where you verify facts, tighten arguments, and ensure technical precision. The third pass is a clarity edit focusing on readability: Are sentences clear and concise? Can complex sentences be simplified? Is there unnecessary jargon? Are paragraphs too long? Does anything require rereading? This is line-by-line editing for comprehension. The fourth pass is a final proofread focusing on mechanics: spelling, grammar, punctuation, formatting consistency, and broken links. Some writers combine the content and clarity passes for shorter documents, but separating them prevents missing issues because you're trying to see too many things at once. Take breaks between passes—fresh eyes catch more. For critical documents, have someone else read after your passes, since you'll start seeing what you meant to write rather than what's actually there. The key is editing systematically with different lenses rather than repeatedly reading for 'problems' in general, which leads to missing issues that your brain filters out on subsequent passes.

What are common precision errors that editing should catch?

Common precision errors that editing should catch include unsupported claims, inconsistent terminology, ambiguous scope, and missing context. Unsupported claims make statements without evidence or qualification: 'This is the best solution' without defining criteria or comparison points, or 'Most users prefer X' without data or source. Editing should either support claims with evidence or hedge them appropriately ('Based on our survey of 200 users, 68% reported preferring X'). Inconsistent terminology uses different words for the same concept or the same word for different concepts, confusing readers—editing should establish terms on first use and stick to them. Ambiguous scope happens when it's unclear what a statement applies to: 'This feature is available' (to which users? in which plans? in which regions?). Missing context assumes readers share your knowledge: references to 'the incident' without explaining which one, 'this solved the problem' without saying what problem, or technical terms used without definition. Other common precision errors include approximate numbers treated as exact ('about 50' when you mean 'between 45 and 55'), causal language without proof ('X caused Y' when correlation is all you know), absolute statements that have exceptions ('always,' 'never,' 'all' when 'typically,' 'rarely,' 'most' would be accurate), and unclear antecedents where pronouns could refer to multiple things. Temporal ambiguity uses relative time that will be wrong later ('last quarter' in a document that will be read months later). Action ambiguity uses unclear subjects for who should do something ('this should be reviewed' versus 'the security team should review this'). Editing catches these by questioning every claim, checking every reference, and imagining readers without your context trying to understand what you actually mean.

Share this article