MN 113-4: MMEL Compliance and Requirements

1.1. Purpose

This part of the MMEL specification defines the compliance and requirements modelling features of the Multi-Modal Modelling Language (MMEL). Compliance modelling is the core mechanism by which MMEL connects process behaviours to normative obligations, enabling standards developers and compliance engineers to trace every requirement from its source document through to implementation and verification.

1.2. Compliance traceability chain

MMEL implements a layered traceability chain that connects external normative documents to process-level compliance checks. Each link in this chain is explicitly modelled and machine-readable.

Normative Document (external)
  |
  +-- Clause content (.sdc file)
  |
  +-- reference { document, clause, title }
       |
       +-- provision { condition, modality, reference }
            |
            +-- process.validate_provision { ProvisionID }
                 |
                 +-- Evaluated during compliance checking

1. The Supplementary Document Content (SDC) file extracts clause-level text from the source normative document.
2. A reference construct provides the bibliographic link to the external document clause.
3. A provision defines the compliance requirement with its modality keyword and optional subject bindings.
4. A process declares which provisions it must satisfy via validate_provision.
5. At runtime, compliance checking evaluates whether the process satisfies all its bound provisions.

1.3. Principles

MMEL compliance modelling follows these fundamental principles:

Compliance awareness

Every process element can carry compliance obligations via provisions with RFC 2119 modality keywords (SHALL, SHOULD, MAY, CAN, MUST). This makes the model directly usable for compliance checking without separate requirement documents.

Traceability

Every provision links to normative references, providing full traceability from implementation back to source standards. Data class fields, approvals, and notes can also carry references.

RFC 2119 alignment

Modality keywords in MMEL follow the semantics defined in RFC 2119 and RFC 8174, ensuring interoperability with standards that use these conventions.

Subject binding

Provisions can bind entities (roles, data registries) to numbered subject slots, enabling parameterized compliance conditions where entity names are substituted into the condition text at evaluation time.

Provision classification

Provisions are classified by type -- governing provisions impose obligations (Requirements, Instructions), while assertional provisions describe capabilities, possibilities, or informational statements.

1.4. Relationship to other MMEL parts

This part builds on the core MMEL syntax defined in MN 113 and relates to other parts as follows:

• MN 113 (Core specification) -- defines the base syntax for provisions, references, and notes
• MN 113-5 (Measurements and Validation) -- defines validate_measurement for quantitative compliance checking
• MN 113-3 (Process Model) -- defines processes that carry validate_provision bindings

2.1. General

Provisions are the central compliance construct in MMEL. A provision defines a single compliance requirement expressed as a condition text, optionally qualified by a modality keyword, bound to subjects, and linked to normative references. Processes reference provisions via validate_provision to declare which requirements they must satisfy.

2.2. Syntax

provision <ProvisionID> {
  condition "Requirement text"
  modality SHALL | SHOULD | MAY | CAN | MUST
  subject#1 <EntityID>
  subject#2 <EntityID>
  ...
  subject#N <EntityID>
  reference {
    <ReferenceID1>
    <ReferenceID2>
  }
}

1. The condition text describing the requirement. May contain { subject#N } placeholder references.
2. Optional RFC 2119 modality keyword. When absent, the provision is an informational statement.
3. Optional numbered subject bindings. Each subject#N binds an entity (role or data registry) to a numbered slot.
4. Optional normative references linking to source document clauses.

2.3. Fields

2.4. Provision type classification

Provisions are classified into two broad categories based on their modality keyword:

provision StandardMeetEnvironment {
  subject#1 StandardRegistry
  condition "{ Standards (Data) } selected meet environmental requirements"
  modality SHALL
}

provision ReviewPolicies {
  condition "Review data protection policies periodically"
  modality SHOULD
}

provision SMSEffectivePerformanceIndicator {
  condition "Performance indicators can be evaluated to determine whether the SMS is effectively implemented and maintained"
  modality CAN
}

provision PreferenceOrderO {
  subject#1 StandardDataRegistry
  condition "Select company standards in cases where the requirements cannot be covered by the documents previously mentioned"
  modality MAY
  reference {
    Ref43
  }
}

provision Provision1 {
  condition "Crimson is Ribose's internal manual system, providing manual documents (e.g., policy and procedures) for staff"
}

2.5. Provision with subjects

Provisions may bind entities to numbered subject slots using subject#N fields. The bound entity names are substituted into the condition text at evaluation time. See subject-binding for full documentation of this feature.

2.6. Provision with references

Provisions link to normative source clauses via the reference { } block. Each reference ID corresponds to a reference declaration that provides the document title, clause number, and clause title.

provision ChangeDrivenByMultilateral {
  condition "The changes are driven by other orders of preference being defined in bilateral or multilateral projects"
  modality SHALL
  reference {
    Ref44
  }
}

2.7. Provision referencing by processes

Provisions are referenced by processes via the validate_provision property. A process may reference one or more provisions, indicating that it must satisfy all of them for compliance.

process UnderstandOrganizationContext {
  name "Management of issues"
  modality SHALL
  reference_data_registry {
    IssueRegistry
  }
  validate_provision {
    UnderstandContext
  }
  output {
    IssueRegistry
  }
}

A process referencing multiple provisions:

process DetermineIssue {
  name "Determine issues"
  modality SHALL
  validate_provision {
    DetermineAllIssue
    DetermineExternalIssue
    DetermineInternalIssue
  }
  output {
    IssueRegistry
  }
}

2.8. Examples from production models

provision SMObjectivesMonitor {
  subject#1 SMObjectiveRegistry
  condition "{ Objectives for the SMS (Data) } are monitored"
  modality SHALL
}

provision AssignConform {
  subject#2 VisionRegistry
  subject#1 MissionRegistry
  condition "Assign responsibility and authority for ensuring that the SMS conforms to the { Mission for the organization (Data) } and { Vision for the organization (Data) } of the organization"
  modality SHALL
}

provision CompetenceDocumentation {
  subject#1 worker
  condition "Retain appropriate documented information as evidence of competence of {Worker (ID: worker)}"
  modality SHALL
}

provision TopManagementEstablish {
  subject#3 DirectionRegistry
  subject#2 VisionRegistry
  subject#1 MissionRegistry
  condition "Establishe { Mission for the organization (Data) }, { Vision for the organization (Data) }, { Direction for the organization (Data) } for the organization"
  modality SHALL
}

provision PreferenceOrderN {
  subject#1 StandardDataRegistry
  condition "Select Military standards of partner nations, such as MIL Standards (USA)"
  modality SHALL
  reference {
    Ref43
  }
}
provision PriorConsent {
  subject#1 Purchaser
  condition "Prior consent from { Purchaser (Role) } shall be obtained"
  modality SHALL
  reference {
    Ref44
  }
}

3.1. General

MMEL uses RFC 2119 modality keywords to indicate the obligation level of provisions and processes. These keywords are interpreted as described in RFC 2119 RFC2119 and RFC 8174 RFC8174 .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

3.2. Keyword definitions

3.3. Normative vs informative bindingness

Modality keywords are divided into two bindingness categories:

Normative keywords (SHALL, MUST, SHOULD, MAY)

These keywords create normative provisions that define compliance obligations. A model is evaluated against these provisions during conformance checking. SHALL and MUST create mandatory requirements; SHOULD creates recommendations; MAY creates optional actions.

Informative keywords (CAN)

The CAN keyword creates informative provisions that describe capabilities rather than obligations. These are used for documentation and descriptive purposes and do not create compliance obligations.

No modality keyword (Statement)

A provision without a modality keyword is a purely informational statement. It carries no bindingness and is used for descriptive context, evidence reference, or documentation.

3.4. Usage in provisions

Modality keywords appear in the modality field of provisions:

provision StandardMeetContratual {
  subject#1 StandardRegistry
  condition "{ Standards (Data) } selected meet contractual requirements"
  modality SHALL
}

provision ApplyUpdatedEdition {
  condition "Apply the new edition"
  modality MAY
  reference {
    Ref44
  }
}

provision CustomerFeedback {
  condition "Monitor customer perception using customer feedback on delivered products and services"
  modality CAN
}

3.5. Usage in processes

Processes may also carry a modality field that indicates the overall obligation level of the process itself:

process UnderstandOrganizationContext {
  name "Management of issues"
  modality SHALL
  validate_provision {
    UnderstandContext
  }
  output {
    IssueRegistry
  }
}

When a process has both a modality and validate_provision , the process modality provides the overall obligation level, while each provision carries its own specific modality.

3.6. Distribution in production models

In the BS 202000 model (Standardization management system):

• SHALL is the predominant modality, used for the majority of the 200+ provisions, indicating mandatory requirements
• CAN is used for approximately 10 provisions describing capabilities (e.g. "Performance indicators can be evaluated", "Monitor customer perception using market-share analysis")
• MAY is used for optional actions in specific process contexts

In the BS 16341 model (Selection of standards):

• SHALL is used for all preference order provisions, indicating mandatory selection criteria
• MAY is used for optional provisions (e.g. "Select company standards in cases where requirements cannot be covered")

4.1. General

References define bibliographic links from model elements to external normative document clauses. They are the primary mechanism for traceability in MMEL, connecting provisions, data fields, approvals, and notes to their source standards.

4.2. Syntax

reference <ReferenceID> {
  document "Document title"
  clause "Clause number"
  title "Clause title"
}

1. The full title of the source document.
2. The clause or sub-clause number within the document.
3. The clause title. May be an empty string if the title is not relevant.

4.3. Fields

4.4. Cross-model references

References may use the Namespace#ElementID notation to declare a reference that originates from a different model. The namespace prefix (before # ) identifies the source model, and the element ID (after # ) identifies the specific reference within that model.

reference BS20400#Ref35 {
  document "..."
  clause "..."
  title "..."
}

This notation enables cross-model traceability where a reference in one model points to a clause from a document associated with another model.

4.5. Examples

reference Ref41 {
  document "BS 16341:2012 Selection of standards"
  clause "4.1"
  title ""
}
reference Ref42 {
  document "BS 16341:2012 Selection of standards"
  clause "4.2"
  title ""
}
reference Ref43 {
  document "BS 16341:2012 Selection of standards"
  clause "4.3"
  title ""
}
reference Ref44 {
  document "BS 16341:2012 Selection of standards"
  clause "4.4"
  title ""
}

reference ISO14971-doc-ref3-1 {
  document "Medical devices -- Application of risk management to medical devices"
  clause "3.1"
  title "Risk management process"
}
reference ISO14971-doc-ref3-2 {
  document "Medical devices -- Application of risk management to medical devices"
  clause "3.2"
  title "Management responsibilities"
}
reference ISO14971-doc-ref3-4 {
  document "Medical devices -- Application of risk management to medical devices"
  clause "3.4"
  title "Risk management plan"
}
reference ISO14971-doc-ref3-5 {
  document "Medical devices -- Application of risk management to medical devices"
  clause "3.5"
  title "Risk management file"
}

4.6. Usage

References are used by the following MMEL constructs:

• Provisions -- links a compliance requirement to its normative source clause. This is the most common usage, providing traceability from each requirement to the specific clause it implements.
• Class fields -- links a data field definition to the clause it implements or derives from.
• Approvals -- links an approval workflow step to its normative basis.
• Notes -- links an annotation or explanatory note to its source clause for traceability.

Example of a reference used by a provision:

provision ChangeDrivenByMultilateral {
  condition "The changes are driven by other orders of preference being defined in bilateral or multilateral projects"
  modality SHALL
  reference {
    Ref44
  }
}

Example of a reference used by a note:

note Note1 {
  type NOTE
  message "A documented quality management system process can be used to deal with safety in a systematic manner"
  reference {
    ISO14971-doc-ref3-1
  }
}

Example of a reference used by an approval:

approval Approval4 {
  name "Non-application of a standard requires written approval"
  actor Contractor
  modality SHALL
  approve_by Purchaser
  approval_record {
    StandardApprovalDataRegistry
  }
  reference {
    Ref41
  }
}

5.1. General

Notes provide structured annotations associated with processes and other model elements. They carry explanatory text, classify the annotation type, and optionally link to normative references for traceability.

5.2. Syntax

note <NoteID> {
  type NOTE | EXAMPLE | DEFINITION | TABLE_REFERENCE | TABLE_OPTIONS | FOOTNOTE
  message "Note text"
  reference {
    <ReferenceID>
  }
}

1. The note type classification. In .mmel model files, only NOTE is used. Other types appear in .sdc files or specific measurement contexts.
2. The note content text.
3. Optional normative references providing traceability.

5.3. Note types

MMEL supports the following note types across its file formats:

5.4. Notes in .mmel files

In .mmel model files, notes use the NOTE type exclusively:

note Note1 {
  type NOTE
  message "A documented quality management system process can be used to deal with safety in a systematic manner, in particular to enable the early identification of hazards and hazardous situations in complex medical devices and systems"
  reference {
    ISO14971-doc-ref3-1
  }
}

A note without a reference:

note Note6 {
  type NOTE
  message "Not all parts of the plan need to be created at the same time. The plan or parts of it can be developed over time"
  reference {
    ISO14971-doc-ref3-4
  }
}

5.5. Notes in .sdc files

In Supplementary Document Content files, note types appear as line prefixes within clause content:

5.1.3#NOTE This is a note.
5.1.3#EXAMPLE This is an example.
5.1.3#DEFINITION This is a definition.

Each line uses the format clause-number#TYPE content , where the type prefix classifies the annotation. The NOTE , EXAMPLE , and DEFINITION prefixes correspond to the note types used in MMEL model elements.

5.6. Note referencing by processes

Processes reference notes via the note { } property. A process may reference multiple notes:

process IdentifyRiskControlMeasure {
  name "Identify risk control measure"
  actor Manufacturer
  validate_provision {
    Provision43
    Provision44
  }
  note {
    Note25
    Note26
    Note27
    Note28
    Note29
  }
  subprocess Page11
}

5.7. Note with table references

In measurement contexts, notes may carry TABLE_REFERENCE or TABLE_OPTIONS types to annotate table lookup semantics:

note NoteTableRef {
  type TABLE_REFERENCE
  message "Lookup value from table based on cable type and cross-sectional area"
}

These note types are used alongside TABLE REFERENCE and TABLE OPTIONS measurement types to document the lookup behaviour.

6.1. General

Subject binding is a MMEL feature that allows provisions to parameterize their condition text by binding named entities (roles or data registries) to numbered subject slots. This enables reuse and precise referencing of entities within compliance conditions.

6.2. Syntax

The subject#N fields are declared within a provision definition:

provision <ProvisionID> {
  subject#1 <EntityID>
  subject#2 <EntityID>
  ...
  subject#N <EntityID>
  condition "{ placeholder text } that references { subject#N }"
  modality SHALL | SHOULD | MAY | CAN | MUST
  reference {
    <ReferenceID>
  }
}

1. The first subject binding. EntityID is a role or data registry.
2. The second subject binding.
3. Additional subject bindings (N may be any positive integer).
4. The condition text may contain { ... } blocks that reference the bound subjects by their entity names or descriptions.

6.3. Placeholder semantics

The { subject#N } placeholder notation in condition text works as follows:

1. Each subject#N field binds an entity ID to the numbered slot N.
2. The bound entity may be a role ID or a data_registry ID.
3. The condition text contains { ... } blocks that describe the entity or reference it by name.
4. At evaluation or rendering time, the { ... } blocks may include the entity name or description, substituted from the bound subject.

The placeholder format in condition text varies across models:

• { Entity name (Data) } -- references a data registry
• { Entity name (Role) } -- references a role
• { Entity name (ID: EntityID) } -- references an entity by its identifier
• { subject#N } -- direct numbered reference (less common in practice)

6.4. Binding semantics

The subject binding follows these rules:

1. Subject numbering starts at 1 ( subject#1, subject#2, etc.).
2. There is no upper limit on the number of subjects, though most provisions use 1 to 3 subjects.
3. Subject numbers need not be contiguous, but conventionally start from 1.
4. Each subject binds to exactly one entity ID.
5. The bound entity may be any top-level element: a role, data_registry, or other identifiable construct.

6.5. Examples

provision SMObjectivesUpdate {
  subject#1 SMObjectiveRegistry
  condition "{ Objectives for the SMS (Data) } are updated, as appropriate"
  modality SHALL
}

provision NonConformityDelegate {
  subject#1 ExternalParty
  condition "Delegate corrective action requriements to an {External parties (ID: ExternalParty)} provider"
  modality SHALL
}

provision AssignConform {
  subject#2 VisionRegistry
  subject#1 MissionRegistry
  condition "Assign responsibility and authority for ensuring that the SMS conforms to the { Mission for the organization (Data) } and { Vision for the organization (Data) } of the organization"
  modality SHALL
}

provision AgreeStandards {
  subject#2 StandardRegistry
  subject#1 Supplier
  condition "The initial list of {Standards (Data)} is agreed between the purchaser and {Standards supplier (ID: Supplier)}"
  modality SHALL
}

provision TopManagementEstablish {
  subject#3 DirectionRegistry
  subject#2 VisionRegistry
  subject#1 MissionRegistry
  condition "Establishe { Mission for the organization (Data) }, { Vision for the organization (Data) }, { Direction for the organization (Data) } for the organization"
  modality SHALL
}

provision LeadershipIdentifyRequirements {
  subject#2 StatutoryRequirementRegistry
  subject#1 CustomerRequirementRegistry
  condition "Ientify {Customer requirements (Data)} and applicable { Statutory and regulatory requirements (Data) }"
  modality SHALL
}

provision PriorConsent {
  subject#1 Purchaser
  condition "Prior consent from { Purchaser (Role) } shall be obtained"
  modality SHALL
  reference {
    Ref44
  }
}

6.6. Prevalence in production models

Subject binding is heavily used in production MMEL models:

• BS 202000 (Standardization management system): 221 subject#N occurrences across approximately 200 provisions. Nearly every provision binds at least one entity.
• BS 16341 (Selection of standards): 35+ occurrences. Provisions for each preference order bind a StandardDataRegistry subject.

This feature is one of the most extensively used compliance constructs in MMEL.

6.7. Relationship to condition text

The subject bindings and the condition text work together:

1. The subject#N fields declare which entities are relevant to the provision.
2. The condition text describes the requirement, using { ... } notation to indicate where entity names or descriptions appear.
3. The correspondence between subject#N numbers and the { ... } blocks in the condition text is by convention: the order of appearance in the condition text typically corresponds to increasing subject numbers.
4. This allows tooling to highlight or link the bound entities when rendering the compliance condition.

7.1. General

Conformance testing in MMEL is the process of evaluating whether a model or implementation satisfies the compliance obligations defined by its provisions and measurement validations. This clause describes the conformance assessment model, self-assessment checklists, progress tracking, and the overall compliance checking workflow.

7.2. Conformance assessment model

The MMEL conformance assessment model defines three levels of conformance:

Model conformance

A model is conformant if it is syntactically valid MMEL and correctly uses the constructs defined in the MMEL specification (provisions, processes, measurements, references, etc.).

Implementation conformance

An implementation (captured as an implementation model) is conformant if all its processes satisfy their bound provisions and measurement validations. This requires evidence that each validate_provision and validate_measurement has been evaluated and passes.

Tool conformance

A MMEL-compliant tool is conformant if it can parse, validate, and evaluate MMEL models according to the requirements defined in the core specification.

7.3. Compliance checking workflow

The compliance checking workflow follows a layered approach:

Reference Model (standard)
  |
  +-- Define provisions with modality
  +-- Define data structures
  +-- Define process flows
  |
  v
Implementation Model (organization)
  |
  +-- Map processes to reference model
  +-- Bind provisions via validate_provision
  +-- Define measurements via validate_measurement
  |
  v
Evidence Collection
  |
  +-- Populate data registers (.sws files)
  +-- Record measurement values
  +-- Link to supporting documents
  |
  v
Compliance Check
  |
  +-- Evaluate each validate_provision
  +-- Evaluate each validate_measurement
  +-- Generate compliance report

1. The reference model defines the normative requirements (provisions with modality keywords, processes, and data structures).
2. The implementation model maps the organization's processes to the reference model and binds provisions.
3. Evidence is collected by populating data registers and recording measurement values.
4. Compliance checking evaluates each bound provision and measurement against the collected evidence.

7.4. Self-assessment checklists

MMEL supports self-assessment through the provision binding mechanism. Each process with a validate_provision declaration creates a checklist item that must be verified.

The checklist is generated from:

1. All provisions referenced by processes via validate_provision.
2. All measurement validations referenced by processes via validate_measurement.
3. The modality keyword of each provision determines its bindingness: SHALL and MUST items are mandatory, SHOULD items are recommended, MAY items are optional.

For each checklist item, the assessor records:

• Whether the provision is satisfied (pass/fail/not-applicable).
• Evidence supporting the assessment (document references, data records).
• Any notes or justifications for the assessment decision.

7.5. Progress tracking

Progress tracking monitors the overall conformance status of an implementation model across all its provisions and measurements.

Progress is tracked as:

1. The total number of provisions bound via validate_provision across all processes.
2. The total number of measurement validations bound via validate_measurement across all processes.
3. For each provision: whether evidence has been collected and whether it passes or fails.
4. The overall compliance percentage: the ratio of passing provisions to total mandatory provisions.

Progress categories:

• Complete -- all mandatory provisions pass, all measurements pass.
• Partial -- some provisions pass, others are pending or failed.
• Not started -- no evidence has been collected.

7.6. Overall compliance view

The overall compliance view provides a summary of conformance status:

+---------------------------------------+
| Overall Compliance View               |
|---------------------------------------|
| Total provisions:     N               |
| Mandatory (SHALL):    M               |
| Recommended (SHOULD): R               |
| Optional (MAY):       O               |
| Capability (CAN):     C               |
|                                       |
| Passed:               P               |
| Failed:               F               |
| Pending:              W               |
| Not applicable:       A               |
|                                       |
| Compliance rate:      P/M * 100%      |
+---------------------------------------+

7.7. validate_provision and validate_measurement

The two mechanisms for conformance checking are:

process UnderstandOrganizationContext {
  name "Management of issues"
  modality SHALL
  validate_provision {
    UnderstandContext
  }
  output {
    IssueRegistry
  }
}

process ApplyOverallCoverageRule {
  name "Apply the overall coverage principle"
  modality SHALL
  validate_provision {
    Provision47
  }
  validate_measurement {
    "[Total_Included_Emissions_In_Percentage] >= 0.95"
  }
}

7.8. Assessment process

The assessment process follows these steps:

1. Import the reference model -- load the normative model containing the provisions and processes.
2. Create or load the implementation model -- load the organization's implementation model that maps to the reference model.
3. Collect evidence -- populate data registers with actual data, record measurement values, and link supporting documents.
4. Run compliance check -- for each process with validate_provision or validate_measurement:
   1. Evaluate the provision condition against the collected evidence.
   2. Evaluate the measurement expression against the recorded values.
   3. Record the result (pass/fail/not-applicable).
5. Review results -- examine failed provisions, assess partial compliance, and identify areas requiring corrective action.
6. Generate compliance report -- produce a report summarizing the overall compliance status, including pass rates, failed provisions, and recommendations.

8.1. Provision

ProvisionDecl    ::= 'provision' IDENTIFIER '{' ProvisionField* '}'
ProvisionField   ::= 'condition' STRING
                   | 'modality' MODALITY
                   | SubjectBinding
                   | 'reference' '{' IDENTIFIER* '}'
SubjectBinding   ::= 'subject#' INTEGER IDENTIFIER

The SubjectBinding production matches the subject#N fields where N is a positive integer (1, 2, 3, ...) and the identifier is the entity being bound (a role ID or data registry ID).

8.2. Note

NoteDecl         ::= 'note' IDENTIFIER '{' NoteField* '}'
NoteField        ::= 'type' NOTE_TYPE
                   | 'message' STRING
                   | 'reference' '{' IDENTIFIER* '}'
NOTE_TYPE        ::= 'NOTE'
                   | 'EXAMPLE'
                   | 'DEFINITION'
                   | 'TABLE_REFERENCE'
                   | 'TABLE_OPTIONS'
                   | 'FOOTNOTE'

In .mmel files, only the NOTE type is used. The other types appear in .sdc files or measurement contexts.

8.3. Reference

ReferenceDecl    ::= 'reference' (NAMESPACE '#')? IDENTIFIER '{' RefField* '}'
RefField         ::= 'document' STRING
                   | 'clause' STRING
                   | 'title' STRING
NAMESPACE        ::= IDENTIFIER

The optional NAMESPACE '# prefix enables cross-model reference declarations.

8.4. Modality

MODALITY         ::= 'SHALL'
                   | 'MUST'
                   | 'SHOULD'
                   | 'MAY'
                   | 'CAN'

8.5. Process compliance fields

ProcessComplianceField ::= 'validate_provision' '{' IDENTIFIER* '}'
                         | 'validate_measurement' '{' STRING '}'
                         | 'modality' MODALITY

8.6. Approval compliance fields

ApprovalComplianceField ::= 'modality' MODALITY
                          | 'reference' '{' IDENTIFIER* '}'
                          | 'approval_record' '{' IDENTIFIER* '}'

8.7. Complete provision examples in grammar

(* Provision with single subject *)
provision StandardMeetEnvironment {
  subject#1 StandardRegistry
  condition "{ Standards (Data) } selected meet environmental requirements"
  modality SHALL
}
(* Provision with multiple subjects *)
provision AssignConform {
  subject#2 VisionRegistry
  subject#1 MissionRegistry
  condition "Assign responsibility... conforms to the { Mission } and { Vision }"
  modality SHALL
}
(* Provision without modality (Statement) *)
provision Provision2 {
  condition "URL: https://crimson.ribose.com"
}