@observertc/observer-js 1.0.0-beta.1 → 1.0.0-beta.11

package/README.md

@@ -1,23 +1,74 @@
-# ObserverTC - Observer JS
+# ObserverTC — `@observertc/observer-js`
 
 [![NPM version](https://img.shields.io/npm/v/@observertc/observer-js.svg)](https://www.npmjs.com/package/@observertc/observer-js)
 [![License](https://img.shields.io/npm/l/@observertc/observer-js.svg)](https://github.com/observertc/observer-js/blob/main/LICENSE)
 
-`observer-js` is a Node.js library for monitoring WebRTC client data. It processes statistical samples from clients, organizes them into calls and participants, tracks a wide range of metrics, detects common issues, and calculates quality scores. This enables real-time insights into WebRTC session performance.
+> **In one line:** feed it WebRTC `getStats()` snapshots, and get back a live, queryable model of
+> every call plus a single typed event stream to react to.
+
+`observer-js` is a **server-side Node.js library for monitoring WebRTC sessions**. A WebRTC
+application (typically an SFU or a signaling/stats backend) feeds it `ClientSample` objects —
+periodic snapshots of each participant's `RTCPeerConnection.getStats()` output plus
+application events — and `observer-js` maintains a live, in-memory model of every call,
+participant, peer connection, and media stream, derives per-interval and cumulative metrics,
+and emits a single, unified stream of typed events the application can react to.
+
+**What you can do with it:**
+
+- **Monitor calls live** — a queryable in-memory tree of every call, client, peer connection,
+  track, codec, ICE candidate and data channel, each holding current **and** cumulative metrics.
+- **React on one event bus** — subscribe once on the `Observer`; every payload carries its full
+  ancestry (`call → client → peer connection → stat`), so you never walk the tree to subscribe.
+- **Get derived metrics for free** — counter-reset-safe per-tick deltas, bitrates, jitter, RTT,
+  fraction-lost, remote-RTP (RTCP) correlation, and TURN/TCP usage from the selected candidate pair.
+- **Correlate across an SFU** — link a publisher's outbound track to every subscriber's inbound
+  track (`RemoteTrackResolver`), and observe mediasoup routers/transports/producers/consumers
+  on the server side.
+- **Detect server-only problems** — cross-client `Detector`s raise `call-issue`s for conditions no
+  single client can see (e.g. everyone in a call degrading at once).
+- **Persist every sample** — per-client sinks (JSONL file, in-memory, or your own) for archival,
+  streaming, and offline replay.
+- **Drop it in safely** — warn-don't-throw, a pluggable logger, dual **ESM + CommonJS**, and **no**
+  media-stack dependency in the core.
+
+> **Status:** `1.0.0-beta`. The API described here is current and intended to be implemented
+> against directly. This document is written to be self-sufficient: an engineer (or an AI
+> agent) should be able to integrate the library, or develop it further, from this file alone.
+> A companion doc, [`docs/logging.md`](./docs/logging.md), covers logging integration in depth.
+
+> **Packaging:** server-side, **Node.js ≥ 22**, shipped as a **dual ESM + CommonJS** build — so it
+> works whether your project uses `import` (ESM) or `require()` (CommonJS). Everything — including
+> the built-in file sink — is exported from the single `@observertc/observer-js` entry.
+
+> **For AI agents:** [`llms.txt`](./llms.txt) is a curated map of these docs (with a one-file
+> [`llms-full.txt`](./llms-full.txt) export for one-shot ingestion); [`AGENTS.md`](./AGENTS.md)
+> covers build/test commands and conventions for working **in** this repository. `llms-full.txt`
+> ships in the npm package (so it's available wherever the library is installed); `llms.txt` and
+> `AGENTS.md` live in the repo (and `llms.txt` belongs at the root of the docs site).
 
-This library is a core component of the ObserverTC ecosystem, designed to provide robust server-side monitoring capabilities for WebRTC applications.
+---
 
-## Features
+## Table of contents
+
+1. [Installation](#installation)
+2. [Quick start](#quick-start)
+3. [Data flow](#data-flow)
+4. [Entity hierarchy](#entity-hierarchy)
+5. [Ingestion: `accept()`, context & lifecycle](#ingestion-accept-context--lifecycle)
+6. [Update policies](#update-policies)
+7. [The event bus](#the-event-bus) ← the core of the API
+8. [API reference](#api-reference)
+9. [Schema types (`ClientSample`)](#schema-types-clientsample)
+10. [Detectors (server-side extension point)](#detectors-server-side-extension-point)
+11. [Remote track resolution (mediasoup / SFU)](#remote-track-resolution-mediasoup--sfu)
+12. [Mediasoup router observation](#mediasoup-router-observation)
+13. [Sinks (per-client sample persistence)](#sinks-per-client-sample-persistence)
+14. [Injecting data into a client](#injecting-data-into-a-client)
+15. [Logging](#logging)
+16. [Error-handling philosophy](#error-handling-philosophy)
+17. [Development & extension guide](#development--extension-guide)
 
-- **Hierarchical Data Model**: Organizes data into `Observer` -> `ObservedCall` -> `ObservedClient` -> `ObservedPeerConnection` and further into streams and data channels.
-- **Comprehensive Metrics**: Tracks a wide array of WebRTC statistics including RTT, jitter, packet loss, codecs, ICE states, TURN usage, bandwidth, and more.
-- **Automatic Entity Management**: Can automatically create and manage call and client entities based on incoming data samples.
-- **Issue Detection**: Built-in detectors for common WebRTC problems.
-- **Quality Scoring**: Calculates quality scores for calls and clients.
-- **Event-Driven**: Emits events for significant state changes, new entities, and detected issues.
-- **Configurable Update Policies**: Flexible control over how and when metrics are processed and updated.
-- **TypeScript Support**: Written in TypeScript, providing strong typing and intellisense.
-- **Extensible**: Supports custom application data (`appData`) and integration with external schema definitions (e.g., `observertc/schemas`).
+---
 
 ## Installation
 
@@ -27,510 +78,1110 @@ npm install @observertc/observer-js
 yarn add @observertc/observer-js
 ```
 
-## Quick Start
+**Server-side, Node.js ≥ 22, dual ESM + CommonJS.** The package ships both module formats, so it
+works the same whether your project is ESM or CommonJS — your import line is unchanged either way:
 
-```typescript
-import { Observer, ObserverConfig } from '@observertc/observer-js';
-import { ClientSample } from '@observertc/schemas'; // Assuming you use the official schemas
+```ts
+import { Observer, ClientSample, createJsonlFileSinkFactory } from '@observertc/observer-js';
+```
 
-// 1. Configure the Observer
-const observerConfig: ObserverConfig = {
-	updatePolicy: 'update-on-interval',
-	updateIntervalInMs: 5000, // Update observer every 5 seconds
-	defaultCallUpdatePolicy: 'update-on-any-client-updated', // Calls update when any client sends data
-};
-const observer = new Observer(observerConfig);
+In an ESM project this resolves to the `.mjs` build; in a CommonJS project (where TypeScript
+compiles your `import` down to `require()`) it resolves to the `.js` build. Everything is exported
+from the single `@observertc/observer-js` entry. Written in TypeScript; ships type declarations for
+both formats (`dist/index.d.ts` for `require`, `dist/index.d.mts` for `import`). Runtime
+dependencies: `@bufbuild/protobuf`, `events`, `uuid`. The library does **not** bundle a logger or
+any transport — see [Logging](#logging).
 
-// 2. Listen to events
-observer.on('newcall', (call) => {
-	console.log(`[Observer] New call detected: ${call.callId}`);
+`ClientSample` and friends are re-exported from this package, and are also published as the
+shared schema in [`@observertc/schemas`](https://github.com/observertc/schemas); samples
+produced on the client (e.g. by `@observertc/client-monitor-js`) conform to the same shape.
 
-	call.on('newclient', (client) => {
-		console.log(`[Call: ${call.callId}] New client joined: ${client.clientId}`);
+---
+
+## Quick start
 
-		client.on('issue', (issue) => {
-			console.warn(`[Client: ${client.clientId}] Issue: ${issue.type} - ${issue.severity} - ${issue.description}`);
-		});
-	});
+```ts
+import { Observer, ClientSample } from '@observertc/observer-js';
+
+// 1. Create an observer.
+const observer = new Observer({
+  // when the observer aggregates call/client metrics:
+  updatePolicy: 'update-when-all-call-updated',
+  // default policy applied to calls created automatically by accept():
+  defaultCallUpdatePolicy: 'update-on-any-client-updated',
+  // optional auto-teardown:
+  closeCallIfEmptyForMs: 20_000,
+  closeClientIfIdleForMs: 60_000,
+});
 
-	call.on('update', () => {
-		console.log(
-			`[Call: ${call.callId}] Metrics updated. Score: ${call.score?.toFixed(1)}, Clients: ${call.numberOfClients}`
-		);
-	});
+// 2. Subscribe on the single bus. Every payload is an object with the ancestry.
+observer.on('call-added', ({ observedCall }) => {
+  console.log('new call', observedCall.callId);
 });
 
-// 3. Process Client Samples
-// (ClientSample typically comes from your application after processing getStats() output)
-function processClientStats(rawStats: any, callId: string, clientId: string) {
-	// Transform rawStats into the ClientSample format
-	// This is a placeholder for your actual transformation logic
-	const sample: ClientSample = {
-		callId,
-		clientId,
-		timestamp: Date.now(),
-		// ...populate with transformed stats from rawStats, adhering to the ClientSample schema
-		// from github.com/observertc/schemas
-	};
-	observer.accept(sample);
+observer.on('client-issue', ({ observedClient, issue }) => {
+  console.warn(`[${observedClient.clientId}] ${issue.type}`, issue.payload);
+});
+
+observer.on('peer-connection-updated', ({ observedClient, observedPeerConnection }) => {
+  console.log(observedClient.clientId, 'RTT(ms):', observedPeerConnection.currentRttInMs);
+});
+
+observer.on('sample-rejected', ({ reason, sample }) => {
+  console.warn('dropped a sample:', reason);
+});
+
+// 3. Feed samples. `context` (optional) is transient per-accept data, carried to the
+//    `*-updated` events this accept triggers (never written to appData).
+function onClientStats(sample: ClientSample) {
+  observer.accept(sample, { studioVersion: '1.2.3' });
 }
 
-// Example usage:
-// const myRawClientStats = getStatsFromClient();
-// processClientStats(myRawClientStats, 'myMeeting123', 'userABC');
+// 4. Tear down.
+process.on('SIGINT', () => observer.close());
+```
 
-// 4. Cleanup when done
-// process.on('SIGINT', () => observer.close());
+---
+
+## Data flow
+
+```
+client getStats()  ──►  ClientSample  ──►  observer.accept(sample, ctx?)
+                                               │
+              ┌────────────────────────────────┘
+              ▼
+   get-or-create ObservedCall ──► get-or-create ObservedClient ──► client.accept(sample, ctx)
+                                                                        │
+                                              per peerConnections[] in the sample
+                                                                        ▼
+                                              get-or-create ObservedPeerConnection
+                                              .accept(pcSample, ctx) updates all sub-stats,
+                                              derives deltas/bitrates/RTT, correlates remote RTP
+                                                                        │
+                          metrics roll up: PeerConnection → Client → Call → Observer
+                                                                        │
+                                          events emitted on the Observer bus  ──►  your handlers
 ```
 
+- A sample **must** have `callId` and `clientId` (the library sets them, or the app does). If
+  either is missing, the sample is dropped and `sample-rejected` is emitted.
+- Sub-entities that stop appearing in samples are garbage-collected via a "visited"
+  mark-and-sweep on each `ObservedPeerConnection.accept()`, emitting the corresponding
+  `*-removed` events.
+
 ---
 
-## Detailed Documentation
+## Entity hierarchy
+
+| Class | Created by | Keyed on its parent as | Holds |
+|-------|-----------|------------------------|-------|
+| `Observer` | `new Observer(config?)` | — (root) | `observedCalls: Map<string, ObservedCall>`, global counters, the event bus |
+| `ObservedCall` | `observer.createObservedCall(settings)` / lazily by `accept` | `observedCalls` | `observedClients: Map<string, ObservedClient>`, call-wide metrics, `detectors`, `scoreCalculator` |
+| `ObservedClient` | `call.createObservedClient(settings)` / lazily | `observedClients` | `observedPeerConnections: Map<string, ObservedPeerConnection>`, per-client metrics |
+| `ObservedPeerConnection` | lazily, from `sample.peerConnections[]` | `observedPeerConnections` | the 15 sub-stat maps below, transport/RTT/bitrate metrics |
+| Sub-stats | lazily, from the `PeerConnectionSample` | maps on the PC | individual WebRTC stat objects |
 
-The following sections provide a comprehensive guide to `observer-js`.
+`ObservedPeerConnection` sub-stat maps (all `public readonly`):
 
-### 1. General Description
+```
+observedCertificates, observedCodecs, observedDataChannels,
+observedIceCandidates, observedIceCandidatesPair, observedIceTransports,
+observedInboundRtps, observedInboundTracks, observedMediaPlayouts,
+observedMediaSources, observedOutboundRtps, observedOutboundTracks,
+observedPeerConnectionTransports, observedRemoteInboundRtps, observedRemoteOutboundRtps
+```
 
-(This section is identical to the introductory paragraph at the top of this README)
+Each sub-stat class (`ObservedInboundRtp`, `ObservedOutboundRtp`, `ObservedInboundTrack`,
+`ObservedOutboundTrack`, `ObservedDataChannel`, `ObservedIceCandidate`,
+`ObservedIceCandidatePair`, `ObservedIceTransport`, `ObservedCertificate`, `ObservedCodec`,
+`ObservedMediaSource`, `ObservedMediaPlayout`, `ObservedPeerConnectionTransport`,
+`ObservedRemoteInboundRtp`, `ObservedRemoteOutboundRtp`) mirrors the corresponding stat
+fields from the schema plus derived fields (deltas, bitrates).
 
-### 2. Core Concepts
+---
 
-#### 2.1. Data Flow
+## Ingestion: `accept()`, context & lifecycle
 
-1.  **Client-Side**: Your application collects WebRTC statistics (e.g., via `RTCPeerConnection.getStats()`).
-2.  **Transformation**: These raw stats are transformed into the `ClientSample` schema (ideally from [observertc/schemas](https://github.com/observertc/schemas)).
-3.  **Ingestion**: The `ClientSample` is passed to the `observer.accept()` method.
-4.  **Processing**: `observer-js` processes the sample, updating or creating relevant entities (`ObservedCall`, `ObservedClient`, `ObservedPeerConnection`, etc.) and their metrics.
-5.  **Analysis**: Metrics are analyzed for issue detection and quality scoring.
-6.  **Events**: Events are emitted for significant state changes, new issues, or updates.
+### `observer.accept(sample, context?)`
 
-#### 2.2. Entity Hierarchy
+The single entry point. It:
 
-- **`Observer`**: The root object, managing multiple calls and global settings.
-  - **`ObservedCall`**: Represents a distinct call session.
-    - **`ObservedClient`**: Represents an individual participant within a call.
-      - **`ObservedPeerConnection`**: Represents a WebRTC RTCPeerConnection of a client.
-        - **`ObservedInboundRtpStream` / `ObservedOutboundRtpStream`**: Tracks individual media streams.
-        - **`ObservedDataChannel`**: Tracks data channels.
-- **`ObservedTURN`**: Tracks global TURN server usage metrics across the observer.
+1. drops + emits `sample-rejected` if the observer is closed;
+2. runs the sample through the **global accept-middleware chain** (see below);
+3. (chain terminal) drops + emits `sample-rejected` if `callId`/`clientId` is missing;
+4. gets or lazily creates the `ObservedCall` and `ObservedClient` (their `appData` comes from the
+   configured factories, never from `context`);
+5. delegates to `client.accept(sample, context)`, which fans out to each
+   `ObservedPeerConnection.accept(pcSample, context)`.
 
-#### 2.3. Automatic Entity Creation
+### Accept middlewares (global pre-dispatch hook)
 
-When `observer.accept(sample)` is called:
+`observer.addAcceptMiddleware(...)` registers middlewares run on **every** sample inside
+`accept()`, in order, **before** the sample is dispatched to any call or client. Each middleware
+gets a `{ sample, context }` payload; it can inspect or mutate the sample (set/normalize
+`callId`/`clientId`, enrich, redact) or the context, then call `next(payload)` to continue.
+**Not calling `next` drops the sample** — nothing is created and no event fires. A throwing
+middleware is caught and warns (the sample is dropped), never crashing `accept()`.
 
-- If an `ObservedCall` for `sample.callId` doesn't exist, it's typically created.
-- If an `ObservedClient` for `sample.clientId` within that call doesn't exist, it's typically created.
-- Peer connections, streams, and data channels are similarly managed based on IDs in the sample.
+```ts
+import { Observer, AcceptMiddleware } from '@observertc/observer-js';
 
-#### 2.4. Metrics Aggregation
+const observer = new Observer();
 
-The library aggregates a wide array of metrics at each level of the hierarchy, including (but not limited to):
+// derive callId/clientId from the app's own attachment, before dispatch
+const route: AcceptMiddleware = ({ sample }, next) => {
+  sample.callId ??= sample.attachments?.roomId as string;
+  sample.clientId ??= sample.attachments?.peerId as string;
+  next({ sample });
+};
 
-- RTT, jitter, packet loss
-- Bytes sent/received (audio, video, data)
-- Codec information
-- ICE connection details, TURN usage
-- Stream/track states (muted, enabled)
-- Frame rates, resolutions
-- Bandwidth estimations
+// drop samples from a blocklisted client (never dispatched)
+const filter: AcceptMiddleware = (payload, next) => {
+  if (blocked.has(payload.sample.clientId)) return;   // no next() => dropped
+  next(payload);
+};
 
-#### 2.5. Issue Detection
+observer.addAcceptMiddleware(route, filter);
+// observer.removeAcceptMiddleware(route);
+```
 
-A `Detectors` system analyzes metrics to identify common WebRTC issues (e.g., high packet loss, low audio levels, frozen video, connection setup problems). Issues are reported via events.
+This is a lightweight global injection point, distinct from the larger (not-yet-built)
+`ClientSampleProcessor` pipeline in the roadmap. When no middleware is registered, `accept()`
+dispatches directly with no overhead.
 
-#### 2.6. Quality Scoring
+### `context` (the `AcceptContext`)
 
-`ScoreCalculator` components assess the quality of calls and clients based on metrics and detected issues, typically resulting in a numerical score (e.g., 0.0 to 5.0).
+```ts
+type AcceptContext = Record<string, unknown>;
+```
 
-#### 2.7. Event-Driven Architecture
+A single, optional, free-form object threaded down the whole accept chain
+(`Observer → Client → PeerConnection`). It is **transient request-scoped data** — temporary or
+contextual information the application wants available while an update is processed.
 
-The library uses Node.js `EventEmitter` to signal various occurrences, allowing applications to react to changes in real-time.
+`context` is **never written to `appData`** and is **not stored** on any entity. The two are
+deliberately distinct:
 
-### 3. API Reference
+- **`appData`** — application-assigned extra info that identifies/decorates an entity, fixed at
+  creation (via `settings.appData` or the `createCallAppData` / `createClientAppData` factories),
+  or assigned by the app on the `*-added` events. The library never changes it.
+- **`context`** — passed per `accept()`, may differ on every call, and is carried straight
+  through to the `*-updated` events that the `accept()` triggers, then discarded.
 
-#### 3.1. `Observer`
+`client-updated` and `peer-connection-updated` carry the exact context of that sample;
+`call-updated` carries the context of the client `accept()` that drove the call update (absent
+for interval- or teardown-driven call updates). When no context is given, the field is absent.
 
-Manages all monitored calls and global observer state.
+### Get-or-create helpers
 
-**Configuration (`ObserverConfig`)**
+If you want to create/configure entities yourself before/without samples:
 
-```typescript
-export type ObserverConfig<AppData extends Record<string, unknown> = Record<string, unknown>> = {
-	updatePolicy?: 'update-on-any-call-updated' | 'update-when-all-call-updated' | 'update-on-interval';
-	updateIntervalInMs?: number; // Used if updatePolicy is 'update-on-interval'
-	defaultCallUpdatePolicy?: ObservedCallSettings['updatePolicy'];
-	defaultCallUpdateIntervalInMs?: number;
-	appData?: AppData; // Custom data for this observer instance
-};
+```ts
+const call = observer.getOrCreateObservedCall({ callId, appData });        // ObservedCall | undefined
+const client = call?.getOrCreateObservedClient({ clientId, appData });     // ObservedClient | undefined
 ```
 
-**Constructor**
+These return `undefined` (and warn) when the parent is closed; `createObservedCall`/
+`createObservedClient` return the **existing** instance (and warn) if the id already exists.
 
-```typescript
-new Observer<AppData>(config?: ObserverConfig<AppData>)
-```
+### Automatic teardown
 
-- `config`: Optional. Defaults: `updatePolicy: 'update-when-all-call-updated'`.
+- `closeClientIfIdleForMs` — a client with no sample for this long auto-closes.
+- `closeCallIfEmptyForMs` — a call with zero clients for this long auto-closes.
+- Closing cascades down (call → clients → peer connections → sub-stats), unsubscribing
+  listeners and emitting the `*-closed` / `*-removed` events.
 
-**Key Properties**
+---
 
-- `observedCalls: Map<string, ObservedCall>`: Active calls.
-- `observedTURN: ObservedTURN`: Aggregated TURN metrics.
-- `appData: AppData | undefined`: Custom application data.
-- `closed: boolean`: True if `close()` has been called.
-- Counters: `totalAddedCall`, `totalRemovedCall`, RTT buckets, `totalClientIssues`, `numberOfClientsUsingTurn`, `numberOfClients`, `numberOfPeerConnections`, etc.
+## Update policies
 
-**Key Methods**
+"Update" means *recompute aggregated metrics and emit the `*-updated` event* at that level.
+Both the observer and each call have a configurable trigger. Updates are **event-driven** — there
+is no built-in timer. An app that wants a fixed cadence can call `observer.update()` /
+`call.update()` from its own `setInterval`. With `'none'`, **nothing auto-updates** — the level
+updates only when the application calls the public `update()` itself.
 
-- `createObservedCall<T>(settings: ObservedCallSettings<T>): ObservedCall<T>`
-- `getObservedCall<T>(callId: string): ObservedCall<T> | undefined`
-- `accept(sample: ClientSample): void`: A convenience method to feed WebRTC stats. If `sample.callId` and `sample.clientId` are provided, it will route the sample to the appropriate `ObservedCall` and `ObservedClient`, creating them if they don't exist. The core sample processing for an existing client happens within the `ObservedClient`'s own `accept` or update mechanism.
-- `update(): void`: Manually trigger an update cycle (behavior depends on `updatePolicy`).
-- `close(): void`: Cleans up resources for the observer and all its calls.
-- `createEventMonitor<CTX>(ctx?: CTX): ObserverEventMonitor<CTX>`: For contextual event listening.
+**Observer-level** (`ObserverConfig.updatePolicy`, default `update-when-all-call-updated`):
 
-**Events (`ObserverEvents`)**
+| Policy | Triggers `observer.update()` when… |
+|--------|-------------------------------------|
+| `update-on-any-call-updated` | any call updates |
+| `update-when-all-call-updated` | every call has updated since the last observer update |
+| `none` | never automatically — only when the app calls `observer.update()` |
 
-- `'newcall' (call: ObservedCall)`
-- `'call-updated' (call: ObservedCall)`
-- `'client-event' (client: ObservedClient, event: ClientEvent)`
-- `'client-issue' (client: ObservedClient, issue: ClientIssue)`
-- `'client-metadata' (client: ObservedClient, metadata: ClientMetaData)`
-- `'client-extension-stats' (client: ObservedClient, stats: ExtensionStat)`
-- `'update' ()`
-- `'close' ()`
+**Call-level** (`ObservedCallSettings.updatePolicy`, defaulted from
+`ObserverConfig.defaultCallUpdatePolicy`):
 
-#### 3.2. `ObservedCall`
+| Policy | Triggers `call.update()` when… |
+|--------|--------------------------------|
+| `update-on-any-client-updated` | any client in the call updates |
+| `update-when-all-client-updated` | every client has updated since the last call update |
+| `none` | never automatically — only when the app calls `call.update()` |
 
-Represents a single call session.
+---
 
-**Configuration (`ObservedCallSettings`)**
+## The event bus
 
-```typescript
-export type ObservedCallSettings<AppData extends Record<string, unknown> = Record<string, unknown>> = {
-	callId: string;
-	appData?: AppData;
-	updatePolicy?: 'update-on-any-client-updated' | 'update-when-all-client-updated' | 'update-on-interval';
-	updateIntervalInMs?: number; // Used if updatePolicy is 'update-on-interval'
-	remoteTrackResolvePolicy?: 'mediasoup-sfu'; // For specific SFU integration
-};
+This is the primary API. **Subscribe on the `Observer` instance** — it is the single emitter
+for the entire hierarchy. The `ObservedCall` / `ObservedClient` / `ObservedPeerConnection`
+objects are themselves `EventEmitter`s too, but those local events are reserved for internal
+lifecycle/teardown wiring (see [Local lifecycle events](#local-lifecycle-events)); application
+code should use the Observer bus.
+
+### Payload shape: ancestry + subject
+
+Every Observer event delivers exactly **one argument: a payload object**. The payload always
+contains the ancestry from the observer down to the entity that raised it, plus any event-
+specific subject:
+
+```ts
+type ObserverEventBase            = { observer: Observer };
+type ObservedCallScope            = ObserverEventBase            & { observedCall: ObservedCall };
+type ObservedClientScope          = ObservedCallScope            & { observedClient: ObservedClient };
+type ObservedPeerConnectionScope  = ObservedClientScope          & { observedPeerConnection: ObservedPeerConnection };
 ```
 
-**Key Properties**
+So a peer-connection-level event hands you the observer, call, client, **and** peer connection:
 
-- `callId: string`
-- `appData: AppData | undefined`
-- `numberOfClients: number`
-- `score: number | undefined`: Overall call quality score.
-- `observedClients: Map<string, ObservedClient>`
-- Counters: `totalAddedClients`, `totalRemovedClients`, `numberOfIssues`, RTT buckets, total bytes sent/received (audio/video/data), etc.
+```ts
+observer.on('inbound-rtp-added', ({ observer, observedCall, observedClient, observedPeerConnection, observedInboundRtp }) => {
+  // all five are present and correctly typed
+});
+```
 
-**Key Methods**
+`observer.on/off/once/emit` are fully typed against the event map — the handler argument is
+inferred per event name.
+
+### Event catalogue
+
+All payloads include the ancestry for their level (above). The **Extra** column lists the
+additional field(s) on top of that scope.
+
+#### Observer level — scope `{ observer }`
+
+| Event | Extra payload | Fires when |
+|-------|---------------|-----------|
+| `observer-updated` | — | `observer.update()` ran (per the observer update policy) |
+| `observer-closed` | — | `observer.close()` |
+| `sample-rejected` | `{ reason: 'observer-closed' \| 'missing-callId' \| 'missing-clientId', sample: ClientSample }` | a sample was dropped by `accept()` |
+
+#### Mediasoup level — scope `{ observer, observedMediasoupRouter }`
+
+| Event | Extra | Fires when |
+|-------|-------|-----------|
+| `mediasoup-router-added` | — | `observer.createObservedMediasoupRouter(...)` registered a router |
+| `mediasoup-router-matched-with-peer-connection` | `{ observedCall, observedClient, observedPeerConnection }` | a newly added peer connection's id matched one of the router's WebRTC transport ids. **Opt-in** via `matchPeerConnectionByWebRtcTransportId: true`. |
+| `mediasoup-router-removed` | — | the underlying mediasoup router closed (its `router.observer` `close` fired) |
+
+See [Mediasoup router observation](#mediasoup-router-observation) for the full design and examples.
+
+#### Call level — scope `{ observer, observedCall }`
+
+| Event | Extra | Fires when |
+|-------|-------|-----------|
+| `call-added` | — | a call is created |
+| `call-updated` | `{ context?: AcceptContext }` | `call.update()` ran |
+| `call-closed` | — | the call closed |
+| `call-empty` | — | last client left the call |
+| `call-not-empty` | — | first client joined a previously-empty call |
+| `call-issue` | `{ issue: ClientIssue }` | `call.addIssue(...)` (server-side detector finding) |
+
+#### Client level — scope `{ observer, observedCall, observedClient }`
+
+| Event | Extra | Fires when |
+|-------|-------|-----------|
+| `client-added` | — | a client is created |
+| `client-sink-created` | `{ sink: ClientSampleSink }` | a per-client sink was created (only when `createClientSink` returns one); fires right after `client-added` |
+| `client-updated` | `{ sample: ClientSample, elapsedTimeInMs: number, context?: AcceptContext }` | the client processed a sample |
+| `client-closed` | — | the client closed |
+| `client-joined` | — | first `CLIENT_JOINED` event seen |
+| `client-left` | — | `CLIENT_LEFT` seen (or inferred on close) |
+| `client-rejoined` | `{ timestamp: number }` | a later `CLIENT_JOINED` after an earlier join |
+| `client-issue` | `{ issue: ClientIssue }` | a client-reported issue arrived, or `client.addIssue(...)` |
+| `client-metadata` | `{ metaData: ClientMetaData }` | a client meta item arrived |
+| `client-extension-stats` | `{ extensionStats: ExtensionStat }` | an app-defined extension stat arrived |
+| `client-event` | `{ event: ClientEvent }` | any client event was processed |
+
+#### Peer-connection level — scope `{ observer, observedCall, observedClient, observedPeerConnection }`
+
+| Event | Extra | Notes |
+|-------|-------|-------|
+| `peer-connection-added` / `peer-connection-closed` | — | lifecycle of the PC |
+| `peer-connection-updated` | `{ context?: AcceptContext }` | the PC processed a sample |
+| `ice-connection-state-changed` / `ice-gathering-state-changed` / `connection-state-changed` | `{ state: string }` | driven by client events |
+| `selected-candidate-pair-changed` | — | *declared; not currently emitted* |
+| `inbound-track-added` / `-updated` / `-removed` / `-muted` / `-unmuted` | `{ observedInboundTrack }` | |
+| `outbound-track-added` / `-updated` / `-removed` / `-muted` / `-unmuted` | `{ observedOutboundTrack }` | |
+| `inbound-rtp-added` / `-updated` / `-removed` | `{ observedInboundRtp }` | `-updated` fires every tick |
+| `outbound-rtp-added` / `-updated` / `-removed` | `{ observedOutboundRtp }` | `-updated` fires every tick |
+| `remote-inbound-rtp-added` / `-updated` / `-removed` | `{ observedRemoteInboundRtp }` | |
+| `remote-outbound-rtp-added` / `-updated` / `-removed` | `{ observedRemoteOutboundRtp }` | |
+| `data-channel-added` / `-updated` / `-removed` | `{ observedDataChannel }` | |
+| `ice-candidate-added` / `-updated` / `-removed` | `{ observedIceCandidate }` | |
+| `ice-candidate-pair-added` / `-updated` / `-removed` | `{ observedIceCandidatePair }` | |
+| `ice-transport-added` / `-updated` / `-removed` | `{ observedIceTransport }` | |
+| `codec-added` / `-updated` / `-removed` | `{ observedCodec }` | |
+| `media-source-added` / `-updated` / `-removed` | `{ observedMediaSource }` | |
+| `media-playout-added` / `-updated` / `-removed` | `{ observedMediaPlayout }` | |
+| `peer-connection-transport-added` / `-updated` / `-removed` | `{ observedPeerConnectionTransport }` | |
+| `certificate-added` / `-updated` / `-removed` | `{ observedCertificate }` | |
+
+> **Volume note.** The `*-updated` sub-stat events fire on every peer-connection `accept()`
+> (i.e. per sample, per stream). For high-throughput servers, subscribe only to what you need,
+> or read fields off the entities on `client-updated` / `call-updated` instead.
+
+### Local lifecycle events
+
+These remain on the individual entities (not the bus), for teardown/coordination. You can
+listen to them, but prefer the bus equivalents above for application logic.
+
+| Entity | Local events |
+|--------|--------------|
+| `ObservedCall` | `update`, `newclient`, `empty`, `not-empty`, `close` |
+| `ObservedClient` | `update` (`sample`, `elapsedTimeInMs`), `close`, `joined`, `left` |
+| `ObservedPeerConnection` | `removed-inbound-track`, `removed-outbound-track`, `close` |
 
-- `createObservedClient<T>(settings: ObservedClientSettings<T>): ObservedClient<T>`
-- `getObservedClient<T>(clientId: string): ObservedClient<T> | undefined`
-- `update(): void`
-- `close(): void`
-- `createEventMonitor<CTX>(ctx?: CTX): ObservedCallEventMonitor<CTX>`
+---
+
+## API reference
+
+### `Observer`
 
-**Events (Emitted via `ObservedCall` instance)**
+```ts
+new Observer<AppData>(config?: ObserverConfig<AppData>)
 
-- `'newclient' (client: ObservedClient)`
-- `'empty' ()`: When the last client leaves.
-- `'not-empty' ()`: When the first client joins an empty call.
-- `'update' ()`
-- `'close' ()`
+type ObserverConfig<AppData = Record<string, unknown>> = {
+    updatePolicy?: 'update-on-any-call-updated' | 'update-when-all-call-updated' | 'none';
+    defaultCallUpdatePolicy?: ObservedCallSettings['updatePolicy'];
+    appData?: AppData;
+    closeClientIfIdleForMs?: number;
+    closeCallIfEmptyForMs?: number;
+    // appData factories — run when an entity is created without explicit appData
+    // (incl. lazily by accept()). appData is application-owned; accept `context` never touches it.
+    createCallAppData?: (p: { callId: string; observer: Observer }) => Record<string, unknown>;
+    createClientAppData?: (p: { clientId: string; observedCall: ObservedCall }) => Record<string, unknown>;
+    // sink factory — produces a per-client sink that receives every accepted sample (see Sinks).
+    createClientSink?: (p: { clientId: string; observedCall: ObservedCall }) => ClientSampleSink | undefined;
+    // track-resolver factory — produces a call's RemoteTrackResolver (see Remote track resolution).
+    createTrackResolver?: (observedCall: ObservedCall) => RemoteTrackResolver | undefined;
+  };
+```
 
-#### 3.3. `ObservedClient`
+**appData factories.** Instead of pre-creating a call/client (or assigning on `call-added` /
+`client-added`) just to enrich its `appData`, register a factory once. It runs in the entity's
+constructor whenever it's created without an explicit `settings.appData` — including the lazy
+creation inside `accept()`. The `client` factory receives the already-created parent
+`observedCall`, so it can derive fields from it. `appData` is application-owned and is never
+modified by the `accept()` context.
+
+```ts
+const observer = new Observer({
+  createCallAppData:   ({ callId })                 => ({ callId, startedAt: Date.now(), region: 'eu' }),
+  createClientAppData: ({ clientId, observedCall }) => ({ clientId, region: observedCall.appData.region }),
+});
+```
 
-Represents a participant in a call.
+Key members:
 
-**Configuration (`ObservedClientSettings`)**
+- `accept(sample: ClientSample, context?: AcceptContext): void`
+- `addAcceptMiddleware(...mw: AcceptMiddleware[]): this` / `removeAcceptMiddleware(...mw): this` — global pre-dispatch sample hooks (see [Accept middlewares](#accept-middlewares-global-pre-dispatch-hook))
+- `getObservedCall<T>(callId): ObservedCall<T> | undefined`
+- `createObservedCall<T>(settings): ObservedCall<T> | undefined`
+- `getOrCreateObservedCall<T>(settings): ObservedCall<T> | undefined`
+- `update(): void` — force an aggregation/`observer-updated` tick
+- `close(): void`
+- `readonly observedCalls: Map<string, ObservedCall>`
+- `readonly observedTURN: ObservedTURN`
+- `get appData()`, `get numberOfCalls()`
+- counters: `numberOfClients`, `numberOfClientsUsingTurn`, `numberOfInboundRtpStreams`,
+  `numberOfOutboundRtpStreams`, `numberOfDataChannels`, `numberOfPeerConnections`,
+  `totalAddedCall`, `totalRemovedCall`, `closed`
+- `on/off/once/emit` typed against the [event map](#event-catalogue)
+
+### `ObservedCall`
+
+```ts
+type ObservedCallSettings<AppData = Record<string, unknown>> = {
+    updatePolicy?: 'update-on-any-client-updated' | 'update-when-all-client-updated' | 'none';
+    callId: string;
+    appData?: AppData;
+    closeCallIfEmptyForMs?: number;
+  };
+```
 
-```typescript
-export type ObservedClientSettings<AppData extends Record<string, unknown> = Record<string, unknown>> = {
-	clientId: string;
-	appData?: AppData;
-	// Potentially other client-specific settings
+Key members:
+
+- `readonly callId: string`, `appData: AppData`
+- `readonly observedClients: Map<string, ObservedClient>`, `get numberOfClients()`
+- `getObservedClient<T>(clientId)`, `createObservedClient<T>(settings)`, `getOrCreateObservedClient<T>(settings)` (all `… | undefined`)
+- `addIssue(issue: ClientIssue): void` — raise a **call-level** issue → emits `call-issue`
+- `readonly detectors: Detectors` — server-side detector registry (empty by default; see [Detectors](#detectors-server-side-extension-point))
+- `scoreCalculator: ScoreCalculator`, `get score()`, `readonly calculatedScore`
+- `remoteTrackResolver?: RemoteTrackResolver` — set from `ObserverConfig.createTrackResolver` at call creation (see [Remote track resolution](#remote-track-resolution-mediasoup--sfu))
+- aggregates: `numberOfIssues`, `numberOfPeerConnections`, `numberOfInboundRtpStreams`,
+  `numberOfOutboundRtpStreams`, `numberOfDataChannels`, `maxNumberOfClients`,
+  `clientsUsedTurn: Set<string>`, `startedAt?`, `endedAt?`, `closedAt?`, `closed`
+- `update()`, `close()`
+
+### `ObservedClient`
+
+```ts
+type ObservedClientSettings<AppData = Record<string, unknown>> = {
+  clientId: string;
+  appData?: AppData;
+  closeClientIfIdleForMs?: number;
 };
 ```
 
-**Key Properties**
+Key members:
+
+- `readonly clientId: string`, `appData: AppData`, `readonly call: ObservedCall`
+- `readonly observedPeerConnections: Map<string, ObservedPeerConnection>`
+- `readonly sink?: ClientSampleSink` — the per-client sink (see [Sinks](#sinks-per-client-sample-persistence)), if `createClientSink` is configured; listen on it for `close`/`error`
+- **Injection API** (queue app data to be merged into the next sample processing):
+  `injectEvent(ClientEvent)`, `injectIssue(ClientIssue)`, `injectMetaData(ClientMetaData)`,
+  `injectExtensionStat(ExtensionStat)`, `injectAttachment(attachments: Record<string, unknown>)`
+- **Direct add API** (process immediately): `addIssue(ClientIssue)`, `addMetadata(ClientMetaData)`,
+  `addExtensionStats(ExtensionStat)`
+- Metrics (current/derived): `currentAvgRttInMs?`, `currentMinRttInMs?`, `currentMaxRttInMs?`,
+  `receivingAudioBitrate`, `receivingVideoBitrate`, `sendingAudioBitrate`, `sendingVideoBitrate`,
+  `usingTURN`, `usingTCP`, `availableIncomingBitrate`, `availableOutgoingBitrate`
+- Counts: `numberOfInboundRtpStreams`, `numberOfOutboundRtpStreams`, `numberOfInbundTracks`,
+  `numberOfOutboundTracks`, `numberOfDataChannels`, `numberOfPeerConnections`
+- Per-tick deltas: `deltaReceivedAudioBytes`, `deltaSentAudioBytes`, … (see source for the full set)
+- Lifecycle: `joinedAt?`, `leftAt?`, `closedAt?`, `closed`, `get score()`
+- Metadata: `browser?`, `engine?`, `platform?`, `operationSystem?`, `mediaDevices`, `mediaConstraints`
+- `accept(sample, context?)`, `close()`
+
+### `ObservedPeerConnection`
+
+Key members:
+
+- `readonly peerConnectionId: string`, `readonly client: ObservedClient`, `appData?`
+- The 15 `observed*` sub-stat `Map`s (listed [above](#entity-hierarchy)), plus array getters:
+  `codecs`, `inboundRtps`, `outboundRtps`, `remoteInboundRtps`, `remoteOutboundRtps`,
+  `mediaSources`, `mediaPlayouts`, `dataChannels`, `peerConnectionTransports`, `iceTransports`,
+  `iceCandidates`, `iceCandidatePairs`, `certificates`, `selectedIceCandidatePairs`,
+  `selectedIceCandiadtePairForTurn`
+- State: `connectionState?`, `iceConnectionState?`, `iceGatheringState?`, `usingTURN`, `usingTCP`
+- Metrics: `currentRttInMs?`, `currentJitter?`, `availableIncomingBitrate`,
+  `availableOutgoingBitrate`, sending/receiving bitrates, packet rates, and `total*` / `delta*`
+  byte/packet counters
+- `accept(pcSample, context?)`, `close()`, `get score()`
+
+**Remote-RTP correlation (derived).** During `accept()`, receiver/sender reports are linked
+to the local streams by `remoteId` (fallback SSRC) and surfaced as fields:
+
+- on `ObservedOutboundRtp`: `remoteRttInMs?`, `remoteFractionLost?`, `remoteJitter?`, `remotePacketsLost?`
+- on `ObservedInboundRtp`: `remoteRttInMs?`, `remoteBytesSent?`, `remotePacketsSent?`, `remoteTimestamp?`
+
+These are reset each tick and only set when the matching remote report is present.
+
+---
 
-- `clientId: string`
-- `call: ObservedCall`: Reference to the parent call.
-- `appData: AppData | undefined`
-- `score: number | undefined`: Client quality score.
-- `numberOfPeerConnections: number`
-- `usingTURN: boolean`
-- `observedPeerConnections: Map<string, ObservedPeerConnection>`
-- Counters: `numberOfIssues`, RTT buckets, total bytes sent/received, `availableIncomingBitrate`, `availableOutgoingBitrate`, etc.
+## Schema types (`ClientSample`)
+
+The shape of an accepted sample (re-exported from this package; identical to
+`@observertc/schemas`). Only the top level is shown — each stat object mirrors the standard
+WebRTC `getStats()` dictionaries plus a few extensions.
+
+```ts
+type ClientSample = {
+  timestamp: number;          // client wall-clock (ms epoch)
+  callId?: string;            // set by you or the library
+  clientId?: string;          // set by you or the library
+  score?: number;             // optional client-computed score (0..5)
+  attachments?: Record<string, unknown>;
+  peerConnections?: PeerConnectionSample[];
+  clientEvents?: ClientEvent[];
+  clientIssues?: ClientIssue[];
+  clientMetaItems?: ClientMetaData[];
+  extensionStats?: ExtensionStat[];
+};
 
-**Key Methods**
+type PeerConnectionSample = {
+  peerConnectionId: string;
+  attachments?: Record<string, unknown>;   // e.g. { direction: 'send'|'recv', producerId, consumerId, label }
+  score?: number;
+  inboundTracks?; outboundTracks?;
+  codecs?;
+  inboundRtps?; remoteInboundRtps?;
+  outboundRtps?; remoteOutboundRtps?;
+  mediaSources?; mediaPlayouts?;
+  peerConnectionTransports?; dataChannels?;
+  iceTransports?; iceCandidates?; iceCandidatePairs?;
+  certificates?;
+};
 
-- `accept(sample: ClientSample): void`: (Or a similar internal update method called by `Observer.accept` or `ObservedCall`) Processes a `ClientSample` specific to this client, updating its metrics, peer connections, streams, etc. This is the primary point where a client's detailed WebRTC statistics are processed.
-- `createObservedPeerConnection<T>(settings: ObservedPeerConnectionSettings<T>): ObservedPeerConnection<T>`
-- `getObservedPeerConnection<T>(peerConnectionId: string): ObservedPeerConnection<T> | undefined`
-- `update(): void`
-- `close(): void`
-- `createEventMonitor<CTX>(ctx?: CTX): ObservedClientEventMonitor<CTX>`
+type ClientEvent     = { type: string; payload?: string; timestamp?: number; /* +ids */ };
+type ClientIssue     = { type: string; payload?: string; timestamp?: number };   // also used for call-issue
+type ClientMetaData  = { type: string; payload?: string; timestamp?: number; /* +ids */ };
+type ExtensionStat   = { type: string; payload?: string };
+```
+
+`payload` fields are JSON strings; the library parses the ones it understands.
+
+**`ClientEventTypes`** (enum of known `event.type` values): `CLIENT_JOINED`, `CLIENT_LEFT`,
+`PEER_CONNECTION_OPENED/CLOSED/STATE_CHANGED`, `MEDIA_TRACK_ADDED/REMOVED/MUTED/UNMUTED/RESUMED`,
+`ICE_GATHERING_STATE_CHANGED`, `ICE_CONNECTION_STATE_CHANGED`, `DATA_CHANNEL_OPEN/CLOSED/ERROR`,
+`NEGOTIATION_NEEDED`, `SIGNALING_STATE_CHANGE`, `ICE_CANDIDATE`, `ICE_CANDIDATE_ERROR`, and the
+mediasoup set `PRODUCER_*` / `CONSUMER_*` / `DATA_PRODUCER_*` / `DATA_CONSUMER_*`.
+
+**`ClientMetaTypes`** (enum of known meta `type` values): `MEDIA_CONSTRAINT`, `MEDIA_DEVICE`,
+`MEDIA_DEVICES_SUPPORTED_CONSTRAINTS`, `USER_MEDIA_ERROR`, `LOCAL_SDP`, `OPERATION_SYSTEM`,
+`ENGINE`, `PLATFORM`, `BROWSER`.
+
+### Worked example: a real `ClientSample`
+
+Two consecutive samples from one participant ("Guest" in room `qq0iwfnd`) of an
+edumeet/mediasoup call show what actually flows through `accept()`: a rich **join snapshot**,
+then lean **steady-state ticks**.
+
+**Sample 1 — the join snapshot.** Carries the one-off lifecycle `clientEvents` and device
+`clientMetaItems` alongside the first stats. (Abbreviated; ids and times are from the real log.)
+
+```jsonc
+{
+  "timestamp": 1780572332518,
+  "callId":   "d3dbf2f5-79be-4cb8-9d43-fb404f07ef27",
+  "clientId": "c926983c-4468-4046-ae8c-a9cabe1a1868",
+  "score": 0,                                          // no quality measured yet on the join tick
+  "attachments": { "displayName": "Guest", "roomId": "qq0iwfnd", "actualSessionId": "d3dbf2f5-…" },
+
+  "clientEvents": [                                     // chronological lifecycle (12 in the real sample)
+    { "type": "CLIENT_JOINED",                 "timestamp": 1780572324515 },
+    { "type": "PEER_CONNECTION_OPENED",        "timestamp": 1780572326790 },   // pc=b81c8d9d (media)
+    { "type": "ICE_GATHERING_STATE_CHANGED",   "timestamp": 1780572326811 },   // → gathering
+    { "type": "PEER_CONNECTION_STATE_CHANGED", "timestamp": 1780572326812 },   // → connecting
+    { "type": "PRODUCER_ADDED",                "timestamp": 1780572326821 },   // producer=1abdaf82 (audio)
+    { "type": "MEDIA_TRACK_ADDED",             "timestamp": 1780572326821 },   // track=36ae42df  (audio)
+    { "type": "PEER_CONNECTION_STATE_CHANGED", "timestamp": 1780572326827 },   // → connected
+    { "type": "PRODUCER_ADDED",                "timestamp": 1780572326837 },   // producer=ba06a35b (video)
+    { "type": "DATA_PRODUCER_CREATED",         "timestamp": 1780572326853 }
+  ],
+
+  "clientMetaItems": [                                  // environment & devices, one-off (10 in the real sample)
+    { "type": "USER_AGENT_DATA", "payload": "{…Chrome 148 / macOS…}" },
+    { "type": "MEDIA_DEVICE",    "payload": "{…\"BRIO 4K Stream Edition\"…}" }
+    // …mic / camera / speaker devices…
+  ],
+
+  "peerConnections": [
+    {
+      "peerConnectionId": "b81c8d9d-…",                // the media PC — Guest publishes to the SFU
+      "outboundRtps":      [ /* audio + video */ ],
+      "outboundTracks":    [ /* mic + camera: label, settings, capabilities */ ],
+      "remoteInboundRtps": [ /* RTCP feedback from the SFU */ ],
+      "codecs": [ /* … */ ], "iceTransports": [ /* … */ ],
+      "iceCandidatePairs": [ /* … */ ], "dataChannels": [ /* … */ ]
+    },
+    { "peerConnectionId": "8635acb7-…", "peerConnectionTransports": [ /* … */ ] }  // signaling-only PC
+  ]
+}
+```
 
-**Events (Emitted via `ObservedClient` instance)**
+What `accept()` does with it, in order — each step emits on the bus with full ancestry:
 
-- `'joined' ()`
-- `'left' ()`
-- `'update' ()`
-- `'close' ()`
-- `'newpeerconnection' (pc: ObservedPeerConnection)`
-- `'issue' (issue: ClientIssue)` (and other specific issue events)
+1. lazily creates the `ObservedCall` → **`call-added`**;
+2. creates the `ObservedClient` → **`client-added`**, then **`client-joined`** (from `CLIENT_JOINED`);
+3. creates an `ObservedPeerConnection` per entry → **`peer-connection-added`** (×2 here);
+4. creates an `ObservedOutboundTrack` per track → **`outbound-track-added`**, plus the matching
+   **`outbound-rtp-added`**;
+5. replays the device list as **`client-metadata`** events and the lifecycle items as
+   **`client-event`**; and finally **`client-updated`** for the whole tick.
 
-#### 3.4. `ObservedPeerConnection`
+`attachments.roomId` lands on `observedClient.attachments` (read it on `client-updated`, **not** at
+creation — see [Ingestion](#ingestion-accept-context--lifecycle)).
 
-Represents an `RTCPeerConnection`.
+**Sample 2 — a steady-state tick** (~8 s later): same `callId` / `clientId`, **no** new
+`clientEvents` or `clientMetaItems`, just refreshed `peerConnections` stats. Each PC now scores `5`
+and the aggregate client `score` is `4.74` — a healthy call. This is the shape of nearly every
+sample: each tick refreshes metrics and fires the `*-updated` events, while the heavy join
+snapshot happens only once.
 
-- Tracks ICE connection state, data channel stats, stream stats.
-- Holds `ObservedInboundRtpStream`, `ObservedOutboundRtpStream`, and `ObservedDataChannel` instances.
+---
 
-#### 3.5. `ObservedInboundRtpStream` / `ObservedOutboundRtpStream`
+## Detectors (server-side extension point)
 
-- Track metrics for individual media streams (audio/video) like codec, packets lost/received, jitter, bytes, etc.
+`observer-js` deliberately ships **no built-in detectors**. Per-client signals — packet loss,
+jitter, RTT, freezes, etc. — are already detectable on the client and arrive on samples as
+`clientIssues` (surfaced via `client-issue`). Server-side detection should focus on what only
+the server can see by **correlating data across the clients of a call**.
 
-#### 3.6. `ObservedDataChannel`
+The hook lives on **`ObservedCall`**:
 
-- Tracks metrics for data channels like state, messages sent/received, bytes.
+```ts
+import { Observer, Detector } from '@observertc/observer-js';
 
-#### 3.7. `ClientSample` (Schema)
+class MyCrossClientDetector implements Detector {
+  readonly name = 'my-detector';
+  constructor(private readonly call /* : ObservedCall */) {}
+  update() {                                   // called on every call.update()
+    // …inspect this.call.observedClients across participants…
+    if (/* condition only visible server-side */ false) {
+      this.call.addIssue({ type: this.name, payload: JSON.stringify({ /* … */ }), timestamp: Date.now() });
+      // → emitted on the bus as 'call-issue'
+    }
+  }
+}
 
-This is the primary input data structure passed to `observer.accept()`. It's a comprehensive object that should mirror the information obtainable from WebRTC `getStats()` and other client-side states. Key fields include:
+const observer = new Observer();
+observer.on('call-added', ({ observedCall }) => {
+  observedCall.detectors.add(new MyCrossClientDetector(observedCall));
+});
+observer.on('call-issue', ({ observedCall, issue }) => { /* react */ });
+```
 
-- `callId`, `clientId`, `timestamp`
-- `peerConnections: RTCPeerConnectionStats[]`
-- `inboundRtpStreams: RTCInboundRtpStreamStats[]`
-- `outboundRtpStreams: RTCOutboundRtpStreamStats[]`
-- `remoteInboundRtpStreams: RTCRemoteInboundRtpStreamStats[]`
-- `remoteOutboundRtpStreams: RTCRemoteOutboundRtpStreamStats[]`
-- `dataChannels: RTCDataChannelStats[]`
-- `iceLocalCandidates: RTCIceCandidateStats[]`, `iceRemoteCandidates: RTCIceCandidateStats[]`, `iceCandidatePairs: RTCIceCandidatePairStats[]`
-- `mediaSources: RTCAudioSourceStats[] / RTCVideoSourceStats[]`
-- `tracks: RTCMediaStreamTrackStats[]`
-- `certificates: RTCCertificateStats[]`
-- `codecs: RTCCodecStats[]`
-- `transports: RTCIceTransportStats[]` (or similar depending on spec version)
-- `browser`, `engine`, `platform`, `os` (client environment metadata)
-- `userMediaErrors`, `iceConnectionStates`, `connectionStates` (client-reported events/states)
-- `extensionStats` (for custom data)
+`Detector` interface and the registry:
 
-_(Refer to the [observertc/schemas](https://github.com/observertc/schemas) repository, particularly the `ClientSample.ts` definition, for the exact and complete structure.)_
+```ts
+interface Detector { readonly name: string; update(): void; }
 
-### 4. Configuration Possibilities
+class Detectors {
+  add(d: Detector): void;
+  remove(d: Detector): void;
+  clear(): void;
+  update(): void;          // called by ObservedCall.update(); guards each detector in try/catch
+  get listOfNames(): string[];
+}
+```
 
-#### 4.1. Update Policies
+---
 
-Control how frequently entities re-calculate metrics and emit `update` events.
+## Remote track resolution (mediasoup / SFU)
 
-**Observer Level (`ObserverConfig.updatePolicy`)**
+In an SFU, one participant's **outbound** track is delivered to other participants as **inbound**
+tracks (one **publisher** → many **subscribers**). Correlation is **opt-in** per observer: set
+`ObserverConfig.createTrackResolver`, a factory invoked when each call is created that returns the
+call's `RemoteTrackResolver` (or `undefined` for none).
 
-- `'update-on-any-call-updated'`: Observer updates if any of its calls update.
-- `'update-when-all-call-updated'`: Observer updates after all its calls update. (Default)
-- `'update-on-interval'`: Observer updates at `ObserverConfig.updateIntervalInMs`.
+`RemoteTrackResolver` is a generic, strategy-driven class. It subscribes to the bus (filtered to
+its call) and links tracks by **publisher id** — the link key — maintaining the links directly on
+the tracks: `inboundTrack.remoteOutboundTrack` and `outboundTrack.remoteInboundTracks: Set`.
 
-**Call Level (`ObservedCallSettings.updatePolicy` or `ObserverConfig.defaultCallUpdatePolicy`)**
+```ts
+import { Observer, createDefaultMediasoupRemoteTrackResolverFactory } from '@observertc/observer-js';
 
-- `'update-on-any-client-updated'`: Call updates if any of its clients update.
-- `'update-when-all-client-updated'`: Call updates after all its clients update.
-- `'update-on-interval'`: Call updates at its `updateIntervalInMs`.
+const observer = new Observer({
+  createTrackResolver: createDefaultMediasoupRemoteTrackResolverFactory(),
+});
 
-#### 4.2. Intervals
+// later, given tracks (links are kept up to date as tracks come and go):
+const source    = inboundTrack.remoteOutboundTrack;       // the publishing ObservedOutboundTrack
+const receivers = [ ...outboundTrack.remoteInboundTracks ]; // the subscribing ObservedInboundTrack[]
+```
 
-- `ObserverConfig.updateIntervalInMs`
-- `ObserverConfig.defaultCallUpdateIntervalInMs`
-- `ObservedCallSettings.updateIntervalInMs`
+Two built-in factories ship: `createDefaultMediasoupRemoteTrackResolverFactory()` (publisher =
+`attachments.producerId`, subscriber = `attachments.consumerId`) and
+`createP2pRemoteTrackResolverFactory()` (matches by RTP **SSRC**, preserved end-to-end in p2p).
 
-#### 4.3. Application Data (`appData`)
+For any other topology, build a `RemoteTrackResolver` with your own key resolvers — the publisher
+id is just whatever links a subscribed track to the published one:
 
-Associate custom context with `Observer`, `ObservedCall`, and `ObservedClient` instances using generics.
+```ts
+import { Observer, RemoteTrackResolver } from '@observertc/observer-js';
 
-```typescript
-interface MyCallAppData {
-	meetingTitle: string;
-	scheduledAt: Date;
-}
-const call = observer.createObservedCall<MyCallAppData>({
-	callId: 'call1',
-	appData: { meetingTitle: 'Team Sync', scheduledAt: new Date() },
+const observer = new Observer({
+  createTrackResolver: (observedCall) => new RemoteTrackResolver(observedCall, {
+    resolveOutboundTrackPublisherId: (out) => out.attachments?.mediaId as string | undefined,
+    resolveInboundTrackPublisherId:  (inb) => inb.attachments?.mediaId as string | undefined,
+    resolveInboundTrackSubscriberId: (inb) => inb.attachments?.subId  as string | undefined, // optional
+  }),
 });
-console.log(call.appData?.meetingTitle);
 ```
 
-#### 4.4. `appData` vs. Attachments
+For the mediasoup factory, the application puts `producerId` / `consumerId` (and optionally
+`direction`, `label`) into the track `attachments`.
 
-The `observer-js` library provides two primary ways to associate custom information with its entities: `appData` and `attachments`. Understanding their distinct purposes is key for effective use.
+---
 
-**`appData` (Application Data)**
+## Mediasoup router observation
+
+Everything above is built from the **client-reported** `ClientSample`. When you run a
+[mediasoup](https://mediasoup.org) SFU you also have the **server's own** ground truth — its
+routers, transports, producers, consumers and data channels, with exact lifetimes and state
+transitions. `ObservedMediasoupRouter` captures that server-side view into a
+**`MediasoupRouterSample`**, completely independent of the client sample pipeline.
+
+### The concept
+
+You hand the observer a live mediasoup `Router`; it attaches to mediasoup's own `observer` API and,
+from then on, **passively records** the router's topology and lifecycle — with no polling and no
+changes to your media code:
+
+- new transports (`webrtc` / `plain` / `pipe` / `direct`), their selected `tuple`, and ICE state
+  transitions;
+- producers (codec, SSRCs/RIDs, `pause`/`resume`) and consumers (`pause`/`resume`,
+  `producerPaused`/`producerResumed`);
+- data producers and data consumers;
+- `createdAt` / `closedAt` for every entity above.
+
+All of it accumulates on `observedMediasoupRouter.sample` (a `MediasoupRouterSample` — see
+[`src/schema/MediasoupRouter.ts`](./src/schema/MediasoupRouter.ts)). This is a *Sample*, not a
+*Report*: it mirrors the naming of `ClientSample` and is yours to snapshot, persist, or correlate.
+
+### Matching peer connections — by **event**, not by storage
+
+The observer correlates the SFU side with the client side **at the peer-connection level**: a
+mediasoup WebRTC transport and a client's `RTCPeerConnection` share the same id, so whenever an
+observed peer connection's id matches one of the router's WebRTC transport ids, that's a match.
+
+**The observer does not store the router (or its sample) on any entity.** Instead, for **every**
+matching peer connection it emits **`mediasoup-router-matched-with-peer-connection`** and steps
+back — *your application* decides what the pairing means. The payload carries the full peer-connection
+ancestry, so you get the router **and** the matched `observedPeerConnection`, `observedClient` and
+`observedCall` in one place. Stamp the `routerId` into the peer connection's / client's `appData`,
+build your own index, attach the server sample to the call in your database — whatever fits.
+
+This matching is **opt-in**: pass `matchPeerConnectionByWebRtcTransportId: true` to
+`createObservedMediasoupRouter`. When enabled, as peer connections are observed
+(`peer-connection-added`) the observer checks whether the peer connection's id is one of the router's
+WebRTC transport ids; on a hit it emits — once per matching peer connection — and keeps watching, so a
+router serving many participants emits one match per participant's transport. When the flag is omitted
+or `false`, no matching is performed and the event never fires. The internal listener is removed
+automatically when the router closes or the observer closes.
+
+When the underlying mediasoup router closes, its `close` propagates to `ObservedMediasoupRouter`,
+which emits **`mediasoup-router-removed`**. That is your cue to do whatever cleanup or persistence
+you want with the now-final `sample` — again, the observer itself keeps nothing.
+
+### Options — `observer.createObservedMediasoupRouter(settings)`
+
+| Field | Type | Required | Meaning |
+|-------|------|----------|---------|
+| `router` | `mediasoup.types.Router` | yes | the live router to observe; the observer attaches to `router.observer` |
+| `routerId` | `string` | yes | your id for the router (the sample also carries `router.id`) |
+| `appData` | `Record<string, unknown>` | no | application-owned bag on the `ObservedMediasoupRouter` |
+| `attachments` | `Record<string, unknown>` | no | free-form data copied onto `sample.attachments` |
+| `matchPeerConnectionByWebRtcTransportId` | `boolean` | no | opt in to peer-connection matching: emit `mediasoup-router-matched-with-peer-connection` for each peer connection whose id matches one of the router's WebRTC transport ids. Omitted / `false` → no matching, the event never fires |
+
+Peer-connection matching is **off by default**; enable it with
+`matchPeerConnectionByWebRtcTransportId: true`. Returns the `ObservedMediasoupRouter`, or `undefined`
+if the observer is closed (a router with the same id returns the existing instance — both warn).
+
+Useful members on the returned object: `.sample` (the `MediasoupRouterSample`), `.appData`,
+`.attachments` (getter over `sample.attachments`), `.webrtcTransportIds: Set<string>`, `.id`,
+`.close()`.
+
+### Example
+
+```ts
+import { Observer } from '@observertc/observer-js';
+import type { ObservedMediasoupRouterScope, ObservedPeerConnectionScope } from '@observertc/observer-js';
+
+const observer = new Observer();
+
+// 1) Feed client samples as usual so the observer knows about calls, clients & peer connections.
+//    (e.g. transport-layer: observer.accept(clientSample, context))
+
+// 2) Observe the SFU side, opting in to peer-connection matching for this router's transports.
+const router = /* your mediasoup router */ undefined as any;
+const observedRouter = observer.createObservedMediasoupRouter({
+  router,
+  routerId: router.id,
+  matchPeerConnectionByWebRtcTransportId: true,
+});
 
-- **Purpose**: `appData` is designed to hold structured, typed, and relatively static metadata about an entity (`Observer`, `ObservedCall`, `ObservedClient`). This data is typically set at the time of entity creation and is directly accessible as a property of the entity instance.
-- **Typing**: It is strongly typed using generics (e.g., `Observer<MyObserverAppData>`). This provides type safety and autocompletion in TypeScript environments.
-- **Mutability**: While technically mutable (if the object assigned is mutable), it's generally intended for information that defines or describes the entity and doesn't change frequently during its lifecycle.
-- **Accessibility**: Directly accessible via `entity.appData`.
-- **Use Cases**:
-  - Storing application-specific identifiers (e.g., `userId`, `roomId`, `meetingType`).
-  - Configuration flags relevant to how your application interprets this entity.
-  - Descriptive information (e.g., `clientDeviceType`, `callRegion`).
+// 3) Every peer connection whose id matches one of the router's WebRTC transport ids fires this —
+//    WE decide what to do with each pairing. The payload carries the full ancestry.
+observer.on('mediasoup-router-matched-with-peer-connection',
+  ({ observedMediasoupRouter, observedCall, observedClient, observedPeerConnection }:
+     ObservedMediasoupRouterScope & ObservedPeerConnectionScope) => {
+    // e.g. remember which router serves this peer connection / client…
+    (observedPeerConnection.appData ??= {}).routerId = observedMediasoupRouter.id;
+    // …or index the server sample by call in your own store:
+    myStore.linkRouterToCall(observedCall.callId, observedMediasoupRouter.sample);
+  },
+);
+
+// 4) The router closed — WE decide what to persist/forward with the final sample.
+observer.on('mediasoup-router-removed', ({ observedMediasoupRouter }: ObservedMediasoupRouterScope) => {
+  myStore.saveRouterSample(observedMediasoupRouter.sample);
+});
 
-**`attachments` (Arbitrary Attachments)**
+// (optional) react to the router being registered at all:
+observer.on('mediasoup-router-added', ({ observedMediasoupRouter }) => {
+  console.log('observing router', observedMediasoupRouter.id);
+});
+```
 
-- **Purpose**: `attachments` (if implemented as a `Map<string, unknown>` or similar mechanism on entities) are meant for associating arbitrary, often dynamic, or less structured data with an entity. This can be useful for temporary state, inter-plugin communication, or data that doesn't fit neatly into a predefined `appData` schema.
-- **Typing**: Typically less strictly typed (e.g., `unknown` or `any` values in a Map). Consumers of attachments need to perform their own type checks or assertions.
-- **Mutability**: Designed to be more dynamic. Attachments can be added, updated, or removed throughout the entity's lifecycle.
-- **Accessibility**: Accessed via methods like `entity.setAttachment(key, value)`, `entity.getAttachment(key)`, `entity.removeAttachment(key)`.
-- **Use Cases**:
-  - Storing temporary state calculated by one part of your application to be read by another (e.g., a custom issue detector plugin might attach intermediate findings).
-  - Caching results of expensive computations related to the entity.
-  - Allowing different modules or plugins to associate their own private data with an observer entity without needing to modify its core `appData` type.
-  - Storing large binary data or complex objects that are not part of the core descriptive metadata.
+### Why event-driven instead of storing on the call
 
-**When to Use Which:**
+- **Loose coupling.** The call model stays about client telemetry; the SFU view lives on its own
+  object and is associated only if and how *you* choose.
+- **You own the association.** One router serves many peer connections (across clients and calls),
+  and the right place to keep that mapping is application-specific — so the observer hands you each
+  peer-connection match and the final sample, and gets out of the way.
+- **No silent accumulation.** Nothing is appended to `ObservedCall`, so there is no hidden growth or
+  lifetime you have to reason about; the router sample lives exactly as long as you keep a reference.
 
-- Use **`appData`** for:
-  - Core, descriptive metadata that is known at creation time or changes infrequently.
-  - Data that benefits from strong typing and is integral to your application's understanding of the entity.
-- Use **`attachments`** for:
-  - Dynamic, temporary, or loosely structured data.
-  - Data added by different, potentially independent, parts of your system or plugins.
-  - Information that doesn't need to be part of the primary, typed `appData` schema.
+---
 
-If `attachments` are not yet a formal feature, this section can serve as a design consideration or be adapted if you introduce such a mechanism. If `attachments` are already present, ensure the description matches their actual implementation.
+## Sinks (per-client sample persistence)
 
-#### 4.5. Remote Track Resolution
+A **sink** receives the samples a client accepts — for archival, streaming, or later offline
+replay. Each `ObservedClient` gets its **own** sink, produced by the
+`ObserverConfig.createClientSink` factory when the client is created (return `undefined` for no
+sink). The client pushes every accepted sample to its sink, and `end()`s it on close.
 
-For SFU scenarios, especially with MediaSoup:
-`ObservedCallSettings.remoteTrackResolvePolicy: 'mediasoup-sfu'`
+### The `ClientSampleSink` base class
 
-### 5. Examples
+`ClientSampleSink` is an **abstract base class** (a typed `EventEmitter`). You create a sink by
+**subclassing it** and implementing `write` and `end`. It is **object-mode**: `write` receives
+the `ClientSample` *object*, so each sink decides how (or whether) to serialize it — JSON line,
+protobuf, a remote POST body, an in-memory push, etc.
 
-#### 5.1. Basic Observer Setup & Sample Ingestion
+```ts
+import { ClientSampleSink, ClientSample } from '@observertc/observer-js';
 
-```typescript
-// filepath: /path/to/your/app.ts
-import { Observer, ObserverConfig } from '@observertc/observer-js'; // Adjust path
-import { ClientSample } from '@observertc/schemas'; // Adjust path if using official schemas
+abstract class ClientSampleSink /* extends EventEmitter */ {
+  abstract write(sample: ClientSample): boolean;   // accept one sample; `false` = backpressure
+  abstract end(): void;                            // flush; emit `close` when the destination is ready
 
-const observerConfig: ObserverConfig = {
-	updatePolicy: 'update-on-interval',
-	updateIntervalInMs: 5000,
-	defaultCallUpdatePolicy: 'update-on-any-client-updated',
-};
-const observer = new Observer(observerConfig);
-
-observer.on('newcall', (call) => {
-	console.log(`[Observer] New call: ${call.callId}`);
-	call.on('update', () => {
-		console.log(`[Call: ${call.callId}] Updated. Clients: ${call.numberOfClients}, Score: ${call.score?.toFixed(1)}`);
-	});
-	call.on('newclient', (client) => {
-		console.log(`[Call: ${call.callId}] New client: ${client.clientId}`);
-		client.on('update', () => {
-			// console.log(`[Client: ${client.clientId}] Updated. Score: ${client.score?.toFixed(1)}`);
-		});
-		client.on('issue', (issue) => {
-			console.warn(`[Client: ${client.clientId}] Issue: ${issue.type} - ${issue.severity} - ${issue.description}`);
-		});
-	});
+  // typed events (inherited): the listener signature is inferred from the event name
+  on(event: 'close' | 'finish' | 'drain', listener: () => void): this;
+  on(event: 'error', listener: (err: Error) => void): this;
+  // ...and the matching `once` / `off` / `emit`
+}
+```
+
+| Event | Meaning |
+|-------|---------|
+| `close` | the destination is fully written and closed (e.g. a file flushed and its fd closed) — "ready" |
+| `error` | the destination failed |
+| `finish` | `end()` was processed and queued data flushed (before `close`) |
+| `drain` | the buffer drained after backpressure; safe to write more |
+
+The library calls `write(sample)` **synchronously** per accepted sample (it is not awaited),
+`end()`s the sink when the client closes, and attaches an `error` listener so a failing sink
+can't crash the process (it also catches throws from `write`/`end`). The application — which
+created the sink — listens for `close` (destination ready) and `error`. Because `write` isn't
+awaited in the `accept()` hot path, **backpressure and batching are the sink's concern**.
+
+### Built-in sinks
+
+```ts
+import { Observer, createJsonlFileSinkFactory } from '@observertc/observer-js';
+
+const observer = new Observer({
+  // one ./stats/<callId>__<clientId>.jsonl per client
+  createClientSink: createJsonlFileSinkFactory({ directory: './stats' }),
 });
 
-// Function to transform your app's WebRTC stats to ClientSample
-function mapStatsToClientSample(appStats: any, callId: string, clientId: string): ClientSample {
-	// Detailed mapping logic here based on ClientSample.ts schema
-	// from github.com/observertc/schemas
-	return {
-		callId,
-		clientId,
-		timestamp: Date.now(),
-		// ... map all relevant stats fields ...
-	} as ClientSample; // Ensure all required fields are present
+// React when a sink is created for a client:
+observer.on('client-sink-created', ({ observedClient, sink }) => {
+  sink.on('close', () => {
+    // the file is fully flushed and its fd closed — ready to upload, move, etc.
+  });
+});
+```
+
+| Export | Signature | Notes |
+|--------|-----------|-------|
+| `createJsonlFileSinkFactory` | `({ directory, flags?, getFileName?, serializeSample? }) => ClientSampleSinkFactory` | per-client JSONL files; path defaults to `${callId}__${clientId}.jsonl` under `directory` (which **must exist**) |
+| `createJsonlFileSink` | `({ path, flags?, serializeSample? }) => ClientSampleSink` | a single JSONL file; wraps `fs.WriteStream` and re-emits its `close`/`finish`/`drain`/`error` |
+| `JsonlFileSink` | `class extends ClientSampleSink` | the underlying class; exposes `readonly path` so a `close` handler knows which file is ready |
+| `createInMemorySink` / `InMemorySink` | `(samples?: ClientSample[]) => InMemorySink` | collects the accepted **sample objects** into `.samples: ClientSample[]`; emits `close` on `end()` |
+
+`serializeSample?: (sample: ClientSample) => string` overrides the default `JSON.stringify` for
+the JSONL sinks (e.g. to redact or reshape before writing).
+
+### Reading sink-specific info (e.g. the file path)
+
+The bus hands you the sink as the base `ClientSampleSink`. To read information specific to a sink
+type — for a file sink, where it was written — **narrow with `instanceof`** and read the sink's
+public fields. `JsonlFileSink` exposes `path`:
+
+```ts
+import { JsonlFileSink } from '@observertc/observer-js';
+
+observer.on('client-sink-created', ({ observedClient, sink }) => {
+  if (sink instanceof JsonlFileSink) {
+    const { path } = sink;                          // the file this client's samples go to
+    sink.once('close', () => uploadFile(path));     // close = flushed & fd closed → ready
+  }
+});
+```
+
+The general pattern: each concrete sink exposes whatever it wants as `public readonly` fields, and
+consumers narrow (`instanceof YourSink`) to read them. Your own sinks do the same.
+
+### Writing your own sink
+
+Subclass `ClientSampleSink` and emit the lifecycle events yourself — for any non-file
+destination (a remote endpoint, a message queue, an object store, …):
+
+```ts
+import { ClientSampleSink, ClientSample, ClientSampleSinkFactory } from '@observertc/observer-js';
+
+class HttpSink extends ClientSampleSink {
+  private buffer: ClientSample[] = [];
+  constructor(private readonly url: string) { super(); }
+
+  write(sample: ClientSample): boolean {
+    this.buffer.push(sample);                  // batch; decide your own backpressure
+    return true;
+  }
+  end(): void {
+    fetch(this.url, { method: 'POST', body: JSON.stringify(this.buffer) })
+      .then(() => this.emit('close'))          // signal "destination ready"
+      .catch((err) => this.emit('error', err));
+  }
 }
 
-// Example: Receiving stats and processing
-const rawStatsFromClient = {
-	/* ... your client's getStats() output ... */
-};
-const callId = 'meeting-alpha-123';
-const clientId = 'user-xyz-789';
-const sample = mapStatsToClientSample(rawStatsFromClient, callId, clientId);
-observer.accept(sample);
+const createClientSink: ClientSampleSinkFactory = ({ clientId, observedCall }) =>
+  new HttpSink(`https://stats.example.com/${observedCall.callId}/${clientId}`);
 
-// Later, on application shutdown:
-// observer.close();
+const observer = new Observer({ createClientSink });
 ```
 
-#### 5.2. Manual Call and Client Creation
+`observedClient.sink?` exposes the created sink; the `client-sink-created` event delivers it on
+the bus with full ancestry. `ClientSampleSinkFactory` is
+`(p: { clientId: string; observedCall: ObservedCall }) => ClientSampleSink | undefined`.
 
-```typescript
-// ... observer setup ...
+---
 
-const call = observer.createObservedCall({
-	callId: 'scheduled-webinar-456',
-	updatePolicy: 'update-on-interval',
-	updateIntervalInMs: 10000,
+## Injecting data into a client
+
+Sometimes the application holds data that belongs on a client's record but isn't part of the
+client-reported `ClientSample` — a room id or display name, an application-level event
+(*"recording started"*), a server-detected issue, an extension stat, or a device/meta item.
+`ObservedClient` exposes **injection** methods that merge such data into the client's sample stream,
+so it updates the live model **and** is persisted to the client's
+[sink](#sinks-per-client-sample-persistence) exactly like sampled data.
+
+| Method | Adds to the sample's | Surfaces as |
+|--------|----------------------|-------------|
+| `injectAttachment(attachments)` | `attachments` (merged via `Object.assign`) | `observedClient.attachments` |
+| `injectEvent(event: ClientEvent)` | `clientEvents` | `client-event` (plus any state the event drives) |
+| `injectIssue(issue: ClientIssue)` | `clientIssues` | `client-issue` |
+| `injectMetaData(meta: ClientMetaData)` | `clientMetaItems` | `client-metadata` |
+| `injectExtensionStat(stat: ExtensionStat)` | `extensionStats` | `client-extension-stats` |
+
+### When the injected data lands
+
+Injection is timing-aware so nothing is dropped, regardless of *when* you call it:
+
+- **During a sample's processing** — e.g. from inside a `client-updated` / `client-event` handler,
+  which run within `accept()` — the data is applied to the **current** sample immediately: reflected
+  in entity state and written to the sink as part of that sample.
+- **Between samples** — the data is buffered and merged into the **next** `accept()`'s sample.
+- **On `close()` with pending injections and no further sample** — the buffer is flushed as a final
+  synthetic sample (applied to state and written to the sink) before the sink is ended, so a
+  last-moment injection is never lost.
+
+In every case the injected data both updates the live `ObservedClient` and reaches the per-client
+sink — the sink always receives the final, **injection-merged** sample (the sink write happens at the
+end of `accept()`, after the merge).
+
+### Example
+
+```ts
+// Enrich at creation from your app's knowledge of the participant. Injecting in `client-added`
+// (which runs just before the first accept) lands on the first sample.
+observer.on('client-added', ({ observedClient }) => {
+  observedClient.injectAttachment({ roomId: lookupRoomId(observedClient.clientId) });
 });
 
-const client1 = call.createObservedClient({ clientId: 'presenter-01' });
-// Samples for 'presenter-01' in call 'scheduled-webinar-456' will update this client.
+// Application-level signals at any time:
+const client = observer.getObservedCall(callId)?.getObservedClient(clientId);
+client?.injectEvent({ type: 'RECORDING_STARTED', timestamp: Date.now() });
+client?.injectIssue({ type: 'app-kicked-participant', timestamp: Date.now() });
 ```
 
-#### 5.3. Using Event Monitors for Contextual Logging
-
-```typescript
-const call = observer.getObservedCall('meeting-alpha-123');
-if (call) {
-	const callMonitor = call.createEventMonitor({ callId: call.callId, started: new Date() });
-	callMonitor.on('client-joined', (client, context) => {
-		console.log(`EVENT_MONITOR (${context.callId}): Client ${client.clientId} joined at ${new Date()}`);
-	});
-	callMonitor.on('issue-detected', (client, issue, context) => {
-		console.error(`EVENT_MONITOR (${context.callId}): Issue on ${client.clientId} - ${issue.description}`);
-	});
-}
+`attachments` are latest-wins (like sampled `attachments`): injecting a key overwrites its previous
+value. `appData` is unaffected — injections flow into the sample/telemetry, not the app-owned
+`appData` bag (see [Ingestion](#ingestion-accept-context--lifecycle)).
+
+## Logging
+
+`observer-js` logs through a single, swappable sink. Out of the box it writes `debug` and
+above to `console` (verbose — install your own sink for production). Funnel everything into your
+logger:
+
+```ts
+import { setObserverLogger, type ObserverLogger } from '@observertc/observer-js';
+
+setObserverLogger({
+  trace: (m, ...a) => myLogger.trace(`[${m}]`, ...a),
+  debug: (m, ...a) => myLogger.debug(`[${m}]`, ...a),
+  info:  (m, ...a) => myLogger.info(`[${m}]`, ...a),
+  warn:  (m, ...a) => myLogger.warn(`[${m}]`, ...a),
+  error: (m, ...a) => myLogger.error(`[${m}]`, ...a),
+});
 ```
 
-### 6. Best Practices
+`createLogger(moduleName)` is also exported for your own modules. See
+**[`docs/logging.md`](./docs/logging.md)** for pino / winston / console recipes, level
+filtering, per-module routing, and full silencing.
+
+---
 
-- **Resource Management**: Always call `observer.close()`, `call.close()`, and `client.close()` when entities are no longer needed to free resources and stop timers.
-- **Error Handling**: Wrap calls to library methods in `try...catch` blocks where appropriate, especially for operations that might throw errors based on state (e.g., creating an entity that already exists if not using `getOrCreate` patterns).
-- **Event Listener Cleanup**: If dynamically adding/removing listeners, ensure they are properly removed (e.g., using `emitter.off()` or `emitter.removeListener()`) to prevent memory leaks, especially for short-lived monitored entities.
-- **`ClientSample` Accuracy**: The quality of monitoring heavily depends on the completeness and correctness of the `ClientSample` data provided. Ensure thorough mapping from `getStats()`.
-- **Update Policies**: Choose update policies carefully based on the desired granularity of updates and performance considerations.
+## Error-handling philosophy
 
-### 7. Troubleshooting
+The library **warns and degrades; it does not throw** on operational problems:
 
-- **Memory Leaks**: Ensure `close()` is called on all entities. Check for unremoved event listeners.
-- **No Events / Missing Updates**:
-  - Verify `observer.accept()` is being called with correctly formatted `ClientSample` data.
-  - Ensure `callId` and `clientId` in samples match expectations.
-  - Check if `updatePolicy` and `updateIntervalInMs` are configured as intended.
-- **Debugging**: Utilize `console.log` within event handlers at different levels (Observer, Call, Client) to trace data flow and state changes. Use `appData` to add correlation IDs for easier debugging.
+- `createObservedCall` / `createObservedClient` on a closed parent → warn + return `undefined`.
+- Duplicate id → warn + return the **existing** instance.
+- `accept()` on a closed client → warn + no-op.
+- Sample missing `callId`/`clientId`, or observer closed → `sample-rejected` event.
+- A throwing accept-middleware → warn + drop that sample (never crashes `accept()`).
 
-### 8. TypeScript Support
+Therefore `create*` and `getOrCreate*` return `T | undefined`; **guard the result.** The
+`Middleware` utility's internal invariants (e.g. calling `next()` twice) throw, but those throws
+are caught by `accept()` and surfaced as a warning.
 
-The library is written in TypeScript and provides type definitions.
-Use generics with `Observer`, `ObservedCall`, and `ObservedClient` to type your custom `appData`.
+---
 
-```typescript
-interface MyClientAppData {
-	userId: string;
-	role: 'admin' | 'user';
-}
-const client = call.createObservedClient<MyClientAppData>({
-	clientId: 'user1',
-	appData: { userId: 'u-123', role: 'admin' },
-});
-// client.appData will be typed as MyClientAppData | undefined
+## Development & extension guide
+
+```bash
+yarn install
+yarn build       # tsup → dist/ (dual ESM .mjs + CJS .js, single entry, .d.ts/.d.mts + sourcemaps)
+yarn lint        # eslint -c .eslintrc.json "src/**/*.ts"
+yarn typecheck   # tsc --noEmit
+yarn test        # jest
 ```
 
-### 9. Contributing
+The build is driven by [`tsup`](https://tsup.egoist.dev) (config in `tsup.config.ts`): a single
+entry (`src/index.ts`), dual ESM + CommonJS output to `dist/` (`index.mjs` / `index.js`) with
+`.d.mts` / `.d.ts` types and sourcemaps, targeting Node 20. CI (`.github/workflows/ci.yml`) runs
+lint + typecheck + **build** + test on every push/PR.
+
+**Project layout** (`src/`): `Observer.ts`, `ObservedCall.ts`, `ObservedClient.ts`,
+`ObservedPeerConnection.ts`, the `Observed*` sub-stat classes, `ObserverEvents.ts` (the typed
+event map + scope types), `detectors/` (`Detector`, `Detectors`), `scores/`, `updaters/`
+(update-policy strategies), `utils/` (remote-track resolvers), `common/` (`logger`, `utils`,
+`Middleware`), `schema/` (sample/event/meta types), and `sinks/` (the `ClientSampleSink` base +
+`JsonlFileSink` / `InMemorySink`, re-exported from the package root).
+
+**Conventions to follow when developing further:**
+
+- *Single event bus.* New consumer-facing events go in `ObserverEvents.ts` with an object
+  payload `[<Scope> & { …subject }]`, and are emitted via the component's
+  `_notify(type, { ...this.eventScope, …subject })`. Each component has a precomputed
+  `eventScope` field and a thin `_notify` wrapper around the right emitter. Keep purely internal
+  coordination as **local** EventEmitter events (and remember to `off` them on close).
+- *Warn, don't throw* on operational/edge conditions; return `undefined` where a value can't be produced.
+- *Counter-reset-safe deltas.* When computing a delta from a cumulative counter, never emit a
+  negative value (guard `curr >= prev`), to survive counter resets / SSRC reuse.
+- *Explicit accumulation.* The per-sample metric accumulation in `accept()` is intentionally
+  explicit and not abstracted — match that style.
+- *Detectors are server-side.* Add cross-client detectors on `ObservedCall.detectors`; don't
+  re-implement client-detectable signals.
+
+**Recipes:**
+
+- *Add an event:* add the key + payload to `ObserverEvents`; in the owning component call
+  `this._notify('my-event', { ...this.eventScope, subject })`.
+- *Add a per-stream metric:* add the field to the relevant `Observed*Rtp`/track class, populate
+  it in its `update()` (reset at the top of `update()` if it's per-tick), and read it from a
+  `*-updated` handler.
+- *Add a detector:* implement `Detector`, register it on `call-added` via
+  `observedCall.detectors.add(...)`, surface findings with `observedCall.addIssue(...)`.
 
-(Placeholder for contribution guidelines - e.g., link to CONTRIBUTING.md, coding standards, pull request process)
+---
 
-### 10. License
+## License
 
-This project is licensed under the [MIT License](LICENSE).
+Apache-2.0. Part of the [ObserverTC](https://github.com/observertc) ecosystem.