Control System Change Log and Rollback Checklist

A change-control checklist for yacht AV and lighting control edits, covering version capture, vendor changes, testing, and emergency rollback.

Control systems are where small edits can create large guest-facing effects. A macro edit, source label change, lighting-scene adjustment, DSP upload, driver update, or firmware prompt can break a room that was working yesterday. On a yacht, the change may happen during a support call, yard period, pre-trip rush, or late-night owner request. That makes rollback discipline essential.

The aim is not bureaucracy. The aim is to preserve a known-good state, make vendor actions visible, and give the onboard team a practical way back if a change causes a new service problem. This applies to Crestron, Lutron, Q-SYS, DSP files, touch-panel projects, AV-over-IP endpoint settings, switch configs, and account-related control integrations.

• Define affected systems, rooms, sources, scenes, panels, tablets, and integrations.
• Identify the approval owner: Captain, owner representative, management, ETO/AVIT, or department head.
• Export current project files, lighting databases, DSP files, endpoint configs, switch configs, and relevant screenshots.
• Record software versions, firmware versions, processor names, Core names, and file timestamps.
• Agree the test scope and rollback trigger before the vendor starts work.
• Confirm whether the change requires a reboot, firmware update, guest-space downtime, or temporary loss of control.

• Change reason: Fault fix, owner request, charter preference, refit scope, warranty work, preventive update, or vendor recommendation.
• Scope: Rooms, sources, scenes, DSP components, panels, processors, endpoints, switch ports, and accounts touched.
• Before state: Backup filenames, versions, screenshots, known-good behaviour, and existing limitations.
• Change made: Files uploaded, parameters edited, firmware changed, macros adjusted, scenes tuned, and accounts modified.
• Test result: User-path tests passed, exceptions found, defects opened, and who accepted the result.
• Rollback: Known-good file, person authorised to roll back, expected downtime, and reason rollback was or was not used.

1. Capture baseline: Export and store the known-good files before any upload, firmware prompt, or scene edit. Do not rely on recovery files as the primary backup.
2. Make the edit: Keep the work inside the approved scope. If the vendor finds additional issues, pause and record whether the scope is being expanded.
3. Test real user paths: Run control from the normal guest or crew interface through source, video, audio, lighting, shutdown, and recovery. Device-online status is not enough.
4. Decide close-out: Accept, roll back, or leave a documented workaround. A vague 'monitoring' status is not a close-out.
5. Update support records: Store revised files, update architecture notes, and add any new dependency or limitation discovered during the change.

A guest-pressure fix may not allow perfect paperwork, but it still needs a minimum record: before version, change made, tester, visible result, known risk, and follow-up action.