What a verified outcome means

Define the result before the activity

A task can contain plenty of activity without achieving its objective. Someone can write a draft that answers the wrong question, update a record without resolving the original problem, or run a check against an outdated version. The visible motion is real. The intended result may still be missing.

Start by describing the state you want to reach. For a customer brief, that might mean a reviewed document covering the customer's current situation, unresolved needs, and agreed next steps. For an engineering task, it could mean a change that passes the relevant checks and addresses the reported behavior. The definition gives both the contributor and the reviewer a common target.

Choose evidence that answers the claim

Different claims require different checks. A file existing does not establish that its contents are correct. A successful submission does not always show that the receiving system now contains the expected state. A passing test supports what that test actually covers, and should not be stretched into a claim about every possible behavior.

The evidence should therefore be selected for the outcome being claimed. A reviewer might inspect the final document, compare the changed record with the requested fields, or examine a test result against the exact revision under review. The closer the check is to the claimed result, the easier it is to judge whether the work is ready.

• Claim: what are we saying has been achieved?
• Check: what would distinguish success from a plausible attempt?
• Evidence: which result or artifact supports that check?
• Limit: what has the check left unresolved?

Keep uncertainty visible

Sometimes the available evidence is inconclusive. A request may have been sent while the response was lost. A source may have changed during a review. A check may cover part of the task but leave an important dependency unresolved. Describing that state accurately helps the next person choose a sensible action.

Repeating an uncertain action is not always the right recovery. It can create duplicate records or repeated messages. A better first step is to inspect the resulting state, determine what is known, and identify what additional evidence would settle the question. Uncertainty becomes manageable when it is specific.

Make completion understandable

Modeus's architecture treats execution and verification as separate responsibilities. Its design links a plan, an action, the resulting evidence, and the conclusion drawn from that evidence. The practical benefit is a completion record that can be assessed by someone who did not watch the work happen.

Use a simple completion note for your next handoff: what changed, where the final result lives, how it was checked, and what remains open. This does not need to become a long report. It needs to give the next person a reliable basis for deciding whether to accept the work or ask for another pass.