# Handover and preview record

## Review access
- Preview URL and expiry:
- Intended reviewers and access procedure:
- Candidate build / release notes:
- Synthetic accounts and demonstration data:
- Known preview differences from production:
- Feedback channel and decision owner:

## Accepted scope
| Requirement | Delivered behaviour | Acceptance evidence | Remaining limitation | Owner |
| --- | --- | --- | --- | --- |
| | | | | |

## Operating instructions
- Source repository and ownership:
- Local setup and supported runtime versions:
- Environment variable names; secret storage location, not secret values:
- Deployment and rollback procedures:
- Monitoring signals and support contacts:
- Backup / restore responsibilities where applicable:
- Dependency and model/provider update process:

## Maintenance knowledge
- Architecture decisions and important trade-offs:
- Content model or fixture layout:
- Test commands and failure investigation:
- AI permissions, evaluation cases and manual fallback:
- Areas that need specialist review:
- Known debt, owner and follow-up date:

## Receiving-team exercise
Choose a safe change: update a content field, add an isolated test or rehearse a recovery in a non-production environment. Ask the receiver to follow the instructions without relying on an undocumented step. Record missing explanations and repeat after correcting them.

## Final record
- Accepted deliverables and approving owner:
- Outstanding work and agreed dates:
- Support period and responsibilities:
- Where the team can find the decision history:

Example — fictional: the preview contains a support assistant using synthetic documents. The receiver reviews source citations and escalation behaviour. Production customer records remain outside the pilot, and sending an answer stays with a human operator. The handover records those boundaries alongside the useful demonstration.