The close-out: prove the solution is ready to run before it enters live service. Each criterion is evidenced — a link, a date, a reference — not merely asserted.
Mirrors the canonical FSD-FRM-03 — FitSD v0.3.0; the canonical form is the authority, so review before use. Nothing is sent to any server — this runs entirely in your browser; download a Markdown record to save your progress.
Resuming a saved form? Load a .md you (or a teammate) downloaded earlier to pick up where it left off — read in your browser only, nothing is uploaded.
.md
For each criterion, record the evidence (a link, a date, a reference) and whether it meets your organisation's standing SAC baseline. The criteria are defined once in FitSD — Service Acceptance Criteria; N/A is a recorded call against a standing applicability rule, not a skip.
HLD, runbook, recovery procedure, user/how-to published.
Backup in place and test restore performed, dated.
Hardening applied, patch path set (FSD-RR), vuln posture acceptable, exceptions logged (FSD-SA).
Access model implemented; least privilege; JML handling confirmed.
SLO met or accepted; capacity & scaling understood; DR position recorded.
Monitoring live; thresholds set; test alert observed end-to-end.
Service-level incident triggers & severities registered with incident management.
Support model agreed; runbook accepted; team ready; training done; continuity assured (knowledge captured, not reliant on one person).
Licences in place; ongoing run-cost confirmed and owned.
Each condition the Gate 2 sign-off attached, and how it stands now.
List any criterion not yet met (the record is re-presented when these are closed), and any open actions that don't block acceptance — acceptance conditions carry an owner and a target date and are tracked to closure (FSD-SD-7).
Service, live Service Owner (and deputy, if your continuity rule names one), status. Acceptance names the live Service Owner on the service register (FSD-GV-2).