contractStatus: Add termination codes

[timgdavies]

@LindseyAM has raised the concern that some implementers are finding the codelist entry for Contract Status of terminated contains too negative a connotation.

Lindsey states:

there was feedback that terminate was too negative (sounding like the contract was ended for failure to perform etc. rather than that the contract simply ended)

The current codelist is shown below:

Code	Title	Description
pending	Pending	This contract has been proposed, but is not yet in force. It may be awaiting signature.
active	Active	This contract has been signed by all the parties, and is now legally in force.
cancelled	Cancelled	This contract has been cancelled prior to being signed.
terminated	Terminated	This contract was signed and in force, and has now come to a close. This may be due to successful completion of the contract, or may be early termination due to some non-completion.

Views on this issue are welcome.

[timgdavies]

@ekoner Is there a quick way for us to check if particular organisations are using or not using 'terminated' as a code in their data?

[chrisalexsmith]

I agree with the concern. Suggest 'terminated' is more appropriate to an active contract that has for some reason been cancelled after signature (either in part or in full) and that 'completed' better describes a contract where all obligations have been fulfilled. In fact it might be helpful to differentiate between the two types.

[timgdavies]

ResourceContracts.org have also described a need to capture a distinction between:

• Contracts terminated prior to completion
• Contracts terminated at completion

There is also the case of 'expired' contracts. I.e. not formally terminated in any way, but past the dates when they would be active.

Considerations

There are a couple of considerations here:

1. We need to be careful to distinguish the concept of contract status (in terms of whether it is force or not) with concepts of contract outcome (actual delivery of the contracted services being complete or not)

2. We need to think about how this data would be supplied: do systems store information that would allow them to choose between termination statuses (this requires some degree of implementation information to be managed)

3. We need to think about how users would draw on this data: if we can be sure there will be reliable data generated by some systems on contract status (distinguishing completed and terminated contracts), are there clear use cases for this - and forms of analysis it enables? And analysis that could not be completed using other existing OCDS fields? (i.e. we want to avoid modelling the same thing in multiple ways).

4. Any change to existing codelists should not change the semantics of the codes. This means we cannot change 'terminated' to mean only 'terminated due to failure' or similar, else the meaning of existing data would change/become confused.

Next steps

From the considerations above - I'm not sure how far we can/should add 'completed' as a code.

It would be useful I think to look at existing Contracts Registers to see what codes they use.

[KaitlinCCSI]

Just a few more thoughts from ResourceContracts/OpenLandContracts:

• Agree with earlier comments about the connotation of “terminated” as well as the distinction seen between “terminated” and “completed” (and while we mentioned expired, don't think that there is as much of a need to distinguish between “completed” and “expired”).

• Some potential use cases/reasons why people would want to know difference between terminated and completed include:

o Researchers/activists who are trying to 'follow the money' related to a particular land or extractives deal wanting to know whether a project was in existence for the full term contemplated in the contract, or ended at an earlier date.

o Researchers using contractual information (along with other project level financial/production disclosures, EITI reports etc.) to model or draw conclusions on the 'fairness' of the fiscal or other terms of a deal wanting to know, ideally, the actual length of the project, or, if that is not possible, to flag that a project ended earlier than the date contemplated in the contract.

o Governments disclosing contracts for transparency purposes wishing to be clear that they received rents/royalties/taxes etc. from a particular project for a shorter period than anticipated by the contract.

o Researchers/others looking at durability of contracts: for same reason one might want to know whether a contract was amended, if it was terminated early, that could similarly suggest the unsustainability (for many reasons) of the contract at the outset and would usefully be reviewed in the same pool as amended contracts

o Researchers/others looking at projects where there has been social unrest or tension between the parties (host state and investor): one wanting to find the underlying contract would want to know whether the contract was terminated prior to completion.

[chrisalexsmith]

One significant cause of contracts being terminated before completion is non-performance by the supplier (or the purchaser or both),possibly resulting in the parties to the contract going to arbitration or court.
It's important for non-performing suppliers and contracts to be identified.

[timgdavies]

Comments from Isabel-Maria Da-Rosa at the EC.

The contract itself has no status. This information that you referred is associated with implementation. There, we have a status field telling if it is on-going (mainly used in public works), terminated or concluded. And yes, we use “terminated” for those cases that the contract ended but was not concluded. We also have to fill an obligatory justification on those situations. It is common to happen, for example, when the Court of Auditors doesn’t give a positive visa.

[timgdavies]

Thanks @KaitlinCCSI for the nudge on this issue.

This did not make it into the 1.1 upgrade, though I'm tagging it post-1.1 so we don't miss it in planning for next major or minor update.

Observations:

• We can't just add a code to contract.status. We would need to deprecate 'terminated' and introduce something like 'concluded' and 'earlyTermination'. Otherwise there is a risk of the meaning of 'termination' being changed in a way that upsets interpretation of data.

• Many of the cases @KaitlinCCSI cites are to do with the date on which a contract ended (either because it was complete, or because of early termination). With use of contract.status this is inferred from the release.date, but not made explicit (and it's possible with the current data model to run these forms of analysis by looking for the release.date value of any release containing contract.status='terminated' and finding those which are before the contract.period.endDate)

• The issue then seems to be about whether we make the date at which a contract actually ended, and the nature of that ending, explicit.

Drawing also on Isabel's comment above, this leads me towards the idea that we should have an extension to Implementation that adds:

• implementation.status with values of 'planned', 'ongoing', 'concluded', 'cancelled'.
• implementation.startDate - the date that implementation formally started.
• implementation.endDate - the data when the operational period of the contract came to an end, either on conclusion of the work, or through cancellation.
• implementation.description - a free text field where any summary information about implementation can be provided.

(I'm specifically avoiding using Period for the startDate and endDate so that there is no suggestion that endDate should be completed prior to the contract implementation ending.

We could still look at tweaks to the contract.status codelist in future upgrades, but taking this extension route would avoid a hold-up, and would clearly separate information on the status of the contract, from information on the status of the implementation.

[ekoner]

@timgdavies I think I replied offline to #395 (comment)

The answer is no-one had published a terminated status as of our pre-upgrade survey.

[SamCCSI]

Thanks @timgdavies

If we were only interested in marking whether a contract has (i) been amended; (ii) been terminated prior to expiration of the contract term; or (iii) expired at the end of the contract term, would there be a way for us to do so without creating any consistency problems with OCDS once an OCDS standard is actually decided on for these issues? ('Planned' or 'ongoing' would likely not be workable in our context, as they will become quickly outdated. )

[timgdavies]

@SamCCSI On the specific question you should not make changes to the values of contract.status, but an OCDS idiomatic way to add the additional flags you want would be to include them in an contract.statusDetails field based on your own codelist, perhaps including:

• earlyTermination
• expiredAtEndOfTerm

For amendments, OCDS 1.1 introduces an amendments array to key objects (tender, contracts) etc. that allows for dates and descriptions of changes - but that could be used to simply record that an amendment has taken place with the field:

contract.ammendments.description containing something like 'Contract Amended'

which would allow OCDS standard-aware systems to register the presence of an amendment, even when other details are not available.

[LindseyAM]

This issue continues to be relevant in Ukraine where data users have indicated it is hard to tell when a contract has been 'terminated' (eg due to non-performance) or ended as intended (eg a concluded purchase).

Perhaps confusion around this codelist is the reason why @ekoner mentioned the terminated status had not been used. I wonder therefore if users can tell if a contract is concluded in any of the implementations (for good or bad reasons). @lmanasco it would be interesting to know if this is still the case...

When possible to change the codelist, would advocate for terminated to be redefined with a negative connotation and concluded to be introduced as the term for when the contract ends well.

[LindseyAM]

This issue came up again today. "Terminated" could be changed to "Ended" or something not as loaded with meaning.

Looking forward to insight from @ekoner and @lmanasco about how this field is being used.

[timgdavies]

One other option naming wise may be extend the code name, to remove the 'loaded' nature, so that we would have codes such as:

• terminatedAtCompletion
• terminatedEarly

[jpmckinney]

The definition of 'terminated' currently encompasses both normal and early termination of the contract. We consequently cannot add a code that bears either of these meanings without editing the definition of 'terminated', otherwise we would have two codes that overlap.

We can add narrower codes without changing broader codes. It's common in ontologies for there to be terms at greater and lesser specificity, e.g. animalia, carnivora, canis lupis familiaris.

[JachymHercher]

I haven't found yet how the EU calls "happy" contract terminations. @JachymHercher, do you have an idea?

In fact, I don't. Maybe there are no happy contracts in the EU? :-) Or, more seriously, it's because implementation is largely out of scope of the EU directives, so indeed things generally end with "contract conclusion"AKA signing.

Off the top of my head, I'd use 'fulfilled' or 'completed' (suggested above and used in tender.status) for a happy contract. ('Ended' is too ambiguous.)

[ColinMaudry]

I'd love to coin "happy" as a standard contract.status code, but I'm not sure @jpmckinney would agree 😋

[ColinMaudry]

It's common in ontologies for there to be terms at greater and lesser specificity

Right, but in ontologies the parent-child relationship is formally expressed. OCDS uses flat codelists, the relationship would need to be expressed in a "loose" fashion, i.e. in the definition of the codes. I don't remember such underlying parent-child relationship in OCDS codelists.

We can do it, but I fear it may be poorly understood and may make data analysis more difficult (misuse in data + poor understanding by data analysts).

[jpmckinney]

I agree that, absent better support for expressing hierarchy between terms, it is not a good idea to have such relationships.

However, in this specific case, we have a code that is in use that is underspecified. For this scenario, I think it is an acceptable compromise to introduce more specific codes without deprecating the broader code. Of course, we might discover during consultation with stakeholders that deprecating the broader code is preferred. We can prioritize this question for outreach. Meanwhile, it will still be useful to define the specific codes, as they will survive either version of the proposal.

[ColinMaudry]

Alright, I just wanted to make sure we are aware of the risks.

Based on this discussion, in the spirit of #395 (comment), I propose the following, which strictly builds on top of the current description of 'terminated' so that the semantics are as obvious as possible:

• 'terminated' remains as-is

This contract was signed and in force, and has now come to a close. This might be due to the successful completion of the contract, or might be early termination due to some non-completion."

• 'terminatedEarly'

This contract was signed and in force, and was terminated early due to some non-completion."

• 'terminatedSuccessful'

This contract was signed and in force, and was terminated due to its successful completion."

[jpmckinney]

'terminatedSuccessful' -> 'terminatedSuccessfully'

Change the second 'was' to 'is', since we typically express semantics in the present tense.

Otherwise, those look good to me.

We might do a comprehensive copy-edit as part of #827, so we can leave further refinement to later, and just do a straightforward split of the 'terminated' description as proposed.