Technology
For engineers and technical decision-makers who want to understand what makes NOBU different — without the marketing.
The short version
NOBU is not machine learning. It's not anomaly detection. It doesn't learn "normal" from historical data and flag deviations.
Instead, NOBU reasons about what your system is doing right now. It maintains competing explanations of your sensor data simultaneously, each weighted by how well it accounts for what the sensors are actually reporting. As new data arrives, the picture sharpens automatically.
The engine actively decides where to focus attention, rather than passively waiting for readings to cross a threshold. It finds problems precisely where conventional monitoring has blind spots — before they become alarms.
Problems tend to emerge in the places conventional monitoring isn't looking. By the time readings cross a conventional threshold, NOBU has usually been tracking the drift for some time.
No training phase
Typical ML approach
Collect weeks or months of labeled data. Train a model offline. Deploy it. Hope the production distribution matches training. Retrain when it doesn't.
NOBU
Works immediately from the first reading. No labels needed. No offline training. New equipment, post-maintenance changes, and novel failure modes are handled naturally.
This matters in practice because industrial environments change constantly. Maintenance schedules, load patterns, seasonal variation, equipment swaps — all invalidate models trained on historical data. NOBU's approach is immune to this because it never assumed a fixed baseline to begin with.
Why not neural networks?
Neural networks are excellent at pattern recognition in high-dimensional data — images, language, genomics. For time-series monitoring of physical systems with 4–10 sensor channels, they're typically overkill and bring significant downsides.
They need labeled failure examples to learn from (rare in most facilities). They produce point predictions rather than calibrated uncertainty. They degrade silently when conditions drift from training data. And they're opaque — when they flag something, you can't easily understand why.
NOBU's approach produces calibrated risk assessments rather than binary alerts, works from the first reading without training data, and finds developing problems before they become threshold-crossing events — exactly where new failure modes tend to appear.
Performance
NOBU's inference engine runs sub-second on standard cloud infrastructure. Compute runs inside AWS Nitro Enclaves, which provide hardware-enforced isolation — encrypted memory that even the cloud operator cannot access. This protects both the inference engine and your sensor data.
Fast inference
Each decision completes in milliseconds. Fast enough that compute cost per reading is negligible at any practical sampling rate.
Hardware-enforced security
AWS Nitro Enclaves provide attestable, encrypted compute. Your sensor data and NOBU's inference engine are protected by hardware, not just software.
Scales with you
Compute spins up on demand and shuts down when idle. You pay for what you use. No always-on GPU clusters.
Standard sensors
Works with whatever sensors you already have — Modbus, serial, UPS, ACPI. No proprietary hardware lock-in.
Integration
For dashboard services (PowerSense, Predictive Maintenance), install the NOBU agent on a device connected to your sensors. The agent reads sensor data at a configurable rate, batches it, and forwards it securely to the NOBU API. Your dashboard shows live results.
The agent is a lightweight Python service that runs on Linux (systemd), Windows (NSSM service), and macOS (launchd). Configuration is a single YAML file: set your API key, choose your sensor backend (NUT, Modbus, serial CSV, or ACPI), and start the service.
For API services (Control, API Fuzzing, Anti-Distillation), call the REST API directly. Send a JSON payload with your system state, get back a decision with confidence levels and recommended actions. See the docs for endpoint details.