A group of tasks must execute exactly once each, in any order, but never concurrently within a process instance. No predetermined sequence and no parallelism — truly flexible serial execution driven by runtime availability and priority.
An AI-assisted onboarding system must complete four verification tasks for each customer: KYC Check, AML Screen, Credit Score, and Document Verification. Each task calls a different external service with distinct rate limits and SLAs. The services do not have equal response times — whichever responds fastest should be processed next. All four must complete exactly once before onboarding is approved. No task may run simultaneously with another because they share a single write connection to the customer credential store.
The key insight: the ordering is not fixed by business logic — it is determined at runtime by service availability. But parallelism is prohibited by the shared write resource. Interleaved Routing is the correct primitive: execute each task exactly once, one at a time, in an order determined dynamically by which is ready first. This is distinct from a Pipeline (fixed order) and from Parallel Split (concurrent execution).
| Metric | Signal |
|---|---|
| Task execution order distribution | Frequency histogram of which task runs first, second, third, fourth. Uniform distribution indicates healthy runtime-determined ordering. Skewed distribution indicates a service is consistently fastest or slowest. |
| Total group completion time | End-to-end time for all four tasks to complete. Compare against sum of individual task times — the difference is sequencing overhead and idle wait time. |
| Idle time between tasks | Time between one task completing and the next dispatching. Should be near-zero if the sequencer is event-driven. Non-zero idle time indicates polling-based sequencing overhead. |
| Exactly-once violation rate | Any non-zero value is a critical correctness failure. Monitor via audit log cross-reference: each task ID must appear exactly once per instance. |
| Node | What it does | What it receives | What it produces |
|---|---|---|---|
| KYC Check | Verifies customer identity against government databases and sanctions lists | Customer identity documents, name, DOB, nationality | Identity verification result, sanctions flag, PEP status |
| AML Screen | Screens customer transaction patterns and counterparty relationships against money laundering typologies | Transaction history, customer profile, AML rules engine | AML risk score, suspicious activity flags, required documentation |
| Credit Score | Retrieves and assesses creditworthiness from credit bureaus | Customer SSN or fiscal ID, bureau access credentials | Credit score, credit history summary, debt-to-income estimate |
| Document Verification | Authenticates submitted identity and financial documents using computer vision and fraud detection models | Uploaded documents (passport, bank statements, utility bills) | Document authenticity verdict, extracted structured data, tamper flags |
| Onboarding Complete | AND-join: waits for all four verification tasks to complete exactly once before proceeding to approval decision | Verification results from all four tasks | Consolidated verification package ready for approval agent |
| Origin of Value | Where it appears | How it is captured |
|---|---|---|
| Future Cashflow | Onboarding Complete join | All four checks complete before the approval decision — no check is skipped. The approval decision is based on complete verification data, reducing false approvals and downstream fraud exposure. Completeness guarantee is the value; flexibility in ordering is the mechanism. |
| Governance | Each verification task | Regulatory requirements mandate each check be performed. The exactly-once guarantee is the compliance primitive — the audit log must show KYC, AML, Credit, and Document checks all completed before onboarding. Interleaved Routing structures this requirement into the process definition. |
| Conditional Action | Shared credential store connection | The shared write connection is the constraint that forces serialization. The compute cost is the same as a fixed-order pipeline; the benefit is that the fastest-responding external service is always processed next, minimizing idle wait time across the task group. |
| Risk Exposure | Task sequencer | The mechanism that determines which task runs next (priority queue, availability polling, or event-driven) is the reliability risk. If the sequencer fails mid-execution with 2 of 4 tasks complete, the instance state must be recoverable — which tasks ran, which remain. |
Contrast with Pipeline (11) and Parallel Split. Pipeline fixes execution order at design time — KYC always before AML. Parallel Split runs all tasks concurrently. Interleaved Routing occupies the design space between: all tasks run, but one at a time, in an order not fixed until runtime. The constraint is mutual exclusion of execution within the group; the freedom is ordering flexibility.
The task sequencer selects KYC Check twice — once at the start and again after a timeout recovery. Both executions complete and both results arrive at the Onboarding Complete join. The join sees 5 completions for 4 tasks — one task ran twice. If the join is a simple counter, it may fire early (after 4 arrivals) leaving a duplicate result unconsumed. If it is task-typed, the duplicate KYC result triggers a conflict. Fix: the task pool must track which tasks have been dispatched, not just which have completed. Once dispatched, a task cannot be re-dispatched. Idempotency keys at the external service level provide an additional guard.
The Credit Score service is down. The sequencer cannot dispatch the Credit Score task. It dispatches KYC, AML, and Document Verification — all complete. Now the only remaining task is Credit Score, which the service cannot fulfill. The instance is stuck: 3 of 4 tasks done, 1 task perpetually blocked. Fix: each task must have a timeout and a fallback path (retry with exponential backoff, manual review queue, or conditional skip with documented justification). The sequencer must handle "task unexecutable" states explicitly.
The instance executes: KYC (completes), AML (dispatched), Credit Score (dispatched — but AML is still running, violating interleaving). This happens when the sequencer fails to properly gate the next dispatch on the previous task's completion signal. Fix: the sequencer must use an explicit "previous task complete" gate before dispatching the next task. Event-driven architectures must ensure the completion event is processed before the next dispatch is triggered, using a durable message queue with acknowledgment-before-next semantics.
| Variant | Modification | When to use |
|---|---|---|
| Priority Interleaved Routing | Tasks are assigned priority weights; highest-priority available task always executes next | Some checks are more time-sensitive (e.g., AML must complete before others can use its result for risk scoring) |
| Interleaved Routing with Skip | A task can be conditionally skipped (marked as N/A) if runtime conditions make it inapplicable; skipped tasks count as "done" for the join | Some verifications only apply to specific customer types — a business customer may skip the individual credit score check |
| Phased Interleaved Routing | Tasks are grouped into phases; within each phase, interleaved routing applies; next phase starts only when current phase completes | Some tasks must logically precede others (KYC must complete before AML in some jurisdictions), but within each phase the ordering is flexible |
| Pattern | Relationship |
|---|---|
| 10.11 Pipeline | Fixed-order alternative — use when task ordering is determined by data dependencies or business rules at design time, not runtime availability. |
| 70.76 Critical Section | Related serialization mechanism — Critical Section serializes access to a shared resource across concurrent threads. Interleaved Routing serializes task execution within a single thread across a task group. |
| 90.91 Thread Merge | When concurrent threads must be collapsed after an earlier Parallel Split — the convergence pattern that follows concurrent execution, contrasted with Interleaved Routing's serial execution. |
| 20.23 Orchestrator-Workers | An orchestrator that dispatches workers one at a time from a task queue implements Interleaved Routing at the architectural level — the orchestrator is the sequencer, the workers are the tasks. |
Interleaved Routing appears in regulated industries where compliance requires complete verification but resource constraints or shared state prohibit parallelism. Financial services onboarding, healthcare prior authorizations, and legal due diligence workflows all exhibit this pattern: a fixed set of checks, each mandatory, each independent, but run serially due to shared credential stores, API rate limits, or regulatory sequencing requirements.
AI-native implementations of this pattern replace the human-in-the-loop scheduler ("the analyst picks whichever service is available") with an event-driven task sequencer. The value is not in the pattern's novelty — it is in the reliability of the exactly-once guarantee and the minimization of idle time between tasks.
Red flag: a system described as "running verifications in parallel" that is actually running them via a shared queue with a concurrency limit of 1. This is interleaved routing implemented implicitly, without the exactly-once tracking. Duplicate dispatches under failure recovery are invisible until an audit reveals them.