Questions and Answers from TED-together 

27-28 November 2025

These are the consolidated Questions and Answers (Q&A) addressed during the TED-together event from 27-28 November 2025. Replies to questions posted live during the workshop were reviewed and regrouped or modified for a more cohesive and complete response.

Please note that some answers may no longer be accurate, as the Publications Office has followed up on comments made and may have modified its approach accordingly.

The recordings of the workshop and the slides of the presentations are available in the “Agenda” tab.

SDK Versioning and releases

SDK Version 1.13 standard lifespan was planned to end on 28.11.25 (at the time of the event). Will this lifespan be extended?

Answer: The standard lifespan for SDK 1.13 now ends on 31 March 2026. This means that it will no longer be systematically patched after that date, so it will have some backports from SDK 1.14 but not from 1.15. This is already the case for SDK 1.12, which will not have any patches following SDK 1.14. We will need to extend the extended lifespan for SDK 1.13 and 1.14 so that they can continue to be used to submit notices and allow a suitable transition period to SDK 2.1.

You mentioned the productive date of SDK 1.14 in January 2026. Does the new version contain any backwards incompatible changes?

Answer: It depends on what is meant by backwards incompatibility. In pure SDK terms, it is a minor version, so if your software could understand SDK 1.12 and 1.13 it will understand SDK 1.14. In terms of the notice itself (xml) validation might fail because we have for instance increased the number of rules.

Is there an eForms roadmap available?

Answer: We don’t explicitly have an eForms roadmap, however, you could consult the other resources below:

- follow the issues in the EXEP eForms group https://code.europa.eu/eproc/eforms/crs.  Here we will aim to tag the agreed conclusions with the SDK version where they will be implemented.

- the SDK roadmap at https://docs.ted.europa.eu/eforms-common/roadmap/index.html, which needs to be updated.

eForms SDK

What is the advantage of EFX compared to Schematrons?

Answer: Schematron is a validation engine, it comes with XML based mark-up language that tells the engine where to look in an XML file to find out if the value is correct or not. EFX is a language that is specific to eForms. With EFX you can reference a field with its name, regardless of where it is in the XML. Schematron has no conception about eForms fields, validation rules and business rules. Schematron is merely XPath and XML. The advantages of EFX are inter alia:

- It works across different versions of the SDK.

- If you write something in EFX you can understand that we are talking about eForms.

- You can translate it to various other validation engines, not just Schematron.

- In Schematron there is a single Schematron expression for every single subtype and in EFX you can combine subtypes.

- EFX is expressed using fields which are analogous to the business term in the annex, and objectively easier to understand. 

Is EFX2 available for writing a prototype? Is there a channel for asking questions about it?

Answer: We are very excited you are interested. We will provide information on where to find everything in the announcement of the next alpha release of the SDK on GitHub. Don’t be afraid to ask questions in the GitHub discussions either.

On average, how much will the switch to SDK 2.0 cost for an eSender?

Answer: This will vary a lot depending on the technical implementation of each eSender. If you do not use EFX in your application, the effort will be similar to upgrading to SDK 1.15. If you have developed your own EFX translators, then you will need to update them.

Is there a publicly available tool or script that can generate complete validation files from fields.json?

Answer: No, there is no such tool that generates full validation in a way that the input would be simple fields.json and the output would be complete validation (Schematron). There is not enough information in fields.json.

If you would like to generate client-side validation from fields.json, it is possible but most likely the results will be disappointing due to the limited information in fields.json.

In the future, the rules will be entirely written in EFX and can be generated in Schematron, JavaScript etc. from EFX. This would support client-side validation properly and disambiguate the rules. 

The implementation of eForms introduced major problems with the data and some fields were no longer used in data reporting (e.g. for “number of offers” there was no data at all from some countries in 2024). How is this being solved? By making more information mandatory?

Answer: Early SDK versions had fewer rules. We have since added more rules and the number of mandatory fields increased. For example, “number of tenders” was made mandatory in SDK 1.11 and more tendering statistics will be mandatory in SDK 1.14, which bring the SDK in line with the reporting requirements of the 2014 directives.

In the TED XML files, is there a single unique identifier for the entire procurement procedure (one that links all related notices: including the Prior Information Notice, the Contract Notice, any subsequent updates or modifications, and the final Contract Award Notice)?

Answer: No, that was not the case in the old TED XML forms. It worked with document families, where each notice referred to the previous one stating the publication number. In eForms, we have a procedure ID. It starts at the level of competition notices. Planning notices do not have it and rely on the Previous Planning Identifier (BT-125). This identifier is used in competition notices to refer back to the planning notices.

Is it still necessary to mark one of the buyers as lead buyer, if there is no lead buyer?

Answer: Yes. The lead buyer has one specific role. If you have more than one buyer, the lead buyer is usually the buyer who publishes the notice on the platform and is in charge of the communication.

Standards

As Prozorro uses Open Contracting Data Standard (OCDS), have you compared this standard to eForms? Do you know what you might gain or lose if you are switching to eForms?

Answer: In Prozorro we use OCDS as data standards in our API. If we compare our data structure with eForms, we can see that ¾ of data is similar. At some point, we will be obliged to integrate with TED and therefore become an eSender. We are ready to start this journey!

When will there be a full alignment between the eProcurement Ontology and eForms?

Answer: We are currently working on an alignment between the eProcurement Ontology, eForms, ESPD-EDM and UBL. It is already possible to map from the ontology to both eForms and the ESPD-EDM.

Even though there are systems for eInvoicing, ePayment, etc. in place, why are the open data from these systems not made available?

Answer: Currently eInvoincing and ePayment is not generally provided as open data. However, the data could become available in the future, perhaps as aggregated data, but this will depend on Member States.

The eProcurement Ontology covers eInvocing and ePayment. This could be useful within your own data systems for linking and reusing data.

eProcurement Ontology and European Single Procurement Document

To what extent is the eProcurement Ontology rapidly adaptable to legal changes?

Answer: At the moment the eProcurement Ontology follows the current Directives. It was developed with a working group comprising of people from different Member States and the Directives were followed as much as possible.

The eProcurement Ontology will also be used to work with DG GROW on the draft for the new public procurement legislation: it can be used to model the ideas regarding procedure types and processes and to define terminology. Alignment between the concepts in the new legislation and semantics will make technical implementation easier in the future.

It is important to note that the eProcurement Ontology is not set in stone. Especially with the new legislation, there will most likely be quite a few changes. 

Will there be translations of the eProcurement Ontology?

Answer: As it was a long process to agree upon the eProcurement Ontology in English there are currently no attempts to extend it to other languages because of its granularity. However, in case the eProcurement Ontology will be included in the new public procurement legislation, translations will be required.

Will DG GROW adopt the eProcurement Ontology for the revision of the Directives and will other DGs adopt the eProcurement Ontology in relation to ongoing or new sectoral legislation with public procurement provisions?

Answer: Yes, the idea is to make the eProcurement Ontology much more prominent for the revision and new legislation. Including the eProcurement Ontology’s concepts and the connecting links would provide more clarity also for the eProcurement services.

Regarding sectoral legislation, this is generally not included in the Procurement Ontology. However, we should be able to link to sectoral information from our ontology. Ideally, other domains would have their own ontologies that we can connect to and link the data. 

Assuming that the eProcurement Ontology evolves and there is a new version of it, is there an impact on Public Procurement Data Space and/or the TED Open Data Service? If we are already using the TED Open Data Service as a user or re-user, how will it affect us?

Answer: When the eProcurement Ontology changes, we will update the triple store to contain the information compliant to the new version of the eProcurement Ontology.

In theory, the impact of a drastic change would be that some queries will not work as expected. There will be a way to change the queries so that they will work again and will retrieve better results. However, in practice, as the eProcurement Ontology already covers the whole public procurement domain and is stable, it is likely that we will not see any drastic changes. When we change the eProcurement Ontology, it should generally just be additions. Therefore, the queries will not be changed in a way that previous queries will not work, but there will merely be new available queries you could make.

Caveat: If a lot changes in the new legislation, then we will need to make significant changes in the future. .

Does version 4 of the ESPD-EDM allow for the use of part 4 alpha?

Answer: No, it does not. From a technical point of view, it can be used, but it is not included in the model.

The exclusion is due to enhancements made in version 2 of the ESPD model, which introduced the possibility to define the requirements directly within the ESPD request document. Previously, two separate documents were required. This change meant that the alpha criterion was no longer necessary.

Will there be an updated official portal showcasing all the features and relations added to every new version, like eNotices2 for TED?

Answer: We currently have a demo ESPD that works with version 4. Here, you can see how the ESPD functions, but you cannot export.

At the moment our priority lies in the release of version 5 of the ESPD-EDM. After that, we could focus on possibly creating such a portal. 

Public procurement data

For Prof. Tatrai: Did you look at the proportion of individual contracts with a duration of at least four years concluded with one economic operator? It seems unclear why framework agreements are picked out as particularly harmful vis-à-vis "normal" long duration contracts.

Answer: First of all, we have the problem that we are not able to make any kind of analysis in terms of the mini competitions and the contracts which are the results of framework agreements, as well as for dynamic purchasing systems. In the case of framework agreements, we simply do not have structured information. We have a lot of information, but we cannot even estimate what is happening behind framework agreements in the second phase. In the future it would be good to have more information, but the problem is not just the mini competition but the unique identifier of the economic operator. If for example, the economic operator is the same one submitting a bid in France, in Hungary, in Poland, and we cannot access information like tax numbers in national systems, then we are not able to count them accurately.

I understand your reaction about framework agreements being perceived as “harmful” compared to “normal” long duration contracts. It seems that we do have some issues with framework agreements, but we did it the same as with accelerated procedures. We were dealing with direct contracting although we know that in most cases, it’s legally absolutely ok to have this type of public procurement procedure. When we combine and examine the results of framework agreements with single suppliers, the behaviour of central purchasing bodies and the general duration of framework agreements, it means we maybe have to open up the information because we do overuse the system of framework agreement with single bidder. We do not want to say that frameworks agreements are a bad solution and should not be used but maybe we have to enlighten the regulation a little bit. We have an important opportunity to improve these systems in terms of long-term procurement methods in the EU. 

Is the TED Open Data Service (using SPARQL) capable of replacing TED search API?

Answer: The difference between TED Open Data Service and TED search API is the following:

- TED search API searches for notices.

- SPARQL searches for public procurement data.

You can also search for notices with SPARQL, but we do not intend to deprecate the current TED search API in the foreseeable future. 

As a new user of the TED Open Data Service, where can I find documentation that explains what data sources are available and how these links are used to construct SPARQL queries?

Answer: As a starting point, you can look at the Query Library available in the TED Open Data Service (http://data.ted.europa.eu), that provides a group of sample queries, where you can see some use cases for prefixes. The prefixes refer to the different semantic vocabularies used in the RDF data.

For EIB: Are you missing indicators that you would like to get from eForms data that would help you with your work? E.g. data on subcontractors?

Answer: Regarding the indicators: DIGIWHIST (digital whistleblower) is a programme funded by the European Commission where the available procurement data in the EU was examined in order to start identifying or highlighting some patterns or aggressive procurement behaviour. By reviewing all available data, mainly TED data, a list of 10 indicators was created. Based on what was available at the time, this was already a comprehensive analysis.

We are currently launching a new project to enhance our indicators and add new ones, also trying to embed AI technologies in our tools. The first version of the tool was created around 10 years ago and since then there is plenty of new information made available.

Regarding data on subcontracting: any additional information on the subcontractors would be useful. Concrete examples would be for instance the date of registration of a company and data regarding the description of the company like number of employees and assets. This is something we could include in our risk analysis.

For EIB: After this public presentation where some methods have been explained (e.g. very short time 5+3 days, or too short/long specification), could it be possible that potential "offenders" will be aware and from now on they will "adjust" the methods to cheat?

Answer: First of all, you can read the full public report from DIGIWHIST where all indicators are properly explained. To answer the question, yes, it could be possible that potential offenders will use the information and adjust any risk indicator. As mentioned in the presentation, if any tool is not reviewed on a regular basis and updated with modern techniques, it will become obsolete and useless. The goal of our project is to review all indicators, make them more useful and to strengthen their analytical force. We aim to make it more agile, identify new patterns and analyse the data in a live manner in order to bring more insights on new trends. If we manage to do so, we will be one step ahead of offenders.

For EIB: Do you plan to open the access to your robot?

Answer: At this stage we are not in a position to share this information (CRIP) with the general public. This is mainly due to its subjectivity (being seen from the point of view of fraud prevention and detection at the EIB) and confidentiality questions.

However, on a case-by-case basis it might be possible. The data is for instance already shared internally with colleagues from the compliance department. It could be possible to extend the group of possible stakeholders who could benefit from our data in future (e.g. other institutions or organisations looking for specific information).

What is already publicly available is the academic research done on procurement data on which the risk indicators are based. You can for instance reach out to us so we can refer you to DIGIWHIST.

Regarding links to get tender related information: are there plans to restrict the practice to hide relevant tender information in documents on separate platforms leaving the notice basically an empty hull?

Answer: In principle, buyers must make procurement documents available with no restrictions. However, in practice this might differ as there are loopholes in the current legislation. “Free” access can also mean that there are still some restrictions to access documents. We are aiming for more clarity about free and open access in the new public procurement legislation.

Could you please share details about the technology and tools used in the Public Procurement Data Space?

Answer: Currently we use mainly open-source components. From a technical point of view, we get the files in different formats (XML, JSON) and then we use our RML mapping to import the data from the eProcurement Ontology into a knowledge graph. We plan to change the architecture of this. For the dashboards we also use an open-source tool which is called “Apache Superset”.

We aim to have such open-source tools so that we can provide the code in a doc container in the future, which would allow interested members states to replicate what we are doing. 

What are the main challenges in integrating data from national portals into Public Procurement Data Space?

Answer: The integration itself works quite well. The ingestion is done on a daily basis: through a runner we collect all the data from different data sources every night and processes them, so when you access the PPDS in the morning all the latest data will be there.

However, we need to adjust the architecture so that we can map not only data we received in eForms format easily to the eProcurement Ontology without data loss, but all data in the source file including data in different formats. 

As there are ambiguous cases in Public Procurement Data Space, are you considering having country specific rules in the rulebook?

Answer: It will be very problematic to have dedicated rules for specific countries. We currently have rules in place that will control the selection of information for a specific field if multiple sets of information are given for that field (e.g. if there are multiple buyers and no lead buyer indicated, we take the first one). We will most likely not have situations where we would interpret the data from a specific country in a different way. We will rather adapt the way we map the data from the country to the eProcurement Ontology.

Public procurement policy

When will the European Commission adopt more comprehensive indicators than those currently used in the Scoreboard (as the existing indicators lack depth and are capturing only surface-level metrics rather than underlying dynamics)?

Answer: This is noted. It is true that currently we are still working with the basic indicators. Hopefully, towards the end of next year we will have more comprehensive indicators, for instance, indicators looking at multiple dimensions.

In the PPDS it is already possible to check data against different areas. For instance, if you have a single bidder, you have the possibility to look for specific sectors.

Is the new public procurement legislation going to be a directive or regulation?

Answer: This is currently not clear. More information will follow when the legislation is proposed.

What do you see as the biggest inefficiencies in today’s procurement and tendering systems that technology has yet to solve?

Answer: Some points raised during the discussion:

- Not respecting the once-only principle. e. g. suppliers often need to provide the same references with every new tender, due to different forms, expiration after a period, etc

- There is too much regulatory complexity and there is too much focus on it. Often the regulatory framework is not in line with what is actually happening on the market. The biggest inefficiencies cannot be solved with technology.

- Given these issues, DG GROW pointed out some aims of the new public procurement legislation:

• The new legislation needs to focus on the core and have strong principles at its basis. Technology can follow.
• The new legislation should be agile. The Directive can stay stable, but the implementing regulations/acts can evolve. Technology can adapt as it goes along. 

Regarding the business wallet, who will be able to access legal-person data and under what conditions? What about national law/public interest exceptions which could make a disclosure of data mandatory?

Answer: One advantage of the proposed business wallet is that it can provide direct access to the buyer. The supplier can choose to give access to specific information to the buyer in the procurement procedure. This leads to a direct connection between buyer and supplier. In previous workshops, we could see that some countries have more advanced systems – buyers can access information - and in some other countries they cannot, and it makes it more complicated for them. The business wallet could allow buyers to get the information as a confirmation, without needing to access the detailed evidence.

What strategies would you recommend for scaling a B2B procurement platform across markets with very different regulations?

Answer: It would indeed be interesting if suppliers had access not only to public procurement procedures, but also to procedures from businesses, both using one client where you can access the information, submit your offer, communicate etc. There were already discussions with PEPPOL and CEN about this.

In your view, what are the most important metrics to measure the health and integrity of a tender marketplace?

Answer: One of the most important metrics to know is the economic operators and contracting authorities. If we are able to identify them, we will be able to know their activities. It could be potentially interesting to know if they have different issues and if they handle different types of procedures. This would lead us to connect those procedures to certain contracting authorities and economic operators. Again, the most important metric is better identification of the market players.

Miscellaneous

What are the limitations for a privately listed company to create a portal exactly like TED?

Answer: We don’t impose any limits: TED data can be reused freely, even for commercial added-value services, and many companies already do this. The limits would be on your side and your capacity to build a service that you can sell. The main difference compared to TED is that your portal wouldn’t be an Official Journal, but the data could be identical if you want.