One workflow.
Many moving parts.
Connecting production, inspection, labels and traceability across the shop floor, the browser and the ERP.
Trace the journey.
Keep the context.
Finishing an action
isn’t the whole story.
Production software has to coordinate physical work with digital records. A component may be produced, inspected, released, packed and labelled — with different people and interfaces involved at each stage.
The design challenge is to make those transitions explicit. Saving a record, releasing quality and transmitting a label are different events. Treating them as one generic “success” can leave an operator unsure what actually happened.
Make the state of the work clear.
Make the next action safe.
Production workflows, inspections, packaging, labels, traceability, inventory and ABAS integration.
Organisation work at Rotoclear. This case study explains the system and its design choices; it does not imply sole authorship.
Different interfaces.
A shared source of truth.
The SvelteKit backend is authoritative for both the web interface and the native Android client. Select a layer to see its responsibility.
SvelteKit backend
Validates transitions and owns the workflow contract for both clients. Business rules stay on the server.
Simplified architecture based on repository documentation. Selectable layers show responsibilities, not the full deployment topology.
“Saved” and “printed”
are different promises.
A label request can outlive the connection that sent it. The application distinguishes a saved record from a confirmed transmission and handles failed or uncertain outcomes.
Two states. Both known.
The record is saved and the transmission is acknowledged. A transmission receipt is not proof that a physical label has been inspected.
Acknowledge what is known. Give uncertainty an explicit state and a safe path forward.
Reliability lives
in the details.
01 Keep rules on the server
Shared server validation prevents the web and Android clients from becoming competing authorities. The tradeoff is that both clients depend on the backend’s workflow contract.
02 Design for recovery
Operation journals, receipts and idempotent inventory withdrawals support reconciliation. This adds state to manage, but helps prevent retries from silently duplicating a business action.
03 Separate internal and customer views
Customer inspection reports exclude inspector names and diagnostic/network details. Internal audit context and external documents serve different purposes.
04 Preserve context in the interface
Saved views, URL filters, local drafts and persistent validation/results support work that gets interrupted. Operators need to understand where they are when they return.
A connected workflow.
A traceable record.
Follow the serial number.
A unified lookup connects stages, components, quality cases and cartons with permitted delivery information.
Separate completion from release.
Inspections and quality release are represented distinctly, with conditional completion and server validation.
Work across interfaces.
Browser and Android workflows share a backend rather than maintaining separate business rules.
These are documented capabilities. No unmeasured time savings or adoption figures are claimed.
The interface is part
of the operating model.
A good workflow interface communicates what is known, what remains uncertain and what the operator can do next. That principle extends beyond production software into wider digitalisation work.
Based on Production Planning documentation, V2.0.0 (October 2026). Source code is private. Diagrams and example records are illustrative.
← Explore more projects