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.
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.
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.
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.
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:
- The RCA issues a request through the API Client to the API Server for the creation of an SCI.
- The API Server acts as a local User Agent of a Controller.
- The API Server returns the ID (created by the API server) of the newly created SCI to RCA.
- 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).
- 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.
- The MPAI Store receives requests from the SCI for delivery of AIW metadata and the subordinate packages that collectively describe the complete AIW.
- 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:
- As simple as a stand-alone web server responding to HTTP Get requests.
- Based on a distributed file system management service, such as HDSF and other variations.
- Based on a standard cloud object management and delivery service, such as Amazon S3 or Open Stack Swift.
- Fronted by an object authenticity management framework, such as The Update Framework.
- Any combination or variation of the above.
- The API Server returns the AIW ID, which was provided by the SCI to the RCA.
- 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.
- 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.
- 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.
- The RCA issues a request via the API Client through the API Server to the indicated SCI for the termination of the RWI.
- 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).
