Database Change Approval Workflows

A schema package is a reviewable artifact, so the approval workflow is the one your team already runs for code: propose, review, record. What differs is that the thing under review is a declarative definition rather than a script whose effect a reviewer has to imagine.

1. Propose — the change is a diff

A schema change arrives as an ordinary diff to JSON in source control, carrying a commit, an author, a timestamp, and whoever reviewed it. The version-control history is the audit trail, with no separate tracking system to keep in step. Because the definition is declarative, the diff states what the schema will be rather than the steps someone intends to take to get there.

2. Review — approve statements, not just JSON

A reviewer previews the exact statements the deployment would generate and attaches the output to the change request:

SmithySettings_WhatIfONLY=true SchemaQuench

SchemaQuench reports the difference between the package and the target and applies nothing. WhatIf is human-facing by design — a person runs it, a person reads the output, and that reading is the review. The preview is what turns “approve this diff” into “approve these statements against this target”.

3. Record — governance metadata rides with the schema

Extensions is an open JSON bag that rides on the schema components in a package — tables, columns, indexes, foreign keys, check constraints, and more depending on the engine — and it is where data classification, ownership, and environment markers belong:

{
  "Name": "[Orders]",
  "Extensions": {
    "Environment": "Production",
    "DataClassification": "PII",
    "OwningTeam": "Identity"
  },
  "Indexes": [
    {
      "Name": "[IX_Orders_AuditCreatedAt]",
      "IndexColumns": "[CreatedAt]",
      "ShouldApplyExpression": "'{{Table.Environment}}' = 'Production'",
      "VariantName": "Production audit index"
    }
  ]
}

Those keys resolve as tokens — a component's own as {{KeyName}}, the parent table's as {{Table.KeyName}} anywhere inside that table. The effect on review is that intent becomes legible in the diff: a reviewer seeing that ShouldApplyExpression knows the index exists in production only, and VariantName records why, then names the variant in deployment log messages when it applies. The metadata survives re-extraction by SchemaTongs, so it is not lost the next time a schema is cast back out of a live database.

Every quench also writes a Deployment Summary Report — SchemaQuench - Summary.json for machines and SchemaQuench - Summary.md for people, rendered from one in-memory model so the two cannot disagree. It carries every target, every timing, and every verified object change, and it is emitted on every exit path: success, partial failure, and hard abort alike. A run that died is exactly the run whose record you most want. Between them, the proposal, the reviewed preview, and the report account for what was asked for, what was approved, and what actually ran. The tooling produces that evidence; enforcing separation of duties remains a policy your organization sets and administers.