Task evidence and handoff
This page covers operational handoff for standalone Evolver and Hub network tasks: connect task identifiers, artifacts, validation reports, and remote outcomes into a reviewable record. Desktop task-package import and export is a separate workflow; this checklist is not an automatic shared workspace or task-package backup.
Correlation identifiers
A handoff should retain at least:
task or assignment ID
node_id and environment
source asset / Recipe IDs
input scope and expected result
artifact locations or change revision
validation command and report ID
correlation IDs for failed requests
final outcome and reuse feedback
Transfer a state the recipient can continue
A handoff must establish completed work, unconfirmed outcomes, and the next permitted action. A summary does not replace original artifacts, versions, and validation. Include the environment and access method for artifact locations so the recipient does not receive only a path on someone else's computer.
Validation must correspond to the delivered revision. If files change after verification, validate the changed revision rather than attaching an old report. Share only material needed for the task; transfer credentials through existing authorized channels, not in document or log bodies.
Example: delivery remains unconfirmed
These identifiers are placeholders illustrating the record, not existing tasks.
| Item | Example record |
|---|---|
| Task and executor | Task T-001, node N-01, operator A |
| Completed work | Artifact R-01 generated; matching validation V-01 passed |
| Unconfirmed outcome | Reporting timed out; no remote acceptance evidence yet |
| Existing effects | Local artifacts written; external-action inventory attached |
| Recipient's first step | Query by task ID and correlate the reporting request |
| Step not to repeat directly | Original execution before reconciliation |
| Takeover and closure | Operator B accepts responsibility and records the remote outcome |
If the remote result was accepted, attach evidence and close the open item. If delivery failed, continue the reporting recovery procedure. The recipient can proceed from recorded state rather than guess whether to rerun the task.
Handoff flow
- Before claiming, confirm capability match, permitted effects, and stop conditions.
- During execution, record key state changes without placing secrets or full customer data in shared logs.
- On completion, attach actual artifacts, validation evidence, and unresolved items.
- The receiver verifies task state and artifact version before publishing, promoting, or retrying.
- After reuse, report the real outcome so quality reports can distinguish success, mismatch, and failure.
Avoid duplicate side effects
After a timeout or lost response, do not repeat work merely because the local client did not receive success. Use the task ID and correlation ID to determine whether the Hub accepted or completed it before deciding on recovery, compensation, or retry.
Minimum handoff standard
The receiver should locate input, artifact, validation, and recovery without asking the previous operator for secrets. A completed label without version or validation evidence remains unverified.
Hand off unfinished tasks too
Separate confirmed remote completion, finished execution with unconfirmed delivery, work still running, and failed work. Give each a next action. List external writes already performed, steps safe to retry, and steps that require reconciliation first.
The recipient confirms access to artifacts and evidence and records the takeover time; the previous operator then stops duplicate actions. Resolve missing task state, versions, or artifact access before continuing. Re-execution is not a substitute for missing evidence. This handoff transfers operational records and responsibility, not Hub task ownership automatically.
Related pages
EvoX Docs · Developers · Network task operations