Structured task handoff

The structured handoff package carries a selected task timeline and selected history records between Flightops users. It is a historical, quarantined package. Import does not update the source task, adopt execution permission, inherit review, or make a procedure executable. Inspection never opens an original task artifact path.

Export a selection

Run flightops handoff export TASK PACKAGE --catalog HISTORY with one or more --event-sequence N, --experiment-id ID, and --record-id SHA256 options for the rows to include. The default selection contains no task events, experiments, native history records, or payload bytes. Selecting an experiment retains its complete existing attempt timeline, including prepared, not-started, failed, aborted, and retained attempts, and includes the task events that refer to that experiment or its attempts. Other task events, experiments, attempts, referenced history records, and bytes appear in explicit omission inventories.

--allow-metadata-sharing is an explicit local owner confirmation for the selected task and history metadata. It is separate from --payload-id and --allow-source-payload-sharing. Task artifact bytes can be selected by their source_artifact_id only when a selected evidence receipt binds that source to a task artifact digest. Managed recordings use recording-segment:<segment-id> and require the recording catalog's read-lease API. Each copied payload requires current caller authorization for both share and retain, a current source-use decision across its upstream lineage, stable regular-file identity, and digest/size equality. Source policy IDs and upstream source IDs are retained in the manifest for later revocation review. Payloads are streamed under byte, item, disk-reserve, and wall-time bounds. The package directory is created without overwrite and its manifest is published last.

Example:

flightops handoff export \
  /var/lib/flightops/tasks/camera.json /tmp/camera-handoff \
  --catalog /var/lib/flightops/history.sqlite \
  --experiment-id 0123456789abcdef0123456789abcdef \
  --record-id 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef \
  --allow-metadata-sharing

The command line flags are local confirmations; embedding applications should provide current authorization callbacks backed by their own owner/session controls rather than infer consent from package contents.

Import and reopen

flightops handoff import PACKAGE QUARANTINE imports metadata only. To retain selected bytes in quarantine, repeat --payload-id SOURCE_ARTIFACT_ID, pass the recipient's --catalog, and explicitly confirm --allow-local-retain. The importer verifies the complete source package, then checks recipient-local current retain policy and authorization for each selected source. Sender policy records are historical evidence; they do not grant recipient access. Payloads that fail current checks stay excluded while the task timeline remains inspectable.

Use flightops handoff list QUARANTINE to list bounded imports and flightops handoff inspect QUARANTINE HANDOFF_ID to reopen the selected timeline, included history records, omissions, export-time policy lineage, and the separate installed-payload status. Every inspection reports quarantined_historical, execution_authorized: false, review_inherited: false, and original_paths_resolved: false. An imported payload marked retained_quarantined is a verified local byte copy, not a current execution, analysis, or review grant.

The package uses flightops.structured-handoff/1 with a canonical manifest digest. Each embedded native record retains its history record digest and schema. Import rejects malformed schemas, digest mismatches, unsafe members, and changed included bytes. The importer creates a new no-overwrite local directory and never follows a package path outside its root.

Bind a configuration snapshot to task history

flightops_tools.tasks.bind_snapshot(...) can bind an experiment, one of its attempts, or its retained result to an existing configuration snapshot and evidence receipt IDs. The catalog records must validate before the task changes. The same binding is idempotent; a different binding is rejected. Existing rows without snapshot_binding remain unbound/unknown. This reference records which configuration and evidence records were selected; it does not assert that the hardware was observed in that configuration.