What the MPAI Store is and does

MPAI — "Moving Picture, Audio and Data Coding by Artificial Intelligence" — is a standards organization that builds AI applications from standardized, swappable building blocks instead of monolithic systems. The MPAI Store is the ecosystem's trusted distribution hub.

This page paraphrases public MPAI material (mpai.store, mpai.community); it is not official MPAI text.

The building blocks

TermWhat it is
AIM — AI ModuleThe atomic processing component, with a defined function and a standardized interface (specified input/output). Any AIM can be swapped for another implementation with the same function and interface — this is MPAI's notion of interoperability. A composite AIM contains SubAIMs.
AIW — AI WorkflowAn assembly of AIMs wired together to perform a complete use case (e.g. answering a spoken question about an image).
AIF — AI Framework (MPAI-AIF)The standardized runtime that executes AIWs and AIMs. It provides a Controller plus services for inter-AIM communication, shared storage, and access to the MPAI Store.
MetadataEach AIW/AIM ships a JSON metadata document describing its identity, ports, sub-AIMs, topology, concrete implementations, and resource policies. That document is what this Store validates, rewrites, and publishes.

The Store's role

Under the MPAI-GME (Governance of the MPAI Ecosystem) standard, the Store is three things at once. This is the role the standard defines — not a description of what this registry performs; see the box below for that.

  1. Registration Authority — registers developers ("Implementers") and issues each a unique Implementer ID. Performed here.
  2. Verification gate — checks submissions before distribution, and tests their claimed conformance to the relevant MPAI standard. Partly performed here: this registry validates metadata against the schema and authenticates the implementer. It does not test conformance.
  3. Distribution catalogue — publishes approved implementations, labeled with their Interoperability Level, for consumers to find and run. Performed here as a catalogue only — implementers host their own artifacts; this registry never serves them.
What this registry actually checks — read this before you rely on a listing. A submission here is checked for two things: that its metadata validates against MPAI's published AIM/AIW metadata schema and is internally consistent, and that it came from a registered implementer holding a valid submission credential. That is the whole check. Everything published here therefore carries Interoperability Level 1. See the Disclaimer and how verification works.

The five ecosystem roles

These are the roles as MPAI-GME defines them, for the ecosystem as a whole. The "MPAI Store" row describes what a Store is specified to do — see the box above for what this registry does.

RoleResponsibility
MPAIDevelops the standards (Technical, Reference Software, Conformance, Performance).
ImplementersBuild AIM/AIW/AIF implementations and submit them to the Store.
Performance AssessorsMPAI-appointed bodies that assess an implementation's performance (reliability, robustness, fairness, replicability).
MPAI StoreRegisters Implementers, verifies security, tests conformance, labels by Interoperability Level, and distributes. This registry performs registration, schema validation and labelling only — it does not verify security, test conformance, or host artifacts.
UsersDownload and run implementations; may report Experience Scores.

The lifecycle

  1. Onboard. A developer registers and is issued an Implementer ID (/register).
  2. Submit. The Implementer sends the AIM/AIW metadata (and, in the full flow, the package, a fingerprint, and the URL where binaries are hosted) (/submit).
  3. Assess. The Store checks the submission's structure against the MPAI metadata schema and the implementer's credentials before it can be published.
  4. Assign & publish. The Store assigns an Implementation ID, stamps the metadata, rewrites the Implementations and ResourcePolicies sections, signs a trust statement, and publishes — returning the rewritten metadata to the developer.
  5. Consume. A consumer's SCI (Store Consumer Interface) searches the Store, reads the Implementation ID, fetches the metadata and signed statement, verifies them, downloads the AIMs, and a Controller instantiates and runs them inside an AIF.

Interoperability Levels (the trust signal)

MPAI labels each published implementation with one of three levels; trust increases from 1 to 3. The "what is verified" column describes what each level means in the MPAI standard — not what this registry performs. As above, this registry issues Level 1 only, on the basis of schema validation and implementer authentication.

LevelMeaningWhat is verified
Level 1Implementer-specific, but runs in a conformant MPAI-AIF.Security verified; conformance to MPAI-AIF tested.
Level 2Conforms to a published MPAI Application Standard (e.g. MPAI-MMC).Security verified; conformance to that standard tested.
Level 3Level 2, plus validated by a Performance Assessor.Additionally assessed Reliable, Robust, Fair, Replicable.

Worked example: MMC-AMQ

MMC-AMQ ("Answer to Multimodal Question") is an AI Workflow in the MPAI-MMC (Multimodal Conversation) standard: it takes a question as text/speech together with an image and produces an answer. Its top-level AIMs are:

MMC-AMQ (AIW) ├─ MMC-ASR Automatic Speech Recognition speech → text ├─ MMC-TIQ Text and Image Query (composite, 3 SubAIMs) │ ├─ OSD-VOI Visual Object Identification │ ├─ MMC-NLU Natural Language Understanding │ └─ MMC-AQM Answer to Question Module └─ MMC-TTS Text-to-Speech text → speech

The composite AIM with three SubAIMs is MMC-TIQ — a good worked example of the shape your metadata takes, because it exercises SubAIMs, ports and a topology all at once. Browse the registry to see what has been published so far.