Operating experience · detailed evidence

Proof · EV fleet

Case A — industrial fleet telemetry pipeline

Problem: Industrial fleet telemetry across 700+ vehicles arrives fragmented, asynchronous, and model-specific; raw payloads have to become production evidence.
Role: Team delivery. Stated scope: InfluxDB ops, mqtt → InfluxDB Converter refactor, expression-evaluation visualization, and Celery module ops.
System: Webhook ingest, Bridge InfluxDB as raw-hex landing/replay storage, multi-process converter, measurement InfluxDB, Celery batch, Avro/GCS output.
Transfer: The same P1-P3 primitives map to robot teleop data, manufacturing-line telemetry, and foundation-data pipelines.
Proof: 1 year 5 months of production operation across a 700+ vehicle fleet. Pipeline performance validated through a heterogeneous asynchronous telemetry load test at 7,000 events/sec (7k TPS).

Industrial vehicle fleet telemetry pipeline (700+ vehicles).A 4-tier distributed telemetry system delivered as part of a team for a 700+ vehicle production fleet. The data-processing modules listed below were my contribution.

Four-tier ingest pipeline: edge to gateway to pipeline to warehouse.

[vehicle terminal] → Webhook → Bridge InfluxDB
  → V2InfluxConverterProcess (multi-process)
  → Measurement InfluxDB → Celery batch → Avro/GCS

Bridge InfluxDB was not a Kafka replacement; it acted as a time-series landing / replay layer for raw hex payloads so failed conversions could be reprocessed. The converter then normalized those payloads into measurement InfluxDB. The pipeline was designed and tested to absorb a 7,000 events/sec asynchronous event-stream load without becoming the bottleneck.

Load-test boundary

Fleet scale: 700+ vehicles in production
Throughput: 7k events/sec synthetic heterogeneous telemetry
Stage: raw landing → converter normalization → measurement write path
Validation: parser stability, bounded memory, replay path
Not claimed: Kafka-style consumer groups or exactly-once semantics

Tier 1 (ingest): Django / Flask webhook · raw hex payload preserved
Tier 2 (decode): ISO-TP reassembly + expression DSL + 4-pack BMS alignment
Tier 3 (analytics): Celery module plug-ins (summary / driving_score / submatrix / avro)
Tier 4 (output): measurement InfluxDB + Avro on GCS

Production reliability

Failure-time reprocessing SLA operated in production. When the converter or measurement-tier InfluxDB hit transient outages, Bridge InfluxDB's raw-hex landing layer drove an automatic replay path within the defined SLA.
Metadata DB on MHA (MySQL High Availability) for zero-loss operation. Automatic failover under master failures, with no data loss in production.

Why this transfers to robot / manufacturing

Industrial vehicle fleet	Robot / manufacturing
4-pack BMS async signals per vehicle	30+ joints + F/T + vision per robot · N machines per line
CAN ISO-TP multi-frame	ROS2 chunked / OPC-UA chunked
Per-model .dbc / Excel DSL	Per-robot URDF / per-PLC vendor protocol

Contribution: mqtt → InfluxDB Converter refactor · expression-evaluation visualization · Celery module ops
Period: 1 year 5 months

Proof · untamedai

Case B — untamedai.me LLM product

Problem: An LLM companion needs memory, safety, payment, and operating-cost control, not a single model call.
Role: Solo owner across product planning, system design, build, deployment, and daily operations.
System: Next.js · FastAPI · Supabase · Cloudflare · PostgreSQL · Claude Opus · GPT 5.x · Polar (payments) · production monitoring loops.
Transfer: LLM ops maps to VLA instruction curation and operator-assistant RAG over manufacturing logs and SOPs.
Proof: 1 year live operation · 1 solo owner · 2 production routes · free tier in production; paid tier with Polar payment system integration and sandbox validation completed.

untamedai.me — solo full-stack LLM product.untamedai.me — an AI companion that remembers users' emotions, planned, built, deployed, and operated end-to-end by one person.

untamedai five-stage operation pipeline: plan, design, build, deploy, operate.

01
Plan
Differentiated concept (the Little Prince fox metaphor + emotional memory), user personas, free / paid (SOULMATE) tier design, copy and brand voice. Product decision = business decision = ops-cost decision, treated as one.
02
Architecture
Memory architecture (short-term context / long-term vector / summary store layered), MBTI-inference consistency, emotion-calendar color mapping, safety guardrails. The system is not one model call — it is memory + session + safety wired together.
03
Build
Next.js frontend · Python FastAPI backend · Supabase + PostgreSQL · Cloudflare hosting · Claude Opus + GPT 5.x for LLMs · Polar for payments — solo full-stack.
04
Deploy
Hosting · CI/CD · domain (untamedai.me + multilingual routing — /samakyeowoo for Korean SEO) · TLS · monitoring channels.
05
Operate
Token-cost discipline (for a solo operator, tokens = runway), moderation balance (Korean AI sensitivity post-Iruda), inflow monitoring, iterative-improvement decisions.

Primitives

Three reusable industrial data primitives

Three pillars proven on an industrial vehicle fleet. They port directly into robot manufacturing and traditional manufacturing.

P1
Fragmented Stream Reassembly
Diagram — sparse arrival fragments → mask bitmap → reassembled signal.
Verified env
Industrial vehicle CAN ISO-TP — First Frame(0x10), Consecutive Frame 4-bit SN wraparound(0x21..0x2F → 0x20), and receiver Flow Control(0x30) tracked separately. Mask-bitmap partial fill inside a timeline window derived from PID period and jitter distribution, with bounded memory.
P2
Multi-Source Temporal Alignment
Diagram — four async channels aligned at a common reference column.
Verified env
Master 1·2 and Slave 1·2 four-pack BMS — each pack’s V·I arrives asynchronously under independent PIDs. Window size is derived from signal PID period and jitter distribution, then values are aligned and summed across four packs for instantaneous power.
P3
Schema-Driven Device Decoder
Diagram — heterogeneous raw sources → adapter → canonical event (schema-registry contract).
Verified env
Per-vehicle signal mappings expressed as a single Excel sheet. Expression DSL → AST whitelist evaluation + compile-cache.

Manufacturing

Target systems — manufacturing AI workflows

What I want to build — robot-manufacturing and existing-manufacturing AI workflows.Current assets are industrial data pipelines and LLM product operations. Robotics, semiconductor, and steel domain depth are separated honestly as post-hire learning areas.

Current assets: Industrial telemetry pipeline work plus solo LLM product operations.
Target use: Robot-manufacturing foundation-data systems and existing-manufacturing AI workflows.
Transfer path: Apply the proven P1/P2/P3 primitives to foundation data, QC telemetry, and operator-team RAG workflows.

Dual-purpose data substrate — the same store serves production reads (inference, dashboards, alerts) and batch exports for training (RLDS, Parquet, MCAP).

6a — Robot manufacturing & foundation-model training data

P1P2P3
Imitation-learning data pipeline
Teleop demos → automatic builds in RLDS / Parquet / MCAP training formats — the standards public corpora such as Open X-Embodiment ship in. Multi-source time alignment (vision · proprio · action · language) → quality filtering → segmentation → augmentation. Data quality at training time is the model’s ceiling; lifting that ceiling is the pipeline’s job. (deps: P1 + P2 + P3)target area
P2
Sim-to-real telemetry bridge
Reconciling simulator output vs real-robot telemetry on time, units, and distribution. Domain-randomization parameter distributions sourced from measured data automatically. Reality-gap metric dashboards. Sim-to-real failures are almost always alignment failures. (deps: P2)target area
P2P3
VLA foundation-data curation
Vision-Language-Action triplet sync, mining-ratio control across failure / success, automatic long-horizon segmentation. Splitting language instructions into semantic units + the cost / safety / iteration loop of LLM ops are exactly what untamedai.me handles daily. (deps: P2 + P3 + LLM product ops)partially transferred
P2P3
Robot-line QC telemetry
Per-station measurements as a robot traverses the line + post-ship field telemetry, joined causally. End-of-line QC → field-failure traceability as one system. (deps: P2 + P3)designed, not built

6b — Existing-manufacturing AI workflow

P1P2P3
Line-telemetry substrate
A unified telemetry pipeline across multi-vendor PLC + OPC-UA + MTConnect for semiconductor / steel / cell / display lines. Production ops and model-training data on the same substrate. (deps: P1 + P2 + P3)
P2
Cycle-level quality prediction
Machine-telemetry time-series → predicted end-of-line inspection results. Gradient-boosting baseline → Temporal Fusion Transformer / Patch-TST. Cycle-definition alignment in time is harder than the model itself. (deps: P2)
P3
Line-assistant LLM
A natural-language interface for operators — “what caused the line-3 alarm at 02:00 last night?” style RAG over machine logs + SOP + history. Having owned this kind of LLM system end-to-end (§5 untamedai.me) ports directly into the line-assistant problem. (deps: P3 + LLM product ops)
P2P3
Anomaly localization
Which machine on the line is the source of the defect? SHAP-based contribution decomposition, drift monitoring, training-distribution guards. (deps: P2 + P3)

Engineering Practice

Working posture

How I work — process signal. From running untamedai.me solo and from team work on industrial data systems, I have learned that how you work matters as much as the result. Three working postures.

AI review loop in production work

On untamedai.me FastAPI backend and Next.js UI changes, AI is used as a first-pass reviewer for API boundaries, null states, and cost paths. The final merge call and operating accountability stay human, with AI output treated as something to audit.

Signal. Use AI to widen the review surface, then own the production decision.

Operator mindset

Running untamedai.me solo forces daily trade-offs — for example, accept a higher token cost on safety-critical Korean moderation calls and pull it back on low-stakes turns.

Signal. Operator mindset — model, system, user, and cost held in view at the same time.

Transferable systems practice

The same operating pattern shows up in both shipped systems: define data boundaries, normalize unreliable inputs, make failure recovery explicit, and keep cost / safety / user impact visible.

Signal. Industrial telemetry and LLM product ops are not separate stories here; they are the same systems discipline applied to different surfaces.

Tech Stack

Stack map

Stack used on the industrial vehicle fleet, mapped to the equivalents that port into robot manufacturing and traditional manufacturing. Production code is under NDA.

Ingestion / Bus	Industrial Fleet: Django · Flask webhook → Robot · Mfg: ROS2 · DDS · Kafka · OPC-UA · MQTT
Time-series store	Industrial Fleet: InfluxDB → Robot · Mfg: TimescaleDB · ClickHouse · MCAP
Metadata DB	Industrial Fleet: MySQL → Robot · Mfg: PostgreSQL
Distributed task	Industrial Fleet: Celery + django-celery-beat → Robot · Mfg: Celery · Airflow · Dagster · Ray
Single-node / distributed compute	Industrial Fleet: single-node multiprocessing → Robot · Mfg: Ray · Dask when distributed execution is required
Replay format	Industrial Fleet: Avro → Robot · Mfg: MCAP · Parquet · RLDS
Storage	Industrial Fleet: GCS → Robot · Mfg: S3 · Azure Blob
LLM stack (untamedai.me)	Next.js (frontend) · Python FastAPI (backend) · Supabase + PostgreSQL (DB) · Cloudflare (hosting) · Claude Opus + GPT 5.x (LLM) · Polar payments (flow built & validated, no transactions yet) → Foundation-model data / VLA / RAG

Imitation-learning data pipeline

Sim-to-real telemetry bridge

VLA foundation-data curation

Robot-line QC telemetry

Line-telemetry substrate

Cycle-level quality prediction

Line-assistant LLM

Anomaly localization

AI review loop in production work

Operator mindset

Transferable systems practice