Database changes ship behind a pre-flight verification gate — and it caught a real issue

Why this post exists

This is an operator-side transparency post about how we ship destructive database schema changes safely. The change topic is operational discipline rather than a new product feature — but for EU mid-market buyers evaluating HumanKey's compliance posture, "how does this vendor avoid losing my audit-trail integrity during routine operational changes?" is a recurring procurement question. The honest answer involves a specific engineering pattern + a verification gate that recently caught a real divergence before any data was lost.

The pattern in plain language

When we need to change how a sensitive field is stored — for example, replacing raw values with minimised forms — we use a two-phase approach:

• Phase 1 (expand): ship the new minimised form alongside the existing raw form. Both columns receive the same minimised value at write time. Read paths prefer the new column with fallback to the old one for any rows that pre-date the change. This phase soaks for at least a week before anything is removed.
• Phase 2 (contract): remove the old raw column entirely once the new minimised form has fully covered the data.

The pattern is called expand-contract in the engineering literature. The risk it manages is: if you simply rename a column or drop one in a single deploy, anything in flight at the moment of deployment can lose data. The two-phase pattern guarantees that every read path can resolve to a value even during the transition.

Why a pre-flight gate matters

The expand-contract pattern works correctly only if the dual-write phase actually wrote both columns for every event during the soak period. If a subtle bug caused some events to write only the old column (without the new minimised form), then dropping the old column would silently lose those rows' identifiers.

To verify this never happens, we run an automated pre-flight verification pass before any Phase 2 destructive change:

1. Sample recent post-deploy rows and confirm both columns hold parity-equivalent values.
2. Count any rows where the old column has data but the new minimised column is empty.
3. Inspect a fixed sample of rows visually for format compliance.

The verification produces a clear PASS or FAIL verdict. If FAIL, the destructive change is halted and we investigate before proceeding. No "I'm pretty sure" or "it probably worked." A documented gate with binary output.

A real recent example

In this development cycle, our pre-flight verification ran against the live database and returned FAIL. The verdict surfaced two distinct issues:

1. A handful of recent events had been written to the old column only, missing the new minimised column. This was a silent dual-write bug introduced in a prior session that none of our tests had caught (the dual-write logic was correct, but a code path edited later had bypassed it).
2. Roughly a hundred older events from before the Phase 1 expand deploy still carried raw values in the old column with no minimised equivalent (the original Phase 1 deployment hadn't backfilled historical rows).

If we had skipped the pre-flight gate and proceeded directly to Phase 2, we would have:

• Lost the identifier metadata for those approximately one hundred legacy events. Not catastrophic for current operations, but a real audit-trail completeness regression that an EU regulator or an enterprise customer's annual audit could legitimately question.
• Lost the recent dual-write-asymmetric events' identifier metadata as well.

Instead, the gate halted the destructive change. We backfilled the affected rows using a documented hybrid strategy that preserved every row, every event timestamp, and every audit-trail entry — only minimising the network-identifier field in a privacy-positive direction. The Phase 2 destructive change then proceeded safely once the pre-flight pass returned PASS.

What this looks like to regulators and buyers

Under GDPR Article 32 — security of processing — the controller must implement appropriate organizational measures to ensure data integrity. A documented pre-flight gate that produces a binary verdict before any destructive change is exactly the kind of measure that satisfies the spirit of Article 32 in a way that survives audit scrutiny.

Under GDPR Article 30 — records of processing — the audit trail itself must be maintainable. A pre-flight gate that catches dual-write divergence before destructive change preserves the trail's completeness.

Under Polish Ustawa o rachunkowości Article 74 — five-year retention for financial records — the trail must remain available for the full statutory period. A gate that catches integrity issues before they become permanent preserves the obligation.

Why we are publishing this

EU buyers conducting procurement due-diligence ask vendors increasingly granular questions about operational discipline. "Show us your destructive-change procedure" is one such question that smaller vendors often answer with hand-waving ("we test thoroughly"). We answer it concretely: there is a documented procedure, a pre-flight verification pass, a binary verdict, and a recent example where the gate prevented a real regression.

Operational discipline does not make for exciting product marketing, but it does make for defensible compliance posture during audits.

What this is not

• Not a magic safety net. The pre-flight pass verifies specific invariants. It cannot catch failure modes that nobody thought to probe for. We extend the probe surface as new failure modes are discovered.
• Not unique to HumanKey. Expand-contract is a well-known pattern; the pre-flight gate is straightforward engineering discipline. What we are publishing is the fact that we actually do this and actually halt destructive changes when the gate fails — which is the part that procurement teams find difficult to verify without working with a vendor over time.
• Not a substitute for backups. Our database provider retains point-in-time-restore backups; the pre-flight gate is a forward-defense measure, not a replacement for restore capability.

Reference points

• GDPR Article 30 — Records of processing activities
• GDPR Article 32 — Security of processing (appropriate organizational measures)
• Polish Ustawa o rachunkowości Article 74 — Five-year retention for financial records
• Our Privacy Notice and DPIA describe the categories of data we process

---

HumanKey is an EU-based, GDPR-native analytics platform for publishers and e-commerce sites. Operator transparency posts cover the compliance and engineering choices that B2B buyers evaluate during procurement.