Must Not and Do Not Have To

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

• Use must not when a technical action is forbidden by a rule, safety boundary, or security policy.

• Use do not have to when an action is not required, without making it sound prohibited.

• Separate forbidden, optional, and unnecessary behavior in short API and rollout comments.

Idea in one sentence: Must not means forbidden; do not have to means not required.

Core Insight

Lesson 012 ended with this warning:

not necessary is not the same as forbidden

This lesson makes that contrast explicit.

Compare these two sentences:

The service must not expose private tokens.
The client does not have to send the legacy header.

They are both negative. They are not close in meaning.

Must not means the action is forbidden.

The service must not expose private tokens.

If the service exposes private tokens, the service violates a security rule.

Do not have to means the action is not required.

The client does not have to send the legacy header.

The client may send it if the API still accepts it, but the client is not required to send it.

The trade-off is small but serious: negative modal verbs are compact, but a compact negative sentence can change a system contract. One phrase removes a requirement. The other forbids an action.

The Small Situation

Imagine the customer export endpoint from the previous lessons.

The API returns export metadata:

• export id;
• status;
• created time;
• download URL;
• expiration time.

The old internal service also stores a private token used to sign the download URL. That token must stay inside the platform. If the API returns it to customers, customers may copy it into logs, tickets, or scripts. The token becomes hard to control.

A teammate writes this review comment:

The service does not have to expose private tokens.

That sounds negative, but it is too weak.

It says exposing private tokens is not required. That is true, but it does not say exposing them is forbidden.

The correct sentence is stronger:

The service must not expose private tokens.

Now the security boundary is clear. The token must stay private.

In the same review, the team also removes a legacy request header. The old API required this header:

X-Export-Mode: async

The new API uses async exports by default. New clients can omit the header.

Here the correct sentence is not must not:

The client does not have to send the legacy header.

That means the header is not required. It does not say the header is forbidden.

Forbidden, Optional, and Not Required

Put actions into three buckets.

The next lesson will spend more time on permission with can and may.

For now, focus on the negative contrast:

must not = forbidden
do not have to = not required

If you are writing a security rule, must not is often the right tool.

If you are simplifying a plan or API contract by removing an obligation, do not have to is often the right tool.

A Worked API Review

Here is a rough review comment:

Do not expose token. Header no need.

It points in the right direction, but it does not make the contract clear.

Step 1: write the forbidden action as a rule.

The export API must not expose private tokens.

Now the reader knows the boundary.

Step 2: write the unnecessary action as not required.

Clients do not have to send the legacy export-mode header.

Now the reader knows the old header is not required.

Step 3: add the reason for each sentence.

The export API must not expose private tokens because those tokens grant access to download URLs. Clients do not have to send the legacy export-mode header because async export is now the default.

Now the comment explains both rules.

Step 4: keep permission separate.

The export API must not expose private tokens because those tokens grant access to download URLs. Clients do not have to send the legacy export-mode header because async export is now the default. Clients may send one optional filter to limit the export by date.

The first sentence forbids a dangerous action.

The second sentence removes an old requirement.

The third sentence gives permission.

Three negative or optional-looking ideas are now separated.

A Deprecation Timeline

Negative modal verbs become especially important during migrations.

A header can move through several phases:

The same header has three different meanings over time.

In the old API, the header is required. A request without the header may fail.

During the transition, the header is not required. Old clients may still send it, but new clients can omit it.

After the cutoff date, the header is forbidden. The server may reject requests that still send it.

This is why a sentence like this is too vague:

The legacy header is deprecated.

Deprecated can mean several things. It may mean "still accepted but discouraged." It may mean "not required." It may mean "will be rejected later." The modal verb makes the current contract visible.

Better:

Clients do not have to send the legacy header during the transition. After 2026-09-01, clients must not send it.

Now the reader knows what is true today and what changes later.

A Review Comment Before and After

Here is a rough review comment:

Header optional, token no.

It may be clear to the person who wrote it. It is not clear enough for an API contract.

Step 1: separate the two objects.

The client does not have to send the legacy header. The service must not expose private tokens.

Now the old header and the private token are not mixed together.

Step 2: add the reason.

The client does not have to send the legacy header because async export is now the default. The service must not expose private tokens because those tokens grant access to download URLs.

Now the reader sees why one action is unnecessary and the other is forbidden.

Step 3: add timing if the rule changes later.

The client does not have to send the legacy header during the transition. After the cutoff date, clients must not send it. The service must not expose private tokens at any time.

This is a much better review comment. It separates current behavior, future behavior, and permanent security rules.

Where the Naive Idea Breaks

The naive idea is:

negative modal = no

That is not enough.

There are different kinds of "no."

The worker must not delete successful export records.

This means deletion is forbidden.

The worker does not have to reprocess successful export records.

This means reprocessing is not required.

Those sentences can lead to different implementations.

If the worker must not delete records, the code needs a guardrail:

Do not delete successful export records.

If the worker does not have to reprocess records, the code may skip unnecessary work:

Skip successful export records unless a manual repair asks for them.

The grammar changes the system behavior the reader expects.

What Tests Should Prove

Good negative-modal sentences often turn into tests.

For must not, the test should prove that the forbidden action cannot happen:

The service must not expose private tokens.

A useful test checks that the response body never includes the token field. If the field appears, the test fails.

For do not have to, the test is different:

Clients do not have to send the legacy header.

A useful test sends a request without the legacy header and checks that the request still succeeds.

These tests are not testing the same kind of rule.

The must not test protects a boundary.

The do not have to test proves that a dependency has been removed.

That is the technical reason the grammar matters. The modal does not only change tone. It changes what a reviewer, tester, or implementer should look for.

So far, the pattern is simple. If the sentence protects a safety or security boundary, prefer must not. If the sentence removes an old requirement, prefer do not have to. If the sentence is only advice, should not may be enough. The useful habit is to ask what would happen if someone ignored the sentence. Would they violate a rule, do extra work, or merely ignore advice?

Must Not vs Should Not

Should not is advice.

Must not is a rule.

Compare:

The service should not expose private tokens.
The service must not expose private tokens.

In a casual review, the first sentence is understandable. But for a security boundary, the second sentence is better.

Should not can sound like "this is a bad idea."

Must not sounds like "this is not allowed."

Use must not when the action would violate a contract, policy, safety boundary, or security rule.

Use should not when you are giving advice but not defining a hard prohibition:

We should not rename the field in this release because old clients still read it.

That sentence advises against a change. It is not necessarily a permanent rule.

Do Not Have To vs Need Not

Lesson 012 introduced need not:

The client need not resend successful export requests.

This is correct, but it sounds formal.

In most team communication, do not have to is more natural:

The client does not have to resend successful export requests.

Both mean "not necessary."

Neither means forbidden.

If resending is forbidden, use must not:

The client must not resend requests with private tokens.

The difference is worth repeating because it is one of the easiest places to create a dangerous misunderstanding.

Active Checks

Check: The API must never return private access tokens. Which sentence fits best?

A. The service must not expose private tokens.
B. The service does not have to expose private tokens.

Think first, then reveal.

Answer: A fits better. The action is forbidden, not merely unnecessary.

Check: The legacy header is no longer required because async export is now the default. Which sentence fits best?

A. Clients do not have to send the legacy export-mode header.
B. Clients must not send the legacy export-mode header.

Think first, then reveal.

Answer: A fits better if the header is simply not required. Use B only if the header is actually forbidden.

Common Confusions

Confusion: Do Not Have To Means Must Not

Why it is tempting:

Both forms are negative, and both can translate into Spanish with a sentence that starts with "no."

Better model:

Do not have to removes a requirement. Must not creates a prohibition.

Confusion: Must Not Is Just Strong Advice

Why it is tempting:

Learners often use must to sound serious, so must not can look like extra-serious advice.

Better model:

Must not should mark a real rule or boundary. If the action is only discouraged, use should not.

Confusion: Optional Means Forbidden Later

Why it is tempting:

During migrations, teams often deprecate a field before removing it.

Better model:

Be explicit about the phase:

Today, clients do not have to send the legacy header.
After the cutoff date, clients must not send the legacy header.

The same action can move from optional to forbidden when the contract changes. The date or condition matters.

Practice: Classify the Negative

Choose the best sentence for each situation.

Situation 1: A service response includes a field that would leak a private token.

A. The service must not expose private tokens.
B. The service does not have to expose private tokens.

Better: A. The action is forbidden.

Situation 2: A client used to send a header, but the new API no longer requires it.

A. The client does not have to send the legacy header.
B. The client must not send the legacy header.

Better: A, unless the API has explicitly banned the header.

Situation 3: A field is deprecated today and banned after the cutoff date.

A. Today, clients do not have to send the legacy field. After the cutoff date, clients must not send it.
B. Clients do not have to must not maybe send the field.

Better: A. It separates the current rule from the future rule.

Daily Practice Lines

Repeat these three lines during the day:

The service must not expose private tokens.
We do not need to rerun the full migration.
Clients may send one optional filter.

Then change one object:

private tokens -> raw passwords -> internal ids -> signing keys
legacy header -> optional filter -> deprecated field -> debug flag

Keep the difference sharp. Must not closes a door. Do not have to removes a required step.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Must - Use it to review obligation and prohibition with must and must not.
• [ARTICLE] Cambridge Dictionary Grammar: Have to, must and should - Use it to compare obligation, prohibition, necessity, and advice.
• [ARTICLE] Microsoft Writing Style Guide - Use it for clear technical wording and reader-friendly sentence choices.

Key Takeaways

• Must not means forbidden: The service must not expose private tokens.
• Do not have to means not required: The client does not have to send the legacy header.
• Negative modal verbs change contracts, so name whether the action is forbidden, optional, or simply unnecessary.