Business-User Sign-Off and the Trust Gate

Estimated read: 3 min

A clean reconciliation dashboard is engineering evidence. It is not, by itself, permission to advance a cutover stage – and treating it as such is a common migration failure mode: an engineer looks at a green dashboard, decides that’s good enough, and flips the next stage without anyone whose job depends on the numbers ever being asked to agree. A trust gate closes that gap by making advancement require an explicit, named, dated approval from the business owner who actually depends on the data being right – not an engineer’s judgment call that the data probably is.

A trust gate is defined by four things, and a gate missing any one of them isn’t really a gate:

• Criteria – the specific, measurable condition that must be true (e.g. “zero open mismatches across all AP tables for 5 consecutive nightly reconciliation runs”).
• Evidence – the artifact that proves the criteria was met (a link to the reconciliation dashboard for that date range, not a verbal “looks fine”).
• Owner – the named business stakeholder accountable for the sign-off, not the migration engineer who built the pipeline being judged.
• Date – when the gate was approved, creating an audit trail for exactly who agreed to what, and when.

This maps directly onto a Delta table, which turns “the business signed off” from a Slack message that gets lost into a queryable, permanent record – the same instinct behind the append-only reconciliation audit table from the previous section, applied to human decisions instead of automated checks.

CREATE TABLE governance.cutover.sign_off_gates (
  gate_id        STRING,
  wave_name       STRING,       -- e.g. 'accounts_payable_phase1'
  criteria        STRING,
  evidence_link   STRING,
  owner_email     STRING,
  status          STRING,       -- 'pending', 'approved', 'rejected'
  decided_at      TIMESTAMP
) USING DELTA;

A Lakeflow Job that orchestrates the cutover stage transition can then read this table as a hard precondition – the read-write stage task simply does not run while any wave_name gate row for the prior stage isn’t approved, turning a policy (“don’t advance without sign-off”) into an enforced dependency the same way task dependencies enforce close-sequencing in the Lakeflow Jobs DAG covered earlier in this section.

The gate blocks on approval, not on the dashboard being green. A green dashboard with no recorded owner sign-off is not a passed gate – it’s just a metric nobody has been asked to stake their name on yet.

This also reframes what the engineering team is optimizing for: the reconciliation engine’s job isn’t to declare the migration done, it’s to produce evidence good enough that a business owner is willing to sign their name to sign_off_gates with a clear conscience. That distinction – automated check versus accountable decision – is what actually earns trust in a cutover, not just a passing test suite.

Sign-off gets someone through the cutover stages with confidence the plan will work. The final lecture in this section covers what happens when it doesn’t: the rollback path that has to be rehearsed and proven before it’s ever needed for real.

---

| ← Previous: The Soft Cutover: Read-Only, Then Read-Write, Then Decommission | Next: Backfill and Rollback Pre-Testing → | |:—|—:|