<-References    Go to ToC    Processes ->

The development of the MMM-TEC standard has been driven by 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‑ 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. DataExchangeMetadata – information about the Item being communicated to another Process.
        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.

Security

MMM-TEC does not define the mechanisms whereby trust is established between Processes. Such mechanisms are  provided by the Process Instance Trust Framework (MPAI-PTF) standard. MMM-TEC, however, defines the information exchanged by Processes and therefore provides the context on which trust decisions may be based. Consider the case where Process A requests Process B to perform a Modify Process Action on an Item. The request may be expressed colloquially as:

Modify Item C With Item D requesting Rights E (Status=Model) and performing Transaction F (Status=Model).

In this example:

  • Modify is the requested Action.
  • Item C is the Item to be modified.
  • Item D is the Item used to perform the modification.
  • Rights E (Status=Model) denotes a set of Rights requested by Process A but not yet granted.
  • Transaction F (Status=Model) denotes a proposed Transaction that does not yet exist but may be established if the request is accepted.

The request therefore contains an Action and a Context. For the purpose of trust establishment:

  • The Action identifies the operation requested to be performed by Process B.
  • The Context consists of the structured information accompanying the Action and required by a Trust Authority to evaluate whether trust may be established between the participating Processes for the requested interaction.

The Context may include:

  • Items and Processes referenced by the request.
  • Requested Rights having Status=Model.
  • Requested Transactions having Status=Model.
  • Complements such as At, From, To, and With.
  • Any additional information required by governance Rules, Service Pricing Models, or other applicable policies.

Using the MPAI-PTF trust framework, a Trust Authority may evaluate:

  • Whether Process A is authorised and credible as requester of the Action in the specified Context.
  • Whether Process B possesses the identity, credentials, evidence, Rights, and capabilities required to perform the Action.
  • Whether the requested future state, including proposed Rights and Transactions, complies with applicable Rules and policies.

If trust is established, Process B may accept the request and execute the Action. In this case, execution results in:

  • A modified version of Item C (a new Item G with a new ID).
  • The granting of Rights H (Status=Final) corresponding to Rights E (Status=Model).
  • The completion of Transaction F (Status=Model) as Transaction I (Status=Final).

If trust cannot be established, the request may be rejected and none of the proposed state changes represented by Rights E (Status=Model) or Transaction F (Status=Model) shall take effect. This separation enables MMM-TEC to specify Actions, Rights, Items, Transactions, and their semantics while allowing the MPAI-PTF external trust framework to determine whether participating Processes may be trusted to engage in a requested interaction.

If trust is established, Process A and Process B may exchange information complemented by Data Exchange Metadata. This provides various types of information related to a data instance such as provenance, annotations, authorisations, legal status, security, associated with data exchanged between Processes after trust has been established. Data Exchange Metadata does not participate in trust establishment itself. Instead, it governs what happens after trust exists.

Virtual Economy

MMM-TEC provides a framework supporting economic interactions among Processes operating in an M-Instance and, where permitted, across federated M-Instances. Economic interactions are expressed using standard Data Types enabling the representation of value, assets, rights, contracts, licensing, transactions, pricing models, provenance, and market policies.

The MMM-TEC virtual economy is based on the principle that economic activities are performed by Processes using Process Actions governed by Rights, Rules, Contracts, and other applicable marketplace policies.

Economic interactions may include:

  • Acquisition and transfer of Assets.
  • Licensing of rights on Items and Processes.
  • Provision of Services by Processes.
  • Transfer of Value between Wallets.
  • Execution of Transactions.
  • Conclusion and execution of Contracts.
  • Participation in Markets defined by Market Classes.

An Asset is an Item intended for economic use and exchange. In addition to the standard Item elements, an Asset may include Provenance information, Economic Metadata, Market Classes, Service Pricing Models, Marketplace Policy Identifiers, and Value Metadata Identifiers describing how the Asset may be exchanged, valued, licensed, or otherwise exploited.

A Value represents an economic quantity expressed in one or more Currency Objects. Values may be transferred between Processes by means of Transactions and may represent payments, fees, royalties, deposits, rewards, penalties, or other forms of economic consideration.

A Wallet represents the means by which a Process manages economic resources. Wallets may hold Values and participate in Transactions according to applicable Rights, Contracts, and Rules.

A Transaction records the transfer, exchange, reservation, or settlement of Value, Rights, Assets, or other economic entities. Transactions may be proposed, negotiated, executed, recorded, audited, and referenced by other economic Data Types.

A Licence represents permissions, obligations, prohibitions, and other conditions governing the use of Assets, Items, Processes, or Services. Licences may be granted, acquired, transferred, exercised, or revoked according to applicable Rules and Contracts.

A Contract Object and a Simple Contract provide representations of economic agreements among participating entities. Contracts may define commitments, obligations, entitlements, service conditions, payment conditions, dispute procedures, and other terms governing interactions among Processes.

A Service Pricing Model specifies the economic conditions under which a Process offers a Service. Pricing information may be used by requesting Processes when deciding whether to engage another Process to perform a requested Action.

A Market Class identifies categories of economic activity. Market Classes may be used to organise Assets, Services, Transactions, pricing policies, and discovery mechanisms within an M-Instance.

Marketplace Policy IDs identify marketplace-specific rules governing participation in economic activities. Such policies may define admissible economic behaviours, fee structures, settlement conditions, disclosure requirements, and dispute procedures.

Value Metadata IDs provide references to information used to characterise or evaluate economic value and may support valuation, pricing, accounting, auditing, regulatory compliance, or market analysis functions.

MMM-TEC supports accountability and auditability of economic activities through the use of Provenance, which records the economic history of Assets and related entities. Provenance ensures traceability of ownership, licensing, valuation, and Transaction history.

MMM-TEC also supports the reporting of abnormal economic or operational conditions through Financial Error Reports, Fault Behaviour Reports, and Fault Detection Reports. These Data Types enable Processes and M-Instances to detect, communicate, investigate, and resolve economic and operational anomalies.

The virtual economy defined by MMM-TEC is independent of any specific financial technology, payment platform, accounting model, currency implementation, or contractual enforcement mechanism. MMM-TEC specifies interoperable representations and semantics enabling economic interactions among conforming Processes while leaving implementation choices to individual M-Instances and service providers.

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 conditions.
  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 under which conditions an Action can be recalled.
  11. The Penalties for violation of Rules.
  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, the 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 outset, 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 for identified Processes. 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. Penalties for infringing Processes.
  7. Resolution of conflicts between Processes.
  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 ->