RotorNote

Hear the machine before it stops — locally on Arm.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for RotorNote

Inspiration

Industrial vibration analysis usually starts with a physical sensor and ends with a maintenance decision, but the useful middle is often split across heavyweight software, cloud services, and opaque model outputs. RotorNote asks a narrower question: can a small, local Arm system turn an attributed vibration capture into an honest first-pass screen, a concrete retest, and evidence that survives the handoff into maintenance?

What it does

RotorNote accepts real vibration CSV data plus the measurement context that order-aware analysis actually requires: sample rate and measured RPM. One channel enters a broad variable-speed anomaly screen. Four synchronized channels unlock a narrower fault-family specialist. The canonical /api/screen route chooses the contract from the evidence supplied instead of pretending a one-channel anomaly score is a field diagnosis.

Both routes run independent FP32 and INT8 engines, enforce signal-quality and fitted-envelope checks, and return review_required on uncertainty, unsupported RPM, or engine disagreement. A successful screen produces a retest instruction, a tamper-evident evidence passport, and a deterministic advisory work order. The included maintenance adapter signs the exact JSON, retries transient failure with one idempotency key, proves that replay creates only one downstream object, and rejects a tampered body.

The browser interface, HTTP API, compiler endpoint, sample captures, tests, model artifacts, SBOM, benchmark harness, and native Arm receipts are all in the public repository. It runs locally with Node.js 22 and requires no account, API key, or remote inference service.

How we built it

The primary workload is a fitted-unit-pruned 96→609→326→120→8 ReLU network trained from 2,925 real CC BY UPATRAS signals spanning 39 complete measurement sequences and 75 speeds. It performs 297,078 MACs per inference. Four-fold evaluation holds out whole measurement sequences; no speed signal or derived window from a held sequence enters training.

The optimized model uses row-wise INT8 weights and a dynamically planned WebAssembly SIMD runtime. Learned bytes fall from 1,192,564 to 307,484, a 74.22% reduction, while preserving every eight-condition label across the full 2,925-signal bank. On the exact committed graph running on a native Arm Neoverse-N2 GitHub runner, the optimized path measured a 3.3124× paired median speedup with a 95% bootstrap interval of 3.3070×–3.3186×. Local x64 timing is never promoted into an Arm claim.

The secondary 48→4 linear specialist uses four synchronized sensors from a separate CC BY physical rig. It remains because its interpretable fault-family output is useful, but its 192-MAC benchmark is explicitly disclosed as call-overhead sensitive. The submission leads with the materially nonlinear 297,078-MAC head rather than using the tiny model to inflate the optimization story.

RotorNote also exposes the deterministic dense-model compiler through /api/compile. It emits downloadable FP32 and INT8 artifacts, utilization and byte-reduction reports, hashes, and a parity result. The product rebuild cross-checks those compiler bytes against both shipped production models.

Challenges

The hardest problem was not producing a prediction. It was preventing a laboratory result from becoming a dishonest field claim. We changed the evaluation boundary from random windows to entire held physical tests or measurement sequences, preserved a complete misalignment failure, and ran three external datasets through the real one-channel route. Those external datasets include two independent seeded-fault rigs and the NASA IMS natural run-to-failure archive.

Every external case currently abstains with review_required. That is useful evidence that the deployment envelope fails closed, but it is not cross-rig sensitivity evidence, and we say so. A nested calibration audit also failed to establish the desired selective-accuracy guarantee. The interface therefore treats model scores as uncalibrated and exposes the observed risk/coverage tables instead of presenting confidence as probability.

The other major challenge was separating product performance from benchmark theater. The native workflow rebuilds the exact graph, runs the complete product and maintenance paths, and reports the real model-call timings. A separate vdotq_s32 witness measures scalar versus NEON compute from 16 through 16,384 MACs, requires exact equality, and is clearly labeled as a witness the product never invokes.

Accomplishments

  • A complete local Physical AI path from real vibration capture to advisory maintenance work order.
  • 39/39 whole-sequence results on the broad development corpus, with the Wilson interval disclosed.
  • 74.22% fewer learned bytes and 100% full-bank label agreement for the primary INT8 model.
  • 3.3124× paired median speedup on the exact model graph on native Arm Neoverse-N2, with raw samples and a bootstrap interval.
  • A reusable, working FP32-to-INT8 dense-model compiler and layer-count-independent WASM memory planner.
  • Native Arm CI that rebuilds, tests, validates, secret-scans, exercises both public routes in a hardened container, and proves the signed/idempotent maintenance loop.
  • Independent pinned Syft, Grype, and npm-registry verification plus a deterministic in-repository SBOM.
  • Explicit failure disclosure: no synthetic production faults, no hidden misalignment miss, no calibrated-confidence claim, no certification claim, and no claim that an external abstention test proves diagnosis.

What we learned

Optimization evidence is strongest when the workload, artifact, runtime, and machine are bound together. A speedup number without the exact graph and raw native samples is weak; a small model can make call overhead look like compute acceleration; random-window validation can leak the same physical experiment into both train and test; and a safe field boundary may be more valuable than a confident answer outside the model's evidence.

We also learned that developer experience is part of safety. The shortest judge path exercises both model contracts, the compiler, malformed input, evidence export, and the real HTTP maintenance loop in about two minutes.

What's next

The next step is a prospective pilot with fixed sensors and operating procedures: collect baseline captures, freeze thresholds before observing faults, compare alerts with qualified analyst findings, and measure abstention, false-alert burden, drift, and lead time. RotorNote is not certified, not a shutdown controller, and not a diagnosis. The goal is to earn a larger operating envelope with evidence rather than claim one in advance.

Setup and validation

git clone https://github.com/equinoxaifinance-rgb/rotornote-arm-ai.git
cd rotornote-arm-ai
npm ci --ignore-scripts --no-audit --no-fund
npm run build
npm test
npm start

Open http://127.0.0.1:8787. Select Variable-speed anomaly and screen it, then select Rotor imbalance and screen the second contract. Click Compile example head to exercise the developer kit. Run npm run proof:maintenance-loop to execute the attributed capture → canonical screen → signed work order → authenticated reference sink path over real local HTTP, including replay deduplication and tamper rejection.

Share this project:

Updates