How Airlift works

Airlift does not replace Lakebridge, a data-transfer engine, or a validation runner. It connects them through a governed migration model so developers can answer four questions for every object:

1. What is in scope and what depends on it?
2. Which artifact was produced, by which tool generation?
3. Which independent evidence shows that it is ready?
4. Which approved, reversible wave may move it into production?

The lifecycle

Assess the complete estate

The assessment adapter executes Lakebridge against exported source assets and records the run and immutable outputs. Inventory SQL together with orchestration, external data, security mappings, and downstream consumers; otherwise a “converted” warehouse can still fail when its pipelines or reports move.

Use a source profile to generate the applicable commands and outputs:

fa source inspect synapse
fa source plan synapse

Plan dependency-aware waves

airlift.wave_plan and airlift.wave_assign group objects into rehearsable units. The planner, owner, object assignments, validation expectations, and rollback responsibility remain explicit. Once approved, a wave cannot silently gain new objects.

Convert without hiding residue

Run deterministic conversion first. If policy admits bounded repair, an agent may return one typed candidate; it cannot approve, certify, waive, or cut over anything. Route every unsupported construct into one visible lane:

• deterministic conversion;
• bounded repair candidate;
• human engineering;
• governed exclusion.

Both automated and human conversion use airlift.conversion_start and airlift.conversion_record, which keeps provenance and funnel state consistent.

Validate independently

Conversion produces a candidate, not proof. Validation providers compare source and target behavior and write detailed results to immutable storage. Airlift admits the run reference, digest, snapshots, tool version, and verdict, then links that observation to one exact object-profile requirement.

A table, stored procedure, pipeline, and report can require different evidence. A passed table comparison does not certify a failed orchestration path or downstream consumer.

Mint a certificate from current evidence

airlift.migration_certificate_mint accepts an object identity and expected digests, not a caller-authored certificate. The handler derives the signed envelope from the current governed projection and fails on missing, stale, mismatched, or waived evidence that policy does not permit.

The useful progress metric is therefore the percentage of in-scope objects deployed and certified against their assigned profile, with provenance and a rollback path—not the percentage of files that produced output.

Cut over with durable verification

Before cutover, Airlift rechecks frozen wave scope, fresh certificates, readiness, and authenticated approvals. The worker then:

1. creates a durable checkpoint;
2. applies the non-idempotent external effect once;
3. verifies the resulting state independently;
4. records success only after verification;
5. leaves uncertainty unresolved for reconciliation rather than guessing.

Rollback is a governed action with its own reason, evidence, and result.

Preserve an attestable trail

airlift.evidence_export assembles the assessment, conversion, validation, certification, approval, cutover, and rollback history for an object or wave. The export is content-digested. Signed certificate envelopes can be verified independently with the Airlift CLI.

This is Airlift's role: migration tools perform specialist work; Airlift makes their outputs traceable, policy-bound, independently provable, and safe to use in a production decision.