The EDR service is the foundation of LimaCharlie. In order to make billing
simpler and more predictible, it is based on a Quota set by the user.

The Quota is the number of sensors (agents) concurrently online that should be
supported by the given Organization. The Quota applies to concurrently onlie sensors
meaning that you may have more sensors registered than your quota.

If sensors attempt to connect to the cloud while the Quota is full, they will simply
be turned away for a short period of time. In that case, a special sensor_over_quota
will also be emitted which you can use in D&R rules for automation.

The endpoint service includes Outputs as well as D&R rules processed
in real-time.

A special case around Quota use is called Sidecar Sensors. At the moment the only
Sidecar Sensor is the Chrome sensor. A Sidecar Sensor will not count against your
Quota as long as it has a correspondant "normal" sensor.

For example, let's say you have 10 Windows sensors and 10 MacOS sensors online for
a total of 20 "normal" sensors. This means you will be able to have up to 20 other
Chrome sensors online without using any extra quota. If 25 Chrome sensors become
online however, 5 extra Quota will be consumed.

The intent is to allow Chrome sensors to be companion sensors enhancing visibility
of your existing LimaCharlie deployment without making Chrome-only deployments
effectively free.

replayed against 100 events would result into 100 "operation evaluations".

Final billing is based on blocks of those "operation evaluations".

The best way to evaluate the cost of a specific rule through Replay is to
launch a limited Replay job of a given rule first. The results of the job
will contain the number of operation evaluations performed. You can then
extrapolate an estimate of the cost.

Replay jobs can also be launched with a maximum number of operation evaluations
to consume during the life-cycle of the job. This limit is aproximate due to
the de-centralized nature of Replay jobs and may vary a bit.