Modal Language Review Protocol¶
Protocol — instantiates Necessity-Possibility-Contingency Framing
A protocol for reviewing must, may, can, cannot, should, would, and might in high-stakes language.
Modal Language Review Protocol is a word-level audit of a finished text: it walks every modal expression — must, shall, may, can, cannot, should, would, might — and checks that each carries the modal force its author intended and that the reader will receive. Its defining move is that it operates on language already written, not on claims or cases: the object under review is the sentence, and the question is whether "should" was meant as a requirement or a suggestion, whether "may" grants a permission or merely notes a possibility, and whether the conditions that govern a requirement actually travel with it in the prose. It does not classify the underlying facts or decide what to do; it makes the wording say what it means.
Example¶
An engineering team is finalizing a protocol specification for a payment API. A Modal Language Review Protocol runs over the draft. It flags each keyword against its intended force under the RFC 2119 convention, where MUST, SHOULD, and MAY have precise, agreed meanings.[1] Three defects surface. A security requirement reads "clients should validate the server certificate" — a SHOULD where the author meant an unconditional MUST, softening a security control into advice. A rate-limit clause reads "servers may reject excess requests," correctly a permission, but the condition ("when the client exceeds its quota") sits two sentences away and reads as unconditional, so an implementer could reject any request. A retry clause hedges "the client might retry," where might blurs whether retrying is permitted, expected, or discouraged.
The review's output is a marked-up draft: promote the certificate SHOULD to MUST, bind the rejection permission to its quota condition in the same sentence, and replace the hedged might with an explicit MAY plus a stated backoff. The facts never changed; the language now carries the force the authors intended.
How it works¶
The protocol scans for every modal expression, then subjects each to three tests: map the word to its intended status in a fixed vocabulary (does "should" mean required or recommended?); flag hedges and confidence-softeners (might, could, generally) that leak force the author did not intend; and verify that any condition or exception governing the modal actually attaches to it in the text rather than floating loose. The distinguishing feature is that it never leaves the level of wording — it corrects sentences, not underlying classifications, and it presumes the modal intent is known and asks only whether the prose delivers it.
Tuning parameters¶
- Keyword vocabulary — an informal reading versus a strict convention (RFC 2119, contractual "shall") with fixed meanings. A strict convention removes ambiguity but requires author buy-in.
- Hedge sensitivity — how aggressively to flag softeners like might, should be able to, generally. High sensitivity catches leaked force but can over-flag legitimate hedging.
- Condition-proximity rule — how close a governing condition must sit to its modal before the review passes it. Strict proximity prevents floating exceptions but forces terser drafting.
- Scope of review — every modal in the document versus only those in normative or safety-critical sections.
- Reviewer independence — author self-review versus a fresh reader; a fresh reader catches intended-versus-received gaps the author cannot see.
When it helps, and when it misleads¶
Its strength is closing the gap between intended and received modal force in exactly the documents where that gap is expensive — specifications, contracts, safety procedures, regulatory filings. A single should that should have been must can turn a requirement into a suggestion no one is accountable for, and this protocol is built to catch it before the document ships.
Its failure mode is that it audits wording, not truth: it can make a sentence unambiguously state a requirement that is itself wrong, and it cannot tell whether the intended force was correct in the first place. Over-applied, it also breeds a legalistic register where every clause is armored in keywords, harming readability without adding clarity. The classic misuse is treating a clean language review as validation of the underlying claims — polished modal prose that no one ever fact-checked. The guarding discipline is to run the review after the modal intent has been settled by a claim ledger or obligation matrix, never as a substitute for settling it, and to pair it with a human read for tone.
How it implements the components¶
modal_status_taxonomy— supplies the fixed vocabulary each modal word is mapped to, so "should" resolves to a definite status rather than an ambiguous one.modal_confidence_marker— the hedge-detection pass surfaces the softeners and qualifiers that signal (or leak) the author's confidence level.condition_and_exception_register— the proximity check ensures the conditions and exceptions governing a modal are attached to it in the text rather than floating free.
It does not build the per-claim action ledger that turns status into an owned step — decision_translation_rule is Modal Claim Table's, which the review's output feeds; and it does not construct hypothetical cases — possible_world_or_case_set belongs to Possible-World Case Matrix.
Related¶
- Instantiates: Necessity-Possibility-Contingency Framing — the protocol audits a text so its modal words carry the force intended.
- Sibling mechanisms: Modal Claim Table · Possible-World Case Matrix · Counterfactual Minimal-Change Checklist · Assumption Lock-and-Relax Workshop · Necessity-Possibility Red Team · Legal Obligation-Permission Matrix · Design Constraint-Relaxation Table
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Modal Language Review Protocol operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a protocol for reviewing must, may, can, cannot, should, would, and might in high-stakes language.
Independent corroboration: The frozen evidence defines Modal Language Review Protocol as 'A protocol for reviewing must, may, can, cannot, should, would, and might in high-stakes language', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Protocol, Workflow & Routine — The review follows a scan-and-test protocol, but its bounded purpose is assurance that high-stakes modal wording delivers the intended force.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: RFC 2119 is direct provenance for review of standardized MUST/SHOULD/MAY language in technical specifications; legal normativity and modal semantics are formative antecedents. This establishes computer_science as the primary origin lineage rather than merely a domain where the mechanism is now applied.
Related originating lineages:
- Law & Governance — Systematic review of must, may, shall, and cannot in high-stakes text is most directly rooted in legal and regulatory drafting practice.
- Linguistics & Semiotics — The semantics and pragmatics of modal verbs materially explain ambiguity in force and scope.
Review resolution: Authoritative/primary-source research resolves the conflicting primary-origin claims in favor of computer_science: RFC 2119 is direct provenance for review of standardized MUST/SHOULD/MAY language in technical specifications; legal normativity and modal semantics are formative antecedents. Retained alternate origins (law_governance, linguistics_semiotics) are limited to independently formative or materially shaping lineages supported by the reviewer evidence; downstream adoption alone was not promoted to origin. The breadth of present-day use is recorded separately as domain_reach=multi_domain. origin_mode=cross_disciplinary_synthesis, confidence=medium, and encyclopedia_synthesis=true reflect the surviving provenance evidence and the encyclopedia's generalization.
Attribution caveat: The generalized protocol extends a computing-standards convention into other high-stakes language.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
- RFC 2119: Key words for use in RFCs — Defines the standardized MUST/SHOULD/MAY modal vocabulary used to review normative technical specifications.
References¶
[1] RFC 2119 is an Internet-standards convention fixing the meanings of the capitalized keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in technical specifications, so that a reader knows an absolute requirement from a recommendation from a permission. It is a working example of exactly the disambiguation this protocol enforces. registry ↩