Thread by @nickwallis

Morning. Day 17 of the Horizon trial, part of the Bates v Post Office litigation (more info: postofficetrial.com). Last day of cross-examination for expert IT witness Jason Coyne, pictured arriving with a member of Freeths, the claimants’ legal team. Live tweets follow.

Judge starts by handing down judgment number 5 - reasons for decision on awarding costs to claimants re Common Issues trial and refusal to give permission to Post Office to appeal CI judgment.
I have a paper copy and will get an email copy later. I’ll post it up at lunchtime.

Just my regular warning that what I am tweeting is a description and/or summary of what is happening and being said in court. Nothing is a direct quote unless it is in “direct quotes”.

We are currently having a discussion about Mr Coyne’s “homework” and the expectations thereof. The references Mr Coyne has drawn are not going to be discussed in open court as the defendants are not in a position to challenge them.

There is a decision to be left with the judge about whether or not he should see them. Mr de Garr Robinson (DG) for the Post Office says no. Mr Patrick Green for the claimants says yes. Judge is not making a decision now and hands the floor back to DG to re-start his xe of...

Jason Coyne (JC).

[We start with a document I can’t see. I will try to pick up the gist…!]

DG starts with and apology and a correction to an assertion he made yesterday about PO adopting an auditor recommendation. He reads out the section of the auditor report he overlooked.
JC points out there are parts in the report where PO decides not to adopt auditor recs...

… and do something else instead.
DG says this is part of the normal back and forth between auditors and their clients
JC accepts
DG focuses on JCs crit of failure to adopt certain recs and asks if that crit is fair - when there is a great degree...

… of evidence that the PO was doing a lot of work on other recommendations that JC chose to leave out of his report.
JC says he thinks it is.
[we move on]

[to the 29 bugs which caused a financial impact on branches]
DG is that it?
JC yes
DG the fact I can only touch on a limited number relies on you summarising documents accurately and explaining them fairly, yes?
JC yes

[we go to bug 15 p13 - phantom transactions]

DG you have two phantom transaction bug reports listed from 2000 and 2001. Am I right in thinking therefore it hasn’t raised its ugly head for 18 years?
JC yes.

[DG is reading from a PEAK report about the bug dated 9 Aug 2000]

DG from the size of the amounts involved in this we can see SPMs are happy to phone in about relatively small amounts of money

JC yes [I can’t see this doc and the sum of money has not been said in open court]

[DG reads from Fujitsu support diagnosis which is that the SPM must have hit suspend accidentally]
DG these transactions were typed into Horizon - they didn’t appear out of nowhere. And they were committed to the system by the SPM accidentally touching the button

JC no I was saying that the system was automatically committing something to the basked
DG are you suggesting that the system is doing something wrong?
JC yes
[they go to Angela van den Bogerd’s witness statement - JC is asked to read it to himself]

[it is par 14.2 p4, I have published this statement here: postofficetrial.com/2019/03/horizo…]
DG this is not Horizon going wrong. this is Horizon doing what it is supposed to do
JC it’s not what the user wanted it to do
DG it’s a standard design in any system
JC yes but it should not...

… complete a transaction when the SPM is not present.
DG it produces a receipt and then the SPM can either reverse it or dispute it.
JC yes

DG you knew that when you called this PEAK a phantom transaction bug in your second report, didn’t you?
JC no I don’t believe I did
DG well let’s have a look...

DG look in your report - under the heading Angela Margaret van den Bogerd you describe her evidence as it relates to phantom transactions.
JC yes
DG so you did know what AvdB was saying because you responded directly to her evidence. It’s completely wrong, isn’t it mr coyne

JC well - it appears to be a design feature.
DG you’re being evasive. you called this evidence of phantom transactions and yet your example is wrong
JC yes it’s operating in line with design, but I could see why a user might get confused

DG we’re not looking at a table called “where users get confused”. we’re talking about bugs in Horizon. And it’s not. Are we now agreed this is not a bug
JC agree
DG so why did you decide it was one of the 29 bugs when its not. did you not read it properly?
JC i did read it...

… properly. But perhaps not in regard to AvdB’s witness statement.
DG yep you were looking for bugs, you thought you’d found a bug and without doing the work you included it. Would it be fair for an outsider to think you were trying to state bugs, irrespective of the truth?

JC accepts he did not check the references completely
[DG goes to the other citation in support of phantom transactions…]

[It is an example from 19 June 2001 about dodgy peripherals (eg sticky or misaligned touch screens) causing phantom transactions]

[this PEAK refers to a problem dealt with by ROMEC the Royal Mail electricians who fixed or installed a lot of Horizon kit back in the day.]

DG reads from report of ROMEC engineer flagging phantom transactions he has witnessed - logs system off, fits some suppressors, switches system back on again and witnesses phantom transactions. Now we have no idea what he saw, do we?
JC no we don’t

DG it is entirely possible that the terminal might have been sitting there with a load of uncompleted transactions with it and then watched as a load of them were completed? and not known what he was seeing.
JC it’s possible.

DG so he may have seen something that was Horizon operating as it should and misinterpreted it.
JC yes if you look at his visit in isolation
DG there were further investigations for some months. Fitted suppressors to the kit and SPM is still having problems - referred to...

… someone senior at Fujitsu called Patrick Carroll. Some months later PC writes that all the problems are user error and closes the peak as no fault in product.
DG given his experience and the info available to him, and given this problem has not reappeared since 2001 - would...

… it be fair to say the best judgement to trust in this situation is Mr Carroll’s judgment.
JC certainly he’d be in the best position. No reference to ARQ data in that log which if they’d done that investigation they would know what had happened.
DG nonetheless do you think...

… when compiling your expert report it would have been helpful to include Mr Carroll’s conclusion.
JC well the document is there with his conclusion in it
DG but you can’t read all the documents you refer to. Wouldn’t it be helpful given we’re all relying on your report...

… for a fair summation of the document. Do you not think it would be fair to include his conclusions.
JC I accept it would be an enhancement to the report.
DG why not try to avoid stopping when you’ve mentioned the bad points. Why not mention some good points as well. Fair?

JC yes.
DG throughout your reports you look for the bad and ignore the good
JC that’s not fair. it is in this example, but it’s not fair generally.
DG do you accept in this instance, that you are in a position to say Mr Carroll was wrong
JC no
DG indeed. none of us are.

JC but it was reported by an SPM, confirmed by an engineer with no evidence that Pat Carroll looked at the ARQ data, so we don’t know what happened.

[we move on]
DG could you explain what Girobank transactions are?
JC i need to go back to my report
DG you don’t remember? that’s fair. It’s impossible to remember eveything every single time. By all means go back to your report…
[JC is reading his report]

JC it’s about the timing of the aspect of the process of Girobank transaction
DG and a GB transaction is?
JC similar to a banking transaction
DG would it be fair to say you’re not very familiar with them?
JC I’m trying to recall...

DG says there are PEAKS and KELS related to Girobank problems of this sort, but they stop in 2001
JC yes

[Anne Chambers comes up again. You do have to wonder why Gareth Jenkins and/or Anne Chambers weren’t put forward or called as witnesses in this trial.]

DG notes JC’s report says the Girobank problems are clear examples of bugs in Horizon causing discrepancies in branch accounts…
JC not just in that table
DG but it’s your expert opinion that PEAK f118 is a clear example of a bug causing a discrepancy
JC that one doesn’t...

… but others do.
DG well you are specifically saying these PEAKS and KELS demonstrate a bug
JC if you look at the previous page
DG no - let’s look at PEAK f118
JC okay that one doesn’t necessarily include a discrepancy
DG but you have written that all these PEAKS clearly...

… show a discrepancy. Are you now saying this one doesn’t?
JC explains why the list of PEAKS ordered the way they are
DG Mr Coyne this is amazing, I can’t believe I’m having this discussion. When you say the PEAKS above show bugs, are you telling me that’s not what you mean?

JC explains that the PEAKS listed are associated to the PEAKS which do demonstrate bugs
DG I see. Why include it in your report at all. What’s the point?
JC because many of the PEAKS with bugs in relate to the KEL “Anne Chambers” so these are PEAKS related to that search.

DG so f118 isn’t a bug at all then?
JC I’ve described it here as a cut off issue, branch unknown. so it likely isn’t
DG could you remind the court what a cut off is
JC it’s after a certain time in the evening. anything after is included in the next day
DG cut off to whom?

JC Girobank?
DG yes so what has happened here is that the SPM made a transaction, couldn’t see it, wondered where it was, called the helpline, Fujitsu had a look (I think it was Mr Roll - yes it was) - and found he was looking at the wrong report. So it wasn’t a bug at all.

JC no but it contains a reference to a bug which is why I included it, but it’s in a different table.
DG forgive me Mr Coyne - speaking as someone who has read your report over a number of deathless hours (as one could say about all the reports submitted in this case)…

… you list these PEAKs as if they were evidence of a fault.
JC yes I accept this is NOT evidence of a bug but I think you read my report wrongly. I’ve clearly stated what it is.
DG I see.
[ we move on ]

[we are now looking at another example of what JC has listed as a bug. DG reads him the PEAK.]
DG can we agree there was a fault in Horizon which went to Girobank NOT a fault in branch accounts. In the PEAk the SPM can’t see a problem.
JC but ANY discrepancy can affect branch...

… accounts.
DG but not in branch accounts. in this case.
JC the support guys call it a discrepancy
DG yes. but not in branch accounts? is it?
JC i struggle to understand why that wouldn’t be the case.

JC if this fault hadn’t been reported it would have likely resulted in a TC>
DG well, that’s my point. it was spotted. It was corrected before it caused a problem in branch accounts. These are effective countermeasures. Horizon is working as it should.
JC yes but it’s a bit...

… obvious we only see PEAKS, so when things are spotted. We don’t know how many times it doesn’t get spotted.
DG you’re not suggesting that if this happened there wouldn’t be an investigation. Fujitsu and the Post Office have elaborate systems to do that.
DG what we are seeing..

… in this instance is Horizon working exactly how it should yes?
JC yes.

DG do you not think this is an example of lots of data going through lots of systems with lots of people watching it and when it gets picked up it gets fixed.
JC yes but it was only picked up by Girobank. It flew through Horizon without getting stopped and it only got picked up

… by Girobank, which means the Girobank systems were good, but Horizon should have picked it up before it even left the system.
[we have a break]

I’m just having a brief flick through judgment number 5. It is ONLY the reasons behind the decision for the common issues trial costs (90/10 in favour of claimants - Post Office to pay 5.5m). It does NOT include reasons for refusing permission to appeal the CI judgment.

If you are new to all this, this Horizon trial I’m tweeting now is the second trial in this litigation. The Common Issues trial was the first trial and you can read all about that here: postofficetrial.com/2019/01/common…
The Post Office lost that one badly. This one seems much more even.

I say “seems” because I am only forming an impressionistic view from what I’m hearing and seeing in court. At the time I thought the claimants had just shaded the Common Issues trial. They ended up beating the PO hands down in almost all areas.

Moral: don’t make predictions. Okay we’re back for second session of the morning. DG is taking JC through yet another PEAK. A PEAK is a log of an occurence of an error. A KEL is a knowledge bank of related errors. We’ve heard a lot about them this week.

DG reading out Fujitsu support staff describing a problem which had been fixed generating daily reports, not branch accounts. Agree?
JC yes
DG to the extent there is a bug at all. it’s not a bug which causes discrepancies in branch accounts.
JC no it does it in branch reports.

DG and where it does occur it will be picked up and investigated.
JC where there is a PEAK it shows it has been investigated
DG the operation of the system is in itself a robustness countermeasure. do yo agree?
JC they have a support process which attempts to fix problems. yes.

DG which increases the overall robustness of Horizon
JC yes
DG it doesn’t show a bug causing discrepancies in branch accounts. It shows people correcting them.

JC we don’t know which branch we relates to
DG you cite this PEAK as evidence of a bug causing dicrepancies in branch accounts, but this PEAK and the one which preceded it that it didn’t create discrepancies in branch accounts yes?
JC it could have done
DG but it didn't

JC accepts
DG you’re suggesting this countermeasure which involves human beings sometimes isn’t perfect - very rarely - isn’t perfect. No one is suggesting it is perfect. But it is a countermeasure which INCREASES robustness. And both PEAKS we’ve seen today INCREASE...

… Horizon robustness. Not detract from them. Do you agree?
JC these PEAKS are a good example
DG and you think Fujistu support is on the whole good?
JC yes, but there are weaknesses. Illustrated here - there isn’t a branch code.
DG if this PEAK were generated in order to...

… 20 years down the line satisfy a judge in court Iwould agree. But this is a working document. Agree?
JC yes, but this PEAK is very dependent on the KEL which describes the flaw. Which hasn’t been disclosed, so we don’t know.
DG you’re not grappling with the central point.

… looking at all the evidence that this does not point to a bug causing a discrepancy in branch accounts. Not this one or the one before.
JC agrees.

DG so why include them in your bug list
JC you need to read them in the wider context of the report.

[we’ve been going round in circles for a bit]

[okay we’ve alighted on another PEAK]
DG do you confirm this is something you have listed as an example of a bug causing a discrepancy in branch accounts?
JC yes

DG reads out an example of an SPM doing something which causes him to re-enter transactions. Support cancels the transactions and the call is closed. Why is this a bug?
JC cos a false report was generated
DG but the bug did not cause a discrepancy in branch accounts
JC no the bug

… caused the false report which led to him putting the wrong transactions in.
DG it’s not that the system made a false report. The SPM just looked at the wrong report.
JC but Fujitsu engineer in this PEAK linked it to the Girobank error KEL
DG look at the words in front of you

DG this was a relief SPM had printed a report which CORRECTLY repped the position and then entered transactions, then looked at the report and did it again.
JC if that was right, why would Fujitsu engineer reference the KEL for that defect
DG it’s plain from the language used

… that this was human error. Not a Horizon error.

JC well why include a reference to this Girobank KEL if it wasn’t part of his consideration.
[they move on to Bug 20 - recovery failures]

In his second report, JC writes: "PC019764397 created 14 April 2010 refers to branch 166948 in which a £240.00 transaction failed in recovery. Whilst a table exists in the database to potentially capture failed recovery transactions, these then have to be manually...

… reconciled. The PEAK states:
“Looking at the PostOfficeCounterLog, the receipt printed ok for this after authorisation was received, the receipt that printed for the cash withdrawel [sic] states "Authorised", so it's possible that the clerk handed
over the monney [sic].”

He continues: "As this was passed to Post Office, it is unclear what their final resolution was. It is not documented if Fujitsu removed the transaction and if they did, how they did it."

DG notes all recovery failures are reported to the MSU and pass it on to SSC (Fujitsu support) to look into it. yes?
JC yes I don’t know how this is triggered.
DG sometimes it is from the SPM, sometimes is comes from the MSU. Fair?
JC yes

DG has taken him to a KEL related to the PEAK JC was referring to.
This problem would always be evident to Fujitsu AND the Subpostmaster is they would see the error message.
JC agrees if the screen was working after this failure they would see the error message.

DG so Fujitsu would be aware too.
J intervenes to note the KEL being referred to is not the PEAK JC was quoting in his report.
DG says yes and explains why, but puts his explanation to JC
JC accepts that explanation and extrapolates and everyone agrees there is a logical reason.

[which would take too long to explain here, but you can read it in the transcript tonight]
[DG goes back to the issue under consideration - recovery errors.]
DG just to confirm, the way H has always worked, whilst you are putting a transaction into a counter - all sorts of info

… is going to various places - legacy Horizon is the branch data centre, in Horizon online it goes to the centralised BRDB etc etc
JC yes
DG and this is a good and useful thing because this means if there is a counter failure there are copies
DG if there is a crash...

… nothing gets lost.
JC well, info could get lost along the way to the BRDB
DG any examples of that?
JC no but comms errors have led to situations arising and that is seen in recovery
DG but invariably, perhaps universally they are towards the end of the transaction?

JC yes that’s fair - there is a time when you are past the point of no return and then you have to sort it out
DG but where you have a recovery scenario there will always be data that needs to be recovered.
JC yes
DG yes so in recovery failures there will be data in the tables

JC yes because recoveries happen because something has gone wrong in branch it’s quite possible whatever went wrong is still going wrong when recovery is being attempted.
DG any system of this sort is going to have recovery situations. you can never guarantee you won’t have ...

… a recovery situation. Which could fail.
JC by design you HAVE to have this process. if it is designed well the VAST majority of recovery situations should be automated.
DG we can agree it should work well. would you accept the fact there have been a lot of recovery failures...

… over the years are not necessarily a sign of a problem.
JC it is axiomatically a problem
DG sorry I didn’t ask the question properly - it’s inevitable there will be a small proportion of cases where automatic recovery doesn’t work
JC yes

DG the recovery system doesn’t allow repeated logons - only twice. a design feature to stop a recovery failure causing a crash loop. A recovery failure is not a threat to robustness unless the number is too high. In this case where you have a failure it is designed...

… so the recovery is a joint process between the SPM, Fujitsu and the PO
JC yes
DG and it’s important to know EXACTLY when money changes hands.
JC yes

DG if authorisation comes up to hand over money on the screen, the SPM might see it, might not, might have handed the cash over might not
JC not if they see an authorised sign. that should be the last thing that happens.
DG v good. but sometimes human beings accept money early?

JC yes
DG and exactly what happened in that scenario needs to be investigated. If the SPM doesn’t take the money because he thinks the transaction hasn’t been accepted and then later finds out he has it needs to be investigated
JC yes if it happens at the time, but not if...

… that investigation happens the next day.
DG eh? why not?
JC just in practical terms I don’t know how that would work in a large Post Office if it isn’t done at the time.
DG as soon as the problem arises the SPM would know about it. Yes?

DG so he would keep a note.
JC if it was him who had the problem and not someone else
DG anyone would remember or know they ought to remember, they’re not goldfish.
JC I accept the premise...

DG looking at this example. quotes: receipt printed saying authorisation had happened so it’s possible the SPM had handed over cash. Flagged as a problem and Fujitsu say the PO may need to issue a TC to the SPM.
JC accepts this is a fair and sensible process.

DG that is the system working as it should to avoid the risk of any loss to a SPM. would you agree?
JC as things stand at the end of this there is a discrepancy in branch accounts. which the PO may well go on to fix, but there is a discrepancy
DG yes you get as far as the problem

DG but then completely ignore the fix. If there was a discrepancy and we don’t know there was, we know the countermeasures resolve it
JC but there was a discrepancy
DG here Fujitsu spotted a failed recovery, looked into it and then formed the view it was necessary to see..

… what had happened on the ground and then asked the SPM what happened. It generated a report to be acted upon and on any fair reading of the evidence it would be extraordinary if they did not contact the SPM and send a TC if needed.
JC yes but I wrote this in response...

… to Horizon issue 4.
DG this is listed as one of your 29 bugs.
JC that is a joint statement remember. Look at the table in my report p12 - it’s quite clear here it’s under H4 not H1 and that is a different issue of “potential”
DG have you finished your answer?
JC yes

DG your answer is absolutely astonishing. you are saying these recovery failures have an impact on branch accounts
JC they do until they are dealt with by Post Office - there’s no doubt about that
DG this PEAK reference is from your bug list in your second report...

… you told me this morning these have an impact on branch accounts.
DG first of all this was not a bug, it was a recovery failure and secondly no evidence of an impact on branch accounts. What we have is a functioning system of recovery.
JC your question there was all about...

… all about bugs. The correct discription in the Horizon issues is bugs, errors and defects. Recovery is a listed Horizon issue.
DG reads out where JC lists this recovery issue as a “bug”. What you are saying there is in your considered opinion is that these PEAKS are evidence..

… of “bugs” causing a “lasting discrepancy”
JC that’s an agreed statement saying there are between 12 and 29 bugs.
DG and you think there are 29. are you withdrawing your evidence?
JC the bug table in my second report has a column has evidence of branch account [impact]

… and this has a column in it is says yes or no.
DG I’m looking at an agreed statement by you which is an assertion that these are 29 bugs causing LASTING discrepancy. There are transient discrepancies and lasting ones. transient ones get handled by countermeasures.

JC they should
DG you are saying these “bugs” caused discrepancies which were lasting - which weren’t handled by countermeasures and yet we go to this PEAK and what i suggest to you there is no evidence of a bug and more importantly if there were a discrepancy caused...

… it would have been picked up.
JC yep if it worked but H4 asked if there was potential
DG you’re evading my question. forget H4. we’re looking at bugs causing lasting discrepancy in branch accounts after taking countermeasures into account. yes?
JC asks why he’s asking...

J intervenes. I’m cutting this short. Its’ gone 1pm. There is a joint statement. We can all read it. How many bugs do you say there are
[JC starts]
J No. How many bugs?
[silences as JC counts]
JC 13
J Thank you. Mr de Garr Robinson if you would like to pick this up after lunch...

… you may.
[DG says nothing.]
J Thank you.
[J rises]

[lunch]

NEW: Bates v Post Office judgment No. 5. This High Court judgment was made on 23 May 2019 and handed down today. It gives reasons for ordering Post Office to pay 90% of claimants costs. The Post Office was ordered to pay £5.5m within 21 days of 23 May.
postofficetrial.com/2019/06/bates-…

We’re back after lunch.
DG asking about which bugs listed by JC are transient or lasting. There are 29. You now say 21 are lasting. And just to be clear there are 8 which would have been picked up?
JC not quite - they could well be...

DG focus on this list. 8 of the bugs in your 2nd report are NOT lasting.
JC yes
[J has just confirmed JC list of 29 lasting bugs is now 21!]
DG this takes me by surprise. this is the definitive list, isn’t it?
Now since your second report you have maintained these were bugs...

… with lasting financial effect.

DG I formed that view on the basis of your heading “Table of bugs errors defects with acknowledged or disagreed areas of impact”. I thought these bugs were lasting financial impact as I think you did. Dr Worden thought there were only 12.
JC yes

DG reads out agreed list of bugs in Horizon which had financial impact - twelve in total. We thought the disagreement between you was that you said a further 17 did, to get you up to 29. yes?
JC yes

DG so my understanding of joint statement 2 was that there were 12 asserted by Dr W and 17 by you.
Am i wrong?
JC yes - there were a range of bugs we couldn’t agree on, so I put some in as examples of what we couldn’t agree on.
DG are you suggesting there were only ever 21?

JC no - they are bugs errors and defects which point to issues.
DG so no one is EVER saying there were 29 bugs? How did we get to that point if no one is saying it?
JC I am not sure who suggested the first draft of that statement
DG doesn’t matter does it
JC no because it was...

… correct.
DG how could that possibly be the case. Where did those 8 bugs come from? When neither you or Dr W had identified them
JC because they could have but we don’t have evidence of that
DG I’d like to suggest that is not a sensible or fair reading of what you set out...

… in your joint statement. Dr W had 12 and you had a further 17. Are you now refuting this?
JC no there were 29 in play
DG this is confusing. It’s binary. Either a bug had lasting financial impact or it does not. You are the only two people producing this statement. Dr W has 12

… you have 17. To make 29.
Now you have a further 9.
JC some we couldn’t find the bugs, but we have evidencce of them.
DG everyone on this side of the court read this report to say there were 17 on top of Dr W’s. Where anywhere in any of your reports does it say definitively...

… had real actual evidence of just 9.
[JC is unable to say]
DG can you tell me, from this table, which bugs on this table caused lasting financial impact.
JC 14 on this table and 7 within this last item.
DG so on this table those 7 in the last item is bug 22.

DG I’ve been focusing on your bug table because I thought this was the last published tally
JC it is.
DG I’m not trying to stop you going to your report
JC yes so covered at 3.211 in the report…
DG there are 2 x PEAKS in that section - how can they account for another 7 bugs

[something is unravelling here]
DG what are you saying…?
[silence as JC reads his report]

JC sorry I’m drawing a blank at the cross-references...

[more silence]

JC sorry I would need to search for that PEAK reference against the list…

DG could we go back to the first issue I was seeking to explore with you. You told us we were wrong to think there were 29 bugs with lasting financial impact. Where in any document will we see it is 21 not 29?
JC throughout the report I’ve set out whether it’s a Horizon issue 1

DG let’s not talk about your second report let’s talk about your second joint statement
JC I said you can’t read that in isolation
DG but this table had 29 bugs in it which had financial impact. I thought you meant lasting because of par 1.15 of the joint statement. where...

… do you say YOUR view is that there are only 21 with lasting financial impact? And if not why not?
JC takes them to an example in the bug table. Here I list a bug which I say DOES not include impact on branch accounts.
DG okay, that brings it down to 28. Where are the other 7?

JC number 17 is re Horizon Issue 4
DG where does that say it DOESN’T have lasting financial impact.
JC doesn’t suggest that it does
DG here’s what I find interesting Mr Coyne, in your table for this in report 1 it has a column about branch impact and the word YES. Is that wrong?

JC as agreed by Dr W - this has an impact.
DG okay now we’re down to 27. Any more?
JC says another bug is H4 not H1 so on the table in my second report I’ve said evidence of branch impact.

DG Perhaps you could tell me the bugs we should take out
JC take out?
J I’ve been taking notes - so far I’ve got 17, 19 and 21
JC 15 - H4
DG does it say it’s H4?
J in the column, but it’s not clear.
JC 16
DG it says that’s a Horizon issue 1 - shall I take that out?

J I don’t want to be pedantic this is a joint statement
DG I don’t think Dr W has ever asserted it was a H1 issue
J it might lead to a permanent deletion later
JC agrees 1 should go
JC Post and Go issue
J number?
JC 19
J you’ve given us that already.

J my running total is:

15, 16, 17, 19, 20 and 21

DG mine are: 15, 16, 17, 19, 20 and 21

so we’re down to 24 bugs, there are another 3 to go.
J yes
DG possibily more if the last item contains 7
J Mr Coyne are you in a position to tell us the remaining three?

[JC is going through his reports.]

[there is an hour left of cross examination]

JC I’ve only got 6 to take out
DG so we’re at 23 not 21. how?
JC I’ve got from the bottom up, not the top down
DG how is your position now inconsistent with your position you had at 2.01pm
JC over lunch I went through them on [an other table] then added the 7
DG could you explain

… how the 7 bugs you list are related to just 4 PEAKS?
J you might want to reconsider that Mr de Garr Robinson…
DG it’s just 4 PEAKS footnoted.

[DG is now conferring (with J’s permission) with Patrick Green QC for the claimants. This is extraodinary]

[goodness knows how many millions this trial cost and right at the death of the claimants IT witness he’s confused as to how many bugs there are which caused lasting impact to branch accounts]

JC it’s just struck me that these could be inclusions from Dr Worden

DG oh i see. right. let’s go back to the start and go through them one by one.
[DG is now calling out the bugs and asking JC to say yes or no if he thinks they had lasting impact on branch accounts. We’ve got to 10]
DG 11 - Girobank discrepnacies
JC yes
DG - 12 counter...

… displacement issues
JC not sure whether Post Office did anything about this
DG we’ve sought to establish transient or lasting all day - so was this lasting - counter replacement issues? evidence of lasting impact
JC yes
DG 13 - stock discrepancies
JC yes

DG - bureau discrepancies bug
JC yes
DG - 14, 15, 16, and 17 are out
JC yes
DG - 18?
JC - yes
DG i’m interested in you saying that because in your own report you say no.
JC after discussion with Dr W changed my mind.
DG okay

DG 19, 20 are out as is 21 do I infer from our previous discussion 22 is in?
JC yes
DG as in, lasting impact
JC yes

[they get all the way up to 29]
DG 29?
[JC is checking]
JC I’ve only got that down as potential
DG so no evidence
JC no - but let me just check
[DG currently has 22 if we remove 29]

JC removes 29
DG we are down to 22. Is that your final answer?
JC yes
DG why did you think there were 21 at 2pm, 13 bugs at 1pm?
JC I tallied wrong
DG to go back to my earlier question - where do you make this clear in the joint statement.

JC in the heading next to bug/error/defect
DG and that’s enough to say it is clear for the reader that of the 29 bugs we only need to be concerned with the 22
JC yes

DG your joint statement is seriously misleading
JC we didn’t believe it was misleading when we put the document together
DG everyone on this side of the court is taken by surprise that it just 22 not 29. I venture to suggest that even claimants own counsel is surprised by this.

JC if you read my report it explains it. I know today you have chosen to go through Horizon Issue 1, but the report deals with ALL the Horizon issues.
DG section 1 of the report deals with Horizon Issue 1, doesn’t it?

DG the natural interpretation of your par 1.15 in that is that Dr W was saying 12 and you were saying 29. How can even your own counsel make that mistake?
J on the basis this is a joint statement, you need to be quite careful about the way you are asking this question.

DG let’s go to claimants’ counsel’s opening statement [he does] where he says there are 29 bugs with lasting effect if that wasn’t the case?
JC it was a statement that was put in there to try and frame the number we would arrive at was somewhere between those 2 parameters.

DG did you read the claimants opening statement?
JC not sure
DG really?
JC these are historic documents are they?
DG these are the opening statements put to the judge - you have considerable experience of court process. You’re an expert witness...

…. are you saying you didn’t read counsel’s opening statement.
JC I don’t think I did, no.
DG so like ships passing in the night you have been running with one idea and your counsel has been running with another under mistaken assumption

DG which continued until 1 minute to 1pm today. it could be said that you have changed your position to avoid what you knew was coming under cross-examination.
JC no that’s not true
DG my lord could we have a break so I can look at my list and with the remaining 45 minutes...

J… work out what you are going to do?
DG work out what I am going to do.
J by all means.
[judge rises.]

[wow.]

[we’re back]
DG we’ve got 35 minutes as I promised my learned friend we’d be done by 3.45pm
DG lets go to the Dalmellington bug, and the PEAK that relates to it.

DG [reads from PEAK] this issue is not a user error it is a system error that needs investigation.
[moves on to p5 of the PEAK]
[Anne Chamber features a lot in here]
Repeat remittance error.
DG so I put this to you yesterday or Wednesday was a bug if you want to call it a bug...

… which caused a screen to come up which they thought meant they had to press enter. So it wasn’t a bug, but it forced them to commit a human error.
JC they were following instructions they were given on the screen
DG so it mimicked a human error.

JC yes
DG so it would be hard to tell whether or not they’d remmed in twice it would be hard to tell if it was a human error due to incompetence or something they were being told to do. Hard for Fujitsu to discern.
JC not if they looked at the audit logs. which they did...

… which is how they discovered it.
DG Ms Chambers says this is not an area which has been changed for several years so it’s likely to have happened before… we are continuing to investigate. So it would be right to say they’ve remmed in the same thing more than once...

… so they could look at the receipts, identify it and reverse the transaction themselves.
JC certainly some did
DG and this would always be visible in the logs and receipts to the SPM
JC yes typically
DG you’d see a discrepancy...

JC possibly, but reconciliation in my experience isn’t as simple as you’d suggest.
DG and these remming in problems would create a receipts and payments mismatch, which I think we’ve already agreed are automatically reported…
JC not sure that’s necessarily the case...

DG as far as we are aware Dalmellington bug affected outreach branches and so Fujitsu had a look to see how many times this had happened - there was an investigation. and they did this by looking at the DLE files looking for symptoms of the issue.

JC yes
DG and they found over a hundred cases (108). Some where corrected at the time, and some where corrected by error notice. In all the cases they looked at (104), either the SPM had fixed it in branch or a TC had been issued.
JC yes

DG so putting those 4 branches which hadn’t been investigated aside, of the 104, 104 had been fixed. So subject to the 4 branches which hadn’t been looked at the countermeasures had 100% success rate, agree?
JC yes
DG so the countermeasures worked very well, yes?

JC without looking at the time between resolving it we don’t know
DG so you’re hypothesizing there may have been a delay in issuing a TC or an SPM exercising self-help?
JC it would help me make a decision on the question you asked me
DG let’s look at the SPM exercising self-help

DG would they do it quickly
JC as quick as possible
DG in the same trading period?
JC maybe, depends how good they are
DG but when they roll over it would come up
JC it might be quite difficult
DG yes but we have evidence it all worked out. you are seeking to ID problems...

…. that are hypothetical. As opposed to what actually happened.
DG it was not lasting impact
JC it was resolved. we don’t know how long it took.
DG do you accept in all those cases none of them were lasting
JC outwith the 4 that weren’t looked at
DG I’m not going to go through

… this again am I? We said we’d put that aside until later. Excepting those 4 do you accept all 104 branches were resolved without loss.
JC yes.
DG Right let’s have a look at the remaining 4. As you know Mrs van den Bogerd asked her team to look at what happened in...

… their cases.
DG do you have a problem with any of the methodology in finding the branches with problems.
JC no
DG of the 4 unknowns one was £25K and one was £2.5K the other two were less than a fiver.

DG So steps were taken to look at the high value branches. And this is the report. Have you read this?
JC not sure
PG QC it was disclosed on 4 March
DG thank you.
DG reads from the doc - the two branches investigated there and was no net impact caused in branch

DG the remittance transactions were completed on different counters (not outreach).
[JC wants to read the last bullet point]
DG so these two branches showed the same symptoms but it wasn’t because the machine wanted you to rem the same pouch twice it was because...

… a human remmed in the same pouch manually twice in both these cases. Report concludes not a Dalmellington issue in both these cases.

Both these branches fixed their problems in branch.

DG so this was not an instance of the Dalmellington bug
JC accepts
DG now the other two branches where a pound and a penny were out, bearing all this in mind… what are the chances that this wasn’t sorted in those branches
JC very small
[DG’s 4 day xe finishes]

[Patrick Green QC for the claimants is on his feet for re-examination]

[This is a run through of 4 days of cross-examination where PG thinks the judge may benefit from some context so he asks JC questions on what he was xe’d on]

[It’s quicksilver fast this, and we’re jumping around all over the place I doubt I’ll be able to keep up]

[transcript usually gets to me by 8pm so you’ll have to look at it then]

PG asking about permission controls and referring him to E&Y report which seems to suggest they are weak - a variety of points
JC generally poor control of user privileges and people being given access where they shouldn’t
PG to be fair management say they will respond

PG okay this is PEAK that has come up before - let’s go through this.
JC It is May 2015 saying SSC users have more access than they should
[PG reads out no issues have arisen because of this because he is asked to DG]
PG also Post Office haven’t been told about this...

… also anne chambers saying when we go off piste we use APSUP, but can we have access to this - it’s a powerful tool isn’t it, APSUP
JC it’s super-user access
PG and there’s a lot of argument about this - so APSUP should only be expressly given by security etc

PG it is a security breach if it used without permission etc etc
PG in the event, do you remember that the new people had not been given APSUP, but the old APSUP privileges had not been taken away.
JC yes
PG and that’s the PEAK you meant in your evidence yesterday
JC yes

[we’re leaping around so much as this is a rattle through]
[we are now looking at a spreadsheet which is hundreds of thousands of rows deep]

PG did you find these spreadsheets easy to work with
JC no they were terrible - don’t see why we couldn’t have been given the information on a database

[PG gets up another doc which seems quite easy to read]
PG were you given any MSCs in this form before the trial started?
JC no
[another doc]
PG this is an email from you info following first day looking at PEAKS (18 July 2018) and you are asking for MSCs OCRs and OCPs

JC yes
PG why did you think they might be useful?
JC so I could see if there had been any changes to branch accounts
PG so yesterday you were asked about claimant FAD codes… and you say one of your early requests was that I shouldn’t make any request for info...

… relating to the individual claimants. and DG said be very careful what you’re saying - you said can I have a look at the RFI and DG said we’ll do it later and we didn’t. Can we go to it now? If we look at par 1.3 there you’ll see you’re asking about a document which...

… might detail any branch affected.
You get a standard answer about PO not having access to what you want AND you are warned not to look for info on individual claimant cases as "That is not the purpose of the Horizon trial”
JC yes

PG is that what you were talking about when you said you asked for info and didn’t get it
JC yes
[they really are rattling through this - PG has just apologised for going so fast]

[so PG is picking up on occasions during his xe where JC has stated he asked for info leading up to the trial and it was not disclosed - he has just read out in court responses saying he should not be asking about claimant info]
PG so do you think you should be cautioned...

… about mentioning that in open court?
JC no it would have been very helpful information in relation to my instruction
[we have moved on.]

PG when did you realise there was an hour difference between ARQ and Horizon data
JC I worked it out. I don’t think I was ever told

[we move on]
PG you got MSCs just before xmas last year and OCPs and OCRs on 24 Jan [JC’s final report came out on 1 Feb] and a further 2500 OCRs on the 18 April. Have you been busy since the Horizon trial was derailed?
JC yes

PG did you have other trials you were working on?
JC yes
PG has this been difficult?
JC yes
PG what do you think of the way you’ve been disclosed interest
JC very difficult
PG how does it compare
JC i’ve never known anything like it

PG that’s me I don’t know if your Lordship has any questions
[re-examination finishes]
J no - thank you very much Mr Coyne you may leave the witness box.
[ we go to housekeeping ]

Thanks for reading all these tweets all week. Amazingly my number of followers is holding steady for which I salute your fortitude. I’ll get a report up on today’s mauling as soon as I can.
And I’ll get these tweets collated...

And I’ll get the transcript up on postoffictrial.com tonight.

Okay we’re back at 10.30am next Tuesday for Patrick Green QC’s three day cross-examination of the Post Office’s independent IT expert Dr Robert Worden.

If you have enjoyed these tweets or any of the material up on postofficetrial.com - please consider putting a few quid in the tip jar if you haven’t already. V grateful. Have a lovely weekend.
#postofficetrial

@threadreaderapp unroll pls