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.
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.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.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).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.The runtime environment detected for this application. Controls which probe strategy NSP uses and sets the baseline confidence ceiling.
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.
ISO 8601 UTC timestamp of when this snapshot was captured, for example
"2026-07-20T13:00:00Z".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:Navigational context describing where within the application the probe was focused at capture time.
The semantic state of the application as a flat key-value map. All keys use dot-notation with bracket indexing — for example To retrieve all keys belonging to a subtree, query by prefix — for example all keys starting with
"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."inbox." give you the full inbox model.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.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:
"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.