Thread by @nickwallis

Welcome to court 26 of the High Court’s Rolls Building for day 15 of the Horizon trial, part of the Bates v Post Office group litigation. Live tweets of proceedings to follow.

Jason Coyne is in the witness box. He is the independent IT expert contracted by the Subpostmasters to look into Horizon. He is being cross-examined by the Post Office’s QC, Anthony de Garr Robinson.

These live tweets are a summary or description of what is happening or being said in court. Nothing is a direct quote unless it is in "direct quotes”.

JC (Mr Coyne) has been taken to a passage in his expert report which says: "The Post Office cash management proposals contained in a report dated 4 August 2017176 suggests that they were actively considering ways to improve processes...

… impacting on many of the issues raised above. It is my opinion that, whilst the Post Office was looking at ways to improve cash management, it is also indicative that the system was generally far from perfect and there existed a real risk of bugs/errors/defects...

… adversely impacting on branch accounts despite the processes in place at the time to prevent this.”

JC has been asked to read a section of the report the above paragraph refers to. He has.

Now he is being read sections of the 4 August PO report by DG (de Garr Robinson).

DG why do you say this document is indicative of "a real risk of bugs/errors/defects adversely impacting on branch accounts”?
JC is looking again at the report.

Thorin waits...

JC cannot explain why he said that. He accepts it is incorrect.

DG you do seem to be looking for problems in documents which don’t support your theory that problems exist. Would you accept this?
JC no it might be an incorrect reference, but in this case…
DG you are citing documents which don’t support your case.
JC I have done here.

DG you have a world view and desire to maximise the impression of an error you uncover. Is that fair?
JC no that’s not fair I thought you were talking about a hypothetical situation

He is taken to another para in his report: "It is clear that in some instances it is not always apparent whether recurring discrepancies were as a result of system bugs or the Subpostmaster’s own actions, or other things beyond the control of the...

… Subpostmaster. However the fact that the SSC support team were unable to assist or identify the root cause does undermine the credibility of Horizon itself.”
[SSC support is Fujitsu 3rd tier support]

DG asks about the footnotes JC quotes in that paragraph and asks if he follows the footnotes we should see something which undermines the credibility of Horizon as described.
JC yes
DG well lets go to the documents in that footnote, shall we?

DG is now reading from the documents JC had referenced. It is a PEAK or KEL written by a Fujitsu engineer about a problem in a branch. It is detailed and appears to be outlining the engineer’s opinion of failings in the branch. Says there is no system problem.

DG now mr coyne what I’d like to suggest to you is that this Fujitsu engineer [Ann Chambers] did a very thorough job of investigating and referring it back to the Post Office having not found a system problem. Why do you say it illustrates a system problem?
JC I think it’s cos...

… later on in the call it was found to be a system problem.
DG it doesn’t say that as far as I can see. The concluding box on the next page says the branch is in a mess and refers it back to the Post Office.

JC what we do see from that is that Ann Chambers is unable to say what has happened. She can’t determine it is the user or the sytem.
DG so let me get this straight… here’s a hypothetical case… the branch is in a mess, they’re misdeclaring stock etc. There is no way SSC...

… can correct those errors.
JC yes
DG so in that scenario SSC cannot discern what is going on
JC accepts
DG I suggest to you that was happening in this case.
JC yes
DG so why say it undermines Horizon?
JC I agree it doesn’t

[we move on to the reliability of Credence - a logging system at the back end at Horizon]
DG on of the themes of your report is that Credence data should NOT be used when deciding whether to issue Transaction Corrections [TC’s]. You think ARQ data should be used?
JC yes

DG takes him to the example of the Helen Rose report [I wrote a story about this report here: postofficetrial.com/2019/03/miscar…]

They are discussing cancellable and non-recoverable transactions in the case of the Subpostmaster referred to in the Helen Rose report. From memory there was a power/reconciliation failure and the Postmaster was being held liable. He felt he wasn’t and got an expert in...

… to prove it.
Credence data must have been involved or DG wouldn’t have brought it up. They are currently discussing the process for data/transaction recovery when something goes wrong.

DG so in that situation, any system is going to have to manage data reconciliation failures.
JC yes. what H does is rather than assume the transaction completes it looks at it to see what happened so it can decide whether or not to roll backwards or roll forward.

More discussion about what should or does happen in these cases. Recoverable transaction flags in databases etc

DG says there has to be a separate investigation as to what the humans did in branch running alongside the failed reconciliation
JC accepts
DG so it might be that a message flashes up on the screen and then the system crashes - SSC or the PO won’t know if cash has...

… changed hands or gone into the till or whatever.
JC yes
DG we go back to the specific case in the Helen Rose report. This was a cancellable transaction. With a cancellable transaction it is removed from the system and becomes a human investigation.
JC yes

DG and that’s what happened in this case
JC well there was a dispute because credence said the Subpostmaster made the transaction, when in fact it was Horizon and this was not clear from the Credence data
DG that’s your considered view?
JC that’s what the Rose report says

DG well let’s have a look at what actually happened, shall we?
[if you want to read the Helen Rose report, it’s very short: scribd.com/document/40237…]
DG is reading from JC’s report paras about the Helen Rose report. [You can read JC’s reports here: postofficetrial.com/2019/06/horizo…]

DG you say "It is therefore relevant to question why Post Office were using Credence data to initially investigate disputed transactions.” are you saying Credence shouldn’t be looked at first?
JC if it’s a cursory look, credence might be okay…
DG continues quoting...

"Observations of the disclosures illustrates that the initial report states "a transaction at 10:42", whereas the credence data file shows 10:32 with the reversal at 10:37. Fujitsu's data states the transactions are at 9:32 and 9:33 and reversal timestamp is 9:37.”
DG you’re...

… suggesting a further problem with Credence here?
JC yes
DG so you’re making the following claims:
1. a receipt wasn’t printed
2. it was both misleading as to who reversed and the time of it
3. and that it put a false loss on the SPM
JC agrees

DG takes him to the Helen Rose report. "On looking at the credence data, it clearly indicates that the reversal was completed by JAR001 (postmaster) at 10:37 04/10/2012 and was reversal indicator 1 (existing reversal) and settled to cash….

… An existing reversal is where the session number/Automated Payment number has to be entered to reverse the item. The fujitsu logs were requested for this branch, but whilst waiting for these to arrive communications took place with Gareth Jenkins at Fujitsu for...

… more details to gain an understanding what had occurred at this branch.”
She infers that the SPM has made the reversal. Mistakenly
JC it doesn’t look like a mistake to me
DG but this is a mistake
JC well it’s a matter for Helen Rose
DG do you accept she could have...

… made a mistake?
JC it’s possible
DG I am suggesting to you she drew an inference from what she saw on credence and did so incorrectly
JC it’s possible

DG one of the claims that you made in your report that there was no disconnected session receipt, but if we look at the data later in the report is says the receipt was generated
JC that’s a receipt about another matter
DG why would Helen Rose be writing about it then?

JC there are two sessions - a session ending in 803 and a session ending in 805…
DG …. yeeees?
[silence]
DG lets’ read the next sentence: "Also row 71 of
Events 4 to 25 Oct 12.xls
shows that a receipt was generated from the session"

DG so it was printed. Your claim about the receipt is wrong because you didn’t read the Helen Rose report properly.
JC no, we’d have to accept certain things here
DG no you clearly say a receipt was generated and it wasn’t
JC accepts
DG so in your anxiety to say a bad thing...

… about Horizon, you read the first bit of the report and didn’t read the end of it.
JC no I was making a distinction about the use of Credence
DG if that was all you were doing we would have done this in five minutes. The problem is you didn’t read the report properly?

JC I agree the receipt was printed.

DG explains to the judge an email from the SPM in question saying he has received the receipts (disclosed 7 March so JC wouldn’t have seen it)

JC doesn’t accept he hasn’t read the report properly and says his point still stands
DG points out one of his points about a system failure does not stand. It was wrong.
JC accepts

DG coming to the next point - timings being wrong in Credence…
the transaction was clearly at 10.37am - the SPM says as much in the email we’ve just seen - this is a typo in the Rose report. I’ll give you an opportunity to correct your error.
JC this was her error or a credence

… error.
DG are you seriously suggesting it is a credence error?
JC time does drift in computer programs
DG are you saying it is an example of why credence is unreliable

DG or is it more likely to be a simple typo?
JC it’s one of those two.
[DG also starts taking him apart on the time difference between Horizon and Credence - Horizon stays in GMT when everyone else goes to BST]

DG you used the Helen Rose report to try extract maximum criticism of the Post Office to support your negative view of Horizon
JC no that’s not fair.

DG notes that JC is perfectly happy to say that things “often” happen if they show Horizon in a bad light, but when there is something shown to be thorough and robust, JC is reluctant to accept it happens regularly.
JC I’m trying to be precise

DG you’re very precise when it comes to Horizon’s strengths, but you generalise very easily when it comes to painting it in a negative light
JC that’s not my intention

DG takes him to JC’s 2nd report: "I consider that Horizon is less robust than as originally expressed in my first report. My primary reasons for this are as follows… c) Post Office do not consult the full audit data before ruling on a …

… discrepancy, instead using third party client reconciliation data or subsections of the audit data from within Credence or HORice.”
DG shouldn’t PO rely on its own management info systems when making decisions?
JC it wasn’t obvious to me - I thought audit data...

... would be consulted.
DG in your first report you say you thought ARQ data was used. In your second report you say back end systems are used eg POLSAP. That’s not ARQ data. Why?
JC not clear on questions
DG in your first report you say there’s a problem as they are using...

… systems PO managements systems. But later you say they’re not. Your position is inconsistent.
JC it’s not in my first report I said the range of management systems and ARQ data should be used in my second report I discovered ARQ data was not used.

DG okay so why not make the point clear in your first report re the use of audit data. In order to be fair.
JC it would perhaps have helped the reader, yes.

DG takes him to 1st report: "In her statement Ms Mather references the number of ARQ requests per year. If it is correct that the contractual limit of 720 per year has never been exceeded except for this litigation...

… , then in my view Post Office is not utilising the audit data sufficiently and certainly is not checking the audit data prior to issuing Transaction Corrections….

…. In 2011/2012 using the figure that Dr Worden produces at his Table 9.3 (section 9.6, page 208) there were 107,584 Transaction Corrections but only a fraction of these were validated by the audit data.”
DG is it your argument that every TC decision should be based on...

… ARQ data?
JC yes
DG but if it costs £200 a time then it would cost £50m a year.
JC yes - now I know the way it works it would.

JC makes the point it doesn’t need to be that complicated or difficult to read.
DG would you accept the closer you get to the raw data the more skills and knowledge needed to read it?
JC yes but it’s not that difficult to extract and make readable.

DG in your first report did you think ARQ data was being extracted and read
JC I thought investigators would be able to read ARQ data when needed
DG if you thought that you would know there was a system for doing that - but instead you assumed all this happened?

JC the purpose of having an audit of what happened at branch counters, someone - PO in this case - should be able to access it. That’s the point of having an audit store. There’s no point in it otherwise.
DG You must have known that the PO was using Management Information Systems

… to make decisions.
JC If you use management info systems to make decisions you have to make a decision on what to exclude and then you are making decisions based on incomplete data.
DG is incredulous that JC thinks PO had access to ARQ data and just assumed it happened.

DG says its a sealed and separate system. It’s completely ridiculous to suggest a sealed and separate system should be cracked open to several times a day to get access to it.
JC calling it “sealed” and having to “crack it open” is misleading. You can write once and read many...

… times.
DG but you never saw any evidence of anyone accessing the ARQ data on the PO side?
JC yes - I realise it was just Fujitsu
DG now you know how the system works, do you accept it would be slow and expensive to do so
JC yes - you have to make decisions on Management...

… Information Systems rather than the audit store.
[we change tack and go back to cost-benefit decision-making which was discussed at length yesterday]
DG asks - when you produced both your reports you looked at whether a risk was reduced “as far as possible”?

JC I think it was in the original Horizon Issues
DG [takes him to the Horizon issues] show me where.

JC the reference - issue 6 “reduced to an extremely low level”
DG so it’s a factual question. It’s not about as low as possible. I put to you that throughout your report you’ve applied the wrong test.

JC well - extremely low level is not defined.
DG but it’s different from as low as possible.
[DG moves on to thoroughness of Fujitsu PEAKs and KELs recording]
DG would you accept it is a well-run system?
JC it’s a decent system
[they move on]

[to report 2]
“At Dr Worden’s paragraph 488 he suggests that serious bugs are rare in the KEL and PEAK records. I agree, they are rare in the KEL records because the purpose of KELs...

… are to inform support personnel how to deal with historic problems, the PEAK’s however do show many serious bugs as I have set out in Section 3 above. Where Dr Worden states at paragraph 489 that I have not identified any bugs, this is untrue.”
DG what do you mean by this?

JC explains
DG are you inferring that a KEL may not be recorded?
JC because a KEL is a single source of a record of a bug error or defect - so it will be referred back if a new error is found.
DG so you’re saying if you get a bug, generally speaking, there will be a KEL...

… which addresses it and that KEL will not be updated if there’s nothing new to see - so that’s what you’re saying?
JC yes
DG so if a bug is detected there will be a KEL? If there are other manifestations it will not necessarily be updated?
JC yes

DG and if the bug manifests itself differently or in an odd way it will generally get recorded in the KEL.
JC yes
DG but if you want to see every manifestation you need to read the PEAK.
JC yes.
DG thanks, that’s very helpful.
[we break fo lunch]

[We’re back!]
DG wants to know about the likely impact on bugs of Horizon and whether they were transient or lasting
JC yes
DG so shouldn’t we settle on a metric for whether or there is a likelihood of doing so
JC I’ve found bugs and looked at their impact

DG don’t you need to set up yardsticks to set up the likelihood of errors causing an impact?
[claimants barrister stands up and says this is re the third report. judge agrees. question is not put to witness]

DG Horizon issues include questions of extent. Likelihood of something happening. Risk high or low
JC agrees
DG so extent and you can assess extent by coming to overall conclusions which are widely useful
JC yes
DG like an exit poll at an election

JC yes
DG you go from a small sample in an exit poll and it gives you a good likelihood of the result
JC yes
DG but to be useful you need to have an unbiased sample. yes?
JC yes

DG there’s no point in only asking people wearing blue rosettes how they voted
JC agrees
DG and that’s the approach Dr Worden has taken with his report
JC yes
DG he’s looked at the PEAKs and KELs and scaled up to make an observation about the reliability of Horizon

JC there are dangers with that, especially when dealing with a very small sample size
DG attempts a statistical analysis point
JC professes no statistical expertise
DG but you doing something similar to Dr Worden aren’t you? You’re drawing an inference from specific examples.

JC but these were from specific bugs - I am not scaling up
DG you say there have been found 29 bugs - have you given an assessment of how many branches were affected?
JC yes we have a column in the second joint statement and some of the source docs will indicated a number.

[We go to JC’s original (not revised) second report. I’m not sure we have this.]

[We don’t.]

Now onto final version of second report: "I have analysed below are a small proportion of the EAKS, from that analysis, I have identified the following as causing financial discrepancies in branch accounts outside of those bugs acknowledged by Post Office... It should be...

… noted there are potentially thousands more PEAKs that illustrate financial discrepancy arising in branch accounts, this is only a small selected sample from keyword searched PEAKs.”
DG you are arguing here that this is a small sample from a large cohort and this...

… should be scaled up.
JC no I’m saying it has potential.
DG could I suggest you are inferring there could be any number of bugs in the cohort you haven’t reviewed
JC that’s why I don’t give a number
DG so you accept you can scale up only if you have a random sample?

JC no cos you’re scaling up from a positive scenario
DG you are saying there is the potential for thousands more bugs
JC the potential, yes
DG you didn’t do this from a random sample though - so you were positively searching for bugs and then you infer there are thousands more.

[this is a massive battleground - JC has gone looking for real bugs, Dr W has looked at likelihood]
DG can we agree you looked at an biased sample from which you cannot scale up?
JC you wouldn’t want to make any numerical assumptions
DG why say thousands then?

DG it seems to me you are inviting the court to infer that having found 29 bugs you want the court to think there might be thousands out there, rather than dozens
JC it is the most appropriate way
DG are you saying its likely there are thousands more bugs?
JC no

DG are you saying it’s more likely there are thousands rather than hundreds or dozens?
JC I think it’s more likely there will be thousands more than dozens
DG are you saying its not impossible?
JC its not impossible in that there are 200,000 PEAKS that haven’t been reviewed.

JC they didn’t respond to the search terms we put in
DG but you told me you and your team are experts in searching. it’s the raison d’etre of your e-disclosure business. Isn’t the fact you’ve only been able to find 29 bugs significant?
JC no - usually I would be assisted...

… by someone from within the organisation who would help me with error codes which may indicate a discrepancy. I didn’t get any of that so I was starting from scratch.
DG but I presume by the phrase such as “intelligent” search the more you try and the more results you get...

… your searching becomes better. Isn’t that how it works.
JC yes. One of the docs I requested early on was a doc when a financial impact has been discovered and it simply wasn’t provided.
DG why make this point
JC because that would have assisted with my search

DG what document is this
JC it was an RFI request made in June or July last year - we wanted to know what codes which show a financial shortfall.
DG let’s not get bogged down. you have found 29 bugs which you think SPMs were made liable. So you’ve seen how PEAKS and KELS...

… relating to those bugs were identified. So you have not been prevented from finding more.
JC the process would have been far easier if I had received the docs I was asking for at the time.
DG let’s not talk about process. Let’s talk about what you’ve done. Let’s assume...

… you became brilliant at searching. you would find all the problems in the PEAKS and KELS.
JC maybe
DG if you’ve only been able to find 29 bugs it’s really unlikely there are hundreds of thousands of bugs you just haven’t been able to find. You’re not that incompetent.

JC I don’t think its inconceivable that that might be the case
DG not likely though is it?
JC it would be a complete guess
DG yes.

DG let’s go to p87 of today’s transcript. You say that generally speaking if you get a bug of that sort there will be a KEL that addresses it.
DG do you withdraw that?
JC no
DG so if a bug has been detected it’s likely to be described in a KEL
JC if it’s been detected, yes.

DG now at the time of your first report you’d looked at 5000+ KELs plus those from members of your team
JC yes
DG and since your first report you would have looked at further KELs
JC yes
DG so you’ve looked at… more than 6K?
JC between 5 and 6,000
DG and your team?
JC about...

JC… a 1000 more.
DG so you’ve looked closely at around 7000 KELs and you’ve found 29 bugs. So the chances are the total number of bugs in the entire cohort of KELS isn’t likely to be thousands, is it?
JC not that have an impact on branch accounts
DG so wouldn’t it be fair...

… to infer the total number of bugs in the cohort available is less than 40.
JC yes that’s fair, but I’m worried we’re confusing PEAKS and KELs.
DG okay let’s take this in stages. 1 how many bugs and 2 what’s their impact. Both important to arrive at extent. You have agreed...

… there are likely to be more than 40 bugs that will have an impact on branch accounts
JC bugs, errors and defects, yes
DG so let’s move on to the issue of PEAKs and KELs. You can identify the relevant KELS and search for the PEAKS which refer to the KELS? Yes?
JC yes

DG so you ID 29 bugs, you do your searches for all the PEAKS and can find all the PEAKS which likely ID all those which refer to all the manifestations of the bug.
JC yes once they get to Fujitsu
DG so by this means you are in a position to ID bugs in the system?
JC as long...

… as they hit the search terms.
DG but these are ones you’ve physically reviewed, you don’t need intelligent search for these.
JC accepts
DG so you could find from reviewing your docs most or a large number of the bugs Fujitsu identified.

JC yes
DG And you would also have the FAD code listed on each KEL.
JC not necessarily - sometimes it says the name of the branch or just that branch accounts might be affected.
DG okay let’s park that for now.

DG you told me you had done some work on how many branches have been affected. where is that?
JC look at joint statement 2… [he takes him to it]
DG hasn’t seen this and says it’s very helpful. Also points out the numbers seem very low in comparison

… to the number of branch accounts. eg a bug which hits 60 branch accounts against 30m monthly accounts [all branches x all monthly accounts x all the time Horizon has been in existence?] is a very low hit rate
JC yup

DG why make a claim there could be potentially thousands more PEAKs when that doesn’t really stack up with the evidence?
JC is now looking through his table of impacts
J asks if DG wants JC to do more sums
DG no I just want him to accept that it is nowhere near...

…. “thousands” of PEAKS
JC I am content with up to a 1000 being correct as you only need to find a few more PEAKS
DG this is an example of evasion. You said “thousands” in your report. Now you are saying “up to a thousand”. Do you accept your “thousands” is wrong?
JC no...

… I stand by it.
DG well I’m not sure where I can go with this from here. Let’s find another example of your language.

…

DG takes him to: "Many Known Error Logs (KELs) identify that not all errors were understood even by Fujitsu. In the circumstances, it is highly unlikely that a Subpostmaster...

…. could interpret or identify the causes of any bugs/errors or defects when Fujistsu themselves often did not understand the cause of such or their full effects.”
DG what do you mean by “many” and “often”?
JC I mean “a number"

DG moves on: "I have noted that hardware replacement often seemed to be a “fix” of last resort where no other explanation could be given, and therefore there is certainly a possibility that hardware was at fault.”
DG what do you mean by “often”?

DG given you are extrapolating from one example?
JC there are a number of other examples - eg the phantom transaction example. There are a number, but there’s only one cited here.
DG how many examples? 5 or 100.
JC there will be 5
DG so often means “5” there does it?
JC yes.

DG moves on: "Whilst both Horizon and Horizon Online contain many measures and controls for ensuring system integrity, these mechanisms do/have failed. It has been identified that known issues/bugs were often deferred and dealt with on a cost/benefit basis.”
DG no scale here...

… what do you mean by "often”?
JC quite a few times
DG a handful, I think when we discussed it yesterday? What’s the number of cases
JC the number contained in that document in the footnote.
DG thank you - I’ll look at that later.

DG takes him to the second report: "For example, it appears that PEAKs are often closed or suggested to be closed if analysis has paused or has not uncovered a full diagnosis despite the Subpostmaster and/or Post Office not having a conclusion….

… It is also not always clear whether a Subpostmaster was informed... I have seen PEAK records that are closed despite support not being able to diagnose a root cause whilst acknowledging that there clearly is some form of error occurring within the Horizon system."

DG now WBD wrote to Freeths and asked how many were being referred to here and the answer back was 9. Were you aware of those 9 there have been only two examples since 2002? So over the past 17 years it’s happened twice. Could you not have indicated this was the case?
JC accepts

DG goes to "At paragraphs 251 to 257 of his report, Dr Worden refers to the concept of “User Error Correction” enabling the facility of correcting many software errors. It should be noted that this would not apply to any bugs...

… /errors and defects unbeknownst to Fujitsu or the Subposmaster. It is evident from the PEAK analysis that often bugs lay undetected for weeks, months or years.”
DG WBD wrote to Freeths and asked which PEAKS showed this. The reply was to refer us to your supplementary report.

DG so we did and it appears there are 4. No other reference. How many other bugs lay undetected for weeks/months or years?
JC Dalmellington?
DG yes…?

JC don’t know I’d have to go through…
DG 1? 4? 10? By using the word “often” it suggests you had a clear idea in your head. Can you give me an idea approximately?
JC no.

[we were on a break. back now]

DG I’d like to suggest to you that ultimately the main number in this case is the impact of bugs in H. Agree?
JC yes
DG you haven’t addressed this at all in your reports
JC the amount of money? no
DG you could have done.

JC I could add up the numbers in the PEAKs.
DG I would suggest that if you did do that exercise you wouldn’t find a number which remotely supports the claimants’ case?
J is this a general question or one in relation to Horizon
DG both
J well you can’t do the former

DG but my expert has a case and I want to put it to this expert
J I’m not saying you can’t ask the question you just have to relate to Horizon
DG I want to put my case to the witness
[J and DG are arguing the toss here. I can only see one winner in this…]
J asks witness to leave

[they continue]
DG wants to take the witness to an area of Dr Worden’s report where he says the total amount of money bugs have cost SPMs £40,000 (not the millions claimed).
J is explaining he can put this question but he must phrase it in relation to his work on the Horizon...

… issues which he was contracted to do the work on.
Patrick Green (claimants’ QC) has got involved on a separate issue. J reasserting control of the situation. Witness returns.
DG takes him to Horizon issues. “I can take any of them but I’d like you to look at Horizon issue 1"

DG it is asking experts to look at the likelihood of bugs impacting branch accounts. One of those ways which MIGHT be helpful in the context of this case is whether or not the bugs would have anything like the amount the claimants are claiming?
JC I don’t think I understand...

… your question.
DG H1 asks the experts to look at the extent of impact. And one useful yardstick might be to measure the financial impact against the claims made by the claimants financially.

JC I can see how it might be one of the contenders yes.
DG now you know that Dr Worden looked at extent in this kind of way
JC yes
DG he was going to look at the assertions being made by the claimants. but you didn’t
JC correct
DG you could have done that, but you didn’t...

… you could have used your skills to measure.
JC we will often see a bug error or defect with a range of impacts. Typically whatever that counter was doing at the time - so if the counter was doing foreign currency transaction for £50 - you get a £50 discrepancy...

… once you know there is adefect, you can’t say all the defects will be £50. If there was a bug on foreign currency and the transaction was £10K it could be £10K value.
DG you could estimate?
JC it’s a fundamentally flawed approach - you can’t scale it up.

DG you could form an estimate
JC yes you can, but the only way to do it is to use the known info, not the unknown info [I’m horribly paraphrasing here]
DG would you accept the evidence indicates of 3 bugs [he is referring to] is no more than £100,000
JC no I haven’t done...

… the sums.
DG but knowing what you do know about the way it was dealt with by Fujitsu - you could come to a reasonable esitmate?
JC no
DG do you have any evidence it was more than £100K?
JC well in Dalmellington there was one which was £25K and we don’t know what happened...

DG … sorry you don’t know what happened?
JC in two of them
DG well for 114 of them it was sorted completely. so the lasting impact was zero
JC yes
DG in the remaining four branches, two were just a few pounds and pennies

JC yes
DG so let’s look at the two we don’t know what happened. Are you suggesting that it wasn’t fixed?
JC no
DG so the overwhelming likelihood is that all affected branches had no lasting effects. It was picked up by the system. It was fixed.

JC agrees once everything was detected, everything was made good.
DG and so Dalmellington is a good example of how countermeasures in the system were correcting the bug
JC yes but there were deficiencies with the countermeasures as it took 5 years to pick up.

DG going back to these three bugs do you think Callendar Square, Receipts payments mismatch and Dalmellington were less than £100K
JC don’t know
DG well - do you have any evidence is was more?
JC don’t know
DG any idea how it could be?
JC don’t know
DG is Dr Worden wrong?

DG in his methodology?
JC I know how he’s gone about it and I don’t think his maths would be wrong.
DG taking these three bugs, the ones we know most about, the likelihood is that they affected branches by £100K. a tiny fraction of the £19m claimed by the claimants.

JC yes
DG you have reined back on your assertion there were potentially thousands of bugs undetected to a number much less than that. Up to 40?
JC based on the earlier methodology we discussed.
DG which you accepted. Do you accept there is no way the branch impact is anything...

… what is being claimed.
JC demurs
DG okay let’s try to take another route to scale up this likelihood.
[they do so in reference to some complex methodology in Dr Worden’s report which I don’t have]

JC we see from bugs that are reported that bugs appear to impact branches differently and a number of times
DG are you aware of some special factor which marks the claimant branches out as being different from the wider network
JC I don’t. No, you’d have to do an assessment...

… of each branch. as we saw with Dalmellington when one branch got done 5 times.
DG please be careful not to confuse with the particular from the law of averages. Is there any factor in the claimants’ branches that gives them a significant feature which makes them...

… different from other branches in the network.
JC I’m not no, but you need to be careful that you’re not drawing conclusions with the wrong information
DG Dr W has concluded that the claimant branches are on average smaller than most branches in the network. Fewer transactions.

[DG takes JC to Dr W’s report which I can’t see. Starts talking about the maths and transactions I can’t see]

DG when it comes to the calculation set out by Dr Worden. On the basis of the evidence we have in relation to the claimant branches, there are no flaws in Dr W’s methodology are there?
JC no
[can’t see this so have no idea what they’re talking about but the number 0.37 has been..

… mentioned. Shorn of context, entirely meaningless.]

Dr W’s second report factors up the 0.37 of meaninglessness to 0.45.

DG is that better methodology?
JC better than before, yes?
DG so actually on that logic a claimant branch is actually LESS likely to be hit by a bug because it does fewer transactions.
JC no

DG if you go outside you are more likely to be hit by lightning than if you stay indoors
JC it’s about the types of transaction
DG if there were a feature that marked out claimant branches don’t you think we would have it now?
JC I didn’t do the work. someone else might

DG you’re being an armchair critic of Dr W
JC no I have a problem with the inputs, not the maths.
[we move on]

DG let’s assume that bugs don’t affect branches equally. I assume you’re not saying claimant branches are 100x more likely to be hit by bugs
JC no all I’m saying of the bugs I’ve studied do not seem to hit branches equally
DG but i’m suggesting you don’t say it’s...

… theoretically possible some branch is more likely to be susceptible to a bug
JC the way I would approach this is possibly the way Fujitsu did when they investigated Dalmellington for example. They found some branches were affected multiple times...

… so I’d look at the business practices in those branches which might help us understand how and why it would affect those branches and why others not at all.
DG that would be understandable for one bug, but we’re not talking about that. We’re talking about lots of branches...

… lots of bugs and lots of different scenarios. Where you have to scale up and make an assessment.
JC I wouldn’t feel comfortable doing that.
DG but you would do it in a business scenario
JC that’s different,
DG but you accept its possible to do and that’s what Dr W has done.

DG goes to Dr W’s assessment which says there needs to be 1000s of bugs out in the estate to justify the claimants claims of £19m
JC all I am doing is confirming Dr W’s maths. Not the process
DG you don’t accept the process because you want to say there’s a process you...

… haven’t identified that makes the claimant branches so suscpetible to bugs they have lost £19m
DG do you have ANY evidence there are bugs of the scale of thousands in Horizon? You don’t do you
JC there is the potential
DG the overwhelming likelihood is there are no more...

… than 40 bugs.
JC yes, but they could have multiple affects
DG their total impact would have to be vast - in the tens and tens of millions
JC if they affected people equally
DG oh so you’re now saying that bugs could only affect certain branches
JC yes because we know that’s...

… happened.
DG so are you really suggesting its possible there might be such a bug which you haven’t identified
JC well haven’t been given the information to identify
DG okay are you saying there is a bug unidentified which will have a substantially greater impact...

… than ones which HAVE been identified?
JC there are bugs which have impacted many branches. What if there is another dalmellington which affected 88 branches
DG we already agreed that had no lasting impact.
JC so far you have ID’d 29 bugs. you say there are unlikely to be...

… more than 40. Are you now saying these bugs could cause £19m of losses which could only impact the claimant branches and not the wider network. So it could have impacted the wider branch network or just the claimant branches.

[xe ends]

We’re on to housekeeping. J wants DG to agree with claimants a finish time to his xe on Friday afternoon to allow re-examination of JC by Patrick Green.

If you liked these tweets and haven’t already done so, please chuck a couple of quid in the tip jar at postofficetrial.com - it’s a paypal thing (but cards are accepted!)
I’ll get these tweets unrolled and a report up tonight, plus a secret email for subscribers!

Thanks for the retweets and comments and all that. We’re back at 10.30am tomorrow for more JC v DG. Cheers.

@threadreaderapp unroll pls