Highlights

Public online presentations: MPAI as a Service Call for Technologies and MPAI Metaverse Model – Technologies V2.2

The 66th General Assembly (MPAI-66) has approved the publication of MPAI as a Service (MaaS) Call for Technologies. Register here to attend the public online presentation of the Call to be held on 30 March 2026 at 8 UTC and register here to attend the public online presentation of the Call to be held on 30 March 2026 at 15 UTC.

Responses should be sent to the MPAI Secretariat by 13 April 2026 at 16 UTC. The following newsletter provides a short introduction to the MaaS Call.

MPAI-66 has also approved the publication of Version 2.2 of the MPAI Metaverse Model – Technologies standard with a Request for Community Comments. Register here to attend the public online presentation of the MMM-TEC V2.2 standard to be held on 9 April 2026 at 15 UTC. Comments on the draft standard should be sent to the MPAI Secretariat by 9 May 2026. The subsequent newsletter provides a short introduction to MMM-TEC V2.2.

An introduction to the MPAI as a Service (MaaS) Call for Technologies

The 66th MPAI General Assembly (MPAI-66) has approved the publication of the “MPAI as a Service” Call for Technologies. To get a proper understanding of the positioning of this new standard in the MPAI Ecosystem, we should recall the basic elements of the AI Framework (MPAI-AIF) and the Governance of the MPAI Ecosystem (MPAI-GME) standards. The former specifies an environment where it is possible to initialise, dynamically configure, and control AI applications called AI Workflows (AIW) composed of connected processing elements called AI Modules (AIM). MPAI-AIF specifies two profiles – a Basic and a Security Profile.

Figure 1 depicts the MPAI-AIF Basic Profile Reference Model. You can see the Controller – the brain of the system – and the MPAI-AIF APIs enabling the Controller to obtain AIWs/AIMs from the MPAI Store, the place where implementers can submit their implementations for distribution after they have been tested for conformance with the standard and verified for security. Once the AI Framework is equipped with the desired domain-specific processing capabilities, the User Agent can activate the Controller, and the AIMs can call it via the appropriate APIs.

Figure 1 – Reference Model of MPAI-AIF Basic Profile

Let’s explore how things can unfold in this new scenario.
1       Creation of infrastructure

Creation of infrastructure is the responsibility of the deployment/control plane to avoid access to the application data plane by the control plane and vice-versa. The REST API protocol is used to specify the steps.

1.1      Connection to the SCI

SCI specifies the required security protocols that the RCA must employ for authentication and authorisation purposes. AIF should include an exemplary list of security protocols (basic, digest, bearer). The connection is required by all subsequent points and must be secured using one of the proposed security schemes described in End Point Open API.

1.2      Creation of an SCI

RCA asks the AIF end point for the creation of one or more SCIs to which all subsequent AIF API requests will be issued. The objective of SCI creation is the acquisition of an SCI identity for use in subsequent API requests to identify the intended SCIs among the many to which the message will be directed.

1.3      Workflow discovery

RCA submits a request to the Server API for AIW matching and discovery. The resulting collection of Workflow Descriptions is returned to the RCA for ultimate selection.

1.4      Launch of the desired AI Workflow

RCA submits a request to the SCI through the AIF end point for the launch of the desired AIW(s). The objective of Workflow launch is the acquisition of a Remote Workflow Instance (RWI) identity for use in subsequent API requests for identification of the intended AIW among the many with which input/output messages will be exchanged.

2       Message Exchange

Application data exchange is the responsibility of the application data plane thus ensuring non-exposure of application data to the control plane. The REST API protocol is used to specify the steps.

2.1      Delivery of messages to the input ports of the AI Workflow

RCA submits requests to the above-identified SCI, through the AIF end point for the delivery of AIF Messages containing application data to the desired input port(s) of the RWI(s).

2.2      Reception of messages from the output ports of the AI Workflow

RCA may submit requests to the above-identified SCI through the AIF end point for the reception of AIF Messages from the desired output port(s) of the launched RWI(s). The RCA makes provision for asynchronous delivery of the response when required.

2.3       Termination of infrastructure

The deployment/control plane is responsible for the avoidance of access to the application data plane by the control plane and vice-versa. The REST API protocol is used to specify the steps.

3    Termination

3.1      Termination of the AI Workflow

RCA submits requests to the SCI through the AIF end point for the termination of the RWI(s).

3.2      Release of the AIF Controller

RCA submits requests to the AIF end point for the termination of the above-identified SCI(s).

 

Figure 2 depicts an initial Reference Model of MPAI as a Service.

Figure 2 – MPAI as a Service Reference Model

 

An overview of the complete workflow is given by:

  1. The RCA issues a request through the API Client to the API Server for the creation of an SCI.
  2. The API Server acts as a local User Agent of a Controller.
  3. The API Server returns the ID (created by the API server) of the newly created SCI to RCA.
  4. The RCA issues a request via the API Client through the API Server to the indicated SCI for the instantiation of a named AIW (RWI).
  5. The SCI retrieves the named AIW metadata (describing the AIW) from the MPAI Store and then parses, retrieves, and installs the referenced packages as required for the instantiation of the AIW.
  6. The MPAI Store receives requests from the SCI for delivery of AIW metadata and the subordinate packages that collectively describe the complete AIW.
  7. The MPAI Store returns the requested elements if it possesses them, otherwise it issues requests to the appropriate remote repositories so as to retrieve the missing elements. The MPAI Store could be:
    1. As simple as a stand-alone web server responding to HTTP Get requests.
    2. Based on a distributed file system management service, such as HDSF and other variations.
    3. Based on a standard cloud object management and delivery service, such as Amazon S3 or Open Stack Swift.
    4. Fronted by an object authenticity management framework, such as The Update Framework.
    5. Any combination or variation of the above.
  8. The API Server returns the AIW ID, which was provided by the SCI to the RCA.
  9. The RCA issues a request via the API Client through the API Server to the indicated SCI for delivery of the accompanying input data message to the specified Port of an AIM of the indicated AIW.
  10. The RCA issues a request via the API Client through the API Server to the indicated SCI for reception of an output data message from the specified Port of an AIM of the indicated AIW.
  11. The API Server returns to the RCA the output data message received from the specified Port of an AIM, which was provided by the indicated SCI.
  12. The RCA issues a request via the API Client through the API Server to the indicated SCI for the termination of the RWI.
  13. The RCA issues a request via the API Client to the API Server for the termination of the indicated SCI.

To leverage the availability of AIMs and AIWs from various sources, MaaS requires that:

  • The access to the MPAI Store be ubiquitous to support envisaged application scenarios.
  • The highest level of authorisation be guaranteed by the SCI to an RCA when accessing AI Workflows and their constituent components.
  • The highest level of authenticity control be exercised by the SCI on AI Workflows and their constituent packaged components.\

MPAI-66 has issued a Call for Technologies requesting interested parties to propose:

  • An architecture for the management of the MPAI Store and the subordinate distributed repositories.
  • Protocol(s) that are considered suitable for supporting the above requirements.
  • Alternatively, a single interface enabling SCIs to access a plurality of repositories each supporting different protocols.
  • If needed, proposals for revision of the MPAI-AIF Basic API, to accommodate requirements of the proposed technologies.

Solutions proposed may be original, or rely on existing technologies, or be any integration thereof.

The MaaS Call will be presented at two online events held on 2026/03/30 at 8:00 UTC (register here to attend) and 15:00 UTC (register here to attend).

The novelties in MPAI Metaverse Model – Technologies V2.2

MPAI started addressing “metaverse” as a subject for standardisation in the early days of 2023 as an objective per se but also as an opportunity to integrate a plurality of technologies for which it had developed or was developing standards. After developing two Technical Reports exploring the issues, MPAI developed the MPAI Metaverse Model – Architecture (MMM-ARC) standard. This was followed by the MPAI Metaverse Model – Technologies (MMM-TEC) standards of which MPAI-66 has recently published Version 2.2.

In three years MPAI has invested significant resources in this project achieving important results. The initial MMM notions included things (Items) and beings (Processes) operating in a metaverse instance (M-Instance) under the responsibility of a human in conformity with the Rules of the M-Instance. Processes hold Rights on Items and Processes and can thus perform Actions on them. A Process may request another Process (e.g., a Service) to perform Actions on its behalf by issuing a Process Action. Twenty-eight Actions have been specified in terms of semantics, and more than 100 Items have been specified in terms of syntax (JSON Schema) and semantics. More than 50% of Items currently identified by MMM-TEC are defined by other MPAI Standards. The notion of Qualifier – metadata giving information such as format of an Item – has been fully adopted and integrated with the notion of a “Convert Service” to facilitate M-Instance interoperability as MMM-TEC does not impose any particular technology, such as for media.

MMM-TEC V2.2 inherits all the enabling technologies from preceding versions and enhances them with new technologies that provide full support for the establishment of virtual economies in an M-Instance.

This is the full list of finance-related Data Types specified by V2.2:

 

Acronym Name JSON Acronym Name JSON
MMM-ASS Asset X MMM-MKC Market Classes X
MMM-CTO Contract Object X MMM-PRV Provenance X
MMM-CUO Currency Object X MMM-SPM Service Pricing Model X
MMM-FBR Fault Behaviour Report X MMM-SCT Simple Contract X
MMM-FDR Fault Detection Report X MMM-TRA Transaction X
MMM-FER Financial Error Report X MMM-VAL Value X
MMM-LIC Licence X MMM-VMI Value Metadata IDs X
MMM-MPI Marketplace Policy IDs X MMM-WAL Wallet X

 

All MPAI specification entities – Data, AI Modules, and AI Workflows – are identified by six characters. The first three identify the standard (MMM in the case of Metaverse) and the remaining three the specific entity within that standard. Each entity (Data Types in this case) is specified in natural language on a specific web page (the table provides the links) and in a JSON Schema that may reference a Qualifier.

MPAI defines a “Simple Contract” that provides basic functionalities but also defines a Contract Object. The term “Object” indicates that the entity is composed of Data and a Qualifier. In the case of Contract, the Data are the contract, but the Qualifier specifies how to interpret the Data. MPAI acts as a Registration Authority that receives requests for new Contract Types not currently included in the Contract Qualifier.

The Asset Data Type is the key element of MMM-TEC finance. As for all MPAI Data Types, the natural language specification is subdivided into Definition (what the Data Type is for), Functional Requirements (the functionalities offered by the Data Type), Syntax (the JSON Schema), Semantics (the meaning of the data carried by an Asset Data Type instance), and Conformance Testing (how to test that an Asset Data Type instance is a correct implementation of the specification).

Let’s analyse what is inside the Asset Data Type, i.e., its semantics.

 

Label Description
Header Asset Header – Standard “MMM-ASS.Vx.y”
M-InstanceID Identifier of M-Instance.
M-Environment Identifier of a relevant Environment.
AssetID Identifier of the Asset.
SourceItemID Identifier of the Source Item that spawned the Asset.
AssetDate Timestamp of Asset creation.
Capabilities Declared process Capabilities and Rights (the Asset carries information on who holds which Rights to the Asset).
Provenance Information about the Asset provenance through a value chain.
MarketClass One of a set of categories of assets, rights, services, and experiences exchanged.
ValueMetadata Identifiers used to tag values associated with transactional or functional attributes.
CurrencyID Allowed currency type for pricing.
ServicePricingModel Rules, parameters, and conditions under which the Asset is offered, billed, chosen, settled, and accessed.
MarketplacePolicyID Identifier of the policy applied to listing, transaction, or operation of an Asset (Item or Service).
DataExchangeMetadata Metadata ensuring correct transfer of information from Source to Destination.
Trace Identity of the Process producing the Asset and its Time of production.
DescrMetadata Free-text metadata.

 

Of the elements in the first column, we will now concentrate on Service Pricing Model (SPM), a Data Type of high importance for establishing a virtual economy in an M-Instance. The following semantic table is much more structured, and so the specification of the different service pricing models has been simplified. The Asset Posting, Chosen, and Settlement parts retain the full details. The SPM Status label is used to signal the intermediate or final status of the Service Pricing Model.

 

Label Description
Header Service Pricing Model Header – Standard “MMM‑SPM‑Vx.y”.
MInstanceID Identifier of the M‑Instance.
MEnvironmentID Identifier of the M‑Environment.
SPMID Identifier of this Service Pricing Model instance.
SPMContext Whether this SPM describes a Service or an AssetPosting.
SPMTime Reference time for this SPM (OSD/V1.5 Time).
ModelType Primary pricing model: OneTime, Subscription, PayPerUse, PayPerTime, Freemium, Tiered, AdSupported, Hybrid (when combining multiple models).
CurrencyObject The currency for prices and values used in this SPM.
Models
├─ OneTime One‑time purchase model.
├─ Subscription Subscription pricing data.
├─ PayPerUse Usage‑based (metered) pricing.
├─ PayPerTime Time‑window pricing.
├─ Freemium Freemium model.
├─ Tiered Tiered plan.
├─ AdSupported Ad‑supported access.
├─ Discounts[] Discount definitions.
└─ Hybrid[] Hybrid composition (combining sections).
AssetPosting Data for posting an Asset under this SPM.
├─ AssetID ID of the asset being posted.
├─ LicenceTerms Terms under which the asset is licensed.
├─ SenderPreValue Value before transaction.
├─ SenderPostValue Value after transaction.
├─ ReceiverPostValue Value after transaction for receiver.
├─ ValueToSender Final value to sender.
├─ SenderWalletID Wallet of sender.
├─ ServiceProviderWalletID Wallet of service provider (marketplace).
├─ ServiceProviderLicence Licence of service provider.
├─ ReceiverLicence Licence of receiver.
└─ Transaction Transaction.
Chosen Frozen snapshot of the chosen model and parameters.
├─ ModelType Chosen model type.
└─ Parameters Set of parameters at selection time.
├─ EffectivePeriod Validity window.
│ ├─ Start Start time.
│ └─ End End time.
├─ Allowances[] Frozen quota allowances.
│ ├─ Meter Meter type.
│ ├─ Unit Unit of measure.
│ ├─ Quantity Quantity allowed.
│ ├─ Window Applicable window label.
│ └─ Rollover Whether unused quota rolls over.
├─ Overage Overage pricing.
│ ├─ Rate Overage rate.
│ └─ Unit Overage unit.
├─ RateLimit Rate limiting constraints.
│ ├─ MaxPerWindow Maximum allowed per window.
│ ├─ Window Window size.
│ └─ Burst Burst allowance.
└─ PriceBreakdown Optional breakdown of base price, discounts, and final charges.
Settlement Payment proof for the SPM‑governed transaction.
├─ SettlementTime Time of settlement.
├─ TargetID Identifier of relevant Service/Asset/Licence.
├─ Transaction Transaction reference.
└─ Evidence[] Optional receipts or provider references (Type, ID).
SPMStatus Either “Model” or “Final”.
DataExchangeMetadata Regulated/controlled exchange metadata.
Trace Information about the Process producing the SPM and the time of production.
DescrMetadata Free‑text descriptive metadata (≤ 2048 chars).

 

Version 2.2 specifies the protocols used by a Process when it requests another Process to perform a Process Action.

Here we describe the MM-Add protocol used by a Process to request a Locate Service to place an Item at a Location.

 

  1. User sends MM-Add Process Action (PA) Request including Item, Point of View, Location, and Rights (Status=Model).
    1. If MM-Add is a free service, goto MM-Add.
    2. If MM-Add is a pay service:
      1. User sends MM-Add PA Request with Service Pricing Model (Status=Model) to the Locate Service of which MM-Add is an element.
      2. Locate sends MM-Add PA Response:
        1. If MM-Add PA Response includes Status=Err, goto End
        2. If MM-Add PA Response includes Status=Ack and Service Pricing Model including Transaction (both Status=Model), User:
          1. Transacts Value contained in Transaction.
          2. Sends MM-Add PA Request with Service Pricing Model (Status=Model) including Transaction (Status=Final) to MM-Add.
        3. MM-Add: Locate
          1. MM-Adds Item.
          2. Sends MM-Add PA Response (to requesting Process) including
            1. Rights (Status=Final) for MM-Added Item.
            2. Service Pricing Model (Status=Final), if MM-Add is a pay service.
          3. End.

 

As you see, the Service Pricing Model is used as the vehicle to finalise the relationship between the Requesting Process and the Locate Service.

MMM-TEC V2.2 will be presented at the online event held on on 9 April 2026 at 15 UTC. Register here to attend.

Meetings in the March-April  2026 cycle