diff --git a/documentation/AGENTS.md b/documentation/AGENTS.md
index f842da26..d6c21d8d 100644
--- a/documentation/AGENTS.md
+++ b/documentation/AGENTS.md
@@ -47,8 +47,11 @@ structure, cross-linking, and validation rules.
 ## Cross-linking
 
 - Link from guides to concepts when the reader needs deeper mechanics.
-- Link only to source-of-truth files, package READMEs, implementation READMEs, or relevant source
-  files.
+- Link only to source-of-truth documentation files, package READMEs, or implementation READMEs.
+- Guides and concepts must not link to or mention source code files directly, including package
+  `src/**`, test files, implementation source files, scripts, config files, generated source
+  outputs, or source line numbers. When code-level detail is useful, link to package README,
+  implementation README, generated reference docs, or a concept/guide that explains the behavior.
 - After moving a document, fix all affected relative links.
 
 ## Validation
diff --git a/documentation/concepts/README.md b/documentation/concepts/README.md
index eb98658e..cf16782c 100644
--- a/documentation/concepts/README.md
+++ b/documentation/concepts/README.md
@@ -3,6 +3,7 @@ title: Concepts
 children:
   - ./core-state-management.md
   - ./entry-personalization-and-variant-resolution.md
+  - ./interaction-tracking-in-web-sdks.md
   - ./interaction-tracking-in-node-and-stateless-environments.md
   - ./profile-synchronization-between-client-and-server.md
   - ./react-native-sdk-interaction-tracking-mechanics.md
@@ -23,6 +24,10 @@ they are not the first stop for installation or setup commands.
 - [Entry personalization and variant resolution](./entry-personalization-and-variant-resolution.md) -
   explains how the SDK resolves a Contentful baseline entry to the selected entry variant, including
   data model expectations, fallback behavior, resolution paths, and preview overrides.
+- [Interaction tracking in Web SDKs](./interaction-tracking-in-web-sdks.md) - explains how
+  `@contentful/optimization-web` and `@contentful/optimization-react-web` detect browser entry
+  views, clicks, hovers, Custom Flag views, page events, and custom events, including consent,
+  profile, DOM, and delivery mechanics.
 - [Interaction tracking in Node and stateless environments](./interaction-tracking-in-node-and-stateless-environments.md) -
   explains what the Node SDK can track from a stateless server runtime, when browser observation is
   required, how the Web SDK can track server-generated HTML without owning personalization, and what
diff --git a/documentation/concepts/interaction-tracking-in-node-and-stateless-environments.md b/documentation/concepts/interaction-tracking-in-node-and-stateless-environments.md
index aebf5e64..f34f02f1 100644
--- a/documentation/concepts/interaction-tracking-in-node-and-stateless-environments.md
+++ b/documentation/concepts/interaction-tracking-in-node-and-stateless-environments.md
@@ -14,7 +14,9 @@ For step-by-step server setup, see
 [Integrating the Optimization Node SDK in a Node app](../guides/integrating-the-node-sdk-in-a-node-app.md).
 For browser setup, see
 [Integrating the Optimization Web SDK in a web app](../guides/integrating-the-web-sdk-in-a-web-app.md).
-For profile handoff between server and browser, see
+For Web SDK interaction tracking mechanics, see
+[Interaction tracking in Web SDKs](./interaction-tracking-in-web-sdks.md). For profile handoff
+between server and browser, see
 [Profile synchronization between client and server](./profile-synchronization-between-client-and-server.md).
 
 <details>
@@ -248,10 +250,10 @@ entry ID.
 
 ### Initialize the Web SDK without client-side personalization
 
-This browser code enables tracking but does not fetch entries or resolve variants:
+This browser code enables tracking but does not fetch entries or resolve variants. It assumes the
+Web SDK constructor is provided by your browser bundle or approved script delivery path:
 
 ```html
-<script src="/dist/contentful-optimization-web.umd.js"></script>
 <script>
   const optimization = new ContentfulOptimization({
     clientId: window.__OPTIMIZATION_CONFIG__.clientId,
@@ -473,9 +475,7 @@ Use this checklist when implementing interaction tracking for Node-rendered HTML
 
 - [Node SDK integration guide](../guides/integrating-the-node-sdk-in-a-node-app.md)
 - [Web SDK integration guide](../guides/integrating-the-web-sdk-in-a-web-app.md)
+- [Interaction tracking in Web SDKs](./interaction-tracking-in-web-sdks.md)
 - [Profile synchronization between client and server](./profile-synchronization-between-client-and-server.md)
 - [Node SSR + Web SDK reference implementation](../../implementations/node-sdk+web-sdk/README.md)
 - [Next.js SSR + React Web SDK reference implementation](../../implementations/react-web-sdk+node-sdk_nextjs-ssr/README.md)
-- [Node stateless runtime source](../../packages/universal/core-sdk/src/CoreStateless.ts)
-- [Web SDK tracking runtime source](../../packages/web/web-sdk/src/entry-tracking/EntryInteractionRuntime.ts)
-- [Web SDK tracking payload source](../../packages/web/web-sdk/src/entry-tracking/resolveTrackingPayload.ts)
diff --git a/documentation/concepts/interaction-tracking-in-web-sdks.md b/documentation/concepts/interaction-tracking-in-web-sdks.md
new file mode 100644
index 00000000..8a6e6eeb
--- /dev/null
+++ b/documentation/concepts/interaction-tracking-in-web-sdks.md
@@ -0,0 +1,428 @@
+---
+title: Interaction tracking in Web SDKs
+---
+
+# Interaction tracking in Web SDKs
+
+Use this document to understand how browser interaction tracking works in
+`@contentful/optimization-web` and the React layer provided by `@contentful/optimization-react-web`.
+It explains how entry views, clicks, hovers, Custom Flag views, page events, and custom events move
+from browser behavior to Core event delivery.
+
+For setup steps, see
+[Integrating the Optimization Web SDK in a web app](../guides/integrating-the-web-sdk-in-a-web-app.md)
+and
+[Integrating the Optimization React Web SDK in a React app](../guides/integrating-the-react-web-sdk-in-a-react-app.md).
+For server-owned rendering, see
+[Interaction tracking in Node and stateless environments](./interaction-tracking-in-node-and-stateless-environments.md).
+
+<details>
+  <summary>Table of Contents</summary>
+
+- [Tracking boundary](#tracking-boundary)
+- [Layer responsibilities](#layer-responsibilities)
+- [Event paths](#event-paths)
+- [Consent and profile gates](#consent-and-profile-gates)
+- [Tracked entry metadata](#tracked-entry-metadata)
+- [Runtime control and precedence](#runtime-control-and-precedence)
+- [DOM discovery](#dom-discovery)
+- [View tracking mechanics](#view-tracking-mechanics)
+- [Click tracking mechanics](#click-tracking-mechanics)
+- [Hover tracking mechanics](#hover-tracking-mechanics)
+- [React Web mechanics](#react-web-mechanics)
+- [Delivery and flushing](#delivery-and-flushing)
+- [Debugging model](#debugging-model)
+- [Design boundaries](#design-boundaries)
+- [Reference](#reference)
+
+</details>
+
+## Tracking boundary
+
+Interaction tracking has two separate jobs:
+
+- **Detection** - Observing browser state or application calls and deciding that an interaction
+  happened.
+- **Delivery** - Building a valid Optimization event, applying consent and profile gates, and
+  sending the event to the correct API.
+
+The Web SDK owns browser detection for Contentful entry views, clicks, and hovers. Core owns event
+construction, consent checks, queues, profile state, and API delivery. React Web does not implement
+a separate tracking engine; it renders Web SDK tracking metadata and exposes the underlying Web SDK
+tracking API through React providers and hooks.
+
+This split keeps the browser-specific code small. A view observer can focus on
+`IntersectionObserver`, timers, and DOM lifecycle. Core can focus on whether a `trackView()` call is
+allowed, which event type it becomes, and which queue receives it.
+
+## Layer responsibilities
+
+| Layer                                | Responsibility in interaction tracking                                                                                                                                         |
+| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `@contentful/optimization-core`      | Builds `page`, `identify`, `track`, entry view, entry click, entry hover, and Custom Flag view events. Applies consent gates. Queues Experience API and Insights API work.     |
+| `@contentful/optimization-web`       | Initializes Core for a browser runtime. Persists consent, profile data, selected optimizations, and anonymous IDs. Discovers tracked DOM elements and observes interactions.   |
+| `@contentful/optimization-react-web` | Creates and tears down the Web SDK instance, resolves entries in React, emits `data-ctfl-*` attributes, exposes `interactionTracking`, and emits router-driven `page()` calls. |
+
+The application still owns Contentful fetching, rendering policy, consent UX, identity policy, route
+ownership, and any business event taxonomy passed to `track()`.
+
+## Event paths
+
+Tracking events use two API paths:
+
+| Path           | Methods                                                                     | Main effect                                                                                   |
+| -------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
+| Experience API | `page()`, `identify()`, `screen()`, `track()`, sticky `trackView()`         | Evaluates or updates a profile and returns `profile`, `selectedOptimizations`, and `changes`. |
+| Insights API   | non-sticky `trackView()`, `trackClick()`, `trackHover()`, `trackFlagView()` | Sends Analytics events for entry interactions and Custom Flag observations.                   |
+
+The Web SDK normally starts a browser journey with `page()` or `identify()`. Those calls use the
+Experience API and populate the state that later Insights events need for attribution. If an
+Insights event is emitted before the stateful SDK has a profile, Core logs a warning and drops that
+Insights event because there is no profile to attach to the batch.
+
+The entry interaction methods map to these wire event types:
+
+| SDK method        | Wire type                                    | Common source                                                            |
+| ----------------- | -------------------------------------------- | ------------------------------------------------------------------------ |
+| `trackView()`     | `component`                                  | `IntersectionObserver` entry view detection, or direct application call. |
+| `trackClick()`    | `component_click`                            | Document click listener, or direct application call.                     |
+| `trackHover()`    | `component_hover`                            | Pointer or mouse hover listener, or direct application call.             |
+| `trackFlagView()` | `component` with `componentType: 'Variable'` | `getFlag()` and `states.flag(name)` reads from stateful Core.            |
+
+Sticky entry views touch both paths. When `trackView({ sticky: true, ... })` is called, Core sends
+the view through Experience first, then sends an Insights view event. Non-sticky views only use
+Insights.
+
+## Consent and profile gates
+
+The Web SDK defaults `allowedEventTypes` to `['identify', 'page']`. Until consent is accepted, Core
+blocks non-allowed event types such as `track`, `component`, `component_click`, and
+`component_hover`.
+
+Consent affects two parts of automatic entry tracking:
+
+- **Observer startup** - Auto-enabled entry interaction detectors start only when consent is `true`.
+  Calling `consent(false)` stops those auto-enabled detectors.
+- **Event delivery** - Every event call still passes through Core's consent guard. Manual
+  `tracking.enableElement(...)` can force an element detector to run, but emitted events are still
+  blocked unless consent or `allowedEventTypes` permits the event type.
+
+This means a typical browser integration needs both:
+
+1. A profile-producing event such as `page()` or `identify()`.
+2. Consent or an explicit event allow-list for the interaction event types the application wants to
+   send.
+
+Blocked events are observable through `onEventBlocked` and `states.blockedEventStream`. Events that
+are blocked by consent are not replayed later when consent changes.
+
+## Tracked entry metadata
+
+Automatic tracking starts from DOM metadata. The Web SDK looks for HTML or SVG elements with a
+non-empty `data-ctfl-entry-id` attribute.
+
+| Attribute                                     | Used for                                                                                             |
+| --------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
+| `data-ctfl-entry-id`                          | Required. Becomes `componentId` in entry interaction events.                                         |
+| `data-ctfl-optimization-id`                   | Optional. Becomes `experienceId`.                                                                    |
+| `data-ctfl-sticky`                            | Optional. `true` sends the first successful view for the element through the sticky Experience path. |
+| `data-ctfl-variant-index`                     | Optional. Non-negative integer used as `variantIndex`; invalid or unsafe values are ignored.         |
+| `data-ctfl-track-views`                       | Optional. `true` or `false` override for view observation when the view detector is running.         |
+| `data-ctfl-track-clicks`                      | Optional. `true` or `false` override for click observation when the click detector is running.       |
+| `data-ctfl-track-hovers`                      | Optional. `true` or `false` override for hover observation when the hover detector is running.       |
+| `data-ctfl-view-duration-update-interval-ms`  | Optional. Per-element interval for periodic view-duration updates.                                   |
+| `data-ctfl-hover-duration-update-interval-ms` | Optional. Per-element interval for periodic hover-duration updates.                                  |
+| `data-ctfl-clickable`                         | Optional. `true` marks a non-semantic element as part of a clickable path for click tracking.        |
+
+The tracking payload uses the resolved entry ID, not the baseline entry ID. When an application
+needs the baseline ID for rerendering, store it separately, for example in `data-ctfl-baseline-id`.
+The Web SDK does not use `data-ctfl-baseline-id` in event payloads.
+
+Manual element observation can provide the same metadata without DOM attributes:
+
+```ts
+optimization.tracking.enableElement('views', element, {
+  data: {
+    entryId: resolvedEntry.sys.id,
+    optimizationId: selectedOptimization?.experienceId,
+    sticky: selectedOptimization?.sticky,
+    variantIndex: selectedOptimization?.variantIndex,
+  },
+})
+```
+
+When manual `data` is valid, it takes precedence over `data-ctfl-*` values on the element. If manual
+data is missing or invalid, the detector falls back to the element attributes.
+
+## Runtime control and precedence
+
+Automatic tracking is opt-in. If `autoTrackEntryInteraction` is omitted, all automatic interaction
+types default to `false`:
+
+```ts
+const optimization = new ContentfulOptimization({
+  clientId: 'your-client-id',
+  autoTrackEntryInteraction: {
+    views: true,
+    clicks: true,
+    hovers: false,
+  },
+})
+```
+
+The same runtime can be controlled after initialization:
+
+| API                                                      | Effect                                                                                             |
+| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
+| `tracking.enable(interaction, options?)`                 | Enables automatic observation for `'views'`, `'clicks'`, or `'hovers'`.                            |
+| `tracking.disable(interaction)`                          | Disables automatic observation for that interaction and stops it when no manual overrides need it. |
+| `tracking.enableElement(interaction, element, options?)` | Force-enables one element, even when global automatic tracking for that interaction is off.        |
+| `tracking.disableElement(interaction, element)`          | Force-disables one element.                                                                        |
+| `tracking.clearElement(interaction, element)`            | Removes the manual override so the element falls back to attribute overrides or automatic state.   |
+
+For each element, the runtime resolves tracking in this order:
+
+1. Manual API override from `enableElement(...)` or `disableElement(...)`.
+2. Per-element `data-ctfl-track-*` override.
+3. Global automatic tracking state and the element registry.
+
+`reset()` stops interaction trackers and clears manual element overrides. `destroy()` also
+disconnects DOM observers and browser lifecycle listeners.
+
+## DOM discovery
+
+The Web SDK has one shared entry element registry. When an interaction detector starts, the registry
+does two things:
+
+- Seeds the initial set from `document.querySelectorAll('[data-ctfl-entry-id]')`.
+- Subscribes to a `MutationObserver` that watches child additions and removals in the document
+  subtree.
+
+When a tracked element is added, the registry notifies the running view, click, and hover detectors.
+When a tracked element is removed, the registry notifies those detectors so they can unobserve the
+element or stop treating it as tracked.
+
+The registry observes element existence, not arbitrary attribute changes. Entry payload attributes
+such as `data-ctfl-entry-id` are read when an event fires, so updated IDs can affect later payloads.
+Per-element tracking overrides such as `data-ctfl-track-views` and interval attributes are resolved
+when the element is added to the detector. If an existing mounted element needs dynamic override
+changes, use the `tracking.*Element(...)` API or remount the tracked element.
+
+## View tracking mechanics
+
+View tracking uses `IntersectionObserver` and dwell-time timers.
+
+Default view settings:
+
+| Setting                             | Default  |
+| ----------------------------------- | -------- |
+| Required visible dwell time         | 1000 ms  |
+| Periodic duration update interval   | 5000 ms  |
+| Minimum visible ratio               | 0.1      |
+| `IntersectionObserver` root         | `null`   |
+| `IntersectionObserver` root margin  | `0px`    |
+| Disconnected-element sweep interval | 30000 ms |
+
+A view cycle works like this:
+
+1. The element crosses the configured visibility threshold.
+2. The observer starts a fresh cycle, assigns a `viewId`, resets accumulated duration, and starts
+   the dwell timer.
+3. After the dwell time passes, the observer calls `trackView()` with `viewId` and `viewDurationMs`.
+4. While the element remains visible, the observer sends periodic duration updates using the same
+   `viewId`.
+5. When the element leaves view after at least one view event fired, the observer sends a final
+   duration update.
+6. If the element leaves view before dwell time completes, the cycle resets without sending an
+   event.
+
+The observer pauses dwell accumulation when the page is hidden and resumes when the page becomes
+visible again. It coalesces in-flight callbacks so a slow or failing event send does not create
+duplicate concurrent sends for the same element. If visibility ends while an event send is in
+flight, the final duration update is sent after that in-flight attempt settles.
+
+Sticky view handling is per DOM element. If the payload has `sticky: true`, the first view attempt
+for that element sends `sticky: true` to Core. After Core returns optimization data for that sticky
+view, later view events for the same element omit `sticky`. If the sticky attempt does not return
+optimization data, the detector retries sticky on the next visibility cycle for that element.
+Separately rendered elements with the same entry ID are treated as separate sticky targets.
+
+## Click tracking mechanics
+
+Click tracking uses one document-level capture listener. It does not call `preventDefault()` or
+`stopPropagation()`.
+
+When a click occurs, the detector resolves two facts:
+
+- Which tracked entry element owns the click.
+- Whether the event path is semantically clickable.
+
+The click detector treats these paths as clickable:
+
+- `a[href]`
+- `button`
+- non-hidden `input`
+- `select`
+- `textarea`
+- `summary`
+- `[role="button"]`
+- `[role="link"]`
+- `[onclick]`
+- elements with an `onclick` property handler
+- `[data-ctfl-clickable="true"]`
+
+The tracked entry can be the clicked element, an ancestor of the clicked element, or a descendant of
+a clickable ancestor. The detector also handles click events whose original target is a text node by
+walking to the parent element.
+
+If a tracked entry and a clickable path are found, the detector resolves entry metadata and calls
+`trackClick()`. Click events do not include a click duration or click ID; the payload carries the
+entry and optimization metadata.
+
+## Hover tracking mechanics
+
+Hover tracking uses element-level listeners. When `PointerEvent` is available, the observer listens
+for `pointerenter`, `pointerleave`, and `pointercancel`, and ignores touch pointer events. When
+pointer events are unavailable, it falls back to `mouseenter` and `mouseleave`.
+
+Default hover settings:
+
+| Setting                             | Default  |
+| ----------------------------------- | -------- |
+| Required hover dwell time           | 1000 ms  |
+| Periodic duration update interval   | 5000 ms  |
+| Disconnected-element sweep interval | 30000 ms |
+
+A hover cycle mirrors the view cycle:
+
+1. The pointer enters a tracked element.
+2. The observer starts a fresh cycle, assigns a `hoverId`, resets accumulated duration, and starts
+   the dwell timer.
+3. After dwell time passes, the observer calls `trackHover()` with `hoverId` and `hoverDurationMs`.
+4. While the pointer remains hovered, the observer sends periodic duration updates using the same
+   `hoverId`.
+5. When the pointer leaves after at least one hover event fired, the observer sends a final duration
+   update.
+6. If hover ends before dwell time completes, the cycle resets without sending an event.
+
+Like view tracking, hover tracking pauses while the page is hidden, coalesces in-flight callbacks,
+and sweeps disconnected element state.
+
+## React Web mechanics
+
+React Web wraps the Web SDK; it does not replace the Web SDK tracking runtime.
+
+`OptimizationRoot` creates one `ContentfulOptimization` instance from its props and destroys that
+instance on unmount. `autoTrackEntryInteraction`, `allowedEventTypes`, `defaults`, `queuePolicy`,
+and other Web SDK configuration values pass through to the underlying instance.
+
+`OptimizedEntry` does three tracking-related things:
+
+- Resolves the baseline entry with `useOptimizedEntry()`.
+- Renders a wrapper element with `display: contents`.
+- Adds tracking attributes for the resolved entry when resolved content is ready.
+
+The wrapper receives:
+
+```html
+<div
+  data-ctfl-entry-id="resolved-entry-id"
+  data-ctfl-optimization-id="experience-id"
+  data-ctfl-sticky="true"
+  data-ctfl-variant-index="1"
+  data-ctfl-duplication-scope="session"
+></div>
+```
+
+`data-ctfl-duplication-scope` is emitted by React Web for optimization metadata, but the Web SDK
+entry interaction payload does not use it.
+
+During loading, `OptimizedEntry` does not emit resolved entry tracking attributes. Loading UI is
+therefore not tracked as the resolved Contentful entry. If `children` is a direct `ReactNode`
+instead of a render prop, the wrapper still receives tracking attributes, but the child content does
+not change based on the resolved entry.
+
+`useOptimizedEntry()` only resolves data. It does not add DOM attributes or register an element. If
+a component uses `useOptimizedEntry()` directly, it must either render the `data-ctfl-*` attributes
+itself or use `interactionTracking.enableElement(...)`.
+
+React Web router adapters emit `page()` calls when supported routers change route. They are page
+event helpers, not entry interaction detectors. Entry views, clicks, and hovers still come from the
+Web SDK runtime.
+
+## Delivery and flushing
+
+Insights events are queued by current profile ID and sent in batches. The queue flushes
+periodically, flushes when the queued event count reaches the batch threshold, and can be flushed
+explicitly with `optimization.flush()`.
+
+Experience events are sent immediately when the browser is online. When the browser is offline,
+Experience events are queued up to the configured offline maximum and replayed when the online
+signal becomes `true`.
+
+The Web SDK wires browser lifecycle events into this queue model:
+
+- `online` and `offline` update Core's online signal. Going online forces a flush.
+- `visibilitychange`, `pagehide`, and `beforeunload` call `flush()` once per hide cycle.
+- Insights delivery uses the configured beacon handler, which defaults to `navigator.sendBeacon()`.
+
+Browser persistence is best-effort. Consent, profile, selected optimizations, Custom Flag changes,
+and the anonymous ID are read from `localStorage` at startup when available. The anonymous ID is
+also persisted in the `ctfl-opt-aid` cookie and migrated from the legacy anonymous ID cookie when
+present.
+
+## Debugging model
+
+When an expected interaction does not appear, check the gates in this order:
+
+1. **Profile** - Call `page()` or `identify()` before relying on Insights events. Insights delivery
+   needs a current profile in state.
+2. **Consent** - Confirm `states.consent.current === true` or configure `allowedEventTypes` for the
+   event types that must emit before consent.
+3. **Detector startup** - Confirm `autoTrackEntryInteraction` or `tracking.enable(...)` is enabled
+   for the relevant interaction.
+4. **Element metadata** - Confirm the tracked element is an HTML or SVG element with non-empty
+   `data-ctfl-entry-id`, or that `enableElement(...)` supplies valid `data.entryId`.
+5. **View threshold** - Confirm the element stays above `minVisibleRatio` for `dwellTimeMs`.
+6. **Clickability** - Confirm clicks happen on a semantic clickable path or an element marked with
+   `data-ctfl-clickable="true"`.
+7. **Hover source** - Confirm the event is not a touch pointer event and that the pointer remains
+   over the element long enough to satisfy dwell time.
+8. **Manual override precedence** - Confirm `disableElement(...)` or `data-ctfl-track-*="false"` is
+   not suppressing the element.
+
+For local diagnostics, subscribe to `states.eventStream` and `states.blockedEventStream`, and use
+`onEventBlocked` for consent-gating visibility.
+
+## Design boundaries
+
+The Web SDKs do not own every part of tracking:
+
+- They do not fetch Contentful entries.
+- They do not decide whether a user has granted consent.
+- They do not infer a browser view from server rendering alone.
+- They do not make non-clickable markup clickable.
+- They do not replay events blocked before consent.
+- They do not guarantee persistence in browsers that deny storage access.
+
+Keep these boundaries explicit when integrating or changing tracking behavior. Detection belongs to
+the browser runtime, event semantics belong to Core, and application-specific policy stays in the
+application.
+
+## Reference
+
+- [Core state management](./core-state-management.md) - Core state, consent, queues, observables,
+  and event streams.
+- [Entry personalization and variant resolution](./entry-personalization-and-variant-resolution.md) -
+  How resolved entries and selected optimization metadata are produced before tracking metadata is
+  rendered.
+- [Interaction tracking in Node and stateless environments](./interaction-tracking-in-node-and-stateless-environments.md) -
+  How browser tracking fits when server runtimes own personalization.
+- [Optimization Web SDK README](../../packages/web/web-sdk/README.md) - Package-level orientation
+  and Web SDK setup options.
+- [Optimization React Web SDK README](../../packages/web/frameworks/react-web-sdk/README.md) - React
+  provider, hook, router, and entry-rendering orientation.
+- [Integrating the Optimization Web SDK in a web app](../guides/integrating-the-web-sdk-in-a-web-app.md) -
+  Step-by-step browser integration flow.
+- [Integrating the Optimization React Web SDK in a React app](../guides/integrating-the-react-web-sdk-in-a-react-app.md) -
+  Step-by-step React integration flow.
diff --git a/documentation/concepts/react-native-sdk-interaction-tracking-mechanics.md b/documentation/concepts/react-native-sdk-interaction-tracking-mechanics.md
index 39d00e64..243033cb 100644
--- a/documentation/concepts/react-native-sdk-interaction-tracking-mechanics.md
+++ b/documentation/concepts/react-native-sdk-interaction-tracking-mechanics.md
@@ -126,8 +126,7 @@ particular:
 | `trackClick` | `component_click`                                                |
 | `trackHover` | `component_hover` (not emitted by RN; included for completeness) |
 
-These wire types are defined in `packages/universal/core-sdk/src/CoreStatefulEventEmitter.ts:45-50`
-and are shared across all SDKs (web, iOS, RN).
+These wire types are shared across SDK runtimes.
 
 ## 2. How events flow from the device
 
@@ -158,14 +157,12 @@ The React Native SDK layers RN-specific behavior on top:
 1. **Online/offline detection** via `@react-native-community/netinfo`. When offline, the queue
    buffers; when `isInternetReachable` (preferred) or `isConnected` flips back to `true`, the SDK
    resumes flushing. If NetInfo is not installed the SDK logs a warning and stays always-online —
-   you keep tracking but lose offline durability. _Source:
-   `packages/react-native-sdk/src/handlers/createOnlineChangeListener.ts:74-112`._
+   you keep tracking but lose offline durability.
 2. **Background flushing.** On `AppState` transition to `background` or `inactive`, the SDK calls
-   `flush()` to drain the queue before the OS might suspend the process. _Source:
-   `packages/react-native-sdk/src/handlers/createAppStateChangeListener.ts:38-54`._
+   `flush()` to drain the queue before the OS might suspend the process.
 3. **Final view event on background.** If an entry is mid-visibility-cycle when the app backgrounds,
    `useViewportTracking` pauses, emits a final view event if at least one event already fired, and
-   resets. _Source: `packages/react-native-sdk/src/hooks/useViewportTracking.ts:525-553`._
+   resets.
 
 The offline queue has a cap (`queuePolicy.offlineMaxEvents`) and a drop callback
 (`queuePolicy.onOfflineDrop`). See the
@@ -187,8 +184,7 @@ assignments survive a cold start:
 | `DEBUG_FLAG_KEY`                   | Forces `logLevel` to `'debug'` when set.                                           |
 
 Persistence is best-effort; write failures keep the SDK running on in-memory state. Structured
-values are schema-validated on load; malformed JSON is evicted. _Source:
-`packages/react-native-sdk/src/storage/AsyncStorageStore.ts`._
+values are schema-validated on load; malformed JSON is evicted.
 
 Why this matters for tracking: selected optimizations persist, so a user placed in Variant B
 continues to see it on the next launch and view/tap events carry the correct `experienceId` /
@@ -207,8 +203,7 @@ The SDK gates event emission behind a three-valued consent state: `true`, `false
 | `true`      | All event types emit.                                                                                            |
 | `false`     | Same as `undefined` — only `allowedEventTypes` emit. Persists until `consent(true)` is called again.             |
 
-The default allow-list comes from `packages/react-native-sdk/src/ContentfulOptimization.ts:52`. To
-widen it before consent, pass `allowedEventTypes` to `OptimizationRoot`:
+To widen the default pre-consent allow-list, pass `allowedEventTypes` to `OptimizationRoot`:
 
 ```tsx
 <OptimizationRoot clientId={CLIENT_ID} allowedEventTypes={['identify', 'screen', 'page']}>
@@ -242,8 +237,7 @@ under the hood.
 
 ### Default thresholds
 
-All defaults live as module constants in
-`packages/react-native-sdk/src/hooks/useViewportTracking.ts:72-75`:
+The default entry view thresholds are:
 
 | Constant                                   | Value  | Meaning                                                                                                             |
 | ------------------------------------------ | ------ | ------------------------------------------------------------------------------------------------------------------- |
@@ -251,8 +245,7 @@ All defaults live as module constants in
 | `DEFAULT_VIEW_TIME_MS`                     | `2000` | Minimum accumulated visible time (ms) before the **initial** view event fires. A.k.a. the "dwell time".             |
 | `DEFAULT_VIEW_DURATION_UPDATE_INTERVAL_MS` | `5000` | Interval (ms) between **periodic** duration update events after the initial event.                                  |
 
-Tap tracking has one additional threshold in
-`packages/react-native-sdk/src/hooks/useTapTracking.ts:17`:
+Tap tracking has one additional threshold:
 
 | Constant                 | Value | Meaning                                                                                                                         |
 | ------------------------ | ----- | ------------------------------------------------------------------------------------------------------------------------------- |
@@ -273,8 +266,6 @@ interface ViewCycleState {
 }
 ```
 
-_Source: `packages/react-native-sdk/src/hooks/useViewportTracking.ts:89-101`._
-
 On every scroll tick or layout change, `checkVisibility()` computes the overlap between the entry's
 measured `{y, height}` and the current viewport `{scrollY, viewportHeight}` to derive a
 `visibilityRatio`, and compares it to `threshold`:
@@ -312,7 +303,7 @@ A few consequences:
 - **An entry briefly scrolled into view (< 2 s total) fires no events.** The initial gate is never
   crossed, so the final event is suppressed (guarded by `attempts > 0`).
 - **An entry scrolled into view for 2 s and then immediately unmounted** fires one initial event,
-  then one final event (from the unmount cleanup effect at `useViewportTracking.ts:555-568`).
+  then one final event from the unmount cleanup effect.
 - **Each event carries `viewDurationMs`**, computed from the cycle's accumulated time at the moment
   of emission. The sequence of events for a 12 s continuous view is: initial (~2000 ms), periodic
   (~7000 ms), periodic (~12 000 ms), final (~12 000 ms).
@@ -327,12 +318,10 @@ Two additional transitions matter:
    background/inactive, it clears the fire timer, pauses accumulation, and — if `attempts > 0` —
    emits a final event before resetting the cycle and marking `isVisibleRef.current = false`. When
    the app becomes `active` again, it re-checks visibility from scratch, which will start a new
-   cycle if the entry is still on screen. _Source:
-   `packages/react-native-sdk/src/hooks/useViewportTracking.ts:525-553`._
+   cycle if the entry is still on screen.
 
 2. **Component unmount.** The unmount cleanup clears the fire timer and, if the cycle had any
-   successful events (`attempts > 0`), flushes a final view event synchronously. _Source:
-   `packages/react-native-sdk/src/hooks/useViewportTracking.ts:555-568`._
+   successful events (`attempts > 0`), flushes a final view event synchronously.
 
 Combined, these guarantees mean that as long as the initial event fired, a final event (with a
 matching `viewId` and the true total duration) will always follow — whether visibility ends
@@ -361,15 +350,13 @@ no matter how far the user scrolls.
 </OptimizationScrollProvider>
 ```
 
-_Source: `packages/react-native-sdk/src/context/OptimizationScrollContext.tsx:80-154`._ The in-tree
-reference implementation wraps its entry list in
-[`OptimizationScrollProvider`](../../implementations/react-native-sdk/App.tsx).
+The [React Native reference implementation](../../implementations/react-native-sdk/README.md)
+demonstrates this scroll-provider pattern in its entry list.
 
 ### Outside OptimizationScrollProvider
 
 With no scroll context, the hook falls back to screen dimensions — `scrollY = 0`, viewport =
-`Dimensions.get('window').height` (with an orientation listener). _Source:
-`packages/react-native-sdk/src/hooks/useViewportTracking.ts:256-257`._
+`Dimensions.get('window').height` with an orientation listener.
 
 This is correct for full-screen non-scrollable layouts, hero/banner content always on screen, and
 modal content. It is _wrong_ for anything below the fold in a `ScrollView` — wrap those.
@@ -388,8 +375,6 @@ Tap tracking is implemented by `useTapTracking`. Behavior:
    `component_click`). If `onTap` was passed on `<OptimizedEntry>`, it's also invoked synchronously
    with the resolved entry.
 
-_Source: `packages/react-native-sdk/src/hooks/useTapTracking.ts:95-156`._
-
 Tap tracking is **off by default**. Enable via
 `<OptimizationRoot trackEntryInteraction={{ taps: true }}>`, `<OptimizedEntry trackTaps>`, or
 implicitly by passing `onTap`.
@@ -421,8 +406,7 @@ The highest-automation path. Wrap `NavigationContainer` in `<OptimizationNavigat
 
 `onReady` fires the initial screen event; `onStateChange` compares the current route name to the
 previous and emits a new screen event when they differ. `includeParams: true` includes the route
-params in the event's `properties` (they're JSON-validated via Zod before being attached). _Source:
-`packages/react-native-sdk/src/components/OptimizationNavigationContainer.tsx:108-167`._
+params in the event's `properties`, which are JSON-validated before being attached.
 
 ### useScreenTracking
 
@@ -443,8 +427,7 @@ function DetailsScreen() {
 ```
 
 With `trackOnMount: true` (the default), it fires once on mount. The hook also resets its internal
-`hasTrackedRef` whenever `name` changes, so renaming the screen mid-life re-fires. _Source:
-`packages/react-native-sdk/src/hooks/useScreenTracking.ts:113-167`._
+tracking state whenever `name` changes, so renaming the screen mid-life re-fires.
 
 ### useScreenTrackingCallback
 
@@ -457,8 +440,6 @@ const trackScreen = useScreenTrackingCallback()
 trackScreen('Deep Linked Article', { slug, source: 'email' })
 ```
 
-_Source: `packages/react-native-sdk/src/hooks/useScreenTracking.ts:55-71`._
-
 ## 8. The configuration surface
 
 All interaction-tracking behavior is controlled at one of three layers: SDK init config,
@@ -475,8 +456,7 @@ ones.
 | `defaults.consent`      | `boolean \| undefined` | `undefined`                    | Initial consent state at startup. Overridden by `consent()` calls at runtime.                     |
 | `allowedEventTypes`     | `EventType[]`          | `['identify', 'screen']`       | Event types permitted while consent is `undefined` or `false`.                                    |
 
-The "`{ views: true, taps: false }`" default lives in
-`packages/react-native-sdk/src/context/InteractionTrackingContext.tsx:38-44`.
+The "`{ views: true, taps: false }`" default is the root interaction-tracking context default.
 
 ### OptimizedEntry props
 
@@ -492,9 +472,7 @@ The "`{ views: true, taps: false }`" default lives in
 | `entry`                        | `Entry`                                  | (required)  | The baseline or optimized Contentful entry.                                                            |
 | `children`                     | `ReactNode \| ((resolved) => ReactNode)` | (required)  | Render prop receives the resolved variant; static children are rendered as-is.                         |
 
-Each default is defined alongside the corresponding prop in
-`packages/react-native-sdk/src/components/OptimizedEntry.tsx:64-141` and confirmed in
-`useViewportTracking.ts:72-75`.
+Each default is defined by the SDK component and tracking hook behavior.
 
 ### SDK init config
 
@@ -532,8 +510,6 @@ The full configuration reference lives in the
 3. Else use `trackEntryInteraction.taps` from `OptimizationRoot`.
 4. Else use the default (`false`).
 
-_Source: `packages/react-native-sdk/src/components/OptimizedEntry.tsx:143-151, 272-273`._
-
 **Live updates enabled?**
 
 1. If the preview panel is open — always `true`, cannot be overridden.
@@ -541,8 +517,6 @@ _Source: `packages/react-native-sdk/src/components/OptimizedEntry.tsx:143-151, 2
 3. Else use `OptimizationRoot.liveUpdates`.
 4. Else default (`false`; the entry locks to its first variant).
 
-_Source: `packages/react-native-sdk/src/components/OptimizedEntry.tsx:229-231`._
-
 ## 9. Manual tracking API
 
 For content that doesn't fit `<OptimizedEntry>` — custom screens, server-rendered fragments,
@@ -565,7 +539,6 @@ useEffect(() => {
 ### Payload shapes
 
 ```ts
-// trackView — Source: CoreStatefulEventEmitter.ts:215-237
 optimization.trackView({
   componentId: string,
   viewId?: string,              // UUID; correlates events in a cycle
@@ -576,7 +549,6 @@ optimization.trackView({
   profile?: PartialProfile,
 })
 
-// trackClick — Source: CoreStatefulEventEmitter.ts:249-251 (wire type: component_click)
 optimization.trackClick({
   componentId: string,
   experienceId?: string,
@@ -652,14 +624,9 @@ For the broader integration walkthrough, read the
 
 ## Reference
 
-- **SDK source:** `packages/react-native-sdk/src/`
-- **Tracking hooks:** `hooks/useViewportTracking.ts`, `hooks/useTapTracking.ts`,
-  `hooks/useScreenTracking.ts`
-- **Context providers:** `context/InteractionTrackingContext.tsx`,
-  `context/OptimizationScrollContext.tsx`, `context/LiveUpdatesContext.tsx`
-- **Event emission pipeline:** `packages/universal/core-sdk/src/CoreStatefulEventEmitter.ts`
-- **Reference implementation:**
-  [`implementations/react-native-sdk`](../../implementations/react-native-sdk/README.md) exercises
-  the React Native SDK API surface in this monorepo.
-- **Integration guide:**
-  [Integrating the Optimization React Native SDK in a React Native app](../guides/integrating-the-react-native-sdk-in-a-react-native-app.md).
+- [React Native SDK README](../../packages/react-native-sdk/README.md) - Package-level orientation
+  and common configuration.
+- [React Native reference implementation](../../implementations/react-native-sdk/README.md) -
+  Working app that exercises the React Native SDK API surface in this monorepo.
+- [Integrating the Optimization React Native SDK in a React Native app](../guides/integrating-the-react-native-sdk-in-a-react-native-app.md) -
+  Step-by-step React Native integration flow.
diff --git a/documentation/guides/AGENTS.md b/documentation/guides/AGENTS.md
index 97c39914..53cd9c35 100644
--- a/documentation/guides/AGENTS.md
+++ b/documentation/guides/AGENTS.md
@@ -69,7 +69,8 @@ Every guide must include this TOC wrapper:
 - Mention relevant monorepo reference implementations briefly near the top of an integration guide,
   usually in `The integration flow`.
 - Expand reference links in `Reference implementations to compare against`.
-- Prefer links to implementation READMEs and relevant source files over vague references.
+- Link to implementation READMEs, not implementation source files. Describe the demonstrated
+  workflow in prose when a specific implementation area matters.
 
 ## Validation
 
diff --git a/documentation/guides/integrating-the-node-sdk-in-a-node-app.md b/documentation/guides/integrating-the-node-sdk-in-a-node-app.md
index 1dbad787..47948f53 100644
--- a/documentation/guides/integrating-the-node-sdk-in-a-node-app.md
+++ b/documentation/guides/integrating-the-node-sdk-in-a-node-app.md
@@ -597,20 +597,17 @@ is usually the right move when you need:
 For the lower-level mechanics behind cookie-based continuity, see
 [Profile synchronization between client and server](../concepts/profile-synchronization-between-client-and-server.md).
 
-The hybrid reference implementation shows exactly that setup:
-
-- [Server integration](../../implementations/node-sdk+web-sdk/src/app.ts)
-- [Browser integration](../../implementations/node-sdk+web-sdk/src/index.ejs)
+The [Node SSR + Web SDK reference implementation](../../implementations/node-sdk+web-sdk/README.md)
+shows that setup across its server and browser flows.
 
 ## Reference implementations to compare against
 
-Use these files when you want working repository examples instead of guide snippets:
+Use these reference implementations when you want working repository examples instead of guide
+snippets:
 
-- [`implementations/node-sdk/src/app.ts`](../../implementations/node-sdk/src/app.ts): server-only
-  SSR flow with `page()`, `identify()`, `resolveOptimizedEntry()`, and `getMergeTagValue()`
-- [`implementations/node-sdk/src/index.ejs`](../../implementations/node-sdk/src/index.ejs): rendered
-  output that consumes resolved entries
-- [`implementations/node-sdk+web-sdk/src/app.ts`](../../implementations/node-sdk+web-sdk/src/app.ts):
-  cookie sharing with `ANONYMOUS_ID_COOKIE` for Node and Web SDK continuity
-- [`implementations/node-sdk+web-sdk/src/index.ejs`](../../implementations/node-sdk+web-sdk/src/index.ejs):
-  browser-side follow-up tracking and entry resolution
+- [Node SSR Only](../../implementations/node-sdk/README.md): server-only SSR flow with `page()`,
+  `identify()`, `resolveOptimizedEntry()`, `getMergeTagValue()`, and rendered output that consumes
+  resolved entries.
+- [Node SSR + Web SDK Vanilla](../../implementations/node-sdk+web-sdk/README.md): cookie sharing
+  with `ANONYMOUS_ID_COOKIE` for Node and Web SDK continuity, plus browser-side follow-up tracking
+  and entry resolution.
diff --git a/documentation/guides/integrating-the-react-native-sdk-in-a-react-native-app.md b/documentation/guides/integrating-the-react-native-sdk-in-a-react-native-app.md
index 55895bf3..6a372d10 100644
--- a/documentation/guides/integrating-the-react-native-sdk-in-a-react-native-app.md
+++ b/documentation/guides/integrating-the-react-native-sdk-in-a-react-native-app.md
@@ -212,10 +212,9 @@ you don't need a runtime consent prompt, set `defaults.consent: true` so events
 </OptimizationRoot>
 ```
 
-The default is applied once at startup; user input later takes precedence. The in-tree reference
-implementation shows an equivalent trusted-context shortcut in
-[`App.tsx`](../../implementations/react-native-sdk/App.tsx) by calling `sdk.consent(true)` after the
-provider initializes.
+The default is applied once at startup; user input later takes precedence. The
+[React Native reference implementation](../../implementations/react-native-sdk/README.md) shows an
+equivalent trusted-context shortcut by calling `sdk.consent(true)` after the provider initializes.
 
 ### Gating consent on a banner
 
@@ -297,8 +296,8 @@ Use `include: 10` on Contentful's Delivery API call:
 const cta = await contentfulClient.getEntry(CTA_ENTRY_ID, { include: 10 })
 ```
 
-The in-tree reference implementation centralizes this pattern in
-[`utils/sdkHelpers.ts`](../../implementations/react-native-sdk/utils/sdkHelpers.ts).
+The [React Native reference implementation](../../implementations/react-native-sdk/README.md)
+centralizes this Contentful fetching pattern in its application helper layer.
 
 ### Render the variant with a render prop
 
@@ -333,10 +332,9 @@ render prop:
 </OptimizedEntry>
 ```
 
-This is the same tracking pattern used by
-[`sections/ContentEntry.tsx`](../../implementations/react-native-sdk/sections/ContentEntry.tsx):
-entries are wrapped so the SDK can track views/taps, while non-optimized content passes through
-unchanged.
+This is the same tracking pattern used by the
+[React Native reference implementation](../../implementations/react-native-sdk/README.md): entries
+are wrapped so the SDK can track views/taps, while non-optimized content passes through unchanged.
 
 ## 4. Interaction tracking with OptimizedEntry
 
@@ -428,8 +426,8 @@ function BlogPostDetailScreen({ post }) {
 }
 ```
 
-The in-tree reference implementation wraps its entry list in `OptimizationScrollProvider` in
-[`App.tsx`](../../implementations/react-native-sdk/App.tsx) before rendering optimized entries.
+The [React Native reference implementation](../../implementations/react-native-sdk/README.md) wraps
+its entry list in `OptimizationScrollProvider` before rendering optimized entries.
 
 Without `OptimizationScrollProvider`, the SDK assumes scroll position is always `0` and the viewport
 equals the screen. That's fine for a single full-screen component, but for content that appears
@@ -473,10 +471,10 @@ export default function App() {
 }
 ```
 
-The in-tree reference implementation exercises this adapter in
-[`screens/NavigationTestScreen.tsx`](../../implementations/react-native-sdk/screens/NavigationTestScreen.tsx).
-The render-prop pattern means the wrapper does not depend on `@react-navigation/native` directly —
-navigation props are passed through to your real `NavigationContainer`.
+The [React Native reference implementation](../../implementations/react-native-sdk/README.md)
+exercises this adapter in its navigation test flow. The render-prop pattern means the wrapper does
+not depend on `@react-navigation/native` directly — navigation props are passed through to your real
+`NavigationContainer`.
 
 Available props:
 
@@ -694,14 +692,7 @@ function DebugBadge() {
 
 ## Reference implementations to compare against
 
-- [`implementations/react-native-sdk`](../../implementations/react-native-sdk/README.md): the
-  in-tree React Native reference implementation that is built and tested alongside the SDK itself
-- [`implementations/react-native-sdk/App.tsx`](../../implementations/react-native-sdk/App.tsx):
-  provider setup, consent bootstrap, page emission, entry rendering, scroll provider usage, and
-  navigation/live-updates test entry points
-- [`implementations/react-native-sdk/sections/ContentEntry.tsx`](../../implementations/react-native-sdk/sections/ContentEntry.tsx):
-  `OptimizedEntry` rendering plus tap tracking
-- [`implementations/react-native-sdk/screens/NavigationTestScreen.tsx`](../../implementations/react-native-sdk/screens/NavigationTestScreen.tsx):
-  `OptimizationNavigationContainer` usage and screen-event assertions
-- [`implementations/react-native-sdk/screens/LiveUpdatesTestScreen.tsx`](../../implementations/react-native-sdk/screens/LiveUpdatesTestScreen.tsx):
-  live-updates behavior and preview-panel visibility simulation
+- [React Native reference implementation](../../implementations/react-native-sdk/README.md): the
+  in-tree React Native app that is built and tested alongside the SDK itself. It demonstrates
+  provider setup, consent bootstrap, page emission, entry rendering, scroll provider usage,
+  `OptimizedEntry` rendering plus tap tracking, navigation tracking, and live-updates behavior.
diff --git a/documentation/guides/integrating-the-react-web-sdk-in-a-react-app.md b/documentation/guides/integrating-the-react-web-sdk-in-a-react-app.md
index 3911a949..de765a84 100644
--- a/documentation/guides/integrating-the-react-web-sdk-in-a-react-app.md
+++ b/documentation/guides/integrating-the-react-web-sdk-in-a-react-app.md
@@ -445,6 +445,9 @@ function CustomEntry({ baselineEntry }) {
 `OptimizedEntry` emits data attributes on its wrapper element that the Web SDK uses for automatic
 entry interaction tracking (views, clicks, and hovers).
 
+For the lower-level runtime mechanics behind those attributes and the Web SDK detectors, see
+[Interaction tracking in Web SDKs](../concepts/interaction-tracking-in-web-sdks.md).
+
 ### Automatic tracking via OptimizedEntry
 
 When resolved content renders, the wrapper element receives:
@@ -586,8 +589,9 @@ export default function App({ Component, pageProps }: AppProps) {
 }
 ```
 
-Mount once in `pages/_app.tsx`. The adapter waits for `router.isReady`, emits on the first eligible
-render and on route changes, and suppresses duplicate consecutive `router.asPath` values.
+Mount once in the Pages Router application root. The adapter waits for `router.isReady`, emits on
+the first eligible render and on route changes, and suppresses duplicate consecutive `router.asPath`
+values.
 
 ### Next.js app router
 
@@ -607,9 +611,8 @@ export function Providers({ children }: { children: React.ReactNode }) {
 }
 ```
 
-Mount in a `'use client'` component inside your App Router provider tree, typically via a
-`providers.tsx` wrapper used by `app/layout.tsx`. Emits on first render and on `pathname + search`
-changes.
+Mount in a `'use client'` component inside your App Router provider tree. Emits on first render and
+on `pathname + search` changes.
 
 ### TanStack router
 
diff --git a/documentation/guides/integrating-the-web-sdk-in-a-web-app.md b/documentation/guides/integrating-the-web-sdk-in-a-web-app.md
index df6f6031..5e62974c 100644
--- a/documentation/guides/integrating-the-web-sdk-in-a-web-app.md
+++ b/documentation/guides/integrating-the-web-sdk-in-a-web-app.md
@@ -448,6 +448,9 @@ falls back to attribute overrides first, then normal automatic behavior.
 
 ### Browser tracking mechanics
 
+For a deeper explanation of the runtime model, see
+[Interaction tracking in Web SDKs](../concepts/interaction-tracking-in-web-sdks.md).
+
 Interaction observers are passive with respect to host event flow. They do not call
 `event.preventDefault()` or `event.stopPropagation()`.
 
@@ -558,16 +561,14 @@ personalization inputs.
 
 ## Reference implementations to compare against
 
-Use these files when you want working repository examples instead of guide snippets:
-
-- [`implementations/web-sdk/public/index.html`](../../implementations/web-sdk/public/index.html):
-  vanilla browser initialization, consent handling, `page()`, entry resolution, merge tags, and
-  automatic or manual interaction tracking
-- [`implementations/node-sdk+web-sdk/src/index.ejs`](../../implementations/node-sdk+web-sdk/src/index.ejs):
-  browser-side continuation of an SSR flow with the Web SDK
-- [`implementations/node-sdk+web-sdk/src/app.ts`](../../implementations/node-sdk+web-sdk/src/app.ts):
-  shared anonymous cookie persistence for Node and Web SDK continuity
-- [`implementations/web-sdk_react/src/App.tsx`](../../implementations/web-sdk_react/src/App.tsx):
-  SPA-style `page()` emission, consent updates, `identify()`, and `reset()` patterns
-- [`implementations/web-sdk_react/src/sections/ContentEntry.tsx`](../../implementations/web-sdk_react/src/sections/ContentEntry.tsx):
-  resolved-entry rendering plus automatic and manual tracking metadata
+Use these reference implementations when you want working repository examples instead of guide
+snippets:
+
+- [Web Vanilla](../../implementations/web-sdk/README.md): vanilla browser initialization, consent
+  handling, `page()`, entry resolution, merge tags, and automatic or manual interaction tracking.
+- [Node SSR + Web SDK Vanilla](../../implementations/node-sdk+web-sdk/README.md): browser-side
+  continuation of an SSR flow with the Web SDK and shared anonymous cookie persistence for Node and
+  Web SDK continuity.
+- [Web SDK React](../../implementations/web-sdk_react/README.md): SPA-style `page()` emission,
+  consent updates, `identify()`, `reset()` patterns, resolved-entry rendering, and automatic and
+  manual tracking metadata.