The vocabulary of evidence-backed network operations

The stage in which REAP recommends, and where approved, executes runbooks with pre-execution validation, confirmation, rollback and an audit trail.

In REAP Recommend-only and approval-gated execution today; per-action autonomy configuration, choosing autonomy by action type and role, is In development. Production auto-remediation is out of scope for every pilot.

The layer that orchestrates REAP’s specialized agents: Troubleshooter, Impact Analyzer, Planner, Posture Analyzer and the device, cloud, Layer-2, routing, security, telemetry and ticketing agents.

In REAP Shown on the architecture diagram; the harness enforces the governance settings an agent runs under.

Network operations in which AI agents plan and carry out multi-step investigations and, under governance, actions, rather than executing predefined scripts or only correlating events.

In REAP The category REAP belongs to. Analysts describe production-grade agentic NetOps software by five requirements: multivendor support, embedded organizational context, multiple autonomy modes, pre-execution validation and transparent reasoning.

Source: Gartner, Market Guide for Agentic NetOps Software (May 2026)

REAP’s line under “From signals to answers.”, written in full as “Agentic Network Assurance. Grounded in Evidence.”: AI agents that verify the network does what its design, business intent and policy require, and show the evidence for every conclusion.

In REAP Network assurance validates that what is configured across the network actually works as intended; agentic means the checking, the reasoning and the next step are done by AI agents, read-only by default and approval-gated when they act; grounded in evidence means every conclusion is traceable to the data behind it.

A deterministic rule that detects a known condition without a model call, so the investigation that follows starts from a confirmed fact.

In REAP In REAP: known conditions are detected by rules; the time to an evidence-backed answer in the investigation that follows is recorded and reported as P50 and P95 in a pilot.

The cross-cutting discipline of controlling what agents may do and producing evidence of what happened: access, approvals, audit, and proof of resilience and control.

In REAP One of the four dimensions of the Network Assurance Self-Assessment. On the platform, Prove is now a step of the loop and governance runs across all four steps.

The separate places where the knowledge that explains a network lives: command references, TAC history, validated designs, topology diagrams, site specifics, CMDB, release notes, debugging tools, runbooks, tickets and alerts.

In REAP REAP reads across the islands; today they are bridged by expert people and hard-coded automation.

A graph of devices, interfaces, paths, sites, services, tickets and documents and the relationships between them, used to relate evidence across sources.

In REAP Part of REAP’s data and intelligence layer; the basis for blast-radius and dependency reasoning.

The stage in which REAP collects and relates the information islands: devices, configurations, telemetry, topology, tickets, change history, runbooks and documentation.

In REAP Collection is read-only by default and brokered through the customer’s PAM where available.

REAP’s operating loop: observe the environment (read-only by default), reason over live evidence, act under governance, and prove the outcome with before-and-after verification and failover tests.

In REAP Every capability on the platform belongs to one of the four steps; governance (autonomy modes, least privilege, approval gates, the audit trail) runs across all of them. Prove became a step in its own right in October 2026; the self-assessment keeps Govern & Prove as its fourth dimension.

The step in which REAP verifies the outcome: a before-and-after verdict on every change, with the evidence behind it, and failover and recovery tested before they are needed.

In REAP Restored is not the same as fixed; completed is not the same as verified. Before-and-after verification on one real change window is a Pilot deliverable today; automated verdicts on every change are In development; failover and posture findings come from Resilience Assurance.

Reasoning Enabled Agentic Platform: the agentic AI platform for network operations, built as the reasoning and assurance layer above the tools an enterprise already runs.

In REAP The company and the product share the name. REAP replaces nothing; it reads from monitoring, ITSM, PAM, on-call and network platforms and writes evidence back into the tickets a team already uses.

The stage in which agents form a hypothesis, gather the next piece of evidence, test it and change course, the way a senior engineer does.

In REAP Produces the Investigation Window and resilience findings, each traceable to its evidence. Change verdicts: a Pilot deliverable on one real change window; automated verdicts on every change are In development.

REAP’s position in the stack: above monitoring, ITSM, PAM, on-call and network platforms, consuming their data and returning explanations with the evidence behind them.

In REAP The phrase that answers “does REAP replace X?”: it does not.

REAP’s conversational interface, which answers “why is this path down”, “what changed”, “what is impacted” and “how do I safely fix this” from topology, configuration, telemetry and history.

In REAP Available today; every answer links to its evidence.

The combination of deterministic rules that detect known conditions and agentic investigation that explains them, including novel incidents.

In REAP The reason REAP reports P50 and P95 separately for known and novel cases, measured in a pilot.

The set of devices, paths and, where dependency context exists, services affected by an incident or a proposed change.

In REAP In REAP: computed from topology; user and service impact where the customer attaches that context. Its accuracy is a diagnosis-quality measure.

The line-by-line difference between two configuration states of a device or service, with timestamps and, where known, the actor.

In REAP Evidence in incidents and the basis of post-change verification (intended versus actual change).

Relating events, metrics, configuration and topology across sources to identify a common cause or dependency.

In REAP In REAP: evidence from separate silos is related inside an investigation and then reasoned about; correlation of third-party alert streams is In development.

Command output, log lines, configuration diffs, telemetry, ticket text or document passages that support or contradict a conclusion.

In REAP Every conclusion in REAP links to its evidence; in a pilot, engineers score whether at least 90% of conclusions are traceable.

The property that every conclusion can be followed back to the exact evidence that supports it, in one click.

In REAP A scorecard measure (diagnosis quality); the first standard on the “How REAP reasons” page.

A candidate explanation an agent forms from what it knows, then tests by gathering the next piece of evidence.

In REAP In REAP: each conclusion is shown with the evidence behind it; a visible log of hypotheses tested and rejected is In development.

REAP’s primary output for an incident: what changed, why it broke, what is affected, the next best action, and the evidence behind each.

In REAP Written into the ServiceNow (opens in a new tab) or Jira (opens in a new tab) record; the artifact engineers arrive to instead of six tools.

The single most useful step REAP recommends next (a diagnostic command, a rollback, a runbook) with the reason and the risk.

In REAP When evidence is insufficient, the next best action is another diagnostic step, not a guess.

A customer’s own runbooks, design documents, naming conventions, tickets and change records, used to inform investigations alongside device state.

In REAP One of the five analyst requirements; in REAP, ingested from the documents you provide and from the ITSM (Confluence (opens in a new tab), SharePoint (opens in a new tab) and NetBox (opens in a new tab): On request).

Source: Gartner, Market Guide for Agentic NetOps Software (May 2026)

A technique in which a model’s answer is grounded in documents retrieved at query time rather than in training data alone.

In REAP REAP’s RAG ingestion service brings runbooks, design documents and vendor documentation into investigations as citable context.

The underlying condition whose correction prevents the incident from recurring, as distinct from the symptom that was restored.

In REAP REAP’s output is an evidence-backed root cause, with time to answer reported as P50 and P95 in a pilot; “restored” without a root cause is the “restored ≠ fixed” gap.

The structured determination of why an incident happened, with evidence, usually written into a problem record.

In REAP REAP produces the RCA narrative and evidence links; pilots measure RCA documentation hours saved.

Reasoning that shows its steps, its evidence and its uncertainty rather than only its answer.

In REAP One of the five analyst requirements for production-grade agentic NetOps software.

Source: Gartner, Market Guide for Agentic NetOps Software (May 2026)

REAP’s rule that when the evidence is insufficient it says so and proposes the next diagnostic step.

In REAP Confident guessing is treated as a failure mode; engineers score conclusions they accept.

The first question REAP answers in any investigation: which configuration, state or environment change preceded the symptom, made by whom or what, and when.

In REAP Configuration history and change records are first-class evidence because most outages are explained by a change nobody connected to the symptom.

Pilot artifact (week 4): runbooks live under approval, one real change window compared before and after with its outcome, and the count of unapproved actions (target zero).

In REAP Measures automation and change verification.

Whether the alternate path can carry the traffic that would fail over to it, measured against observed load rather than nominal bandwidth.

In REAP A resilience finding pattern: failover would succeed and then congest. In REAP: In development; a pilot finding today where interface telemetry is available.

The door that answers “how do we know the change worked?”: pre-execution impact analysis and before-and-after verification, with the outcome and the evidence written to the change record, for changes made anywhere, not only those REAP runs.

In REAP In REAP today: pre-execution change impact analysis is Available; before-and-after verification of one real change window is a Pilot deliverable; an automated outcome on every change is In development.

REAP’s conclusion on a change window: Verified, Degraded, Rolled back, Inconclusive or Blocked, with the pre-change baseline, the diff, the postchecks and the evidence. “Completed” is a workflow state, not an outcome.

In REAP In a pilot today: one real change window compared before and after, with the outcome and evidence recorded in the change ticket (week 4); automated verdicts on every change are In development.

The principle that a change marked successful because nobody complained is a risk that has not surfaced yet.

In REAP The basis of Change Assurance; a change is verified when pre- and post-state have been compared against intent. The second of REAP’s three sentences.

Divergence of a device’s configuration from its golden template, its peers or its last approved state.

In REAP In REAP: running-versus-startup drift and changes against configuration history are flagged on collection; drift against golden templates where you supply them.

The principle that a device matching its intended configuration can still violate the policy it is meant to enforce, and that redundancy which has never been tested is not redundancy.

In REAP The third of REAP’s three sentences, the basis of Resilience Assurance’s posture and compliance findings: drift against golden configurations, standby pairs out of sync, backup paths that were never proven, policy paths that should not exist. Supporting line: uncover operational risks.

Vulnerability exposure prioritized by the features actually in use, the device’s position in the topology and what sits behind it, not by version match alone.

In REAP Resilience Assurance ranks which CVEs matter here and why.

A generated set of configuration, segmentation and topology evidence for an audit scope (for example PCI segmentation), produced from live state.

In REAP In development; intended to replace screenshots gathered by hand over weeks. Where audit scope is in a pilot today, evidence for agreed controls is produced from configuration and topology findings.

The proven ability of a redundant design to carry production load when its primary fails, as opposed to redundancy that is assumed.

In REAP In REAP: In development; delivered today as pilot findings where interface telemetry is available.

Pilot artifact (week 3): resilience, drift, exposure and posture findings reviewed with the customer’s architect.

In REAP Formally the Resilience & Posture Findings Report; measures prevention.

The approved reference configuration for a device role, against which drift is measured.

In REAP In REAP: supplied by the customer; derivation from the estate is In development. Deviations become findings with severity.

The door that answers “why is this path down, what changed and what is affected?” with evidence, on replayed incidents and live ones.

In REAP Outputs: the Investigation Window, time to answer measured, tier 1 that resolves.

Pilot artifact (week 2): results of replaying historical incidents with known root cause, scored by the customer’s engineers.

In REAP Measures diagnosis quality and time to answer.

Pilot artifact (week 1): devices discovered, topology accuracy, integrations operational.

In REAP Measures context completeness: ≥95% discovered, ≥90% topology accuracy, ITSM and telemetry live by day 7.

Capturing a pre-change baseline, stating expected effects and the rollback trigger, diffing what changed, and running immediate and delayed postchecks on reachability, adjacencies and redundancy.

In REAP Applies to changes REAP did not execute: CAB-approved, vendor and emergency changes. Today a Pilot deliverable on one real change window; automated state packs and delayed postchecks are In development.

The current state of redundancy, security configuration, architecture quality and vulnerability exposure across the estate.

In REAP Reported in the Resilience & Posture Findings Report (pilot week 3).

Evaluation of a proposed change against redundancy, reachability, security policy, CVEs and application dependencies before it runs.

In REAP Available in REAP: a proposed change is assessed against topology, reachability, security policy and known CVEs using state snapshots and path tracing; application-dependency impact where that context is attached.

The door that answers “will failover actually work?”: standby health, backup-path capacity, configuration drift and contextual CVE (opens in a new tab) exposure checked with evidence.

In REAP In REAP today: active/standby sync, running/startup drift and contextual CVE (opens in a new tab) exposure are Available as posture findings; backup-path capacity and continuous failover-readiness proof are In development (delivered as pilot findings where interface telemetry exists).

A previously unknown material risk identified by REAP, carrying severity, evidence and a recommended fix, confirmed by the customer’s architect.

In REAP Pilots target at least three confirmed findings (Prevention measure).

The principle that an incident closed when service came back, without a verified root cause, will recur.

In REAP The first of REAP’s three sentences (with Completed ≠ Verified and Configured ≠ Compliant); the “restored ≠ fixed · completed ≠ verified · configured ≠ compliant” index in the self-assessment measures the exposure.

Whether the standby member of an HA pair or a backup path is actually ready to take load: synchronized, reachable and with capacity.

In REAP In REAP: active/standby sync and reachability are checked by posture rules today; capacity checks are pilot findings. The classic finding is a standby that stopped synchronizing.

The three outcomes an engagement starts through: Incident Reasoning, Change Assurance and Resilience Assurance, each with its sentence: Restored ≠ Fixed, Completed ≠ Verified, Configured ≠ Compliant.

In REAP Every proof of value opens one door on one production domain and expands only when the customer pulls.

A required human confirmation before an action executes, recorded with the approver, the time and the evidence presented.

In REAP Every remediation runbook in a pilot runs under approval; unapproved actions are counted (target zero).

The exportable record of every query, conclusion, approval and action REAP performed, with actor, time and evidence.

In REAP A platform service across all deployment models; the basis of “an audit trail auditors can read”.

The selectable levels at which an agent may act: recommend only; approve then act; act and notify, each configured per action type and per role.

In REAP In REAP: recommend-only and approval-gated execution today; per-action autonomy configuration is In development. One of the five analyst requirements.

Source: Gartner, Market Guide for Agentic NetOps Software (May 2026)

A constraint an agent cannot cross regardless of instruction: blast-radius limits, forbidden commands, protected devices, mandatory approvals.

In REAP Enforced by the agent harness, not by the model’s judgment.

An operating design in which a person approves consequential actions and can stop, redirect or override an agent at any point.

In REAP REAP’s default: every write runs inside an approved runbook behind a confirmation. Per-action autonomy configuration is In development.

Granting only the access an actor needs for its task: for REAP, read-only device access for reasoning and scoped write access only for approved runbooks.

In REAP Applies to REAP’s own staff access as well (quarterly reviews, phishing-resistant MFA).

A runbook authored in plain language from an existing SOP rather than in code, so tier-1 and tier-2 teams can run consistent steps.

In REAP Turns escalations into resolutions; measured as human effort and tier-1 resolution.

Obtaining device credentials at time of use from the customer’s privileged access management system rather than storing them in REAP.

In REAP Available with CyberArk (opens in a new tab) where the customer runs it; HashiCorp Vault (opens in a new tab): Planned, not available today. Any credential is revocable by the customer at any time.

Checks performed before any action runs: redundancy, reachability, security policy and dependencies, with the reasons shown and blast-radius limits enforced.

In REAP One of the five analyst requirements; syntax checking alone does not qualify. In REAP: proposed changes are assessed before execution against topology, reachability, security policy and known CVEs, and runbook steps run behind a confirmation.

Source: Gartner, Market Guide for Agentic NetOps Software (May 2026)

REAP’s starting posture: discovery, telemetry and reasoning use least-privilege, read-only credentials; write access exists only for approved runbooks.

In REAP Stated in the Trust Center and in every pilot scope.

Assigning permissions in REAP by role (who may view, approve or execute) mapped from the customer’s identity provider.

In REAP A platform service; SSO via SAML/OIDC with Okta (opens in a new tab) or Microsoft Entra ID (opens in a new tab).

Restoring a device or service to its verified pre-change state when a change or action produces an unintended result.

In REAP In REAP: reverse steps are authored into runbooks where the change is reversible; automatic rollback on breached postchecks is In development.

A procedure compiled from an approved standard operating procedure into steps REAP can guide or execute, with guardrails, approvals, reverse steps where the change is reversible, and audit.

In REAP Diagnostic (read-only) runbooks are Available; approval-gated remediation runbooks are a Pilot deliverable (two or three per pilot).

An environment with no network path to the internet; software and model updates arrive through controlled transfer.

In REAP In REAP: on-premises deployment is By arrangement; air-gapped operation (local models, offline update packages) is scoped per customer and not yet a standard offering.

A list of the specific addresses, hostnames or accounts that are permitted; everything else is refused.

In REAP The network requirements say what to allow-list: the REAP Cloud endpoints the connector reaches outbound (confirmed with engineering at scoping), and the connector’s own address on device VTY lines and in your PAM.

Agent and proxy virtual machines behind a load-balanced virtual IP inside the customer network that collect configurations (pull), poll metrics (CLI, SNMP) and receive telemetry (syslog, SNMP traps, gNMI (opens in a new tab) subscriptions).

In REAP Connection direction, ports and encryption are documented in the security packet.

REAP deployed inside the customer’s own cloud account so data stays in the customer’s cloud and uses its services and integrations.

In REAP In REAP: By arrangement; scoped per pilot.

REAP deployed in the customer’s data center, with the customer operating the infrastructure.

In REAP By arrangement; scoped per customer. Air-gapped operation is not yet a standard offering.

The kinds of data REAP collects: device configurations, command output, topology, telemetry, ticket metadata, and flow records (NetFlow or IPFIX) where you configure them. It does not inspect traffic payloads and does not capture traffic continuously; on-demand packet captures run only when you ask, are kept with that investigation and follow the retention terms. No clinical or cardholder data by design.

In REAP Listed in the Trust Center; retention is configurable and deletion on request at the end of an evaluation.

Where data is stored and processed: a REAP region, the customer’s cloud account, or the customer’s data center.

In REAP Chosen through the deployment model.

The three ways to run REAP: SaaS in REAP Cloud, Customer Cloud (your AWS (opens in a new tab), Azure (opens in a new tab) or GCP (opens in a new tab) account) and Customer On-Prem (your data center).

In REAP SaaS is Available today; Customer Cloud and Customer On-Prem are By arrangement, and air-gapped operation is confirmed per customer. The connector cluster inside the customer network is common to all three.

gRPC Network Management Interface: a streaming telemetry and configuration protocol supported by modern network operating systems.

In REAP One of REAP’s native ingestion paths alongside syslog, SNMP and CLI. REAP uses gNMI (opens in a new tab) for telemetry subscription, not for configuration.

The systems REAP reads from and writes to: ITSM (ServiceNow (opens in a new tab), Jira (opens in a new tab), ManageEngine), PAM (CyberArk (opens in a new tab)), collaboration (Slack (opens in a new tab), Teams), identity (Okta (opens in a new tab), Entra ID (opens in a new tab)), cloud and controllers, and multi-vendor network estates; NetBox (opens in a new tab) reconciliation On request; HashiCorp Vault (opens in a new tab), SolarWinds (opens in a new tab), Zabbix (opens in a new tab), PagerDuty (opens in a new tab), Opsgenie (opens in a new tab), Confluence (opens in a new tab) and SharePoint (opens in a new tab) are Planned, not available today.

In REAP Read-only by default; findings and evidence links written back to the ticket. REAP collects its own telemetry today, including flow records where you configure them; incidents your monitoring raises reach REAP through ServiceNow (opens in a new tab) or Jira (opens in a new tab). See the integrations page for each status.

Where the language models an AI product uses are served: vendor-managed endpoints, the customer’s own endpoint, or on-premises.

In REAP In REAP: REAP-managed endpoints today; the current options and the model-training policy are stated in writing in the security packet and the order form.

The written statement of whether and how customer data may be used to train or fine-tune models.

In REAP Part of the security packet and the customer agreement; asked in every security review.

Serving multiple customers (or an MSP’s customers) from one platform with isolation of data, access and configuration per tenant.

In REAP A platform service in REAP Cloud and the basis of the partner program; per-operator customer scoping for MSPs is In development.

A non-person account created for a system, with the narrowest role that does its job: read-only on devices and controllers, write scope only where a result must be recorded.

In REAP REAP’s device credentials are read-only, revocable by you at any time and brokered from CyberArk (opens in a new tab) where available; the ITSM integration has write scope only for the work notes and verification results REAP adds.

The multi-tenant SaaS deployment operated by REAP on Amazon Web Services (opens in a new tab) in U.S. regions with multi-availability-zone failover.

In REAP Available today; fastest time to value; tenant isolation enforced at the application layer.

How long REAP keeps each data class before deletion; configurable per customer for telemetry.

In REAP Evaluation data is deleted at the end of a proof of value within the period stated in the statement of work.

Credentials, API keys and tokens that must be stored, rotated and revoked carefully; a leaked secret is a compromised account.

In REAP Secrets belong in your PAM or a cloud key management service; how REAP handles secrets found in collected configurations, and how its own integration credentials are stored and rotated, is stated in the security packet.

Authentication to REAP through the customer’s identity provider using SAML or OIDC, with role mapping.

In REAP A platform service across all deployment models.

Machine data emitted by network devices and systems: syslog, SNMP, streaming gNMI (opens in a new tab) and interface counters.

In REAP Ingested through the connector cluster and correlated with configuration and topology.

Controls that keep one tenant’s data and actions invisible to another, enforced at the application layer with per-tenant access.

In REAP Documented in the security packet with the data-flow diagram.

Transport Layer Security encrypts traffic between two systems and lets each verify the other. An outbound tunnel is a connection the connector opens from inside your network to the platform, so no inbound firewall rule is needed.

In REAP Connectors reach REAP Cloud over an outbound TLS tunnel on port 443; TLS 1.2 or higher in transit and AES-256 at rest are stated in the Trust Center.

The physical and logical structure of the network (devices, links, paths, VLANs, routing adjacencies) discovered and kept current by REAP.

In REAP Topology accuracy (≥90%) is a context-completeness measure; topology position drives blast radius and CVE (opens in a new tab) context.

A single address, load-balanced across connectors, to which devices publish telemetry.

In REAP Lets a connector be replaced without touching device configuration.

Alarms that do not require action, or duplicates of one condition, which consume triage time and hide the alerts that matter.

In REAP Alert-triage hours per week are a value-model input.

Turning raw alarm streams into actionable alerts using topology, device role and business context, including flagging lost redundancy before the second failure.

In REAP In REAP: qualified incidents from REAP-collected telemetry are Available today; prioritization of third-party alert streams is In development. REAP prioritizes rather than replaces monitoring.

The group that reviews and authorizes changes.

In REAP CAB-approved changes are among those REAP verifies without having executed them.

The practice of assessing, authorizing and scheduling changes to minimize risk.

In REAP Change Assurance adds evidence before (impact analysis) and after (verification) the CAB decision.

Source: ITIL 4, paraphrased

The ITSM record of a change: intent, approvals, window, implementer and outcome.

In REAP In a pilot today, the before-and-after comparison and its evidence are recorded in the change ticket; automated verdict fields are In development.

The share of incidents passed from tier 1 to higher tiers or to named experts.

In REAP A baseline input for the pilot; reducing it is where engineer capacity comes from.

An unplanned interruption or degradation of a service; in network operations, usually surfaced as alerts and a ticket.

In REAP REAP investigates the qualified incidents its own rules raise from REAP-collected telemetry and the incidents your monitoring raises through ServiceNow (opens in a new tab) or Jira (opens in a new tab), and writes the findings and evidence links back to the ticket. Correlation of third-party alert streams is In development.

Source: ITIL 4 definition, paraphrased

The practice of restoring service as quickly as possible after an incident.

In REAP Restoration is where most incidents are closed; REAP adds the verified cause.

Source: ITIL 4, paraphrased

Average elapsed time from the start of an incident to its detection.

In REAP Industry average 41 minutes to detect a high-impact outage (New Relic (opens in a new tab), 2026 Observability Forecast (opens in a new tab)). In REAP, under 4 minutes to detect is a design target from REAP’s reference architecture until a pilot measures it against your baseline.

Source: New Relic, 2026 Observability Forecast

Average elapsed time from detection to full resolution of an incident.

In REAP Industry average 54 minutes to resolve a high-impact outage (New Relic (opens in a new tab), 2026 Observability Forecast (opens in a new tab)). In REAP, the related figure, under 5 minutes to an evidence-backed root cause, is a design target from REAP’s reference architecture; MTTR itself also depends on the fix and is measured against your baseline in a pilot.

Source: New Relic, 2026 Observability Forecast

A network built from equipment of several manufacturers (Cisco (opens in a new tab), Arista (opens in a new tab), Juniper (opens in a new tab), HPE Aruba (opens in a new tab), Palo Alto Networks (opens in a new tab), Fortinet (opens in a new tab), SONiC (opens in a new tab)) often across acquired sites.

In REAP Multivendor support is the first analyst requirement; REAP reasons across vendors with one investigation surface.

Source: Gartner, Market Guide for Agentic NetOps Software (May 2026)

Executing predefined steps against network devices without manual typing: scripts, playbooks, intent-based tools.

In REAP Automation executes; it does not decide what to look at next. REAP uses automation inside runbooks under governance.

Priority classes for incidents with the greatest business impact, typically requiring immediate response and executive communication.

In REAP The value model counts high-impact incidents per month; “bring us your last P1” is REAP’s offer of a 30-minute walkthrough session on an incident you already solved (see P1 walkthrough).

The median and the 95th-percentile of a measured duration; together they show the typical case and the tail.

In REAP REAP reports both and never hides the tail; a single demo timing is a red flag.

The practice of identifying and removing the causes of incidents so they do not recur.

In REAP REAP’s RCA and evidence carry context across the incident → problem → change lifecycle.

Source: ITIL 4, paraphrased

A state in which a redundant design has lost one of its members or paths and is now a single point of failure.

In REAP In REAP: posture checks flag out-of-sync standby pairs; loss-of-redundancy alerting is In development.

An incident that recurs within a defined window (REAP uses 90 days) with the same cause.

In REAP The “restored, not fixed” number; a value-model input and a self-assessment question.

Closing an incident at the first line of support without escalation to senior engineers.

In REAP Guided evidence and diagnostic runbooks let tier 1 and tier 2 close what used to escalate; measured as human effort.

Elapsed time from trigger to an evidence-backed diagnosis, distinct from time to restore.

In REAP Reported as P50 and P95 for known and novel investigations; a scorecard category.

The number of separate consoles an engineer opens to explain one incident.

In REAP Often six or more in the discovery conversations behind this site; a pilot target is one or two, measured against the baseline.

A software system that pursues a goal by choosing actions (gathering evidence, calling tools, proposing or executing steps) and adapting to what it finds.

In REAP REAP runs specialized agents inside a harness that enforces governance.

AI that runs a persistent, goal-directed loop (plan, act, observe, re-plan) rather than answering a single prompt.

In REAP Distinguished from automation (predefined steps) and from correlation-first tooling: an agent decides what to examine next.

Platforms that apply machine learning to IT operations data to correlate events, reduce noise and recommend actions.

In REAP AIOps platforms typically emphasize correlation and recommendation across events; an agentic investigation additionally decides what to examine next. REAP consumes AIOps outputs as evidence where they exist.

Flagging a measurement that departs from its own history (a link suddenly busier, errors where there were none) without a hand-written threshold.

In REAP Part of REAP’s data and intelligence layer on the architecture diagram (AI/ML services for anomaly and prediction). Qualified incidents are raised from deterministic conditions today, so an anomaly is context for an investigation, never a conclusion by itself.

AI is software that performs tasks that normally need human judgment; machine learning is the branch that learns patterns from data rather than following written rules. Large language models are one kind of AI.

In REAP REAP combines deterministic rules for known conditions with model-driven reasoning for the investigation that follows, and with anomaly and prediction services in its data layer; which model, and where it runs, is a choice you make.

An incident in which AI agents (a vendor’s, an attacker’s or your own) take actions across systems without human direction, such as the 2026 case in which agents under evaluation left their sandbox and reached third-party infrastructure over more than 30 days before detection.

In REAP The scenario class behind REAP’s “incidents nobody planned for” page: detect the unauthorized change, explain it with evidence, act only under approval.

Source: The operator’s incident report, “Hugging Face incident and the road ahead” (August 26, 2026); Cybersecurity Dive, “Hundreds of agents went rogue in lead up to Hugging Face breach” (August 27, 2026)

A confident model output not supported by evidence.

In REAP REAP’s countermeasures: evidence traceability, uncertainty stated, engineer scoring of conclusions.

A model trained on large text corpora that can read, reason over and generate language and structured output.

In REAP One component of REAP’s reasoning; grounded by retrieval, tools and evidence rather than trusted on its own.

The instruction and context given to a language model for one task. In an agent, the prompt also carries the evidence gathered so far and the tools available.

In REAP In REAP, text from tickets, documents and device output is evidence to reason over, never an instruction to follow, and consequential actions require approval regardless of what the model concludes; see prompt injection.

Content crafted to make a model or agent follow instructions its operator did not intend, including instructions hidden in tickets, documents or device banners an agent reads.

In REAP In REAP: consequential actions require approval regardless of what the model concludes; retrieved-content handling is described in the security packet.

The record of evidence steps and tool calls in an investigation, reviewed to check that an agent stayed on its assigned task and reached its conclusion from evidence.

In REAP In REAP: every tool call is logged with its output; in a pilot, engineers score the conclusions and the evidence behind them.

An AI system achieving the letter of its objective in an unintended way, for example by finding answers online instead of solving a task.

In REAP Named by the operator as a root cause of the 2026 incident; REAP’s objective is evidence accepted by your engineers, not a score the agent can game.

Source: The operator’s incident report, “Hugging Face incident and the road ahead” (August 26, 2026)

An isolated environment in which software or agents run with restricted access to networks, credentials and systems.

In REAP The 2026 incidents in which AI agents left their evaluation sandboxes are the reason REAP publishes its isolation, governance and audit design.

Source: The operator’s incident report, “Hugging Face incident and the road ahead” (August 26, 2026); Cybersecurity Dive, “Hundreds of agents went rogue in lead up to Hugging Face breach” (August 27, 2026)

An agent’s ability to call functions (run a show command, query a ticket, diff a configuration) and use the results in its reasoning.

In REAP Every tool call in REAP is logged; read tools and write tools are governed separately.

The customer’s own numbers before REAP: investigation time, tools per investigation, escalation rate, time to resolve, change-validation time, ticket volumes.

In REAP Collected in week 0 with a worksheet; without it every claim is an opinion.

The pre-agreed rule for proceeding: at least five of six technical and operational objectives met and annualized value of at least three times the proposed subscription → the customer signs the order form agreed in form at kickoff, within ten business days of the business review (the pilot fee is credited when it is signed within 30 days).

In REAP Agreed in writing before kickoff, with the value method agreed with finance.

The week-6 meeting with the economic buyer answering four questions: what did REAP find that you did not know, what did it do faster or better, what capacity or risk is that, what does production cost versus the value.

In REAP Ends in BUY, EXTEND (one named gap, at most three weeks) or STOP.

Scorecard category 1: devices discovered, topology accuracy, integrations operational.

In REAP Targets: ≥95% discovered, ≥90% topology accuracy, ITSM and telemetry live by day 7.

The customer’s own figure for the business cost of one hour of a high-impact outage: revenue at risk × share lost, plus productivity of affected staff, plus direct costs.

In REAP Industry references: a mean of $1.85M per hour for a high-impact outage (New Relic (opens in a new tab), 2026 Observability Forecast (opens in a new tab)). Uptime Institute (opens in a new tab), Annual Outage Analysis 2026 (opens in a new tab): 57% of respondents said their most recent major outage cost more than $100,000; one in five, more than $1 million. Build your own in the calculator.

Source: New Relic, 2026 Observability Forecast; Uptime Institute, Annual Outage Analysis 2026

A performance figure REAP’s reference architecture is designed for (under 4 minutes to detect, under 5 minutes to root cause, −30% operations cost) labeled as a target until a pilot measures it.

In REAP Never presented as a customer result.

Scorecard category 2: correct or materially useful root cause on replayed incidents; evidence traceability; blast-radius accuracy.

In REAP Targets: ≥80% correct or useful, ≥90% traceable.

The person who can sign, met before kickoff and present at the week-6 business review.

In REAP An entry criterion.

Scorecard category 7: annualized value on the customer’s baseline versus the proposed subscription.

In REAP Target: at least three times the proposed subscription; computed in the value model with engineer capacity and outage economics shown separately.

The pilot scorecard categories: context completeness, diagnosis quality, time to answer, human effort, prevention, automation & change verification, economics, trust.

In REAP Each has a default target agreed per pilot.

Hours returned to the team through faster diagnosis, fewer repeats, less triage and less change and audit work, expressed as FTE-equivalents.

In REAP The hard-dollar lever; the related figure, −30% operations cost, is a design target from REAP’s reference architecture until a pilot measures it.

The eight things in place before a pilot starts: technical champion, economic buyer, the problem in the customer’s words, baseline, written success criteria, purchase process, commercial hypothesis, decision date.

In REAP Three never move into week 0: the economic buyer committed to the business review, success criteria signed, and the decision date on the calendar. Listed on the Proof of Value page.

Preferred multi-year pricing and a written expansion path for customers who sign during the founding-customer program.

In REAP See Pricing.

Full-time-equivalent: a way to express saved or redirected effort as fractions of a full-time person, so that minutes saved per investigation can be compared with headcount.

In REAP Engineer capacity in the value model is expressed as FTE-equivalents and kept separate from outage economics, so neither inflates the other.

Engineer capacity returned, valued at loaded cost, plus anything the customer would actually stop paying for.

In REAP Reported separately from business impact; capacity is FTE-equivalents redeployed, not headcount reduction.

Scorecard category 4: engineer-minutes per investigation and tools touched.

In REAP Targets: ≥50% reduction on validated incident classes; tools 6 → 1–2.

Running REAP against a historical incident whose root cause the customer knows and REAP is not told, then scoring the result.

In REAP Replays of 5 to 10 incidents in pilot week 2, on the customer’s own network. Before any pilot, “bring us your last P1” is a 30-minute walkthrough session, not a replay: REAP does not run replays on exported tickets, configurations or logs.

A measured number a team manages by, chosen because it reflects an outcome rather than activity.

In REAP The eight measures of a proof of value are its KPIs: context completeness, diagnosis quality, time to answer, human effort, prevention, automation and change verification, economics and trust.

Pilot option B: the fee waived in exchange for logo rights, a case study, reference calls and weekly structured product feedback; same decision date and business criterion.

In REAP For segment-defining accounts.

The self-assessment result: Reactive (under 35%), Managed (35–59%), Assured (60–79%) or Proven (80% and above).

In REAP Each stage maps to a recommended next step.

A figure produced in a customer’s own pilot against their baseline, citable only with consent.

In REAP Replaces design targets on the website when available.

The formal name of REAP’s proof-of-value program.

In REAP Same thing as the proof of value; “pilot” in conversation.

A 30-minute working session in which REAP’s engineers walk through how REAP would investigate an incident the customer has already solved: the evidence it would request, the hypotheses it would test, and the detection that would have caught it earlier. The customer keeps the root cause to itself.

In REAP REAP’s “bring us your last P1” offer, scheduled within one business day of the request. It is a conversation about method, not a replay: REAP does not run replays on exported tickets, configurations or logs, and publishes no turnaround commitment for a written walkthrough. The replay on the customer’s own network, with the evidence trail, happens inside the proof of value (5 to 10 solved incidents in week 2).

Scorecard category 5: previously unknown material risks confirmed by the customer.

In REAP Target: at least three.

REAP’s 45-day pilot on one production domain: baseline in week 0, eight measured categories, a business criterion agreed in writing, and a decision (BUY, EXTEND or STOP) in week 6.

In REAP A pilot is not a product demo; it must prove willingness to buy.

The share of modeled outage cost a buyer chooses to count: 25% in the Conservative case, 50% in the Base case by default.

In REAP Always visible in the calculator; agreed with finance before a pilot.

The value an investment returns compared with its cost, usually over a year. Honest ROI separates hard-dollar savings from avoided risk and shows the assumptions.

In REAP The value calculator shows a conservative and a base case, keeps engineer capacity and outage economics separate and leaves the share of outage cost you count visible; nothing is hidden in a multiplier.

Outage minutes avoided multiplied by the customer’s cost per minute, multiplied by the realization factor.

In REAP The second of the two numbers the value model reports.

The Network Assurance Self-Assessment: 20 rubric-scored questions (or Quick 8) across Observe, Reason, Act and Govern & Prove, producing a stage, the “restored ≠ fixed” index, three largest gaps and a recommended first door.

In REAP Vendor-neutral by design; feeds the December benchmark.

A contractual commitment to a level of service (availability, response time, time to restore), usually with credits when it is missed.

In REAP In the value model, SLA credits and churn are the customer-facing cost of an incident; on REAP’s side, the availability commitment for REAP Cloud is stated in the subscription agreement.

Scorecard category 8: the share of conclusions accepted by senior engineers, and willingness to reference.

In REAP Target: ≥80% accepted.

REAP’s calculator: from six baseline numbers, a Conservative and a Base case with engineer capacity (hard-dollar) and outage cost avoided (risk-adjusted) shown separately and a visible realization factor.

In REAP Available as a web calculator and as the full workbook; the measured version replaces assumptions with pilot results.

The preparation week of a pilot: baseline worksheet, scorecard targets, mutual action plan, security packet, week-0 data request, kickoff with champion and economic buyer.

In REAP Also when integrations are scoped.

The systems and controls covered by an external audit or examination (PCI segmentation, for example) for which evidence must be produced.

In REAP Evidence packages for audit scope are In development; in a pilot, configuration and topology findings serve as evidence for agreed controls.

Standard vendor security questionnaires: the Cloud Security Alliance (opens in a new tab)’s STAR registry and CAIQ (opens in a new tab) questionnaire, and Shared Assessments (opens in a new tab)’ SIG (opens in a new tab). Buyers send one; vendors answer it once and reuse it.

In REAP Questionnaire answers are part of the security packet, so a review starts from written answers rather than a blank form; a CSA STAR (opens in a new tab) listing is under evaluation.

The public identifier for a disclosed vulnerability (CVE-2026-NNNNN), maintained so that vendors, scanners and advisories all refer to the same issue.

In REAP Contextual CVE (opens in a new tab) exposure ranks a CVE by whether the vulnerable feature is configured and reachable on your devices; a version match alone is not a finding.

The contract terms governing REAP’s processing of personal data on a customer’s behalf, including subprocessors, transfers and deletion.

In REAP On request; aligned to GDPR (opens in a new tab), UK GDPR (opens in a new tab) and CCPA (opens in a new tab)/CPRA.

Protection of data moving between systems (TLS 1.2 or higher) and stored (AES-256 with keys in a cloud key management service).

In REAP Stated in the Trust Center; details in the security packet.

The European, UK and California privacy laws that govern personal data: what may be collected, on what basis, where it may go and what a person may ask for.

In REAP REAP’s privacy statement and data processing agreement are aligned to them; most of what REAP processes is device configuration and telemetry, with personal data limited to ticket text and user accounts.

The U.S. health privacy law and the protected health information it covers.

In REAP REAP collects no clinical-systems data: it reasons over device configurations, telemetry and topology. Ticket free text is included only as agreed, and PHI handling is settled in the security review.

The discipline and the systems that decide who and what may access which resources: identities, roles, policies and their review.

In REAP In REAP, SSO and RBAC for people; read-only roles and scoped keys for the cloud accounts and controllers REAP reads; every access change in the audit trail.

International standards for an information security management system (27001) and an AI management system (42001), each certifiable by an accredited auditor.

In REAP REAP’s controls are aligned to ISO/IEC 27001 (opens in a new tab) (not certified; the certification audit is targeted for the first half of 2027) and ISO/IEC 42001 (opens in a new tab) is under evaluation for the agent harness; the Trust Center states the posture and the security packet the timing.

Source: ISO/IEC 27001:2022; ISO/IEC 42001:2023

A cloud service that creates, stores and rotates encryption keys inside hardware-backed boundaries, so the keys never sit beside the data they protect.

In REAP Data at rest in REAP Cloud is encrypted with AES-256 with keys held in a cloud key management service; details in the security packet.

An attacker, or a misdirected agent, moving from the first system it reached to others, often through management interfaces and reused credentials.

In REAP The scenario “lateral movement through the management plane” on this site: individual actions look like administration; the pattern across devices is what REAP’s evidence makes visible.

Requiring a second proof of identity (an app prompt, a hardware key) beyond a password.

In REAP Enforced by your identity provider, which REAP relies on through single sign-on; REAP does not keep its own passwords for SSO users.

The reliability standards for the North American bulk electric system’s cyber assets, including supply-chain requirements (CIP-013).

In REAP Not assessed: utilities with BES Cyber System scope should discuss the deployment boundary, data classes and CIP-013 questions with REAP before an evaluation.

The U.S. National Institute of Standards and Technology’s framework of security outcomes (govern, identify, protect, detect, respond, recover) used to describe and compare security programs.

In REAP REAP’s controls are aligned to CSF 2.0 across Govern, Identify, Protect, Detect, Respond and Recover (aligned, not certified); the mapping is described in the security packet.

Source: NIST CSF 2.0 (2024)

The Open Worldwide Application Security Project and its Application Security Verification Standard: the reference list of web application risks and the checklist for verifying an application against them.

In REAP The OWASP (opens in a new tab) Top 10 for LLM Applications is design guidance for REAP’s agent harness, beside NIST AI RMF (opens in a new tab); agent-specific risks such as prompt injection and tool misuse are reviewed in the threat model.

The payment card industry’s security standard, including the requirement to segment the cardholder data environment and to prove the segmentation.

In REAP Network segmentation evidence is audit scope that pilots in financial services and retail gather by hand today; configuration and topology findings serve as evidence for agreed controls, and payment systems themselves stay out of scope.

An authorized attempt by security professionals to break into a system, reported with findings and their severity.

In REAP An annual penetration test by an independent third party, with the executive summary available under NDA; the vulnerability disclosure policy covers good-faith research outside it.

The two standard protocols by which an application trusts your identity provider to sign users in: SAML (an XML-based standard) and OpenID Connect (built on OAuth 2.0).

In REAP REAP’s console signs in through SAML or OIDC with Okta (opens in a new tab) or Microsoft Entra ID (opens in a new tab), with roles mapped from your groups; see single sign-on.

NIST (opens in a new tab)’s Secure Software Development Framework describes how software should be built; a software bill of materials lists the components a release contains, so a vulnerable library can be found quickly.

In REAP Secure development practices aligned to the SSDF are listed with evidence in the security packet, and the software bill of materials is among the documents available on request under NDA.

Source: NIST SP 800-218

REAP’s written answers for a security review: data-flow diagram, connector details, credential model, data classes and retention, model options and training policy, subprocessors, questionnaire answers and program status.

In REAP Sent under NDA in week 0 of any evaluation or on request from the Trust Center.

A small file at /.well-known/security.txt that tells security researchers where to report a vulnerability and what policy applies.

In REAP Served by the REAP website; it names security@reapnet.ai and the disclosure policy.

Source: RFC 9116

An attack that tricks a server into making requests on the attacker’s behalf, reaching systems the attacker could not reach directly.

In REAP One of the network paths the 2026 autonomous-agent incidents used to escape their sandboxes, as the scenarios page recounts; REAP’s connectors make outbound requests only to the platform and the devices in scope.

A Type I report describes controls at a point in time; a Type II report attests that they operated effectively over a period, usually six to twelve months.

In REAP REAP’s SOC 2 (opens in a new tab) Type II attestation is in process; the status, scope and timeline are in the security packet, and the report is available upon request under NDA.

Source: AICPA trust services criteria

An independent attestation that a service organization’s controls operated effectively over a period, against the AICPA (opens in a new tab) trust services criteria.

In REAP REAP’s attestation is in process; the report is available upon request, under NDA, and the status, scope and timeline are in the security packet. Never described as achieved until it is.

A third party that processes customer data on REAP’s behalf: hosting, edge, form delivery, analytics.

In REAP The versioned list with purposes and locations is in the security packet and the data processing agreement.

The public page that answers a security reviewer’s first questions: deployment and residency, access, data and AI use, controls and program, vulnerability disclosure, subprocessors, accessibility.

In REAP Where a detail belongs in a controlled document, the Trust Center says so and points to the security packet.

The policy and channel for reporting a suspected security vulnerability in REAP: security@reapnet.ai, acknowledgment within two business days, and /.well-known/security.txt.

In REAP Good-faith research under the policy is not pursued.

An ordered list of rules on a router, switch or firewall that permits or denies traffic by addresses, ports and protocols; the last rule is usually an implicit deny.

In REAP The home page’s illustrative P1 is an ACL whose object group was edited: traffic that no longer matched fell to the final deny. Rule hit counts read twice, seconds apart, are the evidence that proves it.

Two devices arranged so one carries the service and the other takes over on failure: firewalls, VPN gateways, load balancers, core routers. “HA” for short.

In REAP Standby sync, configuration drift between the pair and whether a failover has ever been exercised are the resilience checks REAP runs; an out-of-sync standby protects nothing.

The programmatic way one system reads from or writes to another, usually over HTTPS with a token or key; REST APIs exchange JSON.

In REAP Every REAP integration is an API integration with the narrowest scope that does the job: read scope on controllers and cloud accounts, write scope only for the work notes REAP adds to a ticket.

A physically separate data center within a cloud region. Running across more than one zone keeps a service up when one zone fails.

In REAP REAP Cloud runs across availability zones on AWS (opens in a new tab) in U.S. regions with encrypted, region-redundant backups; the recovery objectives are stated in the subscription agreement.

The routing protocol that connects networks to each other and to the internet and cloud providers, exchanging reachable prefixes between autonomous systems.

In REAP BGP sessions, received and advertised prefixes and route changes are evidence for WAN, cloud-interconnect and data-center investigations.

The approved period in which a change may be made or a device restarted, agreed in advance so that impact is expected and watched.

In REAP Before-and-after verification of one real change window is a Pilot deliverable; the guides on this site run every state-changing command only inside an approved maintenance window.

The text interface of a network device: show commands that read state and configuration commands that change it, over SSH or a console.

In REAP Read-only show commands are REAP’s main evidence source; every command and its output are kept with the conclusion they support. Configuration commands run only inside an approved runbook.

A vendor’s cloud-hosted management plane for wireless, switching or SD-WAN estates (Juniper Mist (opens in a new tab), HPE Aruba (opens in a new tab) Central, Cisco Meraki (opens in a new tab)), reached through an API rather than device by device.

In REAP Available integrations: REAP reads network context, inventory and events from these controllers alongside the devices it reaches directly.

The networking objects inside a public cloud account: virtual networks (VPC on AWS (opens in a new tab), VNet on Azure (opens in a new tab)), subnets, route tables, security groups, gateways, transit gateways and VPN connections.

In REAP Read with read-only cloud roles for AWS (opens in a new tab) and Azure (opens in a new tab) today, so hybrid paths between a site and a cloud workload can be traced and verified; GCP (opens in a new tab) network discovery is not available today.

The ITSM’s inventory of configuration items (devices, applications, services) and the relationships between them.

In REAP Optional enrichment: CMDB records give REAP’s investigations business context (which service runs behind which device). NetBox (opens in a new tab) reconciliation is On request.

Source: ITIL (Axelos)

Frames received with a bad checksum, usually a sign of a failing cable, optic or port rather than a configuration problem.

In REAP In REAP’s troubleshooting moment, input and CRC errors on the interface are checked before protocol settings, because a physical fault drops hello packets too.

DHCP hands out IP addresses to devices; a DHCP relay (an “IP helper address” on a router) forwards those requests from a VLAN to a DHCP server somewhere else.

In REAP The illustrative change verification on this site finds a missing helper address on one core after an upgrade: a regression that would surface only on the next failover.

The domain name system: the service that turns names into addresses. When it fails, everything that depends on names looks broken at once.

In REAP A DNS failure is a classic “everything is down” symptom whose cause lies elsewhere; REAP’s evidence separates the name-resolution failure from the path.

Enterprise resource planning (orders, inventory, finance) and manufacturing execution systems (what the plant is producing right now): the business applications whose traffic a plant network carries.

In REAP The illustrative P1 drops ERP return traffic to order entry; the illustrative resilience finding protects MES and plant telemetry with a QoS class on the backup circuit. Both show why a network incident is a business incident.

Passing an incident from the team that took the first call to a more senior engineer or a vendor because it could not be resolved at the first level.

In REAP The number a pilot watches: how many incidents still need a senior engineer or a vendor case when tier 1 has an evidence-backed answer in front of it.

VXLAN carries Layer-2 segments over an IP underlay; EVPN is the BGP-based control plane that distributes the reachability for them. Together they build modern data-center fabrics.

In REAP Supported platforms are confirmed per pilot; fabric specifics such as overlay and underlay evidence are reviewed in scoping, as the industries page says for data centers.

A device or service that enforces security policy between network zones: which addresses, ports and applications may talk, and which may not.

In REAP Firewall pairs are frequent subjects of resilience findings and change verdicts; the firewall failover guide on this site walks through the test, and platform coverage is stated per vendor and version.

Moving a device to a new operating-system release, usually in a maintenance window, one unit of a redundant pair at a time.

In REAP A frequent Change Assurance case: the illustrative core-pair upgrade on this site completed, kept reachability and still introduced one regression that only before-and-after comparison caught.

Summaries of the conversations a device forwards: source, destination, ports, protocol, bytes, packets and time, exported as NetFlow or IPFIX.

In REAP Collected where you configure exporters to the connector; used to show which flows crossed a path before and after a change, and to size a backup path from real traffic.

Protocols that let two routers share one gateway address: one is active, the other stands by and takes over the address if the active one fails (HSRP is Cisco (opens in a new tab)’s; VRRP is the standard).

In REAP Active and standby roles, planned flips during an upgrade and any moment both units sat in standby are evidence in a change verdict; a pair that never flips cleanly is a resilience finding.

An estate in which on-premises networks and one or more public clouds carry production traffic together, with paths that cross the boundary between them.

In REAP One vendor plus AWS (opens in a new tab) or Azure (opens in a new tab) hybrid cloud is one of the three qualifying statements on the home page: the cross-boundary incident is where single-vendor tools stop.

The per-interface statistics a device keeps: packets and bytes in and out, errors, discards, CRC errors, utilization over time.

In REAP Evidence for both incidents (errors and discards on a link) and resilience findings (business-hours p95 load on a primary compared with the capacity of its backup).

IT service management: the practice and the system of record (ServiceNow (opens in a new tab), Jira Service Management (opens in a new tab), ManageEngine) in which incidents, problems, changes and requests are opened, worked and closed.

In REAP REAP reads incidents, problems and changes from your ITSM and writes the Investigation Window, change verdicts and evidence links back as work notes; the ticket you already use stays the system of record.

Source: ITIL (Axelos)

The open-source platform that runs containerized software across a cluster of machines, restarting and scaling components as needed.

In REAP REAP’s platform is Kubernetes-based, which is how it is deployed into a customer’s cloud account or data center as well as run in REAP Cloud; the supported platforms for a customer-hosted deployment are confirmed at scoping.

A data-center network design in which every leaf switch connects to every spine switch, so any two servers are the same number of hops apart and capacity grows by adding spines.

In REAP The fabric designs REAP reasons about for data centers and neocloud providers; redundancy in a fabric is assumed rather than proved until something tests it.

Protocols by which a device announces itself to its directly connected neighbors (LLDP is the standard; CDP is Cisco (opens in a new tab)’s), so each side knows what is on the other end of a link.

In REAP The source of the physical topology REAP discovers and of the “what is actually wired” facts behind its planning and impact analysis.

A step-by-step plan for a network change: the intent, the exact commands, the checks before and after, the rollback trigger and the rollback steps.

In REAP The MOP template guide on this site provides one; REAP’s pre-execution impact analysis reads the intent and the devices in a MOP to say what the change would touch.

Two switches presenting themselves as one logical switch to a downstream device, so a server or switch can be connected to both with one bundled link and survive the loss of either.

In REAP Peer-link state, consistency parameters and orphan ports are part of the resilience checks on redundant pairs.

A network management system: the monitoring platform (SolarWinds (opens in a new tab), Zabbix (opens in a new tab), a vendor’s own) that polls devices, keeps metrics and raises alarms.

In REAP REAP does not replace monitoring and does not modify it. It collects its own telemetry today; incidents your monitoring raises reach REAP through ServiceNow (opens in a new tab) or Jira (opens in a new tab), and reading third-party alert streams is Planned.

The largest packet an interface will carry. A mismatch between two ends drops large packets or keeps a routing adjacency from forming.

In REAP One of the first checks in REAP’s OSPF troubleshooting moment on the home page: hello and dead timers, MTU and area settings on both ends.

Rewriting the addresses in packets as they cross a boundary, so private addresses can reach the internet or two networks with overlapping addresses can talk.

In REAP NAT rules are part of the security policy REAP evaluates before a change and part of the path evidence when a flow stops working after one.

The software a switch, router or firewall runs: Cisco IOS-XE (opens in a new tab) and NX-OS (opens in a new tab), Arista EOS (opens in a new tab), Junos (opens in a new tab), PAN-OS, FortiOS, SONiC (opens in a new tab) and others. Each has its own commands, configuration syntax and failure modes.

In REAP REAP’s agents know each supported platform’s commands and output; coverage is stated per platform and version and confirmed per pilot for anything outside the supported list.

The team and the room, physical or virtual, that watches the network, takes the first call on an incident and escalates what it cannot resolve.

In REAP A pilot measures tier-1 resolution and escalation rate for the NOC; mid-sized companies without a 24x7 NOC are one of the three segments REAP is built for.

The protocol that keeps device clocks synchronized. Without it, logs from different devices cannot be placed on one timeline.

In REAP Accurate timestamps are what let REAP relate a change at 21:14 to a symptom at 21:16; NTP state is checked where evidence timelines disagree.

A named set of addresses, networks or services that firewall and router rules refer to by name, so one group can be reused by many rules.

In REAP Editing a group changes every rule that references it, which is why REAP’s change impact analysis follows references before a change runs and why the illustrative P1 broke a path nobody touched directly.

The rotation of engineers who can be paged outside business hours, and the tooling (PagerDuty (opens in a new tab), Opsgenie (opens in a new tab)) that pages them.

In REAP On-call integrations are Planned; today the engineer who is paged opens the ticket and finds the Investigation Window waiting in it.

The networks and systems that run physical processes: plant floors, building systems, medical devices, utilities. Usually segmented from the IT network and governed by stricter change rules.

In REAP OT networks stay out of scope in manufacturing pilots; REAP reasons about the IT boundary that OT depends on (the plant core, the WAN pair, the firewall between zones).

A link-state routing protocol used inside an organization’s network: routers exchange link information, form neighbor adjacencies and compute the shortest path to every destination.

In REAP OSPF neighbor state (FULL, DOWN, EXSTART and the rest) is standard evidence in an investigation: a neighbor that never changed state rules out the link, as in the Investigation Window on the home page.

An outage is a service that is down; a degradation is a service that still works but worse than its baseline, slower, lossy or without its redundancy.

In REAP Change verdicts use both words: a change can complete, keep reachability and still leave the network degraded, as in the illustrative upgrade whose DHCP relay would fail on the next failover.

Following a flow hop by hop through the network, using routing tables, ACLs and NAT, to see which devices and links it actually crosses.

In REAP Used in pre-execution impact analysis and in resilience findings (which paths share a WAN pair, which failover path would carry the load).

Several physical links between two devices bundled into one logical link for bandwidth and redundancy; LACP is the protocol that negotiates the bundle.

In REAP One of the planning moments on the home page: REAP proposes the bundle from the interfaces that CDP or LLDP shows are actually wired between the two devices.

The written review after an incident: timeline, cause, contributing factors, what detected it, what fixed it and what will prevent it, without blame.

In REAP The postmortem template guide gives the structure; REAP’s Investigation Window supplies the timeline and the evidence so the review starts from facts rather than memory.

The state captured before a change (routing neighbors, redundancy state, probes, counters) and the same capture afterwards, compared to decide whether the change did only what it was meant to do.

In REAP What REAP automates for the changes it verifies: a pre-change baseline, a post-change comparison and a delayed post-check at T+30 minutes, with the result written to the change record.

The ITSM’s ranking of an incident by impact and urgency: P1 is a critical, business-stopping incident, P2 a major one, P3 and P4 lesser ones with longer targets.

In REAP REAP’s loss framing counts the P2s as well as the P1s: the incidents that never reach the board deck add up over a year. See P1 for the figure most teams know by heart.

Source: ITIL (Axelos)

Policy that classifies traffic and gives some classes priority or guaranteed bandwidth when a link is congested.

In REAP The illustrative resilience finding on this site: a backup circuit with no QoS class for plant telemetry would congest on failover and drop production traffic with everything else.

A synthetic test (ping, traceroute or an application-level check) run on a schedule from a known point to confirm that a path still works.

In REAP Probes from the connector before and after a change are compared against the baseline in a change verdict, with a delayed post-check at T+30 minutes; the illustrative P1 had no probe on the ERP path, which is why it went undetected for hours.

Recovery point objective: how much data may be lost in a failure. Recovery time objective: how long recovery may take. Both are commitments, not measurements.

In REAP REAP Cloud’s availability commitment and recovery objectives are stated in the subscription agreement; for customer-hosted deployments, backup and restore procedures are documented for your operations team.

The running configuration is what a device is doing now; the startup configuration is what it will do after a reload. When they differ, a reboot changes the network.

In REAP Running/startup drift is one of the posture findings available today; it is also how a change that was never saved comes back after the next maintenance reload.

Software-defined wide-area networking: branch and site connectivity run as policy over several circuits (internet, MPLS, cellular) and managed from a controller rather than device by device.

In REAP SD-WAN policy and firmware waves are a Change Assurance case for retail and branch estates; coverage of a given SD-WAN platform is confirmed per pilot.

A vendor’s published notice that a vulnerability affects certain releases and features, with the fixed releases and workarounds; vendors publish them through a product security incident response team (PSIRT).

In REAP Contextual CVE (opens in a new tab) exposure: REAP ranks an advisory by whether the vulnerable feature is actually configured and reachable on the device, not by version match alone.

Simple Network Management Protocol: a device exposes counters and state as a tree of values that a monitoring system polls, and sends traps when something changes.

In REAP The connector polls metrics over SNMP (a read community or an SNMPv3 user) and receives traps; both are telemetry REAP collects itself today.

A Layer-2 protocol that blocks redundant switch links so frames cannot loop, and unblocks them when the active path fails.

In REAP Root bridge, blocked ports and topology-change counters are evidence in campus and data-center incidents where a loop or a convergence event is suspected.

Secure Shell: the encrypted protocol used to reach a device’s command line and to transfer files to it.

In REAP The connector cluster reaches devices over SSH with read-only credentials brokered from your PAM where available; the connector’s own traffic to the platform leaves over one outbound TLS tunnel.

A written, repeatable procedure for routine operational work, kept so that different people do the same task the same way.

In REAP SOPs and runbooks are among the information islands REAP reads; approved ones become natural-language runbooks that tier 1 can run under governance.

Devices pushing state and counters to a collector continuously (over gNMI (opens in a new tab), for example) instead of waiting to be polled.

In REAP gNMI (opens in a new tab) dial-out subscriptions to the connector are one of the three telemetry sources a pilot connects on day 2, alongside syslog and SNMP.

The standard way devices send event messages (a link went down, a neighbor changed state, a configuration was saved) to a collector, each with a timestamp and a severity.

In REAP Point device syslog at the connector VIP: syslog lines are first-class evidence, and the absence of a link event in syslog is itself evidence, as in the illustrative P1.

A support case opened with a network vendor’s technical assistance center, usually after the in-house team has exhausted its own evidence.

In REAP TAC history is one of the information islands REAP reads; an investigation that already holds the evidence a TAC engineer would ask for shortens the case or avoids it.

A logical segment of a switched network that keeps a group of ports or devices in their own broadcast domain, identified by a number (VLAN 220, VLAN 3998).

In REAP VLAN membership, trunks and the VLAN interfaces that carry gateways and DHCP relay appear in configuration diffs and in the blast radius of a change.

A virtual private network: an encrypted tunnel that carries private traffic across a public network, between sites or from a user to the network.

In REAP Firewall and VPN standby pairs are among the first resilience checks in campus pilots; cloud VPN gateways are read as cloud network constructs.

The virtual terminal lines through which remote sessions (SSH, Telnet) reach a device; access lists on them decide who may connect.

In REAP Named in the network requirements as one of the things to confirm when enrolling devices: the connector’s address must be permitted on the VTY access list.