---
title: 'Metering Bypass (fleet)'
description: Ranks the fleet by gas-metering bypass risk using four telemetry signs combined into a 0-100 score per node.
section: AI Analytics
weight: 4
related:
  - ai-analytics/fleet-reports/suspicious-nodes
  - ai-analytics/node-reports/metering-bypass
---

import Alert from '@/components/docs/Alert.astro';

This report ranks every metering node in the fleet by the likelihood of gas-metering bypass: substitution of the measuring channel or unmetered flow. Each node receives a score from 0 to 100, and the list is sorted from the most suspicious down to normal. It is built for the control service: open it, see which nodes to check first, and drill into a detailed per-node breakdown.

<Alert type="warning" title="A suspicion assessment, not proof of theft">
The wording is deliberately neutral — "possible channel substitution", "possible tampering". A legal verdict requires a site visit, a seal check, reconciliation with the device's abnormal-situations log and the contract terms. Confidence is capped at the medium level until the device event archive is connected.
</Alert>

## What it shows

| Block | What it means |
|---|---|
| Header | the maximum fleet score and a breakdown by severity level |
| Level summary | how many nodes are critical / high / medium / low / normal |
| Top-N table | nodes in descending score order: address, device type, score, triggered signs, telemetry summary, drill-downs to the detailed breakdown |
| Distribution by sign | how many nodes triggered each of the four signs — the fleet's anomaly profile |
| Timeline by device type | drill-downs to the event timeline for each device type in the top |
| AI fleet summary | a text summary (if enabled); does not affect scores |

## How it is calculated

To avoid overloading the platform, the analysis runs in two stages.

First, a **pre-selection**: a single request fetches the whole fleet and gives each node a rough score from reference data (session age, device status), without heavy requests. This filters out fresh, working nodes. If a company is selected, only its nodes remain (including subsidiaries).

Then a **deep analysis** of the top candidates runs in several parallel workers. For each candidate, the hourly archive (flow, pressure, temperature) and the link-sessions log are fetched. Before the checks run, the node is cleared of false positives:

| Guard | Condition | Effect |
|---|---|---|
| Broken pressure sensor | pressure stuck for a week or longer at least once | pressure-based signs are not run |
| Network node | pressure low and very steady (mains regulator) | the "frozen pressure" sign is turned off |
| Telemetry glitch | pressure above 500 kPa or a one-off flow spike | the record is discarded before the checks |

Then four bypass signs are sought:

| Sign | Severity | What it catches |
|---|---|---|
| Zero flow at stand-in pressure | very high | flow near zero, pressure frozen on a "standby" substitute value (near atmospheric or zero) |
| Business-hours recovery | high | after a long zero flow, a synchronized jump in flow and pressure |
| Frozen pressure (Gay-Lussac) | medium | pressure does not react to temperature change, violating Gay-Lussac's law |
| Archive gap with clean sessions | medium | a hole in the hourly archive while link sessions were successful |
| Zero flow, live pressure | low | zero flow, but pressure changes normally (a weak contextual signal) |

The final score combines the triggered signs as independent probabilities: one strong sign nearly exhausts the scale, while several weak ones do not add up to "critical". For example, a node with a very-high and a high sign scores about 82 — higher than each sign alone, but not 100 (reaching 100 requires device events from the not-yet-connected archive). Informational data-integrity events do not raise the score. The list is sorted by descending score, with ties broken by event count.

## Run parameters

| Parameter | Default | Meaning |
|---|---|---|
| Period from | today − 90 days | start of the window; at least one temperature swing is needed for the pressure sign |
| Period to | yesterday | end of the window |
| Resource company | all companies | fleet filter by company |
| How many nodes in top | 30 | size of the final table (10-200) |
| How many nodes to deep-analyze | 150 | candidates to break down after pre-selection (50-500) |
| Parallel download workers | 4 | lower to 2-4 on HTTP 429 |
| AI fleet summary | off | a text comment; does not affect scores |

A period under 14 days gives an unstable score (few opportunities for the temperature sign), so the severity is automatically lowered by one step.

## How to read it

- **Severity by score:** 0-9 — normal; 10-29 — for information; 30-49 — planned check (quarter); 50-69 — visit queue (month); 70-100 — urgent visit with a seal check.
- **Alarming:** nodes in the red zone (≥70), especially with the zero-flow-at-stand-in-pressure sign; a concentration of suspicious nodes in one subsidiary.
- **Distribution by sign** shows the fleet profile: a predominance of one sign may indicate tampering or a systemic feature (device type, network).
- **False positives:** network nodes (stable regulator pressure — the pressure sign is turned off); devices without a pressure channel (only the archive-gap sign is available).
- **Limitations:** confidence is capped at the medium level until the device event archive is connected; the bottleneck is platform request throttling (HTTP 429), under which you reduce the number of workers.

## Related reports

- **Suspicious Nodes** — the main fleet tool for prioritizing which nodes to check.
- **Metering Bypass (node)** — a detailed breakdown of one node with its event log.