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 maintains a probabilistic model of your system's current state — many weighted hypotheses running in parallel, each representing a plausible explanation of what your sensors are reporting. When new data arrives, hypotheses that explain it well gain weight; those that don't lose it.
The engine then asks: "Where am I most uncertain? What measurement strategy would reduce that uncertainty the fastest?" This is a control-theoretic approach to monitoring — the system actively decides where to focus attention, rather than passively waiting for readings to cross a line.
Problems tend to emerge in the regions where the model is most uncertain. 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
Starts with broad uncertainty and refines 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 graded confidence levels that reflect genuine uncertainty about system state, works from the first reading without training data, and surfaces problems by design in the areas where it knows the least — exactly where new failure modes tend to appear.
Performance
NOBU's inference engine is implemented in C++ and 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), 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.