Bids: Adapt documentation to cover e.g. requests to participate

[timgdavies]

From discussions of whether the bid extension can be used to model submissions of documents as part of a Pre-Qualification phase of a contracting process.

The language of 'bids' does not fit this context, but the general data model does.

Renaming bids to responses and switching to a language of 'invitation' and 'response' (rather than 'tender' and 'bids') would potentially allow much greater generalisation in the use of the standard.

[jpmckinney]

As a core extension, we can't rename until 2.0, but we can address this through documentation.

[duncandewhurst]

In the context of modelling multi-stage contracting processes as discussed in https://github.com/open-contracting/standard/issues/440 and the ocds_second_stage_extension, I think this would also require a way to link each Bid to either the first stage, or to a specific invitation at the second stage.

[jpmckinney]

@duncandewhurst Since in OCDS 1.x, each second stage has its own OCID, isn't it clear which stage the bid relates to?

[duncandewhurst]

I took https://github.com/open-contracting/standard/issues/440#issuecomment-630987113 to mean that from OCDS 1.2 the approach in the second stage extension would be replacing the current approach but now I see that the milestone for that issue is 1.3.0 or 2.0.0, so you can disregard my previous comment.

[odscjen]

Checking what documentation will need updated to cover this scenario. I'm thinking:

1. adding some guidance to the Bid extension itself
2. adding to the Dealing with the hard cases/pre-qualification section in the core documentation? (which I notice doesn't currently say anything about how to link the subsequent stage to the pre-qualification stage)
3. possibly Dealing with the hard cases/Frameworks as well, assuming that we're suggestion using bids to record submissions to the first stage of a Framework agreement in a similar way here too?

[jpmckinney]

Let's just edit the bid extension for now, as we don't presently mention it on those two other pages (the framework is already long and complicated).

[jpmckinney]

@Camilamila @yolile In this issue, it's proposed to allow describing expressions of interest (i.e. pre-qualification responses) via the bids array.

To my knowledge, in the vast majority of cases, a publisher only publishes either the expressions of interest or the bids – but not both. In other words, when there's pre-qualification or pre-selection, the final bids aren't published. From this limited perspective, reusing bids seems advantageous, as the user can just look in one place for the (first) submissions.

In terms of analysis, I'm not sure whether expressions of interest contain the same key fields as bids. Notably, I'm not sure how often expressions of interest have values – which is one of the most interesting fields for red flags and other indicators. (I think they sometimes do, because I think awards can exceptionally be made on the expressions of interest.)

If a publisher were to publish both expressions of interest and bids, the user would need to disambiguate them. They can do this using dates (e.g. comparing to the new tender.expressionOfInterestDeadline), but we'd probably want another way. We could add a field for this to each bid.

All this said, I'm not sure if the two types of submissions should be mixed or not. In terms of analysis, my sense is that there are cases where expressions of interest can't substitute for bids, in which case they should be kept separate. (On the other hand, there are those cases where (I think) awards are made based solely on the expressions of interest.)

Let me know your thoughts. It might still be the case that merging them together is the best compromise.

[Camilamila]

Hi James, I think that if awards are made on expressions of interest then using the bids seems ok, since there wouldn't be an extra stage where they have to submit bids. If that is not the case (e.g if we have expression of interests and actual bids) and if they are all published in the same bids array then I think the clearer option to differentiate is to have a field there to help disambiguate. But that said, do we have a real life example on those two cases?

[jpmckinney]

No, we will have to do some research. @odscjen Can you do a bit of exploration to see whether the two cases (publishing both EOIs and bids; making an award decision based only on EOIs) occur? Obviously, if they never or very rarely occur, they will be hard to find, so don't try for too long. Re: making awards based on EOIs, one angle might be to see if any EOIs express the price or cost.

Re: making an award on the basis of an EOI, I might be confusing that with "The contracting authority reserves the right to award the contract on the basis of the initial tenders [i.e. bids] without conducting negotiations" from the OCDS EU profile. Or, I might have read of such a thing in some US municipality (I can't remember); anyway, we'll need to find it (if it exists), to be clear on how the procedure actually works, to inform the modeling.

In any case, @Camilamila it sounds like you're fine with just adding a field to the Bid object to indicate whether it is an EOI or bid? (Note to @odscjen: We can't rename the field bids, but we can rename the definitions Bid and Bids to Response and Responses). Happy to get your thoughts as well, @yolile.

[odscjen]

sure, I'll do some research on this

[odscjen]

I did some fairly cursory research:

1. looked at OCDS publishers who use the Bid extension to see if they publish the responses to EoIs or if they just use it for actual tender bids. It looked like there are none currently using it for EoIs, and I couldn't see evidence of that EoI detail being published in any other fields
2. looked for some non-OCDS publications and couldn't find any that publish the details of responses to EoIs. Switzerland publish the names and contact details of the parties that have been invited to bid following a successful EoI, but no details of what the EoI response involved, and no details on unsuccessful respondents.

Re. an award being made off the back of an EoI, the closest things I found were:

• In the EU, in the specific case of a public transport franchise, regulation 1370/2007 Article 5 paragraph 3b allows a procurer to enter into negotiations with a supplier following an EoI without going into a full open tender process if there's only been 1 EoI received
• In the UK, I found but only for a couple of awards relating to the English Health Service a Procedure type "Direct Award (below threshold) following Expression of Interest" on Contracts Finder, but I couldn't find any details of the legal process that resulted in this outcome. And I suspect it's been replaced by...
• Again in the UK, a new law, the Health Care Services (Provider Selection Regime) Regulations 2023 which came into force in January 2024 includes the Most suitable provider route to procurement where the buyer publishes a notice of intention which may include details on how interested parties can express their interest, but then the buyer can make the award without going to open competition. They will then have to publish an Intention to award notice which doesn't contain any details of the expressions of interest, just the final award.

[jpmckinney]

Have you found any EOIs that express a price or cost?

I think the cases you found "Re. an award being made off the back of an EoI" are representative (i.e. one qualified EOI leading to negotiation, direct award, etc.).

From my understanding, EOIs can be used in the place of bids for several red flags and indicators, e.g. single submission (whether bid or EOI), only one qualified submission, buyer with a high rate of disqualifications, etc.

While OCP continues to push for publication of bid information, it is presently infrequently published, and so the combination of both EOIs and bids being published seems unlikely.

As such, on balance, it seems to me that it is more useful to users to include both bids and EOIs in the same JSON array, since in most cases only one of the two will be present, and since the indicators are equally relevant in either context. If a publisher does in future include both, we can use a field to disambiguate.

There are perhaps some differences in interpretation of some indicators – but, for example, with respect to disqualification, the interpretation is the same. I'm not sure if any difference is large enough to warrant separate arrays.

Yohanna is on vacation, but once she has a look next week and once Camila replies to my question above, we'll be able to proceed.

[odscjen]

Have you found any EOIs that express a price or cost?

Very few, although as a non-Spanish speaker it's possible some of the Latin American countries do and I just wasn't able to find them when relying on online translations. Hopefully Yohanna can provide some more insight into this once she's back from leave.

The ones I could find are:

• The EU when using a "PIN as a call for competition" the notice invites potential suppliers to submit an EoI and the notice includes a value, e.g. https://ted.europa.eu/en/notice/-/detail/80898-2024, this notice acts as the first part in a selective procedure
• Canada, some EoI notices included a value, e.g. https://bcbid.gov.bc.ca/page.aspx/en/bpm/process_manage_extranet/187084 mentions a maximum budget value that respondents can say they'd need, but most of the ones I looked at didn't
• India, most of the EoI notices didn't include a value, and said "NA" in the tender value field, but a few did seem to, e.g. https://eprocure.gov.in/eprocure/app?component=%24DirectLink&page=FrontEndTendersByClassification&service=direct&session=T&sp=SbIeIXKzZxlSf4wf%2BtuMmtA%3D%3D

[Camilamila]

Regarding your question @jpmckinney, yes I agree that we could just add a field to the Bid object to indicate whether it is an EOI or bid in the case a publisher has both.

[odscjen]

We're in agreement then that we should add a discriminator field and allow the Bid object to be used for both bids and EOIs.

There's a couple of ways we could model this:

1. As a boolean field, e.g. isExpressionOfInterest where false would imply it was a bid, which we would expect to be the default.
2. As a codelist with a closed list of 2 values 'bid' and 'expressionOfInterest'. The naming is tricky but could be something like submissionType?

I'm inclined more towards option 2 as it's clearer at a glance what the data is telling you. Within the code descriptions we can also then cover the other names an EOI goes by e.g.

Code	Title	Description
bid	Bid	A submission made in response to an invitation to tender. Depending on the procedure, a bid can be an estimate, offer, proposal, quote or quotation.
expressionOfInterest	Expression of interest	A submission made in response to an invitation to pre-qualify for a tender. This submission is also call a request to participate.

The language in the descriptions above directly matches part of the updated description of tenderPeriod and expressionOfInterestDeadline respectively.

@jpmckinney does this seem reasonable?

[jpmckinney]

Yes, I also prefer 2 as it's explicit rather than implicit. (If a publication never uses EOIs, they can perhaps omit the field and describe the implicit default in their publication policy – as is the case for many fields.)

We try to avoid "tender" per https://github.com/open-contracting/standard/issues/1639

Reverse the code order, as expressions of interest precede bids (in procedures that use both).

A submission made by a potential supplier describing its qualifications, for the purpose of being invited to submit a bid. This submission is also called a request to participate.

A submission made by a potential supplier describing its offer, for the purpose of being awarded a contract. Depending on the procedure, a bid can be an estimate, offer, proposal, quote or quotation.

[odscjen]

Great, I'll update the PR with this

[odscjen]

The PR is ready for your review @jpmckinney