🤖AI & Predictive Maintenance

What the AI engine actually does

Myncel ships a built-in anomaly-detection and predictive-failure engine that runs on top of every sensor reading you log — manually, via the Edge Gateway, via OBD-II / J1939 / NMEA 2000 / MAVLink, or via a telematics importer. It is on by default for every workspace and you do not need to install or configure anything else. The engine has two jobs: spot readings that look statistically unusual for that specific machine and that specific sensor, and project simple linear trends forward in time so you get a heads-up days before a value would cross a critical threshold.

The engine is intentionally transparent. Every detection records the baseline mean, the rolling standard deviation, the EWMA-smoothed value, the threshold that was crossed, the sigma multiple, the severity, and a plain-language recommendation. Every forecast records the predicted crossing date, a confidence percentage derived from the regression's R², and the horizon used. Nothing is a black box — you can always click into a detection and see exactly why the engine flagged it.

• Anomaly detection — rolling z-score plus EWMA (λ = 0.3) over the last 30 samples per sensor. Flags the latest reading when its absolute deviation exceeds the configured sigma threshold, or when a custom warn / critical threshold is crossed.
• Predictive forecasting — least-squares linear regression over the last 30 days per sensor. Projects forward up to your configured horizon (default 14 days) and emits a forecast when the trend is on track to cross a critical level.
• Severity grading — sigma-ratio based: ≥ 2.0× threshold is CRITICAL, ≥ 1.5× is HIGH, ≥ 1.0× is MEDIUM, anything below is LOW. Same scale across every sensor type and every domain.
• Dedup window — 5 minutes per machine + sensor type, so a noisy reading that hovers around a threshold does not generate dozens of duplicate alerts.
• Forecast TTL — 24 hours. Forecasts auto-expire and the engine regenerates them on the next run, so you never see stale predictions on the dashboard.

The three AI models

Myncel offers three model kinds. They all use the same statistical core; what changes is how much extra context is layered on top. You pick the model once at the workspace level under Settings → AI & Predictive, and you can override it per-machine on the equipment page.

• Statistical (default) — pure rolling z-score + EWMA + linear regression. Deterministic, explainable, fast, no external API calls. This is the right choice for 95% of workspaces and is the only model we recommend leaving on for safety-critical equipment.
• Hybrid — same statistical core, but the recommendation text is enriched with rule-based context (sensor type, asset category, recent work orders on the same asset). Still fully local, still no external calls, just smarter wording on the alert.
• LLM-Assisted — adds a sanity-check pass through a language model before an alert is published. The LLM cannot create or suppress alerts on its own; it only annotates them with extra reasoning. Use this only if you have a heavy false-positive problem that sensitivity tuning has not solved. Custom instructions become available when this model is selected.

Sensitivity, severity, and quiet hours

Sensitivity is a single 0 → 100 slider that maps linearly onto a sigma threshold. The math is intentional: 0 means "only fire on extreme outliers" and 100 means "fire on any small deviation". The default of 50 corresponds to 3σ, which is the standard SPC (statistical process control) threshold and is what you want for almost every sensor.

• 0 → 5σ — silent. Practically nothing fires. Use this only when you are commissioning a new asset and want to suppress alerts.
• 50 → 3σ — SPC standard. Default. About 0.27% of normal readings trip this naturally, which is the right rate for most production sensors.
• 100 → 2σ — paranoid. About 4.5% of normal readings trip this. Useful only on extremely stable, well-instrumented assets where you genuinely want to chase every wobble.
• Minimum severity — independent of sensitivity. Even if the engine detects an anomaly, no alert is published unless the severity meets or exceeds your floor. Most workspaces set this to MEDIUM.
• Quiet hours — a UTC window during which alerts are queued silently and delivered at the next active hour. Useful for workspaces that do not run 24×7 and do not want overnight pings on a non-critical pump.
• Auto-create work orders — when on, every CRITICAL detection auto-opens a work order assigned to the machine's default technician. Off by default; turn it on once you trust the false-positive rate.

Per-machine overrides

Every machine has its own AI tab on the equipment detail page. By default, every field on that tab is set to "inherit from organization" — null in the database — so a workspace-level change automatically applies everywhere. When you flip an override on, only that field is overridden; everything else keeps inheriting. This is how you tune sensitivity for a single noisy asset without affecting the rest of the fleet.

• Custom thresholds — for a specific machine, you can set explicit warn / critical values per sensor type that override the statistical engine entirely. Useful for sensors with a regulated red line (battery voltage, hydraulic pressure, vessel exhaust temp).
• Per-machine model — you can run a single high-value asset on LLM-Assisted while leaving the rest of the fleet on Statistical.
• Per-machine quiet hours — not currently overridable per machine; set once at the workspace level. On the roadmap.

1. Open the equipment detail page for the machine you want to tune.
2. Click the 🤖 AI tab.
3. Read the "Effective settings" card at the top — this shows what the engine will actually use for this machine right now (your overrides plus inheritance).
4. Toggle the override switch next to any field you want to change. The control becomes editable.
5. Pick a new value, or leave the override off to keep inheriting.
6. Click Save. The change takes effect on the next engine run, or immediately if you click "Run engine now".
7. Add a note in the Notes field — future-you will appreciate knowing why this machine has a custom sensitivity.

The confirm/reject feedback loop

Every detection lands in a feed on the equipment AI tab with three possible states: PENDING, CONFIRMED, or REJECTED. When a technician confirms a detection, you are telling the engine "yes, this was a real problem". When they reject it, you are telling the engine "false positive". This feedback is recorded against the detection and powers a rolling false-positive rate shown on your workspace AI dashboard.

Today the feedback is not used to retrain the model — the statistical core does not need training data. It is used for visibility: if your workspace is rejecting more than 30% of detections, the AI dashboard surfaces that and recommends lowering sensitivity. Future models may consume this feedback for fine-tuning; the data is being collected so that path stays open.

• PENDING — the default state. A detection has been published as an alert but no human has weighed in yet.
• CONFIRMED — a technician opened the detection, agreed with it, and clicked Confirm. Counts as a true positive.
• REJECTED — a technician opened the detection, disagreed, and clicked Reject. Counts as a false positive. The associated alert is automatically dismissed.

Running the engine

The engine runs automatically every time a new sensor reading is ingested, and additionally on a 15-minute background sweep across every machine in every workspace. You can also trigger it manually from Settings → AI & Predictive (workspace-wide) or from any equipment AI tab (single machine). A manual run is useful right after you change sensitivity or thresholds and want to see results immediately rather than waiting for the next sweep.

• POST /api/ai/detect — runs the engine across every machine in the workspace. Returns counts of machines scanned, machines skipped because AI is disabled on them, detections created, and forecasts created.
• POST /api/ai/detect/[machineId] — runs the engine for a single machine. Same response shape.
• GET /api/ai/detect/[machineId] — returns the last 50 detections plus all currently-active forecasts for the machine.
• POST /api/ai/feedback/[detectionId] — accepts { feedback: "CONFIRMED" | "REJECTED" } and updates the detection.
• GET / PATCH /api/ai/settings — workspace-level settings (OWNER / ADMIN only for PATCH).
• GET / PATCH /api/ai/settings/[machineId] — per-machine overrides (OWNER / ADMIN / TECHNICIAN can edit).

Costs and limits

The Statistical and Hybrid models add zero cost — they run inside the same Node process that serves the rest of Myncel and use no external APIs. The LLM-Assisted model is metered: each anomaly that is post-processed by the LLM consumes one inference call, and inference calls are counted against your monthly plan limit. Workspaces on Starter and Pro plans get 500 LLM calls/month included; Growth gets 5,000; Enterprise is uncapped. The current count is shown at the bottom of Settings → AI & Predictive when LLM-Assisted is selected.