Backups & Data Responsibility

• Maintaining reasonable recovery procedures for the Institute's own application, configuration and operational environment.
• Creating recovery points before and after material system changes where the platform supports that capability.
• Testing important changes before treating them as stable.
• Investigating material failures and restoring a known-good state where reasonably possible.
• Keeping operational responsibility for platform-level recovery separate from user-owned source files.

• Keeping an independent copy of source documents, videos, reports, datasets, tactical files, presentations and other material uploaded to the service.
• Exporting or preserving records that are essential to the user's club, business, professional activity or legal obligations.
• Checking that their own backup can actually be opened and restored.
• Avoiding use of the Institute as the sole repository for irreplaceable or business-critical information.

Internal recovery is designed to restore the service after an application or configuration problem. A user backup protects the user's own underlying material. These are different risks and neither should be presented as a substitute for the other.

Restoration may be affected by the nature of the incident, the capabilities of third-party providers, retention limits, data corruption, account actions or events outside the Institute's reasonable control. No recovery mechanism can guarantee restoration of every item in every circumstance.

• Keep at least one current independent copy outside the Institute platform.
• For critical professional material, keep more than one copy in separate locations or providers.
• Export important records before deleting accounts, changing providers or making major structural changes.
• Do not assume that a successful upload means the original file can be discarded.

For the Institute application itself, material software changes should follow a controlled sequence: known-good checkpoint, change, build or validation, read-back verification, and a new stable checkpoint. A change is not considered complete merely because it was requested.