Architecture
AuraScore 79/100

Warehouse Execution Integration Architecture Blueprint

Design high-availability event integration between legacy WMS platforms, automated material handling hardware, and enterprise backends.

Deploy this template when designing integration layers between high-speed automated distribution centers, sorting robotics, and legacy enterprise software. It delivers a comprehensive architecture report establishing deterministic message flows and fault containment.

Template

Role: Lead Supply Chain Integration Architect specializing in high-throughput warehouse execution systems (WES) and industrial automation.

Context

  • Physical warehouse landscape: {{warehouse_footprint}}
  • Core legacy warehouse software: {{legacy_wms_system}}
  • Automation hardware interfaces: {{automation_hardware_protocols}}
  • Peak order throughput: {{peak_order_volume}}
  • Upstream enterprise ERP: {{erp_vendor}}
  • Target availability and disaster recovery: {{failover_rto_rpo}}

Task

Author a comprehensive system integration architecture report detailing the asynchronous middleware, message brokering, and edge-orchestration layers required to connect {{legacy_wms_system}} with automated material handling systems across {{warehouse_footprint}} under {{peak_order_volume}}.

Method

  1. Map data exchange boundaries between {{erp_vendor}}, {{legacy_wms_system}}, and PLC/SCADA industrial hardware.
  2. Formulate integration patterns resolving protocol impedance mismatches caused by {{automation_hardware_protocols}}.
  3. Design a local edge brokering layer within {{warehouse_footprint}} to maintain physical sorting during WAN outages.
  4. Specify deterministic order allocation and wave-release event workflows capable of sustaining {{peak_order_volume}}.
  5. Establish state synchronization mechanisms handling partial pick confirmations, item exceptions, and inventory reconciliations.
  6. Define concurrency control and idempotency keys to eliminate duplicate pick commands across autonomous robotics.
  7. Architect end-to-end telemetry observability across network switches, message queues, and automation controllers.
  8. Formulate failover, disaster recovery, and data replay procedures strictly satisfying {{failover_rto_rpo}}.

Constraints

  • MUST maintain autonomous offline operation at each physical facility during extended cloud disconnections.
  • MUST NOT rely on synchronous blocking REST calls for physical conveyor or robotics routing decisions.
  • Sub-second edge sorting loop latencies must be guaranteed regardless of upstream {{erp_vendor}} load.
  • Must explicitly document deadlock prevention strategies for automated multi-shuttle storage systems.

Output format

Provide an architectural evaluation report containing:

  1. Integration Topology & Protocol Matrix (system map and protocol translation layer)
  2. Edge-Resilient Messaging Architecture (broker topology, offline buffer design, and sync protocols)
  3. Concurrency, Idempotency & Exception Handling Model (state transition diagrams and recovery logic)
  4. High Availability, Sizing & Operational SLA Plan (failover runbook adhering to {{failover_rto_rpo}})

Self-review

  • Does the edge topology guarantee zero loss of pick-and-sort operations during a complete WAN severed-link scenario?
  • Is the message processing model fully idempotent across all hardware integration endpoints?
  • Does the failover strategy directly validate the constraints set in {{failover_rto_rpo}}?
AuraScore breakdown
79/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-architecture
transport-logistics
warehouse-automation
systems-integration
wes