A handoff is complete only when the next owner can check what happened, see what remains unresolved and decide whether to take responsibility. If the receiver must reconstruct the work, the transfer has failed.
The UK Health and Safety Executive describes effective shift handover as preparation by the outgoing person, a two-way exchange and a cross-check by the incoming person as responsibility changes.[1] Its guidance concerns safety-critical work. MAJLS adapts that sequence here without equating payroll review with industrial risk or implying HSE endorsement.
The MAJLS handoff acceptance checklist
Use these five blocks when responsibility moves between a rule, an AI-assisted preparation step and a named person. This is a MAJLS framework, not an HSE or NIST standard.
1. Name the transfer
Record:
- the work item and its stable identifier;
- the outgoing owner and incoming owner;
- the handoff time and the version being transferred;
- the exact responsibility that changes hands;
- the next required action and its due time.
"Sent to payroll" is not a transfer definition. Name the version, receiver, responsibility and next decision.
2. Record the state and evidence
The receiver needs the last completed step, current status, source versions, checks already performed and direct links to supporting records. NIST's AI Risk Management Framework says information about an AI system's knowledge limits, the way output may be used and human oversight should be documented well enough to support later decisions and actions.[2]
For an AI-assisted step, add its sources, transformation, validation result and known limits. Link every generated summary to inspectable source records.
3. Expose exceptions
List each unresolved item separately. Give it:
- a plain description;
- the affected record or process step;
- the observed business impact;
- the next action, owner and due time;
- the condition that would clear it.
The receiver should be able to count the open items and see who owns each one.
4. State the authority boundary
Write down what the receiver may decide, what requires another approver and what nobody in this handoff may do. NIST also calls for policies and procedures that distinguish human and AI roles and responsibilities.[2]
This block matters even when the receiver is senior. The handoff may transfer review responsibility without transferring authority to change master data, approve a payment, release funds or submit a regulated filing.
5. Require a receiving cross-check
The incoming owner checks the work item, source version, control totals, required approvals, evidence links and open exceptions. The result must be one of three states:
- Accept: the package is complete enough for the stated next step, and the receiver records the time and scope accepted.
- Return: a named field, check or source is missing or inconsistent, so the outgoing owner receives a reason and correction request.
- Escalate: the issue cannot be resolved inside either owner's authority, so it goes to a named person with the evidence and required decision.
Acceptance transfers responsibility for the next step; it does not approve the business outcome.
Filled example: monthly payroll-file review handoff
This is an illustrative example using synthetic identifiers and control values. It is not a client workflow, payroll instruction, legal advice, deployment or performance claim.
An overnight preparation role receives a file already approved for preparation. It checks structure, records source versions, reconciles non-monetary controls and assembles a review pack. A payroll controller accepts, returns or escalates it. Only the authorized payroll owner may approve submission.
Transfer block
| Field | Filled value |
|---|---|
| Work item | PAY-SEP-04, synthetic identifier |
| Outgoing owner | Overnight payroll preparation role |
| Incoming owner | Payroll controller |
| Handoff time | 29 September 2026, 07:30 Gulf Standard Time |
| Version | Review pack v4 |
| Responsibility transferred | Validate the prepared file and evidence before the submission decision |
| Next action | Complete controller review by 10:00 GST |
State and evidence block
| Check | Recorded state |
|---|---|
| Approved input file | Source version IN-04 linked; approval record linked |
| Expected structure | Required columns present; schema version P-7 recorded |
| Record reconciliation | Input count 742; prepared count 742 |
| Control token | Input token H-9921 matches prepared token H-9921 |
| Duplicate identifier check | No duplicate synthetic employee tokens found |
| Evidence pack | Source hash, validation log and exception register linked |
The preparation role records what it checked, not whether the payroll should be approved. It may not alter employee master data, interpret deductions, choose payments, approve payroll, release funds or submit the file.
Exception block
| Exception | Impact | Next action | Owner | Due |
|---|---|---|---|---|
| Token EMP-018 has no cost-centre value | One record cannot pass the agreed completeness check | Confirm the source value or mark the record for approved exclusion | HR data owner | 09:00 GST |
| Approval link for source annex A returns access denied | Controller cannot verify one source approval | Restore controller access or supply the approved record through the authorized repository | Payroll operations lead | 09:15 GST |
Neither exception becomes "low risk" because a model assigns a high confidence score. The observable conditions are a missing required value and unavailable approval evidence.
Authority block
| Role may | Role may not |
|---|---|
| Preparation role may validate structure, reconcile agreed controls and assemble evidence | It may not edit master data, decide deductions, approve payroll, release funds or submit |
| Payroll controller may cross-check the handoff and request corrections | The controller may not treat acceptance of the pack as submission approval unless the organization's policy separately grants that authority |
| Authorized payroll owner may decide whether to approve submission under the organization's policy | No automated role may assume or infer this authority |
Receiving decision
The payroll controller returns the pack because the approval link cannot be verified. The recorded reason is: "Source annex A approval evidence is inaccessible to the receiving owner." The controller also escalates the unresolved employee record to the named HR data owner because the preparation role has no authority to supply or infer the missing value.
Consequential approval remains with the named human payroll owner. The controller can accept the corrected handoff for review, but only the authorized payroll owner can approve submission. Escalation relies on missing evidence, mismatched controls, unresolved records, missed due times and authority limits; model confidence alone never triggers acceptance, escalation or approval.
First-run checklist
Before using this pattern in a live process:
- choose one handoff and name both owners;
- define the stable work-item identifier and version rule;
- list the source records and checks the receiver must be able to reproduce;
- create a visible exception register with owners and due times;
- write the receiver's authority and prohibited actions;
- test accept, return and escalate paths with synthetic records;
- require a recorded receiving cross-check before responsibility changes;
- keep the final business approval with the person named in the organization's policy.
A useful handoff does not ask the next owner to trust the previous step. It gives them enough evidence to check it, challenge it and take responsibility without starting again.