# Switchover and Failback Procedure — template to adapt

The Capordia case is a team processing independent batches. The objective
is to resume the identified work without losing its acceptance. A
planned interruption is possible. The allowable duration, quality criteria and responsibilities are decided before the migration window.

## 1. Assign responsibilities

| Role | Responsibility | Evidence to retain |
|---|---|---|
| Switchover lead | Authorizes stop, change of authority and resume | Decision and UTC time |
| Data owner | Freezes inputs, checks copy and inventory | Versioned manifest and checksums |
| Processing owner | Stops the producer, classifies attempts | Batch register and process log |
| Acceptance owner | Compares outputs and agreed criteria | Results, rejections and acceptance agreement |

A small team may combine roles, but the person who pronounces
acceptance and the person who knows how to stop the old authority must be
identifiable. The CSV template provided does not impose any person's name.

## 2. Establish the baseline before copying

Assign each batch a stable identifier and an input version.
Record its path, its checksum, the exact processing and the acceptance
criterion. Distinguish a launched attempt from an accepted result.
Retain the parameters and dependencies needed for the resume, including
the computation states your software requires. A file name `final`
is not enough to prove acceptance.

In the exercise, eight batches represent 48 fictional coupons. Acceptance
relies on a deterministic result in integers; this is not a GPU
checkpoint model. The eight baseline outputs are computed before the cutover.

## 3. Stop the arrival of new work

Close admission of new batches and note the last admitted identifier.
Stop the worker or wait for the planned resume boundary. Confirm
that no process on the old machine can still accept outputs.
Classify the register: completed, in progress, to resume. Preserve the traces
of an ambiguous batch instead of declaring it completed by assumption.

In the exercise, the cutover on LOT-004 gives 3 / 1 / 4. A restart without
reconciliation is refused. The register and its results stay together.

## 4. Copy, check, change authority

The target must have the frozen set, the required state and the compatible
program. Verify the checksums and the inventory from the target.
Block the resume if an input is missing, if the manifest has changed or if a
result no longer matches its checksum and the acceptance rule.

In this exercise, `basculer` first closes the source, then copies the
files after connections are closed. The program opens the target to
production only after checking. Do not imitate a hot copy of an
active database outside this procedure. A failure leaves the source stopped.

In a real system, closing a local file does not prevent an isolated old
machine from continuing. An exclusive publication right must be enforced
by the system that receives the results, with rejection of the old rights
and proof of that rejection. This program does not provide that protection.

## 5. Reconcile and accept

Verify that all completed results are present and acceptable.
In-progress attempts without acceptance are reset to resume after
confirmation that their old producer has stopped. Perform a limited resume
before reopening admission. Count the expected batches, the unique
accepted identifiers, the errors and the resumes. Record an acceptance
distinct from the mere end of the process.

In the program: `preparer-reprise` turns the single in-progress batch into a batch
to resume. `executer` does not recompute the three completed batches. The final
check requires eight accepted outputs identical to the baseline. LOT-004 has
two attempts, but only one accepted output.

## 6. Trigger the failback on an observable signal

| Signal | Proposed decision for this exercise |
|---|---|
| Different input fingerprint | Block before processing; retrieve the frozen version |
| Missing or altered result | Block acceptance; examine the batch and the state |
| Two possible authorities | Stop the resumption; establish a single authority |
| Program unable to resume | Keep admission closed and transfer the recent state to the compatible environment |
| Window deadline exceeded | Apply the decision and the limit set by the team before cutover |

If the target has already accepted new results, reverting to the old copy
of the source would lose those acceptances. Freeze the target, export its recent
state, verify it, and transfer it to a new return location.
Reconcile the results before restarting. In the presence of external effects,
their inventory is part of the return; this exercise produces none.

```text
python exercice.py basculer --source manuel/cible --destination manuel/retour --proprietaire atelier-retour
python exercice.py preparer-reprise --dossier manuel/retour
python exercice.py executer --dossier manuel/retour
python exercice.py comparer --reference manuel/reference --candidat manuel/retour
```

After this operation, `manuel/source` and `manuel/cible` are closed. Only
`manuel/retour` can work. If the copy fails or if the check rejects
a result, keep the evidence and do not unlock two producers.

## 7. Close the migration

Keep the manifest, before/after registry, fingerprints, check results,
program version, resumption decision, and any return decision.
Delete the old copy only after the retention period chosen
by the team. The exercise deletes no folders; its resources are
fictional and can be archived with the report.