Stable VBucket placement
A bounded virtual bucket space maps workflow_id → bucket_id → shard_id to a named execution boundary. Exact bucket counts and physical topology remain deployment- and version-bound implementation details.
TI-Flow Engineering Foundation
BPMN workflow runtime for TI-Flow-oriented services.
MEMM exposes an implemented workflow/sharding foundation with stable VBucket placement, shard-local execution, explicit ownership and recoverable migration. The claim is deliberately limited to this engineering layer; it does not turn the runtime into a complete TI-Flow, HCC, ZETA or FHIR implementation.
External development reference:
Draft_TI-Flow_26_2 is used to classify surrounding service, HCC, ZETA and FHIR contexts. It is not treated as an approval or conformance statement.Runtime Foundation
Five implemented properties below the service layer.
These statements apply to the workflow/sharding foundation itself and remain separate from higher-level TI-Flow product and provider responsibilities.
Shard-local write path
Workflow state, jobs, timers, subscriptions, journal and effect/outbox records stay on the responsible shard in the execution path; distributed JOINs and writes do not belong in the hot path.
Per-shard queues & workers
Workers operate only inside their assigned shard-local execution boundary, where work is claimed and executed under explicit ownership. Wakeup, recovery and scheduling mechanisms remain internal runtime details.
Failure containment
Ownership, leases and fencing keep execution on the named shard and expose shard/worker failure as an explicit operating state.
Recoverable migration
Bucket migration follows an explicit recoverable sequence of draining, copy, verification and locked cutover with restart/recovery semantics.
Not a semantic data bucket
VBuckets are routing and placement primitives. Bucket ranges do not automatically become medical, accounting, privacy or tenant boundaries.
Execution model
Local transactions in the hot path. Distributed reads only with explicit semantics.
Write / Execution
- no distributed JOIN/write in the execution hot path
- state + job inside the responsible local transaction boundary
- wrong-shard / unknown-owner is rejected explicitly
- auth, tenant/project and request context stay part of routing
Read / Operate
- cross-shard reads as bounded scatter-gather
- deterministic merge with pagination-aware result contract
- partial failure stays visible
- topology version remains part of the result context
Migration safety
Recoverable cutover instead of a blanket uninterrupted-operation claim.
Migration is a controlled protocol. Sensitive phases may deliberately fail fast or return retryable outcomes to avoid split-brain or ambiguous ownership.
Crash / Restart
Checkpointed phases allow a coordinator to determine a clear continuation or error state after restart.
Source / Target failure
Before verified cutover, source ownership remains authoritative; network or database failure cannot be interpreted as successful migration.
Split-brain guard
Versioned topology, locked cutover and fencing are used to prevent simultaneous active owners for one bucket domain.
Draft_TI-Flow_26_2
The runtime is a foundation. The external TI-Flow scope is broader.
The 30 June 2026 gematik pre-release covers service concepts, HCC clusters, onboarding, product/provider profiles and multiple FHIR Implementation Guides. Those layers are not automatically derived from a BPMN/VBucket runtime.
What this page does claim
- implemented VBucket/sharding workflow foundation
- bounded VBucket space and stable workflow placement
- shard-local execution and queue boundaries
- explicit failure, ownership and migration semantics
What does not automatically follow
- complete TI-Flow service implementation
- HCC or ZETA conformance
- complete FHIR IG, QES or domain-profile coverage
- approval, provider release, uninterrupted operation or GDPR guarantee
Fail-closed runtime
Unknown topology is an error state, not a reason for silent fallback.
Unknown shards, missing owners, stale ownership and unresolved migration remain explicit states. ZETA-specific validation is not inferred from this runtime behavior.
Topology
Incomplete or contradictory active topology is not treated as normal routing.
Ownership
Local/remote ownership and fencing restrict execution to the named owner.
Tenant context
Auth, tenant/project and request metadata stay inside the routing boundary.
ZETA boundary
ZETA remains external TI 2.0/TI-Flow context; complete ZETA validation or conformance is not claimed.
Synthetic design study
Workflow and TI-Flow operations in one technical view.
The view is synthetic. It does not show a real TI-Flow instance, gematik review or measured operating data.
Concept UI · synthetic data
Workflow / Runtime View
Illustrative perspective on process state, technical execution and operating boundaries.
Do not start TI-Flow with a marketing claim. Start with the technical scope.
Separate FHIR/service contract, security/HCC context, workflow translation and the implemented runtime foundation against your target environment.
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.