Architected an industrial IoT platform unifying dye-formulation, defect grading, and machine telemetry using algorithmic recipe engines and Redis Pub/Sub. Achieved sub-25ms real-time broadcasting and reduced lab dye trials by 60% with Next.js, FastAPI, TimescaleDB, and AWS.
// THE CONTEXT
Textile mills lose hundreds of thousands of dollars each month due to failed dye trials and missed defects.
I designed and developed AutoTaskX to solve this by directly bridging the gap between advanced academic research and industrial manufacturing floors.
// THE ORIGIN: ACADEMIA MEETS INDUSTRY
Synthesizing Academic Research into Software Architecture
The genesis of AutoTaskX was highly unconventional. The client approached me not with traditional software wireframes or product specification documents, but with an exhaustive, in-depth academic thesis. This thesis was authored by a brilliant student and researcher at the Bangladesh University of Textile Engineering (BUTEX).
The core of the research focused on predicting exact dye formulations via complex non-linear optical equations, and automating fabric defect grading using high-speed optical physics. To accurately translate this vision into reality, I collaborated closely with a highly professional researcher from BUTEX.
My primary objective was to master these concepts—spending 20 intensive days studying textile chemistry, spectrophotometric reflectance, and ASTM grading standards—and architect a scalable software infrastructure that could execute this academic theory in real-time on a production factory floor.
// KEY ENGINEERING CHALLENGES
Handling Extreme Domain Ambiguity
The Challenge: Requirements were rooted in a dense 150+ page BUTEX academic thesis containing chemical kinetic equations, spectrophotometer physics, and international textile standards (ASTM, ISO, AATCC).
The Solution: Dedicated 20 full days solely to deep academic domain research. Mastered optical reflectance spectroscopy, Kubelka-Munk theory, and jet dyeing mechanics to break down complex theory into maintainable software microservices.
Translating Optical Physics into Matrix Math
The Challenge: Matching target shades requires combining multiple dyes such that their combined absorption curve matches 31 individual wavelengths (400nm to 700nm), ensuring concentrations aren’t negative.
The Solution: Formulated the problem as a Non-Negative Least Squares (NNLS) matrix optimization using `scipy.optimize.nnls`. The system computes exact dye concentration vectors in under 15 milliseconds and includes CIEDE2000 evaluation.
Real-Time Edge Computer Vision & WebSockets
The Challenge: Defect events from 8K cameras arrive in bursts at 60 meters/minute line speeds. Naive WebSocket servers and concurrent database writes lead to corrupted scores and desynced UI HUDs.
The Solution: Implemented an async WebSocket manager backed by a Redis Pub/Sub backplane to sync all HUDs instantly. Used PostgreSQL pessimistic row locking (`with_for_update`) to guarantee ACID consistency when calculating ASTM cut-plans.
AST-Constrained Text-to-SQL
The Challenge: Managers wanted to ask natural language questions (e.g., “Show me yesterday’s high temp batches”). Deploying raw LLMs for SQL generation risks accidental data deletion and SQL injections.
The Solution: Built a 4-stage safety pipeline: Intent extraction, AST parsing via `sqlglot`, strict read-only enforcement (blocking DDL/DML), and whitelist verification scoped only to safe production tables.
// TECHNICAL COMPLEXITY BREAKDOWN
| DIMENSION | TRADITIONAL APPROACH | AUTOTASKX IMPLEMENTATION |
|---|---|---|
| Color Formulation | 3–5 manual lab dips taking 24–72 hours; visual subjective matching. | Kubelka-Munk NNLS matrix solver across 31 spectral wavelengths (400–700nm) in <15ms. |
| Color Tolerance | Simple RGB/HEX distance or legacy CIE76 (inaccurate for human eye). | Comprehensive CIEDE2000 (ΔE00) + Multi-illuminant metamerism indexing (D65, TL84). |
| Quality Inspection | Human inspector on manual perch; optical fatigue; 20-30% missed defects. | 8K GigE line-scan ingestion, sub-25ms ASTM D5430 grading, automated cut relay. |
| Machine Telemetry | Handwritten operator logs; disconnected machine dial gauges. | Sub-second PLC telemetry ingestion (Fong’s, Thies) into TimescaleDB hypertables. |
| Multi-Worker Sync | Single-node in-memory WebSockets (fails when scaled across containers). | Distributed WebSocket connection manager with Redis Pub/Sub cluster backplane. |
| Database Concurrency | Naive read-then-write (causes race conditions and corrupted roll scores). | Pessimistic row locking (`with_for_update`) ensuring atomic penalty accumulation. |
| Query Safety | Raw LLM Text-to-SQL (vulnerable to prompt injection & drops). | 4-stage AST parsing with sqlglot, whitelist enforcement, read-only sandboxing. |
// MEASURABLE OUTCOMES
60%Reduction in lab-to-bulk lead time by computing exact dyestuff recipes mathematically.
25–35%Reduction in fabric rejection chargebacks through automated ASTM D5430 grading.
$$$Significant savings in water, steam, & dyestuff by predicting exact recipe affinity.
< 1sMachine telemetry updates and instant alerts for factory floor managers.
// TECHNICAL DEEP-DIVE Q&A
How did you design for concurrency and real-time performance?
In AutoTaskX, 8K line-scan inspection cameras stream fabric defect events at speeds up to 60 meters per minute. To solve concurrent writes (multiple defect events arriving simultaneously), I utilized PostgreSQL pessimistic row locking (`with_for_update`) within SQLAlchemy AsyncSession to ensure atomic score accumulation. For real-time HUD synchronization across multiple Docker container instances, I implemented a distributed WebSocket manager with a Redis Pub/Sub backplane. Any worker processing a defect publishes to Redis, instantly updating all connected operator HUDs with sub-25ms latency.
How did you ensure security when implementing Text-to-SQL for factory managers?
Executing LLM-generated SQL on production machinery databases is dangerous. I built a 4-stage validation pipeline: First, we provide strict schema context to the LLM. Second, before execution, the generated SQL passes through `sqlglot` to parse its Abstract Syntax Tree (AST). Third, we enforce a strict whitelist of allowed tables and explicitly verify that the root AST expression is a read-only `SELECT`. Any query attempting `DROP`, `ALTER`, or accessing system tables is instantly rejected. Finally, the query is executed with scoped read-only credentials, ensuring complete immunity to SQL injection.