Error Correction

One successful import and two wrong salaries

A company moves payroll to a new system. The first monthly file contains 8,000 employee records, the provider accepts all 8,000 rows and the dashboard reports a successful import.

Two records contain a formatting error. A field shifts position, sending too little money to one employee and too much to another. Every component performed the task it was asked to perform, yet the final state is wrong.

The underpaid employee discovers the mistake only after rent is due. She sends the same evidence to payroll, the provider and her manager because each system shows a completed transaction and nobody owns the mismatch between them.

The organisation could send a payroll file. It had no reliable way to notice and fix a wrong salary once the provider accepted it.

Error Correction means building for the fact that errors happen. The system keeps a separate way to spot them, limits how far they travel and has a safe way to put the affected part right.

What a correction path needs

Error correction needs more than an alarm.

1. A clear idea of right. Decide what has to be true. Payroll totals must add up, every employee identifier must appear once and each payment must match an approved record.
2. A second source of evidence. Keep a signal that can disagree with the main process. “File accepted” only says the provider received it, not that every salary is right.
3. A way to find the bad part. One mismatch should not make the whole batch impossible to trust.
4. A repair action. The team needs a way to pause, correct and safely replay the affected records without paying everyone twice.
5. A lesson that changes the process. Feed the failure back into validation and ownership so it is easier to catch next time.

Before sending the money, the payroll team could compare the total in the file with the total the company approved, check that each employee and account change is valid, and hold only the mismatches for review. Each payment also needs a unique reference that the provider recognises if the same request is sent again, so a retry does not pay someone twice. If a completed payment is wrong, record a separate correction or reversal instead of deleting the original payment.

The extra check looks like duplicate work on a good day. Its value shows up on the day the two records disagree.

Why efficient-looking systems lose the ability to correct

Teams often remove duplicate records, spare capacity and human review because all of them look wasteful when nothing is going wrong.

Some duplication is waste, while some gives you a genuinely separate view. When one pipeline creates the data, validates it and reports its own success, three green indicators can still be the same claim repeated three times.

The check must use evidence that can disagree with the process being checked.

This is why checksums add extra bits to a message, reconciliation keeps a separate record of the same money, and an appeal lets another decision-maker inspect a case. Each is useful because it can show that the first process got the result wrong.

Ask which different failures each check can detect. Three checks built from the same bad source still give one view.

How the same mechanism works elsewhere

Information theory and software. Error-correcting codes add a pattern to a message that gives the receiver another way to check it. If part of the message changes in transit, the receiver can use the pattern to spot the damage and sometimes rebuild the original. Software uses comparable checks: a checksum reveals whether data changed, a second log provides another record, a database rule rejects an invalid state, and a unique request reference keeps a retry from doing the work twice. These checks can prove that a message arrived intact, but they cannot prove that the instruction inside was right.

Biology. DNA replication is accurate because cells combine complementary pairing, proofreading and repair pathways. A damaged base can be identified because the surrounding structure provides evidence about what belongs there. Several repair mechanisms reduce different classes of error, while shared environmental damage can overwhelm them together. Biology also shows the cost of correction: repair consumes energy and occasionally removes a change that would have been useful variation.

Law and organisational design. Appeals, audits, double-entry bookkeeping and independent review create routes through which an initial decision can be challenged and repaired. Their strength comes from separation: an appeal heard by the same person using the same evidence may only repeat the original error. They also give a person a defined route to challenge and correct an institution's finished record. Legal correction must consider reasons, rights and unequal consequences, not only restore a prior state.

In each case, define a valid result, check it with independent evidence and make the affected unit cheap enough to repair.

Where to build this in

Use this model for data imports, payments, medical handoffs, automated decisions, contracts, approvals and any process where a mistake can travel faster than people can inspect it.

Ask:

1. What must remain true after the process completes?
2. What evidence is independent of the component being checked?
3. Can the system locate the bad unit without stopping every good unit?
4. Can that unit be reversed, replayed or compensated safely?
5. Who can raise an exception, and who owns resolving it?
6. Does the correction preserve an audit trail?
7. Which correlated failure could fool every check at once?

Small units of work usually make correction cheaper. A staged migration, bounded transaction or reversible decision lets the system repair one part without reopening everything.

When more checks stop helping

More checks can make a system slower without making it safer.

Two reviewers may share the same blind spot. A reconciliation built from the same corrupted source isn't independent. An exception queue with no owner only gives errors somewhere to wait. Requiring approval for every reversible action can exhaust people until they approve by habit.

There's also a deeper limit. Error correction restores a defined valid state. If that definition is wrong, the system can become very good at preserving the wrong outcome. A payroll process may reconcile every payment perfectly while using an unfair compensation rule.

Use the smallest independent checks that cover important failure modes, then measure whether they find distinct errors and whether repair actually happens.

Related models

Signal Detection Theory asks how evidence separates a meaningful signal from noise and when that evidence should trigger action. Error Correction starts once a deviation is detectable and asks how the system can locate the damage and restore a valid state. A warning without a repair path leaves the problem known and unresolved.

Margin of Safety creates enough distance from failure for ordinary uncertainty to remain survivable. Error Correction reduces how long and how far an error persists after it occurs. A cash reserve can absorb a wrong payment; reconciliation and compensation repair it.

Getting an output is only the first step. The process also needs a separate check and a repair that does not mean rerunning everything.