GoLivePilot versions pages, reviews, news, locales, booking configuration, commerce catalog definitions, media metadata, variants, and releases in Git. Runtime facts live separately in SQLite so a content restore cannot rewrite appointments, orders, submissions, sessions, or audit records that already happened.
Which records belong in content history?
Content history is the right home for information an owner intentionally edits and reviews before publishing. That includes page copy, article drafts, navigation, theme tokens, localized text, media manifest metadata, and release snapshots. Those records can move forward or backward because they describe the site.
A restore can safely replace content-owned records such as:
- Published page definitions and article files.
- Navigation, locale packs, and SEO metadata.
- Variant and release manifests stored with the site definition.
Which records must stay in runtime storage?
Runtime storage keeps the business facts created by visitors, owners, integrations, and system events. Appointments, orders, payments, contact submissions, carts, sessions, and audit traces remain in SQLite because those records describe activity, not editorial state.
What should a restore prove?
A useful restore should bring a previous content version back without changing the operational record. After a restore, owners should still see the same appointments, submissions, and audit history while the public content reflects the selected version.
On this managed GoLivePilot site, that boundary is visible in public booking, commerce, contact, owner chat, release, and restore workflows.