MEMM is aimed at product and platform teams that need a concrete integration scope, explicit ownership and versioned interfaces. The areas below describe development scopes, not blanket availability.
For evaluating a Rust-based Headless core with bounded API, FFI and runtime contracts. The bound R1001 state reports 63/63 Messenger domains with 100% Breadth and 100% Core Foundation inside the fixed Messenger denominator; the separate 37-operation product catalogue remains bound to the native host surface.
For selected profile, validation and processing boundaries around structured content and FHIR®-related scenarios. Draft_TI-Messenger_26_2 is treated as an external development reference.
For explicitly defined identity, attribute, policy and execution boundaries with typed outcomes. The current development model includes a versioned identity-evidence boundary for EUDI Wallet, Health ID and eID-LE contexts; identity verification and application authorization remain separate.
For binding public statements and project-specific verification results to a named version, configuration and environment.
For teams that want higher-level FHIR and service contracts separated from the distributed workflow execution layer underneath.
Bounded VBucket space, stable workflow placement, shard-local queues and transactions, explicit scatter-gather reads, fail-closed ownership and recoverable migration. Draft_TI-Flow_26_2 is classified as an external reference; HCC, ZETA, FHIR profiles and approval are not inferred from the runtime.
Automation, technical identities, identity/attribute/room context and operating boundaries are treated as separate interface and responsibility questions rather than a blanket product promise.
A dedicated page groups automation, identity, attributes, room context, operating boundaries and a cautious classification of Draft_TI-Messenger_26_2.
Together we can bound the target system, current product state, required versions, operating boundary, verification need and responsibilities.