Verify the Work, Not Just the Assistant’s Answer

An assistant can return a polished answer and still leave the real work unfinished. The draft may exist but not be saved. The setting may look correct but not survive a reload. The message may be sent but never delivered. The report may sound certain while resting on incomplete evidence.

Verification closes that gap. It asks a plain question: what evidence would make the claimed result true?

Treat the answer as a claim

“Done” is not proof. Neither is a confident explanation of what the assistant intended to do. Treat every completion statement as a claim that should be matched to observable evidence.

The evidence should fit the consequence. A spelling correction may need a saved-page readback. A payment change needs stronger controls, exact account and mode checks, and proof that the intended configuration persisted. Higher-consequence work deserves stronger verification.

Define proof before the work begins

Verification becomes easier when the completion test is part of the assignment. Before delegating, name:

• The exact outcome that should exist.
• The source or system that is authoritative.
• The check that proves the change persisted.
• The protected items that must remain unchanged.
• The exceptions that require your review.

For example: “Update the appointment page to use the approved event. Reload the saved page, open the public link, confirm the correct event name and booking path, and do not change availability or payment settings.”

Verify the right layer

Different checks prove different things. Use the layer that matches the claim:

• Source check: confirms what was entered or configured.
• Persistence check: reloads or reopens the authoritative system to confirm the change remained.
• Rendered check: confirms what a visitor or customer can actually see and use.
• Delivery check: confirms that an external result, such as an email, reached its destination.
• Preservation check: confirms that adjacent records, settings, or protected content were not changed.

A save notice proves that a save was attempted. A reload is stronger evidence that it persisted. A sent status is not the same as inbox delivery. A screenshot of one screen does not prove a full workflow.

Check the exception, not only the happy path

When a workflow matters, verify at least one likely failure condition. What happens when a required field is empty, a link is opened while logged out, an address already exists, or a permission is missing?

You do not need exhaustive testing for every small task. You do need a check proportionate to the risk. The point is to avoid declaring success from the one path most likely to work.

Report what remains unverified

An honest return separates four states: changed and verified, changed but not yet verified, inspected but unchanged, and blocked by a missing decision or external condition.

This matters because uncertainty is not failure. Hidden uncertainty is. If delivery, mobile behavior, account recovery, or a legal commitment has not been tested, say so directly instead of allowing a nearby check to stand in for it.

Keep the human attached to consequential proof

The assistant can gather evidence, compare expected and observed results, and flag exceptions. The human should retain approval where the evidence affects money, legal commitments, privacy, public claims, or irreversible action.

This is why human-controlled AI executive assistance is not merely about assigning more work. It is about connecting authority, completion, and evidence so that the person responsible can see what actually happened.

What we are exploring with Orabuena

Orabuena is in private research and product discovery. We are exploring how verification requirements and evidence can travel with delegated work across tools. This is a product direction under evaluation, not a promise of generally available functionality.

If you have received a convincing “done” answer and still had to reconstruct what happened, share that experience with our research. Research participation is separate from product-update emails, a Founding 20 application, and any future purchase.