MN 113-9: MMEL Workspace and Runtime

1.1. General

The MMEL workspace is the runtime environment in which an organization executes a model and manages the resulting evidence. While a model defines the "what" (data structures, processes, compliance requirements), the workspace manages the "when" and "how much" -- the actual data records produced during process execution.

1.2. Workspace concept

A workspace represents a single organization's execution context for one or more MMEL models. It contains:

• The data records stored in each data registry at a given point in time.
• Document records that capture evidence of process execution.
• The mapping state between implementation models and reference models.

The workspace is the bridge between the static model definition and the dynamic reality of organizational operations.

1.3. Execution workflow

The typical MMEL execution workflow follows this sequence:

1. Reference model -- A standard or regulation is expressed as an MMEL reference model, defining processes, provisions, and data requirements.
2. Implementation model -- An organization creates an MMEL implementation model that defines how it will comply with the reference model, including concrete processes, data registries, and mappings to the reference model.
3. Workspace execution -- The organization executes the implementation model through its operational processes. As processes run, they populate data registries with records stored in workspace state files.
4. Compliance verification -- Tools evaluate the workspace state against the reference model's provisions to determine compliance status.

+--------------------+     +--------------------+     +--------------------+
| Reference Model    |     | Implementation     |     | Workspace          |
| (.mmel)            |     | Model (.mmel)      |     | (.sws)             |
|--------------------|     |--------------------|     |--------------------|
| provision P1       |<----| map_profile { }    |     | docs {             |
| process RefProc    |     | process ImplProc   |     |   Registry1 {      |
| data_registry Ref  |     | data_registry Impl |     |     record1 { ... }|
| reference R1       |     | output { Impl }    |     |     record2 { ... }|
+--------------------+     +--------------------+     |   }                |
                            |                    |     | }                  |
                            | .map file          |     +--------------------+
                            | (mappings)         |
                            +--------------------+

1.4. Organization and workspace relationship

Each organization maintains its own workspace. The workspace is scoped to the organization's implementation model and contains data that is specific to that organization's operations.

• A single organization may have multiple workspaces for different compliance domains (e.g. one for ISO 27001, another for ISO 13485).
• A single workspace may aggregate data from multiple implementation models.
• Workspace data is persisted in .sws (workspace state) files.

1.5. Toolchain support

MMEL-compliant tools:

1. SHALL be able to parse and display workspace state files ( .sws).
2. SHOULD be able to populate workspace state through process execution simulations.
3. MAY support concurrent multi-user workspace editing.
4. MAY provide workspace diff and comparison capabilities.

2.1. General

Workspace state files ( .sws ) are JSON files that store the runtime data state of an MMEL model. They contain the actual data records that have been populated in data registries through process execution.

2.2. File format

Workspace state files use JSON format with the following top-level structure:

2.3. Structure hierarchy

The docs object follows a hierarchical path:

docs -> namespace -> store -> registry -> docs -> record

At each level:

2.4. DocumentStore

The top-level docs object acts as a collection of namespace-scoped document stores:

{
  "docs": {
    "<Namespace>": {
      "id": "<Namespace>",
      "store": {
        "<RegistryID>": {
          "id": "<RegistryID>",
          "docs": {
            "<RecordID>": { ... }
          }
        }
      }
    }
  }
}

2.5. DocumentRecord

Each document record represents a single entry in a data registry. It has the following structure:

2.6. DocumentData

The attributes object within a record contains key-value pairs where:

• Each key corresponds to a field name defined in the data class referenced by the data registry.
• Each value is the current data for that field.
• The attribute types match the field types defined in the data class schema (string, boolean, datetime, role, reference, enum).

2.7. Complete example

The following is a complete workspace state file example:

{
  "docs": {
    "RiboseCrimson": {
      "id": "RiboseCrimson",
      "store": {
        "TestingRegistry": {
          "id": "TestingRegistry",
          "docs": {
            "6400790380169285": {
              "id": 6400790380169285,
              "name": "Happy first document",
              "attributes": {
                "string": "yes",
                "empty": "also yes",
                "boolean": "False"
              },
              "regid": "TestingRegistry"
            }
          }
        }
      }
    }
  },
  "version": "v1.0.0-dev1"
}

This example shows:

• Namespace RiboseCrimson contains a single store.
• The store contains one registry: TestingRegistry.
• The registry contains one record with ID 6400790380169285.
• The record has three attributes: string ("yes"), empty ("also yes"), and boolean ("False").
• The version field matches the model's semantic version.

2.8. Multiple registries example

A workspace may contain multiple registries within the same namespace:

{
  "docs": {
    "ABCLtd": {
      "id": "ABCLtd",
      "store": {
        "TotalCostOfOwnership": {
          "id": "TotalCostOfOwnership",
          "docs": {
            "1001": {
              "id": 1001,
              "name": "Cable procurement cost",
              "attributes": {
                "price": "5000",
                "deliverCost": "200",
                "installation": "300",
                "energy": "150",
                "maintenance": "100",
                "disposal": "50"
              }
            }
          }
        },
        "SupplierRating": {
          "id": "SupplierRating",
          "docs": {
            "2001": {
              "id": 2001,
              "name": "Supplier A rating",
              "attributes": {
                "supplier": "1001",
                "rating": "distinctive"
              }
            }
          }
        }
      }
    }
  },
  "version": "v1.0.0-dev1"
}

2.9. File encoding

Workspace state files SHALL use UTF-8 encoded JSON. Numeric record IDs are generated as 64-bit integers by MMEL-compliant tooling.

3.1. General

Data registers are populated at runtime through process execution. When a process runs, it writes data records to the registries specified in its output { } property. When a process needs to read existing data, it accesses registries specified in its reference_data_registry { } property.

This clause describes the mechanism by which processes interact with data registries during workspace execution.

3.2. Output binding: registry write

When a process executes successfully, it produces data that is written to the registries listed in its output { } property:

process GiveRating {
  name "Give Ratings to suppliers"
  actor SupplierSelectionPanel
  reference_data_registry {
    SupplierCapacity
  }
  output {
    SupplierRating
  }
}

In this example:

• The process reads from the SupplierCapacity registry to get supplier data.
• Upon completion, it writes a new record to the SupplierRating registry.

The output binding creates a new DocumentRecord in the workspace state file under the target registry. The record's attributes are populated with values corresponding to the data class fields of the registry.

3.3. Reference data registry: registry read

When a process needs to access existing data, it uses the reference_data_registry { } property:

process GiveRating {
  name "Give Ratings to suppliers"
  actor SupplierSelectionPanel
  reference_data_registry {
    SupplierCapacity
  }
  output {
    SupplierRating
  }
}

The reference_data_registry property indicates that this process reads from the SupplierCapacity registry. During execution, the tooling makes the records in that registry available to the process logic.

3.4. Data flow between processes

Processes form a data pipeline through registry bindings:

process SupplierExperience {
  name "Provide supplier experience"
  actor Supplier
  output {
    SupplierCapacity
  }
}
process GiveRating {
  name "Give Ratings to suppliers"
  actor SupplierSelectionPanel
  reference_data_registry {
    SupplierCapacity
  }
  output {
    SupplierRating
  }
}

1. SupplierExperience writes to SupplierCapacity.
2. GiveRating reads from SupplierCapacity (consuming the output of SupplierExperience).
3. GiveRating writes to SupplierRating (producing new data for downstream consumers).

This creates a data dependency chain:

SupplierExperience  --writes-->  SupplierCapacity  --read-by-->  GiveRating  --writes-->  SupplierRating

3.5. Lifecycle of a data record

A data record follows this lifecycle within the workspace:

1. Creation:
   A process with output binding creates a new DocumentRecord.
   The record ID is generated automatically.
   Attributes are populated from process execution data.
2. Storage:
   The record is stored in the workspace state file (.sws)
   under the target registry's docs collection.
3. Access:
   Other processes with reference_data_registry binding
   can read the record from the workspace state.
4. Update:
   Records may be updated by subsequent process executions
   that write to the same registry.
5. Deletion:
   Records may be removed from the workspace state file
   through explicit tooling operations.

3.6. Record creation

When a process writes to a registry, the tooling:

1. Generates a unique numeric record ID.
2. Creates a DocumentRecord with the generated ID.
3. Populates the attributes object with values matching the data class fields.
4. Sets the name field to a human-readable description.
5. Stores the record in the workspace state file under the registry's docs collection.

3.7. Schema validation

The attributes of a record are validated against the data class referenced by the registry:

• Field types (string, boolean, datetime, role, reference, enum) are checked.
• Required fields (those with modality SHALL) must be present.
• Reference fields must point to valid record IDs in the target registry.
• Enum fields must contain values from the defined enumeration.

Validation occurs at write time. If a record does not conform to the data class schema, the write operation SHALL fail with a validation error.

4.1. General

Document records are the fundamental data units stored in workspace state files. Each record represents a single data entry in a registry, with attributes matching the fields defined in the registry's data class.

4.2. Record structure

A document record has the following structure:

{
  "id": <RecordID>,
  "name": "<RecordName>",
  "attributes": {
    "<fieldName>": "<value>",
    "<fieldName>": "<value>"
  },
  "regid": "<RegistryID>"
}

4.3. ID generation

Record IDs are generated automatically by MMEL-compliant tooling. The ID:

• is a 64-bit integer, typically generated as a unique random or sequential number.
• is unique within the registry collection.
• is used for cross-referencing between records (e.g. reference field types).

Example IDs: 6400790380169285 , 1001 , 2001 .

4.4. Name and attributes

The name field provides a human-readable identifier for the record. This is typically entered by the user or generated from key attribute values during process execution.

The attributes object contains the actual data of the record. Each key corresponds to a field name in the data class, and each value is the current data for that field:

{
  "id": 1001,
  "name": "Cable procurement cost analysis",
  "attributes": {
    "price": "5000",
    "deliverCost": "200",
    "installation": "300",
    "energy": "150",
    "maintenance": "100",
    "disposal": "50"
  }
}

4.5. Attribute types

Attribute values in records correspond to the field types defined in the data class:

4.6. Reference attributes

When a data class field uses the reference(Target#data) type, the corresponding attribute value in the record stores the ID of the referenced record:

class SupplierRating#data {
  supplier: reference(SupplierCapacity#data) {
    definition "Supplier's response"
  }
  rating: SRating {
    definition "Rating"
  }
}

The corresponding record:

{
  "id": 2001,
  "name": "Supplier A rating",
  "attributes": {
    "supplier": "1001",
    "rating": "distinctive"
  }
}

The supplier attribute contains ” 1001 “ , which is the ID of a record in the SupplierCapacity registry. The rating attribute contains ” distinctive “ , which is one of the defined values in the SRating enumeration.

4.7. JSON-LD repository format

Workspace state files use a JSON structure that is compatible with JSON-LD conventions:

• The @context field (in .map files) provides a JSON-LD context URI.
• The id fields at each level serve as JSON-LD @id identifiers.
• The hierarchical structure follows JSON-LD nested node patterns.

This design enables future integration with linked data platforms and semantic web technologies, while remaining simple and self-contained for current tooling.

4.8. Record retrieval

Records within a registry are accessed by their ID:

docs["<Namespace>"]["store"]["<RegistryID>"]["docs"]["<RecordID>"]

This path navigates through the workspace state file hierarchy to retrieve a specific record. Tools SHALL support this access pattern for reading and writing records.