Stride

A canning line planner that learns from real production history. Drag, replan, resequence and see the OEE impact before you commit.

Comment

Inspiration

Damm already runs Blue Yonder for planning. It sequences production using standard changeover times, but the shop floor does not behave like a spec sheet. Some changeovers are quick; others quietly burn OEE because of format changes, filler conditions, shift timing, or brand swaps.

Our core insight: all changeovers are not equal, and the difference is already visible in historical data.

From Damm’s 2025 history, transition types showed a clear spread:

  • same-SKU runs hold OEE around 0.54
  • cap-only changeovers reach around 0.62
  • volume changes drop to around 0.26

That 36-point OEE swing is invisible if every changeover is treated as an average. Stride enriches the existing plan with evidence instead of replacing the planner.

What it does

Stride is a planner copilot for canning lines L14, L17, and L19 at El Prat. It:

  1. Reconstructs 2025 execution history from Damm Excel workbooks into production blocks, cleaning events, maintenance windows, and typed transitions.
  2. Recommends a line and slot for urgent orders using historical analogues and predicted OEE impact.
  3. Supports drag-and-drop planning across compatible lines, with previews for ripple effects, format switches, and service-block collisions.
  4. Explains changeover pain through learned transition types such as brand, format, volume, pack, cap, and same-SKU changes.
  5. Surfaces external context through a Cala-shaped provenance modal for supplier, regulatory, and market signals.

The planner is not just placing one order — they are managing how that order changes the whole forward plan. The cost model compares each run against the one before it:

$$ \text{cost}(\text{plan}) = \sum_{i=1}^{n-1} \left(1 - \overline{OEE}{\,\text{type}(s_i, s{i+1})}\right) $$

where type(a, b) is the transition type from observable production attributes, and OEE_t is the mean OEE of the matching historical bucket.

How we built it

Backend. A FastAPI service exposes a versioned planning contract. A Python exporter parses the raw Excel files, reconstructs executed history, learns transition statistics, and emits a canonical data.json. The frontend consumes only that contract, not the raw workbooks.

The backend also supports operational actions such as issues, stoppages, stoppage replanning, manual move previews, and plan recomputation.

Frontend. React + Vite powers a three-lane Gantt-style board for L14, L17, and L19. The board supports week, month, and quarter zooms, with executed history before NOW and the forward plan after NOW.

Planners can drag runs to compatible lines, see incompatible windows marked clearly, and inspect recommendation cards with analogues, transition breakdowns, predicted OEE impact, and ripple warnings.

External enrichment. For demo stability, the frontend uses a curated Cala-shaped mock with provenance and citation behavior. The backend contract keeps the signals path ready for live Cala integration later.

Testing. We tested the data pipeline, planning contract, operational rules, recommendation logic, and UI-critical edge cases without relying on stale test-count claims.

Challenges we ran into

  • Timeline scaling. Durations were in hours, but the UI initially treated them like days, creating a 24x display bug. We fixed the timeline around pxPerHour = pxPerDay / 24.
  • NOW divider drift. Short cards had minimum pixel widths and overflowed past the divider. We rebuilt NOW as an inline layout element between executed and planned content.
  • Cleaning cadence projection. Cleaning rules had weekly, biweekly, and monthly variants. We projected each cadence across the horizon while deduping equivalent service blocks.
  • Cala integration stability. We separated external refreshes from normal planning requests and used cached/mock provenance so the demo survives API limits.

Accomplishments

  • Built an end-to-end planner grounded in Damm production data.
  • Made recommendations explainable with historical analogues, transition types, predicted OEE impact, and rule conflicts.
  • Created a board where planners can reason about urgent orders, line compatibility, cleaning, stoppages, and ripple effects in one place.
  • Kept the architecture merge-safe with a canonical export, versioned contract, deterministic fallback data, and tests around core planning rules.

What we learned

  • The best approach is not replacing planning tools, but layering evidence on top of them.
  • Historical execution data is more valuable than a model trained from scratch without operational context.
  • Explainability comes from carrying the right data shape: analogue, transition type, breakdown, prediction, and source.
  • External APIs should refresh explicitly and cache results, not run inside normal request handlers.

What's next

  • Restore and harden global resequencing on the merged branch, then report only reproducible numbers from main.
  • Cross-line optimisation so production orders can migrate automatically when global cost improves.
  • Due-date penalties once committed delivery bands are available.
  • Live Cala search drawer for planner questions like “Any new sanctions affecting PET suppliers?”
  • Server-backed move preview so all ripple calculations move from the client into /plan/move/preview.

Built With

Share this project:

Updates