# Turnover readiness: evidence before a ready decision

> In progress · 20 October 2026 · Wiki version 2026.10.20.2

A turnover prepares a property between stays. Assignment, cleaning completion, evidence, verification, and readiness are separate states that must refer to the same confirmed property.

## Purpose
Make the actor, decision, evidence, and exception path explicit so “ready” only appears when the supporting checks justify it.

## Diagram text alternative
A confirmed departure leads to assignment, then work evidence, then verifier decision. Accepted evidence becomes a readiness result; missing evidence or stale source information becomes an owned exception.

## Current / proposed status
- Current: In progress — Turno identity is confirmed, but full task/evidence/verifier acceptance is still pending.
- Proposed: Exercise one real turnover with an owner, evidence, and manager verification before treating the flow as accepted.

## Safe example
### 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 id="evidence-state"></a>

## Evidence changes the state; assignment does not

**Status:** In progress

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 / proposed status**
- Current: In progress — the end-to-end evidence and verifier acceptance path is not confirmed as complete.
- Proposed: 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.

**Meaningful tests**
- 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.

<a id="actor-decision"></a>

## Actors perform work; verifiers make readiness decisions

**Status:** Checked

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 / proposed status**
- Current: Checked — this decision separation is a documented operating requirement; individual final ownership remains to be confirmed in live practice.
- Proposed: 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.

**Meaningful tests**
- 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.

<a id="exception-flow"></a>

## Exceptions stay visible until the source or evidence is repaired

**Status:** In progress

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 / proposed status**
- Current: In progress — provider freshness and end-to-end verifier acceptance remain pending operational evidence.
- Proposed: 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.

**Meaningful tests**
- Test stale provider data, missing evidence, and identity mismatch as distinct failure fixtures.
- Check no exception fixture emits an accepted readiness outcome.

## Related pages
- [Property lifecycle: from enquiry to review](/workflows/property-lifecycle/) — A property service lifecycle connects owner needs, identity, stays, readiness, settlement, and learning. It is a model to validate, not a claim that every handover is automated.
- [Dashboard and passive TV: shared views, not source authority](/systems/dashboard-and-tv/) — The staff dashboard and passive TV surfaces make a shared operating picture visible. They consume projections; they do not become the authoritative writer for company state.
- [LINE boundaries: separate identities, accepted records, clear limits](/workflows/line-boundaries/) — LINE employee operations bot, Hermes adapter, and company Official Account are separate identities. A message flow only becomes operational evidence when the right record and acceptance boundary are confirmed.

## Source pointers
- Handoff / pages/workflows.html
- Handoff / START-HERE.html
- Handoff / pages/app-tour.html

## Context export
- Page context: ./exports/workflows--turnover-evidence.context.json