Jehu Lara
ENES
Menu

01 / Case study

QualityOps

Independent open-source technical project

Auditable manufacturing-data analysis across Python, PostgreSQL, SQL, Power BI, and CI.

Status
Published
Evidence
Aug 14, 2026
Stack
Python · PostgreSQL · SQL · Power BI · CI

Evidence as of Aug 14, 2026 · source 2004621 (opens in a new tab)

02

Executive summary

Manufacturing analyses can look precise while concealing choices about missing data, subgrouping, variation estimates, and the limits of descriptive evidence.

The project tests a narrower proposition: can an analysis make those choices inspectable and reconcile the resulting claims across independent technical layers?

My scope

Designed and built the package, data-quality controls, statistical validation, PostgreSQL persistence, audited SQL layer, Power BI evidence view, and automated checks.

03

What I built

  1. 01

    Create strict data-ingestion and statistical contracts in an installable Python package and CLI.

  2. 02

    Audit a public, externally sourced manufacturing dataset before persisting it without imputation.

  3. 03

    Reconcile decision-facing Power BI measures against audited SQL and independent Python calculations.

04

Architecture and data flow

Each stage narrows a different risk: source integrity, calculation clarity, persistence integrity, independent querying, decision communication, and regression protection.

  1. 01

    Excel / public SECOM

    Controlled inputs enter through strict workbook selection or hash-verified public source files.

  2. 02

    Python

    Parsing, data-quality checks, statistical methods, and deterministic source oracles make assumptions explicit.

  3. 03

    PostgreSQL

    A normalized schema stores observations, sensors, and measurements through one transactional, idempotent load.

  4. 04

    Audited SQL

    Twenty parameterized, read-only queries provide a second analytical and reconciliation layer.

  5. 05

    Power BI

    A one-page, read-only decision view communicates dataset health, observed outcomes, and descriptive associations.

  6. 06

    CI evidence

    Automated checks protect calculation contracts, reconciliation evidence, documentation boundaries, and sensitive-data controls.

05

Validation and reconciliation

  • One-way ANOVA, Pearson correlation, and simple linear regression matched Minitab on the same versioned datasets within displayed precision and reached the same conclusions at α = 0.05.
  • The PostgreSQL load validates source hashes and quality oracles before connecting, uses one transaction, rolls back on exceptions, and validates an identical second load without writing again.
  • Six DAX result sets reconciled against corresponding SQL queries and independent Python oracles. This establishes consistency inside the tested scope, not causal correctness.

Visual evidence

QualityOps evidence in five views

A concise, keyboard-operable walkthrough of the problem, architecture, verified dataset evidence, authentic Power BI view, and analytical boundaries.

1 of 5

QualityOps title slide presenting auditable decisions from manufacturing data.
Slide 1 of 5. Auditable decisions from manufacturing data. An evidence-first technical project that makes assumptions, data-quality signals, reconciliation, and decision boundaries inspectable.

Slide 1 of 5

Auditable decisions from manufacturing data

An evidence-first technical project that makes assumptions, data-quality signals, reconciliation, and decision boundaries inspectable.

Manufacturing analyses can look precise while concealing choices about missing data, variation, and statistical interpretation.

QualityOps tests whether those choices can remain traceable from controlled inputs through a decision-facing view.

Open full-resolution slide (opens in a new tab)

1 of 5 · Auditable decisions from manufacturing data

QualityOps title slide presenting auditable decisions from manufacturing data.
Slide 1 of 5. Auditable decisions from manufacturing data. An evidence-first technical project that makes assumptions, data-quality signals, reconciliation, and decision boundaries inspectable.
Auditable decisions from manufacturing data

An evidence-first technical project that makes assumptions, data-quality signals, reconciliation, and decision boundaries inspectable.

06

Evidence-backed findings

Every number carries its meaning and its boundary.

1,567

observations

Represents
Every source measurement row has a corresponding outcome and timestamp.
Why it matters
It defines the bounded population inspected by this public dataset audit.
Does not show
It does not establish deployment scale or represent all manufacturing contexts.

1,463 / 104

observed pass / fail

Represents
The labels in the source are strongly imbalanced: 93.36% pass and 6.64% fail.
Why it matters
The imbalance changes how outcome comparisons should be read and validated.
Does not show
It is not evidence of process health, capability, or acceptable performance.

590

measurement sensors

Represents
The physical measurement columns preserved from the public source.
Why it matters
It creates a wide analytical surface where missingness and constant signals require explicit controls.
Does not show
The source does not provide specification limits or a suitable within-subgroup sigma.

924,530

measurement coordinates

Represents
The complete 1,567 × 590 observation-and-sensor grid, including missing coordinates.
Why it matters
The normalized database reconciles every coordinate rather than only non-null values.
Does not show
The count is not a capacity or industrial scalability benchmark.

41,951

missing measurements

Represents
Source NaN values retained as SQL NULL without imputation, across 538 sensors.
Why it matters
Missingness is a material data-quality risk that must remain visible in interpretation.
Does not show
Missing values alone do not identify their operational cause or impact.

20

audited SQL queries

Represents
A parameterized, read-only analytical contract over the persisted data.
Why it matters
The queries add traceability and an independent layer for reconciling claims.
Does not show
The number of queries does not demonstrate production capacity or industrial scale.

07

Boundaries and unsupported conclusions

  • SECOM does not support Cp, Cpk, Pp, or Ppk conclusions because it lacks documented specification limits and a suitable within-subgroup sigma.
  • Observed associations and standardized mean differences do not identify root causes or establish causality.
  • Reconciliation across Python, SQL, and DAX demonstrates consistency within the validated scope; it does not establish industrial validity.
  • The repository is an alpha portfolio artifact, not an operational quality-management system or a deployed service.
  • The Power BI view is a local, read-only consumer of PostgreSQL and was not published to Power BI Service or Fabric.
  • The statistical comparison reproduces selected results under explicit assumptions; it does not replace the reference tool.

08

Source and provenance

All public technical statements on this page are bounded by the pinned repository evidence.

View full provenance
Evidence date
2026-08-14
Documents consulted
  • README.md
  • docs/portfolio-claims.md
  • docs/powerbi-process-health.md
  • docs/assets/powerbi-process-health.png
  • docs/statistical-validation.md
  • docs/postgresql-persistence.md
  • docs/secom-dataset.md
  • ROADMAP.md
  • LICENSE
Licensing
Project-authored code and documentation are MIT. The original UCI SECOM files and derived representations, including the screenshot, retain CC BY 4.0.