Paridity Business Continuity & Disaster Recovery Summary¶

Verified data. Trusted outcomes.

CDC-Aware Reconciliation Platform

Prepared for: General distribution Version: v0.1 · Date: 2026-10-29

Executive summary¶

Business-continuity reviews of a SaaS vendor usually turn on one question: if the vendor goes down, what happens to us? For Paridity the answer is structural, not contractual. In Paridity's current shipping architecture, the entire platform - API, UI, workflow orchestration, all workers, and the PostgreSQL evidence store - runs inside your own cloud account/VPC, on infrastructure you deploy and operate via a Helm chart and Terraform modules you control. Paridity, the vendor, operates no infrastructure in your reconciliation path. Your backups, your point-in-time recovery, your restore - all execute in your environment, under your cloud provider's managed-database machinery, using procedures Paridity documents and a restore-validation script Paridity ships. A Paridity vendor-side outage cannot take your deployment down, and Paridity's own continuity is not a dependency for the availability of your data or your reconciliation evidence. The one Paridity-operated service your installation uses is the licence service. In releases that enforce the licence (every release after v1.4.0), an installation that cannot reach it keeps running normally for 7 days on the signed licence token it holds; after that a paid licence runs proof-only (counts and hash totals, no field-level diffs, and no new configuration brought into service) until it can reach it again. Runs are never stopped and your data is never touched.

This summary distills Paridity's internal disaster-recovery documentation into the answers a continuity reviewer needs: recovery objectives per deployment tier, the backup and PITR approach, the restore procedure, the quarterly restore-validation playbook, and - per Paridity's own honesty standard - what is a manual runbook today versus what is roadmap, and which of these has actually been exercised.

The continuity model: customer-hosted by design¶

Who owns what. Because the full stack deploys in your VPC, continuity responsibility splits cleanly:

Responsibility	Owner	What it covers
Running the deployment (cluster, database, network)	Customer	Kubernetes cluster, managed Postgres, secrets backend, egress controls - provisioned by the in-repo Terraform modules you apply.
Executing backups and PITR	Customer (via cloud provider)	Managed-Postgres automated backups and point-in-time recovery in your own cloud account. Terraform provisions these by default (see below).
Executing a restore	Customer	Cloud-provider PITR/snapshot restore, then re-pointing the platform per the documented procedure.
Source/target system availability	Customer	Availability of the databases Paridity reconciles (e.g. Oracle, Snowflake) is outside Paridity's recovery scope.
DR procedures, restore runbook, and validation tooling	Paridity (documentation and tooling)	Documented backup/restore procedures, the restore-validation script, Terraform backup defaults, and the RPO/RTO guidance below. Scheduling and executing the drill is the customer's operational task - see "Restore validation" below for what has and has not been exercised.
Software updates and fixes	Paridity	Platform releases, migrations, and the deployment tooling that applies them.

Note: The recovery objectives in this document apply to the Paridity control plane (PostgreSQL + Temporal) running in your environment. Source and target system availability is the customer's responsibility.

Scope note: This document covers platform (deployment-level) continuity only. EGMW is a small, privately held business. It has no formal vendor-side business-continuity arrangement - no organizational BCP, key-person/succession plan, or source-code escrow - and publishes no viability statement or financial statements. The product's only runtime dependency on EGMW is the licence service: without it an installation runs normally for 7 days, then a paid licence runs proof-only (no field-level diffs, no new configuration brought into service) until a refresh succeeds - never a halt. If the licence service never returned, that degraded state would be permanent. See the Trust Center, "What happens without EGMW".

Recovery objectives (RPO / RTO) by deployment tier¶

Paridity documents recovery targets per deployment tier. The tier is a customer deployment choice - larger tiers buy tighter objectives with multi-AZ and replicas:

Tier	Deployment	RPO	RTO
Small	Single-AZ, no replica	1 hour	4 hours
Medium	Multi-AZ, 1 read replica	5 minutes	1 hour
Large	Multi-AZ, 2 read replicas, WAL archive	5 minutes	30 minutes
Global	Per-region with failover	1 minute	15 minutes

These are design targets, not measured recovery times. Paridity has drilled the restore procedure and the integrity of what comes back (once, on 2026-08-17, with an automated quarterly drill scheduled from 2026-11-01) but has not observed a restore at realistic evidence volume, and restore time at volume is what an RTO promises. The reference environment cannot supply that figure: its entire DR backup scope is a 10.6 MB dump. Treat the table as what the architecture is sized for, and ask for the drill transcript rather than inferring an observed number from it.

Important: The Small tier's embedded (in-chart) Postgres option is explicitly non-production - its durability is bounded by the Kubernetes volume's storage class and snapshots, not managed PITR. Any tier with a real RPO target must use external managed Postgres (AWS RDS, Azure Database for PostgreSQL, GCP Cloud SQL).

What must be recovered, in priority order. All platform state lives in one PostgreSQL instance across four schemas:

Schema	Contents	Recovery priority
Configuration	Mapping config, tenant config, schedule config, audit log	Critical - all new runs depend on this
Execution history	Execution history, run status, watermarks	Important - historical record; new runs can restart
Evidence	Proof results, mismatch keys, field diffs, config audit	High - append-only evidence; SOX/ICFR compliance requires it
Projections	Derived run summaries, metric rollups, baselines	Low - fully recomputable from evidence; no custom recovery needed

What does not need recovery. Two categories of state require no custom recovery procedure at all:

In-flight diff state - the in-memory DuckDB diff engine uses local ephemeral storage. If a diff worker dies mid-run, the Temporal workflow retries the diff activity from scratch; there is no persistent diff state to recover. (Known V1 limitation: a long-running diff that fails near completion restarts from the beginning - see Limitations below.)
Workflow state - Temporal persists workflow history durably in its own Postgres database. After a Temporal cluster recovery, in-progress workflows resume from the last recorded event natively. During an extended Temporal outage, new runs cannot be dispatched but no run data is lost - existing run state is preserved.

Backup and point-in-time recovery¶

Standard (Helm/Terraform) deployments. The in-repo Terraform modules for AWS, Azure, and GCP provision managed Postgres with 14-day backup retention plus point-in-time recovery (PITR) enabled, and multi-AZ/high availability on the Medium and Large tiers. The Temporal persistence database (typically 5-10% the size of the application database) is covered by the same managed backups. Paridity's guidance is to verify backup enablement from terraform output after provisioning rather than assume it. For logical, portable backups, the deployment runbook documents a logical pg_dump of the configuration, execution, and evidence schemas.

Self-managed Postgres. For deployments above the Small tier that self-manage Postgres, Paridity documents continuous WAL archiving (archive_mode = on with an object-store archive target), daily base backups via pg_basebackup, and backup integrity verification. On managed platforms the equivalent is: AWS RDS automated backups (the shipped Terraform default is 14-day retention) plus PITR; Azure Database for PostgreSQL geo-redundant backup; GCP Cloud SQL automated backups plus PITR.

All of this runs in the customer's cloud account. There is no Paridity-side backup copy, and no customer data leaves the VPC as part of the backup process.

Restore procedure¶

The documented full-restore procedure (region failure or catastrophic data loss) follows the cloud provider's PITR/snapshot restore, then re-points the platform:

Provision a restored Postgres instance via the cloud provider's point-in-time or snapshot restore to the target timestamp (AWS RDS restore-to-point-in-time, Azure PITR to a new server, GCP clone from backup).
Verify schema integrity - confirm all configuration, execution, and evidence tables are present.
Verify critical row counts against last known values (mapping config, run records, proof results, and the audit log).
Re-point the application - update the database connection secret and roll the API and worker deployments (helm upgrade or kubectl rollout restart). The migration hook re-runs idempotently and is a no-op against a restored, already-migrated schema.
Re-point Temporal to its restored persistence database and restart the Temporal pods.
Run the restore-validation playbook (next section).

Evidence integrity survives restore by construction: evidence tables are append-only and the compare_started_at audit anchor is immutable, so restored evidence is byte-identical to what was originally written - restored as-is, never rewritten.

The licence survives a restore too: the installation id the licence is bound to is a row in the same database, so a restored database (logical dump or PITR) is the same installation and refreshes its licence normally, provided the licence key is still in your secrets backend and the licence service is reachable.

A partial restore procedure is also documented for table-level corruption: restore the affected table from backup into a staging database, compare row counts, and reconcile by inserting missing rows only (using the run identifier as the natural deduplication key) - never updating existing evidence.

Note - rollback vs restore: a helm rollback reverts images and configuration only; database migrations are forward-only and are never reverted by Helm. If a migration caused the incident, the documented recovery is a PITR restore to the pre-upgrade timestamp, not a Helm rollback.

Evidence reconstruction. If a subset of evidence is lost between backups, the documented procedure is to identify affected runs, re-trigger them with the same config version and time window, and log the reconstruction to the audit log (recorded as an evidence-reconstruction action). Stated plainly for audit stakeholders: reconstructed evidence rows carry a different creation timestamp than the originals, and the audit-log entry is the auditor's evidence that reconstruction occurred. Reconstruction must be documented and approved under the customer's SOX/ICFR process.

Restore validation - the quarterly playbook¶

Paridity ships a restore-validation script to be run quarterly, and before every major upgrade, against a scratch database restored from the most recent production backup. It restores the backup and then verifies what came back:

Schema integrity across the configuration, execution, and evidence schemas.
Evidence row counts - every restored evidence table must hold exactly the number of rows the backup artifact itself carries, counted from the dump's own contents rather than from a manifest or from the live database.
Critical table counts - the same artifact comparison for mapping config, schedule config, the audit log, and run records.
Evidence anchors - the immutable compare_started_at audit anchor is present and still constrained, and no restored evidence row references a run the restore did not bring back.
Audit hash-chain - the audit-log tamper-evidence chain recomputes from genesis and its newest signed checkpoint anchors to it, so an auditor can prove the restored trail is the trail that was written.

Any failed check exits non-zero and names the check that failed; a check that could not be executed is reported as unmeasured and counts as a failure, never as a pass. The script only ever writes to a dedicated scratch database and refuses to run against the configured live database. It also carries a --prove-can-fail mode that deliberately corrupts the restored data - deleting an evidence row, rewriting a sealed audit entry - and requires the corresponding checks to go red, so the drill is demonstrably capable of failing before a green result is trusted.

Stated honestly, per Paridity's no-over-claim standard - what is now true, and what is still not:

A restore drill has been executed, and a transcript exists. Restore, PITR, and evidence reconstruction were run against a real backup of the reference environment's live control plane: --prove-can-fail first (all probes red, control green), then the formal run (5/5 checks passed, sealed audit chain verified against its checkpoint anchor and signature), then a PITR leg recovering to a chosen timestamp with a deliberate incident excluded and validated against an end-of-WAL control. The transcript is available to reviewers on request through your Paridity account contact.
The drill is automated and scheduled - it is a workflow in Paridity's continuous-integration pipeline for the reference environment, scheduled quarterly (the 1st of February, May, August, and November), with the --prove-can-fail probes retained ahead of every run. It has executed once to date, by manual dispatch on 2026-08-17; the first scheduled run is 2026-11-01.
Still not true: a drill against a CUSTOMER production backup. Paridity operates no customer production infrastructure, so scheduling and executing the validation in the customer's environment remains the customer's operational task; Paridity supplies the script, the procedure, and now a worked transcript.
Still not true: an RTO observed at realistic evidence volume. The drills prove the procedure and the integrity of what comes back, not how long a restore takes when evidence is large - and that is what the RTO targets promise. The reference environment cannot supply the figure: its whole DR backup scope is a 10.6 MB dump. No number in this document should be read as an observed recovery time.

Limitations & roadmap honesty¶

Per the four-level status vocabulary (Verified / Supported / Roadmap / Evaluating):

Capability	Status	Notes
Customer-hosted deployment - continuity independent of Paridity vendor operations	Verified	Full stack in the customer VPC via Helm + Terraform; Paridity operates no infrastructure that holds customer data. The licence service is the one Paridity-operated dependency (releases after v1.4.0): 7 days of normal running without it, then proof-only for a paid licence until it is reachable; never a halt. An air-gapped installation cannot be activated today, because offline activation is not yet available from the licence service.
Managed-Postgres backups + PITR provisioned by default (14-day retention; multi-AZ on Medium/Large)	Supported	Provisioned by the in-repo Terraform modules; verify enablement via `terraform output` post-deploy.
Documented RPO/RTO targets per deployment tier	Supported	Targets as tabled above; apply to the control plane, not source/target systems.
Full and partial restore procedures (PITR restore + re-point + validate)	Supported	Documented step-by-step, including Temporal recovery and evidence-immutability guarantees.
Restore-validation script	Verified	Shipped and executed end-to-end against a real backup of the reference environment's live control plane, including its `--prove-can-fail` probes (deliberate corruption must turn the checks red).
Quarterly restore drill actually executed	Verified	Performed - restore + PITR + evidence reconstruction, 5/5 checks, sealed audit chain verified; transcript retained and available to reviewers on request. Against Paridity's reference environment; a drill in the customer's own environment remains the customer's operational task.
CI-automated restore validation (automated DR test)	Verified	A continuous-integration workflow on the reference hardware, scheduled quarterly; executed once to date (2026-08-17, manual dispatch, green), first scheduled run 2026-11-01. `--prove-can-fail` probes run first on every execution so a green result is known to be capable of going red.
RTO observed at realistic evidence volume	Roadmap	Not measured. The tier RTO figures are design targets. The reference environment's entire DR backup scope is 10.6 MB, so an at-scale restore timing needs synthesized evidence at volume - outstanding work.
Multi-region failover	Roadmap	Single-region today; full region failure recovery is via restore (RTO per tier). Target V2.0.
Persisted DuckDB diff-state checkpointing	Roadmap	Long-running diff activities restart from scratch on worker failure today; spill-to-object-store checkpointing is on the roadmap with no committed release.
Temporal high availability on the Small tier	Supported	Single-server Temporal on Small is a documented accepted risk for that tier; Medium/Large use an external Postgres-backed cluster.
Paridity vendor-side organizational BCP attestation	Evaluating	Not published; the customer-hosted model removes vendor uptime from the customer's continuity path, and any formal vendor-side attestation is scoped case-by-case.

Appendix¶

The internal disaster-recovery source of truth this summary distills - full RPO/RTO tables, backup commands, restore procedures, the validation playbook, and the limitations register - together with the Helm/Terraform deployment runbook (logical backup and rollback-vs-restore guidance) are available to reviewers on request through your Paridity account contact.
Security Whitepaper - the customer-hosted deployment model, access control, secrets, and evidence-integrity controls in depth.
Trust & Security index - the secure-by-design review starting point and document map.
Paridity glossary - canonical terminology (Mapping, Run, hash_total, compare_started_at, evidence).
Follow-up questions: route through your Paridity account contact.