A manual fix should keep the old receipt attached

Teams often discover the real weakness in their delivery system only after automation stops being enough.

A webhook is stuck.

A payout row needs human repair.

A publication entry must be corrected by hand before the rest of the pipeline can continue.

At that point somebody opens an admin tool, runs a script, or patches a record directly.

The dangerous version of this story is not manual intervention by itself.

The dangerous version is a manual fix that starts a fresh success record while dropping the earlier receipt trail that explains why the fix became necessary.

That leaves the system with two histories.

One history says the original attempt entered uncertainty.

The other says a later human action resolved the problem.

If those histories are not attached, later readers are forced to guess whether the manual step repaired the same obligation, created a second one, or quietly overwrote the evidence of the first.

The safer rule is simple: a manual fix should keep the old receipt attached.

Manual repair is still part of the same obligation #

Teams sometimes treat manual work as though it sits outside the delivery lifecycle.

Automation tried.

Automation failed.

Now a person handled it.

That sounds tidy and is often false.

The customer, provider, or downstream system is still dealing with one obligation.

The only thing that changed is who carried the next step.

If the original delivery created receipt rcpt_7138, then a manual resend, direct reconciliation, or support-assisted completion should still point back to rcpt_7138 unless a real second obligation was deliberately created.

Otherwise the evidence trail becomes weaker at the exact moment when the system needs it most.

The old receipt tells you what uncertainty existed before the human touched anything.

The manual action tells you what repair path was chosen afterward.

Those two facts belong together.

A clean second history hides duplicate-work risk #

One common failure mode is an admin tool that records the manual fix as a brand new success row.

The screen looks cleaner afterward.

The unresolved item disappears.

A fresh completed record appears.

Operationally, this feels satisfying.

Audit-wise, it is a trap.

Now the system may look like it handled two separate events: the original uncertain attempt and a later independent success.

If somebody later asks whether the manual step duplicated remote work, the answer is harder to prove.

If finance asks which external identifier settled the obligation, the operator may have to compare separate histories that should never have been separated.

If support needs to explain what happened to a customer, they may see a manual success without the earlier receipt that made the success necessary.

The product has not only lost clarity.

It has weakened its ability to prove whether the manual correction was a replay, a continuation, a reconciliation, or an override.

That distinction matters.

Different fixes create different risks.

A continuation should inherit the old receipt.

A deliberate second obligation should say explicitly that it is second.

A reconciliation step should preserve both the original receipt and the fact that final certainty came from comparison rather than replay.

The product should not force future readers to infer which path occurred.

Support and reconciliation should read the same chain #

Attached receipts are not only for engineering.

Support benefits because they can explain the incident without improvising a timeline from scattered records.

Reconciliation benefits because they can follow one chain from original uncertainty to human repair to final classification.

Reviewers benefit because they can tell whether manual intervention repaired the oldest unresolved obligation or quietly created a new one that happened to make the dashboard greener.

This becomes especially important when the remote side already accepted some part of the original attempt.

Suppose a provider issued a reference, but the final status stayed unclear.

Hours later an operator manually completes the workflow using a narrower tool.

If the manual fix carries the original receipt forward, later review can ask the right question: did the operator resolve the same externally identified work.

If the receipt disappears, the review question gets weaker: did a human eventually make something succeed somehow.

That is not good enough for systems that care about duplicate delivery, settlement truth, or incident learning.

The manual step needs its own record, not its own detached past #

Keeping the old receipt attached does not mean hiding manual intervention.

The opposite.

The product should say clearly that a human stepped in, why that step was allowed, and what command or path was used.

But it should say those things inside the same evidence chain.

Original receipt.

Original uncertainty.

Manual actor.

Manual action.

Final outcome.

That structure preserves both truths at once: automation was not enough, and the human repair still belonged to the same obligation.

It also improves later product work.

When teams review incident patterns, they can see whether the problem was lookup weakness, replay design, admin-tool ergonomics, or a provider gap that keeps forcing humans into the loop.

Detached manual-success records blur all of those causes together.

Attached receipts keep the failure and the repair in one inspectable line.

At Stack Dispatch we care about this because manual work is inevitable in real systems.

What matters is whether the product treats manual intervention as part of the truth trail or as an excuse to start a cleaner but less honest history.

A manual fix should keep the old receipt attached because the system does not become easier to trust when human repair erases the path that made repair necessary.

It becomes easier to trust when the correction stays visibly tied to the original proof.