Automating a sensitive process without losing traceability

When we automate a process, we think about time saved first. That is fair: nobody misses the hours spent copying forms or reformatting spreadsheets. But for a sensitive process, one that handles health data, payroll or invoicing, time saved is the wrong measure of success. The right measure is whether you can answer a simple question six months later: why did the system do that?

A manual process has an underrated advantage: it leaves human traces. An email, initials on a document, a colleague’s memory. Those traces are imperfect, but they exist. A poorly designed automation erases them and replaces them with a black box that acts fast and remembers nothing. That is where team distrust and unexplainable incidents come from.

Here is what I have learned designing systems that automate this kind of process, in particular filling after-sales forms from incoming files, and reading supplementary health insurance cards.

Separate the rule from its execution

The first mistake is to confuse a rule with its application. In a routing system, for instance, an incoming record has to be sent to one or more forms depending on its content. The temptation is to compute the destination once, on arrival, and never look at it again.

The problem shows up with the first rule change. If the destination is computed on arrival, every pending record keeps the old logic. If it is recomputed continuously, you no longer know which rule actually produced a form that has already been filled.

The approach taken on the after-sales routing project for Santécie rests on two principles. First, the destination is resolved at execution time, with the rules in force at that moment. Second, that resolution is frozen with the execution: every filled form keeps a record of the rule, and the version of the rule, that produced it. You can fix a rule tomorrow without rewriting yesterday’s history.

This decoupling has a cost: rules must be versioned, and a forecast shown on screen is not authoritative. I explicitly separated the routing “projection”, a forecast useful for browsing, from the actual “assignment”, computed just before filling. That distinction in vocabulary saved many misunderstandings with users.

Name things before you automate them

Traceability starts with vocabulary. If the business team and the technical team do not use the same words for the same things, no history will ever be readable.

On that project, I kept a shared glossary with the team, with a short definition for every term and the words to avoid. A “request” is not a “batch”, an “execution” is not a “file”, a “replay” is not a “completion”. These distinctions look pedantic. They become essential the day a user asks why a form was filled twice: the answer depends precisely on the difference between replaying a whole request and completing only what had failed.

I recommend such a glossary to any organisation automating a sensitive process. It costs a few hours at the start and saves many more at every incident.

Keep people where they bring judgement

Automating does not mean automating everything. In a sensitive process, some decisions must stay human, because they commit the organisation or because the machine makes mistakes it cannot detect.

The health insurance card reading demonstrator I designed for Santécie is a good example. The system extracts the text from a card and proposes business fields. But every field stays optional and editable, and a person reviews before anything is confirmed. The system does not check entitlements and makes no automated decision. It prepares; a person validates.

The same principle applies to my own operations. When agents prepare my monthly invoicing, they draft the invoice and the email, but nothing is sent without my explicit approval. Human validation is not a formality tacked on at the end: it is a step of the process, checked against specific data, such as the amount, the recipient or the period, rather than a general impression.

So the question is not “what can we automate?” but “where does human judgement add something a rule cannot capture?”. That is where the approval points belong.

Keep data where it should stay

Traceability also covers the path the data takes. In a process that handles health data, knowing where it travels matters as much as knowing what the system does with it.

On the card reading project, processing is designed to stay on the user’s machine. An external service is only considered for benchmarking, and only with a zero data retention guarantee. Real samples never leave the client’s environment. That discipline has a price: some services, easier to plug in, are ruled out from the start. But it gives a clear answer to the question a compliance officer will ask sooner or later.

Make every step replayable

An automated process will eventually fail. A malformed file, a service outage, an incomplete rule. The goal is not to avoid every failure but to recover cleanly.

That requires every step to be identifiable and replayable on its own. If a record is routed to three forms and one fails, you should be able to rerun that one form, without redoing the other two and without creating duplicates. On the OCR benchmark, every pipeline version produces immutable artefacts: two runs can be compared without wondering whether something changed in between.

This is not technical polish. It is what lets a team fix an incident in a few steps, instead of redoing everything by hand and losing trust in the tool along the way.

Write down decisions, not just code

One last, often neglected point: architecture decisions should be written down. Not in a fifty-page document nobody reads, but in short notes, one per decision, stating what was chosen, why, and which options were set aside.

On the card reading project, eleven such decisions were recorded: the split between control and execution, immutable artefacts, the conditions for using an external API, the deployment target. The day an auditor, a new developer or the client asks why the system works this way, the answer already exists.

Where to start

If you are considering automating a sensitive process, here are three questions to ask before writing a single line of code:

1. What will you need to explain in six months? List the questions an auditor, a client or a colleague might ask. The system must be able to answer them.
2. Where is human judgement irreplaceable? Put your approval points there, and make them proper steps of the process.
3. What happens when a step fails? If the answer is “we start over”, the system is not ready.

Useful automation does not take people out of the process. It takes the mechanical gestures off their hands, and leaves them, with a better memory, what calls for discernment.