Table of Contents

A court IT system is not built only in code. Hundreds of documents come before it and run alongside it: the specifications a developer builds from, the regulations that give electronic actions legal force, the audits that show the real state of things, the strategy papers that decide where it all goes next.

Working through those documents is where most of the influence over the final system actually sits. What follows is not a file list. It is an account of the kinds of documents involved and why each kind matters.

The total is 175 substantive documents covering 33 subsystems, modules and cross-cutting areas. Correspondence, queries, extracts and working drafts are not counted — only documents that stand on their own.

Technical specifications — 47 documents

The group with the most leverage. A specification is what a developer builds from. Anything left out of it will not exist in the system. Anything written loosely will be built the way the contractor happened to read it.

That makes the review stage the cheapest moment to change anything. Here a fix costs a comment in a table. After delivery, the same fix costs a separate contract, money and months.

The work covered requirements for the electronic cabinet, document management, the judicial dossier, the HR and budget modules, core services and access control, the register of enforcement documents, the register of court decisions, the contact centre and the data exchange modules.

In practice this is not “read and approve”. It means functionality comparison tables, analytical reports on requirements, consolidated lists, and records of disagreement — documents that pin down exactly where the client and the contractor failed to agree. Those matter most: a disagreement nobody wrote down turns, later, into an argument about whether the work was ever in scope.

Audits — 22 documents

An audit answers the one question that cannot be answered from inside: whether the things declared to be working actually work.

Two kinds were carried out. A functional audit asks whether the system covers what a court really does, and whether it matches how a case actually moves. A technical audit looks at the software, the hardware, the documentation, the support arrangements, information security, and whether the system can be developed further at all.

Individual modules were covered — the electronic cabinet, e-court, video conferencing, the web portal, the register of court decisions, document management in general and specialised courts — along with cross-cutting areas: hardware, support, testing, security, integrations.

A separate layer is state inspection reports: the Accounting Chamber, the State Audit Service, findings from internal investigations. Among other things, these recorded the absence of subsystems that the law requires to exist.

The value of an audit is not the checking itself. It is that the conversation moves from opinion to fact. “The system works badly” can be argued with. A documented finding that a module has no documentation cannot.

Regulation — 42 documents

The largest group by count, and the least visible from outside.

A technical system without a legal basis has no legal force. For an electronic summons to count as served, for a document filed through the cabinet to carry the same weight as a paper one, for an action taken in the system to be open to appeal — all of it has to be written into a regulation.

The central document is the UJITS Regulation, which governs how the system and its individual subsystems operate. Work on it runs for years: the system grows, modules appear, legislation changes, and every change has to be written back into the Regulation.

The mechanics look like amendment tables: current wording, proposed wording, reasoning. The work covered changes to the data exchange module, automated case assignment, role allocation within the system, oversight of development, the cabinet for legal entities, and the judicial dossier.

It also includes consolidating what courts propose. When dozens of courts send comments on a draft, someone has to collate them, compare them, discard the contradictory ones and produce a final version. It is unglamorous work, and it decides whether the resulting rule can be applied in practice at all.

Strategy and concept papers — 27 documents

The documents that set direction: what the system should become, in what order it should be built, and how that connects to what the state has committed to.

This covers successive editions of the Concept for building the system, strategy documents, roadmaps, feasibility studies and implementation plans. Separately, it covers papers tying the digitalisation of justice to broader rule-of-law obligations.

Their value is that they supply the yardstick for judging any individual decision. Without a written vision, every proposal is argued on its own terms, and the system grows into a collection of unconnected modules.

Reports and analysis — 22 documents

Interim and final results: working group reports, findings on the state of particular subsystems, analytical notes, analysis of judicial business processes, reports on resources and architecture.

Worth singling out are the business process descriptions — a detailed account of how a case actually moves, from initial filing to enforcement, across civil, commercial, administrative and criminal proceedings. This is the foundation for any technical requirement: you cannot automate a process nobody has described.

Operating documentation

The smallest group, and a necessary one: administrator guides, deployment and data recovery instructions, user manuals.

Their absence is a recurring audit finding. A system only the person who wrote it knows how to maintain is a risk, however good the code.

What this work changes

Document work rarely looks like a result. There is no new button in the interface, no launch to announce. Yet this is where most of what later becomes the system is decided.

Requirements define the product. A function not written into the specification will not appear. One written imprecisely will appear in a form nobody can use.

Regulation defines legal force. The most accomplished system in technical terms counts for nothing if an action taken in it cannot be recognised as legally performed.

Audits define what gets discussed. Until the state of a system is recorded independently, every conversation about its problems is an exchange of impressions.

Strategy defines the order of work. Without it, resources go to whatever is easiest to build rather than whatever is needed most.

The limits of this overview

A few caveats, without which the numbers would mislead.

175 is substantive documents, not the whole of the work. Correspondence, queries, replies, extracts, meeting minutes and working drafts are excluded. The working folder holds several times that volume.

Different versions of one document count once. A concept paper that went through four editions is one entry here, though it took four times the work.

The line around “substantive” is a judgement call. Is an amendment table for a regulation a document in its own right, or one stage of a single long effort? Depending on the answer, the total moves by roughly thirty.

This overview does not disclose content. Much of the material is not public, and security assessment results are not published for obvious reasons. What is described here is the type of document and the nature of the work, not the specific findings.