<-Data Types Go to ToC Reference Software ->

1 What conforms

An implementation of any of the entities of Table 1 may claim conformance with MPAI-AIF V3.0. It conforms when it meets the requirements the chapters of this Technical Specification state for it, and the requirements of the Profile it claims.

Table 1 – Entities and their requirements

Entity Conforms when Requirements
Controller It runs a Module as its Metadata declares, exposes the Controller API, and is the trust authority of the Module. CTR, EXE, COM, STO; the Basic API
AIM Implementation Its AIM Instance Metadata validates and is an instance of its AIM Metadata, and it behaves as the AIM its Standard specifies. AIM, MET
User Agent It drives a Module only through the Controller API and interprets Workflows as specified. UA, WDL
Workflow It is a valid Workflow of the Workflow Description Language, written against one Module. WDL
MPAI Store It approves, versions and verifies Metadata and Implementations as specified. STR

2 Profiles

A Controller conforms to a Profile if it meets the requirements of that Profile (Zero Trust and Profiles):

  • Basic Profile: the requirements of Zero Trust met with the secure transports of the platform and the fingerprints of the MPAI Store, and the Basic API.
  • Secure Profile: in addition, roots of trust in hardware, attestation of the Controller and of AIM hosts, Secure Storage, and the Security API.

The AIF Metadata of an Implementation declares its Profile; the AIM Metadata of an AIM declares the Profile it requires.

3 Conformance of an AIM Implementation

The conformance of an AIM Implementation has two parts:

  1. With MPAI-AIF: its AIM Instance Metadata validates against the AIM Metadata Schema and is an instance of the AIM Metadata its Header names (Metadata), and the Implementation meets the requirements of AI Modules. The MPAI Store checks the first when it approves the Metadata.
  2. With the Standard that specifies the AIM: it produces, from the Data Types at its Input Ports, the Data Types at its Output Ports as that Standard specifies, and the Conformance Testing of that Standard applies.

4 Means of testing

The following means support conformance testing:

  • The record of the boundary (Storage): what a Module was given and what it produced, with its stamps, written by the Controller. A record made with a reference Implementation, played back at its original rate to the Implementation under test, allows the outputs of the two to be compared.
  • Workflows (Workflow Description): a Workflow drives a Module identically on any conforming Controller, since it addresses the Module only by Data Type and Port Number.
  • The named outcomes of the Controller API (Basic API): a test can distinguish what did not happen from what went wrong.
  • The Trace: the signed and hash-chained record of the Controller’s decisions, against which an audit verifies its behaviour.
  • The Reference Software, as a reference Implementation.

A conformance test consists of a Test Module, a Test Workflow, recorded input data and the expected results:

  • A Test Module is a Module whose AIMs are replaced by test AIMs, each giving a defined, deterministic response on every Output Port it declares.
  • A Test Workflow drives the boundary Ports of the Test Module.
  • Recorded input data are records of the boundary of a Module (Storage), replayed to the boundary Input Ports at the pace their stamps give.
  • Expected results are stated per Data Type and Port Number.

A Controller conforms when, for every test, the data at the boundary of the Test Module equal the expected results. AIM Instance Metadata conforms when it is an instance of its AIM Metadata (Metadata). A Workflow Description conforms when it is read without error and every Port it offers to or asks of is declared by its Module.

<-Data Types Go to ToC Reference Software ->