OPS-ONT-001 — Protect the Ontology source of truth
| Field | Value |
|---|---|
| Status | Open finding; live-confirmed and source-verified |
| Severity | Critical |
| Components | sparqd/platform-stacks, KubeBlocks PostgreSQL, sparqd/ontology |
| Associated issues | sparqd/platform-stacks#681 |
Concrete observed case
Ontology state has moved from Git to PostgreSQL. The live onto-db cluster has
one PostgreSQL replica, one 20 GiB ESSD PVC, no backup configuration, and
terminationPolicy: Delete. The database currently contains only the empty
core model, but the same deployment is intended to hold projects, published
objects, immutable versions, proposals, decisions, notifications, workbooks,
and dashboards.
Expected condition
The model authority has declared encrypted backups, retention, restore targets, capacity alerts, deletion protection, recovery-point and recovery-time objectives, and a regularly tested restore that preserves all cross-table and effective-model invariants.
Why it matters
Loss or corruption of this database removes both current semantic definitions and the governance history needed to explain them. Cube and Trino cannot reconstruct the model authority from query state.
Existing controls and workarounds
The bound persistent volume protects against ordinary pod replacement. It is not a backup and does not cover cluster deletion, volume failure, corruption, operator error, or recovery to an earlier point.
Alternatives considered
- Recommended: provider-backed scheduled PostgreSQL backups with point-in-time recovery where supported, protected retention, and automated restore tests.
- Export immutable model revisions to versioned object storage in addition to database backup; useful defense in depth but not a substitute for full-state database recovery.
- Recreate from Cube — rejected because Cube is a consumer and does not retain the authoritative governance model.
Component involvement
- Platform stacks declares backup, retention, deletion protection, monitoring, and restore-test resources.
- KubeBlocks provides the database and backup/restore mechanics selected by the platform.
- Ontology supplies integrity checks and effective-model hashes for restored data.
Reproduction and verification
Resolution conditions
Close after a representative database is backed up and restored into isolation, the restored model compiles through Cube, retention and deletion protection are verified, and measured recovery results meet approved objectives.
Validation and blockers
The missing live backup declaration is confirmed. Backup target, retention, cost, encryption, cross-region requirements, PVC reclaim behavior, RPO, and RTO require operations and security review.