The warehouse failure diagnostic.

What you send

An export of the event log one of your systems already writes — the WMS usually has it — covering a period long enough to contain a few bad days. Three or four of them is enough; the patterns are what we are looking for, not the incidents.

When

A timestamp. Local or UTC, as long as it is consistent.

What

The activity. Whatever your system already calls it — we do not need it renamed or mapped first.

To what

The ids of the things it happened to: the order, the item, the container, the location, the shift. As many as the row carries.

A file, not a connection. No integration, no live system access, no IT project — the export has to satisfy that constraint, which is why the ask is a period of history rather than a door into a running system. What happens to it once it reaches us is on the security page.

What comes back

Failure patterns

What repeatedly precedes disruption.

Not the incidents you already investigated — the shape they share. A pattern that has happened eight times in a year is a pattern you can be warned about the ninth time.

Warning time

How early the signal appears.

Measured from the moment the pattern is detectable to the moment the floor feels it. This is the number the whole product rests on, and it is different in every operation. Yours is whatever your data says it is.

Root cause

Where the failure begins.

Usually not where it is felt. The station that runs dry and the constraint that dried it are rarely in the same part of the building, or the same system.

Intervention

What could have been done.

Restricted to moves that were actually available on the day, inside the controls you already have. An intervention that needs a new process is not an intervention, it is a project.