Conversion factory controls
An engineering leadership guide to scope, throughput, quality, human capacity, and promotion decisions.
Conversion factory controls
The conversion factory is designed for two audiences. Developers need reproducible attempts and artifact lineage. Engineering leaders need an honest answer to five questions: what scope is running, what finished, what still needs people, what evidence supports quality, and whether a strategy should be promoted.
Control boundaries
| State | Owner | Leadership implication |
|---|---|---|
| Accepted migration scope | Airlift | Batch membership cannot drift from the accepted assessment |
| SQL translation | Lakebridge | Converter generation is pinned on every batch and attempt |
| Repair candidate | Harness agent or engineer | A candidate has no approval or certificate authority |
| Validation run | Experiments | Quality evidence is independent from the actor that produced code |
| Artifact body | Repository, volume, or release store | Airlift keeps a reference and digest, not a second code store |
| Work coordination | Tower or another work manager | Work completion does not close migration truth |
| Residue closure and readiness | Airlift | Evidence and independent review are required |
These boundaries let teams replace a specialist tool without rewriting the migration ledger. They also prevent the common failure mode where a ticket status or converter exit code is presented as production readiness.
Batch admission
A batch is allowed only when the assessment has been accepted for the engagement and all objects belong to that accepted snapshot. Each batch pins method and tool generation. Every attempt must match those values. Use smaller batches for high-complexity stored code and larger batches for homogeneous low-complexity objects; the contract supports up to 1,000 objects but does not prescribe an operational size.
Completion rules
Counts are computed from the ledger. A batch cannot complete while an object is missing an attempt or has a running attempt. Converted objects need matching immutable artifacts. Failed objects need active residue. This makes throughput reports reproducible after a worker restart or full event replay.
Human capacity
Residue estimates are minutes plus required skills, not story points hidden in a delivery
tool. Use the remediation projection to plan specialist capacity and join its workRef
to your work manager for scheduling. Keep commercialAttribution visible so included,
client-owned, change-request, and managed-service work do not collapse into one cost pool.
Repair strategy promotion
Run versioned repair datasets through Experiments. Feed the resulting digest-bound
summary into evaluateRepairPromotion with explicit thresholds for:
- minimum sample size;
- schema-valid output rate;
- compile-pass rate;
- parity-pass rate;
- maximum unsafe-output rate;
- minimum acceptable regression delta.
Any failed threshold blocks promotion. Dataset and evaluation-run references stay in the decision record so a future model, prompt, or policy change can be compared against the same baseline.
Reporting without overclaiming
Never report an unmeasured time-savings percentage. Report observable measures: accepted objects, terminal attempts, artifact-backed conversions, open residue, estimated and actual remediation minutes, independent validation passes, and reviewed closures. A time-reduction claim requires paired or historical benchmark evidence; the number is not inferred from automation coverage.
Operational screens
The Conversion App screen shows batch scope/outcomes, attempt generations, artifact digests, and validation references. The Remediation screen shows human/agent lanes, effort, skills, commercial treatment, assignment, artifact/evidence submission, and independent review. Both use the same tenant-scoped governed mutations as the CLI and remote API.