Clarify award description

[jpmckinney]

Background

awards in OCDS:

Information from the award phase of the contracting process. There can be more than one award per contracting process e.g. because the contract is split among different providers, or because it is a standing offer.

Award in OCDS:

An award for the given procurement. There can be more than one award per contracting process e.g. because the contract is split among different providers, or because it is a standing offer.

UNCITRAL glossary defines "Award of a procurement contract or framework agreement":

A final stage of the procurement proceedings regulated by the Model Law, resulting in the conclusion and entry into force of a procurement contract or framework agreement between the procuring entity and selected supplier(s) or contractor(s).

and "Public notice of the award":

Announcement to the public in general through publication in the media specified in the legislation of the enacting State to whom the procurement contract or the framework agreement was awarded and the price of the procurement contract.

The eProcurement Ontology has a class for Award Decision:

Resolution of the buyer as to the result of the procurement procedure.

and for Contract Award Notice:

An announcement of the award or non-award of a contract by a procuring entity.

This was also an "additional note" in #790

Discussion

The schema and documentation are not clear what, precisely, is intended by 'award'. This therefore leaves its precise semantics up to interpretation by publishers, which leads to different publishers choosing different semantics, which reduces the value of the standard in terms of interoperability and comparability.

In OCDS, the Award object is intended to communicate a direct relationship between items, suppliers, and values. It should be possible to know, at the award stage, in OCDS data, which items will later be supplied by which suppliers, and what the value of those contracts will be. If all suppliers and all items are put into one object, then there are no direct relationships, and it is not possible to know the breakdown intended to be communicated by the Award object. This is reflected within the description of suppliers:

If different suppliers have been awarded different items or values, these should be split into separate award blocks.

For the sake of clarity, the Award object is not intended to match the 'award notice', because some jurisdictions announce all the relationships above at once. It is also not intended to match the 'award decision', because some jurisdictions create all the relationships in one decision. Another reason for confusion is that some jurisdictions have no term matching the Award object.

(See related discussion in #249)

Proposal

A new definition can better describe the intention in the discussion, and align (where possible) with the definitions of the UNCITRAL glossary or eProcurement Ontology.

[jpmckinney]

I updated the discussion to focus on semantics instead of terms, because focusing on the 'award decision' term was not compelling in cases where all awards are decided at once.

[jpmckinney]

Related: #903

[jpmckinney]

The discussion above is from the perspective of procurement procedures. Per #903, contracting processes can have a variety of results (e.g. in the case of design contests, or in the case of being added to a supplier list that can be reused in other procedures). In that case, there isn't a direct relationship between items, suppliers, and value.

[JachymHercher]

General

• I do not think the award definition in the UNCITRAL model law / glossary is usable for the OCDS award. I read the "stage [...] resulting in [...] a contract" as implying that the contract is established within the "award stage", while in OCDS the contract is established within the "contract creation phase". The UNCITRAL award stage probably corresponds to the OCDS award and contract stages.
• I take it that the main use case for distinguishing Award and Contract is distinguishing an unilateral, internal decision by the authority from an agreement between two parties. I think this makes sense (eForms concentrated predominantly on the contract for simplicity's sake).
• My takeaway from the quote below is that while Award cannot be mapped to any one of the concepts mentioned, its point is to cover all the use cases described there ("award notice", "award decision", "single universal award decision", "no award decision").

the Award object is not intended to match the 'award notice', because some jurisdictions announce all the relationships above at once. It is also not intended to match the 'award decision', because some jurisdictions create all the relationships in one decision. Another reason for confusion is that some jurisdictions have no term matching the Award object.

Proposal

Definition for Award:

"Decision by the buyer or procuring entity on which supplier should supply what item and at what value. Typically, this decision leads to a contract, but not always (e.g. the award is appealed at court or the supplier refuses to sign the contract). Depending on the jurisdiction, a single decision may concern a single supplier, item and value; or batches of suppliers and/or items and/or values. Similarly, sometimes the award is published as soon as it is made and sometimes only together with a contract (including only being implicitly covered by the contract). As far as possible, the award should be published at the most granular level (i.e. a given supplier will deliver a given item at a given value) and as soon as it is made."

Note: this definition possibly mixes normative and non-normative statements too much. If so, e.g. the last sentence could go into a non-normative section. On the other hand, having information in one place is not that bad... :)

Note2: I'm not sure whether the definition takes sufficiently into account framework agreements, design contests and the like. Suppliers in the OCDS presumably cover also members of a framework agreement, Item applies to framework agreements and design contests (e.g. because it contains CPV) and value presumably covers estimated/maximum/"real" value, so in principle it does too, but this might need to be made more explicit. Perhaps it would be clearer if the first sentence was:

"Decision by the buyer or procuring entity on the supplier with whom it wishes to conclude a contract, including the items the supplier should supply and their price.

Note3: We could replace "Decision on" with "Choice of".

Definition for "awards" :

"Information from the award phase of the contracting process."

[jpmckinney]

To allow for a variety of decisions (procurement, framework agreement setup, design contest, concession, etc.) we might want a more generic first sentence, and then: "In the case of a procurement procedure, [most of the proposed content]." followed by "An award can also represent the decision to: establish a framework agreement with the selected suppliers; award a prize to a participant in a design contest; ..." (feel free to re-word).

I am happy with "long" definitions. In the initial design of OCDS there was an ambitious goal that field titles/descriptions could be used in applications that adopt OCDS, but this has never occurred to my knowledge, and if we wanted to support that, we could instead have an "application-friendly" version of the schema. The focus of the schema should be to maximize semantic clarity.

As for award value, we might need separate fields for maximum value and real value depending on the outcome of #896 (comment)

[JachymHercher]

Strictly speaking, I think the definition covers these options (see Note2 above). But if we want to make it more generic, does "Decision by the buyer or procuring entity on the supplier with whom it wishes to conclude a contract, including the items the supplier should supply and their price." work? Since we are defining contracts in #896 as covering framework agreements, prizes from design contests, etc. I think that would fulfill all the scenarios you mention. We also wouldn't need to add "In the case of a procurement procedure" etc. - the broad definition of contract covers it.

For clarity, we could specify "...a contract (incl. a framework agreement or the prize resulting from a design contest).", but I think it may be better not to repeat definitions like that.

[jpmckinney]

Good point - we can defer a lot to the definition of contract in #896. So, I abandon my preceding comment. Between:

Decision by the buyer or procuring entity on the supplier with whom it wishes to conclude a contract, including the items the supplier should supply and their price.

And:

Decision by the buyer or procuring entity on which supplier should supply what item and at what value.

I prefer the first, since it allows that deferral to the definition of contract.

[JachymHercher]

New question: how are unsuccessful procedures (e.g. where all tenderers were excluded because of exclusion grounds or selection criteria) modelled in OCDS? Specifically, is Award used? I assume this is done through status being equal to 'unsuccessful', but I'm not sure whether Tender.status is enough or Award.status is also used. Depending on the approach, this will also need to be reflected in the definition of Award.

Related to the above (candidates for new issues?):

• The definition of 'unsuccessful' in https://standard.open-contracting.org/latest/en/schema/codelists/#award-status addresses the above question indirectly, implying that if an award is not made then Award still contains some information about this. Some of this could perhaps be said more directly and some of the text might belong more in the guidance.
• I expected https://standard.open-contracting.org/1.1/en/guidance/map/unsuccessful_tender/ to answer the question "how does OCDS model unsuccessful procedures", but the guidance is rather about the definition of a contracting process.

Definitions in other contracting standards

The ePO defines an award as "Resolution of the buyer as to the result of the procurement procedure."

UNCITRAL glossary defines an award as: "A final stage of the procurement proceedings regulated by the Model Law, resulting in the conclusion and entry into force of a procurement contract or framework agreement between the procuring entity and selected supplier(s) or contractor(s)."

I find both both definitions consistent with our approach above, with the caveat of how to deal with unsuccessful procedures (ePO's award covers decisions on not awarding a contract which corresponds with older TED forms and eForms; UNCITRAL does not.).

[jpmckinney]

I agree that the description of the awardStatus 'unsuccessful' code needs revision. I opened #1160.

how are unsuccessful procedures (e.g. where all tenderers were excluded because of exclusion grounds or selection criteria) modelled in OCDS?

https://standard.open-contracting.org/latest/en/guidance/map/unsuccessful_tender/ gets around to explaining how to model unsuccessful tenders. Basically: set tender.status to 'unsuccessful', then link to the unsuccessful OCID from a new OCID via relatedProcesses. I've opened #1159 to move/remove the first half.

The OCDS for EU profile uses awards in F03. Since there might be many CANs for the same procedure (e.g. one per lot), and it's unknown whether a later CAN will be successful, this approach makes sense. But, it means all awards could be unsuccessful.

[JachymHercher]

https://standard.open-contracting.org/latest/en/guidance/map/unsuccessful_tender/ gets around to explaining how to model unsuccessful tenders. Basically: set tender.status to 'unsuccessful', then link to the unsuccessful OCID from a new OCID via relatedProcesses.

When would award.status (equal to 'unsuccessful' and perhaps also 'cancelled') be used? It might have impact on the awards definition. (Very much related to #1160 (comment).)

[jpmckinney]

As discussed in #1149, we would change "wishes" to "intends".

[jpmckinney]

When would award.status (equal to 'unsuccessful' and perhaps also 'cancelled') be used? It might have impact on the awards definition. (Very much related to #1160 (comment).)

I think we can continue that discussion in #1160.

[JachymHercher]

I have updated the PR, it is ready for review. Changes:

1. Renamed this issue from "awards" to "award", as the discussion here concentrates since the beginning on award. Rewording Awards is discussed in Update all status codelists #1160 (comment).
2. Removed "(including only being implicitly covered by the contract)" and wrong use of normative language, as proposed in points 1,2 and 4 from https://github.com/open-contracting/standard/pull/1175/files#r619667010).
3. Based on the discussion of point 3) from https://github.com/open-contracting/standard/pull/1175/files#r619667010, removed "As far as possible, the award should be published at the most granular level (i.e. a given supplier will deliver a given item at a given value) and as soon as it is made."
4. Based on the same point, I am not sure whether not to also remove "Depending on the jurisdiction, a single decision concerns a single supplier, item and value; or batches of suppliers and/or items and/or values." The pros: it is true and may appease users who are unsure whether the specificities of their awards aren't a problem. The cons: it might be confusing. I am inclined to leave it, it is included in the PR.
5. Based on the same point (and the discussion in Merge Lots extension #891 (comment)), added the following note to docs/guidance/map/awards_contracts_buyers_suppliers.md

In OCDS 1.2 and earlier, a single contract cannot be linked to more than one award. Consequently, in cases where real-world awards are more detailed than the resulting real-world contract (e.g. two lots are awarded to a single supplier and only a single contract is signed), this cannot be represented fully accurately in OCDS. There are two possible workarounds: 1) summarizing the real-world awards into one OCDS award (e.g. summing up the values of individual lots, choosing the most common award date), 2) splitting the single real-world contract into multiple OCDS contracts. If you want to disclose this type of information, we recommend using approach 1) or contacting the helpdesk. The approach to modelling many-to-one awards to contracts in a future, backwards incompatible version of the standard is under discussion on Github.

[jpmckinney]

(1) (2) (3) OK. (5) Note looks good.

(4) I am also inclined to leave it, because it is true, and because both can be (and are) modelled in OCDS.