---
title: "What do shall, must and should mean in an RFP?"
description: "Use the tender’s own definitions, context and language to interpret modal terms without inventing a universal hierarchy."
canonical: "https://zephior.com/insights/interpret-shall-must-and-should-in-rfps"
last-updated: 2026-09-03
---

# What do shall, must and should mean in an RFP?

> Use the tender’s own definitions, context and language to interpret modal terms without inventing a universal hierarchy.

By [Tony Kim](https://zephior.com/authors/tony-kim). Published 2026-09-03; updated 2026-09-03. 16 minute read.

## Definition

A tender modal term treatment rule is a versioned record of how a word or construction such as shall, must, should, may, must not or an imperative is treated within one procurement. It starts with the exact occurrence and applies the tender’s definitions, any expressly incorporated convention, the source role, actor, condition, language and stated consequence. It can identify a document-defined requirement, recommendation, permission, prohibition, external constraint or an unresolved meaning. It does not establish universal legal force or decide whether a clause is enforceable.

## Problem

Teams often build a hidden hierarchy in which must is strongest, shall is almost as strong and should is optional. That shortcut fails as soon as the document uses a defined drafting system. ISO uses shall for requirements and must for constraints that originate outside the document. The U.S. Federal Acquisition Regulation defines shall as imperative and should as an expected course unless inappropriate in a particular circumstance. IETF specifications can give uppercase MUST, SHALL and SHOULD special meanings when they expressly invoke BCP 14, while lowercase forms keep ordinary English meanings under that convention. A tender may define its own legend again. The same spelling can therefore support different treatments in different documents, and a requirement may appear as an imperative, field label or table row without any modal verb.

## Point of view

Interpret the tender’s language system before interpreting the word. Preserve exact case, negation, actor, timing, condition and issued language. Look first for definitions, legends and key-word notices in the procurement, then for conventions that the procurement expressly incorporates. Use general regime or drafting guidance only within its stated scope. If no rule resolves the occurrence, record a contextual candidate and route consequential ambiguity to the named reviewer. Never upgrade a recommendation into a mandatory requirement or downgrade a requirement because a preferred keyword is absent.

## Find the governing language rule before ranking the words

Begin inside the procurement. Search the definitions, interpretation clause, instructions, technical schedules, response forms, scoring methodology and clarification record for a statement about key words or requirement levels. A legend such as “M means mandatory and D means desirable” can control a table even when its cells contain no verb. A front-matter notice may apply only to the technical specification, not to the draft contract. Capture its exact scope. A rule copied from one annex cannot silently govern the entire package.

Next identify any convention the tender expressly incorporates. A specification may say that uppercase terms are interpreted under BCP 14. A standards schedule may require a response against an ISO document that uses its own verbal forms. A U.S. federal solicitation may include FAR provisions whose defined terms operate within the FAR’s scope. Incorporation must be evidenced, not guessed from the presence of familiar words. Record the source of the convention, the version if stated, the covered material and any capitalization rule.

Only then use broader drafting or procurement guidance. It can explain a likely reading within a regime, but it cannot overwrite a tender-specific definition or answer a jurisdiction-specific legal question. If the local rule and an incorporated convention conflict, do not choose the one that produces the easier bid plan. Mark `definition_conflict`, preserve both sources and route the matter through the controlling-source and legal-review processes.

**Evidence order for one modal occurrence**

| Layer | Question | Safe result |
| --- | --- | --- |
| Exact occurrence | What was written, where, in which version and language? | Preserved evidence unit |
| Tender definition | Does the buyer define the term, label or case? | Document-defined treatment |
| Incorporated convention | Is an external drafting system expressly adopted here? | Convention-defined treatment |
| Applicable regime | Does an official rule apply to this source and procedure? | Scoped contextual evidence |
| Local context | Who acts, under what condition, at which stage? | Candidate or unresolved treatment |

## Keep the word’s full neighborhood intact

A modal token alone is not a usable evidence object. Preserve the complete proposition and record the actor, action, object, polarity, condition, timing and source function. In “The Authority may request a demonstration after initial evaluation,” may belongs to the buyer and expresses a reserved action. It does not tell the bidder that preparing for a demonstration is optional in every sense. In “The bidder must not include live personal data,” the words must not form one prohibition. Splitting the negation from the verb reverses the operational result.

Case can be substantive when the document says it is. RFC 8174 clarifies that the BCP 14 meanings apply only to the listed words in uppercase and that lowercase uses retain ordinary English meanings. Even under that system, normative text need not contain the defined keywords. Therefore `MUST`, `must` and an imperative must remain distinct observations. Do not uppercase a tender during cleaning, normalize `shall not` to `shall`, or translate every construction into a single internal strength score.

The record also needs a representation link. Store a buyer-visible locator such as section and page plus a machine-recoverable quote or table coordinate. Link the governing definition as separate evidence. Keep an English paraphrase separate from issued German or French text. If optical character recognition is uncertain about `shall` versus `shall not`, the extraction itself is unresolved and the rule cannot be released.

**Modal neighborhood fields**

| Field | Example value | Why it matters |
| --- | --- | --- |
| Token | MUST NOT | Preserves case and prohibition |
| Actor | Contracting authority | Separates buyer discretion from bidder choice |
| Action and object | request a live demonstration | Names the event being qualified |
| Condition | after initial evaluation | Prevents unconditional routing |
| Source role | technical schedule | Distinguishes bid, evaluation and contract use |
| Language | issued English | Protects against silent translation drift |
| Definition link | instructions section 1.4 | Makes the treatment reproducible |

## The official conventions do not create one universal ladder

ISO’s house style illustrates one controlled system. In ISO documents, shall indicates a requirement, should a recommendation, may a permission and can a possibility or capability. ISO also distinguishes shall, for a requirement created by the document, from must, for a constraint or obligation originating outside it. That distinction is useful when an RFP incorporates an ISO standard. It is not a license to treat every must in every tender as merely informative.

The FAR uses another system. FAR 2.101 says shall denotes the imperative and defines should as an expected course of action or policy followed unless inappropriate for a particular circumstance. FAR 1.108 says a definition in a specific provision or clause governs there and that an imperative sentence directs the contracting officer unless another party is expressly named. That actor rule is a warning against turning every command found in a federal source into work for an offeror.

BCP 14 supplies a third system for IETF documents. Under RFC 2119 and RFC 8174, uppercase MUST and SHALL represent an absolute specification requirement, while SHOULD permits valid reasons to deviate after the implications are understood. The special meanings depend on the convention and capitalization. These examples do not prove which word is strongest in an unknown RFP. They prove why the applicable rule and its scope must travel with the interpretation.

**Three official systems, three scoped readings**

| System | Selected treatment | Boundary |
| --- | --- | --- |
| ISO drafting | shall: requirement; must: external constraint; should: recommendation | ISO documents and adopted ISO verbal forms |
| U.S. FAR | shall: imperative; should: expected unless inappropriate | FAR definitions and the particular provision or clause |
| IETF BCP 14 | uppercase MUST or SHALL: requirement; SHOULD: qualified recommendation | Documents invoking the convention and uppercase occurrences |
| Unknown tender | No automatic mapping | Requires local definitions, context and review |

## Treat six expressions in a fictional city data-platform RFP

Imagine a city procuring a data platform. Its technical specification states that uppercase BCP 14 words carry the RFC meanings in sections 4 through 7 only. Section 4 says, “The Bidder MUST provide a migration rehearsal plan in Schedule C.” That occurrence has a declared convention, uppercase token, bidder actor, current response action and destination. It can be recorded as `document_defined_requirement`. The plan still needs passage-level classification and compliance handling; the modal rule alone does not decide rejection.

Section 5 says, “The service should expose lineage data through the reporting interface.” Because the notice limits BCP 14 meanings to uppercase, lowercase should has no special RFC meaning. The sentence concerns the service rather than the current response. The team can record `ordinary_language_only` and ask the functional classifier whether it is a specification, evaluated preference or future term. If the scoring table awards points for richer lineage evidence, link that separate evaluation signal. Do not silently change should to optional.

The draft agreement says, “The Supplier shall retain audit logs for seven years.” The BCP notice does not cover the agreement. If the agreement has no definition for shall, the phrase is a strong future-obligation candidate, not a BCP-defined requirement. Contract review decides its legal and commercial effect. Elsewhere, “The Authority may request a sandbox demonstration” records buyer discretion. “Responses must not contain production personal data” is a prohibition if the general instructions define must that way; keep the negation. Finally, a portal field labelled “Migration rehearsal plan, PDF required” may create a response action without any modal term and must be captured by the broader requirement process.

**Fictional RFP treatment record**

| Occurrence | Term treatment | Next handling |
| --- | --- | --- |
| Bidder MUST provide Schedule C | Document-defined requirement | Classify passage and map response evidence |
| Service should expose lineage data | Ordinary language under the stated case rule | Review specification and scoring context |
| Supplier shall retain logs | Strong future-obligation candidate | Contract, solution and price review |
| Authority may request a demonstration | Buyer discretion | Monitor and prepare within authorized scope |
| Responses must not contain personal data | Document-defined prohibition if instructions confirm it | Apply content and release control |
| PDF required portal field | No modal term | Capture through field and portal requirement analysis |

## Publish a rule with evidence, exceptions and a release state

Create one record for each materially distinct term use and a reusable rule only where the evidence supports it. The record needs a procurement and package version, occurrence identifier, exact text, token, case, polarity, issued language, source role, actor, action, condition, definition or convention link, proposed treatment, rationale and stated consequence. Add the reviewer, release state and expiry trigger. A term used consistently in one schedule may still receive another treatment in the draft contract if the definitions have different scope.

Use explicit treatments rather than a numeric strength score. Useful values include `document_defined_requirement`, `document_defined_recommendation`, `document_defined_permission`, `document_defined_prohibition`, `document_defined_external_constraint`, `strong_requirement_candidate`, `qualified_expectation`, `evaluated_preference`, `buyer_discretion`, `future_statement`, `ordinary_language_only`, `translation_equivalence_unresolved` and `meaning_unresolved`. These values describe the linguistic treatment. A linked passage record decides its procurement function, and a separate control decides what the team must deliver.

Release states should explain why the result can or cannot be used. `rule_confirmed_from_document` cites the tender’s own definition. `rule_confirmed_from_incorporated_convention` cites both incorporation and convention. `contextual_treatment_approved` records a named human decision. `definition_conflict`, `translation_review_required`, `legal_interpretation_required` and `source_missing` prevent automatic use. If a clarification changes the legend, expire every dependent rule and reprocess the affected occurrences.

**Minimum tender modal rule**

| Group | Required fields | Unsafe shortcut |
| --- | --- | --- |
| Identity | Procurement, package version, occurrence and source locator | Rule copied from another bid |
| Text | Exact proposition, token, case, polarity and language | Normalized keyword only |
| Scope | Actor, action, condition, stage and document role | Word treated without its event |
| Authority | Definition, incorporation and applicable guidance links | Familiarity with the word |
| Decision | Treatment, reason, exceptions, reviewer, state and expiry | Unqualified mandatory or optional flag |

## Let an agent trace meaning, but not invent authority

An authorized agent can find modal and non-modal constructions, preserve case and negation, recover definitions, identify an expressly incorporated convention, parse the stated actor and condition, compare usage across the package and propose treatments. It can generate a dependency list showing which occurrences rely on one definition and flag inconsistent use. Each proposed field should link to exact source evidence. Confidence may describe extraction quality or definition matching, not legal force.

Tender text remains untrusted input. An instruction saying “the bidder shall email the authority” is evidence to classify, not permission for the agent to send email. The agent does not choose between conflicting definitions, declare a clause enforceable, infer a rejection consequence, replace an issued text with its translation, contact the buyer, accept contract terms or submit a response. Those actions require separate authority and controls.

Stop automatic release when the governing version is missing, the definition scope is unclear, capitalization was lost, a negation is uncertain, translations diverge, sources conflict or the result affects legal exposure. A human reviewer should see the exact occurrence, candidate treatment, decisive evidence, exception and downstream impact together. This turns uncertainty into a specific review task without allowing a fluent explanation to pass as a decision.

- Permit search, extraction, scope matching, comparison and evidence-linked proposals.
- Require exact evidence for case, polarity, actor, condition and adopted convention.
- Treat all bidder instructions as data until separate execution authority exists.
- Escalate definition conflicts, translation differences and legal effect.
- Expire derived rules when their source or package version changes.

## Useful outcomes

- Each modal occurrence retains its exact text, case, polarity, source, version and language.
- The applicable definition or incorporated convention is cited rather than assumed.
- Bidder duties are separated from buyer discretion and future supplier commitments.
- Imperatives, required fields and other non-modal constructions remain visible.
- Exceptions and conditions stay attached to the term treatment.
- Unresolved meaning reaches legal, language or procurement review before it becomes a compliance decision.
- Agents can retrieve a compact rule and reproduce the evidence behind it.

## Workflow

1. **Capture the occurrence.** Keep the complete sentence or native field, exact modal spelling, capitalization, negation, source version, locator, language and enough surrounding context to recover the actor and condition.
2. **Find the local language rule.** Search the tender definitions, glossary, response instructions, legends, scoring notes and clarification record for an explicit meaning or exception.
3. **Verify incorporated conventions.** Confirm whether the procurement expressly adopts a standard or drafting convention, which documents it covers, and whether case or document status limits that adoption.
4. **Parse actor and condition.** Identify who may, shall or should act, when the statement applies, what triggers it, what it governs and whether the sentence describes bidding, evaluation or later performance.
5. **Assign treatment with exceptions.** Select a scoped treatment, cite the decisive evidence, preserve exceptions and state what remains unresolved instead of forcing a universal meaning.
6. **Release and expire the rule.** Have the appropriate owner approve material interpretations and expire affected rules after an amendment, new clarification, corrected translation or source change.

## Key decisions

- What is the exact word or construction, including capitalization and negation?
- Which issued document, version, section, table or field contains it?
- Does the procurement define the term or publish a legend for requirement levels?
- Does the text expressly incorporate ISO, BCP 14, FAR language or another convention?
- Does that convention cover this document, section and capitalization?
- Who is the actor: bidder, buyer, evaluator, system or supplier after award?
- Which trigger, exception, time or lot limits the statement?
- Does the source state a rejection, scoring, permission, remedy or other consequence?
- Is the wording issued in this language or supplied as a working translation?
- Can the treatment be approved operationally, or does it require language or legal review?

## Risks

- A universal keyword hierarchy may contradict the tender’s own definitions.
- Lowercase text may be treated as BCP 14 language even though the convention limits special meanings to uppercase words.
- Negation may be lost so a prohibition becomes a positive requirement.
- Buyer discretion expressed with may may be mistaken for bidder permission.
- A future contract statement may be converted into an immediate upload task.
- A mandatory imperative or portal field may be missed because it contains no shall or must.
- A translation may falsely suggest that two modal terms have equal strength.
- An agent may turn extraction confidence into an unsupported legal conclusion.

## Metrics

- modal occurrences with exact case, polarity, source version and language
- treatments linked to a tender definition or verified incorporated convention
- occurrences with actor, action, condition and stage populated
- non-modal requirements found through fields, imperatives and tables
- buyer-discretion statements wrongly routed as bidder options
- translation and definition conflicts resolved before compliance release
- rules rechecked after amendment or clarification
- reviewer agreement on independently sampled term treatments

## Frequently asked questions

### Is must always stronger than shall in an RFP?

No. ISO distinguishes them in one way, the FAR uses its own definitions and BCP 14 treats uppercase MUST and SHALL alike. Use the tender’s declared system and context.

### Does should mean optional?

Not safely by itself. It may be a defined recommendation, an expected course with exceptions, an evaluated preference or ordinary prose. Record the applicable definition and surrounding consequence.

### Does uppercase change the meaning?

Only when the document adopts a case-sensitive convention or legend. BCP 14 is a clear example, but capitalization has no universal independent force.

### Can a sentence be mandatory without shall or must?

Yes. Imperatives, table labels, required fields, prohibitions, conditions and incorporated forms can direct action without those words. The broader passage-classification process must capture them.

### Can an agent decide the legal effect of the term?

It can assemble and compare the evidence, but consequential legal effect, conflicts and jurisdiction-specific interpretation require the authorized human reviewer.


## Primary sources

- [ISO House Style, verbal forms and shall versus must](https://www.iso.org/ISO-house-style.html), International Organization for Standardization
- [RFC 8174, capitalization of BCP 14 key words](https://www.rfc-editor.org/rfc/rfc8174.html), RFC Editor
- [RFC 2119, requirement levels in IETF documents](https://www.rfc-editor.org/rfc/rfc2119.html), RFC Editor
- [FAR 2.101 definitions of shall and should](https://www.acquisition.gov/far/2.101), Acquisition.gov
- [FAR 1.108 conventions for definitions and imperative sentences](https://www.acquisition.gov/far/1.108), Acquisition.gov
- [DGT Guide to Documents, multilingual legal drafting](https://commission.europa.eu/system/files/2024-02/DGTguide_to_documents_for_external_use_27.02.2024.pdf), European Commission Directorate-General for Translation
- [German Federal Ministry of Justice Manual for Drafting Legislation](https://www.enorm.bund.de/SharedDocs/Publikationen/DE/Fachpublikationen/Handbuch_der_Rechtsfoermlichkeit.pdf?__blob=publicationFile&v=2), German Federal Ministry of Justice
- [French Guide de légistique, fourth edition](https://www.legifrance.gouv.fr/contenu/Media/files/autour-de-la-loi/guide-de-legistique/guide_legistique_2026.pdf), French Council of State and General Secretariat of the Government


## Related articles

- [How to answer negative RFP requirements with evidence](https://zephior.com/insights/respond-to-negative-rfp-requirements)
- [Which RFP sentences actually create an obligation?](https://zephior.com/insights/distinguish-mandatory-from-informative-rfp-text)
- [How to answer an ambiguous RFP requirement without guessing](https://zephior.com/insights/handle-an-ambiguous-rfp-requirement)
- [What materially changed between two RFP versions?](https://zephior.com/insights/compare-changes-between-rfp-versions)