Evidence changes the state; assignment does not
An assigned cleaning task tells the team that work is expected.
Read the details
An assigned cleaning task tells the team that work is expected. It does not show the work occurred, whether it applied to the correct property, or whether a responsible person accepted it. A completed task still needs the required evidence and verification before it can support a readiness decision.
The dated dashboard screenshot is helpful because it labels unfinished work as in progress or unverified. Treat it as a screen example, not proof that the same values or states are current now.
- Current
- In progress — the end-to-end evidence and verifier acceptance path is not confirmed as complete.
- Proposed next state
- Use a real, current turnover to record task evidence, verifier identity, decision time, and any exception.
- Expected outcome
- The team can explain why a property is ready or why it is not, without relying on a status label alone.
Checks to include when changing this section
- Use a fixture where the task is complete but evidence is absent; assert the output is awaiting evidence.
- Use a fixture where the evidence belongs to a different property; assert an identity exception.
Actors perform work; verifiers make readiness decisions
A useful turnover flow names the actor who performs or reports the work, the source record that identifies the stay, and the person authorised to accept the readiness result.
Read the details
A useful turnover flow names the actor who performs or reports the work, the source record that identifies the stay, and the person authorised to accept the readiness result. Those roles can be connected, but they should not disappear into one generic “done” label.
The actor should supply the missing result when evidence is absent. The verifier should record an accepted outcome only when supporting checks justify it. The operational display should make that distinction legible to the next person.
- Current
- Checked — this decision separation is a documented operating requirement; individual final ownership remains to be confirmed in live practice.
- Proposed next state
- Record current role ownership in the actual task and decision records rather than assuming a permanent staffing structure.
- Expected outcome
- A reviewer can identify who needs to act and who is allowed to accept the result.
Checks to include when changing this section
- Check the diagram identifies source, actor, evidence, verifier, and result nodes.
- Check a context prompt includes the selected actor/decision section, not the entire handbook.
Exceptions stay visible until the source or evidence is repaired
Provider information that is old or incomplete needs a coverage confirmation or a new source read.
Read the details
Provider information that is old or incomplete needs a coverage confirmation or a new source read. A task with no completion evidence needs a request for the missing result. A mismatched property identifier needs a verified reconciliation. Each exception has a different repair path.
Do not resolve these by silently promoting a card to ready. The correct outcome may be an explicit blocker for the next arrival, with a named owner and a scheduled next check.
- Current
- In progress — provider freshness and end-to-end verifier acceptance remain pending operational evidence.
- Proposed next state
- Capture the source window, exception type, owner, decision deadline, and closing evidence for every resolved exception.
- Expected outcome
- A missing fact becomes work that can be tracked and reviewed instead of an unsafe assumption.
Checks to include when changing this section
- Test stale provider data, missing evidence, and identity mismatch as distinct failure fixtures.
- Check no exception fixture emits an accepted readiness outcome.
Apply with care
A concrete safe example
Example, responsibilities & checklist
A conservative readiness decision
A cleaning job may say completed, but the property is only ready after the required evidence is linked to the confirmed property and an authorised verifier accepts the outcome. If the evidence is missing, show “awaiting evidence” and name the next action.
Responsibilities
- The source record identifies the correct departure and property.
- The assigned actor carries out or reports the work.
- The evidence reviewer checks the supporting result against the correct property.
- The authorised verifier records an accepted readiness outcome or a blocker.
Checklist
- Confirm source record, cleaning task, and readiness decision use the same property identity.
- Separate assigned, in progress, completed, evidence received, accepted, and exception states.
- Do not call a property ready because a display was repainted or a task was merely assigned.
- Give incomplete evidence a responsible owner and next check before the next arrival.
A next-arrival decision can be traced to a confirmed property, the right evidence, and a named verifier.
Traceability without sensitive material
Source pointers and exports
This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.
Documentation references
- Handoff / pages/workflows.html
- Handoff / START-HERE.html
- Handoff / pages/app-tour.html