Skip to main content
The SubstrateState object (also referred to as an SSF — Substrate Schema Format — document) is the primary data structure NSP returns when you read an application’s current state. Every GET /state response wraps one, every WebSocket state-change event carries one, and every action you dispatch consumes one as its pre-flight context. It represents a point-in-time snapshot of everything the probe could semantically label inside the target process, plus the action surface available at that moment.
capture_id
string
required
A UUIDv7 time-ordered unique identifier generated for each state capture. Because UUIDv7 embeds a millisecond-precision timestamp, a lexicographically larger capture_id is always a more recent capture — you can use this to detect and discard stale responses without parsing captured_at.
app_id
string
required
A stable semantic identifier for the application. On first detection NSP derives a candidate ID in the form {app-name}-{runtime}-{pid} (for example gmail-chrome-12847), then promotes it to a content-hash-based ID that persists across process restarts once the probe has confirmed the app’s identity. You should always use app_id — not pid — when you want to reference a specific application across sessions.
app_name
string
required
Human-readable display name assigned by the signature registry, for example "Gmail" or "Mission Planner". Suitable for logging and UI display; not intended for programmatic identity checks (use app_id for that).
pid
integer
required
The OS process ID of the target application at the time of this capture. Because PIDs are recycled by the OS after a process exits and a new one starts, pid is only stable for the lifetime of a single process. Prefer app_id for persistent references.
runtime
enum
required
The runtime environment detected for this application. Controls which probe strategy NSP uses and sets the baseline confidence ceiling.
schema_version
string
required
Semver string representing the version of the discovered schema for this application, for example "1.4.2". NSP bumps the version as it learns more about the app:
  • Patch (1.4.2 → 1.4.3): A label correction was learned; 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 due to an app update. Rare — verify your hardcoded key names when this occurs.
captured_at
string
required
ISO 8601 UTC timestamp of when this snapshot was captured, for example "2026-07-20T13:00:00Z".
confidence
float
required
A quality score from 0.0 to 1.0 representing how completely the probe was able to semantically label the application’s state. NSP uses this score to gate which action reversibility tiers you can invoke:
context
object
required
Navigational context describing where within the application the probe was focused at capture time.
objects
object
required
The semantic state of the application as a flat key-value map. All keys use dot-notation with bracket indexing — for example "inbox.emails[0].subject" — rather than nested JSON objects. This design lets you reference any value with a single stable string key and perform prefix queries without traversing a tree.Value types can be number, string, boolean, null, object, or array. Keys are stable across poll cycles for a given app_id and schema_version: the same key always refers to the same semantic concept.
To retrieve all keys belonging to a subtree, query by prefix — for example all keys starting with "inbox." give you the full inbox model.
actions
object
required
A map of action name to ActionSchema describing every action the probe has discovered on this substrate. Keys are the action names you pass to POST /action; values are the full schema objects including signature, reversibility, parameters, and per-action confidence.
probe_metadata
object
required
Internal telemetry from the probe run that produced this snapshot. Useful for diagnosing latency, cache behaviour, and probe tier selection.

Full JSON Example


The Dot-Notation objects Format

NSP deliberately stores all application state as a flat key-value map rather than nested JSON. Every key is a dot-notation path that encodes the full hierarchy in a single string:
This design has two practical benefits. First, you can retrieve any specific value with a single key lookup — no need to traverse a tree structure. Second, prefix queries let you pull an entire subtree by filtering keys that start with a common prefix (for example "inbox.emails[0]." to get all fields on the first email). Keys are stable across poll cycles for a given app_id and schema_version. When schema_version increments to a new minor or major version, new keys may appear and, in major-version cases, existing keys may be renamed — verify your key names against the updated schema when you detect a version change.