Normative language
In documents or sections that explicitly adopt this convention, uppercase normative terms carry the meanings defined in RFC 2119 and RFC 8174. They turn prose from description into requirement.
The definitions below follow RFC 2119 and RFC 8174. Uppercase normative terms have normative meaning only in documents or sections that explicitly adopt this convention.
MUSTAn absolute requirement of the specification.
MUST NOTAn absolute prohibition of the specification.
SHOULDA recommended behavior. Valid reasons may exist to ignore it in particular circumstances, but the implications must be understood and weighed.
SHOULD NOTA recommendation against a behavior. Valid reasons may exist to do it in particular circumstances, but the implications must be understood and weighed.
MAYA permitted option. A document may choose whether to include the item.
When to use normative language
Use uppercase normative terms only where a statement is genuinely normative. FTL does not use normative language in exploratory brainstorming merely to make prose look precise, and it does not allow a rewriting tool to invent MUST where the source only said can or could.
Ordinary-language modality vs RFC modality
Lowercase and ordinary-language modality must not be silently promoted to uppercase RFC modality.
canUsually capability; sometimes possibility, depending on context.
mayOrdinary English permission or possibility, depending on context.
couldPossibility, capability, hypothetical case, or tentative option, depending on context.
shouldRecommendation, expectation, or prediction, depending on context.
MAYNormative permission in a document that adopts RFC 2119/8174 terminology.
SHOULDNormative recommendation.
MUSTNormative requirement.
Worked examples
Preserve could when the meaning is uncertain
Source
The service could retry.Wrong
The service MAY retry.Right
The service could retry.Reason. could expresses uncertain possibility, not normative permission. RFC uppercase MAY would assert permission the source does not grant.
Preserve can as capability
Source
The service can retry.Wrong
The service MAY retry.Right
The service can retry.Reason. can here expresses capability, not permission. Converting it to MAY reinterprets capability as normative permission.
Preserve MAY as normative permission
Source
The service MAY retry.Wrong
The service can retry.Right
The service MAY retry.Reason. Uppercase MAY is normative permission in a document adopting RFC 2119/8174. Lowering it to can would lose the normative force.
Do not automatically convert should to SHOULD
Source
The service should retry.Wrong
The service SHOULD retry.Right
The service should retry. (recommendation; upgrade to SHOULD only after confirming normative intent)Reason. Ordinary lowercase should can be a recommendation, expectation, or prediction. RFC uppercase SHOULD is a normative recommendation that requires the RFC convention.
An explicit decision may introduce a requirement
Source
Proposal: the service should retry after a transient failure.Wrong
The service MUST retry. (silent strengthening without a decision)Right
Decision recorded: the service MUST retry after a transient failure. (requirement introduced by an authorized decision)Reason. A proposal becomes a requirement only when an authorized decision introduces it and that decision is recorded. The transformation must not supply the decision itself.
FTL-T01 preserves source modality. FTL-A07 keeps requirements out of descriptive prose. Both rules depend on the definitions above.