<-References Go to ToC User Agent ->
1 The Reference Model
Figure 1 depicts the Reference Model of MPAI-AIF V3.0. It has three tiers:
- Above the Controller: the User Agent, and the Module it drives, with what lies beyond the Module – another Controller, an AIM host, a Remote Client.
- The Controller, which the User Agent and the AIMs of the Module deal with only through the Controller API.
- Beneath the Controller, the services it uses: the MPAI Store, Communication, Shared Storage, Access and Trust.
Figure 1 – Reference Model of MPAI-AIF V3.0
The Reference Model is the same whether the User Agent and the Controller are in one process or on two machines. Where they are on two machines, the Controller API is carried over the network by MPAI-MAS: the User Agent is then a Remote Client Application and the Controller a Service Controller Instance.
2 Components
2.1 User Agent
The User Agent implements an Application. It decides the sequence of steps, acquires data from the real world and delivers data to it, and drives a Module by requesting the Controller through the Controller API. It comprises:
- Workflow: what the User Agent does, and in what order, written in the Workflow Description Language and interpreted at run time.
- Physical Layer: the Acquisition Units and Delivery Units that take data from, and deliver data to, the devices – microphone, camera, keyboard, avatar, sensors, actuators – reached through the Physical Layer API. Acquisition and delivery are the User Agent’s acts, never an AIM’s.
- Record and playback of what crosses a Module’s boundary.
- Identity and sessions: one session per client of a Service.
The User Agent gives and obtains data by Data Type and Port Number. It shall not address an AIM, and shall not depend on the Metadata of the Module it drives.
2.2 AI Module (AIM)
An AIM is a processing element that receives data at its input Ports and produces data at its output Ports according to its Function. It is Basic, or Composite: an aggregation of AIMs connected by a Topology. It may be implemented in software, hardware or both, and may run in the Controller’s process, in another process, or on another machine. A Port is addressed by its Data Type and Port Number, never by its name. An AIM keeps no state of an interaction between executions: state that must persist travels as data or is kept in Storage.
2.3 Module
A Module is the AIM, Basic or Composite, that a Controller runs. Its boundary Ports are the only points at which a User Agent reaches it, and they carry every datum a User Agent is to give or to obtain. A Composite Module is a set of AIMs connected by Channels according to its Topology, and has a Private Storage. A Module may have External Ports, through which it exchanges data with Modules run by other Controllers.
2.4 Controller
The Controller is responsible for the life cycle of a Module. It:
- obtains a Module’s Metadata and the Implementations of its AIMs from the MPAI Store, and verifies them;
- builds the Module from its Metadata, resolving the Topology once, at load time, into connections of Data Type and Port Number;
- instantiates the AIMs – in its own process, or on an AIM host – establishes every Channel the Topology declares, and binds each AIM’s Port and Storage handles;
- executes the Module by exchange or continuously, as its Metadata declares (Execution), and starts, pauses, resumes and stops it and its AIMs;
- keeps the status of each AIM – alive, degraded, dead – and applies the Module’s policy when one degrades;
- keeps one time base and stamps every Message and every Storage write;
- keeps the sessions of its clients, and deletes what a session kept when it ends;
- verifies every AIM before it runs, and records every trust decision (Zero Trust).
The Controller alone decides which AIM may reach which Port; an AIM cannot open a Channel of its own. The Controller need not carry the data it decides about.
2.5 Another Controller, AIM host, Remote Client
- Another Controller: a Controller in range running the same type of Module – another vehicle, for instance – with whose External Ports a Module exchanges Messages, each signed by its sender.
- AIM host: a program that runs AIMs of a Module on another machine, under the control of the Module’s Controller, admitted by the Trust Protocol. It is the Controller’s instrument, not a Controller.
- Remote Client: a User Agent on another machine, using the Controller API over MPAI as a Service.
2.6 MPAI Store
The MPAI Store is a repository of approved Metadata and of the Implementations it names. It validates the Metadata of an Implementation against the Metadata of its Standard, records the fingerprints of approved Implementations, and verifies that an Implementation is the approved one. It never runs an AIM and is not addressed by a User Agent at run time.
2.7 Communication
Communication moves data: between the AIMs of a Module, between the User Agent and the Module’s boundary, between a Module and AIMs on other machines, and between Controllers. A Channel joins an output Port to the input Ports the Topology connects to it, and is carried by a transport – in process, between processes, to another machine, to another Controller – that the AIMs never see. An input Port may declare how it behaves when full or when data are old. Large payloads may travel by reference within a Controller.
2.8 Storage
Storage carries data across time, and is governed as Communication is. The Private Storage of an AIM is reached by that AIM alone; the Private Storage of a Module by its AIMs, by the Controller on its behalf and by the User Agent that drives it; Shared Storage by the Modules given the same location. Every datum is written under rules – its readers, its category, its lifetime – and every write is stamped with its writer and time.
2.9 Access
Access provides the static or slowly changing data a Module needs, such as domain knowledge and data models.
2.10 Trust
Trust provides what the Controller needs to operate in a Zero-Trust environment according to MPAI-PTF: the identities and credentials of AIMs, the attestation of what they run, the Trust Protocol between Controllers and AIM hosts, and the signing of the Messages exchanged between Controllers.
3 Interfaces
Table 1 specifies the interfaces of the AI Framework.
Table 1 – Interfaces of the AI Framework
| Interface | Between | Function |
| Controller API, User Agent face | User Agent and Controller | Initialise and destroy the Controller; start, pause, resume and stop the Module; write to and read from its boundary Ports by Data Type and Port Number, with a timeout; reach Storage as its rules allow; record the boundary. Each call returns a named outcome. |
| Controller API, AIM face | An AIM and the Controller | Read and write the AIM’s own Ports, with a timeout; select among Ports with pending Messages; read the time; report; where allowed, request lifecycle changes of other AIMs and use External Ports. |
| Store API | Implementer, Controller and MPAI Store | Submit Metadata; find and retrieve Metadata and Implementations; verify an Implementation. |
| Security API | An AIM or the Controller and Trusted Services | Cryptography, attestation, secure storage and secure communication. |
| Trust Protocol | Controller and AIM host; Controllers | Mutual establishment of trust when a link is opened, according to MPAI-PTF. |
| MPAI-MAS | Remote Client and Service | The Controller API carried over HTTPS. |
4 AI Framework Implementations
MPAI-AIF enables a wide variety of Implementations:
- AIF Implementations can be tailored to different execution environments, e.g., High-Performance Computing systems or resource-constrained computing boards. For instance, the Controller might be a process on a HPC system or a library function on a computing board.
- There is always a Controller even if the AIF is a lightweight Implementation.
- The API may have different MPAI-defined Profiles to allow for Implementations to run on different computing platforms and different programming languages, and to be based on different hardware and resources available.
- AIMs may be implemented in hardware, software and mixed hardware and software. Interoperability between AIMs is ensured by the way communication between AIMs is defined, irrespective of whether they are implemented in hardware or software: compatible AIM Ports may be connected irrespective of the AIM implementation technology.
