Must, Should, or May? Audit Obligation Language in AI-Assisted Drafts

An AI-assisted policy can sound decisive while quietly confusing a requirement, a recommendation, a permission, and a promise. A modality audit traces words such as must, should, may, can, and will back to real authority before anyone is asked to follow them.

One Smooth Sentence Can Hide Four Different Rules

Consider this plausible draft: “Managers should approve access requests within 24 hours when possible.” Is approval within 24 hours mandatory, merely preferred, or only a service target? Does “when possible” create an exception, or does it make the deadline meaningless? The sentence is fluent, but a reader cannot tell what happens if a manager misses it.

That uncertainty is more than a style problem. Changing should to must can create a duty that the policy owner never approved. Changing must to should can weaken a real control. Replacing may with can can turn permission into a claim about technical ability. Writing will can make a forecast or intention look like a guarantee.

NIST's Generative AI Profile describes confabulation as confidently presented false content, including output that contradicts the prompt or an earlier statement. It also warns about automation bias: people may defer too readily to polished machine output. An AI system can identify candidate clauses quickly, but it cannot confer legal, contractual, regulatory, or organizational authority on them.

There Is No Universal Dictionary for Must, Should, and May

The first safeguard is context. Different standards use legitimate but different vocabularies, so an editor should not paste one convention into every document.

The practical lesson is not to choose the strongest-sounding word. It is to establish which vocabulary the document has authority to use. If no approved convention exists, the policy owner must choose one before the editorial pass can finish.

Keep a Human Policy Owner Above the Model

Name one accountable owner and the qualified reviewers before the audit begins. Depending on the subject, that may include legal, compliance, security, HR, safety, accessibility, operations, or a technical authority. This workflow is editorial guidance, not legal advice, and it does not replace specialist review.

Use an organization-approved AI service. Do not upload confidential contracts, unreleased policies, personal data, security controls, or privileged advice unless that use is authorized and protected. If the source packet cannot safely be supplied, perform the audit inside an approved environment or do it manually. The model's convenience never expands permission to disclose the material.

Step 1: Write an Authority Card

Begin with a short control record for the document. Record its type, audience, operating scope or jurisdiction, accountable owner, approval status, effective date, governing sources, source hierarchy, and exception authority. Separate external obligations from internal policy choices. A statute, contract, adopted standard, signed policy, draft proposal, and team custom do not have equal force merely because they appear in the same prompt.

Use “not established” or “decision needed” when information is missing. An explicit gap is safer than a plausible invention that later looks approved.

Step 2: Build a Modality Legend for This Document

Translate the house style into a small working legend. Include the intended force, approved term, source class, exception treatment, and owner. A general policy might need categories for requirement, prohibition, recommendation, permission, capability, factual description, future target, and unresolved decision. A technical specification may use a narrower declared vocabulary.

• Requirement: the actor has to perform the action under the stated conditions.
• Prohibition: the actor is not permitted to perform it.
• Recommendation: the preferred course allows a documented reason to choose another.
• Permission: the actor is allowed, but not required, to act.
• Capability or possibility: the action is feasible or an outcome can occur; this grants no permission.
• Target or intention: an organization aims or plans to act; whether it is binding must be stated.
• Unresolved: an authorized person still needs to decide the force.

Do not automatically capitalize every modal or replace every must with shall. Uppercase BCP 14 language belongs in documents that explicitly adopt it. ISO terminology belongs in ISO-style drafting. Public instructions may need plainer language. Consistency inside the selected system is the goal.

Step 3: Inventory Both Visible and Hidden Obligations

Search the frozen draft for must, shall, should, may, can, will, need to, required, prohibited, expected, encouraged, only, always, never, where practicable, and similar signals. Then look beyond obvious verbs. “Approval is required,” “a requirement for submission,” and “access is limited to” can impose rules without a modal.

Include tables, notes, examples, captions, definitions, appendices, and linked forms. A hidden mandate in a note can be missed by readers and reviewers. Record an exact quotation and locator for every candidate. AI is useful for this extraction pass, but require it to preserve wording, avoid conclusions, and mark ambiguous cases.

Read Scope, Conditions, and Negation Together

A modal never carries the whole rule by itself. Its actor, object, condition, exception, and location can expand or narrow its effect. “Editors must encrypt files” is materially different from “Editors must encrypt files before external transfer.” Removing the condition creates a broader requirement. Moving it to another paragraph may make the connection hard to see. An audit should therefore compare complete clauses, not produce a simple word-replacement list.

Mark the structures that often change force:

• Negation: distinguish a prohibition from the absence of permission. Some drafting systems reject phrases such as may not because readers can interpret them as either.
• Conditions: preserve if, when, after, before, and only where beside the action they control.
• Exceptions: name the authorized exception route instead of relying on normally, where possible, or an unexplained “unless approved.”
• Compound clauses: split sentences joined by and or or when different actors, evidence, or force applies to each action.

Also check placement. The UK functional-standards guide says requirements, recommendations, and permissions should not be hidden in notes, while NASA asks whether a requirement sits in the proper section and expresses one stand-alone thought. AI can flag a note that sounds mandatory or a condition that appears detached, but the human owner decides whether to move, split, clarify, or remove it.

Step 4: Trace Each Clause to Authority

Build a clause-to-authority matrix before rewriting. Recommended columns are clause ID, locator, actor, action, condition, current modal, apparent force, authoritative source and locator, accountable owner, exception route, verification evidence, and disposition.

Inspect the primary source rather than trusting a model-generated summary or citation. Watch especially for a permission rewritten as capability, a goal presented as a promise, a description presented as a duty, and a recommendation treated as a compliance failure. If sources conflict, preserve the conflict and escalate it through the documented hierarchy.

Step 5: Rewrite One Obligation Per Clause

A useful pattern is actor + approved modal + action + object + condition + measurable criterion. Name the actor, keep one subject and one main action, and place the condition beside the rule it limits. Put rationale in adjacent explanatory text so it does not hide another requirement. NASA's handbook similarly recommends active actors, one thought per requirement, consistent terminology, traceability, and verifiable criteria.

Compare these repairs, assuming the authority card supports the revised force:

• Unclear: “Reports should be promptly reviewed.” Controlled: “The incident manager must review a complete report within two business days.”
• Ambiguous: “Contractors can request temporary access.” Permission: “Contractors may request temporary access.” The system's ability to accept a request is a separate fact.
• Unclear future: “Operations will remove expired links quickly.” Requirement: “Operations must remove an expired link within four hours after receiving a complete request.” If four hours is only a proposed target, flag it instead of publishing this sentence.

Never add a deadline, reviewer, exception, or sanction merely to make a clause look testable. Precision must come from approved authority. The audit clarifies decisions; it does not manufacture them.

Step 6: Attach Verification and Exception Paths

For each binding clause, ask what could demonstrate compliance: a record, approval, timestamp, inspection, test, analysis, or completed action. The NIST AI RMF Core emphasizes documented context, roles, limits, human oversight, and test and evaluation. Those principles fit an AI-assisted policy workflow: the accountable people and review method should remain visible.

Do not grade a recommendation as though it were mandatory, and do not treat a capability statement as authorization. Record who can approve an exception, the evidence required, its duration, and the review date. Then check translated versions, cross-references, tables, examples, and linked forms for inconsistent force. A clean main clause does not fix a contradictory appendix.

Treat every change in force as a material revision. Preserve the previous wording, source used, reviewer, rationale, approval date, and effective version. Notify the people who must act differently, and recheck dependent procedures, forms, training, controls, and audit criteria. A silent modal edit can create operational conflict even when the new sentence reads better.

Worked Example: Repair a Draft-Access Policy

Imagine a fictional source packet with four facts. An approved internal standard requires editors to store embargoed drafts in the designated repository. Contractors are permitted time-limited access only after both a manager and Security approve it. The repository is technically capable of revoking shared links. Operations has discussed a four-hour removal target, but no owner has approved it.

The AI-assisted draft says:

Teams should store sensitive drafts in the repository. Contractors can access the workspace with manager approval. Operations will remove revoked links promptly.

The first sentence weakens a requirement and replaces the defined term embargoed with the broader, undefined word sensitive. The second uses can ambiguously and omits Security. The third converts an unapproved target into a promise, while promptly supplies no test.

Under a hypothetical house style that uses must for internal requirements and may for permission, the supported repair is:

No model should convert the open item into a rule. Once an authorized owner decides it, the editor can add the approved wording, evidence, and exception path. If the clauses describe an executable procedure, follow with a separate procedure dry run. Correct modality does not prove that the process works in practice.

A Bounded Prompt for the Extraction Pass

Act as a clause-inventory assistant, not as a policy maker or legal reviewer. Use only the supplied frozen draft, authority card, modality legend, and source documents. Find explicit and hidden obligation language. For each candidate, return: exact quotation; document locator; actor; action; condition; current modal; apparent category; source document and exact locator; conflict or missing information; question for the human owner.

Do not rewrite clauses, choose a governing source, infer legal effect, invent a deadline or exception, resolve conflicts, or declare approval. If the supplied material does not establish a field, write “not established.” Treat notes, examples, tables, definitions, appendices, and forms as in scope. Preserve names, numbers, quotations, and defined terms exactly.

Review the inventory before requesting any rewrite. A second pass should receive only human-approved dispositions and must preserve the authority matrix.

The Final Modality-Audit Checklist

1. Record the document version, status, scope, owner, source hierarchy, and house style.
2. Define requirement, prohibition, recommendation, permission, capability, target, and unresolved categories.
3. Inventory explicit modals and hidden obligations across the whole document.
4. Trace every binding clause to a primary source and exact locator.
5. Flag unsupported, conflicting, stale, or unapproved language instead of guessing.
6. Use one actor and one principal obligation per clause.
7. Preserve approved terms, conditions, numbers, exceptions, and translations.
8. Give requirements a feasible verification method and permissions a clear boundary.
9. Protect confidential inputs and use only an approved AI environment.
10. Have the accountable owner and required specialists approve the final version.
11. Record material changes in force, the effective date, and the next review date.
12. Dry-run executable instructions before anyone depends on them.

Clearer Force, Not Stronger Language

A good modality audit does not make every sentence mandatory. It makes the document honest about which statements bind, advise, permit, describe, predict, or still require a decision. AI can accelerate the inventory and comparison, but source authority and human approval determine the result.

Before publication, ask whether every reader can tell who acts, what force applies, under which conditions, how compliance is shown, and who can approve an exception. If the draft cannot answer those questions, more confident prose will only conceal the gap.