“The projects were too broad, inadequately planned, insufficiently coordinated, insufficiently user-oriented and short of ICT competence.”
There is little wrong with this diagnosis.
But it may not be deep enough.
It describes what became visible when Finnish justice-sector information-system programmes struggled to deliver the expected interoperable whole. The findings describe the programme’s condition, but not necessarily the mechanism that produced it.
If scope was too broad, why did it become too broad? If coordination was insufficient, why did separately developed systems depend on coordination for success? If interoperability was critical, why could projects progress while it remained unresolved?
Those questions take us beyond project management, to the way the system itself was understood.
A complex digital system is easily treated as a collection of requirements, applications and interfaces. Work is divided across organizations, suppliers and teams, each responsible for its own part. When those parts are later integrated, the whole is expected to emerge.
Yet the whole can still fail.
In criminal justice, the real system is not the software. It is the continuous movement of a case through evidence, authority, decisions, documents and state changes. Different organizations may use different applications, but the case does not become a different reality at each boundary.
Before asking what functionality each application needs, we should ask what reality all of them must preserve together. What makes evidence authoritative? When is a role legally valid? What makes a document authoritative, and what must be true before the case may move to its next state? Which rules must remain invariant, and where is variation legitimate?
These questions form the cognitive model of the system.
If that model is not explicit and shared, hundreds of requirements can coexist with several different understandings of what is actually being built. Each team may make locally reasonable decisions and each supplier may satisfy its own contract, while milestones continue to move forward.
And the system can fragment before anyone notices.
This is why “insufficient coordination” may itself be a surface diagnosis.
If one legally continuous process is decomposed into several systems that must later be coordinated back into coherence, coordination has already been given too much responsibility. Meetings can exchange information. They cannot manufacture a missing system contract afterwards.
Interoperability should not be something we hope will emerge because projects cooperate well. It should be an invariant.
Therefore, perhaps A–B–C will work.
A, B and C are acceptable only if they preserve its rules.
The weaker model says: A works, B works and C works, so perhaps A–B–C will work. The stronger model says the end-to-end process must work, so A, B and C are acceptable only if they preserve its rules.
AIPA’s functions were pushed toward uniformity even though prosecutors and courts do not perform identical work. Reuse is sensible. But perhaps the wrong layer was standardized.
A prosecutor and a judge do not necessarily need the same workflow. What should be common is the structure underneath the workflow: a stable identity for the case and its evidence, traceable provenance, authoritative documents, valid roles and authority, explicit state-transition rules and auditability.
That matters when system activity is confused with system reality.
One reported AIPA problem illustrates this: information could appear to have been sent even when the recipient had not received it. Other reports describe incorrect roles and changing or disappearing material. The reports do not reveal the technical cause. But they reveal the class of problem to design against.
A critical system should not believe something happened merely because an operation was attempted.
“Send document” is an activity.
A verified state transition is something else: the correct document and version must exist, the recipient and authority must be valid, the transfer must occur through an accepted channel, and evidence of that transfer must exist.
Those are not the same thing.
This is where evidence-gated pipelines matter far beyond AI systems.
A transition is allowed only when required evidence exists, has the correct provenance and has been validated. If it is missing or unresolved, the system does not silently continue. That leads to another familiar answer to large-project failure: incremental development. Incrementality is sensible, but this case supports a more uncomfortable hypothesis:
You can build incrementally and still build the wrong decomposition. Feature A can be followed by B and C without ever proving that A–B–C preserves the end-to-end truth of the system.
Traditional MVP thinking often asks what minimum functionality can be released. A kernel-first approach asks something different:
What is the smallest end-to-end system whose correctness we can actually demonstrate?
For a justice process, this could mean choosing one constrained case type and carrying it all the way through with realistic evidence, real roles and authority, a real decision path, a real transfer and a verifiable final state. Not a mock-up of the chain, but the smallest meaningful version of the chain itself.
Then try to break it.
Verify that evidence survives the journey, roles cannot mutate without authorized cause, documents cannot silently change, and critical states remain traceable to the evidence that justified them.
Only then has the programme proven something structurally important.
From there, the system can grow by adding domain variation, new case types, exceptions, integrations and richer functionality — but every addition must preserve the kernel contracts already proven.
This changes development from implementation of assumed knowledge into structured hypothesis verification. A requirement is not knowledge because it appears in a specification. A process diagram is not reality because stakeholders approved it. An integration design is not proof that information remains correct across organizational boundaries. They remain hypotheses until the system demonstrates them against reality.
User involvement also gains a more precise meaning: users should validate not only usability and workflow, but the cognitive model itself.
A beautifully designed interface on top of the wrong model is still the wrong system.
None of this means evidence gating or kernel-first development would have prevented every AIPA problem. Capacity, security, procurement, suppliers and resilience still matter.
But the approach changes something extremely important: when contradictions are discovered. Instead of allowing uncertainty to accumulate behind milestones, it forces the programme to confront uncertainty while the system is still small. Instead of scaling assumptions, it scales verified learning. The most dangerous moment in a complex programme may be much earlier than failure: when everyone believes they share an understanding because they share a roadmap, vocabulary and requirements.
A shared plan is not the same thing as a shared cognitive model. Three functioning applications are not the same thing as one functioning system. And incrementality is not controlled learning if the core has never been proven.
The encouraging part is that none of this requires magic.
The alternative is a different order of operations: make the cognitive model explicit, turn its critical truths into invariants, prove the smallest meaningful end-to-end kernel against real evidence and failure modes, and only then let domain layers and functionality accumulate around it. Each new layer is another hypothesis to verify, not another assumption to scale.
Complexity will not disappear. But complexity does not need to be accepted all at once.
Cases like this are not inevitable. We can choose a different order of operations.
We do not have to become better at managing enormous complexity after we have created it.