IT tender analysis. Inside the NS SR decisions system

A supplier pricing IS Rozhodnutia NS SR has to account for two separate environments. Staff will work with unpublished court documents internally. The public will see approved decisions. Moving content safely between them affects the whole delivery, from migration to support.

Tender.sk suggested this procurement after consulting its data team. We chose it for our planned joint IT tender analysis. This article is Rise.sk's contribution on the technical work.

This is a review of public procurement documents. Rise.sk has not delivered the system. The EVO record listed the competition as active when checked on 19 October 2026, with bids due on 19 November 2026 at 10:00.

Before committing to a price, check what your existing product can demonstrate and what needs adapting. Public documents alone cannot establish whether a particular team can deliver on time.

A successful import can still leave decisions hard to find

Imagine opening a migrated decision and finding every page intact. The import looks successful. But its court division has disappeared from the metadata, so anyone searching by that filter misses the document. This is an illustrative migration problem, not a finding about the existing collection.

The requirements catalogue calls for migration of historical and current decisions from NUXEO. The revised specification also requires data-quality management. That makes checking the contents part of the job.

Start with a NUXEO inventory and a representative export. Map each field to its destination and agree how to handle missing values before trying the import. A developer should not guess a missing legal classification. Someone who understands the court's documents needs to decide.

The trial should be repeatable without creating duplicates. Record failures and changed values, with a way to trace each result back to NUXEO. Agree who resolves outstanding differences and how to capture edits made since the trial.

Search needs tests that reflect how people look for decisions

A known case reference should return the right decision. Searching for a legal issue is less straightforward, because relevant decisions may use different words.

The catalogue requires full-text search with filters and related decisions, including partial matches and text similarity. These requirements alone do not imply that a language model must generate legal answers.

Test exact retrieval against approved examples. A case reference should find the expected document, and a date filter should remove the right results. After an edit, check that search finds the new text.

A meaning-based test might use the example query "state liability for delays in proceedings". Someone familiar with the case law must approve relevant results and flag misleading matches before the team tunes the search. A fast response alone proves little.

There is also a question about what the public may search. The catalogue lists FR_008 as a public function but assigns it to Private. Other public functions mention processing states or non-anonymised data. Ask the authority to confirm that allocation before building the filters. Those labels must agree with the separation required by the specification.

Walk one legal document through the API before building the rest

An API can return valid XML and still lose a relationship that another system needs. Take a decision with a reference to legislation. Its export should preserve that reference and point to the applicable version of the legal text.

The specification requires REST interfaces using JSON/XML, with connections to the NS SR Register and systems holding other courts' decisions. IS CSSR requires readiness for a future connection. The authority's clarification identifies RESS and public Ministry of Justice interfaces. Confirm test access for each connection.

The prototype validates against an existing schema. The clarification points to the IS Slov-Lex XML schema. For the final system, the supplier must develop a schema for decisions and opinions, based on the Slov-Lex schema and CEN MetaLex rules. MetaLex provides a structured way to describe legal documents and their relationships.

Start with one decision. Map its text and metadata, preserve its legal references in XML and validate it before testing the API export. The catalogue requires validity checks. For other internal messages, the clarification leaves the format to the bidder.

Authentication belongs in this work too. The catalogue requires OAuth 2.0 and role-based API permissions. Agree what each connected application may retrieve before exposing the endpoints.

A corrected document must change everywhere the public can reach it

Consider a published decision that needs correcting. Updating the page is only part of the work. The previous file might still be downloadable, or an API response might serve an older cached copy. This is another example worth testing before acceptance.

The specification requires physically separate public and private environments, each with its own document-management and full-text components. Content passes one way, into the public environment. Our illustration shows that boundary.

We would transfer the version approved by an authorised person, with only permitted metadata. The operator needs to see whether publication succeeded, including failures where the file transfers but search does not update.

Test a correction through the page and download, then check search, the API and any caches. Repeat the exercise for withdrawal. This makes the publication rules something the team can demonstrate.

For internal access, the catalogue requires a connection to LDAP/Active Directory. The specification adds multi-factor authentication and permissions limited to what each role needs. Removing a button from the screen is not an access test. Revoke a user's rights and try retrieving the same document directly through the API. A technical review of the requirements can help turn these questions into agreed checks.

Include recovery and handover in the delivery estimate

A demonstration can run smoothly while the next operator still cannot restore a backup. Agree how to prove recovery before pricing handover.

The specification requires microservices and containers. We recommend repeatable deployment and a recovery test using the delivered configuration. The catalogue also requires operational documentation and connections to EDR security tooling, backups and planned central monitoring.

Confirm the assumptions before pricing

Several differences in the documents affect the estimate. The catalogue specifies at least 320 concurrent users in one requirement, but 320 users and 100 concurrent accesses in another. Confirm expected use and document sizes, then use that basis for performance testing.

For the prototype, the clarification allows 30 days from receipt of the instruction to begin, while Article VII of the draft contract uses one month. Confirm the binding deadline against the delivery schedule. The supplier may host the prototype using public or anonymised data. Meeting that early deadline depends on how much of the existing product is ready.

Availability needs the same care. The catalogue gives 99%, whereas the specification requires 99.5% outside planned maintenance and the draft contract uses 99.5% per calendar month. Agree how availability will be measured, including exclusions. Confirm the target with the authority.

Allow time for the next operator to take over

Acceptance includes recovery testing and handover of bespoke source code with the data model. Standard and third-party software have licensing exceptions. Article IX of the draft contract requires five years of manufacturer support for third-party software, included in the delivery price. This is separate from the optional 12-month service package, which starts only if the customer orders it.

For custom software development, we suggest the following estimate breakdown. The authority does not prescribe this structure.

Agree who accepts each output and owns shared tests. Our software-supplier due-diligence checklist covers the handover questions in more detail.

Alongside the estimate, decide whether the company meets the participation conditions and whether preparing a bid is worthwhile. Tender.sk's analysis service helps assess those conditions. Its public offer includes AI answers linked to source documents and help from a procurement specialist. Our contribution addresses whether the team can deliver the system and what its estimate needs to cover.

Five questions to settle before committing to a price

1. What is actually in NUXEO? Request an inventory and a representative export. Agree how the migration report will record differences and who will decide what to do with them.
2. What must search find? Ask the people responsible for the court's content to approve example queries and expected results. Confirm which filters and data belong in the public environment.
3. Can we demonstrate a valid document exchange? Request a sample prototype XML export and test access for the connected systems. Name the person who will approve the final schema.
4. What happens when a published decision changes? Agree the publication rules and a correction test that follows the document through search, downloads, the API and caches.
5. What exactly will the authority accept? Confirm expected use and the prototype deadline with the operations and contract owners. Agree the evidence required for recovery and handover.

Cover photograph by Mikhail Nilov on Pexels, used as an illustration.