<-References    Go to ToC    Processes ->

Ten design principles have driven the development of the MMM-TEC standard:

  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‑ and Rules‑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 inter-operation; trust is based on governance/trust agreements among parties.
  6. Auditable activity: Activity Data (logs) can be collected and 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 on the needs of specific application domains.

The following text describes the architecture and operation of MMM-TEC using a subset of its normative elements. The full specification of all MMM-TEC elements 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. An M-Instance is populated by Processes.

Processes

  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 before they can 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 residing in the Universe, i.e., the real world.
  3. Perform
    1. Actions whose names may begin with:
      1. MM: indicating Actions performed inside the M-Instance, e.g., MM-Animate, which uses a stream or command to animate a 3D Model Object with a Spatial Attitude (defined as Position, Orientation, and their velocities and accelerations).
      2. MU: indicating Actions originating 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 MU-Move to move it from one U-Location to another.
      3. UM: indicating Actions originating 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. Applied 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, and other characteristics of 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 – the name of the Process that produced the Item and the Time it was produced.
        7. A standard format specified as a JSON Schema.
    3. Based on:
      1. The M-Instance or M-Environment Rules and their own Rights.
      2. The security protocols of the Process Instance Trust Framework to establish trust, adding a Service Pricing Model to the content of messages sent to other Processes.
  4. Request another Process to perform an Action, either on their own initiative or driven by the actions of humans or machines in the Universe, using the Inter-Process Protocol. This may follow a Transaction of a Value (i.e., an Amount in a Currency) to the Wallet of the requested Process based on a Service Pricing Model, when the requesting Process cannot (lacks the technology) or may not (lacks the Rights) perform the Process Action itself.
    1. The request is called a Process Action Request when the Action is requested of another Process. A Process Action Request is expressed as: deontic verb + Action + set of Complements (Nil/At/From/To/With) + Item or ProcessID, where:
      1. Deontic verbs are May, May Not, and Must, corresponding to Permission, Prohibition, or Obligation.
      2. Complements (e.g., Nil, At, From, To, With) are applied to Items and Processes.
    2. The response is called a Process Action Response and consists of one or more Complements (Nil/At/From/To/With) followed by an Item or ProcessID and a PA Status, where:
      1. The first part conveys the result of the executed Process Action Request.
      2. PA Status reflects success or failure in the execution of the Process Action Request.
  5. May hold a set of Rights on Items or Processes, i.e., may perform the set of Process Actions listed as Rights of the Process. Rights may also be applied to an Item to specify which Processes may perform which Process 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 on the initiative of the Process.
    3. Granted to the Process or Item by another Process.
  6. Expose their 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, acting at the M-Instance level.
      2. Distributed Services, typically executed in a subset of an M-Instance (M-Environment) in coordination with Centralised Services, but which may also be executed independently as Distributed Services.
      3. Third-Party Services, 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.

Virtual Economy

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 standard Item elements, 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.

Rules

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 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, the relationship between supply and demand, the 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 participants.
  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 the case of 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.

Federated M-Instances

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.
  2. Globally unique Identifiers for Items and Processes.
  3. 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.

M-Instance Manager

An M-Instance is managed by an M-Instance Manager. At the initial time, the M-Instance Manager holds 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 which it may attach Rights. The following are examples of functions that may be relevant to an M-Instance implementation and may be retained by an M-Instance Manager:

  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 against 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 Actions are compliant with its Rights or the M-Instance Rules. An M-Instance may choose to verify the full set of Activity Data (the log of Process Actions performed), to make verifications based on claims by another Process, to perform random verifications, or to make no verification at all. Accordingly, MMM-TEC does not specify how an M-Instance Manager may sanction transgressing Processes.

Profiles

Implementing all MMM-TEC-specified technologies may be unnecessarily costly for M-Instances with limited scope. MMM-TEC therefore specifies Profiles to facilitate conforming implementations that would otherwise be burdened by requirements outside their application domain.

A Profile includes only the subset of Actions and Items expected to be needed by a sizeable number of applications in a given domain. 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, which facilitated the development of the MMM-ARC and MMM-TEC Technical Specifications. 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

Qualifiers

The fast development of certain technology areas has so far been one of the main obstacles to the development of metaverse standards. MMM-TEC addresses this by providing JSON Schemas and semantics for all Items. A JSON Schema may reference Qualifiers, MPAI-defined Data Types that provide additional information about 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 determine from the Qualifier referenced in the Object’s JSON data whether it has the technology required to process it, or whether it must Convert the Object to a version matching its Capabilities. This approach extends the useful life of the MMM-TEC specification, since in many cases only the Qualifier specification will need to be updated rather than the MMM-TEC specification itself.

<-References    Go to ToC    Processes ->