Skip to content
Jose RubioES
All work

Case study 02 / 17Data Science

A wear and remaining-life digital twin for a slurry pipeline

Charges every operating excess to the pipe in days of life, per segment and per minute; built by a 30-agent AI team under my guardrails.

Stack

  • TypeScript
  • Node.js
  • InfluxDB
  • Flux
  • Playwright
  • Claude Code
  • PowerShell

01 · How it works

  • TodaytoChanged in this work
  • Data flow

What it does

A wear and remaining-life model for a long-distance slurry pipeline that turns what the hydraulic model already computes into what the asset pays: every minute, every 100 m segment is classified into one of seven flow regimes and charged that regime's wear. Wear inside the agreed operating window is base; anything outside it is extra, charged to operations in days of life, with corrosion and transient fatigue kept as separate clocks.

Read more

I designed the method and governed the autonomous team of AI agents that built the first version: an engine, a per-segment ledger, an API and a 3D viewer.

5 connections· select a part to trace it
  1. 1D hydraulic model to Read-only data copy: flow, pressure, batches
  2. Read-only data copy to Regime + wear engine: one value per minute
  3. Regime + wear engine to Segment-day ledger: base + extra, in days
  4. Segment-day ledger to Local read-only API: reproducible, hashed
  5. Local read-only API to 3D margin viewer: stretch, date compare

02Results

  • R01Higher is better

    Flow regimes the wear law tells apart

    Before 1, after 7, 7× higher. Higher is better.
    Before
    After
  • R02Lower is better

    Ways the agent team could write outside the project

    Before 11, after 0, eliminated. Lower is better.
    Before
    After
  • R03Lower is better

    Agent errors per 100 tool calls

    Before 6.7, after 2.4, 2.8× lower. Lower is better.
    Before
    After

What it achieved

  • Wear accounting: one rate for the whole line → seven flow regimes per segment per minute, with base and extra in days of life
  • Asset life: one clock → two, wear plus corrosion and transient fatigue; the first to run out governs
  • Per-minute compute: a GPU kernel per event → plain formulas on a CPU, seconds per day of data
Read more
  • First version: a design document → an engine, a 12-day ledger of 56 fields per segment-day, an API and a 3D viewer, with 546 tests passing
  • Team safety: 11 ways to write outside the project → 0, behind a fail-closed guardian passing 72 of 72 test cases
  • Team reliability: 6.7 → 2.4 errors per 100 tool calls, after each denied command was written into the rules as a trap

The challenge

Wear on a slurry pipeline accumulates in microns per month, invisible to any single inspection, so operations never learn what an overspeed, a dense batch, a slow restart or running near the deposition velocity costs the pipe. The initial proposal I reviewed implied a wear rate 1,300 to 4,000 times what steel plausibly loses in this service, and it placed each event at the sensor, although a change in flow reaches the whole line within minutes.

Read more

Its GPU kernel fed identical inputs to every point, so every result was the same.

The data proved harder than the physics: a field the code suggested held velocity per point did not exist when measured live, two system codes had been conflated, and the lab server turned out to run a simulation, not the plant.

What I learned

Days of life are the right unit before calibration: they add up, need no thickness measurement and make a month of microns readable. Millimetres come only after in-line inspection and ultrasonic readings, so the first version labels every view as simulation data and uncalibrated, and its calibration code refuses simulation ledgers.

Read more

Measure the data, not the code: a field the code promised was not there. Running an AI team for days taught me that guardrails beat permissions. I wrote each denied command into the rules instead of loosening the guardian, and kept the decisions that matter, such as which system and which operating ranges, with a person.

Stack

  • TypeScript
  • Node.js
  • InfluxDB
  • Flux
  • Playwright
  • Claude Code
  • PowerShell

Skills

  • Slurry hydraulics and wear modeling
  • Asset integrity and remaining life
  • Fatigue and transient analysis
  • AI agent orchestration
  • Guardrail and hook design
Cover picture for A wear and remaining-life digital twin for a slurry pipelineCover picture for A wear and remaining-life digital twin for a slurry pipeline