Review: Requirement, Advice, and Risk

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

• Classify a technical sentence as uncertainty, requirement, external pressure, recommendation, or warning.

• Rewrite vague engineering comments with the modal verb that matches the evidence and risk.

• Combine must, should, have to, ought to, had better, and might in one short review comment.

Idea in one sentence: A modal verb is a commitment marker: it tells the reader whether you are guessing, requiring, advising, reacting to pressure, or warning about risk.

Core Insight

This review connects the second cluster of the track.

You have seen these lines:

The spike might be related to the deploy.
Every request must include an idempotency key.
We have to rotate the key before Friday.
The alert should fire before users notice.
We had better pause the migration.

Each sentence is short. The difference is not length. The difference is commitment.

Might keeps evidence open. Must states a hard rule. Have to points to external pressure. Should gives a recommendation or expected behavior. Ought to gives reasoned advice. Had better gives advice with a warning.

The trade-off is precision versus speed. A quick sentence is easy to write, but the wrong modal can make advice sound like a rule, a rule sound optional, or a hypothesis sound proven.

The Small Situation

Imagine a team adding a customer data export endpoint.

The endpoint creates a file with user emails, order ids, and billing events. The file is stored for 24 hours, then deleted. Customers can request the export from the admin UI.

During review, the team sees five facts:

• the export contains sensitive data;
• the legal audit is on Friday;
• the first staging run produced a latency spike;
• the team has not confirmed whether the spike came from the export worker;
• the migration lesson taught that rising lag can turn advice into warning.

A vague review comment says:

Encrypt it. Maybe log something. Pause if bad.

The ideas are not crazy. The language is doing too little work.

A better review separates the claims:

Export files must be encrypted at rest. We should log the approval decision. The staging spike might be related to the export worker, so we had better pause the rollout if queue lag keeps growing.

Now the reader sees three different jobs:

• must for the security requirement;
• should for useful audit advice;
• might for uncertain evidence;
• had better for a warning if the risk becomes close.

The Commitment Ladder

Use this ladder when you revise a technical sentence.

The ladder is not a grammar ranking from "nice" to "angry." It is a map of what kind of claim you are making.

Ask:

Is this evidence, rule, pressure, advice, or warning?

Then choose the modal.

Worked Classification

Here are six rough comments from the export review.

Notice how the technical object stays visible:

• the staging spike;
• export files;
• the audit notes;
• the approval decision;
• queue lag.

The modal is not enough by itself. A good sentence also names the object and the condition.

The Three Questions Before You Write

Before choosing a modal, ask three small questions.

First:

What do we know?

If the answer is incomplete evidence, use uncertainty language:

The staging spike might be related to the export worker.

Second:

What is forcing the action?

If the force is a design rule, use must:

Export files must be encrypted at rest.

If the force is a date, audit, vendor policy, or external situation, use have to:

We have to finish the audit notes before Friday.

Third:

How close is the risk?

If the action is a good recommendation, should is usually enough:

We should log the approval decision.

If the action is responsible follow-up, ought to may fit:

We ought to document why exports are retained for 24 hours.

If the signal is getting worse, had better may fit:

We had better pause the rollout if queue lag keeps growing.

These questions are slow at first. With practice, they become a quick mental check before you write the sentence.

Active Checks

Check: You are writing a security contract. Which sentence fits better?

A. Export files should be encrypted at rest.
B. Export files must be encrypted at rest.

Think first, then reveal.

Answer: B fits better. In a security contract, encryption is a hard rule, so must is clearer than should.

Check: Staging latency rose after the export worker ran, but you have not confirmed the cause. Which sentence fits better?

A. The export worker caused the spike.
B. The staging spike might be related to the export worker.

Think first, then reveal.

Answer: B fits better. The evidence is incomplete, so might keeps the investigation open.

Common Confusions

Confusion: Making Every Important Sentence Use Must

Why it is tempting:

Must sounds serious, and technical work often feels serious.

Better model:

Use must only when the sentence is a rule or required property. If the sentence is advice, use should or ought to. If it is a warning, use had better.

Confusion: Using Should for a Hidden Requirement

Why it is tempting:

Should sounds collaborative, so it feels safer in review comments.

Better model:

Politeness should not hide a security or correctness requirement. Write the rule as a rule, then add advice separately.

Export files must be encrypted at rest, and we should log the approval decision.

Confusion: Treating Have To and Must as Identical

Why it is tempting:

Both can feel strong in Spanish translation.

Better model:

Must usually states a rule inside the design. Have to usually points to pressure from outside the design.

Export files must be encrypted at rest.
We have to finish the audit notes before Friday.

Transfer Challenge

Rewrite this rough review comment:

Secure the export. Audit Friday. Maybe worker slow. Stop rollout if queue bad.

Model answer:

Export files must be encrypted at rest. We have to finish the audit notes before Friday. The staging spike might be related to the export worker, so we had better pause the rollout if queue lag keeps growing.

This answer is not the only possible version. A good version should do four things:

• use must for the security rule;
• use have to for the external deadline;
• use might for incomplete evidence;
• use had better only if the warning is tied to a real signal.

What Comes Next

The next lesson adds need to.

That phrase often lives inside an engineering plan:

We need to backfill the missing rows.

This is different from the review ladder in this lesson. Need to usually says that a task is necessary for the plan to work. It may be less formal than must, less deadline-driven than have to, and less warning-like than had better.

So keep this review map in mind. When you meet need to, ask whether the sentence is naming a required task inside the work plan, not a rule, not a hypothesis, and not a warning.

Daily Practice Lines

Repeat these three lines during the day:

We must encrypt it, and we should log the decision.
We had better pause the migration.
The spike might be related to the deploy.

Then change the object:

export file -> token -> webhook payload -> audit note

Keep the practice small. The goal is to feel the difference between rule, advice, pressure, uncertainty, and warning.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Modals - Use it as a compact reference for modal meaning and modality.
• [ARTICLE] Microsoft Writing Style Guide - Use it for clear technical wording and reader-friendly sentence choices.
• [ARTICLE] Google SRE Book: Managing Incidents - Use it as context for careful uncertainty, evidence, and action language during incidents.

Key Takeaways

• Choose the modal by the job of the sentence: uncertainty, rule, pressure, advice, or warning.
• Must is for hard rules; have to is for external pressure; should and ought to are for advice; had better is for warning.
• A good review comment can combine modals, but each modal should have a clear reason.