Embedded intelligence for telematics

Turn motion your telematics hardware already captures into a risk signal.

Scapton builds small intelligence features that run directly on telematics devices. The first one is near-collision detection: accelerometer, gyroscope and speed data go in, an evasive-driving event comes out — for insurers and telematics platforms that already own the hardware.

Explore a pilot See how it works

C99 · INT8 · no NPU required · bare metal / FreeRTOS / Zephyr

near_collision.featureillustrative

accel xyzgyro xyzspeed

normalnear misscrash

Confidence

0.91

Severity

High

event ready for customer risk model

Illustrative signal flow, not a claim about measured model accuracy.

01Telematics hardware manufacturersAdd a differentiated capability to hardware you already ship, without a new hardware platform.
02Telematics platformsOffer customers a richer behavioral signal than harsh-event counts, on devices already in the field.
03Insurance telematics providersFeed a new behavioral signal into risk models you already run. You keep the scoring logic.
04Automotive insurersSee whether telemetry reveals meaningful risky behavior before it becomes a claim.

The problem with thresholds

A threshold tells you one number crossed a line.

Harsh-brake counters fire on a single value: deceleration above a cutoff. That value alone cannot tell a genuine evasive maneuver apart from a pothole, a bad sensor mount, or normal city traffic. Scapton looks at the shape of the whole motion sequence instead of one peak.

conventional telematics

accel > threshold

HARSH BRAKE

One signal, one cutoff, one event class.

scapton

accel xyz + gyro xyz + speed

motion over time

evasive-driving pattern

NEAR COLLISION

confidence: 0.91

Multiple signals, a temporal pattern, a graded event.

NHTSA's 100-Car naturalistic-driving study logged 761 near-crashes against 69 fully analyzed crashes — near-collision events occur far more often than the losses they precede.NHTSA study (PDF)

Product hypothesis

Two drivers, zero crashes, very different risk.

A driver can avoid every crash and still repeatedly create dangerous situations. Claims history alone treats both drivers the same. Near-collision frequency and severity may not.

Hypothesis — not yet validated against claims outcomes

This is what Scapton is built to test, not a result it has already proven. Scapton exposes the near-collision signal; the insurer or platform decides how — or whether — it affects pricing, underwriting, alerts or coaching. Scapton does not make pricing or underwriting decisions.

In one Swiss Re study, combining telematics with traditional variables produced 12–13× decile lift in claim-frequency separation, versus 6–8× for traditional variables alone — independent evidence that richer telematics signals can sharpen risk separation.Swiss Re report (PDF)

Driver A500 trips · 0 crashes · 1 near-collision

Driver B500 trips · 0 crashes · 27 near-collisions

Claims history: A ≈ B
Richer behavioral signal: A ≠ B

Integration

Ships like an ordinary embedded C library.

Training, quantization and model conversion happen on Scapton's side, before deployment. The customer initializes a struct, feeds it samples, and reads a result — the same shape as any other embedded C library.

near_collision.cillustrative API

nc_ctx_t ctx;
nc_init(&ctx, &config);

while (running) {
  nc_result_t result;
  nc_process(&ctx, &sample, &result);
}

result.classNEAR_MISS

result.confidence0.91

result.severity—

Not installed on the device

PyTorch
TensorFlow
ONNX
Python
quantization tooling
NPU compiler

Those tools stay on Scapton's development side. The customer does not need ML expertise to integrate the feature.

Distribution

Most of what's needed is already deployed.

Telematics hardware already in the field typically contains an MCU, GNSS, an IMU, a cellular modem, and sometimes CAN. Scapton adds a new capability in software, without a new hardware platform.

existing device

GNSSIMUCAN (sometimes)

MCU

SCAPTON FEATURE

richer signal

Compatibility with a specific device is validated case by case, not assumed.

Why run locally

Raw sensor data: stays local where appropriate
Cellular traffic: reduced
Connectivity: not required for inference
Latency: local
Existing MCU: usable
NPU: not required

Edge inference is not used because it's fashionable — it's used where local processing gives a concrete product advantage.

Architecture

Complex before deployment. Small on the device.

Scapton separates the machinery needed to build an embedded model from the code needed to run one. Customers integrate the generated feature; the training stack stays off-device.

Training side

development environment

Training dataset
Training + validation
INT8 quantization
embedded-ml-toolchain

generated C

Device side

resource-constrained MCU

Sensor inputs
embedded-ml-runtime
near-collision feature
Event signal

embedded-ml-toolchainowns model export, quantization, validation and generation of embedded-friendly C.

embedded-ml-runtimeowns the small reusable C99 inference runtime: tensors, static memory, preprocessing and generic kernels.

near-collisionis the first feature repository built on top of both.

Deployment target

Language: C99
Inference: INT8 first
Memory: static / predictable
Heap: not required
OS: optional
Bare metal: yes
FreeRTOS: target
Zephyr: target
NPU: not required
CPU backend: baseline, always available

A generic CPU implementation is the baseline. Optimized backends such as CMSIS-NN or future NPU integrations may be added, but they are not required for correctness.

Validation

Accuracy on one dataset is not enough.

A model can score well on the data it trained on and still fail on a different vehicle, sensor mount, or road surface. Cross-dataset validation exists to check whether the model learned a real physical signature of evasive driving — or just artifacts of one dataset.

training dataset
train
hold out unseen vehicles
freeze model
independent dataset
domain-shift measurement
generated C
real MCU

Most important near-term metric

false positives per driving hour

A model that catches most near-misses but keeps false-alerting is not a commercially useful telematics feature. This number has not been published because it has not been measured against real-world driving hours yet — it is the gate before any pilot, not a claim.

Also tracked

near-miss precision
near-miss recall
crash recall
confusion matrix
unseen-vehicle performance
cross-dataset performance
flash usage
peak RAM
inference latency

Maturity

What's built, what's being validated, and what needs a customer.

Building now
- embedded-ml-runtime
- embedded-ml-toolchain
- near-collision feature training
- training dataset pipeline
- embedded deployment work
Validating
- unseen-vehicle generalization
- cross-dataset stability
- false positives per driving hour
- hardware portability
Requires customers / real deployment
- telematics field validation
- different real IMUs and mounting configurations
- insurance outcome correlation
- actuarial usefulness

No claim is made that near-collision scoring predicts insurance losses better than existing telematics metrics. Scapton has no production telematics deployments today, and has not validated portability across arbitrary hardware. This page describes current work, not finished outcomes.

Future feature IP

Where the same architecture could go next.

Only after near-collision proves useful does the same runtime and toolchain extend to other signals. These are directions being considered, not products available today — near-collision is the only feature in active development.

Driver identity / fingerprint confidenceKeep driving-risk history tied to the right person across shared and multi-driver vehicles.
GNSS trust / spoofing detectionFlag unreliable or manipulated positioning data before it reaches a downstream decision.
Battery no-start predictionFlag rising no-start risk early, ahead of avoidable roadside events and downtime.
Vehicle integrity signalsCross-signal anomaly detection for sensor, installation and vehicle issues.

Pilot

Explore a pilot.

Test near-collision intelligence against telemetry from hardware you already run. Tell us what you're working with and we'll follow up directly.

A focused conversation about integration, hardware fit and pilot scope.
An email address is enough. Everything else is optional.
No newsletter, no ads and no automated risk decisions.

Prefer email? Write to paulius.ragauskas@scapton.com. Read the privacy notice for what we store and how to have it deleted.