7. Verified Outcome

A task does not reach the end of the AG Arch lifecycle simply because execution has stopped.

It reaches the end when the intended result has been demonstrated by evidence.

That is what AG Arch calls a Verified Outcome.

The distinction is central:

work completed is a statement about activity.

verified outcome is a statement about reality.

Verification closes the gap between action and result

Earlier stages established:

• what was intended;
• what reality looked like before the work;
• what success would mean;
• what authority and constraints applied;
• which capability performed the work;
• what actually happened afterwards;
• what evidence was collected.

Verified Outcome brings those pieces together.

The final question is not:

Did the agent finish?

It is:

Does the evidence show that the intended result is now true?

Only when the answer is supported by the required evidence should the work be treated as successfully completed.

PROVEN is more than “no errors”

An execution can finish without errors and still fail to produce a verified outcome.

Likewise, an agent may confidently report success while the evidence tells a different story.

For AG Arch, a successful lifecycle requires a PROVEN result.

That means the observations and evidence support the success criteria established before execution.

For example, if success required:

• a configuration change;
• a healthy running service;
• no unintended changes elsewhere;

then all of those relevant conditions need to be supported by the evidence.

The absence of an obvious error is not enough.

Verified Outcome is tied to the original intent

Verification should not drift away from the reason the work existed in the first place.

Suppose an agent was asked to restore a service.

During execution it successfully updates several files and restarts multiple processes.

Those actions may all succeed technically.

But if the service is still unavailable, the original intent has not been satisfied.

AG Arch therefore connects the final result back through the entire lifecycle:

Intent → Success Criteria → Execution → Observation → Evidence → Verdict → Verified Outcome

This prevents a sequence of successful intermediate actions from being mistaken for a successful final result.

A verified outcome should be explainable

A useful verified outcome should make it possible to understand, at an appropriate level:

• what was supposed to happen;
• what actually changed;
• what evidence was used;
• which criteria were satisfied;
• why the result was considered proven.

That does not mean every user needs to see every low-level log or technical detail.

Different audiences may need different views.

But the conclusion should remain traceable to the evidence behind it.

This is what allows a human, another agent, or a later process to distinguish a genuine verified result from an unsupported completion claim.

Verification does not require a human to inspect every result

A verified outcome does not mean that a person must manually approve every autonomous task.

If the success criteria, evidence requirements, and evaluation rules are already clear, the system can perform much of that verification autonomously.

Human involvement should remain exceptional rather than becoming the normal completion mechanism.

For example, a routine configuration change may be verified automatically through:

• authoritative state checks;
• health checks;
• functional tests;
• protected-state comparisons.

If those checks provide the required proof, another manual confirmation adds little value.

Verification is only as strong as the evidence behind it

A `PROVEN` label should not become an empty status.

Its value comes from the evidence supporting it.

If required evidence is missing, unreliable, stale, or contradictory, the system should not declare a verified outcome merely because the task appears likely to have succeeded.

This is why AG Arch keeps the proof requirement connected to the work from the planning stage onward.

The standard should not be lowered after execution just to reach completion.

NOT PROVEN does not disappear

If the verdict is NOT PROVEN, the lifecycle does not manufacture a successful ending.

Instead, the unresolved result remains explicit.

That may lead to:

• another observation;
• additional evidence collection;
• replanning;
• different authority;
• another capability;
• safe termination.

Those paths belong to the Recovery part of AG Arch, which we will describe separately.

The important point here is simple:

unproven work does not become a verified outcome.

Verified Outcome can become new reality

Once an outcome is proven, the resulting state may become part of the current reality for whatever happens next.

This creates continuity between autonomous tasks.

For example, after a verified configuration change, the new configuration is no longer merely the result of the previous task.

It is now part of the real environment that future work must observe.

This makes the lifecycle naturally recursive:

one verified outcome can become the starting reality for the next governed task.

Example — changing a system configuration

Continuing the same example:

The intended result was:

• the approved configuration is active;
• the running service is using it;
• the service remains healthy;
• unrelated settings remain unchanged.

Execution completed.

Observation then showed:

• the approved value is active;
• the service is using that value;
• the health check passes;
• unrelated configuration remains unchanged.

The evidence supports every required success criterion.

The verdict is therefore:

PROVEN

Only now does AG Arch treat the work as a Verified Outcome.

The final statement is no longer:

“The agent changed the configuration.”

It becomes:

“The required configuration is active, the running service is using it, the service remains healthy, and the protected settings remain unchanged. The intended outcome is proven.”

That is a much stronger form of completion.

What the lifecycle has achieved

The full lifecycle has now moved from an initial goal to a result that can be supported by evidence:

Intent & Reality established where the work began.

Define Success established what the result needed to look like.

Plan & Govern established the route, authority, constraints, and required proof.

Handoff & Route selected the capability that would perform the work.

Execute performed the controlled action.

Observe & Prove examined the resulting reality and produced the evidence and verdict.

Verified Outcome closes the lifecycle only when that evidence supports the intended result.

The lifecycle explains the main flow of governed autonomous work.

The next part of the guide explains the systems that support that flow continuously: