V4.02.5Reassignment provenancedesignresearch

Reassignment should preserve the original assigner to maintain accountability

Aliases: assignment history · responsibility chain · task transfer record

What it is

Reassignment provenance preserves the original assigner, transfer initiator, successive owners, timestamps, and reasons when task ownership changes. The current assignee answers who acts now; the responsibility chain explains how the task arrived there and who ensures continued coverage. Overwriting an avatar erases an allocation decision rather than documenting a handoff.

Why it happens

Reassignment changes execution responsibility but does not automatically transfer context, access, or oversight. Without history, the new owner cannot readily recover the source of scope, while the assigner may assume that handoff is complete. Append-only transitions reconstruct the decision path, distinguish legitimate rematching from repeated deflection, and expose patterned burden concentration.

Studying it

In scenarios with repeated transfer, refusal, and absence, compare current-owner-only displays with complete chains on reconstruction accuracy, handoff omissions, resolution time, and attribution disputes. Field logs can examine depth, reason, bounce-backs, and role concentration, followed by interviews about motive. High transfer counts are not inherently harmful when task requirements change.

Where it stops holding

A responsibility chain should not become a public blame board; load balancing and expert escalation require healthy transfer. Sensitive personnel history may need restricted access or scheduled deletion. The original assigner need not retain execution responsibility indefinitely, but some role must maintain coverage until the new owner accepts.

Applying it

  • Record transfer as an appended event with initiator, old and new owner, time, reason, and acceptance state.
  • Carry scope, progress, dependencies, and deadline into the transfer and require recipient confirmation.
  • Identify who follows up while acceptance is pending so responsibility never becomes ownerless.
  • Audit repeated transfers, bounce-backs, and concentration to fix description, access, or capacity causes.

Related

  • Same group: V4.02.1 Assignment versus claiming · V4.02.2 Information needed for claiming · V4.02.3 Fallback assignment · V4.02.4 Acceptance as commitment
  • Adjacent: V4.04 Versions, Change Sets, and Diffs · V4.05 Handoffs and Context Transfer
  • Search terms: reassignment provenance · responsibility chain · task handoff

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/V4.02.5