Assignment Workflow

The real problem: “Assigned To” is not responsibility

A work item can show a person, a due date, and a delivered notification while still lacking proof that the person accepted responsibility for the current version of the work. We need to know who had authority to assign, which role and scope the assignee accepted, which plan/version governed the work, and what actually transferred at handoff or reassignment. The owned artifact is Assignment State and Responsibility Ledger v1.

Owned boundary

COM-023 owns assignment and responsibility workflow only. Vetting/test-job quality belongs to COM-022; creator/media inventory belongs to COM-024. Assignment authority is also separate from review approval and publication authority. This lesson performs no live hiring, production reassignment, publishing, or external mutation.

Mental model: keep four things separate

1. Work identity: assignment_id and work_item_id identify the unit of work.
2. Responsibility binding: assignee, role, assigner, and assignment_authority show who proposed responsibility and whether the actor could do so.
3. Version binding: plan_id/plan_version, input_refs, and scope_version show exactly what was accepted.
4. Lifecycle evidence: acceptance, start, handoff, reassignment, submission, review, and audit are separate events.

A notification is a message; acceptance is a responsibility event. Changing an assignee field is a UI mutation; a handoff is an evidence boundary.

Separate FACT, INFERENCE, and DESIGN

FACT: PROV-O is a W3C Recommendation and models provenance with Entity, Activity, and Agent. Association and delegation express responsibility relationships; qualified association can additionally describe role and plan. INFERENCE: auditability improves when acceptance and handoff are events rather than only the latest Assigned To value. DESIGN: ACCEPTED, DECLINED, IN_PROGRESS, HANDOFF, REASSIGNED, SUBMITTED, plus fail-closed HOLD/BLOCKED/DISPUTED, are MAKNOW workflow states; W3C does not prescribe them.

The 21-dimension Assignment Ledger contract

1) assignment_id and work_item_id

An assignment has its own lifecycle. Reassigning the same work item does not necessarily create a new work item, but assignment history must not be overwritten.

2) Assignee, role, assigner, and authority

assignee_id identifies who; assignee_role says in what role; assigner_id identifies the actor initiating assignment; assignment_authority proves that actor could make the assignment. Reviewer approval cannot substitute for assignment authority.

3) Plan, inputs, and scope version

Acceptance without version binding is ambiguous. If a plan changes from v3 to v4, acceptance of v3 does not silently carry forward. At minimum, the delta and re-acknowledgement need evidence.

4) Acceptance is separate from notification

An email/push/chat delivery receipt proves message delivery only. acceptance_state=ACCEPTED needs its own evidence. DECLINED is also a legitimate state and should not be hidden as an unexplained failure.

5) Workflow state is event-based

IN_PROGRESS follows valid acceptance and a start event. HANDOFF marks the transfer boundary. REASSIGNED is bounded only when handoff is traceable and the new assignee accepts the current scope. SUBMITTED without output_ref is invalid.

6) Approval is separate from assignment

reviewer_id and approval_state describe review. They create neither assignment authority nor publication authority. This prevents the shortcut “the reviewer approved it, so responsibility transferred too.”

7) Audit/evidence is append-only

audit_event_id and evidence_ref make the chain reconstructable. Completed evidence is preserved through handoff; future responsibility starts at a new boundary.

Worked examples

1. Valid baseline -> IN_PROGRESS

An authorized manager assigns brief v3, Creator A explicitly accepts that scope, and a start event is recorded. Responsibility for the current scope is active.

2. Notification delivered, no acceptance -> HOLD

The UI shows Creator A and the notification was delivered, but there is no acceptance event. This is not a success state.

3. Plan v3 -> v4 without re-ack -> HOLD

Acceptance of v3 is useful evidence, but it does not prove acceptance of the new scope. Record the delta and a new acknowledgement.

4. Reassignment without handoff -> DISPUTED

Creator B replaces Creator A in Assigned To, but no handoff_id or evidence-preservation event exists. Past and future responsibility cannot be reliably separated.

5. Valid reassignment -> REASSIGNED

Creator A preserves completed evidence, a handoff event is recorded, and Creator B accepts the current scope. Assignment responsibility transfers; prior review approval does not.

6. Reviewer approval but no assignment authority -> BLOCKED

Review approval does not create the right to assign work.

Common failure modes

• Treating Assigned To as accepted responsibility.
• Treating delivered notification as acceptance.
• Changing plan/scope version while reusing old acceptance.
• Reassigning by overwriting the assignee field and losing handoff history.
• Dropping completed evidence from the prior assignee.
• Treating reviewer approval as assignment authority.
• Treating assignment authority as publication authority.
• Emitting SUBMITTED without output evidence.
• Filling missing evidence with optimistic guesses.

Alternatives and trade-offs

Mutable current row only: simple and cheap, but weak for audit and handoff. Event ledger + current projection: preserves history while keeping a fast current view; more modeling cost, but the recommended pattern here. Full workflow engine: useful for complex orchestration, but not required to prove this outcome. Get the evidence model right before choosing tooling.

Experienced bridge: 14 critical questions

Are assignment/work-item identities explicit? Are assignee and role explicit? Is assignment authority valid? Are plan and version known? Is scope version known? Is there an acceptance event for that exact scope? Does state match event evidence? Does reassignment have a handoff? Does submission have an output reference? Is an audit event present? Is evidence traceable? Was completed evidence preserved? Did review approval stay separate from assignment authority? Was the transfer decision recomputed rather than copied?

Guided and independent practice

Complete the baseline 21-dimension ledger and derive state only from visible evidence. Then run three mutations: notification-only, plan-version change without re-acknowledgement, and reassignment without handoff. For independent transfer, reassign a specialist mid-task because of capacity. Show which evidence stays, which responsibility transfers, and which approvals do not transfer.

Acceptable evidence

Minimum acceptable evidence includes assignment/work-item identity, assignee/role, assignment authority, plan/version, scope version, acceptance state, workflow state, handoff/output when applicable, audit event, and evidence reference. A human reviewer must be able to reproduce the decision from visible records; hidden reasoning or guesses do not count.

Assessment and transfer

Passing requires four things: the COM-023 boundary, a complete baseline ledger, diagnosis of one mutation, and the reassignment transfer. During transfer, completed pre-handoff evidence stays; the new assignee accepts current scope; review/publication approval does not silently transfer. If any decisive condition is missing, a success state is forbidden.

References and freshness

• W3C PROV-O: The PROV Ontology — Recommendation, 30 April 2013. Rechecked on 2026-09-15; it remains the stable Recommendation covering Entity/Activity/Agent, Association, Role, Plan, and Delegation. https://www.w3.org/TR/prov-o/
• The workflow state vocabulary and authority split in this lesson are MAKNOW DESIGN, not W3C requirements.
• Evolving practice claims are reviewed by 2026-12-31 or earlier after materially relevant change.