WES — Application Validation

Warehouse Execution Management System

Overview

WES is an order-driven, high-complexity application that exercises the widest range of platform capabilities. It manages AMR fleets, MHE (material handling equipment), and PDAs in warehouse environments — decomposing incoming orders into pick/move/place task sequences, assigning them to devices, and orchestrating execution across a dynamic warehouse floor.

WES is the platform’s primary stress test: complex multi-step execution contracts, high-frequency replanning, multi-device coordination, and policy-driven failure recovery. As a first-party application built by Syrius Robotics, WES uses the same APIs available to third-party developers — no privileged access.

Platform Services Consumed

Service

Plane

Usage

DeviceAdmin

Data

Enroll AMRs, MHEs, PDAs; monitor alerts and OTA status

ThingIO

Data

Fleet dashboards, order throughput analytics, zone utilization widgets

OTAForge

Data

Policy-driven firmware and map distribution to warehouse robots

DotID / StarGate

Identity

Authenticate robots, operators, and upstream systems (OMS/WMS)

Equator

Spatial

Warehouse maps, zones, rack locations, charging stations, landmarks

Marie

Spatial

Proximity queries, path clearance checks, zone-based resource lookup

Planner

Intelligence

Decompose orders into pick/move/place task sequences across the fleet

Scheduler

Intelligence

One-time task assignment based on resource availability and proximity

Execution Manager

Intelligence

Orchestrate and monitor multi-step task execution via contracts

Policy Service

Governance

Failure recovery strategies, planning preferences, scheduling priorities

AI Policy Agent

Governance

Operators define warehouse rules conversationally using the WES domain schema

Planes Exercised

Plane

How WES Uses It

Data Plane

Device enrollment (DeviceAdmin), fleet dashboards (ThingIO), firmware updates (OTAForge)

Identity Plane

Authentication for robots, operators, and upstream WMS/OMS integrations

Spatial Plane

Warehouse floor maps, rack positions, zone-based queries, path clearance

Intelligence Plane

Full planning → scheduling → execution pipeline for order fulfillment

Governance Plane

Policy-driven planning, failure recovery, and operator-defined rules

Ecosystem Plane

Published to Marketplace, registers Domain Policy Schema on install

Validation Scenarios

1. Complex Execution Contracts

WES produces multi-step contracts with decision points:

Contract: Pick Order #4521
├── Step 1: Navigate to Rack B-12 (map excerpt included)
├── Step 2: Pick item SKU-7890 from shelf 3
├── Step 3: Navigate to Packing Station 2
├── Step 4: Place item on conveyor
├── Failure policy: Retry once, then reassign to nearest AMR
└── Constraints: Battery > 20%, complete within 15 min

What this validates:

  • The Execution Contract model handles multi-step, multi-decision-point payloads

  • Contracts are self-contained enough for offline execution (spatial data, constraints, and failure policies included at push time)

2. Edge-Cloud Reconciliation Under Load

A busy warehouse has 50+ AMRs, some losing connectivity in RF-dead zones:

  • Connected AMRs are replanned as orders change

  • Offline AMRs hold their contracted tasks as projected state

  • On reconnection, actual state (position, task progress) is reconciled

What this validates:

  • The Edge-Cloud Reconciliation pattern works under high device density and frequent connectivity changes

  • Partial-fleet replanning correctly locks projected tasks and avoids double-assignment

3. Policy-Driven Failure Recovery

An AMR encounters a blocked aisle during a pick sequence:

  1. Execution Manager detects the contract failure

  2. Consults Policy Service — WES’s app-defined policy says “retry once, then reassign”

  3. Retry fails (aisle still blocked)

  4. Task reassigned to the nearest available AMR

  5. Planner replans the remaining sequence

What this validates:

  • The Policy Architecture pattern supports application-defined failure recovery

  • Recovery strategies are composable (retry → reassign → escalate) and configurable per application

4. Domain Policy Schema and AI Policy Agent

A warehouse operator tells the AI Policy Agent:

“Prioritize urgent orders over standard orders, and never assign more than 3 tasks to a single AMR”

The Agent uses the WES Domain Policy Schema to understand order.priority, AMR, and task-count constraints, creating formal policies that the Planner and Scheduler respect.

What this validates:

  • Domain Policy Schemas make the AI Policy Agent reusable across applications

  • Operators can customize application behavior without writing code

  • Conversationally-created policies are validated before activation

5. One-Time Scheduling

WES uses one-time, order-driven scheduling:

  • An order arrives → Planner decomposes it → Scheduler assigns tasks to available AMRs

  • No recurring schedules — each order is a discrete scheduling event

What this validates:

  • The Scheduler’s one-time scheduling mode handles dynamic, unpredictable workloads

  • Scheduling decisions respect policy constraints (device availability, battery thresholds, zone restrictions)

Architecture Insights Surfaced

Insight

Impact on Platform Design

Execution contract model needed

Multi-step tasks require self-contained contracts for offline execution

Edge/cloud reconciliation needed

High device density + intermittent connectivity demand formal state reconciliation

Policy-driven recovery, not hardcoded

Different failure types need different strategies, customizable per deployment

Application-defined policy with platform execution

Developers define domain-specific policies; the platform enforces them uniformly

Two-tier planning justified

Strategic (cloud) and tactical (edge) planning solve fundamentally different problems