SubstrateState is the central data structure flowing through every NSP operation. Each time you call GET /state/{pid} or POST /action, you receive a SubstrateState — a typed, versioned JSON snapshot of exactly what a running application contains at the moment of capture. Every field is semantically labeled by the probe, normalized to the Substrate Schema Format (SSF), and stored with a confidence score that controls which actions you are permitted to execute against it.
JSON Example
Fields
string (UUIDv7)
required
A time-ordered unique identifier for this state capture. UUIDv7 values are monotonically increasing — a higher
capture_id is always more recent. Use this field to detect stale responses or deduplicate events from the WebSocket stream.string
required
A stable semantic identifier for the application. The format on first detection is
{app-name}-{runtime}-{pid} (for example, "gmail-chrome-12847"), and it is promoted to a content-hash-based ID that survives daemon restarts. You can safely store app_id in your agent and use it across sessions without tracking raw PIDs.string
required
The human-readable display name of the application, such as
"Gmail" or "Mission Planner". This value is assigned by the signature registry and is stable across captures.integer
required
The OS process ID at the time of capture. Unlike
app_id, the PID changes if the application restarts. Use app_id for stable references and pid only when you need to target a specific OS process.enum
required
The runtime substrate the probe connected to. One of:
v8— JavaScript/V8 (Chrome, Electron, Node.js)jvm— Java Virtual Machineclr— .NET Common Language Runtimeunknown— Runtime detected but not yet classified
string (semver)
required
The semantic version of the discovered schema for this application, for example
"1.4.2". A version change means the schema registry learned something new:- Patch (
1.4.2 → 1.4.3): A label correction was applied. Existing key meanings are unchanged. - Minor (
1.4.x → 1.5.0): New state keys or actions were discovered. Existing keys are unchanged. - Major (
1.x → 2.0.0): Key names were restructured. Rare — only occurs on major application updates.
schema_version changes.string (ISO 8601)
required
The UTC timestamp at which this snapshot was taken, for example
"2026-07-20T13:00:00Z".float (0.0–1.0)
required
The overall quality score for this capture, representing how certain the probe is in its semantic labels. Confidence gates which actions you are allowed to execute. See the confidence table below.
AppContext object
required
The navigational context of the application at capture time — where inside the app the user currently is.
object
required
The semantic state of the application as a flat key-value map. All keys use dot-notation with array indexing (see key format below). Value types may be
number, string, boolean, null, object, or array. This is the map you reference in verify_expression strings and SDK accessors.object
required
A map of action name to ActionSchema. Each entry describes a callable action discovered from the application’s runtime, including its signature, reversibility tier, and typed parameter list. You pass the action name directly to
POST /action.object
required
Internal telemetry from the probe cycle that produced this snapshot.
Dot-Notation Key Format
All state inobjects is stored as a flat map with dot-notation keys. Instead of navigating nested JSON, you reference a specific value with a precise path string:
app_id and schema_version, the same key always refers to the same semantic concept. When you query POST /verify or write a verify_expression, you reference these exact key strings.
Confidence Score
EverySubstrateState includes a confidence value that controls which actions the NSP daemon will allow you to execute.
If a
POST /action request arrives when confidence is below the required threshold for that action’s reversibility tier, the daemon returns 503 confidence_too_low. You can force a fresh probe with ?fresh=true on GET /state/{pid} to attempt to raise confidence before acting.