CASE STUDY / 06

Applied AI · Mechanical reliability · Evidence-linked reasoning

Mechanical Evidence Engine

A mechanical-investigation workspace that connects engineering evidence, deterministic calculations, and an AI-guided investigation to the next useful physical test.

Client
Rolu Labs
An engineering product built by Rahim Iqbal and demonstrated at Hacker Cottage.
Status
Controlled pilot · Deployed August 2026
Engineering workflow
From machine symptoms to a testable investigation
01 / Constraint

The client problem

A pump, motor, or bearing problem rarely arrives as a clean question. Measurements, maintenance notes, manuals, and competing explanations need to be considered together. A plausible answer is not enough: the engineer needs to see its evidence, what remains uncertain, and which observation would distinguish the remaining causes.

02 / Deployment

What we built

Rahim built a continuing investigation workspace around structured equipment identity, observations, competing failure hypotheses, and next-test state. The implementation combines document retrieval, deterministic mechanical calculations, AI-assisted synthesis, and an interactive equipment view that links the reasoning back to evidence. The application was deployed on Railway with PostgreSQL and persistent file storage.

03 / Evidence

What changed

The deployed application brings intake, investigation, calculations, and evidence review into one workflow. Engineers can examine the reasoning, continue the investigation as observations arrive, and record physical findings. Rahim demonstrated the pump-diagnosis workflow at Hacker Cottage in August 2026.

Deployment is documented in the August 2026 release record. The live application is an access-controlled pilot, not evidence of customer adoption or validated plant performance. Engineering decisions remain human-supervised: a diagnosis is not confirmed by model confidence alone. Development benchmarks are not a claim of field accuracy or autonomous maintenance readiness.

Reasoning that can be inspected

Measurements, source passages, and calculations retain distinct provenance. The workspace preserves evidence snapshots and tool inputs so an engineer can inspect what a result depends on instead of treating generated prose as authority.

Engineering tools, not guessed arithmetic

Versioned tools cover rotating-equipment calculations such as shaft and bearing frequencies, gear mesh, pump affinity, NPSH margin, thermal growth, and first-pass signal analysis. Their assumptions and inputs remain part of the investigation record.

A clear boundary for confirmation

Competing mechanisms stay open when evidence is insufficient. The next observation is chosen to help distinguish them, and a confirmed root cause requires physical inspection or a comparable corrective intervention. The equipment view is a reasoning aid, not CAD or a validated digital twin.

From request to a durable evidence record

A FastAPI endpoint loads the investigation and hashes attachments. Retrieval selects published, tenant-permitted evidence; registered tools calculate explicit numeric inputs. The model proposes a structured next turn, the server validates it and enforces the confirmation boundary, and PostgreSQL retains the result with its evidence and tool records. A deterministic mapper produces the equipment view without accepting model-authored geometry.

What the verification actually covers

On September 8, 2026, a clean source snapshot passed 47 automated tests and 16 known-answer calculation checks. Five synthetic, model-off continuity scenarios also passed their development rubric, including an underdetermined equipment case that must not invent bearing geometry. These results test software behavior, arithmetic, and conservative fallback—not live-model quality or field diagnostic accuracy. The dated verification record below gives the source revision, commands, measured outputs, and limits.

Failure modes and unfinished work

When model synthesis is unavailable, the workspace labels its output evidence-only. Insufficient equipment identity must not become an OEM-specific conclusion, and a plausible diagnosis must not become confirmed without physical evidence. The pilot still needs blinded plant-case evaluation, enterprise identity controls, and operational hardening before broader production use. Deployment availability is not customer adoption.

PUBLIC EVIDENCE / 03

Evidence from the work.

DOCUMENTATION STATUS

The public Hacker Cottage builder listing includes Rahim's pump-diagnosis demonstration. Deployment and software verification are separate from validation on real plant cases.

Read the dated verification record
Executed checks, source revision, reproduction commands, and explicit evaluation limits. No customer records or access credentials are included.

Open the deployed application
Live controlled pilot. An access token is required to run investigations; the public entry screen is available without one.

Rahim Iqbal at Hacker Cottage
Builder profile and the public pump-diagnosis demo from the August 2026 weekend.