Skip to content

Blueprint contract

Status: Draft
Version: 0.1

1. Identity

  • blueprint_id: dr/postgresql-cloudsql-standby-gcp@v1
  • epoch: 2026E
  • lifecycle: deploy | destroy | drill | status
  • maturity: planned

2. Purpose

  • outcome:
  • Establish a managed PostgreSQL standby posture in GCP without cutting application traffic.
  • non-goals:
  • MUST NOT promote the managed standby to primary.
  • MUST NOT cut over application traffic or service endpoints.
  • MUST NOT replace baseline backup/restore DR as a prerequisite for shipment.

3. Inputs

3.1 Required inputs

  • managed target project/network selection
  • source cluster contract selection
  • replication mode selection
  • explicit standby confirmation flag

3.2 Optional inputs

  • lag thresholds
  • observability configuration
  • standby sizing policy

3.3 Input resolution

  • GCP project and network SHOULD be resolved from upstream state where available.
  • Source cluster identity MUST be consumed from platform/onprem/postgresql-ha or an equivalent source-preparation contract.
  • Secrets MUST be resolved via HyOps vault or environment.

4. Step composition

4.1 Required steps

The blueprint SHOULD contain at least:

  1. managed PostgreSQL provisioning
  2. source preparation
  3. external replication or standby establishment
  4. standby verification

4.2 Ordering and dependency rules

  • Source preparation MUST complete before external replication is established.
  • Standby verification MUST run after replication setup.
  • No cutover step MAY exist in this blueprint family.

5. State contracts

5.1 Consumed state

  • managed database target contract
  • on-prem source contract
  • repository or backup provenance contract where needed for validation

5.2 Published state

  • standby readiness status
  • managed endpoint contract
  • replication health contract
  • promotion eligibility signals

6. Safety and failure semantics

  • The blueprint MUST fail fast if source fencing state is ambiguous when the selected standby mode requires strict source posture.
  • The blueprint MUST distinguish provisioning failures from replication-establishment failures.
  • Destroy MUST remove standby resources only and MUST NOT imply production cutover reversal or repository purge.

7. Evidence

Minimum evidence set:

  • run metadata
  • managed target identifiers
  • source contract identifiers
  • replication establishment evidence
  • standby health evidence

8. Security

  • Replication secrets MUST NOT be written to state outputs.
  • Private connectivity SHOULD be preferred over public exposure.
  • Evidence MUST redact provider/service-sensitive values.

9. Change control

Breaking changes require an updated blueprint contract and compatibility notes.