A clear status for the morning data

1. Agree what should arrive

The source is the system holding the original orders. The destination is the system receiving the reporting copy. A job is one attempt to transfer that data.

Delivery

Orders for 2 October 2026: from 00:00 that day up to, but excluding, 00:00 on 3 October. All times use Asia/Riyadh (UTC+3).

Schedule

Source ready by 06:00 on 3 October. Start transfer at 06:00 only when all three source batches are confirmed. Destination due by 06:10; verify at 06:15. The team needs the copy at 07:00.

Expected contents

An approved copy of one day's orders in three groups called batches: six different order numbers (IDs), worth 600 Saudi riyals (SAR). No orders are removed and no values are changed. The person responsible for the source approves this expected list independently of the record of the transfer attempt.

Required columns

Order ID (text), order date (date), batch ID (text) and amount (numeric SAR). Hold changed or missing columns for review; do not silently skip them.

Owners

Source owner: operations coordinator. Transfer and recovery: data operator. Business use: reporting owner. Deputy: support lead. These are example roles, not service commitments.

2. Keep the expected records visible

Each row has order date 2026-10-02. Batch totals: A = 200, B = 200, C = 200. Total = 6 orders / SAR 600.

At 06:15, compare this exact dated version with the destination. Check that every order ID and amount matches, no ID repeats, and all three batches are present. Confirm six rows and SAR 600. Record the source-ready, load-finished and verification times separately. A matching count alone can hide a missing order replaced by a duplicate.

The freshness check uses both the covered day and actual arrival time. A new timestamp on the previous day's copy fails. If the expected set or destination evidence is unavailable, readiness is unknown; missing evidence is never zero.

3. Give each result a different response

These are alternative runs of the same delivery, not consecutive events or measured service performance.

Record the exception, covered day, expected and observed contents, last verified copy, responsible person and next check. At 06:15 the operator tells the reporting owner about any unready delivery. If unresolved at 06:20, involve the support lead and record the next update time. The reporting owner tells affected colleagues that the requested 2 October reporting copy is not yet ready. These are chosen example times, not response promises.

4. Recover the incomplete copy safely

1. Keep the evidence. Keep the record of the incomplete transfer and its four-order copy. Keep the previous verified day visible with its date; do not overwrite it with a partial result.
2. Confirm what can be repeated. Inspect the receiving system. Keep an unchanged copy of the original records approved for 2 October. Check its columns and six IDs. Stop if the source has changed, a newer approved copy exists, or it is unclear whether another transfer could create duplicates.
3. Prepare a separate replacement. After fixing the skipped-batch cause, rebuild all six rows in a separate area. For this example, the system can replace the day's entire copy at once and prevent the same order number appearing twice within that day. Confirm these controls, and prevent other processes from changing that day's data during replacement. If the system cannot do this, stop and agree another recovery method. Do not add the new copy to the records already there.
4. Check before replacement. Match all six IDs, per-order amounts, three batch totals and SAR 600 against the frozen source. Replace only 2 October after these checks pass. Keep the earlier incomplete copy as evidence, outside the view used by the team.
5. Verify after replacement. At 06:35, read the destination again: 6 rows / SAR 600, correct period, columns and IDs. The reporting owner accepts it for use. Show Ready after recovery · loaded 06:32 · verified 06:35. Keep the original missed deadline in the history; close the incident with the owner, cause, action and verification evidence.

If the same approved copy is transferred again using this whole-day replacement method, the result still contains six orders worth SAR 600, not twelve worth SAR 1,200. This is the example's required behavior, not a promise that any system can be rerun safely. A late source also needs all checks after it arrives; it does not become ready merely because the file appeared.

5. Challenge the result before adopting the routine

• Six rows and SAR 600, but only the ID on O-106 was changed to O-105; its SAR 110 amount stays unchanged: hold. IDs do not match and one repeats.
• Six correct IDs, but O-106 is SAR 100: hold. The total is SAR 590 and that order differs from the source.
• The copy contains an older day's orders, even though it was transferred today: do not approve it. A new transfer time does not change the day the records describe.
• Missing amount column or an unapproved format change: hold for review. Do not discard affected rows to make the job finish.
• The expected number of orders is missing, or the reporting copy cannot be checked: not verified. A genuine zero-order day requires the source owner's explicit confirmation of zero expected orders, plus the normal period and destination checks.

Delivery checks cannot prove the source recorded every real order or that its values are correct. Record-quality checks and decisions about sending reports remain separate. Adapt the expected set, schedule, permissions and recovery controls to your systems before using this specification.

Method references: Google Cloud monitoring shows the transfer status, measurements and event records separately; Microsoft's retry pattern explains why the cause of a failure and the effects of repeating an action matter. Neither source establishes the example's chosen deadlines or guarantees recovery.