Manufacturing Intelligence Platform
An end-to-end manufacturing analytics platform that turns seeded synthetic assembly-line records into executive visibility: OEE, output loss, defect propagation, shift repair gaps, reliability trends, and validation proof.
Evidence
Screenshots from the live dashboard showing the executive report, operational loss analysis, quality propagation, reliability planning, and data validation.
Problem
Manufacturing leaders need to know where output is being lost, whether quality problems are created upstream or merely detected downstream, and which reliability issues deserve capital planning. Raw logs do not answer those questions on their own.
The goal was to build a portfolio-safe factory analytics system that feels like a production data product while using only synthetic, seeded, reproducible data.
Users and decisions
Plant managers, production leaders, quality engineers, and maintenance leaders are the intended users. The dashboard helps them decide which stations, shifts, defect sources, and reliability risks deserve investigation or action first.
The dashboard is designed for an executive operations review: fast enough to scan, detailed enough to defend, and explicit about the data generation and validation behind every metric.
A seeded generator, a star schema, and a report that ranks loss
I built a seeded factory data generator, loaded the resulting events into a PostgreSQL star schema, created analytical SQL views, served the data through FastAPI, and published a Next.js report at the live factory domain.
The report moves from plant health to action: OEE decomposition, ranked station loss, crew repair variance, defect origin versus detection, event rediscovery, robot replacement candidates, seasonal reliability context, and validation evidence.
Architecture
Data flow
The generator writes reproducible CSV outputs from a fixed seed. A loader creates the database schema, imports the facts and dimensions, and applies validation checks before the API exposes the reporting views.
The frontend calls the API endpoints directly and presents results as executive metrics, ranked operational lists, trend charts, and trust panels. The same repo documents the generator, schema, backend, frontend, and deployment path.
Tools used
Key features
- Three-year synthetic plant dataset with 35.3M production, station, defect, and inspection records across 26,304 production hours, including 725.5k defect records and about 8k equipment faults.
- OEE decomposition into availability, performance, and quality.
- Ranked station-loss analysis combining downtime hours and scrap units.
- Shift and crew repair-time comparison that surfaces night-shift support gaps.
- Defect origin versus detection analysis to separate where problems are created from where they are found.
- Reliability view for replacement candidates, year-over-year fault trends, and seasonal fault context.
- Validation and provenance panel showing row counts, foreign-key checks, null checks, date range, and yield reconciliation.
Most defects are detected downstream of where they start
The core story is automated trend analysis across a multi-line plant model. The dashboard identifies production bottlenecks before they turn into vague monthly summaries: Final Assembly and Paint dominate combined loss, most defects are detected downstream from where they originate, and one crew has materially slower repair time for the same categories of faults.
The trend layer also checks whether real process changes can be rediscovered from the data. The model surfaces step changes tied to known synthetic events such as weld-cell retooling, a supplier fastener batch issue, a paint-booth upgrade, and a preventive-maintenance program.
Methodology
The dataset is fully synthetic and generated from a seeded Python model. That keeps the project publishable while still allowing realistic manufacturing patterns: wear-out curves, shift variance, defect propagation, seasonal severity, replacement resets, and known events for validation.
The methodology page and API expose provenance and validation checks so the dashboard does not ask viewers to trust polished charts without seeing the data quality layer underneath.
Injected events recovered end to end: the round trip is the claim
These numbers validate the transformation chain, not a plant. The data comes from a seeded generator I wrote, so the headline figures below are recovered signals: each was injected upstream and then rediscovered end to end from raw records through the star schema, the SQL views, and the dashboard. That round trip is the claim. Any OEE or yield figure the dashboard renders is a generator parameter read back, and is not evidence about a real factory.
Evidence for
Round tripInjected process events recovered end to end from raw records, confirming the pipeline preserves signal.Evidence for
69%Of defects surfaced downstream of the station that created them, recovered by the propagation join rather than assumed.Evidence for
45%Spot-weld defect reduction rediscovered from raw event records after the injected weld-cell retooling event, matching the seeded step change.Limitations
This is a portfolio demonstration built from synthetic data. It is not a real plant monitoring system and should not be interpreted as real operating performance, safety status, or machine-control logic.
The dashboard emphasizes executive analytics and validation. A production deployment would add authentication, role-based access, real data contracts, observability, incremental loading, and formal data-owner review.
What I would improve next
I would add incremental ingestion, dbt-style model documentation, alerting for emerging bottlenecks, drill-through views from executive charts to source events, and a Power BI companion report for stakeholders who prefer managed BI distribution.