Using Modal Verbs in Instructions and Written Rules

Modal verbs shape the tone of directions and formal guidelines by showing how strong a message is. They signal whether an action is required, recommended, permitted, or simply possible, so readers understand what to do and how much flexibility they have. In notices, manuals, and classroom tasks, choosing the right modal reduces confusion and keeps instructions polite yet clear.

How modal verbs appear in written instructions and guidelines

In procedural writing, modal verbs help signal whether something is required, recommended, allowed, or discouraged. The same action can sound like a strict rule or a helpful suggestion depending on the modal chosen, so writers often rely on a small set of predictable patterns to keep directions clear and consistent.

Common patterns used in rules and procedures

• Requirement (strong obligation): must + base verb (e.g., “Users must reset their password every 90 days.”)
• Prohibition: must not / mustn’t + base verb (e.g., “You must not share your access code.”)
• External rule or policy obligation: have to + base verb (e.g., “Visitors have to sign in at reception.”)
• Recommendation (best practice): should + base verb (e.g., “You should back up files before updating.”)
• Stronger recommendation: ought to + base verb (e.g., “You ought to label all containers clearly.”)
• Permission: may + base verb (e.g., “You may request an extension in writing.”)
• Informal permission: can + base verb (e.g., “You can use the side entrance after 6 p.m.”)
• Conditional permission: may/can + base verb + if/when clause (e.g., “You may proceed if the indicator light is green.”)
• Ability/capability (not permission): can + base verb used for what is possible (e.g., “This device can overheat in direct sunlight.”)
• Expectation or typical outcome: will + base verb (e.g., “The system will restart automatically.”)
• Instruction framed as a polite command: will + base verb in formal notices (e.g., “You will present ID upon entry.”)
• Negative recommendation: should not + base verb (e.g., “You should not unplug the unit during calibration.”)
• Soft prohibition or warning: may not + base verb meaning “is not permitted” in formal contexts (e.g., “Employees may not install unapproved software.”)
• Warning about risk: may/can + base verb for potential problems (e.g., “Loose cables may cause tripping hazards.”)
• Optional step: can + base verb or may + base verb (e.g., “You can add notes to the report.”)
• Reduced obligation in exceptions: do not have to / don’t need to + base verb (e.g., “You don’t have to submit receipts under $10.”)

How writers signal strength and authority

• must is typically reserved for non-negotiable requirements; it reads as a firm rule rather than advice.
• have to often points to an outside requirement (law, policy, system constraint), which can make the instruction feel less like a personal command.
• should works well for guidance, safety tips, and quality standards when exceptions are possible.
• may is common in formal guidelines because it clearly marks permission and keeps the tone neutral.
• can is useful for user-friendly instructions, but it can blur the line between permission and capability if the context is not explicit.

Typical sentence frames you’ll see in guidelines

• “You must ___ before ___.”
• “You must not ___ while ___.”
• “You should ___ to avoid ___.”
• “You may ___ if ___.”
• “You may not ___ unless ___.”
• “You can ___ using ___.”
• “The device will ___ when ___.”
• “If ___, you must ___.”
• “Before you ___, you should ___.”
• “To ___, you may ___.”

Common clarity issues (and how to avoid them)

• ✅ “You must wear gloves.” → clear requirement
  ❌ “You should wear gloves.” (if it is actually mandatory)
• ✅ “You may enter after scanning your badge.” → permission
  ❌ “You can enter after scanning your badge.” (could be read as “it is possible,” not “it is allowed”)
• ✅ “You don’t have to submit the form.” → no obligation
  ❌ “You mustn’t submit the form.” (changes meaning to prohibition)
• ✅ “Employees may not install software.” → not permitted (formal)
  ❌ “Employees can’t install software.” (could imply inability rather than a rule)

Common modal verbs used to express obligation, permission, or advice

In instructions and written rules, modal verbs help you show how strong a requirement is, whether something is allowed, or what is recommended. The most useful patterns are modal + base verb (no to): must wear, may enter, should check.

Obligation (strong requirement)

• must + base verb: strongest rule from the writer/authority. Example: “Users must reset their password every 90 days.”
• have to + base verb: obligation that can sound more practical or external. Example: “You have to sign in to view your account.”
• need to + base verb: focuses on necessity to achieve a result. Example: “You need to back up files before updating.”
• must not / mustn’t: prohibition (not “lack of obligation”). Example: “You must not share your access code.”
• cannot / can’t: often used for rules that are framed as not allowed or not possible in a system. Example: “You can’t edit the form after submission.”

Permission (allowed or not allowed)

• may + base verb: formal permission; common in policies. Example: “Staff may work remotely with approval.”
• can + base verb: neutral, everyday permission; also used for capability, so context matters. Example: “You can save your progress at any time.”
• may not: formal way to say something is not permitted. Example: “Visitors may not enter restricted areas.”
• can’t / cannot: direct, plain-language prohibition. Example: “You cannot park in front of the gate.”

Advice and recommendations (best practice, not a strict rule)

• should + base verb: standard recommendation. Example: “You should review the summary before confirming.”
• ought to + base verb: similar to should, slightly more formal. Example: “You ought to label all containers clearly.”
• had better + base verb: strong advice with an implied consequence; use carefully in formal documents. Example: “You had better disconnect power before opening the panel.”

Useful patterns and common pitfalls

• Use the base verb after a modal: ✅ “You must submit the form.” ❌ “You must to submit the form.”
• To express “no obligation,” prefer don’t have to / do not need to: “You don’t have to create an account to browse.”
• Avoid using mustn’t when you mean “not necessary”: ✅ “You don’t need to print the receipt.” ❌ “You mustn’t print the receipt.”
• For clear rule writing, keep one modal per requirement: “Users must verify identity” is clearer than mixing “must” and “should” in the same sentence.
• Choose formality to match the document: policies often use must/may; quick-start guides often use have to/can/should.

Examples from manuals, policies, and official documents

Formal instructions often rely on a small set of modal verbs to signal obligation, permission, prohibition, and recommendations. The patterns below show how writers keep rules clear by pairing a modal with a precise action verb, a defined subject (user/employee/system), and any needed conditions or exceptions.

Common modal patterns and what they do

• Must + base verb for non-negotiable requirements: “Operators must wear protective eyewear in designated areas.”
• Must not + base verb for strict prohibitions: “Users must not share their passwords with anyone.”
• Shall + base verb for binding rules in policies/contracts: “The contractor shall provide monthly status reports.”
• Shall not + base verb for formal bans: “The device shall not be operated in explosive atmospheres.”
• Should + base verb for recommendations or best practice: “You should back up data before installing updates.”
• Should not + base verb for discouraged actions: “Employees should not store confidential files on personal devices.”
• May + base verb for permission: “Visitors may use the public Wi‑Fi in the lobby.”
• May not for lack of permission (often policy-based): “Staff may not approve expenses without documentation.”
• Can for capability or general possibility (not authority): “The system can generate a report in PDF format.”
• Cannot for technical limits: “The unit cannot operate below 0°C.”
• Will for stated outcomes or system behavior: “The application will log you out after 15 minutes of inactivity.”
• Need to for practical necessity (less legal than “must”): “You need to restart the router after changing settings.”

Typical wording from different document types

• Safety manuals often combine obligation + condition: “You must disconnect power before servicing the unit.”
• IT acceptable-use policies use prohibition with scope words (any, ever, under any circumstances): “Users must not install unauthorized software on company devices.”
• HR policies use “shall” for formal duties and “may” for discretionary actions: “Employees shall report conflicts of interest. Management may request additional documentation.”
• Data handling rules clarify permission boundaries: “Customer data may be accessed only for approved business purposes.”
• Procedures use “should” to separate best practice from mandatory steps: “You should verify the serial number before shipping.”
• Terms and conditions use “will” for what the service does and “may” for reserved rights: “The service will send notifications. The company may suspend accounts for repeated violations.”

Drafting patterns that reduce ambiguity

• Put the modal early and keep the verb specific: “Staff must submit the form” (clearer than “Staff must ensure submission”).
• Use one modal per rule when possible; avoid stacking: ❌ “Users must not be allowed to…” → ✅ “Users must not…”
• State the actor explicitly instead of relying on passive voice: “Supervisors shall approve timesheets” (not “Timesheets shall be approved”).
• Add conditions with “before/after/when/unless” to prevent overbroad rules: “Devices must be encrypted before they are issued to staff.”
• Reserve “may” for permission and “can” for ability; mixing them can confuse authority with capability.
• When exceptions exist, attach them to the same sentence or the next line: “Employees must badge in at entry points, unless the system is offline.”
• For measurable requirements, pair the modal with a number or timeframe: “Reports shall be retained for seven years.”
• For system behavior, prefer “will” over “shall” in user-facing software notes: “The app will display an error message if the upload fails.”

How modal verbs distinguish strict rules from recommendations

Instructional writing often needs to separate what is mandatory from what is merely suggested. Modal verbs do that work quickly: they signal obligation, permission, prohibition, or advice, and they also set the tone (firm, neutral, or polite). Choosing the right modal helps readers understand what they must do, what they may do, and what they should consider doing.

Use strong modals for non-negotiable requirements

When a rule is enforceable (policy, safety, compliance, exam conditions), use modals that clearly mark obligation or prohibition. Avoid “softening” language in these cases, because it can create loopholes.

• Must + base verb for obligation: “Employees must wear ID badges.”
• Must not / mustn’t for strict prohibition: “You must not share your password.”
• Have to for externally imposed rules (often similar to must): “Visitors have to sign in at reception.”
• Cannot / can’t for disallowed actions, especially in rules and UI text: “You can’t submit the form without an email address.”
• May not for formal prohibition (common in legal/policy style): “Participants may not record the session.”
• Will for fixed procedure or system behavior (not a choice): “The system will log you out after 10 minutes.”
• Shall for formal rule statements (contracts/specs): “The tenant shall pay rent on the first day of each month.”

Use softer modals for guidance and best practice

When the goal is to steer behavior without making it a condition, use modals that express recommendation, preference, or possibility. These forms keep the instruction helpful while leaving room for exceptions.

• Should for strong recommendation: “You should back up your files before updating.”
• Should not for discouraged actions: “You shouldn’t store food near chemicals.”
• Ought to for advice (more formal, less common): “Users ought to review settings after installation.”
• Can for options and ability: “You can save your progress and return later.”
• May for permission or acceptable variation: “You may use either format.”
• Could for gentle suggestions or alternatives: “You could restart the app if the screen freezes.”
• Might for tentative advice or low-certainty outcomes: “You might need extra time during peak hours.”

Pattern cues that readers interpret as “rule” vs “tip”

Beyond the modal itself, common patterns reinforce how strict the message is. Pair firm modals with clear conditions and consequences; pair advisory modals with reasons and flexibility.

• Rule pattern: “If X happens, you must do Y.”
• Rule pattern with enforcement: “You must do Y, or Z will occur.”
• Rule pattern for prohibition: “You must not do Y during X.”
• Recommendation pattern: “You should do Y to improve X.”
• Recommendation with exception: “You should do Y unless X applies.”
• Option pattern: “You can do Y if you prefer.”
• Permission pattern: “You may do Y, provided that X.”
• Suggestion pattern: “If X occurs, you could try Y.”
• Uncertainty pattern: “You might need Y when X happens.”
• Procedure pattern: “The device will do Y after X.”

Avoid mixed signals and unintended loopholes

• ❌ “You should wear a helmet.” (sounds optional) → ✅ “You must wear a helmet.” (mandatory)
• ❌ “You may not enter without a badge.” (can be misread as “maybe you won’t”) → ✅ “You must not enter without a badge.” or “You cannot enter without a badge.”
• ❌ “You must try to submit by Friday.” (unclear obligation) → ✅ “You must submit by Friday.” or “You should submit by Friday if possible.”
• ❌ “Users will not share accounts.” (sounds like prediction) → ✅ “Users must not share accounts.”
• ❌ “You have to consider updating.” (awkward, unclear) → ✅ “You should consider updating.”

How context determines the strength of a written instruction

The same modal verb can sound like a firm rule, a polite request, or a simple suggestion depending on where the instruction appears and who is expected to follow it. Readers infer strength from the document type, the relationship between writer and reader, and what happens if the instruction is ignored.

Context cues that change how “strong” a modal sounds

• Document type: A safety policy makes must and shall feel non-negotiable; a quick-start guide makes should feel like a recommendation.
• Authority and role: Instructions from an employer, regulator, or system admin carry more force than instructions from a peer.
• Audience size: Messages to a whole organization tend to use more formal, rule-like modals (must, may not) than one-to-one messages.
• Risk level: When harm, legal exposure, or data loss is possible, writers typically choose obligation/prohibition forms (must, must not).
• Enforcement and consequences: If the text names a penalty, audit, or system block, even should can be read as near-mandatory.
• Placement in the document: A “Policy” or “Requirements” section strengthens modals; a “Tips” or “Notes” box weakens them.
• Formatting signals: Headings like “Required,” warning labels, and numbered steps increase perceived obligation even without changing the verb.
• Specificity: Concrete, testable actions (“submit the form within 24 hours”) feel stricter than general guidance (“respond promptly”).
• Time pressure: Deadlines and frequency words (“immediately,” “weekly”) make the instruction sound more binding.
• Conditional language: “If X happens, you must…” is interpreted as a firm rule inside that condition, even if the overall document is informal.
• Permission frameworks: In controlled environments, may often means “allowed only under these conditions,” not “optional.”
• Negative forms: Prohibitions (must not, may not) are usually read as stricter than positive duties (must), because they imply clear boundaries.
• Consistency across the document: If must is used elsewhere for hard requirements, readers will treat it as the strongest form throughout.
• Local norms and style guides: Some organizations reserve shall for legal language; others avoid it entirely, which changes how readers interpret it.

Common patterns: matching modals to situations

• must / must not for safety, compliance, security, and other non-optional rules.
• should / should not for best practice, strong advice, and quality standards that allow exceptions.
• may / may not for permission and prohibition in controlled processes (access, eligibility, approvals).
• can for capability or system behavior (what the user or software is able to do), not for granting permission in formal rules.
• need to for practical necessity in procedures; it often reads as firm but slightly less formal than must.

Mini-examples: how the same modal shifts with context

• In a safety sign: “You must wear eye protection.” (treated as a strict requirement)
• In a friendly team note: “You must try this shortcut.” (often read as emphasis, not a literal rule)
• In a policy: “Employees may access records only for work purposes.” (permission with limits)
• In a casual message: “You may want to restart your laptop.” (suggestion, not permission)
• In documentation: “The device can store up to 10 profiles.” (capability)
• In a ruleset: ✅ “Users may create one account.” ❌ “Users can create one account.” (permission is clearer with may)

When drafting instructions, choose the modal that matches the intended obligation, then reinforce it with context: place it in the right section, state conditions and consequences when relevant, and keep usage consistent so readers don’t have to guess how strong each rule is.

How readers interpret modal verbs in formal rule statements

In rule-like writing, readers treat modal verbs as signals of strength: whether something is mandatory, allowed, recommended, or merely possible. Small wording choices change how enforceable a sentence feels, how much discretion the reader believes they have, and how likely they are to challenge or ignore the instruction.

Common interpretations readers bring to modal verbs

• Must is read as a strict requirement with little or no discretion; readers expect consequences for noncompliance.
• Must not is read as a clear prohibition; readers assume it overrides convenience or preference.
• Shall is often read as “must” in legal or contractual contexts, but many readers outside those contexts find it formal or ambiguous.
• Shall not is typically interpreted as a prohibition, though some readers may pause to confirm whether it is legal language rather than an everyday instruction.
• Should is read as a strong recommendation; readers often infer “do this unless you have a good reason not to.”
• Should not is read as advice against an action, not always an absolute ban; readers may treat it as optional if pressure is high.
• May is commonly read as permission (“is allowed to”), especially in policies and procedures.
• May not can be read two ways: prohibition (“is not allowed to”) or possibility (“might not”); in formal rules, many readers expect the prohibition meaning, but the ambiguity can still cause disputes.
• Can is often read as ability (“is able to”) rather than permission; in rules it can unintentionally sound like a capability statement instead of an authorization.
• Cannot is read as impossibility or a hard constraint; if the rule is really a prohibition, readers may wonder whether it is technically impossible or simply not allowed.
• Will is read as a prediction or a stated outcome (“this happens next”), not a requirement; it can also sound like a promise by the organization.
• Will not is read as a stated refusal or a guaranteed non-occurrence; it may sound like system behavior rather than a user-facing rule.
• Need to is read as practical necessity; it often feels less formal than “must” but still fairly strong.
• Have to is read as external obligation; it can feel conversational but still mandatory to many readers.
• Ought to is read as moral or traditional advice; it can feel old-fashioned and less enforceable.
• Might is read as possibility; in rules it tends to weaken clarity unless the goal is to describe risk or uncertainty.

Patterns that reduce misinterpretation in formal rules

• Use one modal per rule statement when possible; stacking modals (“may be required to”) makes the level of obligation harder to judge.
• Reserve mandatory language for true requirements; if everything is “must,” readers stop distinguishing critical rules from guidance.
• Avoid “may not” when readers could plausibly read it as “might not”; prefer a clearer prohibition form (for example, “must not” or “is not permitted to”).
• Separate permission from capability: write permission with “may” (allowed) and capability with “can” (able), so readers do not confuse authorization with feasibility.
• When using “should,” add the exception condition if it matters (for example, “should … unless …”), so readers know when deviation is acceptable.
• Make the actor explicit (“Users must…,” “The system must…,” “Supervisors may…”) to prevent readers from guessing who the rule applies to.
• Place the modal close to the main verb (“must submit,” “may access”) to keep the obligation level easy to scan.
• State consequences or enforcement separately from the modal; readers interpret “must” more consistently when the rule is not overloaded with penalties.

Example rewrites that match reader expectations

• ✅ “Employees must wear ID badges on site.” → clearer than “Employees should wear…” if it is enforced.
• ✅ “Visitors may use the lobby restroom.” → clearer permission than “Visitors can use…”
• ❌ “Users may not share passwords.” → can be misread; prefer “Users must not share passwords.”
• ✅ “You should back up files weekly unless automated backups are enabled.” → recommendation with an explicit exception.
• ✅ “The system will lock the account after five failed attempts.” → appropriate when describing system behavior, not user obligation.
• ❌ “Staff will submit reports by Friday.” → sounds like a prediction; prefer “Staff must submit…” if it is a deadline rule.

Exercises and practice activities with modal verbs in instructions

Build accuracy by practising how modals signal obligation, prohibition, permission, and advice in rule-like sentences. Focus on consistent patterns: modal + base verb (must wear, should check, may enter), and negatives for bans (must not, may not, cannot).

1) Choose the best modal for the rule

Select the most suitable option for each instruction. Use meaning clues (required, optional, recommended, not allowed).

1. Employees ____ wear an ID badge at all times. (must / may / should)
2. You ____ park here after 6 p.m. (may / must / should)
3. Visitors ____ sign in at reception. (must / can / might)
4. You ____ use headphones in the library. (should / must / may)
5. Passengers ____ smoke on the platform. (must not / should not / may not)
6. You ____ submit the form by Friday to be considered. (must / can / may)
7. Children ____ be supervised near the pool. (must / may / could)
8. You ____ bring your own laptop; computers are provided. (don’t have to / must not / may not)
9. To avoid errors, you ____ double-check the address. (should / must / may)
10. Staff ____ take breaks only in the designated area. (must / might / could)

2) Rewrite to match the meaning (pattern practice)

Rewrite each sentence using the modal given. Keep the same meaning as closely as possible.

1. It is necessary to wear safety glasses. (must)
2. It is not permitted to use the elevator during a fire. (must not)
3. It is optional to print the receipt. (don’t have to)
4. It is a good idea to back up your files weekly. (should)
5. It is allowed to enter through the side door after 9 a.m. (may)
6. It is not allowed to take photos in the gallery. (cannot)
7. It is required to keep the exit clear. (have to)
8. It is recommended to read the instructions before assembly. (ought to)

3) Fix the form (common errors in written rules)

Correct each instruction. Watch for base-verb form after modals and clear negatives.

1. You must to wear gloves.
2. Visitors may enters only with a pass.
3. You don’t must leave bags unattended.
4. Staff should to check the temperature every hour.
5. You mustn’t to touch the equipment.
6. Passengers can not to open the doors.
7. You may not bringing food into the lab.
8. Employees have to wears closed-toe shoes.

4) Sort the modals by function (meaning awareness)

Put each modal phrase into the best category: obligation, prohibition, permission, no obligation, advice. Use each phrase once.

1. must
2. must not
3. may
4. don’t have to
5. should
6. have to
7. cannot
8. may not
9. ought to
10. needn’t

5) Mini production tasks (write clear instructions)

Write one rule for each situation using the modal in brackets. Keep it short, direct, and suitable for a sign or handbook.

1. A lab rule about protective equipment. (must)
2. A museum rule about phones. (must not)
3. A school rule about arriving on time. (should)
4. A hotel rule about checkout time flexibility. (may)
5. An office note about optional attendance. (don’t have to)
6. A workshop rule about machine use. (cannot)

Useful patterns to reuse while practising

• Must / have to + base verb for requirements: “You must submit the report by 5 p.m.”
• Must not / cannot + base verb for bans: “You must not block the fire exit.”
• May / can + base verb for permission (depending on formality): “You may leave early with approval.”
• Don’t have to / needn’t + base verb for no obligation: “You don’t have to print this page.”
• Should / ought to + base verb for recommendations: “You should store chemicals in labeled containers.”
• Keep negatives simple and unambiguous: ✅ “You must not enter.” ❌ “You don’t must enter.”
• Avoid extra “to” after modals: ✅ “must wear” ❌ “must to wear”
• Prefer consistent subjects in rule sets (often “You” or the role): “Guests must…” “Staff must…”