What verified workspace restoration actually means

Verified workspace restoration means comparing the intended final state with a new observation of the real desktop. It is not enough for an operating-system API to return success, for an animation to finish, or for most windows to look approximately right.

The distinction sounds strict because it is. Reliability is the product.

An accepted command is not an observed outcome

Desktop automation crosses process boundaries. Orvial may request that another application move or resize a window, but that application remains part of the result.

Apple’s AXUIElement reference makes that boundary visible in the API itself: accessibility messaging can fail to complete when another application is unresponsive or waiting for input.

It can delay the change, clamp the geometry, resist the requested size, recreate the window, or stop responding. The operating system may accept a request while the visible workspace ends in a different state.

A system that reports success at the API boundary measures its own intention. A system that verifies measures the user-visible outcome.

Verification is property-specific

“The window is correct” is not one indivisible fact. Identity, display assignment, geometry, minimized state, fullscreen state, application context, and focus can each have different evidence and tolerances.

A final result may therefore be partially confirmed. Geometry can be verified while a fragile application context remains unconfirmed. A deliberate display-role fallback can be fully verified while still being reported as a fallback.

Collapsing those distinctions into one green check would lose information that matters for recovery and trust.

Unknown is not false

Suppose a window enumeration is incomplete. Failing to find a matching window does not establish that the window is absent. Opening a replacement in that state could create a duplicate.

This is one of Orvial’s most important evidence rules:

Insufficient evidence may prevent action. It may never be upgraded into certainty merely to appear successful.

That affects both planning and verification. A fresh observation can still be incomplete. A cached binding can still be stale. Evidence remains attached to the value it supports so later decisions can judge its quality, scope, and generation.

Three outcomes are better than one vague failure

The public product language is still being shaped, but the core distinctions are clear:

Verified

Fresh, relevant evidence confirms that the property matches the resolved desired state.

Unresolved

The desired state could not be safely resolved or applied. An unavailable display role, unsupported fullscreen behavior, or a failed safety condition can make this the correct answer.

Unconfirmed

The action may have occurred, but the available observation cannot prove the result. Unconfirmed is not silently promoted to verified, and it counts against a promise of correct and verified restoration.

Verification should drive recovery

Verification is not an audit log appended after the useful work. Its result determines what happens next.

A bounded recovery strategy can re-observe, retry a safe action, wait for a known settle period, or explain that an application resisted. The same process also creates better diagnostics because the system knows which intended property failed and what evidence was available.

Retries remain bounded. Repeating an uncertain mutation forever is not reliability.

Measurement must preserve failed runs

When Orvial eventually makes reliability claims, the measurement methodology matters as much as the percentage.

Failed runs cannot disappear because a later fix exists. A fix begins a new campaign. Unconfirmed results count against headline reliability. Claims apply only to populations covered by an independent oracle. A campaign runs to its planned sample count rather than stopping when interim results look good.

This discipline is less photogenic than a launch animation. It is also how a trustworthy product is made.

In summary

• API success proves only that a request was accepted at some boundary.
• Verification re-observes the actual final workspace.
• Properties can be independently verified, unresolved, or unconfirmed.
• Evidence quality and completeness stay attached to observations.
• Recovery responds to verified differences and remains bounded.
• Reliability claims preserve failures and measurement context.

The goal is not to make every run look successful. The goal is to know what actually happened—and to make that outcome dependable over time.