SPC Process

This section walks through the operational workflow of using the Numerics.NET SPC API, from selecting an analysis through consuming results, integrating outputs into applications, and handling failures. Understanding the workflow helps you avoid the most common usage mistakes before you interact with detailed APIs.

Every SPC analysis in this library follows the same sequence of stages:

1. Choose the right analysis. Select the chart family that correctly models your measurement type and data structure. An incorrect choice produces statistically invalid results.

2. Prepare data correctly. Order observations chronologically, arrange subgroups as expected, and confirm that inputs satisfy the validation constraints for the chosen chart.

3. Interpret the result model correctly. Understand what the result object contains, which limit properties are scalar summaries and which are authoritative pointwise vectors, and how rule-violation windows are reported.

4. Integrate and persist outputs. Map result data to a plotting layer, expose it from a service, or serialize it for later rendering.

5. Handle diagnostics and failures. Respond correctly to exceptions from invalid inputs and surface advisory diagnostic messages to the appropriate layer of your application.

Each stage of the workflow has consequences for correctness:

• Chart selection affects statistical meaning. A P chart assumes binary outcomes. Applying it to count data violates its statistical model. The library cannot detect this error; you must choose correctly.

• Data contracts affect correctness. Control limits depend on subgroup structure, time order, and the absence of infinite or missing values. Incorrect inputs produce incorrect limits.

• Rendering semantics affect visualization correctness. Variable-sample P and U charts produce pointwise limit vectors. Rendering them from scalar summary limits produces incorrect chart lines.

• Diagnostics affect trust. An unstable process produces diagnostics that caution against interpreting capability metrics. Ignoring diagnostics leads to incorrect process assessments.

The most important transition in the SPC workflow is from stability assessment to capability analysis. Capability metrics ($C_p$, $C_{pk}$) are statistically meaningful only when the process is in statistical control. Compute stability first. Compute capability second, and only when stability is confirmed.

The second important transition is from chart computation to result consumption. Once Analyze() has been called, the fitted chart object is an immutable, self-contained snapshot of the analysis. It can be serialized, passed through service boundaries, and rendered at any later time without recomputing.

• Choosing the Right Analysis — decision guide and chart-selection matrix for every supported chart family. Start here if you are unsure which chart to use.

• Data Contracts and Preparation — supported input types, ordering requirements, subgroup semantics, missing-value handling, and validation constraints. Start here if your analysis is throwing or producing unexpected results.

• Result Model and Rendering Semantics — how to correctly interpret and render result objects, including scalar vs pointwise limits and rule-violation windows.

• Integration and Persistence — how to use results in plotting layers, web APIs, and serialized storage.

• Diagnostics, Exceptions, and Failure Modes — how the library communicates errors, warnings, and statistical cautions.

If you are new to the API, read the child pages in order: choosing an analysis, then data contracts, then result model, then integration, then failure modes. Each page assumes the previous ones.

If you have a specific problem, go directly to the relevant page. The pages are written to be self-contained.

Other Resources