Skip to main content
VerificationOutcome is the result of evaluating a verify_expression against the application’s post-action state. Rather than trusting an HTTP 200 response to confirm that an action had its intended effect, NSP probes the runtime after execution and evaluates a JavaScript-style boolean predicate directly against the live objects map. This gives your agent ground-truth confirmation — for example, that a sent email actually incremented the sent count, or that a drone actually changed flight mode. You receive a VerificationOutcome inside every ActionResponse when a verify_expression was provided, and as the direct response body of POST /verify.

​
JSON Example

​
Fields

​
boolean
required
true if the verify_expression evaluated to true within the verify_timeout_ms window. false if the expression never became truthy before the timeout expired. When passed is false, the HTTP response status is 422 Unprocessable Entity and ActionResponse.success is false. See verification failure behavior below.
​
string
required
The exact verify_expression string that was evaluated — echoed from the request so you can log outcomes without cross-referencing the original request.
​
boolean
required
The final evaluated result of the expression. For a successful verification this is true. For a failed verification this is false, but it may also be null if the expression could not be evaluated (for example, because a referenced key did not exist in the state map after the timeout).
​
string
required
A human-readable narrative of what happened during verification, generated by the daemon. For a passing verification this describes when it passed; for a failure it describes what value was seen and for how long. Examples:
  • "Expression evaluated to true after 2 poll cycles (280ms)"
  • "inbox.sent_count remained 14 after 10 poll cycles (5000ms). Action may have failed silently."
​
integer
required
The total time in milliseconds spent in the verification polling loop, from the post-action settlement wait through the final poll cycle.
​
integer
required
The number of state probe cycles run during verification. The daemon polls approximately every 500ms, so a 5-second timeout yields up to 10 cycles. A poll_cycles value of 1 with passed: true means the expression was satisfied on the very first check after the post-action settlement delay.
​
array
required
An array of field diffs describing every objects key whose value changed between the pre-action snapshot and the final post-action snapshot. An empty array means no observable state change occurred — which is expected for read actions and may indicate a silent failure for write actions.

​
Verification Failure Behavior

When passed is false, the daemon returns HTTP 422 Unprocessable Entity. The action may have already executed — ActionResponse.executed will be true if the action was dispatched. A 422 means the post-action state did not confirm the expected outcome within the timeout, not necessarily that the action had no effect. A failed VerificationOutcome looks like this:
When you encounter a 422, consider these steps:
  1. Inspect changed_fields — if it is empty, the application state did not change at all. The action may have been silently no-oped by the application.
  2. Increase verify_timeout_ms — if changed_fields shows the right fields changing but too slowly, the action is working but your timeout is too short.
  3. Revisit your expression — if changed_fields shows changes but passed is still false, your expression may reference a stale or wrong key.
  4. Check confidence — retrieve a fresh SubstrateState and verify the confidence score is above the threshold for the action’s reversibility tier.