The challenge
The client’s process and quality data already lived in Seeq as one large asset tree: product, step, operation, measurement, site. SPC didn’t. The usual way to add it, one control chart per parameter built by hand, doesn’t survive thousands of parameters across dozens of production lines.
The parameters weren’t one kind, either. Lab results such as bioburden, assay, potency and yield arrive once per batch and need a classic control chart. Continuous in-process signals run for hours, and a single mean and sigma say nothing about them; they need a golden-batch profile, a typical run shape with bounds around it. Spec limits existed for some parameters and not others.
Hand-built charts also drift apart, one engineer’s choices at a time. Adding a parameter should be a re-run, not a project.
Our approach
- Classify from the tree, not the data Signal metadata couldn’t tell discrete from continuous: every signal reported the same interpolation type. The client’s own naming convention could, so the classifier reads that, with a fallback bucket that surfaces unknown types instead of dropping them.
- Build the analysis once, as a second asset tree A build walks the source tree and writes a parallel one where every parameter already holds its finished analysis as ordinary Seeq calculated items: centerline, sigma bands and Nelson rules 1–3 for discrete parameters, a golden profile and excursion condition for continuous ones. All the math runs in Seeq Formula.
- Use spec limits where they exist Where the source carries spec limits, the analysis uses them. Where it doesn’t, it falls back to limits calculated from sigma, so every parameter gets a chart on day one.
- Prove it before touching the client’s server Every step ran first against a mirror tree we controlled: offline tests, a formula oracle the builder had to match exactly, and a read-only compile check of every formula shape. The first write to client data was a deliberately small slice covering every parameter shape.
- Put a lens on it Engineers drill from product down to parameter in a Data Lab add-on, see a share-of-batches-in-control score, open the parameter’s own chart, and turn any node into a one-page Organizer report.
The outcome
The analysis runs in production across thousands of parameters. The charts are generated, not hand-built, and a new parameter is picked up by re-running the build. The first walk of the client’s real tree also caught a defect our synthetic test data had hidden: real step and operation names carried an ordering prefix the test data had stripped, and left alone it would have collapsed every parameter into one container. It was caught before anything was written. Test data has to copy the server’s naming exactly, not the parser’s cleaned-up version of it.
- Thousands of quality parameters under live SPC across many sites
- Each parameter type gets the analysis it needs, not one shared recipe
- Spec limits used where they exist, sigma limits where they don’t
- In-control scores read a pass/fail flag, never process values
- A new parameter is a re-run of the build, not a new chart