Skip to main content
Runtime probes are the core mechanism NSP uses to read live state from running applications. Instead of taking screenshots or simulating mouse clicks, each probe is a language-specific agent that attaches directly to a process’s managed runtime — V8, JVM, or CLR — and extracts structured, semantic data from memory. You never need access to source code, you never need to instrument the application, and you never need to modify it in any way.

​
The Three Probe Types

NSP ships three production-ready probes, each targeting a different runtime family. Click through to the individual probe pages for setup instructions and deeper technical details.

V8 Probe

Attaches to Chrome and Electron apps via CDP. Covers Gmail, Slack, VS Code, Notion, Discord, and any Electron-based application.

JVM Probe

Attaches to running Java processes via JVMTI. Covers SAP ERP, IntelliJ IDEA, Jenkins, Elasticsearch, and more.

CLR Probe

Attaches to .NET processes via an MMF bridge. Covers Mission Planner, Visual Studio, Microsoft Office, and all WinForms and WPF apps.
Native C/C++ process probing is scheduled for release next month and will extend NSP coverage to unmanaged executables.

​
Runtime Coverage

The table below summarises what each probe covers, the underlying extraction technique, and the accuracy you can expect in production.

​
App Lifecycle

When you start an application, NSP detects and attaches to it automatically — no manual steps required. The sequence below shows every stage from process start to live state polling.
The ProcessScanner polls all running OS processes every 500 ms. As soon as it sees a new PID, the RuntimeDetector inspects the process name, command-line arguments, and loaded modules to decide which probe to use. The SignatureRegistry then matches the process to a known application signature, assigning a stable app_id that survives process restarts.

​
Cold Probe vs. Fast Poll

The first time NSP attaches to a process, it performs a cold probe — a full runtime inspection that can take anywhere from 3 seconds to 90 seconds depending on the application’s heap size and complexity. This happens once per application per daemon session. After the cold probe completes and the first SubstrateState is cached, NSP switches to the ASO fast-path for all subsequent reads. The fast-path injects a lightweight JavaScript snippet (for V8) or uses a pre-warmed JVMTI / MMF connection (for JVM and CLR) to pull only the changed portions of state. Typical fast-poll latency is ~50 ms.
If your agent calls GET /substrate/v1/state/{pid} before the cold probe finishes, the daemon returns a partial state with a low confidence score rather than blocking. Poll until confidence >= 0.80 before acting on the data.

​
Confidence Scores

Every SubstrateState object includes a confidence field (0.0–1.0) that tells you how complete and accurate the probe’s semantic labeling is for that capture. NSP uses this score to gate which action types your agent is allowed to execute. Once a probe is fully warmed, each runtime consistently reaches these confidence baselines: A confidence score below the expected baseline usually means the probe is still in its cold-attach phase or the application has navigated to a view that NSP has not yet learned. The score recovers automatically as the fast-poll loop accumulates more captures.