What production teaches us about regulation

Overview

The feature had already been analysed, implemented and used in production. The first rollout covered the regulatory interpretation and business scenarios agreed at the time.

Later, customer usage exposed workflows that had not previously needed explicit treatment. Some were usability problems. Others raised questions about how the regulation should apply in a more specific operational situation.

The first implementation was not being declared invalid. Production had simply given us more evidence than we had during the original analysis.

---

Context

The feedback divided into two streams.

The first concerned workflows that were compliant but unnecessarily difficult for users. Those could be analysed as product improvements without changing the regulatory interpretation.

The second concerned exceptional cases. Looking at them individually would have been quicker, but it would not have answered the more important question: if several new cases had appeared, were there other scenarios that the original model also left implicit?

That was the point at which the subject had to be reopened more broadly.

---

Defining the problem

I did not want to turn each customer report directly into a separate patch. Once the regulatory model was open again, it made more sense to review the rules one by one and check whether the implementation still represented them coherently.

The question shifted from how do we support this case? to what does this case tell us about the completeness of the model?

The first question leads quickly to a solution. The second may reveal that the apparent exception is connected to several existing rules and should not be handled in isolation.

---

Making decisions

The optimisation work and the regulatory review needed different validation paths.

I was not trying to prove that the first release was right or wrong. It was to decide whether the evidence from production justified making additional cases explicit in the model.

---

Validating decisions

For the workflow improvements, the analysis is complete and waiting for refinement and development.

The regulatory review is still in progress. Each relevant rule is being checked against the newly observed scenarios, and the interpretation will be discussed with the customer before implementation choices are finalised.

I kept that order on purpose. Starting development too early would make the technical solution part of the argument, when the business interpretation is what still needs to be tested.

---

Current status

The two streams are now at different stages. The optimisation work is ready to move forward. The broader review is not finished, and the customer workshop has not yet taken place.

There is no final outcome to present yet. What it can show is the analysis strategy: use the reported cases as evidence, but do not assume they define the full scope of the problem.

---

Perspective

Before this work, I tended to place regulatory analysis before implementation and production validation after it. The boundary is less clean in practice.

Specifications describe expected situations. Production reveals combinations, exceptions and user behaviour that are difficult to anticipate in full. That new information does not automatically mean the original interpretation was poor. It means the model can now be tested against a richer reality.

For regulated products, analysis sometimes continues after release—not because the work failed, but because the product has finally encountered the situations that make the rules concrete.

---

Key takeaway

When production reveals a new regulatory case, the useful question is not only how to fix it, but whether it changes our understanding of the model as a whole.