Review: Certainty and Commitment
LESSON
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:
- Is this about what the system is able to do?
- Is this about what may happen?
- Is this about what the team recommends?
- Is this about what a rule requires?
- Is this about what evidence suggests happened?
- Is this about what would have changed the result?
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:
- Is the bad event certain or possible?
- What signal should the team watch?
- What action is recommended now?
- What condition makes rollback required?
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:
might lockkeeps the event uncertain;could slownames the possible consequence;should keeprecommends a concrete rollout control;must stopstates the hard condition for rollback.
Daily Practice Lines:
- 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.
Resources
- [ARTICLE] Cambridge Dictionary Grammar: Modals and modality
- Focus: Compare modal meanings for possibility, obligation, permission, and advice.
- [ARTICLE] Microsoft Writing Style Guide: Be clear and concise
- Focus: Keep technical sentences short and direct.
- [REFERENCE] Google API Improvement Proposals: AIP-155 Request Identification
- Focus: See why repeated technical actions need visible identifiers and clear rules.
Key Takeaways
- Modal verbs control commitment: possibility, evidence, advice, permission, requirement, and retrospective judgment.
- Stronger language is not always clearer. The modal must match the job of the sentence.
- A good risk comment separates possible event, possible consequence, recommended control, and hard condition.
- For the capstone, prepare one short artifact where each modal has one visible engineering job.
← Back to Technical English: Modals and Engineering Judgment