Verification as a product principle

The design question

How should a system represent work when an AI can propose actions, tools can fail in ambiguous ways, and people need to understand what actually happened? This note describes a principle in the Modeus architecture. It is a discussion of the design, not a report of measured production performance or a peer-reviewed research result.

The starting point is a separation between intent, execution, and verification. Intent describes the outcome being requested. Execution records the attempt to change something. Verification examines evidence about the resulting state. Keeping those concepts distinct prevents a successful tool response from becoming an unsupported conclusion about the wider objective.

The claim and its evidence belong together

Suppose a task asks for a particular field in a shared record to be updated. The action request has a target, arguments, and an expected change. A response from the tool may confirm that it accepted the request. A separate read of the resulting record can help establish whether the requested value is now present. These events provide different kinds of evidence.

The design ties evidence to the specific claim it supports. It also retains the relevant source, version, and time of observation. This is useful when the surrounding world changes: a check against an earlier version should remain a record of that earlier check, rather than silently becoming proof about the current state.

Unknown is a meaningful outcome

An action can have an unknown outcome when a system loses contact after a request may have reached its destination. Marking the attempt as a simple failure can encourage an unsafe retry. Marking it as a success can conceal unfinished work. A distinct unknown state allows the system to pursue reconciliation: inspect the target, seek a receipt, or ask for a human decision.

This has a product consequence. The interface needs to show the uncertainty prominently, explain what is known, and make the next recovery step legible. A long activity log is not enough if the user cannot distinguish a completed result from an unresolved attempt.

• Keep the requested change distinct from the attempt to perform it.
• Record the check and the evidence behind each conclusion.
• Preserve uncertainty when the available evidence cannot settle an outcome.
• Reconcile ambiguous external actions before deciding whether to repeat them.

A question for the interface

The Modeus architecture asks whether a person opening a consequential run can quickly identify the objective, the actor, the policy or approval, the external effects, the verification result, and the remaining uncertainty. This is a design goal for comprehensibility. It is not a claim that every future workflow can be reduced to one universal check.

Further evaluation should examine whether reviewers correctly distinguish verified, failed, and unresolved outcomes across realistic tasks. It should also test whether the evidence is sufficient for an independent reviewer to reach a defensible conclusion. The product principle is simple: the strength of the completion claim should match the strength of its evidence.