Skip to content

Blueprint contract

Status: Draft
Version: 0.1

1. Identity

  • blueprint_id: dr/postgresql-cloudsql-failback-onprem@v1
  • epoch: 2026E
  • lifecycle: deploy | drill | status
  • maturity: candidate

2. Purpose

  • outcome:
  • Return service from a managed GCP DR primary back to an on-prem PostgreSQL HA cluster using a controlled, evidence-driven failback process.
  • non-goals:
  • MUST NOT attempt to resume an ambiguous pre-DR Patroni timeline.
  • MUST NOT treat failback as a trivial reverse of promotion.
  • MUST NOT silently destroy managed DR state after failback.

3. Inputs

3.1 Required inputs

  • on-prem target contract
  • explicit manual gate confirmation
  • managed primary fencing confirmation
  • endpoint cutback intent

3.2 Optional inputs

  • reseed mode selection
  • reverse replication mode selection when later supported
  • post-failback standby retention policy

3.3 Input resolution

  • Managed source identity MUST be consumed from managed DR state.
  • On-prem target SHOULD be consumed from an explicit rebuild/reseed contract.
  • Secrets MUST be resolved via HyOps vault or environment.

4. Step composition

4.1 Required steps

The blueprint SHOULD contain at least:

  1. on-prem target verification or selection
  2. explicit manual gate
  3. endpoint cutback publication

4.2 Ordering and dependency rules

  • Managed-primary fencing confirmation MUST occur before cutback publication.
  • On-prem rebuild or reseed MUST already be complete before cutback publication.
  • Managed standby retention or destroy policy MUST remain separate from the cutback blueprint.

5. State contracts

5.1 Consumed state

  • on-prem target contract
  • managed-primary fencing evidence
  • DNS authority contract

5.2 Published state

  • on-prem active primary endpoint
  • failback completion status
  • manual gate evidence

6. Safety and failure semantics

  • Failback MUST be modeled as a reseed/new-lineage operation unless reverse replication is explicitly implemented and validated.
  • The blueprint MUST fail if fencing or manual gate confirmation is absent.
  • The blueprint MUST distinguish between readiness failure and cutback-publication failure.

7. Evidence

Minimum evidence set:

  • managed-primary fencing confirmation
  • on-prem readiness evidence
  • manual gate evidence
  • cutback publication evidence
  • resulting on-prem readiness evidence

8. Security

  • Export/replication credentials MUST NOT be published in state outputs.
  • Managed and on-prem endpoint evidence MUST be redacted where appropriate.
  • Destructive cleanup of managed standby resources MUST remain explicit and separate.

9. Change control

Breaking changes require an updated blueprint contract and compatibility notes.