HT-2020-000448 - [2024] EWHC 1185 (TCC)

Once this dependency had been overcome, it is TCS’s case that the project could have proceeded but for two fundamental difficulties, both of which it claims are ‘Authority Cause’:

DBS’s essential point in answer to these allegations is that a failure to agree changes to the scope of work cannot amount to ‘Authority Cause’ or to a delay event. TCS is required to build in accordance with the scope set out in the Agreement unless and until it is varied by a CCN. If TCS decided not to do so in the anticipation that a change to scope of work may occur in the future, that was at TCS’s own risk.

I will first set out the relevant facts as I find them to be in relation to the period from September 2017 up to the alleged Partial Termination/de-scoping, and then turn to consider the analyses of liability and causation.

Taking stock at September 2017, as identified by Dr Hunt, the key requirements for entry into Final SIT were (1) availability of SIT-L with connectivity to support the R1 Disclosure interfaces (2) availability of all technical architecture unless otherwise agreed (3) completion of CIT/SIT on any further required software drops, including resolution of all Severity 1 & 2 defects, unless agreed with DBS and (4) availability of test plans, test data and test scripts. Dr Hunt confirmed that she had seen no evidence that TCS would have had any issue with the test plans, data and scripts, so (4) was not an issue.

As regards the availability of SIT-L with connectivity to support the R1-D interfaces, as already identified, the initial period of unavailability is linked to its being used for R1-B&B. However, thereafter, there remained third party dependencies. As set out in TCS’s email dated 5 October 2017, at this point there were 18 Disclosure Interfaces with connectivity not yet verified. Dr Hunt accepted that the third party dependencies (for which DBS was responsible) required to be resolved prior to commencing Final SIT and that there were still dependencies outstanding as at February 2018.

In terms of availability of all technical architecture unless otherwise agreed, the areas of dispute concerned RFC 489, R1 Add-Ons services Security Functions, and RFC 417, and Content Inspection. It seemed to be common ground between the IT experts that, as Dr Hunt explicitly accepted and I find, neither of these were required to start Final SIT (although they would have been required to complete it), and so these are not reasons why Final SIT could not have been commenced, if SIT-L with connectivity to support the R1 Disclosure interfaces had been available.

In relation to the Sev2 defects which existed post exit from SIT, these were not being treated with any particular urgency. This is no doubt because, as Dr Hunt also fairly accepted, the Sev2 defects were not going to be ‘showstoppers’ and could have been resolved once TCS had got into Final SIT 2. They would not therefore have prevented the commencement of Final SIT once the environment was available.

Against this background, I accept the factual evidence from Mr Padannayi that, had there not been various other issues considered in more detail below, during this time, TCS would have, as they plead, been ready to enter Final SIT in around September 2017. When cross-examined about a TCS internal email dated 4^th May 2018 that as of that date ‘The software is not ready to start Final SIT’, he explained, and I accept:

However, it follows from this that, for the purposes of the Clause 7 analysis, TCS were never going to achieve the R1-D Milestone until between July and September 2018, if one assumes a period of around 9-12 months from Final SIT to Go-Live. (9 months is not an unreasonable planned period: for example, the 4 October 2017 Microsoft update plan showed a period of 9 months from the start of Final SIT to Go-Live; the 12 December 2017; the February 2018 POAP showed a duration for this period 8.5 months; Dr Hunt’s evidence referred to further below suggests 12 months).

As at the start of September 2017, TCS sought two RBs to test the e-bulk system and the web services solution for SIT. By email dated 6 September 2017, DBS indicated that they were not in a position to provide these. Mr Brown of DBS stated that he considered it necessary to be realistic about the timelines, and that DBS was working on the assumption that e-RBs needed at least 6 months to make system changes to their front end systems. Mr Rowlands of DBS indicated, as part of the same e-mail exchange, the scale of the challenge facing DBS’ roll-out of R1 to RBs:

By mid-September, Mr Padannayi, internally, was recording the existence of a number of risks relating to the progression of R1-D SIT. In his email of 19 September 2017, risk 8 was:

As recorded in the DBS Business Change Review Board Summary, attended by a number of senior DBS witnesses who gave evidence, ‘Must Have’ was a term stemming from use of a basic MoSCoW prioritisation technique. It meant a ‘requirement is defined as making the solution unlawful, unviable or unsafe without this requirement’. Ms Owen, Head of Commercial for DBS, fairly accepted that this was so in terms, at Day 11/143.

At the same time, there were 52 outstanding issues which had not been delivered by TCS with R1-B&B and therefore were to be delivered as part of R1-D. These were referred to as ‘deferred items’.

On 22 September 2017, Mr Kuncheria of TCS sent the following message to Mr Narayanan:

Mr Narayanan responded on the same day:

TCS’s position was being communicated to DBS. On 18 October 2017, the DBS Project Board ‘PB’) minuted that, ‘TCS has advised [Mr Evans of DBS] that they need to know the totality of the build before they move to final SIT. Scope will need to include deferred items, changes as a result of GDPR and known ‘post-R1 RFCS’.

Reflecting the earlier indication from DBS referred to above to Mr Padannayi recorded on 19 September 2017, there were likely to be a number of issues affecting the potential scope of R1-D that were seen as ‘Must Have’, and which needed to be resolved, in addition to the deferred items. For example, in relation to ‘eBulk’, the PB identified issues around the conclusion of the ATOS contract, which ran out in July 2018. The PB would need to decide how long eBulk was extended for. Having identified various factors, the minutes record that “all of this will need to be documented in the data migration strategy. Potential for eBulk to run from R0 and webservice from R1 but will depend on both technical limitations and stakeholder (e-RB) consultation.”

Another important issue was GDPR, which was coming into effect in May 2018, and which would affect the legality of the solution. The PB were informed that there was a DBS working group in place to look at what work was required with the product plan in place to implement this. Issues were identified around eBulk and citizen consent, and the fact that an RB would get results at the same time as the user which will not be compliant under GDPR. The minutes concluded on this topic that the full impact of GDPR was not understood as yet as it covered consent from data subject, what data was wanted, why it was wanted, realistic timescales for holding the data and communication channels that would be used.

Mr Evans of DBS, in a lengthy and slightly confused passage of cross-examination at [Day 11 /87-96] accepted, fairly, that DBS did not challenge the suggestion that the totality of scope needed to be determined before moving to Final SIT. He also accepted that there were ‘Must Have’ RFCs which formed part of what DBS considered to be the minimum viable product, and that if those Must Have RfCs were not agreed there would be no viable product.

In light of these and other issues, under ‘Delivery Confidence’, disclosure delivery moved to ‘amber/red’, recording that comments for the (now pessimistic) Disclosure ‘rating’ as follows:

The inability to divorce delivery from commercials was inherent in the existence of ‘Must Haves’ required by DBS as part of the solution that needed to be agreed according to the Change Control Procedure in order for what DBS considered (and may objectively have been the case) a viable product to be delivered.

The logic of progression to Final SIT being necessarily linked to scope clarification was also reflected in the evidence of Dr Hunt, which I accept in this regard (Day 22/191):

The PB concluded that it was ‘not within sight of a date for disclosure delivery’. The thrust of the minutes, as I find them to be, is that this uncertainty was due principally to difficulties in identifying the ultimate scope in respect of matters which would constitute changes to the way in which TCS was then contracted to provide R1-D. In light of the fact that there were ‘Must Have’ changes, and that those changes would have to be specified through RFCs and their commercial implications negotiated and agreed, the comment that commercials and delivery could not be completely divorced was recognition of the practical reality, notwithstanding the existence of a contractual obligation upon TCS to continue to build to contractual scope unless an RFC was in place. For example, if ‘the transition for RBs cannot take a big bang approach’ was DBS’s position, there was no purpose for either party in TCS continuing to produce that solution. Similarly, continuing work on a solution which would not be complaint with GDPR would obviously be pointless and wasteful for both parties.

On 6 December 2017, DBS presented ‘DBS Challenges with respect to Disclosure R1’ and asked TCS to consider the challenges and provide solutions. Two of those challenges related to transition of RBs from R0 to R1. Mr Topham of DBS (at the time, Chief Information and Digital Officer) confirmed in cross-examination that it was this presentation that led to the issue of RFC 607. He also gave evidence that his understanding was that the genesis of RFC 607 was the lessons learned from Basics deployment, which was that a big bang deployment of all the RBs would be ‘impossible to manage and detrimental to the business’.

On 25 January 2018, DBS’s presentation to the Home Office entitled ‘DBS-TCS Extension’ by Adele Downey, the CEO, sought approval in principle to re-negotiate the contract with TCS. This was known as ‘Plan A’. In terms of Disclosure Release, the document recorded:

In seeking an extension of the TCS contract, one of the reasons given to justify why Plan A was favourable was that it “allows the time required for a phased transition in line with DBS strategy”. It also described the purpose of renegotiation was amongst other things to “support a seamless transition of services and avoidance of ‘big bang’ migrations”. The presentation continued, ‘In order to further de-risk the programme, elements of delivery will be modified from existing TCS contractual scope, including data migration and eRB transition’.

This presentation contained a number of entirely redacted slides (pages 17-23). It is not clear to me why these redactions were made (or, indeed, not challenged). Nevertheless, by reference to the Contents slide setting out the ‘aims’ of the meeting, a reasonable inference is that these slides outlined ‘Plan B’ and ‘Plan C’ contingencies. From Barry Topham’s later presentation ‘Commercial & Delivery Options’ (dated 27 April 2018), it can be seen that Plan B involved TCS Disclosure ceasing delivery, but with a one year extension to allow for transition between a change of suppliers, with Disclosure being provided by another partner. It appears from the presentation that Plans A and B were initially considered as early as October 2017. The same slide identified that the approach agreed in January 2018 had been to make a final decision at the end of February and divert all R1 resources onto plan B if necessary at that point.

With a view to advancing Plan A, RFC 607 was issued on 8 February 2018. It was marked ‘Change Priority: High’ which meant that it was “important for DBS and must be implemented soon enough to prevent a significant negative impact to our ability to conduct business”. The RFC requested TCS “to identify solutions to enable a smooth transition for RB’s moving from the R0 system to R1, for both e-bulk and web submissions”. It further stated:

Dr Hunt’s evidence in relation to RFC607 in her Reply Report stated:

However, Dr Hunt fairly conceded in cross-examination that her understanding of TCS’s intention to include a bridge was wrong and that she may have got the timeline confused. As set out below, her conclusion that the inability to agree the commercial implications of RFC607 and related ‘Must Have’ RFCs did not affect TCS’s ability to enter Final SIT, in at least practical if not purely technical terms, is not supported by the factual evidence.

Mr Padannayi’s evidence, which I accept, was that:

On the same date that RFC 607 was issued, Adele Downey wrote to Mr Shankar Narayanan (TCS’s Head of UK and Ireland) and Mr McCarthy (TCS’s then Commercial Director) stating:

This email therefore recorded an agreement that the parties would enter discussions to consider the scope related matters pertaining to R1-D, which, in particular, would include RB migration. In light of the acknowledgement that the commercials had thwarted progress to date, this email in context confirmed the ‘status quo’ understood by both parties, namely there was a pressing requirement to resolve scope as part of R1-D deployment.

Reflecting this, the following was then reported by Ms Downey to the DBS team, described as ‘an agreed statement for Shankar and I’:

“Following the productive joint meetings that have taken place between colleagues in India and in the UK, we have reached joint agreement in principle for the Disclosure re-planning exercise, subject to validation of one commercial matter to be concluded by close on Monday 12 February. Both teams are therefore commissioned to conduct a joint re-planning exercise that will result in a Disclosure delivery date and broad cost proposals for agreed changes to scope. This is to be agreed by 23rd February to form part of the formal negotiations that will take place week of 26 February.”

It is to be noted that the agreement related to the ‘re-planning exercise’, there being no suggestion that TCS was, or could be, continuing with R1-D Final SIT until the scope of R1-D was known and agreed. There was no evidence about the ‘one commercial matter to be concluded by close on Monday 12 February’, and nothing was provided to suggest that this attempt to reach commercial agreement on scope floundered within days. The evidence demonstrated that it continued at a project level (through workshops) and a commercial level for some time.

No doubt as part of the pressure to resolve scope issues, it was around this time that it appears that DBS started to engage with RBs. On 14 February 2018, a conference call took place with a number of RBs to begin ‘early engagement on the transition options’. This presented options of parallel running, big bang and ‘transition period’ (effectively what became known as Option 4). Feedback from the e-RBs was reported as being that more time would be required to assess the available options, and that a minimum of 6 months lead in time from the publication of the final version of the specifications would be required. Clearly, on this basis, in circumstances where the specification was in flux due to DBS’s concerns around the migration strategy (and the feasibility of the solution TCS had contracted to provide), delivery was still a long way off. Indeed, Mr Fritton of DBS advised the e-RBs that ‘no confirmed date for R1 (standard/enhanced) exists currently, although the aim is to delivery within 12 months’ (i.e. February 2019).

Alongside RFC 607, the Business Change Review Board on 16 February had been convened by DBS to give ‘urgent consideration of must have RfCs for R1 Disclosure go-live being given highest priority to enable planning to take place…..’. In light of the essential nature of Must Have RFCs to the viability of the R1-D solution, it is entirely unsurprising that DBS knew well that resolution of those RFCs as part of the overall scope was a necessary part of project planning (and, of course, in due course development and testing). The meeting identified 23 outstanding RFCs which were ‘Must Have’ RFCs that had to be delivered for R1-D Go-Live. Some of the ‘Must Have’s were nevertheless recorded as ‘To remain on hold’ with the BCRB deciding (for example, in relation to RFCs 567 and 576) that notwithstanding their ‘Must Have’ status, ‘the RfC is on hold and is not to be sent to TCS yet’.

On 26 February 2018, TCS presented a number of options under RFC 607, Option 4 being recorded as DBS’s preferred option, which was for a ‘bridge’ to be developed to allow RBs to make submissions using either R0 or R1 data formats before and after Go-Live of R1-D. The final slide set out assumptions about the commercial implications of the change:

In essence, this was required to enable R1 to be delivered in a staggered migration rather than a ‘big bang’, in line with DBS’s own concerns and strategy. TCS’s POAP of the same date based upon the implementation of Option 4 showed that the submission of RFCs by DBS was part of the anticipated timelines, forming part of the critical path through Code Drop 2 to Final SIT and beyond to Go-Live on 16 July 2019:

Mr Evans, of DBS, agreed in cross-examination, and I accept, that their inclusion within the POAPs indicated that the RFCs were regarded by the parties as key. In cross-examination, Mr Evans gave the following evidence (Day 11/121):

Numerous workshops were required between the parties in order to finalise the scope. In parallel with the discussions between DBS and TCS to agree the scope of R1-D, with associated commercials, DBS was, perhaps not unsurprisingly, planning for the eventuality that a commercial agreement could not be reached and as such, ‘Plan A’ would prove unachievable. DBS was reporting internally (in the presentation by Mr Topham dated 2 March 2018) that in delivering plan B with a new supplier, DBS would be effectively starting the R1-D delivery from scratch with any Design and Build work undertaken by TCS being rendered as nugatory. It indicated that there would be a substantial cost to maintain R0 until the R1-Dwas delivered by the new supplier. The procurement process/contract review period for the new supplier was anticipated to be starting in Q2 2018 (i.e. imminently).

As at 20 March 2018, TCS reported (at slide 2) to DBS on the ongoing workshop process to agree the new scope. TCS indicated that 14 High Level Scope Items needed to be clarified, which needed 35 workshops with various DBS teams and 20 workshops with various TCS teams. Approximately 400 Test Cases were estimated to be added to Final SIT scope due to RFCs. At slide 4 of TCS’s presentation, it indicated that the reasons TCS could not start Final SIT were RFCs, GDPR, External Stakeholder Readiness, SPS changes because of GDPR and RFCs (SPS was a key sub-contractor to TCS providing physical document handling services), Data Migration Strategy and External Interface Connectivity. The presentation then detailed for each of these categories a series of issues and what needed to be resolved by the DBS, third parties, or the parties together. For example, it was for DBS to confirm the number of Templates to be changed due to GDPR; and DBS needed to engage with the Friendly RBs.

There was a discussion of the programme between DBS and TCS at a Programme Board meeting on 27 March 2018. In the section of the meeting attended by DBS alone, Mr Evans gave the R1 Programme update which was reported as follows:

It is clear that both DBS and TCS were proceeding at this time on the joint understanding that without commercial agreement on the ‘Must Have’s R1-D was not viable, at least not as envisaged in the original TCS specification. I accept the evidence of Mr Padannayi, consistent with this conclusion, that RFC 607 was fundamental to the whole approach at this time, and its significant ramifications needed to be understood and agreed before TCS could proceed. This was also the effect of Mr Topham’s evidence, which I accept in this regard (Day 9/66):

By 25 April 2018, however, DBS had informed TCS that RFC 607 was not going to proceed. It indicated to TCS the reason as follows:

I accept TCS’s submission that this reason was essentially bogus. DBS clearly remained of the view that a ‘big bang’ transition was practically unworkable. There is no evidence that their engagement with RBs on the issue, which had started very late, and which by this stage was extremely limited had led them to alter their own view expressed in October 2018 that, ‘The transition for RBs cannot take a big bang approach’. This is unsurprising, in light of the technical view of Dr Hunt, which I accept, that ‘moving all 170 e-RBS from one interface to another simultaneously would always have been very challenging, if not impossible, to achieve’. Nor is there any evidence that DBS’s internal planning at this stage or in the months to come was at any stage predicated on any scenario which adopted a ‘big bang’ approach to data migration and transition. This letter was, instead, the beginning of the end of negotiations to produce a solution by which TCS would be able to deliver the R1-D which DBS knew it needed for its own reasons.

This strategy was reflected in the ‘Commercial and Delivery Options’ presentation by Mr Topham dated 2 days later. One slide set out what, ‘DBS Wants and Needs from Disaggregation’. This outlined the benefits from the DBS strategy of moving away from a single supplier like TCS. The key ‘changes in approach’ included:

It is also fair to identify that within this presentation, DBS presented considerable dissatisfaction with TCS delivery in relation to Barring and Basics, and that it may well be that that dissatisfaction fed into the decision which was effectively made around this time to bring TCS delivery of R1-D to an end. In my judgment, the degree of dissatisfaction, at least insofar as it could legitimately have been directed at TCS, is overstated. In terms of delays to R1-B&B, I have already concluded that TCS is not entitled to relief in light of its inability to have satisfied the contractual requirements of Clause 7. This does not mean that (notwithstanding the contractual risk allocation) it did not face considerable difficulties caused in reality by HPE’s infrastructure issues which were outside its direct control. In terms of the defects in R1 delivery, as set out in the relevant section below, I consider that whilst there is some justification in relation to some of the difficulties encountered, there are also a number of user-interface issues which are not the responsibility of TCS, and the significant performance and reliability related issues encountered after Go-Live (Snowbound aside) were predominantly caused, also, by infrastructure.

On 4 May 2018, TCS set out internally the reasons why at that stage TCS did not consider that it was possible to deliver R1-D by March 2019. I have already set out Mr Padannayi’s evidence in respect of the first reason, above. The other items in the email included:

It is clear from this email that, as DBS submits, it was technically possible at this stage for TCS to produce its Interface Control Document updated with matters which were within TCS’s control to update. However, it is equally clear that this would not be a final ICD until the GPDR issue was resolved. The evidence set out above demonstrated that the RBs had said clearly that a minimum of 6 months lead in time from the publication of the final version of the specifications would be required. The production of a non-final version would not have, in my judgment, advanced matters and was not causing any delay in the engagement of ‘the major dependency’. There is no contemporaneous evidence that the non-production of a non-final ICD was either causing actual delay nor delaying engagement with RBs.

On 22 May 2022, Mr Topham and Mr Whiting of DBS produced their commercial update paper recommending that the Board endorse the approach of discontinuing R1-D delivery with TCS and exit the contract as soon as reasonably practicable. This was referred to as ‘Plan D’. The paper reported that the cost of this option (Plan D) had been assessed at £231.7m versus a revised Plan A (i.e. to have continued with TCS, deliver disclosure on an extension of up to 3 years) cost of £276.5m for the period 2017-18 to 2021-22. The revised cost was broken down into BAU expenditure of £123.3m and additional expenditure of £108.4m including optimism bias of £24m.

On 31 May 2018, TCS responded to DBS’s letter of 25 April 2018, relating to RFC 607. The letter stated, having set out a short history of the matter:

Contrary to DBS’s submission that this reflected TCS (implicitly unjustifiable) ‘digging in’, in my judgment this letter reflected a generally accurate picture that the whole impetus for the move away from a (contractually specified) single migration was DBS’s initiative, with which TCS provided its co-operation. Indeed, this fact was accepted fairly by Mr Topham in evidence (Day 9, p35):

DBS’s submission, however, that this letter is a reflection of the fact that by this stage at the latest negotiation over the scope of R1-D had broken down is accurate. TCS concluded its letter by requiring that DBS ‘Finalise and communicate to TCS the final approach of data migration, including any agreement of any outstanding options’ by 6 June 2018.

This did not happen. On 13 June 2018, an instruction was given within TCS to cease work on R1-D. I accept that this was because TCS were not receiving the inputs they required from DBS, as explained by Mr Kuncheria in evidence when questioned about this evidence (Day3/106):

On the same date, the Options paper from Mr Topham and Mr Whiting was sent to the Home Office for approval. A further summary position paper was sent on 22 June 2018 which made clear that DBS's initial evaluation supported a preferred option of not building a new R1-D product; instead a new provider would take over the existing R1 system as it was (Basics and Barring) together with the current R0 (Disclosure). DBS sought official approval. The report emphasised what it saw as TCS’s failures in relation to R1-B&B delivery, and in relation to data migration stated that, ‘Levels of programme and technical complexity have increased and TCS's original proposal for data migration and registered body transition were flawed and the impact would have been catastrophic for DBS. DBS insistence following the difficulties experienced in the Basics transition led to TCS reconsidering their approach.’ This does not, in my judgment, fairly characterise the development of the change in approach to transition, with DBS (no doubt for reasons of internal pressure) seeking to place responsibility for the move away from ‘big bang’ on a flaw in the proposed technical solution, rather than its own views as to the ability of RBs to be ready for such an approach and the effect of RB unreadiness and/or lack of capability at a single unified time on the viability of continued provision of disclosure services. DBS were fully aware of the delays to the delivery of R1-D caused by the preceding period of flux in its attempts to institute Plan A and then Plan B, and noted at 3.6 that (in light of these delays) ‘Investment in the R0 legacy systems was always going to be a requirement’. It also noted a non-financial benefit to the preferred approach that it would enable greater focus on Disclosure improvements for the business as management attention was not on delivering a full new Disclosure solution. The paper also set out the perceived savings of the preferred approach against ‘the current product price’.

The Board’s conclusions were as follows:

The proposed timeline took negotiations through to the end of September 2018 at the latest whilst approval for the approach was obtained.

Positioning correspondence continued between the parties about the origins of the implementation of phased transition and TCS’s development of R1-D. On 28 June 2018, TCS recorded in correspondence, in my judgment accurately:

DBS wrote to TCS on 9 July and 17 August 2018. These were letters which were in due course relied upon by DBS in its purported Partial Termination of the contract (i.e. what was to be the descoping of R1-D).

The 9 July 2018 letter (from DBS’s solicitors) dealt the ‘data breach’ incidents, and performance and efficiency issues with R1-B&B. Paragraph 4.3 stated that the facts previously set out were ‘material Defaults’, specifically:

DBS therefore required TCS to comply with a Remedial Plan process in accordance with Clause 56.2.1 of the Agreement. The only reference to R1-D in the letter was at paragraph 5.8 which stated:

TCS’s response joined issue with the content of much of the letter. A short further letter from DBS’s solicitors dated 17 August 2018 re-iterated DBS’s position that a Remedial Plan in accordance with Clause 56.2 of the Agreement was required.

The business case proposed by the Board was considered by the PIC committee on 30 August 2018, and by email dated 13 September 2018, approval for the proposal to move services from the TCS contract to a new supplier as soon as possible after the end of the current contract was given.

Five days later, DBS’s solicitors wrote further to the letters of 9 July and 17 August 2018 stating, on 18 September 2018, in relation to R1-D:

The following day, DBS gave notice of Partial Termination. The letter stated:

Following de-scoping, the parties disagreed about the contractual validity of the Partial Termination. However, the parties treated R1-D as having been removed from the scope of work in fact. For example, in DBS’s Change Management Report dated 9 October 2018 following the above communications, DBS had reported upon its ‘Review of RFC pipeline required following DBS decision to not roll out R1 any further; not introducing R1 for Standard and Enhanced Disclosures.’ The ‘Must Have’ RFCs were generally stated to be with DBS, and were generally ‘on hold’. DBS’s Amended Defence and Counterclaim expressly admits (at paragraph 46.1), and I find, that following the notice of Partial Termination DBS did not (and indeed, to use the word asserted by DBS within its pleading ‘refused to’) engage with TCS in relation to R1-D. In its Closing Submission DBS contends that TCS did not pursue this point or put it to witnesses, but in light of DBS’s pleaded admission, this was not necessary.

R1-D could plainly not in fact be delivered without (1) resolution of the scope question in relation to those RFCs DBS regarded as ‘Must-Haves’ (which would require further co-operation from DBS) and (2) engagement from third parties and in particular RBs, for which DBS was again responsible for co-ordinating. As Dr Hunt’s evidence confirmed, and I find, TCS could not ‘strike out alone’ once DBS had indicated that, lawfully or unlawfully, it had removed R1-D from TCS’s scope and its engagement ceased.

On the basis of the foregoing chronology, distilled from the much wider body of documentation and witness evidence relied upon by the parties which I have considered, I therefore find as a matter of fact that, in summary: