JC has been asked to read a section of the report the above paragraph refers to. He has.
JC is looking again at the report.
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.
JC no that’s not fair I thought you were talking about a hypothetical situation
[SSC support is Fujitsu 3rd tier support]
DG well lets go to the documents in that footnote, shall we?
JC I think it’s cos...
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.
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...
DG so in that scenario SSC cannot discern what is going on
DG I suggest to you that was happening in this case.
DG so why say it undermines Horizon?
JC I agree it doesn’t
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?
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.
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.
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...
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 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
JC if it’s a cursory look, credence might be okay…
DG continues quoting...
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
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...
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
JC that’s a receipt about another matter
DG why would Helen Rose be writing about it then?
DG …. yeeees?
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"
JC no, we’d have to accept certain things here
DG no you clearly say a receipt was generated and it wasn’t
DG so in your anxiety to say a bad thing...
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?
DG points out one of his points about a system failure does not stand. It was wrong.
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
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
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]
JC no that’s not fair.
JC I’m trying to be precise
JC that’s not my intention
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...
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...
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.
JC it would perhaps have helped the reader, yes.
DG is it your argument that every TC decision should be based on...
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.
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.
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?
DG You must have known that the PO was using Management Information Systems
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.
JC calling it “sealed” and having to “crack it open” is misleading. You can write once and read many...
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...
[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”?
DG [takes him to the Horizon issues] show me where.
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.
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]
“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...
DG what do you mean by this?
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...
DG so if a bug is detected there will be a KEL? If there are other manifestations it will not necessarily be updated?
DG but if you want to see every manifestation you need to read the PEAK.
DG thanks, that’s very helpful.
[we break fo lunch]
DG wants to know about the likely impact on bugs of Horizon and whether they were transient or lasting
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
[claimants barrister stands up and says this is re the third report. judge agrees. question is not put to witness]
DG so extent and you can assess extent by coming to overall conclusions which are widely useful
DG like an exit poll at an election
DG you go from a small sample in an exit poll and it gives you a good likelihood of the result
DG but to be useful you need to have an unbiased sample. yes?
DG and that’s the approach Dr Worden has taken with his report
DG he’s looked at the PEAKs and KELs and scaled up to make an observation about the reliability of Horizon
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.
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.
DG you are arguing here that this is a small sample from a large cohort and this...
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?
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.
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?
JC it is the most appropriate way
DG are you saying its likely there are thousands more bugs?
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.
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...
DG but I presume by the phrase such as “intelligent” search the more you try and the more results you get...
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
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...
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...
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.
DG not likely though is it?
JC it would be a complete guess
DG do you withdraw that?
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 and since your first report you would have looked at further KELs
DG so you’ve looked at… more than 6K?
JC between 5 and 6,000
DG and your team?
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...
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...
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 once they get to Fujitsu
DG so by this means you are in a position to ID bugs in the system?
JC as long...
DG but these are ones you’ve physically reviewed, you don’t need intelligent search for these.
DG so you could find from reviewing your docs most or a large number of the bugs Fujitsu identified.
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.
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
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...
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?
DG well I’m not sure where I can go with this from here. Let’s find another example of your language.
DG what do you mean by “many” and “often”?
JC I mean “a number"
DG what do you mean by “often”?
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?
DG no scale here...
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 WBD wrote to Freeths and asked which PEAKS showed this. The reply was to refer us to your supplementary report.
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?
DG I’d like to suggest to you that ultimately the main number in this case is the impact of bugs in H. Agree?
DG you haven’t addressed this at all in your reports
JC the amount of money? no
DG you could have done.
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
J well you can’t do the former
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
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...
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"
JC I don’t think I understand...
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.
DG now you know that Dr Worden looked at extent in this kind of way
DG he was going to look at the assertions being made by the claimants. but you didn’t
DG you could have done that, but you didn’t...
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...
DG you could estimate?
JC it’s a fundamentally flawed approach - you can’t scale it up.
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...
DG but knowing what you do know about the way it was dealt with by Fujitsu - you could come to a reasonable esitmate?
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...
JC in two of them
DG well for 114 of them it was sorted completely. so the lasting impact was zero
DG in the remaining four branches, two were just a few pounds and pennies
DG so let’s look at the two we don’t know what happened. Are you suggesting that it wasn’t fixed?
DG so the overwhelming likelihood is that all affected branches had no lasting effects. It was picked up by the system. It was fixed.
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.
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?
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.
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...
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]
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...
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...
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.
[can’t see this so have no idea what they’re talking about but the number 0.37 has been..
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 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
JC no I have a problem with the inputs, not the maths.
[we move on]
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...
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...
DG that would be understandable for one bug, but we’re not talking about that. We’re talking about lots of branches...
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.
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...
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...
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...
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...
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...
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.
I’ll get these tweets unrolled and a report up tonight, plus a secret email for subscribers!