Detection models

Detection is deterministic statistics, running hourly on your own hardware against your own data. There is no cloud model, no shared baseline, and no signature subscription. The optional language model explains incidents; it does not detect them.

The five detectors

Detector	Asks
rarity	Has this device ever done this before?
beaconing	Is this contact suspiciously regular?
robust_baseline	Is this hour unlike this device’s usual hours?
scan	Is this device probing?
peer_isolation	Is this device behaving unlike devices that behave like it?

rarity

First time this device reached this destination, this domain, this port, this TLS fingerprint, this user agent. Tracked per device and per network.

Rarity is the strongest single signal in a small network, because a home network is deeply repetitive: a camera talks to three places, forever. It is also the loudest, which is why it has the longest prior-observation requirement of any detector.

beaconing

Regularity of the intervals between a device’s contacts with one destination. The measure is the coefficient of variation of those intervals: a human browsing is irregular, a scheduled check-in is not, and malware calling home is very much not.

robust_baseline

Per device, per hour-of-week: bytes, flow count, destination count. The statistics are robust — median and median absolute deviation rather than mean and standard deviation — so one enormous backup does not raise the threshold for the next month. Deviation is reported as a z-score.

scan

Unique destination ports contacted within a short window. This is the one detector that is closer to a rule than a baseline, and deliberately so: there is no normal amount of port scanning.

peer_isolation

Devices are clustered by behaviour — services, destinations, volumes, times — and a device that sits far from its own cluster is flagged. An isolation-forest score over hourly features per group.

This is the detector that partly replaces manual device typing: you do not have to tell Nyxtrace that these eight things are cameras, because they behave like each other.

The shipped model set

A model is a detector plus parameters plus a base score. This is the set that ships:

Model	Detector	Severity	Base score	Fires when
rare_destination_v1	rarity	medium	45	A destination not seen in the prior 14 days
periodic_destination_v1	beaconing	high	65	≥ 5 intervals, coefficient of variation ≤ 0.15
hourly_volume_v1	robust_baseline	medium	50	Hourly bytes, ≥ 8 samples, z ≥ 6
hourly_flow_count_v1	robust_baseline	medium	50	Hourly flow count, ≥ 8 samples, z ≥ 6
hourly_destination_count_v1	robust_baseline	medium	55	Hourly destination count, ≥ 8 samples, z ≥ 6
destination_scan_v1	scan	high	70	≥ 20 unique ports in 60 s
peer_isolation_v1	peer_isolation	medium	60	Isolation score ≥ 70
rare_periodic_destination_v1	composite	high	80	A new destination contacted periodically

The last one is the interesting one, and it shows what the model language is for. Neither half is alarming alone — new destinations happen daily, and plenty of legitimate things poll on a schedule. A new destination that is also being polled on a tight schedule is a different thing entirely, and it scores 80.

Writing your own

Models are declarative YAML, validated before use. There is no code execution: a model is a combination of conditions over computed features, plus a score.

version: 1
models:
  - id: camera_reaches_unexpected_peer_v1
    title: Camera reached a destination other than the recorder
    severity: high
    base_score: 75
    conditions:
      - feature: destination_rarity
        operator: eq
        threshold: 1
      - feature: beacon_score
        operator: gte
        threshold: 40

Conditions are combined with AND. Features are the values the detectors compute; the operators are comparisons. Anything outside that vocabulary is rejected at load time, which is exactly what makes it safe to let a language model draft one — it produces a proposal that a validator checks and a person approves, and approving it does not activate it.

The scores decay over time per device, so a single event does not keep a device at the top of the list forever.

What is not in the product

For the sake of not overpromising: Bayesian baselines, per-group autoencoders and sequence models over service order are planned, not present. They need four to eight weeks of data before they can be evaluated at all, so they follow the statistical layer rather than replacing it. See the roadmap.