diff --git a/context/skills/self-driving/references/2-read-context.md b/context/skills/self-driving/references/2-read-context.md
index e9da8b9a..6b4dcd6a 100644
--- a/context/skills/self-driving/references/2-read-context.md
+++ b/context/skills/self-driving/references/2-read-context.md
@@ -18,7 +18,7 @@ Emit:
 
 {{> mcp-tool-calling}}
 
-Load the local tools via `ToolSearch select:Read,Glob,Grep`. Reach the PostHog tools through the `exec` tool — run `info <tool>` before the first `call` for `scout-project-profile-get`, `query-session-recordings-list`, `surveys-get-all`, and `query-error-tracking-issues-list`.
+Load the local tools via `ToolSearch select:Read,Glob,Grep`. Reach the PostHog tools through the `exec` tool — run `info <tool>` before the first `call` for `scout-project-profile-get`, `query-session-recordings-list`, `surveys-get-all`, `query-error-tracking-issues-list`, and `endpoints-get-all`.
 
 ## Do
 
@@ -30,12 +30,13 @@ Load the local tools via `ToolSearch select:Read,Glob,Grep`. Reach the PostHog t
    - `query-session-recordings-list` — any recording → replay in use
    - `surveys-get-all` — any survey → surveys in use
    - `query-error-tracking-issues-list` — any issue → error tracking in use, even when this repo doesn't instrument it
+   - `endpoints-get-all` — any endpoint → Endpoints in use. Neither the repo nor the profile reports this product, so the probe is the only evidence step 4 can gate on
 
 4. **Light scan for what the report, profile, and server state won't cover.** Targeted lookups only — package manifests, config files, a grep or two. You are answering these questions:
    - **Revenue**: is there a payment SDK (Stripe, Paddle, LemonSqueezy, RevenueCat…) or revenue events?
    - **Surveys**: does the code or profile show PostHog surveys in use?
    - **AI/LLM**: are there `$ai_*` events, an LLM SDK, or LLM analytics in the profile?
-   - **Logs**: is the PostHog logs product in use (per the profile)?
+   - **Logs**: is the PostHog logs product in use (per the profile)? Step 4 needs the answer.
    - **CSP**: is a Content-Security-Policy with PostHog CSP reporting configured?
    - **Support**: does the team use PostHog support/conversations (per the profile)?
    - **Connected tools**: any hints of an issue tracker (Linear, Jira, GitLab, Gitea, Shortcut), error tracker (Sentry, Rollbar, Bugsnag, Honeybadger, Raygun), support desk (Zendesk, Freshdesk, Front, Gorgias, Kustomer, Dixa, Plain), database performance (pganalyze), security scanner (Snyk, SonarQube, Semgrep, Rapid7), product-feedback / review tool (Featurebase, Frill, Aha, UserVoice, Productboard, Canny, AskNicely, Retently, Appfigures, AppFollow, Judge.me), or search analytics (Google Search Console) — you will still ask in step 5; hints only shape the question, they never authorize enabling.
diff --git a/context/skills/self-driving/references/4-sources.md b/context/skills/self-driving/references/4-sources.md
index dc373df8..34666021 100644
--- a/context/skills/self-driving/references/4-sources.md
+++ b/context/skills/self-driving/references/4-sources.md
@@ -35,6 +35,8 @@ Reach the source-config tools through the PostHog `exec` tool — `info` then `c
 | Scout gate | **On by default — never create a row.** The server lets scout findings into the inbox with no config row; a `signals_scout` / `cross_source_issue` row only exists to opt OUT. If you find one with `enabled: false` (an earlier opt-out), flip it back on with `inbox-source-configs-partial-update`; with no row, do nothing and record "on by default" | `signals_scout` / `cross_source_issue` — existing disabled row only |
 | Health checks | **Always** — instrumentation issues (missing events, proxy gaps, outdated SDKs) are always actionable and a good thing for the agent to fix | `health_checks` / `health_issue` |
 | Error tracking | **Enable by default**, even with no current signal — teams adopt error tracking sooner or later, and with no errors there are no findings and no cost. Evidence (report, exception autocapture ON, or error issues from the step-2 probe) only raises confidence; its absence is **not** a reason to skip | **All three rows**: `error_tracking` / `issue_created`, `error_tracking` / `issue_reopened`, `error_tracking` / `issue_spiking` — the product UI treats them as one switch |
+| Logs | **Only when the project uses Logs**, per your step-2 checklist. The pair carries alerts that fire and alerts the server auto-disables, so a project with no logs never produces one | `logs` / `alert_state_change` |
+| Endpoints | **Only when the project has endpoints**, per the step-2 `endpoints-get-all` probe. The pair carries failed executions and breakdown-limit overflows | **Both rows**: `endpoints` / `endpoint_execution_failed` and `endpoints` / `endpoint_breakdown_limit_exceeded` |
 | Support | **Enable by default** — step 3 turned the Conversations product ON, so wire its source. It stays idle until an inbound channel (email / inbox / Slack) is connected, so record that channel connection as a follow-up — but enabling the source now means tickets reach the inbox automatically once a channel exists, with no second setup. Don't gate on profile evidence. | `conversations` / `ticket` |
 
 ## Nothing to create here
@@ -46,7 +48,7 @@ The rest of the pairs have no row for this run to write. Each one's coverage liv
 | `session_replay` / `session_analysis_cluster` | Step 6c's Replay Vision scanners. This pair is **retired** — the session summarization feature behind it is gone, PostHog deleted the existing rows, and the server now skips the pair when it checks whether a team has a working source, so a row written here is a dead switch in the user's inbox. |
 | `replay_vision` | The scanners themselves. Replay Vision is **self-authorizing**: `emits_signals` on each scanner *is* its per-source config, so step 6c's writes are the whole story. |
 | `llm_analytics` | Nowhere — it's internal, with no user-facing responder behind it. |
-| `logs`, plus any `source_type` of `evaluation` or `alert_state_change` | Nowhere yet — no v1 responder. |
+| `source_type` of `evaluation` | Nowhere — no emitter produces this type any more. The taxonomy keeps the value so older signals still resolve to a label. |
 | `github`, `linear`, `zendesk`, `pganalyze`, `jira`, `google_search_console`, … | Step 5, on the user's answer, once each tool's warehouse source exists. |
 
 Record every source decision with its reason — the report needs them.