Product & Session
Product information, service-account context, login/logout and a clearly non-production cleanup path.
TI-Messenger Headless Client
Embeddable Matrix communication runtime for PVS, KIS and OEM products.
Communication as a product component—not as a second product.
MEMM places communication capabilities inside healthcare and OEM products through explicit host, API and native contracts. The bound R1001 evidence stays separate from the commercial integration narrative so scope, implementation state and external responsibilities remain reviewable.
Development reference: selected requirements from gematik pre-release
Draft_TI-Messenger_26_2 and its Headless Client product type are considered as external engineering context. No general availability, approval or conformance is inferred from that reference.Integration value
Keep infrastructure complexity behind a product boundary.
The value is a versionable contract that lets the host keep its own UX and business process while communication lifecycle, state and integration responsibilities remain bounded.
01Decouple host logic
Selected protocol, E2EE and integration responsibilities stay behind a named Headless boundary rather than being rebuilt in every host.
02Make integration planable
Lifecycle, errors, ownership and release change are treated as explicit contracts.
03Reduce duplicate runtime work
The Rust-based core groups technical responsibilities that the host does not need to recreate inside the agreed scope.
Target: a shorter path from architecture scope to a verifiable integration—without promising a specific delivery time.
Product operation catalogue
37 product operations across six host/native clusters—plus a separate call surface.
The source-local host/native catalogue remains 37 operations. Calling is represented through the existing Messenger-operation boundary and is therefore reported separately instead of inflating the 37/37 counter.
Directory & Discovery
FHIR-VZD-related visibility, authentication and MXID mapping plus practitioner and homeserver discovery inside the bound Headless scope.
Messaging
Direct and room messaging, history, edits and controlled redaction/replacement variants.
Rooms
Room lists, creation, settings, membership transitions, forget and state-event queries.
Media
Upload and authenticated retrieval as named product operations inside the same host ownership boundary.
Authorization
Explicit authorization mode and allow/block lists as typed Headless product boundaries.
Calls9 / 9 domains16 bounded Messenger operations
Matrix VoIP signalling with a host-owned WebRTC media/session boundary.
R1001 covers call availability, invite, ringing, session, participants, media state, permissions, transport and encryption as 9/9 evidenced Messenger domains. Five signalling operations cover availability, invite, answer, reject and hangup; eleven bounded media/session operations cover session open/close, transport/ICE, permissions, encryption facts, media state, session phases, participants, renegotiation and finality.
MEMM / Matrix signalling→bounded Call contracts→Host-owned WebRTC media runtime
The media runtime remains the integrating host's responsibility. MEMM carries signalling and versioned media/session/security facts across the Java 21 Panama, Kotlin and Swift boundary.
Boundary 37/37 is the defined Headless product-operation catalogue. The call surface is separate. Neither number claims complete TI-M specification coverage, gematik approval, production release or external-provider interoperability.
Messenger functional breadth
63/63 domains in the fixed Messenger denominator.
R1001 keeps the denominator fixed and binds every domain to executable source/test evidence inside its declared responsibility boundary.
All 63 domains are carried as executable_source at maturity 100 in the bound R1001 state.
Arithmetic breadth over the fixed 63-domain denominator: 100.00%.
The 26 Core Foundation domains are at 100.00% inside their declared scope.
Marker entries alone are not sufficient for the 100% state.
Core Foundation
Lifecycle, update stream, projections, conversation/timeline, delivery, security, rooms, realtime, media, search and E2EE/cache foundations.
Account & Room Safety
Account, device and room safety domains inside the fixed Messenger denominator.
Rich & Presentation
Presentation, rich-event and related messaging domains with bounded evidence identity.
Calls & Integrations
Call domains plus integration-oriented domains represented without changing the fixed denominator.
Evidence reading “100% Breadth” is arithmetic coverage of this fixed source-local denominator. It is not a percentage of the entire TI-M specification and does not establish certification or provider interoperability.
Native integration chain
One bounded product contract across Rust and host languages.
The public integration model separates the Rust implementation core from the host-facing ABI and language bindings.
HostJava 21 / Kotlin / Swiftapplication-owned UX and process
BoundaryFlat C ABI / FFIbounded types, lifecycle and errors
CoreRust runtimeinternal implementation boundary
Subscription-first
Runtime updates are exposed through bounded subscription/update paths rather than creating an independent host-facing polling owner.
No pooling island
The embedded boundary does not introduce a second independent connection-pool owner for the host integration path.
Bounded facades
Host bindings stay narrow and versioned instead of leaking internal runtime classes and state machines.
Security & host boundary
E2EE state, host data and external transport remain distinct responsibilities.
The product boundary aims to keep secret-bearing state out of public diagnostics and to make host/runtime ownership explicit. External transport and deployment controls remain separately operated.
Cryptographic state
E2EE state remains inside the bounded runtime responsibility instead of becoming a general host data model.
Secret-safe diagnostics
Diagnostics are limited to typed or redacted information rather than raw dependency text or secret material.
Lifecycle & zeroisation
Shutdown and sensitive-state handling are part of the integration contract, while OS dump and raw-memory controls remain a deployment responsibility.
External transport
Network transport requires its own TLS, provider and operating boundary; it is not collapsed into the local FFI claim.
Verification boundary Source/static review and locally executable checks are not the same as external production validation. Live-provider interoperability, controlled memory exercises and release authorization remain separate evidence.
Technical depth
Headless architecture, native contracts and cryptographic boundary.
Public knowledge briefs explain the integration model without exposing private source paths, raw evidence or secret-bearing implementation detail.
Headless ClientTI-Messenger Headless ClientArchitecture view of a local Headless Client integration: product boundary, the fixed 63-domain Messenger denominator, the separate 37-operation host/native catalogue, native bindings, calls and ownership.Open knowledge brief →Technology BoundaryRust & native integrationHow a Rust core, Flat C ABI and narrow language bindings form a host integration boundary without implying universal platform or performance claims.Open knowledge brief →Security BoundaryCryptographic isolationHow host data, product state, E2EE state, diagnostics and external transport can be treated as separate boundaries in an embedded component.Open knowledge brief →
Evaluating a concrete Headless scope?Map the target system, bindings and required product operations before a generic demo process.
Concept UI · synthetic data
Headless Client operations concept
Illustrative view of instances, state changes, open notices and integration status. All content is synthetic.
Classification: Matrix, FHIR®, TI, TI-M, TI-Flow, ZETA, ePA and gematik refer to external standards, infrastructures or integration contexts. This site does not claim certification, approval or commissioning by gematik or another authority. Supported profiles, versions and operational boundaries are confirmed in writing before use.
Next technical step
Do not start with a demo. Start with the integration scope.
A first technical discussion compares your target architecture with the current MEMM product and integration boundaries without turning that discussion into a promise of availability, conformance or delivery date.
Architecture check
Map PVS, KIS, AVS, OEM or contact-center host boundaries, native integration and required Headless operations.
Specification & architecture mapping
Review relevant external profiles and versions in the context of your target system while naming open or external prerequisites explicitly.
Scope before pilot
Separate host, MEMM and external TI/provider responsibilities before pilot assumptions become project risk.
Technical scope composer
Prepare the conversation locally.
The entries are not transmitted to this website. Submitting opens your local email client with a pre-filled scope. Do not send health, patient, key or access data.
Boundary Architecture and specification mapping are technical classification—not legal advice, certification, approval, an availability commitment or a binding effort estimate.