Documentation | Meta Museum

Status: Active operational playbook (Cloud now, self-host later).

Purpose: keep hosting costs low now with Wikibase Cloud while preserving a clean migration path to Docker/custom Wikibase when scale, control, or compliance needs increase.

Current state (pre-filled, non-secret)

Deployment mode: Wikibase Cloud (cost-first starter mode)
Cloud owner username: `Sundog358`
Primary project owner: `@rsung`
Canonical internal IDs: `https://lod.metamuseum.org/{type}/{ulid}`
Service account for automation: _pending setup_
MFA status on owner account: _verify and record_
Last credential rotation date: _record in runbook/release notes_
Self-host target mode (future): _TBD_ (`Docker Compose` or `Kubernetes`)

1) Cloud-first baseline (do now)

[ ] Confirm owner account has MFA enabled.
[ ] Rotate temporary bootstrap password after first login.
[ ] Create a dedicated service/bot account for automation; do not automate with personal account credentials.
[ ] Store secrets only in environment variables/secret manager; never in committed files.
[ ] Record current Wikibase Cloud tenant URL, org owner, and backup owner in runbook.

2) Portability guardrails (must stay true at all times)

[ ] Keep Meta Museum canonical IDs stable: `https://lod.metamuseum.org/{type}/{ulid}`.
[ ] Treat Wikibase Q/P identifiers as mapped externals, not canonical internal IDs.
[ ] Preserve bidirectional mapping table: internal ID <-> Wikibase entity ID.
[ ] Require source citation + rights metadata on publishable claims.
[ ] Keep write operations audit-logged (who, what, when, before/after references).

3) Data model and schema discipline

[ ] Freeze a documented minimum property set for first publishing scope (object/work/agent/place/set + rights + citations).
[ ] Track schema changes with migration notes (new property, deprecation, mapping updates).
[ ] Define statement-reference requirements for publishable facts.
[ ] Maintain round/fixture-linked tests for publish payload shape and reference completeness.

4) Backup and export routine (Cloud phase)

[ ] Schedule recurring full exports (items/properties/statements/references).
[ ] Keep at least two independent backup locations (primary + secondary).
[ ] Record restore drill owner and cadence (for example, monthly).
[ ] Run a restore drill at least once before any self-host cutover decision.

5) Trigger criteria for self-host activation

Move from Cloud to self-host when one or more are true:

[ ] Cost threshold exceeded for 2 consecutive cycles.
[ ] Required extension/feature unavailable in Cloud.
[ ] Compliance, data residency, or network control requirement cannot be satisfied in Cloud.
[ ] Performance/SLO needs require infra-level tuning not available in Cloud.

6) Target self-host design decision

[ ] Choose platform: Docker Compose (starter) or Kubernetes (production scale).
[ ] Pick database and storage sizing profile with 12-month growth buffer.
[ ] Define auth/SSO strategy and service-account policy.
[ ] Define observability baseline (metrics, logs, alerts, backup-monitoring).
[ ] Define DR objectives (RPO/RTO) and test schedule.

7) Dry-run migration (no public cutover yet)

[ ] Export from Wikibase Cloud snapshot N.
[ ] Import into self-host staging.
[ ] Run parity checks:
[ ] entity counts (items/properties/statements/references)
[ ] random sample semantic equivalence checks
[ ] external-ID mapping integrity
[ ] citation/reference completeness
[ ] Run application integration tests against staging endpoint.
[ ] Fix mapping or schema drift before production cutover planning.

8) Production cutover checklist

[ ] Announce maintenance window and rollback window.
[ ] Freeze writes on Cloud publication path.
[ ] Take final export snapshot N+1 and checksum it.
[ ] Import N+1 into self-host production.
[ ] Reconcile counts and integrity checks.
[ ] Switch application publish target via configuration flag.
[ ] Run post-cutover smoke tests (read, write, references, rights, citation surfaces).
[ ] Unfreeze writes after verification sign-off.

9) Rollback plan (must be prepared before cutover)

[ ] Keep Cloud environment available during rollback window.
[ ] Keep publish-target toggle reversible without code changes.
[ ] Document exact rollback operator and decision authority.
[ ] Rehearse rollback once in staging.

10) Post-cutover stabilization

[ ] Monitor error rates, latency, and queue backlog for 7-14 days.
[ ] Re-run parity audit after first full sync cycle.
[ ] Capture lessons learned and update this checklist.
[ ] Decide Cloud decommission timeline only after stabilization is complete.

Ownership and review cadence

Owner: `@rsung` (or assigned platform owner)
Review cadence: monthly during Cloud phase; weekly during migration window
Last review date: _fill when first adopted_