Execution is an event. Verification is the proof.
ZENQIX keeps requested state, provider result, endpoint observation and verification separate so an administrator can tell what actually happened.
Success from the provider may still be incomplete.
If the endpoint reports a different state afterward, ZENQIX keeps the mismatch visible instead of converting it into success.
Software desired state
From finding to verified outcome.
The record shows why work was performed, who or what authorized it, what ran and what the endpoint reported afterward.
What condition or operational problem was observed.
Endpoint facts supporting the finding.
Who or what policy approved the action.
The structured administrative operation requested.
What the endpoint reported after execution.
Whether observed state matched the requested outcome.
Timestamped evidence retained for review.
Verified, mismatch and unknown are different results.
Observed endpoint state matches the requested outcome using the capability's verification method.
Execution completed, but the observed endpoint state does not match the request.
The system does not have enough fresh evidence to conclude success or failure.
Keep the facts needed for support and review.
The example is synthetic and bounded; it does not expose credentials or private environment details.
Evidence follows capability status.
Not every Preview action has completed platform-specific physical acceptance. Verification claims remain tied to the capability matrix and release evidence.
Evaluate verification with the product model.
Use Product Proof and the technical checklist to decide which outcomes your pilot must verify on physical endpoints.