Review: Capability vs Possibility

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

• Choose between can, could, was able to, cannot, and could not in short technical updates.

• Separate a proven capability from a possible option, a possible risk, a past success, and a hard limit.

• Revise a design-review sentence so it says what the system can do without hiding what could still fail.

Idea in one sentence: A good modal tells the reader how strong the claim is: available capability, open possibility, achieved result, or blocked action.

Core Insight

The first four lessons gave you a small but powerful set of choices:

The worker can process two queues at once.
We could cache the response for one minute.
The team was able to restore traffic quickly.
The client cannot retry without a request id.

This review lesson makes those choices work together.

The central practice line is:

The system can recover, but it could still lose logs.

This sentence is useful because it does not overpromise.

Can recover says there is a real recovery capability.

Could still lose logs says a risk remains possible.

Both parts can be true at the same time. A system can recover traffic and still lose some logs. A worker can process two queues and still fall behind during backfill. A client can retry safe requests and still cannot retry payment requests without a request id.

That is the main review idea:

can = capability
could = possible option or possible risk
was able to = specific success
cannot = hard current limit
could not = hard past limit

The trade-off is precision versus simplicity. A short sentence like The system can recover is clean, but it may hide a remaining risk. A longer sentence can be more honest, but only if each modal has a visible job.

The Small Situation

Imagine a team reviewing a recovery design for a product API.

The system has two regions. If region eu-2 fails, the load balancer can route users to region eu-1. The team tested this failover during a game day.

So someone writes:

The system can recover.

That sounds good. It is not wrong. But it is too broad.

The system can recover traffic. That does not automatically mean it can preserve every log line, replay every event, or retry every request safely.

During failover, the API writes logs to a local buffer. If the buffer fills before the agent ships the logs, some logs may disappear. The design can restore user traffic, but operational evidence may be incomplete.

The better sentence is:

The system can recover, but it could still lose logs.

Now the reader sees both claims:

• capability: recovery is available;
• possibility: log loss remains a risk.

This is the sentence shape you want in many technical reviews:

The system can [good thing], but it could still [remaining risk].

It is precise without being dramatic.

The Review Map

Use this map when you are choosing a modal.

The same English word can move between jobs.

Could is the most important example. It can open an option:

We could cache the response for one minute.

It can also name a possible risk:

The system could still lose logs.

The subject helps you read it.

We could... often sounds like a team suggestion.

The system could... often sounds like a possible behavior or risk.

So do not translate one word at a time. Ask what job the sentence is doing.

Where the Naive Sentence Breaks

The naive review comment is:

The system can recover.

This sentence has one visible claim: recovery capability.

But the design review has more facts:

Traffic failover works.
Log shipping is asynchronous.
The local buffer can fill.
The team restored traffic in the last incident.
Missing logs cannot be replayed without event ids.

If you write only The system can recover, the reader may assume the whole recovery story is safe.

That is the break.

The sentence reports one capability but hides the boundary.

A better review comment is:

The system can recover traffic after a region failure, but it could still lose logs if the local buffer fills.

Now the sentence says exactly what is strong and what is still risky.

You can add the past success when it matters:

The team was able to restore traffic within ten minutes during the last incident.

You can add the hard limit when the design needs a fix:

The system cannot replay missing logs without stable event ids.

Each sentence has its own job. The review becomes clearer because the modals are not fighting each other.

A Worked Review Trace

Let us revise one design-review note.

Starting note:

The system can recover.

Step 1: name the exact capability.

The system can recover traffic after a region failure.

Now can is not vague. It points to traffic recovery, not every possible recovery promise.

Step 2: name the remaining risk.

The system can recover traffic after a region failure, but it could still lose logs if the local buffer fills.

Now could does useful work. It does not suggest an action. It names a possible failure.

Step 3: separate past evidence from current capability.

The team was able to restore traffic within ten minutes during the last incident.

This is not the same as can. It is one successful result. It supports confidence, but it does not prove every future recovery.

Step 4: name the hard limit.

The system cannot replay missing logs without stable event ids.

Now the reader knows what condition is missing.

Final review comment:

The system can recover traffic after a region failure, but it could still lose logs if the local buffer fills. The team was able to restore traffic within ten minutes during the last incident. The system cannot replay missing logs without stable event ids.

This is longer than the first sentence. It is also much safer. It separates capability, possible risk, past success, and hard limit.

Check: In the final review comment, which modal names the remaining risk?

Think first, then reveal.

Answer: Could names the remaining risk: it could still lose logs if the local buffer fills.

Common Confusions

Confusion: Can Means the Whole System Is Safe

Why it is tempting:

Can recover sounds strong and complete.

Better model:

Can should name the exact capability.

Too broad:
The system can recover.

Better:
The system can recover traffic after a region failure.

Then add any remaining risk:

The system can recover traffic after a region failure, but it could still lose logs.

Confusion: Could Always Means a Suggestion

Why it is tempting:

Lesson 002 used could for suggestions.

Better model:

Could can open an option or describe a possible risk. The subject and context tell you which job it is doing.

Option:
We could cache the response for one minute.

Risk:
The cache could serve stale data.

Confusion: Was Able To Proves the Future

Why it is tempting:

A past success feels reassuring.

Better model:

Was able to reports one successful result. It is evidence, not a permanent guarantee.

The team was able to restore traffic quickly.

That sentence is useful. But if the design changed, traffic changed, or logs are handled differently, you still need to state the current capability and the current risk.

Trade-offs and Limits

The trade-off in this review is between concise confidence and honest boundaries.

Concise confidence:

The system can recover.

This is easy to read. It is also easy to overread.

Honest boundary:

The system can recover traffic after a region failure, but it could still lose logs if the local buffer fills.

This costs a few more words. In exchange, the reader knows what is safe and what still needs attention.

Do not turn every sentence into a modal inventory. If one clear sentence is enough, use one clear sentence.

Use the full distinction when the reader might make the wrong decision from a vague claim.

You can see the boundary when a reviewer asks:

Recover what exactly?
Is that proven, proposed, possible, or blocked?
What can still fail?

Those questions are a signal that the modal needs more precision.

Practice

Classify each sentence.

1. The worker can process two queues at once.
2. We could cache the response for one minute.
3. The team was able to restore traffic quickly.
4. The client cannot retry without a request id.
5. The client could not retry because the request id was missing.
6. The system can recover, but it could still lose logs.

Model answers:

1. current capability
2. possible option
3. specific successful result
4. current hard limit
5. past hard limit
6. capability plus possible risk

Now revise this vague review comment:

The system can recover.

Model answer:

The system can recover traffic after a region failure, but it could still lose logs if the local buffer fills.

Stronger answer when you have evidence and a known limit:

The system can recover traffic after a region failure, but it could still lose logs if the local buffer fills. The team was able to restore traffic within ten minutes during the last incident. The system cannot replay missing logs without stable event ids.

Daily Practice Lines

Repeat these three lines during the day:

The system can recover, but it could still lose logs.
The client cannot retry without a request id.
The team was able to restore traffic quickly.

Then change one piece:

recover traffic -> process jobs -> route users -> replay events
lose logs -> serve stale data -> duplicate a payment -> miss an alert
request id -> idempotency key -> valid token -> stable event id

Keep the review small. You are training this question:

Am I stating a capability, opening a possibility, reporting a result, or naming a limit?

The next lesson adds a new kind of uncertainty:

The spike might be related to the deploy.

That is different from could as an option or risk. It is about evidence that is not complete yet.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Can, could or be able to - Use this to review the basic grammar forms before applying them to technical commitment.
• [ARTICLE] Microsoft Writing Style Guide - Use this to keep review comments direct while still naming boundaries.
• [ARTICLE] Google SRE Book: Managing Incidents - Use this for the operational context behind recovery, evidence, and remaining risk.

Key Takeaways

• Can states a current capability: The system can recover traffic after a region failure.
• Could can open an option or name a possible risk: The system could still lose logs.
• Was able to reports one successful result: The team was able to restore traffic quickly.
• Cannot names a hard current limit: The client cannot retry without a request id.
• A useful review sentence can combine confidence and caution: The system can recover, but it could still lose logs.