1       Introduction. 1

2       Problem statement 1

3       What is requested. 2

4       Synopsis of the operation workflow.. 2

5       How to submit a response. 4

6       Evaluation Criteria and Procedure. 4

7       Timeline. 5

8       References. 5

Annex 1 – Information Form.. 6

Annex 2 – Mandatory text in responses. 7

 

1        Introduction

MPAI is planning on developing a standard allowing Remote Client Applications (RCA) to instantiate AI Workflows (AIW) on a Controller called Service Controller Instances (SCI) operating in accordance with the AI Framework (MPAI-AIF) standard [8]. This configuration is preliminarily called “MPAI as a Service (MaaS)”. Its practical implementation requires that SCIs be allowed to retrieve the AI Workflows from distributed repositories managed by the MPAI Store, the entity delegated to test the conformance and distribute implementations of AIW and its constituent AI Modules (AIM).

This Call for Technologies is issued with the goal to acquire the technologies that will enable MPAI to develop the MPAI as a Service standard possibly by extending the AI Framework (MPAI-AIF) standard.

2        Problem statement

Version 1 of MPAI-AIF was first approved in October 2021. The standard was adopted without modifications by IEEE with the number 3301.

The goal of MPAI-AIF is to provide an environment where AI Workflows (AIW) composed of interconnected AI Modules (AIM) exchange application data, are initialised, dynamically configured, and controlled. The MPAI-AIF Basic Profile illustrated in Figure 1 assumes a Zero-Trust AI Framework.

Figure 1 – Reference Model of the Basic Profile of MPAI-AIF

MPAI-AIF specifies the technical features of the Controller and a rich set of API enabling

  1. The Controller to call the MPAI Store from where conforming AIMs and AIWs can be downloaded.
  2. The User Agent to call the Controller.
  3. The AIMs to call the Controller.

The MPAI Store – a non-profit company registered in Scotland – is the entity delegated to assign Implementer Identifiers, verify that AIMs and AIWs conform to the MPAI-AIF standard, and make them available for users to download.

The MaaS Service considered by MPAI envisages that a Remote Client Application (RCA) can select an AI Workflow amongst those available in the MPAI Store, for download and execution by a Service Controller Instance (SCI), and retrieval of outputs resulting from execution of the AI Workflow.

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 when accessing AI Workflows and their constituent components.
  • The highest level of authenticity control be exercised on AI Workflows and their constituent packaged components.

3        What is requested

  • 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 Service Controller Instances to access a plurality of repositories each supporting different protocols.
  • Solutions proposed may be original, or rely on existing technologies, or any integration thereof.
  • If needed, proposals for revision of the MPAI-AIF Basic API, to accommodate requirements of the proposed technologies.

4        Synopsis of the operation workflow

Figure 2 depicts a reference model on which the future MPAI as a Service could be based.

Figure 2 – Reference Model of MPAI as a Service

Here is the workflow from SCI creation request to SCI termination request.

  1. 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 as SCI (the SCI is initialised by MPAI_AIFU_Controller_Initialize).
  3. The API Server returns the ID (created by the API server) of the newly created SCI to the RCA.
  4. RCA issues a request via the API Client through the API Server to the indicated SCI for the instantiation of a named AIW (by calling MPAI_AIFU_AIW_Start).
  5. The SCI retrieves the named AIW metadata from the MPAI Store which it then parses retrieving all the nested metadata and retrieving then installing the referenced packages as required for the instantiation of the AIW.
  6. MPAI Store receives requests from the SCI for delivery of AIW metadata and the subordinate packages collectively describing the complete AIW.
  7. If the MPAI Store possesses the requested elements, it returns the requested elements.
  8. If the MPAI Store does not possess some or all of the needed AIW elements, it issues requests to the appropriate remote repositories 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 variations of the above.
  9. The API Server returns the ID of the AIW, which was returned by the SCI, to the RCA.
  10. 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 Basic API must support the management of multiple AIWs).
  11. 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.
  12. The API Server returns to the RCA the output data message received from the specified Port of an AIM, which was returned by the indicated SCI.
  13. RCA issues a request via the API Client through the API Server to the indicated SCI for the termination of the indicated AIW (by calling MPAI_AIFU_AIW_Stop).
  14. RCA issues a request through the API Client to the API Server for the termination of the indicated SCI.

Table 1 describes the workflow above in a more compact form.

Table 1 – Typical MPAI as a Service workflow

# Who Does What Via Through To/From
1 RCA Issues SCI Creation Request API Client API Server
2 API Server Returns SCI ID RCA
3 RCA Issues AIW Instantiation Request API Client API Server SCI
4 SCI Issue AIW Request MPAI Store
5 MPAI Store Returns Requested elements SCI
5’ MPAI Store Issues Requested elements Request Rem. Repos.
5” Rem. Repos. Return Requested elements MPAI Store SCI
6 SCI Returns AIW ID API Server
7 API Server Returns AIW ID RCA
8 RCA Issues InMsg to AIM Port Request API Client API Server SCI
9 RCA Issues OutMsg fm AIM Port Request API Client API Server SCI
10 SCI Returns API Server
11 API Server Returns OutMsg fm AIM Port Request RCA
12 RCA Issues AIW termination Request API Client API Server SCI
13 RCA Issues SCI termination Request API Client API Server SCI

Figure 2 depicts the life cycle of an MPAI as a Service instance.

Figure 2 – The life cycle of an MPAI as a Service Instance

5        How to submit a response

Those planning to respond to this Call are:

  1. Informed that the MaaS Call will be presented at two online events held on 2026/04/02 at 08:00 UTC and 15:00 UTC. The recorded events and related material will be published at [7].
  2. Requested to communicate their intention to respond to the MPAI secretariat by 2026/04/08 with an initial filled out version of the form in Annex 1. Submissions of Annex 1 help MPAI to properly plan for reviewing the responses. However, an Annex 1 submission is not a commitment to submit a Response and a Response without a previous submission of Annex 1 will still be accepted.
  3. Advised to visit the MPAI-AIF web page regularly where relevant updates may be posted.
  4. Strongly encouraged to use the Template for Responses [6] when submitting a response to this Call.

A respondent is requested to present their Response at an online meeting properly announced by the MPAI Secretariat to the respondent. If the presenter of a submission does not attend that meeting, their Response will be discarded.

Respondents are advised that, upon acceptance by MPAI of their submission in whole or in part for further evaluation, MPAI will require that a non-MPAI member immediately join MPAI. If that Respondent elects not to join, their submission will be discarded. Directions on how to join MPAI are available here.

Further information on MPAI can be obtained from the MPAI website.

6        Evaluation Criteria and Procedure

The following process will be used to assess the Responses:

  1. An Evaluation Panel is created from:
    1. MPAI members in attendance.
    2. Non-MPAI members who are Respondents.
    3. Non-Respondents/non-MPAI member experts invited in a consulting capacity.
    4. (No one from 1.1.-1.2. will be denied membership in the Evaluation Panel).
  2. Respondents present their proposals to the Evaluation Panel and respond to any questions.
  3. Evaluation Panel members fill out the Annex 2 form for each proposal.
  4. A Final Evaluation Report is produced.

The Evaluation Form will contain the following elements.

Proposal title:

Response summary: (a few lines)

Comments on possible MaaS profiles1

Assessment of Response features:

Table 1 – Features to be considered in a Response

Submission features Evaluation Elements
Completeness of description A detailed description is recommended 
Understandability of description A detailed description is recommended 
Complexity of proposal The implementation complexity and technologies that are potentially usable to implement the proposal.
Reliance on established technologies When assessments are similar, preference will be given to proven technologies.
Availability of reference software When assessments are similar, preference will be given to technologies for which a running reference software is available.
Existence of Essential Patents A proposal that is unencumbered by IP may be selected against a functionally equivalent encumbered proposal.

7        Timeline

Timeline of the Call, deadlines and response evaluation:

Table 2 – Dates and deadlines

Step Deadline Time
Call issued 2026/03/18 17:00 UTC
Online presentation 2026/04/02 15:00 UTC
Notification of intention to submit a Response 2026/03/27 23.59 UTC
Imperative deadline for submission of Responses 2026/04/13 16.00 UTC

8        References

  1. MPAI; The MPAI Statutes
  2. MPAI; The MPAI Standards
  3. MPAI; The MPAI Workplan
  4. MPAI; The MPAI Patent Policy
  5. MPAI; Framework Licence: MPAI Metaverse Model V1.0
  6. MPAI; Template for Responses; MPAI Metaverse Model V1.0
  7. MPAI; MPAI Presentations; https://mpai.community/community/presentations/
  8. MPAI; Technical Specification: AI Framework (MPAI-AIF) V2.2

  • Annex 1 – Information Form

This information form is to be filled in by a Respondent to the MPAI-PGM Call

  1. Title of proposal:
  2. Organisation: company name, position, e-mail of contact person
  3. What are the main functionalities of your proposal?
  4. Will you provide a demonstration to show how your proposal meets the evaluation criteria?

 


  • Annex 2 – Mandatory text in responses

MPAI is willing to consider Responses whose implementation requires exploitation of third-party Intellectual Property. Therefore, even for responses not containing references to proprietary technologies, Respondents are required to include the following statements where Company/Member term is replaced by the name of the Responding non-MPAI member or MPAI member.

A Response to this MaaS Call must include the following text:

<Company/Member> submits this technical document as a Response to Call for Technologies: MPAI as a Service V1.0 (N2880).

<Company/Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N2774), in particular <Company/Member> declares that  <Com­pany/Member> or its successors will make available the terms of the Licence related to its Essential Patents according to Framework Licence: MPAI as a Service V1.0 (N2881), alone or jointly with other IPR holders after the approval of the corresponding Technical Specif­ication (“Standard”) by the General Assembly and in no event after commercial implementations of the Technical Specification become available on the market.

In case the Respondent is a non-MPAI member, the submission must include the following text:

If (a part of) this submission is identified for inclusion in an MPAI Technical Specification, <Company> understands that <Company> will be requested to immediately join MPAI and that, if <Company> elects not to join MPAI, this submission will be discarded.

During the development of the Standard, technical contribution must include this text:

<Member> submits this document to MPAI-AIF Development Committee (AIF-DC) as a con­tribution to the development of  a Technical Specification related to MPAI as a Service.

<Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N2774), in particular  <Company> declares that <Company> or its successors will make available the terms of the Licence related to its Essential Patents according to Framework Licence: MPAI as a Service V1.0 (N2881), alone or jointly with other IPR holders after the approval of the Technical Specification by the General Assembly and in no event after commercial implementations of the Technical Specification become available on the market.