> For the complete documentation index, see [llms.txt](https://docs.layeronecloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.layeronecloud.com/platform/aegis.md). # LayerOne Aegis (network security) Aegis is the customer-facing network security surface: observed traffic, application usage, open ports and identified services, potential CVE matches, DDoS incidents and alerts. Aegis is the customer-facing network security surface: observed traffic, application usage, open ports and identified services, potential CVE matches, DDoS incidents and alerts. **L1 Network Monitor remains the measurement source** and publishes a bounded projection to this platform over the authenticated Admin API; browser requests read that account-scoped projection and **never receive a monitor credential or access to its operator APIs.** Client section `/client/aegis/` with its own navigation entry (separate from Networking) and a secondary sidebar: **Dashboard** (bandwidth and packet-rate graphs, latest total/inbound/outbound readings, observation freshness and capture coverage, top applications, account attack counts) · **Applications & ports** · **Attack activity** (the paginated account-owned DDoS incident log) · **Alert preferences** · **Settings**. Operator section `/console/aegis/`: **Security overview** (Overview, Attack activity) and **Management** (Applications & ports, Alert delivery). All four routes are **GET-only, administrators only, Support default-denied.** Overview shows recorded incident and unresolved totals, eligible public-IP allocations, failed email deliveries and the ten most recent incidents — **stored-record summaries, not a claim of live protection or complete scan coverage.** ## 10.1 Telemetry The dashboard opens on a **fifteen-minute live** bandwidth and packet-rate view using ten-second observation buckets and five-second browser refreshes; last hour, six hours and 24 hours are available as **minute** history. Bandwidth shows inbound, outbound and combined total; packet rate shows total PPS. Expected baseline and observed DDoS series provide context. **Live observations are a separate, short-lived projection, not interpolated minute history.** The monitor uses exact-IP host WAN counters from its live capture windows, divides by the **actual measured duration**, and deduplicates overlapping captures before producing buckets. **Source windows that straddle an assignment boundary are excluded.** A recently completed bucket may supply the headline for up to 30 seconds after its end, and **delivery retries never refresh that observation time**; older samples stay on the graph but the headline becomes unavailable. **Missing buckets remain gaps.** Partial-window coverage cannot be displayed as full coverage. Live expected/DDoS values stay unavailable when exact comparable evidence is missing — the current live exporter supplies neither overlay, so live legends and tooltips identify those series as **Historical only** with guidance to select a history range. **No minute readings are copied into ten-second live samples.** Application attribution stays at completed-minute resolution, and **application inventory and totals always use the last 24 hours**, including beside live, one-hour and six-hour charts. **Live interface/MAC application totals are not substituted for exact endpoint facts.** This view measures **observed traffic, not billed transfer**, and does not expose shared infrastructure counters. **Traffic availability is determined only by observations in the selected graph range.** Retained application history cannot make an empty live graph appear partially available; applications remain readable independently while the traffic status explicitly reports unavailable, and **a measured zero rate is a valid observation.** **Application lifetime.** An application is retained for 24 hours after positive observed **outbound** bytes on the same currently owned public-IP allocation, application name, transport and application server port. Replies to inbound connections qualify — the application need not initiate. New outbound traffic restarts the lifetime; at exactly 24 hours without outbound it expires, using the **original completed-minute timestamp** rather than receipt, retry or scan time. **Inbound traffic cannot extend it**, and another IP, port or transport cannot renew it. Eligibility is evaluated **before** names are combined or ranked, so inbound-only continuation minutes retain their measured bytes only for an eligible identity. Legacy name-only samples and identified samples with an unknown port remain separate unknown identities and **cannot qualify a concrete port.** **Top applications** previews the twelve busiest by observed inbound + outbound bytes for the selected devices over the last 24 hours, independent of chart ranges, with a native **Show more** disclosure for the remaining named applications. The local icon catalog covers networking, gaming, messaging, streaming, databases, cloud services and developer tools; known brands use bundled Font Awesome logos and protocols use Lucide icons (a lock for HTTPS), with a generic icon for unknown names, and case/space/punctuation variants plus transport-qualified labels (`TLS.Discord`, `QUIC.YouTube`) resolve to the same icon. **Labels remain the source's observed names — the icon catalog does not add detections or invent traffic.** Scan-only, inbound-only, zero-traffic entries and the synthetic *Other observed applications* aggregate are excluded from the ranking. **Device scope.** **All devices** is the default; a customer can select one of their own servers, which includes its current primary and assigned floating public IPs. Traffic, packet rates, baselines, DDoS series and application breakdowns use the selected scope, while **attack counts, incident history and alert preferences are explicitly account-wide.** Removed or foreign device IDs return the same **404** rather than silently falling back to account totals. Changing the filter clears the previous scope immediately and discards late responses. **Neither device names nor telemetry from another account are sent to the browser.** **Measurement honesty.** Client bandwidth and PPS come from exact-IP packet observations; **interface counters describe shared infrastructure and are not used as customer totals.** The current sensor records total packets, so **directional PPS is not inferred.** The monitor selects one observation per address and minute to avoid counting mirrored captures twice (conservative when traffic uses multiple paths). Application attribution requires exact local endpoint evidence and exports catalog names and byte counts **without raw connection endpoints or domains.** Version 1 requires **globally routable public IPs** — private, shared, link-local and other non-global addresses are excluded at the source, because an address alone cannot distinguish overlapping tenant networks. **The expected baseline** uses earlier non-attack observations for the same owned address. **It is an estimate, not a mitigation guarantee or the detector's configured trigger threshold.** DDoS traffic comes only from incidents for that exact address — shared-interface, subnet and site-wide totals are excluded. Unknown baselines, absent measurements and stale sensors stay **unavailable**; the graph frame remains visible and **missing intervals are gaps, not invented zero readings.** **Normal DDoS zero readings require full detector coverage and a recorded protected-target configuration covering that address for the complete sample minute**; legacy observations without that history stay unknown, and a partial set of IP observations can contribute explicitly partial measured traffic while an account-wide baseline or DDoS rate stays unavailable if any eligible address lacks that measurement. Display: existing console tokens and components, compact numeric readouts, labelled units, rounded chart scale intervals and separate observation-quality metadata. Bandwidth axes and readouts use **decimal Mbps** (1 Mbps = 1,000,000 bits/s) to two decimal places; packet rate likewise. Tiny rates such as 0.00000041 Mbps display as 0.00 Mbps — **rounding affects only displayed values, preserving the underlying observations.** Detected DDoS uses a solid red line distinct from the dashed amber outbound series; bandwidth precedes packet rate; hovering or touching either graph shows a crosshair and timestamped sample rates. **Missing intervals show no observation instead of borrowing a distant sample.** ## 10.2 Ports, applications and potential vulnerabilities **Applications & ports** opens with a list of instances (name, public IPs, open-port count, application count); instances with unignored findings also show a yellow flag and their active service/CVE count. Selecting an instance opens its ports and applications in the same workspace; its application window is fixed to the last 24 hours. Port tiles show port/transport, identified service, public IP, concise stale/retained warnings and eligible vulnerability counts; opening a port reveals product/version and original observation time. **Scan coverage lives in a closed-by-default Scan details disclosure**, with partial/failed/stale/incomplete warnings in its summary. Selecting an instance or application is **local navigation and does not enqueue scans or change observations.** **Open-port observations** come from hourly top-100 TCP/UDP scans and daily full scans **on the hypervisor**, using its WAN IP-owning interface. The monitor takes candidates from its existing cached device inventory, restricted to **running VMs assigned to that specific hypervisor** — no additional inventory calls, and passively observed peers or the hypervisor itself are never candidates. It sends exact current public-IP allocation results through the existing integration; **the portal never scans a customer host or fetches monitor credentials in a browser.** The scan vantage point is the hypervisor WAN interface, so **reachability can differ from other networks.** Scan freshness is independent of the selected traffic range. A service probe with **confidence ≥ 5/10** can display the identified application and product/version (without repeating a score in every row); unidentified services, lower-confidence probes and port-number hints use **Port N** without claiming detection. **Raw scan banners, scripts, domains and extra service information are not accepted fields.** Port tiles have **no byte totals** — a selected application's detail explains that its totals are per application, not per port or billed transfer, and **name totals are never assigned to a scan-port row.** Scan-only evidence cannot create application traffic, and **missing measurements are not zero traffic.** Full scans request ports 1–65535 for both protocols; common scans request Nmap's top 100 per protocol. **Successful scan execution is distinguished from port-state certainty:** a finished sweep with filtered or silent ports is **Complete with `coverage_uncertain: true`**, not a failed job; **Partial** means checks or output were incomplete (interruption, failed identification, malformed output, truncation); unknown software versions remain unknown and do not alone fail a scan. **Legacy Partial rows are not reclassified**, because their generic message cannot identify the original cause. **Partial, failed and uncertain-complete attempts retain prior open observations with their original observation time** — only complete full scans without uncertainty may retire older observations, and a common scan never retires a finding outside its coverage or refreshes the last full-scan time. Common observations become **stale after two hours**, full-scan observations **after 27 hours**. At most **4,096** open observations per IP are retained for **seven days**, ranked by original observation time; when a limit omits older evidence a **persistent truncation flag and partial state remain visible** until a complete scan replaces the list, and **omission does not claim that a port closed.** Every retained port is accessible in the client grid, including beyond the first 100. **Potential Vulnerabilities.** Applications & ports shows advisories from the Monitor's centrally refreshed NIST NVD cache. **Only services with actual, confident current matches show details** (detected version, CVE, severity/score, description, NVD link) with an **Ignore/Restore** action. New CVEs still appear after another finding is ignored; a changed version or allocation assignment **does not inherit the previous ignore**. Counts and detail come from current, owner-validated scan evidence, independently of the traffic time selector. **These are potential matches from version evidence, not verified exploitation or installed patch state.** Vendor backports can fix an older advertised version. Unidentified/unsupported software and ambiguous versions remain **unable to assess** and create no disclosures or port warning labels; pending, unavailable, stale and empty assessments likewise produce no badges. Reads recheck the current probed identity (confidence 5–10), exact version, the Monitor's assessed software fingerprint, the current port observation, and **a check less than 24 hours old.** Account counts, instance badges and Ignore/Restore share the same eligibility rule, so **a hidden stale finding cannot be acted on through an old browser action.** Snapshots and saved ignore records are not deleted, so a fresh eligible assessment can show the finding again with its ignore intact. The public projection marks eligible details with `displayable` and filtered summary counters with `confidence_filtered`; **clients fail closed for older payloads without those markers.** Platform-dependent matches and capped responses disclose incomplete coverage alongside eligible findings, failed scans and NVD failures retain original evidence times, and **hidden or absent findings never confirm that a vulnerability was fixed or that a service is secure.** **Scan now.** Each running device with current public IPs has **Request port scan now** (`POST /client/aegis/devices//scan/`, empty JSON, CSRF-protected). Pending clicks reuse the same request IDs; new requests have a **ten-minute per-device cooldown**; a device request includes its current primary and floating public IPs, up to 32 IPs, with at most **100 queued IP requests per account**. Ownership and running state are rechecked **inside the enqueue transaction**. Requests use **two dedicated full-scan slots**, independent of the eight daily full-scan and two hourly common-port slots, and **active scans of the same IP are not interrupted or overlapped.** The portal persists the queue and the Monitor claims its immutable request IDs. **A claim remains Queued until the sensor reports a successful scanner start**, then the job becomes Running; start observations and 30-second heartbeats are durably retried, and **missing heartbeats show overdue contact, not a fabricated failure or permission to scan twice.** A request must start within 24 hours, but a valid long-running scan can complete later — the client shows expired after 24 hours **only when a start has not been confirmed**, and running jobs may complete after that deadline while staying protected from duplicate requests and deadline cleanup. **Scheduled scan pools.** The site's daily full-scan start time and time zone are configured in the Monitor (default 22:00 America/New\_York). The server supplies the latest daily boundary in its authenticated scan plan; the sensor records **one attempt per IP per boundary** and catches up after downtime **without replaying every missed day.** Hourly common-port attempts have a separate durable schedule. **Customer requests always select the full profile and cannot be satisfied by a top-100 report with the same UUID.** The sensor has eight daily full-scan slots, two dedicated customer full-scan slots and two hourly common-port slots — at most 12 different active IPs — each with a separate cgroup limited to one logical CPU, 384 MiB memory high / 512 MiB max, no swap and 64 tasks, with the supervisor on its own budget. Host-wide pressure checks defer work. **Full scans can run past the configured start hour: the time is a daily release time, not a cutoff or a promised completion time.** Reserved customer slots do not preempt an existing scan or pending result for the same IP. The latest full result is stored **separately** from the latest common scan, and manual results retain their own immutable request snapshot, so the portal accepts a delayed full scan **without replacing newer common-scan metadata or port evidence.** **Manual result reconciliation.** A newer hourly observation must not discard a completed manual result before the portal acknowledges it. The portal resolves a matching authorized request even when its result arrives behind a newer scan — **the newer port evidence and its original timestamps remain authoritative.** Different request IDs, changed assignments, conflicting sources and starts outside the request window **cannot resolve a request.** **Operator recovery of a stranded manual request.** Jobs → **Aegis Scans Manual** offers super admins **Close as result unavailable and retry** for claimed Queued/Expired manual requests with no recorded scanner execution or results. Clients, Support and automatic jobs cannot use it. GET/HEAD only display evidence; the CSRF-protected POST requires the original UUID, a concise verification reason, and a five-minute actor/state-bound confirmation. **Immediately before submitting, the operator must check the exact UUID on the sensor and Monitor** — no active scanner, pending result or lifecycle observation, no retained Monitor result, and the sensor's deduplication record intact. **The portal cannot remotely establish these facts**, and missing heartbeats or an empty local result field alone do not authorize a retry. The transaction rechecks account/VM/cluster/public-IP assignment, running VM, account preference, original authorized project/site and absence of local execution evidence, and retains the ten-minute cooldown and 100-pending limit. The old UUID becomes **Result unavailable** with an operator closure time, actor and reason — **not a fabricated scan completion or failure** — and one fresh manual full-scan UUID is linked to it, staying Queued until its source claims it and supplies actual start evidence. Replayed confirmations return the same replacement, and audit records contain both UUIDs and the verification summary. **Late lifecycle/result reports for the closed UUID cannot reopen it, update the IP projection or complete its replacement.** **Jobs → Aegis Scans Manual / Automatic** are searchable 50-row pages of persisted full-scan attempts with separate state filters and counts. Automatic history includes queued, running and terminal daily full jobs, **not hourly top-100 projections.** Each row preserves UUID, account, instance, address, queued/scheduled time, claim, observed scanner start, latest heartbeat and outcome. Reported attempt time is **labelled separately** when an older sensor supplied no actual start acknowledgment. **Queued does not establish execution**, and stale Running stays Running with an overdue-contact note. GETs never enqueue or update jobs. **Historical automatic queues cannot be reconstructed from latest-IP reports and are not invented.** **Logs → Aegis** (`/console/audit/aegis/`) records failed port-scan reports in a separate read-only history: failure time, original service and account labels, IP, and a **safe** failure reason, plus scan UUID, start and receipt times, protocol counts, source site, allocation and API project IDs. Search covers labels, IP, reason and exact UUID; 50 per page, newest first. **Failures are recorded only after the receiver validates allocation ownership and the source.** Repeated delivery does not duplicate or rewrite an entry; late valid failed attempts can enter history without replacing a newer scan; later successful scans and deletion of the original service, allocation, account or API project **do not erase these snapshots.** The receiver preserves the sensor's **recognized fixed** diagnostic messages and maps common timeout/permission/reachability diagnostics to fixed descriptions; **raw diagnostic text, paths, banners and credentials are never retained**, and missing or unrecognized diagnostics explicitly report that no recognized safe reason was supplied. Clients and Support cannot access it. ## 10.3 DDoS incidents and alerts `POST /api/admin/v1/ddos/incidents/` accepts the Admin API bearer token when the project has the **LayerOne Aegis updates** permission (off by default, no new key required). The contract carries `contract_version: 1`, `source_site_id`, mapped `cluster_ids`, and at most **100 incidents per request** (1 MiB body). Each incident carries its UUID, exact `target_ip`, `state` (`active`/`stale`/ `resolved`), attack type, severity, source timestamps and current/peak bit and packet rates. The receiver acknowledges by UUID; the monitor keeps durable acknowledgments, retries failures and scans pending work in bounded pages under a renewable database lease. **Customer and service identifiers never come from the sender.** The platform matches the destination against current primary and floating public-IP assignments in the supplied clusters; **ambiguous or unassigned addresses produce `unmatched`.** History stays with the original account, and reassignment stops active alerts for that account **without exposing the new owner's VM name.** Deleted VMs and IP addresses can leave historical records without blocking VM deletion. **Observation timestamps remain authoritative: retries do not refresh stale data.** The monitor marks observations stale after its 90-second sensor window, and the platform ages active records after ten minutes without fresh observations. **Only an explicit resolution produces a resolved status.** Older updates cannot restore an attack; a strictly newer **resumed** attack advances a notification generation so its start and end can each notify once. Customer preferences at `/client/aegis/alerts/`: **in-app alerts on by default, email alerts opt-in**, with a minimum severity and whether to receive an email when an attack ends. The Aegis badge and top-bar shield refresh every 30 seconds and after client navigation, and **the activity page remains available when notifications are disabled.** Attack badges and notification emails link to activity; preference email links go directly to the alert settings page. **Alert delivery** (`/console/aegis/alerts/`) shows searchable paginated saved email attempts with delivery status and timestamps. Customer opt-in preferences and the existing delivery/retry workflow remain authoritative. **Opening these pages does not create preferences, scan hosts, enqueue jobs or send notifications.** Attack activity (`/console/aegis/activity/`) is a searchable 50-row incident history whose state filter selects the **source's recorded state**, while displayed status also accounts for observation freshness and changed ownership; an unresolved incident for a reassigned address displays **Awaiting update.** ## 10.4 The customer switch **Aegis → Settings** has an explicit Disable/Enable Aegis button. `DDoSAlertPreference.aegis_enabled` defaults **true**. Disabling hides the customer dashboard/applications/activity views, rejects customer telemetry and finding actions, pauses customer alerts and cancels queued manual requests. **The form explicitly says that network security monitoring and DDoS protection continue** — ingestion and operator monitoring are unaffected, settings and saved alert preferences stay accessible, re-enabling keeps preferences and retained data without resurrecting cancelled requests, and in-flight scans may finish. **Automatic security scanning does not depend on the customer's display preference.** ## 10.5 Integration contracts and ownership Ingest endpoints, all under the Aegis project permission, all advertising their capability and contract version through discovery: | Endpoint | Purpose | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `GET /api/admin/v1/aegis/targets/` | Pages current authorized public-IP allocations by allocation ID (exact address, cluster, account, VM, effective assignment timestamp) | | `POST /api/admin/v1/aegis/telemetry/` | Bounded minute observations with application byte counts | | `POST /api/admin/v1/aegis/live/` | Version-1 live contract: ≤ 90 completed ten-second buckets from the last fifteen minutes, with `observed_seconds` (> 0, ≤ 10) | | `POST /api/admin/v1/aegis/port-scans/` | Scan results (≤ 10 targets, ≤ 4,096 open observations, 1 MiB) | | `GET/POST /api/admin/v1/aegis/scan-jobs/` | Operations-owned scan job intents, claims and progress | | `GET /api/admin/v1/aegis/scan-requests/` | Customer manual requests with an `after_id` cursor | | `POST /api/admin/v1/aegis/vulnerabilities/` | Bounded software assessment projection keyed to an existing scan UUID | **The monitor uses the explicit cluster-to-site mapping before reading any source facts.** Application identity adds paired `transport` and `server_port` fields to each minute entry (port null or 1–65535 for TCP/UDP; other transports require null), unique by name/transport/port, ≤ 20 per minute; identified senders omit synthetic overflow applications and prioritize outbound evidence, and **missing entries remain incomplete evidence, not fabricated zero traffic.** Legacy senders can continue with name-only entries. **Ownership is re-resolved on receipt and on customer reads.** A target must have **one unambiguous current public allocation** and a valid owning VM; unassigned addresses and ambiguous claims **fail closed**. A sample cannot precede the effective assignment boundary, **even by part of a minute.** Changes to an allocation invalidate an earlier assignment snapshot, so **no prior customer's traffic can be imported under a new assignment.** Repeated deliveries are idempotent and **multiple monitor sources cannot inflate a client's totals** by contributing duplicate copies of an address/minute. Starts cannot precede assignment; **older starts or repeated scan IDs do not replace newer evidence or refresh freshness**; assignment changes invalidate all retained observations; and **source conflicts quarantine results** until their ownership binding changes. Receipts are `{contract_version, results: [{id, status}]}` with `accepted`, `unchanged`, `unmatched` or `source_conflict`. Scan-job admission is stricter still: **claims pin the original source before any result exists and remain Queued**; only a claimed job's authenticated, in-window scanner observation can mark it Running; and **replays cannot change its start, rewind a heartbeat, steal the claim or reopen a terminal outcome.** GET requires `cluster_ids` and `source_site_id`, returns at most 100 immutable intents and a fair cursor, and **claimed and running intents are visible only to their bound project/site.** Once central scheduling is enabled for a site, **transient integration failures do not switch it back to locally generated daily jobs.** Sensor lifecycle observations enter a bounded SQLite outbox **only after actual process spawn**, and **a missing heartbeat never automatically hands an ambiguously running job to another sensor.** Live rows have their own unique allocation/bucket key and bounded retention cleanup through the existing notice-flush schedule, keeping sixteen minutes of samples (a one-minute buffer beyond the view). Client telemetry reads (`?range=1h|6h|24h|live`, optional `device=all` or an owned VM ID) derive ownership from the signed-in account, **cannot select a different account or request infrastructure-wide totals**, and are `no-store`. Application response metadata is independent of graph metadata (`applications_retention_seconds: 86400`, `applications_start`, `applications_end`). **Deployment ordering matters and is versioned per feature:** deploy this platform with its migrations **first**, then the monitor with its migrations, then update installed hypervisor sensors. **Deploying the monitor web service publishes a sensor binary but does not update installed sensors**, and old sensors safely ignore optional fields but cannot expedite scans, report starts, or use managed queues. Monitor supervises its NVD worker by default; **the NVD API key is optional and belongs only on the Monitor.** The inventory integration's success indicator **does not** establish live traffic delivery — the monitor's own `sync_pulsar_aegis_live` tick reports delivered/empty/unmapped/unsupported/ unmatched/conflicting assignments, and missing Redis live observations or a missing Aegis permission are **explicit failures, not minute/interface fallbacks.** A busy site's live history can exceed the monitor's source bounds (four sensors × 1,000 hosts × 30 windows already exceeds the 100,000-row limit); the exporter retains the **newest validated** windows, reports the limitation, and exports unknown coverage rather than discarding all traffic — **omitted hosts remain unavailable.** The old `/client/networking/ddos-protection/` bookmark redirects to the dashboard, and previously rendered POST preference forms remain valid. ## 10.6 Public marketing `/network-security/` is the public page, linked as **LayerOne Aegis** under VPS Servers, from the product footer, from the shield callout on VPS pricing, and from a Features section. The route is reserved from the CMS and included in the sitemap and `llms.txt`. **Copy must stay inside the capabilities above.** Aegis supports **manual intrusion detection through passive visibility** — customers can spot suspicious activity and investigate it — with **no automatic intrusion alerts or blocking.** DDoS notifications and upstream L3/L4 mitigation are **separate** protections. **Open-port observations do not promise vulnerability assessment or a complete installed-software inventory.** The customer guide at `/docs/networking/layerone-aegis/` covers traffic visibility, port scans, potential NVD matches, scanner-source allowlisting and the support-ticket fallback when the scanner address is unavailable, and documents the opt-out accurately: customer views and alerts are disabled while underlying monitoring and DDoS protection continue. **Instance destination IPs are not scanner IPs.** *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.layeronecloud.com/platform/aegis.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.