Concrete Detail, Specific Nouns, and Useful Verbs

By the end of this lesson, you will be able to...

• Replace a vague technical claim with observable actors, actions, evidence, and a bounded consequence.

• Separate what a document observed from what it infers or still does not know.

• Reject false precision when a number or detail does not help a reader verify or act.

Idea in one sentence: Name the thing that changed and what it did, then show the evidence and limit instead of asking the reader to trust a vague impression.

Core Insight

At 14:20, a support engineer asks why customer imports handled by import-worker are late. The first incident note says:

The import service had reliability issues under load. The team made improvements and the situation recovered.

The note may be sincere. It is not useful yet.

Which service? What kind of work? What changed? Who made which change? How late were imports? Did the system recover on its own, or did an action change it? A reader cannot tell where to look, what to verify, or whether the same risk remains.

The problem is not simply that the prose lacks flavor. Vague language hides the link between evidence and claim. It lets a writer sound certain without saying what would make the claim true or false.

Lesson 004 gave each sentence a job: expose an action or relationship. This lesson makes that sentence-level job inspectable. A useful noun identifies the object under discussion. A useful verb shows what it did. Concrete detail tells the reader what evidence supports the claim and where the claim stops.

The Tempting but Weak Model

The naive model is:

  technical writing sounds precise when it uses abstract nouns

That produces sentences such as:

The system experienced degradation because of a capacity issue.

The nouns “system,” “degradation,” and “capacity issue” compress too much. They might refer to a worker, database pool, queue, network link, CPU, disk, or rate limit. The verb “experienced” tells us nothing about what changed.

The stronger model is:

  actor or object + observable action or state + evidence + consequence + boundary

For the import note, a reader needs to know whether a queue grew, workers waited, jobs retried, or database connections ran out. Those details are not decoration. They locate the claim in a system that someone can inspect.

Plain meaning:

Do not replace a broad word with a fancier broad word. Replace it with the thing, action, signal, or constraint the reader needs to see.

In this lesson's scenario:

“Imports had reliability issues” can become “The import queue grew while workers retried database writes after the connection pool reached its limit.”

Technical name:

This is evidence-bounded specificity: use detail that makes a claim checkable, while marking what is observed, inferred, or still uncertain.

Build an Evidence Ladder

Specificity is strongest when the reader can follow the path from observation to conclusion. Use this ladder before adding a number or a confident cause.

The observation is evidence. The inference is a reasoned explanation. They should not be written as if they have the same strength.

For example, this sentence is too confident if the team has only a graph:

The connection pool caused every delayed import.

This version preserves useful uncertainty:

During the delay, the connection pool was full and workers retried database writes. That pattern likely increased queue time; we have not yet confirmed whether one client version also increased the retry rate.

The second version is not weaker. It tells the reader exactly what the team knows, what it suspects, and what to investigate next.

Check: Which sentence contains evidence-bounded specificity?

• A. “The platform had a significant performance incident.”
• B. “At 14:35, the import queue contained 8,400 jobs and workers were retrying database writes; the team is still checking why retry traffic increased.”
• C. “The database was definitely very overloaded in a major way.”

Think first, then reveal.

Answer: B. It names the object, observed state, and remaining uncertainty. A and C offer an impression without a checkable path.

A Worked Rewrite of an Incident Summary

Here is the original note again:

The import service had reliability issues under load. The team made improvements and the situation recovered.

It has three problems:

Assume the following fictional evidence is available:

1. At 14:05, the queue held 600 jobs.
2. Between 14:05 and 14:35, workers retried failed database writes.
3. At 14:35, the queue held 8,400 jobs and new file validation was delayed.
4. At 14:42, the team paused automatic retries and increased the connection-pool limit.
5. By 15:05, the queue had fallen below 1,000 jobs.

Now revise in passes.

The revised summary is:

Between 14:05 and 14:35, the import queue grew from 600 to 8,400 jobs while import workers retried failed database writes. New file validation slowed during that period. At 14:42, the on-call team paused automatic retries and raised the database connection-pool limit. By 15:05, the queue had fallen below 1,000 jobs. The team is still verifying whether retry traffic alone explains the initial pool exhaustion.

Trace what changed:

  vague incident impression
  -> queue, workers, database writes, and validation delay
  -> observed times and queue counts
  -> named intervention
  -> measured result plus an unresolved causal question

The naive failure was to call the event “reliability issues” and stop. The revision gives an operator a place to investigate, a manager a bounded impact statement, and a future writer a record of what still needs proof.

So far, specificity has not meant putting every log line into the note. It has meant choosing the few details that let a reader reconstruct the important path.

Keep Details That Carry Weight

Ask four questions about each detail:

1. Does it identify the actor, object, action, condition, or consequence?
2. Can the intended reader use it to verify, decide, or investigate?
3. Does it distinguish this event from a nearby but different event?
4. Does it need a confidence label such as observed, likely, or unknown?

If the answer is no, the detail may be noise.

For example, “the queue contained 8,400 jobs” helps if the reader needs to understand a backlog and compare later recovery. “The dashboard line was blue” does not help unless color itself signals a state. “CPU was 93.17%” is false precision if the dashboard only shows rounded values or if CPU did not affect the decision. “CPU remained above 90% for twenty minutes” may be useful when the threshold and duration explain a worker slowdown.

Useful verbs also carry weight. Prefer verbs that show what moved or changed:

Do not use a stronger verb to invent stronger evidence. “Triggered” claims a causal link. “Coincided with” may be the honest choice until the trace is complete.

Check: A dashboard rounds queue depth to the nearest hundred. Which sentence is best for a postmortem?

• A. “The queue reached exactly 8,437 jobs at 14:35.”
• B. “The queue was around 8,400 jobs at 14:35, according to the rounded dashboard.”
• C. “The queue was extremely enormous.”

Think first, then reveal.

Answer: B. It is concrete enough to inform the reader and honest about the measurement's resolution. A claims more precision than the dashboard provides; C cannot be checked.

Trade-offs and Limits

Evidence-bounded specificity improves trust, diagnosis, and revision. The trade-off is detail versus attention: every number, component name, and qualifier asks the reader to carry more information.

This technique helps when a document needs to explain a mechanism, report an incident, justify a decision, or describe a constraint. It does not require raw logs in every paragraph. A tutorial may need one representative result; a reference entry may need exact defaults; a broad executive summary may need one bounded impact statement and a link to evidence.

Specific language cannot repair missing evidence. If nobody recorded queue depth, do not manufacture a plausible number. Say what the team observed, state the uncertainty, and name the measurement needed next time. You can see the boundary when a detail does not change the reader's understanding, decision, or ability to verify the claim.

Common Confusions

Confusion: More numbers always make writing more precise

Why it is tempting:

Numbers sound objective and technical.

Better model:

Use a number when its source, unit, and resolution support the decision. Rounded, estimated, or sampled data should be described honestly.

Confusion: Specificity means listing every component

Why it is tempting:

An exhaustive inventory feels thorough.

Better model:

Keep the components that carry the causal path. Move supporting detail to a trace, table, or linked reference when it interrupts the main explanation.

Confusion: Strong verbs prove causality

Why it is tempting:

“Caused” and “triggered” make a note sound decisive.

Better model:

Choose verbs that match the evidence. Distinguish observed sequence, likely contribution, and confirmed cause.

Practice: Rewrite a Status Update

Rewrite this update for a team deciding whether to pause a rollout:

The new export process has some issues. Performance is worse and users are affected. We are looking into it and may make changes.

Use four to six sentences. Include:

• a specific object or workflow
• one observable signal with a source or confidence boundary
• the user-facing consequence
• an observed fact separated from an inference
• the next decision or investigation step

A good answer should:

• replace “issues,” “performance,” “users,” and “changes” with relevant nouns and verbs
• avoid inventing numbers, causes, or affected groups that the update does not support
• state whether a claim is observed, likely, or still unknown
• give the reader enough evidence to understand the rollout decision
• keep only details that serve the decision, not every implementation fact
• prepare one mechanism for lesson 006 to represent with an example, diagram, trace, or small model

Connections

Lesson 004 showed how a sentence, paragraph, and section create a path. This lesson makes the sentence's evidence visible and bounded. Lesson 006 will choose the representation—example, diagram, trace, or small model—that best exposes the same causal path.

Resources

• [COURSE] Clear Sentences — Google Technical Writing — Focus: choose strong verbs, clear subjects, and evidence rather than vague phrasing.
• [COURSE] Words — Google Technical Writing — Focus: use unambiguous, consistent terms and repair ambiguous references.
• [COURSE] Short Sentences — Google Technical Writing — Focus: keep one idea per sentence without removing the context needed for meaning.

Key Takeaways

• Specific nouns and useful verbs expose the object and action that a reader must inspect.
• Separate observation, inference, consequence, and uncertainty so the strength of each claim is visible.
• A detail earns its space when it helps a reader verify, decide, or investigate.
• False precision is not accuracy; match numbers and causal verbs to the evidence you actually have.
• Use enough detail to show the path, then choose a representation in lesson 006 that makes the path easier to inspect.