How to identify the type of result of procedure

[jpmckinney]

Background

A design contest in the EU is very similar to other procurement procedures (it uses the same values for procurementMethod and procurementMethodDetails as other procedures, among other similarities, see https://standard.open-contracting.org/profiles/eu/master/en/F12/).

However, it differs in that the result of the procedure might be a prize or other type of reward, that is not a contract to deliver goods, services or works. The prize can have a value, but this is not in exchange for delivery. There is typically no contract related to the award of a prize.

There is presently no high-level indication that the result of the procedure is different in the case of a design contest.

Issue

As described, the result of a design contest has different implications than in other procurement procedures. This difference can be relevant to analysis.

OCDS for EU adds a tender.designContest object to describe the design contest, but a tool that works with 'core' schema will not know to look there.

Discussion

A design contest is not so dissimilar from other procurements. As such, it might not make sense to add a 'designContest' code to initiationType.csv as a means of resolving the issue.

An analysis to calculate the government's total expenditure would prefer that the values of prizes in design contests be disclosed in the same way as other results/awards. This, and other use cases, suggest that keeping the result of the procedure in awards (rather than adding a new top-level field just for the results of design contests) has advantages and disadvantages, and so it is more a question of which use cases to prioritize and how complex a model to offer.

A design contest has no tender.mainProcurementCategory (among others), so it's possible that these differences in core fields are sufficient to indicate to a careful analysis that the contracting process has different implications.

Related: #895 and #896 and conversation starting at #903 (comment)

cc @ColinMaudry

[jpmckinney]

Tagging as Documentation for now, since this might just result in documenting what assumptions are safe to make with respect to the result of the procedure.

[ColinMaudry]

A design contest has no tender.mainProcurementCategory (among others)

Right, but in case it was an argument in favour of a new designContest class, I think most fields are optional in OCDS because we know all procedures don't need all fields.

We mostly need to work on the outcome part, that is on the award.

Maybe prizes could be modelled like items: present in the tender, and some are awarded, some may not be awarded.

[yolile]

For the case of framework agreements:

Both Paraguay and Chile use the term 'modalidad' in their definition of what a Framework Agreement is
For Colombia the framework agreement is a "tool" and "contract"

Chile definition: http://www.mercadopublico.cl/Home/Contenidos/QueEsCM
Paraguay definition: https://www.contrataciones.gov.py/dncp/ejogua.html
Colombia definition: https://www.colombiacompra.gov.co/tienda-virtual-del-estado-colombiano/acuerdos-marco/acuerdos-marco

[jpmckinney]

Right, but in case it was an argument in favour of a new designContest class

It was an argument against :) because its absence can signal that the procedure might require a different analysis.

Until we have a better understanding of the data use implications, I don't think we can make progress on this issue. It's possible that no new field is needed, and that design contests (and whatever else publishers include, like grants), can be excluded from an analysis based on other fields.

So, I will close this issue, as it has not received much engagement by the broader community.