Review: Certainty and Commitment

LESSON

Technical English: Modals and Engineering Judgment

023 20 min beginner REVIEW

Review: Certainty and Commitment

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

  • Classify a technical sentence as possibility, evidence, advice, requirement, permission, or retrospective judgment.

  • Revise a vague review comment so each modal verb has one clear commitment level.

  • Prepare a short risk comment that is ready for the capstone.

Idea in one sentence: Modal verbs are commitment controls: they tell the reader how certain the claim is, who owns the action, and how strong the obligation is.

Core Insight

A team is deciding whether to ship a canary release for a new billing worker.

The first comment in the review thread says:

This can break payments, so we must be careful and maybe should rollback.

The worry is reasonable. The English is not precise enough.

Can break payments may sound like a normal capability, as if breaking payments is something the system is able to do. Must be careful is strong, but it does not name a concrete rule. Maybe should rollback mixes a weak hedge with a recommendation.

A clearer review comment separates the jobs:

The new worker might retry a timed-out payment and could send the same charge twice.
We should keep the canary at 5% until duplicate-charge alerts stay quiet.
If the duplicate rate rises, we must roll back before increasing traffic.

Now the reader can see the commitment scale.

might -> possible event
could -> possible consequence
should -> recommended control
must -> hard condition

This lesson reviews the whole track through that scale. The goal is not to choose the fanciest modal. The goal is to make the engineering judgment visible.

The Review Situation

Use one concrete scenario.

The team wants to route 5% of payment traffic to a new worker. The worker has better retry behavior, but the old worker and the new worker do not share all duplicate-request state yet.

The review notes say:

Evidence: duplicate-charge alerts are quiet today.
Risk: a timeout during the canary may trigger a retry.
Possible harm: the retry may send the same charge twice.
Recommendation: keep the rollout small while watching the alert.
Hard rule: roll back if duplicate charges appear.
Permission: support engineers may disable the canary for one customer.
Retrospective judgment: if the alert fires, the team should have blocked the traffic increase.

The naive model is:

Use a strong word when the situation is serious.

That model breaks because different serious sentences need different strengths.

A risk may be possible, not certain. A control may be recommended, not mandatory. A policy may be mandatory, not polite advice. A permission may allow an action without requiring it. A postmortem may judge a missed action without blaming a person.

Plain meaning:

Choose the modal that matches the job of the sentence.

In this scenario:

The retry might happen. The duplicate charge could happen. The small rollout should continue only while signals are quiet. The team must roll back if the safety signal crosses the line.

Technical name:

This is modal calibration. Calibration means matching the strength of the English sentence to the strength of the evidence, risk, authority, or rule.

The Commitment Scale

Use this table as a review map.

Job of the sentence Useful modal Example
capability can The worker can process refunds.
softer option could We could route 5% of traffic first.
specific past success was able to The old worker was able to recover after the queue drained.
uncertainty may / might The retry might send the same charge twice.
recommendation should We should keep the canary small.
strong warning had better We had better test rollback before launch.
external requirement have to We have to keep audit logs for billing events.
hard requirement must The worker must not charge twice for one payment id.
not required do not have to We do not have to retry read-only status checks.
permission may / can Support may disable the canary for one customer.
committed behavior will The service will reject repeated payment keys.
contract-style rule shall The endpoint shall return 409 for duplicate request ids.
inference from evidence must have The first request must have reached the provider.
weak past possibility might have The alert might have missed the first duplicate.
missed better action should have We should have blocked the traffic increase.
counterfactual result would have A shared idempotency store would have prevented the duplicate charge.

Do not memorize the table as a script. Use it as a diagnostic tool.

Ask:

The question tells you where to look on the scale.

A Worked Review

Start with the vague comment:

This can break payments, so we must be careful and maybe should rollback.

Input:

Change: route 5% of payment traffic to the new worker.
Risk path: timeout -> retry -> repeated charge request.
Signal: duplicate-charge alert.
Control: hold traffic at 5% while the alert is quiet.
Hard condition: rollback if duplicate charges appear.

Transition:

Give each piece one modal job.

Piece Intermediate state Better sentence
possible event retry is uncertain The new worker might retry a timed-out payment.
possible consequence harm is possible The retry could send the same charge twice.
recommended control small canary is the right next step We should keep the canary at 5% while duplicate-charge alerts stay quiet.
hard condition rollback is required if the signal appears If the duplicate rate rises, we must roll back before increasing traffic.

Output:

The new worker might retry a timed-out payment and could send the same charge twice.
We should keep the canary at 5% while duplicate-charge alerts stay quiet.
If the duplicate rate rises, we must roll back before increasing traffic.

Naive failure contrast:

This can break payments, so we must be careful.

That version uses strong words, but the reader still has to guess:

The revised version answers those questions. It is not longer because it is more formal. It is longer because the original sentence hid four different judgments inside one line.

So far, the habit is simple:

Do not make one modal carry four jobs.

Check Your Understanding

Check: Which sentence states a hard requirement?

The worker might retry after a timeout.
The retry could send the same charge twice.
We should hold the canary at 5%.
The team must roll back if duplicate charges appear.

Think first, then reveal.

Answer: The last sentence states the hard requirement. Must roll back marks a non-negotiable action under a specific condition.

Check: Why is this sentence weak for a risk review?

The canary can break payments, so maybe we must fix it.

Think first, then reveal.

Answer: It mixes meanings. Can break may sound like capability instead of risk. Maybe we must weakens a hard requirement. The sentence also does not name the control or the signal.

Trade-offs and Limits

Clear modal calibration improves a review comment because it separates evidence, risk, advice, permission, and rule.

The trade-off is speed versus precision. It costs a little extra thinking. You have to decide what kind of claim each sentence makes before you choose the modal.

It does not solve weak engineering analysis. If the risk path is wrong, precise English will only make the wrong risk path easier to inspect.

It also does not remove the need for numbers. A sentence like we should hold the canary becomes stronger when the condition is visible:

We should hold the canary at 5% until duplicate-charge alerts stay quiet for one hour.

You can see the boundary when a teammate asks:

Is this a possibility, a recommendation, or a launch blocker?

If the comment cannot answer that question, revise the modal force.

Confusion: must is always safer

Why it is tempting:

Serious production risks feel like they deserve the strongest word.

Better model:

Use must for rules, invariants, policies, and blockers. Use might or could for uncertain risk paths. A possible event is not clearer when you pretend it is a requirement.

Confusion: should is too weak for engineering advice

Why it is tempting:

Should can sound softer than must.

Better model:

Should is strong enough for a recommendation when the team still has judgment to apply. It says, "This is the better engineering move," without turning every recommendation into a contract.

Confusion: permission means recommendation

Why it is tempting:

May and can both appear in sentences about possible actions.

Better model:

Permission allows an action. It does not require the action and does not necessarily recommend it.

Support may disable the canary for one customer.

This means support is allowed to do it. It does not mean support must do it for every customer.

Practice: Prepare for the Capstone

Rewrite this rough comment:

The migration can be risky. We must maybe keep rollback ready and should not increase traffic.

Use this structure:

[possible event] might ...
[possible consequence] could ...
We should ...
If [hard condition], we must ...

Model answer:

The migration might lock the orders table during the canary and could slow checkout requests.
We should keep traffic at 5% until checkout latency stays below 300 ms.
If checkout errors rise above the rollback threshold, we must stop the migration and restore the old worker.

Why this works:

Daily Practice Lines:

Resources

Key Takeaways

PREVIOUS Practice: Write a Design Review Comment NEXT Capstone: Give Precise Advice on a Risky Change