![](https://pbs.twimg.com/media/D8cqgSDXoAAV52Q.jpg)
I have a paper copy and will get an email copy later. I’ll post it up at lunchtime.
[We start with a document I can’t see. I will try to pick up the gist…!]
JC points out there are parts in the report where PO decides not to adopt auditor recs...
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...
JC says he thinks it is.
[we move on]
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
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 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 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
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]
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...
DG it produces a receipt and then the SPM can either reverse it or dispute it.
JC yes
JC no I don’t believe I did
DG well let’s have a look...
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
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
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...
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?
[DG goes to the other citation in support of phantom transactions…]
JC no we don’t
JC it’s possible.
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...
DG given his experience and the info available to him, and given this problem has not reappeared since 2001 - would...
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...
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...
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?
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.
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]
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...
JC yes
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...
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...
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?
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.
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?
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.
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)…
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 ]
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...
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.
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...
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..
JC yes.
JC yes but it was only picked up by Girobank. It flew through Horizon without getting stopped and it only got picked up
[we have a break]
The Post Office lost that one badly. This one seems much more even.
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.
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.
JC yes
DG it doesn’t show a bug causing discrepancies in branch accounts. It shows people correcting them.
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
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...
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...
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.
JC agrees.
JC you need to read them in the wider context of the report.
DG do you confirm this is something you have listed as an example of a bug causing a discrepancy in branch accounts?
JC yes
JC cos a false report was generated
DG but the bug did not cause a discrepancy in branch accounts
JC no the bug
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
JC if that was right, why would Fujitsu engineer reference the KEL for that defect
DG it’s plain from the language used
[they move on to Bug 20 - recovery failures]
“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].”
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
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.
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.
[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
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...
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?
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
DG any system of this sort is going to have recovery situations. you can never guarantee you won’t have ...
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...
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
JC yes
DG and it’s important to know EXACTLY when money changes hands.
JC yes
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?
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...
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?
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...
JC accepts this is a fair and sensible process.
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
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..
JC yes but I wrote this in response...
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
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...
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...
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..
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]
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.
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...
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...
[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...
[DG says nothing.]
J Thank you.
[J rises]
[lunch]
postofficetrial.com/2019/06/bates-…
![](https://pbs.twimg.com/media/D8dfJitXUAArGTV.jpg)
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...
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...
JC yes
JC yes
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?
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...
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...
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
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...
[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.
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
DG what are you saying…?
[silence as JC reads his report]
JC throughout the report I’ve set out whether it’s a Horizon issue 1
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...
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?
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?
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.
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?
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.
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?
[there is an hour left of cross examination]
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
J you might want to reconsider that Mr de Garr Robinson…
DG it’s just 4 PEAKS footnoted.
JC it’s just struck me that these could be inclusions from Dr Worden
[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...
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
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
JC yes
DG as in, lasting impact
JC yes
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]
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.
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
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.
DG section 1 of the report deals with Horizon Issue 1, doesn’t it?
J on the basis this is a joint statement, you need to be quite careful about the way you are asking this question.
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.
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...
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
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...
DG work out what I am going to do.
J by all means.
[judge rises.]
[wow.]
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.
[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...
JC they were following instructions they were given on the screen
DG so it mimicked a human error.
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...
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...
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...
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 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
JC yes
DG so the countermeasures worked very well, yes?
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
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...
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
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...
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.
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
[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...
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]
[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]
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
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...
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 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 are now looking at a spreadsheet which is hundreds of thousands of rows deep]
JC no they were terrible - don’t see why we couldn’t have been given the information on a database
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
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...
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
JC yes
[they really are rattling through this - PG has just apologised for going so fast]
PG so do you think you should be cautioned...
JC no it would have been very helpful information in relation to my instruction
[we have moved on.]
JC I worked it out. I don’t think I was ever told
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
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
[re-examination finishes]
J no - thank you very much Mr Coyne you may leave the witness box.
[ we go to housekeeping ]
And I’ll get these tweets collated...
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.
#postofficetrial