↻
The second turn of the wheel. Cortex built Om WMS as a product; packaged here as a vertical configuration, it installs at a warehouse customer through the very same install flow — and builds their warehouse.
What's in the configuration
the complete default configurationA vertical configuration is a complete, ready-to-run default configuration — not just code. When Om WMS installs at a warehouse customer, this is what they get on day one, already wired to run their warehouse.
6
Departments
Receiving · Putaway · Picking · Packing · Shipping · Inventory
14
Playbooks
Cycle-count, replenishment, slotting, exception handling…
5
AI Employees
Floor Assistant · Gate Keeper · Slotting Optimizer · Vision Picker · Supervisor
28
Skills
Scan-to-locate, layout-learn, put-wall logic, discrepancy triage…
9
Outcomes
Order accuracy, dock-to-stock time, pick rate, shrinkage…
Ready to run on day one — install and the warehouse starts operating
Two layers — base & overlay
Base-default layer
we own · OTA-updated
Everything above ships as the base — the default departments, playbooks, AI employees, skills, and outcomes. We maintain it and push improvements over the air. This is the configuration's authored starting point.
Customer-override overlay
they own
Every change the customer makes — a renamed department, a tweaked playbook, an added skill — lands in their overlay, sitting on top of the base. Their configuration, their edits.
🛡️
Customer edits win. Every OTA update merges into the base and then re-applies the customer's overlay on top — so their renames and tweaks survive the update. They get our improvements and keep their changes; an update never clobbers what they configured.
OTA delivery
edge-hardened, over the air
🔏
Signed update bundles
Every configuration update is a signed bundle — the customer's install verifies it before applying. No unsigned code runs.
🚦
Staged / canary rollout
Updates roll out gradually — a canary slice first, watched, then the rest — so a bad update is caught before it reaches everyone.
↩️
Rollback
Any update can be rolled back to the last known-good version — recovery is one step, not a rebuild.
⚙️
Per-customer update policy
Each customer picks how updates land:
auto
notify
approve
Behavior-changing playbooks require approve — an update that changes how the warehouse acts never applies silently.
↻ The same wheel, one turn further
This is the platform in one line. Cortex built Om WMS as a product; packaged, Om WMS installs at a warehouse customer through the very same install flow — and builds their warehouse. The machinery runs twice.
First turn
Om Cortex builds Om WMS
The platform defines the product, attaches the workflows, and runs the build — the screens in this journey.
→
Ships
Om WMS = a vertical configuration
Versioned, signed, installable — the configuration you're publishing here.
→
Second turn
Installs at a warehouse customer
The same install flow — and Om WMS builds their warehouse.
Cortex built Om WMS; Om WMS builds the customer's warehouse. The same wheel → one turn further. The engine is the product, and the product is an engine again.
Publishing signs the v1.0.0 bundle and makes the Om WMS vertical configuration installable — customers can license it, install it, and start running their warehouse on the base configuration.