From 500K Daily 5G Records to Factory Floor Safety: How Jagannathan Josium Applies Manufacturing Data Analytics to Catch Defects Before They Ship

A defect that gets caught in a dashboard costs a few dollars to fix. A defect that makes it past the production line costs thousands — in recalls, rework, and reputation. The difference between those two outcomes is not quality inspectors with clipboards. It is data.

Before I started building manufacturing safety dashboards at Rheo AI, I spent a year analyzing 5G network data for Verizon and AT&T at Prodapt — 500,000+ records every single day. When a cell tower dropped performance by 2%, our dashboards flagged it in minutes, not days. That experience changed how I think about manufacturing data: the same techniques that catch network anomalies at telecom scale catch defect patterns on a factory floor.

Most manufacturing analytics fails not because the data is bad. It fails because dashboards show yesterday's summary instead of today's signal. By the time someone opens a weekly PDF report and notices a defect trend, the defective parts have already shipped.

I build dashboards that prevent that — using D3.js, Grafana, and Kibana to turn raw manufacturing and safety data into real-time, actionable signals. Here is how manufacturing data analytics actually works when you are building it from the data up, not from a vendor pitch down.

Expert Insight by

Jagannathan Josium

Data Analyst

Manufacturing Data Analytics / Telecom AnalyticsLinkedIn

Jagannathan Josium is a Data Analyst with cross-industry experience spanning manufacturing safety analytics, 5G telecom network analysis, and banking application performance. At Rheo AI, he analyzes manufacturing and safety datasets, builds interactive dashboards using D3.js, Grafana, and Kibana, and identifies defect patterns that improve operational performance. Previously at Prodapt, he analyzed 500K+ daily 5G network records for Verizon and AT&T, applied LLM-based analysis to 500K+ log records, and improved API response times by 15% using BigQuery. He holds an M.S. in Computer Science (Machine Learning) from the University at Buffalo.

Verified Expert

Most manufacturers sit on enormous amounts of data and extract almost nothing useful from it. Sensors on every machine, quality logs from every shift, safety incident reports from every quarter — all of it stored somewhere, most of it never analyzed beyond a monthly summary slide.

The field covers four distinct layers, and most organizations are stuck on the first one:

At Rheo AI, I work across all four layers — but the biggest impact comes from moving manufacturers from descriptive to diagnostic. Knowing your defect rate was 3.2% is useless if you do not know why. Knowing that defects spike after shift changes on a specific machine — that is actionable.

Before I touched manufacturing data, I spent a year at Prodapt analyzing 5G network performance for Verizon and AT&T. Every day, 500,000+ records flowed through our pipelines — signal strength, latency, throughput, error rates, device handoffs, tower performance metrics. The job was to find the anomalies that mattered in a sea of noise.

That sounds nothing like manufacturing. But the underlying patterns are identical.

Why Telecom and Manufacturing Data Are the Same Problem

A 5G cell tower and a CNC machine have more in common than you would think. Both generate high-volume time-series data. Both have normal operating ranges that drift under stress. Both require real-time monitoring because catching a problem an hour late means the damage is already done.

At Prodapt, I built dashboards that could detect a 2% performance drop in a specific network segment within minutes. The technique was straightforward: establish baselines per segment, apply statistical thresholds, trigger alerts when deviations persist beyond a time window. That same approach — baselines, thresholds, time-windowed alerts — is exactly what I use now for manufacturing defect detection.

The LLM-based analysis was another direct transfer. At Prodapt, I applied LLM-based analysis on 500,000+ log records to identify patterns that traditional regex-based parsing missed. Network logs are messy, semi-structured text — just like manufacturing system logs. The same technique of using language models to extract structured insights from unstructured logs works on both.

At Rheo AI, I build interactive dashboards using three tools: D3.js for custom stakeholder-facing visualizations, Grafana for real-time operational monitoring, and Kibana for log analysis and investigation. Each tool serves a different purpose, and using the wrong one for the wrong job is one of the most common mistakes I see.

The Three-Layer Dashboard Architecture

The dashboards I build follow a three-layer architecture that separates operational monitoring from investigation from strategic reporting:

Grafana for Real-Time Operations

Grafana connects directly to time-series databases and displays live production metrics — temperature, pressure, cycle times, defect counts, safety incidents. The power of Grafana is its alerting system: when a metric crosses a threshold, it triggers a notification before a human would notice the problem.

For manufacturing safety dashboards, the critical alerts are:

• Equipment parameter drift — a machine's operating temperature creeping upward over hours
• Defect rate spikes — reject count exceeding the baseline for a specific production run
• Safety sensor triggers — gas levels, noise levels, or vibration exceeding safe operating ranges
• Cycle time anomalies — a machine taking 15% longer per cycle, indicating potential wear

Kibana for Investigation

When Grafana flags an anomaly, Kibana is where I go to understand why. Kibana sits on top of Elasticsearch, which indexes manufacturing logs — machine event logs, quality inspection records, maintenance history, operator actions.

The investigation workflow looks like this: Grafana alert fires for a defect spike on Line 3. I open Kibana, filter logs to Line 3 for the last 4 hours, and search for correlated events. Did a material batch change? Did a maintenance event occur? Did an operator change shifts? Kibana lets me search, filter, and visualize log data to find the root cause.

D3.js for Strategic Dashboards

D3.js is what I use when Grafana and Kibana are not enough — when the visualization needs to be custom, interactive, and designed for a non-technical audience. Plant managers do not want to learn Grafana. They want a browser-based dashboard with intuitive navigation that tells them: are we safe, are we on target, and what needs attention?

D3.js lets me build exactly that — heat maps of defect rates by machine and shift, interactive drill-down charts that let managers click from plant-level summary to line-level detail, and trend visualizations that show whether safety metrics are improving or degrading over time.

Defect detection in manufacturing is not about finding defects — quality inspectors do that. It is about finding the patterns that cause defects before the next batch is affected.

At Rheo AI, I analyze manufacturing datasets to identify trends and anomalies in operational performance. The methodology follows a systematic approach that I developed from telecom anomaly detection.

The Baseline-Deviation-Correlation Method

Every measurable parameter gets a baseline — the normal operating range derived from historical data. For a manufacturing process, this includes cycle time per part, machine operating temperature and pressure, defect rates per shift and per machine, and material consumption rates.

The baseline is not a single number. It is a distribution with expected variance. A cycle time of 45 seconds ± 3 seconds is normal. A cycle time of 52 seconds is a signal.

With baselines established, I apply statistical process control (SPC) rules to flag deviations in real time. The standard Western Electric rules work well for manufacturing:

• 1 point beyond 3σ — immediate alert (critical anomaly)
• 2 of 3 consecutive points beyond 2σ — warning (trending anomaly)
• 8 consecutive points on one side of the mean — investigation required (systematic shift)

These rules run continuously on the Grafana dashboards, turning raw sensor data into actionable alerts.

When a deviation is flagged, the analysis shifts from "what" to "why." I correlate the anomaly with upstream variables:

At Rheo AI, one of the first things I did was identify which analysis tasks were being repeated manually — and automate them. Recurring reports that consumed hours of analyst time every week were prime targets.

What Manual Reporting Actually Costs

The hidden cost of manual reporting in manufacturing is not just time. It is delay. When an analyst spends Monday morning compiling last week's safety report, the data is already 2-3 days old by the time a manager reads it. In manufacturing, that delay can mean defective parts have already been shipped, a safety risk has already been present for multiple shifts, or an equipment problem has already worsened.

How I Automated Recurring Analysis

The automation approach I use follows a consistent pattern:

1. Identify the recurring task — any analysis performed on a schedule (daily, weekly, monthly)
2. Extract the logic — what data sources, what transformations, what output format?
3. Build the pipeline — SQL for extraction, Python for transformation, scheduled execution via Airflow or cron
4. Replace the report with a dashboard — instead of generating a PDF, push results to a live dashboard
5. Add alerting — if the report existed because someone needed to check a metric, add an alert that triggers when the metric needs attention

The result: analysts stop spending time generating reports and start spending time on investigation and improvement — the work that actually moves metrics.

At Prodapt, I applied LLM-based analysis on 500,000+ log records to identify patterns that traditional methods missed. This is one of the most transferable techniques from telecom to manufacturing, and it is still underutilized in the manufacturing sector.

Why Traditional Log Analysis Falls Short

Manufacturing systems generate logs — machine event logs, PLC logs, SCADA system messages, quality inspection notes, maintenance records. These logs are semi-structured at best: a mix of timestamped events, error codes, free-text descriptions, and numerical readings.

Traditional log analysis uses regex patterns and keyword matching to extract structured data from these logs. The problem: regex patterns break when log formats change, miss patterns that do not match predefined rules, and cannot interpret free-text descriptions like "operator noticed unusual vibration during startup sequence."

How LLM-Based Analysis Changes the Game

LLM-based log analysis uses large language models to parse and interpret unstructured log data. Instead of defining every pattern manually, the model can:

• Extract structured events from free-text maintenance notes
• Classify incidents by severity and type without predefined categories
• Identify correlations across log entries that span different systems
• Summarize trends from thousands of log entries into actionable insights

At Prodapt, this approach improved issue detection accuracy on telecom network logs. The same technique applies to manufacturing: feed machine logs, quality inspection notes, and maintenance records into an LLM pipeline, and extract patterns that human analysts and regex rules would miss.

I use all three tools daily at Rheo AI, and the most common mistake I see is teams trying to use one tool for everything. Each tool has a specific strength, and the right choice depends on the use case, not the tool's popularity.

When to Use Grafana

Use Grafana when you need live operational dashboards that floor supervisors check throughout the shift. Grafana excels at time-series visualization — temperature over time, defect count per hour, machine uptime percentage. Its alerting system is the most mature of the three, supporting email, Slack, PagerDuty, and webhook notifications.

At Rheo AI, Grafana is our operations layer. Every production line has a Grafana dashboard showing live KPIs, and alerts fire when any metric crosses its threshold.

When to Use Kibana

Use Kibana when you need to investigate — when a Grafana alert fires and you need to understand why. Kibana sits on Elasticsearch, which indexes log data for fast full-text search. When a defect spike occurs, analysts open Kibana to search logs, filter by time range and machine, and discover what happened.

Kibana's Discover view is where root cause analysis happens. You can search across millions of log entries, filter by fields, and visualize patterns in the data.

When to Use D3.js

Use D3.js when Grafana and Kibana are not enough — when you need a visualization that does not exist as a pre-built panel, or when the audience is non-technical and needs an intuitive, custom interface. D3.js gives you full control over every pixel, which means you can build exactly the visualization the use case requires.

The tradeoff is development time. A Grafana dashboard takes hours. A D3.js dashboard takes days or weeks. Use D3.js only when the custom visualization justifies the investment.

After working across telecom and manufacturing analytics, I have seen the same mistakes kill analytics projects regardless of industry. Here are the ones that cost the most.

Mistake Deep Dive: Historical Summaries vs Real-Time Signals

This is the most expensive mistake. A monthly quality report tells you what happened 30 days ago. A real-time dashboard tells you what is happening right now. In manufacturing, the difference between those two is whether you catch a defect pattern in the first hour or after 10,000 parts have been produced.

The fix is architectural: design your data pipeline for real-time from the start. Sensor data should flow into a time-series database (InfluxDB, Prometheus, TimescaleDB) that feeds Grafana dashboards with sub-minute refresh rates. Do not route manufacturing data through batch ETL pipelines that run nightly — by the time the data arrives, the opportunity to act has passed.

Mistake Deep Dive: No Baseline Modeling

I see manufacturing teams set static alert thresholds — "alert if temperature exceeds 200°C" — without understanding the normal distribution of that metric. If the machine normally operates at 195-198°C, a static 200°C threshold will fire constantly (false alarms) or never fire until a catastrophic exceedance.

Statistical baselines solve this. Calculate the mean and standard deviation from historical data, then alert on deviations from the baseline rather than raw values. A machine running at 202°C when its baseline is 196°C ± 2°C is a meaningful signal. The same 202°C on a machine with a baseline of 200°C ± 3°C is normal operation.