<-References Go to ToC Processes ->

The MMM-TEC standard has been developed based on ten design principles:

  1. Metaverse objects as interoperable Items: Items are signed assemblies of data specified by JSON Schemas with technology descriptors expressed as Qualifiers (Sub‑Type, Format, Attributes).
  2. Actions in metaverse are Rights‑centric: Processes are metaverse actuators operating on the basis of Deontic permissions (May), prohibitions (May Not), and Obligations (Must) governing all Actions on Items.
  3. Speech Acts as contracts represented by Process Actions: Interactions are expressed as Process Actions acting on Items via Complements and producing explicit outcomes (PA Status).
  4. Separation of concerns in security: Rules are set by the M‑Instance Manager (Governance) and Enforcement is specified by MMM-TEC but is mechanism‑neutral.
  5. Federated trust: Resolution enables cross‑M-Instance interoperation; trust is based on governance/trust agreements among parties.
  6. Auditable activity: Activity Data (logs) can be collected and be verified; concrete tamper‑resistant evidence is implementation‑defined.
  7. Inter‑Process Protocol & value transfer: Service invocation and payments are “first‑class” (Value→Wallet).
  8. Capability exposure & conversion: Capabilities are advertised; Conversion Services bridge Qualifier gaps.
  9. Fault-reporting Items: Fault Behaviour Report (intra‑instance) and Fault Detection Report (cross‑instance) are standard claim/alert payloads.
  10. Capability scoping (Profiles): The Baseline/Finance/Management/High Profiles keep implementations focused to the needs of applications.

The following text describes the architecture and the operation of MMM-TEC using a subset of the normative MMM-TEC elements. The full specification of all MMM-TEC elements, however, is delegated to the relevant MMM-TEC Chapters.

A metaverse instance (M-Instance) is an Information and Communication Technologies (ICT) platform implementing this MMM-TEC specification. Its main feature is to be populated by Processes that:

  1. May be imported (UM-Sent) by a human Registering with the M-Instance. The human
    1. Requests to open an Account of a certain class.
    2. May be requested to provide their Personal Profile and perform a Transaction.
    3. Obtains a set of Rights that their Processes may exercise.
    4. May need to have their Processes Certified for them to be imported.
  2. Operate with various degrees of autonomy and interactivity under the responsibility of the M-Instance Manager, Third-Party Service Providers, or humans who reside in the Universe, i.e., the real world.
  3. Perform
    1. Actions whose name may begin with:
      1. MM: to indicate Actions performed inside the M-Instance, e.g., MM-Animate using a stream or a command to animate a 3D Model Object with a Spatial Attitude (defined as Position, Orientation, and their velocities and accelerations).
      2. MU: to indicate Actions originated in the M-Instance but influencing the Universe, e.g., MU-Add to place a physical object (R-Item) at a Location with a Spatial Attitude or to MU-Move it from a U-Location to another U-Location.
      3. UM: to indicate Actions originated in the Universe and influencing the M-Instance, e.g., UM-Capture to acquire Data by capturing a scene or an object at a U-Location using a Qualifier of the Data.
    2. On
      1. Processes, and/or
      2. Items, signed assemblies of Data each composed of:
        1. A unique Identifier.
        2. Data proper to the Item that has been Identified in, and thus recognised by, the M-Instance.
        3. A Qualifier of the Data (providing the format, transport, etc. used by the specific instance of the Data).
        4. Capabilities that include the Rights held by identified Processes on the Item.
        5. The Identifier of the Item that spawned it.
        6. Trace – name of Process that produced the Item and Time it was produced.
        7. A standard format specified as a JSON Schema.
    3. According to the M-Instance or M-Environment Rules and its Rights.
  4. Request another Process to perform the Action, either on their initiative, or driven by the actions of humans or machines in the Universe, using the Inter-Process Protocol, possibly after Transacting a Value (i.e., an Amount in a Currency) to the Wallet of the requested Process based on a Service Pricing Model, in case the requesting Process cannot (does not have the technology) or may not (does not have the Rights) perform the Process Actions.
    1. The request is called Process Action Request if the Action is requested to another Process. A Process Action Request is expressed by: deontic verb + Action + set of Complements (Nil/At/From/To/With) + Item or ProcessID) + If Event where:
      1. Deontic verbs are May, May Not, and Must corresponding to Permission, Prohibition, or Obligation.
      2. The Complements: (e.g., Nil, At, From, To With, etc.) are applied to Items and Processes.
      3. Event is a Process Action or a logical combination thereof and Time whose performance triggers the execution of a Process Action.
    2. The response is called Process Action Response and consists of one or more Complements (Nil/At/From/To/With) – Item or ProcessID and PA Status, where:
      1. The first part conveys the result of the executed Process Action Request, and
      2. PA Status reflects success or failure in the Process Action Request execution.
  5. May hold a set of Rights on Items or Processes, i.e., may perform the set of Process Actions that are listed as Rights of the Process. The notion of Rights may also be applied to an Item to signal which Processes may perform which Processes Actions on it. Rights have Levels indicating that a specific set of Rights is:
    1. Internal, e.g., assigned by the M-Instance at Registration time according to the M-Instance Rules and Account type.
    2. Acquired, e.g., obtained by initiative of the Process.
    3. Granted to the Process or Item by a Process.
  6. Expose its Capabilities. A slightly modified format is used to expose the capabilities of an M-Instance and of an Item.
  7. Are characterised as:
    1. Services providing specific functionalities, such as content authoring.  They are classified as:
      1. Centralised Services, because they that act at the M-Instance level.
      2. Distributed Services that are typically executed in a subset of an M-Instance (M-Environment) in coordination with the Centralised Services but may also executed
        as Distributed Services.
      3. Third-Party Services that are offered by third-party service providers.
    2. Devices connecting the Universe to the M-Instance and the M-Instance to the Universe.
    3. Apps running on Devices.
    4. Users representing and acting on behalf of human entities, residing in the Universe and possibly rendered as Personae, i.e., avatars.

MMM-TEC offers specific functionalities designed to support a virtual economy.

An Asset is an Item intended for Transaction that includes, in addition to the elements included in an Item, the Identifier of the Item that spawned it, the Provenance – the list of all Transactions executed on an Asset, first and last included – and Economic Metadata, namely, Currency, Service Pricing Model, Market Classes, Value Metadata IDs,  and Marketplace Policy IDs.

The Rules shall be made accessible to all Users having business with and within the M-Instance and may include:

  1. The carriage of Version ID and Effective Time condition.
  2. The procedure whereby the Rules may be changed and a new Version is made effective.
  3. The procedures for the investigation or enforcement of compliance with the Rules of an M-Instance.
  4. The procedure used by a Process to modify its Capabilities, e.g., its own economic Rules.
  5. Statistical information about the number of Assets available in a Market Class, relationship between supply and demand, frequency of time-dependent Asset exchange, and average price movement.
  6. Disclosure of conflicts of interest affecting fees, rankings, or visibility.
  7. Procedures for pausing markets, rolling back affected Transactions, and communicating incident status to par-
  8. The types and number of Messages that a Process may send to a Centralised or Distributed Service.
  9. The degree of control applied to the Actions performed by a Process (full, random, or no control) and, in case of the random selection, the selection criteria.
  10. How Activity Data is recorded and In which conditions an Action can be recalled.
  11. The sanctions for infringing Actions.
  12. The ability of a Process to view the Rights of a Process or an Item.
  13. The rendering of and access to the Identity associated with an activated Persona.
  14. The conditions under which access to the Personal Profile is permitted.

Two M‑Instances may establish an active Resolution session using the Inter-Process Protocol (for different M-Instances). If they are bound by a governance/trust agreement, each M‑Instance may treat Items originating from the other as if locally originated. In this federated model, interoperable use of Rights relies on

  1. The foreign Item being a signed assembly with Capabilities including Rights held by identified Processes, (ii) globally unique Identifiers for Items and Processes, and
  2. (iii) the receiving M‑Instance’s verification of Item integrity and compliance with local Rules at the Effective Time. MMM‑TEC does not require a portable Rights‑proof artefact in this case; interoperable recognition follows from the combination of Resolution, signed Items, and external governance.

An M-Instance is managed by an M-Instance Manager. At the initial time, the M-Instance Manager has Rights covering the M-Instance and may decide to define certain subsets inside the M-Instance – called M-Environments – on which it has Rights and to attach Rights to them. These are some of the functions that may be relevant to an M-Instance implementation and may be retained by an M-Instance Manager, e.g.:

  1. Management of the M-Instance.
  2. Establishment of M-Instance Rules.
  3. Installation and maintenance of Services.
  4. Definition of Account Types.
  5. Monitoring of Process Actions
  6. Sanctions to infringers.
  7. Resolution of conflicts.
  8. Certification of Processes and Data Types.

MMM-TEC does not specify how an M-Instance verifies that a Process’s Process Actions are compliant with the Process’s Rights or the M-Instance Rules. An M-Instance may decide to verify the full set of Activity Data (the log of Process Actions performed), to make verifications based on claims by another Process, to make random verifications, or to not make any verification at all. Therefore, MMM-TEC does not specify how an M-Instance Manager can sanction transgressing Processes.

In some cases, an M-Instance could be wastefully too costly as an undertaking if all the MMM-TEC-specified technologies were mandatorily to be implemented, even if the particular M-Instance had limited scope. MMM-TEC specifies Profiles to facilitate the implementations of conforming M-Instances that are unduly burdened by the requirements of other application domains.

A Profile includes only a subset of the Actions and Items that are expected to be needed and are shared by a sizeable number of applications. MMM-TEC defines four Profiles (see Figure 1):

  1. Baseline Profile enables basic applications such as lecture, meeting, and hang-out.
  2. Finance Profile enables trading activities.
  3. Management Profile enables a controlled ecosystem with more advanced functionalities.
  4. High Profile enables all the functionalities of the Management Profile with a few additional functionalities of its own.

Figure 1 – MMM-TEC V2.0 Profiles

MPAI developed and used some use cases in the two MPAI-MMM Technical Reports published in 2023 and developed to facilitate the MMM-ARC and MMM-TEC Technical Specifications. However, the Verification Use Cases have been included in MMM-TEC to verify that the currently specified Actions and Items support those Use Cases.

Figure 2 gives a summary view of some of the basic MMM-TEC elements.

Figure 2 – Main elements of an M-Instance

The fast development of certain technology areas is one of the issues that has so far prevented the development of metaverse standards. MMM-TEC deals with this issue by providing JSON Schemas and semantics for all Items. A JSON Schema may reference Qualifiers, MPAI-defined Data Types that provide additional information to the Data in the form of:

  1. Sub-Type (e.g., which colour space is used in a Visual Data Type).
  2. Format (e.g., which compression or file/streaming format is used in a Speech Data Type).
  3. Attributes (e.g., which Binaural Cues are used in an Audio Data Type).

For instance, a Process receiving an Object can understand from the Qualifier referenced in the Object’s JSON data whether it has the required technology to process it, or else it has to Convert it to obtain a version of the Object matching its Capabilities. This approach helps prolong the life of the MMM-TEC specification as in many cases only the Qualifier specification will need to be updated and not the MMM-TEC specification.

<-References Go to ToC Processes ->