LEARN. PRACTICE. GROW.Resume from effective state
Losing a local log does not remove changes already applied. If ADD COLUMN completed and the executor repeats the entire script, a later failure may coexist with earlier committed steps. Before resuming, inspect effective state, migration history, and available evidence. Classify each step as completed, failed, or uncertain and choose a compatible sequence. Idempotency is a property to demonstrate for a specific operation and its conditions; it does not automatically accompany every DDL statement. Preserve data and avoid deleting objects to force a restart. When outcome is uncertain, reconciliation is part of recovery, not an optional delay to meet the window.
Delimit transaction scope
The final group changes dispatch from pending to sent inside a transaction and writes a receipt to a temporary file. It then executes ROLLBACK. The database returns to pending, but the receipt remains because it does not participate in the SQLite transaction. The file represents an external effect without sending a real message. In a production flow, do not conclude that pending means no execution at the recipient. Before repeating, seek the outcome through a reliable mechanism and define resumption or compensation. Changing identity may create a second operation rather than resolve the first. Include this boundary in recovery plans and reconciliation criteria, especially for financial flows.
Verify integrity and meaning separately
An ok result from integrity_check is useful but does not automatically know the rule that amount_cents should equal one hundred times amount_units. The fixture retains a valid file and an incorrect business relationship. Acceptance needs checks tied to meaning: values, counts, identities, and expected effects under service criteria. Do not replace this reconciliation with an HTTP probe or averages hiding discrepancies. Record the checked population and write paths producing it. A physically intact result can be semantically wrong; a limited functional test also does not establish every physical or operational property. Each piece of evidence should retain its scope when used in a decision.
Map evidence to entry and exit criteria
A simple matrix links each criterion to required observation, result, version, date, and owner. If the plan requires old reads, new writes, and reconciliation, twenty green HTTP checks do not fill those three rows. Use clear states: passed, failed, not executed, or inconclusive, with supporting evidence. A known failure should not be reclassified as unexecuted to improve the report. If discrepancy-free reconciliation is mandatory, a 98% average does not revoke the requirement. Changing a criterion needs a valid decision and explicit impact. This model allows communicating real progress without declaring acceptance where information does not yet support it. Keep the original and revised criteria traceable.
Update recovery options after each phase
Before contraction, the old version may still read the column it knows. After removal, that option fails in the lab. A runbook should therefore identify the phase in which each strategy remains valid and which data needs reconciliation. Retaining binary v1 does not resolve the resulting incompatibility. Another rehearsed option may exist, such as a forward fix or state recovery with reconciliation, but it should not be improvised during an incident without assessment. At handover to RUN, show the compatibility matrix and relevant rehearsal results. The shift team needs to know what it can execute, who decides, and which limits prevent continuing.
Deliver a record another team can use
The lab records Python and SQLite versions, ten groups, results, and the script hash. Real statements ran in a disposable database; approval and scheduling controls are local models with explicit rules. There was no access to pipelines, real identities, banking environments, or remote destinations. Use the same scope discipline when handing over operational evidence: artifact, effective configuration, instants, results, deviations, and outstanding work with owners. If a mandatory condition remains unproven, communicate the gap and required decision. The aim is to let RUN maintain the service and understand actual options, rather than merely find a ticket marked closed. Retain enough context for the next shift to act.
-- The local file effect is outside this SQLite transaction.
BEGIN IMMEDIATE;
UPDATE dispatch SET state='sent' WHERE id='demo-1'
-- Python writes a synthetic receipt to a temporary file here.
ROLLBACK;
-- Database: pending. Receipt file: still present.Probes pass and the database file is intact, but the runbook promises an old version whose query fails on current schema. The team hands the incompatibility and pending decision to the operational owner.
Common pitfalls
Repeating uncertain steps without inspection, treating pending as absence of effect, confusing physical integrity with correct business outcomes, or closing with an outdated rollback promise.
Related topics: Application Production Support · Problem Management · Release Management
A change is ready for acceptance when evidence addresses applicable criteria and RUN understands the actual state, limits, and available recovery.
Reference: Architecture strategies for safe deployment practices · BigSavant Change Management 2026.1; independent technical curriculum