Clarify definition of contracting process

[jpmckinney]

Problem

A contracting process is described in terms of an 'initiation process' on http://standard.open-contracting.org/latest/en/getting_started/contracting_process/#defining-a-contracting-process:

All the planning, tendering information, awards, contracts and contract implementation information related to a single initiation process.

An initiation process might be a tender, a direct contract award, or a call to award a concession.

However, we never define what an 'initiation process' is, which makes the definition ambiguous.

The only example given for multiple initiations is:

for example, when a framework is setup, and then mini-competitions are used for purchases from the framework

This was introduced in #439 (related to #310) on April 24, 2017, after the peer review for 1.1, and the changes regarding the description of 'initiation process' were not mentioned in the update to peer reviewers. As such, we should treat the mini-competitions example as non-normative guidance.

The 'tender' code in the initiationType codelist would also need correction of its description. #821

Background

In the BPMN for a restricted procedure shared by EBRD, the process could be said to be 'initiated' by the publication of a contract notice (tender notice), after which there is 'supplier qualification' (pre-qualification), 'tendering' (submitting bids, etc.), and so on. (The BPMN for an open procedure is similar, but without a supplier qualification stage.)

In the EU, the same notice is used whether there is a supplier qualification stage or not (which is why the phrase "tenders or requests to participate" is used).

In the EU, the contract establishing a framework agreement and each contract resulting from a framework agreement are considered to be the same procedure. eForms/eForms#221 (comment)

Discussion

For a restricted procedure, I think it's correct to say there is only one initiation process (publication of a contract notice), not two (pre-qualification and tendering). This agrees with this comment from the peer review, and disagrees with this later interpretation in the qualification extension.

For a framework agreement, the same comment from the peer review indicates that all contracts resulting from a framework agreement are part of the same procedure/process that established the framework agreement. Further discussion can be pursued in #440

Proposal

• Improve the definition of a contracting process, to be clearer about initiation processes (or substitute that term with an equivalent)
• Remove the warnings from the qualification extension

[jpmckinney]

With respect to framework agreements, the UNCITRAL glossary clarifies:

Framework agreement procedure with second-stage competition:

Procedure under an open framework agreement or a closed framework agreement with more than one supplier or contractor in which certain terms and conditions of the procurement that cannot be established with sufficient precision when the framework agreement is concluded are to be established or refined through a second-stage competition.

Framework agreement procedure without second-stage competition:

Procedure under a closed framework agreement in which all terms and conditions of the procurement are established when the framework agreement is concluded.

Second-stage competition:

A stage in closed framework agreements with more than one supplier or contractor and in open framework agreements through which certain terms and conditions of the procurement that cannot be established with sufficient precision when the framework agreement is concluded are established or refined through a competition between or among suppliers or contractors parties to the framework agreement.

With respect to this issue, such 'second-stage competitions' are considered new contracting processes as they initiate a new competition that can be open to new bidders (in the case of an open framework agreement), which is consistent with our existing guidance. (see below)

[jpmckinney]

After further consideration in #440 (comment), second-stage competitions only make sense (and only respect the semantics of OCDS) in the context of their first stage, so I've crossed out my analysis in the previous comment ('contracting process' can't be defined as 'any new competition').

[jpmckinney]

Rough outline: In the case of procurement, a contracting process can be defined as a procurement procedure. There is a one-to-one correspondence between the first stage of a procurement procedure and a contracting process. (Note: Need to be explain why the planning stage is not considered the first stage, see next comment.) If a procedure is cancelled or unsuccessful, and a new procedure is started to re-try the procurement, those are two different contracting processes. The second stage of a procedure is part of the same contracting process as its first stage.

In the case of public-private partnerships, there is a one-to-one correspondence between the public-private partnership and a contracting process. This can be more clearly stated in the OCDS for PPPs documentation: open-contracting-extensions/public-private-partnerships#216

In the case of concessions, we can follow the rough outline of procurement procedure. (The EU uses very similar forms both types of contracting processes.) I might want to revisit my very early work on extractives in case there are relevant ideas.

In the case of infrastructure, we can explain the distinction between project-level and contract-level data, taking content from OC4IDS. Otherwise, it's the same as procurement procedure.

Types of contracts not yet developed:

• Sale/lease of government assets

We can look up legal definitions of 'procurement procedure' to add more clarity and to avoid deferring to each implementer's legal definition of that term.

[jpmckinney]

Building on this internal discussion https://crm.open-contracting.org/issues/4864#note-10

In OCDS, at a conceptual level, a contracting process is intended to match each concrete attempt to start a procedure that leads to one or more contracts. Attempts can include: an invitation to tender (in open procedure); an invitation to request to participate; a competition for a concession…

At a use-case level, the definition of ‘contracting process’ is also intended to correctly represent the competitive conditions and to make it easy for potential suppliers (and other users) to identify opportunities.

Multi-stage procedures

A concrete example: The e-GP systems in some jurisdictions, like New South Wales #371 (comment), model pre-qualification (making a list of qualified suppliers) as one phase, and tendering (using the list of qualified suppliers) as another phase. In their system, these are treated as separate processes, with a link between them. In OCDS, these are treated as one contracting process with two stages. If they were treated as two contracting processes, then for the second process, the data would suggest that the procuring entity directly invited the suppliers without open advertisement (known as ‘limited tendering’ in the GPA), which is not the desired semantics; in reality, the procuring entity had an open advertisement in a first phase, and held a competition between qualified suppliers in a second phase (known as ‘selective tendering’ in the GPA).

By representing this as one contracting process in OCDS, the model and process for selective tendering is clearly distinguished from limited tendering, which is relevant to potential suppliers and to analysts evaluating the competitiveness of a procurement market, among other use cases.

With respect to the intention above, the 'start' of the procedure in this example is the pre-qualification phase. The tendering phase is not the start, because it must follow after the pre-qualification phase (and is always linked to it).

Planning information

A government might prepare a procurement plan, a preliminary market consultation, a notice of planned procurement (GPA), a prior information notice (EU), etc., each of which are plans. At this stage, there is flexibility to decide the procurement procedures at a later date. A plan is not an opportunity that suppliers can participate in, and a plan might not even lead to an attempt to award a contract, e.g. if budget conditions change and the plan needs to be remade.

In OCDS, it is relevant and desirable to include the planning information that relates to the process, but the contracting process is not interpreted as ‘starting’ with the planning stage. In OCDS, the planning stage is something that comes before the start of a contracting process.

This is consistent with the guidance on http://standard.open-contracting.org/latest/en/getting_started/contracting_process/#defining-a-contracting-process:

All the planning, tendering information, awards, contracts and contract implementation information related to a single initiation process. … An initiation process might be a tender, a direct contract award, or a call to award a concession.

Furthermore, the graphic at the top of the page indicates "Initiation (Tender)", i.e. the tender block (used for requests to tender, etc.) is the start/initiation of the contracting process.

Because one plan can lead to multiple contracting processes (as defined in OCDS), there is also a 'planning' code in relatedProcesses.csv, described as:

This contracting process follows on from the related planning process.

With respect to the intention above, the 'start' of the procedure is not the planning stage, because at least one of the following is true of a planning stage: it is not a concrete attempt to award one or more contracts like a request for tender, etc.; it is not a concrete opportunity for potential suppliers to participate in (a plan is not a call for competition, etc.); it does not describe the competitive conditions (the type of procedure might not be indicated or chosen in the plan).

Unsuccessful processes

If a process fails to award a contract, it is often restarted.

In many jurisdictions, the new process has differences from the unsuccessful process, in order to increase the likelihood of a successful award; for example, in the EU, a procuring entity might switch to a negotiated procedure if an open procedure failed.

With respect to the intention of correctly representing the competitive conditions, since the competitive conditions can change between the old and new procedures (like in the EU), the two are distinct contracting processes in OCDS.

With respect to the intention of making it easy for potential suppliers (and other users) to identify opportunities, since the new process is often a new opportunity (e.g. it might be open to suppliers who didn't submit to the old process), each new opportunity is a new contracting process.

For these reasons, there is an 'unsuccessfulProcess' code in relatedProcesses.csv, described as:

This contracting process follows on from an previous unsuccessful process.

[jpmckinney]

Useful definition of 'procurement' here: #358 (comment)

[jpmckinney]

After internal discussions, it'd be useful to distinguish between the concepts of a 'contracting process' and a 'unit of analysis'. In short, in OCDS, the unit of analysis represented by the OCDS record is the invitation to tender (in open procedure); an invitation to request to participate; a competition for a concession. A 'contracting process' extends beyond that and includes the planning stage (whose information is also provided within the OCDS record).

Examples of different units of analysis are:

1. If an accountant working for the state auditor is investigating a fraudulent transaction, their unit of analysis might be the transaction; they want to go over every suspicious transaction, to analyze whether it is fraudulent.
2. The unit of analysis for a vendor performance tracking system, on the other hand, might be the contract. The tracking system might include metadata about the process that led to the contract, but that is not its primary concern.
3. If an analyst at a competition bureau is measuring indicators for fair competition, with a focus on the fairness of the award stage, their unit of analysis might be the award (including bids).
4. For the Infrastructure Transparency Initiative, one unit of analysis is the infrastructure project, which is higher-level than the contracting processes that are part of an infrastructure project.
5. If a researcher is comparing the procurement markets of different provinces within a country, their unit of analysis might be entire markets, rather than individual contracting processes.

And so on. It would be possible to author many standards, each of which uses one of the above as its unit of analysis. In OCDS, in a procurement context, the unit of analysis is the invitation to tender/request to participate, both for the reasons discussed above, and also because most transparency obligations in national laws, trade agreements, and international instruments (GPA, UNCITRAL, etc.) focus on this as the unit of analysis.

Different use cases are easier to satisfy with different units of analysis (as in the examples above). Standardizing on only one unit of analysis just means that information will need to be re-organized differently to better satisfy the use cases.

Even when the unit of analysis is low-level (like transactions), it's always possible to include information about the 'higher' levels of contracts, awards, tenders, planning, etc. In other words, the choice of unit of analysis doesn't limit what information gets disclosed.

[JachymHercher]

I second the conclusions in #866 (comment) on multi-stage, planning and unsuccessful. I am not sure whether I understand the implications of the unit of analysis discussion from #866 (comment). Is it right to summarize it as "contracting process = OCDS unit of analysis + planning"?

In OCDS, in a procurement context, the unit of analysis is the invitation to tender/request to participate, both for the reasons discussed above, and also because most transparency obligations in national laws, trade agreements, and international instruments (GPA, UNCITRAL, etc.) focus on this as the unit of analysis.

This surprised me - I always took the contract as the unit of analysis, mainly because I consider it the most important artifact of the contracting process (i.e. the one that fulfills the most use cases). Doesn't concentrating on the tenders/requests go against the approach to multi-stage procedures (regardless of whether they are framework agreements or procedures where bidders are requested to submit updated bids in several rounds)?

Concerning the rough draft in #866 (comment):

• Does OCDS define (a general) "procedure"? EU law does not (discussed in GLOSSARY - Procurement Procedure OP-TED/ePO#113 (comment)).
• Does a 'direct' procedure (or rather procurementMethod) have a first stage? In reality I'd say yes (the procuring entity contacts a single supplier), and I don't think we define a first stage in the OCDS anywhere (?), so it should be fine, but just to be sure.

Concerning the definition of the contracting process, I'd propose something along the lines of:

"All the actions aimed at concluding one or more contracts. This covers planning, tendering, awarding, contracting and implementation, including (pre)qualification, multiple stages of a framework agreement, etc. Procedures that failed and were restarted are considered as new processes.

Boundaries between processes (e.g. whether two contracts result from a single process or from two processes) are set by buyers depending on their needs (e.g. efficient division of labor, clear communication with the market) and legislation (e.g. rules on using procedures and lots)."

(To define the "OCDS unit of analysis", we could use the same text as above, just removing "planning" in the second sentence and adding "It does not include actions linked to planning, as these are often less structured and may be linked to multiple contracting processes.")

[jpmckinney]

This surprised me - I always took the contract as the unit of analysis, mainly because I consider it the most important artifact of the contracting process (i.e. the one that fulfills the most use cases).

Regarding the unit of analysis, I introduced the concept to help reason about what an OCDS record is representing – what separates one record from another. Since a record can have many contracts, the contract can't be the unit of analysis. That said, OCDS is designed to support all sorts of units of analysis; if you're only interested in contracts, you can re-shape the data to be a list of contracts, each copying whatever data is relevant to your analysis from other sections of the record. On the other hand, if you're interested in procurement plans (one level broader than the record), OCDS data is not easy to re-shape; you'll have to deduplicate planning sections, identify updates to planning data from different processes, determine whether planning data is incomplete and/or disclosed in different parts across different processes, etc.

Another reason for introducing the concept is to circumvent conceptual differences across jurisdictions. In CRM-4864, Paraguay's DNCP considers a contracting process to start with the planning process. By using a generic term like "unit of analysis" we can avoid disagreement and give the record an unambiguous, non-context-dependent definition.

Doesn't concentrating on the tenders/requests go against the approach to multi-stage procedures (regardless of whether they are framework agreements or procedures where bidders are requested to submit updated bids in several rounds)?

Hard to say! For OCDS 1.1, due to a deficiency in the standard, we use a work-around: representing an FA with second-stage competitions as multiple records instead of only one. Issues like #440 #906 #909 are postponed to OCDS 1.3 or 2.0, since we expect they will require backwards-incompatible changes. So, right now, our desired semantics are a little inconsistent with our guidance. – I don't know if that's what you meant, though :)

Does OCDS define (a general) "procedure"? EU law does not (discussed in OP-TED/ePO#113).

No (not yet).

Does a 'direct' procedure (or rather procurementMethod) have a first stage? In reality I'd say yes (the procuring entity contacts a single supplier), and I don't think we define a first stage in the OCDS anywhere (?), so it should be fine, but just to be sure.

No, though we should define a first stage, perhaps in the broader #827. Note that the tender block in OCDS presently covers concepts relevant to both the "procedure" and the "first stage".

I wasn't sure if sole sourcing had a first stage, but since there still needs to be at least that initial communication from buyer to supplier as you note, I think that qualifies as a first stage.

[JachymHercher]

Hmmm, I'm not sure I'm convinced about the "unit of analysis" thing, or at least not fully.

1. I think "unit of analysis" is not the right term for OCDS, because OCDS doesn't "do" analysis. Unit of analysis as a term is very much rooted in social science and it is linked with data use (e.g. "A unit of analysis is the entity that you wish to say something about at the end of your study" (unit of observation has the same problems). If we want to think this way, I'd say it's the OCDS's "unit" or "unit of collection".

2. I'm not sure this fits with the aim to standardize.

using a generic term like "unit of analysis" we can avoid disagreement and give the record an unambiguous, non-context-dependent definition.

"Unit" implies not only "no context", but also, I think, "no meaning" (= no description). If you start describing it, then it can have a proper name; if not then not - but then it's not really useful. I understand that "contracting process" may have different, and very established, meanings in different parts of the world, but I think the added value (and difficulty) of standardisation is exactly to overcome that.

In other words, I think we need to say that OCDS is about a real-world X and then explain how X is covered. This may be "OCDS is about contracting processes and these cover planning, tendering, award, ..."; or it may be "OCDS is about contracting processes and these cover tendering, award,... Additionally, you can use OCDS to publish information about the planning that took place before your contracting process started." This could be easier to sell if X was slightly less semantically charged, e.g. talking about "contracting journeys" instead of "contracting processes". However, it needs to be linked with something with a clear real-world meaning.

Hard to say! For OCDS 1.1, due to a deficiency in the standard, we use a work-around: representing an FA with second-stage competitions as multiple records instead of only one. Issues like #440 #906 #909 are postponed to OCDS 1.3 or 2.0, since we expect they will require backwards-incompatible changes. So, right now, our desired semantics are a little inconsistent with our guidance. – I don't know if that's what you meant, though :)

This goes back to the contract vs. tender/request discussion and the importance of uniqueness. What I meant was that because 1.1 is deficient, it has second-stage competitions as multiple records, and that's why we can say tender/request is unique, thus it is the main "unit". Does that mean that when 2.0 comes around and we'll have multiple stage in one process, and thus multiple tenders in one process, will tender/request stop being the unit? Or is uniqueness not the right attribute and instead the central concept for a contracting process should be derived from something else, e.g. value for users?

[jpmckinney]

Good points. The definition we need is for an "OCDS record" – to set a boundary around what it contains, and to describe the "thing" to which OCIDs are assigned. So, we can focus on that term instead, without using the term "unit" in its definition.

The OCDS record might coincide with a local definition of "contracting process", or it might not. I think your proposed italicized definitions (substituting "OCDS record" for "OCDS unit of analysis") strike a good balance of abstraction and specific real-world connections (which is what standardization is all about: if it were pure specifics, we've have the territory not the map). Publishers and users can then interpret "OCDS record" as matching whatever concept or term they use locally with that same meaning.

This goes back to the contract vs. tender/request discussion and the importance of uniqueness. What I meant was that because 1.1 is deficient, it has second-stage competitions as multiple records, and that's why we can say tender/request is unique, thus it is the main "unit". Does that mean that when 2.0 comes around and we'll have multiple stage in one process, and thus multiple tenders in one process, will tender/request stop being the unit?

Aha, I think we lost a bit of the nuance from the original comment. The comment you seconded #866 (comment) included:

a contracting process is intended to match each concrete attempt to start a procedure that leads to one or more contracts. Attempts can include: an invitation to tender (in open procedure); an invitation to request to participate; a competition for a concession…

So, the tenders and requests I intended to capture were only at the first stage. As such, this would be 2.0-ready. (The present thinking as modelled in this extension is that tenders at the second stage will be modelled in a secondStage/invitations array. So, even at the level of serialization, the first stage would still have a unique tender/request/whatever.)

The problem, instead, is that this definition would be a mismatch for the 1.1 approach. So, for 1.2, the definition of "OCDS record" should account for (or have a caveat about) procedures with multiple second-stage events having separate records for each event.

Or is uniqueness not the right attribute and instead the central concept for a contracting process should be derived from something else, e.g. value for users?

We're always trying to maximize value for users, but as described in the first comment about the unit of analysis #866 (comment) different users value different things, and presently we have a 'monolithic' format centralized around the concept of an OCDS record. We could take a linked data approach, where every object (whether a supplier, transaction, or contracting process) is a node in a graph, which can be aggregated into whatever shape the user likes, but that would be a consideration for OCDS 2.0.

[JachymHercher]

Based on your comments above and our call, here is a new set of proposals. Looking at the initial topics in #866 (comment), I think we are able to resolve them only partially in OCDS 1.2:

• Unsuccessful processes can be resolved fully by improving the definition.
• Planning stage information can be resolved partially with definitions, but some things will need to be fixed in a backwards incomapatible OCDS update.
• Multistage procedures can be resolved only minimally with definitions, most of the work needs a backwards incompatible update.

Furthermore, beyond the definitions of an OCDS contracting process and an OCDS record, I think we also need to change the definition of the OCID. The reason is that the the discussion above and the resulting definition below exclude the planning stage from the contracting process. However, every release needs to have an Open Contracting Identifier of a contracting process (OCID). Consequently, a release containing only a planning stage (e.g. an equivalent to the EU's prior information notice) would need to have a contracting process identifier even though it is not part of any contracting process.

OCDS 1.2

Normative

OCDS record
"Information about a contracting process or a contracting planning process. Furthermore, a record may also inform about a single stage of a multi-stage procedure (e.g. a framework agreement with reopening of competition)."
EDIT: Second sentence removed, because this case is already covered by the definition of the contracting process, see next paragraph.

OCDS contracting process
"All the actions aimed at concluding one or more contracts. This covers tendering, awarding, contracting and implementation. It does not include actions linked to planning, as these are often less structured and may be linked to multiple contracting processes. In multiple stage procedures (e.g. framework agreements with reopening of competition), each round of competition is treated as a separate contracting process. (Pre)qualification, however, can be treated as the same process by using the prequalification extension.

Procedures that failed and were restarted are considered as new processes.

Boundaries between processes (e.g. whether two contracts result from a single process or from two processes) are set by buyers depending on their needs (e.g. efficient division of labor, clear communication with the market) and legislation (e.g. rules on using procedures and lots)."

OCID
"A globally unique identifier for this Open Contracting Process //OR: contracting process//. Furthermore, this identifier can also refer to an open contracting planning process or a single stage of a multiple stage procedure."

OR

"A globally unique identifier for this Open Contracting Process //OR": contracting process// or an open contracting planning process. Furthermore, this identifier can also refer to a single stage of a multiple stage procedure."

We should choose the first option if in OCDS 2.0, we would introduce a new identifier for contracting planning processes; option 2 if we assume we will keep using OCID for both.

Non-normative

In the identifiers guidance we should specify that users are recommended to use different OCIDs for a release concerning a planning stage and a release concerning the rest of the process, with the two being connected using relatedProcess and the 'planning' code.

More generally, the "contracting process" may deserve a page in the https://standard.open-contracting.org/latest/en/guidance/map/#mapping-the-hard-cases or some comments explaining the above in https://standard.open-contracting.org/latest/en/schema/identifiers/#contracting-process-identifier-ocid, possibly with a note that this might be simplified in OCDS 2.0.

In https://standard.open-contracting.org/latest/en/guidance/map/related_processes/, I would consider removing "The procurement systems through which stages of the process are managed by different bodies, and are not integrated;". Doesn't it just say "you might end up not fully respecting the standard because of your IT idiosyncarcies", which is a fair point, but one which holds for any field?

OCDS 2.0 (i.e. a version requiring backwards incompatible changes)

OCDS record
"Information about a contracting process or a contracting planning process.

OCDS contracting process
"All the actions aimed at concluding one or more contracts. This covers tendering, awarding, contracting and implementation, including (pre)qualification, multiple stages of a framework agreement, etc. It does not include actions linked to planning, as these are often less structured and may be linked to multiple contracting processes.

Procedures that failed and were restarted are considered as new processes.

Boundaries between processes (e.g. whether two contracts result from a single process or from two processes) are set by buyers depending on their needs (e.g. efficient division of labor, clear communication with the market) and legislation (e.g. rules on using procedures and lots)."

OCID
"A globally unique identifier for this Open Contracting Process //OR: contracting process//."

OR

"A globally unique identifier for this Open Contracting Process //OR: contracting process// or an open contracting planning process.

If we go for the first option, we will need a new field and identifier for contracting planning processes.

[jpmckinney]

In terms of where to describe these concepts, they will form an important part of the Getting Started section, though we should also describe them (or refer to Getting Started) on the pages you mention.

I agree with removing that bullet from the related processes page.

Prequalification

The semantics of the prequalification extension aren't consistent with OCDS – it introduces a new preQualification object, which is intended to represent the first stage, after which the tender object is used for the second stage. However, in OCDS, tender expresses procedure-level information and first-stage information.

The issues related to prequalification are #906 and #909 (though not scheduled for 1.2).

Planning

I think it's okay for a contracting process to describe planning details that have already completed. Do the definitions exclude that possibility?

The Budget Breakdown, Finance, Project and Metrics extensions add fields to the Planning and Budget objects, and several publishers make use of Budget Breakdown. (It's possible that this information doesn't belong in planning.)

Can you add a definition for "contracting planning process"?

OCID

I prefer option 1. I think OCDS 2.0 would likely pursue/allow the publication of individual objects, in which case we might have a class for Procedure, a class for PlanningProcess, etc. each of which would have a separate id property.

[JachymHercher]

Prequalification

The semantics of the prequalification extension aren't consistent with OCDS

Noted, but what does this imply for the proposed definitions for OCDS 1.2? We can remove "(Pre)qualification, however, can be treated as the same process by using the prequalification extension." but if the prequalification extension may be used for the time being, then shouldn't we explain it? (We could add a box saying that the Prequalification will be changed in a future version of OCDS.)

Planning

I think it's okay for a contracting process to describe planning details that have already completed. Do the definitions exclude that possibility?

Yes, the proposal above would exclude it. Are you sure that data should be structured differently depending on when it is published? This would probably just concern the type of identifier and whether you need a relatedProcess, but I'd still think that data structure should only reflect the contracting actions, not when you decide to publish information about them.

Also, I'm wondering how set in stone a "completed" planning process really is. I'd be afraid that even if "completed", it could still happen that it would end up leading to an unforeseen contracting process if the buyer's circumstances change. This is not a problem if it is always under a separate ID, but would be a problem if it was placed under an OCID.

(Going superficially through Budget Breakdown, Finance, Project and Metrics extensions, I like how Metrics can apply to any stage. I think the others could as well, or rather, I think that budget, finance and project might be linked to a planning or contracting process as a whole rather than to a particular stage. However, that's probably off-topic here.)

Can you add a definition for "contracting planning process"?

OCDS contracting planning process (For brevity, I've removed the "contracting", I'd say it still works.)
"All the action aimed at planning one or more contracting processes. This covers, for example, establishing the rationale for the procurement, getting the necessary budget, forecasting and conducting market research.

Planning processes are often less structured than contracting processes, so one or more planning process may end up leading to one or more contracting process."

[jpmckinney]

MAPS glossary defines:

Term	Definition
Public procurement	The process of identifying what is needed; determining who the best person or organisation is to supply this need; and ensuring that what is needed is delivered to the right place, at the right time and for the best price; and that all this is done in a fair and open manner;
Public procurement cycle	The sequence of related activities, from needs assessment through competition and award to payment and contract management, as well as any subsequent monitoring or auditing.
Public-private partnership	A contract (institutional relationship) between public and private actors for the co-operative provision of a public good or service. The essential element is some degree of private participation in the delivery of goods or services traditionally in the public domain. Private actors may include both for-profit and not-for-profit organisations.

UNCITRAL glossary defines:

ID	Term	Definition	Reference
58	Procurement	Defined in the Model Law as: “Acquisition of goods, construction or services by a procuring entity.” For the explanation of the terms “goods” and “construction”, see ## 35 and 15 above. For the explanation of the terms “procuring entity” and “services”, see ## 62 and 76 below.	N/A
64	Public procurement	Should be understood as procurement (see # 58 above).

EBRD glossary lists:

UNCITRAL Model Law Terms	Description Notes	Others in use or similar Terms
Procurement procedure	The procedure for awarding a contract	Award Procedure (EU)

[jpmckinney]

Prequalification

Noted, but what does this imply for the proposed definitions for OCDS 1.2? We can remove "(Pre)qualification, however, can be treated as the same process by using the prequalification extension." but if the prequalification extension may be used for the time being, then shouldn't we explain it? (We could add a box saying that the Prequalification will be changed in a future version of OCDS.)

The prequalification extension is going away and thankfully, to my knowledge, no one has used it: open-contracting-extensions/public-private-partnerships#217

Planning

Apologies, I might have lost the thread of the discussion in the past month. My understanding is, for OCDS 1.2:

Publishers can create OCDS releases/records for planning processes, even though these are not the same as contracting processes. The contracting process(es) that result from the planning process should refer to it using relatedProcesses and use different OCID(s). Those contracting processes should omit the planning section. As for the planning processes, they should omit the awards and contracts section. Right now, in OCDS, the tender section covers fields relevant to describing the procedure (not just the solicitation), so planning processes might include some tender fields.

Is that consistent with the proposal?

[JachymHercher]

Yes, it is consistent.

Main point of #866 (comment) was that we should have the same approach for all processes, i.e. there is no processes containing Planning and at the same time (Awards and/or Contracts). It is one or the other, always. This implies, for example, that if a publisher wants to provide information about rationale or budget, he has to do it within a separate OCDS planning process.

Right now, in OCDS, the tender section covers fields relevant to describing the procedure (not just the solicitation), so planning processes might include some tender fields.

Very good (and basic) point, I didn't realize that. I'm wondering what implications this ambiguity (Tender block being used both during the "planning stage" and "tender stage") has for definitions of Tender, Planning and potentially also others blocks. Perhaps their definitions should not refer to "stages" at all, but simply talk about the data that they contain. Worth a separate issue?

Concerning the definition of the "OCDS planning process", I would update it like this to take into account of Tender being used:

"All the actions aimed at planning one or more contracting processes. This covers, for example, establishing the rationale for the procurement, giving the market a general description of the purchase, getting the necessary budget, forecasting and conducting market research.

Planning processes are often less structured than contracting processes, so one or more planning process may end up leading to one or more contracting process."

Also, it's worth noting that if there was a release that only contains Tender, then, under 1.2, it would not be clear whether it is a part of an OCDS contracting process or an OCDS planning process (and may even become either, depending on which information is added to it through time). I don't think this would bring major problems, but e.g. in some cases it could happen that a company will not know whether to expect more information before the deadline for submission of tenders passes or not.

[jpmckinney]

Worth a separate issue?

I created #1154

Also, it's worth noting that if there was a release that only contains Tender, then, under 1.2, it would not be clear whether it is a part of an OCDS contracting process or an OCDS planning process (and may even become either, depending on which information is added to it through time).

The release should be tagged as 'planning' or 'planningUpdate' to distinguish it as a planning release. That said, compiled releases lose this detail. But, the problem could be solved by the user by querying for data that refers back to the planning OCID with a 'planning' relationship.

I think we've clarified this issue. Could you prepare a PR while it is still fresh? Once that is done, we can also create follow-up issues to add guidance on:

• when/how to create planning processes vs. contracting processes
• how to upgrade from OCDS 1.1 to OCDS 1.2 (especially relevant to publishers with planning extensions)

[JachymHercher]

I have created a draft PR. A few notes:

1. An OCID is normatively defined in the schema (as well as https://standard.open-contracting.org/latest/en/schema/identifiers/). However, I do not think there are any normative definitions for "record" (except a brief mention in the description of the top-level "Schema for an Open Contracting Release"), nor contracting process and planning process. Shouldn't we define them normatively somewhere (e.g. into the description of "Schema for an Open Contracting Release")?
2. There are no changes (yet) to http://standard.open-contracting.org/latest/en/getting_started/contracting_process/, because Getting Started is under review. I assume this is the main place where we will explain how it works.
3. I have replaced "contracting process" with "contracting and/or planning process" only in a few prominent places where I thought it would be useful. The rest I propose doing once the "Getting Started" section is reviewed.

(Thinking above the above also led me to #1215.)

[JachymHercher]

1. Discussed with @jpmckinney, yes, we add the definitions to "Schema for an Open Contracting Release". Done in 588097f.

[JachymHercher]

The PR is pretty much ready. The updates to the guidance assume that #1300 and #1333 are part of 1.2, which is not currently the case, but that shouldn't hopefully cause major problems. Few new issues below:

4. The first two sentences of the contracting process definition agreed above are "All the actions aimed at concluding a contract. This covers tendering, awarding, contracting and implementation." The first sentence has a problem - it very much sounds as if the "Implementation" stage/block is not part of a contracting process. I see a few possible solutions:
   a) Change "concluding" to "implementing" in the first sentence. This is strictly speaking correct, but I'm not sure it's intuitive enough.
   b) Change "concluding" to "concluding and implementing". This is strictly speaking superfluous, but might be clearer. On the other hand, the first two sentences then start looking like two different enumerations, which is confusing.
   c) Change "implementing" in the previous point to a new synonym (e.g. realizing, executing), which reduces the repetition / makes the first one look less like an enumeration, but introduces a new undefined term.

   After some going back and forth, I propose a) in the PR.

5. The text includes "Notes" highlighting the lose ends discussed above, which will need to be dealth with in a future update. One of them says:

   When publishing data, we recommend separating data about the planning and contracting processes in line with the definitions above. However, publications of both planning and contracting data within a single contracting process continue to be conformant with OCDS 1.2 and earlier. Requiring the publication of this data in separate planning and contracting processes is being considered for a future, backwards uncompatible version of the standard (GitHub issue).

   If this summary is correct, then publishing planning information is essentially voluntary. In that case, can't we introduce a new OCDS planning identifier (OCPID? OPID?) field already with 1.2.? Since it's voluntary, it is a backwards compatible change. (The requirement for conformity would change from "your release must have an OCID" to "your release must have an OCID or OCPID").

   I'm not sure whether that causes any problems with the "single object publication" mentioned in Clarify definition of contracting process #866 (comment), but I would assume it doesn't. (Also, single object publication also sounds like another thing you "may" do, so something that maybe doesn't need to wait for a major release?)

   This change is not reflected in the current PR, but it would be fairly easy.

6. The contracting process image (moved from Unsuccessful tenders to the new Contracting and planning processes) needs to be updated in line with the text. If the text stays as it is, then the main changes should be:

   • Show that planning and tender are part of planning processes; tender to implementation of contracting processes.
   • Remove the mentions of "initiating" from the image (they have been removed from the text).

7. The new Guidance on Planning and contracting processes now states that

   A planning process ought to have releaseTag set to 'planning' (or 'planningUpdate'). A contracting process can have releaseTag set to any other value from the codelist. A planning process should not contain the releaseTag 'tender' even if it contains the Tender block.

   I believe this is appropriate because, if we don't go for the OCPID mentioned in 5, it is essentially the only way to distinguish, in OCDS 1.2., a "2.0 style" planning process and an "1.1 style" contracting process containing a planning block and a tender block - the former will not contain tender in releaseTag, the latter will.

8. Sometimes, I'm a bit worried about the cyclical nature of the process definitions. Specifically, whether the contracting process being "actions aiming at a contract" and the planning process being "actions aiming at a contracting process" doesn't imply that the planning process is also part of the contracting process. Perhaps it's just splitting hairs though.

Concerning the two tasks mentioned at the bottom of #866 (comment), I'm not sure we need anything more for the first one, I did not address the second one.

[jpmckinney]

4. I am happy with (a), as it reuses a term already in the schema (implementation). Indeed, the purpose is to implement contracts, not only conclude/sign them.
5. • Why would we need a new identifier field for planning processes? Could the same field not be used to identify either contracting processes or planning processes?
   • Regarding the linked data approach with individual nodes/objects: While, in a sense, we can offer in 1.2 an entirely new, parallel standard and approach that publishers may use, that is not really in the spirit of semantic versioning.
6. @yolile Can you work with Jáchym to update the image?
7. Sounds good.
8. I don't see a problem. A planning process is "aimed at planning one or more contracting processes". That seems different from "aimed at implementing one or more contracts". A plan of action is not the same as the action itself.

[jpmckinney]

Concerning the two tasks mentioned at the bottom of #866 (comment), I'm not sure we need anything more for the first one, I did not address the second one.

To be clear, we don't need to do anything more for "when/how to create planning processes vs. contracting processes"? Sounds good. For the second one, I added a comment here: #1217 (comment)

[JachymHercher]

5. Why would we need a new identifier field for planning processes? Could the same field not be used to identify either contracting processes or planning processes?

I think it could, I understood your comment at the end of #866 (comment) ("I prefer option 1") as going for separate fields. If that is not the case, this implies some minor drafting changes, along the lines of #866 (comment). Maybe we just misunderstood each other.

(The only reason I can think of for not having one "process identifier" field is that you could see it as a case of "conditional semantics", where the identifier is sometimes "contracting process identifier" and sometimes "planning process identifier".)

[JachymHercher]

@yolile Can you work with Jáchym to update the image?

@yolile 1d74326 looks good!

[yolile]

@JachymHercher great, and for the planning identifier, remember that we will add that in #1335 (where I will use the "planning process" term)

[jpmckinney]

Aha, option 1 refers to the first of these two options for the OCID description:

"A globally unique identifier for this Open Contracting Process //OR: contracting process//. Furthermore, this identifier can also refer to an open contracting planning process or a single stage of a multiple stage procedure."

"A globally unique identifier for this Open Contracting Process //OR": contracting process// or an open contracting planning process. Furthermore, this identifier can also refer to a single stage of a multiple stage procedure."

I think I was less sensitive to the "Furthermore" construction, but I see its utility now. I might restore it in the PR.

If we were starting fresh, we would have separate schema for contracting processes and planning processes, and we would not need the longer, mixed descriptions for ocid.

I'm not sure whether it's possible to have separate schema in OCDS 1.x. Publishers would need a way to unambiguously opt-in to the separated schema in terms of conformance checks. Users and tools would also have to be aware of the new schema. This is not a principled position, but I feel it'd be too large a change, and that we're constrained to the one release schema.

In any case, if there were separate schema, the same field name can be used in both. For example, we generally use id on objects like award, contract, etc. ocid is just an idiosyncrasy of OCDS. If we were to change anything, it would be to use id consistently, rather than add another idiosyncrasy like ocpid (which also starts to look like Open Contracting Partnership ID).

So, I liked option 1, because I was already thinking of having separate schema, but in which we would just use id everywhere as a generic label for the given object's identifier.

[jpmckinney]

All that said, I think the "minor drafting changes" you refer to are just the differences between options 1 and 2 for the ocid field? If so, then I'm happy to just restore option 1 in the PR.

[JachymHercher]

Based on the outcome of #1385, we will likely need to slightly udpate the definition of planning process from

All the actions aimed at planning one or more contracting processes. This covers, for example, establishing the rationale for the procurement, giving the market a general description of the purchase, getting the necessary budget, forecasting and conducting market research.
Planning processes are often less structured than contracting processes, so one or more planning processes may lead to one or more contracting processes.

to (done in 0bbf85e)

All the actions aimed at planning one or more contracting processes. This covers, for example, need identification, budget planning, and market research.
Planning processes are often less structured than contracting processes, so one or more planning processes may lead to one or more contracting processes.

[JachymHercher]

Moved to #1409

[jpmckinney]

Moved to #1409 (comment)