@observertc/observer-js 1.0.0-beta.18 → 1.0.0-beta.21

package/dist/index.d.mts

@@ -2578,11 +2578,33 @@ type CallSummaryConfig = {
      * with only `enrich` is a perfectly good summary.
      */
     include: CallSummarySection[];
-    /** Fold arbitrary state in from any call-scoped event. See {@link CallSummaryEnrichers}. */
+    /**
+     * Fold arbitrary state in from any call-scoped event, into `summary.attachments`. See
+     * {@link CallSummaryEnrichers}.
+     *
+     * Each enricher runs on **every** occurrence of its event, for its own call, so prefer the
+     * low-frequency lifecycle events (`client-joined`, `call-issue`) over `client-updated`, which fires
+     * once per sample per client. Keep them cheap and side-effect free: an enricher that throws is logged
+     * and skipped rather than allowed to disturb the call, but one that is slow is on the ingestion path.
+     */
     enrich?: CallSummaryEnrichers;
-    /** Cap on the retained issue log. Default `500`. See the note on truncation. */
+    /**
+     * Cap on retained issues. Default `500`.
+     *
+     * A bound on memory per call, so scale it by how long your calls run and how noisy they are, not by
+     * taste — a two-hour call with a struggling participant can raise hundreds. Past the cap issues are
+     * dropped and `summary.truncated.issues` counts them, so the real total stays recoverable as
+     * `issues.length + (truncated?.issues ?? 0)`. `0` collects the count only, keeping no issue objects.
+     */
     maxIssues: number;
-    /** Cap on retained client ids. Default `10_000`. */
+    /**
+     * Cap on retained client ids. Default `10_000`.
+     *
+     * High because the elements are short strings and the usual reason to read a summary is *who was in
+     * this call*. It exists so a webinar-scale room cannot grow the summary without limit. Overflow is
+     * counted in `summary.truncated.clientIds`; `joined`, `left` and `peak` are unaffected by the cap,
+     * since they are counters rather than a list.
+     */
     maxClientIds: number;
 };
 /**
@@ -3667,7 +3689,29 @@ declare class RemoteTrackResolver {
     private readonly resolvers;
     private readonly _publisherIdToOutboundTrack;
     private readonly _subscriberIdToInboundTrack;
+    /**
+     * Tracks whose publisher id the strategy could not resolve **yet**.
+     *
+     * A track announces itself once, but its `attachments` are replaced on every sample, so a key that
+     * is missing from the first sample can appear on the second — and a strategy backed by an
+     * application's own mapping (a server-side `ssrc -> producerId` table, say) is inherently racy
+     * against sample arrival. Resolving only at `*-track-added` meant losing those tracks for their
+     * entire life, silently: an unresolvable outbound track never even reaches
+     * `unconsumedOutboundTracks`, so it is invisible to `UnconsumedTrackDetector` too.
+     *
+     * So they wait here and are retried on their own `*-track-updated`, i.e. exactly when new stats
+     * arrived for them. A track leaves on its first successful resolution or on removal, which makes
+     * a linked track cost one `Set.has` per update and bounds these sets by the unresolved tracks
+     * alive right now.
+     */
+    private readonly _pendingInboundTracks;
+    private readonly _pendingOutboundTracks;
     constructor(observedCall: ObservedCall, resolvers: RemoteTrackResolvers);
+    /** Tracks still waiting for a resolvable publisher id. Diagnostics; normally both are empty. */
+    get pendingTrackCounts(): {
+        inbound: number;
+        outbound: number;
+    };
     /** The published (outbound) track for a publisher id, if any. */
     getOutboundTrackByPublisherId(publisherId: string): ObservedOutboundTrack | undefined;
     /** The subscribed (inbound) track for a subscriber id, if the strategy resolves subscriber ids. */
@@ -3704,18 +3748,47 @@ type CallConcurrentIssueDetectorConfig = {
      * exactly these and sees nothing else.
      */
     issueTypes: string[];
-    /** Minimum participants in the call before a ratio is meaningful. Default `3`. */
+    /**
+     * Participants the call needs before a ratio means anything. Default `3`.
+     *
+     * In a 1:1 call "half the participants" is one person, which is a client problem and not a call
+     * problem — `2` effectively disables the ratio gate. Raise it for large-meeting products where you
+     * only care once a handful are affected.
+     */
     minClients: number;
-    /** Minimum distinct clients sharing the open issue. Default `3`. */
+    /**
+     * Distinct clients that must share the issue. Default `3`.
+     *
+     * The absolute floor under `affectedRatioThreshold`, so a small call cannot clear a ratio with two
+     * unlucky people. Sensible range `2`–`5`; `2` is the lowest that can still mean "more than one
+     * participant", which is the whole premise.
+     */
     minAffectedClients: number;
-    /** Fraction of the call's participants that must share it. Default `0.5`. */
+    /**
+     * Fraction of the call's participants that must share it, `0`–`1`. Default `0.5`.
+     *
+     * Typical `0.3`–`0.7`. Lower catches partial events — a subset on one SFU worker — at the cost of
+     * firing on a few coincidentally unhappy participants; `1` demands literally everyone, which real
+     * incidents rarely produce because someone always reconnects first.
+     */
     affectedRatioThreshold: number;
     /**
-     * When the onsets fall within this span (ms), the finding is escalated to `ISSUE_ONSET_BURST` —
-     * they didn't just overlap, they started together. Default `2_000`.
+     * Onsets falling within this span (ms) escalate the finding to `ISSUE_ONSET_BURST` — they did not
+     * just overlap, they started together. Default `2_000`.
+     *
+     * Bound this by your sampling period, not below it: onsets are only known as accurately as clients
+     * report them, so a window shorter than one sampling period can only fire by luck. Typical
+     * `1_000`–`5_000`. Wider makes the escalation meaningless, since unrelated issues drift into the
+     * same window.
      */
     onsetBurstWindowInMs: number;
-    /** Re-arm time (ms) per issue type. Default `60_000`. */
+    /**
+     * Re-arm time per issue type (ms). Default `60_000`.
+     *
+     * A shared event is one incident, not one per tick. Too low and a persistent problem raises an
+     * issue every tick for as long as it lasts; too high and a genuinely new occurrence is swallowed
+     * by the previous one's cooldown. Typical `30_000`–`300_000`.
+     */
     cooldownMs: number;
 };
 /** What the detector currently knows about one issue type in this call. */
@@ -3779,25 +3852,88 @@ declare class CallConcurrentIssueDetector implements Detector, ActiveIssueTracke
     private _groupOf;
 }
 
+/** A point on the earth, as an application reports it for one client. */
+type ClientLocation = {
+    latitude: number;
+    longitude: number;
+};
+/**
+ * Approximate cell width at each geohash length, for choosing a precision.
+ *
+ * Index is the character count; the value is the rough cell size at the equator. Cells are taller
+ * than they are wide at high latitudes, so treat these as an order of magnitude, not a radius.
+ */
+declare const GEOHASH_CELL_SIZES: readonly ["", "~5000 km", "~1250 km", "~156 km", "~39 km", "~5 km", "~1.2 km", "~150 m"];
+/**
+ * Encode a point as a geohash of `precision` characters — a **grid cell key**, not a cluster.
+ *
+ * ### Why cells rather than "within N kilometres"
+ *
+ * Grouping clients "within a radius" sounds like the natural thing and is a much worse fit. It is a
+ * clustering problem, not a keying one: the groups depend on which client you start from, two
+ * clients can each be within the radius of a third but not of each other, group identity is not
+ * stable as participants join and leave, and maintaining it costs pairwise distance work. None of
+ * that survives contact with a detector that has to produce the *same* group name on every tick so
+ * a cooldown and a control group mean anything.
+ *
+ * A geohash prefix is a plain function of the coordinates: O(1), stable for the life of the client,
+ * and usable directly as a population label. The honest cost is that a cell boundary can separate
+ * two clients who are physically adjacent, which splits a real group into two smaller ones. That
+ * biases towards **missing** a finding rather than inventing one, which is the right direction for
+ * something that raises issues.
+ *
+ * Returns `undefined` for coordinates that are not finite or not on the earth, rather than encoding
+ * nonsense into a plausible-looking cell key.
+ */
+declare function geohash(location: ClientLocation, precision?: number): string | undefined;
+
 declare const ClientPopulationIssueTypes: {
     /** One issue type is concentrated on one client population while the rest of the fleet is fine. */
     readonly clientPopulationIssue: "CLIENT_POPULATION_ISSUE";
 };
 /** The client attribute to group by. One axis per detector — see the class description. */
-type ClientPopulationAxis = 'browser' | 'engine' | 'platform' | 'operationSystem';
+type ClientPopulationAxis = 'browser' | 'engine' | 'platform' | 'operationSystem' | 'location';
+/**
+ * Reads a client's coordinates, for `groupBy: 'location'`. **Required for that axis.**
+ *
+ * There is no coordinate field in `ClientSample`, so the shape is yours: read it off
+ * `client.attachments`, off a custom meta item, or from an `appData` field your accept middleware
+ * filled in. Return `undefined` for clients whose location you do not know — they are then excluded
+ * from both the population and the control group, exactly like a client that never reported its
+ * browser.
+ */
+type ClientLocationResolver = (client: ObservedClient) => ClientLocation | undefined;
 type ClientPopulationIssueDetectorConfig = {
     /**
      * The issue types to watch. **Required, and must not be empty.**
      *
-     * The types worth grouping this way are the ones an endpoint owns: `cpulimitation`,
+     * **Match the issue family to the axis.** On the endpoint axes (`browser`, `engine`, `platform`,
+     * `operationSystem`) the types worth grouping are the ones an endpoint owns: `cpulimitation`,
      * `encoder-bottleneck`, `capture-bottleneck`, `stuck-decoder`, `video-decoder-overloaded`.
      * Grouping a *network* symptom by browser is a category error — `congestion` clusters by ISP and
-     * geography, neither of which this detector can see, and it would happily report a browser
-     * correlation that is really a "most of our users are on Chrome" artefact.
+     * geography, not by build, and the detector would happily report a browser correlation that is
+     * really a "most of our users are on Chrome" artefact.
+     *
+     * On the `location` axis it is the other way round: group the network symptoms — `congestion`,
+     * `ice-disconnected`, `unstable-ice-path` — and not the endpoint ones, since there is no reason a
+     * decoder should stall by geography.
      */
     issueTypes: string[];
     /** Which client attribute to group by. Default `'browser'`. */
     groupBy: ClientPopulationAxis;
+    /**
+     * Where to read a client's coordinates. **Required when `groupBy` is `'location'`**, ignored
+     * otherwise. See {@link ClientLocationResolver}.
+     */
+    resolveClientLocation?: ClientLocationResolver;
+    /**
+     * Geohash characters to group locations by, i.e. how coarse a "place" is. Default `3` (~156 km).
+     *
+     * `2` ~1250 km, `3` ~156 km, `4` ~39 km, `5` ~5 km. Coarser cells hold more clients, which is what
+     * makes a rate mean anything, so start coarse: a city-sized cell rarely has `minPopulationSize`
+     * participants in it. See `utils/geohash` for why this is a grid cell and not a radius.
+     */
+    locationPrecision: number;
     /**
      * Group by `name` only, or by `name + version`. Default `true` (include version).
      *
@@ -3805,26 +3941,66 @@ type ClientPopulationIssueDetectorConfig = {
      * thing that changed on a date. Set to `false` when comparing whole engines.
      */
     includeVersion: boolean;
-    /** Minimum clients in a population before its rate means anything. Default `20`. */
+    /**
+     * Clients in a population before its rate means anything. Default `20`.
+     *
+     * Higher than the other detectors' minimums on purpose: this one compares *rates*, and a rate over
+     * five clients is not a rate. Sensible range `20`–`100`. On the `location` axis this is the field
+     * most likely to silence the detector — a city-sized cell rarely holds twenty concurrent
+     * participants, so reach for a coarser `locationPrecision` before lowering this.
+     */
     minPopulationSize: number;
-    /** Minimum affected clients in the population. Default `5`. */
+    /**
+     * Affected clients required within the population. Default `5`.
+     *
+     * Checked independently of `affectedRatioThreshold`, so one unlucky user on a rare browser cannot
+     * page anyone however striking the ratio looks. Sensible range `5`–`20`.
+     */
     minAffectedClients: number;
-    /** Share of the population that must be affected. Default `0.3`. */
+    /**
+     * Share of the population that must be affected, `0`–`1`. Default `0.3`.
+     *
+     * Lower than the per-call thresholds deliberately: an issue hitting 30% of one browser version while
+     * the rest of the fleet is clean is already a strong signal, and endpoint faults rarely affect
+     * *everyone* on a build. Typical `0.2`–`0.5`. This is the weakest of the gates —
+     * `minRelativeRisk` is what makes the finding mean anything.
+     */
     affectedRatioThreshold: number;
     /**
      * How many times worse the suspect population must be than the rest of the fleet. Default `3`.
      *
-     * This is the control, and it is what makes the finding mean anything. See the class description.
+     * **This is the gate that makes the finding mean anything** — see the class description. Typical
+     * `2`–`10`. At `2` you will see populations that are merely somewhat worse, which is often just a
+     * different usage pattern; at `10` only stark, unambiguous concentrations survive. A spotless
+     * control group yields `Infinity`, which clears any threshold, so the minimum-count gates above are
+     * what stop that from being trivial.
      */
     minRelativeRisk: number;
-    /** Minimum clients **outside** the suspect population before a comparison is possible. Default `20`. */
+    /**
+     * Clients **outside** the suspect population before a comparison is possible. Default `20`.
+     *
+     * "Worse than everyone else" needs an everyone else. Sensible range `20`–`100`. Note the practical
+     * consequence: a fleet that is overwhelmingly one browser can never have that browser reported,
+     * because there is no control group left — which is honest, since at 95% Chrome you cannot separate a
+     * Chrome fault from a fleet-wide one.
+     */
     minControlSize: number;
-    /** Re-arm time (ms) per (population, issue type). Default `300_000`. */
+    /**
+     * Re-arm time per (population, issue type) in ms. Default `300_000`.
+     *
+     * Long by design: a bad client build is a condition lasting days, not an event, and the action it
+     * prompts — ship a fix, roll back a version — is not one you take twice an hour. Typical
+     * `300_000`–`3_600_000`.
+     */
     cooldownMs: number;
 };
 /** The rollup for one population on one issue type. */
 type ClientPopulation = {
-    /** e.g. `'Chrome 141'`, or `'Chrome'` when `includeVersion` is off. */
+    /**
+     * e.g. `'Chrome 141'`, or `'Chrome'` when `includeVersion` is off. For the `'location'` axis this
+     * is the geohash cell — never the coordinates themselves, so an archived payload carries a place
+     * at the configured resolution and not a person's position.
+     */
     population: string;
     axis: ClientPopulationAxis;
     issueType: string;
@@ -3896,12 +4072,48 @@ type ClientPopulation = {
  * Safari is usually one fact reported twice, and a detector that emits both leaves the reader to
  * work out which one is causal. Pick the axis you want to reason about.
  *
+ * ### The `location` axis
+ *
+ * With `groupBy: 'location'` the population is a **geohash cell** rather than a client attribute, so
+ * the same machinery answers a different question: *is this symptom concentrated in one place?* That
+ * is the grouping the note above says browsers cannot give you, and it is the one that matters for
+ * network symptoms.
+ *
+ * The observer does not derive "this client's RTT jumped" — `client-monitor`'s `CongestionDetector`
+ * already owns that verdict, comparing each peer connection's RTT against its own EWMA baseline and
+ * requiring a bandwidth-limitation corroboration before it raises `congestion`. Absolute RTT is not
+ * comparable between clients anyway: someone 200 ms away is *always* 200 ms away, so the only signal
+ * is deviation from that client's own baseline, which is exactly what the client already measures.
+ * This detector's contribution is the part no endpoint can see — that many of the affected clients
+ * are in the same place at the same time.
+ *
+ * ```ts
+ * observer.addObserverDetector('client-population-issue-detector', {
+ *   issueTypes: [ 'congestion', 'ice-disconnected' ],
+ *   groupBy: 'location',
+ *   locationPrecision: 3,                                  // ~156 km cells
+ *   resolveClientLocation: (client) => client.attachments?.geo as { latitude: number, longitude: number },
+ * });
+ * ```
+ *
+ * Coordinates are not in `ClientSample`, so `resolveClientLocation` is required — see
+ * {@link ClientLocationResolver}. Only the cell key reaches the issue payload, never the
+ * coordinates, which matters because these payloads are archived into call summaries.
+ *
+ * **The limitation to state plainly: geography is confounded with your topology.** The control group
+ * is "everyone outside this cell", which cannot separate *"the path into this region degraded"* from
+ * *"the SFU that happens to serve this region degraded"*. If a region maps largely onto one
+ * deployment, both hypotheses fit the same evidence. The discriminator is whether clients elsewhere
+ * on the same server also degraded, which is what `SfuCongestionDetector` and
+ * `TurnServerHealthDetector` answer — so the conclusion here points at them rather than claiming an
+ * attribution it cannot support.
+ *
  * ### Clients that never reported their metadata
  *
  * `browser` / `engine` / `platform` / `operationSystem` arrive as client metadata and may be absent —
  * a client that closed before sending them, or an application that does not collect them. Those
  * clients are excluded from **both** the population and the control group rather than bucketed as
- * `'unknown'`. A synthetic `'unknown'` population would be a mixture of every real one, so any rate
+ * `'unknown'`. The same applies to a client whose location `resolveClientLocation` cannot supply. A synthetic `'unknown'` population would be a mixture of every real one, so any rate
  * computed for it means nothing, and leaving those clients in the control group would dilute the
  * comparison with clients whose kind we cannot verify.
  */
@@ -3953,9 +4165,21 @@ type PublisherFaultCorroborationDetectorConfig = {
      * "I am not getting this properly", which is the half the publisher cannot see.
      */
     receiverIssueTypes: string[];
-    /** Minimum subscribers of the track that must be complaining. Default `2`. */
+    /**
+     * Subscribers of the track that must be complaining at the same time. Default `2`.
+     *
+     * `1` still yields a genuine two-sided corroboration — publisher and one receiver agreeing is
+     * already more than either says alone — but `2` rules out the case where a single receiver's own
+     * downlink is at fault and merely coincides with the publisher's complaint. Sensible range `1`–`3`;
+     * higher mostly costs you findings in small calls, where a track may only have two subscribers.
+     */
     minAffectedReceivers: number;
-    /** Re-arm time (ms) per published track. Default `60_000`. */
+    /**
+     * Re-arm time per published track (ms). Default `60_000`.
+     *
+     * Typical `30_000`–`300_000`. This detector raises the highest-confidence finding in the library,
+     * so it is the one you least want repeating every tick.
+     */
     cooldownMs: number;
 };
 /** The two-sided evidence behind one finding. */
@@ -4054,7 +4278,13 @@ type ObserverConcurrentIssueDetectorConfig = {
      * exactly these and sees nothing else.
      */
     issueTypes: string[];
-    /** Minimum distinct clients sharing the open issue. Default `3`. */
+    /**
+     * Distinct clients that must share the open issue. Default `3`.
+     *
+     * Absolute, deliberately — see `affectedCallRatioThreshold` for why no client *ratio* exists at
+     * this scope. Sensible range `3`–`10`; scale it with fleet size, since three clients is a real
+     * signal across five calls and background noise across five hundred.
+     */
     minAffectedClients: number;
     /**
      * Minimum number of *distinct calls* the affected clients must span. Default `2`.
@@ -4078,11 +4308,21 @@ type ObserverConcurrentIssueDetectorConfig = {
      */
     affectedCallRatioThreshold: number;
     /**
-     * When the onsets fall within this span (ms), the finding is escalated to
-     * `CROSS_CALL_ISSUE_ONSET_BURST`. Default `2_000`.
+     * Onsets falling within this span (ms) escalate the finding to `CROSS_CALL_ISSUE_ONSET_BURST`.
+     * Default `2_000`.
+     *
+     * This is the strongest evidence the detector produces: independent calls starting to fail *at the
+     * same instant* has no explanation other than something they share. Keep it at or above your
+     * sampling period — onsets are only as precise as clients report them — and no wider than a few
+     * seconds, or unrelated failures drift into the same window. Typical `1_000`–`5_000`.
      */
     onsetBurstWindowInMs: number;
-    /** Re-arm time (ms) per issue type. Default `60_000`. */
+    /**
+     * Re-arm time per issue type (ms). Default `60_000`.
+     *
+     * Typical `60_000`–`600_000`. A fleet-wide event is one incident: without a cooldown a sustained
+     * outage would raise an issue on every tick for its whole duration.
+     */
     cooldownMs: number;
 };
 /** What the detector currently knows about one issue type across the fleet. */
@@ -4175,13 +4415,38 @@ type IssueFanOutDetectorConfig = {
      * hardware and would be a false accusation.
      */
     issueTypes: string[];
-    /** Minimum receivers of the track before a ratio is meaningful. Default `3`. */
+    /**
+     * Receivers a track needs before a ratio means anything. Default `3`.
+     *
+     * With two receivers, "60% affected" is one of them — which is the single-receiver case below, not
+     * a fan-out. Sensible range `2`–`5`; in small calls a published track rarely has more than a couple
+     * of subscribers, so raising this can silence the detector entirely.
+     */
     minReceivers: number;
-    /** Fraction of a track's receivers that must share the issue. Default `0.6`. */
+    /**
+     * Fraction of a track's receivers that must share the issue, `0`–`1`. Default `0.6`.
+     *
+     * The higher this is, the more the finding points at the publisher rather than at the network
+     * between: *everyone* receiving this track badly is hard to explain any other way. Typical
+     * `0.5`–`0.8`. Below `0.5` you are reporting "some receivers", which usually means their own
+     * last miles.
+     */
     affectedRatioThreshold: number;
-    /** Also report the "only one receiver is affected" case. Default `true`. */
+    /**
+     * Also report when exactly one receiver is affected. Default `true`.
+     *
+     * Kept on because the finding is *useful and correctly weaker*: it is raised with a lower
+     * confidence and the opposite conclusion — one unhappy receiver out of eight points at that
+     * receiver, not at the publisher. Turn it off if you only want publisher-blaming findings and
+     * treat single-receiver trouble as the client's own business.
+     */
     reportSingleReceiver: boolean;
-    /** Re-arm time (ms) per (track, issue type). Default `60_000`. */
+    /**
+     * Re-arm time per (track, issue type) in ms. Default `60_000`.
+     *
+     * Per track, so a call with many bad publishers still reports each of them. Typical
+     * `30_000`–`300_000`.
+     */
     cooldownMs: number;
 };
 /**
@@ -4272,14 +4537,76 @@ type SfuCongestionDetectorReport = {
     relativeIncrease: number;
 };
 type SfuCongestionDetectorConfig = {
+    /**
+     * Client issue types counted as "congestion" for this indicator. Default `[ 'congestion' ]`.
+     *
+     * Keep this narrow. Every type you add widens what counts as a congested client, and the whole
+     * method rests on comparing *like with like* across time buckets — mixing in a type that appears
+     * for unrelated reasons raises the baseline and buries the spike you are looking for.
+     */
     consumedClientIssueTypes: string[];
+    /** The `observer-issue` type raised when a bucket is judged congested. Default `'sfu-congestion'`. */
     emittedObserverIssueType: string;
+    /**
+     * How long your clients take to send a sample (ms). Default `10_000`.
+     *
+     * **Set this to your collector's actual sampling period** — it is a description of your clients,
+     * not a tuning knob. The bucket is `samplesSendingTimeInMs * 2`, so every client gets a fair
+     * chance to report at least once inside each bucket. Set it too short and clients that simply had
+     * not reported yet look absent, so the ratio jumps around on sampling noise; too long and the
+     * detector reacts slowly and averages a spike away.
+     */
     samplesSendingTimeInMs: number;
+    /**
+     * Completed buckets kept as history — the candidate plus its baseline. Default `30`.
+     *
+     * At the default bucket size this is ~10 minutes of baseline. Sensible range `10`–`60`. Longer is
+     * more robust to a single odd bucket but slower to accept a genuinely changed normal (a growth
+     * spurt, a new region coming online); shorter adapts quickly but lets a sustained problem become
+     * the new baseline and stop being reported.
+     */
     historySize: number;
+    /**
+     * Buckets required before any judgement is made. Default `5`.
+     *
+     * Below this the detector is silent, which is the point: a median and MAD over two buckets is not
+     * a baseline. Costs `minHistorySize * samplesSendingTimeInMs * 2` of warm-up after start — about
+     * 100 s at the defaults. Do not lower it to make a test fire faster; shorten the bucket instead.
+     */
     minHistorySize: number;
+    /**
+     * Distinct congested clients required in the candidate bucket. Default `3`.
+     *
+     * The absolute floor beneath every ratio below, so that a tiny fleet cannot produce a finding: two
+     * unhappy clients out of four is 50% and means nothing. Raise it on a large fleet where three
+     * clients is always noise.
+     */
     minAffectedClients: number;
+    /**
+     * How far the candidate's congested-client **ratio** must exceed the baseline median, in absolute
+     * terms (`0`–`1`). Default `0.05`, i.e. five percentage points.
+     *
+     * This is the practical-significance gate: it stops a statistically striking move from 0.5% to 2%
+     * being reported as an event. Typical `0.03`–`0.15`.
+     */
     minAbsoluteRatioIncrease: number;
+    /**
+     * How many times the baseline median the candidate ratio must reach. Default `2`.
+     *
+     * Multiplicative counterpart to the absolute gate — both must pass. Typical `1.5`–`3`. Below
+     * `1.5` ordinary fluctuation qualifies; above ~`4` only near-total events do.
+     */
     minRelativeRatioIncrease: number;
+    /**
+     * Robust z-score the candidate must reach against a median+MAD baseline. Default `3`.
+     *
+     * The statistical-significance gate. `3` is the conventional "clearly outside normal variation";
+     * `2` is noticeably chattier, `4`–`5` only for very stable fleets. Median and MAD rather than mean
+     * and standard deviation on purpose — a couple of past incidents in the history would inflate a
+     * standard deviation enough to hide the next one. Note that a perfectly flat baseline gives
+     * `MAD = 0`, where any increase scores `Infinity`; the two ratio gates above are what keep that
+     * honest.
+     */
     robustZThreshold: number;
 };
 /** The statistical/practical-significance verdict for one candidate bucket against its baseline. */
@@ -4402,15 +4729,35 @@ declare const TrackDeliveryMismatchTypes: {
     readonly publisherTrackDry: "PUBLISHER_TRACK_DRY";
 };
 type TrackDeliveryMismatchDetectorConfig = {
-    /** The receiver-side issue type meaning "no media arriving". Default `'dry-inbound-track'`. */
+    /**
+     * The receiver-side issue type meaning "no media arriving". Default `'dry-inbound-track'`, which is
+     * what client-monitor-js raises. Only change it if you raise your own equivalent.
+     */
     dryInboundIssueType: string;
-    /** The publisher-side issue type meaning "not producing". Default `'dry-outbound-track'`. */
+    /**
+     * The publisher-side issue type meaning "not producing". Default `'dry-outbound-track'`, as raised
+     * by client-monitor-js. The pairing of these two types is the whole detector: their **disagreement**
+     * is the finding.
+     */
     dryOutboundIssueType: string;
-    /** Minimum subscribers before "all of them" means anything. Default `2`. */
+    /**
+     * Subscribers required before "all of them" means anything. Default `2`.
+     *
+     * With one subscriber, "every receiver is dry" is a single client's report and carries no more
+     * weight than the client issue already does. Sensible range `2`–`4`.
+     */
     minReceivers: number;
-    /** Fraction of subscribers that must be dry to call it a whole-track delivery failure. Default `1`. */
+    /**
+     * Fraction of subscribers that must be dry to call it a whole-track delivery failure. Default `1`.
+     *
+     * `1` — literally all of them — on purpose. The inference here is sharp: the publisher says it is
+     * sending and *every* receiver says nothing arrives, so the fault is between them, in the SFU's
+     * forwarding. Lowering it to `0.8` admits mixed evidence, where some receivers do get the media, and
+     * the conclusion no longer follows: that is a per-receiver problem and `IssueFanOutDetector`'s
+     * question. Do not lower it without deciding what the finding then means.
+     */
     allReceiversRatio: number;
-    /** Re-arm time (ms) per (track, verdict). Default `60_000`. */
+    /** Re-arm time per (track, verdict) in ms. Default `60_000`. Typical `30_000`–`300_000`. */
     cooldownMs: number;
 };
 /**
@@ -4461,19 +4808,47 @@ declare const TurnServerHealthTypes: {
     readonly turnServerDegraded: "TURN_SERVER_DEGRADED";
 };
 type TurnServerHealthDetectorConfig = {
-    /** Minimum clients on a server before a ratio is meaningful. Default `5`. */
+    /**
+     * Clients a server must be carrying before its ratio means anything. Default `5`.
+     *
+     * With two relayed clients, "half are degraded" is one person having a bad time. Sensible range
+     * `5`–`20`; raise it if you run many small TURN deployments, since each needs enough traffic to be
+     * measurable on its own.
+     */
     minClientsPerServer: number;
-    /** Fraction of a server's clients that must have an open issue. Default `0.5`. */
+    /**
+     * Fraction of a server's clients that must have an open issue, `0`–`1`. Default `0.5`.
+     *
+     * Typical `0.4`–`0.7`. Remember each finding also carries the *other* servers' ratios, so the
+     * threshold is not doing the comparison on its own — a server at 50% next to peers at 45% reads very
+     * differently from one next to peers at 3%. Below `0.3` you will report servers that are merely
+     * carrying unlucky clients.
+     */
     degradedRatioThreshold: number;
     /**
-     * Which client issue types count as "in trouble". Empty (default) means **any** open issue —
-     * appropriate here, because the question is not *what* is wrong with each client but whether
-     * trouble clusters on one relay.
+     * Which client issue types count as "in trouble". Empty (the default) means **any** open issue.
+     *
+     * The permissive default is deliberate and unusual for this library: the question is not *what* is
+     * wrong with each client but whether trouble clusters on one relay, and a relay problem shows up as
+     * whatever symptom each client happens to notice first. Narrow it to network types
+     * (`congestion`, `ice-disconnected`) if endpoint issues like `cpulimitation` are common enough in
+     * your fleet to blur the comparison between servers.
      */
     issueTypes: string[];
-    /** Consecutive ticks the condition must hold before raising. Default `2`. */
+    /**
+     * Consecutive `observer.update()` ticks the condition must hold before raising. Default `2`.
+     *
+     * The de-bounce. `1` reacts immediately and will fire on a single tick where several clients
+     * happened to be mid-reconnect; `2`–`3` costs a tick or two of delay and removes most of that.
+     * Note this counts *ticks*, not time, so how long it actually waits depends on your sample rate.
+     */
     consecutiveTicks: number;
-    /** Re-arm time (ms) before raising again for the same server. Default `60_000`. */
+    /**
+     * Re-arm time per server (ms). Default `60_000`.
+     *
+     * Shorter than the outage detector's, because degradation is a condition you may want re-reported as
+     * it persists or worsens, not a single event. Typical `60_000`–`300_000`.
+     */
     cooldownMs: number;
 };
 /** The per-server view this detector builds. */
@@ -4526,8 +4901,11 @@ declare const TurnServerOutageTypes: {
 };
 type TurnServerOutageDetectorConfig = {
     /**
-     * How many clients a server must have been carrying at its peak before its collapse means
-     * anything. Below this, one or two people leaving looks like an outage. Default `5`.
+     * Clients a server must have been carrying at its peak before its collapse means anything. Default
+     * `5`.
+     *
+     * Below this, one or two people leaving looks like an outage. Sensible range `5`–`50`; the higher it
+     * is the more confident the finding, and the more small deployments go unwatched.
      */
     minClientsAtPeak: number;
     /**
@@ -4536,8 +4914,11 @@ type TurnServerOutageDetectorConfig = {
      */
     lossRatioThreshold: number;
     /**
-     * Window (ms) the peak population is measured over. Long enough to span a real outage's onset,
-     * short enough that yesterday's peak isn't held against today. Default `120_000`.
+     * Window the peak population is measured over (ms). Default `120_000`.
+     *
+     * Long enough to span a real outage's onset, short enough that yesterday's peak is not held against
+     * today. Typical `60_000`–`600_000`. Too long and the natural end of a busy period reads as a
+     * collapse; too short and a gradual failure never shows a peak to fall from.
      */
     peakWindowMs: number;
     /**
@@ -4546,11 +4927,28 @@ type TurnServerOutageDetectorConfig = {
      * event, or the observer shutting down all look exactly like a TURN outage. Default `true`.
      */
     requireControlGroup: boolean;
-    /** Minimum clients elsewhere before the control group is statistically worth anything. Default `5`. */
+    /**
+     * Clients elsewhere before the control group is worth anything. Default `5`.
+     *
+     * If you run a single TURN server there is never a control group, so with `requireControlGroup: true`
+     * this detector can never fire — which is correct rather than unfortunate: with one relay you cannot
+     * distinguish "the relay died" from "everyone went home". Sensible range `5`–`20`.
+     */
     minControlGroupClients: number;
-    /** Fraction of the control group that must still be healthy. Default `0.7`. */
+    /**
+     * Fraction of the control group that must still be healthy, `0`–`1`. Default `0.7`.
+     *
+     * The evidence that the rest of the world is fine. Typical `0.6`–`0.9`. Set it too high and a
+     * concurrent unrelated problem elsewhere masks a real outage; too low and a fleet-wide network event
+     * gets blamed on whichever server lost clients first.
+     */
     controlGroupHealthyRatio: number;
-    /** Consecutive ticks the condition must hold before raising. Default `2`. */
+    /**
+     * Consecutive `observer.update()` ticks the condition must hold before raising. Default `2`.
+     *
+     * Counts ticks, not time. `1` will fire on a single tick where a batch of clients happened to be
+     * between samples; `2`–`4` is the useful range for something this consequential to declare.
+     */
     consecutiveTicks: number;
     /**
      * Re-arm time (ms) per server. Long by default (`300_000`) — an outage is one event, not one
@@ -4631,11 +5029,31 @@ declare const UnconsumedTrackTypes: {
     readonly unconsumedPublishedTrack: "UNCONSUMED_PUBLISHED_TRACK";
 };
 type UnconsumedTrackDetectorConfig = {
-    /** How long a track must stay unconsumed while sending before reporting (ms). Default `30_000`. */
+    /**
+     * How long a track must stay unconsumed **while still sending** before it is reported (ms).
+     * Default `30_000`.
+     *
+     * This is the main guard against a false alarm, because a gap between publishing and the first
+     * subscription is completely normal at join time — and again after every renegotiation. Sensible
+     * range `15_000`–`120_000`. Too low and you report every join; too high and you tolerate wasted
+     * uplink for longer than you need to. Waste is not an outage, so err high.
+     */
     minUnconsumedDurationInMs: number;
-    /** Ignore tracks below this bitrate — a trickle isn't worth an alert (bps). Default `50_000`. */
+    /**
+     * Ignore tracks sending below this bitrate (**bits per second**). Default `50_000` (50 kbps).
+     *
+     * The point of the detector is wasted bandwidth, and a track trickling keep-alive packets wastes
+     * none worth an alert. Typical `20_000`–`100_000`: muted or paused tracks sit near zero, a real
+     * video track is hundreds of kbps. Set it to `0` to report every unconsumed track regardless of
+     * cost.
+     */
     minBitrate: number;
-    /** Re-arm time (ms) per track. Default `300_000`. */
+    /**
+     * Re-arm time per track (ms). Default `300_000`.
+     *
+     * Long on purpose: an unconsumed track usually *stays* unconsumed, so a short cooldown means a
+     * steady drip of the same finding for the life of the call. Typical `300_000`–`900_000`.
+     */
     cooldownMs: number;
 };
 /**
@@ -5012,17 +5430,57 @@ type SimulcastReceiverReportPayload = ({
     checks: number;
 };
 type SimulcastReceiverValidatorConfig = {
-    /** Minimum receivers of a published track before the comparison means anything. */
+    /**
+     * Receivers a published track needs before the comparison means anything. Default `3`.
+     *
+     * The question is whether *one* receiver drags *the others* down, which needs at least one other to
+     * be dragged — so `3` gives a worst receiver plus two to compare against. `2` is the technical
+     * minimum but makes "median of the others" a single number. Sensible range `3`–`5`.
+     */
     minReceivers: number;
-    /** How long a track's bitrates are correlated over (ms). */
+    /**
+     * How long bitrates are correlated over (ms). Default `10_000`.
+     *
+     * Long enough to contain a real adaptation response — the publisher's encoder reacting to a
+     * bandwidth estimate takes seconds, not milliseconds. Typical `10_000`–`30_000`. Too short and you
+     * catch transient jitter rather than a sustained relationship; too long and a genuine change is
+     * averaged out by the healthy period around it.
+     */
     windowMs: number;
-    /** Samples needed inside the window before it can be judged. */
+    /**
+     * Samples needed inside the window before it can be judged. Default `5`.
+     *
+     * A correlation over two or three points is meaningless. Combined with `windowMs` this implies a
+     * sampling period: 5 samples in 10 s needs clients reporting at least every ~2 s. If your collector
+     * is slower, widen `windowMs` rather than lowering this.
+     */
     minSamples: number;
-    /** The worst receiver must be at most this share of the median, or there is nothing to be dragged by. */
+    /**
+     * The worst receiver must be at most this share of the median receiver, `0`–`1`. Default `0.5`.
+     *
+     * The precondition, not the finding: unless somebody is genuinely doing much worse than the rest,
+     * there is nothing for the publisher to be dragged *by* and the check has nothing to look at.
+     * Typical `0.4`–`0.7`. Higher makes the check run more often on weaker evidence; lower means it
+     * rarely finds a qualifying situation at all.
+     */
     outlierRatioThreshold: number;
-    /** How closely the publisher must follow the worst receiver to count as dragged. */
+    /**
+     * How closely the publisher must track the worst receiver to count as dragged, `0`–`1`. Default
+     * `0.8`.
+     *
+     * This is the finding: the publisher sending at ≥80% of the *worst* receiver's rate means it has
+     * collapsed to the lowest common denominator instead of serving everyone else properly. Typical
+     * `0.7`–`0.9`. Toward `1` you only catch total collapse; below ~`0.6` normal encoder behaviour can
+     * look like dragging.
+     */
     trackingRatioThreshold: number;
-    /** Clean checks required before concluding per-receiver adaptation. One could be luck. */
+    /**
+     * Clean checks required before concluding per-receiver adaptation works. Default `3`.
+     *
+     * One clean check could be luck — the qualifying moment might simply not have been bad enough. This
+     * is what stops a lucky sample from being reported as a pass, so raising it strengthens the verdict
+     * at the cost of taking longer to reach one. Typical `3`–`10`.
+     */
     minChecks: number;
 };
 /**
@@ -5140,13 +5598,38 @@ type RemoteTrackResolverReportPayload = ({
     checks: number;
 };
 type RemoteTrackResolverValidatorConfig = {
-    /** Participants a call needs before it can plausibly have publisher↔subscriber links. Default `2`. */
+    /**
+     * Participants a call needs before it can plausibly have publisher↔subscriber links. Default `2`.
+     *
+     * A one-person call has nobody to subscribe to anyone, so counting it would dilute the ratio with
+     * calls that *could not* have produced a link. `2` is the true minimum here and there is little
+     * reason to raise it.
+     */
     minClients: number;
-    /** Inbound tracks that must be present in a call before it counts as a check. Default `2`. */
+    /**
+     * Inbound tracks a call must have before it counts as a check. Default `2`.
+     *
+     * Same idea: no subscribed tracks means nothing to link. Sensible range `2`–`5`.
+     */
     minInboundTracks: number;
-    /** Share of inbound tracks that must be linked to conclude the resolver works. Default `0.5`. */
+    /**
+     * Share of inbound tracks that must be linked to conclude the resolver works, `0`–`1`. Default
+     * `0.5`.
+     *
+     * Deliberately lenient, because a partially-linked call is normal: tracks arrive before their
+     * publisher is known, and simulcast layers or probing streams may have no publisher at all. The
+     * question is "is this resolver wired up", not "is every track linked". Typical `0.3`–`0.7`. Raising
+     * it toward `1` turns the check into a strictness audit and it will report failure on healthy
+     * systems.
+     */
     linkedRatioThreshold: number;
-    /** Eligible calls to observe before concluding either way. One could be a race. Default `3`. */
+    /**
+     * Eligible calls to observe before concluding either way. Default `3`.
+     *
+     * One call could be a race — every track happening to arrive before its publisher. Typical `3`–`10`.
+     * Note that a low value makes a *pass* less trustworthy than a failure: linking nothing repeatedly is
+     * conclusive, linking things once might be luck.
+     */
     minChecks: number;
 };
 /**
@@ -5255,11 +5738,27 @@ type CodecConsistencyValidatorConfig = {
      * case where everyone agrees on the wrong thing — a silent fallback that nothing else notices.
      */
     expected?: Partial<Record<'audio' | 'video', string>>;
-    /** Which kinds to inspect. Default both. */
+    /**
+     * Which kinds to inspect. Default `[ 'audio', 'video' ]`.
+     *
+     * Narrow it when only one matters: audio codec splits are the ones that usually cost transcoding,
+     * while video splits are more often a deliberate per-client decision.
+     */
     kinds: ('audio' | 'video')[];
-    /** Participants a call needs before disagreement is meaningful. Default `3`. */
+    /**
+     * Participants a call needs before disagreement is meaningful. Default `3`.
+     *
+     * In a 1:1 call "the participants disagree" is two clients differing, which can be a legitimate
+     * negotiation outcome rather than a fault. Sensible range `3`–`5`.
+     */
     minClients: number;
-    /** Calls to inspect before concluding. Default `3`. */
+    /**
+     * Calls to inspect before concluding. Default `3`.
+     *
+     * A structural property of your negotiation, so a handful of calls is plenty — but one call could be
+     * an unusual mix of participants. Typical `3`–`10`. Higher delays the verdict without adding much,
+     * since the answer does not vary call to call.
+     */
     minChecks: number;
 };
 /**
@@ -5439,8 +5938,38 @@ type ClientAppDataFactory = (params: {
     acceptCtx?: AcceptContext;
 }) => Record<string, unknown>;
 type ObserverConfig<AppData extends Record<string, unknown> = Record<string, unknown>> = {
+    /**
+     * Application-owned data for the observer itself. Never read or modified by the library.
+     *
+     * For per-call / per-client data prefer `createCallAppData` / `createClientAppData`, which run at
+     * creation time and can see the `accept()` context.
+     */
     appData?: AppData;
+    /**
+     * Close a client that has not produced a sample for this long (ms). Default `60_000`.
+     *
+     * This is the **liveness timeout for a participant**, so set it from your client's sampling
+     * period, not from taste: a client sampling every 5 s needs several missed samples to look gone.
+     * Sensible range `3x`–`10x` the sampling period; `60_000` suits the usual 2–10 s collectors.
+     *
+     * Too low and a client that merely paused (tab backgrounded, brief network drop) is closed and
+     * then re-created as a *new* client, which restarts its detectors and splits one participant into
+     * two in any summary. Too high and left participants linger, inflating `peak`, the denominators of
+     * every ratio-based detector, and memory. `undefined` disables the timeout — then nothing closes
+     * an abandoned client but your own `client.close()`.
+     */
     closeClientIfIdleForMs?: number;
+    /**
+     * Close a call once it has had zero clients for this long (ms). Default `60_000`.
+     *
+     * The grace period exists so a brief empty moment — everyone reconnecting after a network blip,
+     * the last participant refreshing — does not end the call and start a new one under the same
+     * `callId`. Sensible range `10_000`–`300_000`.
+     *
+     * Too low splits one meeting into several calls, and each split emits its own `call-summary`. Too
+     * high keeps dead calls in `observedCalls`, holding their detectors and summaries in memory.
+     * `undefined` disables it: the call then lives until you call `call.close()`.
+     */
     closeCallIfEmptyForMs?: number;
     /**
      * When `true` (the default), every call update triggers an observer-wide `update()` pass.
@@ -5481,15 +6010,75 @@ type ObserverConfig<AppData extends Record<string, unknown> = Record<string, unk
      * say which. One shape for every call, or none.
      */
     callSummary?: Partial<CallSummaryConfig> | null;
+    /**
+     * Thresholds that mark a **received** track as degraded. Omitted (the default) means no track is
+     * ever marked degraded — `inboundTrack.degraded` stays `false` and `degradationReasons` stays
+     * empty, so this is opt-in and absence is *not* a clean bill of health.
+     *
+     * Each field is an **exclusive upper bound**: the reason is added when the measured value is
+     * strictly greater. All are evaluated on every update and any number can fire at once;
+     * `degradationReasons` lists the ones that did.
+     *
+     * These feed `CallHealthAggregator` and `outboundTrack.degradedRatio` (how many of a publisher's
+     * receivers are unhappy), which is what `TrackDeliveryMismatchDetector` and
+     * `PublisherFaultCorroborationDetector` read. They are **not** a substitute for client issues:
+     * client-monitor already decides "this endpoint is in trouble" with hysteresis and multi-signal
+     * confirmation. Treat these as a coarse per-track flag for cross-participant comparison, and keep
+     * them loose enough that a single bad tick does not trip them.
+     */
     inboundTrackDegradationThresholds?: {
+        /**
+         * Freezes counted **in one sampling period**, not since the start of the call. `1` means "any
+         * freeze at all this tick", which is strict; `2`–`3` tolerates the odd frame hiccup.
+         * Reason: `'freezes'`.
+         */
         deltaFreezeCount: number;
+        /**
+         * Fraction of frames dropped, `0`–`1`. Typical `0.05`–`0.2`; below ~`0.02` you are inside
+         * normal jitter for most decoders. Reason: `'frames-dropped'`.
+         */
         framesDroppedRatio: number;
+        /**
+         * Jitter buffer delay in **ms**. Typical `150`–`500`: audio stays intelligible well past
+         * `200`, while conversation turn-taking suffers beyond ~`400`. Reason:
+         * `'jitter-buffer-delay'`.
+         */
         jitterBufferDelayInMs: number;
+        /**
+         * Concealed (synthesised) audio samples as a fraction, `0`–`1`. Typical `0.05`–`0.15`; above
+         * ~`0.1` is usually audible as robotic or clipped speech. Reason: `'concealment'`.
+         */
         concealmentRatio: number;
+        /**
+         * Round-trip time in **ms**, as reported for this inbound stream. Typical `250`–`500`.
+         * Remember this is absolute, not relative to the participant's own baseline — a genuinely
+         * distant participant will sit permanently above any fixed bound, which is why "RTT got
+         * worse" belongs to client-monitor and not here. Reason: `'rtt'`.
+         */
         rttInMs: number;
     };
+    /**
+     * Thresholds that mark a **published** track as degraded, from what the receivers report back.
+     * Omitted (the default) means neither threshold-based reason can fire.
+     *
+     * Note two reasons are added regardless of this setting, because they need no threshold:
+     * `quality-limited-<reason>` when the encoder reports a `qualityLimitationReason`, and
+     * `no-packets-sent` when an unmuted track sent nothing in a sampling period.
+     *
+     * Also an **exclusive upper bound** per field, evaluated on every update.
+     */
     outboundTrackDegradationThresholds?: {
+        /**
+         * Fraction of packets lost as reported by the remote end, `0`–`1`. Typical `0.02`–`0.1`;
+         * anything under ~`0.01` is normal on the open internet and will fire constantly. Reason:
+         * `'remote-fraction-lost'`.
+         */
         fractionLost: number;
+        /**
+         * Round-trip time in **ms** as reported by the remote end. Typical `250`–`500`, and absolute
+         * rather than baseline-relative — see the note on the inbound `rttInMs`. Reason:
+         * `'remote-rtt'`.
+         */
         rttInMs: number;
     };
     /**
@@ -5861,14 +6450,43 @@ declare class SlidingWindow<T> {
 
 type TrendTesterConfig = {
     /**
-     * How many of the most recent values to keep. The one knob that controls how far back "trend"
-     * looks, for both tests — there is deliberately no separate window per test.
+     * How many of the most recent values to keep. Default `30`, floored at `2`.
+     *
+     * The one knob controlling how far back "trend" looks, for both tests — there is deliberately no
+     * separate window per test. This counts *samples*, so the time it spans depends on how often you
+     * push. Mann-Kendall needs roughly 8–10 points before its significance test is worth anything, so
+     * below ~`10` it will mostly answer `no-trend`. Typical `20`–`60`: long enough for a stable
+     * baseline, short enough that a sustained change eventually becomes the new normal instead of being
+     * flagged forever.
      */
     size?: number;
-    /** Page-Hinkley's drift tolerance and detection threshold — see {@link pageHinkley}. */
+    /**
+     * Page-Hinkley's **drift tolerance** — change smaller than this is treated as noise and never
+     * accumulated. Default `0`. See {@link pageHinkley}.
+     *
+     * Expressed in the units of whatever you push, so there is no universally good value: for RTT in ms
+     * a few ms is a reasonable tolerance. The default `0` accumulates *every* deviation, which is the
+     * most sensitive setting. Too low and ordinary fluctuation accumulates into a false step change; too
+     * high and a real but gradual shift never accumulates at all.
+     */
     pageHinkleyDelta?: number;
+    /**
+     * Page-Hinkley's **detection threshold** — how much accumulated drift counts as a step change.
+     * Default `50`. See {@link pageHinkley}.
+     *
+     * Also in your units, and the direct sensitivity control: lower detects smaller or earlier steps and
+     * false-positives more; higher waits for unmistakable ones. Worth tuning against a recorded series
+     * rather than by intuition, because the right value depends entirely on the scale and noisiness of
+     * the metric you feed it.
+     */
     pageHinkleyLambda?: number;
-    /** Mann-Kendall's significance level — see {@link mannKendallVerdict}. */
+    /**
+     * Mann-Kendall's significance level. Default `0.05`. See {@link mannKendallVerdict}.
+     *
+     * Conventional values are `0.01`, `0.05` and `0.1`. This is the probability of claiming a monotonic
+     * trend that is not really there: `0.01` is stricter and slower to call a trend, `0.1` more
+     * sensitive and noisier.
+     */
     mannKendallAlpha?: number;
 };
 /**
@@ -6043,4 +6661,4 @@ declare function createInMemorySink(samples?: ClientSample[]): InMemorySink;
 declare function createDefaultMediasoupRemoteTrackResolverFactory(): RemoteTrackResolverFactory;
 declare function createP2pRemoteTrackResolverFactory(): RemoteTrackResolverFactory;
 
-export { type AcceptContext, type AcceptMiddleware, type AcceptMiddlewarePayload, type ActiveClientIssue, type ActiveIssueTracker, ActiveIssuesRegistry, type AvailableCallScopeDetectorsConfigs, type AvailableDetectorsConfigs, type AvailableObserverScopeDetectorsConfigs, type AvailableValidatorConfigs, CODEC_MISMATCH_ISSUE, type CallAppDataFactory, CallConcurrentIssueDetector, type CallConcurrentIssueDetectorConfig, type CallConcurrentIssueGroup, CallConcurrentIssueTypes, type CallHealth, CallHealthAggregator, type CallIssue, type CallIssueSpread, type CallScopedEventName, type CallSummary, type CallSummaryClients, CallSummaryCollector, type CallSummaryConfig, type CallSummaryEnricher, type CallSummaryEnrichers, type CallSummaryScores, type CallSummarySection, type CallSummaryTruncation, type CallSummaryTurnServers, type ClientAppDataFactory, type ClientEvent, ClientEventTypes, type ClientHealth, type ClientHealthThresholds, type ClientIssue, type ClientMetaData, ClientMetaTypes, type ClientPopulation, type ClientPopulationAxis, ClientPopulationIssueDetector, type ClientPopulationIssueDetectorConfig, ClientPopulationIssueTypes, type ClientSample, ClientSampleSink, type ClientSampleSinkEvents, type ClientSampleSinkFactory, type CodecConsistencyReportPayload, CodecConsistencyValidator, type CodecConsistencyValidatorConfig, type CodecEvidence, type CorroboratedPublisherFault, type Detector, Detectors, InMemorySink, type Issue, type IssueBase, type IssueConclusion, IssueFanOutDetector, type IssueFanOutDetectorConfig, IssueFanOutTypes, type IssueFaultDomain, JsonlFileSink, type JsonlFileSinkFactoryOptions, type JsonlFileSinkOptions, LOWEST_COMMON_DENOMINATOR_ISSUE, type Logger, type MannKendallResult, type MediasoupConsumerSample, type MediasoupConsumerSampleEvent, type MediasoupDataConsumerSample, type MediasoupDataProducerSample, type MediasoupDirectTransportSample, type MediasoupDirectTransportSampleEventMap, type MediasoupPipeTransportSample, type MediasoupPipeTransportSampleEventMap, type MediasoupPlainTransportSample, type MediasoupPlainTransportSampleEventMap, type MediasoupProducerSample, type MediasoupProducerSampleEvent, type MediasoupRouterSample, type MediasoupSampleEnricher, type MediasoupTransportSample, type MediasoupWebRtcTransportSample, type MediasoupWebRtcTransportSampleEventMap, type Middleware, ObservedCall, type ObservedCallScope, ObservedCertificate, ObservedClient, ObservedClientIssueRegistry, type ObservedClientScope, ObservedCodec, ObservedDataChannel, ObservedIceCandidate, ObservedIceCandidatePair, ObservedIceTransport, ObservedInboundRtp, ObservedInboundTrack, ObservedMediaPlayout, ObservedMediaSource, ObservedMediasoupRouter, type ObservedMediasoupRouterEvents, type ObservedMediasoupRouterScope, type ObservedMediasoupRouterSettings, ObservedOutboundRtp, ObservedOutboundTrack, ObservedPeerConnection, type ObservedPeerConnectionScope, ObservedPeerConnectionTransport, ObservedRemoteInboundRtp, ObservedRemoteOutboundRtp, Observer, ObserverConcurrentIssueDetector, type ObserverConcurrentIssueDetectorConfig, type ObserverConcurrentIssueGroup, ObserverConcurrentIssueTypes, type ObserverEventBase, type ObserverEvents, type ObserverIssue, type ObserverIssueSpread, type ObserverLogger, type PageHinkleyResult, PublisherFaultCorroborationDetector, type PublisherFaultCorroborationDetectorConfig, PublisherFaultTypes, RESOLVED_ISSUE_SUFFIX, type RemoteTrackLinkEvidence, RemoteTrackResolver, type RemoteTrackResolverFactory, type RemoteTrackResolverReportPayload, RemoteTrackResolverValidator, type RemoteTrackResolverValidatorConfig, type RemoteTrackResolvers, type ResolvedActiveClientIssue, type RunningValidator, type SampleRejectedReason, type ScoreCalculator, SfuCongestionDetector, type SfuCongestionDetectorBucket, type SfuCongestionDetectorConfig, type SfuCongestionDetectorEvaluation, type SfuCongestionDetectorReport, type SimulcastReceiverEvidence, type SimulcastReceiverReportPayload, SimulcastReceiverValidator, type SimulcastReceiverValidatorConfig, SlidingWindow, type SlidingWindowEntry, type StatsSummary, TrackDeliveryMismatchDetector, type TrackDeliveryMismatchDetectorConfig, TrackDeliveryMismatchTypes, TrendTester, type TrendTesterConfig, type TurnServerHealth, TurnServerHealthDetector, type TurnServerHealthDetectorConfig, TurnServerHealthTypes, TurnServerOutageDetector, type TurnServerOutageDetectorConfig, TurnServerOutageTypes, UNRESOLVED_TRACK_LINKS_ISSUE, UnconsumedTrackDetector, type UnconsumedTrackDetectorConfig, UnconsumedTrackTypes, type ValidationReport, type Validator, type ValidatorName, baseIssueType, concludeCallIssue, concludeObserverIssue, correlation, counterDelta, createCallSummary, createDefaultMediasoupRemoteTrackResolverFactory, createInMemorySink, createJsonlFileSink, createJsonlFileSinkFactory, createLogger, createP2pRemoteTrackResolverFactory, defaultCallSummaryConfig, defaultClientHealthThresholds, isClientIssueResolutionEntry, issuePayloadAsString, mannKendall, mannKendallVerdict, median, medianAbsoluteDeviation, pageHinkley, percentile, percentileOfSorted, robustZScore, setObserverLogger, summarize };
+export { type AcceptContext, type AcceptMiddleware, type AcceptMiddlewarePayload, type ActiveClientIssue, type ActiveIssueTracker, ActiveIssuesRegistry, type AvailableCallScopeDetectorsConfigs, type AvailableDetectorsConfigs, type AvailableObserverScopeDetectorsConfigs, type AvailableValidatorConfigs, CODEC_MISMATCH_ISSUE, type CallAppDataFactory, CallConcurrentIssueDetector, type CallConcurrentIssueDetectorConfig, type CallConcurrentIssueGroup, CallConcurrentIssueTypes, type CallHealth, CallHealthAggregator, type CallIssue, type CallIssueSpread, type CallScopedEventName, type CallSummary, type CallSummaryClients, CallSummaryCollector, type CallSummaryConfig, type CallSummaryEnricher, type CallSummaryEnrichers, type CallSummaryScores, type CallSummarySection, type CallSummaryTruncation, type CallSummaryTurnServers, type ClientAppDataFactory, type ClientEvent, ClientEventTypes, type ClientHealth, type ClientHealthThresholds, type ClientIssue, type ClientLocation, type ClientLocationResolver, type ClientMetaData, ClientMetaTypes, type ClientPopulation, type ClientPopulationAxis, ClientPopulationIssueDetector, type ClientPopulationIssueDetectorConfig, ClientPopulationIssueTypes, type ClientSample, ClientSampleSink, type ClientSampleSinkEvents, type ClientSampleSinkFactory, type CodecConsistencyReportPayload, CodecConsistencyValidator, type CodecConsistencyValidatorConfig, type CodecEvidence, type CorroboratedPublisherFault, type Detector, Detectors, GEOHASH_CELL_SIZES, InMemorySink, type Issue, type IssueBase, type IssueConclusion, IssueFanOutDetector, type IssueFanOutDetectorConfig, IssueFanOutTypes, type IssueFaultDomain, JsonlFileSink, type JsonlFileSinkFactoryOptions, type JsonlFileSinkOptions, LOWEST_COMMON_DENOMINATOR_ISSUE, type Logger, type MannKendallResult, type MediasoupConsumerSample, type MediasoupConsumerSampleEvent, type MediasoupDataConsumerSample, type MediasoupDataProducerSample, type MediasoupDirectTransportSample, type MediasoupDirectTransportSampleEventMap, type MediasoupPipeTransportSample, type MediasoupPipeTransportSampleEventMap, type MediasoupPlainTransportSample, type MediasoupPlainTransportSampleEventMap, type MediasoupProducerSample, type MediasoupProducerSampleEvent, type MediasoupRouterSample, type MediasoupSampleEnricher, type MediasoupTransportSample, type MediasoupWebRtcTransportSample, type MediasoupWebRtcTransportSampleEventMap, type Middleware, ObservedCall, type ObservedCallScope, ObservedCertificate, ObservedClient, ObservedClientIssueRegistry, type ObservedClientScope, ObservedCodec, ObservedDataChannel, ObservedIceCandidate, ObservedIceCandidatePair, ObservedIceTransport, ObservedInboundRtp, ObservedInboundTrack, ObservedMediaPlayout, ObservedMediaSource, ObservedMediasoupRouter, type ObservedMediasoupRouterEvents, type ObservedMediasoupRouterScope, type ObservedMediasoupRouterSettings, ObservedOutboundRtp, ObservedOutboundTrack, ObservedPeerConnection, type ObservedPeerConnectionScope, ObservedPeerConnectionTransport, ObservedRemoteInboundRtp, ObservedRemoteOutboundRtp, Observer, ObserverConcurrentIssueDetector, type ObserverConcurrentIssueDetectorConfig, type ObserverConcurrentIssueGroup, ObserverConcurrentIssueTypes, type ObserverEventBase, type ObserverEvents, type ObserverIssue, type ObserverIssueSpread, type ObserverLogger, type PageHinkleyResult, PublisherFaultCorroborationDetector, type PublisherFaultCorroborationDetectorConfig, PublisherFaultTypes, RESOLVED_ISSUE_SUFFIX, type RemoteTrackLinkEvidence, RemoteTrackResolver, type RemoteTrackResolverFactory, type RemoteTrackResolverReportPayload, RemoteTrackResolverValidator, type RemoteTrackResolverValidatorConfig, type RemoteTrackResolvers, type ResolvedActiveClientIssue, type RunningValidator, type SampleRejectedReason, type ScoreCalculator, SfuCongestionDetector, type SfuCongestionDetectorBucket, type SfuCongestionDetectorConfig, type SfuCongestionDetectorEvaluation, type SfuCongestionDetectorReport, type SimulcastReceiverEvidence, type SimulcastReceiverReportPayload, SimulcastReceiverValidator, type SimulcastReceiverValidatorConfig, SlidingWindow, type SlidingWindowEntry, type StatsSummary, TrackDeliveryMismatchDetector, type TrackDeliveryMismatchDetectorConfig, TrackDeliveryMismatchTypes, TrendTester, type TrendTesterConfig, type TurnServerHealth, TurnServerHealthDetector, type TurnServerHealthDetectorConfig, TurnServerHealthTypes, TurnServerOutageDetector, type TurnServerOutageDetectorConfig, TurnServerOutageTypes, UNRESOLVED_TRACK_LINKS_ISSUE, UnconsumedTrackDetector, type UnconsumedTrackDetectorConfig, UnconsumedTrackTypes, type ValidationReport, type Validator, type ValidatorName, baseIssueType, concludeCallIssue, concludeObserverIssue, correlation, counterDelta, createCallSummary, createDefaultMediasoupRemoteTrackResolverFactory, createInMemorySink, createJsonlFileSink, createJsonlFileSinkFactory, createLogger, createP2pRemoteTrackResolverFactory, defaultCallSummaryConfig, defaultClientHealthThresholds, geohash, isClientIssueResolutionEntry, issuePayloadAsString, mannKendall, mannKendallVerdict, median, medianAbsoluteDeviation, pageHinkley, percentile, percentileOfSorted, robustZScore, setObserverLogger, summarize };