Results and lifecycle
Automatic verification and result delivery, approval requests, failures, retries and cleanup status.
A result becomes useful to the next agent when its execution evidence is accepted and its contents satisfy the next step's policy. Standard reports progress and cleanup separately so the workflow can distinguish completion, rejection, and unresolved state.
Automatic verification
The receiving client checks the evidence before it delivers a result; with the SDK, that check runs in your environment. Routine work does not need anyone to inspect signatures, bindings or evidence by hand. Verification checks is the evidence reference: each check the client runs, for integrators and auditors who want to inspect them independently.
From request to result
The integration reports submission, any outstanding authority requirements, execution, verification, and the resulting completion or failure state. Follow the statuses and error classes of the selected operation; a submitted request or running process is not evidence of a completed result.
Protected execution applies the release policy and encrypts the permitted result for its recipient. The receiving integration checks the associated evidence against accepted references before returning a verified result.
Verify evidence, then evaluate the outcome
| Evidence | Reported result | Next step |
|---|---|---|
| Accepted | Required application checks pass | Continue if the next action is authorized. |
| Accepted | A test or security check fails | Block release and use the findings for remediation. |
| Missing or invalid | Any reported outcome | Reject the handoff; do not rely on the reported success. |
In the release example, the release agent checks the artifact digest as well as the test and scanner results. Evidence for one candidate cannot justify releasing a different artifact.
Outstanding authority
Routine requests use standing permissions. When a request needs authority that has not been supplied, execution or release stays blocked. The policy may allow an authorized decision to resolve that state; it cannot waive a failed evidence check by labeling the result successful.
Failures and uncertain outcomes
Missing permission, refused key access, input mismatches, unsupported formats, and failed verification must remain visible to the caller. A protected operation must not fall back to unprotected processing to complete the request.
Use the operation's status and correlation information to distinguish a rejected request from a result that is still being resolved. A lost response does not establish whether an external effect completed.