Learning to Make Quality Visible

From Dashboards to Workflow Platforms

I built and deployed the Manufacturing Quality Intelligence Platform to connect evidence collection, investigation state, process context, and corrective-action review in one workflow.

The shift was from presenting analytical results to supporting the steps engineers take before and after a conclusion.

Designing Human-in-the-Loop AI

The platform integrates an AI provider within explicit evidence boundaries. It streams progress and structured output, while preserving uncertainty, references, and human review.

The output supports investigation decisions. It does not claim autonomous root-cause determination or replace formal quality judgment.

Production-Oriented Engineering

FastAPI, asynchronous services, provider integration, streaming feedback, and cloud deployment made operational behavior part of the design. The deployed public platform uses confidentiality-safe generated scenarios and remains separate from formal production quality systems.

From Reports to Investigation Tools

I moved beyond static reporting and built dashboards that brought yield trends, defect concentration, equipment patterns, retest behavior, and corrective-action results into the same investigation flow.

Tableau supported broad communication across the review, while Python made more customized analysis and interaction possible.

Combining Domain Knowledge and Statistical Signals

Statistical signals helped surface unusual periods and concentrated patterns. Manufacturing context still determined which evidence mattered and what required engineering review.

Anomaly detection became a way to prioritize attention, not a claim of automatic root-cause determination.

What the Demos Were Designed to Prove

The public dashboards were confidentiality-safe demonstrations rather than deployed factory systems. They showed how domain knowledge, visualization, and analytical methods could form a reusable quality-review workflow without exposing production records.

Beyond the Page

A page working locally is not the same as a system people can trust.

When a tool became part of an engineering workflow, the hard parts moved beyond the UI: who could change what, how data moved through the API, how status changed over time, how schema changes affected existing records, and how to understand failures without guessing.

What I Started to Care About

I began paying more attention to things that are easy to ignore in a demo:

• API contracts
• permission boundaries
• database migrations
• automated tests
• logs and error context
• deployment differences
• recovery paths when something goes wrong

That was the difference between building features and building an internal system.

Why I Expanded

Scripts and desktop tools were useful for individual analysis, but they became harder to maintain and share as workflows grew.

I expanded into web systems because engineering teams needed clearer inputs, shared status, and traceable results rather than isolated outputs.

What I Learned

I learned and applied Flask, Vue, REST APIs, authentication, relational data modeling, and containerized deployment. MySQL became a way to represent products, process steps, evaluation records, and workflow states.

Deployment and maintainability became part of the engineering problem, not tasks to consider after a feature was finished.

How Manufacturing Context Shaped the Software

The systems followed real evaluation workflows: evidence had to stay connected to process context, status changes needed to be visible, and another engineer had to understand what happened without relying on my memory.

The Reason

I did not start Python automation because I wanted to become a software engineer.

I started because the same work kept coming back: raw data cleanup, test-log parsing, measurement extraction, yield summaries, weekly reports, and trend charts.

I used Python to turn manufacturing test logs into structured tables and visualizations, extracting fields such as product identifiers, electrical measurements, test items, results, and process context.

The Shift

At first, scripts were just a way to save time.

Then I realized they were also a way to make repeated analysis more consistent. If the same manufacturing logic had to be applied again and again, it should not live only in manual Excel operations or memory.

This was where software became part of my quality workflow.

A Different Level of Ownership

By early 2023, product quality work no longer felt like only reading abnormal data.

Issues such as component damage and FET burnout forced me to connect more layers at the same time: electrical behavior, PCB-level symptoms, process history, hardware confirmation, and yield recovery.

Moving the Problem

The goal was not just to identify a defect.

The real work was moving the problem to the place where it could be fixed: the process condition, the equipment behavior, the handling method, or the control point that created the risk.

That was when product quality started to feel like work I could own with confidence.

The Trap

A fail code feels like an answer when you first see it.

It is not.

A code can point to a direction, but it cannot tell you whether the issue is a false fail, a product defect, a process problem, or an equipment abnormality.

The Evidence Chain

I learned to compare the code with everything around it: logs, retest behavior, position or equipment concentration, earlier process history, equipment condition, and hardware confirmation.

Sometimes the product was fine.

Sometimes the failure was real.

Sometimes the root cause was far upstream from where the fail code appeared.

That changed how I looked at manufacturing data. The signal mattered, but the evidence chain mattered more.

A New Vocabulary

Production had its own language.

Yield, process step, test result, product identifier, schematic, product history, internal system. At first, I was not trying to build anything impressive. I was trying to understand what the data was saying.

Excel was the first translator. I used raw production data and pivot tables to summarize yield, classify results, and draw simple yield trends.

What Started to Connect

The numbers only made sense when I connected them with the process.

For SSD and eStorage products, I learned how units moved through assembly, array-level testing, singulation, and later validation stages. I also started using schematic review to support basic product and circuit-level analysis.

That was the beginning of reading manufacturing as a system, not as isolated tables.

The First Pattern

Most problems did not arrive as clean technical descriptions.

They came as screenshots, vague symptoms, urgent messages, or repeated complaints. My work was to slow the situation down: reproduce the issue, record the context, track the case, and make the next step clear.

What Stayed

I did not know it at the time, but this became a habit I kept using later.

A symptom is not the root cause.

A case needs context.

Repeated issues should become a better workflow, not just more manual effort.