Friday 7 June 2019

Horizon trial day 17: PEAKs and troughs

Jason Coyne
Who would be an expert witness? I don't know what Jason Coyne was getting for sitting in the witness box of Court 26 for the last four days, but it wasn't enough.

One thing I have learned from my experience of reporting every day of the first (common issues) trial in this litigation is that it is dangerous to draw conclusions from what you see and hear in court. 

Furthermore I am not privy to all the information both sides have got at their fingertips, I haven't been given the joint statements and nor yet (you'll forgive me) have I had an opportunity to pore over each of Jason Coyne's 200+ page reports

So what follows is my impression of what happened in court today from listening to Mr Coyne's final day of cross-examination. And my impression is that Mr Coyne took an absolute battering.

The morning session was just one win after another for the Post Office QC, Mr Anthony de Garr Robinson.

Mr de Garr Robinson started with the list of 29 bugs in Horizon which Mr Coyne had asserted caused a discrepancy with a lasting impact. Then he set about steadily demolishing them.

Phantom transactions

First up was phantom transactions. There were two examples of phantom transactions which Mr Coyne had found originating in 2000 and 2001. None since.

Mr de Garr Robinson read out the Fujitsu report (known as a PEAK) into the 2000 example. The transactions were loaded onto the system by the Subpostmaster who then pressed a button which suspended the session.

So "these were transactions that were actually
 typed into the system. They didn't appear out of nowhere" and "the postmaster
 accidentally must have touched "suspend" with her hand
 or something with the result that the session was suspended for that period of time.
"

Mr Coyne agrees, but says it was the registering of that basket of transactions which was done by Horizon, not the user.

"I see", says Mr de Garr Robinson "So what you are suggesting is that if the system automatically commits an uncommitted basket after a period of time, that's evidence of phantom transactions? That's evidence of a bug in Horizon that needs to be corrected?"

"Yes", says Mr Coyne.

Mr de Garr Robinson directs Mr Coyne to Angela van den Bogerd's witness statement which notes this is a design quirk of Horizon. If a bunch of products sit in a basket for long enough on the screen Horizon will turn them into a sale automatically.

"So this isn't evidence of Horizon going wrong, is it?
" asks Mr de Garr Robinson. "It is an example of Horizon doing what it was supposed to do."

"It is evidence of the system doing something
 without the user choosing to do it." retorts Mr Coyne.

But that is not the point. It is not a bug in the system, and Mr Coyne describes it as this in his report.

Lasting losses

Mr Coyne then starts to dig himself a hole, claiming he cited it as a bug because he hadn't seen Angela van den Bogerd's witness statement explaining Horizon's little quirk.

Mr de Garr Robinson is ready for this. "You did." he says, and directs Mr Coyne to the section of his report entitled Angela van den Bogerd in which he records responding directly to her evidence about phantom transactions.

Mr de Garr Robinson tries again. He asks Mr Coyne to accept this is Horizon working as designed and not a bug.

Mr Coyne does acknowledge this, but points out that the experience would be confusing for the user.

Mr de Garr Robinson responds: "If we were looking at a table which was a
 table of areas where users might get confused, then we
 wouldn't be having this conversation. We are having this conversation because you have added
 this piece of evidence as evidence in support of the
 proposition, firstly, that there are bugs in Horizon
 and, secondly, that they cause losses, lasting losses to postmasters."

Having destroyed the PEAK listed in 2000 as an example of a phantom transaction, Mr de Garr Robinson then attempts to euthanise the only other example from 2001, suggesting it wasn't a phantom transaction at all, but an example of Horizon's default timeout quirk of turning a basket of transactions into a sale.

Mr Coyne pushed back quite a lot on this, but Mr de Garr Robinson asked him see how the PEAK progresses. We see, in another box, a note from a senior Fujitsu engineer, Pat Carroll, which makes it clear he has investigated thoroughly and concluded it was user error.

"Would it be fair to suggest
", asks Mr de Garr Robinson "that the best judgment to trust in relation to what was
 going on here is Mr Carroll's judgment?... Do you think you are in a position now, in 2019, looking at this PEAK nearly 18 years ago, to say that Mr Carroll, with the familiarity he had with the system and with the information that he had at his fingertips, he must have been wrong?"

Mr Coyne says on the evidence he can't be sure that's right. Mr de Garr Robinson reformulates his question: "Do you think you now, with the information you have,
 are in a position to say that Mr Carroll was wrong?"

Mr Coyne accepted he couln't. So why, Mr de Garr Robinson wanted to know, hadn't he mentioned the conclusions of Mr Carroll into his report? Surely that's what a fair, independent expert should be doing.

Mr Coyne accepted perhaps he should have done so.

A heavy beating

And on it went. PEAKs and KELs (Known Error Logs) which Mr Coyne had cited to support his evidence of bugs causing lasting impact on Subpostmaster branch accounts were examined. On each occasion he was forced to accept that it was at the least reasonable to accept that in most cases there was a bug which was spotted and resolved as part of Horizon's counter-measures, or no bug at all.

Whilst I don't want to suggest that Mr Coyne was not making valid points, and pushing back in some significant ways throughout the morning, the overall impression I got was that he was taking a heavy beating.

But that was nothing as to what happened next. Mr Coyne already been grilled on a PEAK which described a recovery failure. Some data had gone missing, leaving a branch with a discrepancy. According to Mr de Garr Robinson's reading of the PEAK log (and don't forget I couldn't see any of these PEAKs or KELs referred to today) the issue was resolved when the recovery failure was flagged by the system, Fujitsu got involved, called the branch and between the Subpostmaster, Fujitsu and the Post Office it all got resolved.

Mr Coyne agreed it would be reasonable to assume, looking at the evidence, that the bug was recognised and the Subpostmaster was recompensed, but he also made the point that the recovery failure caused a discrepancy.

Then things really started to unravel. Mr de Garr Robinson noted Mr Coyne was very keen to point out a problem, but not the fix. He had chosen to list this PEAK as one of his 29 examples of a bug causing a lasting discrepancy.*

"First of all" said Mr de Garr Robinson, "there's not evidence of a bug, but more importantly... the evidence constituted by this
 PEAK demonstrates that if there were any discrepancy caused, it would have been picked up in the process."

Freefall

When asked why he had included it on his list, Mr Coyne said not everything on the list of 29 bugs was a list of 29 bugs which created a lasting discrepancy. It was a list of 29 bugs errors and defects which had an impact on branch accounts.

Mr de Garr Robinson asked Mr Coyne why it had appeared in a list on a joint statement under the title "distinct bugs, for which the experts have seen strong evidence of the bug causing a lasting discrepancy in branch accounts"*

It was a question to which there was no real answer.

After lunch the situation went into freefall. Mr de Garr Robinson wanted to know how many bugs out of the 29 listed in the joint statement were not actually "bugs" causing a "lasting discrepancy in branch accounts".

Mr Coyne had decided he was pretty sure 21 were, so eight weren't.
Tony de Garr Robinson QC, (r)

Entirely reasonably, Mr de Garr Robinson asked Mr Coyne to list them. Over the next excruciating hour (and feel free to read this in the transcript) the judge, Mr de Garr Robinson and eventually even Patrick Green, QC for the claimants, looked to Mr Coyne as he tried to work out which of the 29 lasting bugs were the eight which weren't.

The judge made a list, Mr de Garr Robinson made a list. They compared notes. The numbers didn't match up with Mr Coyne's new total. They went back to Mr Coyne. Mr de Garr Robinson, who was no doubt enjoying himself, returned to the central question - how could the defence and, indeed the claimants have been led to believe Mr Coyne thought there were 29 bugs that caused a lasting discrepancy in branch accounts?

Total humiliation

"Everybody on both sides of the court
 thought that was the position." he said "How could that possibly be the case?  How can your own counsel, Mr Coyne, have made that mistake?


The judge intervened - noting that the "lasting discrepancy" line came from both Dr Worden and Mr Coyne: "On the basis it is a joint statement,
 Mr de Garr Robinson", he warned "I think you have to be quite
 careful about how you put the question.
"

Quick as a flash Mr de Garr Robinson produced his trump card. Not only was the lasting discrepancy phrase in the joint statement, it was in the claimants' opening statement.

Which Mr Coyne then admitted he had probably never read.

It was a total humiliation.

At three o'clock Mr de Garr Robinson all but wiped the blood off his sword and handed it to his equerry. He turn to the judge:

"My Lord, I wonder whether it would be a convenient moment to break so that I could look at the
 list and decide...

"what you are going to do.
" finished the judge.

".... what I'm going to do." repeated the QC, possibly slightly dazed.

The spring in the step from the Post Office legal team as they marched out of court was very noticeable.

After the break Mr de Garr Robinson put to one side the heady atmosphere of the previous session and got back down to business.

He used the 35 minutes he had left of his four day cross examination to look at the Dalmellington bug, which affected Post Offices with outreach branches.

By the end of the 35 minutes he had demonstrated to Mr Coyne from Post Office internal investigations that of the 108 branches known to be affected, by the time the bug was discovered, 104 of them had noticed the dodgy transactions and reversed them themselves or had transaction corrections issued automatically by Horizon. Of the remaining four, two were manual errors caused by someone typing in a bag number twice and two suffered discrepancies of a pound or less and so weren't investigated.

Mr Coyne accepted, in not so many words, that whilst there was clearly a bug, it was very unlikely that anyone was out of pocket.

And so four long days of cross-examination came to an end. What little evidence Mr Coyne had found of serious Horizon errors causing lasting discrepancies to branch accounts had been tested, almost to destruction.

The coda

During re-examination, Mr Green for the claimants asked Mr Coyne about a number of area he'd been tested on over the course of the last four days. The issue ringing through loud and clear was disclosure.

We know the Post Office has fought tooth and nail to avoid disclosing anything it felt irrelevant to the trial. It meant that PEAKs and KELs were were handed over, but the Post Office refused to provide any search terms which might have helped Mr Coyne find errors in those PEAKs and KELs. They refused to give him any information which might have allowed him to investigate particular problems at claimants branches.

In fact, Mr Green took him to more than one document where he was warned off any interest in the claimants by the Post Office who told him "an attempt to obtain
 documents containing information that could potentially be tied to individual cases... is not the purpose of the Horizon trial."

Mr Green also asked Mr Coyne about mysterious documents known as MSCs, OCPs and OCRs (I think of them as quarks to the protons and electrons that are KELs and PEAKs). On seeing the KELs and PEAKs, Mr Coyne had asked in July last year to see their related MSCs, OCPs and OCRs. He got the MSCs in December and the OCPs and OCRs in January, a week before he delivered his final report.

Mr Green wondered about the way the MSCs were given to him.

Mr Coyne replied: "the MSC database was
 a singular database with all the data in it but the way
 that it has been provided to us... it
 has been split into three different Excel spreadsheets... there's no easy way to try and interrogate across the three spreadsheets. They aren't all the same
 length, so you can't put them together. One has lots of columns going across and the other
 one has literally hundreds of thousands of columns going
 down. So it is practically impossible to use for the purposes of analysis.
"

What were they like to work with, Mr Green wondered?

"Terrible." Mr Coyne replied.

Mr Green opened the subject out: "Mr Coyne, can I ask you whether you have been busy since
       the time that the Horizon trial should have ended, had
 it gone to plan and not been derailed?
"
JC: "Yes, yes, I have got a number of other projects."
PG: "Have you had a give oral evidence in any other cases?"
JC: "Yes, I have had to give oral evidence in a case at Manchester and I have a number of other non-contentious projects where I'm helping companies go live with big systems.
PG: "How have you found the timing of your receipt of
 documents for the purposes of preparing your reports?
"
JC: "It has been very problematic.
"
PG: "How does it compare to other cases you have been in?"
JC: "I don't think there has been another case where I have experienced this level of... the disclosure being
 provided in dribs and drabs, especially after making
 a specific request...  last year because it
       was quite clear then the types of documents that would
 be required.
"

Next week is going to be interesting, that's for sure.

**************

* Although it was a joint statement the Post Office IT expert only accepted 12 of them.

Live tweets of the day can be found here. I'll be back live tweeting here from Tuesday at 10.30am.

*******************
If you can, please help keep this crowdfunded public-interest journalism project going by chucking a few quid in the tip jar below. Contributors who give £20 or more will start receiving regular "secret" emails which have all the info and gossip about this litigation as it makes its way through the courts.

If you want to see how much I have raised to date and how I've spent it, click here.
If you want to find out more about the underlying story, click here.
Choose an amount

Horizon trial day 17: transcript

This is the transcript of Day 17 of the Horizon trial, the second trial in the Bates and others v Post Office group litigation, held at the High Court's Rolls Building on Friday 7 June 2019.

Jason Coyne, independent IT expert for the claimants, spent his last of four days being cross-examined on his expert reports by the Post Office's QC, Anthony de Garr Robinson.

Mr Coyne's reports can be found here. The transcript follows:

                                          Friday, 7th June 2019
   (10.15 am)
                       MR JASON PETER COYNE
       Cross-examination by MR DE GARR ROBINSON (continued)
   MR JUSTICE FRASER:  Before we start, just formally I'm
       handing down judgment number 5, which is the reasons for
       the costs and the other orders of 23rd March.  The
       reference is 2019 EWHC 1373 (QB).
           My learned clerk is going to give each party one
       hard copy.  There are three other hard copies, one of
       which is for the press, there are two spare.  If anybody
       wants it emailing, if they put their email address on
       a piece of paper and in the mid-morning break my clerk
       will email it and it is going on BAILII later.
           The other point, which is just a reminder, can the
       two of you, please, between you, make sure that at the
       end of the day you remind me to mention to you the PEAKs
       and KELs hard copy.
   MR DE GARR ROBINSON:  Between us.
   MR JUSTICE FRASER:  There is a good chance during the course
       of today excitement will overcome me and I will forget.
   MR DE GARR ROBINSON:  Between the three of us hopefully
       someone will remember.
   MR JUSTICE FRASER:  Right.  Mr de Garr Robinson.
   MR DE GARR ROBINSON:  My Lord.
           Mr Coyne, good morning.
   A.  Morning.
   Q.  I believe you have some homework to provide this
       morning, is that right?
   A.  Yes.  There was a number of questions that were asked
       the other day that I have got the answers to.
   Q.  Yes.  I'm not going to ask for oral answers.  Have you
       got pieces of paper indicating particular PEAKs and KELs
       or whatever it was that you wanted to rely on?
   A.  Yes, I have got some notes here, they are rather rough.
       I thought I would be reading them out rather than
       handing --
   Q.  It is really a matter -- of course it is up to his
       Lordship to decide but I would rather not have evidence
       read into the record in that way.  If you have documents
       you wish to rely on then by all means produce them
       but --
   MR JUSTICE FRASER:  Did you bring copies of the documents or
       references of the documents that you were asked to
       provide?
   A.  Some of them, my Lord.  Some of the other questions were
       about how many, so I have got a number of how many,
       rather than a reference to all the documents.  So, for
       example, it was about how many retrospective OCRs and
       OCPs, so I have a number for that.
   MR DE GARR ROBINSON:  Actually I specifically don't want
       evidence being read into the record which isn't
       supported by document references and which is the
       basis -- which is the fruit of work that you have done,
       would this be right, this is all the fruit of work that
       you have done since your last joint statement with
       Dr Worden on 4th March, yes?
   A.  Yes.
   Q.  And this is the fruits of clever searches that you did
       since that time, correct?
   A.  It was a simple search for the word "completed
       retrospectively", that was the word I searched for.
   Q.  That's not the only item that you are going to address.
       All of those items are matters that you have discovered
       looking at the documents since your fourth joint
       statement, correct?
   A.  Yes.
   Q.  Do you accept that in accordance with your duty as
       an expert and as a matter of basic fairness to
       Post Office, you should have provided this material to
       Dr Worden and indicated the conclusions you were drawing
       from it before this evidence started?
   A.  Mr Worden -- Dr Worden will have this material.  These
       aren't new documents.  They are documents disclosed to
       both of us at the same time.  I haven't made a point in
       my report about these retrospective OCRs.  It was as
       a result of you asking me the question the other day
       about the process that I simply answered that some of
       them were completed retrospectively.
   Q.  That is one particular issue.  There are other issues
       which I imagine you knew very well you were going to be
       asked about when you knew you were going to be giving
       evidence, correct?
   A.  I'm not sure any of the other answers that I have got
       here could have been foreseen that I would be asked the
       question about.
   MR JUSTICE FRASER:  I'm not going to stop you, just so that
       I can get a summary, all right?
           Could either of you tell me where on the transcript
       yesterday there was a summary about what the witness was
       asked to do last night, because I have just quickly
       looked for it and I can't --
   MR DE GARR ROBINSON:  My Lord, I don't believe there was
       a discussion where we listed the specific points.  It
       was just along the way.
   MR JUSTICE FRASER:  All right.
           Mr Coyne, I'm just going to try and save some of
       Mr de Garr Robinson's time.  Last night you were asked
       to go off and do a particular series of exercises which
       you would now, please -- don't give me the answers, but
       just tell me what they were as far as you understood
       them, and I did make it clear that you had a list.
   A.  Yes.
   MR JUSTICE FRASER:  Would you like to give me the things you
       went off to do.
   A.  Yes, it was to report how many OCRs and OCPs were
       completed retrospectively.  It was to provide the
       reference to a PEAK that has been edited where the
       branch is less than 32.
   MR JUSTICE FRASER:  Yes.
   A.  It is to provide an answer to how many TIP repairs were
       conducted.
   MR JUSTICE FRASER:  Yes.
   A.  And in how many PEAKs --
   MR JUSTICE FRASER:  Sorry, have you gone onto another item?
   A.  Sorry, my Lord, I have.
   MR JUSTICE FRASER:  So that is the third item I have
       identified, answer how many TIP repairs.  The fourth
       one, please.
   A.  Fourth item, how many times do we see evidence of
       messagestores being rebuilt.
   MR JUSTICE FRASER:  Right.  Therefore at least number 2 on
       that list should be a list of references.
   A.  Yes, my Lord.
   MR DE GARR ROBINSON:  I have to say, my Lord, my
       apprehension was what he was being asked was a list of
       references of things.
   MR JUSTICE FRASER:  I understand that entirely and that's
       something that might have to be pursued in a moment, but
       at least number 2 on that list should be a list of
       references.  Have you provided anyone with that list of
       references yet?
   A.  No, but I do have that reference for that one.
   MR JUSTICE FRASER:  Right.  Well at least on that item
       Mr de Garr Robinson is entitled to a list of references.
       How many are there against that item?
   A.  I have only extracted one, my Lord, so I only have one.
   MR JUSTICE FRASER:  Why don't you give us the reference.
   A.  It is {F/377.1/1}.
   MR JUSTICE FRASER:  So that is the only reference arising
       out of your exercise of last night which has now been
       given to Mr de Garr Robinson.
   MR DE GARR ROBINSON:  And that is a reference for what?
   A.  That is a reference to a PEAK where it shows an edit
       taking place where the branch that it is modified to is
       less than 32.
   Q.  I see.  It is the only -- it is a PEAK showing an edit
       of messagestore data taking place, full stop.  That is
       the only PEAK of which you are aware that shows an edit
       of the message -- of transaction data in the
       messagestore, correct?
   A.  The question that was asked was -- sorry, the position
       that you put to me was that it is always 32 that is the
       replacement, and I said that I had seen evidence that
       that wasn't the case but I couldn't provide the
       reference and that is one of the references of that.
   Q.  Well, Mr Coyne, as I recall, and it may be my fault and
       I'm hesitant in case I might make a mistake, but my
       recollection is you were asked for the references you
       had showing an editing of transaction data or other
       accounting data within the messagestore?
   A.  Yes.
   Q.  And would I be right in thinking you are only aware of
       one and that's 377.1?
   A.  No, that's not correct.  It is only where the branch
       number is modified to be less than 32.  The process that
       was put to me is that whenever Fujitsu edits a message
       they would replace the branch with the number 32, and
       I said that that was incorrect and that I had
       an example, and that is the example.
   MR DE GARR ROBINSON:  My Lord, what I'm getting is not what
       I'm expecting and I don't believe it would be helpful
       for Mr Coyne to read out from the notes he has plainly
       obtained statements which actually aren't backed up by
       any documents at all, so can't be ascertained or
       substantiated in any way.  So subject to your Lordship,
       I'm going to leave the matter there.
   MR JUSTICE FRASER:  Well, what I don't want to do today is
       I don't want to have a detailed who had said what
       yesterday about what he was and wasn't asked to do
       because that's just going to use up too much of your
       time.
   MR DE GARR ROBINSON:  We certainly can't do that today.
   MR JUSTICE FRASER:  Whether we can or not, I'm not prepared
       to entertain that today.
   MR DE GARR ROBINSON:  I'm grateful.
   MR JUSTICE FRASER:  But so far as any other documentary
       references he has, I would like to have them, and I'm
       just going to ask you: what other documentary references
       do you have?
   A.  So, my Lord, with regard to --
   MR JUSTICE FRASER:  No, just tell me the references.  What
       are the references you have gone away and looked up?
   A.  Annex A of my second report.
   MR JUSTICE FRASER:  Okay, well that's -- yes.
   A.  Specifically it was in the section --
   MR JUSTICE FRASER:  No, that's fine.  It's annex A, I know
       where that is, I can go and look at it.  Next one.
   A.  The other two, my Lord, are numbers, a calculation of
       numbers, so I don't have the underlying documents.
   MR JUSTICE FRASER:  As in the number of times you have seen
       things?
   A.  Yes.
   MR JUSTICE FRASER:  Right.
   A.  If it would assist I can run that report and get the
       numbers out but I wouldn't be able to do that --
   MR JUSTICE FRASER:  I don't really understand what that
       means but don't worry about that.
           So Mr de Garr Robinson, are you saying that Mr Coyne
       shouldn't tell me and/or you the number of times he has
       seen these things based on what you asked him yesterday?
   MR DE GARR ROBINSON:  Where we are now, my Lord, I say he
       should not.
   MR JUSTICE FRASER:  Right.
   MR DE GARR ROBINSON:  Because it would then set all sorts of
       new hares running.  Mr Coyne might have to be recalled.
       We would be in a pretty pickle, in my submission.
   MR JUSTICE FRASER:  And are you objecting to me hearing what
       the numbers are on a de bene esse basis?
   MR DE GARR ROBINSON:  Yes.
   MR JUSTICE FRASER:  You are.
           Mr Green, what do you want to say?
   MR GREEN:  I don't want to take up time, but your Lordship
       will appreciate I don't think that is a very sensible
       way.  He was asked to do homework.  Some of the examples
       are easily identifiable on the transcript of what he was
       asked, like page 94 yesterday about 32 {Day16/94:1}, and
       he has done what he was asked.
   MR JUSTICE FRASER:  Thank you.
           Mr de Garr Robinson, on the basis you asked him, and
       you now have explained your position on his answers, I'm
       just going to hand the floor back to you, you can
       continue your cross-examination.
   MR DE GARR ROBINSON:  I'm grateful, my Lord.
           Now, Mr Coyne, yesterday you may recall that I said
       I would check something overnight?
   A.  Yes.
   Q.  It relates to the enhancement that was suggested by
       Ernst & Young during the 2012/2013 audit that the
       monitoring control to validate the proper management of
       programme changes in POLSAP and HNG-X be generated
       directly from the system, do you recall that?
   A.  Yes.
   Q.  You said you thought it was suggested in the 2011
       Ernst & Young management letter, and I asked you some
       questions on the assumption that it wasn't, saying that
       I would check and if that was an unfair assumption
       I would come back and apologise.  Well, there is
       something about it in the 2011 letter so I'm coming back
       and apologising to you, Mr Coyne.  As a matter of
       fairness I should tell you where it is.
           If we could go to {F/869/25}, please.  There is
       a heading on the left-hand side, you see "Segregation of
       duties within the manage change process".  Do you see
       that?
   A.  Yes.
   Q.  Then on the second from the right there is a series of
       recommendations.
   A.  Yes.
   Q.  And they go on.  If you go over the page to page
       {F/869/26}, there's the second bullet:
           "Implementing a change monitoring control for the
       in-scope applications whereby system generated list of
       changes made to production are independently reviewed by
       POL on a periodic basis to determine that changes have
       been authorised authorised, tested and approved prior to
       migration.  This will help POL gain assurance that
       changes implemented by third party service providers
       have been approved by POL management."
           Do you see that?
   A.  I do.
   Q.  If we go back to page {F/869/25} we will see "Management
       Comment" on the far right-hand side:
           "A Fujitsu project has been established to review
       all user management areas and is being led by the CISO
       of the RMG account."
           Do you see that?
   A.  Yes.
   Q.  If one then goes over two pages, so this section goes on
       for more than one page, {F/869/27}, the last comment in
       the "Management Comment" box is that:
           "POL is to ensure through a periodic sample and
       exception review that changes have been authorised,
       tested and approved prior to deployment."
           Do you see that?
   A.  Yes.
   Q.  This is an example where an auditor suggests one thing
       and the client comes back and indicates: I'm not sure
       I'm going to do that but I will do this other thing
       instead, which I believe you accepted but let me suggest
       it again in case I misunderstood, that that sort of
       thing happens all the time in these kind of situations,
       yes?
   A.  Yes, it does.  There are a number of other things on
       other pages which it is suggested should be done by way
       of recommendations.  But no, I do accept your position.
   Q.  The recommendation was made and it is only right that
       I should correct the position with you and give you the
       opportunity to comment.  And as I say, I am sorry
       I overlooked this yesterday.  It is a long document and
       I missed that bullet point.
           Just to put it in proper context to give you
       a proper opportunity to comment, if we could look now at
       your second report, please.  That is at {D2/4.1/195}.
           At paragraph 5.264 you said:
           "Regarding the specific recommendations in the 2011
       audit it is my opinion that the key recommendations
       directly impact on some of the 18 countermeasures
       outlined in Dr Worden's report and therefore are
       relevant to the question of robustness of Horizon since
       they offer an opportunity to improve these
       countermeasures which it appears Post Office chose not
       to take."
           So you are saying there, aren't you, that the four
       key recommendations made by Ernst & Young offered
       Post Office an opportunity to improve countermeasures
       which it did not take, yes?
   A.  Yes.
   Q.  The way I read what you are saying is that Post Office
       chose not to take any actions to improve in response to
       the four key recommendations.  Would that be a fair
       reading of what you said?
   A.  Yes.
   Q.  Now, would you suggest that that claim is justified
       because amongst the proposals made there was a proposal
       for a system-generated change monitoring process, and
       Post Office responded by indicating that it would
       enhance its monitoring in a different way?
   A.  Well, it is saying it wouldn't accept the auditor's
       recommendation but would follow an alternative path.
   Q.  Do you say that justifies the claim that Post Office
       chose not to take actions to improve in response to the
       four key recommendations made by Ernst & Young?  Because
       I would suggest to you it doesn't justify that claim,
       Mr Coyne, and that the claim is exaggerated.
   A.  I mean for clarity here, it is correct that I do make
       reference to the key recommendations --
   Q.  It is all you are talking about, isn't it --
   A.  -- of which there are four, but actually that particular
       audit does address a number of other elements.  But it
       is correct that my report does only reference the four.
   Q.  Let's move on.  Let's talk about the bugs that you have
       identified in the bug table in joint statement 2.  We
       will be referring to this a lot.  It is at {D1/2/3}.  It
       starts at page 3.
           Now, as I understand it, your analysis of all the
       available evidence has culminated in a table which is
       entitled, and we see it here:
           "Table of Bugs/Errors/Defects with acknowledged or
       disagreed evidence of financial impact."
           Would that be a correct summation of what this table
       is?
   A.  Yes.  It can't be read completely in isolation of the
       report, but it is an attempt to bring together most of
       the references from the report into one single table.
   Q.  Would you accept that it brings together all the
       references that you consider important and significant?
   A.  It may not do.  There may be references that still
       remain in the report that haven't been distilled into
       this joint statement.
   Q.  Let me ask a slightly different question.  This is the
       definitive list, isn't it?  You are not suggesting that
       there are other bugs with evidence of financial
       impact -- you are not relying on any other bugs with
       evidence of financial impact, it is just the 29 bugs
       identified here?
   A.  These are the ones that I have identified, yes.
   Q.  Thank you.  Obviously in the time available I can't go
       through all the bugs and I can't even go through all the
       PEAKs and KELs referred to for some of the bugs, but
       I can touch on a limited number.  That simple fact, that
       I can only touch on a limited number, does underline the
       importance, doesn't it, of an expert in your position
       summarising documents you are relying on accurately and
       explaining their significance fairly?  I am sure you
       would agree.
   A.  Yes.
   Q.  Let's first of all talk about some issues that you say
       are bugs.  Could we go, first of all, please, to bug 15
       which is at page {D1/2/13} of the table.  Table 13, bug
       15, "Phantom Transactions".  You will see very helpfully
       on the right-hand side of the table there are two F
       numbers, there are two documents referred to which are
       references for two PEAKs you are relying on for this
       proposition, yes?
   A.  Yes.
   Q.  Let's look, first of all, at the PEAK which is {F/48/1}
       which is PC0052025.  Before going to that, while we have
       still got the screen, it is worth mentioning that in the
       "Identified Year/Year(s) in Effect" column, those two
       bugs are referred to, one of them is August 2000 and the
       other is April 2001, is that correct?
   A.  Yes.
   Q.  So would I be right in thinking that whatever problems
       there were in 2000 and 2001 regarding phantom
       transactions, the PEAKs indicate that such transactions
       have not raised their ugly head for the last 18 years?
   A.  Yes.
   Q.  So we are just talking about the early period of
       Legacy Horizon, is that right?
   A.  With regard to this particular --
   Q.  Yes.  Let's look at {F/48/1}, please.
           There may be a problem with the system.
   MR JUSTICE FRASER:  It takes such a long time because there
       are so many documents in the folder, I'm afraid.  Where
       would you like to go?  F?
   MR DE GARR ROBINSON:  F/48.  Perhaps one way of doing it is
       if you stay on the bug table itself you can click on the
       hyperlink, which is probably what I should have
       suggested first of all.  Thank you.
           Right, let's pick it up first of all at the top of
       the page, page 1.  It happened on 14th August 2000.
       Well, actually --
   MR JUSTICE FRASER:  I think it is the 9th.
   MR DE GARR ROBINSON:  I'm so sorry, four lines down,
       9 August 2000, 9.22.  Do you see that, about four lines
       down from the top?
   A.  Yes.
   Q.  "PM informs that receipt came out of machine at 2:14pm
       and it had 3 transactions on it.  Was advised that
       transactions are cut off automatically if they are not
       finished.  P&A, BT payment card £5 and British gas bill
       payment is also showing for £5, and there is another chq
       for £43."
           Then there is an entry for later I think in the same
       day:
           "System has printed ghost transactions before, but
       not this severe."
           So we see from the size of the amounts involved in
       this call that at least some subpostmasters are
       perfectly happy to call in when they have got
       difficulties with relatively small amounts of money,
       would you agree with that?
   A.  Yes.
   Q.  And would it be fair to say you have seen a substantial
       number of PEAKs where SPMs have phoned in with problems
       about relatively small sums of money?
   A.  Yes.
   Q.  Thank you.  These are described as ghost transactions,
       and presumably that's why you have included this as one
       half of the evidence you rely on in support of the
       suggestion that Horizon had phantom transactions during
       this period, yes?
   A.  Yes.
   Q.  If we go to page {F/48/2} to 14.12, so that is three
       boxes down.  It is David Seddon from the SSC and he
       writes:
           "Messages in the messagestore confirm that the
       'phantom' transactions were due to them being in a
       suspended session that was later forcefully committed
       explained this to PM who was happy with explanation but
       she says she is sure she never pressed the suspend icon.
       Nevertheless she agrees closure for this problem.  Can
       only assume that she hit the suspend icon by accident."
           Do you see that?
   A.  Yes.
   Q.  First of all, these were transactions that were actually
       typed into the system.  They didn't appear out of
       nowhere, would you agree with that?
   A.  Yes.
   Q.  What happened, though, was that having been typed in,
       they weren't committed to the -- the basket wasn't
       committed to the messagestore.  Instead the screen was
       left for a period of time and after a certain lapse of
       time the system forcefully committed them to the
       messagestore, yes?
   A.  Without any user interaction.
   Q.  Well, that's what you say, Mr Coyne, but isn't a fair
       reading of what's in that box that the postmaster
       accidentally must have touched "suspend" with her hand
       or something with the result that the session was
       suspended for that period of time?
   A.  Yes, that's possible, but it isn't that that was the
       reference that I was making to without user interaction.
       It is the later event, the automatic commit that would
       appear to have been done automatically without a user
       being involved.
   Q.  I see.  So what you are suggesting is that if the system
       automatically commits an uncommitted basket after
       a period of time that's evidence of phantom
       transactions, that's evidence of a bug in Horizon that
       needs to be corrected, is that what you are suggesting?
   A.  Well, it is evidence of the system doing something
       without the user choosing to do it.
   Q.  Are you suggesting it is something -- it is evidence of
       the system doing something wrong?  I think you are,
       aren't you?
   A.  Yes.
   Q.  Let's look at Mrs Van Den Bogard's witness statement, it
       is at {E2/5/1}.  To save time, I would ask you simply to
       read paragraph 14.2 of her witness statement, please.
       I'm so sorry, my note says page 54.  Is it page 5?  No,
       it is paragraph 14.2 which is page 4.  {E2/5/4}.
           Could you read that paragraph, please,
       paragraph 14.2.  (Pause)
   A.  Yes.
   Q.  So this isn't evidence of Horizon going wrong, is it?
       It is evidence of Horizon doing what it has been
       designed to do.  Yes?
   A.  It would appear from what's been said here that that was
       the design, but I can completely understand the user's
       concern.  They hadn't committed the transaction and they
       might not have wanted to commit the transaction --
   Q.  It is a standard security measure in many IT systems,
       measures of this kind, isn't it?
   A.  Yes, it is.  It suspension of the user session is
       certainly standard.  A roll back of any work in progress
       would be a standard.  I have not seen one in a retail
       environment or a banking environment where it will
       actually complete a transaction that the user didn't
       choose to complete just because they weren't at their
       screen.
   Q.  And the receipt -- the system prints a receipt so that
       the postmaster knows what has happened and if there is
       a problem the postmaster can then reverse the
       transaction, correct?
   A.  Yes.
   Q.  That's what the system is designed to do.  The system
       has to decide whether just to delete the entire session
       from the system or to commit it.  Either way a design
       choice has to be made, and either way what's important
       is that the subpostmaster knows what happens, and this
       system is designed to give the postmaster that
       information by printing out a receipt, correct?
   A.  Yes.
   Q.  Right.  And you knew that, didn't you, when you included
       this PEAK as a phantom transaction bug in your second
       report?
   A.  No, I don't believe I did.  No.
   Q.  Well, let's have a quick look at that just to see.  It
       is at {D2/4.1/114}.  Do you have the page?  Under the
       heading "Angela Margaret Van Den Bogard" it says, 4.69:
           "Mrs Van Den Bogard has provided a witness statement
       commenting on individual cases and various disparate
       factual matters, which I do not attempt to comment on in
       detail here.  I note the following discrete points."
           Then under the heading "Phantom Transactions", you
       say {D2/4.1/115}:
           "I have seen evidence of phantom sales recorded in
       the disclosed documents.  PEAKs PC0065021 216 and
       PC0052025 ..."
           Which is the one we are just looking at?
   A.  Yes.
   Q.  "... (documented in further detail at section 3,
       'Phantom Transactions (Horizon Issue 4)' above) refer to
       phantom transactions in branches, the former which was
       observed by an engineer on site at the branch and the
       latter which refers to discrepancy arising from them."
   A.  Yes.
   Q.  So you did know what Mrs Van Den Bogard was saying
       because you identified this very PEAK when you were
       responding to that very evidence?
   A.  Yes.
   Q.  It is completely wrong, isn't it, Mr Coyne?
   A.  My understanding is now that it would appear that it is
       a design feature, that that happens.
   Q.  If you don't mind my saying so, Mr Coyne, you appear to
       be rather evasive.  What I have just shown you is that
       Mrs Van Den Bogard set out quite clearly in a witness
       statement how the system was designed to operate, and it
       was designed to operate in a way that committed
       transactions that were left on the machine for a certain
       amount of time and a receipt was printed so the
       postmaster knew what had happened?
   A.  Yes.
   Q.  And you responded to that by saying, well, I have got
       some evidence of phantom transactions and half of the
       evidence, one of the two PEAKs you rely on for that
       purpose, is a PEAK which actually demonstrates the truth
       of what Mrs Van Den Bogard is actually saying, doesn't
       it?
   A.  Certainly one of the two examples it would appear that
       it is operating in line with the design, but I can
       certainly understand how a user would perceive that that
       would be a phantom transaction because they didn't
       complete it --
   Q.  Mr Coyne, if we were looking at a table which was a
       table of areas where users might get confused, then we
       wouldn't be having this conversation.
   A.  Mm.
   Q.  We are having this conversation because you have added
       this piece of evidence as evidence in support of the
       proposition, firstly, that there are bugs in Horizon
       and, secondly, that they cause losses, lasting losses to
       postmasters.  That is right, isn't it?
   A.  Yes.
   Q.  And you agree now, do you, that this PEAK is not
       evidence either of a bug or of the causing of a lasting
       loss to a postmaster?
   A.  I do agree.
   Q.  Thank you.  So I then come to my final question which is
       how is it you came to include this PEAK both in your
       report and even in the bug table here on page 13?  Did
       you not read the PEAK properly?
   A.  Yes, I did read the PEAK properly, possibly not in full
       consideration of the witness statement of Ms Van Den
       Bogard.
   Q.  But you cited the PEAK in response to her witness
       statement.
   A.  I did.
   Q.  So you must surely have had it in mind when you were
       choosing those two PEAKs to refer to.  Would I be right
       in thinking -- would an outsider be right in thinking
       that you were anxious to find evidence in support of the
       hypothesis that Horizon generates phantom transactions
       and you saw a very helpful reference at the top of the
       first page and you thought, I'll have that, let's put it
       in.  And you then included it in your second witness
       statement and you have included it in your bug table.
       Would it be reasonable for an outsider to form that
       impression?
   A.  I would certainly have taken it from my report and put
       it into the joint statement table, yes, that would be
       the case.
   Q.  Did you not check the PEAKs -- before you lifted the
       PEAKs from your report and put them in the bug table did
       you not check them, review them, to make sure that they
       really were good evidence of the propositions for which
       you were citing them?
   A.  The process that I followed with Dr Worden is we went
       through our respective reports, put the text in where it
       was a shared text or separate text, and then in order to
       assist the court we put as many relevant references as
       possible from our reports into this table.  That was the
       purpose of that.  And it would appear that rather than
       validating each of the references in the report before
       putting them in the table I have lifted the references
       out of the report and put them in the table.
   Q.  So you didn't check them?
   A.  I haven't checked each and every reference -- I checked
       the references in the report, before they went in the
       report, but I haven't re-checked and opened all the
       documents before we put the references in this
       "Supporting Evidence" column.  This is a shared column,
       the "Supporting Evidence" column at the end.  You will
       see that Dr Worden has put some references in there and
       I have put references in there.
   Q.  Yes, but you are not suggesting that Dr Worden has
       suggested the inclusion of F197, are you?
   A.  No.
   Q.  Thank you.  Let's go to the other PEAK you rely on.
           In the bug table at {D1/2/13}, you say:
           "Whilst no specific branch account discrepancies are
       noted, many events recorded in the PEAK PC0065021
       suggesting multiple 'Phantom Transactions' at branch
       during the period of 14th April 2001 to 12th November
       2001.  It is therefore possible (with the unpredictable
       nature of Phantom Transactions) that branch accounts
       could have been impacted.
           "Observations recorded on 19th June 2001 by
       Fujitsu's Patrick Carroll, 'I now have pressing evidence
       to suggest that unwanted peripheral input is occurring,
       the likely source being the screen… I have observed
       system activity corresponding to screen presses
       happening with no corresponding [sic] evidence of either
       routine system activity or human interference."
           So that's what you say about that PEAK in the bug
       table?
   A.  Yes.
   Q.  Let's have a look at the PEAK.  It is at {F/97/1}.
       Before I ask you a question about that, I'm reminded,
       Mr Coyne, that you already knew that Horizon false
       commits transactions which are in a counter for
       a substantial period of time.  You say that in
       paragraph 3.151 of your second report, do you remember
       doing that?
   A.  I would have to go back and refresh myself.
   Q.  It is at {D2/4.1/56}.
   MR JUSTICE FRASER:  I think the passage that you have just
       been asked about is at the top of {D2/4.1/57}.  So 56
       and 57.
           You say at the top of page 57:
           "It appears that Horizon will, after periods of
       inactivity ultimately commit transactions a
       Subpostmaster has not fully completed themselves."
           Actually you say that in relation to, if you look at
       3.150, the very PEAK we have been looking at
       {D2/4.1/56}.  So that makes your inclusion of this PEAK,
       as an example of a bug causing a subpostmaster losses,
       that makes it even more curious.  You did write both
       section 3 and section 4 of the report, I am sure?
   A.  I did, yes.
   Q.  I would not even suggest to you otherwise, Mr Coyne.  So
       how is it that you came to such inconsistent results in
       two different parts of the same report?  Can you
       explain?
   A.  Yes.  It is a mistake to include that as a reference as
       an example for that phantom transaction.
   Q.  So let's go back to {F/97/1} and if we pick it up on
       page {F/97/4}.  It is a very long PEAK.  It is a big
       yellow box on page 4 and about perhaps a little less
       than a third of the way down there is a date 30/4/01,
       14.12.  Do you see that?
   A.  Yes, I do.
   Q.  We have got:
           "Information: Romec attended site 23/4/01 carried
       out inspection and testing and report no fault found
       with the Horizon circuit."
           Just for the record, who is Romec?
   A.  I believe Romec are hardware engineers, or communication
       engineers.
   MR JUSTICE FRASER:  Mr de Garr Robinson, I'm sorry,
       I haven't found that part.
   MR DE GARR ROBINSON:  It is 18 lines down.
   MR JUSTICE FRASER:  Ah, yes.  It is just that there are two
       entries at 30/04/01 and the other one is a bit further
       down, out of chronological order.
   MR DE GARR ROBINSON:  It is at 14.12.  And if you go down to
       just after the bottom third of the same page, there is
       01/05/01 at 10.56, do you see that?
   A.  Yes.
   Q.  It says:
           "Information: Romec are contacting the site to let
       them know that they will be attending site 2/5 to fit
       suppressors and double sheet flyleads, in order to help
       the enviromental fault."
   A.  Yes.
   Q.  I am sure you will recall that all sorts of
       environmental tests were done at this particular site to
       see if the environment was responsible, yes?
   A.  Yes, and certainly the fitting of suppressors and
       sheeted flyleads would suggest that that's what they
       suspected.
   Q.  It is fair to say from reading the PEAK as a whole -- we
       don't have time to go through it all -- that the
       investigations that Fujitsu carried out were very
       thorough, weren't they?
   A.  Yes.  I think they ultimately determined they could not
       decide what the fault was but the process seemed to be
       a reasonable process to go through.
   Q.  And they sent engineers from Romec.  Do you know what
       Romec's familiarity with the system is?
   A.  I would suspect that they know the hardware and the
       communication equipment very well.  I don't know if they
       will know how Horizon as a software product would work.
   Q.  That is a very fair answer.  You saw where I was going
       and that is a very fair answer, Mr Coyne.  They might
       very well know how to set the system up, make sure
       everything is connected and see that everything is
       logged on properly, but when it comes to the internal
       workings of the system itself they may well not be
       familiar, yes?
   A.  Yes.
   Q.  Thank you.  Anyway, they were sent to inspect and test
       the circuit and improve the cabling.  We have already
       gone to the reference I was taking you to.
           If we go to page {F/97/5}, which is 2/5/01, at
       14.12.  "Information".  That's about a third of the way
       down, my Lord.  Does your Lordship see it?
   MR JUSTICE FRASER:  Yes.
   MR DE GARR ROBINSON:  02/05/01, 14.12.
   MR JUSTICE FRASER:  With "UK052436" next to it?
   MR DE GARR ROBINSON:  Yes.
           "Information: Romec have been to site today and
       fitted shielded cabling and suppressors.  Romec engineer
       advises that he has witnessed further phantom
       transactions whilst on site.  He will carry out further
       tests and advise results."
           So there is the Romec engineer seeing phantom
       transactions?
   A.  Yes.
   Q.  That's the visit that's referred to in the quote that
       I have read out from the joint statement, isn't it?
   A.  Yes.
   Q.  So the engineer comes in, he logs the system off, he
       fits the suppressors and whatever else he needs to do,
       then logs on again.  And while he was there he saw what
       are described as phantom transactions, yes?
   A.  Yes.
   Q.  They could equally be described, I suppose, as ghost
       transactions, couldn't they?
   A.  They could be, yes.
   Q.  The reason why I ask that question is because we have no
       idea what he saw and we have no idea whether he
       misinterpreted something, do we?
   A.  We don't, but it would be reasonable to assume that
       an engineer whose particular role it is to service
       Horizon equipment, whilst he wouldn't know how to
       operate Horizon in detail, would have a reasonable
       understanding of how it would work.
   Q.  Maybe, Mr Coyne, another counter hadn't been used for 59
       minutes, it had uncompleted transactions on it, and it
       automatically completed them and printed a receipt.
       That is possible, isn't it?
   A.  That is possible.
   Q.  And it is possible that an engineer with his familiarity
       of the hardware would not know that feature of the
       operating system of Horizon, so he might be surprised by
       that, correct?
   A.  He might be surprised by that.  But I think we have got
       to read this in context, that the subpostmaster had
       already explained that they perceived that there were
       problems with what they said was phantom transactions.
       So Post Office and/or Fujitsu would have gone through,
       I would presume, their support process, would have
       looked at various logs and things like that before
       dispatching a hardware engineer to site.  So if they
       suspected that it was just the simple case of a counter
       coming to the end of its 59 minutes of suspension and
       doing something automatically, I think they would have
       dealt with that before dispatching an engineer.
   Q.  We can agree, Mr Coyne, that the SSC had experience of
       these things and they had access to information that we
       don't have.  We can agree on that.  But just focusing on
       the Romec engineer visit, would you not accept that it
       is quite possible that the engineer saw something which
       was an example of Horizon operating as it should and was
       not in fact a phantom transaction at all, and he
       misinterpreted it because he didn't have the familiarity
       with the system that someone at Fujitsu might have?
       Would you accept that that was at least possible?
   A.  I accept that it was possible if you look at that visit
       in isolation, yes.
   Q.  And then what we know is that there are further
       investigations for some months and Mr Carroll is
       involved from at least 4th May, I think.  You see his
       reference.  If you go down to the bottom of page 5, you
       see 04/05/01 at 9.30?
   A.  Yes.
   Q.  "information Ki Barnes has called in.  I am unsure as to
       what to do with this call now.  Romec have been to site
       and state that they have actually seen the phantom
       transactions, so it is not just the PM's word now.  They
       have fitted suppressors to the kit but the PM is still
       having problems.  As yet there has been no recurrence to
       the phantom transactions but there still may be
       problems.  Contacted Pat Carroll for guidance."
           So it is fair to infer, isn't it, that Pat Carroll
       was someone very experienced and more senior in the
       organisation?
   A.  Certainly his name appears on a number of documents that
       I have seen.
   Q.  And it is fair to assume, isn't it, that he is in a good
       place, with the information and the experience that he
       has, to form a judgment as to what the likely cause of
       these problems are, yes?
   A.  Yes.
   Q.  Well, the matter goes on for some months and there are
       further investigations.  If I could pick it up in
       November now at page {F/97/9}.  If we go to the bottom
       of the page, 12/11/01, at 9.48.  This is Patrick Carroll
       himself:
           "Phantom Txns have not been proven in circumstances
       which preclude user error in all cases where these have
       occurred a user error related cause can be attributed to
       the phenomenon."
           {F/97/10}:
           "I am therefore closing this call as no fault in
       product."
           Now, given Mr Carroll's experience and the
       information he has available to him, and given that as
       you have yourself fairly acknowledged this phantom
       transaction problem hasn't re-appeared since
       November 2001 in any PEAK, would it be fair to suggest
       that the best judgment to trust in relation to what was
       going on here is Mr Carroll's judgment?
   A.  Certainly Mr Carroll would have access to all the
       information that should allow him to determine the
       position.  One thing that I do note from that, there is
       no reference to looking at the audit logs or the ARQ
       data which may well have confirmed what was going on
       while the Romec engineer was on site and would almost
       certainly document whether the recovery from
       a suspension, as we talked about before, actually
       happened at that time, and I don't believe that this
       document reflects that that investigation was conducted.
   Q.  Nonetheless, Mr Carroll formed the judgment that he did.
       Do you think that adopting a balanced approach when
       explaining this PEAK in your expert report at some
       length, for example, it would have been helpful to have
       included his conclusion at the end of the PEAK as well
       as including the earlier passage that you quote in the
       joint statement?
   A.  I don't believe that would be required.  The reference
       to the PEAK is there.  There's lots of detail in that
       PEAK that --
   Q.  But haven't we already agreed several times, Mr Coyne,
       that given that so many documents, I mean a mass of
       documents -- if you try to weigh all the documents you
       refer to in your two reports it would probably come to
       something close to my own body weight, and that's saying
       something -- it is simply not humanly possible to read
       all the documents you refer to in your report or at
       least not in a limited amount of time, and in those
       circumstances wouldn't it be helpful, given that we are
       all relying on your report for a fair summation of the
       document, wouldn't it be helpful and fair to have
       included the passage at the end of the PEAK which is
       less helpful to your analysis as well as the passage in
       the middle of the PEAK which is, you consider, helpful
       to your analysis.  Do you not think that would have been
       an appropriate and fair thing to do?
   A.  I don't.  I accept that it would be an enhancement to
       the report but I would not know where to stop if we keep
       including all aspects of all documents that are
       referenced.
   Q.  I have got one suggestion for you, Mr Coyne.  Why not
       try and avoid stopping when you have mentioned the bad
       points?  Why not try and carry on so that you can
       mention some points for balance as well?  Do you not
       think that would be a good idea?
   A.  Yes.
   Q.  Because in your report wouldn't it be fair to say that
       that tends to be what you have done?  In many cases, you
       have mentioned the bad things arising from the document
       or what you perceive to be a bad thing, a critical thing
       in Horizon arising from a document, but you don't
       trouble yourself to mention any of the other points that
       may be mitigating or maybe positive?
   A.  No, I don't think that's fair at all.  I think you have
       been able to point me to this example but I do not think
       that's fair at all.
   Q.  And one other final question.  Do you think you are in
       a position now, in 2019, looking at this PEAK nearly
       18 years ago, to say that Mr Carroll, with the
       familiarity he had with the system and with the
       information that he had at his fingertips, he must have
       been wrong in his attribution of the cause for the
       difficulties experienced at this branch?
   A.  I think with the ARQ data you would be able to determine
       what the position was.
   Q.  That wasn't my question, though, was it?  My question
       was do you think you now, with the information you have,
       are in a position to say that Mr Carroll was wrong?
   A.  No.
   Q.  Thank you.  I suggest to you none of us are in that
       position.  It is impossible at this remove in time and
       on the information available to us to come to any view
       as to whether this was a phantom transaction or not,
       would you agree with that?
   A.  What I can say is that on balance, because it has been
       reported by a subpostmaster, and then somebody with
       technical knowledge says that they have observed it as
       well and that there hasn't been a full examination done
       by Pat Carroll of the data, then I believe that it could
       well be the case that it is a phantom transaction.  But
       I do accept the position that we don't know today.
   Q.  Let's talk about a different bug.  Bug 11, Girobank.  If
       we could go back to the bug table at {D1/2/9}.
           There are just too many documents for me to go
       through, it would take hours.  Perhaps first of all you
       could explain what Girobank transactions are, just to
       set it up.
   A.  I'm just going to go back to my report.
   Q.  You don't remember.  It is impossible to know everything
       about this system at every single time.  By all means go
       back to your report, Mr Coyne.
   A.  Yes, it is about the timing of the various aspects of
       the process of a Girobank transaction.
   Q.  And a Girobank transaction is?
   A.  It is similar to a retail banking function.
   Q.  Okay.  Would it be fair to say that you are not really
       familiar with what Girobank transactions are?
   A.  I'm just trying to recall the details of it now.
   Q.  Anyway looking at the bug table, if we look at column 3,
       "Identified Year/Year(s) in Effect", the period
       identified is May to September 2000?
   A.  Yes.
   Q.  So again very early days in Legacy Horizon?
   A.  Yes.
   Q.  Would it be fair to say that whatever problems there
       were in 2000, they hadn't manifested themselves in any
       PEAKs or KELs since then?  Would that be fair?
   A.  That is right, yes.  Sorry, there is one over the page
       which is dated 2001 {D1/2/10}.
   Q.  Yes, you are quite right.  So it is 2000 and 2001.  Now,
       there is a KEL in the right-hand column, A Chambers, on
       page 10, 4410R?
   A.  Yes.
   Q.  Which is the reference to -- we are not going to it --
       actually I don't have it, the reference isn't written
       down here.  Anyway, I won't go to it.
   MR JUSTICE FRASER:  Sorry, I can't see where that is, I'm
       afraid.
   MR DE GARR ROBINSON:  My Lord, if one goes to page 10, under
       the "Supporting Evidence" column on the right-hand side,
       just above "Coyne Supplemental Report", there are two
       KELs, M Wright --
   MR JUSTICE FRASER:  Yes, I have got it.
   MR DE GARR ROBINSON:  -- and A Chambers 4410R.
           You talk about that KEL in your report.  And if we
       could look at your report, please, it is {D2/4.1/50}.
           3.126:
           "The KEL related to this PEAK you are talking about
       is documented as 'AChambers4410R', this KEL does not
       appear to have been disclosed ..."
           That's why it doesn't have an F number.
           "... therefore it has not been possible to ascertain
       what advice might have been given ..."
   A.  Yes.
   Q.  If you go up in the earlier table at the top of the page
       you will see that there is a reference to a PEAK.
   A.  There's reference to a number of PEAKs.
   Q.  Sorry, if you look at 3.127 below, I'm a bit confused:
           "Further associated PEAKs that reference [that KEL]
       are provided in the table below."
           I would like to ask you about those.  It is the PEAK
       on page 51.  It is PC0076065 at {F/118/1}.  If we could
       look at that please.  I should, for completeness,
       actually read out what you say immediately below that
       table.  This is in 3.128, we don't need to go back to it
       on the transcript -- on the machine:
           "The above PEAKs related to Girobank discrepancies
       are clear examples of bugs within Horizon that affect
       branch accounts by way of a financial discrepancy and
       illustrate, by their interlinking natures, the
       complexities of the PEAKs/KELs."
           So what you are saying there is that the PEAKs
       referred to in that table are clear examples of bugs in
       Horizon that affect -- that create financial
       discrepancies in branch accounts, correct?
   A.  Yes, I'm referring to the PEAKs within this section, not
       just that particular table.  If you read up, there is
       a table there and there is a table before it.
   Q.  What I'm seeking to elicit from you, Mr Coyne, and
       I think you have confirmed it, is that it is your
       contention, your judgment, your expert opinion that
       {F/118/1} is a clear example of a bug which has caused
       a financial discrepancy in a branch account?
   A.  The text in my report is:
           "Giro deposit cut off ... Branch unknown."
           So a number of other ones in the table actually list
       the discrepancy.  That one doesn't list the discrepancy
       next to it.
   Q.  Let's look specifically at what you say in
       paragraph 3.128 then.  It is {D2/4.1/51}.
       Paragraph 3.128 says:
           "The above PEAKs related to Girobank discrepancies
       are clear examples of bugs within Horizon that affect
       branch accounts ..."
           "The above PEAKs", they include all of those PEAKs
       in that table, don't they?
   A.  Yes.  If you go back a page you will see --
   Q.  Mr Coyne, I just want to ask you about F/118 and what
       I'm suggesting to you is in your report -- and I didn't
       think this would be controversial -- you are claiming
       that, amongst others, F/118 is a clear example of a bug
       in Horizon causing branch discrepancies.  That is what
       you say in your report, isn't it?
   A.  That is one of the PEAKs that's included in the tables
       on the preceding pages, yes.  The text for that one that
       has been provided doesn't necessarily indicate that for
       that one there is a discrepancy.  Some of the other
       items in the table I do clearly say that there is
       a discrepancy.
   Q.  So I had read paragraph 3.128 as making a claim that all
       the PEAKs you refer to in this section above, not only
       in the table but in the earlier table as well, were
       PEAKs that clearly created discrepancies in branch
       accounts.  Are you now saying that that PEAK didn't?
   A.  If you read paragraph 3.127 {D2/4.1/50}, what that is
       saying there is at the top of the page there is a table
       with all the discrepancies that are listed next to the
       particular branches.  What 3.127 says is that the PEAKs
       above reference a KEL called Anne Chambers, so that is
       the link, and by searching for "Anne Chambers" you find
       the PEAKs below.
   Q.  Yes.
   A.  So they are a different set of PEAKs that reference
       Anne Chambers, but it is the --
   Q.  Mr Coyne --
   A.  Sorry, it is the table at the top of page {D2/4.1/44},
       at the head of it, which are the PEAKs with the
       discrepancies in.
   Q.  So when you say "The above PEAKs", you are not actually
       referring to the table below 3.127, you are just
       referring to the table below table 3.123, are you?
   A.  Yes, and that is introduced at 3.127.
   Q.  Mr Coyne, this is amazing.  You are clearly -- when you
       say in paragraph 3.128 -- I can't believe I'm having
       this discussion.  When you say in 3.128 {D2/4.1/51}:
           "The above PEAKs related to Girobank discrepancies
       are clear examples of bugs within Horizon that affect
       branch accounts ..."
           The bugs in the table below 3.127 include bugs
       relating to Girobank?
   A.  Yes, but you have to read the paragraph before that
       table to understand what that table is.  It clearly says
       {D2/4.1/50} --
   Q.  All right.  All right.
   A.  "Further associated PEAKs ... are provided in the table
       below."
           They are PEAKs that are associated by way of KEL to
       those Girobank transactions.
   Q.  I see.
   A.  The PEAKs that mention the discrepancies are clearly set
       out in the other table --
   Q.  I see, so --
   A.  -- which essentially is above, it is just over the page.
   Q.  So you accept then that {F/118/1} isn't a bug which
       creates discrepancies in branch accounts?
   A.  No, it is linked by way of KEL; the Anne Chambers --
   Q.  Why do you mention it in your report then?  What is its
       relevance to the subject that you are considering, which
       is bugs creating discrepancies in branch accounts?
   A.  Because the bugs that create the discrepancies in branch
       accounts, many of them reference the KEL Anne Chambers.
       So they cite that as being the cause of the problem.  So
       what I have then done is I have searched for other PEAKs
       which also reference Anne Chambers and I found these
       others in that table, so I'm providing them.
   Q.  Even though they don't -- they are not bugs that
       actually create discrepancies in branch accounts?
   A.  Yes, but I don't actually say that they do.  It is quite
       clear what I'm saying in 3.127, and a few moments ago
       you were critical for me leaving out things, so here is
       an example where I haven't left something out, I have
       put it in for context.
   Q.  We can save some time then.  You accept that {F/118/1},
       or the PEAK that is referred to there, isn't a bug at
       all, don't you?
   A.  I have described it here as a cut-off issue, branch
       unknown.  So it likely isn't a --
   Q.  Do you remember the PEAK?  It is to do with -- could you
       remind the court what cut-off means?
   A.  It is the end of a time period, so it is after a certain
       point in the evening.
   Q.  Yes.  And what's the significance of that point in the
       evening?
   A.  That the submission has to be conducted before that.
       Anything that's conducted after that I think is shown as
       being the following day.
   Q.  Submission to whom?
   A.  Girobank.
   Q.  So there is a time in the evening when a report is sent
       to Girobank of all the Girobank transactions in one day?
   A.  Yes.
   Q.  And that report will contain all the Girobank
       transactions that have been undertaken up to that point
       in time?
   A.  Yes.
   Q.  We can save some time, we can go to the PEAK if you
       want, but this PEAK was a PEAK where the postmaster had
       done a report which -- in fact he did two reports.  He
       did one report, and then he did another Girobank
       transaction, then he did another report.  And when he
       looked at the first report he saw that the later
       Girobank transaction that he had done wasn't included
       and he was confused so he phoned the helpline and the
       helpline put him through to the SSC.  Because the
       helpline, when they reach a point where they don't think
       they can help someone, that's what they do, isn't it?
   A.  Yes.
   Q.  They will just pass it straight through.  They don't
       form some Olympian judgment as to whether it is
       a software error or not, they work out whether they can
       help the caller and, if they can't, they then just pass
       it on up the chain.  Would you agree with that?
   A.  I would indeed.
   Q.  So they passed it on up the chain to the SSC and the SSC
       looked, I believe it was Mr Roll, actually.  Yes, it was
       Richard Roll.  And they saw that the postmaster had been
       looking at the wrong report, and as a result of looking
       at the prior report he had confused himself.  So it was
       closed as a category 62, no fault in product.  That
       wasn't a bug at all, was it?
   A.  No.  And as I fairly say here, it is a cut-off issue,
       branch unknown.  But contained within that PEAK, that
       call, someone has put the reference to Anne Chambers
       4410R because they considered it would be another
       occurrence of the Girobank defect which caused the
       discrepancy, so that is why I have referenced it in this
       report.  But it is in a different table and made very
       clear that it is just another PEAK that references that
       Anne Chambers, it's not the --
   Q.  Forgive me, Mr Coyne, but speaking as someone who has
       read your report over a number of deathless hours, and
       the same could be said about all the reports in this
       case, it has to be said, the strong impression that
       a reader might get from this report is that these
       paragraphs are a catalogue of problems arising in
       Horizon and the table that you include underneath 3.127
       adds to the impression of a catalogue of problems
       arising in Horizon.  Would you accept with me, on the
       basis of the account I have given of {F/118/1}, and
       I appreciate I haven't taken you to it, but would you
       accept it from me that F/118 is not any kind of problem,
       and to the extent that your report gives that impression
       it gives a false impression?
   A.  Yes, I accept that that is not a record of a defect, but
       I believe you were mistaken when you read my report
       because this section is quite clearly introduced at
       3.127 to say:
           "Further associated PEAKs ..."
           Are associated with this KEL.  And in the right-hand
       box of the observations, none of them do they say
       "discrepancy", but on the table above, where I have
       managed to work out a discrepancy, I have put it in the
       box.
   Q.  Let's go back to the bug table at page 9 where you talk
       about Girobank discrepancies {D1/2/9} and let's pick up
       the first one you mention in the right-hand column,
       which is PC0044232, and that's at {F/25/1}.  Let's go to
       it.
           At the bottom of page 1 -- let's pick it up at the
       top.  5 May 2000.  It is reported on 4 May:
           "System error.  Girobank said there was
       a discrepancy on the Giro figures."
           So it looks as if this was called in by Girobank
       itself, yes?
   A.  Yes.
   Q.  Go down three lines:
           "Girobank have been in touch to say that there is
       software problem as the figures are not correct.  Daily
       figures when totalled are more than the cash account
       giro figures."
   A.  Yes.
   Q.  Then an example is given:
           "These are for the Giro payments only.
           "The PM has checked all dockets and all reversals
       that may have been done and cannot find anything
       therefore he would like this investigated ..."
           Do you see that?
   A.  Yes.
   Q.  Let's go down to the bottom of the page at 5 May at
       15.02.  Mark Wright says:
           "This difference (£505.72) between the Cash Account
       and the Daily reports is explained by
       KEL:MWright531P.htm. There was a giro for this amount
       that was entered on the 13th Apr then reversed AFTER
       cutoff then re-entered again and reversed again."
           Which is a very strange series of events.
           "The daily report would have shown the original
       £505.72 but the daily reports never show reversals."
           Do you see that?
   A.  Yes.
   Q.  That explains why Girobank phoned in.  That is not
       a fault with the system, is it, that is how it is
       designed to operate, would you accept that?
   A.  I'm not sure, because it does say below that:
           "It would be nice to close the call as known error,
       however while investigate the messagestore I have
       identified another problem ..."
           This does appear to indicate that there is a system
       problem.
   Q.  Okay.  Let's go on with it:
           "It would be nice to close the call as known error,
       however while investigate the messagestore I have
       identified another problem ... there is a Giro Deposit
       for £81 (1-17240) that is being calculated in TWO
       consecutive cutoffs (18th AND 19th April).  I have
       attached the full message store as evidence, however the
       error happens in message 3-8932 where the tidemark SEQ
       number (117240) which in this case relates to counter 1
       is GREATER than the Mark calculated for counter 1 in the
       same message."
           I don't pretend to understand that but you can see
       he has seen a symptom.
           {F/25/2}:
           "It would appear that the report calculation uses
       this SEQ number along with the PreviousMark numbers to
       generate the total.  As this number was larger than the
       current mark, it would also be included in the following
       days report."
           So that is what he explains as happening.
           Now, can we agree that the problem here was a fault
       in the report that went through to Girobank?
   A.  Well, it was a problem that occurred in Horizon that
       resulted in information being sent to Girobank that was
       incorrect.  We can certainly agree on that.
   Q.  Can we agree that the fault was in the report that went
       to Girobank, it wasn't a fault that manifested itself in
       the branch accounts.  It manifested itself in the
       figures that Girobank saw, not in the figures the
       postmaster saw, because the postmaster says on page 1:
           "The PM has checked all dockets and all reversals
       ... and cannot find anything ..."
           He doesn't see anything wrong.  Do you see that?
   A.  Yes.
   Q.  So would you accept that on a fair reading of this PEAK,
       this is a problem that relates to the transmission of
       information through to Girobank, it is not a bug that
       directly causes a discrepancy in branch accounts?
   A.  Yes, but any discrepancy can well have an impact on
       branch accounts and that's why it is important that
       these are highlighted.
   Q.  Well, I fully agree that it is important that these
       issues are fixed, Mr Coyne, but there are two points,
       aren't there?  First of all, this is being presented as
       a bug that creates a discrepancy in branch accounts and
       I think we have agreed that it doesn't.  Yes?
   A.  But the support guys here say there is a discrepancy.
   Q.  It is a discrepancy in the report.  It is a discrepancy
       between the report sent to Girobank and the true figures
       in the branch accounts.
   A.  So then that is a discrepancy.
   Q.  Yes.  So that is the first point.  It is not a bug which
       has actually caused a discrepancy in branch accounts, is
       it?
   A.  I struggle to understand why that wouldn't be the case.
   Q.  Before you said, Mr Coyne, a problem with the report
       going to Girobank is still a problem because then there
       is a reconciliation error and that could result in a TC
       being created.
   A.  Yes.
   Q.  But if there is a problem I would like to suggest to you
       that the evidence of this PEAK indicates that that's
       what the problem would be, yes?
   A.  Yes.  If this fault hadn't been reported by somebody,
       this would have likely resulted in a TC.
   Q.  You see, that's where I come to the second point,
       Mr Coyne.  It was reported, the problem was spotted.
   A.  Yes.
   Q.  There was a reconciliation problem and it went straight
       to the SSC, and the SSC worked out what the cause of the
       problem was.  Do you accept that what this PEAK shows is
       not a threat to the robustness of Horizon, actually it
       shows the operation, the good and effective operation of
       countermeasures to possible threats to Horizon, do you
       see?
   A.  I do, but it is a little obvious that what we are
       looking at is PEAKs, so we will only see the times that
       somebody calls in and it is recorded.  We won't have
       records if somebody hasn't reported it.
   Q.  You are not suggesting, are you, that where there is
       a reconciliation exception between a financial
       institution and Horizon, that that doesn't result in
       an investigation.  Surely you do accept that?
   A.  It should result in an investigation.
   Q.  Fujitsu has elaborate processes designed to identify
       reconciliation exceptions, doesn't it?
   A.  I don't know whether it would be Fujitsu or Post Office
       or who will do that element of it, but they will be
       Post Office's clients.
   Q.  My suggestion to you, Mr Coyne, is that what this report
       is evidence of is the robustness of Horizon, it is not
       evidence that undermines that robustness, would you
       accept that?
   A.  This is evidence of a defect being identified and
       because it was picked up there wasn't -- or if
       Post Office handled the next stage of it, then there
       needn't be an impact on branch accounts.  So there is
       a discrepancy that's here, but it is the next stage, but
       we don't have evidence of what that next stage would be.
   Q.  What we do have in this PEAK is evidence of the problem
       being raised and being properly diagnosed and resolved.
       Surely you accept that in this particular case?
   A.  Yes.  It actually says someone is going to send
       a request to the EPOS development team, so that's the
       point of sale development -- so new code is going to be
       created and that will hopefully fix the problem for the
       future.
   Q.  But also the underlying discrepancy in the report sent
       to Girobank, that's also supported.  That is the
       starting point of the entire inquiry.  This is
       an example of the robustness countermeasure, RDS and
       MID, operating as it should, would you agree with that?
   A.  What do those two stand for, sorry?
   Q.  Redundant data storage and manual inspection of data.
   A.  What does redundant data storage --
   Q.  It means where you have -- I thought you'd agreed that
       this was a standard form of countermeasure in IT
       strategies --
   A.  No, sorry, with regard to this PEAK I'm just trying to
       understand why redundant data storage --
   Q.  It means where you have the same information stored in
       different parts of the system and in different systems
       and then processes which involve the comparison of that
       data to see if there's any discrepancy requiring
       investigation, yes?
   A.  This actually required Girobank to pick up on the
       problem.
   Q.  Yes.  I don't know whether it required it, but the fact
       it there was a problem and it was picked up because
       people look at the figures that they get.
           Do you not -- are you not willing to accept that
       this is an example of the fact that if lots of different
       versions of information are propagated through a system,
       and lots of people are looking at that information, that
       actually increases the likelihood of any problems in any
       data being identified and resolved successfully?  Do you
       not accept that this is an example of that happening
       quite well?
   A.  Yes, but this is an example of Horizon doing it.  This
       is Girobank that have picked up on this.  So the
       information has flown through Horizon, not been picked
       up, gone to Girobank, and Girobank have picked up on the
       problem.  So, yes, their systems must be quite good to
       pick that up, but Horizon effectively should have
       stopped this before the figure went to them, surely.
   Q.  Let's move on to another bug.  In your table --
   MR JUSTICE FRASER:  Just before you do, can I have the trial
       references for two KELs, please?
   MR DE GARR ROBINSON:  My Lord, the two KELs, they are so old
       they don't exist anymore, I believe.
   MR JUSTICE FRASER:  They don't exist anymore.  Right.
   MR DE GARR ROBINSON:  This is from 1999/2000.
   MR JUSTICE FRASER:  Which is why there is no reference in
       there.  Right.
   MR DE GARR ROBINSON:  Yes.  I wonder whether this would be
       a convenient moment.  I'm looking very shamefacedly at
       the transcript writers.
   MR JUSTICE FRASER:  Yes, I think it probably is.  We will
       have 10 minutes.  And not wishing to come across as
       excessively pedantic, but that means coming back at 48
       minutes past.
   MR DE GARR ROBINSON:  I would be happy to have those extra
       two minutes.
   MR JUSTICE FRASER:  That's why I said 48 rather than 50.
           So we will come back at 48 minutes past.  A
       10-minute break.  Thank you very much.
   (11.39 am)
                         (A short break)
   (11.48 am)
   MR DE GARR ROBINSON:  Mr Coyne, we were on the bug table and
       we were talking about item 11 on that table which is
       Girobank discrepancies.
   A.  Yes.
   Q.  And by Girobank discrepancies, you mean discrepancies
       within branch accounts, yes?
   A.  Yes.
   Q.  Another one of the bugs that you identify over the page
       {D1/2/10} is PC0052575, which is at {F/49.1/1}.  Could
       we have a quick look at {F/49.1/1}, please.  This is
       a call in on 16 August 2000.  This is a call by the
       postmaster about three or four lines down -- I should
       say 14 August, I'm sorry:
           "14/08/00, 16.20:
           "Pm has error on giro deposit report. Counter Daily
       report does not match office daily report."
           So it is right, isn't it, that the reports he is
       talking about, these reports are a little bit like
       snapshots of the position at the time the report is
       taken.  Some of them are sent -- maybe all of them are
       sent elsewhere, certainly some of them are.  And the
       postmaster has a problem with the reports because they
       aren't consistent with each other, do you see that?
   A.  Does not match the daily report yes.
   Q.  Correct me if I'm wrong, but that doesn't mean the
       underlying accounts are wrong, it just means that the
       reports that have been printed out are wrong, correct?
   A.  Yes, just reading down.  So it tells us there is
       a software error and that operator error has been ruled
       out.  But it may well be the case that it is only the
       information that appears on the report is wrong, so it
       is misrepresenting what the position is.
   Q.  If we pick it up at the bottom of that box, 16/08 at
       8.51:
           "Repeat call: PM has phoned to say his Giro deposits
       had a discrepancy between his counter daily and his
       office daily reports for yesterday."
           Then there are the figures.
   MR JUSTICE FRASER:  I'm afraid I can't see where you are
       reading.
   MR DE GARR ROBINSON:  My Lord, it is in the big box on page
       1, about three-quarters of the way down, 16/08 at 8.51:
           "PM has phoned to say his Giro deposits had
       a discrepancy between his counter daily and his office
       daily reports ..."
           Then it sets out the figures.
           "PM has produced another transaction log for the
       errant amount ... only appears once however shows twice
       on office daily printed at 11.08."
           So the problem is with the report, not the
       transaction log, yes?
   A.  Yes, it would appear so.
   Q.  If we go over the page to {F/49.1/3}, the fourth box
       down, 31st August at 11.31.  This is Alex Kaiser:
           "I have looked at this call and found the problem.
       It is caused by the window of opportunity that arises
       between the points at which a user prints and then cuts
       off a Counter Daily\Giro Deposits report on a counter."
           So there is a reference to cutting off that we
       discussed before.
   A.  Yes.
   Q.  "If they are using a shared SU and between the two
       points in time another Giro Txn is performed on another
       counter, it will NOT be included on that report but it
       will be included on the summary record written to the
       Messagestore at the point of cut off.
           "When the subsequent office daily/Giro deposits
       summary report is produced it uses the summary record as
       its source and that is why a record that was missed off
       the counter report appears on the office one.
           "This problem has already been fixed at CI4 by ..."
           Then a number of PinICLs are referred to.
           What is being described in this PEAK is a problem
       that had already been fixed but it is a problem in the
       software which generates daily reports, it is not
       a problem in the software which generates branch
       accounts, would you agree?
   A.  Yes.
   Q.  Therefore to the extent that there is a bug at all,
       which it appears there is, the bug for which this PEAK
       is evidence is not a bug which creates discrepancies in
       branch accounts, is it?
   A.  No, it is a bug that creates discrepancies in branch
       reports.
   Q.  And my final question on this PEAK: what this shows is
       that where there are such discrepancies, there will be
       an investigation and the true position will be
       ascertained, would you agree with that?
   A.  Where something is logged and we have a PEAK for it,
       then that PEAK does typically suggest that it is
       investigated correctly.
   Q.  What I would like to suggest, Mr Coyne, is that where
       there are these different pieces of information in the
       system being produced and being sent and so on, and
       being compared by all sorts of people, including the
       postmaster himself or herself, that is a system, the
       operation of such an arrangement is in itself
       a robustness countermeasure.  Would you agree with that?
   A.  That they have a support process that attempts to
       determine the problem?  Yes, that's a --
   Q.  Well, that there are processes which lead to these
       problems being exposed and it is the exposition, it is
       the exposing of these problems, which lead to
       investigations that can assist in increasing the overall
       robustness of Horizon?
   A.  Yes.
   Q.  What this PEAK shows is not that there was a bug in
       Horizon which created a discrepancy in branch accounts.
       What it shows is that the Horizon system and all the
       support operations surrounding it and supporting it
       operated well in identifying if there were any
       discrepancies and checking to see if there were any
       problems created by those discrepancies, would you agree
       with that?
   A.  I do agree with that.  I mean on this example I have
       noted in my report that the discrepancy amount was
       unclear, and I have also noted that it doesn't appear
       that the branch actually appears in this so we don't
       know what branch is relates to.
   Q.  If we could just focus on my particular question.  My
       question is this really: you cite this PEAK in your
       report as evidence of a bug creating discrepancies in
       branch accounts, and you then list it triumphantly in
       your list of Girobank discrepancy-creating bugs in joint
       statement 2, but the discussion we have just had of this
       PEAK and the one that preceded it has resulted in your
       accepting first of all that it didn't create any
       discrepancies in branch accounts, yes?
   A.  It created a discrepancy which could impact branch
       accounts.
   Q.  It didn't create a discrepancy in someone's branch
       accounts, did it?
   A.  Correct, yes.
   Q.  What you say is it raised a possibility that some third
       party, like Post Office, might generate a TC for some
       reason and then the subpostmaster, having received that
       TC, might then accept it rather than saying "I don't
       know what you are talking about"?
   A.  Yes.
   Q.  What you are suggesting is that this countermeasure,
       which obviously involves human beings, it is designed to
       do that, sometimes, and I would suggest very rarely,
       isn't perfect.  But nobody is suggesting, Mr Coyne, that
       countermeasures are perfect.  The really important
       question is whether in the overwhelming majority of
       times the countermeasure has the effect of increasing
       robustness rather than detracting from it.  And what
       I would suggest to you, Mr Coyne, is that both of the
       PEAKs that we have been looking at this morning are
       really quite good examples of how these countermeasures
       increase rather than detract from the robustness of
       Horizon.  And that's my question to you, do you agree?
   A.  I agree from looking at the PEAKs, by the nature of them
       being calls, what we see is the investigatory process
       when a call is made.  So they are a good example.
   Q.  And I think your -- I mustn't put words into your mouth,
       but from evidence you have given on previous days, would
       it be fair to say that you think the support process,
       the investigation process undertaken by Fujitsu is on
       the whole a good one?
   A.  It is on the whole a good one.  There are a number of
       weaknesses in the process and for clarity we do need to
       be clear on what they are, and one is illustrated here,
       that there isn't a branch code in here.
   Q.  Mr Coyne, could I suggest that if a PEAK were produced
       for the purposes of allowing the robustness of Horizon
       to be determined by a judge 20 years or 19 years after
       the event, then you are absolutely right, this is
       a terrible document because it doesn't identify the
       branch, it doesn't enable a litigant to demand
       disclosure of all the branch records and all the TCs
       issued, you are absolutely right.  But it is not the
       purpose of a PEAK to do that.  You regard it as
       a limitation of the PEAK.  The PEAK is a work process
       document which simply records the work being done by the
       SSC in relation to a particular call in.  It doesn't
       need to have that information in order to be
       an effective work document, would you agree?
   A.  I do agree.  It has another problem in that this PEAK is
       very dependent on the KEL that describes what the flaw
       was and the KEL hasn't been disclosed either.  So we
       don't really know what the determination was.
   Q.  Forgive me, Mr Coyne, I'm simply asking you to accept
       what I would suggest are the obvious implications of the
       document that you have got in front of you, and when
       faced with a question of that sort you take refuge in
       saying "Well, I haven't seen this and I haven't seen
       that".
           But you are not grappling with the essential point,
       are you?  Looking at the information contained in these
       PEAKs, with all the limitations that that information
       has because of the nature of the PEAK and the purpose
       for which it was created, looking at the information in
       those PEAKs actually it gives you a good basis for
       concluding, first of all, that these PEAKs do not relate
       to a bug that created any discrepancies in Horizon,
       would you agree?
   A.  That this PEAK did not, I would agree.
   Q.  And the previous one as well, would you agree?
   A.  The previous one you took me to, yes.  Because it was
       picked up, that shouldn't lead to one either.
   Q.  So first of all we are agreed that both of these PEAKs
       are not related to a bug which caused a branch
       discrepancy.  Secondly we are agreed, aren't we, that
       these PEAKs are not evidence that a process was set in
       train which led to a TC being issued to the relevant
       branch which then foisted a false shortfall on the
       branch.  Neither of these PEAKs are evidence of that,
       are they?
   A.  No.  These are evidence of a part of the process.  We
       don't know what happened to correct these discrepancies.
   Q.  So you accept that in both of these cases the relevant
       PEAK didn't lead -- the problem identified and dealt
       with in each of those PEAKs did not actually lead to
       Post Office issuing a transaction correction -- or in
       this period it would have been an error notice -- that
       would have subjected the relevant subpostmaster to
       a risk of loss?
   A.  No, these documents alone do not show that.
   Q.  Indeed it would be inconsistent with these documents
       because it is quite clear that Fujitsu in these
       documents have identified the problem, clarified that it
       is nothing that requires any change to any accounts.
       There is a problem with the report mechanism, that it is
       not ideal in certain very unusual states of
       circumstances, yes?
   A.  It is a little bit more than that.  It might be very
       misleading for the subpostmaster.
   Q.  What I would like to suggest to you, Mr Coyne, is none
       of that comes out from your report.  The clear
       impression given by your report is that these two PEAKs
       are one of many examples in which there are bugs in
       Horizon creating discrepancies in branch accounts, and
       my suggestion to you, Mr Coyne, is that these PEAKs are
       evidence of the opposite.
   A.  Bugs, errors and defects is the way that the question
       was asked and we --
   Q.  We are talking about Horizon Issue 1.  You don't need me
       to go back to Horizon Issue 1, do you?
   A.  I think that says bugs, errors and defects, doesn't it?
   Q.  "Bugs, errors and defects to cause apparent or alleged
       discrepancies or shortfalls relating to subpostmaster's
       branch accounts or transactions."
   A.  Yes.
   Q.  And neither of these PEAKs are an example of either of
       these things, are they?
   A.  On their own, no.
   Q.  Thank you.
   A.  They are an indication of a discrepancy being
       identified.
   Q.  And yet they are listed in your bug list which you
       agreed with me at the beginning of this
       cross-examination today was a list of bugs which caused
       discrepancies in branch accounts.  Could you explain why
       you have included those two PEAKs in this list?
   A.  You need to read it -- as I have said before, for full
       context you need to go back to the report.  There is
       another table in the report that says the discrepancy
       amount or whether there was no discrepancy noted, at
       page 43.
   Q.  Page 43 of the report?
   A.  Page 43 on the face of the report.
   MR JUSTICE FRASER:  That's page 49 in the bundle.  The
       bundle reference is 49.  I think that's where you were
       actually, Mr de Garr Robinson.
   MR DE GARR ROBINSON:  Yes.
   MR JUSTICE FRASER:  Do you mean the table at
       paragraph 3.123?
   A.  Yes.
   MR JUSTICE FRASER:  That's the table you are being asked
       about, I think.  {D2/4.1/49}  Or it is an entry within
       that table that Mr de Garr Robinson has been asking you
       about.
   A.  I believe, my Lord, he was asking the same within the
       reference from the joint statement.
   MR DE GARR ROBINSON:  Actually, it is very helpful that you
       have gone back to that table, Mr Coyne, I would have
       overlooked it otherwise.  If we could go to page
       {D2/4.1/51} and look at paragraph 3.128.  I'm sorry to
       do this in such inordinate detail.  3.128, this is
       a paragraph I took you to before.
   A.  Yes.
   Q.  "The above PEAKs related to Girobank discrepancies are
       clear examples of bugs within Horizon that affect branch
       accounts by way of a financial discrepancy ..."
           So you are saying there that the relevant bugs
       created a financial discrepancy, yes?
   A.  Yes.
   Q.  And I took you first of all to the bug that was
       immediately above that paragraph.
   A.  Yes.
   Q.  {F/118/1}.  And you told me: I didn't put that forward,
       you misread paragraph 3.128, I didn't put that forward
       as a bug creating discrepancies.
   A.  Yes.
   Q.  But you then said that it is not that table I should be
       concerned about, it is the previous table.
   A.  Yes.
   Q.  Above 3.124, yes?
   A.  Yes.
   Q.  If we go back to page {D2/4.1/49} where that table
       begins, you will see that the fourth item on that table,
       which on your own evidence is a list of bugs that create
       discrepancies in branch accounts, is {F/49.1/1},
       PC0052575?
   A.  Yes, with the observation:
           "Discrepancy amount unclear.  Branch unclear."
   Q.  Mr Coyne, let's assume that that particular PEAK had
       identified the branch and had identified a discrepancy
       of £50 or something, just so that I can close off that
       escape route when I ask you the next question I'm about
       to ask you.  So let's pretend.  It is the case, isn't
       it, that that PEAK is not evidence of a bug which
       created discrepancies in branch accounts?  You have just
       agreed that with me.
   A.  It created a financial discrepancy within the Horizon
       system which could then ultimately have an impact on
       branch accounts.
   Q.  I will move on.  Let's take another example that's
       contained in your bug table.  Going back to the bug
       table at {D1/2/10}.
   MR JUSTICE FRASER:  You want to be in the joint statement
       now?
   MR DE GARR ROBINSON:  Yes.  And if you can click on {F/52/1}
       on the side of the page that will give us the relevant
       PEAK, which is PC0052704.
           So just to set the scene.  It is your expert
       opinion, is it, that this PEAK is another PEAK that is
       a clear example of a bug which created discrepancies in
       branch accounts, is that your opinion?
   A.  Sorry, I'm just catching up here.  Where are we?  Number
       12, "Counter Replacement ..."
   Q.  We are looking at one of the bugs that you refer to in
       bug 11, Girobank discrepancies.
   A.  Right, sorry.
   Q.  And the particular bug we are looking at is the bug that
       you say is evidenced by {F/52/1}, and this is F/52.
   A.  Right.  Okay, yes.
   Q.  Just for the record, would you confirm that you have
       included this PEAK in your report, that you lifted it
       from your report and you put it in the joint statement
       because it is a PEAK which you say is evidence of a bug
       creating discrepancies in branch accounts?
   A.  A bug, error or defect, yes.
   Q.  Right.  If we could just go over to page {F/52/2} of the
       PEAK, the last yellow box.  Date 23rd August 2000, 9.30.
       This is Martin Harvey at the SSC:
           "All these problems occurred while a relief PM was
       in place.
           "Giro.
           "A cut-off was performed between the original
       transactions and reversal."
           Then there is reference to a KEL.
           "A P&A report was produced and then two further
       transactions were input before cutoff.  The first report
       was then mistakenly used to infer that these
       transactions had not been performed and so they were
       re-input."
           Do you see?
   A.  Yes.
   Q.  "I could find nothing wrong and when I asked the PM to
       re-check his figures neither could he ...
           "The PM is happy and has agreed call closure."
           On what basis do you say this PEAK evidences a bug
       in Horizon that has created a branch account
       discrepancy, Mr Coyne?
   A.  So as a result of the bug, error or defect with the
       report that we see on the earlier PEAK, this has led the
       subpostmaster to re-enter transactions.  It says towards
       the end here:
           "The first report was then mistakenly used to infer
       these transactions had not been performed ..."
           So they were re-input.  That's because the report
       was misrepresenting the true position because of the
       defect.
   Q.  Then the postmaster looks at the end of the day at his
       transaction log and he sees that he has got two copies
       of the same transaction in his transaction log and he
       sees that if there is a discrepancy in his accounts, it
       will be in exactly the sum of the repeated transaction
       that he has entered a second time in his transaction
       log.
           The bug itself didn't cause any discrepancy at all,
       did it?
   A.  No, the bug itself led to the report misrepresenting
       what the current position was.  That's the bug that we
       saw before.  As a result of that bug, this subpostmaster
       has used the information on the face of that report and
       entered some transactions that then impacted his branch
       accounts.
   Q.  So just to be clear, you are relying on the passage
       that's under the heading "P&A", yes?
   A.  Yes, which includes the KEL M Wright 531, which appears
       to be the common denominator between each of those
       Girobank discrepancies.
   Q.  That KEL is a Girobank discrepancy.  We are in P&A now.
       What does P&A stand for?
   A.  I don't know.
   Q.  It says:
           "A P&A report was produced and then two further
       transactions were input before cutoff.  The first report
       was then mistakenly used to infer that these
       transactions had not been performed and so they were
       re-input."
           Mr Coyne, it is not that the system produced a false
       report which then induced the postmaster to make
       an error.  It is that the postmaster looked at a report
       that had been done before the two transactions had been
       entered.  Do you see?
   A.  Well, on the information given here, Martin Harvey
       linked it to the KEL where the Girobank fault was.
   Q.  Mr Coyne, just look at the words that are written down
       in front of me:
           "A P&A report was produced and then ..."
           Do you see the word "then"?
   A.  Yes.
   Q.  "... two further transactions were input before cutoff.
       The first report ..."
           So the report that was done before the two
       transactions were entered into, yes?
   A.  Yes.
   Q.  "... was then mistakenly used to infer that these
       transactions had not been performed and so they were
       re-input."
           So what happened was the postmaster -- who it has to
       be remembered was a relief postmaster and may not have
       been as experienced as he or she might have been, which
       is no doubt why that was written down -- had printed
       a report that correctly represented the position as at
       the time the report was printed, had then entered into
       two transactions, had then looked at the report that he
       printed, and foolishly he then thought that shows that
       I haven't entered the two transactions I have just
       entered so I will enter them again.  Do you see?
   A.  I do see but --
   Q.  That, I would suggest, is not the result of a bug in
       Horizon.
   A.  So if that was right, why would Martin Harvey, when he
       wrote that at 9.30 on 23rd August, choose to reference
       the KEL for that particular defect?  It would make no
       sense if he didn't consider that that was part of his
       consideration.
   Q.  Well, I suggest to you, Mr Coyne, that it is plain from
       the actual language that he has used, the very language
       that you are relying upon, that there was some human
       error in this case and the human error was in using the
       wrong report, a report that reported on the state of
       affairs before the two transactions had actually been
       done, and the mistake was that the postmaster thought
       that it ought to include those two transactions,
       wrongly, and so added them again.  And I'm suggesting to
       you that that's what Mr Harvey is saying in that middle
       paragraph.
   A.  I don't accept that because Martin Harvey would, in
       considering what the issue was, I can't imagine that he
       would have referenced the M Wright and the D Rowe KEL if
       he didn't believe they were relevant to the situation
       that had occurred.  That is contra to what the purpose
       of these documents are for.  They are to lead the next
       person that finds the problem, to link these together.
       It would be crazy to include a reference to that if it
       wasn't relevant to this problem.
   Q.  Would you excuse me a moment, Mr Coyne.  (Pause)
           Let's move on to bug 20 now, recovery failures.
   MR JUSTICE FRASER:  Just before you do, can you tell me what
       P&A stands for?
   MR DE GARR ROBINSON:  My Lord, I can't.
   MR JUSTICE FRASER:  All right, it doesn't matter.
   MR DE GARR ROBINSON:  I was hoping Mr Coyne could.
   MR JUSTICE FRASER:  Do you know what P&A stands for?
   A.  I don't, my Lord.
   MR JUSTICE FRASER:  All right.
   MR DE GARR ROBINSON:  Bug 20, recovery -- it is called
       recovery failures.  Let's start at your second report,
       Mr Coyne, please {D2/4.1/66}.  You say in paragraph
       3.194:
           "PC0197643 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 withdrawal [sic]
       states 'Authorised', so it's possible that the clerk
       handed over the monney [sic].'"
           Then you say at 3.195:
           "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."
           {D2/4.1/67}.
           This is a PEAK that you also refer to in the bug
       table and which we will come to in a moment.  Could we
       look at that PEAK, please.  It is {F/613/1}.  So the
       PEAK starts on 13th April 2010, which I think must be
       during the initial Horizon Online roll out.  You agree?
   A.  Yes.
   Q.  If you could look at the top right-hand side of the
       PEAK, the call logger, you see it is "MSU-IndtMgt".  Do
       you know what that stands for?
   A.  Management support unit ...
   Q.  The other letters you don't know?
   A.  I don't.  Well, management will be the end one but
       I don't know what --
   Q.  Yes.  And what does the MSU do?
   A.  I'm not sure I have seen that set out anywhere.
   Q.  It receives -- you have seen a great number of PEAKs
       that are created as a result of the MSU, yes?
   A.  Yes.
   Q.  It monitors things --
   A.  Right.
   Q.  -- doesn't it, in the system?
   A.  Yes.
   Q.  It monitors all sorts of exceptions?
   A.  Right.
   Q.  And when it spots exceptions it passes them through to
       the SSC.
   A.  Right.
   Q.  That is consistent with your understanding of PEAKs,
       isn't it?
   A.  That sounds reasonable, yes.
   Q.  And amongst the things that the MSU monitors is recovery
       failures, isn't it?
   A.  Mm.
   Q.  So all recovery failures of the sort we are discussing
       here are in the first instance reported to the MSU, yes?
   A.  Yes.
   Q.  Then the MSU will, having identified the problem, pass
       it on to the SSC to look into it, correct?
   A.  Yes.  I don't know when this is triggered because there
       are -- I have seen PEAKs where it is the subpostmaster
       that is attempting recovery and they report that the
       counter just keeps re-booting, so perhaps it's --
   Q.  But sometimes -- and perhaps we can agree on this.
       I have thought about that as well and my surmise is that
       sometimes the SPM gets the report in first and other
       times the MSU does, it is just a timing issue.
   A.  Yes.
   Q.  And if the SPM has phoned in first then that is the PEAK
       and there doesn't need to be a separate PEAK because the
       MSU puts in a call as well, would you say that's fair?
   A.  Sounds reasonable.
   Q.  Then it says on the top box "13th April", so we are
       really -- Horizon Online is brand new and there are very
       few users at this stage:
           "Details entered are:
           "Summary: Branch ..."
           There is the branch FAD code.
           "... NB102 Section 5 CAPO - state 4."
           That's one of the reports, isn't it, that identifies
       when there is a failure, a recovery failure?
   A.  Yes.
   Q.  If we go down to 10.06 there is a reference added,
       a KEL, that is "dsed2640M".  Do you see that?
   A.  Yes, I do.
   Q.  If we could have a quick look at that, if we look at
       {F/586/1}, please.  We will come back to this PEAK,
       though.
           Have I given you the wrong reference?
   MR JUSTICE FRASER:  No, that was the reference to the PEAK.
       Or did you mean the trial bundle reference?
   MR DE GARR ROBINSON:  My note, and Homer does nod, I don't
       think I'm even Homer for these purposes.  My note tells
       me that the dsed KEL is at {F/586/1} and if I'm wrong
       then I need to move on quickly.
   MR JUSTICE FRASER:  Don't worry about rushing, it will only
       take a moment to find it.
   MR DE GARR ROBINSON:  It may be 587 {F/587/1}.
           So this is the KEL that's referred to.  It says:
           "Transaction in state 4 on the NB102 Section 5
       banking reconciliation report - failed recovery."
           Then if we go down to "Symptoms:
           "There is a transaction in state 4 on the NB102
       Section 5 banking reconciliation report as the
       transaction failed to be recovered during recovery."
           Of course recoverable transactions will always
       involve a bank, won't they, they will always involve
       a financial institution, because if it weren't
       a three-way transaction involving three parties it
       wouldn't be recoverable, it would be cancellable,
       wouldn't it?
   A.  Yes.
   Q.  So this report will always pick up failed recoveries.
           It says under the heading "Problem":
           "The transaction in question failed to be settled
       due to problems with printing so there was no C1
       confirmation.  The printing problem was caused by the
       failure to print an earlier report/receipt that seemed
       to have stuck and caused every print attempt thereafter
       to fail.  When the user logged off and logged back on
       again, the recovery process attempted to recover the
       banking transaction but because this in itself requires
       a receipt to be produced this failed as well."
           Do you see that?
   A.  Yes.
   Q.  Then it says:
           "The print problem should be evident by 0607 errors
       being displayed to the PM and the same error being
       recorded in the PostOfficeCounter.log at the time.
       There will also be Warnings logged to this log with the
       words "Received second print request, before completing
       first print request."
           So would it be right to infer from what that KEL
       says that this problem, as well as going through to the
       MSU and being pushed through to the SSC in the normal
       way, the problem would also be evident to the postmaster
       who was undertaking the transaction at the branch, would
       you agree with that?
   A.  Yes.  It is said there will be a 0607 error displayed.
       So if the screen is working as a result of whatever this
       failure is, then they would probably see that.  The
       other two things there, PostOfficeCounter.log and
       warnings in the log, they won't be visible to the
       subpostmaster.
   Q.  So one way or another, both the postmaster and Fujitsu
       independently will know that there's a problem when this
       arises, yes?
   A.  Yes, and at this stage the counter probably hasn't yet
       booted back up yet.  It is in a failed state obviously.
   MR JUSTICE FRASER:  Mr de Garr Robinson, can I just make one
       observation and it is not to distract you at all.  The
       number of the PEAK on that KEL is not the number that
       you were looking at before.
   MR DE GARR ROBINSON:  The number of the PEAK on that KEL?
   MR JUSTICE FRASER:  That's 193463, and the one we were
       looking at was 197643.
   MR DE GARR ROBINSON:  My Lord, yes.  The reason why we were
       looking at that KEL is because it is referred to in the
       PEAK.
   MR JUSTICE FRASER:  I do understand that, but I just wanted
       to make sure that you didn't think it was exactly the
       same PEAK.  I know the way PEAKs and KELs work so it
       wouldn't necessarily be the case.
   MR DE GARR ROBINSON:  Let me ask a question of Mr Coyne.
           The fact that the KEL is referred to in the PEAK
       back at {F/613/1}, if we could look at that, please,
       that's indicative of the fact that the SSC person who
       has received this call has looked at the symptoms and
       thought, hang on a second, this displays the symptoms in
       this particular KEL.  Sometimes they might be wrong,
       sometimes it might be an early diagnosis and they may
       have a more developed view later.  But in general if you
       see a KEL referred to in a PEAK it means the person at
       that point in time thinks this is a repetition of the
       symptoms described in the relevant KEL, would that be
       correct?
   A.  Yes, that is right.  And then to balance that when you
       look at the KEL, sometimes you do see the back reference
       to the PEAKs that use that, other times you will just
       see in that scenario just a reference that doesn't refer
       back but it might be the first instance of that --
   Q.  Yes, that's very helpful.  So where the KEL refers to
       a PEAK, sometimes there might only be one PEAK and it
       will be probably the first PEAK that resulted in the
       production of the KEL, but other times the KEL could
       refer to lots of PEAKs, indeed hundreds of PEAKs.  It
       depends.
   A.  Yes.  There are a number of KELs that on their own will
       refer to many hundreds, and that goes back to the
       statement that I made before about the number of likely
       PEAKs that could be linked to KELs.  You can very
       quickly get to very large numbers.
   Q.  Yes.  If we look at this PEAK again at the bottom of the
       page, 13th April 2010, at 11.37 it says -- Andy Keil,
       who is now dealing with it says:
           "Request and authorisation were successful, but no
       confirmation or reversal:
           "This transaction is in the all branches recovery
       table, as per the KEL -'There's a Recovery Table button
       on Smiley which shows transactions (for all branches)
       where recovery has failed.  If your transaction is in
       here, it will need manual reconciliation'."
           So stopping there.  Just to confirm, the way that
       Horizon has always worked is that while you are in the
       course of typing in a transaction into the counter all
       sorts of information is going up the wires into the data
       centre which may be the messagestore, in Legacy Horizon
       it could be the messagestore at the gateway counter at
       the branch, and that would then be replicated in due
       course to the correspondence server.  And in
       Horizon Online it goes straight through to the BRDB, one
       of the central data servers, doesn't it?
   A.  Yes.
   Q.  On numerous occasions during the course of the
       transaction numerous tables -- it is easier if we just
       talk about Horizon Online -- in the BRDB are populated
       with data relating to the transaction being typed in?
   A.  Yes.
   Q.  That is a good thing because it means that if there is
       a problem with a transaction, if the transaction goes
       wrong before the basket is committed, then there will be
       actually several copies of data relating to that
       transaction to be found in various tables in the BRDB,
       would that be right?
   A.  There might not be several copies of it but there will
       be a stake in the ground somewhere saying you have
       commenced a transaction.
   Q.  So at least if you look for it nothing gets lost, would
       that be right?
           I don't want to commit you to an extreme
       articulation.  I understand why you're hesitating.
   A.  It is a fact that information will have to go from the
       counter to the BRDB so theoretically things can get lost
       along the way but that's quite unlikely.
   Q.  Would I be right in thinking that you are not aware of
       any PEAK relating to a situation where data relating to
       a recoverable transaction has never actually got through
       to the relevant tables in the first place?
   A.  No.  There is a number of references to communication
       errors have led to situations arising and that often is
       seen in recovery, that they determine that the recovery
       is required because a communication fault --
   Q.  But invariably those -- perhaps universally, actually,
       those communication problems will be towards the end of
       the transaction because that's the point at which the
       bank becomes engaged, that is the point at which there
       is a risk of the transaction becoming recoverable.  At
       the relatively early stages where the initial elements
       of the transaction are being typed in, if that
       information doesn't get through, the system will just
       stop, won't it?
   A.  Yes, that's fair.  There is a time by which you are past
       the point of no return, if you will, without having to
       sort something out.
   Q.  But my suggestion to you and I'm not trying to fence
       with you, Mr Coyne, and I'm not trying to be clever, or
       at least no more than usual, but where you have
       a recovery scenario, there will always be data relating
       to the transaction to be recovered.  If there isn't data
       in the relevant tables in the BRDB about that
       transaction, then you are not in a recovery situation at
       all?
   A.  That is right.
   Q.  You haven't got far enough in?
   A.  Yes.
   Q.  Thank you, that's very helpful.  So the way that it
       works then is -- what we are talking about is recovery
       failures.  There will be data in the -- I'm talking
       about the BRDB just for simplicity, I appreciate this
       is -- actually this is Horizon Online.
   A.  Yes.
   Q.  In the BRDB there will be tables containing the data
       that relates to the relevant transaction?
   A.  Yes.
   Q.  And ideally the system will tell the SPM to try and
       recover the transaction but sometimes if there is
       a problem with the printer, because the system depends
       upon the printer printing out receipts and so on, there
       could be a problem which means that although the SPM
       knows there's something wrong and he or she has to
       address it, there will be a problem that means he can't
       on his own, yes?
   A.  Yes.  Because recoveries happen because something has
       gone wrong in branch, could be power, could be
       communications, could be a whole range of things,
       something has gone wrong and therefore the recovery
       process needs to start, it is quite possible that
       whatever went wrong in the first place is still going
       wrong when the recovery attempts and that's why
       sometimes the recovery won't be successful because it is
       a power problem, you still might have a power problem,
       a communication problem, it still might be there.
   Q.  Yes.  So would I be right in thinking it is inherent in
       the system in that the fact that any system of this sort
       is going to have recovery situations, you can never
       guarantee that you won't have recovery failures.  The
       failure that causes the recoverable transaction in the
       first place could be of a nature which is going to
       involve a failure of the recovery as well, for example?
   A.  By design there always would have to be a recovery
       process because the risk that there's going to be
       a power problem is always going to trigger somewhere on
       an estate of this size.  If that part of it is designed
       well, then the vast majority of all recoveries should be
       completely automated.
   Q.  Yes.
   A.  There shouldn't be many of the situations --
   Q.  Well, we can agree that the vast majority of recovery
       situations should work well?
   A.  Yes.
   Q.  Bearing in mind the vast number of transactions
       undertaken at Horizon --
   A.  Indeed.
   Q.  -- and a tiny proportion of situations where that
       doesn't happen could actually be a quite a large number
       over a period of 20 years?
   A.  Certainly could be.
   Q.  So would you accept with me that the fact that there
       have been a significant number of recovery failures over
       20 years, that of itself isn't indicative of a problem
       in the recovery process?
   A.  Of course it has to be accepted that it is a problem
       because it shouldn't really happen.  Typical recovery
       should work on an automatic basis.  The manual
       intervention that's required when recovery fails, that
       shouldn't happen but does happen.  It is because it
       doesn't know what situation it is and there hasn't been
       a recovery scenario created for that and therefore it
       requires manual intervention.
   Q.  I didn't ask the question properly, and it is my fault
       not yours.  What I meant to ask was it is inevitable
       with any system, however well designed, that there will
       be a small proportion of cases where the automatic
       recovery processes don't work.  That's just inevitable,
       isn't it?
   A.  Yes.
   Q.  Thank you.  That's very fair.  And that's what happened
       here, this is one of those cases?
   A.  Yes.
   Q.  You will see that, as I think from the passage we have
       already read:
           "There's a Recovery Table button on Smiley which
       shows transactions (for all branches) where recovery has
       failed.  If your transaction is in here, it will need
       manual reconciliation."
           We have agreed that data relating to recoverable
       transactions will always be somewhere within BRDB,
       I think?
   A.  Mm.
   Q.  We have agreed that there will always be cases, a small
       proportion of cases, where the recovery process that one
       would like to operate automatically for one reason or
       another doesn't, and in that small proportion of cases
       some form of manual assistance is required, isn't it?
   A.  Yes.
   Q.  And the system for example isn't designed -- the
       recovery system isn't required to require the counter to
       keep trying to log on and log on perpetually, it is
       designed to log on only twice?
   A.  Yes.
   Q.  That is a design feature, because if it is perpetual you
       can't use the machine?
   A.  Yes.
   Q.  That is very helpful.  So the fact that you have
       recovery failures is not of itself a threat to
       robustness unless the proportion of the recovery
       failures you have is too high?
   A.  Yes.
   Q.  Here the system that's operated by Horizon is that where
       you have a recovery failure it is always reported both
       to Fujitsu and, by error warnings, also to the
       subpostmaster, yes?
   A.  Yes.
   Q.  So both Fujitsu and the postmaster, where there is
       a failed recovery, know there is a problem and they know
       they need to deal with it by communicating with each
       other, do you agree with that?
   A.  Yes.
   Q.  And that's the way that the Horizon system is
       constructed, correct?
   A.  Yes.
   Q.  One other aspect of the recovery process that's very
       important is to know when money changes hands?
   A.  Yes.
   Q.  And let me just expand on why that's important.  You
       have a transaction, ex hypothesi it is a transaction
       involving a financial institution making or receiving
       a payment, and let's say it is a bank deposit.  The
       customer hands in £100 at the branch, the branch presses
       the buttons so that the customer's bank account goes up
       by £100, and the problem that arises with recoverable
       transactions is that the bank may have been told to
       increase the balance by £100 before the transaction has
       actually been committed to the accounts of the branch.
   A.  Yes.
   Q.  And in that scenario, the postmaster may have seen
       a symbol on his screen saying "Accept the money,
       authorised to accept money", yes?
   A.  Yes.
   Q.  Or he may not have done.  But whether he has or not, you
       don't know whether actually money has passed hands, do
       you?  If you are at Fujitsu you are not going to know
       whether money has passed hands and you are going to want
       to check, because it might be that the postmaster sees
       the transaction stopping and says to the customer "I'm
       terribly sorry, I have a problem with the system, I'm
       closing it down.  You had better keep your money and
       come back a bit later".  That's always possible, yes?
   A.  I was in agreement with you until you said if the
       message on screen says "Accept the money", because that
       should be the very last thing that happens after the
       process has been completed.  That shouldn't be
       an intermediate phase before completion.
   Q.  So what you are saying is the message "Accept recovery"
       never comes up before the transaction is committed to
       the database?
   A.  You said "Accept money", did you?  You said "Accept
       money"?
   Q.  Yes.
   A.  Well, that message -- it would be unsafe if that message
       was to appear before the transaction has been
       properly --
   Q.  Right, but -- very good.  But sometimes human beings do
       accept money a bit early, don't they?
   A.  Yes.
   Q.  So it is prudent, isn't it, in the scenario where there
       is a transaction, to check with the SPM as to whether
       money has been received or not, do you agree?
   A.  Yes.
   Q.  There is a danger, if you don't do that, that the SPM
       could end up being foisted with a false shortfall, isn't
       there?  For example, the SPM might say to the customer,
       "There is a problem with my system.  Ordinarily I would
       be taking money from you but you had better come back
       later with your money, I'm terribly sorry", and doesn't
       take the money, but then finds that his accounts have
       been multi-ed(sic) to the tune of £100.  The account
       thinks he has received the money and there then appears
       to be a shortfall.  Do you see that?
   A.  Yes.
   Q.  So in that kind of scenario it is always prudent, isn't
       it, for there to be a conversation with the postmaster
       to work out, to ascertain what the postmaster actually
       did on the ground, would you agree?
   A.  Yes, I mean I think if that conversation can go on at
       the time that the transaction is taking place, then
       I can see how that would work.  If it is going to happen
       the following day or something like that then there's
       very little value.
   Q.  Why would that be, Mr Coyne?  There is a recoverable
       transaction, something has gone wrong, the recovery for
       one reason or another hasn't operated automatically.
       The way that Horizon is set up is that the system is
       then made aware of the problem so that there can be
       a communication, co-operation between Fujitsu on the one
       hand, Post Office on the one hand, and the postmaster on
       the other, to work out what happened to make sure that
       the branch accounts properly reflect what happened in
       the real world.
   A.  Yes.
   Q.  What would be better than having such a co-operative
       arrangement?
   A.  Just in practical terms I don't know how that would work
       in a large Post Office if it isn't taking place at the
       time that the transaction is going on.
   Q.  As I think we have established, the postmaster -- as
       soon as the problem arises the postmaster knows about
       it.  I think you have already agreed that.  So
       a postmaster can be expected to keep some kind of note
       that I have had a problem or remember that he has had
       a problem, yes?
   A.  If it was the postmaster that was at the counter at the
       time, yes.
   Q.  Or the clerk whom the postmaster employs to do that job.
       One way or another, when something goes wrong you would
       expect the person at the branch doing the transaction to
       remember -- to know that something has gone wrong and to
       remember it because it could be important for accounting
       purposes later.  Postmasters and clerks aren't goldfish,
       are they, they do have a memory of these things?
   A.  That is fair.
   Q.  They will know the significance of the point and they
       will know they ought to remember because it may come up
       later, yes?
   A.  Yes, I think it is going beyond my technical expertise
       about what happens physically within the Post Office,
       but I can accept the premise that you are putting to me.
   Q.  If we go back to the PEAK.  We are at the bottom of
       page 1, middle paragraph of the box at 11.37 {F/613/1}:
           "Looking at the PostOfficeCounterLog, the receipt
       printed ok for this after authorisation was received,
       the receipt that printed for the cash withdrawal states
       'Authorised' ..."
           So it looks as if the postmaster was authorised.
           " ... so it's possible that the clerk handed over
       the monney.  There is a timeout issue after the receipt
       printed."
           And timeout issues, we discussed that before, didn't
       we, that the system is designed only to try on two
       occasions and then it stops because otherwise it makes
       the machine hard to use, yes?
   A.  Yes, so the receipt was printed and then something else
       happened.  The timeout issue, I'm not sure what --
   Q.  So if we go down to the next box, 13th April at 11.37:
           "The call record has been transferred to the team
       ..."
           MSU again.  This time would you agree it is going
       back to the MSU so the MSU can contact Post Office and
       say "You need to speak to the postmaster to check what
       happened and, if necessary, you may need to do a TC",
       would you agree with that?
   A.  Yes, I haven't seen that document.
   Q.  If we go over the page {F/613/2}, the yellow box at the
       top of the page, 13th April at 15.07.  Joanne Ball, who
       I assume is at MSU, says:
           "Thanks Andy."
           Andy being Andy Keil at the SSC.
           "Final BIMS issued to POL."
           Can you explain what a BIMS is?
   A.  Business incident management?  I don't know what the S
       is.
   Q.  Yes.  So what do you think that BIMS would be saying?
   A.  It will possibly be describing the scenario that
       occurred and suggesting what actions --
   Q.  Post Office should take?
   A.  Post Office should take, yes.
   Q.  In this case it will be: you need to check with the
       branch whether money changed hands, and if it didn't you
       might need to issue a TC, if it did then you won't, yes?
   A.  Yes.
   Q.  Could I suggest to you, Mr Coyne, that is the system
       working as it should.  This PEAK isn't a demonstration
       of a failure in the Horizon system or in its
       countermeasures.  It is actually good evidence of the
       countermeasures working so as to avoid the risk of any
       loss to a subpostmaster.  Would you agree with that?
   A.  As the position stands at the end of this PEAK, there is
       a discrepancy within branch accounts which Post Office
       may well go on to fix as a result of that BIMS but it is
       incorrect at this point in time, or it might be
       incorrect at this point in time.
   Q.  What interests me, Mr Coyne, is that you are quite happy
       to describe this PEAK as an example of recovery failures
       creating discrepancies in branch accounts.  We don't
       know whether it did or not actually.  But you stop.  At
       a earlier stage in your cross-examination I think you
       accepted that it is important for the expert to consider
       not just what the immediate impacts of a bug are but
       also what impacts the countermeasures that the system
       has would be.  It is important therefore to focus on the
       ultimate result, not on some transient situation that
       may exist for a limited amount of time.  I think you
       agreed with that before but perhaps I will invite you to
       agree with it again.
   A.  I do agree with that but we have to work off the
       technical evidence available, and there isn't technical
       evidence available to show that this discrepancy was
       resolved.
   Q.  Here's what interests me, Mr Coyne.  What you are saying
       is -- let me do it this way.  I would suggest to you
       that on any fair and reasonable reading what this PEAK
       demonstrates is, first of all, that Fujitsu spotted that
       there was a failed recovery situation?
   A.  Yes.
   Q.  Very reliably.  One can reliably assume that's going to
       happen, yes?
   A.  Yes.
   Q.  Looked into the underlying circumstances at the branch
       at the time of the recovery.  Again one can reliably
       assume that's going to happen?
   A.  Yes.
   Q.  Then formed the view it was necessary to work out what
       had happened on the ground in order to know whether any
       discrepancy had been created or not, yes?
   A.  Yes.
   Q.  Then sent through a BIMS to Post Office to tell
       Post Office to reach out to the postmaster and ask what
       actually happened on the ground?
   A.  Yes.
   Q.  And I further suggest to you, Mr Coyne, that the reason
       why Fujitsu sent that BIMS and the reason why
       Post Office received that BIMS, they don't receive these
       documents in order to put them in a pile in some
       warehouse and never look at them, they receive them so
       that they can be acted upon?
   A.  Yes.
   Q.  And on any fair reading of the evidence, it would be
       extraordinary in this case to assume that having
       received that BIMS, Post Office would not have reached
       out to the postmaster, ascertain what had happened and
       sent a TC or not depending on the postmaster's answer.
   A.  Yes, but this is quite clear, when you read the heading
       "Recovery Failures", that it is seeking to address
       Horizon Issue 4: to what extent has there been the
       potential for errors in the data recorded in Horizon?
   Q.  Mr Coyne, can I remind you we are talking about a PEAK
       which is in your bug table.  It is in your evidence of
       bugs which have caused discrepancies.  This table
       consists exclusively of what you say are bugs for which
       there is good evidence that discrepancies were caused to
       branch accounts, am I wrong?
   A.  There is a table in my report -- this is a joint
       statement, remember.  There is a table in my second
       report.  If you look on the face of it, page 12
       {D2/4.1/18}, and it is quite clear here that this is
       under Horizon Issue 4 rather than Horizon Issue 1.  And
       Horizon Issue 4 is a different issue talking about the
       potential.
   Q.  Have you finished your answer?
   A.  Yes.
   Q.  Mr Coyne, your answer is absolutely astonishing.  First
       of all, let's look at the table.  It is "Recovery
       Failures" which is three rows from the bottom.  You say
       it is relevant to Issue 4.  Look at the next column.
       The next column says "Evidence of Branch Impact."
   A.  Yes.
   Q.  You are there saying that the recovery failures that you
       have identified are recovery failures for which there is
       evidence they had an impact on branch accounts?
   A.  They do have an impact on branch accounts until it is
       dealt with by Post Office.  There is very little doubt
       about that.
   Q.  Secondly, I got this reference not from your table or
       from any paragraph of your report, I got this PEAK
       reference from the bug list in JS2, and you agreed with
       me I think at the beginning of this morning's evidence
       that that represents a list of bugs that you think had
       branch impact, had an effect on branch accounts.  So
       I go to the PEAK and I expect to see a bug in there
       which has a demonstrated impact on branch accounts.
           But we go to this PEAK and what do I see?  First of
       all, I don't see any bug at all.  I see a failure in
       recovery which you yourself accepted was inevitable.
       Even in the best, most perfect system there are always
       going to be recovery failures.
           Secondly, I see no evidence of a discrepancy being
       created as a result of any bug in branch accounts.  What
       I see is a system which is designed to avoid any
       discrepancy being created in branch accounts?
   A.  Your questioning there was all about bugs.  The actual
       Horizon Issue is framed as bugs, errors and defects.  It
       is quite clear both in my report and in the table within
       the joint statement that recovery issues has been
       identified as Horizon Issue 4.
   Q.  If we could go to paragraph 1.15 of the joint statement,
       so that's {D1/2/29}, please.
   A.  The second joint statement?
   Q.  Second joint statement:
           "The number of distinct bugs, for which the experts
       have seen strong evidence of the bug causing a lasting
       discrepancy in branch accounts, is between 12 and 29."
           So your expert opinion is that all 29 of the bugs on
       the bug table contain strong evidence of a financial
       discrepancy being caused in postmaster's accounts, yes?
   A.  Sorry, let me --
   MR JUSTICE FRASER:  I think you have given an incorrect
       reference to the joint statement or I can't find where
       you are reading from.
   MR DE GARR ROBINSON:  I'm sorry.  Paragraph 1.15 on page 29
       of the bug table.  Well, it's not the bug table, it's
       JS2.
   MR JUSTICE FRASER:  The joint statement, second joint
       statement?
   MR DE GARR ROBINSON:  Second joint statement, yes.
   A.  The agreed part of it?  Yes.
   MR DE GARR ROBINSON:  So what you are saying there is your
       expert opinion, your considered opinion, is that all 29
       of those bugs contain strong evidence of the bug causing
       a lasting discrepancy in branch accounts, yes?
   A.  The statement there is an agreed statement between us.
   Q.  Yes.
   A.  That the number is between 12 and 29.
   Q.  And your view is that it is 29, correct?
   A.  My view will be whatever the number is in the table --
   Q.  Yes, it is 29.
   A.  -- in my report.
   Q.  Yes.  29 bugs are in the bug table in the second joint
       statement, yes?  And you confirmed when you started
       giving evidence about the bug table this morning that
       these 29 bugs represented the culmination of the work
       that you have done, they represented bugs that you
       considered had caused discrepancies in branch accounts.
       You are not withdrawing that evidence now, are you,
       Mr Coyne?
   A.  I'm not.  Are you referring to the bug table in my
       report?
   Q.  I'm referring to the bug table in the second joint
       statement from which I have been working all morning,
       yes.
   A.  Right, okay.  Well, the bug table in my second report
       has a column that says "Evidence of Branch Account" and
       it has an indicator in there saying yes or no.
   Q.  I'm looking at paragraph 1.15 which is agreed by you.
   A.  Yes.
   Q.  As I understand it, it is an assertion by you that all
       29 of the bugs in the bug table caused lasting
       discrepancies, that there's strong evidence that they
       caused lasting discrepancies.  Do you see that?
   A.  Yes.
   Q.  And by "lasting", the antithesis of a lasting
       discrepancy is a transient discrepancy, correct?
   A.  Sorry, just put that question again, please.
   Q.  There are two kinds of discrepancy that can be caused.
       There are transient discrepancies and there are lasting
       ones.
   A.  Right.
   Q.  And the difference between transient discrepancies and
       lasting discrepancies is transient discrepancies get
       handled by countermeasures.  So there is no ultimate
       effect, there is no lasting effect.  There may be some
       short period of time where there is a potential
       shortfall, but in the long run the countermeasures
       existing in the Horizon system will ensure that the
       discrepancy is resolved.  Yes?
   A.  They should ensure if they are all working in position
       correctly, yes.
   Q.  And that's what's meant by the word "lasting" in
       paragraph 1.15, yes?
   A.  Yes.
   Q.  So what you are saying is for each of the 29 bugs there
       is strong evidence that the bugs concerned not only
       caused discrepancies but they caused discrepancies which
       were lasting, which weren't handled by countermeasures.
       You see?  That's your expert opinion, isn't it?
   A.  Yes.
   Q.  And yet we go to this -- and you cite lots and lots of
       PEAKs, I can't go through them all.  But we go to this
       PEAK and what I suggest to you, Mr Coyne, is first of
       all there's not evidence of a bug, but more importantly
       for present purposes the evidence constituted by this
       PEAK demonstrates that if there were any discrepancy
       caused, it would have been picked up in the process, the
       BIMS process, that we have been discussing.  Do you not
       agree?
   A.  It certainly should pick it up and that will correct the
       discrepancy, and therefore it shouldn't be lasting if
       that whole process works in the way that you suggest.
       But that was offered up as Horizon Issue 4, and Horizon
       Issue 4 asked for the potential and that is the area of
       potential.
   Q.  Mr Coyne, I don't want to be discourteous to you, but
       I suggest to you that you are evading my question.  My
       question is, please forget Horizon Issue 4.
   A.  Right.
   Q.  We are talking about bugs creating discrepancies in
       branch accounts.
   A.  Yes.
   Q.  I have closed off that escape route for you, if I may
       say so.  Okay?
   A.  Right.
   Q.  And the purpose of the bug table is to identify
       precisely those bugs that had a lasting effect on branch
       accounts after taking countermeasures into account, yes?
   A.  Why are you suggesting that the purpose of this bug
       table is what you are suggesting it is?
   MR JUSTICE FRASER:  All right, I'm actually going to
       shortcircuit it this way because it is just past
       1 o'clock.  There is a joint statement that says you and
       Dr Worden agree between 12 and 29.
   A.  Yes.
   MR JUSTICE FRASER:  Do you know what your number is between
       12 and 29?
   A.  There is evidence --
   MR JUSTICE FRASER:  No, no.  Do you know what your number
       is?
   A.  13.
   MR JUSTICE FRASER:  Right.  If you want to pursue this
       anymore, Mr de Garr Robinson, do it at 2 o'clock.
           Thank you all very much.  2 o'clock.
   (1.03 pm)
                     (The short adjournment)
   (2.00 pm)
   MR DE GARR ROBINSON:  Mr Coyne, good afternoon.
   A.  Good afternoon.  Sorry, Mr de Garr Robinson, before we
       start could I please correct the number I provided just
       before lunch.
           In tallying up the numbers in the column in my
       report I missed that the last one is actually a heading
       that includes a number of bugs, errors and defects, so
       the actual number is 21.  They are in the report, they
       are just grouped together for the purposes of the table.
   Q.  21.  So which ones -- if we are looking at the bug
       table -- did you mistakenly leave out?  Which headings
       are we talking about?
   A.  The very last on on the table in any report.
   Q.  Network banking bug?
   MR JUSTICE FRASER:  I do not think you are in the same
       please.
           Can you just give us a paragraph number?
   A.  Just above paragraph 3.22 of the second report.
   MR DE GARR ROBINSON:  So this is {D2/4.1/18}.
   A.  Yes.  The last one on there that talks about bugs,
       errors and defects introduced previously by fixes?
   Q.  Yes.
   A.  That is actually a group heading, and in the report
       there's seven bugs, errors and defects included in that
       heading.
   MR JUSTICE FRASER:  So the number is 21.
   A.  The number is 21.
   MR JUSTICE FRASER:  All right.
   MR DE GARR ROBINSON:  Just before we get to the number,
       I would like to just understand where we now stand.
           We all understand, I think, we discussed it several
       times during the course of the last few days, the
       significance of the distinction between transient bugs
       on the one hand and lasting bugs on the other?
   A.  Yes.
   Q.  The distinction is transient bugs are bugs that will be
       caught by countermeasures, lasting bugs are the ones
       that the countermeasures may miss, yes?
   A.  Yes.
   Q.  So where you say you have identified 21 bugs that are
       lasting, you are also saying that the other bugs, such
       other bugs as have been identified at any tables or any
       lists, those bugs actually in your judgment are bugs
       that would not have got past countermeasures, yes?
   A.  That would not have got past?
   Q.  Yes, that would have been caught by countermeasures.
       That's why they are not lasting.
   MR JUSTICE FRASER:  I'm afraid I don't understand that
       question.
   MR DE GARR ROBINSON:  A large number of bugs are set out in
       the bug table in JS2.
   A.  Yes.
   Q.  When I say the bug table, I'm talking about the table
       which I thought represented the issues between the
       experts on bugs.
   MR JUSTICE FRASER:  Yes, the one in the joint statement.
   MR DE GARR ROBINSON:  The one in the joint statement.  There
       are 29 bugs in that joint statement.
   A.  Yes, bugs, errors and defects.
   Q.  I'm not seeking to achieve an advantage by just saying
       bugs, I'm simply using the term as a form of shorthand,
       Mr Coyne.  I understand what you mean when you seek to
       make yourself clear.  That's entirely reasonable.
           That table identifies 29 bugs.  You now say 21 bugs
       are lasting.  And just to be clear, what you are
       actually saying is that 8 of the 29 bugs were not
       lasting, they are bugs that in your judgment would not
       have got past the countermeasures that exist in Horizon,
       yes?
   A.  Not quite.  They are bugs which have the potential, so
       they could well be caught at a later point in time.
       They go to one of the later Horizon Issues.
   Q.  I'm focusing exclusively, and I would be very grateful
       if you would focus exclusively, on bugs having an impact
       on branch accounts, okay?  I'm not going to be asking
       you questions about Issue 4 or other issues.  I'm
       focusing today exclusively on Issue 1, okay?  Just to be
       clear.
   A.  Right.
   Q.  What I'm suggesting -- what I'm seeking to ascertain
       from you, Mr Coyne, is that by saying your expert
       judgment is that there are 21 bugs which are lasting, it
       follows that eight of the bugs on the bug table in JS2,
       eight of those bugs in your view are not lasting,
       correct?
   A.  Yes.
   Q.  So in your expert view, you do not suggest that those
       eight bugs got past countermeasures, would have got past
       the Horizon countermeasures?
   A.  Yes, that's true.
   Q.  Thank you.  That's very kind.
   MR JUSTICE FRASER:  A different way of putting the same
       point is the passage that I asked you about, which is at
       1.15 on JS2 on page 29, which said:
            "The number of distinct bugs, for which the experts
       have seen strong evidence of the bug causing a lasting
       discrepancy in branch accounts, is between 12 and 29."
           29 is now 21?
   A.  Yes, my Lord {D1/2/29}.
   MR JUSTICE FRASER:  Right.
   MR DE GARR ROBINSON:  That you are now asserting 21 rather
       than 29 takes me by surprise, Mr Coyne.  If I could ask
       you to look at the transcript for this morning.
   A.  Yes.
   Q.  Page 15, if we pick it up at line 11 {Day17/15:11}.
           "Question:  Let me ask a slightly different
       question."
           And I'm talking now about the bug list in JS2.
           "Question:  This is the definitive list, isn't it?
       You are not suggesting that there are other bugs with
       evidence of financial impact -- you are not relying on
       any other bugs with evidence of financial impact, it is
       just the 29 bugs identified here?"
           "Answer:  These are the ones that I have identified,
       yes."
   A.  Yes.
   Q.  I didn't ask you any further questions and moved on
       because I had understood you consistently throughout
       this case actually since before Christmas -- or
       certainly since your second report -- as asserting --
       well, actually since JS2 -- that the 29 bugs in JS2 were
       bugs with lasting financial effect.
           I form that understanding on the basis of the
       heading to the table.  If we could look at the bug
       table, it is {D1/2/3}.  So there's the heading.  It is
       page 3:
           "Table of Bugs/Errors/Defects with acknowledged or
       disagreed evidence of financial impact."
           What I had understood, Mr Coyne, was that this set
       out the bugs that you thought had -- and I'm going to
       introduce the word "lasting, it is not in the heading --
       that you thought had lasting financial impact and those
       bugs which Dr Worden thought had lasting financial
       impact.  My apprehension had been that you said 29 bugs
       had lasting financial impact and Dr Worden said only 12
       did.
   A.  Yes.
   Q.  If we move forward in the table to page {D1/2/27}, there
       are various agreements recorded here in relation to
       Horizon Issue 1, which of course is to do with
       shortfalls.
   A.  Yes.
   Q.  If we look at paragraph 1.2, look at "Statement", this
       is an agreed statement:
           "Referring to the table of bugs above, the experts
       agree that the bugs in rows 1, 2, 3, 10, 13, 14, 18, 23,
       24, 25, 27 and 28 may have had financial impact on
       branch accounts.  Other rows, the impact is not agreed
       between the experts."
   A.  Yes.
   Q.  That's 12 bugs.  And I had understood the position, in
       fact everyone on this side of the court had understood
       the position, that Dr Worden accepted that those 12 bugs
       had that financial impact, or there was evidence that
       those bugs might have had lasting financial impact, and
       the disagreement between you was that you said another
       17 did to get you up to 29.  Do you see?
   A.  Right.
   Q.  Then if we move forward in the table to page {D1/2/29},
       please, in the joint statement, and we look at
       paragraph 1.15, another agreement:
           "The number of distinct bugs, for which the experts
       have seen strong evidence of the bug causing a lasting
       discrepancy in branch accounts, is between 12 and 29."
           I thought -- and I'm telling you this so that you
       can explain what my mistake was and how I made it --
       that that 12 was the 12 referred to in paragraph 1.2 and
       the 29 was the other 17 in the table that you were
       asserting.  So my understanding of joint statement 2 was
       that you were asserting there were 29 bugs with lasting
       financial impact and Dr Worden -- or with evidence of
       lasting financial impact -- and Dr Worden was asserting
       that there were 12 bugs for which there was evidence of
       lasting financial impact.  Was I wrong?
   A.  Well, yes, you were wrong.  That was a statement that we
       agreed to put in because we couldn't get agreement on
       how many there actually were, so we ended up putting
       a range in for the purposes of --
   Q.  Here's what I don't understand.  I presumed that you
       agreed with the 12 bugs that Dr Worden had identified
       because they are set out in paragraph 1.2.
   A.  Yes.
   Q.  So the point was that you were asserting an extra --
       some extra bugs to bring us to a higher total, yes?
   A.  Yes.
   Q.  And in paragraph 1.15, forgive me, it appears that that
       higher total is given, namely 29?
   A.  Yes.
   Q.  Are you suggesting that you have only ever suggested 21
       and no one was suggesting anything above 21?
   A.  No.  There are 29 bugs, errors and defects in the list
       and in the table starting at number 1, but some of those
       go to other Horizon Issues apart from Horizon Issue 1,
       and they do say that clearly in the heading.
   Q.  The reason why I'm confused by your answer is that it
       seems to me -- and tell me why I'm wrong -- that in
       paragraph 1.15 it is being suggested that someone is
       saying there are 29 bugs which have lasting financial
       impact.
           If what you are now saying has always been your
       position, then nobody was ever saying that there were 29
       bugs with lasting financial impact.  So my question
       becomes: how is it you were saying in 1.15 that there
       were another seven bugs with lasting financial impact
       when no one was saying so?
   A.  I'm not actually sure who suggested the first draft of
       that statement.
   Q.  It doesn't matter though, does it?
   A.  No, it doesn't matter, but because it was correct it's
       gone in as agreed.
   Q.  How could it possibly be correct in a world in which
       Dr Worden was suggesting there was evidence for 12 bugs
       with lasting financial effect, and you were saying no,
       there's an extra nine to bring it up to 21, how could it
       possibly be correct that there might be 22, 23, 24, 25,
       26, 27, 28, 29?  Where do the other eight bugs come
       from?  How is it possible that there could be an extra
       eight bugs with lasting financial effect where you have
       just told me that neither you nor Dr Worden thought that
       there was?
   A.  Because some of the Horizon Issue 4 bugs, errors and
       defects that are reported in here and are reported in
       the joint statement could have a lasting impact on
       branch accounts but we don't necessarily have evidence
       of that.
   Q.  Mr Coyne, I would like to suggest that that is not any
       sensible or fair reading of what's set out in
       paragraph 1.15 and that on any sensible reading
       Dr Worden was alleging 12 and you were alleging 29.
   A.  Mm.
   Q.  And you refute that, do you?
   A.  No, at the time we were working from that table of 29
       bugs, errors and defects.  There were 29 in play that
       were being discussed.
   Q.  I have to say your answers are making things more, not
       less, clear.  I don't know what you mean by "being in
       play".  You either -- it is a binary situation.  It is
       almost a set of philosophical statements.
           A human being either believes that there's evidence
       that a bug has a lasting financial impact or he does
       not.  In a world in which Dr Worden believes that there
       are 12 and you believe that there are 21, and there is
       no one else in the room who has a belief because you are
       the only two people who are producing the statement, it
       makes no sense for anyone to mention an additional
       number to bring you up to 29.  You should have said: it
       is between 12 and 21.
   A.  No, but what you have said there precisely illustrates
       my point.  You said there is either evidence of, and the
       challenge is with a number of these there is evidence of
       there being a defect but there isn't necessarily
       evidence of financial impact from that defect.
   Q.  Mr Coyne, everybody on this side of the court, and
       I mean everybody on this side of the court, believed
       that your view was that the evidence showed that there
       were 29 bugs with lasting financial impact.  You are now
       saying that we made a mistake, are you?
   A.  Yes.
   Q.  Could I ask you to explain where you made it clear what
       you were actually saying?
   A.  Well, as set out in my second report, there is a table
       there that quite clearly says whether there is evidence
       of branch impact or not.  And there is also a list of
       which Horizon Issue it specifically relates to.  The
       only addition to that is when you come to the very last
       column, there's other bugs, errors and defects that are
       re-introduced and they are only covered in the joint
       statements.
   Q.  Would you give me a moment, I'm so sorry.  Because
       I wasn't prepared for the discussion we are now having
       I'm afraid I'm going to stumble rather.
           (Pause)
           So what you are suggesting is that there are I don't
       know how many ... In your table 1, how many bugs have
       you counted from your table 1 that you now say have
       evidence of lasting financial impact?
   A.  How many from your table?  Right, okay.  So 14 from the
       table.
   Q.  14.  Then an extra seven that come from the last item?
   A.  The last item, yes.  They are covered in the report at
       3.211.
   Q.  So it is the last item on the report.  There appears to
       be an item corresponding to that item in the bug table.
   A.  There is, yes.
   Q.  It is in {D1/2/21}.  It is bug 22.  So have I made
       another error, Mr Coyne?  Have I wrongly assumed that
       item 22 corresponded with the last item in your table 1
       in your joint report?  Are you now saying, no, no, that
       last item in the joint report actually accounts for
       a whole host of other bugs?
   A.  Yes, let me just turn to that in my report.
   Q.  I must admit I have been focusing on your bug table
       because this represents the last statement, as
       I understood it, of the issues between the parties or
       between the parties' experts.
   A.  It does.
   Q.  I'm not trying to stop you going to your report, please
       go ahead, Mr Coyne.
   A.  Yes.  Yes, they are covered in the 22 ... sorry.
       (Pause)
           So covered at 3.211 in the report.
   Q.  Yes.
   A.  You see the PEAKs that are ...
   Q.  There are two PEAKs in that section, {F/53/1} and
       {F/55/1}.  I'm not sure how that could account for
       another seven bugs.
   A.  But then if you go on from 22 you have got 23, bureau de
       change.
   Q.  You are saying that is an aspect of bugs, errors and
       defects introduced by previously applied PEAK fixes, are
       you?  Because it is plainly not right, Mr Coyne.  What
       are you saying?
   A.  Sorry, I'm drawing a blank now what the cross reference
       is for these ...  Sorry, I would need to search for that
       PEAK reference under the Coyne impact column against 23,
       bureau de change, just to see where that features.
   Q.  The interesting thing is if you look at table 1 in your
       second report {D2/4.1/18}, there is an item for bureau
       discrepancies.  That's different from bureau de change,
       is it?
   A.  I think bureau discrepancies is already covered further
       up in this joint statement.
   Q.  I see.  So are you saying that bureau de change were --
       they were within your category of bugs, errors and
       defects introduced by previously applied fixes?  Is that
       what you are saying?
   A.  Yes.
   Q.  And are you saying that for the others: wrong branch,
       customer change?  I don't want to put words into your
       mouth.
   A.  Yes, because the original bureau de change is at 14 --
       sorry, bureau discrepancies which corresponds --
   Q.  Sorry, it was a red herring I introduced.  I was trying
       to help and I do not think I did.
           Let me move away from that subject.  Perhaps we
       could have a think about that, maybe we will have
       a break in a few minutes and think about it, but before
       we do that, subject to his Lordship of course, I would
       like to go back to the first issue I was seeking to
       explore with you, which is how wrong we were about what
       your expert opinion was, and you told me that on this
       side of the court we were wrong to think that your
       expert opinion was that there were 29 bugs with lasting
       financial impact.
           Could you tell me where in any document you have
       indicated that your view is in fact not 29 but 21?
       Where will I get that from?
   A.  Throughout the report I have set out next to every
       single defect whether it is relating to the test of
       Horizon Issue 1 or a later Horizon Issue, and I have
       also set out whether I believe there was impact on
       branch accounts all the way through report number 2.
   Q.  Let's not talk about report number 2 because the
       statement -- the most up to date statement of the
       position, I think you agreed with me at the beginning of
       today, the culmination of all your work, including work
       you did after your second report, is the bug table in
       joint statement 2?
   A.  Yes, but when you put that to me I said that that can't
       be read in isolation, it must be read with the second
       report.
   Q.  Indeed you did.  And that was entirely fair because with
       particular PEAKs you might need to go back to your
       report to see what you said about those PEAKs.  But
       nonetheless, the bug table had 29 bugs in it which you
       said had financial impact.  I had thought you were
       saying all 29 had lasting financial impact for the
       reasons I have already explained because of what was in
       paragraph 1.15 of the joint statement.
           My question is: where in your joint statement do you
       say my view as to lasting financial impact is 21?  And
       if you say it nowhere, why do you say it nowhere?
   A.  Can I take you to one illustration of that?  If you look
       at number 21.
   Q.  In the bug table?
   A.  In the bug table.  {D1/2/20}  So that is transaction
       correction issues, and I say there in brackets "(Horizon
       Issue 4 & 15)".
           Then what my statement says there is:
           "Transaction correction bugs/errors and defects do
       not cause discrepancies with branch accounts but do:
           "(a) Reduce the Subpostmaster's ability to resolve
       any discrepancies ..."
           Etc.  So I make it clear in there that there's not
       an impact on branch accounts but it does relate to
       Horizon Issue 4.
   Q.  So you say you make it clear it is not 29.  So we have
       got down to 28.  Where do you make it clear that another
       seven should also be excluded from the list?
   A.  Number 17 {D1/2/16} has Horizon Issue 4.
   Q.  And where do you say that doesn't have lasting financial
       impact?
   A.  If you read the text it doesn't suggest that it does.
   Q.  Here's what I find really interesting, Mr Coyne.  I'm
       looking at your table 1 -- you know you keep wanting me
       to go back to look at your second report.  If I look at
       table 1 of your second report it has an entry for branch
       customer discrepancies {D2/4.1/18}, and in the "Evidence
       of Branch Impact" column it has the word "Yes".  So did
       you make a mistake, should you have written "No" there?
       Or are you putting a construction on bug 17 in the table
       that it doesn't bear?
   A.  If you read Dr Worden's opinion on that, recovery
       messages needed to be dealt with to correct the
       discrepancy at the branch.  So there was an impact on
       branch accounts but it was corrected.
   Q.  Let's move on.  So far we have taken out two of these
       items on the list.  Where are the others coming from?
       Which others should we be taking out?
   A.  So 19, Post & Go, that's a Horizon Issue 4.
   Q.  Yes.
   A.  So on the table I have said that there is evidence of
       branch impact on there.
   Q.  Sorry, which table?  What am I looking at?
   A.  Forgive me.  In my second report, on the table, you will
       see that Post & Go is listed as a Horizon Issue 4.
   Q.  Yes, and it is also listed as having evidence of branch
       impact --
   A.  I will take you to that in one second, yes.  In the
       joint statement table that explains that that's Horizon
       Issue 4.
   Q.  Right.
   A.  And there is evidence of branch impact.  The problem
       impacted at least one branch account for 43 days and it
       appeared repeatedly on the daily report to the
       Post Office from Fujitsu.
   Q.  Rather than -- I'm not taking you to task or criticising
       you for this, and I understand entirely why you are
       explaining your reasoning, but in the first instance
       could you simply tell me the bugs that you think should
       be taken out from the list I thought I was facing and
       then we can perhaps talk about them after you have done
       that?
   A.  You want the bugs to take out?
   Q.  Yes.
   MR JUSTICE FRASER:  At the moment I have been noting it.  We
       have got 17, 21 and 19.
   A.  So phantom transactions, which is number 15 {D1/2/13},
       that is a Horizon Issue 4.
   Q.  Yes.  Does it say Horizon Issue 4 somewhere and I have
       missed it?
   MR JUSTICE FRASER:  I think table 1.
   MR DE GARR ROBINSON:  I see.  Yes.
   MR JUSTICE FRASER:  But you are right, it is not in the
       column in the joint statement.  Right, so that is
       another one.
   A.  Yes.  And branch account impact was noted on that.
           Number 16 {D1/2/13}, reconciliation, is Horizon
       Issue 4.
   Q.  You actually say -- in the bug table you say Issues 1, 4
       and 5.  So I should delete Issue 1, should I?
       {D1/2/14}.  I will do that.
   A.  Sorry, in the bug table?
   MR JUSTICE FRASER:  I don't want to be too pedantic,
       Mr de Garr Robinson, but do remember it is a joint
       statement.  So far as Mr Coyne is concerned --
   MR DE GARR ROBINSON:  From your perspective --
   MR JUSTICE FRASER:  -- can number 1 come out in the column
       against item 16?
   MR DE GARR ROBINSON:  Entirely fair, my Lord.  Although
       Dr Worden has never asserted that this is Issue 1
       but ...
   MR JUSTICE FRASER:  As I said, I don't want to be too
       pedantic, but at the moment it is a joint statement.  It
       might lead to a permanent and agreed deletion but for
       the moment.
   MR DE GARR ROBINSON:  I hadn't thought of that.
   A.  Yes, I have noted reconciliation issues as Horizon
       Issue 4.
   MR JUSTICE FRASER:  Okay.  I will tell you what my number
       is: it's 17, 21, 19, 15 and 16.
   MR DE GARR ROBINSON:  So there's another two to go.  Is that
       right?  No, it's another four to go.
   MR JUSTICE FRASER:  Mr Coyne, number?
   A.  So Post & Go is number 4 -- sorry, is Horizon Issue 4.
       That can come out.
   MR JUSTICE FRASER:  Can you give me the item number?
   A.  Number 19.
   MR JUSTICE FRASER:  You have given us that already.
   A.  Recovery failures, number 20 --
   MR DE GARR ROBINSON:  Right.
   A.  -- is a Horizon Issue 4.  {D1/2/19}  Transaction
       correction issues is a Horizon Issue 4.
   MR JUSTICE FRASER:  Item number, please?
   A.  Sorry, 21.
   MR DE GARR ROBINSON:  I'm reminded that you indicated that
       you got to 21 by treating one of these bugs as actually
       counting as seven, is that right?  The bugs, errors and
       defects introduced by previously applied fixes, was that
       right?  Or did I misunderstand what you said?
   A.  There should be seven within that heading.
   Q.  Right.  So does that mean we have to take a lot more
       from the index of the bug table to get to the right
       number?
   MR JUSTICE FRASER:  Mr de Garr Robinson, have you been
       taking a note of the item numbers in the joint
       statement?
   MR DE GARR ROBINSON:  I have been drawing circles around
       them, my Lord.
   MR JUSTICE FRASER:  I'm just going to tell you what my
       numbers are in case I'm wrong, and I'm putting these in
       numerical order: 15, 16, 17, 19, 20 and 21.  Does that
       match your numbers?
   MR DE GARR ROBINSON:  Mine are 15, 16, 17, 19, 20, and 21.
       My Lord, yes.  So we are down to 24 bugs.  There's
       another three to go, is that right?
   MR JUSTICE FRASER:  I think 29 minus six, yes, 23.
   MR DE GARR ROBINSON:  Or possibly more if bug 22 is actually
       seven.
   MR JUSTICE FRASER:  If we could for my purposes concentrate
       on the 29 subtracting these, because the 29 are
       individually set out.
           So, Mr Coyne, we started with 29 and you have taken
       six out.  Mr de Garr Robinson would like to know what
       the others are.  Are you in a position to tell us?
   A.  I will certainly try, my Lord.
           (Pause)
           Just from that tally, my Lord, I have only got six
       to take out of the list in here.
   MR JUSTICE FRASER:  Okay.
           Over to you, Mr de Garr Robinson.
   MR DE GARR ROBINSON:  So we are at 23, are we, not 21?
   A.  Just going from the joint statement, from what I have
       just done, yes.
   Q.  So how is it you arrived at 21 --
   A.  I have gone from the bottom up rather than the top down,
       so --
   Q.  I presume you thought of little else during the luncheon
       adjournment, which is why when you came back in you were
       very quick to explain -- to correct the answer that you
       had given his Lordship just before we broke.
   A.  Yes.
   Q.  So how is it that the position that you are adopting now
       is inconsistent with the position that you were adopting
       at 2.01 pm?  Can you explain that?
   A.  What I did over the lunch is I have gone from my table
       at page 12 of the joint statement and then added in
       seven under the last one, that's how I have got the
       number.
   Q.  When you say seven under the last one, I hesitate to
       change the subject, but the bugs, errors and defects
       introduced by previously applied PEAKs, which is the
       last item on table 1 of your second report, that whole
       section of your report only refers to two PEAKs.  So how
       is it that that section has somehow generated an extra
       seven bugs?  Could you explain that perhaps?
           I'm so sorry, it is four PEAKs.
   MR JUSTICE FRASER:  I'm not sure -- you might just want to
       re-consider that, Mr de Garr Robinson.
   MR DE GARR ROBINSON:  You are quite right.  It is 1, 2, 3,
       4 -- yes, it is four PEAKs.  Between 3.211 and 3.219
       four PEAKs are footnoted.
           Would your Lordship let me confer?
   MR JUSTICE FRASER:  By all means.  (Pause)
   A.  Sorry, what's just struck me about the ones at the tail
       end, it could well be the case that these are inclusions
       from Dr Worden.
   MR DE GARR ROBINSON:  Oh, I see.  So it isn't the case that
       these bugs introduced by fixes do explain another
       seven --
   A.  Or Dr Worden wanted them included into this joint
       statement.
   Q.  Let's just go back for a second and work out how many of
       these bugs you say there is evidence to justify the
       suggestion that there might have been a lasting
       financial impact.  You think there's such evidence with
       the receipts and payments mismatch, number 1, yes?
   A.  Let me start again.
   Q.  Let's go from the front.
   MR JUSTICE FRASER:  Are we in the joint statement?
   MR DE GARR ROBINSON:  In the joint statement, yes.  So you
       think there is evidence for number 1?
   A.  Yes.
   Q.  You think there is evidence for Callendar Square?
   A.  Yes.
   Q.  This is evidence of a lasting impact, yes?
   A.  Yes.
   Q.  You think there is evidence for suspense account bug,
       number 3?
   A.  Yes.
   Q.  Do you think there is evidence for lasting financial
       impact for Dalmellington?
   A.  There was certainly evidence that not all branches were
       resolved.
   Q.  So you include that as --
   A.  Yes.
   Q.  You think there's evidence of lasting financial impact.
       Okay.  What about remming in bug, number 5?  Is there
       evidence of lasting financial impact for that?
   A.  Yes.
   Q.  Remming out bug, 6/1?
   A.  Yes.
   Q.  Remming out bug, 6/2?
   A.  Yes.
   Q.  7, local suspense issue?
   A.  Yes.
   Q.  8, recovery issues?
   A.  Yes.
   Q.  9, evidence of lasting financial impact for reversals?
   A.  Yes.
   Q.  10, evidence of lasting financial impact data tree build
       failure discrepancies?
   A.  Yes.
   Q.  11, evidence of lasting impact Girobank discrepancies,
       that we discussed this morning?
   A.  Yes.
   Q.  12, counter replacement issues, evidence of lasting
       impact?
   A.  Sorry, you using the word "lasting impact" now.  I don't
       know whether Post Office went on to make any later
       corrections to sort out these discrepancies.
   Q.  I have sought to establish a degree with you on a number
       of occasions now the difference between transient impact
       that you think would have been caught by countermeasures
       and lasting impact that would not have been caught by
       countermeasures.  That's what I'm getting at, Mr Coyne.
       Because I think you agreed with me on at least one
       occasion previously that it is the lasting impact bugs
       that really have a material impact on robustness, or are
       capable of having an impact on robustness.  So that's
       what I mean by lasting.
           So counter replacement issues, you say there is
       evidence of lasting impact?
   A.  Yes.
   Q.  13, do you say there's evidence of lasting impact with
       withdrawn stock discrepancies?
   A.  Yes.
   Q.  14, do you say there is evidence of lasting impact with
       bureau discrepancies?
   A.  Yes, I believe so.
   Q.  Okay.  15, I will let you look at your report.
   A.  Sorry.  (Pause)
           Yes.
   Q.  Okay?
   A.  Yes.
   Q.  15 is out.
   A.  Yes.
   Q.  16 is out.  17 is out.
   A.  Yes.
   Q.  18, do you say there's evidence of lasting impact with
       18, concurrent logins?
   A.  Yes.
   Q.  I'm interested that you should say that, Mr Coyne,
       because if we could go back to your second report at
       {D2/4.1/18}.
   A.  Yes.
   Q.  Look at the table and look at concurrent logins, for
       "Evidence of Branch Impact" you say "No" there.  Did you
       change your mind?
   A.  After discussion with Dr Worden, yes.
   Q.  Okay.  Then 19 is out.  20 is out.  21 is out.
           What about 22?  I infer from what you have already
       said that you say there is evidence of lasting impact
       for 22, yes?
   A.  Yes.
   Q.  And 23, evidence of lasting impact, do you say?
   A.  Yes.
   Q.  24, wrong branch customer change displayed?
   A.  Yes.
   Q.  When you say "Yes", you mean evidence of lasting impact,
       I should make that clear.
   A.  Yes.
   Q.  Then 25, Lyca top up, do you say evidence of lasting
       impact for that?
   A.  Yes.
   Q.  At 26 do you say evidence of lasting impact on branch
       accounts for the TPSC250 report?
   A.  Yes.
   Q.  And 27, TPS, do you say there's evidence of lasting
       impact on branch accounts for TPS?
   A.  Yes.
   Q.  28, Drop and Go, do you say there is evidence for
       lasting impact for Drop and Go?  {D1/2/25}
   A.  Yes.
   Q.  And 29, network banking bug, do you say there's evidence
       of lasting impact for 29?
   A.  Sorry, I'm just checking the text on that.  I have
       actually got that down as the potential for bank account
       discrepancies.
   Q.  So is your view that there isn't evidence of lasting
       financial impact?
   A.  Yes.
   Q.  So that should come out, should it?
   A.  That should come out and that should be --
   Q.  That's network banking?
   A.  Yes.
   Q.  Very good.  Thank you.  So we have got from 29 I think
       down to 22.  Is that your final number?
   A.  Sorry, I'm still just reading the network banking one.
   MR JUSTICE FRASER:  While you just read that, are you
       counting 6 as one or two, just out of interest, because
       you went through it --
   MR DE GARR ROBINSON:  I'm counting it as one.
   MR JUSTICE FRASER:  Okay.  Counting it as one.
   MR DE GARR ROBINSON:  I'm using the same numbering system
       as --
   MR JUSTICE FRASER:  But it is just split between 6(a) and
       6(b) --
   MR DE GARR ROBINSON:  I hadn't factored that in, my Lord.
   A.  Certainly with regard to network banking it is causing
       potential for branch impact, but I haven't got evidence
       of discrepancies.
   Q.  So it comes out?
   A.  Well -- no, it will be a Horizon Issue 4.
   Q.  Given that today all I'm talking about is Horizon
       Issue 1, it is all I have got time to talk about and
       I have barely got time to talk about that, and that's
       not a criticism, by the way, it is just how things are
       these days, we are down from 29 bugs to 22 bugs.  Are
       you now sure that that's the right number?
   A.  Yes.
   Q.  And I would like to ask you why is it you thought there
       were 21 bugs at 2 o'clock, whereas you thought -- was it
       14 bugs at 1 o'clock?  13 bugs at 1 o'clock.
   A.  Because I was just counting down the table at number 1
       in my report.  In the pressure of the situation I just
       tallied that column down, I didn't have enough time to
       consider it fully.
   Q.  To go back to a question I asked you earlier, where do
       you make this clear in the joint statement?
   A.  In the heading next to the -- in the bug, error or
       defect.
   Q.  And you are saying that the heading to the bug table,
       which is "Table of Bugs/Errors/Defects with acknowledged
       or disagreed evidence of financial impact", you say that
       heading is sufficient to enable the reader to understand
       that of the 29 bugs referred to, in fact we only need to
       be concerned with 22 of them, yes?
   A.  Sorry, I'm talking about in the joint statement.
   Q.  Yes.
   A.  Yes.
   Q.  How is the reader supposed to divine from the heading
       that Dr Worden was saying evidence for 12 bugs and you
       were saying evidence for 22?
           Dr Worden indicates his position in the body of the
       joint statement but, as I said, in paragraph 1.15 and in
       the bug table itself you appear to be indicating your
       position that it was 29, and I would suggest to you,
       Mr Coyne, that in that respect the joint statement was
       seriously misleading.  Why was that?
   A.  We didn't believe it was misleading when we put the
       document together.  I mean, it is always a negotiated
       position to get the joint statements.
   Q.  As I say, Mr Coyne, everyone on this side of the court
       is taken completely by surprise by the suggestion that
       it is 22, not 29.  Indeed I venture to suggest that the
       claimants' own counsel are taken by surprise that it is
       22, not 29.  Now why is that?
   A.  I don't really see why that would be the case when, if
       you read the text in the report, it explains what
       particular Horizon Issue I'm attempting to deal with.
       I know today you have chosen to go through Horizon
       Issue 1, but in the report it attempts to deal with all
       issues -- all technical issues that were put to me.
   Q.  Section 1 of the joint statement relates to Horizon
       Issue 1, doesn't it?
   A.  Section 1 of the joint statement?  (Pause)
   Q.  If you look at the joint statement there is the
       introductory text, then there's the bug table.
       Immediately after the bug table, which is at page --
       there is a global agreement section, and then
       immediately after that at page 27 there are a series of
       propositions relating to Horizon Issue 1. {D1/2/27}
   A.  Yes.
   Q.  So section 1 of the joint statement talks about Horizon
       Issue 1.
   A.  Yes.
   Q.  As I suggested to you, the natural interpretation of
       what you say there in Horizon Issue 1, and in particular
       paragraph 1.15 on page {D1/2/29}, is that Dr Worden was
       saying 12 and you were saying 29 and I would venture to
       suggest that everybody on both sides of the court
       thought that was the position.  How could that possibly
       be the case?  How can your own counsel, Mr Coyne, have
       made that mistake?
   MR JUSTICE FRASER:  On the basis it is a joint statement,
       Mr de Garr Robinson, I think you have to be quite
       careful about how you put the question.
   MR DE GARR ROBINSON:  Could I ask you to go to bundle
       {A/1/1}, please.  This is the claimants' written
       openings.
   A.  Yes.
   Q.  Could we go to page {A/1/7}, paragraph 9.  It is said:
           "The fact that further significant bugs have come to
       light, in the way that they have, from the enquiries
       that the experts have been able to undertake, is
       significant ..."
           If we skip down to (4), you will see it says:
           "There are a number of further bugs identified so
       far, which Post Office had neither admitted nor
       volunteered: between 12 (Dr Worden) and 29 (Mr Coyne)
       bugs with ..."
           And there's a quote:
           "... 'strong evidence of the bug causing a lasting
       discrepancy in branch accounts'."
           That's why I asked that question.  How is it your
       own counsel thought you were saying there were 29 bugs
       with lasting effect if that wasn't the case?
   A.  It was a statement that was put in there to try and
       frame that the number that we would probably ultimately
       arrive at would be somewhere between those two
       parameters.
   Q.  I presume, Mr Coyne, that you reviewed the claimants'
       opening submissions either before or after they were
       filed with the court, would that be right?
   A.  I'm not sure I did.
   Q.  Are you suggesting that you didn't read the claimants'
       submissions before you came to give evidence today?
   A.  These are quite historic documents, are they?
   Q.  These were the submissions that the claimants filed with
       the court at the beginning of the trial.  It is the
       opening submissions.  I know you have considerable
       expertise in giving expert evidence.  The opening
       statements of both parties were put into the judge so he
       would have an understanding of the issues and where the
       parties saw themselves standing.  And I'm asking you
       whether either before they were submitted, which would
       be common, or afterwards you looked at the claimants'
       opening submissions.
   A.  I don't believe I have, no.
   Q.  So what we have is ships sailing in opposite directions
       in the night.  You in your own mind thinking I have got
       22 bugs.  Counsel for the claimants thinking it is 29.
       And no one ever discovering the truth until the judge
       asked you a question at about 12.59 pm today.
   A.  My answer is I can't recall reading the openings.
   Q.  Some people might think that you have adjusted your
       position in line with a position that you think it might
       be easier to defend in cross-examination this afternoon.
       What would you say to that suggestion?
   A.  That's not true.
   MR DE GARR ROBINSON:  My Lord, I wonder whether it would be
       a convenient moment to break so that I could look at the
       list and decide --
   MR JUSTICE FRASER:  What you are going to do.
   MR DE GARR ROBINSON:  -- what I'm going to do in the next 45
       minutes allotted to me.
   MR JUSTICE FRASER:  By all means.  3.10 pm.
   MR DE GARR ROBINSON:  Thank you.
   MR JUSTICE FRASER:  Thank you very much.
   (3.03 pm)
                         (A short break)
   (3.10 pm)
   MR DE GARR ROBINSON:  Mr Coyne, I have got 35 minutes,
       I have promised my learned friend that I will finish at
       3.45, so I will start with some bugs and we will see how
       far I get in that time.
           The first one I want to take you to is obviously
       a bug where you say there's evidence of lasting
       financial impact and I will go to Dalmellington first of
       all.
           Could we first of all go to {F/1389/1}, please.
       This is the PEAK that relates to Dalmellington and we
       can see there is a call in on 13th October 2015.  If we
       go to the second box on the first page, just underneath
       the "Incident Management" text, it says:
           "Transfer note: Please can PEAK investigate this
       discrepancy issue.  NBSC has confirmed that following
       discussions and checks with the user that this is not
       a user error issue, but an issue within the system
       requiring Fujitsu investigation."
           Do you see that?
   A.  Yes.
   Q.  So that's when the penny dropped that it was not a user
       error, it was a system problem?
   A.  Yes.
   Q.  If we move on to page {F/1389/5} of the PEAK.  At the
       bottom of the page Anne Chambers, who we have seen a lot
       of, she says at 15 October at 15.56:
           "We have found that if there is a logout before a
       user has fully logged on, then subsequently a pouch is
       remmed in manually (most likely at an outreach branch),
       then after the rem in slip has been printed, the same
       screen is redisplayed and the user is likely to press
       Enter again and duplicate the remittance, possibly
       several times.  A different screen should be displayed
       which would prevent this happening."
           So something I put to you I think either Wednesday
       or Thursday, and I think you may have not felt able to
       agree with it, the nature of the Dalmellington bug is it
       was a bug, if you want to call it a bug, which caused
       a screen to come up after a rem in had been made, and
       users thought that meant they had to press enter again
       and so it caused them to make a human error?
   A.  Yes.
   Q.  So from the perspective of the outside world, it was
       a bug which didn't itself cause a problem with branch
       accounts, but it had an effect under which it could
       cause subpostmasters to make a mistake which then would
       have an impact on branch accounts, yes?
   A.  Well, they would be following the instructions that they
       are given on screen.
   Q.  So what I'm suggesting to you, Mr Coyne, is that it
       mimicked exactly what would happen if a human error was
       made.
   A.  Yes.
   Q.  If someone remmed in the same thing to an outreach
       branch twice by mistake it would look exactly like that?
   A.  Yes.
   Q.  So from an outsider's perspective you would not be able
       to tell the difference between someone remming in twice
       by accident, because they are incompetent, and someone
       remming in twice because they had been given a screen
       which has made them do it.  From an outsider's
       perspective, like Fujitsu, it would seem exactly like
       a human error, wouldn't it?
   A.  It would until you looked at the very detailed logs,
       because when they did do that they discovered what the
       problem was.
   Q.  If we go back to the text:
           "A rem in slip is printed each time, showing the
       same details but different session numbers, and a
       transaction log search confirms the repeated rems."
           So what Anne Chambers is saying there is if you are
       the postmaster doing it, you get more than one receipt,
       you get more than one session number, you get pieces of
       paper and indeed logs which makes it clear that you have
       remmed in things more than once.  You would see it
       fairly quickly, wouldn't you?
   A.  There's certainly something printed, yes.
   Q.  Then Ms Chambers says:
           "This is not an area that has changed for several
       years so it likely to have happened before but we have
       no record of it having been reported to us.  I can only
       check back two months; I've found 4 other instances
       (outreach branches 214869, 106444, 110444, 207828) and
       all but the last removed the discrepancy by completing a
       rem out for the excess, which corrected the system cash
       holding branch 224843 may be able to do the same but
       NBSC should advise on this.
           "We are continuing to investigate the problem ..."
   A.  Yes.
   Q.  So it would be right, wouldn't it, that often it would
       be obvious to the postmaster that he or she has remmed
       in the same thing more than once, and where it is
       obvious to the postmaster he or she will be able to rem
       the amount out to correct for the error.  In other words
       it is possible, and indeed would often have happened,
       that postmasters would have been able first of all to
       identify the problem and, secondly, to exercise self
       help to fix it, yes?
   A.  Certainly a number of them did do that, yes, and that's
       reported later.
   Q.  And the simple fact is that where the Dalmellington bug
       caused double rems in, the fact that the same thing had
       been remmed in twice would always be visible in the logs
       and receipts and other information available to the
       postmaster, yes?
   A.  Yes, if you was to review the detail then typically that
       information will be in there, yes.
   Q.  And if you ran a trial balance for example or a report
       on the outreach branch, you would immediately see that
       there was a discrepancy and you would immediately see
       the amount of the discrepancy is the amount of the
       double rem in, yes?
   A.  No, I do not think it is as simple as that because
       typically with trial balances you might have a small
       discrepancy one way or the other anyway, so seeing
       an extra round £100 would often not be the case.
   Q.  Why do you say that, Mr Coyne?  That seems to me to be
       conjecture.  Do you have any basis for saying that?
   A.  Well, a lot of subpostmasters that you see do have small
       discrepancies one way or the other.
   Q.  But when you rem in amounts you wouldn't usually rem in
       £3.96, you would be remming in a round sum.  That is how
       it tends to works.
   A.  That's exactly my point.  If you have already a small
       discrepancy of £3.96 on there and then you rem in £100,
       what you suggested before is that you would see £100
       that was out -- or you wouldn't see £100 that was out,
       you --
   Q.  What I'd suggest to you, Mr Coyne, is you would see the
       outreach branch is £97 out and you would try and
       understand why that should be and you would see that the
       branch has received twice as much as you expected it to
       receive.  It would not be one of the more difficult
       problems to see in the logs and given that also you are
       given several receipts, would it?
   A.  I don't believe it would be as simple as that.  I do
       agree it is possible to spot it, but reconciliation in
       my experience typically isn't as simple as you suggest
       there.
   Q.  Where there are these remming in and remming out
       problems they produce receipts and payment mismatches,
       don't they?
   A.  Yes.
   Q.  And I think we have already agreed that receipts and
       payments mismatches are automatically reported through
       to Fujitsu, aren't they?
   A.  Well, it would come up at the monthly -- or it's likely
       to come up at the monthly balancing.  I don't know
       whether it would come up with the receipts and payments
       mismatch because it's --
   Q.  I don't have time to go into the technicalities.
   A.  Sorry.
   Q.  And I'm not criticising you for trying to answer
       carefully and accurately, I'm really not, but bearing in
       mind the time it is sufficient for my purposes if you
       will agree with me, as I think you will, that whether on
       the day or by the end of the relevant transaction period
       there will be an automatic report that is remitted to
       Fujitsu, is that right?
   A.  If not Fujitsu, that will be available in branch.
   Q.  Not just in branch but also it would automatically go to
       Fujitsu, wouldn't it?
   A.  That is the bit that I'm unsure about, whether in this
       scenario it would go automatically to Fujitsu.
   Q.  Let's look at what happened.  If we can go to
       {F/1415/1}, please.  This is a presentation that was
       made by Fujitsu to Post Office after Anne Chambers had
       realised that this bug existed.
   A.  Yes.
   Q.  It is dated 10th December 2015.  Now, so far as we are
       aware, the Dalmellington bug affected outreach branches,
       didn't it?
   A.  Yes.
   Q.  And the SSC reviewed logs to identify where similar
       scenarios could have occurred, yes?
   A.  Yes.
   Q.  And they did this by identifying duplicate remittances
       of unique pouch bar codes, correct?
   A.  Yes.
   Q.  The reason they did that was because a branch can't use
       the same barcode twice in the same rem in session but it
       is possible to use the same barcode in separate
       sessions, correct?
   A.  Right, yes.
   Q.  And they did this by gathering all the BLE files?
   A.  Yes.
   Q.  And the BLE files are the branch data files, data
       transfer files sent daily from Horizon to POLSAP?
   A.  To POLSAP, yes.
   Q.  Thank you.  They checked the BLE files looking for
       symptoms of the issue?
   A.  Yes.
   Q.  And we can see at page {F/1415/3} that the SSC have
       identified 112 occurrences, do you see that?
   A.  Yes.
   Q.  So an audit found 112 occurrences over the past five
       years, and it would be five years over which this
       problem would have operated, correct?
   A.  Yes.
   Q.  Then if we move on to the third bullet point, it says:
           "108 items were corrected at the time either by:
           "Transaction correction by Post Office."
           Or by the:
           "SPS reversal completed at the time."
   A.  Yes.
   Q.  Would you agree with me that what that shows is that
       even before the Dalmellington bug was discovered to be
       a bug, so even at a time when it was thought it was
       inexplicable to human error, in the overwhelming
       majority of cases -- in fact in all of the cases that
       had been looked at at that time, because they had only
       looked at 108, yes?  There were four items still to be
       confirmed.  Do you see that?
   A.  Yes.
   Q.  So with all of the occasions that they had looked at one
       of two things had happened.  Either the SPM had
       exercised self help and just fixed it himself or herself
       because it was quite easy to do that?
   A.  Yes.
   Q.  Or Post Office had issued a transaction correction
       because the information about the mismatch would have
       got through to the Post Office or perhaps a postmaster
       might have phoned in.  One way or another, the
       information would have got through to Post Office and it
       is Post Office's practice to fix errors of that sort by
       sending an appropriate transaction correction, yes?
   A.  Yes.
   Q.  So would you agree with me that putting those four
       branches that hadn't been looked at to one side, and
       I want to be absolutely clear about this, I know you
       don't want to and we will talk about them, but laying
       those to one side, the first 108 branches that they
       looked at, the countermeasures in operation in and
       around Horizon had caught them all and fixed their
       consequences, correct?
   A.  Yes.
   Q.  So subject to the four branches that hadn't been looked
       at, the countermeasures had 100% success rate, would you
       agree?
   A.  Yes.
   Q.  So would you agree with me that it is fair to say that
       this analysis shows that the relevant countermeasures in
       operation here worked very well, yes?
   A.  We wouldn't know how well they worked without trying to
       understand the amount of time between the fault
       occurring and its resolution.
   Q.  Are you suggesting that there is any reason to think
       that when an SPM exercises self help, he or she would
       only have done it after a considerable time?
   A.  No, I'm saying we don't know.  The evidence isn't there
       either way.
   Q.  So why are you even raising that with me?  What's the
       relevance of the point you are making?
   A.  Because you ask me: does it show that the
       countermeasures worked well or not?
   Q.  And you are hypothesising that there might have been
       a delay between the problem occurring and the problem
       being made good, is that what you are saying?
   A.  There may have been, and that would help me answer
       whether the countermeasures worked well or not.
   Q.  Do you have any reason to think that there would have
       been a delay in this kind of case?  Let's take it in
       stages.  First of all, an SPM exercising self help.  Do
       you have any reason to think that an SPM would have
       delayed in doing that, or do you think it is more likely
       that the SPM would have spotted the error quite quickly
       and fixed it straightaway when it was fresh in his mind?
   A.  They would certainly endeavour to fix it as quick as
       they had spotted what the issue was.
   Q.  Do you think there's any reasonable likelihood of the
       issue not being fixed within the trading period in which
       the error actually arose?
   A.  It would really depend on how good the SPM is at working
       out what has gone wrong from the information that he has
       got in front of him.
   Q.  I suggest to you, Mr Coyne, that it is plain as
       a pikestaff -- that's a phrase that lawyers are far too
       fond of and I have just used it and I'm really cross --
       but it is obvious, isn't it, that the last -- in the
       real world if a postmaster hasn't actually spotted the
       problem before he balances, before he rolls over, when
       he rolls over that's the point at which it is going to
       come out and that's the point at which he is going to
       exercise self help, wouldn't you accept that?
   A.  Yes, but at that point in time it could be some time
       after the event and there could be quite a lot of data
       to consider where the problem is.
   Q.  Well, here's the interesting thing.  We actually have
       evidence.  We know what happened and we know that the
       SPMs were all made good.  I think you are suggesting
       that delay may cause a state of affairs which ends up
       with the SPM not getting the right resolution, but we
       know that in relation to the Dalmellington bug that that
       isn't what happened.  We know that the SPMs were made
       good.
           So could I suggest to you that you are seeking to
       identify problems that are far more theoretical than
       real and that in the real world we know that SPMs were
       made good?
   A.  Yes, I accept they are made good.  I only introduced
       delay when you put to me that the countermeasures worked
       well.  That was the point in time that I questioned
       about the amount of time.
   Q.  Let me put it a different way.  They worked in a way
       that ensured that the financial impact of the problem
       wasn't lasting.
   A.  I mean the financial impact was resolved but we don't
       know when, I don't know whether it was seven days or 14
       days or what it was.
   Q.  Do you accept that of the 108 items that had been
       identified -- or, rather, that had been investigated at
       that stage, the evidence shows that the losses caused by
       Dalmellington in none of those cases were those losses
       lasting, do you accept that?
   A.  Outwith the four that we're not aware of at this stage.
   Q.  Do I have to make that clear again?  Haven't I made it
       clear already that I'm not going to come to those until
       we have finished with the 108?
   A.  Okay.
   Q.  And of the 108 that were looked at, do you accept that
       in 100% of those cases the countermeasures prevented any
       lasting loss from being suffered?
   A.  Yes.
   Q.  Thank you.  Now let's look at the four that were still
       to be confirmed.  We know that Mrs Van Den Bogard asked
       her team to examine what would happen with those
       branches, or at least -- in fact we should explain what
       the branches were.  If I could pick it up -- I'm so
       sorry, Mr Coyne.  (Pause)
           There is a page which identifies them and I'm now
       struggling to find it.  Could you give me a moment?
   MR JUSTICE FRASER:  Are you looking in the Fujitsu
       presentation?
   MR DE GARR ROBINSON:  Yes.  It is the page which indicates
       that the amounts of the four -- I'm terribly sorry not
       to have that page at my fingertips.
   MR JUSTICE FRASER:  Don't worry.
   MR DE GARR ROBINSON:  I'm so sorry, my Lord.  It is one of
       those occasions where you know that something is in the
       document ... Here we are, it is page {F/1415/8}.  I do
       apologise to everyone concerned.
           "Detailed Preliminary Findings", do you see that?
   A.  Yes.
   Q.  2011, six incidents.  2012, nine.  2013, seven.
           By the way, stopping here, you've seen the
       methodology that was adopted to identify the branches
       that were affected by this issue?
   A.  Yes.
   Q.  You don't have any objections to or concerns about that
       methodology, do you?
   A.  No.
   Q.  Thank you.  It would have been relatively easy for
       Fujitsu to identify all the affected branches in the
       last five years, would you agree?
   A.  Once they discovered it was an issue, that they worked
       out what the profile of the issue was and, as you
       explained, they then looked back to the historic files,
       yes.
   Q.  Thank you.  Then 2013, seven incidents:
           "4 transaction correction completed by POL.
           "1 corresponding remittance transaction completed by
       PMs.
           "2 unknown outcomes FAD 157242 - value £25,000 ..."
           That's quite a lot.
           "... and FAD 209311 - value £2,500."
           Then if we go forward to page {F/1415/9}, 2014, nine
       incidents.  And the third item under 2014:
           "1 unknown outcome FAD 214420 - value £0.01.
           I now need to find -- oh, and if we go back to page
       {F/1415/8} -- I'm really not covering myself in glory
       here -- 2012, nine incidents.  The third item:
           "1 unknown outcome FAD 120004 - value £1.00."
           So we have four branches that hadn't been
       investigated at that stage.  One had a thumping loss --
       or value, I should say, because it wasn't a loss as we
       both know, of £25,000.  Another one which had a value of
       £2,500, and then a third one with a value of £1 and
       a fourth one with a value of 1 penny.  And steps were
       taken to find out about the two big branches, yes?
   A.  Yes.
   Q.  If we can go forward to {F/1427.1/1}, please.  This was
       a subsequent report which was produced as a result of
       a request by Mrs Van Den Bogard.  We can take it very
       quickly.  There is a slow way of taking it but
       I suspect -- are you familiar with this document now?
   A.  Is there a title page for it or does it start with this?
   MR GREEN:  For context, it was disclosed on 4th March this
       year.
   MR DE GARR ROBINSON:  That's very helpful of my learned
       friend.  It really is useful to know that.
           This is a report that was produced by Fujitsu for
       Post Office.
   A.  Right.
   Q.  And I take it you have read this document.  I apprehend
       from a discussion we had the other day that you have
       read this document?
   A.  I'm not sure.  Has it got a title page?  Is that where
       it starts?
   Q.  That's where this document starts, yes.
   A.  Right, okay.
   Q.  So "Outreach Branch Issue - Report on Findings":
           "Summary:
           "As part of the investigation into the issue known
       as the branch outreach issue' an audit of the BLE files
       was undertaken by Fujitsu.  The detailed preliminary
       findings were then shared with Post Office.  Fujitsu
       reported that there were 112 occurrences of Duplicate
       Pouch IDs over the past five years where branches could
       have been impacted.
           "Fujitsu have clarified that their investigations
       into duplicate pouches were intended to find instances
       when a system issue had resulted in duplication."
           The third bullet point reads:
           "They have further clarified that the search of the
       BLE files entailed looking for any duplicate pouch for
       the same day/branch/amount.  This is the only reason
       that branch 209311 and branch 157242 have been looked at
       in detail.  There is no indication of any system issue,
       or any impact on the branch accounts in these two
       branches."
           Do you see that?
   A.  Right.
   Q.  So whatever happened in those two branches there was no
       net impact, there was no discrepancy caused in the
       branch.  Do you see that?
   A.  Right, because it was made good.
   Q.  Well, no.  If we go forward:
           "Fujitsu have confirmed that this is not an outreach
       issue and this correlates with Post Office findings that
       neither of these branches operates outreach services.
       Fundamentally, in respect of branch 209311 and branch
       157242 the remittance transactions were completed on
       different counters [while] in the case of the outreach
       branch issue, duplicate transactions take place on the
       same counter."
           Do you see that?
   A.  Yes.
   Q.  Then if we go over the page to page {F/1427.1/2}.
   A.  Sorry, can I read the last bullet point on page 1,
       please? {F/1427.1/1}
   Q.  Sorry.  Of course, please do.
           (Pause)
   A.  Right, I see.
   Q.  So what happened with these two branches is that they
       showed the same symptoms because the same pouch number
       was remmed in but it wasn't because the machine caused
       you to rem the same pouch twice, it was because one
       machine remmed it in properly using the barcode and then
       for some reason a human being operating on a different
       counter remmed it in manually.  He or she wouldn't have
       been able to do it by using the barcode because the
       system would have prevented it, but it is possible if
       you type in the numbers manually to do it twice, and it
       appears, remarkably, that in both of those branches that
       mistake was made.
   A.  Right.
   Q.  Do you see?  If we go over the page to page
       {F/1427.1/2}, second bullet point down:
           "Post Office concludes the issues at the branches
       have arisen as a result of remittances pouches received
       at the branch entered manually which had the same
       barcode id.  Thus creating duplicate entries which
       Fujitsu highlighted as part of the BLE files checks.
       However, in these instances from the available evidence
       Post Office concludes that the correct amount of pouches
       were delivered, accepted and entered on Horizon.  This
       is supported by the fact that there has been no negative
       impact in the branch accounts and no record of an issue
       raised by the branches with post Office.
           Do you see that?
   A.  Right.
   Q.  If one goes over -- there are then conclusions
       articulated in each case.  So with the first case, if we
       go to page {F/1427.1/10}, under the heading
       "Conclusion", the first bullet point:
           "All transactions were undertaken on 1 March 2013
       and within an hour between the first and final entry. It
       is assumed, based on the sequence of events that the
       branch understood an error was made and took action to
       rectify by recording a remittance surplus and
       subsequently redeeming the surplus, leaving the branch
       in balance."
           Do you see that?
   A.  Yes.
   Q.  Then if one moves forward to page {F/1427.1/12}, again
       under the heading "Conclusion":
           "Post Office can conclude that although there has
       been a duplicate pouch id recorded this is not related
       to the known 'outreach issue' but as a result of a
       manual entry of a remittance in.  Fundamentally, the
       transactions were undertaken on separate tills and the
       branch does not offer outreach services.
           "Based on the available evidence and absence of any
       shortages impacting on the branch accounts, Post Office
       concludes that the branch did receive two pouches
       containing £25,000.00 with the same barcode together
       with three further pouches on 18 February 2013."
           Then there is a reference to a £49,500 figure which
       was also -- the branch accounts also show.
           So you will see that in relation to the two extra
       branches that appeared to have significant values, it
       wasn't -- neither of them was actually an instance of
       the Dalmellington bug, do you see that?
   A.  Yes.
   Q.  Do you accept that?
   A.  This is what the investigation tells, so yes.
   Q.  And you have no reason to think that the investigation
       was wrong, do you?
   A.  No.
   Q.  So that leaves the two branches, one branch which
       suffered £1 loss -- I'm saying loss, that's quite the
       wrong word.  One branch where there was a £1 value and
       one branch where there was a penny value.  Now Mr Coyne
       it is quite right to say, and you are entitled to say,
       that there has been no investigation about those two
       branches and those two amounts of money, but bearing in
       mind the evidence that you have seen, in particular
       bearing in mind that when they looked at 108 branches
       they found that all of them, whether by way of self help
       or by way of a TC, had been made good.  What do you
       think the chances are that those two branches were not
       made good?
   A.  Very small.
   MR DE GARR ROBINSON:  Thank you.  My Lord, I see it is
       3.40 pm.  If I started another subject I would not be
       able to finish it.
   MR JUSTICE FRASER:  I do not think anyone will hold the 4
       minutes against you.  So that is the end of your
       cross-examination?
   MR DE GARR ROBINSON:  My Lord, that concludes my
       cross-examination.
   MR JUSTICE FRASER:  Thank you very much.
           Right, Mr Green.
                    Re-examination by MR GREEN
   MR GREEN:  Now, Mr Coyne, can we please look first at
       paragraph 3.128 of your second report which is
       {D2/4.1/51}.
   A.  Yes.
   Q.  And you will remember, if we go back to the previous
       page {D2/4.1/50}.
   A.  Yes.
   Q.  This was a section of your report that you were asked
       about quite a lot?
   A.  Yes.
   Q.  And if we go forward again {D2/4.1/51}, you were asked
       about paragraph 3.128 several times.
   A.  Yes.
   Q.  You were only taken to the first half of that paragraph.
   A.  Yes.
   Q.  In the last clause of that paragraph you say:
           " ... and illustrate, by their interlinking natures,
       the complexities of the PEAKs/KELs."
           What did you mean by that?
   A.  In that they share a reference to a particular KEL, so
       often you will see a different number of PEAKs referring
       to one KEL and that would suggest that there has been
       a number of occurrences of the same defect.
   Q.  Thank you very much.  You were also asked in
       cross-examination about the Ernst & Young reports.
   A.  Yes.
   Q.  Can we just bring up the transcript from Day 16 at
       page 173, first of all.  If you look at line 20, you
       were being asked about monitoring basically user
       privileges, do you remember? {Day16/173:20}
   A.  Yes.
   Q.  You were being criticised for saying nothing had been
       done about user privileges?
   A.  Yes.
   Q.  It was just an interesting answer at the bottom of the
       page there.  You say at line 23:
           "Answer:  Well, nothing got done or got improved
       over it and we can see that from the PEAK where Fujitsu
       are trying to address --"
   A.  Yes.
   Q.  Can we just take this in stages.  First of all, can we
       go to the Ernst & Young report itself, please, which is
       at {F/869/1}.  That is the management letter for the
       year ended 27th March 2011.  If we go forward to page
       {F/869/2}, please, that's the letter itself.
   A.  Yes.
   Q.  Explaining the work, if you look at the second
       paragraph, second line:
           "This work is not primarily directed towards the
       discovery of weaknesses ...."
   A.  Yes.
   Q.  Then on the third page {F/869/3} we can see the part you
       referred to in the bottom half of that page?
   A.  Yes.
   Q.  Could we now go forward, please, to the reference to --
       you were taken to pages {F/869/25} and {F/869/27} of it.
       Can we have a look, please, at page {F/869/30}.
   A.  Yes.
   Q.  Now, you will see there the heading "HNG-X".
   A.  Yes.
   Q.  That's Horizon?
   A.  Horizon Online, yes.
   Q.  It is common ground.  Did you look at this part?
   A.  Yes, I did.  So the auditors seek to take a sample of
       a number of changes that have been made to the system,
       so they looked at ten changes to the counter and five
       manual changes, and what they report here, that of those
       changes there is no record of those changes being
       retained -- there's no records available.
   Q.  Right.  I won't go further in relation to the control
       environment for changes because you have received
       a partial apology for that this morning.
   A.  Yes.
   Q.  But if we can look at permission controls on page
       {F/869/33}.  Again under "HNG-X", which is Horizon?
   A.  Yes.
   Q.  "There are inappropriate system privileges assigned to
       the APPSUP role and SYSTEM_MANAGER role at the Oracle
       database level ...
           "There is inappropriate privileged access at the
       oracle database level ...  System privileges assigned to
       the APPSUP role and OPS$TPS account are inappropriate
       ..."
           And so forth.
   A.  Yes.
   Q.  That actually continues on, doesn't it?
   A.  Yes, it is telling us that the auditor found that there
       was a number of very powerful roles that were available
       that would provide you access to the Horizon database
       for both reading and writing to the database and it was
       inappropriate.
   Q.  We see that all the way through to page {F/869/36}?
   A.  Yes.
   Q.  And then if we look at page {F/869/39}.  Just below
       "HNGX" again:
           "The “Change of Access to Live Network” form for the
       modified user selected for our Walkthrough was not
       authorised by a line manager ..."
   A.  Yes.
   Q.  So that is a slightly different point.  Then at
       {F/869/40} over the page, top bullet point:
           "Three instances of additional access being granted
       to a user without supporting evidence.
           "Inappropriate access to the pathways active
       directory [and so forth]."
           So there is a variety of points which --
   A.  It is generally very poor control of user privileges,
       potentially incorrect privileges being applied to
       certain groups of users.
   Q.  Okay.  Now to be fair, go back to page {F/869/33} very
       kindly.  There is a "Management Comment" that they will
       review adequacy and regularity of controls?
   A.  Yes.
   Q.  On the face of it, all might be absolutely fine.  You
       referred in your evidence in the transcript, the part
       I just took you to, to a PEAK?
   A.  Yes.
   Q.  But you weren't taken to any PEAK.
   A.  That is right.
   Q.  Can we look at {F/768/1} please.  This is the PEAK
       that's come up before in the proceedings, off piste and
       so forth.
   A.  Yes.
   Q.  Can we take it through, was this the PEAK you were
       referring to?
   A.  Yes, I believe it was.  Can we just look at page 2 of
       that?  I mean what is -- I mean the heading on there is
       that the SSC users have more access than is required to
       the database resources and this is contrary to
       a security policy.
   Q.  And that had been updated in May 2015?
   A.  Yes.
   Q.  And there are several places, we can see here if you
       look in the yellow box at the bottom.  (Pause).
           Item 4:
           "Scope: No actual impact/incidents of problems
       relating to this issue have been experienced yet (and
       not expected)."
           That's what they recorded themselves?
   A.  That is right, yes.
   Q.  My learned friend asked me to read that out.  While we
       are there.  2:
           "Cost.  There is currently no cost though to this
       issue."
   A.  That is correct.
   Q.  "Perceived Impact: The customer is not aware of this
       problem or change."
           So Post Office didn't seem to be aware, on the face
       of that, while we are reading out those headings, that
       they weren't aware of all this going on?
   A.  No, that is right.
   Q.  We can take it reasonably shortly, if we may.  In the
       yellow box at the bottom, effectively what I hope --
       this appears to be common ground on the face of the
       document, let me try and summarise it.  There was
       an issue of user creation scripts provided by
       development which offered the option to create each user
       type.  We can see that at (1) in the yellow box?
   A.  Yes.
   Q.  Effectively there had been some things created for SSC
       users but SSC users still wanted to have APPSUP access?
   A.  Yes.
   Q.  And that was the conflict they are trying to resolve?
   A.  APPSUP appears to be a group and that group provides
       a significant amount of privileges and the SSC users are
       in that group.
   Q.  When we look over the page at page {F/768/2} we have the
       bit with Anne Chambers halfway down.  She is talking
       about two different sorts of scripts and says:
           "When we go off piste we use APPSUP, can we have
       both?"
   MR JUSTICE FRASER:  Where are you reading?
   MR GREEN:  Halfway down the page, my Lord, in the yellow
       box.
   MR JUSTICE FRASER:  Yes.
   MR GREEN:  The point about APPSUP is made in various places
       but it is an extremely powerful tool, isn't it?
   A.  Yes, it could be described as a super user privilege.
   Q.  If we go to page {F/768/3} please.  There is quite a lot
       of arguing about what the nature and purpose of the PEAK
       is and so forth.
           We can see at the third yellow one down,
       16th August 2011, 10.08.07:
           "The optional role 'APPSUP' is extremely powerful.
       The original BRDB design was that 3rd line support
       should be given the 'SSC' role ~...and only given the
       optional role 'APPSUP' temporarily (by Security Ops
       authorisation) if required to make emergency amendments
       in BRDB Live. Since then Host-Dev have delivered a
       series of auditable amendment tools for known SSC data
       amendment operations in Live, and these are assigned by
       role to individual SSC user accounts. As such SSC should
       not require the APPSUP role in BRDB, unless there is an
       unforeseen update required to Live. [etc]."
   A.  Yes.
   Q.  Then there is a difference of view from Mr Simpkins
       below.  If we go down to the bottom we can see there is
       quite a lot of detail there and again it is reiterated
       that it is extremely powerful in the bottom yellow box:
           "Should only be used under extreme circumstances
       assist and under MSC supervision...  As such the Branch
       Database design was that..."
           That is all repeated then.  Then if we come down to
       just under the repeat, do you see about eight lines up
       from the bottom:
           "It is a security breach if any user write access is
       not audited on branch database."
   A.  That is right.
   Q.  Then it says:
           "... hence the emergency MSC for any APPSUP role
       activity = must have session logs attached under the
       MSC."
   A.  Yes, that's the blanket MSC that allows access to
       Fujitsu to conduct emergencies pre-approved.
   Q.  In the event, can we just go to the end, almost the end
       on page {F/768/7}.  Do you remember that the new people
       had not been given APPSUP?
   A.  Yes.
   Q.  But the old APPSUP privileges --
   A.  Weren't taken away, yes.
   Q.  Is that what you had in mind when you referred to the
       PEAK in your cross-examination?
   A.  That was absolutely the PEAK, yes.
   Q.  While we are on MSCs, you mentioned in your evidence
       that MSCs presented a bit of a challenge?
   A.  Yes.
   Q.  When you got them.  And you I think referred to that in
       your witness statement as well?
   A.  Yes.
   Q.  Could we bring up please {F/1844/1} the MSC complete
       data spreadsheet.  You have explained in your witness
       statement it is one of three separate Excel
       spreadsheets?
   A.  That is right.
   Q.  Which you have to use together?
   A.  Yes.  So it would appear that the MSC database was
       a singular database with all the data in it but the way
       that it has been provided to us, it would appear that it
       has been split into three different Excel spreadsheets
       but there's no easy way to try and interrogate across
       the three spreadsheets.  They aren't all the same
       length, so you can't put them together.
           One has lots of columns going across and the other
       one has literally hundreds of thousands of columns going
       down.  So it is practically impossible to use for the
       purposes of analysis.
   Q.  Let's just have a look.  That's the sort of document --
       one of the three documents you have to cross refer to
       each other?
   A.  This is the header document and from there you have to
       go to read the detail about it, yes.
   Q.  Could we go please to row 15024.
   A.  Yes.
   Q.  Let's go down to the bottom, just look there.
           "MSC emergency master change to cover any essential
       SSC adhoc works."
   A.  Yes.  This is the pre-approved MSC.  So that if anything
       comes up as an emergency, you don't have to effectively
       go through the MSC approval process again.  It is
       pre-approved.
   Q.  Could we now please look at {F/1834.14/1} please.  While
       that's coming, did you find these easy to work with?
   A.  No, they are terrible to work with.  I am sure they
       could have been provided to us in a database that we
       could interrogate rather than being exported to
       essentially text files or Excel.
   Q.  Were they small Excel files or quite big ones?
   A.  No, they are huge.  I don't know precisely what the
       numbers are but in megabytes terms they are quite high
       and they are hundreds of thousands of lines.
   Q.  If we look at the document we are now seeing, this is
       one of the MSCs produced by Womble's for the trial.
       This was actually uploaded on Friday.
   A.  Yes.
   Q.  Were you given any -- on 31st May -- MSCs in this form
       before the trial started?
   A.  No, it might well be the case that some of this text
       that appears on here might have been found within the
       Excel spreadsheets.  Certainly not in this format, no.
   Q.  That's helpful, thank you.  Sorry, one more reference if
       we can.  Can we look quickly at {C5/16/1}.  This is
       an email from you, on 20 July 2018 to Freeths and
       Womble's, copying in Dr Worden.
           "Information requests following the first day
       looking at PEAKs/Tfs"?
   A.  Yes.
   Q.  You say:
           "During the first day spent at Fujitsu looking at
       the TfS and PEAK systems, both Dr Warden and I noted
       information that would be helpful in the drafting of our
       respective reports."
   A.  Yes.
   Q.  "Whilst the request for some items of information on the
       below list may be supported by Dr Worden, I have been
       unsuccessful in gaining agreement ..."
           Then you mention PEAKs and various other things?
   A.  Yes.
   Q.  And at the bottom MSCs, OCRs and OCPs?
   A.  Yes.
   Q.  Why did you think those might be useful to see at that
       period?
   A.  Because I thought that they may indicate what changes
       had been made to branch accounts or the databases.
   Q.  Now, yesterday, on Day 16, you were cross-examined
       about -- let's have a look please, Day 16 in the
       transcript, page 22.
           We will look at line 18 {Day16/22:18}, if we may.
       It is the bit about the claimant FAD codes.  It says:
           "Question:  And both you and Dr Worden are aware of
       the FAD codes that relate to a very helpful sample in
       the context of this case, aren't you, which is the FAD
       codes of the claimants in these proceedings, yes?"
           Then you say:
           "Answer:  Yes.  In one of my early requests for
       information the response that I was given is that
       I shouldn't be requesting any information that makes any
       attempt to identify particular claimant
       characteristics."
           Then you are met with:
           "Question:  Mr Coyne, I really don't think you
       should be suggesting that Post Office were telling you
       not to look at that group as a group.  We could have
       a discussion about it if you want, but could I caution
       you against making that claim because that wouldn't be
       an entirely accurate way of characterising what
       happened, would it?"
           You say:
           "Answer:  Can we go to the RFI and have a look?"
           And you are met with:
           "Question:  Let's to do it after a break, shall we?"
   A.  Yes.
   Q.  You weren't shown the RFI.
   A.  No.
   Q.  Can we look please at {C5/21/5}.  Thank you very much.
       If we look at paragraph 1.3 there.
   A.  Yes.
   Q.  You will see you are asking about a document where
       there's documentation which might detail any specific
       branches that were affected.
   A.  Yes.
   Q.  That refers to {F/238/1}.  And there is a sort of
       standard answer at the top about the technical documents
       and: Mr Coyne, Post Office is in no better position to
       search the documents.
   A.  Yes.
   Q.  And then underneath that, at the bottom four lines:
           "It also appears to be an attempt to obtain
       documents containing information that could potentially
       be tied to individual cases.  That is not the purpose of
       the Horizon trial."
   MR JUSTICE FRASER:  You have gone onto the next page.
   MR GREEN:  Yes, sorry, if you could go on to the next page
       {C5/21/6}.  Was that what you had in mind?
   A.  That's exactly -- and I think that's repeated in another
       part of the RFI as well.
   Q.  Let's look at 1.5 on the next page {C5/21/7} please.
       This was the Golden Gate replication issue?
   A.  Yes.
   Q.  In relation to dix    Oracle being aborted and resulting
       in a number of branches reporting, over the page, cash
       declaration ... Go over the page very kindly. {C5/21/8}.
       Stock reporting discrepancies.
   A.  Yes.
   Q.  "Were any transaction corrections sent to the 247
       affected branches as a result of the discrepancies and
       which branches were affected by the incident?"
   A.  Yes, this was an attempt for me to go from the
       information that I see within the PEAK, talking about
       discrepancies, to see whether they were made good by
       Post Office.
   Q.  Whether or not they were made good in the end.  It is
       the bottom paragraph on that second page:
           "It also appears to be an attempt to obtain
       documents containing information that could potentially
       be tied to individual cases. That is not the purpose of
       the Horizon issues trial."
   A.  Again in the end column that's repeated as well.
   Q.  Yes.  Remains of that view, right-hand side.  Then if we
       can go forward, I'm sorry to be taking this at some
       pace, Mr Coyne.
   A.  It is all right.
   Q.  {C5/22/1} if we can.  On page {C5/22/2} of that
       document, which is the response to the email, if we look
       in (vi) you are asking for:
           "PEAK and/or TfS records for any claimant who has a
       record including any audit data for the period (at least
       a month)  ... Post Office objects to this request.
       Mr Coyne is seeking documents relevant to specific
       claimants but the Horizon Issues trial will not be
       considering the circumstances of individual claimants.
       Post Office's solicitors requested an explanation for
       this in a letter ... but no response has been received."
           Yes?
   A.  Yes.
   Q.  Then they say this information hasn't been pooled or
       collated and it would be necessary to carry out a review
       which they say is disproportionate.
   A.  Yes.
   Q.  Do you feel that you should be cautioned from saying
       what you said yesterday?
   A.  Not at all.  No.  I mean that data would have been very
       pertinent to the instruction that we had been given.
   Q.  Can we move forward to something you were asked to do
       and let's look at {F/78.1/1}, please.  You were asked to
       do some homework specifically and to identify some
       PEAKs?
   A.  Yes.
   Q.  You identified PEAKs at 78.1, 123.21, 198.2, 271, 338,
       345.1, 414.1 and 1115.1 all in bundle F?
   A.  Yes.
   Q.  I'm not going to take you to all of them.
   A.  Right.
   Q.  Can we just choose one or perhaps two.  Let's look at
       {F/338/1}, please.  That is PEAK number PC0133933 and
       you can see this is around March 2006.
   A.  Yes.
   Q.  On page 2 of that PEAK {F/338/2}, you can see there are
       two reasonably large yellow boxes?
   A.  Yes.
   Q.  One halfway down, one three-quarters of the way down?
   A.  Yes.
   Q.  And you can see what the PEAK problem was referring to?
   A.  Yes.
   Q.  Yes?  And then at the bottom of that box:
           "I believe this PEAK should therefore be transferred
       to Escher-Dev, so this PEAK is being routed to QFP for
       their consideration."
           Escher were developers for Riposte?
   A.  That is right.
   Q.  If you look at the bottom yellow box, 6th April 2006,
       14.07:
           "This may be a 'well known problem' but this does
       not mean it is worth chucking over the fence to Escher!
       We need to give them a reasonably high probability
       scenario in which the problem arises.  If it is only
       a tiny percentage or fraction of daily transactions then
       they can hardly be expected to investigate it with no
       further evidence.  Gareth Jenkins confirms that this
       logic has been applied all along."
           Then if we now go please to {F/414.1/1}.  If we
       could look please at page {F/414.1/9}.  Do you see there
       in the bottom -- middle yellow box --
   A.  Yes.
   Q.  -- it talks about:
           "A possible alternative to the one suggested above
       by Mark Scardifield (replacing the Notify timer with an
       independent one) would be to tidy up (one-line code
       change) NBFramework so that it does not loop when it
       times out a component.  Then we could be justified in
       reducing the configured timeout period for
       NBRequestReply from the present ten minutes to say one
       minute.
           "However this timeout is still rather 'brutal' and
       does not provide for any recovery actions such as
       resetting the PIN pad or suggesting that the Clerk tells
       the customer to retrieve their ICC card. This clumsiness
       may be acceptable for a rare occurrence; it can easily
       be worked around and the PIN pad can be reset by
       subsequent actions.
           "However it is not clear whether the transaction
       recovery is really adequate in this circumstance. This
       could be investigated ..."
           Then at the bottom:
           "BTW it is not understood in EPOSS Dev why this
       whole problem appears only with Banking transactions.
       Surely the whole Riposte and comms path is
       identical ..."
           Do you see that?
   A.  Yes.
   Q.  If we go over the page {F/414.1/10}, we can see at the
       top of the page, do you see if you come four lines down:
           "For 145617 I accept that we are unlikely to get
       a fix from Escher, and even if we got one, we are
       unlikely to implement it."
   A.  Yes.
   Q.  Do you see that?
   A.  Yes.
   Q.  Now, this also makes a reference to cost benefit in this
       PEAK as well.  Now, these were the PEAKs that you found?
   A.  Yes.
   Q.  Did they undermine what you felt about the relevance of
       cost benefit approach?
   A.  No.
   Q.  You were also asked questions about the Riposte message
       searching?
   A.  Yes.
   Q.  And you mentioned that you had come across Riposte
       import which had been helpful to search for?
   A.  That is right.
   Q.  Can we look at {H/253/1}, please.  This is a letter of
       20 March, so this is during the trial.
   A.  Yes.  Is this the letter which points out the suggested
       things to search for?
   Q.  It is.  And you see there -- this is the bit where
       a SSC -- an unnamed SSC technician has done some
       searches as well and Riposte import is mentioned there.
   A.  Yes.
   Q.  Can you remember whether you had identified Riposte
       import before or because of this letter or after?
   A.  I think we had only started to use it as a result of
       these messages here.
   Q.  Thank you.
   MR JUSTICE FRASER:  "These messages", you mean --
   A.  Sorry --
   MR JUSTICE FRASER:  The letter?
   A.  -- the strings, yes, the letter, and knowing that these
       are suitable things to search for on our system.
   MR JUSTICE FRASER:  As a result of the letter?
   A.  Yes, my Lord.
   MR GREEN:  You were also asked about the difference of
       an hour between the two sets of ARQ data and other data.
   A.  Yes.
   Q.  Can you remember when you realised or learnt of that
       difference?
   A.  I believe that I have only really surmised that the
       reason for the difference is just a time zone
       difference.  I do not think I have ever been told that's
       what it is.
   Q.  Can we look at Day 16 of the transcript, please,
       page 12, line 7 {Day16/12:7}.  It was put to you that
       MSCs had been disclosed on the Friday before Christmas,
       21 December?
   A.  Yes.
   Q.  And OCPs and OCRs on 24th January?
   A.  Yes.
   Q.  If we look at {H/263/1} now, this is a letter of
       18th April 2019.  There was an extra 2,500 OCRs
       disclosed on 18th April.
   A.  Yes.
   Q.  Mr Coyne, can I ask you whether you have been busy since
       the time that the Horizon trial should have ended, had
       it gone to plan and not been derailed?
   A.  Yes, yes, I have got a number of other projects.
   Q.  Have you had a give oral evidence in any other cases?
   A.  Yes, I have had to give oral evidence in a case at
       Manchester and I have a number of other non-contentious
       projects where I'm helping companies go live with big
       systems.
   Q.  How have you found the timing of your receipt of
       documents for the purposes of preparing your reports?
   A.  It has been very problematic.
   Q.  How does it compare to other cases you have been in?
   A.  I don't think there has been another case where I have
       experienced this level of -- the disclosure being
       provided in dribs and drabs, especially after making
       a specific request back in June of last year because it
       was quite clear then the types of documents that would
       be required.
   Q.  And finally, you were asked what proportion of OCRs had
       been granted -- permissions had been granted
       retrospectively?
   A.  Yes.
   Q.  Do you have that number?
   A.  I do.  I searched last night.  There's just over 21,000
       OCRs and OCPs and there is 1,450 that are described as
       being created retrospectively, that's about 7%.
   MR GREEN:  Thank you very much.
           My Lord, I have no further questions.
   MR JUSTICE FRASER:  I don't have any -- let me just check.
       I do not think I have any, but let me just check.
           No, thank you very much, Mr Coyne.  You can leave
       the witness box because we have a few matters to deal
       with, although I do not think very many, or certainly
       not very many from me.
                            Discussion
   MR JUSTICE FRASER:  The next day of evidence is Tuesday
       morning.  You are calling Dr Worden, is that right?
   MR DE GARR ROBINSON:  My Lord, yes.
   MR JUSTICE FRASER:  So it is Tuesday, Thursday, Friday of
       next week?
   MR DE GARR ROBINSON:  My Lord, yes.
   MR JUSTICE FRASER:  Mr de Garr Robinson, yesterday you
       identified or referred to Ernst & Young audits for
       different years going on from 2011 onwards.
   MR DE GARR ROBINSON:  Yes.
   MR JUSTICE FRASER:  Can you just let me have a list of
       references?
   MR DE GARR ROBINSON:  The trial bundle references?
   MR JUSTICE FRASER:  Yes, please.
   MR DE GARR ROBINSON:  My Lord, yes.
   MR JUSTICE FRASER:  You were also going to just send me on
       Monday I think some information, just a summary --
   MR DE GARR ROBINSON:  A very short note summarising the
       redaction position, yes.
   MR JUSTICE FRASER:  The redaction exercise.
           Then the only other thing I have --
   MR DE GARR ROBINSON:  My Lord, can I just ask, when you say
       the Ernst & Young audits, do you mean the service audits
       for Fujitsu or do you mean --
   MR JUSTICE FRASER:  Well, yesterday you put to the witness,
       and I can find my note in a moment, I think you said "We
       have them for each year 2011, 2012", and you went
       through a list of years.
   MR DE GARR ROBINSON:  Those were the service audits,
       my Lord.  I will give you the references for those.
   MR JUSTICE FRASER:  If you can just give me the references.
           Then the only other point is the PEAKs and KELs hard
       copy file.  I remember at the beginning of the evidence
       of fact I said could I have one, and I was anxious not
       to impose too much of a burden on anyone and I said
       I didn't need a detailed index.  The indices that came
       through were somewhat idiosyncratic, I think that's
       because they were not necessarily done by the same
       person which is really not a problem, but it makes the
       file really quite difficult to follow.  I think it was
       broken down by per day, per sitting day.
           I deliberately haven't marked it because I have been
       using the electronic ones.  I have got an index for --
       well, I have got a document which says it is an index
       for week 1 and a document that says it is an index for
       week 2.  Week 2 does refer to numbered tabs, but the
       tabs that are in the file aren't numbered in accordance
       with the tabs in the index.  For example, one would
       start at tab 97 and I can't find tab 97 for the life of
       me.  I think it is just re-ordering the way the index
       and/or the tabs are numbered.  I'm not asking for the
       actual contents to be re-ordered.
           Did it come from the claimants or did it come from
       the Post Office?
   MR DE GARR ROBINSON:  I believe it is a combined process.
   MR JUSTICE FRASER:  I'm in no way on any sort of a witch
       hunt.
   MR DE GARR ROBINSON:  Everyone is looking around furtively
       at the other side.
   MR JUSTICE FRASER:  It is just to try and get that file in
       a usable form.  That usefully is the evidence of fact
       file.  There is as yet no expert evidence PEAK file but
       I would like to make it clear that I would like one at
       some point.
   MR DE GARR ROBINSON:  My Lord, could I ask how you would
       like that file organised.  Are you content that it
       should remain in day by day form?
   MR JUSTICE FRASER:  Yes.
   MR DE GARR ROBINSON:  It is simply a matter of getting the
       right index?
   MR JUSTICE FRASER:  For example, you put one of the more
       important PEAKs to Mr Coyne, which had already been
       dealt with.  It was impossible for me to find where that
       was in the end.  I know it is in here somewhere.
   MR DE GARR ROBINSON:  I see.
   MR JUSTICE FRASER:  But, for example, if one looks at the
       index for week 1, which I will just hand you and then
       you will see what I mean.  (Handed)  You will see that
       really is just a total of everything that's in the file
       without necessarily telling you where it is or being in
       any immediately discernible order.
   MR DE GARR ROBINSON:  Could I ask, are there markers?  Are
       there dividers between each PEAK?
   MR JUSTICE FRASER:  Well, there are, but they don't seem
       necessarily to follow.
   MR DE GARR ROBINSON:  I'm wondering whether your Lordship
       would like a paginated bundle -- I don't want to make
       work for anyone -- and an index --
   MR JUSTICE FRASER:  Paginated would be glorious.
   MR DE GARR ROBINSON:  Yes.
   MR JUSTICE FRASER:  So what it really amounts to,
       Mr de Garr Robinson, without spending too long, is this
       file in either a different order or a more usable form.
       I'm happy for it to stay in the current order, which is
       per day, if I could, for example, think well that was
       put on Day 3, and actually find where Day 3 is in here
       and look at it.  And a similar wholly separate file for
       the PEAKs that are going to be put to the experts.
   MR DE GARR ROBINSON:  But ordered in the same way, day by
       day.
   MR JUSTICE FRASER:  Either in the same way or in their own
       separate way, I don't much mind.
   MR DE GARR ROBINSON:  If it is not day by day it is
       difficult to think how else one would actually do it.
   MR JUSTICE FRASER:  I prefer day by day because it makes it
       easier.
   MR DE GARR ROBINSON:  My Lord, does that mean you are happy
       for the file to contain duplications?
   MR JUSTICE FRASER:  Yes.
   MR DE GARR ROBINSON:  My Lord, I don't have instructions to
       do this, but could I volunteer entirely without
       instructions to take that file, paginate it, and get
       a proper index for your Lordship?
   MR JUSTICE FRASER:  By all means.  You will see I have
       flagged the week 2 index in here, which is in
       a different form to the one I have just given you, which
       is week 1.  This is the one that says tab 97.
   MR DE GARR ROBINSON:  Which doesn't exist.
   MR JUSTICE FRASER:  No.  Unless there is a strange non-base
       10 numbering system which I haven't come across.  Would
       you like this back?
   MR DE GARR ROBINSON:  If your Lordship is happy --
   MR JUSTICE FRASER:  It is deliberately not marked.  There is
       some writing on the index for week 2 but that actually
       isn't my writing.
   MR DE GARR ROBINSON:  Very good.
   MR JUSTICE FRASER:  It was there when the file came.
   MR DE GARR ROBINSON:  My Lord, we can do that and we can
       produce it by Tuesday.  We can produce it by the time we
       start on Tuesday next week.
   MR JUSTICE FRASER:  That would be very helpful.  Then after
       next week, if the same thing can be done for the
       experts, please.
   MR DE GARR ROBINSON:  Yes.
   MR JUSTICE FRASER:  I think we have achieved consensus.
   MR DE GARR ROBINSON:  The only thing on my list was to
       remind your Lordship about the PEAK files but we've done
       that.
   MR JUSTICE FRASER:  PEAKs and KELs, but that is it, that's
       because I remembered.
           Anything else?
   MR GREEN:  My Lord, no.
   MR JUSTICE FRASER:  One final point, and it is really not
       a big point, I got an email from Opus about transcripts
       to be moved from one work space of Horizon across to
       another.  I don't recall asking for that to be done.
       I don't mind it being done.  I think it flowed from the
       point I made about Day 13 and where was it.
           I know what day we are on here, this shows 17
       sitting days.  If between you, you could just agree
       which days we have in fact sat and what their numbers
       are in terms of the sequential number of the hearing
       that would be useful.
   MR DE GARR ROBINSON:  It's probably easier for me because
       I have only been here when we have actually been doing
       Horizon business so I will discuss that with my learned
       friend.
   MR JUSTICE FRASER:  Again, it is just to be consistent,
       that's all.
   MR DE GARR ROBINSON:  We can do that on Monday morning.
   MR JUSTICE FRASER:  Thank you all very much.  Tuesday at
       10.30.
   (4.28 pm)
         (The court adjourned until 10.30 am on Tuesday,
                          11 June 2019)