Can for Capability and Technical Possibility

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

• Explain when can means real system capability, not only a possible idea.

• Classify short technical sentences where can means ability, permission, or general possibility.

• Rewrite vague capability claims into clear engineering sentences.

Idea in one sentence: Can is useful when it tells the reader what a system, person, or tool is able to do under the current conditions.

Core Insight

A small English word can carry a serious engineering claim.

When you write:

The worker can process two queues at once.

you are not only saying a grammar pattern. You are making a capability claim.

The reader may understand it as:

• the code supports this behavior;
• the worker has enough resources;
• the configuration allows it;
• the team has tested it;
• the behavior is available now, not only imaginable.

That is why can is the first modal in this track. It looks simple. It is also the word people use when they are not yet sure whether they mean ability, permission, or possibility.

This lesson builds the first mental model for the track:

can = ability under some conditions

Sometimes the condition is obvious:

The admin can restart the service.

Sometimes the condition needs to be said:

The worker can process two queues at once when each queue has fewer than 1,000 pending jobs.

The trade-off is small but important. Can keeps a sentence short and direct. It can also hide the condition that makes the claim true. A good engineering sentence uses can, then adds the condition if the reader could make a risky decision from the claim.

The Small Situation

Imagine a team preparing a small deploy.

They are changing a background worker. Today the worker reads from one queue:

queue: image-resize
worker: resize-worker-1

After the change, the worker should read from two queues:

queue: image-resize
queue: thumbnail-refresh
worker: resize-worker-1

The team wants to write a release note:

The worker can process two queues at once.

That sentence is natural English. It is short. It is useful.

But before the team ships, someone asks a good question:

Can it do that in production traffic, or can it only do that in a local test?

Now the grammar problem becomes an engineering problem.

If the sentence means "the code has this feature", it is a capability claim.

If the sentence means "this design might be possible someday", it is a possibility claim.

If the sentence means "the worker is allowed to read from both queues", it is a permission claim.

The word is the same. The meaning is not.

The Naive Idea

The naive idea is:

Use can whenever Spanish would use puede.

That works in many simple sentences:

The API can return JSON.
The script can delete old files.
The dashboard can show the error rate.

These are useful sentences. They name a technical object and a capability.

The problem is that can is flexible. It can mean several nearby things:

The worker can process two queues.

This may mean:

• It has the ability.
• It has permission.
• It is technically possible.
• Someone is suggesting an option.

In casual conversation, the reader may guess correctly. In technical work, guessing is expensive. A reviewer may approve a risky deploy because the sentence sounded more tested than it was.

So the better question is not "Can I use can here?"

The better question is:

What kind of claim am I making with can?

The Precise Meaning

Plain meaning:

Can says that something is able to happen.

In this scenario:

The worker has code, configuration, and enough runtime capacity to read from two queues at the same time.

Technical name:

This is a capability claim.

A capability claim connects three pieces:

The actor must be visible. The action must be concrete. The condition must be present when it matters.

Compare these:

It can be done.

This is vague. What can be done? By what? Under what condition?

The worker can process two queues during normal traffic.

This is clearer. The actor is visible. The action is visible. The condition is still broad, but at least the reader knows the claim is about normal traffic.

The worker can process two queues during normal traffic, but it cannot keep up during the nightly backfill.

This is much better for engineering work. It tells the reader where the capability stops.

Worked Classification

Let us classify four sentences.

The same word appears in every sentence. The surrounding words decide the technical meaning.

Look at the actor:

• The worker points to system ability.
• Admins points to permission.
• We often points to an option or suggestion.
• The API plus during failover points to possible behavior under a condition.

Now rewrite the release note with more precision:

Before:
The worker can process two queues at once.

After:
The worker can process the image-resize and thumbnail-refresh queues at the same time during normal traffic.

The revised sentence is not fancy. It is better because it says what the capability is attached to.

If the team has not tested production-like traffic, the honest sentence changes:

The worker can process both queues in staging, but we have not tested nightly backfill traffic yet.

That sentence is longer. It is also safer. It stops the reader from hearing more certainty than the evidence supports.

Where Can Breaks

Can breaks when the reader needs a stronger or narrower meaning.

Confusion: Can vs Could

Why it is tempting:

Both words can talk about possible actions.

Better model:

Use can when the capability is available now. Use could when you are suggesting an option or speaking more tentatively.

Available now:
The worker can process two queues.

Possible option:
We could split the queues across two workers.

Lesson 002 will focus on could. For now, notice the pressure: can sounds more direct and more available.

Confusion: Can vs May

Why it is tempting:

Both words can appear in sentences about allowed actions.

Better model:

In everyday technical English, can often means permission, especially with users, roles, and admins. May sounds more formal and is useful when permission needs to be explicit.

Natural product/API wording:
Users can export their own reports.

More formal permission wording:
Users may export their own reports if the export feature is enabled.

This track returns to permission in lesson 014. Today, the important point is simple: if permission is the real issue, make the actor and rule visible.

Confusion: Can vs Is Able To

Why it is tempting:

Both can describe ability.

Better model:

Use can for general or current ability. Use was able to or is able to when the sentence is about a specific success, failure, or attempt.

General ability:
The worker can process two queues.

Specific result:
The worker was able to drain both queues before the deploy window ended.

Lesson 003 will use this distinction to connect capability with evidence and time.

A Small Trace

Here is a tiny capability trace for the worker.

The first sentence is true, but incomplete. Each later sentence adds the condition that makes the claim useful.

This is the pattern to remember:

actor + can + action + condition when needed

Do not add every condition every time. That would make every sentence heavy.

Add the condition when the reader might use the sentence to make a decision.

Here is the same pattern in an API sentence:

The API can return 404 when the resource does not exist.

This is not a sentence about failure in general. It is a sentence about one allowed and expected behavior. The actor is The API. The action is return 404. The condition is when the resource does not exist.

If you remove the condition, the sentence becomes weaker:

The API can return 404.

That is still true, but the reader may not know whether 404 is expected, accidental, user-caused, or a sign of a broken route. The condition tells the reader how to interpret the behavior.

Now compare it with permission:

Support agents can resend the invite email.

Here can is not mainly about system capacity. It is about what a role is allowed to do. The actor is a person or role, not a service. That is a useful clue.

Check: Which sentence is safest for a release note?

A. It can process queues.

B. The worker can process both queues in staging, but production backfill still needs a load test.

C. The worker can probably handle it.

Think first, then reveal.

Answer: B is safest. It names the actor, the action, the tested condition, and the missing evidence. A is too vague. C hides the condition behind probably.

Trade-offs and Limits

Using can well improves clarity. It gives the reader a direct capability claim:

The dashboard can show per-region latency.

It costs a little care. You must decide whether the condition matters:

The dashboard can show per-region latency after the new metric label is enabled.

It can still fail when the sentence hides evidence:

The system can recover automatically.

That sounds strong. But maybe it only recovered once in a test. A safer sentence may be:

The system recovered automatically in staging after one worker crashed.

Notice the trade-off. Can is clean and reusable. Evidence language is more specific. Good technical English chooses the sentence that fits the decision.

Use can when you want to state a reusable capability.

Use a past-tense evidence sentence when you want to report what actually happened.

The signal that your can sentence is too broad is a reader asking:

Under what condition?
Who is allowed?
Have we tested that?

Those questions do not mean the sentence is bad. They mean the capability claim needs a boundary.

Practice

Rewrite each vague sentence into a capability sentence.

Use this pattern:

actor + can + action + condition when needed

1. It can be changed.
2. This can work.
3. Users can do it.

Model answers:

1. The deploy script can change the worker count without restarting the API.
2. The cache can reduce read load when the same product page is requested many times.
3. Admin users can export audit logs from the settings page.

Now write three Daily Practice Lines.

Repeat them during the day:

The worker can process two queues at once.
The API can return JSON and CSV.
Admins can restart the service during the maintenance window.

Change one noun at a time:

worker -> API -> deploy script -> dashboard -> cache

Keep the sentence small. Make the actor visible. Add the condition only when it changes the meaning. That small discipline is enough for the first lesson: one actor, one action, one honest boundary.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Can - Use this to compare ability, permission, and possibility uses of can.
• [ARTICLE] Microsoft Writing Style Guide: Bias-free communication - Use this as a practical reminder that clear technical language should name actors and actions directly.
• [ARTICLE] MDN Web Docs: HTTP response status codes - Use this to practice capability sentences such as The API can return 404 when the resource does not exist.

Key Takeaways

• Can is strongest when it names a visible actor and a concrete action.
• In technical English, can may mean capability, permission, or possibility; classify the meaning before trusting the sentence.
• Add a condition when a capability claim could affect a design, release, support, or incident decision.
• The first useful pattern in this track is: actor + can + action + condition when needed.