Architecture knowledge from BPMN Core Execution to TI-Flow and FHIR®.
The Knowledge hub presents the platform as one connected architecture: BPMN execution, logical placement and ownership boundaries, distributed views, controlled recovery and the versioned TI-Flow/FHIR® integration boundary—alongside Headless, identity/policy, security and operations.
From BPMN process to versioned TI-Flow delivery.
The key separation: workflow execution stays inside a stable internal domain. External profiles and service versions cross a controlled adapter boundary.
Public architecture overview. Implementation details and internal operating parameters remain outside the website scope.
BPMN Core Execution as distributed—but explicitly bounded—runtime.
Five public briefs explain the completed BPMN/VBucket foundation at product and architecture level.
BPMN Core Execution
Public architecture overview of the fully implemented BPMN engineering foundation at product and technical-effect level.
Architecture brief →BPMN RoutingVirtual-bucket sharding
Why a virtual placement layer decouples workflow identity from the current physical distribution.
Architecture brief →Execution IsolationShard-local execution
Why executable work and state changes remain inside a clear local ownership and consistency boundary.
Architecture brief →Distributed ReadsDistributed reads & routing
Why cluster-wide views and state-changing commands receive different distributed semantics.
Architecture brief →Migration SafetyWorkflow migration & recovery
Why ownership changes are treated as recoverable operating actions with explicit responsibility and recovery semantics.
Architecture brief →External profiles change. The workflow core should remain stable.
TI-Flow is explained as its own integration domain: canonical process/task semantics, Flowtype/profile generations, deterministic FHIR® mapping and durable delivery after workflow commit.
TI-Flow architecture
Architecture model for a canonical TI-Flow process and task context kept separate from concrete FHIR® profile generations and external service boundaries.
Versioned architecture brief →Versioned ProfilesTI-Flow/FHIR versioning
How explicit Flowtype/profile generations, deterministic mapping and durable delivery can decouple external change from running workflow semantics.
Versioned architecture brief →Every previous knowledge area remains available.
Headless, TI 2.0, API contracts, identity/policy, security, FHIR®, evidence and operations remain independent entry points, now complemented by the workflow tracks.
TI 2.0 architecture
How software-based TI access, digital identities and Zero Trust relate to the MEMM product boundary without implying TI-Gateway, ZETA or general TI 2.0 conformance.
Read technical brief →Headless ClientTI-Messenger Headless Client
Architecture 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.
Read technical brief →Security BoundaryCryptographic isolation
How host data, product state, E2EE state, diagnostics and external transport can be treated as separate boundaries in an embedded component.
Read technical brief →13 established technical briefs remain unchanged and reachable.
The new structure expands the knowledge base without removing prior URLs or topics.
TI 2.0 architecture
How software-based TI access, digital identities and Zero Trust relate to the MEMM product boundary without implying TI-Gateway, ZETA or general TI 2.0 conformance.
TI-Messenger Headless Client
Architecture 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.
Local Headless architecture
Why a local SDK/FFI boundary creates different responsibilities from a separate REST, TCP or WebSocket control service.
Rust & native integration
How a Rust core, Flat C ABI and narrow language bindings form a host integration boundary without implying universal platform or performance claims.
Versioned API contracts
Making API version, capabilities, data contracts, lifecycle and error semantics explicit so integrations do not depend on silent fallbacks.
Specification Change Control
Using versioned adapters and anti-corruption boundaries so changes in external drafts and profiles do not silently become changes in stable domain logic.
FHIR® & structured data
How FHIR®-related structured data, profile versions and validation boundaries are classified without making a general FHIR®, ePA or TI conformance statement.
Identity, attributes & policy
A control model that keeps identity evidence, attributes, authorization policy and the final execution decision distinct.
Cryptographic isolation
How host data, product state, E2EE state, diagnostics and external transport can be treated as separate boundaries in an embedded component.
Release Evidence
A release-oriented evidence model that keeps source state, artifact identity, configuration, test context and review reference connected without publishing private evidence.
Health & readiness
Separating liveness, critical dependency readiness and degraded service states instead of reducing operational health to one green indicator.
Fail-closed integration
Why unknown versions, missing configuration, unsupported capabilities and unsafe states should produce explicit outcomes instead of hidden compatibility assumptions.
PVS/KIS responsibility
A practical boundary model for primary systems, the agreed MEMM scope and external operators before evaluation or pilot work begins.
Public product architecture with a precise statement boundary.
- product and integration boundaries
- architecture principles and technical effects
- version and error semantics
- responsibility and recovery effects
Implemented BPMN foundation does not automatically mean complete TI-Flow conformance.
The website keeps those states separate: the BPMN engineering foundation is owner-confirmed as implemented, while TI-Flow/FHIR® articles remain version- and profile-bound until a narrower release claim is separately supported.