@observertc/observer-js 1.0.0-beta.9 → 1.0.0

package/dist/index.d.mts

@@ -1,6 +1,7 @@
 import { EventEmitter } from 'events';
 import { types } from 'mediasoup';
 
+declare const schemaVersion = "3.7.0";
 /**
 * The WebRTC app provided custom stats payload
 */
@@ -12,7 +13,7 @@ type ExtensionStat = {
     /**
     * The payload of the extension stats the custom app provides
     */
-    payload?: string;
+    payload?: Record<string, unknown>;
 };
 /**
 * A list of additional client events.
@@ -23,9 +24,9 @@ type ClientMetaData = {
     */
     type: string;
     /**
-    * The value associated with the event, if applicable.
+    * The attributes of the meta data entry, if applicable.
     */
-    payload?: string;
+    payload?: Record<string, unknown>;
     /**
     * The unique identifier of the peer connection for which the event was generated.
     */
@@ -52,9 +53,13 @@ type ClientIssue = {
     */
     type: string;
     /**
-    * The value associated with the event, if applicable.
+    * Identifier of the related issue or resolution when it is provided.
     */
-    payload?: string;
+    key?: string;
+    /**
+    * The attributes of the issue, if applicable.
+    */
+    payload?: Record<string, unknown>;
     /**
     * The timestamp in epoch format when the event was generated.
     */
@@ -69,16 +74,16 @@ type ClientEvent = {
     */
     type: string;
     /**
-    * The value associated with the event, if applicable.
+    * The attributes of the event, if applicable.
     */
-    payload?: string;
+    payload?: Record<string, unknown>;
     /**
     * The timestamp in epoch format when the event was generated.
     */
     timestamp?: number;
 };
 /**
-* Certificates
+* Certificate Stats
 */
 type CertificateStats = {
     /**
@@ -102,7 +107,7 @@ type CertificateStats = {
     */
     base64Certificate?: string;
     /**
-    * The certificate ID of the issuer (nullable).
+    * The certificate ID of the issuer.
     */
     issuerCertificateId?: string;
     /**
@@ -119,7 +124,7 @@ type IceCandidatePairStats = {
     */
     id: string;
     /**
-    * The timestamp of when the stats were recorded, in seconds.
+    * The timestamp of when the stats were recorded, in milliseconds.
     */
     timestamp: number;
     /**
@@ -134,7 +139,10 @@ type IceCandidatePairStats = {
     * The ID of the remote ICE candidate in this pair.
     */
     remoteCandidateId?: string;
-    state?: 'new' | 'in-progress' | 'waiting' | 'failed' | 'succeeded' | 'cancelled' | 'inprogress';
+    /**
+    * The checklist state of this candidate pair. Values follow the W3C RTCStatsIceCandidatePairState enum (frozen, waiting, in-progress, failed, succeeded). Two further values are accepted for backward compatibility and are not part of the current spec: `new` (never standardised) and `cancelled` (removed from the spec after 2016).
+    */
+    state?: "new" | "frozen" | "in-progress" | "waiting" | "failed" | "succeeded" | "cancelled" | "inprogress";
     /**
     * Whether this candidate pair has been nominated.
     */
@@ -229,7 +237,7 @@ type IceCandidateStats = {
     */
     transportId?: string;
     /**
-    * The IP address of the ICE candidate (nullable).
+    * The IP address of the ICE candidate.
     */
     address?: string;
     /**
@@ -358,7 +366,15 @@ type IceTransportStats = {
     */
     selectedCandidatePairChanges?: number;
     /**
-    * Additional information attached to this stats
+    * Number of congestion control feedback (CCFB) messages sent on this transport.
+    */
+    ccfbMessagesSent?: number;
+    /**
+    * Number of congestion control feedback (CCFB) messages received on this transport.
+    */
+    ccfbMessagesReceived?: number;
+    /**
+    * Additional information attached to this stats.
     */
     attachments?: Record<string, unknown>;
 };
@@ -539,7 +555,7 @@ type MediaSourceStats = {
     attachments?: Record<string, unknown>;
 };
 /**
-* Remote Outbound RTPs
+* Remote Outbound RTP Stats
 */
 type RemoteOutboundRtpStats = {
     /**
@@ -625,7 +641,24 @@ type QualityLimitationDurations = {
     other: number;
 };
 /**
-* Outbound RTPs
+* Cumulative PSNR measurements for Y, U, V components.
+*/
+type PsnrSum = {
+    /**
+    * PSNR value for the Y (luminance) component.
+    */
+    y: number;
+    /**
+    * PSNR value for the U (chrominance) component.
+    */
+    u: number;
+    /**
+    * PSNR value for the V (chrominance) component.
+    */
+    v: number;
+};
+/**
+* Outbound RTP Stats
 */
 type OutboundRtpStats = {
     /**
@@ -677,6 +710,10 @@ type OutboundRtpStats = {
     */
     rid?: string;
     /**
+    * Index of the encoding in the encoding array.
+    */
+    encodingIndex?: number;
+    /**
     * The total number of header bytes sent on this stream.
     */
     headerBytesSent?: number;
@@ -733,6 +770,14 @@ type OutboundRtpStats = {
     */
     qpSum?: number;
     /**
+    * Cumulative PSNR measurements for Y, U, V components.
+    */
+    psnrSum?: PsnrSum;
+    /**
+    * Total number of PSNR measurements collected.
+    */
+    psnrMeasurements?: number;
+    /**
     * The total time spent encoding frames on this stream in seconds.
     */
     totalEncodeTime?: number;
@@ -741,10 +786,14 @@ type OutboundRtpStats = {
     */
     totalPacketSendDelay?: number;
     /**
-    * The reason for any quality limitation on this stream.
+    * The reason for any quality limitation on this stream (e.g., 'cpu', 'bandwidth', 'other').
     */
     qualityLimitationReason?: string;
     /**
+    * The duration of quality limitation reasons categorized by type.
+    */
+    qualityLimitationDurations?: QualityLimitationDurations;
+    /**
     * The number of resolution changes due to quality limitations.
     */
     qualityLimitationResolutionChanges?: number;
@@ -765,7 +814,7 @@ type OutboundRtpStats = {
     */
     encoderImplementation?: string;
     /**
-    * Indicates whether the encoder is power efficient.
+    * Indicates whether the encoder is power-efficient.
     */
     powerEfficientEncoder?: boolean;
     /**
@@ -777,16 +826,16 @@ type OutboundRtpStats = {
     */
     scalabilityMode?: string;
     /**
-    * The duration of quality limitation reasons categorized by type.
+    * Number of packets sent with ECT(1) congestion marking.
     */
-    qualityLimitationDurations?: QualityLimitationDurations;
+    packetsSentWithEct1?: number;
     /**
     * Additional information attached to this stats.
     */
     attachments?: Record<string, unknown>;
 };
 /**
-* Remote Inbound RTPs
+* Remote Inbound RTP Stats
 */
 type RemoteInboundRtpStats = {
     /**
@@ -818,6 +867,22 @@ type RemoteInboundRtpStats = {
     */
     packetsReceived?: number;
     /**
+    * Total number of RTP packets received for this SSRC marked with the ECT(1) marking.
+    */
+    packetsReceivedWithEct1?: number;
+    /**
+    * Total number of RTP packets received for this SSRC marked with the CE marking.
+    */
+    packetsReceivedWithCe?: number;
+    /**
+    * Total number of RTP packets for which an RFC8888 report has been sent with a zero R bit.
+    */
+    packetsReportedAsLost?: number;
+    /**
+    * Total number of RTP packets reported as lost but later recovered in a subsequent RFC8888 report.
+    */
+    packetsReportedAsLostButRecovered?: number;
+    /**
     * The total number of packets lost on this stream.
     */
     packetsLost?: number;
@@ -846,12 +911,16 @@ type RemoteInboundRtpStats = {
     */
     roundTripTimeMeasurements?: number;
     /**
+    * Number of packets with ECT(1) marking that were bleached by a middlebox.
+    */
+    packetsWithBleachedEct1Marking?: number;
+    /**
     * Additional information attached to this stats
     */
     attachments?: Record<string, unknown>;
 };
 /**
-* Inbound RTPs
+* Inbound RTP Stats
 */
 type InboundRtpStats = {
     /**
@@ -887,6 +956,22 @@ type InboundRtpStats = {
     */
     packetsReceived?: number;
     /**
+    * Total number of RTP packets received for this SSRC marked with the ECT(1) marking.
+    */
+    packetsReceivedWithEct1?: number;
+    /**
+    * Total number of RTP packets received for this SSRC marked with the CE marking.
+    */
+    packetsReceivedWithCe?: number;
+    /**
+    * Total number of RTP packets for which an RFC8888 report has been sent with a zero R bit.
+    */
+    packetsReportedAsLost?: number;
+    /**
+    * Total number of RTP packets reported as lost but later recovered in a subsequent RFC8888 report.
+    */
+    packetsReportedAsLostButRecovered?: number;
+    /**
     * Number of packets lost on the RTP stream.
     */
     packetsLost?: number;
@@ -895,7 +980,7 @@ type InboundRtpStats = {
     */
     jitter?: number;
     /**
-    * The MediaStream ID of the RTP stream.
+    * The media stream identification tag from the SDP media section.
     */
     mid?: string;
     /**
@@ -991,15 +1076,15 @@ type InboundRtpStats = {
     */
     bytesReceived?: number;
     /**
-    * Number of NACKs sent.
+    * Number of NACKs received.
     */
     nackCount?: number;
     /**
-    * Number of Full Intra Requests sent.
+    * Number of Full Intra Requests received.
     */
     firCount?: number;
     /**
-    * Number of Picture Loss Indications sent.
+    * Number of Picture Loss Indications received.
     */
     pliCount?: number;
     /**
@@ -1177,10 +1262,14 @@ type OutboundTrackSample = {
     */
     kind: string;
     /**
-    * Calculated score for track (details should be added to attachments)
+    * Calculated score for track (details should be added to scoreReasons)
     */
     score?: number;
     /**
+    * Reasons for the score calculation, mapping each reason to how much it contributed to the score
+    */
+    scoreReasons?: Record<string, number>;
+    /**
     * Additional information attached to this stats
     */
     attachments?: Record<string, unknown>;
@@ -1202,16 +1291,20 @@ type InboundTrackSample = {
     */
     kind: string;
     /**
-    * Calculated score for track (details should be added to attachments)
+    * Calculated score for track (details should be added to scoreReasons)
     */
     score?: number;
     /**
+    * Reasons for the score calculation, mapping each reason to how much it contributed to the score
+    */
+    scoreReasons?: Record<string, number>;
+    /**
     * Additional information attached to this stats
     */
     attachments?: Record<string, unknown>;
 };
 /**
-* docs
+* A sample containing statistics and metrics for a WebRTC peer connection
 */
 type PeerConnectionSample = {
     /**
@@ -1223,10 +1316,14 @@ type PeerConnectionSample = {
     */
     attachments?: Record<string, unknown>;
     /**
-    * Calculated score for peer connection (details should be added to attachments)
+    * Calculated score for peer connection (details should be added to scoreReasons)
     */
     score?: number;
     /**
+    * Reasons for the score calculation, mapping each reason to how much it contributed to the score
+    */
+    scoreReasons?: Record<string, number>;
+    /**
     * Inbound Track Stats items
     */
     inboundTracks?: InboundTrackSample[];
@@ -1239,19 +1336,19 @@ type PeerConnectionSample = {
     */
     codecs?: CodecStats[];
     /**
-    * Inbound RTPs
+    * Inbound RTP Stats
     */
     inboundRtps?: InboundRtpStats[];
     /**
-    * Remote Inbound RTPs
+    * Remote Inbound RTP Stats
     */
     remoteInboundRtps?: RemoteInboundRtpStats[];
     /**
-    * Outbound RTPs
+    * Outbound RTP Stats
     */
     outboundRtps?: OutboundRtpStats[];
     /**
-    * Remote Outbound RTPs
+    * Remote Outbound RTP Stats
     */
     remoteOutboundRtps?: RemoteOutboundRtpStats[];
     /**
@@ -1283,7 +1380,7 @@ type PeerConnectionSample = {
     */
     iceCandidatePairs?: IceCandidatePairStats[];
     /**
-    * Certificates
+    * Certificate Stats
     */
     certificates?: CertificateStats[];
 };
@@ -1308,10 +1405,14 @@ type ClientSample = {
     */
     attachments?: Record<string, unknown>;
     /**
-    * Calculated score for client (details should be added to attachments)
+    * Calculated score for client (details should be added to scoreReasons)
     */
     score?: number;
     /**
+    * Reasons for the score calculation, mapping each reason to how much it contributed to the score
+    */
+    scoreReasons?: Record<string, number>;
+    /**
     * Samples taken PeerConnections
     */
     peerConnections?: PeerConnectionSample[];
@@ -1585,6 +1686,24 @@ declare class ObservedOutboundRtp implements OutboundRtpStats {
     bitPerPixel: number;
     deltaPacketsSent: number;
     deltaBytesSent: number;
+    deltaFramesSent: number;
+    deltaFramesEncoded: number;
+    deltaKeyFramesEncoded: number;
+    deltaNackCount: number;
+    deltaPliCount: number;
+    deltaFirCount: number;
+    deltaRetransmittedPacketsSent: number;
+    deltaRetransmittedBytesSent: number;
+    deltaEncodeTime: number;
+    deltaQualityLimitationResolutionChanges: number;
+    /**
+     * `true` when the codec, encoder implementation or scalability mode changed in this tick.
+     *
+     * Chrome resets `packetsSent`/`bytesSent` on the SSRC when the codec switches
+     * (crbug.com/webrtc/5361), producing sawtooth spikes and negative bitrates. All deltas for the
+     * tick are suppressed so a codec change is never mistaken for a traffic event.
+     */
+    counterResetBoundary: boolean;
     remoteRttInMs?: number;
     remoteFractionLost?: number;
     remoteJitter?: number;
@@ -1599,6 +1718,241 @@ declare class ObservedOutboundRtp implements OutboundRtpStats {
     update(stats: OutboundRtpStats): void;
 }
 
+/**
+ * Small statistics helpers used by the aggregators and detectors.
+ *
+ * Rationale: a mean is a poor summary for call telemetry — one participant with a 1500 ms RTT
+ * skews the average for nine healthy ones. Detectors should reason with medians, high percentiles
+ * and "affected ratios" instead.
+ */
+/** A distribution summary of a numeric sample set. */
+type StatsSummary = {
+    count: number;
+    min: number;
+    max: number;
+    mean: number;
+    median: number;
+    p25: number;
+    p75: number;
+    p95: number;
+};
+/**
+ * The p-th percentile (0..1) using linear interpolation between closest ranks.
+ * Returns `undefined` for an empty input.
+ */
+declare function percentile(values: number[], p: number): number | undefined;
+/** The median (50th percentile). `undefined` for an empty input. */
+declare function median(values: number[]): number | undefined;
+/**
+ * Median absolute deviation: `median(|value - median(values)|)`. A robust alternative to standard
+ * deviation for describing how spread out `values` are — one wild outlier shifts a mean-based
+ * deviation a lot, but barely moves a median. `undefined` for an empty input.
+ */
+declare function medianAbsoluteDeviation(values: number[]): number | undefined;
+/**
+ * A robust z-score: how many (MAD-based) standard deviations `value` sits above/below the median of
+ * `baseline`.
+ *
+ * Uses the median and MAD instead of the mean and standard deviation so a handful of baseline
+ * outliers can't inflate the "normal" spread and mask a genuine spike — the same reasoning behind
+ * {@link summarize}'s percentiles applies here to a single scalar spread. `1.4826` is the constant
+ * that makes MAD estimate the standard deviation of a normal distribution, so the result reads on
+ * the same scale as a classic z-score.
+ *
+ * A classic z-score divides by zero once every baseline value is identical (`MAD === 0`). Here:
+ * `value` strictly above that constant baseline reads as `Infinity` — a spike with no precedent
+ * whatsoever, however small; `value` at or below it reads as `0`, indistinguishable from the (flat)
+ * baseline rather than a division error.
+ *
+ * ### Worked example
+ *
+ * A baseline of "share of clients reporting congestion", one entry per 10 s bucket, on a healthy
+ * fleet: `[0.02, 0.01, 0.03, 0.04, 0.02]`. Median `0.02`, MAD `0.01`, so the scale is
+ * `1.4826 * 0.01 ≈ 0.0148`.
+ *
+ * ```ts
+ * robustZScore(0.03, baseline);   // ≈ 0.67  — an ordinary bucket
+ * robustZScore(0.25, baseline);   // ≈ 15.5  — a quarter of the fleet at once; nothing like it before
+ * ```
+ *
+ * Now add one bad bucket to the *baseline* — `[0.02, 0.01, 0.03, 0.04, 0.02, 0.40]`. A mean/stddev
+ * z-score would absorb it: the mean climbs to `0.087` and the stddev to `~0.14`, so a genuine `0.25`
+ * spike scores about `1.2` and looks unremarkable. **One past incident would hide the next one.**
+ * Median and MAD barely move (median `0.025`, MAD `0.01`), so `0.25` still scores `≈15.2`. That
+ * resistance is the entire reason for this function.
+ *
+ * The `Infinity` case is not an edge case in practice — it is a fleet that has been perfectly quiet:
+ *
+ * ```ts
+ * robustZScore(0.10, [ 0, 0, 0, 0, 0 ]);   // Infinity — first congestion ever seen
+ * robustZScore(0, [ 0, 0, 0, 0, 0 ]);      // 0        — still nothing happening
+ * ```
+ *
+ * `Infinity` clears any finite threshold, which is intended: "we have never seen this" *is* the
+ * strongest possible statistical statement. It is also why a caller must gate on practical
+ * significance too — see `SfuCongestionDetector`, which additionally requires a minimum number of
+ * affected clients, so a single client on a quiet fleet cannot page anyone.
+ *
+ * `undefined` when `baseline` is empty — there is nothing to compare against.
+ */
+declare function robustZScore(value: number, baseline: number[]): number | undefined;
+/** Summarize a numeric sample set. Returns `undefined` for an empty input. */
+declare function summarize(values: number[]): StatsSummary | undefined;
+/**
+ * Linear-interpolated percentile of an **already ascending** array. The building block behind
+ * {@link percentile} and {@link summarize}; exported so callers computing several percentiles over
+ * the same data can sort once themselves.
+ *
+ * Passing an unsorted array yields a meaningless number rather than an error — sort first.
+ */
+declare function percentileOfSorted(sorted: number[], p: number): number;
+/**
+ * A counter-reset-safe delta: the increase of a cumulative counter between two observations.
+ *
+ * Returns `0` when the counter went backwards (reset / SSRC reuse) or when either side is missing.
+ * NOTE the guard is `>=` on **defined** values — a previous value of `0` is a perfectly valid
+ * baseline, so `0 -> 5` correctly yields `5` (using a truthiness check here silently drops the
+ * first interval of every counter, which is exactly when the first loss/freeze event happens).
+ */
+declare function counterDelta(previous: number | undefined, current: number | undefined): number;
+/**
+ * Pearson correlation of two equal-length series, clamped to `0..1`.
+ *
+ * Negative or undefined relationships read as `0`, because every caller here asks "does A follow B?"
+ * — an inverse relationship is not a weaker yes, it is a no.
+ */
+declare function correlation(xs: number[], ys: number[]): number;
+/** Per-step result of {@link pageHinkley}. */
+type PageHinkleyResult = {
+    /**
+     * The Page-Hinkley statistic after each observation, same length as the input — one value per
+     * `values[i]`, so `statistic[i]` is "how far the cumulative deviation has grown above its own
+     * historical low, using only `values[0..i]`". Never negative (it's a gap to a *minimum*), and
+     * `0` for as long as the process looks stable.
+     */
+    statistic: number[];
+    /**
+     * Index of the **first** observation whose statistic exceeded `lambda`, else `undefined`.
+     *
+     * This is a one-shot latch over the call's whole input: once found, later observations are not
+     * re-checked, even if the statistic subsequently falls back down (e.g. after a single transient
+     * spike — see the class doc example). "Is it *still* elevated right now" is a different
+     * question, answered by looking at the *tail* of {@link statistic}, or — for a live stream — by
+     * re-running this over a recent window each time (which is what `TrendTester` does) rather than
+     * over the whole history once.
+     */
+    changePointIndex?: number;
+    /** `true` when {@link changePointIndex} is defined. */
+    changeDetected: boolean;
+};
+/**
+ * Page-Hinkley test: sequential (online) detection of a sustained **increase** in the mean of
+ * `values` — "has this metric settled onto a durably higher level", as opposed to "did one sample
+ * come in high". A single noisy point should not read as a regression; ten points that are all a
+ * bit higher than before should.
+ *
+ * ### How it works
+ *
+ * At step `i`, three numbers are tracked:
+ *
+ * 1. `mean` — the running average of `values[0..i]` (**not** a fixed baseline — it is recomputed
+ *    from everything seen so far, including `values[i]` itself, which is what makes this
+ *    *adaptive*: after a real shift, `mean` keeps drifting up to meet the new level, and the
+ *    signal below fades back out on its own rather than staying triggered forever).
+ * 2. `cumulative` — running sum of `(values[i] - mean - delta)`. Subtracting `mean` centres each
+ *    term on "surprise relative to what we've seen so far"; subtracting `delta` on top means a
+ *    small positive surprise still nets to a *negative* contribution, so it doesn't accumulate.
+ * 3. `runningMinimum` — the lowest `cumulative` has ever been.
+ *
+ * The **Page-Hinkley statistic** is `cumulative - runningMinimum`: how far the running sum has
+ * climbed above its own historical floor. Pure noise pulls `cumulative` up and down around a flat
+ * trend, so the gap to `runningMinimum` stays small. A sustained increase pushes `cumulative`
+ * mostly one direction — up — so `runningMinimum` stops updating and the gap grows every step,
+ * crossing `lambda` once the shift is large/long enough to be sure it isn't noise. That first
+ * crossing is {@link PageHinkleyResult.changePointIndex}.
+ *
+ * ### Parameters
+ *
+ * - `delta` — the **drift tolerance** (in the same units as `values`, e.g. ms of RTT): how much of
+ *   a step-to-step increase is written off as noise rather than counted towards the cumulative sum.
+ *   `0` means even a razor-thin, consistent upward creep eventually accumulates enough to trigger;
+ *   raising it requires each observation to clear that bar above the running mean before it
+ *   contributes anything (see the class doc's hand-worked example — the same jump that triggers
+ *   with `delta: 0` is completely absorbed at `delta: 10`).
+ * - `lambda` — the **detection threshold** the statistic must exceed. It is in "surprise units" (a
+ *   sum of deviations, not a single observation's units), so there's no shortcut for picking it
+ *   other than trying it against representative data — see the RTT examples in `stats.spec.ts` for
+ *   a worked comparison of a low vs. a high `lambda` on the same series. Raising it delays
+ *   detection but makes a false positive from a lucky run of noise less likely.
+ *
+ * O(n) — one pass, unlike {@link mannKendall}'s O(n²). To detect a **decrease** instead of an
+ * increase, negate `values` before calling (or negate the result's meaning if you'd rather).
+ */
+declare function pageHinkley(values: number[], delta?: number, lambda?: number): PageHinkleyResult;
+/** Result of {@link mannKendall}. */
+type MannKendallResult = {
+    /** Sum of pairwise signs (`sign(values[j] - values[i])` for every `i < j`). */
+    s: number;
+    /** Variance of {@link s}, corrected for tied values. */
+    variance: number;
+    /** Standard-normal score derived from `s`. `0` when `s` is `0` — no evidence either way. */
+    z: number;
+    /** Two-tailed p-value for the null hypothesis "no monotonic trend". */
+    pValue: number;
+    /** `'increasing'` / `'decreasing'` when significant at `alpha`, else `'no-trend'`. */
+    trend: 'increasing' | 'decreasing' | 'no-trend';
+};
+/**
+ * Mann-Kendall trend test: a non-parametric test for a **monotonic** trend in `values`, without
+ * assuming a distribution or a constant rate of change — it only asks "are later values
+ * consistently larger (or smaller) than earlier ones more often than chance would allow".
+ *
+ * Every pair `i < j` votes `+1` (`values[j] > values[i]`), `-1` (`values[j] < values[i]`) or `0`
+ * (tie); `s` is the sum of those votes. Under the null hypothesis of no trend, `s` is
+ * approximately normal with mean `0` and a known variance (corrected here for tied values), which
+ * turns `s` into a Z score and a two-tailed p-value. `trend` is only `'increasing'` / `'decreasing'`
+ * when that p-value clears `alpha` — a handful of mostly-ascending points is exactly what noise
+ * looks like half the time, and this is what keeps that from reading as a trend.
+ *
+ * O(n²) (every pair is compared); fine for the small, per-tick sample counts detectors work with,
+ * not for large historical series.
+ */
+declare function mannKendall(values: number[], alpha?: number): MannKendallResult;
+/**
+ * Turns a Mann-Kendall `s` statistic and its `variance` into a Z score, p-value and verdict — the
+ * back half of {@link mannKendall}, split out so an incremental caller that maintains `s` /
+ * `variance` itself (e.g. over a sliding window, correcting for evicted points rather than
+ * recomputing every pair from scratch) doesn't have to reimplement the normal approximation.
+ */
+declare function mannKendallVerdict(s: number, variance: number, alpha?: number): Pick<MannKendallResult, 'z' | 'pValue' | 'trend'>;
+
+/** The per-receiver view the aggregator builds for one subscribed track. */
+type PublishedTrackReceivingDistributionEntry = {
+    numberOfReceivers: number;
+    numberOfHealthyReceivers: number;
+    numberOfDegradedReceivers: number;
+    /** degradedReceivers / receivers (0..1); `0` when there are no receivers. */
+    degradedRatio: number;
+    /** Distribution summaries across receivers (undefined when no receiver reported the metric). */
+    bitrate?: StatsSummary;
+    fractionLost?: StatsSummary;
+    jitter?: StatsSummary;
+    rttInMs?: StatsSummary;
+    jitterBufferDelayInMs?: StatsSummary;
+    concealmentRatio?: StatsSummary;
+    /** Fan-out counters: how many receivers saw the symptom, and the total across them. */
+    freezes: {
+        affectedReceivers: number;
+        total: number;
+    };
+    plis: {
+        affectedReceivers: number;
+        total: number;
+    };
+    concealment: {
+        affectedReceivers: number;
+    };
+};
 declare class ObservedOutboundTrack implements OutboundTrackSample {
     timestamp: number;
     readonly id: string;
@@ -1609,18 +1963,28 @@ declare class ObservedOutboundTrack implements OutboundTrackSample {
     private _visited;
     appData?: Record<string, unknown>;
     readonly remoteInboundTracks: Set<ObservedInboundTrack>;
+    readonly detectors: Detectors;
+    receivingDistribution?: PublishedTrackReceivingDistributionEntry;
     readonly calculatedScore: CalculatedScore;
     addedAt?: number | undefined;
     removedAt?: number | undefined;
     muted?: boolean;
     attachments?: Record<string, unknown> | undefined;
+    degradedReasons?: string[] | undefined;
+    bitrate?: number | undefined;
+    deltaPacketsSent?: number | undefined;
+    remoteFractionLost?: number | undefined;
+    remoteRttInMs?: number | undefined;
+    qualityLimitationReason?: string | undefined;
     constructor(timestamp: number, id: string, kind: MediaKind, _peerConnection: ObservedPeerConnection, _outboundRtps?: ObservedOutboundRtp[] | undefined, _mediaSource?: ObservedMediaSource | undefined);
     get score(): number | undefined;
     get visited(): boolean;
+    get degraded(): boolean;
     getPeerConnection(): ObservedPeerConnection;
     getOutboundRtps(): ObservedOutboundRtp[] | undefined;
     getMediaSource(): ObservedMediaSource | undefined;
     update(stats: OutboundTrackSample): void;
+    private createReceivingDistribution;
 }
 
 declare class ObservedInboundTrack implements InboundTrackSample {
@@ -1638,6 +2002,8 @@ declare class ObservedInboundTrack implements InboundTrackSample {
     removedAt?: number | undefined;
     muted?: boolean;
     attachments?: Record<string, unknown> | undefined;
+    degradationReasons: string[];
+    get degraded(): boolean;
     constructor(timestamp: number, id: string, kind: MediaKind, _peerConnection: ObservedPeerConnection, _inboundRtp?: ObservedInboundRtp | undefined, _mediaPlayout?: ObservedMediaPlayout | undefined);
     get score(): number | undefined;
     get visited(): boolean;
@@ -1645,6 +2011,7 @@ declare class ObservedInboundTrack implements InboundTrackSample {
     getInboundRtp(): ObservedInboundRtp | undefined;
     getMediaPlayout(): ObservedMediaPlayout | undefined;
     update(stats: InboundTrackSample): void;
+    private checkDegradation;
 }
 
 declare class ObservedRemoteOutboundRtp implements RemoteOutboundRtpStats {
@@ -1752,6 +2119,46 @@ declare class ObservedInboundRtp implements InboundRtpStats {
     deltaBytesReceived: number;
     deltaReceivedSamples: number;
     deltaSilentConcealedSamples: number;
+    deltaConcealedSamples: number;
+    deltaConcealmentEvents: number;
+    deltaFreezeCount: number;
+    deltaFreezesDuration: number;
+    deltaPliCount: number;
+    deltaNackCount: number;
+    deltaFirCount: number;
+    deltaPacketsDiscarded: number;
+    deltaFramesDecoded: number;
+    deltaFramesReceived: number;
+    deltaFramesRendered: number;
+    deltaFramesDropped: number;
+    deltaKeyFramesDecoded: number;
+    deltaDecodeTime: number;
+    deltaJitterBufferDelay: number;
+    deltaJitterBufferEmittedCount: number;
+    deltaRetransmittedPacketsReceived: number;
+    deltaFecPacketsReceived: number;
+    deltaFecPacketsDiscarded: number;
+    deltaPausesDuration: number;
+    /**
+     * Mean jitter-buffer delay for the frames/samples emitted in this tick (seconds), derived from
+     * the cumulative `jitterBufferDelay` / `jitterBufferEmittedCount` pair — the only correct way to
+     * read those two counters.
+     */
+    jitterBufferDelayInMs?: number;
+    /** Fraction of the samples received in this tick that were concealed (0..1). */
+    concealmentRatio?: number;
+    /** Fraction of the frames received in this tick that were dropped before rendering (0..1). */
+    framesDroppedRatio?: number;
+    /**
+     * `true` when the codec or decoder implementation changed in this tick.
+     *
+     * Chrome resets `packetsReceived`/`bytesReceived` on an SSRC when the codec switches
+     * (crbug.com/webrtc/5361, open since 2015), which shows up as a sawtooth spike or a negative
+     * rate. Every delta in this tick is therefore suppressed to `0` rather than reported as traffic
+     * — otherwise a room-wide codec rollout produces a synchronized fake-degradation alert across
+     * every participant at once.
+     */
+    counterResetBoundary: boolean;
     remoteRttInMs?: number;
     remoteBytesSent?: number;
     remotePacketsSent?: number;
@@ -1941,7 +2348,34 @@ declare class ObservedPeerConnection extends EventEmitter {
     sendingVideoBitrate: number;
     receivingAudioBitrate: number;
     receivingVideoBitrate: number;
+    /**
+     * Median round-trip time of the tick, in ms.
+     *
+     * Prefers {@link rtcpRttInMs} and falls back to {@link iceRttInMs}, so within one tick it always
+     * reports **one** kind of round trip. It used to be the median of both mixed together, which was
+     * a bug: the mixing ratio changed as streams came and went, so the value moved for reasons that
+     * had nothing to do with the network.
+     */
     currentRttInMs?: number;
+    /**
+     * RTT measured by ICE/STUN consent checks, in ms — the trip to **whatever terminates ICE**. In an
+     * SFU topology that is the SFU, so this is the client↔SFU leg, not client↔client.
+     */
+    iceRttInMs?: number;
+    /**
+     * RTT reported by RTCP receiver reports, in ms — an **end-to-end** media-path round trip.
+     *
+     * Not the same trip as {@link iceRttInMs}; the difference between the two is roughly the far side
+     * of the SFU (see {@link sfuHopRttInMs}).
+     */
+    rtcpRttInMs?: number;
+    /**
+     * `rtcpRttInMs - iceRttInMs`, when both are known — an estimate of everything *past* the SFU.
+     *
+     * Useful for splitting "this client's own last mile is slow" (high `iceRttInMs`) from "the path
+     * beyond the SFU is slow" (low ICE, high hop).
+     */
+    sfuHopRttInMs?: number;
     currentJitter?: number;
     usingTCP: boolean;
     usingTURN: boolean;
@@ -2036,6 +2470,487 @@ type OperationSystem = {
     version: string;
 };
 
+/**
+ * Turning a correlation into a **conclusion**.
+ *
+ * Every detector in this library ultimately reports the same shape of observation: *N clients have
+ * issue X open at once, and here is what they have in common*. That is useful but not yet
+ * actionable — someone still has to know that congestion spread across unrelated calls means the
+ * server, while CPU limitation spread across unrelated calls means a bad client release. This module
+ * holds that interpretation step so it is stated once, consistently, instead of being re-derived by
+ * whoever reads the alert at 3am.
+ *
+ * ### Two functions, because there are two questions
+ *
+ * A detector already knows its scope — it was constructed with an `ObservedCall` or with the
+ * `Observer`. Handing that scope back to a single generic function meant every caller supplied
+ * fields the other scope needed and its own scope ignored: a call-scoped detector passing
+ * `affectedCalls: 1, totalCalls: 1` forever, an observer-scoped one passing a participant ratio that
+ * was deliberately never read. Placeholders like that are a standing invitation to read them as if
+ * they meant something.
+ *
+ * So there are two entry points, each taking only the facts its scope actually has:
+ *
+ * - {@link concludeCallIssue} — within one call. The axis is *how much of the meeting*, and whether
+ *   the affected clients all subscribe to one published track.
+ * - {@link concludeObserverIssue} — across calls. The axis is *how many independent calls*, which is
+ *   the only thing that separates "one bad room" from "our infrastructure".
+ *
+ * Neither the issue family nor the spread concludes anything alone: congestion in one call is a
+ * meeting problem, congestion in six calls is an infrastructure problem, and the issue type is
+ * identical in both.
+ */
+/** Where the fault most likely sits, given who is affected. */
+type IssueFaultDomain = 
+/** Independent calls affected at once — they share only the servers and the network. */
+'infrastructure'
+/** One call, broadly affected — something that call shares (its SFU worker, room, or host). */
+ | 'call'
+/** The subscribers of one published track — the publisher's path or the forwarding of it. */
+ | 'published-track'
+/** A single endpoint — its own device or last mile. */
+ | 'endpoint'
+/** Independent calls affected, but by something endpoints own — a client build, not a server. */
+ | 'client-population'
+/** Not enough signal to attribute. */
+ | 'unknown';
+/** A stated verdict, attached to the raised issue payload. */
+type IssueConclusion = {
+    /** Where to look. */
+    faultDomain: IssueFaultDomain;
+    /** One line, written to be readable in an alert without opening a dashboard. */
+    summary: string;
+    /** What to check first. Omitted when the issue family is unknown to this module. */
+    recommendation?: string;
+    /**
+     * How much the spread alone justifies the verdict, `0..1`. Not a probability — a coarse ranking
+     * so alerting can threshold on it. More independent calls, or a tighter onset, means higher.
+     */
+    confidence: number;
+};
+/** The facts a **call-scoped** conclusion is drawn from. */
+type CallIssueSpread = {
+    issueType: string;
+    /** Distinct clients of this call with the issue open. */
+    affectedClients: number;
+    /** Participants in the call — the denominator. */
+    totalClients: number;
+    /** True when the onsets clustered — a shared trigger rather than drift. */
+    onsetBurst: boolean;
+    /**
+     * Set when the affected clients are the subscriber set of **one published track**.
+     *
+     * The strongest call-scoped statement available: those clients share a publisher and nothing
+     * else, so the receivers are exonerated and the source's path is implicated.
+     */
+    publishedTrackId?: string;
+};
+/** The facts an **observer-scoped** conclusion is drawn from. */
+type ObserverIssueSpread = {
+    issueType: string;
+    /** Distinct clients across the fleet with the issue open. */
+    affectedClients: number;
+    /** Clients in the fleet. Reported for context; it does not gate anything at this scope. */
+    totalClients: number;
+    /** Distinct calls containing at least one affected client. The dimension that matters here. */
+    affectedCalls: number;
+    /** Calls in flight. */
+    totalCalls: number;
+    /** True when the onsets clustered. */
+    onsetBurst: boolean;
+};
+/**
+ * Draw the conclusion for a group of clients **within one call**.
+ *
+ * Ordered most-to-least specific: a track-scoped group is a stronger statement than a call-wide one,
+ * and a single affected endpoint is not a statement about the call at all.
+ */
+declare function concludeCallIssue(spread: CallIssueSpread): IssueConclusion;
+/**
+ * Draw the conclusion for a group of clients spanning **several calls**.
+ *
+ * One affected call is not an observer-scoped finding — it has an obvious local explanation and the
+ * call-scoped detector has already reported it — so that case returns `call` and says so rather than
+ * dressing it up as a fleet event.
+ *
+ * Which domain breadth implicates depends on the family, and this is the whole reason the module
+ * exists: `congestion` across unrelated calls points at the servers, `cpulimitation` across unrelated
+ * calls points at what those *endpoints* share — a client release, a browser version, shared
+ * virtualised hardware — and pointing an SFU team at the second one wastes a night.
+ */
+declare function concludeObserverIssue(spread: ObserverIssueSpread): IssueConclusion;
+
+/**
+ * What every server-raised finding carries, whatever raised it.
+ *
+ * ### Why this is not `ClientIssue`
+ *
+ * `ClientIssue` is a **wire** type: it arrives inside a `ClientSample`, so its `payload` is bound to
+ * what the schema can carry — a record of primitives since schema 3.5.0, a JSON string on samples
+ * from earlier clients. Server-raised findings were reusing it, which forced every detector to `JSON.stringify` a
+ * perfectly good object on the way out and every handler to `JSON.parse` it back on the way in —
+ * paying serialisation on a path where nothing is ever serialised, and losing type information in
+ * both directions. These go straight to an in-process handler, so they carry the object.
+ */
+type IssueBase = {
+    /** What was found, e.g. `'CROSS_CALL_ISSUE_ONSET_BURST'`. */
+    type: string;
+    /** Observer clock, when the finding was raised. */
+    timestamp: number;
+    /**
+     * What the finding *means* — where to look, and how much the evidence justifies it.
+     *
+     * A first-class field rather than a key inside {@link payload}, because it is the one part every
+     * finding has in common and the one part an alerting rule reads. Burying it in the evidence made
+     * `payload.conclusion.faultDomain` the path to the most important thing in the object.
+     */
+    conclusion?: IssueConclusion;
+    /**
+     * The evidence, and **only** the evidence.
+     *
+     * Deliberately does not repeat `type`, `scope`, or the ids already present on the event that
+     * delivers it. A payload that restates its envelope invites the two to disagree — and they did,
+     * because nothing kept them in step.
+     */
+    payload?: Record<string, unknown>;
+};
+/**
+ * A finding about **one call**, raised by `observedCall.addIssue()` and delivered as `call-issue`.
+ *
+ * The call is the event's scope (`{ observedCall, observer }`), so the payload does not carry a
+ * `callId` — read it from the event.
+ */
+type CallIssue = IssueBase & {
+    scope: 'call';
+};
+/**
+ * A finding about the **fleet**, raised by `observer.addIssue()` and delivered as `observer-issue`.
+ *
+ * Raised by detectors and validators that reason across calls, so no single call owns it. Where the
+ * finding does concern specific calls — a cross-call correlation, say — they are named in the
+ * evidence, because that *is* the evidence.
+ */
+type ObserverIssue = IssueBase & {
+    scope: 'observer';
+};
+/**
+ * Either kind, discriminated by {@link IssueBase} + `scope`.
+ *
+ * `scope` is on the issue and not merely implied by which event fired, so a finding stays
+ * self-describing once it leaves the bus — funnelled into one handler, a log line, or a queue.
+ */
+type Issue = CallIssue | ObserverIssue;
+/**
+ * The payload as a JSON string, for the boundaries that genuinely need text — a log line, an HTTP
+ * body, a message queue.
+ *
+ * Returns `undefined` for a missing payload, or for one that cannot be serialised (a circular
+ * reference from something an application attached): the caller wanted text, not an exception.
+ */
+declare function issuePayloadAsString(issue: Pick<IssueBase, 'payload'>): string | undefined;
+
+/**
+ * The bus events that carry an `observedCall`, i.e. the ones an enricher can attribute to a summary.
+ *
+ * Derived from the event map rather than listed by hand, so it cannot drift: adding a call-scoped
+ * event makes it enrichable automatically, and an enricher on an observer-scoped event
+ * (`observer-issue`, `validation-ready`) will not compile — there is no single call it belongs to,
+ * and quietly writing a fleet-wide fact into every open summary would be worse than a type error.
+ */
+type CallScopedEventName = {
+    [K in keyof ObserverEvents]: ObserverEvents[K][0] extends ObservedCallScope ? K : never;
+}[keyof ObserverEvents];
+/** A function that folds one event into the summary. Runs on every occurrence, for its own call. */
+type CallSummaryEnricher<K extends CallScopedEventName> = (summary: CallSummary, ...args: ObserverEvents[K]) => void;
+/** The enricher map: any subset of the call-scoped events, each fully typed against its payload. */
+type CallSummaryEnrichers = {
+    [K in CallScopedEventName]?: CallSummaryEnricher<K>;
+};
+/** The built-in sections. Ask for what you want; anything absent is simply not collected. */
+type CallSummarySection = 'clients' | 'issues' | 'turnServers' | 'scores';
+type CallSummaryConfig = {
+    /**
+     * Which built-in sections to accumulate. Empty (the default) collects none of them — a summary
+     * with only `enrich` is a perfectly good summary.
+     */
+    include: CallSummarySection[];
+    /**
+     * 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 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`.
+     *
+     * 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;
+};
+/**
+ * Who was in the call over its whole life — not just who is in it now.
+ *
+ * Deliberately identifiers and counts only. Anything *about* a client — browser, platform, region —
+ * is already on `observedClient` while the call is live, and belongs in `attachments` via an enricher
+ * if you want it kept. Duplicating it here would mean the library deciding which client attributes
+ * matter, and it would mean reading the highest-frequency event on the bus to do it.
+ */
+type CallSummaryClients = {
+    /** Every client id seen, in join order, capped by `maxClientIds`. */
+    clientIds: string[];
+    /** The most participants present at any one moment. */
+    peak: number;
+    joined: number;
+    left: number;
+};
+/** Which TURN relays carried this call's media. */
+type CallSummaryTurnServers = {
+    serverUrls: string[];
+    /** Distinct clients seen relaying through any of them. */
+    clientsRelayed: number;
+};
+/** The call score over time. Percentiles, not a mean — see `utils/stats`. */
+type CallSummaryScores = {
+    min?: number;
+    max?: number;
+    median?: number;
+    /** How many score readings went into the above. `0` means nothing was measured. */
+    samples: number;
+};
+/** What had to be dropped to stay within the caps. Absent when nothing was. */
+type CallSummaryTruncation = {
+    issues?: number;
+    clientIds?: number;
+};
+/**
+ * An accumulating record of one call's life, finalised when the call closes.
+ *
+ * ### Why this exists
+ *
+ * Everything else in this library is about *now*. Detectors answer "is something wrong right now",
+ * validators answer a structural question once, and both read state that the call throws away when
+ * it ends. Nothing kept the answer to *"what happened in that meeting?"* — who was in it, what was
+ * raised, how it scored — and that is the question asked after the call, by support, by billing, by
+ * whoever is writing the incident note.
+ *
+ * ### It is opt-in, and its sections are opt-in
+ *
+ * `observedCall.summary` is `undefined` unless a summary was configured, and each section is present
+ * only if it was requested. **An absent section means "not collected", never "nothing happened"** —
+ * the same rule as `inconclusive` on a validator. Reading `summary.issues` as "this call had no
+ * issues" when `'issues'` was never in `include` is the one misreading this type invites, so it does
+ * not offer a default-empty section to make it easy.
+ *
+ * ### Read it live, receive it once
+ *
+ * The object is live: read `observedCall.summary` at any point during the call. It is also delivered
+ * on the `call-summary` event, emitted inside `close()` while the call is still reachable — after
+ * that the call is gone from `observer.observedCalls` and there is nothing left to ask.
+ */
+type CallSummary = {
+    callId: string;
+    /** First client join (client clock), as `ObservedCall` computed it. */
+    startedAt?: number;
+    /** Last client leave. */
+    endedAt?: number;
+    /** `endedAt - startedAt`, when both are known. */
+    durationInMs?: number;
+    /** When the summary itself was finalised (observer clock). Set by `close()`. */
+    closedAt?: number;
+    clients?: CallSummaryClients;
+    /**
+     * Every issue raised against this call, in the order they were raised, capped by `maxIssues`.
+     *
+     * Just the issues — no derived tallies. A count is `issues.length`, a per-type count is one
+     * `filter`, and either is cheaper to write at the call site than to keep correct here. The one
+     * thing you cannot derive is what the cap discarded, which is why `truncated.issues` exists:
+     * the issues actually raised is `issues.length + (truncated?.issues ?? 0)`.
+     */
+    issues?: CallIssue[];
+    turnServers?: CallSummaryTurnServers;
+    scores?: CallSummaryScores;
+    /**
+     * Whatever your enrichers put here. The library never writes to it, so it cannot collide with a
+     * section added in a future version.
+     *
+     * **`attachments`, not `appData`, and the distinction is load-bearing.** `appData` is the live
+     * working state an application hangs off an entity for the entity's lifetime, and it may hold
+     * references that cannot be serialised — a mediasoup router, an `RTCPeerConnection`, a socket. A
+     * summary is the opposite: it outlives the call precisely so it can be *shipped* — archived,
+     * queued, written to a column — and it is handed to you on `call-summary` at the moment the call
+     * it came from is being torn down. Anything unserialisable in it is a reference to something
+     * already gone.
+     *
+     * So put serialisable facts here, the same contract as `attachments` on a `ClientSample`. If you
+     * need the live object, read it off `observedCall` / `observedClient` inside the enricher and
+     * attach what you can serialise: the router's `id`, not the router.
+     */
+    attachments: Record<string, unknown>;
+    /**
+     * What the caps discarded, and how much.
+     *
+     * Present **only** when something was actually dropped. A silently truncated summary is worse
+     * than no summary — someone will count `log.length` and report it as the issue count — so the
+     * shortfall is stated rather than left to be inferred from a suspiciously round number.
+     */
+    truncated?: CallSummaryTruncation;
+};
+/** The defaults a summary is created with. Caps are generous but finite; see {@link CallSummary}. */
+declare const defaultCallSummaryConfig: CallSummaryConfig;
+/** A fresh summary for `callId`, with only the requested sections present. */
+declare function createCallSummary(callId: string, config: CallSummaryConfig): CallSummary;
+
+/**
+ * What a validator concluded, once it is done.
+ *
+ * `S` is the validator's own payload — a discriminated union on `verdict` plus whatever evidence
+ * belongs to each outcome — so a report reads in the language of the thing being checked rather than
+ * in generic pass/fail.
+ *
+ * Note this is a plain intersection with `S`, not `{ [K in keyof S]: S[K] }`. A mapped type over a
+ * union collapses to the keys its members *share* (`keyof (A | B)` is the intersection), which would
+ * silently drop every per-verdict evidence field and leave only `verdict` behind.
+ */
+type ValidationReport<S extends Record<string, unknown> = Record<string, unknown>> = 
+/** Still running — it has not seen the conditions it needs to judge anything yet. */
+{
+    ready: false;
+}
+/** Done. `verdict` is narrowed by `S` to that validator's own vocabulary. */
+ | ({
+    ready: true;
+    verdict: string;
+    decidedAt: number;
+} & S);
+/**
+ * A **one-shot structural check**: something true of the deployment rather than of this moment.
+ *
+ * The distinction from a `Detector` is what changes over time. A detector answers "is something wrong
+ * *right now*" — congestion, a dead relay, a track nobody receives — and the answer legitimately
+ * differs every tick, so it runs every tick, forever. A validator answers "is this deployment built
+ * correctly" — does the SFU pick layers per receiver — and that only changes when you deploy. So a
+ * validator **runs until it knows, then finishes**: it calls {@link onDone} once, the observer drops
+ * it, and nothing more is computed.
+ *
+ * To check again — after a deploy, say — start a new one with `observer.addValidator(...)`. There is
+ * no revalidation timer, because a deploy, not the passage of time, is what makes a structural
+ * verdict stale.
+ *
+ * Validators are held in `observer.validators` and driven by `observer.update()`.
+ */
+interface Validator<S extends Record<string, unknown> = Record<string, unknown>> {
+    readonly name: string;
+    /**
+     * The conclusion so far. `{ ready: false }` until {@link onDone} fires — and **that is not a
+     * pass**. A validator usually needs specific conditions to occur before it can judge anything,
+     * and plenty of deployments never present them.
+     */
+    readonly report: ValidationReport<S>;
+    /** Called exactly once, when the validator finishes. The observer uses this to unregister it. */
+    onDone: (report: ValidationReport<S>) => void;
+    /** Gather evidence; decide if there is now enough. Called on every `observer.update()`. */
+    update(): void;
+    /**
+     * Give up without a verdict. Finishes with `inconclusive`, so a caller waiting on it is freed.
+     *
+     * `reason` is carried into the report. Worth passing something specific — "cancelled" tells the
+     * reader nothing, whereas "sfu redeployed" explains why a check that was running has no verdict.
+     */
+    cancel: (reason?: string) => void;
+}
+/**
+ * The part of a validator the observer needs in order to drive it.
+ *
+ * `Validator<S>` is invariant in `S` — `onDone` takes a `ValidationReport<S>` and `report` returns one
+ * — so a `Set<Validator>` cannot hold validators with different payloads. Driving one only needs the
+ * three members that don't mention `S`.
+ */
+type RunningValidator = Pick<Validator, 'name' | 'update' | 'cancel'>;
+
+/** The suffix client-monitor-js appends to the type of a resolution entry. */
+declare const RESOLVED_ISSUE_SUFFIX = "-resolved";
+/**
+ * A **stateful** client issue the server currently believes to be open.
+ *
+ * client-monitor-js (>= 4.6.0, `sendResolvedIssuesToServer`) puts an issue's whole lifecycle on the
+ * wire as two entries sharing a `key`:
+ *
+ * ```
+ * raise:      { type: 'stuck-decoder',          key, payload,                                timestamp: raisedAt }
+ * resolution: { type: 'stuck-decoder-resolved', key, payload: { raisedAt, comment, …final }, timestamp: resolvedAt }
+ * ```
+ *
+ * The observer opens an `ActiveClientIssue` on the raise and closes it on the matching key, which
+ * turns a stream of point-in-time symptom reports into **intervals**. That is what makes the
+ * difference between "several clients reported congestion in the last 10 seconds" (a guess built on
+ * an arbitrary window) and "several clients are congested *right now, simultaneously*" — the latter
+ * being real evidence of a shared cause.
+ *
+ * Issues still active when the client monitor closes are auto-resolved by the client, so a clean
+ * departure does not leak.
+ */
+type ActiveClientIssue = {
+    /** Identity shared by the raise and its resolution. Unique per client. */
+    key: string;
+    /** The issue type **without** the `-resolved` suffix (e.g. `'congestion'`). */
+    type: string;
+    /** The client that reported it. */
+    clientId: string;
+    /**
+     * The call that client belongs to. The dimension that separates "one bad meeting" from "our
+     * infrastructure": at observer scope, clients in *different* calls share nothing but the server.
+     */
+    callId: string;
+    /** When the client raised it (client clock). */
+    raisedAt: number;
+    /** When the observer first saw it (server clock) — skew-free, use this for cross-client timing. */
+    observedAt: number;
+    /** Parsed raise payload, when it was JSON. */
+    payload?: Record<string, unknown>;
+    /** `payload.peerConnectionId`, when present — most client detectors report it. */
+    peerConnectionId?: string;
+    /** `payload.trackId`, when present — the join key to a track (and thus to a publisher). */
+    trackId?: string;
+};
+/** A closed interval: an {@link ActiveClientIssue} plus how it ended. */
+type ResolvedActiveClientIssue = ActiveClientIssue & {
+    /** When the client resolved it (client clock). */
+    resolvedAt: number;
+    /** Observer-clock resolution time. */
+    observedResolvedAt: number;
+    /** `resolvedAt - raisedAt` as reported by the client, else derived from observer clocks. */
+    durationInMs: number;
+    /** Free-form note passed to `resolveIssue`. */
+    comment?: string;
+    /** Payload explicitly passed at resolution (the built-in detectors pass their final payload). */
+    resolutionPayload?: Record<string, unknown>;
+    /**
+     * How the interval ended: the client said so, the observer expired it, or the client left
+     * without resolving.
+     */
+    resolvedBy: 'client' | 'timeout' | 'client-closed';
+};
+/** `true` when the entry is a resolution companion rather than a raise. */
+declare function isClientIssueResolutionEntry(issue: ClientIssue): boolean;
+/** Strip the `-resolved` suffix, so both entries of a lifecycle share one logical type. */
+declare function baseIssueType(type: string): string;
+
 /** The lifecycle events a sink may emit (a subset of Node's writable-stream events). */
 type ClientSampleSinkEvents = {
     /** The destination is fully written and closed (e.g. a file flushed and its fd closed). */
@@ -2103,11 +3018,11 @@ type RtpCodecParameters = {
         parameter?: string;
     }[];
 };
-type SampleHistoryItem<T extends string> = Record<string, unknown> & {
+type SampleHistoryItem<T extends string> = {
     type: T;
     timestamp: number;
 };
-type MediasoupRouterSample = Record<string, unknown> & {
+type MediasoupRouterSample = {
     routerId: string;
     attachments: Record<string, unknown>;
     createdAt: number;
@@ -2151,7 +3066,9 @@ type MediasoupDirectTransportSample = {
     type: 'direct';
     history: MediasoupDirectTransportSampleEventMap[];
 };
-type MediasoupTransportSample = Record<string, unknown> & {
+type MediasoupTransportSample = {
+    /** Free-form application data. Attach anything here — see `ObservedMediasoupRouter`. */
+    attachments?: Record<string, unknown>;
     id: string;
     createdAt: number;
     connectedAt?: number;
@@ -2167,7 +3084,9 @@ type MediasoupProducerSampleEventMap = {
 type MediasoupProducerSampleEvent = {
     [K in keyof MediasoupProducerSampleEventMap]: SampleHistoryItem<K>;
 }[keyof MediasoupProducerSampleEventMap];
-type MediasoupProducerSample = Record<string, unknown> & {
+type MediasoupProducerSample = {
+    /** Free-form application data. Attach anything here — see `ObservedMediasoupRouter`. */
+    attachments?: Record<string, unknown>;
     id: string;
     transportId: string;
     createdAt: number;
@@ -2191,7 +3110,9 @@ type MediasoupConsumerSampleEventMap = {
 type MediasoupConsumerSampleEvent = {
     [K in keyof MediasoupConsumerSampleEventMap]: SampleHistoryItem<K>;
 }[keyof MediasoupConsumerSampleEventMap];
-type MediasoupConsumerSample = Record<string, unknown> & {
+type MediasoupConsumerSample = {
+    /** Free-form application data. Attach anything here — see `ObservedMediasoupRouter`. */
+    attachments?: Record<string, unknown>;
     id: string;
     producerId: string;
     transportId: string;
@@ -2200,7 +3121,9 @@ type MediasoupConsumerSample = Record<string, unknown> & {
     kind: 'audio' | 'video';
     history: MediasoupConsumerSampleEvent[];
 };
-type MediasoupDataProducerSample = Record<string, unknown> & {
+type MediasoupDataProducerSample = {
+    /** Free-form application data. Attach anything here — see `ObservedMediasoupRouter`. */
+    attachments?: Record<string, unknown>;
     id: string;
     transportId: string;
     createdAt: number;
@@ -2208,7 +3131,9 @@ type MediasoupDataProducerSample = Record<string, unknown> & {
     label: string;
     protocol: string;
 };
-type MediasoupDataConsumerSample = Record<string, unknown> & {
+type MediasoupDataConsumerSample = {
+    /** Free-form application data. Attach anything here — see `ObservedMediasoupRouter`. */
+    attachments?: Record<string, unknown>;
     id: string;
     dataProducerId: string;
     transportId: string;
@@ -2218,30 +3143,142 @@ type MediasoupDataConsumerSample = Record<string, unknown> & {
     protocol: string;
 };
 
+/**
+ * Declarative enrichment: return the `attachments` to stamp onto an entity's sample the moment it is
+ * created. Called once per entity, before the corresponding `*-sample-added` event.
+ *
+ * The mediasoup object is handed in, so the common case — mirroring mediasoup's own `appData`, where
+ * applications already keep `participantId`, `purpose` and friends — is a one-liner. Returning
+ * `undefined` attaches nothing.
+ */
+type MediasoupSampleEnricher = {
+    transport?: (transport: types.Transport) => Record<string, unknown> | undefined;
+    producer?: (producer: types.Producer, transport: types.Transport) => Record<string, unknown> | undefined;
+    consumer?: (consumer: types.Consumer, transport: types.Transport) => Record<string, unknown> | undefined;
+    dataProducer?: (dataProducer: types.DataProducer, transport: types.Transport) => Record<string, unknown> | undefined;
+    dataConsumer?: (dataConsumer: types.DataConsumer, transport: types.Transport) => Record<string, unknown> | undefined;
+};
 type ObservedMediasoupRouterSettings<AppData extends Record<string, unknown> = Record<string, unknown>> = {
-    routerId: string;
     router: types.Router;
     appData?: AppData;
     attachments?: Record<string, unknown>;
+    /** Stamp `attachments` onto each entity sample as it is created. See {@link MediasoupSampleEnricher}. */
+    enrich?: MediasoupSampleEnricher;
 };
+/**
+ * Lifecycle hooks for building your own report.
+ *
+ * Each entity announces itself as `<entity>-sample-added` when it appears and
+ * `<entity>-sample-closed` when it goes away, carrying **the live sample object** plus the mediasoup
+ * object it came from. Mutating `sample.attachments` inside a handler is the intended way to extend
+ * a sample on the fly — the object you receive is the one held in `observedRouter.sample`, not a copy.
+ */
 type ObservedMediasoupRouterEvents = {
     close: [];
-};
+    'transport-sample-added': [{
+        sample: MediasoupTransportSample;
+        transport: types.Transport;
+    }];
+    'transport-sample-closed': [{
+        sample: MediasoupTransportSample;
+        transport: types.Transport;
+    }];
+    'producer-sample-added': [{
+        sample: MediasoupProducerSample;
+        producer: types.Producer;
+        transport: types.Transport;
+    }];
+    'producer-sample-closed': [{
+        sample: MediasoupProducerSample;
+        producer: types.Producer;
+        transport: types.Transport;
+    }];
+    'consumer-sample-added': [{
+        sample: MediasoupConsumerSample;
+        consumer: types.Consumer;
+        transport: types.Transport;
+    }];
+    'consumer-sample-closed': [{
+        sample: MediasoupConsumerSample;
+        consumer: types.Consumer;
+        transport: types.Transport;
+    }];
+    'data-producer-sample-added': [{
+        sample: MediasoupDataProducerSample;
+        dataProducer: types.DataProducer;
+        transport: types.Transport;
+    }];
+    'data-producer-sample-closed': [{
+        sample: MediasoupDataProducerSample;
+        dataProducer: types.DataProducer;
+        transport: types.Transport;
+    }];
+    'data-consumer-sample-added': [{
+        sample: MediasoupDataConsumerSample;
+        dataConsumer: types.DataConsumer;
+        transport: types.Transport;
+    }];
+    'data-consumer-sample-closed': [{
+        sample: MediasoupDataConsumerSample;
+        dataConsumer: types.DataConsumer;
+        transport: types.Transport;
+    }];
+};
 declare interface ObservedMediasoupRouter {
     on<U extends keyof ObservedMediasoupRouterEvents>(event: U, listener: (...args: ObservedMediasoupRouterEvents[U]) => void): this;
     off<U extends keyof ObservedMediasoupRouterEvents>(event: U, listener: (...args: ObservedMediasoupRouterEvents[U]) => void): this;
     once<U extends keyof ObservedMediasoupRouterEvents>(event: U, listener: (...args: ObservedMediasoupRouterEvents[U]) => void): this;
     emit<U extends keyof ObservedMediasoupRouterEvents>(event: U, ...args: ObservedMediasoupRouterEvents[U]): boolean;
 }
+/**
+ * Observes a live mediasoup `Router` by subscribing to its `observer` API and **accumulates** its
+ * topology and lifecycle into an in-memory `MediasoupRouterSample` (`observedRouter.sample`):
+ * transports, producers, consumers, data producers/consumers, their state-change history and
+ * `createdAt` / `closedAt`. The sample grows for the life of the router (closed entities are kept,
+ * with their `closedAt` set) and is yours to read, snapshot, or persist.
+ *
+ * NOTE: this is intentionally the simplest approach — everything is held in memory. For very large
+ * routers (e.g. ~100 participants producing and consuming on one router, where consumers grow as
+ * O(N²)) this can become substantial; in that case do your own periodic sampling/persistence and
+ * discard what you don't need (see the README's "Memory & large meetings" note).
+ */
 declare class ObservedMediasoupRouter<AppData extends Record<string, unknown> = Record<string, unknown>> extends EventEmitter {
     readonly router: types.Router;
-    readonly sample: MediasoupRouterSample;
     appData: AppData;
+    readonly sample: MediasoupRouterSample;
     readonly webrtcTransportIds: Set<string>;
-    get attachments(): Record<string, unknown>;
     closed: boolean;
+    private readonly _transportSamples;
+    private readonly _producerSamples;
+    private readonly _consumerSamples;
+    private readonly _dataProducerSamples;
+    private readonly _dataConsumerSamples;
+    private readonly _enrich?;
     constructor(settings: ObservedMediasoupRouterSettings<AppData>);
     get id(): string;
+    get attachments(): Record<string, unknown>;
+    getTransportSample(id: string): MediasoupTransportSample | undefined;
+    getProducerSample(id: string): MediasoupProducerSample | undefined;
+    getConsumerSample(id: string): MediasoupConsumerSample | undefined;
+    getDataProducerSample(id: string): MediasoupDataProducerSample | undefined;
+    getDataConsumerSample(id: string): MediasoupDataConsumerSample | undefined;
+    /**
+     * Merge `attachments` into an entity's sample, whichever kind it is.
+     *
+     * Ids are unique across mediasoup entity kinds, so one method covers all of them. Returns `false`
+     * when the id is unknown — a real answer instead of failing quietly, which matters when the
+     * annotation is driven by application events that may race the mediasoup ones.
+     */
+    attachTo(id: string, attachments: Record<string, unknown>): boolean;
+    /**
+     * A **detached deep copy** of the current sample — the basis for building your own report.
+     *
+     * `this.sample` is live: its arrays grow and its `history` entries are appended as the router
+     * runs, so a report built directly on it keeps changing after you think you're done. This returns
+     * a snapshot that never moves.
+     */
+    snapshot(): MediasoupRouterSample;
+    close(): void;
     addTransport: (transport: types.Transport) => void;
     addWebRtcTransport(transport: types.WebRtcTransport): void;
     addPlainTransport(transport: types.PlainTransport): void;
@@ -2251,8 +3288,19 @@ declare class ObservedMediasoupRouter<AppData extends Record<string, unknown> =
     addConsumer(transport: types.Transport, consumer: types.Consumer): void;
     addDataProducer(transport: types.Transport, dataProducer: types.DataProducer): void;
     addDataConsumer(transport: types.Transport, dataConsumer: types.DataConsumer): void;
-    close(): void;
     private attachRouterListeners;
+    private _addTransportSample;
+    private _addProducerSample;
+    private _addConsumerSample;
+    private _addDataProducerSample;
+    private _addDataConsumerSample;
+    /**
+     * Run an enricher and merge what it returns.
+     *
+     * Takes a thunk rather than a value so the **invocation** is inside the guard — application code
+     * runs here, and a throwing enricher must not take the router's bookkeeping down with it.
+     */
+    private _applyEnrichment;
     private _attachTransportObserverListeners;
 }
 
@@ -2293,16 +3341,36 @@ type ObserverEvents = {
         reason: SampleRejectedReason;
         sample: ClientSample;
     }];
+    /** An observer-scoped (cross-call / SFU-wide) finding raised by `observer.addIssue(...)`. */
+    'observer-issue': [ObserverEventBase & {
+        issue: ObserverIssue;
+    }];
+    /**
+     * A validator decided. Fires once per settle, not per tick — the point of a validator is that it
+     * stops talking once it knows.
+     */
+    'validation-ready': [ObserverEventBase & {
+        validator: string;
+        report: ValidationReport;
+    }];
     'mediasoup-router-added': [ObservedMediasoupRouterScope];
     'mediasoup-router-removed': [ObservedMediasoupRouterScope];
-    'mediasoup-router-matched-with-call': [ObservedMediasoupRouterScope & ObservedCallScope];
+    'mediasoup-router-matched-with-peer-connection': [ObservedMediasoupRouterScope & ObservedPeerConnectionScope];
     'call-added': [ObservedCallScope];
     'call-updated': [ObservedCallScope];
     'call-closed': [ObservedCallScope];
     'call-empty': [ObservedCallScope];
     'call-not-empty': [ObservedCallScope];
     'call-issue': [ObservedCallScope & {
-        issue: ClientIssue;
+        issue: CallIssue;
+    }];
+    /**
+     * A call's summary was finalised. Emitted from inside `close()`, while the call is still in
+     * `observer.observedCalls` — after that there is nothing left to ask. Only fires for calls that
+     * had a summary configured.
+     */
+    'call-summary': [ObservedCallScope & {
+        summary: CallSummary;
     }];
     'client-added': [ObservedClientScope];
     'client-sink-created': [ObservedClientScope & {
@@ -2321,6 +3389,14 @@ type ObserverEvents = {
     'client-issue': [ObservedClientScope & {
         issue: ClientIssue;
     }];
+    /**
+     * A stateful client issue ended — the client sent its `<type>-resolved` companion, or the
+     * observer force-closed it because the client went away. Carries the finished **interval**
+     * (`raisedAt` → `resolvedAt`, `durationInMs`).
+     */
+    'client-issue-resolved': [ObservedClientScope & {
+        resolvedIssue: ResolvedActiveClientIssue;
+    }];
     'client-metadata': [ObservedClientScope & {
         metaData: ClientMetaData;
     }];
@@ -2492,6 +3568,61 @@ type ObserverEvents = {
     }];
 };
 
+/**
+ * Something that wants to be **handed** open client issues rather than to go looking for them.
+ *
+ * Register one with `activeIssuesRegistry.addIssueTracker(type, tracker)` and it receives every
+ * issue of that type when it opens ({@link add}) and when it closes ({@link delete}). A detector
+ * implementing this pays only for the issues it actually consumes.
+ *
+ * `ActiveIssuesRegistry` implements it too, which is how a call's registry feeds the observer's.
+ */
+interface ActiveIssueTracker {
+    /** An issue of a subscribed type opened. */
+    add(issue: ActiveClientIssue): void;
+    /**
+     * An issue this tracker was given has closed.
+     *
+     * Return `true` if it was actually held. Returning `false` is legitimate and not an error — a
+     * tracker that counts *occurrences* (see `SfuCongestionDetector`) deliberately ignores
+     * resolutions, because when a symptom ended says nothing about how many endpoints reported it.
+     */
+    delete(issue: ActiveClientIssue): boolean;
+    /** How many issues this tracker currently holds. */
+    size: number;
+    /** Drop everything. Called when the owning scope closes. */
+    clear(): void;
+    has(issue: ActiveClientIssue): boolean;
+}
+
+/**
+ * One client's currently **open** stateful issues, keyed by `ClientIssue.key`.
+ *
+ * The server-side mirror of the client monitor's own active-issue map (client-monitor-js >= 4.6.0):
+ * a raise opens an entry, the matching `<type>-resolved` closes it, and the client's own close
+ * force-resolves whatever is left. That turns point-in-time symptom reports into **intervals**,
+ * which is what lets detectors ask "are these clients broken *at the same time*" rather than "did
+ * they both report something recently".
+ *
+ * Keyed by `key` rather than by type on purpose: one client can have several issues of the same type
+ * open at once (one per track), and they resolve independently.
+ *
+ * Every change is forwarded to the call's `ActiveIssuesRegistry`, which forwards to the observer's —
+ * so the client owns the storage and the wider scopes get their views maintained as it happens.
+ */
+declare class ObservedClientIssueRegistry {
+    private readonly registry?;
+    private readonly issues;
+    constructor(registry?: ActiveIssueTracker | undefined);
+    get size(): number;
+    keys(): IterableIterator<string>;
+    values(): IterableIterator<ActiveClientIssue>;
+    get(key: string): ActiveClientIssue | undefined;
+    add(issue: ActiveClientIssue): this;
+    remove(key: string): ActiveClientIssue | undefined;
+    clear(): void;
+}
+
 type ObservedClientSettings<AppData extends Record<string, unknown> = Record<string, unknown>> = {
     clientId: string;
     appData?: AppData;
@@ -2570,10 +3701,20 @@ declare class ObservedClient<AppData extends Record<string, unknown> = Record<st
     totalScoreSum: number;
     numberOfScoreMeasurements: number;
     readonly mediaDevices: MediaDeviceInfo[];
-    issues: ClientIssue[];
-    private _injections;
+    /**
+     * The client's currently **open** stateful issues, keyed by `ClientIssue.key` — the server-side
+     * mirror of the client monitor's own active-issue map (client-monitor-js >= 4.6.0).
+     *
+     * This turns point-in-time symptom reports into intervals, which is what lets detectors ask
+     * "are these clients broken *at the same time*" instead of "did they both report something
+     * recently". Entries are opened by a raise, closed by the matching `<type>-resolved` entry, and
+     * force-closed when the client closes.
+     */
+    readonly activeIssues: ObservedClientIssueRegistry;
+    private _pendingInjections;
+    private _activeSample?;
     private closeTimer?;
-    constructor(settings: ObservedClientSettings<AppData>, call: ObservedCall);
+    constructor(settings: ObservedClientSettings<AppData>, call: ObservedCall, activeIssues: ObservedClientIssueRegistry);
     get numberOfPeerConnections(): number;
     get score(): number | undefined;
     close(): void;
@@ -2582,13 +3723,28 @@ declare class ObservedClient<AppData extends Record<string, unknown> = Record<st
     injectEvent(event: ClientEvent): void;
     injectIssue(issue: ClientIssue): void;
     injectExtensionStat(stat: ExtensionStat): void;
-    injectAttachment(key: string, value: unknown): void;
+    injectAttachment(attachments: Record<string, unknown>): void;
     addMetadata(metadata: ClientMetaData): void;
+    /**
+     * Process one `clientIssues[]` entry.
+     *
+     * Entries come in two flavours (client-monitor-js >= 4.6.0):
+     *
+     * - a **raise** — opens an {@link ActiveClientIssue} under `issue.key` and emits `client-issue`;
+     * - a **resolution** — `type` ends in `-resolved` and carries the same `key`; it closes the
+     *   matching active issue and emits `client-issue-resolved`.
+     *
+     * Keyless entries are one-shot: reported, never tracked. A re-raise of a key already active
+     * refreshes the payload rather than opening a second interval.
+     */
     addIssue(issue: ClientIssue): void;
     addExtensionStats(stats: ExtensionStat): void;
+    /** Close the active issue a `<type>-resolved` entry refers to, and announce the finished interval. */
+    private _resolveIssue;
     private _processClientEvent;
     private _updatePeerConnection;
-    private _mergeInjections;
+    private _mergePendingInjections;
+    private _flushPendingInjections;
     /** Emit an Observer-bus event scoped to this client (or a peer connection under it). */
     private _notify;
 }
@@ -2629,7 +3785,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. */
@@ -2642,184 +3820,2398 @@ declare class RemoteTrackResolver {
     private _removeOutboundTrack;
 }
 
-interface Updater {
-    readonly name: string;
-    readonly description?: string;
-    close(): void;
-}
-
 interface Detector {
     readonly name: string;
     /** Called on every entity update; may raise issues via the entity it observes. */
     update(): void;
+    /**
+     * Optional teardown, called when the detector is removed from its registry (or the registry is
+     * cleared, which happens when the owning call/observer closes). Implement it when the detector
+     * subscribes to events or holds timers, so it doesn't leak.
+     */
+    close?(): void;
 }
 
-declare class Detectors {
-    private _detectors;
-    constructor(...detectors: Detector[]);
-    get listOfNames(): string[];
-    add(detector: Detector): void;
-    remove(detector: Detector): void;
-    update(): void;
-    clear(): void;
-}
-
-type ObservedCallUpdateConfig = {
-    updatePolicy?: 'update-on-any-client-updated' | 'update-when-all-client-updated' | 'none';
+declare const CallConcurrentIssueTypes: {
+    /** Several participants of this call have the same issue open **at the same time**. */
+    readonly concurrentClientIssues: "CONCURRENT_CLIENT_ISSUES";
+    /** Those issues also *began* together — the signature of one shared event. */
+    readonly issueOnsetBurst: "ISSUE_ONSET_BURST";
 };
-type ObservedCallSettings<AppData extends Record<string, unknown> = Record<string, unknown>> = ObservedCallUpdateConfig & {
-    callId: string;
-    appData?: AppData;
-    closeCallIfEmptyForMs?: number;
+type CallConcurrentIssueDetectorConfig = {
+    /**
+     * The issue types to watch. **Required, and must not be empty** — the detector subscribes to
+     * exactly these and sees nothing else.
+     */
+    issueTypes: string[];
+    /**
+     * 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;
+    /**
+     * 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, `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;
+    /**
+     * 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 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;
 };
-type ObservedCallEvents = {
-    update: [];
-    newclient: [ObservedClient];
-    empty: [];
-    'not-empty': [];
-    close: [];
+/** What the detector currently knows about one issue type in this call. */
+type CallConcurrentIssueGroup = {
+    type: string;
+    issues: ActiveClientIssue[];
+    clientIds: string[];
+    affectedRatio: number;
+    totalClients: number;
+    /**
+     * Spread of the onsets, in **observer** time (ms) — `max(observedAt) - min(observedAt)`.
+     *
+     * Measured on the observer clock on purpose: `raisedAt` comes from each client's own clock, and
+     * comparing those across machines makes clock skew look like a shared event.
+     */
+    onsetSpreadInMs: number;
+    firstObservedAt: number;
 };
-declare interface ObservedCall {
-    on<U extends keyof ObservedCallEvents>(event: U, listener: (...args: ObservedCallEvents[U]) => void): this;
-    off<U extends keyof ObservedCallEvents>(event: U, listener: (...args: ObservedCallEvents[U]) => void): this;
-    once<U extends keyof ObservedCallEvents>(event: U, listener: (...args: ObservedCallEvents[U]) => void): this;
-    emit<U extends keyof ObservedCallEvents>(event: U, ...args: ObservedCallEvents[U]): boolean;
-}
-declare class ObservedCall<AppData extends Record<string, unknown> = Record<string, unknown>> extends EventEmitter {
-    readonly observer: Observer;
-    updater?: Updater;
-    scoreCalculator: ScoreCalculator;
-    readonly detectors: Detectors;
-    readonly callId: string;
-    readonly observedClients: Map<string, ObservedClient<Record<string, unknown>>>;
-    readonly clientsUsedTurn: Set<string>;
-    readonly calculatedScore: CalculatedScore;
-    remoteTrackResolver?: RemoteTrackResolver;
-    totalAddedClients: number;
-    totalRemovedClients: number;
-    numberOfIssues: number;
-    numberOfPeerConnections: number;
-    numberOfInboundRtpStreams: number;
-    numberOfOutboundRtpStreams: number;
-    numberOfDataChannels: number;
-    maxNumberOfClients: number;
-    deltaNumberOfIssues: number;
-    appData: AppData;
-    closed: boolean;
-    startedAt?: number;
-    endedAt?: number;
-    closedAt?: number;
-    readonly settings: Pick<ObservedCallSettings, 'closeCallIfEmptyForMs'>;
-    /** Ancestry base shared by all Observer-bus events originating at this call. */
-    readonly eventScope: ObservedCallScope;
-    private closeTimer?;
-    constructor(settings: ObservedCallSettings<AppData>, observer: Observer);
-    get numberOfClients(): number;
-    get score(): number | undefined;
-    /** Raise a call-level (server-side) issue; surfaced on the Observer bus as `call-issue`. */
-    addIssue(issue: ClientIssue): void;
+/**
+ * Answers **"is this meeting in trouble?"** — several participants of one call with the same issue
+ * open simultaneously.
+ *
+ * The client already decides *what* is wrong for itself — `congestion`, `ice-disconnected`,
+ * `audio-concealment`, `video-decoder-overloaded` — with hysteresis and multi-signal confirmation
+ * behind each verdict. Re-deriving those server-side from raw counters would be strictly worse. What
+ * the server uniquely knows is *how many other participants of the same call are in that state right
+ * now*, which is the difference between "one person's Wi-Fi" and "this room is broken".
+ *
+ * Concurrency is judged from the **open interval set**, not a window of recent reports. A window has
+ * to guess whether a symptom is still happening; an interval is closed by the client when the episode
+ * actually ends (client-monitor-js >= 4.6.0 ships the `<type>-resolved` companion for exactly this).
+ *
+ * ```ts
+ * observedCall.addDetector('call-concurrent-issue-detector', {
+ *   issueTypes: [ 'congestion', 'ice-disconnected' ],
+ * });
+ * ```
+ *
+ * For the cross-call version of this question — which is a different question, not this one with a
+ * bigger denominator — see `ObserverConcurrentIssueDetector`.
+ */
+declare class CallConcurrentIssueDetector implements Detector, ActiveIssueTracker {
+    private readonly _call;
+    static readonly NAME: "call-concurrent-issue-detector";
+    readonly name: "call-concurrent-issue-detector";
+    private readonly _config;
+    private readonly _lastRaisedAt;
+    /** issue type -> the issues of that type currently open in this call. */
+    private readonly _byType;
+    private _size;
+    /** The groups that qualified on the most recent `update()`. Exposed for tests/dashboards. */
+    lastGroups: CallConcurrentIssueGroup[];
+    constructor(_call: ObservedCall, config?: Partial<CallConcurrentIssueDetectorConfig>);
+    get size(): number;
+    has(issue: ActiveClientIssue): boolean;
+    add(issue: ActiveClientIssue): void;
+    delete(issue: ActiveClientIssue): boolean;
+    clear(): void;
+    update(): void;
     close(): void;
-    getObservedClient<ClientAppData extends Record<string, unknown> = Record<string, unknown>>(clientId: string): ObservedClient<ClientAppData> | undefined;
-    createObservedClient<ClientAppData extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedClientSettings<ClientAppData>): ObservedClient<ClientAppData> | undefined;
-    getOrCreateObservedClient<ClientAppData extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedClientSettings<ClientAppData>): ObservedClient<ClientAppData> | undefined;
-    update(context?: AcceptContext): void;
-    private _onClientUpdate;
-    private _clientJoined;
-    private _clientLeft;
-    /** Emit an Observer-bus event scoped to this call. */
-    private _notify;
-}
-
-type Middleware<T> = (input: T, next: (nextInput: T) => void) => void;
-interface Processor<T> {
-    finalCallback?: Callback<T>;
-    process(value: T): void;
-    addMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
-    removeMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
-}
-type Callback<T> = (input: T) => void;
-declare class MiddlewareProcessor<T> implements Processor<T> {
-    private stack;
-    finalCallback?: Callback<T>;
-    addMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
-    removeMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
-    process(value: T): void;
+    private _groupOf;
 }
 
-type SampleRejectedReason = 'observer-closed' | 'missing-callId' | 'missing-clientId';
-
+/** A point on the earth, as an application reports it for one client. */
+type ClientLocation = {
+    latitude: number;
+    longitude: number;
+};
 /**
- * Optional, free-form context supplied to `accept()`. A single context object is
- * threaded down the accept chain (Observer -> Client -> PeerConnection) and is
- * merged into the `appData` of entities created during the accept pass.
+ * 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.
  */
-type AcceptContext = Record<string, unknown>;
-/** The payload threaded through `accept()` middlewares: the sample and its optional context. */
-type AcceptMiddlewarePayload = {
-    sample: ClientSample;
-    context?: AcceptContext;
-};
+declare const GEOHASH_CELL_SIZES: readonly ["", "~5000 km", "~1250 km", "~156 km", "~39 km", "~5 km", "~1.2 km", "~150 m"];
 /**
- * A global middleware run on every sample passed to `observer.accept()`, in registration order,
- * **before** the sample is dispatched to any call/client. It may inspect or mutate the sample
- * (e.g. set/normalize `callId`/`clientId`, enrich, redact) or the context, then call
- * `next(payload)` to continue the chain. Not calling `next` **drops** the sample.
+ * 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.
  */
-type AcceptMiddleware = Middleware<AcceptMiddlewarePayload>;
-type ObserverUpdateConfig = {
-    updatePolicy?: 'update-on-any-call-updated' | 'update-when-all-call-updated' | 'none';
+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";
 };
-/** Produces the initial `appData` for a call created without an explicit `appData`. */
-type CallAppDataFactory = (params: {
-    callId: string;
-    observer: Observer;
-}) => Record<string, unknown>;
-/** Produces the initial `appData` for a client created without an explicit `appData`. */
-type ClientAppDataFactory = (params: {
-    clientId: string;
-    observedCall: ObservedCall;
-}) => Record<string, unknown>;
-type ObserverConfig<AppData extends Record<string, unknown> = Record<string, unknown>> = ObserverUpdateConfig & {
-    defaultCallUpdatePolicy?: ObservedCallSettings['updatePolicy'];
-    appData?: AppData;
-    closeClientIfIdleForMs?: number;
-    closeCallIfEmptyForMs?: number;
+/** The client attribute to group by. One axis per detector — see the class description. */
+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.**
+     *
+     * **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, 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;
     /**
-     * Optional factory invoked when a call is created without an explicit `appData`
-     * (e.g. lazily by `accept()`), so apps can enrich appData without pre-creating the
-     * entity. `appData` is application-owned; it is never modified by the `accept()` context.
+     * Where to read a client's coordinates. **Required when `groupBy` is `'location'`**, ignored
+     * otherwise. See {@link ClientLocationResolver}.
      */
-    createCallAppData?: CallAppDataFactory;
-    /** Same as `createCallAppData`, for clients. Receives the (already-created) parent call. */
-    createClientAppData?: ClientAppDataFactory;
+    resolveClientLocation?: ClientLocationResolver;
     /**
-     * Optional factory invoked when a client is created, producing a per-client sink that
-     * receives every sample the client accepts (or `undefined` for no sink). The destination
-     * can be derived from `callId` / `clientId`.
+     * 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.
      */
-    createClientSink?: ClientSampleSinkFactory;
+    locationPrecision: number;
     /**
-     * Optional factory invoked when a call is created, producing the call's `RemoteTrackResolver`
-     * (or `undefined` for none). Use the built-ins
-     * (`createDefaultMediasoupRemoteTrackResolverFactory()` / `createP2pRemoteTrackResolverFactory()`)
-     * or build a `RemoteTrackResolver` with custom publisher/subscriber id resolvers.
+     * Group by `name` only, or by `name + version`. Default `true` (include version).
+     *
+     * Version is usually the point: "Chrome" is not actionable, "Chrome 141" is, because it names a
+     * thing that changed on a date. Set to `false` when comparing whole engines.
+     */
+    includeVersion: boolean;
+    /**
+     * 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;
+    /**
+     * 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, `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 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;
+    /**
+     * 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.
      */
-    createTrackResolver?: RemoteTrackResolverFactory;
+    minControlSize: number;
+    /**
+     * 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;
 };
-declare interface Observer {
-    on<U extends keyof ObserverEvents>(event: U, listener: (...args: ObserverEvents[U]) => void): this;
-    off<U extends keyof ObserverEvents>(event: U, listener: (...args: ObserverEvents[U]) => void): this;
-    once<U extends keyof ObserverEvents>(event: U, listener: (...args: ObserverEvents[U]) => void): this;
-    emit<U extends keyof ObserverEvents>(event: U, ...args: ObserverEvents[U]): boolean;
+/** The rollup for one population on one issue type. */
+type ClientPopulation = {
+    /**
+     * 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;
+    clients: number;
+    affectedClients: number;
+    affectedRatio: number;
+    affectedClientIds: string[];
+    /** Everyone not in this population. */
+    controlClients: number;
+    controlAffectedClients: number;
+    controlAffectedRatio: number;
+    /** `affectedRatio / controlAffectedRatio`. `Infinity` when the control group is completely clean. */
+    relativeRisk: number;
+};
+/**
+ * Finds an issue that is concentrated on **one kind of client** — one browser, one browser version,
+ * one OS — rather than on anything the servers own.
+ *
+ * ### Why this exists
+ *
+ * The other observer-scoped detectors all answer "who else has this open, and what do they share?"
+ * with the answer *the infrastructure*, because clients in unrelated calls share nothing else. That
+ * inference is right for network symptoms and **wrong for endpoint symptoms**, and the difference
+ * matters at 3am. `cpulimitation` opening across six unrelated calls is not an SFU event: CPU is
+ * owned by the endpoint, so what those endpoints have in common is a client release, a browser
+ * update, or a fleet of identical VDI hosts. `IssueConclusion` already says exactly this — it maps
+ * the endpoint-capacity family to a `client-population` fault domain instead of `infrastructure` —
+ * but until now nothing in the library actually computed the grouping that claim refers to. This
+ * detector is that computation.
+ *
+ * It is the one correlation in this library that is neither per-call nor per-server. A client knows
+ * its own browser and nothing about anyone else's; only something sitting above the whole fleet can
+ * notice that every complaint is coming from the same build.
+ *
+ * ### The control group is the whole point
+ *
+ * "30% of Chrome 141 users report encoder-bottleneck" is not a finding on its own. If 30% of
+ * *everyone* reports it, Chrome 141 is not the story — you have a fleet-wide problem and this
+ * detector would be pointing at the largest population rather than at a cause. Naive share-based
+ * grouping always indicts whichever browser is most popular, which is why the gate here is
+ * **relative risk**: the suspect population's rate divided by the rate among everyone else. A
+ * population only qualifies when it is `minRelativeRisk` times worse than the rest of the fleet, and
+ * only when the rest of the fleet is large enough (`minControlSize`) for "the rest of the fleet" to
+ * be a real measurement.
+ *
+ * A completely clean control group gives `Infinity`, which is honest — nobody outside this
+ * population has the problem at all — and is exactly why `minAffectedClients` and
+ * `minPopulationSize` are checked independently, so a single unlucky user on a rare browser cannot
+ * page anyone.
+ *
+ * ### One axis per detector
+ *
+ * `groupBy` takes a single attribute. Add a second instance if you want a second axis:
+ *
+ * ```ts
+ * observer.addObserverDetector('client-population-issue-detector', {
+ *   issueTypes: [ 'cpulimitation', 'encoder-bottleneck', 'stuck-decoder' ],
+ *   groupBy: 'browser',
+ * });
+ *
+ * observer.on('observer-issue', ({ issue }) => {
+ *   if (issue.type !== ClientPopulationIssueTypes.clientPopulationIssue) return;
+ *   // → { population: 'Chrome 141', issueType: 'encoder-bottleneck',
+ *   //     affectedRatio: 0.34, controlAffectedRatio: 0.02, relativeRisk: 17 }
+ * });
+ * ```
+ *
+ * Deliberately not a cross-product of every axis at once: an issue that clusters on macOS *and* on
+ * 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'`. 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.
+ */
+declare class ClientPopulationIssueDetector implements Detector, ActiveIssueTracker {
+    private readonly _observer;
+    static readonly NAME: "client-population-issue-detector";
+    readonly name: "client-population-issue-detector";
+    private readonly _config;
+    private readonly _lastRaisedAt;
+    private readonly _issues;
+    /** The populations that qualified on the most recent `update()`. Exposed for tests/dashboards. */
+    lastPopulations: ClientPopulation[];
+    constructor(_observer: Observer, config?: Partial<ClientPopulationIssueDetectorConfig>);
+    get size(): number;
+    has(issue: ActiveClientIssue): boolean;
+    add(issue: ActiveClientIssue): void;
+    delete(issue: ActiveClientIssue): boolean;
+    clear(): void;
+    update(): void;
+    close(): void;
+    /** `undefined` when the client never reported this attribute — see the class description. */
+    private _populationOf;
+    private _rollupOf;
+    private _riskText;
+    /** Bigger populations and starker contrasts are harder to produce by chance. */
+    private _confidenceOf;
 }
-declare class Observer<AppData extends Record<string, unknown> = Record<string, unknown>> extends EventEmitter {
-    readonly config: ObserverConfig<AppData>;
+
+declare const PublisherFaultTypes: {
+    /**
+     * A publisher is reporting trouble on its own send path **while** its subscribers report trouble
+     * receiving it. Both ends agree, so the source is implicated rather than inferred.
+     */
+    readonly corroboratedPublisherFault: "CORROBORATED_PUBLISHER_FAULT";
+};
+type PublisherFaultCorroborationDetectorConfig = {
+    /**
+     * Issue types raised by the **publishing** client about its own outbound path. **Required.**
+     *
+     * The natural set from client-monitor-js: `encoder-bottleneck`, `capture-bottleneck`,
+     * `dry-outbound-track`. All three mean "I am failing to produce or send this properly", which is
+     * the half of the story the receivers cannot see.
+     */
+    publisherIssueTypes: string[];
+    /**
+     * Issue types raised by the **subscribing** clients about the track they receive. **Required.**
+     *
+     * The natural set: `freezed-video-track`, `dry-inbound-track`, `video-recovery-failed`. These say
+     * "I am not getting this properly", which is the half the publisher cannot see.
+     */
+    receiverIssueTypes: string[];
+    /**
+     * 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 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. */
+type CorroboratedPublisherFault = {
+    trackId: string;
+    kind: string;
+    publisherClientId: string;
+    /** The publisher's own open issue types on this track. */
+    publisherIssueTypes: string[];
+    /** The receiver-side open issue types across this track's subscribers. */
+    receiverIssueTypes: string[];
+    receivers: number;
+    affectedReceivers: number;
+    affectedClientIds: string[];
+    publisherBitrate?: number;
+};
+/**
+ * Fires only when **both ends of one published track are complaining at the same time**: the
+ * publisher about its own send path, and its subscribers about receiving it.
+ *
+ * ### How this differs from `IssueFanOutDetector`
+ *
+ * Fan-out sees one end. It observes that most of Alice's subscribers are unhappy and *infers* that
+ * the fault is on Alice's side, because the affected clients share a publisher and nothing else. That
+ * inference is sound, and it is still a inference: the same observation is produced by the SFU
+ * mangling Alice's stream on the way out, with Alice herself perfectly healthy.
+ *
+ * This detector removes the inference. When Alice reports `encoder-bottleneck` *and* four of her six
+ * subscribers report `freezed-video-track` in the same window, there is nothing left to deduce — the
+ * source said it was struggling and the receivers confirmed the consequence. That is the strongest
+ * statement this library can make about where a fault sits, and it is only available to something
+ * holding both ends at once. Neither the publisher nor any receiver can reach this conclusion alone.
+ *
+ * Run both: fan-out is broader and catches the SFU-forwarding case where the publisher is fine;
+ * this one is narrower and, when it fires, needs no interpretation.
+ *
+ * ### Silence here is not health
+ *
+ * A quiet detector means only that the two halves have not coincided — most commonly because the
+ * publisher is genuinely fine and the fault is in forwarding, which is exactly the case `fan-out`
+ * exists to report. Do not read "no corroborated fault" as "no publisher-side problem".
+ *
+ * ```ts
+ * observedCall.addDetector('publisher-fault-corroboration-detector', {
+ *   publisherIssueTypes: [ 'encoder-bottleneck', 'capture-bottleneck', 'dry-outbound-track' ],
+ *   receiverIssueTypes: [ 'freezed-video-track', 'dry-inbound-track' ],
+ * });
+ * ```
+ *
+ * ### Requires a `RemoteTrackResolver`
+ *
+ * Matching a publisher's issue to its subscribers' issues needs the publisher↔subscriber links. With
+ * no resolver the detector does nothing rather than guessing.
+ */
+declare class PublisherFaultCorroborationDetector implements Detector, ActiveIssueTracker {
+    private readonly _call;
+    static readonly NAME: "publisher-fault-corroboration-detector";
+    readonly name: "publisher-fault-corroboration-detector";
+    private readonly _config;
+    private readonly _lastRaisedAt;
+    /** Open publisher-side issues that name a track. */
+    private readonly _publisherIssues;
+    /** Open receiver-side issues that name a track. */
+    private readonly _receiverIssues;
+    /** The faults corroborated on the most recent `update()`. Exposed for tests/dashboards. */
+    lastFaults: CorroboratedPublisherFault[];
+    constructor(_call: ObservedCall, config?: Partial<PublisherFaultCorroborationDetectorConfig>);
+    get size(): number;
+    has(issue: ActiveClientIssue): boolean;
+    add(issue: ActiveClientIssue): void;
+    delete(issue: ActiveClientIssue): boolean;
+    clear(): void;
+    update(): void;
+    close(): void;
+    /**
+     * Resolve a publisher-side issue's `trackId` to the outbound track it is about.
+     *
+     * Looked up through the reporting client's own peer connections: the issue names its client, so
+     * the search is bounded by that client's transports rather than by the size of the call.
+     */
+    private _outboundTrackOf;
+}
+
+declare const ObserverConcurrentIssueTypes: {
+    /**
+     * The same issue is open in **several unrelated calls at once**. Those clients share no meeting,
+     * no publisher and no room — only the infrastructure serving them.
+     */
+    readonly crossCallConcurrentIssues: "CROSS_CALL_CONCURRENT_ISSUES";
+    /** The cross-call version that also started together. The strongest "it's us" signal available. */
+    readonly crossCallIssueOnsetBurst: "CROSS_CALL_ISSUE_ONSET_BURST";
+};
+type ObserverConcurrentIssueDetectorConfig = {
+    /**
+     * The issue types to watch. **Required, and must not be empty** — the detector subscribes to
+     * exactly these and sees nothing else.
+     */
+    issueTypes: string[];
+    /**
+     * 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`.
+     *
+     * This is what makes an observer-scoped finding mean something a call-scoped one doesn't. Without
+     * it, one thirty-person meeting with congestion satisfies every client-count threshold and raises
+     * a fleet-wide alert for what is really one bad room — which `CallConcurrentIssueDetector` has
+     * already reported. Requiring two or more independent calls is the difference between a
+     * coincidence and a shared cause.
+     */
+    minAffectedCalls: number;
+    /**
+     * Fraction of the calls in flight that must be affected. Default `0` — off, because absolute
+     * counts matter more than ratios here: three broken calls out of a thousand is still worth
+     * knowing about, and a ratio threshold would hide it. Raise it if you only care about fleet-wide
+     * events.
+     *
+     * Note there is deliberately **no participant ratio** at this scope. Six broken calls out of forty
+     * is a handful of clients against the whole fleet, so any meaningful client ratio would suppress
+     * exactly the finding this detector exists to produce.
+     */
+    affectedCallRatioThreshold: number;
+    /**
+     * 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 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. */
+type ObserverConcurrentIssueGroup = {
+    type: string;
+    issues: ActiveClientIssue[];
+    clientIds: string[];
+    totalClients: number;
+    affectedRatio: number;
+    callIds: string[];
+    totalCalls: number;
+    affectedCallRatio: number;
+    /** Per-call breakdown, largest first — the first question anyone asks is "which calls, how badly?". */
+    perCall: {
+        callId: string;
+        affectedClients: number;
+        totalClients: number;
+    }[];
+    /**
+     * Spread of the onsets, in **observer** time (ms). Client clocks are never compared across
+     * machines here — skew between them would masquerade as a synchronized event.
+     */
+    onsetSpreadInMs: number;
+    firstObservedAt: number;
+};
+/**
+ * Answers **"is our infrastructure in trouble?"** — the same issue open across several *unrelated*
+ * calls at the same moment.
+ *
+ * This is not the call-scoped question with a bigger denominator, which is why it is a separate
+ * detector with separate gates and its own finding types. Participant count alone is a bad fleet
+ * signal: one thirty-person meeting where everybody is congested clears every client threshold, yet
+ * it has an obvious local explanation. Clients in *different* calls share no room, no publisher and
+ * no host — only the servers and the network. When the same issue opens across several of them at
+ * once, the infrastructure is the only remaining common factor, and that is the finding worth paging
+ * someone about.
+ *
+ * ```ts
+ * observer.addObserverDetector('observer-concurrent-issue-detector', {
+ *   issueTypes: [ 'congestion', 'ice-disconnected' ],
+ *   minAffectedCalls: 3,
+ * });
+ *
+ * observer.on('observer-issue', ({ issue }) => {
+ *   if (issue.type === ObserverConcurrentIssueTypes.crossCallIssueOnsetBurst) page(issue);
+ * });
+ * // → CROSS_CALL_ISSUE_ONSET_BURST { issueType: 'congestion', calls: 40, affectedCalls: 6, … }
+ * ```
+ *
+ * Onsets are compared on the **observer clock** (`observedAt`), never on client clocks: participants
+ * degrading together within a couple of seconds is far more likely to be a deploy, a TURN failover or
+ * a link flap than a coincidence — but only if the timestamps being compared came from one clock.
+ */
+declare class ObserverConcurrentIssueDetector implements Detector, ActiveIssueTracker {
+    private readonly _observer;
+    static readonly NAME: "observer-concurrent-issue-detector";
+    readonly name: "observer-concurrent-issue-detector";
+    private readonly _config;
+    private readonly _lastRaisedAt;
+    /** issue type -> the issues of that type currently open anywhere in the fleet. */
+    private readonly _byType;
+    private _size;
+    /** The groups that qualified on the most recent `update()`. Exposed for tests/dashboards. */
+    lastGroups: ObserverConcurrentIssueGroup[];
+    constructor(_observer: Observer, config?: Partial<ObserverConcurrentIssueDetectorConfig>);
+    get size(): number;
+    has(issue: ActiveClientIssue): boolean;
+    add(issue: ActiveClientIssue): void;
+    delete(issue: ActiveClientIssue): boolean;
+    clear(): void;
+    update(): void;
+    close(): void;
+    private _groupOf;
+}
+
+declare const IssueFanOutTypes: {
+    /** Most receivers of one published track have the same issue open → the fault follows the source. */
+    readonly publishedTrackIssueFanOut: "PUBLISHED_TRACK_ISSUE_FAN_OUT";
+    /** Exactly one receiver of a track has it → that receiver's own problem. */
+    readonly singleReceiverIssue: "SINGLE_RECEIVER_ISSUE";
+};
+type IssueFanOutDetectorConfig = {
+    /**
+     * The receiver-side issue types to attribute to publishers. **Required, and must not be empty** —
+     * the detector subscribes to exactly these.
+     *
+     * There is no "all types" option. Which of a receiver's complaints are worth blaming a publisher
+     * for is application knowledge: `freezed-video-track` fanning out across a track's subscribers
+     * implicates the source, `cpulimitation` fanning out the same way implicates the receivers'
+     * hardware and would be a false accusation.
+     */
+    issueTypes: string[];
+    /**
+     * 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, `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 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 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;
+};
+/**
+ * Attributes **client-reported issues to the published track they are about**, then asks how far
+ * the problem fans out across that track's receivers.
+ *
+ * The join is what makes this possible: a receiver-side issue payload carries `trackId` (the client
+ * detectors report it for every track-scoped issue), the observer resolves that to an inbound track,
+ * and `RemoteTrackResolver` links the inbound track to the `remoteOutboundTrack` that published it.
+ * With the whole subscriber set of one source in hand, the verdict is straightforward and is the
+ * single most useful thing a server can say:
+ *
+ * - **most receivers of Alice's track are affected** → the fault is on Alice's path — her uplink, the
+ *   SFU's ingress, or its forwarding of that stream.
+ * - **one receiver of Alice's track is affected** → that receiver's downlink. Nothing to do with
+ *   Alice, even though the symptom is reported against her stream.
+ *
+ * Deliberately generic over the issue vocabulary: `freezed-video-track`, `keyframe-storm`,
+ * `audio-concealment`, `video-decoder-overloaded`, `stuck-decoder` and anything a custom client
+ * detector invents all fan out the same way, so one mechanism replaces a family of symptom-specific
+ * detectors.
+ *
+ * ### It walks the affected tracks, never all of them
+ *
+ * The detector is fed open issues by the call's registry and keeps only those carrying a `trackId`.
+ * Each tick it resolves *those* tracks to their publishers — never the published tracks of the call,
+ * of which there are many more and almost all of them fine. A call with nothing wrong costs one
+ * `size === 0` check.
+ *
+ * ### Requires a `RemoteTrackResolver`
+ *
+ * Without publisher↔subscriber links there is no way to know which receivers belong to one source,
+ * so the detector does nothing when the call has no resolver. It does not fall back to guessing:
+ * "one receiver of an unknown set" is not a statement worth raising.
+ */
+declare class IssueFanOutDetector implements Detector, ActiveIssueTracker {
+    private readonly _call;
+    static readonly NAME = "issue-fan-out-detector";
+    readonly name = "issue-fan-out-detector";
+    private readonly _config;
+    private readonly _lastRaisedAt;
+    /** Open issues that name a track. Issues without a `trackId` cannot be attributed and are dropped. */
+    private readonly _trackIssues;
+    constructor(_call: ObservedCall, config?: Partial<IssueFanOutDetectorConfig>);
+    get size(): number;
+    has(issue: ActiveClientIssue): boolean;
+    add(issue: ActiveClientIssue): void;
+    delete(issue: ActiveClientIssue): boolean;
+    clear(): void;
+    update(): void;
+    close(): void;
+    /**
+     * Resolve the issue's `trackId` to the outbound track that published it.
+     *
+     * Looked up through the reporting client's own peer connections rather than by scanning the call:
+     * the issue names its client, so the search is bounded by that client's transports (typically one
+     * or two) instead of by the size of the meeting.
+     */
+    private _publisherOf;
+}
+
+/**
+ * One completed sampling bucket: how many/which clients reported congestion during it.
+ *
+ * `totalClients` (and therefore `congestedClientRatio`) is a snapshot of `observer.numberOfClients`
+ * taken when the bucket closes — an approximation of "how many clients could have been congested",
+ * not a claim that every client sent exactly one sample within the bucket. Good enough for a ratio
+ * that only needs to be comparable bucket-to-bucket.
+ */
+type SfuCongestionDetectorBucket = {
+    observedAt: number;
+    totalClients: number;
+    congestedClients: number;
+    congestedClientRatio: number;
+    affectedClientIds: string[];
+    affectedCallIds: string[];
+};
+type SfuCongestionDetectorReport = {
+    affectedCallIds: string[];
+    affectedClientIds: string[];
+    congestedClientRatio: number;
+    totalNumberOfClients: number;
+    numberOfCongestedClients: number;
+    historySize: number;
+    baselineCongestedClientRatio: number;
+    robustZ: number;
+    absoluteIncrease: number;
+    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. */
+type SfuCongestionDetectorEvaluation = {
+    isCongested: boolean;
+    baselineCongestedClientRatio: number;
+    robustZ: number;
+    absoluteIncrease: number;
+    relativeIncrease: number;
+};
+/**
+ * Detects a **shared** congestion event: many clients, across different calls, reporting congestion
+ * inside the same slice of time.
+ *
+ * Only add this when the observer's calls all come from the **same SFU** — the finding's whole
+ * meaning is "these clients have nothing in common except that server", and that is only true if the
+ * server really is the common factor.
+ *
+ * ### Why fixed-interval buckets, and not the update tick
+ *
+ * The obvious implementation counts congested clients on each `update()`. It is wrong here, for two
+ * separate reasons:
+ *
+ * - **The tick is not evenly spaced.** `update()` fires when a client is updated, so its rate is a
+ *   function of how many clients are connected and how their sampling happens to interleave. Two
+ *   counts taken from windows of different length are not comparable, and this detector's entire
+ *   job is to compare a count against earlier counts.
+ * - **Clients report on their own schedule.** A client sends a sample roughly every
+ *   `samplesSendingTimeInMs`, unsynchronised with every other client. A window shorter than that
+ *   systematically undercounts — half the congested clients simply hadn't spoken yet — and the
+ *   undercount varies with arrival phase, which is noise indistinguishable from signal.
+ *
+ * So the detector runs on a wall-clock interval and closes a bucket every
+ * `samplesSendingTimeInMs`, giving every client a fair chance to be heard in each one. Buckets are
+ * equal-length and equally lagged, which is what makes bucket-to-bucket comparison mean something.
+ * {@link update} is deliberately empty: nothing here is driven by the update tick.
+ *
+ * ### Occurrences, not intervals
+ *
+ * Unlike `ConcurrentIssueDetector`, this one ignores resolutions — see {@link delete}. It counts how
+ * many *distinct clients reported* congestion in a bucket, not how many are still congested. A
+ * client that hits congestion and immediately drops its bitrate resolves the issue within seconds
+ * and would vanish from an open-interval view, yet it is exactly the evidence wanted here.
+ */
+declare class SfuCongestionDetector implements Detector, ActiveIssueTracker {
+    private readonly _observer;
+    static readonly NAME = "sfu-congestion-detector";
+    readonly name = "sfu-congestion-detector";
+    private readonly _config;
+    private readonly _history;
+    private readonly _trackedIssues;
+    private timer;
+    private _lastEvaluatedBucket;
+    constructor(_observer: Observer, config?: Partial<SfuCongestionDetectorConfig>);
+    get size(): number;
+    /** Record the issue against the bucket currently open. The timer, not this, closes the bucket. */
+    add(issue: ActiveClientIssue): void;
+    /**
+     * Deliberately a no-op returning `false`.
+     *
+     * Resolutions are not interesting here. A congested client typically fixes its own symptom by
+     * dropping bitrate hard, so the issue closes within seconds — but it still *happened*, and it is
+     * evidence that the server was under pressure during this bucket. What matters is how many
+     * distinct clients reported congestion within the bucket and whether that count suddenly jumps,
+     * not how long any one client's issue stayed open.
+     *
+     * Nothing leaks: the tracked set is emptied wholesale every time a bucket closes.
+     */
+    delete(_issue: ActiveClientIssue): boolean;
+    clear(): void;
+    has(issue: ActiveClientIssue): boolean;
+    close(): void;
+    /** The completed buckets kept so far, oldest first. Read-only — for introspection/tests. */
+    get history(): readonly SfuCongestionDetectorBucket[];
+    /**
+     * Intentionally empty — see the class description.
+     *
+     * Everything here is driven by the bucket timer, because the update tick is neither evenly spaced
+     * nor long enough for every client to have reported. Counting on it would compare windows of
+     * different lengths and call the difference a signal.
+     */
+    update(): void;
+    private _closeBucket;
+    /**
+     * Evaluate only the latest completed bucket (the candidate) against the buckets before it (the
+     * baseline) — never against itself. Reached once per newly-closed bucket via {@link update}; the
+     * identity check below additionally guards against evaluating the same bucket twice, in case
+     * `update()` is ever called again before the next rotation.
+     */
+    private _evaluateLatestBucket;
+    /**
+     * Is `candidate` — the latest completed bucket — abnormally high compared with the `baseline`
+     * buckets before it?
+     *
+     * Requires both **statistical** significance (a robust z-score against a median+MAD baseline —
+     * deliberately not Mann-Kendall, which asks "is this a monotonic trend", not "is the latest point
+     * an outlier"; a single sudden spike on an otherwise flat series is exactly what should trigger
+     * here and exactly what a trend test would miss) and **practical** significance (enough affected
+     * clients, and a big enough absolute/relative jump — a statistically significant move in a tiny
+     * or trivial ratio is not worth an alert).
+     */
+    private _evaluateBucket;
+}
+
+declare const TrackDeliveryMismatchTypes: {
+    /**
+     * The source is sending, but **none** of its subscribers are receiving → the media is being lost
+     * between the publisher and the receivers. In an SFU that means the forwarding path.
+     */
+    readonly publishedTrackNotDelivered: "PUBLISHED_TRACK_NOT_DELIVERED";
+    /**
+     * The source is sending and most subscribers are fine, but **some** are dry → those consumers are
+     * broken individually (in mediasoup, the usual mitigation is recreating the consumer).
+     */
+    readonly receiverTrackNotDelivered: "RECEIVER_TRACK_NOT_DELIVERED";
+    /**
+     * The source itself stopped producing, so its subscribers being dry is expected and **not** an
+     * SFU fault. Reported so the other two verdicts can be trusted as *not* being this.
+     */
+    readonly publisherTrackDry: "PUBLISHER_TRACK_DRY";
+};
+type TrackDeliveryMismatchDetectorConfig = {
+    /**
+     * 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'`, as raised
+     * by client-monitor-js. The pairing of these two types is the whole detector: their **disagreement**
+     * is the finding.
+     */
+    dryOutboundIssueType: string;
+    /**
+     * 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`.
+     *
+     * `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 per (track, verdict) in ms. Default `60_000`. Typical `30_000`–`300_000`. */
+    cooldownMs: number;
+};
+/**
+ * Answers **"is the media actually getting through?"** by joining the two ends of a published track.
+ *
+ * A dry track is the clearest possible symptom — no bytes are arriving — but on its own it is
+ * ambiguous, and the ambiguity is precisely what a single endpoint cannot resolve. A receiver seeing
+ * silence cannot tell whether the camera was switched off, the SFU stopped forwarding, or its own
+ * consumer wedged. All three look identical from the browser.
+ *
+ * With the publisher↔subscriber links this becomes a three-way decision:
+ *
+ * | publisher | subscribers | verdict |
+ * |---|---|---|
+ * | sending | **all** dry | `PUBLISHED_TRACK_NOT_DELIVERED` — the SFU/forwarding path |
+ * | sending | **some** dry | `RECEIVER_TRACK_NOT_DELIVERED` — those consumers (recreate them) |
+ * | dry | any dry | `PUBLISHER_TRACK_DRY` — the source stopped; not an SFU fault |
+ *
+ * The publisher side is judged from **both** signals available: its own `dry-outbound-track` issue
+ * when the client reports one, and — as the fallback, and the corroboration when it does not — the
+ * observed outbound RTP (`deltaPacketsSent`). That combination is what makes the first row
+ * trustworthy: the server can state that packets demonstrably left the publisher during the same
+ * interval in which every receiver got nothing.
+ *
+ * This is the "SFU forwarding mismatch" check, and notably it needs **no** mediasoup instrumentation
+ * — the client's own dry-track verdicts plus the resolver links are sufficient.
+ */
+declare class TrackDeliveryMismatchDetector implements Detector, ActiveIssueTracker {
+    private readonly call;
+    static readonly NAME: "track-delivery-mismatch-detector";
+    readonly name: "track-delivery-mismatch-detector";
+    private readonly _config;
+    private readonly _lastRaisedAt;
+    private readonly dryOutboundTracks;
+    private readonly dryInboundTracks;
+    constructor(call: ObservedCall, config?: Partial<TrackDeliveryMismatchDetectorConfig>);
+    close(): void;
+    add(issue: ActiveClientIssue): void;
+    delete(issue: ActiveClientIssue): boolean;
+    get size(): number;
+    clear(): void;
+    has(issue: ActiveClientIssue): boolean;
+    update(): void;
+}
+
+declare const TurnServerHealthTypes: {
+    /** One TURN server's clients are in trouble while other servers' clients are fine. */
+    readonly turnServerDegraded: "TURN_SERVER_DEGRADED";
+};
+type TurnServerHealthDetectorConfig = {
+    /**
+     * 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, `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 (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 `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 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. */
+type TurnServerHealth = {
+    serverUrl: string;
+    /** Distinct clients whose media is relayed through this server. */
+    clients: number;
+    /** Of those, how many currently have at least one open issue. */
+    degradedClients: number;
+    degradedRatio: number;
+    affectedClientIds: string[];
+    /** The open issue types seen on this server's clients, most common first. */
+    issueTypes: string[];
+};
+/**
+ * An **observer-level** detector that groups relayed clients by the TURN server carrying them and
+ * compares the servers against each other.
+ *
+ * Counting TURN usage is not useful on its own; knowing that `turn-eu-1` has 22 of 30 clients in
+ * trouble while `turn-eu-2` has 1 of 34 is. Because the comparison spans calls it lives on
+ * `observer.detectors` and raises `observer-issue` — one actionable alert instead of fifty
+ * per-client ones. Each finding carries the other servers' ratios as context, since "half the
+ * clients here are unhappy" only means something relative to the rest of the fleet.
+ *
+ * Whether a client is in trouble comes from **its own reported issues**, not from thresholds applied
+ * here. The client already decides that far better than a server-side rule could; the value this
+ * adds is the grouping — the dimension no endpoint can see.
+ *
+ * For a relay that has stopped serving entirely, see `TurnServerOutageDetector`: this detector needs
+ * clients *on* the server to ask how many are unhappy, and an outage takes them away.
+ */
+declare class TurnServerHealthDetector implements Detector {
+    private readonly _observer;
+    static readonly NAME = "turn-server-health-detector";
+    readonly name = "turn-server-health-detector";
+    private readonly _config;
+    private readonly _streaks;
+    private readonly _lastRaisedAt;
+    /** The per-server rollup computed on the most recent `update()`. */
+    lastServers: TurnServerHealth[];
+    constructor(_observer: Observer, config?: Partial<TurnServerHealthDetectorConfig>);
+    update(): void;
+    close(): void;
+    private _serverHealth;
+}
+
+declare const TurnServerOutageTypes: {
+    /** One TURN server's relayed population collapsed while the rest of the fleet is fine. */
+    readonly turnServerOutage: "TURN_SERVER_OUTAGE";
+};
+type TurnServerOutageDetectorConfig = {
+    /**
+     * 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;
+    /**
+     * Fraction of the peak population that must be gone or disrupted. Default `0.8` — an outage is
+     * near-total by definition; partial degradation is `TurnServerHealthDetector`'s question.
+     */
+    lossRatioThreshold: number;
+    /**
+     * 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;
+    /**
+     * Require a healthy **control group** — clients not relayed through this server that are still
+     * connected — before blaming the server. Without this, a call ending, a fleet-wide network
+     * event, or the observer shutting down all look exactly like a TURN outage. Default `true`.
+     */
+    requireControlGroup: boolean;
+    /**
+     * 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, `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 `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
+     * per tick, and a server that stays down would otherwise alert forever.
+     */
+    cooldownMs: number;
+};
+/**
+ * Detects a **TURN server outage** — a relay that has stopped serving — by watching its client
+ * population collapse while the rest of the fleet carries on.
+ *
+ * This is the case its sibling `TurnServerHealthDetector` structurally *cannot* see, and the
+ * distinction is worth being precise about. That detector groups clients by the server relaying them
+ * and asks how many are reporting issues. It needs clients on the server to ask the question. When a
+ * TURN server goes down completely, allocation fails: existing sessions drop, and new clients never
+ * obtain a relay candidate through it at all, so they are never attributed to it. The server's
+ * population goes to zero and the health detector falls silent for the worst possible reason — it
+ * has nobody left to ask. Degradation makes clients unhappy; an outage makes them *disappear*.
+ *
+ * So the signal here is absence, measured against the server's own recent peak:
+ *
+ * - clients gone entirely (their relayed peer connections closed, or they re-negotiated onto a
+ *   different path), plus
+ * - clients still attributed to the server whose ICE or connection state is `disconnected` /
+ *   `failed` / `closed` — the ones mid-collapse, which is what you catch if you look during the
+ *   outage rather than after it.
+ *
+ * ### The control group is the whole design
+ *
+ * Absence is a dangerous signal: a call ending, everyone going home at 6pm, a fleet-wide network
+ * event, and the observer itself shutting down all produce exactly the same collapse. The detector
+ * therefore refuses to blame a server unless clients **not** relayed through it are demonstrably
+ * still connected — `requireControlGroup`, on by default. "Everyone on `turn-eu-1` vanished" is
+ * ambiguous; "everyone on `turn-eu-1` vanished while 200 clients elsewhere are fine" is an outage.
+ *
+ * That comparison is only available to something watching every call at once, which is why this is
+ * an observer-level detector raising `observer-issue` — one alert for the fleet, not one per
+ * abandoned call.
+ *
+ * ### Caveats worth knowing before you tune it
+ *
+ * Clients that fail over cleanly to a second TURN server still count as lost here, which is
+ * correct — the server did stop serving them — but it means a well-configured fleet with automatic
+ * failover reports outages that users never felt. That is the intended behaviour: the failover
+ * worked *and* the server is down are both true, and you want to know the second one.
+ *
+ * A genuinely quiet server (last call of the day ends) is suppressed by the control group, not by
+ * the collapse test. If you run a small deployment where the control group is routinely below
+ * `minControlGroupClients`, this detector will stay quiet — prefer alerting on your TURN server's
+ * own health checks there, since a handful of clients cannot distinguish these cases.
+ */
+declare class TurnServerOutageDetector implements Detector {
+    private readonly _observer;
+    static readonly NAME = "turn-server-outage-detector";
+    readonly name = "turn-server-outage-detector";
+    private readonly _config;
+    /** serverUrl -> recent population observations, used to derive the windowed peak. */
+    private readonly _peaks;
+    private readonly _streaks;
+    private readonly _lastRaisedAt;
+    constructor(_observer: Observer, config?: Partial<TurnServerOutageDetectorConfig>);
+    update(): void;
+    close(): void;
+    /** Distinct clients on a server, split by whether their relayed transport is actually up. */
+    private _populationOf;
+    /** Record this tick's population and return the peak across `peakWindowMs`. */
+    private _recordAndPeak;
+    /**
+     * Everyone *not* relayed through `serverUrl`: clients on other TURN servers plus every client
+     * the observer knows about that isn't relayed at all. The healthy share of that group is what
+     * separates "this server broke" from "everything broke".
+     */
+    private _controlGroup;
+}
+
+declare const UnconsumedTrackTypes: {
+    /** A track is being published to the SFU that nobody is subscribed to — pure wasted uplink. */
+    readonly unconsumedPublishedTrack: "UNCONSUMED_PUBLISHED_TRACK";
+};
+type UnconsumedTrackDetectorConfig = {
+    /**
+     * 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 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 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;
+};
+/**
+ * Finds tracks that are **published but consumed by nobody** — uplink and SFU ingress spent on media
+ * that is never forwarded anywhere.
+ *
+ * This is the one detector that reads the resolver's *silence* as the signal: an outbound track with
+ * an empty `remoteInboundTracks` set, still pushing packets. It reads `call.unconsumedOutboundTracks`,
+ * which the resolver maintains as tracks gain and lose subscribers, so a healthy call costs one
+ * `size === 0` check rather than a walk over every published track. The usual causes are a participant
+ * publishing while everyone has them hidden or muted-in-UI, a simulcast layer no viewer's bandwidth
+ * ever selects, or an application that forgot to stop a track after the last subscriber left.
+ *
+ * It is deliberately slow to fire: `minUnconsumedDurationInMs` must elapse with the track still
+ * sending, because a brief gap between publishing and the first subscription is completely normal at
+ * join time.
+ *
+ * ### Careful: this detector is only sound with a resolver
+ *
+ * "No subscribers" and "no resolver configured" produce the identical observation — an empty link
+ * set. Without a `RemoteTrackResolver` this would report *every* published track in the call as
+ * unconsumed, so it checks `call.remoteTrackResolver` at runtime and does nothing without one.
+ */
+declare class UnconsumedTrackDetector implements Detector {
+    private readonly call;
+    static readonly NAME = "unconsumed-track-detector";
+    readonly name = "unconsumed-track-detector";
+    readonly config: UnconsumedTrackDetectorConfig;
+    /** trackId -> when it was first seen sending with no subscribers. */
+    private readonly _unconsumedSince;
+    private readonly _lastRaisedAt;
+    constructor(call: ObservedCall, config?: Partial<UnconsumedTrackDetectorConfig>);
+    update(): void;
+    close(): void;
+}
+
+/**
+ * Detectors that reason **across calls**, created once on the observer.
+ *
+ * Adding one means: give the class a `static readonly NAME`, add its entry here, and add a `case` to
+ * `Observer.addObserverDetector`. This map is what types the call site — the config is checked
+ * against the right detector and an unknown name won't compile.
+ */
+type AvailableObserverScopeDetectorsConfigs = {
+    [SfuCongestionDetector.NAME]: SfuCongestionDetectorConfig;
+    [ObserverConcurrentIssueDetector.NAME]: ObserverConcurrentIssueDetectorConfig;
+    [ClientPopulationIssueDetector.NAME]: ClientPopulationIssueDetectorConfig;
+    [TurnServerHealthDetector.NAME]: TurnServerHealthDetectorConfig;
+    [TurnServerOutageDetector.NAME]: TurnServerOutageDetectorConfig;
+};
+/**
+ * Detectors that reason **within one call**, created for every call the observer opens.
+ *
+ * Note there is no detector in both maps. "Is this meeting in trouble?" and "is our infrastructure in
+ * trouble?" are different questions with different gates and different findings, so they are separate
+ * classes — `CallConcurrentIssueDetector` and `ObserverConcurrentIssueDetector` — rather than one
+ * class branching on what it was handed.
+ */
+type AvailableCallScopeDetectorsConfigs = {
+    [UnconsumedTrackDetector.NAME]: UnconsumedTrackDetectorConfig;
+    [TrackDeliveryMismatchDetector.NAME]: TrackDeliveryMismatchDetectorConfig;
+    [CallConcurrentIssueDetector.NAME]: CallConcurrentIssueDetectorConfig;
+    [IssueFanOutDetector.NAME]: IssueFanOutDetectorConfig;
+    [PublisherFaultCorroborationDetector.NAME]: PublisherFaultCorroborationDetectorConfig;
+};
+type AvailableDetectorsConfigs = AvailableObserverScopeDetectorsConfigs | AvailableCallScopeDetectorsConfigs;
+declare class Detectors {
+    private _detectors;
+    constructor(...detectors: Detector[]);
+    /**
+     * Every registered detector, in registration order.
+     *
+     * This is **the** way to get hold of an instance: `addDetector` / `addObserverDetector` are
+     * chainable and return the owning entity, so the registry is where instances live. Read it to
+     * inspect a detector's state, or to pick one out and {@link remove} it.
+     *
+     * A copy, not the live array — a caller iterating this while removing would otherwise skip
+     * entries, and that is exactly what "remove the ones that look like X" does.
+     */
+    get instances(): Detector[];
+    /** Iterate the registry directly: `for (const detector of call.detectors)`. */
+    [Symbol.iterator](): IterableIterator<Detector>;
+    /** The names in registration order. Duplicates are meaningful — see {@link getAll}. */
+    get listOfNames(): string[];
+    get size(): number;
+    add(detector: Detector): void;
+    /** The first detector registered under `name`. See {@link getAll} when several can share one. */
+    get(name: string): Detector | undefined;
+    /**
+     * Every detector registered under `name`.
+     *
+     * More than one is legitimate: `ClientPopulationIssueDetector` is meant to be added once per
+     * `groupBy` axis, and two instances of it share a name.
+     */
+    getAll(name: string): Detector[];
+    has(name: string): boolean;
+    /** Remove one specific instance. Returns `false` if it was not registered here. */
+    remove(detector: Detector): boolean;
+    /**
+     * Remove **every** detector registered under `name`, returning how many were removed.
+     *
+     * All of them rather than the first, because a name can legitimately be registered more than once
+     * (see {@link getAll}) and "remove the `client-population-issue-detector`" cannot sensibly mean
+     * "remove whichever axis happens to be first in the array". Removing all of them is the only
+     * behaviour that leaves the registry in a state the caller can predict from the name alone.
+     *
+     * Each removed detector gets `close()`, so trackers unsubscribe from the issue registry, bus
+     * listeners drop, and timers clear — a detector removed without closing keeps being fed issues
+     * forever.
+     */
+    removeByName(name: string): number;
+    update(): void;
+    clear(): void;
+    private _close;
+}
+
+/**
+ * The set of client issues currently believed to be **open**, plus the fan-out that pushes them to
+ * whoever asked for them.
+ *
+ * ### Push, not poll
+ *
+ * A detector does not scan for the issues it cares about; it registers as an
+ * {@link ActiveIssueTracker} for the types it consumes and is handed them as they open and close.
+ * The cost of a detector is then proportional to the issues it actually receives, not to the number
+ * of participants — a healthy 500-client fleet does no work per tick.
+ *
+ * ```ts
+ * observer.activeIssuesRegistry.addIssueTracker('congestion', detector);
+ * ```
+ *
+ * There is **no wildcard**. A tracker names the types it consumes, and nothing else reaches it. "Feed
+ * me everything and I'll work out what matters" pushes the decision from the application — which
+ * knows its client build and its issue vocabulary — onto a detector that has to guess, and it makes
+ * the cost of a subscription unbounded and invisible. If a detector should watch five issue types,
+ * the caller lists five issue types.
+ *
+ * ### Two levels
+ *
+ * Every call owns a registry constructed with the observer's as its `parent`. An add or delete
+ * touches both, so a call-scoped tracker sees only that call's issues while an observer-scoped one
+ * sees the fleet — without either side iterating the other. The child keeps **its own** storage:
+ * `size` is this scope's count, and {@link clear} (called when the call closes) removes only this
+ * scope's issues from the parent and never touches the parent's tracker registrations.
+ *
+ * ### Only keyed issues arrive here
+ *
+ * An issue without a `key` has no lifecycle — nothing can ever close it — so treating it as "active"
+ * would mean holding a symptom that may have ended long ago. Keyless issues stay one-shot: emitted
+ * as `client-issue`, never registered. `client-monitor-js` >= 4.6.0 sends `key` on everything
+ * stateful.
+ */
+declare class ActiveIssuesRegistry implements ActiveIssueTracker {
+    private readonly parent?;
+    private readonly issues;
+    private readonly typesToTrackers;
+    constructor(parent?: ActiveIssueTracker | undefined);
+    get size(): number;
+    /**
+     * The open issues in this scope, in insertion order.
+     *
+     * Insertion order is age order (`observedAt` is assigned on insert), which is what lets a consumer
+     * stop at the first entry newer than its cutoff instead of scanning the whole set.
+     */
+    values(): IterableIterator<ActiveClientIssue>;
+    [Symbol.iterator](): IterableIterator<ActiveClientIssue>;
+    has(issue: ActiveClientIssue): boolean;
+    add(issue: ActiveClientIssue): this;
+    delete(issue: ActiveClientIssue): boolean;
+    /** Feed `tracker` every issue of `type` as it opens and closes. One call per type; no wildcard. */
+    addIssueTracker(type: string, tracker: ActiveIssueTracker): this;
+    removeIssueTracker(tracker: ActiveIssueTracker): this;
+    /**
+     * Drop every issue in this scope, e.g. because the call closed.
+     *
+     * Deletes through {@link delete} so the parent sheds exactly this scope's issues. Tracker
+     * *registrations* survive: a detector subscribed to the observer's registry must keep receiving
+     * issues after any one call ends.
+     */
+    clear(): void;
+    private _trackIssue;
+    private _untrackIssue;
+    /**
+     * Apply `apply` to every tracker interested in `type`.
+     *
+     * A tracker throwing must not abort the fan-out: the issue has already been added to (or removed
+     * from) this registry, so a partial dispatch would leave the remaining trackers permanently out of
+     * step with it. One broken detector should not desynchronise the others.
+     */
+    private _trackersOf;
+    private _safely;
+}
+
+type ObservedCallSettings<AppData extends Record<string, unknown> = Record<string, unknown>> = {
+    callId: string;
+    appData?: AppData;
+    closeCallIfEmptyForMs?: number;
+    /**
+     * When `true`, the call's `update()` is invoked whenever a client accepts a sample. When `false`, it is not.
+     *
+     * DEFAULT: `true` — the call is updated on every client sample, which is the most common use case.
+     */
+    autoUpdateOnClientUpdate?: boolean;
+};
+type ObservedCallEvents = {
+    update: [];
+    newclient: [ObservedClient];
+    empty: [];
+    'not-empty': [];
+    close: [];
+};
+declare interface ObservedCall {
+    on<U extends keyof ObservedCallEvents>(event: U, listener: (...args: ObservedCallEvents[U]) => void): this;
+    off<U extends keyof ObservedCallEvents>(event: U, listener: (...args: ObservedCallEvents[U]) => void): this;
+    once<U extends keyof ObservedCallEvents>(event: U, listener: (...args: ObservedCallEvents[U]) => void): this;
+    emit<U extends keyof ObservedCallEvents>(event: U, ...args: ObservedCallEvents[U]): boolean;
+}
+declare class ObservedCall<AppData extends Record<string, unknown> = Record<string, unknown>> extends EventEmitter {
+    readonly observer: Observer;
+    readonly activeIssuesRegistry: ActiveIssuesRegistry;
+    scoreCalculator: ScoreCalculator;
+    readonly detectors: Detectors;
+    readonly callId: string;
+    readonly observedClients: Map<string, ObservedClient<Record<string, unknown>>>;
+    readonly clientsUsedTurn: Set<string>;
+    readonly calculatedScore: CalculatedScore;
+    remoteTrackResolver?: RemoteTrackResolver;
+    /**
+     * The accumulating record of this call's life, or `undefined` when no summary was configured.
+     *
+     * Live — read it at any point during the call. It is also delivered once on `call-summary` when
+     * the call closes. See `CallSummary`: an absent section means "not collected", never "nothing
+     * happened".
+     */
+    summary?: CallSummary;
+    /**
+     * Published tracks that currently have **no** subscriber linked to them.
+     *
+     * Maintained by the `RemoteTrackResolver` at the exact moments a track gains or loses its last
+     * subscriber — the only moments the answer can change. `UnconsumedTrackDetector` reads this
+     * instead of walking every published track in the call, so in a healthy call (where the set is
+     * empty) it does no work at all.
+     *
+     * Empty when no resolver is configured: without links, "no subscribers" is unknowable.
+     */
+    readonly unconsumedOutboundTracks: Set<ObservedOutboundTrack>;
+    totalAddedClients: number;
+    totalRemovedClients: number;
+    numberOfIssues: number;
+    numberOfPeerConnections: number;
+    numberOfInboundRtpStreams: number;
+    numberOfOutboundRtpStreams: number;
+    numberOfDataChannels: number;
+    maxNumberOfClients: number;
+    deltaNumberOfIssues: number;
+    appData: AppData;
+    closed: boolean;
+    startedAt?: number;
+    endedAt?: number;
+    closedAt?: number;
+    readonly settings: Pick<ObservedCallSettings, 'closeCallIfEmptyForMs' | 'autoUpdateOnClientUpdate'>;
+    /** Ancestry base shared by all Observer-bus events originating at this call. */
+    readonly eventScope: ObservedCallScope;
+    private closeTimer?;
+    constructor(settings: ObservedCallSettings<AppData>, observer: Observer, activeIssuesRegistry: ActiveIssuesRegistry);
+    get numberOfClients(): number;
+    get score(): number | undefined;
+    /**
+     * Build a call-scoped detector onto this call. Chainable.
+     *
+     * To get a handle on what was built — to inspect it, or to remove that exact instance later — read
+     * it back off the registry: `call.detectors.getAll(name)`, or `call.detectors.instances`.
+     */
+    addDetector<K extends keyof AvailableCallScopeDetectorsConfigs>(name: K, config?: Partial<AvailableCallScopeDetectorsConfigs[K]>): this;
+    /**
+     * Start accumulating this call's summary, if the observer was configured for summaries.
+     *
+     * Called by `createObservedCall`; you should not need it. It takes no configuration of its own on
+     * purpose: the collector subscribes to exactly the events the observer's `include` requires, so a
+     * per-call section outside that set would be created and then never written to — an empty section
+     * that reads as "nothing happened". One shape per observer is the only shape that can be filled.
+     *
+     * The collector builds it rather than this method, so the resolved configuration never has to
+     * leave the one object that owns it. Returns `undefined` when summaries are off, and is
+     * idempotent: an existing summary is kept, not restarted.
+     */
+    enableSummary(): CallSummary | undefined;
+    /**
+     * Remove a detector from **this call** by name, returning how many were removed.
+     *
+     * **Every** instance under the name goes — a name can legitimately be registered more than once.
+     * When you want one of them specifically, go through the registry, which deals in instances:
+     *
+     * ```ts
+     * const [ first ] = call.detectors.getAll('issue-fan-out-detector');
+     *
+     * call.detectors.remove(first);
+     * ```
+     *
+     * Either route `close()`s the detector, so it unsubscribes from `activeIssuesRegistry` — without
+     * that the registry keeps feeding a detector nobody is running any more, and its tracked set grows
+     * for the life of the call.
+     *
+     * To stop building it on *future* calls too, use `observer.removeCallDetector(name)`.
+     */
+    removeDetector(name: keyof AvailableCallScopeDetectorsConfigs): number;
+    /**
+     * Raise a call-level (server-side) finding; surfaced on the Observer bus as `call-issue`.
+     *
+     * `payload` is an **object** and holds evidence only — it is delivered to an in-process handler,
+     * so there is nothing to serialise for. `scope` is stamped here, and the `callId` is already on
+     * the event, so neither belongs in the payload. Put the interpretation in `conclusion`.
+     */
+    addIssue(issue: Omit<CallIssue, 'scope'>): void;
+    close(): void;
+    getObservedClient<ClientAppData extends Record<string, unknown> = Record<string, unknown>>(clientId: string): ObservedClient<ClientAppData> | undefined;
+    createObservedClient<ClientAppData extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedClientSettings<ClientAppData>, acceptCtx?: AcceptContext): ObservedClient<ClientAppData> | undefined;
+    getOrCreateObservedClient<ClientAppData extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedClientSettings<ClientAppData>, acceptCtx?: AcceptContext): ObservedClient<ClientAppData> | undefined;
+    update(context?: AcceptContext): void;
+    private _onClientUpdate;
+    private _clientJoined;
+    private _clientLeft;
+    /** Emit an Observer-bus event scoped to this call. */
+    private _notify;
+}
+
+type Middleware<T> = (input: T, next: (nextInput: T) => void) => void;
+interface Processor<T> {
+    finalCallback?: Callback<T>;
+    process(value: T): void;
+    addMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
+    removeMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
+}
+type Callback<T> = (input: T) => void;
+declare class MiddlewareProcessor<T> implements Processor<T> {
+    private stack;
+    finalCallback?: Callback<T>;
+    addMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
+    removeMiddleware(...middlewares: Middleware<T>[]): Processor<T>;
+    process(value: T): void;
+}
+
+/** Raised once if one receiver turns out to be dragging a publisher down for everyone. */
+declare const LOWEST_COMMON_DENOMINATOR_ISSUE = "WORST_RECEIVER_CONTAGION";
+/** The measurements behind a decided verdict — everything needed to check the call yourself. */
+type SimulcastReceiverEvidence = {
+    callId: string;
+    trackId: string;
+    publisherClientId: string;
+    worstReceiverClientId: string;
+    publisherBitrate: number;
+    worstReceiverBitrate: number;
+    medianReceiverBitrate: number;
+    /** How closely the publisher's bitrate followed the **worst** receiver's, `0..1`. */
+    trackingWithWorst: number;
+    /** The same against the **median** receiver — the control. */
+    trackingWithMedian: number;
+};
+type SimulcastReceiverReportPayload = ({
+    /** The publisher held up while one receiver lagged: layers are being chosen per consumer. */
+    verdict: 'layer-decided-per-receiver';
+    evidence: SimulcastReceiverEvidence;
+} | {
+    /** The publisher tracked its worst receiver: everyone is getting the lowest common denominator. */
+    verdict: 'layer-decided-lowest-common-denominator';
+    evidence: SimulcastReceiverEvidence;
+} | {
+    /** Gave up without the conditions needed to judge. **Not a pass.** */
+    verdict: 'inconclusive';
+    reason: string;
+}) & {
+    startedAt: number;
+    /** How many times the check actually ran — i.e. how much the verdict is worth. */
+    checks: number;
+};
+type SimulcastReceiverValidatorConfig = {
+    /**
+     * 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 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. 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 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 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 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;
+};
+/**
+ * Answers one question: **does this SFU adapt each receiver on its own, or does one bad receiver
+ * drag the publisher down for everyone?**
+ *
+ * That is what simulcast (or SVC) exists to prevent. With several encodings available the server can
+ * hand the struggling participant a lower layer and leave everyone else alone. Without it — or with
+ * a server that relays RTCP end to end instead of terminating it, so the publisher's bandwidth
+ * estimate collapses to the minimum across all receivers — the only way to serve the slowest
+ * participant is to make the source send less, and everybody gets the lowest common denominator.
+ *
+ * The two causes are worth naming because the *observation* cannot separate them: the publisher's
+ * bitrate tracking its worst receiver looks identical either way. What the check establishes is
+ * whether per-receiver adaptation is happening at all. If the verdict is
+ * `layer-decided-lowest-common-denominator`, look at both — is simulcast/SVC actually enabled with
+ * layers selected per consumer, and is the SFU terminating receiver reports rather than forwarding
+ * them?
+ *
+ * ### The control matters more than the correlation
+ *
+ * "Publisher follows worst receiver" alone proves nothing: when the whole call degrades together,
+ * the publisher follows *everyone*, and that is ordinary adaptation working correctly. The verdict
+ * only goes against the deployment when the publisher tracks the worst receiver **more closely than
+ * it tracks the median** — the worst receiver is leading, not merely coinciding.
+ *
+ * Likewise, a window with no outlier in it is not evidence of health, it is an untested SFU: if
+ * nobody is struggling, there is nothing for per-receiver adaptation to do. Those windows are
+ * skipped and never counted in `checks`.
+ *
+ * ### Why a validator, not a detector
+ *
+ * This is a property of the SFU build and configuration, not of this moment: a server doing
+ * per-receiver layer selection at 09:00 still is at 17:00. Re-deriving it every tick cannot produce
+ * new information — it would only keep a sliding window alive per published track for the life of
+ * every call. So it decides once, reports, and releases that state.
+ *
+ * ```ts
+ * observer.on('validation-ready', ({ validator, report }) => {
+ *   if (validator !== 'simulcast-receivers' || !report.ready) return;
+ *   console.log(report.verdict);   // 'layer-decided-per-receiver' | ... | 'inconclusive'
+ * });
+ *
+ * observer.addValidator('simulcast-receivers');
+ * onDeploy(() => observer.addValidator('simulcast-receivers'));   // check again
+ * ```
+ *
+ * ### `inconclusive` is not a pass
+ *
+ * The check only runs when a publisher has several receivers and one of them is far behind the
+ * median; plenty of healthy deployments never present that. Concluding from the absence of a failure
+ * would verify nothing, so `checks` counts the times the check genuinely ran, and a validator that
+ * is cancelled (or whose observer closes) finishes `inconclusive` with the reason why.
+ */
+declare class SimulcastReceiverValidator implements Validator<SimulcastReceiverReportPayload> {
+    private readonly _observer;
+    readonly onDone: (report: ValidationReport<SimulcastReceiverReportPayload>) => void;
+    static readonly NAME: "simulcast-receivers";
+    readonly name: "simulcast-receivers";
+    readonly startedAt: number;
+    report: ValidationReport<SimulcastReceiverReportPayload>;
+    private readonly _config;
+    private readonly _windows;
+    private _checks;
+    private _done;
+    constructor(_observer: Observer, onDone: (report: ValidationReport<SimulcastReceiverReportPayload>) => void, config?: Partial<SimulcastReceiverValidatorConfig>);
+    /** How many times the comparison actually ran. `0` means nothing was established. */
+    get checks(): number;
+    /** Give up without a verdict, freeing anything waiting on this validator. */
+    cancel(reason?: string): void;
+    update(): void;
+    /** Returns `true` when a verdict was reached and the caller should stop iterating. */
+    private _inspect;
+    /**
+     * Settle on a verdict, exactly once.
+     *
+     * The guard is not paranoia: `onDone` removes this validator from the observer, and a second call
+     * would emit a second `validation-ready` for a validator that is no longer registered — e.g. when
+     * `observer.close()` cancels a validator that decided earlier in the same tick.
+     */
+    private _finish;
+    private _windowOf;
+}
+
+/** Raised once if the resolver turns out never to link anything. */
+declare const UNRESOLVED_TRACK_LINKS_ISSUE = "REMOTE_TRACK_LINKS_UNRESOLVED";
+/** What the check actually saw, whichever way it went. */
+type RemoteTrackLinkEvidence = {
+    /** Calls that presented the conditions for linking: a resolver, ≥2 clients, and inbound tracks. */
+    eligibleCalls: number;
+    /** Inbound tracks seen across those calls. */
+    inboundTracks: number;
+    /** Of those, how many were linked to the outbound track that published them. */
+    linkedInboundTracks: number;
+    /** `linkedInboundTracks / inboundTracks`. */
+    linkedRatio: number;
+    /** A call that presented the conditions, for the reader to go and look at. */
+    exampleCallId?: string;
+};
+type RemoteTrackResolverReportPayload = ({
+    /** The resolver is linking subscribers to publishers. The detectors that need links will work. */
+    verdict: 'links-resolved';
+    evidence: RemoteTrackLinkEvidence;
+} | {
+    /** Every condition for linking was met, repeatedly, and nothing was ever linked. */
+    verdict: 'no-links-resolved';
+    evidence: RemoteTrackLinkEvidence;
+} | {
+    /** Never saw a call that could have been linked. **Not a pass.** */
+    verdict: 'inconclusive';
+    reason: string;
+}) & {
+    startedAt: number;
+    /** How many times the check genuinely ran — i.e. how much the verdict is worth. */
+    checks: number;
+};
+type RemoteTrackResolverValidatorConfig = {
+    /**
+     * 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 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, `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. 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;
+};
+/**
+ * Answers one question: **is the `RemoteTrackResolver` actually linking anything?**
+ *
+ * ### Why this is worth a validator
+ *
+ * Four things in this library are built on publisher↔subscriber links —
+ * `IssueFanOutDetector`, `TrackDeliveryMismatchDetector`, `UnconsumedTrackDetector` and
+ * `SimulcastReceiverValidator`. Every one of them checks `call.remoteTrackResolver` and, finding no
+ * links, correctly does nothing rather than guessing.
+ *
+ * That is the right behaviour and it produces a nasty failure mode: a resolver wired to the wrong id
+ * field, or a mediasoup `producerId` the application never attaches, leaves all four permanently
+ * silent — and **silence is what a healthy deployment looks like too**. You would conclude your
+ * calls were clean when in fact nothing was ever examined. This check exists to make that specific
+ * mistake loud.
+ *
+ * ### `inconclusive` is not a pass
+ *
+ * A verdict is only reached from calls that *could* have been linked: a resolver configured, at
+ * least `minClients` participants, and at least `minInboundTracks` inbound tracks present. A
+ * one-to-one deployment, a lobby full of audio-only listeners, or a quiet period never presents
+ * those conditions — and concluding "resolver works" from calls that had nothing to resolve would be
+ * the very mistake this validator is here to catch. `checks` counts the eligible calls actually
+ * seen; a validator cancelled before reaching `minChecks` finishes `inconclusive` and says so.
+ *
+ * ```ts
+ * observer.on('validation-ready', ({ validator, report }) => {
+ *   if (validator !== 'remote-track-resolver' || !report.ready) return;
+ *   if (report.verdict === 'no-links-resolved') alert('resolver misconfigured — 4 detectors are inert');
+ * });
+ *
+ * observer.addValidator('remote-track-resolver');
+ * ```
+ *
+ * Run it once at start-up, and again after changing the resolver or the SFU's id scheme. Like every
+ * validator it is one-shot: the answer is a property of the wiring, not of this moment.
+ */
+declare class RemoteTrackResolverValidator implements Validator<RemoteTrackResolverReportPayload> {
+    private readonly _observer;
+    readonly onDone: (report: ValidationReport<RemoteTrackResolverReportPayload>) => void;
+    static readonly NAME: "remote-track-resolver";
+    readonly name: "remote-track-resolver";
+    readonly startedAt: number;
+    report: ValidationReport<RemoteTrackResolverReportPayload>;
+    private readonly _config;
+    /** Accumulated across every eligible call seen, so one small call cannot decide alone. */
+    private _eligibleCalls;
+    private _inboundTracks;
+    private _linkedInboundTracks;
+    private _exampleCallId?;
+    private _checks;
+    private _done;
+    constructor(_observer: Observer, onDone: (report: ValidationReport<RemoteTrackResolverReportPayload>) => void, config?: Partial<RemoteTrackResolverValidatorConfig>);
+    /** How many eligible calls were actually examined. `0` means nothing was established. */
+    get checks(): number;
+    cancel(reason?: string): void;
+    update(): void;
+    private _evidence;
+    private _finish;
+}
+
+/** Raised once if the deployment is not actually delivering the codec it thinks it is. */
+declare const CODEC_MISMATCH_ISSUE = "CODEC_INCONSISTENCY";
+/** What the check saw across a call's participants. */
+type CodecEvidence = {
+    callId: string;
+    kind: 'audio' | 'video';
+    /** Every mime type in use in that call, most common first — e.g. `[ 'video/VP8', 'video/H264' ]`. */
+    mimeTypes: string[];
+    /** How many clients used each, in the same order as {@link mimeTypes}. */
+    clientsPerMimeType: number[];
+    /** Clients considered — those that reported at least one codec of this kind. */
+    clients: number;
+    /** The codec the check was told to expect, when it was given one. */
+    expected?: string;
+};
+type CodecConsistencyReportPayload = ({
+    /** One codec per media kind, and it is the expected one if an expectation was given. */
+    verdict: 'codec-consistent';
+    evidence: CodecEvidence[];
+} | {
+    /** Participants of one call are split across different codecs. */
+    verdict: 'codec-split';
+    evidence: CodecEvidence[];
+} | {
+    /** Consistent, but not what the deployment believes it negotiated. */
+    verdict: 'unexpected-codec';
+    evidence: CodecEvidence[];
+} | {
+    /** Never saw a call with enough participants reporting codecs. **Not a pass.** */
+    verdict: 'inconclusive';
+    reason: string;
+}) & {
+    startedAt: number;
+    checks: number;
+};
+type CodecConsistencyValidatorConfig = {
+    /**
+     * The mime type you believe you are delivering, per kind — e.g.
+     * `{ video: 'video/VP8', audio: 'audio/opus' }`.
+     *
+     * Optional. Without it the check still reports a *split* (participants disagreeing with each
+     * other), which needs no expectation to be a fact. With it, the check can additionally catch the
+     * 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 `[ '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`.
+     *
+     * 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`.
+     *
+     * 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;
+};
+/**
+ * Answers: **is every participant of a call actually using the same codec — and is it the one you
+ * think you negotiated?**
+ *
+ * ### Why the server has to answer this
+ *
+ * A client knows only its own codec. It cannot tell whether it is the odd one out, and an SFU that
+ * forwards without transcoding cannot serve a call where participants disagree — so a split is a
+ * real fault with a very confusing symptom: some pairs of participants see each other and some do
+ * not, with no error anywhere. Only something holding every participant of a call at once can see
+ * the split at all.
+ *
+ * The second half is the quieter failure. A deployment configured for VP9 or AV1 will fall back to
+ * VP8 whenever one endpoint cannot negotiate the preferred codec, and nothing reports that — the
+ * call works, the bitrate is higher than it should be, and the team believes it shipped AV1 months
+ * ago. Give the check an `expected` mime type and it will say so.
+ *
+ * ### Why a validator and not a detector
+ *
+ * The answer is a property of the deployment — SDP munging, codec preferences, the SFU build — not
+ * of this moment. A deployment that negotiates VP8 at 09:00 negotiates VP8 at 17:00. Re-deriving it
+ * every tick would walk every codec of every peer connection of every call, forever, to re-learn a
+ * constant. So it decides once and stops.
+ *
+ * Start it again after a deploy, or after changing codec preferences:
+ *
+ * ```ts
+ * observer.addValidator('codec-consistency', {
+ *   expected: { video: 'video/VP9', audio: 'audio/opus' },
+ * });
+ *
+ * observer.on('validation-ready', ({ validator, report }) => {
+ *   if (validator !== 'codec-consistency' || !report.ready) return;
+ *   // 'codec-consistent' | 'codec-split' | 'unexpected-codec' | 'inconclusive'
+ * });
+ * ```
+ *
+ * ### `inconclusive` is not a pass
+ *
+ * Only calls with at least `minClients` participants *reporting codecs of that kind* count as a
+ * check. An audio-only deployment will never say anything about video, and concluding "video codecs
+ * are consistent" from calls that carried no video would verify nothing.
+ *
+ * ### Comparison is by mime type only
+ *
+ * `sdpFmtpLine` carries profile and level — `profile-level-id` for H.264, `profile-id` for VP9 — and
+ * two clients on the same mime type with different profiles are not truly interchangeable. That is
+ * deliberately out of scope: fmtp differences are common, usually benign, and would make this check
+ * noisy enough to ignore. It answers the coarse question, which is the one that is actually wrong in
+ * practice.
+ */
+declare class CodecConsistencyValidator implements Validator<CodecConsistencyReportPayload> {
+    private readonly _observer;
+    readonly onDone: (report: ValidationReport<CodecConsistencyReportPayload>) => void;
+    static readonly NAME: "codec-consistency";
+    readonly name: "codec-consistency";
+    readonly startedAt: number;
+    report: ValidationReport<CodecConsistencyReportPayload>;
+    private readonly _config;
+    private readonly _inspectedCallIds;
+    private _evidence;
+    private _checks;
+    private _done;
+    constructor(_observer: Observer, onDone: (report: ValidationReport<CodecConsistencyReportPayload>) => void, config?: Partial<CodecConsistencyValidatorConfig>);
+    get checks(): number;
+    cancel(reason?: string): void;
+    update(): void;
+    /** One evidence entry per configured kind that the call actually carried. */
+    private _tallyOf;
+    private _finish;
+}
+
+/**
+ * The validators `observer.addValidator(name, config)` knows how to build, and the config each takes.
+ *
+ * Adding one means: write the class with a `static readonly NAME`, add its entry here, and add a
+ * `case` to `addValidator`. The map is what gives the call site its types —
+ * `addValidator('simulcast-receivers', { … })` type-checks the config against the right validator,
+ * and an unknown name won't compile.
+ */
+type AvailableValidatorConfigs = {
+    [SimulcastReceiverValidator.NAME]: SimulcastReceiverValidatorConfig;
+    [RemoteTrackResolverValidator.NAME]: RemoteTrackResolverValidatorConfig;
+    [CodecConsistencyValidator.NAME]: CodecConsistencyValidatorConfig;
+};
+/** A validator name that can be started. */
+type ValidatorName = keyof AvailableValidatorConfigs;
+
+/**
+ * Keeps every configured `CallSummary` up to date, from **observer-level** bus subscriptions.
+ *
+ * ### Why one collector and not one per call
+ *
+ * The obvious implementation subscribes each call's summary to the events it needs. But the bus is
+ * observer-wide: a listener attached for call A is invoked for every event of every call, so that
+ * design costs `calls × events` listeners *and* `calls` invocations per event — quadratic in the
+ * thing most likely to be large. At 500 concurrent calls and eight subscribed events that is 4 000
+ * listeners doing 500 no-op calls each, per event.
+ *
+ * So the collector attaches **one listener per event type, once**, and routes each event to the
+ * summary of the call it names. Cost is O(subscribed event types), independent of how many calls are
+ * in flight, and an event for a call with no summary costs one `undefined` check.
+ *
+ * ### Only call-scoped events
+ *
+ * Routing needs `observedCall` on the payload, which is exactly what `CallScopedEventName` selects.
+ * Observer-scoped events have no single call to attribute to; see that type for why fanning them out
+ * to every open summary would be worse than refusing.
+ */
+declare class CallSummaryCollector {
+    private readonly _observer;
+    private readonly _config;
+    private readonly _scratch;
+    private readonly _listeners;
+    private _closed;
+    constructor(_observer: Observer, _config: CallSummaryConfig);
+    /**
+     * Build a summary for `callId` and start tracking it.
+     *
+     * Creating it here, rather than letting the call create one and hand it over, keeps the resolved
+     * configuration inside the single object that owns it — and makes it impossible to end up with a
+     * summary whose sections nobody subscribed to fill.
+     */
+    createSummary(callId: string): CallSummary;
+    /**
+     * Finalise `call`'s summary: fold in what only makes sense once, and stamp the closing times.
+     *
+     * Percentiles are computed here rather than on every update — a median recomputed per tick over a
+     * growing array is quadratic work to produce a number nobody reads until the end.
+     */
+    finalise(call: ObservedCall): void;
+    /** Drop every bus subscription. Called when the observer closes. */
+    close(): void;
+    /**
+     * Subscribe `listener` to `event`, routed to the summary of the call the event names.
+     *
+     * The `observedCall` is read off the payload rather than closed over, which is what lets one
+     * subscription serve every call.
+     */
+    private _on;
+    private _subscribeBuiltIns;
+    private _subscribeEnrichers;
+}
+
+type SampleRejectedReason = 'observer-closed' | 'missing-callId' | 'missing-clientId';
+
+/**
+ * Optional, free-form context supplied to `accept()`. A single context object is
+ * threaded down the accept chain (Observer -> Client -> PeerConnection) and is
+ * merged into the `appData` of entities created during the accept pass.
+ */
+type AcceptContext = Record<string, unknown>;
+/** The payload threaded through `accept()` middlewares: the sample and its optional context. */
+type AcceptMiddlewarePayload = {
+    sample: ClientSample;
+    context?: AcceptContext;
+};
+/**
+ * A global middleware run on every sample passed to `observer.accept()`, in registration order,
+ * **before** the sample is dispatched to any call/client. It may inspect or mutate the sample
+ * (e.g. set/normalize `callId`/`clientId`, enrich, redact) or the context, then call
+ * `next(payload)` to continue the chain. Not calling `next` **drops** the sample.
+ */
+type AcceptMiddleware = Middleware<AcceptMiddlewarePayload>;
+/** Produces the initial `appData` for a call created without an explicit `appData`. */
+type CallAppDataFactory = (params: {
+    callId: string;
+    observer: Observer;
+    acceptCtx?: AcceptContext;
+}) => Record<string, unknown>;
+/** Produces the initial `appData` for a client created without an explicit `appData`. */
+type ClientAppDataFactory = (params: {
+    clientId: string;
+    observedCall: ObservedCall;
+    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.
+     *
+     * There is deliberately no timer and no separate policy object: a call is updated when any of its
+     * clients is, and the observer is updated when any of its calls is — so the observer is updated
+     * exactly when any client anywhere is. Set to `false` only if you drive `observer.update()`
+     * yourself, and note that observer-scoped detectors and validators run *nowhere else*.
+     */
+    autoUpdateOnCallUpdate?: boolean;
+    /**
+     * Accumulate a {@link CallSummary} on every call this observer creates.
+     *
+     * **Absent or `null` means no summaries at all** — no accumulation, and not one bus subscription.
+     * Pass an object (`{}` is valid) to switch it on; anything you leave out takes its default from
+     * `defaultCallSummaryConfig`, including `include: []`, which collects *no* built-in section. A
+     * summary that only runs `enrich` is a perfectly good summary.
+     *
+     * ```ts
+     * const observer = new Observer({
+     *   callSummary: {
+     *     include: [ 'clients', 'issues' ],
+     *     enrich: {
+     *       'client-joined': (summary, { observedClient }) => {
+     *         ((summary.attachments.regions ??= []) as string[]).push(String(observedClient.appData.region));
+     *       },
+     *     },
+     *   },
+     * });
+     *
+     * observer.on('call-summary', ({ summary }) => archive(summary));
+     * ```
+     *
+     * This is construction-time and fixed for the observer's life, unlike detectors, which are added
+     * per call as an application decides what to watch. A summary is a record of what happened, and a
+     * record you can turn on halfway through is a record with a hole in it — calls that started
+     * earlier would carry different sections from calls that started later, with nothing on either to
+     * 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;
+    };
+    /**
+     * Optional factory invoked when a call is created without an explicit `appData`
+     * (e.g. lazily by `accept()`), so apps can enrich appData without pre-creating the
+     * entity. `appData` is application-owned; it is never modified by the `accept()` context.
+     */
+    createCallAppData?: CallAppDataFactory;
+    /** Same as `createCallAppData`, for clients. Receives the (already-created) parent call. */
+    createClientAppData?: ClientAppDataFactory;
+    /**
+     * Optional factory invoked when a client is created, producing a per-client sink that
+     * receives every sample the client accepts (or `undefined` for no sink). The destination
+     * can be derived from `callId` / `clientId`.
+     */
+    createClientSink?: ClientSampleSinkFactory;
+    /**
+     * Optional factory invoked when a call is created, producing the call's `RemoteTrackResolver`
+     * (or `undefined` for none). Use the built-ins
+     * (`createDefaultMediasoupRemoteTrackResolverFactory()` / `createP2pRemoteTrackResolverFactory()`)
+     * or build a `RemoteTrackResolver` with custom publisher/subscriber id resolvers.
+     */
+    createRemoteTrackResolver?: RemoteTrackResolverFactory;
+};
+declare interface Observer {
+    on<U extends keyof ObserverEvents>(event: U, listener: (...args: ObserverEvents[U]) => void): this;
+    off<U extends keyof ObserverEvents>(event: U, listener: (...args: ObserverEvents[U]) => void): this;
+    once<U extends keyof ObserverEvents>(event: U, listener: (...args: ObserverEvents[U]) => void): this;
+    emit<U extends keyof ObserverEvents>(event: U, ...args: ObserverEvents[U]): boolean;
+}
+declare class Observer<AppData extends Record<string, unknown> = Record<string, unknown>> extends EventEmitter {
     readonly observedTURN: ObservedTURN;
     readonly observedCalls: Map<string, ObservedCall<Record<string, unknown>>>;
     readonly observedMediasoupRouters: Map<string, ObservedMediasoupRouter<Record<string, unknown>>>;
-    updater?: Updater;
     /** Ancestry base shared by all Observer-bus events originating at the observer. */
     readonly eventScope: ObserverEventBase;
+    readonly config: ObserverConfig<AppData>;
     closed: boolean;
     totalAddedCall: number;
     totalRemovedCall: number;
@@ -2831,19 +6223,151 @@ declare class Observer<AppData extends Record<string, unknown> = Record<string,
     numberOfPeerConnections: number;
     /** Global, pre-dispatch middleware chain run on every accepted sample. */
     readonly acceptMiddlewares: MiddlewareProcessor<AcceptMiddlewarePayload>;
-    constructor(config?: ObserverConfig<AppData>);
+    /**
+     * Fleet-wide index of every open client issue, maintained incrementally as issues open and close.
+     * Each call's index propagates into this one, so cross-call queries cost O(matching issues) rather
+     * than a walk over every call and client. This is what observer-scoped detectors read.
+     */
+    readonly activeIssuesRegistry: ActiveIssuesRegistry;
+    /**
+     * Validators currently running. Each removes itself when it finishes, so this is normally empty —
+     * a validator is a one-shot check, not a permanent fixture. Start one with {@link addValidator}.
+     */
+    readonly validators: Set<RunningValidator>;
+    /**
+     * Observer-scoped detector registry, run on every `observer.update()` — the place for findings
+     * that span **calls**, e.g. "many calls on the same SFU degraded at once". Detectors raise
+     * findings with `observer.addIssue(...)`, surfaced on the bus as `observer-issue`.
+     * (For findings within a single call use `observedCall.detectors`.)
+     *
+     * Starts **empty**. Populate it with {@link addObserverDetector}, or `detectors.add(...)` for an
+     * instance you built yourself.
+     */
+    readonly detectors: Detectors;
+    /**
+     * The call-scoped detectors to build on **every** call this observer creates, in registration
+     * order. Written by {@link addCallDetector}; read by `createObservedCall`.
+     *
+     * Nothing is created implicitly. There is no detector configuration in `ObserverConfig` and no
+     * default set, because a detector that nobody asked for is a detector nobody will act on: it costs
+     * time on every tick and raises findings into a handler that was not written to expect them. An
+     * application says what it wants to watch, or it watches nothing.
+     *
+     * ```ts
+     * observer.addCallDetector('call-concurrent-issue-detector', {
+     *   issueTypes: [ 'congestion', 'ice-disconnected' ],
+     * });
+     * ```
+     */
+    readonly callDetectorConfigs: Map<keyof AvailableCallScopeDetectorsConfigs, Partial<UnconsumedTrackDetectorConfig | TrackDeliveryMismatchDetectorConfig | CallConcurrentIssueDetectorConfig | IssueFanOutDetectorConfig | PublisherFaultCorroborationDetectorConfig>>;
+    /**
+     * Owns every call's summary: the resolved `config.callSummary`, the bus subscriptions that keep
+     * the summaries current (one per event type, not one per call), and the summaries themselves.
+     *
+     * `undefined` when `config.callSummary` was absent or `null` — so its presence *is* the answer to
+     * "are summaries on", and nothing is subscribed to anything.
+     */
+    readonly callSummaryCollector?: CallSummaryCollector;
+    constructor(config?: Partial<ObserverConfig<AppData>>);
     get numberOfCalls(): number;
     get appData(): AppData | undefined;
+    /**
+     * Build a cross-call detector onto `observer.detectors`. Chainable.
+     *
+     * To get a handle on what was built — to inspect it, or to remove that exact instance later — read
+     * it back off the registry: `observer.detectors.getAll(name)`, or `observer.detectors.instances`.
+     */
+    addObserverDetector<K extends keyof AvailableObserverScopeDetectorsConfigs>(name: K, config?: Partial<AvailableObserverScopeDetectorsConfigs[K]>): this;
+    /**
+     * Enable a call-scoped detector for calls created **from now on**.
+     *
+     * This edits the config, not the live calls: calls already open keep the detector set they were
+     * built with. To add one to an existing call, use `observedCall.addDetector(...)` directly.
+     */
+    addCallDetector<K extends keyof AvailableCallScopeDetectorsConfigs>(name: K, config?: Partial<AvailableCallScopeDetectorsConfigs[K]>): this;
+    /**
+     * Remove an observer-scoped detector by name, returning how many were removed.
+     *
+     * **Every** instance registered under the name goes, since a name can legitimately be registered
+     * more than once (`ClientPopulationIssueDetector` is meant to be added once per `groupBy` axis).
+     * When you want one of them specifically, go through the registry, which deals in instances:
+     *
+     * ```ts
+     * const [ byBrowser, byOs ] = observer.detectors.getAll('client-population-issue-detector');
+     *
+     * observer.detectors.remove(byOs);   // keeps the browser axis running
+     * ```
+     *
+     * Either route `close()`s the detector, so it unsubscribes from the issue registry and drops any
+     * timers or bus listeners it held.
+     */
+    removeObserverDetector(name: keyof AvailableObserverScopeDetectorsConfigs): number;
+    /**
+     * Stop building `name` on calls created from now on.
+     *
+     * By default this also removes it from the calls **already open**, so that "remove this detector"
+     * means the same thing whether you say it before or after a call started — the alternative leaves
+     * a fleet where the detector is live on some calls and not others, decided by join time. Pass
+     * `{ includeOpenCalls: false }` to change only what future calls are built with.
+     *
+     * Returns the number of live detector instances removed (`0` when only the config changed).
+     */
+    removeCallDetector(name: keyof AvailableCallScopeDetectorsConfigs, { includeOpenCalls }?: {
+        includeOpenCalls?: boolean;
+    }): number;
+    /**
+     * Start a structural check. It runs on each `observer.update()` until it can decide, reports once
+     * on `validation-ready`, and removes itself.
+     *
+     * ```ts
+     * observer.validate('simulcast-receiver-validator', { minChecks: 5 });
+     * ```
+     *
+     * Config keys are optional and merged over that validator's defaults. Call it again — after a
+     * deploy, say — to check again; there is no revalidation timer, because a deploy rather than
+     * elapsed time is what makes a structural verdict stale.
+     */
+    addValidator<K extends keyof AvailableValidatorConfigs>(name: K, config?: Partial<AvailableValidatorConfigs[K]>): this;
+    /**
+     * Stop a running validation, by name or by instance. Returns how many were cancelled.
+     *
+     * Cancelling is **not** silent discarding. The validator finishes with `inconclusive` and the given
+     * `reason`, emits `validation-ready` like any other completion, and removes itself. That matters
+     * because anything waiting on the verdict — a deploy gate, a dashboard, a promise — would otherwise
+     * wait forever, and because "we stopped asking" is a materially different outcome from "we asked
+     * and learned nothing", which is exactly what `inconclusive` with a reason records.
+     *
+     * ```ts
+     * observer.cancelValidator('simulcast-receivers', 'sfu redeployed');
+     *
+     * // or one specific instance — `observer.validators` holds what is running
+     * for (const validator of observer.validators) observer.cancelValidator(validator, 'shutting down');
+     * ```
+     *
+     * Pass a real reason. The default tells the reader nothing they could not already infer.
+     */
+    cancelValidator(target: keyof AvailableValidatorConfigs | RunningValidator, reason?: string): number;
     getObservedCall<T extends Record<string, unknown> = Record<string, unknown>>(callId: string): ObservedCall<T> | undefined;
-    createObservedCall<T extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedCallSettings<T>): ObservedCall<T> | undefined;
-    getOrCreateObservedCall<T extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedCallSettings<T>): ObservedCall<T> | undefined;
+    /**
+     * @param acceptCtx the `accept()` context, when this call is being created to receive a sample.
+     * Passed on to `ObserverConfig.createCallAppData`, so the factory can read whatever the caller (or
+     * an accept middleware) put there — a tenant, a region, a trace id.
+     */
+    createObservedCall<T extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedCallSettings<T>, acceptCtx?: AcceptContext): ObservedCall<T> | undefined;
+    getOrCreateObservedCall<T extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedCallSettings<T>, acceptCtx?: AcceptContext): ObservedCall<T> | undefined;
     createObservedMediasoupRouter<T extends Record<string, unknown> = Record<string, unknown>>(settings: ObservedMediasoupRouterSettings<T> & {
-        callId?: string;
-        bindCallByWebRtcTransportId?: boolean;
+        matchPeerConnectionByWebRtcTransportId?: boolean;
     }): ObservedMediasoupRouter<Record<string, unknown>> | undefined;
     close(): void;
     accept(sample: ClientSample, context?: AcceptContext): void;
     update(): void;
+    /**
+     * Raise an observer-scoped (cross-call / SFU-wide) finding. Emitted on the bus as
+     * `observer-issue`. Intended for `observer.detectors`, but the application may call it too.
+     *
+     * `payload` takes an **object**; see `ObserverIssue`.
+     */
+    addIssue(issue: Omit<ObserverIssue, 'scope'>): void;
     /** Emit an Observer-bus event. */
     private _notify;
 }
@@ -2882,6 +6406,286 @@ declare enum ClientEventTypes {
     DATA_CONSUMER_CLOSED = "DATA_CONSUMER_CLOSED"
 }
 
+/** Thresholds deciding when a client counts as degraded on the receiving / sending side. */
+type ClientHealthThresholds = {
+    /** Inbound loss fraction across the client's received streams (0..1). */
+    inboundFractionLost: number;
+    /** Loss fraction reported back about the client's sent streams via RTCP (0..1). */
+    outboundFractionLost: number;
+    /** Round-trip time (ms). */
+    rttInMs: number;
+    /** Freezes observed across the client's inbound video in the tick. */
+    freezeCount: number;
+    /** Concealment fraction across the client's inbound audio (0..1). */
+    concealmentRatio: number;
+};
+declare const defaultClientHealthThresholds: ClientHealthThresholds;
+/** The per-client health view, split by direction. */
+type ClientHealth = {
+    observedClient: ObservedClient;
+    clientId: string;
+    /** Receiving (download) side is impaired. */
+    inboundDegraded: boolean;
+    /** Sending (upload) side is impaired. */
+    outboundDegraded: boolean;
+    /** `inboundDegraded || outboundDegraded`. */
+    degraded: boolean;
+    reasons: string[];
+    inboundFractionLost?: number;
+    outboundFractionLost?: number;
+    rttInMs?: number;
+    deltaFreezeCount: number;
+    concealmentRatio?: number;
+    /** Quality-limitation reasons seen on this client's outbound video ('cpu' | 'bandwidth' | …). */
+    qualityLimitationReasons: string[];
+    usingTURN: boolean;
+    usingTCP: boolean;
+};
+/** Call-level rollup of the per-client health, using percentiles rather than means. */
+type CallHealth = {
+    callId: string;
+    clients: ClientHealth[];
+    numberOfClients: number;
+    numberOfDegradedClients: number;
+    numberOfInboundDegradedClients: number;
+    numberOfOutboundDegradedClients: number;
+    /** degradedClients / clients (0..1). */
+    degradedRatio: number;
+    inboundDegradedRatio: number;
+    outboundDegradedRatio: number;
+    rttInMs?: StatsSummary;
+    inboundFractionLost?: StatsSummary;
+    concealmentRatio?: StatsSummary;
+    /** How many clients reported each quality-limitation reason on their outbound video. */
+    qualityLimitation: {
+        cpu: number;
+        bandwidth: number;
+        other: number;
+    };
+    freezes: {
+        affectedClients: number;
+        total: number;
+    };
+};
+/**
+ * Aggregates a call along the **client** axis (as `TrackDistributionAggregator` does along the
+ * publisher→subscriber axis): per-client health split into sending vs receiving, plus percentile
+ * rollups and "affected ratio" counts for the whole call.
+ *
+ * Build once per call and call `aggregate()` on each `call.update()`.
+ */
+declare class CallHealthAggregator {
+    private readonly _call;
+    readonly thresholds: ClientHealthThresholds;
+    constructor(_call: ObservedCall, thresholds?: ClientHealthThresholds);
+    aggregate(): CallHealth;
+    private _clientHealth;
+}
+
+/** An entry retained by {@link SlidingWindow}. */
+type SlidingWindowEntry<T> = {
+    timestamp: number;
+    value: T;
+};
+/**
+ * A time-bounded buffer used by detectors that reason over a window ("N of M clients degraded within
+ * 10 s"). Entries older than `windowMs` are evicted on write and on read.
+ *
+ * ### Ordering is enforced, not assumed
+ *
+ * Eviction walks from the front and stops at the first entry still inside the window, which is only
+ * correct if entries are ordered by timestamp. Callers mostly pass `Date.now()` and are ordered by
+ * construction — but not always: a timestamp taken from a client sample, or two calls inside the
+ * same millisecond, can arrive out of order, and one such entry would park itself at the head and
+ * stop eviction *permanently*, so the window would grow without bound and keep reporting symptoms
+ * from hours ago.
+ *
+ * Rather than trust the caller, {@link add} inserts in timestamp order. Appending (the overwhelmingly
+ * common case) stays O(1); an out-of-order insert costs a short backward scan, because such entries
+ * are near the tail in practice.
+ *
+ * ### The window advances on the newest observation
+ *
+ * Eviction is relative to the largest timestamp seen, not the one just passed. A caller that reads
+ * with a `now` behind the newest entry (a replayed sample, a clock that stepped back) would
+ * otherwise un-evict nothing and, worse, a caller passing an old `now` to {@link add} would evict
+ * everything newer.
+ */
+declare class SlidingWindow<T> {
+    readonly windowMs: number;
+    /** Optional hard cap on retained entries, to bound memory on very chatty inputs. */
+    readonly maxEntries: number;
+    private _entries;
+    private _latest;
+    constructor(windowMs: number, 
+    /** Optional hard cap on retained entries, to bound memory on very chatty inputs. */
+    maxEntries?: number);
+    /** Add an entry (defaults to `Date.now()`), then evict anything outside the window. */
+    add(value: T, timestamp?: number): void;
+    /**
+     * The entries still inside the window, oldest first.
+     *
+     * A **copy** — callers routinely map/sort what they get back, and handing out the live array let
+     * them mutate the window from the outside.
+     */
+    entries(now?: number): SlidingWindowEntry<T>[];
+    /** The values still inside the window, oldest first. */
+    values(now?: number): T[];
+    /**
+     * How many entries are inside the window as of `now`.
+     *
+     * Prefer this to `values(now).length`: counting through {@link values} allocates an array of every
+     * entry only to read its length, which on a hot path is the whole cost of the call.
+     */
+    count(now?: number): number;
+    /** Retained entries, without evicting first. See {@link count} for the windowed answer. */
+    get size(): number;
+    clear(): void;
+    private _evict;
+}
+
+type TrendTesterConfig = {
+    /**
+     * 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** — 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. 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;
+};
+/**
+ * Streaming home for `stats.ts`'s two trend tests: feed it one value at a time via {@link add}
+ * instead of re-running the batch functions over an array you manage yourself.
+ *
+ * ### The two tests answer different questions
+ *
+ * Take a client's RTT, sampled every couple of seconds. Two things can go wrong with it, and only
+ * one of them looks like a spike:
+ *
+ * - **Mann-Kendall** asks *"is this drifting?"* — a monotonic trend, regardless of shape or scale.
+ *   `40, 45, 52, 61, 70, 84 ms` is a rising path with no single dramatic step; every jump is small
+ *   and plausible on its own. Mann-Kendall counts how many later samples exceed earlier ones and
+ *   reports whether that lopsidedness could plausibly be chance. It is rank-based, so one absurd
+ *   reading (a 4000 ms outlier from a stalled event loop) moves it by exactly one pair, not by the
+ *   4000.
+ * - **Page-Hinkley** asks *"did it change, and when?"* — a step. `40, 42, 39, 41, 180, 176, 182 ms`
+ *   is not a trend at all; it is one level followed by a different level, which is what a route
+ *   change or a TURN failover looks like. It accumulates the deviation from the running mean and
+ *   fires when the cumulative excess passes `lambda`.
+ *
+ * Neither subsumes the other, which is why both live here on one window. A slow climb toward
+ * unusability shows up in Mann-Kendall and never trips Page-Hinkley; a hard failover trips
+ * Page-Hinkley immediately while Mann-Kendall may read `no-trend`, because after the step the series
+ * is flat again. `tests/trendTester.spec.ts` builds both RTT series and shows exactly this.
+ *
+ * ```ts
+ * const rtt = new TrendTester({ size: 30, mannKendallAlpha: 0.05, pageHinkleyLambda: 50 });
+ *
+ * peerConnection.on('update', () => {
+ *   if (peerConnection.currentRttInMs === undefined) return;   // no measurement is not a measurement
+ *   rtt.add(peerConnection.currentRttInMs);
+ *
+ *   if (rtt.mannKendall().trend === 'increasing') warn('RTT is drifting up');
+ *   if (rtt.pageHinkley()?.changeDetected) {
+ *     warn('RTT stepped');
+ *     rtt.clear();   // the old level is no longer the baseline — judge the new one on its own
+ *   }
+ * });
+ * ```
+ *
+ * ### Both read the same window
+ *
+ * `size` is the one knob controlling how far back either test looks. They are kept incremental
+ * differently, because they don't tolerate an evicted point the same way:
+ *
+ * - **Mann-Kendall**'s statistic is a sum over *pairs*, so evicting the oldest value only touches
+ *   the pairs it was part of — one pass over the (bounded) window corrects it in O(size) instead of
+ *   the O(size²) a full recompute costs.
+ * - **Page-Hinkley**'s statistic is a running minimum of a cumulative sum, which has no cheap
+ *   correction for "forget this one old point" — the minimum may have depended on it. It is
+ *   recomputed from the window on every {@link add} rather than hand-rolling an incremental version
+ *   that would be easy to get subtly wrong. That recompute is O(size), the same order as above.
+ *
+ * ### Non-finite input is rejected, not absorbed
+ *
+ * See {@link add}. A single `NaN` would otherwise destroy the instance permanently.
+ */
+declare class TrendTester {
+    private readonly _size;
+    private readonly _values;
+    private readonly _tieCounts;
+    private readonly _pageHinkleyDelta;
+    private readonly _pageHinkleyLambda;
+    private readonly _mannKendallAlpha;
+    private _s;
+    private _rejected;
+    private _pageHinkleyResult?;
+    constructor(config?: TrendTesterConfig);
+    /** Values rejected by {@link add} for being non-finite. Non-zero means the caller has a bug. */
+    get rejected(): number;
+    /** How many values are currently in the window (`<= size`). */
+    get length(): number;
+    /** The configured window length. */
+    get size(): number;
+    /**
+     * Add the next value in the stream, evicting the oldest once the window is full.
+     *
+     * **Non-finite values are rejected** rather than stored, and the rejection is counted in
+     * {@link rejected}. This is not defensive noise — it is the difference between a bad reading and
+     * a bad instance. `Math.sign(NaN)` is `NaN`, so a single `NaN` would poison the incremental
+     * Mann-Kendall sum `_s` **permanently**: every later `add` and `_evictOldest` adds or subtracts
+     * `NaN`, the z-score is `NaN`, every comparison against it is `false`, and the tester silently
+     * reports `no-trend` forever after. It would also take a `NaN` key in `_tieCounts` that can never
+     * be matched on eviction, since `NaN !== NaN`.
+     *
+     * `undefined` RTT (no measurement this tick) must not be coerced to `0` and passed in either —
+     * "we didn't measure" is not "the trip took no time", and feeding zeros manufactures a downward
+     * trend. Skip the sample instead.
+     */
+    add(value: number): void;
+    /** The current Page-Hinkley read-out over the window. `undefined` before the first value. */
+    pageHinkley(): PageHinkleyResult | undefined;
+    /** The current Mann-Kendall read-out over the window. */
+    mannKendall(): MannKendallResult;
+    /** Drop everything, e.g. after a detected change point, to start judging the trend fresh. */
+    clear(): void;
+    /** Remove the oldest value from the window and correct `_s` for the pairs it was part of. */
+    private _evictOldest;
+    private _bumpTie;
+}
+
 interface Logger {
     trace(...args: any[]): void;
     debug(...args: any[]): void;
@@ -2953,4 +6757,4 @@ declare function createInMemorySink(samples?: ClientSample[]): InMemorySink;
 declare function createDefaultMediasoupRemoteTrackResolverFactory(): RemoteTrackResolverFactory;
 declare function createP2pRemoteTrackResolverFactory(): RemoteTrackResolverFactory;
 
-export { type AcceptContext, type AcceptMiddleware, type AcceptMiddlewarePayload, type CallAppDataFactory, type ClientAppDataFactory, type ClientEvent, ClientEventTypes, type ClientIssue, type ClientMetaData, ClientMetaTypes, type ClientSample, ClientSampleSink, type ClientSampleSinkEvents, type ClientSampleSinkFactory, type Detector, Detectors, InMemorySink, JsonlFileSink, type JsonlFileSinkFactoryOptions, type JsonlFileSinkOptions, type Logger, 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 MediasoupTransportSample, type MediasoupWebRtcTransportSample, type MediasoupWebRtcTransportSampleEventMap, type Middleware, ObservedCall, type ObservedCallScope, ObservedCertificate, ObservedClient, 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, type ObserverEventBase, type ObserverEvents, type ObserverLogger, RemoteTrackResolver, type RemoteTrackResolverFactory, type RemoteTrackResolvers, type SampleRejectedReason, type ScoreCalculator, createDefaultMediasoupRemoteTrackResolverFactory, createInMemorySink, createJsonlFileSink, createJsonlFileSinkFactory, createLogger, createP2pRemoteTrackResolverFactory, setObserverLogger };
+export { type AcceptContext, type AcceptMiddleware, type AcceptMiddlewarePayload, type ActiveClientIssue, type ActiveIssueTracker, ActiveIssuesRegistry, type AvailableCallScopeDetectorsConfigs, type AvailableDetectorsConfigs, type AvailableObserverScopeDetectorsConfigs, type AvailableValidatorConfigs, CODEC_MISMATCH_ISSUE, type CalculatedScore, 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 CertificateStats, 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 CodecStats, type CorroboratedPublisherFault, type DataChannelStats, type Detector, Detectors, type ExtensionStat, GEOHASH_CELL_SIZES, type IceCandidatePairStats, type IceCandidateStats, type IceTransportStats, InMemorySink, type InboundRtpStats, type InboundTrackSample, 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 MediaKind, type MediaPlayoutStats, type MediaSourceStats, 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, MiddlewareProcessor, ObservedCall, type ObservedCallScope, type ObservedCallSettings, ObservedCertificate, ObservedClient, ObservedClientIssueRegistry, type ObservedClientScope, type ObservedClientSettings, ObservedCodec, ObservedDataChannel, ObservedIceCandidate, ObservedIceCandidatePair, ObservedIceTransport, ObservedInboundRtp, ObservedInboundTrack, ObservedMediaPlayout, ObservedMediaSource, ObservedMediasoupRouter, type ObservedMediasoupRouterEvents, type ObservedMediasoupRouterScope, type ObservedMediasoupRouterSettings, ObservedOutboundRtp, ObservedOutboundTrack, ObservedPeerConnection, type ObservedPeerConnectionScope, ObservedPeerConnectionTransport, ObservedRemoteInboundRtp, ObservedRemoteOutboundRtp, ObservedTURN, type ObservedTURNEventMap, ObservedTurnServer, Observer, ObserverConcurrentIssueDetector, type ObserverConcurrentIssueDetectorConfig, type ObserverConcurrentIssueGroup, ObserverConcurrentIssueTypes, type ObserverEventBase, type ObserverEvents, type ObserverIssue, type ObserverIssueSpread, type ObserverLogger, type OutboundRtpStats, type OutboundTrackSample, type PageHinkleyResult, type PeerConnectionSample, type PeerConnectionTransportStats, type PsnrSum, PublisherFaultCorroborationDetector, type PublisherFaultCorroborationDetectorConfig, PublisherFaultTypes, type QualityLimitationDurations, RESOLVED_ISSUE_SUFFIX, type RemoteInboundRtpStats, type RemoteOutboundRtpStats, 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, schemaVersion, setObserverLogger, summarize };