This is the transcript of Day 15 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 Tuesday 5 June 2019.
Jason Coyne, independent IT expert for the claimants spent the second of four scheduled 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:
Jason Coyne, independent IT expert for the claimants spent the second of four scheduled 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:
Wednesday, 5th June 2019
(10.30 am)
MR JASON PETER COYNE (continued)
Cross-examination by MR DE GARR ROBINSON (continued)
MR JUSTICE FRASER: Mr de Garr Robinson, just two things
before we start.
Judgment number 5, which I know you are not
interested or involved in, went out this morning. The
embargo doesn't really apply because it is detailed
reasons for decisions which were made public last week,
but I would like a list of typographic errors by
6 o'clock tomorrow.
And in the interests of transparency, the learned
usher just told me, just before I came in, that he had
been given a message by the witness to give me, and
I said I didn't want to hear the message and I'm not to
take messages from witnesses in that way or indeed in
any way, but I wanted both parties to know that that
exchange had taken place.
MR DE GARR ROBINSON: My Lord, thank you for letting us
know.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: Would your Lordship like to
investigate that question?
MR JUSTICE FRASER: No, I don't intend to do anything at all
but I wanted both of you to be told straightaway.
MR DE GARR ROBINSON: I understand.
Mr Coyne, good morning.
A. Morning.
Q. Yesterday I'm sorry to say we gave you some homework.
A. Yes.
Q. We discussed your claim that bugs are often deferred or
not dealt with at all on a cost benefit basis, do you
remember making that claim?
A. I do.
Q. And I asked you whether you can think of any PEAK other
than the particular PEAK we were looking at that shows
that happening.
A. Yes.
Q. Have you been able to find the handful or so of PEAKs
you referred to yesterday?
A. Yes, I have.
Q. I'm very grateful. Do you have that on a piece of
paper?
A. I do indeed.
Q. Perhaps the sensible thing to do would be at the break
if you could give me the piece of paper and we can copy
it and get it circulated to both sides.
A. Yes.
Q. Would that be acceptable?
A. Yes, it would.
Q. Thank you.
Yesterday afternoon we were going through some
documents you rely on in your reports with a view to
seeing whether they justified the claims that you made
about them. These are some example documents. I'm
going to do a few more but I'm going to do them as
quickly as I possibly can. First of all can I ask you
to look at paragraph 5.195 of your first report, and for
the transcript it is at {D2/1/107}
A. Yes.
Q. You will see you say there:
"The Post Office cash management proposals contained
in a report dated 4 August 2017 suggests that they were
actively considering ways to improve processes impacting
on many of the issues raised above. It is my opinion
that, whilst the Post Office was looking at ways to
improve cash management, it is also indicative that the
system was generally far from perfect and there existed
a real risk of bugs/errors/defects adversely impacting
on branch accounts despite the processes in place at the
time to prevent this."
A. Yes.
Q. Mr Coyne, if we could go very quickly to that document.
It is at {F/1673/1}. It would take too long for me to
read it out loud. Perhaps I could ask you, Mr Coyne, to
read the first page quickly to yourself.
(Pause)
A. Yes, I have read that.
Q. Then over the page {F/1673/2} we can see "What we
propose to do and why", about a third of the way down
the page:
"We proposed to deliver the following initiatives
through this business case."
First of all there is a reduction of branch cash
holdings by circa £80 million. Perhaps I can ask you to
read that paragraph 1(a). (Pause)
A. Yes.
Q. Then 1(b) is "Improving branch cash declarations" where
they say:
"In conjunction with the above activity, a more
strategic solution will be delivered to reduce surplus
cash in the branch network by £80m (£60m in Sterling and
£20m in foreign currencies) through mandatory and
accurate cash declarations in branch."
A. Yes.
Q. That's talking about trying to get postmasters, when
they make their cash declarations which they have to do
everyday, to make them more accurate, to make sure they
get them right.
A. Yes.
Q. That's explained in the following paragraphs (i), (ii),
"Proactively manage non-conformance" and "Changing time
of cash declaration submission", do you see that?
A. Yes.
Q. Then over the page {F/1673/3}, "Improving operational
design, training and communications to Postmasters to
ensure cash declaration conformance." It is all about
getting the SPMs to do what they already do but to get
them to do it better.
A. Yes.
Q. Then if we go over to page {F/1673/9} of the document
there is what is called a "Benefits Map". It is a table
with a series of solutions on the left-hand side,
a series of impacts and a series of benefits in
different columns along the page.
A. Yes.
Q. Picking it up so we can see the sort of thing it is
dealing with, at page {F/1673/10}, the second box down:
Discrepancy management – at the moment there is a
lack of visibility of any inaccurate cash declaration to
the Postmaster of one of his stock units. If we deliver
a technical change to the cash declaration process this
will send any discrepancy amount to the Local Suspense
account which will give the Postmaster immediate
visibility and will allow faster
corrections/investigations ..."
A. Yes.
Q. What they are suggesting is that the information that
a postmaster gets when doing a cash declaration, some
further information should be added which is immediately
added to his or her suspense account which then impels
him or her to look into the matter more closely, do you
see that?
A. Yes.
Q. That is essentially what I get from this document. It
might be my fault. What I would like to ask you is,
going back to your statement at paragraph 5.195, why is
it you say that this document is indicative that:
"... there existed a real risk of bugs ... adversely
impacting on branch accounts despite the processes in
place at the time to prevent this."
{D2/1/107}
A. Could I have the document back up, please?
Q. Of course. It is {F/1673/10}.
A. Sorry, could we go to the first page {F/1673/1} of that
document. Then go on to the next, please {F/1673/2}.
Onto the next, please {F/1673/3}. And onto the next,
please {F/1673/4}. And onto the next, please
{F/1673/5}. And onto the next, please {F/1673/6}. Next
one, please {F/1673/7}. And the next one, please
{F/1673/8}. Next one, please {F/1673/9} and again,
please {F/1673/10} and the next one, please {F/1673/11}.
And the next one please {F/1673/12}. And the next
one please {F/1673/13}. Sorry next one, please
{F/1673/14}. And again, please {F/1673/15}. Next one,
please {F/163/16} and again, please {F/1673/17} and
again, please {F/1673/18}.
That's the end of that document, is it?
Q. Yes. So can you tell me what it is you saw in this
document which allowed you to express the opinion that
it indicates that there existed a real risk of bugs
adversely impacting on branch accounts?
A. It is incorrect to find that from that document.
Q. Mr Coyne, you have already accepted, and very fairly and
properly accepted, that as an expert it is important
when relying on documents, particularly in
a document-heavy case where many, many documents are
relied on in a report, you have already accepted the
great importance of making sure any summary of the
document, any explanation as to what the document means
or what it indicates, it is very important to get that
right to assist the court.
You do seem to be looking for problems in documents
which don't support the suggestion that those problems
exist. Would you accept that?
A. No, I don't. It might be the case that we have
an incorrect reference, there was an incorrect reference
yesterday, but I don't think so in this case because the
context of the paragraph appears to relate to this
document.
Q. You are simply citing documents that don't support the
claims you make about them, aren't you, in this report?
A. This particular example, there appears to be a mistake
here, yes.
Q. Let's move down the page to paragraph 5.198 where you
say -- this is in your report at {D2/1/107}:
"It is clear that in some instances it is not always
apparent whether recurring discrepancies were as a
result of system bugs or the Subpostmaster's own
actions, or other things beyond the control of the
subpostmaster."
Then you have two footnotes {D2/1/108}. Then:
"However the fact that the SSC support team were
unable to assist or identify the root cause does
undermine the credibility of Horizon itself."
Correct me if I'm wrong, but I think what you are
suggesting there is that the two documents you refer to
in the footnote as examples of it not being apparent
whether recurring discrepancies were a result of bugs or
human error, you are saying those documents itself
support the idea that the support team were unable to
identify root causes and in a way that undermines the
credibility of Horizon itself?
A. There is a number of documents, and I agreed with
Dr Worden that often the bugs, errors or defects would
appear as if they were mistakes made by the
subpostmasters.
Q. You say "often". We need to be careful with "often".
A. There are a number of occurrences.
Q. Let's be clear about scale, shall we? I think you have
agreed with Dr Worden that over the lifetime of Horizon
there were something like 3 million branch accounts
generated, yes?
A. Yes.
Q. And I'm taking a branch account as a monthly branch
account. I'm simplifying because of course between 1999
and 2005 they were weekly accounts, weren't they, but
let's just treat them as monthly accounts. So there
were 3 million branch accounts that were produced during
the course of this period and if an error is made, one
error is made, that means it has a branch account
effect, that means that there is a 1 in 3 million chance
of that error affecting a branch account, yes?
A. It is unlikely that one error within the system would
only affect one single branch account.
Q. We will talk about that. It depends on the nature of
the error.
A. It does indeed.
Q. You can't say that, can you, before you know the nature
of the error?
A. No, you can't say that. That's why you need to be
careful.
Q. So when you say this often happened, it gives
an impression, doesn't it? It gives an impression that
suddenly large numbers -- a significant portion of
branch accounts may be unreliable because of something
happening. But if you are talking about a handful of
cases or if you are talking about 20 cases, you are
still only talking about 20 in 3 million. You are
talking about 2 in 300,000. You are talking about a 1
in 50,000 chance, aren't you?
A. I wasn't talking about branch accounts, I was talking
about bugs, errors and defects. Bugs, errors and
defects often appear as if it was a user error rather
than a defect of Horizon and it was that that Dr Worden
and I agreed on.
Q. What we are talking about is what undermines the
credibility of Horizon itself.
A. Yes.
Q. What I'm suggesting to you is that if there were a dozen
examples of something happening, given the number of
branch accounts that are in existence, and assuming each
of those examples only had one impact, that doesn't
undermine the credibility of Horizon itself, does it?
A. Well, it needs to be considered because it is unlikely
that it would only have an impact on one branch account.
Sorry, let me finish, please. If it is a defect in the
system, the majority of the users, subpostmaster users,
were using that system. So it would be unlikely that it
only impacted one.
Q. I'm very interested in your answer, Mr Coyne, because in
my question I was quite careful to indicate that I was
asking about one error that had one impact, but you
immediately flicked to a situation where you were able
to say, well, there are likely to have been more impacts
in circumstances where I wasn't even specifying what the
error was other than that it didn't have multiple
impacts, and could I suggest to you that you did that
because you have a view, you have a world view, you have
a desire to maximise the impression given of any error
that you identify, do you think that's fair?
A. No, I don't think that's fair. I understood the
question you were putting to me was about this system
rather than a hypothetical scenario where one bug only
impacts one account.
Q. Let's talk about a remote access instance. The SSC on
one occasion does some remote access which affects one
branch. Do you accept that would only have one branch
impact?
A. Yes.
Q. So if you find one example of remote access which has
one branch impact and you don't know which branch is
affected, and you look at the totality of the branches
in the network and the totality of the monthly accounts
that have been generated in the network over 20 years,
you would have -- if you picked a branch account at
random, you would have a 1 in 3 million chance of
finding a branch that was affected by that remote
access?
A. If that remote access was done correctly it would only
impact one branch, yes.
Q. Thank you. Going back to this example, and if I'm wrong
please tell me because it will save some time. There
are two footnotes, do you see, and they are call logs.
Do you see that? And they are footnotes which are given
as instances where it is not always apparent whether
recurring discrepancies were as a result of system bugs
or the SPM's own action, do you see?
A. Mm.
Q. You then go on to say the fact that the SSC support team
were unable to assist or identify the root cause
undermines the credibility of Horizon. Are you
suggesting that if I look at those logs I will see
something to justify the inference that you make here --
that you appear to make here -- that the credibility of
Horizon itself is undermined? {D2/1/108}
A. The way that the reference is introduced here is "or
other things beyond the control of the Subpostmaster".
{D2/1/107}
Q. I'm sorry? I'm not following you and it is my fault,
not yours.
A. Sorry, I have just flicked back to read what was before.
Q. Yes.
A. So these are discrepancies that were:
"... as a result of systems bugs or the
Subpostmaster's own actions, or ... things beyond the
control of the Subpostmaster."
And they should be referenced in these --
Q. Right. So these logs indicate that things are happening
which are either the result of system bugs or a result
of SPM action or are beyond the control of the SPM, yes?
A. Yes.
Q. And do you infer from those examples -- is what you then
say in the last sentence an inference from that? Do you
say that those examples show -- well, those examples
undermine the credibility of Horizon itself? I think
you would say yes?
A. We are in the section of my report here which is
"Opinion Summary", so it is summarising the section
that's come before it.
Q. Yes, but you give these two examples here and I would
have thought you did that for a reason.
A. It is likely that these are two documents that relate to
this section, but if there was a footnote that I have
already referred to in the section I wouldn't reference
it again here.
Q. Yes. So you are suggesting that if we look at the
footnote we will see something that undermines the
credibility of Horizon itself, is that right?
A. Yes.
Q. Let's have a look then. Could we go to {F/333/1}
please. This is a call log. I think it relates to
Mrs Misra's branch and the date is -- it was opened on
23rd February 2006. So far as I can tell, the relevant
passage that you would rely on is at the bottom of the
page where it says:
"OTI close Monday 27 February."
Do you see that?
MR JUSTICE FRASER: I think we are going to need to increase
the size.
MR DE GARR ROBINSON: Yes, it is very small. Could we go to
the bottom and increase the size, please?
MR JUSTICE FRASER: I think for present purposes that's
probably magnified enough at least so I can read it.
MR DE GARR ROBINSON: Let me read it:
"No transaction date and time was provided for this
action using current date and time. Update by Anne
Chambers: Category 94 -- Final -- Advice and guidance
given."
Stopping there. We have seen a lot of
Anne Chambers' work, haven't we?
A. Yes, we have.
Q. My impression is that she is quite a professional
operator. Would that be your impression as well or
would you disagree with that?
A. I don't think I could give a view on that.
Q. Very good.
"I have checked very carefully and can see no
indication that the continuing discrepancies are due to
a system problem. I have not been able to pin down
discrepancies to individual days or stock units because
the branch does not seem to be operating in a
particularly organised manner. In particular I have
noted 1. There are 6 stock units for this 3 counter
branch, which seems a bit excessive. 2. The loss in
euros in TP 9 appears genuine - the declared quantity
was 4000 fewer than the system expected. It is not clear
from the information above whether anyone found out why
this happened (there were several rem outs, and a rem
in, on 23rd Dec - did the pouches contain the declared
number of euros?). 3. Stock is sometimes transferred
out of a stock unit where it is not held. In particular
there were several transfers out of stock unit SMI in TP
10. At the end of the period the stock figures were
corrected back up to zero via Adjust Stock. This gave a
gain of over £2000 in SMI. Equivalent negative stock
adjusts in AA gave a corresponding loss in AA. 4. I am
not confident that the stock declarations are always
correct e.g. at the end of TP 9 there was a declared
holding of 5 £20 PO phonecards in the branch, then a few
days later 20 were transferred from one SU to another.
None were remmed in until a week after that. 5. The
branch had declared 27 £20 Argos vouchers at the end of
TP 9. Branches have now been instructed to rem out this
product; they remmed out 17 and adjusted stock to
account for the remaining 10 (so did they really only
have 17 to start with?). This has correctly caused a
loss of £200 in SU AA. 6. Lottery instants sales are
entered onto the system as a single transaction every 10
days or so. 7. Stock units SMI and AA rolled over with
non-zero cheque holding. This may be to do with how the
discrepancies have been accounted for but I do not
really understand this (the total is greater than the
sum of the branch adjustments for TP 9 and 10). I
recommend that this call is passed back to NBSC tier 2
for further investigation, since there is no evidence
that the discrepancies are being caused by a system
problem. If you want the above information in an email,
let me know."
Now, Mr Coyne, what I would like to suggest to you
is that what that shows is that Anne Chambers did a very
thorough job, went through the figures very carefully,
saw there was a branch that was operating in some sort
of chaos, forms the clear view that there's no system
problem, but says: there are these questions, it should
go back to NBSC to investigate. And I would like to ask
you why you think that that story there, told in that
box, does undermine the credibility of Horizon itself?
A. I think it is that when this call is later advanced, it
is discovered that there was a system problem.
Q. Perhaps you would go to the second page because if
that's the case I have missed it but I'm happy to be
corrected. {F/333/2}. What I get is what's in the
final entry, Mr Coyne:
"Call close by David Dawe: pm was getting
discrepancy's ssc have investigated and adviced that the
NBSC take a 2nd look at this as the office stock units
appear to be in a mess."
But please don't let me stop you reading the whole
thing.
(Pause)
A. But what we do see from that is that Anne Chambers isn't
able to say what has actually happened with the
discrepancy that has been seen. She is unable to
determine whether it is the user that has caused that or
whether there is a potential problem with the system.
Q. So let me get this straight. Let me give you
a hypothetical case. A branch is being run in a mess
and things are being reported that are wrong. So things
are being remmed out from a particular stock unit that
aren't in the stock unit, they are declaring cash that
they don't have, they are declaring they have stock that
no longer exists, there are inconsistent declarations of
stock on different days. It is a mess. Clearly lots of
erroneous figures are being entered into the system.
There is no way that someone in the SSC is going to be
able to correct those errors, only the subpostmaster
will know what the true position is on the ground.
Correct?
A. Yes.
Q. So in that situation, the SSC comes in and looks to see
if there's a system problem and they can't find one.
Now are you saying -- that scenario is inevitable, isn't
it? It doesn't matter how good the system would be; you
could have the computer from the Star Trek Enterprise.
The point is that in that scenario the SSC would not be
able to say that this has happened or that has happened,
because the data they have got is too chaotic, correct?
A. Yes.
Q. So I would like to suggest to you, Mr Coyne, that the
sense one gets from these logs is that's what was
happening with this branch.
A. Yes.
Q. So why do you say that this log undermines the
credibility of Horizon itself?
A. No, I agree that this log in itself doesn't.
Q. I don't want to take any time up, but are you suggesting
that the second log, if I go to the second log, I'm
perfectly happy to do it, would show a different
picture?
A. I would have to check it. I believe it shouldn't but
I'm happy to go to it.
Q. I do not think I have time. Lets move on.
What I would like to do now is to talk about
a document on which you have built one of the major
themes in both your reports, which is the reliability of
Credence, and as we know that is one of the management
information systems used by Post Office. It is the
Post Office system, isn't it? And it uses it for
various purposes, including it is one of the systems it
uses when deciding whether to issue a transaction
correction, yes?
A. Yes.
Q. One of the themes in your reports is that it shouldn't
be used for the purpose of making those decisions, ARQ
data actually should be used, is that right?
A. Yes.
Q. That is your considered view?
A. Yes.
Q. And on that basis you rely on a document which is
called -- which has become called the Helen Rose report,
I'm not sure it is a report, but it is a five-page
document produced by Helen Rose who was a fraud analyst
at the Post Office in June 2013.
Before we go to it, can we just agree the basic
facts. I presume you looked at the report and the
associated facts quite carefully so you are familiar
with the case?
A. Yes.
Q. It related to an incident at the Lepton branch of which
the SPM was a Mr Armstrong, is that right?
A. Mm.
Q. A bill payment transaction had failed at his branch when
the system went down, correct?
A. Yes.
Q. And it was a cancellable transaction, correct?
A. Yes.
Q. So he completed the transaction, he took money from the
customer, and he did that via -- the customer had
actually got cash out from a Lloyds TSB cash withdrawal
but that's by the by because that didn't fail. So he
completed the transaction and he took money from the
customer. Because the system went down he had to log
back in, and when he logged back in the recovery process
automatically reversed the cancellable transaction,
correct?
A. Yes.
Q. And that's how the system should operate with
cancellable transactions, correct?
A. Yes.
Q. And that left him with a surplus in his branch, didn't
it?
A. Likely, yes.
Q. Because he had been given cash by the customer which was
to be used to pay -- I think it was a phonecard or
something like that. It was a BT bill payment, sorry.
But of course because the transaction had failed the BT
bill payment was not made, yes?
A. Well, it depends at what point the counter failed and
that's what the recovery process does, it determines how
far the transaction got.
Q. Yes. When you agreed with me a moment ago that it was
a cancellable transaction, what that means is -- there
are two kinds of transactions, aren't there? There is a
recoverable transaction and the opposite of
a recoverable transaction is a cancellable transaction,
correct?
A. It is often called nonrecoverable.
Q. But the technical name is cancellable?
A. Yes.
Q. Could you explain what the difference is between those
two transactions, why a transaction is cancellable or
recoverable?
A. It depends on whether it requires an interaction with
any of the banking organisations or not. Often with
things like credit cards or debit card transactions
a call will be placed to the bank to check the money and
then if the process continues all the way to the end the
money being requested. If there is a failure in the
counter at some point through that process then Horizon
has got to understand whereabouts it failed and then
effectively unwind that process.
Q. The difference is where a third party system is
involved, isn't it?
A. A third party system, yes.
Q. So where you are doing a transaction at the counter
there are a number of steps you take and if the
transaction involves, I don't know, a payment being made
from a bank, during the course of typing in the
transaction hundreds of messages are passing back and
forth both to the BRDB to record the nature of the
transaction that's being keyed in and also to the
financial institution, and the two institutions marry up
and the financial institution says I recognise you, and
the counter says I want you to make this payment, and
the financial institution says I accept it, and so on.
A. Yes.
Q. Then at the end of that process the postmaster closes
the stack.
A. Yes.
Q. He enters the transaction into the system. I think the
technical term is he commits the basket to the system?
A. Yes.
Q. And that's the moment at which the basket enters his
branch accounts, is that correct?
A. Yes.
Q. Everything I have said so far is correct, is it?
A. It is, yes.
Q. Thank you. The problem is that inevitably the moment at
which the transaction is committed to -- the basket is
committed to the system is different in time from the
moment at which the payment instruction is accepted by
the bank, yes?
A. Yes.
Q. So what happens, in a relatively rare situation you can
have the bank accepting an instruction to make a payment
and making the payment, then the system breaks down, and
then that means that the transaction is not entered into
the branch account?
A. That is correct, yes.
Q. So you have a discrepancy between what has happened in
the real world, which is that a payment has been made by
the bank, yes?
A. Yes.
Q. And you have the fact that that payment is not recorded
in the branch accounts because the system has collapsed
before the basket has been closed -- I should say
committed, yes?
A. Yes.
Q. Do you mean collapsed? You said the system collapsed.
MR DE GARR ROBINSON: It is a very loose form of --
your Lordship understands what I mean.
But the system goes down. It could be a comms
problem, it could be a systems problem, it could be
someone has dug up the phone line outside.
A. A power problem.
Q. It could be a thousand kinds of problem, yes?
A. It could be lots. I'm not sure thousands --
Q. I'm sorry, it is fair that you should make that
clarification. I am not trying to commit you to that
number.
So in that situation any system, let's forget about
Horizon, again we have got a Star Trek brilliant system,
any system is going to have to manage that problem,
isn't it, in some way?
A. Yes.
Q. Because there are always going to be situations where
what's happened in the real world may not actually
accord with what's recorded in the accounts?
A. That is right. Frankly what Horizon does, rather than
make the assumption that the transaction completed
successfully, it effectively re-looks at the elements of
the transaction to see how far it got, to see whether it
should roll back or roll forward.
Q. Yes, because in the course of the transaction being
keyed in, before the basket is committed, all the
elements of the transaction are actually recorded --
let's talk Horizon Online -- they're all recorded in the
BRDB but they are in different tables of the BRDB. So
they are securely kept, held somewhere, for the moment
in time in which the transaction is committed to the
audit store -- I shouldn't say the audit store -- to the
database, so they are held there but they are held in
abeyance. Then when something goes wrong the
transaction isn't committed to the database and the
tables which contain the data relating to the
transaction, and some other tables, they then throw up
a flag saying this is a recoverable transaction. And
what that means is that the transaction appears -- it
has been done in the real world but it hasn't entered
the stacks, it hasn't entered the branch accounts, so it
has to be looked at to see what needs to be done, is
that correct?
A. Yes.
Q. And that's how the Horizon system was designed to work,
correct?
A. Yes. Just in pure technical terms, the raising of the
flag, once the transaction is started that's recoverable
a flag or a stake is put in the database to say we are
starting a recoverable transaction. Then at the end of
it, once it is committed, the flag is taken down.
Q. Exactly.
A. So when the counter restarts it has a look to see
whether there is any recoverable transaction flags
there. If there are, it has to deal with that before it
boots up.
Q. Exactly. And this isn't strictly relevant to Helen Rose
but just to be clear, in that scenario, given the way
the system is designed, indeed given the way any system
would have to be designed, there would then have to be
an enquiry as to what happened on the ground, wouldn't
there?
A. By the humans interacting?
Q. Yes. In other words, let's take this example, the
Post Office would have to find out from the postmaster
whether he accepted the £76, wouldn't he? They would
need to know whether the money was accepted or whether
it wasn't, and only then would they know what they
should do in relation to this transaction?
A. Typically a counter would know whether the transaction
or whether the monies have been handed over because one
of the last things that you would do at the end of the
transaction would be -- it is called firing, you would
fire the cash drawer and the cash drawer would come
open.
Q. You are not suggesting it wouldn't have to be checked.
You wouldn't assume that the money had passed hands, you
would need to know whether it had. You would need to
ask the postmaster, wouldn't you, in order to work out
what, if anything, needed to be done to restore the
branch to balance?
A. But it is a worthwhile check to do, to find out whether
cash has been handed over or not.
Q. Yes, because the system on its own doesn't know whether
cash has passed hands, does it? The system doesn't tell
you. It doesn't photograph the passing of cash from one
to the other, there is no way in which the system would
ever know that?
A. No. It would know whether it has displayed a message on
screen to say pay X amount and it would know whether the
cash drawer has been opened or not, but it wouldn't know
if physically that instruction had been followed, yes.
Q. So it might be, for example, the message is flashed up
on the screen and then the system crashes, and if you
were at the Post Office or the SSC you would not be able
to tell, looking at the data you have, what had happened
and you would have to make an enquiry. And it would be
a good practice, generally speaking, to make that
inquiry before deciding whether any correction needs to
be made or not, yes?
A. Yes.
Q. Thank you. So let's go back to Lepton. This was
a cancellable transaction because there hadn't been
an immediate instruction for a payment to be made by
a financial institution. I think you will accept with
me that when that happens it is not in the recoverable
category, it is in the cancellable category, yes?
A. I would have to check that by looking at the report.
I can't recall precisely what the --
Q. Okay. You agreed with me earlier that it was
a cancellable transaction?
A. I believe so, yes.
Q. Which means that the standard process with -- in fact
the universal process with cancellable transactions is
that the transaction is then removed from the system.
The assumption is made that the transaction should not
be done. Then if there is any problem that can be
handled by manual processes. Again you can ask the
branch whether in actual fact, although we have
cancelled the transaction, have you actually received
some money? That's how the system works, correct?
A. Mm.
Q. And that is how the system worked in this case, didn't
it?
A. In this case there was a dispute between whether the
system itself said there was the reversal or whether the
human, the subpostmaster, chose to do the reversal or
not. And the indicator within Horizon was that it was
the subpostmaster that did the reversal but it was found
that that was incorrect and it was actually Horizon.
Q. So you are saying Credence said it was the postmaster
that did it but in actual fact it was the system that
did it. And that's your considered view?
A. I believe that's what the document reflects, yes.
Q. Let's pick this up in your second report -- one other
thing I should mention, actually, is that in this
process, the way the system is supposed to operate, when
there is a cancellable transaction like that, or indeed
even a recoverable transaction, receipts should be
printed by the system to allow the postmaster to know
what's happened and what he or she should be doing, yes?
A. Yes. The process should be that receipts are printed.
There are other reports elsewhere that suggest that that
is not always the case, but that is certainly what the
process should be.
Q. Let's look. Can we go to page 117 of your second report
which is {D2/4.1/1}. This is paragraph 4.78. It is all
under the heading "Failed Reversals" {D2/4.1/117}.
You say at 4.78:
"As dealt with above at paragraph 4.62, the excerpt
from Gareth Jenkins within the Helen Rose report
indicates that there was no evidence of the creation of
a disconnected session receipt, unless further diagnosis
(which I do not believe has been disclosed to me) has
since been conducted and reviewed by Angela Van Den
Bogerd. I have reported on what was diagnosed
contemporaneously by Mr Jenkins, particularly ..."
Then you quote a piece of text that I won't read but
I invite you to read.
(Pause)
A. Yes.
Q. So what you are suggesting there is that the Helen Rose
report indicates that Horizon didn't produce a
disconnected session receipt in branch, yes?
A. Yes.
Q. If we go back to page 113, {D2/4.1/113} and look at
paragraph 4.63, you are talking about Credence now, you
are talking about the Helen Rose report. You say:
"Therefore, the contemporaneous evidence is
consistent with the determination that Horizon initiated
the reversal, NOT the Subpostmaster."
A. Yes.
Q. "In my first report I had explained (at paragraph 4.61)
that the Subpostmaster had not reversed the transaction,
this had been a reversal generated by the system as part
of recovery."
A. Yes.
Q. "Credence data appeared to show (or was interpreted as)
being a reversal initiated by the Subpostmaster. This
difference of position arose from Post Office looking at
Credence data and Gareth Jenkins of Fujitsu looking at
audit data and system logs."
A. Yes.
Q. "This demonstrates two positions", you say:
"(a) Credence data, most commonly used by Post
Office for their investigations, is either wrong or does
not provide sufficient information to complete the full
picture; and
"(b) It was only after the Subpostmaster involved an
external forensic accountant that the Audit data was
requested."
The external forensic accountant, are you aware of
this, what that's a reference to, Second Sight?
A. In the documents that I have seen, the call logs,
I think the subpostmaster says "I have got a forensic
accountant involved", I do not think he mentions --
Q. You are not aware it was Mr Warmington from
Second Sight?
A. I wasn't aware.
Q. Fine, I will not ask you any more about that.
Then if we go back to what you said about this in
your first report. Can we go to {D2/1/67} please. Are
you there? Paragraphs 5.49 to 5.50:
"The document ('Helen Rose report') refers to an
incident where a Transaction Correction was issued which
the Subpostmaster duly settled financially despite the
Subpostmaster denying conducting the reversal."
5.50:
"The report appears to show that the material that
Post Office initially reviewed did not identify that it
was the system that initiated the reversal rather than
the Subpostmaster and therefore the Transaction
Correction making the Subpostmaster liable was issued in
error. Since this is effectively a failure to
appropriately reduce the risk of error this is also
dealt with further ..."
So here you are saying -- well, let's move on
actually to page {D2/1/101}. You have some more points
to make about Credence at page 101. Picking it up at
paragraph 5.175 --
A. Sorry, are we in the second report now?
Q. The first report {D2/1/101}. Picking it up at 5.175,
you say:
"The report regarding the reversal dispute conducted
by Helen Rose states:
"On looking at the Credence data, it clearly
indicates that the reversal was completed by ...
(Subpostmaster) at 10:37 ... and was reversal indicator
1 (existing reversal) and settled to cash."
{D2/1/102}
"5.176:
"It is therefore relevant to question why Post
Office were using Credence data to initially investigate
disputed transactions."
Stopping there. Your contention is that they should
not use Credence to initially investigate, is that
right?
A. It would seem that you can use Credence to conduct
a cursory investigation but you have to go back to the
full logs to get the full picture. Because if there's
a different picture being given by Credence to that of
the logs, then ultimately both can't be correct.
Q. It is just your use of the word "initially". Is there
any significance attached to that? That's not what you
should look at even first, you should look at something
else first, should you?
A. No, I mean, it depends what depth of investigation you
are going to look. If it is just a cursory
investigation then Credence might be okay for that.
Q. I see, thank you.
5.176:
"Whilst it is evident that it was understood by Post
Office in this instance to request assistance from
Fujitsu for further material to investigate this dispute
there appears to be further issues with the data
provided by Fujitsu."
5.177:
"Observations of the disclosures illustrates that
the initial report ..."
That is the Helen Rose report, right?
A. Mm.
Q. " ... states 'a transaction at 10.42', whereas the
Credence data file shows 10.32 with the reversal at
10.37."
Stopping there. You are giving another example of
Credence giving wrong data, yes?
A. There appears to be a difference between the times that
are recorded, yes.
Q. "Fujitsu's data states the transactions are at 9.32 and
9.33 and reversal timestamp is 9.37."
You are suggesting that is a further problem with
Credence, that it is actually an hour out as compared
with audit data, yes?
A. I actually say that in the next paragraph, yes.
Q. Then you say:
"5.178:
"Whilst this hour difference between the data sets
might be easily traceable for Fujitsu, it is not clear
how easily it would have been to investigate issues
where the Subpostmaster was not sure of what time things
went on erroneously in the system ..."
A. Yes.
Q. So what you are doing here, Mr Coyne, is that you are
making the following claims: first of all,
a disconnected session receipt wasn't printed when it
should have been, correct?
A. That is what the report says, yes.
Q. Secondly, that Credence data initially relied on by
Post Office was misleading, misleading as to who
reversed and misleading as to time, yes?
A. Yes.
Q. And, thirdly, the problems with Credence led to
an erroneous transaction correction, inflicting a false
loss on the subpostmaster, correct?
A. Whether there was an erroneous transaction correction or
not is not clear, it depends what decision was taken
based on the evidence, based on either the Credence or
the ARQ log.
Q. We can go back to your first report, paragraph 5.50, but
my understanding of what you said there was the
Post Office wasn't liable and it was a false transaction
correction. So that is your view, isn't it, that you
formed on the basis of reviewing the Helen Rose report
and other documents?
A. If Post Office had have continued to use the Credence
data, then the transaction correction would have been
issued in error.
Q. You actually say, reading again from paragraph 5.50:
"... and therefore the transaction correction making
the Subpostmaster liable was issued in error." {D2/1/67}
A. Yes.
Q. You are making a claim as to what happened on the basis
of the documents you have seen?
A. Yes.
Q. And is that your view?
A. Yes.
Q. Thank you. Let's now go to Ms Rose's report. It is at
{F/1082/2}, pick it up at page 2. There's the
"Executive Summary" and the first paragraph has the time
10.42 that you referred to. You see that?
A. Yes.
Q. The report says:
"The branch was issued with a Transaction Correction
for £76.09, which they duly settled; however the
postmaster denial reversing this transaction ..."
Under "Reviewing the Data", let's read that:
"On looking at the Credence data, it clearly
indicates that the reversal was completed by JAR001
(postmaster) at 10:37 04/10/2012 and was reversal
indicator 1 (existing reversal) and settled to cash. An
existing reversal is where the session number/Automated
Payment number has to be entered to reverse the item.
"The Fujitsu logs were requested for this branch,
but whilst waiting for these to arrive communications
took place with Gareth Jenkins at Fujitsu for more
details to gain an understanding what had occurred at
this branch."
A. Yes.
Q. Now, she says the Credence data clearly indicates that
the reversal was completed by the subpostmaster. But it
is fair to say, isn't it, that the Credence data did not
actually say that the subpostmaster had initiated the
reversal, correct?
A. Well, certainly whoever constructed this report said it
clearly indicates that the reversal was completed by the
user.
Q. She's inferring from the facts that she sets out there
that the reversal itself must have been initiated by the
subpostmaster, isn't she?
A. That's what she is saying. She's saying "it clearly
indicates".
Q. It is an interpretation of the data she has got. There
isn't a box in Credence -- she's not saying there is
a box in Credence saying this was initiated by the
subpostmaster, it is that the reversal has a postmaster
reference attached to it and a reversal indicator 1, and
she infers from that, she construes that, she interprets
that as indicating that the reversal was specifically
undertaken by the subpostmaster. Would you accept that
what we are talking about here is a mistake in
interpretation?
A. There's nothing here to suggest there is a mistake in
interpretation to me. The words on the page say "it
clearly indicates that the reversal was completed" by
the subpostmaster.
Q. I would like to suggest to you, Mr Coyne, that what this
suggests is she looked at the three points of
information and she inferred from those three points of
information that the reversal was undertaken by the
postmaster, but the Credence system doesn't specifically
say that. She has made a mistake because she has put
two and two together and made four, in fact five?
A. I think that really is a matter for Helen Rose.
Q. Would you accept it is possible?
A. It is possible that she was mistaken, are you asking,
sorry?
Q. If we go over --
A. Sorry, I might have given the wrong answer. Are you
asking me is it possible --
Q. Are you suggesting that Credence did specifically state
that the reversal was undertaken by the postmaster
himself, rather than a reversal happened when the
postmaster was logged on. In fact it was the postmaster
logging on that caused the reversal to happen?
A. I haven't looked at Credence myself in order to validate
what the author of this report saw. I have gone off
what this paragraph says, that Credence clearly
indicated that a reversal took place by the user.
That's what I have based my evidence on.
Q. I understand, but I suggest to you that what you have
read here is consistent with the view that what happened
is Ms Rose misunderstood the significance of the items
of information that were on Credence and formed the a
mistaken conclusion?
A. I agree that that is possible, yes.
Q. Thank you. Then if we go over to page 3 of the report
{F/1082/3}. For completeness I should say that on
page 1 you will see that there are two -- this report,
it is not really a report. It is curious that it has
some questions and then some answers that are provided
by Mr Jenkins by e-mail and those answers are there in
blue.
MR JUSTICE FRASER: I think you mean page 2. We have gone
to page 1 which is literally just the facing page.
MR DE GARR ROBINSON: I'm so sorry, I meant page {F/1082/2}.
I'm sorry.
So there are passages in blue which are quotations
from emails she has received. The first email is on the
first page. And the middle paragraph, just to be clear,
this is the paragraph you relied on. About halfway down
it says:
"The fact that there is no indication of such a
receipt in the events table suggests the counter may
have been rebooted and so perhaps may have crashed in
which case the clerk may not have been told exactly what
to do."
I presume that was the basis upon which you said
there were no receipts printed for this transaction,
correct?
A. I think there is a more definitive statement than that
later on in this document. This is Gareth Jenkins
suggesting that there wasn't a receipt.
MR JUSTICE FRASER: Is the blue Mr Jenkins?
A. Yes, I believe so, my Lord.
Yes, it is the paragraph below where it says:
"The reversal was due to recovery [and] was not
an explicit reversal [made] by the clerk".
Q. What you are saying is this affirmatively states that no
receipt was printed for the postmaster to tell him what
to do. That's what I'm asking you about, remember.
A. Well Mr Jenkins here, who has investigated it, has said
from the logs that there wasn't a disconnected session
receipt.
Q. And it was on the basis of that text, you said that in
your report?
A. Yes.
Q. You remember, one of the claims you made in your report
is that there was no session receipt printed?
A. Yes.
Q. If we go over the page, please, there was a second email
that comes a couple of weeks later, at the top of the
page {F/1082/3}. It is the paragraph beginning:
"The files 4 to 25th October ..."
Do you see that?
A. Yes.
Q. If we can miss out the sentence that talks about those
files. The next sentence says:
"Also row 70 of events 4 to 25 Oct ... shows that
session 537803 ... has been recovered and this event has
the same timestamp as the Reversal Session. Also row 71
of Events 4 to 25 Oct ... shows that a receipt was
generated from the session 537805 (not explicitly, but
it was the only session at that time)."
So you will see that on the very next page,
Mr Jenkins is saying actually the receipt was printed
after all?
A. No, I think that's talking about a receipt for something
else. It is not a disconnected session receipt, I do
not think.
Q. Are you suggesting that -- so he is talking about
a completely different -- why would he be talking about
a completely different session in this -- or rather why
would she, Ms Rose, be quoting in this email
a discussion about a completely different session?
A. They are actually talking about two sessions here.
There is the session ending in 803 and the session
ending in 805.
Q. Yes. Perhaps I could read the next sentence.
A. Yes.
Q. "This receipt would have told the user that a Rollback
had taken place (but the logs don't make that
explicit)."
Is that clear enough for you, Mr Coyne? What
Mr Jenkins is saying here is that a receipt was printed
showing that the transaction had been rolled back,
correct?
A. Right, so what Mr Jenkins is saying here is that the
logs were missing the record that the receipt was
printed but he believes the receipt was printed.
Q. Yes. So your claim in your report that the report shows
that the receipt was not printed, that claim is wrong,
isn't it? You hadn't read this document properly, had
you?
A. Well, the situation here is that we have got to -- in
order for this scenario that you are putting to me to be
correct, we have got to assume that firstly the initial
investigation showing that it was a user that issued the
reversal was wrong, and then we have also got to assume
a receipt was printed although it is not within the
logs.
Q. Mr Coyne, in your report you specifically say, and
I think you confirmed to me that it is your opinion,
that the report -- this report shows that a receipt
wasn't printed for the disconnected and reverse session,
yes?
A. Mm.
Q. What I'm suggesting to you is that this report, if you
can call it that, says nothing of the sort and that you
haven't read it carefully enough, is that right or is
that wrong?
A. Well, if Gareth Jenkins is correct then a receipt would
have been printed.
Q. So would it be fair to say that in your anxiety to write
a bad thing, to be able to write down a bad thing in
your report about Horizon, you recorded what was said on
the first page of the report, but you didn't look at the
second page of the report which would have shown that
that bad thing wasn't in fact correct?
A. No, but my point was about this report is to show that
there is a difference between the view that you get of
the data from viewing the Credence data from the ARQ
data, and that's correct.
Q. Mr Coyne, if you just made that claim we would have been
in and out of this issue within about five minutes. The
reason why we have spent about 20 minutes so far is
because you made several claims, and I set them out
orally and you agreed that you were making each of those
claims on the basis of this Helen Rose report. And what
I'm suggesting to you is that the claim that we are now
talking about is a claim that was wrong and that you
should have known it was wrong if you had read the
report properly?
A. I do agree that the report suggests that the receipt was
printed.
Q. Isn't this another example of you taking a document that
on a superficial reading could be said to say something
critical about Horizon, and immediately writing that
critical thing down without analysing the document
properly to see what it actually said?
A. No. This document does illustrate the point that I was
making about the difference between Credence and ARQ
data.
Q. And do you accept that a receipt -- are you suggesting
the receipt was not printed -- are you giving up on your
suggestion that a receipt was not printed?
A. The only evidence that we have here is that
Gareth Jenkins is saying that the receipt was printed.
Q. So you are disclaiming --
A. No, no, I can accept that position.
Q. Very good. For your Lordship's note, if one goes to
{F/1095.1/1} there is an email between Mr Armstrong and
Mr Warmington of Second Sight in which Mr Armstrong
confirms that he did receive three receipts in relation
to this reversed transaction at the time. It is at page
{F/1095.1/4} of that document. I see it is up on the
screen so let's have a quick look.
To be fair to you, Mr Coyne, you wouldn't have seen
this at the time you wrote your reports, I do not think.
MR JUSTICE FRASER: When was it disclosed?
MR GREEN: 7 March, my Lord.
MR JUSTICE FRASER: 2019? Okay.
MR DE GARR ROBINSON: You will see that on 25th June
Mr Armstrong writes an email to Mr Warmington of
Second Sight and he says:
"Having read your report I searched through the
weekly records for the 4th October 2012 and found THREE
disconnected session receipts all with the same session
ID ..."
If we go to the bottom of the page:
"The time shown on these slips is 10.36 yet I had
had the foresight to enter the time of 10.32 am on the
customers bill alongside the amount paid of £76.09.
This means that the customer had already left the office
by the time these receipts were printed out by the
system."
So he had manually written the time of the
transaction on the customer's bill, and one infers --
would it be right to infer from that, Mr Coyne, that he
hadn't actually got a receipt, he hadn't closed the
basket and a receipt had been printed, so he realised
something had gone wrong and he manually wrote the time
of the transaction down on the bill he received from the
customer, is that a fair inference?
A. Yes.
Q. So he knew something was wrong but he accepted the money
from the customer and he allowed the customer to leave
the premises?
A. Yes.
MR JUSTICE FRASER: I do not want to start a hare running,
but just for my purposes that session ID of 537803 --
this isn't a question for you, Mr Coyne, it is for
counsel. Can we just go back to the Gareth Jenkins blue
extract because he mentions two sessions, 537803 and
537805. So are they different receipts from the 537805
receipt that he is talking about? It might be it
doesn't matter.
MR DE GARR ROBINSON: I would strongly suggest, my Lord, it
doesn't.
MR JUSTICE FRASER: But is your take on it that they are
different receipts or is he talking about the same
receipt?
MR DE GARR ROBINSON: My take on it, my Lord, is that one
transaction was cancelled, it was this transaction, and
the appropriate receipts were printed for it.
MR JUSTICE FRASER: Was that session 805 or 803?
MR DE GARR ROBINSON: My Lord, I'm afraid I haven't
considered these documents sufficiently to answer that
question.
MR JUSTICE FRASER: I don't want to start an unnecessary
hare running.
Right back to you, Mr de Garr Robinson. {F/1082/3}
MR DE GARR ROBINSON: Coming to the next point, timings
being wrong. If we go back to 5.177 of your first
report, that is {D2/1/102}. So we have dealt with the
question whether Credence affirmatively stated that the
reversal was by the postmaster or by the system, and we
dealt with the question whether a session receipt --
session receipts, I should say, were printed or not.
We now come to this further criticism which is that:
"Observations of the disclosure illustrates that the
initial report states 'a transaction at 10.42', whereas
the credence data file shows 10.32 with the reversal at
10.37."
I would like to suggest to you, Mr Coyne, and we
might be able to save some time, that the transaction
was clearly at 10.37, indeed we have Mr Armstrong
himself saying so in the email we have just read.
A. Yes.
Q. Clearly what happened is there is a typo in Ms Rose's
report. If we go to {F/1082/2}, please, at page 2.
At the top of the page she says:
"A transaction took place at Lepton ... on the
04/10/2012 at 10.42 for a British Telecom bill payment
..."
Then she then says in the next sentence:
"At 10.37 on the same day the British Telecom bill
payment was reversed out to cash settlement."
Now, I would just like to give you an opportunity to
correct what you are saying in 5.177. Isn't it fairly
clear that the reference to 10.42 here was her error,
because you can't have a transaction that's reversed
five minutes before the transaction is done. In fact
she should have written 10.32, yes?
A. Well, either she has got it wrong or the system has
recorded it wrongly, I don't know which.
Q. Are you really seriously suggesting that Credence was
indicating that the transaction was done at 10.42 and
that that's a reason for suggesting, for thinking, that
Credence is unreliable? Is that really your contention?
A. Times on computers can be out. They do drift. It is
possible that it's got the time wrong. I agree with
your position that it could well be a mis-key on behalf
of Helen Rose.
Q. It wouldn't be a sound basis for suggesting that
Credence wrongly records the time done of transactions,
would it? This wouldn't be a sound basis for making
that claim about Credence? What it is a sound basis for
saying is that when people write documents sometimes
they press the wrong keys, would you agree?
A. Yes. It is one of those two scenarios, yes.
Q. As for the second point made at 5.177, that the ARQ data
always works in accordance with Greenwich Mean Time,
whereas everybody else at the time was working on
British Summer Time, that's not a serious problem, is
it? It's not something that is going to cause great
difficulties to anybody, is it?
A. As soon as you know that you are an hour adrift then it
becomes very easy to deal with, but if you don't know
that it is problematic.
Q. So are you imagining a world in which Mr Armstrong is
provided with ARQ data but nobody tells him that ARQ
data is based upon Greenwich Mean Time, is that your
assumption? And that's a problem, because nobody tells
him that ARQ data is based on Greenwich Mean Time?
A. No, my answer is if you are told then it becomes very
clear very quickly, but if you are not told it is
confusing.
Q. But in 5.178, Mr Coyne, you seem to be assuming
{D2/1/102}, remarkably, that no one would have told him.
You say:
"... it is not clear how easily it would have been
to investigate issues where the Subpostmaster was not
sure of what time things went on erroneously in the
system ..."
Why are you assuming that, having reached a point
where the subpostmaster actually has the ARQ data, no
one is going to help him understand that there is
an hour discrepancy between the ARQ data and British
Summer Time?
A. The point that I'm making is that unless somebody tells
him it wouldn't be clear. I do not think a user would
typically know that the computer would be an hour out.
I think the assumption would be that if it is an audit
system of some description, that the clock difference
would actually be dealt with correctly.
Q. What I would like to suggest to you, Mr Coyne, is that
in this section what you are doing is you are trying to
squeeze as much criticism as you can out of the
Helen Rose report that you can level at Post Office.
This isn't a fair-minded explanation of what happened,
it is an exercise in trying to extract bad points as and
where you can find them. What would your response be to
that?
A. That's not true. And with regard to the time, when
I point out that the time was wrong, the next paragraph
explains how it is likely that it was wrong.
Q. You say "it is not clear how easy it would have been to
investigate", that's a suggestion that in fact the
subpostmaster would ...
I'll read the whole of it:
"... it is not clear how easy it would have been to
investigate issues where the Subpostmaster was not sure
of what time things went on erroneously ..."
What are you saying that is a suggestion of?
A. Well, the subpostmaster might not necessarily know what
the actual time was that the error took place. So if
they have got to then work out what time it actually
took place precisely, and then look at two different
times because the clock might be right on the audit log
or it might be an hour forward or an hour backward on
the audit log it just makes the process more difficult.
But I do accept that if somebody explains to the
reviewer that it is an hour behind, then that makes the
process easier.
MR DE GARR ROBINSON: My Lord, I wonder whether this is
a convenient moment.
MR JUSTICE FRASER: By all means. We will have a 10-minute
break.
MR DE GARR ROBINSON: Could we make it five minutes,
my Lord?
MR JUSTICE FRASER: One of the transcribers has a back issue
and that's why we are having 10 minutes.
MR DE GARR ROBINSON: Very good.
MR JUSTICE FRASER: But we can go on a little bit past 4.30
if you are worried about losing time. The trouble with
five minutes is it is not really sufficient for current
purposes. So a 10-minute break and come back in at
11.55 am.
(11.45 am)
(A short break)
(11.55 am)
MR DE GARR ROBINSON: My Lord. Mr Coyne, we were talking
about your criticisms of the use of Credence. This
isn't -- the discussion we have just had, the points we
have just been discussing -- actually before finishing
on this system, would you accept that what happened in
the Lepton case was a customer gave cash for a BT bill
payment to be made, in fact the BT bill payment was not
made but the branch accepted cash for that payment, it
therefore had a surplus of cash and so a TC had to be
issued to correct for that surplus. Do you accept that
that's what happened?
A. Yes, I believe that that's what happened.
Q. So do you accept that the TC was not erroneously issued,
in fact it was correctly issued?
A. Yes.
Q. Thank you. Then let's move on to another criticism you
have of Credence at {D2/1/101}. This is your first
point about Credence. It is paragraph 5.174. You say:
"The End to End Reconciliation Reporting document
from 27 February 2012 states:
"There is no formal reconciliation produced between
the POLSAP System and the Credence transaction stream.
The Credence stream should therefore not be used to
verify financial integrity and Post Office should ensure
the POLSAP System Transaction information is used for
this purpose."
A. Yes.
Q. That's one of the bases upon which you suggest that
Credence shouldn't be used in order to make decisions on
transaction corrections, right?
A. Yes.
Q. Okay. Let's look at the document itself. It is at
{F/896/1}.
I'm afraid I can't see the date on the version on
the screen.
A. 27 February 2012.
Q. Thank you very much. It is called "End to End
Reconciliation Reporting", so it is a document about the
reconciliation process that we discussed yesterday.
A. Yes.
Q. Which is the process by which data goes into POLSAP and
the data in POLSAP is then compared with client data,
data from banks other institutions and that sort?
A. Yes.
Q. Then exceptions are identified and looked into?
A. Yes.
Q. Right. If we could go forward to page {F/896/65}.
Section 5 at the top of the page says "TPS
Reconciliation Reports Specified".
It starts by saying:
"The Transaction Processing System (TPS) Report Set
has been designed to enable reconciliation of the
transactions carried out in Post Office branches using
the Electronic Point of Sale Service (EPOSS) which are
sent to POLSAP and POLMIS."
A. Yes.
Q. Just to be clear, the TPS system is the system which
takes -- it is almost the highway which takes data from
the Horizon branch database and transfers it into
Post Office's own systems?
A. Mm.
Q. They are generally referred to as back office systems?
A. Yes.
Q. They are actually separate systems that belong to
Post Office, yes?
A. Yes.
Q. In the course of that process there are -- that's when
the reconciliation --
A. Yes.
Q. Once they arrive at POLSAP the reconciliation process is
undertaken, yes?
A. Yes. I mean reconciliation, this is talking about end
to end reconciliation, so it is all the way through the
whole -- the entirety of the systems.
Q. But when the comparison occurs -- the figures hit POLSAP
and then the comparison with client data occurs, does
it?
A. Yes.
Q. I see. So:
"The ... (TPS) Report Set has been designed to
enable reconciliation of the --"
Sorry, I have just read that sentence. Let's move
on:
"The TPS exceptions report set identified herewith
reports errors that have occurred within counter
transactions or during the harvesting process.
"NB: for the avoidance of doubt, there is no formal
reconciliation produced between the POLSAP and POLMIS
transaction stream. The POLMIS stream should therefore
not be used to verify financial integrity and Post
Office Ltd should ensure the TPS Report Set and POLSAP
transaction stream are used for this purpose."
This is the document you referred to and it refers
to POLMIS here. Actually there is a later version of
this document that refers to Credence.
A. Yes.
Q. It may be that the document reference you have given is
erroneous?
A. I think that that's right. It must be a later version
of the same document.
Q. I presume you didn't check all the document references,
it would have been very difficult for you to do that.
A. I have put what's called a MD5 reference at the bottom
of there, so I'm not sure. I don't think there's any
easy way of checking that.
Q. I have found a later version of the document that does
refer to Credence so I'm not going to challenge you on
that, Mr Coyne.
MR JUSTICE FRASER: Would you give me, for my note, that
reference at some point. You don't have to do it now.
MR DE GARR ROBINSON: Yes, my Lord. It is {F/1686/1}.
MR JUSTICE FRASER: Thank you very much.
A. Sorry, my footnote does say 27 February and the date at
the bottom of this one is 22 June.
MR JUSTICE FRASER: No, this is 27 February but I think
an earlier version was 22 June of 2011.
A. Forgive me, my Lord, I'm just looking at the bottom of
what's on the screen at the moment, towards the bottom
right.
MR JUSTICE FRASER: Yes, that's because you can't see the
way the colours have been struck through.
That is right, isn't it, Mr de Garr Robinson?
MR DE GARR ROBINSON: My Lord, I believe so.
MR JUSTICE FRASER: For some reason I have got in my
{F/896/1} on my trial bundle, I have got a coloured
track change version of the same document which does
show 22 June crossed out.
MR DE GARR ROBINSON: Mine does --
MR JUSTICE FRASER: Yours does as well?
MR DE GARR ROBINSON: I have a hard copy and mine does,
which I printed off the trial bundles, my Lord.
Should I say "from" the trial bundles? I never
know.
MR JUSTICE FRASER: That's fine.
MR DE GARR ROBINSON: If we go back to page {F/896/8} of
this document, I hope it is of this document and not the
1696 version.
It explains, if we look at section 2, "Scope":
"This document defines the format and content of all
reconciliation reports for HNG-X ..."
That is Horizon Online?
A. Mm.
Q. "... which satisfies the DRS, APS and TPS reconciliation
requirement."
These are all different forms of reconciliation.
Can you take us through them. What's DRS?
A. It is something reconciliation service but I can't think
what.
Q. APS?
A. Automated payment system.
Q. Then we have TPS.
A. Transaction --
Q. These are all separate systems beyond, as it were, the
branch data?
A. Yes.
Q. It is beyond branch accounts. This is information taken
from the BRDB and pushed through those streams to allow
different forms of reconciliation to be undertaken?
A. Yes.
Q. It does not attempt to define within the operating
systems how the transactions are processed.
"This document does not attempt to define the
business processes undertaken within Fujitsu Services
and Post Office Ltd with respect to the resolution of
any exceptions which may arise, nor does it scope the
requirement for any systems that may be required to
assist in this process. This information can be found
in the associated documents."
So it is just talking about the format and content
of all reconciliation reports and it doesn't talk about
the business processes undertaken with respect to the
resolution of any exceptions.
Now, if we go back to -- so just to be clear, it has
nothing to do with the Post Office business processes
leading to decisions on transaction corrections, does
it?
A. It does -- well, the decision to make a transaction
correction is a comparison between, in rudimentary
terms, front end and back end systems. Because what is
going on here through transaction processing has
a potential to change transactions in the back end.
Q. Mr Coyne, I'm getting slightly concerned about time.
I asked quite a simple question which was this
document -- paragraph 2, section 2 that we have just
read, makes it clear it is not about the business
processes which lead to the decisions made to issue
transaction corrections. That is a yes or no answer, if
I may suggest. Could you give me one?
A. Yes, this document does not go to --
Q. Thank you. It is not what this document is concerned
with at all, is it? It is concerned with the
reconciliation process. And that process may end up
leading to investigations that result in decisions being
made but it is not about that side of the divide at all,
is it?
A. No, that is right.
Q. Thank you.
A. I have the DRS, it is data reconciliation service.
Q. Thank you.
Then if we go back to page 65 {F/896/65}, this is
going back to section 5. This is describing the process
by which exceptions are identified, yes?
A. Yes.
Q. Then the various reports that are produced are then
discussed. So at 5.1 there is the TPSC250 report, "Host
Detected Transaction Control Errors":
"This report is produced daily and shows detail for
any Post Office branch where the control totals for the
transactions output by the Host to POLFS and POLMIS do
not match the daily transaction totals calculated by the
counters."
So that is quite a good check. It shows if there is
a discrepancy between what the counters have done and
the information going into Post Office's systems.
That's quite a useful check, isn't it?
A. Yes, it is a report that's available to the Post Office.
It isn't given to the branch I don't believe.
Q. No, it's not. I think actually it is given in the first
instance to Fujitsu. It is only given to Post Office if
Post Office request it, that is right, isn't it?
Because Post Office isn't involved in this, it is
a Fujitsu process, correct?
A. There is a suite of reports that is handed over between
Fujitsu and Post Office automatically each morning. I'm
not sure whether this is one of the reports that's sent
to them.
Q. If one goes over the page, 5.2, TPSC254. This is
another form of report that's generated each day, yes?
{F/896/66}
A. Yes.
Q. This is called "Harvester Exceptions":
"This report is produced daily and shows a list of
exceptions detected by the BRDB copy process when
failing to process one or more messages."
These are all countermeasures, aren't they? They
are the sort of countermeasures Dr Worden is talking
about, spotting discrepancies between data that ought to
be the same. It is a good example of redundant data
storage and MID and all those other acronyms that
Dr Worden uses, correct?
A. These are reports that are available so as long as
somebody looks at the reports they should be able to
pick it up.
Q. Mr Coyne, you are not suggesting that people don't look
at -- people look at these reports every day, don't
they? These are the reports that produce all those
exceptions about which you make so much hay in your
report?
A. They certainly should do, yes.
Q. Are you suggesting -- let me get -- are you suggesting
that people don't look at these reports? Have you seen
evidence to suggest that people don't look at these
reports?
A. No, what I'm saying is somebody needs to read the
reports.
Q. Very good. Then if one goes over the page to 5.3
{F/896/67}, TPSC257, that's "POLFS Incomplete Summaries
Report". That's another daily report, isn't it?
A. Yes.
Q. "This report identifies all Post Office branches on a
daily basis in which the net total of transactions
(debits/credits) does NOT net to a value of zero."
So this, for example, picks up receipts and payments
mismatches, doesn't it?
A. Yes.
Q. So if there is a receipts and payments mismatch at any
branch on any day of the week it will be automatically
reported to Fujitsu who will be aware of it and can
investigate, isn't that right?
A. Yes, I believe that this is the report that's printed to
indicate that, yes.
Q. And would I be right in thinking that you have seen
hundreds of PEAKs which show that Fujitsu do absolutely
investigate these exceptions when they arise?
A. There are certainly PEAKs that talk about the
investigation from these incomplete summary reports,
yes.
Q. I'm interested, would you accept that there are lots of
PEAKs that do that?
A. I don't know exactly what the number would be but there
are a number, yes. There are many.
Q. Here's what interests me about that answer, Mr Coyne.
You are perfectly happy when you see an example of
a handful of things happening to say things often happen
when they favour a case -- that they help build a case
that Horizon is bad. But when I ask you a simple
question, "You have seen lots of PEAKs in which these
exceptions are investigated?" you are unwilling even to
concede that it happens a lot of times. I'm quite
interested in why you should have a different attitude
depending on whether or not something is a criticism of
Horizon or in praise of Horizon?
A. I'm attempting to be as precise as possible with my
answers to you.
Q. When it comes to saying something positive about Horizon
you are very precise indeed. Can I suggest to you, Mr
Coyne, that you are rather less precise when it comes to
criticising it.
A. That's certainly not my intention.
Q. Let's go back to page {F/896/65}. This is the third
paragraph under section 5:
"NB: For the avoidance of doubt there is no formal
reconciliation produced between the POLSAP and POLMIS
transaction stream."
We can call that Credence.
"The POLMIS stream should therefore not be used to
verify financial integrity and Post Office Ltd should
ensure the TPS Report Set and POLSAP transaction stream
are used for this purpose."
You appear to suggest in the paragraph of your
report that we have just read, paragraph 5.174, that
this is an indication that Post Office should not be
using Credence for the purposes of making decisions
about transaction corrections. That is your claim,
isn't it?
A. Yes.
Q. Could I just suggest to you, Mr Coyne, that when this
report is talking about financial integrity that's
a reference to the integrity of the financial data, it
is a reference to ensuring that the data for the given
day is complete so that it can be used for
reconciliation. It is not a statement about what should
be done when making decisions on transaction
corrections?
A. But some of the information that is reported here and
finds its way back into POLSAP will be required in order
to make a decision on whether to issue a transaction
correction or not. And if they are not reconciled
together, you could have the scenario where Credence
data differs from POLSAP data.
Q. So as I understand it, you are using this as part of
an argument -- and it becomes a theme of your second
report -- that Credence data shouldn't be used for the
purposes of deciding on TCs, actually it should be ARQ
data?
A. My point is that Credence data alone shouldn't be used.
The ARQ data will give the full picture of what went on
at the counter.
Q. If in this report they are talking about that process,
and I have already suggested to you, Mr Coyne, that that
question, the data that is used for the purposes of
transaction correction decisions, has got nothing to do
with this report. The writer isn't concerned with that.
I have already suggested that to you and I think you
have accepted it. But are you suggesting that the
writer has decided to say something that's outside the
scope of this report because he is concerned that
inappropriate data is being used for the purposes of
making transaction correction decisions? Is that how
you construe this paragraph?
A. Well, I mean I don't exactly know what was in the mind
of the author when they put this together, but they saw
fit to put a specific note to say that there was a doubt
over what should and shouldn't be used to verify
financial integrity, and what should be used to verify
financial integrity is the TPS reports in POLSAP.
Q. Mr Coyne, from the get-go Post Office has used its
management information systems in order to decide on
whether or not to issue transaction corrections, is that
right?
A. Yes, I would think so.
Q. And it has used Credence and any predecessor -- I'm
presuming here that POLMIS might be a predecessor of
Credence -- would that be right?
A. It is Post Office Management Information System.
Whether that later became Credence or not, I would have
to check.
Q. I'm afraid I don't know. That was a genuine question.
So we have a business, the Post Office, which has
had a practice since the beginning of making decisions
in relation to transaction corrections based upon its
management information systems?
A. Its range of management information systems.
Q. And you are suggesting, are you, here in this paragraph,
that the writer of this report in 2012, February 2012
and thereafter, is suggesting that what Post Office has
been doing for the previous 12 or 13 years is completely
wrong? Do you honestly think that that's what the
writer of this sentence was intending to convey?
A. No, I don't think they are saying that what you have
been doing for the last 12 years is completely wrong.
They are providing a warning that you should use one set
of systems rather than another set of systems because
the two do not reconcile.
Q. And what I would like to suggest to you, Mr Coyne, is
that when this report talks about financial integrity,
it is talking about the integrity of the data that's
compared as between the client and Post Office. It is
not talking about the process of making decisions about
transaction corrections. Do you not accept that?
A. But the integrity of the data between the Post Office
and its clients could well have an impact on branch
accounts, because if there's an issue between
Post Office and its clients, the client will report
a different view of the transaction.
Q. Let me move on. Let's move on to the conclusion that
you then draw from the passages that we have seen, the
Helen Rose report, and the end to end reconciliation
reporting.
The conclusion you draw is that when faced with
a problem, an apparent discrepancy, an apparent
exception in accounting figures, when therefore called
upon to make a decision about whether to decide on
a transaction correction or not, Fujitsu and Post Office
should always use the raw ARQ data that's held in the
audit store, that is your claim, isn't it?
A. In order to get the definitive position on it they
should, yes, because that is a record of what actually
happened.
Q. So let's take this in stages. It is a good thing for
a complex system like Horizon to have a secure place to
store a copy of all the transaction data that comes in
from branches, isn't it?
A. Yes.
Q. Because one can then go back to look at that pristine
copy months or years later if there is a concern about
the accuracy of the data in the management systems,
correct?
A. Yes.
Q. And the whole point of an audit store is that the data
in it is effectively locked away in a secure place and
only extracted when it is necessary for checking against
the other sources, correct?
A. Yes.
Q. Now, were you in court when Mr Dunks gave evidence about
the process of obtaining data from the audit store, do
you remember? Were you here when he gave that evidence?
A. I'm not sure that I was.
Q. You will recall his witness statement where he describes
it, yes?
A. Yes.
Q. It is a slow and careful process, isn't it, extracting
the data in a reliable way?
A. I don't know if "careful" is the right word but it
certainly would be slow, I can imagine.
Q. And it is done from a very small number of very
carefully managed secure sites, correct?
A. Likely, yes.
Q. And it is labour intensive and quite expensive, correct?
A. I can't imagine why it would be labour intensive.
I imagine you'd put a search into the computer system
and press go, I would imagine, and it would --
Q. Mr Dunks' witness statement describes the care with
which these processes are undertaken, the care with
which access to the relevant systems is carefully
controlled.
A. Yes.
Q. It is only particular people that are allowed to do that
particular job --
A. Indeed.
Q. -- and they have to have particular authorisation and
particular qualifications?
A. Yes.
Q. And I think you have already accepted it can be a slow
process?
A. Yes.
Q. Particularly if a large amount of data is being
extracted you would accept, would you, that it could
take weeks and weeks for really huge quantities of data
to be extracted?
A. I would be surprised if that was the case. But I mean
typically you would be extracting a day's worth of
transactions, perhaps even less than that, to understand
what went on around the particular hour or --
Q. And it is quite an expensive process, isn't it?
A. I believe that there are -- there is a certain number of
requests that can be made within Fujitsu's service level
agreement and then after that there is a charge that's
made, yes.
Q. And the charge that's made over the allowance of 720
a year, it is over £200, are you aware of that?
A. I think I did see that figure, yes.
Q. Right. And what you get when the data is extracted is
not data organised into the form of elaborate reports,
it is raw data which actually needs packaging even to
put it in a spreadsheet. It is very difficult to manage
this kind of data, isn't it?
A. I believe the process is that there is a raw version but
there is also a version that is packaged so it can be
read in Excel.
Q. You mean in a spreadsheet?
A. In a spreadsheet.
Q. Do you mean the spreadsheets that the witnesses -- the
claimant witnesses were taken to during the course of
their evidence at the beginning of the trial? Because
my experience of those spreadsheets is that they are
very difficult to manage your way through, but would you
suggest not?
A. Absolutely. You would have to be reasonably experienced
in interpreting the data that's given to you, it would
be quite a complex spreadsheet. But it can be opened up
in a conventional spreadsheet.
Q. The controls and checks described by Mr Dunks are what
you would expect if the idea is to have a gold standard
store of data that cannot be altered or corrupted or
lost in the meantime, yes?
A. Yes.
Q. Perhaps I could go to your second report now at
{D2/4.1/7}. This is your executive summary of your
second report.
A. Yes.
Q. In paragraph 1.2 you say:
"I consider that Horizon is less robust than as
originally expressed in my first report. My primary
reasons for this are as follows ..."
A. Mm.
Q. And you talk about remote access.
If you go down to paragraph (c).
A. Yes.
Q. "Post Office do not consult the full audit data before
ruling on a discrepancy, instead using third party
client reconciliation data or subsections of the audit
data from within Credence or HORice."
A. Mm.
Q. So this is something -- your discovery that this was
happening is something that caused you to have a change
of heart on robustness, is that right?
A. Yes. It was my original belief that the audit data was
consulted.
Q. So when you drafted your first report you thought that
every time Post Office was faced with some kind of
discrepancy that might lead to a TC, you thought in
every case regard was had to the full audit data that
was held in the audit store, did you?
A. Well, certainly that was my original opinion, yes.
I thought that was the purpose of the audit store, to
actually go back and see what happened at branches.
Q. But you knew, Mr Coyne, that the audit store was copied
from the BRDB and sealed and maintained for seven years,
didn't you?
A. But it only needs to be sealed from a write perspective.
You can seal something and still have read access to it.
There is generally no problem with that. That doesn't
tamper with any seals --
Q. Didn't you know, in fact wasn't it obvious, bearing in
mind all the controls that we just discussed with
Mr Dunk's report, witness statement and so on, that
Post Office would generally rely on its own management
information systems when making decisions on transaction
corrections? Wasn't that obvious to you?
A. No, it wasn't obvious to me. I perceived that the
management information systems would be part of it, but
that to get the true picture of what had happened at the
branch the audit data would be consulted.
Q. Well, if we could go back to your first report, it is
{D2/1/119}.
MR GREEN: My Lord, in fairness to the witness, it does
pre-date the witness statement being referred to. The
witness statement is November.
MR DE GARR ROBINSON: I'm grateful to my learned friend.
Thank you.
If we look at paragraph 6.46, you will see it is
under the heading "Reconciliation Summary". This is
your first report, yes?
A. Mm.
Q. You say:
"In consideration that Branch account positions were
interpreted and reviewed from data flows through to Post
Office back end systems (which would determine whether
Transaction Corrections were to be applied), the
following is considered relevant."
{D2/1/120}
Over the page you say:
"POLSAP – Following investigation by Fujitsu, Logica
and Ingenico, the root cause of a long outstanding
problem with missing data within POLSAP was identified
as out of range dates which failed the Credence
validation (in excess of 90 days). Ingenico has
corrected the data and P&BA has advised that the
mismatches have been cleared ..."
Here you appear to be saying, indeed you appear to
be raising it as a criticism of Post Office, that when
making management -- decisions on transaction
corrections, Post Office were using management data that
could be wrong.
Now I would like you, if you would, to explain why
having made that criticism there you claimed just three
and a half months later in your next report that in fact
you made the opposite assumption, namely, that
Post Office always looked at all the core audit data?
A. Sorry, I don't understand the question.
Q. This is your first report, paragraph 6.46 is your first
report.
A. Yes.
Q. And we just read your second report where you said: when
I produced my first report I believed that when
decisions were made about transaction corrections the
full ARQ data was used. Correct?
A. Yes.
Q. Now we go to 6.46 and here you are saying that
management information systems, the back end systems,
were used to determine whether transaction corrections
were to be applied, and you give as an example, over the
page, POLSAP?
A. Yes.
Q. Now, ARQ data, the core audit store, that isn't back
end, is it? That's not held by Post Office and used by
Post Office for its systems, it is an entirely separate
process that's maintained by Fujitsu, isn't it?
A. Yes.
Q. So here in your first report you appear to be saying
that there is a problem with the process by which
Post Office decides transaction corrections because they
are using Post Office management systems that might be
unreliable?
A. Yes.
Q. But if you believed that when Post Office made those
decisions actually they used the full ARQ audit data,
that criticism would be utterly misconceived, wouldn't
it? So either you were telling the truth -- or either
you believed when you did your first report that
management systems, not ARQ data, was used, or it is the
position that you were making a criticism of the use of
management systems even though you believed that the
full audit data was actually used, but it can't be both.
A. I think it can be both. In my first report it was my
perception that the range of management information
systems and the ARQ data should be used, and in my
second report -- well, before my second report
I discovered that the ARQ data was not used.
Q. I see. So let's look at paragraph 6.46 again. In that
paragraph, forgive me, but it appears to be yet another
criticism of the method by which Post Office conducts
its business and the criticism appears to be that
Post Office is using a form of information which is
unreliable {D2/1/119}.
If you had wanted to be balanced in your approach to
that criticism, would it not have been appropriate for
you to say: but I do of course recognise that this is
only one subset of the information that Post Office used
and I do understand Post Office actually used the full
audit data as well? Would a need for balance not have
required you just to make that point clear?
A. Certainly if I had included that it may have helped the
reader, yes.
Q. If we could now move back to your second report, it is
{D2/4.1/228}. Actually I'm so sorry, I have taken you
to the wrong page. Could we go to 114 rather than 128
{D2/4.1/114}.
You say in paragraph 4.67 under the heading "ARQ
Requests":
"In her statement Ms Mather references the number of
ARQ requests per year. If it is correct that the
contractual limit of 720 per year has never been
exceeded except for this litigation, then in my view
Post Office is not utilising the audit data sufficiently
and certainly is not checking the audit data prior to
issuing transaction corrections."
A. Mm.
Q. Then at 4.68:
"in 2011/2012 using the figure that Dr Worden
produces at his Table 9.3 (section 9.6, page 208) there
were 107,583584 Transaction Corrections but only a
fraction 213 of these were validated by the audit data."
A. Mm.
Q. So you are suggesting, are you, that full audit data
should have been extracted from the database in at least
107,584 occasions during that year?
A. Yes. I believe that the audit data should be consulted
every time there is a potential dispute and need to
issue a transaction correction. In light of now
understanding the process of getting at the audit data
and getting it extracted, I see that it wouldn't be
possible to do that.
Q. It would also cost something like -- well, because of
course you wouldn't only look at ARQ data when actually
issuing a transaction correction. Would I be right in
thinking that your view would be that every time there
is an exception, a discrepancy, a full audit data ought
to be looked at as well?
A. Certainly a section of the audit data, yes. You don't
have to look at the full audit data. On a lot of
systems if you believe something happened between
10 o'clock and 11 o'clock, you can go to a screen, put
10/11 o'clock on a certain date, press go, and it will
give you a list of all the actions that happened on that
day.
Q. I don't believe the audit still works like that. Is
that something you are aware of?
A. No, I now understand the audit data doesn't operate like
that and I now understand there are costs associated
with it, but I don't believe that was understood --
Q. So let's say there are 107,000 TC decisions made a year.
The number of decisions that don't result in TCs, let's
pluck a figure out of the air, I have no idea, it could
be an equivalent number, it could be much more actually.
Let's say 250,000 decisions a year. If each of those
audit requests cost £200, we are looking at £50 million
a year, aren't we?
A. Yes.
Q. Another point that interests me is: is it really the
case that you are assuming that although the audit data
was kept separate, it was nonetheless available in some
kind of information stream in a similar way to POLSAP
and to Credence? Is that how you thought it worked?
Because it bears no relation to how the audit store was
actually operated and maintained.
A. I have got experience of working or designing audit
stores for a number of different systems and they don't
have to work in the way that they have been defined
here. Audit systems are often very easily accessible to
be able to be read by certain users. There's nothing
inherently difficult about that. I accept that the
write aspect of it, you know, you wouldn't want people
writing to an audit database. But having the ability to
read to it is something that's quite simple -- read from
it is quite simple.
Q. And would you accept that the closer you get to raw
data, the more you need specialist knowledge and skills
to interpret that raw data?
A. You do, but the extraction or the report that's run from
the audit data would typically handle the presentation
aspect of it. There might be lots of 0s and 1s at the
back, but the report generator can often put it together
in quite a usable form --
Q. So are you suggesting that when you were giving your
first report, your first opinion, you believed that
there was a process by which the core audit store that
was kept separately by Fujitsu, and there are references
in your report explaining how separately they were kept,
that actually there was a system that extracted data
from that audit store on a regular basis, perhaps on
a continual basis, and packaged that information into
easy to use reports that gave you all sorts of
information that you would need in order to make
transaction correction decisions, is that what you
believed was happening?
A. I would not characterise it in the way you have done
there, but my perception is if Post Office needed to
hone in on a particular area, whether it be an hour or
a day of what happened at a branch, that they would have
a way of viewing that audit data for that period on
a screen or by pulling a report.
Q. What I would like to suggest to you, Mr Coyne, is that
if that had been your apprehension, if that had been
your belief, you would have -- these would have required
their own quite sophisticated systems and you would have
been aware of those systems. You have a vast amount of
technical documents explaining all the different systems
in operation and how they fitted together, including
documents relating to the audit store, you would have
seen that there was a system of that sort. Indeed
I rather imagine that Post Office would have been quite
happy to come forward to explain how that process
happened. But instead, you are saying that you assumed
that all this happened even though you had seen no
documentation to support such a belief at all, and I'm
asking you, Mr Coyne, can that really be right?
A. Well, the purpose of having an audit of what happens at
branch counters is so that if there is a dispute over
what has happened that somebody, presumably this will be
Post Office, can have a very quick look at what happened
and find out the truth. That's the purpose of having
an audit store. There is no other reason for it other
than looking back at what actually happened. It is my
perception that that look back was available to people
at the Post Office.
Q. Could I suggest to you, Mr Coyne, that you knew very
well that the system that Post Office used for the
purposes of having what you describe as a quick look
were its management information systems. The hint is in
the name, MIS, management information systems. And you
would expect, in the absence of being told to the
contrary, that a business such as Post Office would use
its management information systems for making business
decisions of that sort?
A. And the audit database would be part of that management
information system.
Q. Mr Coyne, if that were true you would certainly have
seen documents explaining that amongst the management
information systems of Post Office was an audit store
that was maintained in an entirely separate facility
that was owned by an entirely separate company and was
maintained separately and had no connection with the
outside world, would you not?
A. No, I don't believe that that was the case. If you are
making decisions based purely on a cut-down version of
the data in a management information system you have to
decide what data is going to be cut out of that. So if
everything is in the audit store and just a portion of
that data is in your management information systems,
then you are going to necessarily make a decision based
on a subset of the data and not the whole of the data.
Q. I understand the logic of your position, Mr Coyne. What
I'm seeking to explore with you is whether it bears any
relation to reality.
Data comes out from the BRDB in streams. It comes
out -- copies of data come from the BRDB and go into
Credence. Copies of data come out from BRDB and go into
POLSAP. They go into other management information
systems maintained by Post Office. Entirely separately,
and the word "separate" is in your first report,
information goes out to a sealed audit store, the word
"sealed" is in your report, where it is kept for seven
years.
A. Yes.
Q. And what I'm suggesting to you is that there is no basis
upon which you could ever have thought that the
information in that audit store could be regarded as
a Post Office management information system?
A. I believed that it was a system that Post Office would
look at whenever there was a dispute about what happened
at a branch counter. I believed that they would have
access to that.
Q. Did you see any technical documents indicating a route
by which information from the sealed audit store was
made available on a read only basis to Post Office?
A. No.
Q. Did you see any PEAK or any other document, any -- well,
OCPs, it is too early for that. But did you see any
documents of any sort indicating or referring to the
stream of data flowing on a continual basis out of the
audit store into Post Office's management systems?
A. No, but that's not how things would work. If
Post Office wanted to get access to the data in the
audit store they would go to a screen or go to
an application on their computer and they would run the
request for that data.
Q. Mr Coyne, I would like to suggest to you that it is
completely unrealistic to think that a separate sealed
core audit store of the sort we're talking about should
be cracked open hundreds of times a day in preference to
using management information systems which are designed
for that precise purpose?
A. I think the word "sealed" is misleading and the concept
of cracking something open to get access to it I think
is misleading as well.
Things in an audit store are only -- can be written
to and only written to once, and the term that's often
used is write once read many, WORM. So the process is
written to once, but people can read from that store on
many occasions.
Q. But just to be absolutely clear, you had not and indeed
you have not seen any documents suggesting that
Post Office had the ability to gain access to the audit
store on its own systems, had you? There was no design
facility, there was no -- there were no lines of
communication between the audit store and Post Office in
any document you had ever seen, correct?
A. No, it looks as if the majority of the references to
audit database access was from Fujitsu personnel.
Q. And one final thing. Would I be right in thinking that
now that you understand how the audit store actually
works and the costs and delays associated with
extracting data on a large basis from the audit store,
would you accept that it would be disproportionate to be
using the audit store as a basis for making decisions on
transaction corrections in every single case?
A. Yes, it would seem that it would be very expensive and
very slow to access the audit store, and effectively for
the number of transaction corrections you couldn't do
that, and therefore you accept that you make decisions
on the management information systems rather than the
audit store.
Q. In your evidence yesterday we discussed your approach,
remember, to whether and to what extent Post Office and
Fujitsu did things on a cost benefit basis?
A. Yes.
Q. In the course of that evidence I recall you indicating
that you regarded it as important to ascertain whether
the possibility of error was reduced as far as possible.
Do you remember that exchange that we had?
A. Yes.
Q. Was it your objective in your reports to address that
question?
A. Was it my objective at the outset to address that
question?
Q. To consider not whether the risk was reduced as far as
reasonable or to consider whether the risk was reduced
as far as practicable, but to consider whether the risk
was reduced as far as possible, which is a much more
exacting standard?
A. I believe that was the word that was used in the Horizon
Issues.
Q. So would the answer to my question be yes, that when you
produced both your reports you did so with the objective
of applying that test when determining whether something
constituted a problem in the system or not, whether it
satisfied the test of reducing a risk as far as
possible?
A. Yes.
Q. And not just with -- and did that inform -- does that
inform actually the approach, the criticisms you make of
the use or non-use of ARQ data in your second report?
A. Yes.
Q. But if you take a step back and consider questions such
as proportionality and reasonableness, would you take
a different view on that question and perhaps some other
questions too?
A. As I understand it, the question was reduce as far as
possible.
Q. Yes.
A. So that is the way I answered that question.
Q. Could we go to {C1/1/1}, please. This is the Horizon
Issues. I don't want to take more time than is
necessary, but I would like to give you an opportunity
to tell me which of these Horizon Issues raises that
question as a test.
(Pause)
MR JUSTICE FRASER: Are you looking for it in your report?
A. I am, sir.
MR JUSTICE FRASER: The list of issues is at page 3,
I think, of your first --
A. Thank you.
MR JUSTICE FRASER: You can only see one page at a time on
the screen.
MR DE GARR ROBINSON: Absolutely, my Lord.
A. That's okay.
(Pause)
The reference at Issue 6 at 116 is reduced to
an extremely low level, the risk.
Q. Yes. So it is a factual question as to how low level
the risk was. It is not a question whether Post Office
had reduced the risk to the lowest possible level, is
it? I'm just wondering, Mr Coyne, whether you may have
applied in your entire approach to your reports the
wrong test for the purposes of these proceedings. Do
you think that's possible?
A. No, I don't believe so. I mean, it is not defined what
an extremely low level is.
Q. But you do accept that as low as possible, that was the
test that you used when approaching both your reports.
I think you have already accepted that?
A. Yes.
Q. Thank you. Let's move on to a different subject.
Perhaps I can deal with this quickly. I would like to
talk about PEAKs and KELs.
From what you said yesterday about your change of
mind on robustness between the first joint statement and
your first report, I imagine you would agree that the
system of KELs and PEAKs that Fujitsu developed was
quite a thorough system?
A. Yes.
Q. And that you formed the view that members of the SSC
were very familiar with the Horizon system?
A. Yes.
Q. And they were very familiar with the PEAK and KEL
system?
A. Yes.
Q. And with their training and experience and with using
search facilities they were able to navigate that system
quite well?
A. Yes.
Q. Notwithstanding the limitations that you have fairly
identified. And that using search facilities they were
often able to find PEAKs or KELs addressing similar
problems to the ones that they were facing?
A. Yes.
Q. And would you agree that the PEAKs show, generally show,
the thoroughness with which they generally worked?
A. Yes.
Q. And they tended to keep a written record of what they
did step by step in PEAKs, didn't they?
A. Yes.
Q. It wasn't comprehensive, no one is suggesting it is
comprehensive, but it's quite a process-driven process,
one doesn't often see something significant happening
that isn't somewhere recorded or alluded to in the PEAK
during the different processing steps that are described
as you go down the PEAK from the top.
A. Yes.
Q. So in the scheme of things, compared with other systems
with which you are familiar, you would accept, wouldn't
you, that this is actually quite a well organised, well
run system?
A. Certainly the way of recording the information in the
PEAKs and KELs is a reasonably good system, yes.
Q. Thank you. Now, I would like to ask you about something
you say in your second report which is at {D2/4.1/176}.
It is 5.186, Mr Coyne.
A. 5 point what, sorry?
Q. 5.186 at page 176 of the trial bundle.
A. Yes.
Q. You say:
"At Dr Worden's paragraph 488 he suggests that
serious bugs are rare in the KEL and PEAK records. I
agree, they are rare in the KEL records because the
purpose of KELs are to inform support personnel how to
deal with historic problems, the PEAK's however do show
many serious bugs as I have set out in Section 3 above."
I would like to ask you what you mean by "the
purpose of KELs are to inform support personnel how to
deal with historic problems". Could you explain
precisely what you mean by that?
A. Yes. So the purpose of a KEL is that it is to provide
knowledge for people who -- for SSC support people who
might be searching for things. So if a problem arises
they would search the KELs and either they will find
a KEL that appears to be appropriate, and it shows that
what has happened before has happened again and there
might be instructions on how to deal with it.
Alternatively if they don't find a KEL, they go through
the process of creating a new one.
Q. One possible implication that might be drawn from
paragraph 5.186 is that if there is a bug which has
an effect on branch accounts you will often not find
a KEL that addresses it. But I would like to give you
an opportunity to clarify whether that is what you are
trying to imply or not. I may be reading too much into
it.
A. Because a KEL is a single source of a record of a bug,
error or defect, what you will find is if the fault has
occurred again they will refer back to the KEL and they
will see that that fits their scenario. They often will
not put the details of this particular scenario, this
particular bug, error and defect, back in the KEL. The
KEL is just the single source of knowledge for them to
say, ah, it is that problem.
Q. I see. So what you are saying is that if you get a bug,
you generally speaking -- and of course there are
always -- I'm not suggesting to you that anything is
comprehensive -- but you are saying that generally
speaking if you get a bug of that sort there will be --
once it is detected, there will be a KEL which addresses
it, yes?
A. Yes.
Q. But that KEL will generally address the first instance
in which it arose?
A. Yes.
Q. And when there are other instances in which it arose the
KEL won't necessarily address those?
A. Won't necessarily. Sometimes you see it updated if they
have got a slightly new manifestation of it, or there is
some additional knowledge they have gained and they will
add it to the KEL so that the next time it arises it
might be helpful to the person, but there will only be
one KEL.
Q. I understand.
A. There might be ten instances of that triggering and they
will be in the PEAKs.
Q. That's very helpful. So is this right, if there is
a bug of that sort that's detected you are likely --
there's likely to be a KEL which deals with it?
A. Yes.
Q. Which describes it, put it that way?
A. Mm.
Q. And if there are other manifestations of that bug that
occur in a similar way, the KEL may well not refer to
them?
A. Yes.
Q. But if the bug manifests itself in a slightly different
way, in an odd way, then the KEL will be generally
speaking -- there are always exceptions I am sure, it is
a human system, but generally speaking there will be
an amendment to the KEL to explain the new variance, to
explain the new phenomenon, to enable the users to have
a proper understanding of what they need to look for?
A. That is right. Someone within SSC will decide whether
to add to the KEL that's already there, or that it is
significantly different so they will create a new KEL
for it.
Q. I think we can agree that in some cases KELs give quite
a lot of information and can be very useful?
A. Yes.
Q. In other cases one needs to look at PEAKs to have
a proper understanding of some details that may be
relevant to the inquiry that we are undertaking now?
A. Yes.
Q. So it depends?
A. It does depend. Sometimes a KEL will say: please record
every occurrence of this that you see in this KEL, other
ones you don't have that information.
Q. That's very kind, Mr Coyne.
My Lord, I wonder -- this is a convenient moment,
I wonder whether we can break now and perhaps sit at
1.50 pm. Would that be acceptable to your Lordship?
MR JUSTICE FRASER: Yes. Do I detect an undercurrent of
concern about time on your part?
MR DE GARR ROBINSON: I always have an undercurrent,
my Lord.
MR JUSTICE FRASER: We will come back at 1.50 pm. Usually
it will be a minimum for an hour. It is not for me, it
is not for you, it is for the witness. But today,
because it is the first time it has arisen and you asked
so politely, we will come back at 1.50 pm.
MR DE GARR ROBINSON: I'm grateful, my Lord.
MR JUSTICE FRASER: Mr Coyne, usual arrangements.
A. Yes, my Lord.
MR JUSTICE FRASER: If you could come back for 1.50 pm
I would be very grateful.
Just one housekeeping point. My file of PEAKs and
KELs that were being referred to, obviously we can start
a new one now for the experts, but I just wouldn't like
that to be forgotten about.
So 1.50 pm.
(12.55 pm)
(The short adjournment)
(1.50 pm)
MR DE GARR ROBINSON: My Lord, good afternoon.
Good afternoon, Mr Coyne.
A. Afternoon.
Q. Let's see if we can agree some things. First of all,
can we agree that the parties aren't here spending all
this time and money just to find out if Horizon could
have been improved, yes?
A. Yes.
Q. That might be important to understanding the background
to a particular claim by a particular claimant, but if
no bugs in Horizon caused any non-transient losses to
any claimants, we might as well go home, yes?
A. Yes.
Q. In those circumstances, would you agree with me that it
is useful to know, in fact it is necessary to know, in
this trial, about the likely impact of bugs that have
occurred in Horizon and whether that impact is likely to
have been transient or lasting?
A. Yes.
Q. That's what the Horizon Issues we discussed yesterday
are all about, isn't it? The extent to which it is
likely or unlikely for bugs to cause shortfalls for
which subpostmasters have been held liable?
A. Yes, I think the term is the extent to which it is
possible or likely, yes.
Q. And for that issue to be meaningful don't we have to
settle upon some metric for the likelihood of a bug
causing a lasting shortfall of that sort?
A. The metric I have adopted is to find whether there was
an actual bug, error or defect and see whether it had
an impact. I don't believe there is any other metric.
Q. Don't you need a yardstick to have a proper measure of
extent? For example, the likely impact of bugs in
Horizon across all Post Office branches, the likely
impact in a single branch in a single month, the
likelihood impact across all claimant branches while
they held those branches? Wouldn't those be useful
yardsticks for the purposes of deciding extent?
MR GREEN: My Lord, I'm hesitant to rise, but we
specifically asked whether they were going to try to get
the third report in by the back door.
MR DE GARR ROBINSON: I have no intention of asking any
questions about that.
MR GREEN: That's one of the three questions that has just
been asked.
MR JUSTICE FRASER: Mr de Garr Robinson, your last question
is really a question for me, isn't it?
MR DE GARR ROBINSON: My Lord, it is a question about what
this expert witness has done in approaching the --
MR JUSTICE FRASER: If you do it by reference to his witness
evidence rather than by reference to submissions that
really amount to arguing the case in front of me, that
would probably be more useful.
MR DE GARR ROBINSON: My Lord, if I may, I would like to
follow my own course with my cross-examination of this
witness.
MR JUSTICE FRASER: You can, but your last question to that
witness is an issue for me.
MR DE GARR ROBINSON: Now, Mr Coyne, can we also agree that
there is no realistic prospect of you or anyone else
examining, still less assimilating, every document
that's been disclosed in this case in relation to
Horizon and its operation over the last 20 years?
A. Yes.
Q. That left you and it left Dr Worden with a choice,
didn't it? You can make observations on the documents
you found which may not advance matters very far: here
are some bugs which caused shortfalls in some branch
accounts, so it follows that it is not just possible
that a bug has caused loss, it is a certainty. That
answers the question: is it possible or likely the bugs
have a potential to cause shortfalls, but it is not
an answer to the complete question, is it, because as we
have seen the Horizon Issues include questions of
extent?
A. Yes.
Q. To what extent is this likely or unlikely to happen in
branch accounts in Horizon? To what extent was the risk
faced by a user in Horizon high or low? Do you accept
that those are the sort of issues that are raised in
this trial?
A. Yes.
Q. And to address extent, you can look at a limited portion
of the evidence that you can sensibly review. You can
assess its nature and scale and on the basis of those
assessments you can arrive at overall conclusions that
are generally useful, can't you?
A. Yes.
Q. An analogy with which we are familiar is an exit poll
that is taken on the day of an election. Only a very
small number of people are actually asked how they
voted, but based on that sample useful estimates can be
made about how all the voters voted, do you agree?
A. Yes.
Q. So you can move by a process of sampling from a position
of relatively uninformative certainty, you know, knowing
with certainty how 5% of people have voted, to
a position of much greater certainty or much greater
interest, namely what the actual outcome of the election
is going to be, yes?
A. I believe it would be an indicator, yes. Yes.
Q. In order to be useful, do you agree that the sample you
must choose needs to be an unbiased sample?
A. Yes, in that scenario it would need to be an unbiased
sample, yes.
Q. So if you are trying to work out, for example, how
voters have voted in an election it is no use just
asking people coming out of voting booths wearing blue
rosettes, is it?
A. No, that is true. If you are going down the route of
using sampling then you would have to make sure that
that sample is unbiased.
Q. Once you have an unbiased sample it then becomes
possible, doesn't it, to scale up. So you can scale up
the results that you have got from your unbiased sample
and invite people, invite the court, to make judgments
about what the overall likelihood of something happening
or not happening is, do you agree?
A. Certainly in your election scenario that would scale up
with a reasonable tolerance, yes.
Q. And that's what Dr Worden has done in his first report,
isn't it?
A. Yes.
Q. And it is the sort of question that arises in a case of
this sort where there are so many thousands of KELs and
over 200,000 PEAKs and tens of thousands of OCPs, OCRs
and MSCs, yes?
A. Yes, there is an inherent danger with that in that with
such a large sample size, and in the likelihood that it
is a small fraction of the entirety of the transactions
or branches that have suffered failure, that you might
sample and not find any.
Q. Yes, and there are well known statistical techniques for
dealing with that problem, aren't there? So if you
take -- how is it -- ten samples. The number of the
samples you take will then determine how representative
the results are that you are likely to get from
attempting to scale up. Are you aware of how this
works?
A. Not really with what you have put to me there. Would
you explain that a little bit further?
Q. Let me see if I can put -- you will have to give me
a moment, I'm afraid. Would you give me one moment?
A. Certainly.
MR GREEN: My Lord, I know my learned friend is worried
about time. Mr Coyne has disavowed statistical
expertise in his report.
MR JUSTICE FRASER: If Mr de Garr Robinson wants to use his
time exploring basic elements of statistical analysis
I'm not going to stop him.
MR DE GARR ROBINSON: My learned friend actually is quite
right. Mr Coyne has disclaimed any ability or expertise
in this, so let me move on.
A. Certainly I have very little expertise. I have a broad
ability to understand the concept.
Q. So you have no expertise in what to do with samples and
how to assess whether the sample can be
effectively scaled up or not, is that right?
A. Yes, I can see how that could be effective in certain
scenarios, but I don't believe the scenario that the
application here will work.
Q. Well, isn't it actually what you are trying to do in
your evidence as well, Mr Coyne? Aren't you saying:
I found a number of bugs, and aren't you suggesting that
an inference should be drawn that there could be a great
number of other bugs that you haven't found yet?
A. Yes, but it is from the basis of actually finding bugs
and trying to identify how many branches may be impacted
by those bugs, errors and defects.
Q. What I'm suggesting to you is that when you find certain
hits in your sample, because any sample is necessarily
limited, your ability to be able to say that the court
should scale up and should infer that there are likely
to be a certain number of other hits, or an uncertain --
a certain scale of other hits, that is dependent upon
the quality of the sample that you have chosen in
a particular -- whether it is an unbiased sample, yes?
A. Yes, but in my report I haven't suggested any scaling up
from particular bugs, errors and defects. I have talked
about specific bugs, errors and defects and how many
branches they are recorded to have impacted. There's no
scaling applied to that.
Q. Have you done that? Have you -- you say that you found,
or I should say you say that there have been found 29
bugs, yes?
A. Mm.
Q. Have you given any assessment of how many branches were
affected by those bugs?
A. Yes, Dr Worden and I in I think it is the second joint
statement, the longest joint statement, that has the
bugs in, we have a column in there that attempts to
identify the number of branches that were impacted. And
certainly some of the source documentation will indicate
a number, it might not be the right number, but it does
indicate whether it is 28 or 30 or 32.
Q. What I would like to ask you to do, please, is to look
at your original second report, not your revised
version. This is {D2/4/43}.
A. I don't have a paper copy of that.
MR JUSTICE FRASER: You haven't?
A. Not a paper copy. I will have the second.
MR DE GARR ROBINSON: I'm only going to take you to one
paragraph. It is 3.105. This is the original version.
You have changed it in the revised version.
A. Mm.
Q. You say:
"The PEAKs analysed below are a small portion of the
PEAKs I have identified as causing financial discrepancy
in branch accounts outside of those bugs acknowledged by
Post Office. It should be noted there are potentially
thousands more PEAKs that illustrate financial
discrepancy arising in branch accounts, this is only a
small selected sample from keyword searched PEAKs."
A. Yes.
Q. Now let's take this in stages. You have changed the
wording of the first sentence and I will go to that
change but I want to ask you about what the original
version means first. What you are claiming there is
that you have identified a large number of PEAKs
recording bugs which cause branch shortfalls but you
have only mentioned a small portion of them in your
report.
A. Yes.
Q. That wasn't true, was it?
A. No. By the conclusion of this report there was
a substantial amount that was looked at.
Q. In fact what you had done is you had identified every
single bug that you could and included it in this
report, hadn't you?
A. Within the time available. I mean it is probably quite
possible that there could well be more but we have
certainly had a good search.
Q. So what you say in the first sentence wasn't true, was
it?
A. No, my concern with the way that it read is that --
I was saying that I had only analysed a small portion of
the ones that had caused financial discrepancy.
Q. What you are saying there -- what the words literally
mean, Mr Coyne, is that you've analysed below a small
portion of a larger group of PEAKs that you have
identified as causing financial discrepancy?
A. Yes.
Q. And in fact that wasn't the case. What you did in your
report was you included every PEAK you could, every PEAK
that you were aware of as causing financial discrepancy,
didn't you?
A. Yes.
Q. So this is an important paragraph. You will see that it
is immediately under the heading "Horizon Issue 1
PEAKs", so it is an introductory paragraph, it is
introducing the reader to what comes next. It is not as
if you wouldn't have paid attention to what was in this
paragraph. I would just like to know what possessed you
to make that extraordinary claim that wasn't true?
A. Well, all the PEAKs hadn't been analysed, but of the
portion that had been analysed there was a number that
identified financial discrepancy.
Q. Weren't you seeking to give an impression in that
sentence that wasn't accurate?
A. No, not at all, but I did see that it wasn't as clearly
worded as it should have been.
Q. And do you accept that this was corrected only after my
instructing solicitors wrote to Freeths on 1st February
asking for these other PEAKs to be identified?
A. Yes, clarification was requested. Yes.
Q. And shall we look at Freeths' response. It is at
{C5/36/1}. This is Freeths' response to my instructing
solicitor's letter. If we could go to page {C5/36/2},
please. Picking it up at the bottom, paragraph 3, it
sets out the sentence that we are talking about.
Post Office's request is:
"Please identify the full set of PEAKs that Mr Coyne
has identified as causing financial discrepancy in
branch accounts outside of those bugs acknowledged by
Post Office."
The response comes:
"See response 2.2 above, see the 'yes' entries in
the column ..."
Then if we can go over the page {C5/36/3}:
"Mr Coyne has considered this paragraph in his
Supplemental Report and notes that his opinion has not
been articulated correctly in the sentence extracted in
your client's Request ..."
I'm sorry, my Lord?
MR JUSTICE FRASER: My screen has crashed yet again but I'm
going to deal with it. I still have the common screen
and I still have LiveNote, that's good enough.
MR DE GARR ROBINSON: "As is clear from the sentence which
follows it, Mr Coyne intended to refer to the fact that
he has only reviewed a small proportion of the total
PEAK documents disclosed. As such, Mr Coyne now
clarifies the meaning of this sentence as being: 'I have
analysed a small proportion of the PEAKS, from that
analysis, I have identified the following as causing
financial discrepancies in branch accounts outside of
those bugs acknowledged by Post Office'."
A. Yes.
Q. So was that your intention? Was that what you had
intended to say at paragraph 3.105 and by clumsy
drafting you had said something very different?
A. Yes, what I meant to say was in the second draft.
Q. Well, let's go to the second draft. That's at
{D2/4.1/45}.
I do believe I have the wrong page, I do apologise.
MR JUSTICE FRASER: No, you haven't. It is {D2/4.1/45}, it
is indeed page 45 but it is in the next version.
MR DE GARR ROBINSON: {D2/4.1/45}, please. Here you say:
"I have analysed a small proportion of the PEAKs,
from that analysis I have identified the following as
causing financial discrepancies in branch accounts ...
It should be noted there are potentially thousands more
PEAKs that illustrate financial discrepancy arising in
branch accounts, this is only a small selected sample
from [the keyword searches] ..."
So knowing that it was being said that you have not
found anything like the PEAKs that you would need to
find even to begin to justify the claimants' claim,
because that had been said by Dr Worden in his first
report, hadn't it, you are now arguing in
paragraph 3.105 that this is only a small sample from
a large cohort and the small sample of bugs, the small
number of bugs that you found should be scaled up to
reflect the large size of the cohort, yes?
A. I'm saying that there is the potential.
Q. Could I suggest to you, Mr Coyne, that there's no basis
for taking the fact that you found a small number of
bugs in the PEAKs that you reviewed and inferring there
could be any number of bugs in the PEAKs that you
haven't reviewed because scaling up only works if you
have taken an unbiased sample, I think you have already
agreed that, yes?
A. Yes, and that's why I'm not giving a view on what the
scaling might be. I'm saying that the potential exists.
Q. So you accept that you can scale up from, say, 200 PEAKs
or KELs to a cohort of 220,000 but only if the sample
that you have looked at is chosen at random. Would you
agree with that?
A. No, I don't agree with that, because this scaling is
starting from the basis that there was actual bugs,
errors and defects that did cause financial
discrepancies. So you are scaling up from a positive
position that there are records in there that do show
that and there's the potential for other ones to show
that.
Q. So what you are suggesting is that having found 29 bugs,
it is possible to scale up, it is possible to infer that
there are likely to be thousands more bugs in existence,
is that what you are saying?
A. There's certainly the potential to be.
Q. There is the potential. Because what interests me is
this concept of scaling up. The bugs that you found you
didn't find by reviewing a randomly selected sample, did
you?
A. No.
Q. You did the equivalent of asking everyone coming out of
the polling station who was wearing a blue rosette,
didn't you? Because what did you was you were looking
for bugs that had that effect. You were positively
searching for and excluding all others. You were
searching for bugs that had particular characteristics?
A. It doesn't work when you try and relate it back to the
election scenario where the purpose of that is to try
and establish what the percentage of people voting would
be. In this scenario here we are, as I understand it,
trying to identify real bugs, errors and defects, so
that is what is -- what was done during this exercise.
And what I'm saying here is because I have only analysed
a small number of the totality of the PEAKs, then there
is the potential for many more to be in here.
Q. Could I suggest that the process that you have
undertaken -- first of all, perhaps we can agree this.
Do you agree that the sample, the small sample that you
describe, the small selected sample that you describe in
3.105, that isn't an unbiased sample, it isn't
an unbiased sample from which it is possible to scale up
anything?
A. It is certainly not an unbiased sample, that is correct.
Q. From which it is possible to scale up anything?
A. You wouldn't want to scale up from that and make any
numerical assumptions based on the -- however many,
I think it was less than 10,000, but however many there
is, that that should be the number multiplied by that
percentage of the total number of PEAKs, you wouldn't
want to make that assumption.
Q. What I would like to understand, though, is why you
chose to say there are potentially thousands more PEAKs.
Why didn't you say dozens more or hundreds more? Why
did you choose to say thousands more PEAKs? It seems to
me, Mr Coyne, as if you are inviting the court to infer
that because you found 29 bugs from a small sample, it
is appropriate to think there could well be thousands
more out there that you haven't found, and I would like
to ask you why you think it is appropriate for the court
to think that?
A. I don't believe there is any more appropriate number to
put in there. Nothing would provide any precision in
there as to what the number could or should be.
Q. Are you suggesting that it is likely that there are
thousands more bugs of this sort?
A. No.
Q. In fact are you suggesting that -- well, are you
suggesting that it is more likely that there are
thousands than there are hundreds or dozens, for
example?
A. Yes, I don't -- I would think there would be more than
dozens certainly.
Q. I'm interested that you should say that. So you are
suggesting -- you are now making a claim that having
found 29 you think there will be dozens more. Is that
right?
A. I certainly believe there would be dozens more, yes.
Q. And are you prepared -- but you are not claiming that
there could be more than -- that there are likely to be
more than dozens, that is not a claim you are making?
A. I don't know what the number would be but there
certainly is the potential for there to be thousands
more.
Q. By "potential", you are saying it is not impossible, are
you?
A. Sorry, say again?
Q. By "potential" you are saying -- sometimes when people
say "potential" they mean it is a really viable
possibility and close to a likelihood that something is
going to happen, other times they simply mean it is
simply not impossible. Potentially I could become Prime
Minister. It is possible although it isn't going to
happen. Other times I could say potentially I could
retire when I'm 65, and that would be -- it's not
certain but it is a real -- now, when you say
"potential" you mean not impossible, don't you?
A. It is certainly not impossible and it is on the basis
that there are 200,000 PEAKs, whatever the exact number
might be, that haven't been reviewed. They weren't
responsive to the search terms that were selected at the
time.
Q. But here's what I don't understand, Mr Coyne. As you
explained very helpfully yesterday morning, you and your
team have spent a great deal of time using the
intelligent search functions that you have at your
disposal, which I rather envy, I have to say, in order
to find precisely these kinds of PEAKs and KELs?
A. Yes.
Q. And you are quite good at that. You are certainly
better than I would be. It is the entire raison d'etre
of your e-disclosure business, isn't it, that you can
use what is in the trade called intelligent search
functions? In those circumstances isn't the fact that
you have only been able to find 20 bugs significant?
A. No, I don't believe so. Typically we would be and
I would be assisted by somebody within the organisation
who created the documents, that would be helpful with
things like particular error codes that might indicate
financial discrepancy, certain terminology in code and
things like that. None of those were provided. So
I was starting from the basis of just trying to come up
with words and phrases that may be used, that may
indicate a discrepancy, that may indicate a defect,
an imbalance, but it is entirely possible that there are
words and phrases used that I'm not aware of.
Q. But I presume that by the phrase "intelligent search
functions" you include concepts such as once you have
started finding some and you see how they draft
themselves, you realise there are word patterns or
symbol patterns or report patterns, TPSC256, TPSC268A,
all those automatic report numbers which indicate
receipts and payments mismatches, or CRC failures, or
all the other issues that could be indicative of a bug.
That as you go along and as your knowledge of the PEAKs
and the KELs increases, you become better and better at
finding terms and symbols which will enable you to zero
in on the PEAKs and KELs that you are actually looking
for. Isn't that how it works?
A. That is how it works. One of the documents that
I requested very early on was a document that would
indicate where a financial impact has been discovered.
That was one of the very first documents. And that
simply wasn't provided, that request was --
Q. I'm sorry, why are you making that point?
A. Because that would have assisted with the searching that
I was doing at the time.
Q. Mr Coyne, what document are you talking -- what document
did you request?
A. There was an RFI request that I put in, I think it was
in June or July --
Q. Right, and this RFI request was a request which was
designed to assist your search functions, was it?
A. Yes.
Q. And what did the request seek?
A. We have probably got the document, but it asked for
documents that were returned that would indicate that
a financial impact has been discovered.
Q. I have to say, it may be my fault, but I'm scratching my
head metaphorically, I don't recall that particular
request, but let's not waste any time on it.
Let me ask you a different question. My suggestion
to you is the fact that you have only been able to find
29 bugs, it is significant, because with or without the
document you just referred to you have found bugs which
you think do disclose a lasting shortfall for which
subpostmasters were made liable, is that right?
A. Yes.
Q. So you have seen how PEAKs and KELs relating to those
bugs are worded, yes?
A. Yes.
Q. So it is not as if you have been prevented from making
choices about the form of words and symbols and so on,
not been prevented from alighting upon the kind of
searches you need to do in order to find the bugs you
are looking for, yes?
A. The process would have been far easier if the documents
that I had asked for would have been provided at the
time.
Q. Okay. Let's not talk about the process, let's talk
about what you have actually done.
A. Yes.
Q. Imagine for the sake of argument that your team's
intelligent service system were absolutely brilliant and
that it were perfectly qualified, having become really
familiar with the system and with all the reports that
are generated in the system and all the phrases that
tend to be used and so on, they were absolutely
brilliant at capturing evidence of bugs of the sort you
were looking for. Now if that were the scenario, the 29
bugs that have been found could be very close to the
absolute total number of bugs that are to be found in
the cohort of documents, couldn't they?
A. It is possible that that's the case. I think it is
highly unlikely but it is possible that that's the case.
Q. Then let's assume that you weren't quite that good. It
might be that you only got half of them or perhaps
a third of them.
A. Yes.
Q. But doesn't, with all the intelligent search functions
that you have at your disposal and the people you have
to help you, doesn't the fact that only 29 have been
found strongly suggest that there aren't thousands more
bugs lurking in the PEAKs that you have been unable to
uncover?
A. It is certainly possible that the number is a lot less
than that, yes.
Q. I would suggest to you, Mr Coyne, that it is obvious
that if you have only been able to find 29 PEAKs there's
no way in the world that there are 100 times that number
of PEAKs out there that you have been unable to find?
A. There are hundreds of thousands of PEAKs and the impact
is not always described in the PEAK.
Q. Could you just answer my question before we can move on.
You have segued into the question of impact and I am
going to come to that.
A. Sorry, forgive me.
Q. But just focus on my question for a moment. Isn't it
obvious that however difficult the process has been,
that your team has not been so clumsy and incompetent
that it has only managed with all its intelligent
searches to find 1 in 100 of the bugs that are actually
disclosed in the PEAKs and KELs that you have reviewed?
A. No, I do not think that's inconceivable.
Q. Can you say that again?
A. I don't think it is inconceivable that that might be the
case.
Q. You don't think it is likely, though, do you?
A. It would be a complete guess.
Q. Yes. Here's what interests me, Mr Coyne. Before we
broke for lunch I asked you some questions about the KEL
system and the PEAK system, and I'm afraid I don't have
the transcript in front of me, but I think you helpfully
agreed that if a bug was detected which had branch
impact it would -- the chances were, I think I may be
putting it slightly too low, that it would be likely to
be addressed in a KEL somewhere, yes?
A. A PEAK somewhere.
Q. A KEL. We were talking about KELs at that time.
A. Sorry, could you put your question again then.
I thought you --
Q. Perhaps I should look at the transcript. Could we go
back to just before we broke. Would you give me
a moment, please.
A. Certainly.
Q. If we could go to page {Day15/94:21} of today's
transcript, please.
MR JUSTICE FRASER: Of which page, sorry?
MR DE GARR ROBINSON: 94, my Lord.
MR JUSTICE FRASER: 94, line 21.
MR DE GARR ROBINSON: I ask a question. I say:
"I see. So what you are saying is that if you get
a bug, you generally speaking -- and of course there are
always -- I'm not suggesting to you that anything is
comprehensive -- but you are saying that generally
speaking if you get a bug of that sort there will be --
once it is detected, there will be a KEL which addresses
it, yes?
A. Yes.
Q. And you said "Yes".
A. Yes.
Q. You are not withdrawing that evidence, are you?
A. No, no.
Q. So we have this situation. We have if there is a bug
that has been detected, the chances are it is going to
be described in a KEL somewhere, yes?
A. Yes, if it has been detected, yes.
Q. And there aren't 220 KELs, are there, there are
something like 9 and a bit thousand, is that right?
A. Yes.
Q. And we know that even by the time of your first
report --
MR JUSTICE FRASER: Just give me literally 30 seconds.
MR DE GARR ROBINSON: Of course, my Lord.
(Pause)
MR JUSTICE FRASER: It is all right. Go ahead,
Mr de Garr Robinson.
MR DE GARR ROBINSON: At the time of your first report we
know you had already reviewed yourself 5,114 KELs, yes?
A. Mm.
Q. And members of your team had, would I be right in
thinking, I may have specifically asked you this, and if
so I'm sorry to be going over it, but members of your
team would have reviewed other KELs in addition to that?
A. Yes.
Q. And since your first report you would have looked at
further KELs on top of the --
A. Yes.
Q. And I think I asked you how many you had reviewed and
you said you were unable to tell me. That's my
recollection but forgive me if I'm wrong.
A. No, I think that is right.
Q. Right. So you have looked at more than 5,114 KELs.
Would I be right to infer you probably looked at more
than 6,000?
A. No, it probably is between 5 and 6,000.
Q. And your team had looked at others as well. Are you in
a position to give any kind of assessment of how many
other KELs they are likely to have looked at?
A. It will likely be probably 1,000 more or something like
that.
Q. Okay. So you and your team collectively have looked at
something like between 6 and 7,000 KELs out of a total
of, what, 9,500, that kind of figure? Yes?
A. Mm.
Q. And yet all that has been found is 29 bugs, correct?
A. Yes.
Q. Isn't that a significant indication, Mr Coyne? Doesn't
it suggest quite strongly that the chances are that the
total number of bugs that are out there are not going to
be in the thousands. In fact there are unlikely to be
more than perhaps twice as many in the entire cohort of
KELs, would you agree?
A. That have an impact on branch accounts, yes.
Q. Yes. And if one then were to assume that some error
factor, let's assume there are some PEAKs that don't
make it through to KELs, that's not going to account for
very many, is it, because most of the time you would
expect the PEAK to have resulted in a KEL as soon as the
problem was discovered?
A. Yes.
Q. So actually, just ignoring the PEAKs for a moment, in
that you have reviewed, you and your team, over 6,000
KELs, so more than two-thirds of the available KELs --
A. Yes.
Q. -- and you found, between you and Dr Worden, 29 bugs --
A. Yes.
Q. -- wouldn't it be fair to infer that the total number of
bugs to be found in those KELs is likely to be less than
40?
A. Yes, that sounds reasonable. I'm just concerned that
the confusion here is between KELs, which document
a single instance of a bug, and a PEAK which is what we
are referring to here, which shows how many times that
bug has had an impact on the Horizon system.
Q. So let's take this in stages. Two questions raised.
The first one is how many bugs? The second one is how
many impacts and what's the nature of their impacts?
A. Yes.
Q. Both questions are important building blocks in order to
arrive at an assessment of extent, yes?
A. Yes.
Q. Thank you. I think you have agreed that the chances
are, as a result simply of your examination of KELs,
that there are likely to be no more than 40 bugs which
have been found to have branch impact, yes?
A. Bugs, errors and defects, yes.
Q. So we move on to the next question which is what was the
impact of these 40 bugs? What you say is -- and I fully
understand it -- that you can't get that from KELs, you
get that from PEAKs.
A. Yes.
Q. But here's the interesting thing: because you have got
the KEL, actually the KEL operates as a really useful
way of looking for PEAKs to which the KEL is relevant,
doesn't it?
A. Yes, you will often see the link between the two.
Q. Quite often, as you fairly say, there is actually
a specific link made between the PEAK and the KEL, and
you can search for PEAKs and the PEAKs will -- this
would be right, wouldn't it: PEAKs invariably refer to
the KELs to which the problems they address are
relevant, yes?
A. Yes. There is a better quality of link from PEAKs to
KELs. There's not always that link KEL back to PEAK.
Q. But this is where the beauty of intelligent searching
comes in, isn't it? Because you can intelligently
search through the body of PEAKs, having identified all
the relevant KELs, and there may be a number of them,
there may be one KEL and perhaps two or three others
that are also relevant, you search for all the PEAKs
which refer to those KELs, don't you?
A. Yes.
Q. And by that means you are going to get actually quite
a good sense of -- you are going to get a good hit rate.
You are going to find most, probably more than most, of
the PEAKs considering problems which those KELs address,
yes?
A. It is entirely possible to do that, yes.
Q. I'm not asking you whether it is possible, I'm
suggesting that it is likely that if you undertake that
search you will actually find all the PEAKs that are
relevant -- that exist that are relevant to the problem
addressed in the KEL?
A. Yes.
Q. So you have identified 29 bugs, you do your searches for
all the PEAKs, and by that means you can identify all
the PEAKs which record manifestations of the bug. It's
likely, I'm going to use the word "likely". I'm not
suggesting it can be entirely comprehensive, Mr Coyne.
So can we take it as read that obviously there are going
to be gaps at the margin, aren't there?
A. Yes. A PEAK is typically created when the bug, error or
defect gets to SSC within Fujitsu. So there may be
others that don't get there, but once they get to third
line support the PEAK is created, so yes.
Q. So by this means you were in a good position both to
identify bugs that have been detected in the system --
A. Yes.
Q. -- quite reliably, so with a fair degree of confidence
that there won't be that many more bugs in the system?
A. As long as they hit the search terms that I have used,
yes.
Q. Remember we are talking about the KELs now. The
starting point for the process that I have described is
the KELs.
A. Yes.
Q. And you've physically reviewed those KELs, haven't you?
A. Yes.
Q. So it is not as if you need intelligent search terms to
find the right ones, you have actually looked at them,
haven't you?
A. Yes.
Q. So by physically looking at them you found however many
bugs you found, I think it was -- it must be somewhere
below 20 because of course of the 29 there were also
bugs that were accepted by Post Office and there were
the bugs that were found by Dr Worden as well. So you
found -- if I suggest to you that you found around in
the late teens, would that figure sound about right to
you?
A. I believe that the figure in the second report was 28,
was it?
Q. 28. Well, that would include the bugs that have been
found by -- that have been admitted --
A. Yes, it did --
Q. -- by Post Office, yes?
A. -- the three --
Q. And it would include bugs that have been identified by
Dr Worden in his report?
A. Yes.
Q. Let's not quibble about numbers. The point is by that
process I think you have accepted that it is
a relatively reliable process by which you will have
successfully identified the large majority of the bugs
that have been identified by the SSC during the
operation of the PEAK and KEL system?
A. Yes.
Q. What's more, because having done that you can then look
through the PEAK system, you have the ability to
identify all the PEAKs which represent manifestations of
those bugs?
A. Yes.
Q. And those PEAKs identify -- where there are branch
effects those PEAKS generally will identify the branches
affected, yes?
A. Generally but not always.
Q. Generally speaking, if a branch has a problem then the
PEAK will identify the FAD code of the branch, correct?
A. No, that's not always the case. They will typically say
this might have an impact on branch accounts. They will
sometimes list a FAD code. They will sometimes refer to
a branch by name or location.
Q. I see. Let me park that issue until another day. But
in any event by this means, by moving from the PEAKs to
the KELs, you have quite a good method of identifying
the number of instances in which branches have been
affected by the relevant bug, yes?
A. Yes.
Q. Perhaps half an hour ago you gave me an answer which
surprised me. I wasn't expecting it. You indicated
that in the bug table in joint statement 2 there was
a column which indicated what the extent of each of your
bugs were, in other words the number of branches that
were affected by each of your bugs. Did I misunderstand
your answer?
A. It is either in the joint statement 2 or it is in the
report 2.
Q. You see, I'm struggling to understand what you are
talking about. It may be my fault. But I'm not aware
that anywhere -- that you have anywhere given any
evidence as to how many branches you think were affected
by any particular bug. Have I misunderstood your
evidence?
A. It certainly is in here. There is an attempt to
identify how many branches may have been impacted by
that defect.
Q. It would be helpful if you could tell me because it
might save some time tomorrow or the day after. Should
I be looking at the joint statement?
A. Yes, if you look at joint statement 2. So the page
where the actual table starts, index 1 on the left-hand
side. Then it says receipts and payments mismatch, the
year, and then it says:
"Coyne's opinion as to branch account impact ...
identified approximately 60 branch accounts ..."
Q. That's because Post Office had identified 60 branches.
But if we go --
A. If you go down for example to number 5, 14 examples of
branch impacted.
Q. Oh, I see, and we have got 57 branches impacted. For
6.2 it's one branch impacted.
That's very helpful, Mr Coyne, and by saying it is
very helpful I'm of course conveying that I obviously
haven't read this table properly.
What's interesting about it, though, is that the
numbers of branch impacts you are talking about are
relatively low, aren't they? I mean even 60 branches.
So if we take the receipts and payments mismatch, 60
branches affected. 60 branches out of 30 million
monthly accounts, that represents a 1 in 5 million
chance of a bug impact on a given set of accounts,
doesn't it?
A. You have used two different variables there. You have
used branch accounts --
Q. Yes.
A. -- and you have applied that to branches. If 60
accounts are impacted should that not be compared
against the total number of branches?
Q. Are you suggesting that when 60 branch accounts are --
so what you have done here is you have indicated how
many branches were impacted, but are you suggesting that
lots of these branches were impacted on lots of
occasions, is that --
A. No, I was responding to your -- you gave me an example
of why it was low.
Q. Yes. My suggestion to you, Mr Coyne, is that in
circumstances where you have got a bug that affects 60
branches?
A. Yes.
Q. And let's say it affects 60 branches on one occasion
each, sometimes it will be more, but let's assume it is
on one occasion each. If you look at the entire corpus
of monthly branch accounts, which is 3 million over
20 years, then of the 3 million branches that will have
been affected -- or that could have been affected,
I should say, 60 will have been affected.
A. Yes.
Q. Which means it has a 1 in 5 million chance of hitting
any given branch that you are looking at at any --
A. On any given month. That may well be right, yes.
Q. Okay. Thank you.
MR JUSTICE FRASER: But that's where his evidence was to
where he had identified the numbers.
MR DE GARR ROBINSON: My Lord, I see that.
So moving back to my line of questioning, I was
asking you whether finding only 29 bugs strongly
suggests that there aren't thousands more bugs in the
system in the way that you seem to suggest at paragraph
3.105?
A. No, but that's referring to "potentially thousands more
PEAKs". PEAKs are occurrences of bugs.
Q. I see. But I thought -- I may have misunderstood your
evidence then, Mr Coyne, because I thought you just told
me that once you had a KEL identifying a particular bug
it is relatively easy to find all the PEAKs to which
that KEL is relevant, yes?
A. Yes.
Q. And I think you established with me that you had done
that and that the result of that process is the column
in joint statement 2 that we have just been looking at?
A. Yes.
Q. Could I ask you, Mr Coyne, if you were to add up all the
PEAKs that are referred to in that second column in
joint statement 2, will it demonstrate that there are
thousands more PEAKs that are relevant?
A. I would have to go through and add them up. It is not
something that I have done at this stage.
Q. You are making a claim here, Mr Coyne, that there could
be -- you don't just say -- yes, "potentially thousands
more PEAKs". But even when you wrote that sentence you
had it in your power to actually work out how many more
PEAKs we are talking about, didn't you?
A. No, I have worked out the number of PEAKs that relate to
the KELs and the numbers will be in here. But there
could well be many more PEAKs that don't have the
references to the KELs.
Q. Well, aren't you contradicting some evidence you gave to
me a few minutes ago, Mr Coyne, in order to preserve
your position on that second sentence? Because before
I think you told me that once you identify a KEL it is
actually quite easy to then find all the PEAKs to which
the KEL is relevant.
A. Yes, that is right.
Q. Right. So the simple fact is that in order to
demonstrate the truth of the statement:
"... there are potentially thousands more PEAKs that
illustrate financial discrepancy ... in branch accounts
..."
All I have to do is go to column 2 of joint
statement 2 and add up all the numbers. Do you think
there is a remote possibility of all those numbers
coming to thousands, plural?
A. No, I don't believe -- I'm just looking through now to
see if there's any that has an impact on ... It is
possible that there is a PEAK that has an impact on, for
example, 100 branches but I don't know whether that's
the case or not, we would have to look through.
MR JUSTICE FRASER: One says 88, I think.
Mr de Garr Robinson, do you want the witness to do
a more detailed arithmetical analysis of that column, is
that what you are asking him to do?
MR DE GARR ROBINSON: My Lord, I'm asking the witness to
accept that in actual fact, having done all the work
that he has done, and having produced the results which
are now recorded in the second column which I freely
admit I haven't fully understood and I'm grateful for
Mr Coyne's clarification, it doesn't get anywhere near
thousands more PEAKs.
MR JUSTICE FRASER: So, Mr Coyne, that was a question to
you.
A. I'm content with the answer that I have given that there
is the potential for there to be up to 1,000 PEAKs
because you don't -- you only need to find a few more
KELs that have impacts such as the bug, error or defect
that impacted 88 branches to get to 1,000.
Q. Here's what's interesting, Mr Coyne. What we have is
what might be called an example of evasion. The claim
you make in 3.105 is that there are potentially
thousands, plural, more PEAKs, and do you see what you
did with your answer? You went down to up to 1,000 in
order to maintain your position.
What I'm suggesting to you is on the very process
that you have described to this court, on oath, and your
explanation of the documents and how they work and the
kind of things that they show and the things that they
are likely to contain, it stands to reason as night
follows day that there are not thousands more PEAKs in
the PEAK corpus that illustrate financial discrepancy
arising in branch accounts, would you accept that?
A. I don't accept that. I don't accept that that position
that there are potentially thousands more is incorrect.
Q. Well, I'm not sure I can go any further with this at
this point, Mr Coyne.
Let's analyse other examples where you use words
suggesting that things happened on a large scale where
in fact that might not be the case. Can we go to your
first statement {D2/1/38}, please. At paragraph 3.18 --
A. Sorry?
Q. Of your first report.
MR JUSTICE FRASER: 28. I think you said 38.
MR DE GARR ROBINSON: I'm so sorry.
MR JUSTICE FRASER: Let's go to 28.
MR DE GARR ROBINSON: {D2/1/28}. At 3.18:
"Many ... (KELs) identify that not all errors were
understood even by Fujitsu. In the circumstances, it is
highly unlikely that a Subpostmaster could interpret or
identify the causes of any bugs/errors or defects when
Fujitsu themselves often did not understand the cause of
such or their full effects."
So you have got another use of the word "often", do
you see that?
A. Yes.
Q. And no indication is given of the scale of the word
"many" or the scale of the word "often", what kind of
numbers you are discussing. Would you agree with me,
Mr Coyne, that 10, for example, is hardly material given
the scale of Horizon and the long period over which it
has been in operation, yes?
A. 10 KELs?
Q. Yes.
A. When you say it is material? I don't --
Q. Let me change the question. Use of words like "many"
and "often" are capable of being really dangerous,
aren't they, because they are capable of giving
an impression unless you are clear about the scale of
the occasions which you believe to be shown by the
evidence, yes?
A. Yes.
Q. And what scale -- when you say "many" and when you say
"often", what scale of numbers are you referring to in
that paragraph, can you recall?
A. No, I can't recall. There is a number.
Q. In paragraph 5.64 at page {D2/1/71} of the same
document, the last sentence in that paragraph:
"I have noted that hardware replacement often seemed
to be a 'fix' of last resort where no other explanation
could be given, and therefore there is certainly a
possibility that hardware was at fault."
Now you see there is a footnote there. Do you see
that, footnote 88?
A. Yes.
Q. Perhaps we could have a look at that, it is {F/178/1}.
This is a KEL, it is dated -- it was raised on
18th November 1999, so it is very early in the life of
Horizon.
A. Yes.
Q. It was last updated in January 2004.
A. Yes.
Q. Under "Solution" -- and I see again that Atos is
referred to, which is very curious because Atos wasn't
on the scene for years until after 2004 and I do rather
think that there must have been some word-processing
change made at some point, I don't know how.
It says:
"This appears to be either the PM is typing ahead of
themselves and the system suddenly catches up, or
keyboard or screen fault generating spurious key
presses. Recommend that the PM tries not to type ahead
of the system (or to press the same key a number of
times if there appears to be no response from the
system) or to replace the keyboard and/or screen. PM
should select existing. This functionality has been
removed from CI4 ..."
Which I think would be a release. So there came
a point at which it was no longer a problem, yes?
A. Yes.
Q. Now, that's one example of a possible hardware fault,
yes?
A. Yes.
Q. How can that justify the claim that you make here that
hardware replacements are often a fix of last resort?
A. Well, there's a number of other examples. There is the
phantom transactions example where hardware was changed
because it was -- they were trying to work out whether
it was environmental issues or not that were causing
erroneous transactions. There are a number of examples.
There is only one cited here but there are a number of
examples throughout the report.
Q. Are we talking about five examples or are we talking
about 100 examples?
A. There will certainly be five examples that --
Q. I see. So there "often" means something in the region
of five, does it?
A. Yes.
Q. Then if we move on to page 97, paragraph 5.161
{D2/1/97}:
"Whilst both Horizon and Horizon Online contain a
number of measures and controls designed to check system
integrity, these mechanisms have been shown to have
failed. This is a point agreed upon in the Joint
Statement. It has been identified that known
issues/bugs were often deferred and dealt with on a
cost/benefit basis."
That is a paragraph that we have discussed before
and I have already suggested to you that the evidence
gives no basis for claiming that it happened "often".
But more importantly, I would like to ask you what
you mean by "often" in that sentence. Again you give no
scale, no sense of how many times we are talking about.
Are we talking about five times, ten times, a hundred
times?
A. Quite a few times. There is a document that looks at
defect deferment, so a number of defects have been
identified but they are deferred to be dealt with later,
although they acknowledge that they could have an impact
on branch. This was the point that we discussed
yesterday.
Q. This is the handful of PEAKs that you provided to me
this morning, is it?
A. Yesterday we were taken to an incorrect reference in the
document and --
Q. Do you mean a document you had incorrectly referred to
in your statement or did I take you to a wrong document?
Because if it is the latter, I'm terribly sorry.
A. Sorry, I think it was as a result of -- Mr Green
interjected and directed to a document, but the document
wasn't provided at the side of Magnum, so we should have
gone to the footnote. I would like to go there if
that's possible.
Q. I'm afraid I don't actually know what you are talking
about. Does Mr Green?
MR GREEN: My Lord, I didn't want to press my intervention
yesterday. I will explain it in re-examination. But
5.166 is the paragraph which gives context to what
I mentioned yesterday.
MR DE GARR ROBINSON: The document we looked at just before
we broke?
MR GREEN: No, it is the release note.
MR DE GARR ROBINSON: Oh, I see.
MR GREEN: In the context of which there is an example.
MR DE GARR ROBINSON: Very good.
So in answer to my question what's the scale of
"often" in that sentence, what would your answer be?
What sort of number of cases are we talking about?
A. A number, it will be the number that's actually
contained within that document at footnote 156.
Q. Okay. So the answer is to be found in that footnote, is
it? Thank you, I will look at that later.
Let's move on to your second report at {D2/4.1/14}.
If we could go to page 14. At paragraph 3.13 you say:
"For example, it appears that PEAKs are often closed
or suggested to be closed if analysis has paused or has
not uncovered a full diagnosis despite the Subpostmaster
and/or Post Office not having a conclusion. It is also
not always clear whether a Subpostmaster was informed
..."
Then at the end you say:
"I have seen PEAK records that are closed despite
support not being able to diagnose a root cause whilst
acknowledging that there clearly is some form of
error ..."
A. Yes.
Q. You will I think recall that my instructing solicitors
wrote to Freeths to ask which PEAKs were being referred
to.
A. Right.
Q. If we could look at {C5/36/1}, please. Go to page
{C5/36/2}, paragraph 1. Here is Freeths' answer to that
question. The question is:
"Please identify the ... PEAKs [referred to in that
paragraph]."
And the answer comes, there are nine PEAKs referred
to. Do you see that?
A. Yes.
Q. I don't have time to take you to them, there are
subtleties in those documents which might otherwise be
put. But are you aware that of those nine PEAKs there
have been only two examples since 2002?
A. I don't understand the question. So within those
PEAKs --
Q. Of the nine, seven of them occurred between 1999 and
2001.
A. Right.
Q. One is from 2012 and one is from 2017.
A. Right.
Q. So the truth is that over the past 17 years this has
happened, or there are PEAKs showing this as having
happened twice, yes?
A. Yes, okay.
Q. Bearing in mind you are making a claim about these
things often happening, could I suggest to you it might
have been helpful and balanced for you to have indicated
that that was the position?
A. Yes.
Q. That most of these occasions occurred during the very
early years of the original Horizon. Do you accept
that?
A. Yes, it would have been helpful to include that.
Q. If I can take you to another example just before we
break. At 5.108 at page {D2/4.1/156} it is said:
"At paragraphs 251 to 257 of his report, Dr Worden
refers to the concept of 'User Error Correction'
enabling the facility of correcting many software
errors. It should be noted that this would not apply to
any bugs/errors and defects unbeknownst to Fujitsu or
the Subposmaster. It is evident from the PEAK analysis
that often bugs lay undetected for weeks, months or
years."
My instructing solicitors wrote in the letter that
we have just discussed, wrote a letter asking which
PEAKs show that happening, and the response came at
paragraph 9.2 of the letter, that's {C5/36/5}.
The answer was:
"Please refer to Mr Coyne's Supplemental Report
(particularly paragraph 3.26 to 3.54) which sets out
commentary in respect of various bugs ..."
Now paragraphs 3.26 to 3.54 are the section which
I think is headed "Acknowledged Bugs" but it is actually
the four bugs, the four main bugs, that you focus on in
your report, namely the three bugs identified by
Post Office plus Dalmellington. Do you remember that?
A. Yes.
Q. No particular reference is made to any other bug in this
context. How many other bugs do you say lay undetected
for weeks, months or years?
A. Well, there was certainly Dalmellington.
Q. Yes, that's one of the bugs referred to in those
paragraphs. Let's not worry about weeks because one can
understand why it may take time for a bug to be
detected, but months or years. In your list of 29 how
many other bugs lay undetected for months or years, can
you tell me?
A. I can't. I would have to go through and --
Q. Could you give me a scale? Between one and four? Ten?
Any idea at all? It is just that by using the word
"often" it suggests to me that you have a clear idea in
your head, Mr Coyne.
A. Well, I will have had a clear idea in my head, I just
don't know what the actual number is now that you are --
Q. An approximate number, a scale. Can you give me any
indication?
A. No, I would prefer to work it out properly and give you
a proper answer to that.
Q. That is entirely fair.
Let me ask one last question before the break. In
relation to bugs that are detected after a period of
time there's evidence showing, I am sure you all agree,
that investigations are undertaken by Fujitsu to ensure
that all the branches that are affected in the meantime
are identified, are you aware of that evidence?
A. Yes.
Q. It is said that this is a standard process undertaken by
Fujitsu when they identify a bug that could affect
branches, yes?
A. Yes.
Q. Do you have reason for thinking that that has not
happened in any number of cases?
A. I am aware of one where the data was no longer available
to investigate it.
Q. Which bug was that?
A. I would have to find the example. It is in the report.
Q. I see.
A. I would have to find the example. I know that on
Dalmellington there was I think at least two occurrences
where Fujitsu weren't able to identify what the impact
actually was. They were able to identify the number of
branches --
Q. We will come to Dalmellington. So it is Dalmellington
and one other, those are two examples you are aware of,
is that right?
A. I've certainly got an example of another, yes.
Q. Are you aware of any other examples of this not
happening?
A. No.
MR DE GARR ROBINSON: My Lord, I don't know whether this
would be a convenient moment?
MR JUSTICE FRASER: We will come back at 3.15 pm. 10
minutes.
(3.05 pm)
(A short break)
(3.15 pm)
MR DE GARR ROBINSON: Mr Coyne, I would like to suggest to
you that ultimately the main number in this case is the
impact, the financial extent of bugs in Horizon, do you
agree?
A. Yes.
Q. But it is interesting that you don't address that in
your reports, do you?
A. The actual amount of the impact?
Q. Yes.
A. No.
Q. You have not been prepared to venture any figure which
estimates the total impact in financial terms of bugs in
Horizon, yes?
A. That is right, yes.
Q. Might I suggest that with your experience of IT risk
analysis, you are perfectly capable of setting out at
least in broad terms a view of the extent of the losses
caused by the bugs that you have identified?
A. The best that I could do would be to go through the
PEAKs and write down the numbers that were said to be
wrong but I do not think that would be a very
satisfactory way of doing it.
Q. What I suggest to you is that if you were to do that
process or perform any judgment at all as to financial
impact, you wouldn't find a number which remotely
supports the claimants' case, would you accept that?
A. I haven't looked at the detail of the claimants' case.
MR JUSTICE FRASER: Just hold on one second.
Mr de Garr Robinson, are you pursuing those
questions as part of what ought to have been done on
particular Horizon Issues or just as a general umbrella
question?
MR DE GARR ROBINSON: Both.
MR JUSTICE FRASER: As a general umbrella question it is not
a question for the witness. But if you want to pursue
it in terms of: to answer this Horizon Issue properly
you ought to have done that, then you should do it by
reference to the Horizon Issues.
MR DE GARR ROBINSON: Well, my Lord, I'm putting my case to
the witness and that case is based upon what's in
Dr Worden's expert report.
MR JUSTICE FRASER: No, I --
MR DE GARR ROBINSON: To which I will be coming in due
course.
MR JUSTICE FRASER: Mr de Garr Robinson, this witness is
giving evidence on the Horizon Issues.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: I'm not saying don't put it, I'm saying
if you are doing it in terms of: in order to address the
Horizon Issue correctly, you need to identify it by
reference to a Horizon Issue.
MR DE GARR ROBINSON: My Lord, I have a case to put which is
based upon my expert's report. The questions I am
putting are establishing the building blocks for putting
that case and I would be obliged if your Lordship would
let me do that.
MR JUSTICE FRASER: But Mr de Garr Robinson, the two experts
have approached each of their separate -- the same
exercise, they have approached it in different ways.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: That's the point.
MR DE GARR ROBINSON: And I have to put my case to this
witness, my Lord.
MR JUSTICE FRASER: Yes, but he is called to give evidence
on the Horizon Issues. I'm not saying you can't put the
question, what I'm saying is you need to put it by
reference to the Horizon Issues that he is giving on
rather than just arguing your case.
MR DE GARR ROBINSON: My Lord, I don't want to argue my case
with this witness which is why I would like to ask him
questions rather than engage in argument about
particular Horizon Issues. If your Lordship is saying
that I have to argue with him about particular Horizon
Issues then I will do that, but I would respectfully be
obliged if your Lordship would let me put my case.
MR JUSTICE FRASER: Mr de Garr Robinson, you are slightly
misunderstanding two things. You are misunderstanding
that cross-examination is just arguing with him, which
it isn't.
MR DE GARR ROBINSON: Well, exactly.
MR JUSTICE FRASER: What I'm saying is by reference to
Horizon Issues upon which he gives evidence, if you are
going to put to him: in order to have fulfilled that
properly you should have done X, Y and Z, and you
haven't, then you can put the question, but you need to
peg it back to the Horizon Issues.
MR DE GARR ROBINSON: My Lord --
MR JUSTICE FRASER: I think I have now said that three
times.
MR DE GARR ROBINSON: You have.
MR JUSTICE FRASER: And I do not think it is a controversial
point. If you want to make it a controversial point in
due course in submissions you can.
MR DE GARR ROBINSON: My Lord, let me explain to
your Lordship where I'm going. I'm loath to do that in
front of the witness, but let me explain.
MR JUSTICE FRASER: Hold on a minute. A couple of minutes.
Just for the transcript, I'm asking the witness to
step outside.
(In the absence of the witness)
MR DE GARR ROBINSON: I am going to take the witness to
section 8.5 of Dr Worden's report.
MR JUSTICE FRASER: Yes.
MR DE GARR ROBINSON: In which he says that in order to have
sufficient bugs to even begin to justify the claims
being made by the claimants there would need to be in
the region of 40,000, and I'm going to put it to him
that that's right.
MR JUSTICE FRASER: Yes.
MR DE GARR ROBINSON: Now, is your Lordship going to permit
me to do that?
MR JUSTICE FRASER: Yes, of course. But the question you
asked him was:
"If you were to do that process or perform any
judgment at all as to financial impact, you wouldn't
find a number which remotely supports the claimants'
case ..."
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Now, by "number", I take that to mean
financial number as in pounds, not shillings anymore,
and pence. Is that right?
MR DE GARR ROBINSON: Yes, that's --
MR JUSTICE FRASER: But that is not part of one of the
Horizon Issues.
MR DE GARR ROBINSON: That's the point that's put in
section 8.5 of Dr Worden's report, my Lord.
MR JUSTICE FRASER: Well, if you are going to suggest to
him -- I'm going to deal with it on this basis. As
I made clear, I think, I'm going to let you put the
question and pursue that line by reference to
Dr Worden's evidence, but if you are going to maintain
to this witness that in order properly to have addressed
each of the Horizon Issues he should have come back --
or, sorry, he should have arrived at an financial impact
figure, which is a point I'm saying I'm allowing you to
put, you need to do it by reference to which Horizon
Issue you say he could only address properly if he did
that exercise. Is that clear?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: All right.
MR GREEN: My Lord, just before he comes back in, the
question that was put at {Day15/147:18} was:
"Might I suggest that with your experience of IT
risk analysis, you are perfectly capable of setting out
at least in broad terms a view of the extent of the
losses caused by the bugs that you have identified?"
And the suggestion in cross-examination we hadn't
done that anywhere, there are various examples. At
{D2/4/29} there is a table, and so forth.
MR JUSTICE FRASER: Mr Green, you can --
MR GREEN: I know it is a separate point.
MR JUSTICE FRASER: Mr Green, it is a separate point and,
with respect, you can wrap those points up in your
re-examination. If Mr de Garr Robinson is putting
a point which is clarified by a reference, the time at
which to do that is in re-examination.
Just before we have the witness back in, I think
I've made it quite clear I have a fairly light touch in
terms of your cross-examination. I'm neither steering
you one direction or another, I'm giving you virtually
free rein, but there is a limit to the free rein because
it has to be done by reference to the Horizon Issues
which is what the trial is about. The Horizon trial is
completely different to the individual claimants' cases
or their financial losses, for example.
MR DE GARR ROBINSON: Absolutely, my Lord.
MR JUSTICE FRASER: Right. Can we have the witness back in
please.
(In the presence of the witness)
MR DE GARR ROBINSON: Now Mr Coyne, could we first of all go
to bundle {C1/1/1}, please, which is the Horizon Issues.
I can take any of them, but I would like you to look at
Horizon Issue 1 when it comes up on the screen. I am
sure you have read it many times.
A. Yes.
Q. It begins with the words:
"To what extent was it possible or likely ..."
That's a question which is asking the experts to
explore the likelihood of bugs in Horizon causing
shortfalls in postmaster branch accounts, correct?
A. Yes.
Q. As I suggested to you I think this morning, but it may
have been after the luncheon adjournment, there are many
different ways or there are various different ways in
which an assessment could be made of extent of
likelihood, yes?
A. Yes.
Q. One of those ways that might be thought to be very
helpful in the context of this case is to consider
whether the likely extent of bugs in Horizon has any
chance of justifying any significant part of the claim
that is made by the claimants, would you accept that?
That would be a useful measure to adopt in a case of
this sort?
A. Sorry, could you put the question again? I do not think
I understand the question.
Q. Horizon Issue 1 requires the experts to consider the
extent of the -- and I'm using shorthand now --
A. Yes, that's good.
Q. I hope it is not controversial. The extent of the
likelihood of bugs in Horizon causing shortfalls in
branch accounts.
A. Yes.
Q. And I'm suggesting to you that one useful yardstick for
measuring extent is whether the likelihood in this case
is of any sort which could begin to justify the claims
that these proceedings are designed to decide.
A. Yes.
Q. And do you accept that that could be a useful yardstick
for measuring extent in the context of this case?
A. I can see how it might be one of the contenders for
that, yes.
Q. Thank you. Now you know, because Dr Worden said so in
his first joint statement, that Dr Worden was going to
look at extent in that kind of way, yes?
A. Yes.
Q. He was going to look at financial impact?
A. Mm.
Q. And see whether the likely financial impact of bugs,
which there were likely to exist, would have any chance
of justifying the sort of claim, the sort of assertions
that are being made in the context of these overall
proceedings?
A. Yes.
Q. So you saw that he was going to do that and you have
refrained from doing that, correct?
A. Yes.
Q. What I suggested to you before you very kindly stepped
out was you could have done that. You could, using your
skills as an IT risk analyst, you could have, by
reference to the KELs and the PEAKs that you had
identified, formed an assessment as to the likely
financial impact in each of the instances that you had
identified?
A. Yes, I could. If I could please answer that by way of
illustration to the problem with that approach.
Q. Please do.
A. We will often see a bug, error or defect with a very
wide range of impacts and the impact is typically
whatever the counter was doing at that point in time.
So if the counter was doing a foreign currency
transaction for just £50 and something goes wrong, the
discrepancy may be £50.
By knowing that there is a bug, error or defect in
the Horizon system that leads to problems with foreign
currencies, you can't then say it is only a £50 defect
because that isn't incorrect. If another person was to
be subject to that defect and they were doing a £10,000
foreign currency transaction, they would likely have
that same level of defect.
Now that's an illustration to say you can't value
bugs and their potential impact by looking at what has
happened historically. You can't value it in that way.
Q. But what you can do is form an estimate having regard to
the totality of the PEAKs that you have seen, can't you?
A. But it is a fundamentally flawed approach. If you have
seen three branches that have had an impact because they
were doing three foreign currency transactions, a £20,
a £50 and a £100, but then there is a fourth person that
believes that they have been subjected to that but that
isn't recorded, you can't simply look at the three where
it has been recorded and say the fourth couldn't
possibly have occurred because we know there is a defect
there.
Q. I'm not suggesting that you could arrive at a certain
conclusion of an absolute cast iron number, but I repeat
my question. Can't you form an estimate having regard
to the totality of the PEAKs that you have seen?
A. Yes, but your estimate would have to be based on the
three people where it has been recorded to have
occurred, so you would say £20, £30 and £50, and the
best you could possibly do is come up with an average of
that, and you would say that the value of that defect is
whatever that is.
Q. There is another way that you could do it, isn't there,
which is that you could look at the three bugs, the
receipts and payments mismatch, the suspense account bug
and Callendar Square, the ones that have been thoroughly
investigated, and you could form inferences from the
scale of those bugs, yes? Would that be reasonable?
A. For those types of bugs, potentially yes.
Q. Those are quite large bugs, aren't they? They are not
small bugs in the scheme of things. That's why they
were identified in the letter, because these were major
bugs of which even Post Office was aware?
A. Yes. And carrying on from the one we were not told
about until later, the Dalmellington one, there were
some which were only pounds, just a few pounds, and
I think there was at least one that was £25,000.
Q. But just fixing our attention for the moment on those
three bugs, would you accept that the evidence indicates
that altogether the total financial impact of those
three bugs is no greater than £100,000. Do you agree
with that?
A. No, I haven't done that so I would not know whether that
was right or close to right.
Q. You are aware of the calculations that were made by
Fujitsu and the documents setting out the financial
impact of those three bugs, and you are aware, aren't
you, that that calculation has resulted in a figure that
is less than £100,000? Would you not accept that for
the purposes of forming an estimate and scaling up from
some examples, it would be useful to take that kind of
figure as an example of sizeable bugs and start doing
calculations on the basis of that sort of figure?
A. No, I don't accept that that's --
Q. Do you have any evidence to suggest that the financial
impact of those bugs was more than £100,000?
A. I don't know. Looking at Dalmellington there was
a £25,000 in there, but I don't know what the outcome of
that was, how that was fixed.
Q. Do you not accept -- sorry, you don't know -- you just
made a point about Dalmellington. You don't know how
Dalmellington was fixed?
A. The document talks about -- I think there was only two
that they didn't know how it was fixed. The majority of
them had been fixed by some form of correction to --
Q. All but -- you will remember there are two Dalmellington
documents, the first one covered -- identified 118
branches affected and dealt with 114 of them?
A. Yes.
Q. And as it happens all of those branches had been
actually made good already because of the
countermeasures that existed in the Horizon system, yes?
A. Yes.
Q. So of the 114 branches that were affected by the
Dalmellington bug, in fact there was no lasting impact
on any of those 114 branches, was there?
A. I think there was two that Fujitsu wasn't aware of.
Q. I have asked you about the 114. You are trying to talk
about the other four, aren't you?
A. Yes. They were corrected, yes.
Q. So we can lay the 114 to one side, because the answer to
the question: what was the lasting impact of the
Dalmellington bug on those 114 branches? The answer is
zero, correct?
A. Yes.
Q. So we then move to the other four branches which were
dealt with with another document, which I can tell from
your answers you are completely familiar with. There
were four branches, weren't there? Two of them appeared
to have large impacts?
A. Yes.
Q. And the other two had impacts of around £1, I think one
of them was pennies?
A. There were some very small ones.
Q. So shall we lay the pound and the penny to one side for
a moment?
A. No, because if that indicates a defect then it depends
what transaction it was doing, so we can't lay any of
them to one side.
Q. Let's talk about the other two which I think were the
two you wanted to talk about, yes?
A. Yes.
Q. Those two, it turned out, weren't examples of
the Dalmellington bug and they didn't suffer any loss,
did they? There is another document which contains
an analysis which demonstrates that, do you recall?
A. I don't recall, no.
Q. Very good. Well, let's lay those two aside. So we have
got two bugs, one of which is for about £1 and one of
which is for pennies, and we have 114 branches that were
affected, all of which were made good by the
countermeasures that existed in the system, yes? And
are you suggesting that the two branches that hadn't
been hunted down, that had a £1 deficiency and a
deficiency of two pennies, are you suggesting that it is
to be inferred that those two branches uniquely weren't
corrected by those countermeasures?
A. No, it should be the case that it all was corrected.
Q. Very good. So would you accept that in relation to the
Dalmellington bug, the overwhelming likelihood is that
that bug caused no lasting deficiencies in branch
accounts?
A. By "lasting" -- well, can you help me by saying what you
mean by "lasting"?
Q. A deficiency that wasn't made good either by the SPM
actually reversing the remming error, because of course
Dalmellington was a bug which caused people to rem in
amounts more than once when they -- which is why it
looked like human error, and why it was picked up by the
system and fixed as time went on.
A. Yes.
Q. That's why it took so long. It is one of your examples
of a bug that took a long time to identify.
A. Absolutely.
Q. But the reason why it took a long time to identify was
because it looked exactly like a human error, didn't it?
A. Right.
Q. Right. All of those instances were picked up by the
system and either the SPM himself reversed the rem in
some way and made himself good, or it was picked up by
Post Office and TCs were sent, correct?
A. Yes.
Q. So that's what I mean by saying in relation to the
Dalmellington bug there were no lasting deficiencies, no
lasting shortfalls for which SPMs were ultimately made
liable?
A. Yes, I think that is right. I think once everything was
detected everything was made good.
Q. In fact, Dalmellington is quite a good example of how
countermeasures need to be brought into account and how
it is important to look at financial impact to make
an assessment of the extent question that's raised in
Horizon Issue 1, isn't it? Because it is no good saying
118 branches were affected and some of them were
affected by large amounts, when in fact we all know that
even before the bug was detected the branches involved
were in fact made whole anyway, yes?
A. It does suggest that, but it also suggests that there
were deficiencies with the countermeasures because
I believe it was five years after the first occurrence
of the bug that the defect was finally discovered.
Q. Because, as you have already agreed, to an outside
observer it looks exactly like a human error because it
was a human error. The bug wasn't causing losses, it
was causing errors to be made and those errors were
picked up, would you agree with that?
A. No, it wasn't a human error, it was a defect of the
system. It made it look like a human error.
Q. That's for another day.
Going back to these three bugs. Do you have any
reason for thinking, any evidence to suggest, that the
receipts and payments mismatch bug, the suspense account
bug and the Callendar Square bug had a total net impact
of more than £100,000?
A. As I said previously, I have not gone through and noted
all the impacts of those so I could not give you
a number.
Q. Would you accept that the best evidence is that the loss
was under £100,000?
A. That still requires me to work out what the number is.
All I can tell you is that it would appear that the
receipts and payments mismatch, it was about 60 branch
accounts that were impacted, but without going through
and looking at the numbers I don't know.
Q. Well --
A. It was 30 per Callendar Square.
Q. Dr Worden has done that in his expert report, you
recall, yes?
A. Mm.
Q. Are you aware of any evidence to suggest that
Dr Worden's analysis is wrong? Is there any evidence to
challenge his calculations in relation to those three
bugs?
A. No. I understand the process that Dr Worden has gone
through, he has looked at the numerical values that are
recorded in the PEAKs for the branches that are
available that are recorded in there and he has added
those up, so I do not think his maths is going to be
wrong.
Q. So if we were to take those these bugs as some kind of
indication of fairly sizeable bugs that might appear in
the system, it is fair to say, isn't it, that £100,000
is quite small compared to the £19 million that's
claimed by the claimants in this case. It is less than
1%, correct?
A. Just on the pure numbers, yes.
Q. So these three bugs, which are the ones we know most
about, do not by themselves even begin to support the
claimants' case, do they?
A. But the numbers that are given are only the numbers that
are in the PEAKs, and the PEAKs only reflect where
Fujitsu have become involved and have started to
investigate the impact of those bugs from the branches
that they are aware of.
Q. So assuming that £100,000 represents a fair assessment
of the impact of those bugs, what would you say? You
would say, well, they are the tip of the iceberg. There
are many more bugs that are capable of producing the
kind of financial loss that would justify the claimants'
claim, would you say that?
A. Well, it is my position that there's many more than the
three and I have set out these here.
Q. In paragraph 3.105 of your report you said potentially
thousands, but I think you have moved from that now.
Now you are saying perhaps up to 40, yes?
A. On the logic that we went through before, yes.
Q. Well, you accepted that logic, didn't you?
A. My position as stated in the report is that there is the
potential for more.
Q. Well, I won't go back over the answers you have already
given in cross-examination, Mr Coyne.
Do you accept that 40 bugs are plainly nowhere near
enough to have caused the claimants the shortfalls that
they are seeking to recover?
A. I don't accept that position. Because the bug impacts
the transaction that would be in effect at the time, if
it was a large transaction at the time then the impact
of that bug would be a lot larger. In the alternative,
they may have experienced the bug a number of times but
on smaller transactions.
Q. Well, let's see if we can agree some steps here about
what can properly be done to scale up in this case.
Could I ask you to go to bundle {D3/1/148} at page 148.
A. Yes, I have that.
Q. This is Dr Worden's first report and he says at
paragraph 6.19:
"Over the period 2000-2018 the Post Office network
has consisted of more than 11,000 branches. The mean
number of branches in all years over the period has been
about 13560."
And he explains how the figure is derived.
"If this evidence is accepted, the number of 'branch
months' (a single branch, trading for a single month)
has been ... 3,091,680. This is the number of monthly
branch accounts that have been produced."
I believe you have agreed that figure with Dr Worden
in one of the joint statements, yes?
A. Yes.
Q. That leaves Dr Worden to formulate what he describes as
a scaling factor between on the one hand the number of
bugs on all branches over the lifetime of Horizon and
that's what he calls scope A, and on the other hand the
number of bugs on one claimants' branch in any one
month, and that scaling factor is 3 million. Do you
accept the basic logic as a starting point?
A. I don't believe I do, no.
Q. You do refer in your report, Mr Coyne, to technical
flaws in Dr Worden's analysis?
A. Yes.
Q. If you look at paragraph 620 is there a technical flaw
in what Dr Worden says there {D3/1/148}?
A. No, I don't believe so.
Q. There is no technical flaw?
A. No, if the 3 million has come from the 3 million branch
months.
Q. Then what Dr Worden has done is he has considered where
there is evidence showing the need to adjust that factor
to account for the possibility that the claimants'
branches may not be typical when compared with the
general body of sub-post office branches?
A. Yes.
Q. They might be more or less likely to be hit by bugs than
your average Post Office branch?
A. Yes.
Q. And he sees no such evidence other than in relation to
their size, do you accept that logic?
A. I don't accept that logic, no. We see from the bugs
that are reported that bugs appear to impact branches
differently and one bug may hit a branch a number of
times and only hit a handful of branches, and there
doesn't appear to be any -- well, there will be
an underlying technical reason for that but it is often
down to the way that that branch is configured or the
processes that they follow.
Q. Do you accept -- no, let me ask you this. Are you aware
of some special factor applying to the claimant branches
which marks them out as very different from the rest of
the branch network making their susceptibility to bugs
very different from the wide range of branches in the
rest of the network?
A. I'm not aware of it, no, but it would require -- in
order to look at that it would require a detailed
understanding of the particular processes of the
branches. And I think that's illustrated by what we
know of Dalmellington, that impacted -- I think one
branch was impacted five times, where there was only
a handful of branches -- I think, was it 88 that was
impacted in total?
Q. Mr Coyne, it is quite important not to get confused
between particular instances of things happening and the
law of averages. What I'm asking you about is what's
likely to happen over a large number of cases, do you
understand the difference? So of course if people are
all walking down the streets, some of them are going to
get hit by lightning. Everybody won't get hit by
lightning in the same way. It will be a very small
number of people who will be hit by lightning and
they'll usually be in particular situations when it
happens. But one can make a generalisation about the
likelihood of people being hit by lightning, do you
understand, because of the law of averages?
A. I do understand, but in that illustration it would be
very unusual for one person to be hit by lightning five
times.
Q. But it has happened. I remember, goodness gracious me,
watching a programme, I think it may have been
Blue Peter when I was a child, where precisely such a
thing had happened.
That's the point, that one has to step back from the
particular. When undertaking statistical analyses one
has to step back from the particular and look at the
broad range of consequences applying the law of large
numbers and what's conventionally known as the law of
averages. You do understand that?
A. I do understand that, yes.
Q. And are you suggesting that you are aware of any factor
relevant to the claimants' branches that means that
there's some material, significant -- that they have
some significant feature that takes them away from --
that makes them completely different from the broad
range of branches that exist in the Post Office network,
large and small?
A. No, I'm not aware of it, but my suggestion is that in
order to conduct that you should ensure that they are
representative before using the law of averages.
Q. Well, one thing that Dr Worden has done is he has
considered the size of the branches. Unlike you, and
I'm not making this by way of criticism, but he has
thought about this very question to see whether there
are any real differences between the broad range of
branches in the network and the claimant branches and he
has spotted that claimant branches tend to be smaller,
okay, in the sense that they do fewer transactions per
day on average than the average Post Office branch.
Yes?
A. Yes.
Q. He does that at paragraph 623 on page {D3/1/149} of this
document, and he reaches the conclusion that he sets out
in paragraphs 624 and 625. Could I ask you to read
those three paragraphs, please.
(Pause)
A. Yes, okay.
Q. Do you accept that these calculations that he does there
in principle? There is no technical flaw?
A. I am sure the maths is correct, but again I'm not sure
that transactions is wholly the correct unit to use.
Has it been considered what the value of those
transactions are; whilst they do half the amount, do
they do high value transactions, does that have
an impact?
Q. Isn't that brought into account by -- isn't in forming
a calculation the first question you have to ask
yourself is: how likely it is that this branch is going
to be impacted? And then you have to form an assessment
of what the size of impact is likely to be, yes?
A. Yes.
Q. At this point in the equation what Dr Worden is trying
to do is to work out how likely it is branches are going
to be affected?
A. Yes.
Q. He reasons that branches with more transactions, doing
more transactions, are statistically over a large number
of occasions more likely to be hit by a bug than
a branch doing fewer transactions and would you agree
the principle underlying that observation?
A. I think that's probably a reasonable principle. If we
look at the defects we found though, there is probably
other factors that could be brought into that.
Q. But you are not aware of any, you are not in a position
to suggest a single factor which you have any evidence
to think actually applies in relation to the claimants
as compared with the rest of the branch network?
A. I don't know the make up of the claimant, but one
example might be, do they have an outreach branch?
Q. You are aware, aren't you, how small the number of
outreach branches there is, how insignificant that is in
the context of the Post Office network, aren't you?
A. Well, it wouldn't be insignificant to the people that
are impacted by the defect and I don't know whether any
of the -- because I haven't studied the claimants,
I don't know whether any of the claimants have that or
not.
Q. What you are doing is you are speculating that some of
the claimants might have outreach branches?
A. I'm not. I'm illustrating the potential problems with
the approach that you are taking just simply using the
unit of number of transactions.
Q. Mr Coyne, what I'm suggesting to you is that, in order
to suggest that there is a marked difference in
susceptibility to bugs as between the claimants and the
general -- other Post Office branches, one needs
a reason for doing it. It is not enough to sit in
an armchair and think of possible factors where you have
no basis for knowing whether the factors apply or don't
apply.
A. Yes.
Q. What you must do is simply work with the evidence that
you have and there is no evidence to suggest that there
is any particular preponderance of outreach branches
amongst the claimants as compared with the general
Post Office network, is there?
A. No, I'm not aware of the make up of the claimants. No.
Q. So when it comes to the calculation that's set out --
where is it?
MR JUSTICE FRASER: Are you looking for the smaller than
average?
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Because it is at 6 --
MR DE GARR ROBINSON: It is at 629 on page {D3/1/150}.
Thank you my Lord.
On the basis of the evidence that we actually have
in relation to the claimant branches, the process that
Dr Worden goes to in order to arrive at a scaling factor
of 0.37, there are no technical flaws in that, are
there?
A. No.
Q. Then in his second report, and perhaps we could go to
that, it is at {D3/6/30}, it is paragraph 113, Dr Worden
alighted upon a methodology that was more accurate,
an improvement. Could I ask you to read paragraphs 113
and 114.
A. Mm. (Pause). Yes.
Q. So here he refines his approach by aggregating the size
of all claimant branches across three years for which
data is available and then comparing that to the
aggregate size of all branches across all three years
and his view is that that is a more reliable approach,
would you agree?
A. It would appear to be a more reliable approach than the
approach that was being taken for before yes.
Q. That results in an increased factor of 0.45, yes?
A. Yes.
Q. You accept that that's a better approach in principle?
A. It is a better approach than the approach that was being
taken before, yes.
Q. And do you accept that on the information of which you
are aware, a scaling factor of 0.45 is in the right
ballpark? One can speculate that there might be other
information out there producing a different result but
taking account of the information of which you are
aware, that scaling factor is in the right ballpark,
yes?
A. Scaling based on number of transactions, yes.
Q. Thank you. What that means is that because they have
fewer transactions a claimant branch is less likely to
be hit by a bug than an average branch, you accept the
logic, yes?
A. No, I don't accept that logic, no.
Q. So do you suggest there should be a different scaling
factor?
A. No, I don't accept that because they do less
transactions they are less likely to be hit.
Q. Isn't it rather like going outside -- if we go back to
the lightning analogy. If people spend most of their
time inside a building, they are much less likely to get
hit by lightning than people who spend most of their
time out in the countryside, yes?
A. Yes.
Q. Doing a transaction is a bit like going out into the
countryside, isn't it? It makes you vulnerable to the
elements, yes?
A. Yes, but it is the types of transactions.
Q. You say types of transactions, Mr Coyne. All of these
branches did a wide range of transactions?
A. They do but some will do more of a particular type of
transaction than others.
Q. That's also true of the general body of the Post Office
network?
A. Yes.
Q. If there were some really curious difference between the
kind of business done by the claimant branches and the
kind of business done by the vast -- I mean you do
accept, don't you, that the non-claimant branches in the
Post Office network go from the very small to the very
large and can do a vast range of different kinds of
business?
A. Yes.
Q. If there were some feature that marked out the claimant
branches as different from the general Post Office
network branches, do you not think we would have
identified that by now?
A. It isn't a piece of work that I have done so I wouldn't
have identified it but I don't know whether anyone else
has looked at that or not.
Q. My suggestion to you, Mr Coyne, is that you are raising
an armchair objection on the basis not that you believe
this would actually produce a different result in this
particular case, but merely as an attempt to object to
performing an estimate which it is in fact open to you
and to Dr Worden to perform?
A. My perception is that it is a flawed process because the
units, the inputs to the process I don't believe are
correct. I'm not arguing with the maths, it is the
principles behind it that I'm not happy with.
Q. Let's move on. If you are genuinely saying it is
impossible to arrive at any judgment on these matters,
if you had to make a business decision about risk and
this was the only information available to you, you
wouldn't just sit there and say you couldn't make
a decision, would you? You would perform a judgment on
the best information you have, yes?
A. Yes, I agree with that, if a decision had to be made and
there was no other information available, then I would
use the best information that was available to me.
Q. And you would build in a margin of error, wouldn't you,
to account for the possibility that there may be
unknowns out there that could throw your figures out?
A. Yes.
Q. In the way that Dr Worden has done, correct?
A. Yes.
Q. Let me ask you this, you are suggesting that
susceptibility of bugs may change depending on the kind
of business that's done. Is it your view, having regard
to your close study of the 29 bugs that are in the JS2
bug list, is it your view that those bugs are such that
there is some feature in them which makes it likely that
the claimants are going to be more or less susceptible
to them than anybody else?
A. Not with regard to claimants because as I said I have
not looked at those but there are bugs in there which do
seem to be susceptible to particular branches.
Q. Now let's go back to Dr Worden's first report.
{D3/1/150} please and paragraph 630.
A. Yes.
Q. On Dr Worden's approach:
" ... Claimants' branches, being generally smaller
than Post Office average, have fewer transactions per
month and so are less likely to be hit by a Horizon bug
in a given month."
Here he refers to his 0.37 scaling factor.
"The factor 0.37 increases the scaling factor above,
between scopes (a) (see paragraph 617.1) and (c) (617.3)
from about 3 million to about 8 million."
Yes?
A. Right, yes.
Q. You accept that logic, don't you?
A. I accept Dr Worden's mathematics based on his logic,
yes.
Q. So if you take a bug which has occurred 16 times over
the lifetime of Horizon?
A. Yes.
Q. With a mean financial impact of £1,000 and that's quite
a significant bug compared with most of the bugs you
found, would you agree?
A. It is certainly significant in its impact, yes.
Q. It is in the top five, yes?
A. Quite possibly.
Q. And then you select a claimant branch a month at random,
the chance of that bug occurring in that branch in that
month is 16 in 8 million, correct?
A. If bugs affect branches equally, yes.
Q. And that's around 2 in 1 million and you have just
accepted the logic, thank you.
And the probabilities are obviously additive. So if
there is a second similar bug, the chances become 4 in
1 million and so on. So if there are 100 bugs it is 1
in 5,000, yes?
A. But all this is predicated on accepting that bugs affect
branches equally.
Q. Well let's do this Mr Coyne, let's assume that bugs
don't affect branches equally. I presume you are not
saying it is impossible to say -- I assume you are not
saying that the claimant branches are likely to be 100
times more likely to be susceptible of bugs?
A. As I say I don't know the make up of claimant branches
so I don't know about that. All I do know is that for
the bugs that I looked at they don't appear to impact
branches equally. Dr Worden referred to a rainfall
across a field, that isn't a concept that I accept.
Q. Which is why he changed it in his second report to --
A. Lightning.
Q. Do you remember? Or maybe it was the joint statement,
I can't remember.
A. Yes.
Q. What I'm suggesting to you, Mr Coyne, is that you don't
just throw up your hands and say it is theoretically
possible that a particular claimant branch or particular
set of claimant branches may do a particular kind of
business making them more or less susceptible to bugs
than other branches. You need to have -- it is
possible, isn't it, to have a sense of what the maximum
likely impact of that phenomenon is, yes? You are not
suggesting that the claimant branch is 100 times more
likely than any other branch bearing in mind that the
rest of the Post Office network contain branches from
large to small the entire spectrum of branches that
exist in the network?
A. The way I would approach this would be possibly the way
that Fujitsu did when they were investigating
Dalmellington by way of example, in that they know it
impacted 88 different branches but a number of those
were impacted multiple times.
I would have a look at the make up of those -- the
business process that was followed in the branches that
were impacted multiple times to find out why one branch
was impacted three times and nobody else has been
impacted at all.
Once you understand what it is within that business
process, you can then see from the knowledge you have
got within the Post Office and Fujitsu who else across
the estate operates in that same way.
Q. Mr Coyne, if we were just talking about one bug that
affected a particular event or transaction, then I would
understand what you are saying. But we are not, are we?
We are talking about a whole range of bugs operating and
being triggered in a whole range of different
circumstances?
A. Yes.
Q. So we have bugs which themselves have a scatter gun
effect and we have a scatter gun of branches all over
the country, some of which peppered all over the country
are claimant branches?
A. Yes.
Q. What I'm suggesting to you is that when forming
a judgment, trying the best you can do to make
an assessment on the information available, what you are
going to do in the absence of a strong indication that
there is some factor that justifies the inference that
all of the claimant branches are very different from all
of the branches in the rest of the network, is you adopt
the sort of approach that Dr Worden has adopted.
A. It isn't an approach that I would take. I wouldn't feel
confident in undertaking that type of approach.
Q. If you were making a business decision I think you
accepted that you would form a judgment that would be
the best judgment you could on the information you had,
correct?
A. Yes. I think that is in a different scenario, isn't it?
You are making a business decision.
Q. What it shows is that it is possible to make estimates
that have some materiality and could be of use when
forming judgment about human conduct, yes?
A. Yes.
Q. That's what Dr Worden has done and the calculation he
arrives at is that, as we have said and I think you have
accepted the logic of the position, that the chance of
the bug we have discussed occurring in a claimant branch
in a particular month are 2 in a million, and if there
are 100 such bugs the chance would be 1 in 5,000. And
that's what Dr Worden says at paragraph 634 on page 151.
Again do you accept the logic?
A. I accept the maths, yes.
Q. So for a bug to have even a 1 in 10 chance of hitting
one claimant branch in one month there would need to be
tens of thousands of such bugs, wouldn't there, yes?
A. Based on those mathematics, yes.
Q. Dr Worden says 50,000 in his first report but this
becomes 40,000 in his supplemental report because he has
chosen a different scaling factor, correct?
A. Yes.
Q. If it were to be a 5 in 10 chance there would need to be
200,000 bugs, correct?
A. That's what he says.
Q. If one were to assume that the scaling factor were very
different, you would still need an enormous number. You
would still need thousands of bugs, wouldn't you, to
even begin to have a chance of justifying the sort of
claim that is being made in this case. It is a matter
of commonsense, isn't it?
A. All I'm doing here is effectively just confirming
Dr Worden's maths, but I don't accept the process.
Q. You don't accept the process because you are seeking to
suggest there might be some factor you can't identify
which means that the claimant branches have a different
susceptibility to bugs when doing a transaction than the
branches in the rest of the Post Office network, yes?
A. Yes, quite possibly.
Q. What I'm suggesting to you, Mr Worden --
A. Coyne.
Q. -- is that even if you factored in some enormous number,
a substantial number, assuming the claimants were much
more likely than your average Post Office branch to be
susceptible to bugs, it would still be in the thousands.
There would still need to be thousands of those bugs
wouldn't there in order to justify anything like the
claim made by the claimants.
A. I don't have the detail of the claims by the claimants.
So I don't know the make up of them.
Q. Do you have any evidence that causes you think that
there are in fact that scale of bugs in Horizon,
thousands of bugs in Horizon? I'm thinking as a result
of the evidence you gave after lunch you don't, do you?
A. I don't -- there is the potential for that many in
Horizon but I think it will be likely somewhere lower
than that.
Q. Mr Coyne, the overwhelming likelihood is that there
aren't more than 40 bugs of the sort that you have
identified in Horizon, correct?
A. Yes, but what you have got to remember is each of those
bugs can have an impact on multiple branch accounts. It
is not just one bug, one impact.
Q. So are you suggesting that some of those bugs have
massive impact? Remember, we are not talking about bugs
that affect only the claimant branches. We are talking
about bugs that are in operation over the entire
Post Office network.
A. Yes.
Q. So on any view those bug impacts -- the total bug
impacts is going to be very, very much greater than the
specific impact that might affect the claimants, yes?
A. Yes.
Q. So the total impact of the kind of bug you are
suggesting, to justify the £19 million claim just made
by the claimants alone, the total impact of the kind of
bug you are hypothesising would have to be vast,
wouldn't it, in the tens and tens of millions?
A. If we are using the law of averages to show that it has
impacted everybody equally rather than just impacting
the claimants' branches, yes.
Q. I see. You are now suggesting that there might be bugs
which have only affected the claimants and haven't
affected the wider Post Office network, is that what you
are claiming?
A. I'm saying it is entirely possible because we know from
the bugs that have actually happened that they have only
impacted a small number of branches.
Q. Is it really entirely possible though, Mr Coyne? You
are hypothesising a bug which has had many, many, many
effects in order to justify the suggestion that it has
generated a large number of losses. That's what we are
talking about?
A. Yes.
Q. Those bugs occur at branches because of factors that you
are not prepared yet to identify, yes?
A. I haven't been given the information to enable me to
identify.
Q. You don't have a specific bug in mind which has
a particular feature which means that it only affects
certain kinds of branches. You are not telling me that.
You are saying that it is possible there might be such
a bug?
A. Yes.
Q. With this theoretical bug you are suggesting it is quite
possible that it could affect just the claimants'
branches and not affect the branches in the wider Post
Office network. Is that really your view? Do you
really think that is a likely outcome?
A. It may well have affected other branches in the branch
network.
Q. That's my point, Mr Coyne. It is all very well to say
"I don't know, it is a really difficult judgment to
make", but there are certain features which are just
matters of commonsense. What I'm suggesting to you is
that, bearing in mind the claimants represent such
a small fraction of the total Post Office network over a
period of 20 years, it stands to reason as night follows
day that if there are bugs which justify their claims
those bugs would also have incurred losses in the wider
Post Office network. Would you accept that?
A. Yes.
Q. Would you accept, therefore, that the wider losses that
would have been caused in the Post Office network would
be substantially greater than the £19 million --
A. That's likely, yes.
Q. Yet nowhere do we see any sign of any bugs of the sort
of scale that would be necessary to justify 100 billion,
200 billion of losses caused by these bugs. Do you not
find that surprising? Do you not draw any inferences
from that fact, Mr Coyne?
A. But there are bugs that we have found that have impacted
many branches. So what if there is another -- I keep
using the example of Dalmellington -- but what if there
is another Dalmellington that has impacted 88?
Q. We have talked about Dalmellington and we have agreed
I think that there is no net lasting impact from that
bug.
A. But that was only cleared up in its entirety after five
years.
Q. So you are talking about a bug which affects 88
branches?
A. A number of which were impacted on multiple occasions.
Q. So was it 114 impacts on 88 branches, is that right?
A. I think that is right.
Q. You are suggesting that that phenomenon would justify
the conclusion that there doesn't need to be thousands
of bugs in order to justify the claimants' claim, is
that right?
A. What I'm saying is using the profile of that type of bug
illustrates how there can be a large number of branches
impacted for a relatively long amount of time before it
is dealt with and with a large range of branch impacts.
Q. Mr Coyne, so far you have found 29 bugs and you have
very helpfully accepted that there are unlikely to be
more than 40 bugs if one were to read each and every
document, for which I'm obliged.
The supposition is that 40 bugs are capable of
causing £19 million worth of loss in the claimant
branches without causing any greater loss in the Post
Office network. Is that what you are suggesting? Are
you suggesting that's a viable scenario which might
explain what's happened?
A. You are asking me questions about the actual claim and
I haven't studied the claim. I'm aware of that headline
number that you are talking about but I have not looked
at the detail of the claim.
Q. I see.
A. So there is two possible scenarios. There is probably
many more. But that it has impacted the wider branch
network as well or that it has only impacted the
branches which are claimants'.
Q. Sorry could you say that last point again? I didn't
hear.
A. What I'm saying is that there is a range of scenarios
that go from additional bugs or the bugs that we found
impacting just the claimant branches, is the start of
the spectrum, up to bugs, errors and defects not only
affecting the claimant branches but the wider Horizon
estate.
Q. I suggest to you, and my Lord bearing in mind the speed
with which this cross-examination has come, with
your Lordship's indulgence I'm not proposing to put
Dr Worden's section 8.7 analysis to him unless you
indicate to me --
MR JUSTICE FRASER: To Mr Coyne?
MR DE GARR ROBINSON: Yes, unless your Lordship indicates
that I really need to.
MR JUSTICE FRASER: No, it is entirely up to you. It can't
be said against you, I don't think, if you don't put it,
and as I made clear at the pre-trial review and in a
time limited trial generally a point like that would be
ambitious -- are you concerned that if you don't go
through it chapter and verse it will be said it hasn't
been properly put?
MR DE GARR ROBINSON: Yes. My Lord, important points should
be put in my respectful submission.
MR JUSTICE FRASER: Yes, but this is really a methodological
difference, isn't it? So I'm not going to require you
to put every single --
MR DE GARR ROBINSON: I'm obliged my Lord.
MR JUSTICE FRASER: Is your intention literally not to put
any of it or just to put two or three headline points or
do you want to think about it?
MR DE GARR ROBINSON: Would your Lordship give me one
moment?
MR JUSTICE FRASER: Of course.
MR DE GARR ROBINSON: My Lord, I suspect that I will not be
putting any questions but I'm going to take instructions
overnight to see whether there might be some very short
number of points.
MR JUSTICE FRASER: Mr de Garr Robinson that is entirely
understood and entirely sensible.
MR DE GARR ROBINSON: My Lord, unless you have any further
points this may be a convenient moment.
MR JUSTICE FRASER: All right. That's fine. I mean just to
be clear Mr de Garr Robinson to make it -- well, to try
and help you when you take instructions on the way you
might want to or not to deal with 8.7, one way which is
often adopted is simply to boil it down to two or three
propositions and deal with it like that. But I'm not
saying you have to do that because I think both the
experts have been quite clear about the different way in
which they have and haven't approached the exercise.
I don't know if that's helpful.
MR DE GARR ROBINSON: It is very helpful my Lord and I'm
obliged to your Lordship.
MR JUSTICE FRASER: I have one very minor housekeeping point
which may sound like a joke but isn't. Yesterday was
Day 14 and today is Day 15, what happened to Day 13,
does anyone know?
MR DE GARR ROBINSON: No idea. I was wondering that.
I think it is Day 11 actually.
MR JUSTICE FRASER: It is definitely not Day 11.
MR GREEN: My Lord, wasn't the handing down of the recusal
judgment which technically was counted as a Horizon
day --
MR JUSTICE FRASER: Is that what --
MR GREEN: I think it may have, I will check --
MR JUSTICE FRASER: I'm not suggesting we re-number at all,
as long as we are all working on the same numbering I do
not think it matters. All right. Thank you very much.
So Mr Coyne you are going to come back tomorrow.
A. Yes.
MR JUSTICE FRASER: Can I just raise one point about timing
for both of you to think about. Ordinarily in any time
limited trial, which almost all the trials in this
building, certainly in the QB part of this building are
time limited, re-examination is kept to a very, very
minimum and I think I did tell you Mr de Garr Robinson
at the pre-trial review that although at that stage we
were looking at two days cross-examination of this
witness, which was then changed to four, that you would
have the vast bulk of that time.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Just in terms of the court staff, not
for my convenience, can you just liaise between
yourselves about approximately the time you will finish
on Friday afternoon. I'm not making any indications one
way or the other, but it would just be sensible for you
to have a dialogue because Mr Green today I think has
threatened re-examination on at least two and maybe more
occasions.
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: So tomorrow 10.30 Mr de Garr Robinson?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: 10.30 tomorrow morning. Thank you very
much.
(4.25 pm)
(The court adjourned until 10.30 am on Thursday,
6 June 2019)
(10.30 am)
MR JASON PETER COYNE (continued)
Cross-examination by MR DE GARR ROBINSON (continued)
MR JUSTICE FRASER: Mr de Garr Robinson, just two things
before we start.
Judgment number 5, which I know you are not
interested or involved in, went out this morning. The
embargo doesn't really apply because it is detailed
reasons for decisions which were made public last week,
but I would like a list of typographic errors by
6 o'clock tomorrow.
And in the interests of transparency, the learned
usher just told me, just before I came in, that he had
been given a message by the witness to give me, and
I said I didn't want to hear the message and I'm not to
take messages from witnesses in that way or indeed in
any way, but I wanted both parties to know that that
exchange had taken place.
MR DE GARR ROBINSON: My Lord, thank you for letting us
know.
MR JUSTICE FRASER: All right.
MR DE GARR ROBINSON: Would your Lordship like to
investigate that question?
MR JUSTICE FRASER: No, I don't intend to do anything at all
but I wanted both of you to be told straightaway.
MR DE GARR ROBINSON: I understand.
Mr Coyne, good morning.
A. Morning.
Q. Yesterday I'm sorry to say we gave you some homework.
A. Yes.
Q. We discussed your claim that bugs are often deferred or
not dealt with at all on a cost benefit basis, do you
remember making that claim?
A. I do.
Q. And I asked you whether you can think of any PEAK other
than the particular PEAK we were looking at that shows
that happening.
A. Yes.
Q. Have you been able to find the handful or so of PEAKs
you referred to yesterday?
A. Yes, I have.
Q. I'm very grateful. Do you have that on a piece of
paper?
A. I do indeed.
Q. Perhaps the sensible thing to do would be at the break
if you could give me the piece of paper and we can copy
it and get it circulated to both sides.
A. Yes.
Q. Would that be acceptable?
A. Yes, it would.
Q. Thank you.
Yesterday afternoon we were going through some
documents you rely on in your reports with a view to
seeing whether they justified the claims that you made
about them. These are some example documents. I'm
going to do a few more but I'm going to do them as
quickly as I possibly can. First of all can I ask you
to look at paragraph 5.195 of your first report, and for
the transcript it is at {D2/1/107}
A. Yes.
Q. You will see you say there:
"The Post Office cash management proposals contained
in a report dated 4 August 2017 suggests that they were
actively considering ways to improve processes impacting
on many of the issues raised above. It is my opinion
that, whilst the Post Office was looking at ways to
improve cash management, it is also indicative that the
system was generally far from perfect and there existed
a real risk of bugs/errors/defects adversely impacting
on branch accounts despite the processes in place at the
time to prevent this."
A. Yes.
Q. Mr Coyne, if we could go very quickly to that document.
It is at {F/1673/1}. It would take too long for me to
read it out loud. Perhaps I could ask you, Mr Coyne, to
read the first page quickly to yourself.
(Pause)
A. Yes, I have read that.
Q. Then over the page {F/1673/2} we can see "What we
propose to do and why", about a third of the way down
the page:
"We proposed to deliver the following initiatives
through this business case."
First of all there is a reduction of branch cash
holdings by circa £80 million. Perhaps I can ask you to
read that paragraph 1(a). (Pause)
A. Yes.
Q. Then 1(b) is "Improving branch cash declarations" where
they say:
"In conjunction with the above activity, a more
strategic solution will be delivered to reduce surplus
cash in the branch network by £80m (£60m in Sterling and
£20m in foreign currencies) through mandatory and
accurate cash declarations in branch."
A. Yes.
Q. That's talking about trying to get postmasters, when
they make their cash declarations which they have to do
everyday, to make them more accurate, to make sure they
get them right.
A. Yes.
Q. That's explained in the following paragraphs (i), (ii),
"Proactively manage non-conformance" and "Changing time
of cash declaration submission", do you see that?
A. Yes.
Q. Then over the page {F/1673/3}, "Improving operational
design, training and communications to Postmasters to
ensure cash declaration conformance." It is all about
getting the SPMs to do what they already do but to get
them to do it better.
A. Yes.
Q. Then if we go over to page {F/1673/9} of the document
there is what is called a "Benefits Map". It is a table
with a series of solutions on the left-hand side,
a series of impacts and a series of benefits in
different columns along the page.
A. Yes.
Q. Picking it up so we can see the sort of thing it is
dealing with, at page {F/1673/10}, the second box down:
Discrepancy management – at the moment there is a
lack of visibility of any inaccurate cash declaration to
the Postmaster of one of his stock units. If we deliver
a technical change to the cash declaration process this
will send any discrepancy amount to the Local Suspense
account which will give the Postmaster immediate
visibility and will allow faster
corrections/investigations ..."
A. Yes.
Q. What they are suggesting is that the information that
a postmaster gets when doing a cash declaration, some
further information should be added which is immediately
added to his or her suspense account which then impels
him or her to look into the matter more closely, do you
see that?
A. Yes.
Q. That is essentially what I get from this document. It
might be my fault. What I would like to ask you is,
going back to your statement at paragraph 5.195, why is
it you say that this document is indicative that:
"... there existed a real risk of bugs ... adversely
impacting on branch accounts despite the processes in
place at the time to prevent this."
{D2/1/107}
A. Could I have the document back up, please?
Q. Of course. It is {F/1673/10}.
A. Sorry, could we go to the first page {F/1673/1} of that
document. Then go on to the next, please {F/1673/2}.
Onto the next, please {F/1673/3}. And onto the next,
please {F/1673/4}. And onto the next, please
{F/1673/5}. And onto the next, please {F/1673/6}. Next
one, please {F/1673/7}. And the next one, please
{F/1673/8}. Next one, please {F/1673/9} and again,
please {F/1673/10} and the next one, please {F/1673/11}.
And the next one please {F/1673/12}. And the next
one please {F/1673/13}. Sorry next one, please
{F/1673/14}. And again, please {F/1673/15}. Next one,
please {F/163/16} and again, please {F/1673/17} and
again, please {F/1673/18}.
That's the end of that document, is it?
Q. Yes. So can you tell me what it is you saw in this
document which allowed you to express the opinion that
it indicates that there existed a real risk of bugs
adversely impacting on branch accounts?
A. It is incorrect to find that from that document.
Q. Mr Coyne, you have already accepted, and very fairly and
properly accepted, that as an expert it is important
when relying on documents, particularly in
a document-heavy case where many, many documents are
relied on in a report, you have already accepted the
great importance of making sure any summary of the
document, any explanation as to what the document means
or what it indicates, it is very important to get that
right to assist the court.
You do seem to be looking for problems in documents
which don't support the suggestion that those problems
exist. Would you accept that?
A. No, I don't. It might be the case that we have
an incorrect reference, there was an incorrect reference
yesterday, but I don't think so in this case because the
context of the paragraph appears to relate to this
document.
Q. You are simply citing documents that don't support the
claims you make about them, aren't you, in this report?
A. This particular example, there appears to be a mistake
here, yes.
Q. Let's move down the page to paragraph 5.198 where you
say -- this is in your report at {D2/1/107}:
"It is clear that in some instances it is not always
apparent whether recurring discrepancies were as a
result of system bugs or the Subpostmaster's own
actions, or other things beyond the control of the
subpostmaster."
Then you have two footnotes {D2/1/108}. Then:
"However the fact that the SSC support team were
unable to assist or identify the root cause does
undermine the credibility of Horizon itself."
Correct me if I'm wrong, but I think what you are
suggesting there is that the two documents you refer to
in the footnote as examples of it not being apparent
whether recurring discrepancies were a result of bugs or
human error, you are saying those documents itself
support the idea that the support team were unable to
identify root causes and in a way that undermines the
credibility of Horizon itself?
A. There is a number of documents, and I agreed with
Dr Worden that often the bugs, errors or defects would
appear as if they were mistakes made by the
subpostmasters.
Q. You say "often". We need to be careful with "often".
A. There are a number of occurrences.
Q. Let's be clear about scale, shall we? I think you have
agreed with Dr Worden that over the lifetime of Horizon
there were something like 3 million branch accounts
generated, yes?
A. Yes.
Q. And I'm taking a branch account as a monthly branch
account. I'm simplifying because of course between 1999
and 2005 they were weekly accounts, weren't they, but
let's just treat them as monthly accounts. So there
were 3 million branch accounts that were produced during
the course of this period and if an error is made, one
error is made, that means it has a branch account
effect, that means that there is a 1 in 3 million chance
of that error affecting a branch account, yes?
A. It is unlikely that one error within the system would
only affect one single branch account.
Q. We will talk about that. It depends on the nature of
the error.
A. It does indeed.
Q. You can't say that, can you, before you know the nature
of the error?
A. No, you can't say that. That's why you need to be
careful.
Q. So when you say this often happened, it gives
an impression, doesn't it? It gives an impression that
suddenly large numbers -- a significant portion of
branch accounts may be unreliable because of something
happening. But if you are talking about a handful of
cases or if you are talking about 20 cases, you are
still only talking about 20 in 3 million. You are
talking about 2 in 300,000. You are talking about a 1
in 50,000 chance, aren't you?
A. I wasn't talking about branch accounts, I was talking
about bugs, errors and defects. Bugs, errors and
defects often appear as if it was a user error rather
than a defect of Horizon and it was that that Dr Worden
and I agreed on.
Q. What we are talking about is what undermines the
credibility of Horizon itself.
A. Yes.
Q. What I'm suggesting to you is that if there were a dozen
examples of something happening, given the number of
branch accounts that are in existence, and assuming each
of those examples only had one impact, that doesn't
undermine the credibility of Horizon itself, does it?
A. Well, it needs to be considered because it is unlikely
that it would only have an impact on one branch account.
Sorry, let me finish, please. If it is a defect in the
system, the majority of the users, subpostmaster users,
were using that system. So it would be unlikely that it
only impacted one.
Q. I'm very interested in your answer, Mr Coyne, because in
my question I was quite careful to indicate that I was
asking about one error that had one impact, but you
immediately flicked to a situation where you were able
to say, well, there are likely to have been more impacts
in circumstances where I wasn't even specifying what the
error was other than that it didn't have multiple
impacts, and could I suggest to you that you did that
because you have a view, you have a world view, you have
a desire to maximise the impression given of any error
that you identify, do you think that's fair?
A. No, I don't think that's fair. I understood the
question you were putting to me was about this system
rather than a hypothetical scenario where one bug only
impacts one account.
Q. Let's talk about a remote access instance. The SSC on
one occasion does some remote access which affects one
branch. Do you accept that would only have one branch
impact?
A. Yes.
Q. So if you find one example of remote access which has
one branch impact and you don't know which branch is
affected, and you look at the totality of the branches
in the network and the totality of the monthly accounts
that have been generated in the network over 20 years,
you would have -- if you picked a branch account at
random, you would have a 1 in 3 million chance of
finding a branch that was affected by that remote
access?
A. If that remote access was done correctly it would only
impact one branch, yes.
Q. Thank you. Going back to this example, and if I'm wrong
please tell me because it will save some time. There
are two footnotes, do you see, and they are call logs.
Do you see that? And they are footnotes which are given
as instances where it is not always apparent whether
recurring discrepancies were as a result of system bugs
or the SPM's own action, do you see?
A. Mm.
Q. You then go on to say the fact that the SSC support team
were unable to assist or identify the root cause
undermines the credibility of Horizon. Are you
suggesting that if I look at those logs I will see
something to justify the inference that you make here --
that you appear to make here -- that the credibility of
Horizon itself is undermined? {D2/1/108}
A. The way that the reference is introduced here is "or
other things beyond the control of the Subpostmaster".
{D2/1/107}
Q. I'm sorry? I'm not following you and it is my fault,
not yours.
A. Sorry, I have just flicked back to read what was before.
Q. Yes.
A. So these are discrepancies that were:
"... as a result of systems bugs or the
Subpostmaster's own actions, or ... things beyond the
control of the Subpostmaster."
And they should be referenced in these --
Q. Right. So these logs indicate that things are happening
which are either the result of system bugs or a result
of SPM action or are beyond the control of the SPM, yes?
A. Yes.
Q. And do you infer from those examples -- is what you then
say in the last sentence an inference from that? Do you
say that those examples show -- well, those examples
undermine the credibility of Horizon itself? I think
you would say yes?
A. We are in the section of my report here which is
"Opinion Summary", so it is summarising the section
that's come before it.
Q. Yes, but you give these two examples here and I would
have thought you did that for a reason.
A. It is likely that these are two documents that relate to
this section, but if there was a footnote that I have
already referred to in the section I wouldn't reference
it again here.
Q. Yes. So you are suggesting that if we look at the
footnote we will see something that undermines the
credibility of Horizon itself, is that right?
A. Yes.
Q. Let's have a look then. Could we go to {F/333/1}
please. This is a call log. I think it relates to
Mrs Misra's branch and the date is -- it was opened on
23rd February 2006. So far as I can tell, the relevant
passage that you would rely on is at the bottom of the
page where it says:
"OTI close Monday 27 February."
Do you see that?
MR JUSTICE FRASER: I think we are going to need to increase
the size.
MR DE GARR ROBINSON: Yes, it is very small. Could we go to
the bottom and increase the size, please?
MR JUSTICE FRASER: I think for present purposes that's
probably magnified enough at least so I can read it.
MR DE GARR ROBINSON: Let me read it:
"No transaction date and time was provided for this
action using current date and time. Update by Anne
Chambers: Category 94 -- Final -- Advice and guidance
given."
Stopping there. We have seen a lot of
Anne Chambers' work, haven't we?
A. Yes, we have.
Q. My impression is that she is quite a professional
operator. Would that be your impression as well or
would you disagree with that?
A. I don't think I could give a view on that.
Q. Very good.
"I have checked very carefully and can see no
indication that the continuing discrepancies are due to
a system problem. I have not been able to pin down
discrepancies to individual days or stock units because
the branch does not seem to be operating in a
particularly organised manner. In particular I have
noted 1. There are 6 stock units for this 3 counter
branch, which seems a bit excessive. 2. The loss in
euros in TP 9 appears genuine - the declared quantity
was 4000 fewer than the system expected. It is not clear
from the information above whether anyone found out why
this happened (there were several rem outs, and a rem
in, on 23rd Dec - did the pouches contain the declared
number of euros?). 3. Stock is sometimes transferred
out of a stock unit where it is not held. In particular
there were several transfers out of stock unit SMI in TP
10. At the end of the period the stock figures were
corrected back up to zero via Adjust Stock. This gave a
gain of over £2000 in SMI. Equivalent negative stock
adjusts in AA gave a corresponding loss in AA. 4. I am
not confident that the stock declarations are always
correct e.g. at the end of TP 9 there was a declared
holding of 5 £20 PO phonecards in the branch, then a few
days later 20 were transferred from one SU to another.
None were remmed in until a week after that. 5. The
branch had declared 27 £20 Argos vouchers at the end of
TP 9. Branches have now been instructed to rem out this
product; they remmed out 17 and adjusted stock to
account for the remaining 10 (so did they really only
have 17 to start with?). This has correctly caused a
loss of £200 in SU AA. 6. Lottery instants sales are
entered onto the system as a single transaction every 10
days or so. 7. Stock units SMI and AA rolled over with
non-zero cheque holding. This may be to do with how the
discrepancies have been accounted for but I do not
really understand this (the total is greater than the
sum of the branch adjustments for TP 9 and 10). I
recommend that this call is passed back to NBSC tier 2
for further investigation, since there is no evidence
that the discrepancies are being caused by a system
problem. If you want the above information in an email,
let me know."
Now, Mr Coyne, what I would like to suggest to you
is that what that shows is that Anne Chambers did a very
thorough job, went through the figures very carefully,
saw there was a branch that was operating in some sort
of chaos, forms the clear view that there's no system
problem, but says: there are these questions, it should
go back to NBSC to investigate. And I would like to ask
you why you think that that story there, told in that
box, does undermine the credibility of Horizon itself?
A. I think it is that when this call is later advanced, it
is discovered that there was a system problem.
Q. Perhaps you would go to the second page because if
that's the case I have missed it but I'm happy to be
corrected. {F/333/2}. What I get is what's in the
final entry, Mr Coyne:
"Call close by David Dawe: pm was getting
discrepancy's ssc have investigated and adviced that the
NBSC take a 2nd look at this as the office stock units
appear to be in a mess."
But please don't let me stop you reading the whole
thing.
(Pause)
A. But what we do see from that is that Anne Chambers isn't
able to say what has actually happened with the
discrepancy that has been seen. She is unable to
determine whether it is the user that has caused that or
whether there is a potential problem with the system.
Q. So let me get this straight. Let me give you
a hypothetical case. A branch is being run in a mess
and things are being reported that are wrong. So things
are being remmed out from a particular stock unit that
aren't in the stock unit, they are declaring cash that
they don't have, they are declaring they have stock that
no longer exists, there are inconsistent declarations of
stock on different days. It is a mess. Clearly lots of
erroneous figures are being entered into the system.
There is no way that someone in the SSC is going to be
able to correct those errors, only the subpostmaster
will know what the true position is on the ground.
Correct?
A. Yes.
Q. So in that situation, the SSC comes in and looks to see
if there's a system problem and they can't find one.
Now are you saying -- that scenario is inevitable, isn't
it? It doesn't matter how good the system would be; you
could have the computer from the Star Trek Enterprise.
The point is that in that scenario the SSC would not be
able to say that this has happened or that has happened,
because the data they have got is too chaotic, correct?
A. Yes.
Q. So I would like to suggest to you, Mr Coyne, that the
sense one gets from these logs is that's what was
happening with this branch.
A. Yes.
Q. So why do you say that this log undermines the
credibility of Horizon itself?
A. No, I agree that this log in itself doesn't.
Q. I don't want to take any time up, but are you suggesting
that the second log, if I go to the second log, I'm
perfectly happy to do it, would show a different
picture?
A. I would have to check it. I believe it shouldn't but
I'm happy to go to it.
Q. I do not think I have time. Lets move on.
What I would like to do now is to talk about
a document on which you have built one of the major
themes in both your reports, which is the reliability of
Credence, and as we know that is one of the management
information systems used by Post Office. It is the
Post Office system, isn't it? And it uses it for
various purposes, including it is one of the systems it
uses when deciding whether to issue a transaction
correction, yes?
A. Yes.
Q. One of the themes in your reports is that it shouldn't
be used for the purpose of making those decisions, ARQ
data actually should be used, is that right?
A. Yes.
Q. That is your considered view?
A. Yes.
Q. And on that basis you rely on a document which is
called -- which has become called the Helen Rose report,
I'm not sure it is a report, but it is a five-page
document produced by Helen Rose who was a fraud analyst
at the Post Office in June 2013.
Before we go to it, can we just agree the basic
facts. I presume you looked at the report and the
associated facts quite carefully so you are familiar
with the case?
A. Yes.
Q. It related to an incident at the Lepton branch of which
the SPM was a Mr Armstrong, is that right?
A. Mm.
Q. A bill payment transaction had failed at his branch when
the system went down, correct?
A. Yes.
Q. And it was a cancellable transaction, correct?
A. Yes.
Q. So he completed the transaction, he took money from the
customer, and he did that via -- the customer had
actually got cash out from a Lloyds TSB cash withdrawal
but that's by the by because that didn't fail. So he
completed the transaction and he took money from the
customer. Because the system went down he had to log
back in, and when he logged back in the recovery process
automatically reversed the cancellable transaction,
correct?
A. Yes.
Q. And that's how the system should operate with
cancellable transactions, correct?
A. Yes.
Q. And that left him with a surplus in his branch, didn't
it?
A. Likely, yes.
Q. Because he had been given cash by the customer which was
to be used to pay -- I think it was a phonecard or
something like that. It was a BT bill payment, sorry.
But of course because the transaction had failed the BT
bill payment was not made, yes?
A. Well, it depends at what point the counter failed and
that's what the recovery process does, it determines how
far the transaction got.
Q. Yes. When you agreed with me a moment ago that it was
a cancellable transaction, what that means is -- there
are two kinds of transactions, aren't there? There is a
recoverable transaction and the opposite of
a recoverable transaction is a cancellable transaction,
correct?
A. It is often called nonrecoverable.
Q. But the technical name is cancellable?
A. Yes.
Q. Could you explain what the difference is between those
two transactions, why a transaction is cancellable or
recoverable?
A. It depends on whether it requires an interaction with
any of the banking organisations or not. Often with
things like credit cards or debit card transactions
a call will be placed to the bank to check the money and
then if the process continues all the way to the end the
money being requested. If there is a failure in the
counter at some point through that process then Horizon
has got to understand whereabouts it failed and then
effectively unwind that process.
Q. The difference is where a third party system is
involved, isn't it?
A. A third party system, yes.
Q. So where you are doing a transaction at the counter
there are a number of steps you take and if the
transaction involves, I don't know, a payment being made
from a bank, during the course of typing in the
transaction hundreds of messages are passing back and
forth both to the BRDB to record the nature of the
transaction that's being keyed in and also to the
financial institution, and the two institutions marry up
and the financial institution says I recognise you, and
the counter says I want you to make this payment, and
the financial institution says I accept it, and so on.
A. Yes.
Q. Then at the end of that process the postmaster closes
the stack.
A. Yes.
Q. He enters the transaction into the system. I think the
technical term is he commits the basket to the system?
A. Yes.
Q. And that's the moment at which the basket enters his
branch accounts, is that correct?
A. Yes.
Q. Everything I have said so far is correct, is it?
A. It is, yes.
Q. Thank you. The problem is that inevitably the moment at
which the transaction is committed to -- the basket is
committed to the system is different in time from the
moment at which the payment instruction is accepted by
the bank, yes?
A. Yes.
Q. So what happens, in a relatively rare situation you can
have the bank accepting an instruction to make a payment
and making the payment, then the system breaks down, and
then that means that the transaction is not entered into
the branch account?
A. That is correct, yes.
Q. So you have a discrepancy between what has happened in
the real world, which is that a payment has been made by
the bank, yes?
A. Yes.
Q. And you have the fact that that payment is not recorded
in the branch accounts because the system has collapsed
before the basket has been closed -- I should say
committed, yes?
A. Yes.
Q. Do you mean collapsed? You said the system collapsed.
MR DE GARR ROBINSON: It is a very loose form of --
your Lordship understands what I mean.
But the system goes down. It could be a comms
problem, it could be a systems problem, it could be
someone has dug up the phone line outside.
A. A power problem.
Q. It could be a thousand kinds of problem, yes?
A. It could be lots. I'm not sure thousands --
Q. I'm sorry, it is fair that you should make that
clarification. I am not trying to commit you to that
number.
So in that situation any system, let's forget about
Horizon, again we have got a Star Trek brilliant system,
any system is going to have to manage that problem,
isn't it, in some way?
A. Yes.
Q. Because there are always going to be situations where
what's happened in the real world may not actually
accord with what's recorded in the accounts?
A. That is right. Frankly what Horizon does, rather than
make the assumption that the transaction completed
successfully, it effectively re-looks at the elements of
the transaction to see how far it got, to see whether it
should roll back or roll forward.
Q. Yes, because in the course of the transaction being
keyed in, before the basket is committed, all the
elements of the transaction are actually recorded --
let's talk Horizon Online -- they're all recorded in the
BRDB but they are in different tables of the BRDB. So
they are securely kept, held somewhere, for the moment
in time in which the transaction is committed to the
audit store -- I shouldn't say the audit store -- to the
database, so they are held there but they are held in
abeyance. Then when something goes wrong the
transaction isn't committed to the database and the
tables which contain the data relating to the
transaction, and some other tables, they then throw up
a flag saying this is a recoverable transaction. And
what that means is that the transaction appears -- it
has been done in the real world but it hasn't entered
the stacks, it hasn't entered the branch accounts, so it
has to be looked at to see what needs to be done, is
that correct?
A. Yes.
Q. And that's how the Horizon system was designed to work,
correct?
A. Yes. Just in pure technical terms, the raising of the
flag, once the transaction is started that's recoverable
a flag or a stake is put in the database to say we are
starting a recoverable transaction. Then at the end of
it, once it is committed, the flag is taken down.
Q. Exactly.
A. So when the counter restarts it has a look to see
whether there is any recoverable transaction flags
there. If there are, it has to deal with that before it
boots up.
Q. Exactly. And this isn't strictly relevant to Helen Rose
but just to be clear, in that scenario, given the way
the system is designed, indeed given the way any system
would have to be designed, there would then have to be
an enquiry as to what happened on the ground, wouldn't
there?
A. By the humans interacting?
Q. Yes. In other words, let's take this example, the
Post Office would have to find out from the postmaster
whether he accepted the £76, wouldn't he? They would
need to know whether the money was accepted or whether
it wasn't, and only then would they know what they
should do in relation to this transaction?
A. Typically a counter would know whether the transaction
or whether the monies have been handed over because one
of the last things that you would do at the end of the
transaction would be -- it is called firing, you would
fire the cash drawer and the cash drawer would come
open.
Q. You are not suggesting it wouldn't have to be checked.
You wouldn't assume that the money had passed hands, you
would need to know whether it had. You would need to
ask the postmaster, wouldn't you, in order to work out
what, if anything, needed to be done to restore the
branch to balance?
A. But it is a worthwhile check to do, to find out whether
cash has been handed over or not.
Q. Yes, because the system on its own doesn't know whether
cash has passed hands, does it? The system doesn't tell
you. It doesn't photograph the passing of cash from one
to the other, there is no way in which the system would
ever know that?
A. No. It would know whether it has displayed a message on
screen to say pay X amount and it would know whether the
cash drawer has been opened or not, but it wouldn't know
if physically that instruction had been followed, yes.
Q. So it might be, for example, the message is flashed up
on the screen and then the system crashes, and if you
were at the Post Office or the SSC you would not be able
to tell, looking at the data you have, what had happened
and you would have to make an enquiry. And it would be
a good practice, generally speaking, to make that
inquiry before deciding whether any correction needs to
be made or not, yes?
A. Yes.
Q. Thank you. So let's go back to Lepton. This was
a cancellable transaction because there hadn't been
an immediate instruction for a payment to be made by
a financial institution. I think you will accept with
me that when that happens it is not in the recoverable
category, it is in the cancellable category, yes?
A. I would have to check that by looking at the report.
I can't recall precisely what the --
Q. Okay. You agreed with me earlier that it was
a cancellable transaction?
A. I believe so, yes.
Q. Which means that the standard process with -- in fact
the universal process with cancellable transactions is
that the transaction is then removed from the system.
The assumption is made that the transaction should not
be done. Then if there is any problem that can be
handled by manual processes. Again you can ask the
branch whether in actual fact, although we have
cancelled the transaction, have you actually received
some money? That's how the system works, correct?
A. Mm.
Q. And that is how the system worked in this case, didn't
it?
A. In this case there was a dispute between whether the
system itself said there was the reversal or whether the
human, the subpostmaster, chose to do the reversal or
not. And the indicator within Horizon was that it was
the subpostmaster that did the reversal but it was found
that that was incorrect and it was actually Horizon.
Q. So you are saying Credence said it was the postmaster
that did it but in actual fact it was the system that
did it. And that's your considered view?
A. I believe that's what the document reflects, yes.
Q. Let's pick this up in your second report -- one other
thing I should mention, actually, is that in this
process, the way the system is supposed to operate, when
there is a cancellable transaction like that, or indeed
even a recoverable transaction, receipts should be
printed by the system to allow the postmaster to know
what's happened and what he or she should be doing, yes?
A. Yes. The process should be that receipts are printed.
There are other reports elsewhere that suggest that that
is not always the case, but that is certainly what the
process should be.
Q. Let's look. Can we go to page 117 of your second report
which is {D2/4.1/1}. This is paragraph 4.78. It is all
under the heading "Failed Reversals" {D2/4.1/117}.
You say at 4.78:
"As dealt with above at paragraph 4.62, the excerpt
from Gareth Jenkins within the Helen Rose report
indicates that there was no evidence of the creation of
a disconnected session receipt, unless further diagnosis
(which I do not believe has been disclosed to me) has
since been conducted and reviewed by Angela Van Den
Bogerd. I have reported on what was diagnosed
contemporaneously by Mr Jenkins, particularly ..."
Then you quote a piece of text that I won't read but
I invite you to read.
(Pause)
A. Yes.
Q. So what you are suggesting there is that the Helen Rose
report indicates that Horizon didn't produce a
disconnected session receipt in branch, yes?
A. Yes.
Q. If we go back to page 113, {D2/4.1/113} and look at
paragraph 4.63, you are talking about Credence now, you
are talking about the Helen Rose report. You say:
"Therefore, the contemporaneous evidence is
consistent with the determination that Horizon initiated
the reversal, NOT the Subpostmaster."
A. Yes.
Q. "In my first report I had explained (at paragraph 4.61)
that the Subpostmaster had not reversed the transaction,
this had been a reversal generated by the system as part
of recovery."
A. Yes.
Q. "Credence data appeared to show (or was interpreted as)
being a reversal initiated by the Subpostmaster. This
difference of position arose from Post Office looking at
Credence data and Gareth Jenkins of Fujitsu looking at
audit data and system logs."
A. Yes.
Q. "This demonstrates two positions", you say:
"(a) Credence data, most commonly used by Post
Office for their investigations, is either wrong or does
not provide sufficient information to complete the full
picture; and
"(b) It was only after the Subpostmaster involved an
external forensic accountant that the Audit data was
requested."
The external forensic accountant, are you aware of
this, what that's a reference to, Second Sight?
A. In the documents that I have seen, the call logs,
I think the subpostmaster says "I have got a forensic
accountant involved", I do not think he mentions --
Q. You are not aware it was Mr Warmington from
Second Sight?
A. I wasn't aware.
Q. Fine, I will not ask you any more about that.
Then if we go back to what you said about this in
your first report. Can we go to {D2/1/67} please. Are
you there? Paragraphs 5.49 to 5.50:
"The document ('Helen Rose report') refers to an
incident where a Transaction Correction was issued which
the Subpostmaster duly settled financially despite the
Subpostmaster denying conducting the reversal."
5.50:
"The report appears to show that the material that
Post Office initially reviewed did not identify that it
was the system that initiated the reversal rather than
the Subpostmaster and therefore the Transaction
Correction making the Subpostmaster liable was issued in
error. Since this is effectively a failure to
appropriately reduce the risk of error this is also
dealt with further ..."
So here you are saying -- well, let's move on
actually to page {D2/1/101}. You have some more points
to make about Credence at page 101. Picking it up at
paragraph 5.175 --
A. Sorry, are we in the second report now?
Q. The first report {D2/1/101}. Picking it up at 5.175,
you say:
"The report regarding the reversal dispute conducted
by Helen Rose states:
"On looking at the Credence data, it clearly
indicates that the reversal was completed by ...
(Subpostmaster) at 10:37 ... and was reversal indicator
1 (existing reversal) and settled to cash."
{D2/1/102}
"5.176:
"It is therefore relevant to question why Post
Office were using Credence data to initially investigate
disputed transactions."
Stopping there. Your contention is that they should
not use Credence to initially investigate, is that
right?
A. It would seem that you can use Credence to conduct
a cursory investigation but you have to go back to the
full logs to get the full picture. Because if there's
a different picture being given by Credence to that of
the logs, then ultimately both can't be correct.
Q. It is just your use of the word "initially". Is there
any significance attached to that? That's not what you
should look at even first, you should look at something
else first, should you?
A. No, I mean, it depends what depth of investigation you
are going to look. If it is just a cursory
investigation then Credence might be okay for that.
Q. I see, thank you.
5.176:
"Whilst it is evident that it was understood by Post
Office in this instance to request assistance from
Fujitsu for further material to investigate this dispute
there appears to be further issues with the data
provided by Fujitsu."
5.177:
"Observations of the disclosures illustrates that
the initial report ..."
That is the Helen Rose report, right?
A. Mm.
Q. " ... states 'a transaction at 10.42', whereas the
Credence data file shows 10.32 with the reversal at
10.37."
Stopping there. You are giving another example of
Credence giving wrong data, yes?
A. There appears to be a difference between the times that
are recorded, yes.
Q. "Fujitsu's data states the transactions are at 9.32 and
9.33 and reversal timestamp is 9.37."
You are suggesting that is a further problem with
Credence, that it is actually an hour out as compared
with audit data, yes?
A. I actually say that in the next paragraph, yes.
Q. Then you say:
"5.178:
"Whilst this hour difference between the data sets
might be easily traceable for Fujitsu, it is not clear
how easily it would have been to investigate issues
where the Subpostmaster was not sure of what time things
went on erroneously in the system ..."
A. Yes.
Q. So what you are doing here, Mr Coyne, is that you are
making the following claims: first of all,
a disconnected session receipt wasn't printed when it
should have been, correct?
A. That is what the report says, yes.
Q. Secondly, that Credence data initially relied on by
Post Office was misleading, misleading as to who
reversed and misleading as to time, yes?
A. Yes.
Q. And, thirdly, the problems with Credence led to
an erroneous transaction correction, inflicting a false
loss on the subpostmaster, correct?
A. Whether there was an erroneous transaction correction or
not is not clear, it depends what decision was taken
based on the evidence, based on either the Credence or
the ARQ log.
Q. We can go back to your first report, paragraph 5.50, but
my understanding of what you said there was the
Post Office wasn't liable and it was a false transaction
correction. So that is your view, isn't it, that you
formed on the basis of reviewing the Helen Rose report
and other documents?
A. If Post Office had have continued to use the Credence
data, then the transaction correction would have been
issued in error.
Q. You actually say, reading again from paragraph 5.50:
"... and therefore the transaction correction making
the Subpostmaster liable was issued in error." {D2/1/67}
A. Yes.
Q. You are making a claim as to what happened on the basis
of the documents you have seen?
A. Yes.
Q. And is that your view?
A. Yes.
Q. Thank you. Let's now go to Ms Rose's report. It is at
{F/1082/2}, pick it up at page 2. There's the
"Executive Summary" and the first paragraph has the time
10.42 that you referred to. You see that?
A. Yes.
Q. The report says:
"The branch was issued with a Transaction Correction
for £76.09, which they duly settled; however the
postmaster denial reversing this transaction ..."
Under "Reviewing the Data", let's read that:
"On looking at the Credence data, it clearly
indicates that the reversal was completed by JAR001
(postmaster) at 10:37 04/10/2012 and was reversal
indicator 1 (existing reversal) and settled to cash. An
existing reversal is where the session number/Automated
Payment number has to be entered to reverse the item.
"The Fujitsu logs were requested for this branch,
but whilst waiting for these to arrive communications
took place with Gareth Jenkins at Fujitsu for more
details to gain an understanding what had occurred at
this branch."
A. Yes.
Q. Now, she says the Credence data clearly indicates that
the reversal was completed by the subpostmaster. But it
is fair to say, isn't it, that the Credence data did not
actually say that the subpostmaster had initiated the
reversal, correct?
A. Well, certainly whoever constructed this report said it
clearly indicates that the reversal was completed by the
user.
Q. She's inferring from the facts that she sets out there
that the reversal itself must have been initiated by the
subpostmaster, isn't she?
A. That's what she is saying. She's saying "it clearly
indicates".
Q. It is an interpretation of the data she has got. There
isn't a box in Credence -- she's not saying there is
a box in Credence saying this was initiated by the
subpostmaster, it is that the reversal has a postmaster
reference attached to it and a reversal indicator 1, and
she infers from that, she construes that, she interprets
that as indicating that the reversal was specifically
undertaken by the subpostmaster. Would you accept that
what we are talking about here is a mistake in
interpretation?
A. There's nothing here to suggest there is a mistake in
interpretation to me. The words on the page say "it
clearly indicates that the reversal was completed" by
the subpostmaster.
Q. I would like to suggest to you, Mr Coyne, that what this
suggests is she looked at the three points of
information and she inferred from those three points of
information that the reversal was undertaken by the
postmaster, but the Credence system doesn't specifically
say that. She has made a mistake because she has put
two and two together and made four, in fact five?
A. I think that really is a matter for Helen Rose.
Q. Would you accept it is possible?
A. It is possible that she was mistaken, are you asking,
sorry?
Q. If we go over --
A. Sorry, I might have given the wrong answer. Are you
asking me is it possible --
Q. Are you suggesting that Credence did specifically state
that the reversal was undertaken by the postmaster
himself, rather than a reversal happened when the
postmaster was logged on. In fact it was the postmaster
logging on that caused the reversal to happen?
A. I haven't looked at Credence myself in order to validate
what the author of this report saw. I have gone off
what this paragraph says, that Credence clearly
indicated that a reversal took place by the user.
That's what I have based my evidence on.
Q. I understand, but I suggest to you that what you have
read here is consistent with the view that what happened
is Ms Rose misunderstood the significance of the items
of information that were on Credence and formed the a
mistaken conclusion?
A. I agree that that is possible, yes.
Q. Thank you. Then if we go over to page 3 of the report
{F/1082/3}. For completeness I should say that on
page 1 you will see that there are two -- this report,
it is not really a report. It is curious that it has
some questions and then some answers that are provided
by Mr Jenkins by e-mail and those answers are there in
blue.
MR JUSTICE FRASER: I think you mean page 2. We have gone
to page 1 which is literally just the facing page.
MR DE GARR ROBINSON: I'm so sorry, I meant page {F/1082/2}.
I'm sorry.
So there are passages in blue which are quotations
from emails she has received. The first email is on the
first page. And the middle paragraph, just to be clear,
this is the paragraph you relied on. About halfway down
it says:
"The fact that there is no indication of such a
receipt in the events table suggests the counter may
have been rebooted and so perhaps may have crashed in
which case the clerk may not have been told exactly what
to do."
I presume that was the basis upon which you said
there were no receipts printed for this transaction,
correct?
A. I think there is a more definitive statement than that
later on in this document. This is Gareth Jenkins
suggesting that there wasn't a receipt.
MR JUSTICE FRASER: Is the blue Mr Jenkins?
A. Yes, I believe so, my Lord.
Yes, it is the paragraph below where it says:
"The reversal was due to recovery [and] was not
an explicit reversal [made] by the clerk".
Q. What you are saying is this affirmatively states that no
receipt was printed for the postmaster to tell him what
to do. That's what I'm asking you about, remember.
A. Well Mr Jenkins here, who has investigated it, has said
from the logs that there wasn't a disconnected session
receipt.
Q. And it was on the basis of that text, you said that in
your report?
A. Yes.
Q. You remember, one of the claims you made in your report
is that there was no session receipt printed?
A. Yes.
Q. If we go over the page, please, there was a second email
that comes a couple of weeks later, at the top of the
page {F/1082/3}. It is the paragraph beginning:
"The files 4 to 25th October ..."
Do you see that?
A. Yes.
Q. If we can miss out the sentence that talks about those
files. The next sentence says:
"Also row 70 of events 4 to 25 Oct ... shows that
session 537803 ... has been recovered and this event has
the same timestamp as the Reversal Session. Also row 71
of Events 4 to 25 Oct ... shows that a receipt was
generated from the session 537805 (not explicitly, but
it was the only session at that time)."
So you will see that on the very next page,
Mr Jenkins is saying actually the receipt was printed
after all?
A. No, I think that's talking about a receipt for something
else. It is not a disconnected session receipt, I do
not think.
Q. Are you suggesting that -- so he is talking about
a completely different -- why would he be talking about
a completely different session in this -- or rather why
would she, Ms Rose, be quoting in this email
a discussion about a completely different session?
A. They are actually talking about two sessions here.
There is the session ending in 803 and the session
ending in 805.
Q. Yes. Perhaps I could read the next sentence.
A. Yes.
Q. "This receipt would have told the user that a Rollback
had taken place (but the logs don't make that
explicit)."
Is that clear enough for you, Mr Coyne? What
Mr Jenkins is saying here is that a receipt was printed
showing that the transaction had been rolled back,
correct?
A. Right, so what Mr Jenkins is saying here is that the
logs were missing the record that the receipt was
printed but he believes the receipt was printed.
Q. Yes. So your claim in your report that the report shows
that the receipt was not printed, that claim is wrong,
isn't it? You hadn't read this document properly, had
you?
A. Well, the situation here is that we have got to -- in
order for this scenario that you are putting to me to be
correct, we have got to assume that firstly the initial
investigation showing that it was a user that issued the
reversal was wrong, and then we have also got to assume
a receipt was printed although it is not within the
logs.
Q. Mr Coyne, in your report you specifically say, and
I think you confirmed to me that it is your opinion,
that the report -- this report shows that a receipt
wasn't printed for the disconnected and reverse session,
yes?
A. Mm.
Q. What I'm suggesting to you is that this report, if you
can call it that, says nothing of the sort and that you
haven't read it carefully enough, is that right or is
that wrong?
A. Well, if Gareth Jenkins is correct then a receipt would
have been printed.
Q. So would it be fair to say that in your anxiety to write
a bad thing, to be able to write down a bad thing in
your report about Horizon, you recorded what was said on
the first page of the report, but you didn't look at the
second page of the report which would have shown that
that bad thing wasn't in fact correct?
A. No, but my point was about this report is to show that
there is a difference between the view that you get of
the data from viewing the Credence data from the ARQ
data, and that's correct.
Q. Mr Coyne, if you just made that claim we would have been
in and out of this issue within about five minutes. The
reason why we have spent about 20 minutes so far is
because you made several claims, and I set them out
orally and you agreed that you were making each of those
claims on the basis of this Helen Rose report. And what
I'm suggesting to you is that the claim that we are now
talking about is a claim that was wrong and that you
should have known it was wrong if you had read the
report properly?
A. I do agree that the report suggests that the receipt was
printed.
Q. Isn't this another example of you taking a document that
on a superficial reading could be said to say something
critical about Horizon, and immediately writing that
critical thing down without analysing the document
properly to see what it actually said?
A. No. This document does illustrate the point that I was
making about the difference between Credence and ARQ
data.
Q. And do you accept that a receipt -- are you suggesting
the receipt was not printed -- are you giving up on your
suggestion that a receipt was not printed?
A. The only evidence that we have here is that
Gareth Jenkins is saying that the receipt was printed.
Q. So you are disclaiming --
A. No, no, I can accept that position.
Q. Very good. For your Lordship's note, if one goes to
{F/1095.1/1} there is an email between Mr Armstrong and
Mr Warmington of Second Sight in which Mr Armstrong
confirms that he did receive three receipts in relation
to this reversed transaction at the time. It is at page
{F/1095.1/4} of that document. I see it is up on the
screen so let's have a quick look.
To be fair to you, Mr Coyne, you wouldn't have seen
this at the time you wrote your reports, I do not think.
MR JUSTICE FRASER: When was it disclosed?
MR GREEN: 7 March, my Lord.
MR JUSTICE FRASER: 2019? Okay.
MR DE GARR ROBINSON: You will see that on 25th June
Mr Armstrong writes an email to Mr Warmington of
Second Sight and he says:
"Having read your report I searched through the
weekly records for the 4th October 2012 and found THREE
disconnected session receipts all with the same session
ID ..."
If we go to the bottom of the page:
"The time shown on these slips is 10.36 yet I had
had the foresight to enter the time of 10.32 am on the
customers bill alongside the amount paid of £76.09.
This means that the customer had already left the office
by the time these receipts were printed out by the
system."
So he had manually written the time of the
transaction on the customer's bill, and one infers --
would it be right to infer from that, Mr Coyne, that he
hadn't actually got a receipt, he hadn't closed the
basket and a receipt had been printed, so he realised
something had gone wrong and he manually wrote the time
of the transaction down on the bill he received from the
customer, is that a fair inference?
A. Yes.
Q. So he knew something was wrong but he accepted the money
from the customer and he allowed the customer to leave
the premises?
A. Yes.
MR JUSTICE FRASER: I do not want to start a hare running,
but just for my purposes that session ID of 537803 --
this isn't a question for you, Mr Coyne, it is for
counsel. Can we just go back to the Gareth Jenkins blue
extract because he mentions two sessions, 537803 and
537805. So are they different receipts from the 537805
receipt that he is talking about? It might be it
doesn't matter.
MR DE GARR ROBINSON: I would strongly suggest, my Lord, it
doesn't.
MR JUSTICE FRASER: But is your take on it that they are
different receipts or is he talking about the same
receipt?
MR DE GARR ROBINSON: My take on it, my Lord, is that one
transaction was cancelled, it was this transaction, and
the appropriate receipts were printed for it.
MR JUSTICE FRASER: Was that session 805 or 803?
MR DE GARR ROBINSON: My Lord, I'm afraid I haven't
considered these documents sufficiently to answer that
question.
MR JUSTICE FRASER: I don't want to start an unnecessary
hare running.
Right back to you, Mr de Garr Robinson. {F/1082/3}
MR DE GARR ROBINSON: Coming to the next point, timings
being wrong. If we go back to 5.177 of your first
report, that is {D2/1/102}. So we have dealt with the
question whether Credence affirmatively stated that the
reversal was by the postmaster or by the system, and we
dealt with the question whether a session receipt --
session receipts, I should say, were printed or not.
We now come to this further criticism which is that:
"Observations of the disclosure illustrates that the
initial report states 'a transaction at 10.42', whereas
the credence data file shows 10.32 with the reversal at
10.37."
I would like to suggest to you, Mr Coyne, and we
might be able to save some time, that the transaction
was clearly at 10.37, indeed we have Mr Armstrong
himself saying so in the email we have just read.
A. Yes.
Q. Clearly what happened is there is a typo in Ms Rose's
report. If we go to {F/1082/2}, please, at page 2.
At the top of the page she says:
"A transaction took place at Lepton ... on the
04/10/2012 at 10.42 for a British Telecom bill payment
..."
Then she then says in the next sentence:
"At 10.37 on the same day the British Telecom bill
payment was reversed out to cash settlement."
Now, I would just like to give you an opportunity to
correct what you are saying in 5.177. Isn't it fairly
clear that the reference to 10.42 here was her error,
because you can't have a transaction that's reversed
five minutes before the transaction is done. In fact
she should have written 10.32, yes?
A. Well, either she has got it wrong or the system has
recorded it wrongly, I don't know which.
Q. Are you really seriously suggesting that Credence was
indicating that the transaction was done at 10.42 and
that that's a reason for suggesting, for thinking, that
Credence is unreliable? Is that really your contention?
A. Times on computers can be out. They do drift. It is
possible that it's got the time wrong. I agree with
your position that it could well be a mis-key on behalf
of Helen Rose.
Q. It wouldn't be a sound basis for suggesting that
Credence wrongly records the time done of transactions,
would it? This wouldn't be a sound basis for making
that claim about Credence? What it is a sound basis for
saying is that when people write documents sometimes
they press the wrong keys, would you agree?
A. Yes. It is one of those two scenarios, yes.
Q. As for the second point made at 5.177, that the ARQ data
always works in accordance with Greenwich Mean Time,
whereas everybody else at the time was working on
British Summer Time, that's not a serious problem, is
it? It's not something that is going to cause great
difficulties to anybody, is it?
A. As soon as you know that you are an hour adrift then it
becomes very easy to deal with, but if you don't know
that it is problematic.
Q. So are you imagining a world in which Mr Armstrong is
provided with ARQ data but nobody tells him that ARQ
data is based upon Greenwich Mean Time, is that your
assumption? And that's a problem, because nobody tells
him that ARQ data is based on Greenwich Mean Time?
A. No, my answer is if you are told then it becomes very
clear very quickly, but if you are not told it is
confusing.
Q. But in 5.178, Mr Coyne, you seem to be assuming
{D2/1/102}, remarkably, that no one would have told him.
You say:
"... it is not clear how easily it would have been
to investigate issues where the Subpostmaster was not
sure of what time things went on erroneously in the
system ..."
Why are you assuming that, having reached a point
where the subpostmaster actually has the ARQ data, no
one is going to help him understand that there is
an hour discrepancy between the ARQ data and British
Summer Time?
A. The point that I'm making is that unless somebody tells
him it wouldn't be clear. I do not think a user would
typically know that the computer would be an hour out.
I think the assumption would be that if it is an audit
system of some description, that the clock difference
would actually be dealt with correctly.
Q. What I would like to suggest to you, Mr Coyne, is that
in this section what you are doing is you are trying to
squeeze as much criticism as you can out of the
Helen Rose report that you can level at Post Office.
This isn't a fair-minded explanation of what happened,
it is an exercise in trying to extract bad points as and
where you can find them. What would your response be to
that?
A. That's not true. And with regard to the time, when
I point out that the time was wrong, the next paragraph
explains how it is likely that it was wrong.
Q. You say "it is not clear how easy it would have been to
investigate", that's a suggestion that in fact the
subpostmaster would ...
I'll read the whole of it:
"... it is not clear how easy it would have been to
investigate issues where the Subpostmaster was not sure
of what time things went on erroneously ..."
What are you saying that is a suggestion of?
A. Well, the subpostmaster might not necessarily know what
the actual time was that the error took place. So if
they have got to then work out what time it actually
took place precisely, and then look at two different
times because the clock might be right on the audit log
or it might be an hour forward or an hour backward on
the audit log it just makes the process more difficult.
But I do accept that if somebody explains to the
reviewer that it is an hour behind, then that makes the
process easier.
MR DE GARR ROBINSON: My Lord, I wonder whether this is
a convenient moment.
MR JUSTICE FRASER: By all means. We will have a 10-minute
break.
MR DE GARR ROBINSON: Could we make it five minutes,
my Lord?
MR JUSTICE FRASER: One of the transcribers has a back issue
and that's why we are having 10 minutes.
MR DE GARR ROBINSON: Very good.
MR JUSTICE FRASER: But we can go on a little bit past 4.30
if you are worried about losing time. The trouble with
five minutes is it is not really sufficient for current
purposes. So a 10-minute break and come back in at
11.55 am.
(11.45 am)
(A short break)
(11.55 am)
MR DE GARR ROBINSON: My Lord. Mr Coyne, we were talking
about your criticisms of the use of Credence. This
isn't -- the discussion we have just had, the points we
have just been discussing -- actually before finishing
on this system, would you accept that what happened in
the Lepton case was a customer gave cash for a BT bill
payment to be made, in fact the BT bill payment was not
made but the branch accepted cash for that payment, it
therefore had a surplus of cash and so a TC had to be
issued to correct for that surplus. Do you accept that
that's what happened?
A. Yes, I believe that that's what happened.
Q. So do you accept that the TC was not erroneously issued,
in fact it was correctly issued?
A. Yes.
Q. Thank you. Then let's move on to another criticism you
have of Credence at {D2/1/101}. This is your first
point about Credence. It is paragraph 5.174. You say:
"The End to End Reconciliation Reporting document
from 27 February 2012 states:
"There is no formal reconciliation produced between
the POLSAP System and the Credence transaction stream.
The Credence stream should therefore not be used to
verify financial integrity and Post Office should ensure
the POLSAP System Transaction information is used for
this purpose."
A. Yes.
Q. That's one of the bases upon which you suggest that
Credence shouldn't be used in order to make decisions on
transaction corrections, right?
A. Yes.
Q. Okay. Let's look at the document itself. It is at
{F/896/1}.
I'm afraid I can't see the date on the version on
the screen.
A. 27 February 2012.
Q. Thank you very much. It is called "End to End
Reconciliation Reporting", so it is a document about the
reconciliation process that we discussed yesterday.
A. Yes.
Q. Which is the process by which data goes into POLSAP and
the data in POLSAP is then compared with client data,
data from banks other institutions and that sort?
A. Yes.
Q. Then exceptions are identified and looked into?
A. Yes.
Q. Right. If we could go forward to page {F/896/65}.
Section 5 at the top of the page says "TPS
Reconciliation Reports Specified".
It starts by saying:
"The Transaction Processing System (TPS) Report Set
has been designed to enable reconciliation of the
transactions carried out in Post Office branches using
the Electronic Point of Sale Service (EPOSS) which are
sent to POLSAP and POLMIS."
A. Yes.
Q. Just to be clear, the TPS system is the system which
takes -- it is almost the highway which takes data from
the Horizon branch database and transfers it into
Post Office's own systems?
A. Mm.
Q. They are generally referred to as back office systems?
A. Yes.
Q. They are actually separate systems that belong to
Post Office, yes?
A. Yes.
Q. In the course of that process there are -- that's when
the reconciliation --
A. Yes.
Q. Once they arrive at POLSAP the reconciliation process is
undertaken, yes?
A. Yes. I mean reconciliation, this is talking about end
to end reconciliation, so it is all the way through the
whole -- the entirety of the systems.
Q. But when the comparison occurs -- the figures hit POLSAP
and then the comparison with client data occurs, does
it?
A. Yes.
Q. I see. So:
"The ... (TPS) Report Set has been designed to
enable reconciliation of the --"
Sorry, I have just read that sentence. Let's move
on:
"The TPS exceptions report set identified herewith
reports errors that have occurred within counter
transactions or during the harvesting process.
"NB: for the avoidance of doubt, there is no formal
reconciliation produced between the POLSAP and POLMIS
transaction stream. The POLMIS stream should therefore
not be used to verify financial integrity and Post
Office Ltd should ensure the TPS Report Set and POLSAP
transaction stream are used for this purpose."
This is the document you referred to and it refers
to POLMIS here. Actually there is a later version of
this document that refers to Credence.
A. Yes.
Q. It may be that the document reference you have given is
erroneous?
A. I think that that's right. It must be a later version
of the same document.
Q. I presume you didn't check all the document references,
it would have been very difficult for you to do that.
A. I have put what's called a MD5 reference at the bottom
of there, so I'm not sure. I don't think there's any
easy way of checking that.
Q. I have found a later version of the document that does
refer to Credence so I'm not going to challenge you on
that, Mr Coyne.
MR JUSTICE FRASER: Would you give me, for my note, that
reference at some point. You don't have to do it now.
MR DE GARR ROBINSON: Yes, my Lord. It is {F/1686/1}.
MR JUSTICE FRASER: Thank you very much.
A. Sorry, my footnote does say 27 February and the date at
the bottom of this one is 22 June.
MR JUSTICE FRASER: No, this is 27 February but I think
an earlier version was 22 June of 2011.
A. Forgive me, my Lord, I'm just looking at the bottom of
what's on the screen at the moment, towards the bottom
right.
MR JUSTICE FRASER: Yes, that's because you can't see the
way the colours have been struck through.
That is right, isn't it, Mr de Garr Robinson?
MR DE GARR ROBINSON: My Lord, I believe so.
MR JUSTICE FRASER: For some reason I have got in my
{F/896/1} on my trial bundle, I have got a coloured
track change version of the same document which does
show 22 June crossed out.
MR DE GARR ROBINSON: Mine does --
MR JUSTICE FRASER: Yours does as well?
MR DE GARR ROBINSON: I have a hard copy and mine does,
which I printed off the trial bundles, my Lord.
Should I say "from" the trial bundles? I never
know.
MR JUSTICE FRASER: That's fine.
MR DE GARR ROBINSON: If we go back to page {F/896/8} of
this document, I hope it is of this document and not the
1696 version.
It explains, if we look at section 2, "Scope":
"This document defines the format and content of all
reconciliation reports for HNG-X ..."
That is Horizon Online?
A. Mm.
Q. "... which satisfies the DRS, APS and TPS reconciliation
requirement."
These are all different forms of reconciliation.
Can you take us through them. What's DRS?
A. It is something reconciliation service but I can't think
what.
Q. APS?
A. Automated payment system.
Q. Then we have TPS.
A. Transaction --
Q. These are all separate systems beyond, as it were, the
branch data?
A. Yes.
Q. It is beyond branch accounts. This is information taken
from the BRDB and pushed through those streams to allow
different forms of reconciliation to be undertaken?
A. Yes.
Q. It does not attempt to define within the operating
systems how the transactions are processed.
"This document does not attempt to define the
business processes undertaken within Fujitsu Services
and Post Office Ltd with respect to the resolution of
any exceptions which may arise, nor does it scope the
requirement for any systems that may be required to
assist in this process. This information can be found
in the associated documents."
So it is just talking about the format and content
of all reconciliation reports and it doesn't talk about
the business processes undertaken with respect to the
resolution of any exceptions.
Now, if we go back to -- so just to be clear, it has
nothing to do with the Post Office business processes
leading to decisions on transaction corrections, does
it?
A. It does -- well, the decision to make a transaction
correction is a comparison between, in rudimentary
terms, front end and back end systems. Because what is
going on here through transaction processing has
a potential to change transactions in the back end.
Q. Mr Coyne, I'm getting slightly concerned about time.
I asked quite a simple question which was this
document -- paragraph 2, section 2 that we have just
read, makes it clear it is not about the business
processes which lead to the decisions made to issue
transaction corrections. That is a yes or no answer, if
I may suggest. Could you give me one?
A. Yes, this document does not go to --
Q. Thank you. It is not what this document is concerned
with at all, is it? It is concerned with the
reconciliation process. And that process may end up
leading to investigations that result in decisions being
made but it is not about that side of the divide at all,
is it?
A. No, that is right.
Q. Thank you.
A. I have the DRS, it is data reconciliation service.
Q. Thank you.
Then if we go back to page 65 {F/896/65}, this is
going back to section 5. This is describing the process
by which exceptions are identified, yes?
A. Yes.
Q. Then the various reports that are produced are then
discussed. So at 5.1 there is the TPSC250 report, "Host
Detected Transaction Control Errors":
"This report is produced daily and shows detail for
any Post Office branch where the control totals for the
transactions output by the Host to POLFS and POLMIS do
not match the daily transaction totals calculated by the
counters."
So that is quite a good check. It shows if there is
a discrepancy between what the counters have done and
the information going into Post Office's systems.
That's quite a useful check, isn't it?
A. Yes, it is a report that's available to the Post Office.
It isn't given to the branch I don't believe.
Q. No, it's not. I think actually it is given in the first
instance to Fujitsu. It is only given to Post Office if
Post Office request it, that is right, isn't it?
Because Post Office isn't involved in this, it is
a Fujitsu process, correct?
A. There is a suite of reports that is handed over between
Fujitsu and Post Office automatically each morning. I'm
not sure whether this is one of the reports that's sent
to them.
Q. If one goes over the page, 5.2, TPSC254. This is
another form of report that's generated each day, yes?
{F/896/66}
A. Yes.
Q. This is called "Harvester Exceptions":
"This report is produced daily and shows a list of
exceptions detected by the BRDB copy process when
failing to process one or more messages."
These are all countermeasures, aren't they? They
are the sort of countermeasures Dr Worden is talking
about, spotting discrepancies between data that ought to
be the same. It is a good example of redundant data
storage and MID and all those other acronyms that
Dr Worden uses, correct?
A. These are reports that are available so as long as
somebody looks at the reports they should be able to
pick it up.
Q. Mr Coyne, you are not suggesting that people don't look
at -- people look at these reports every day, don't
they? These are the reports that produce all those
exceptions about which you make so much hay in your
report?
A. They certainly should do, yes.
Q. Are you suggesting -- let me get -- are you suggesting
that people don't look at these reports? Have you seen
evidence to suggest that people don't look at these
reports?
A. No, what I'm saying is somebody needs to read the
reports.
Q. Very good. Then if one goes over the page to 5.3
{F/896/67}, TPSC257, that's "POLFS Incomplete Summaries
Report". That's another daily report, isn't it?
A. Yes.
Q. "This report identifies all Post Office branches on a
daily basis in which the net total of transactions
(debits/credits) does NOT net to a value of zero."
So this, for example, picks up receipts and payments
mismatches, doesn't it?
A. Yes.
Q. So if there is a receipts and payments mismatch at any
branch on any day of the week it will be automatically
reported to Fujitsu who will be aware of it and can
investigate, isn't that right?
A. Yes, I believe that this is the report that's printed to
indicate that, yes.
Q. And would I be right in thinking that you have seen
hundreds of PEAKs which show that Fujitsu do absolutely
investigate these exceptions when they arise?
A. There are certainly PEAKs that talk about the
investigation from these incomplete summary reports,
yes.
Q. I'm interested, would you accept that there are lots of
PEAKs that do that?
A. I don't know exactly what the number would be but there
are a number, yes. There are many.
Q. Here's what interests me about that answer, Mr Coyne.
You are perfectly happy when you see an example of
a handful of things happening to say things often happen
when they favour a case -- that they help build a case
that Horizon is bad. But when I ask you a simple
question, "You have seen lots of PEAKs in which these
exceptions are investigated?" you are unwilling even to
concede that it happens a lot of times. I'm quite
interested in why you should have a different attitude
depending on whether or not something is a criticism of
Horizon or in praise of Horizon?
A. I'm attempting to be as precise as possible with my
answers to you.
Q. When it comes to saying something positive about Horizon
you are very precise indeed. Can I suggest to you, Mr
Coyne, that you are rather less precise when it comes to
criticising it.
A. That's certainly not my intention.
Q. Let's go back to page {F/896/65}. This is the third
paragraph under section 5:
"NB: For the avoidance of doubt there is no formal
reconciliation produced between the POLSAP and POLMIS
transaction stream."
We can call that Credence.
"The POLMIS stream should therefore not be used to
verify financial integrity and Post Office Ltd should
ensure the TPS Report Set and POLSAP transaction stream
are used for this purpose."
You appear to suggest in the paragraph of your
report that we have just read, paragraph 5.174, that
this is an indication that Post Office should not be
using Credence for the purposes of making decisions
about transaction corrections. That is your claim,
isn't it?
A. Yes.
Q. Could I just suggest to you, Mr Coyne, that when this
report is talking about financial integrity that's
a reference to the integrity of the financial data, it
is a reference to ensuring that the data for the given
day is complete so that it can be used for
reconciliation. It is not a statement about what should
be done when making decisions on transaction
corrections?
A. But some of the information that is reported here and
finds its way back into POLSAP will be required in order
to make a decision on whether to issue a transaction
correction or not. And if they are not reconciled
together, you could have the scenario where Credence
data differs from POLSAP data.
Q. So as I understand it, you are using this as part of
an argument -- and it becomes a theme of your second
report -- that Credence data shouldn't be used for the
purposes of deciding on TCs, actually it should be ARQ
data?
A. My point is that Credence data alone shouldn't be used.
The ARQ data will give the full picture of what went on
at the counter.
Q. If in this report they are talking about that process,
and I have already suggested to you, Mr Coyne, that that
question, the data that is used for the purposes of
transaction correction decisions, has got nothing to do
with this report. The writer isn't concerned with that.
I have already suggested that to you and I think you
have accepted it. But are you suggesting that the
writer has decided to say something that's outside the
scope of this report because he is concerned that
inappropriate data is being used for the purposes of
making transaction correction decisions? Is that how
you construe this paragraph?
A. Well, I mean I don't exactly know what was in the mind
of the author when they put this together, but they saw
fit to put a specific note to say that there was a doubt
over what should and shouldn't be used to verify
financial integrity, and what should be used to verify
financial integrity is the TPS reports in POLSAP.
Q. Mr Coyne, from the get-go Post Office has used its
management information systems in order to decide on
whether or not to issue transaction corrections, is that
right?
A. Yes, I would think so.
Q. And it has used Credence and any predecessor -- I'm
presuming here that POLMIS might be a predecessor of
Credence -- would that be right?
A. It is Post Office Management Information System.
Whether that later became Credence or not, I would have
to check.
Q. I'm afraid I don't know. That was a genuine question.
So we have a business, the Post Office, which has
had a practice since the beginning of making decisions
in relation to transaction corrections based upon its
management information systems?
A. Its range of management information systems.
Q. And you are suggesting, are you, here in this paragraph,
that the writer of this report in 2012, February 2012
and thereafter, is suggesting that what Post Office has
been doing for the previous 12 or 13 years is completely
wrong? Do you honestly think that that's what the
writer of this sentence was intending to convey?
A. No, I don't think they are saying that what you have
been doing for the last 12 years is completely wrong.
They are providing a warning that you should use one set
of systems rather than another set of systems because
the two do not reconcile.
Q. And what I would like to suggest to you, Mr Coyne, is
that when this report talks about financial integrity,
it is talking about the integrity of the data that's
compared as between the client and Post Office. It is
not talking about the process of making decisions about
transaction corrections. Do you not accept that?
A. But the integrity of the data between the Post Office
and its clients could well have an impact on branch
accounts, because if there's an issue between
Post Office and its clients, the client will report
a different view of the transaction.
Q. Let me move on. Let's move on to the conclusion that
you then draw from the passages that we have seen, the
Helen Rose report, and the end to end reconciliation
reporting.
The conclusion you draw is that when faced with
a problem, an apparent discrepancy, an apparent
exception in accounting figures, when therefore called
upon to make a decision about whether to decide on
a transaction correction or not, Fujitsu and Post Office
should always use the raw ARQ data that's held in the
audit store, that is your claim, isn't it?
A. In order to get the definitive position on it they
should, yes, because that is a record of what actually
happened.
Q. So let's take this in stages. It is a good thing for
a complex system like Horizon to have a secure place to
store a copy of all the transaction data that comes in
from branches, isn't it?
A. Yes.
Q. Because one can then go back to look at that pristine
copy months or years later if there is a concern about
the accuracy of the data in the management systems,
correct?
A. Yes.
Q. And the whole point of an audit store is that the data
in it is effectively locked away in a secure place and
only extracted when it is necessary for checking against
the other sources, correct?
A. Yes.
Q. Now, were you in court when Mr Dunks gave evidence about
the process of obtaining data from the audit store, do
you remember? Were you here when he gave that evidence?
A. I'm not sure that I was.
Q. You will recall his witness statement where he describes
it, yes?
A. Yes.
Q. It is a slow and careful process, isn't it, extracting
the data in a reliable way?
A. I don't know if "careful" is the right word but it
certainly would be slow, I can imagine.
Q. And it is done from a very small number of very
carefully managed secure sites, correct?
A. Likely, yes.
Q. And it is labour intensive and quite expensive, correct?
A. I can't imagine why it would be labour intensive.
I imagine you'd put a search into the computer system
and press go, I would imagine, and it would --
Q. Mr Dunks' witness statement describes the care with
which these processes are undertaken, the care with
which access to the relevant systems is carefully
controlled.
A. Yes.
Q. It is only particular people that are allowed to do that
particular job --
A. Indeed.
Q. -- and they have to have particular authorisation and
particular qualifications?
A. Yes.
Q. And I think you have already accepted it can be a slow
process?
A. Yes.
Q. Particularly if a large amount of data is being
extracted you would accept, would you, that it could
take weeks and weeks for really huge quantities of data
to be extracted?
A. I would be surprised if that was the case. But I mean
typically you would be extracting a day's worth of
transactions, perhaps even less than that, to understand
what went on around the particular hour or --
Q. And it is quite an expensive process, isn't it?
A. I believe that there are -- there is a certain number of
requests that can be made within Fujitsu's service level
agreement and then after that there is a charge that's
made, yes.
Q. And the charge that's made over the allowance of 720
a year, it is over £200, are you aware of that?
A. I think I did see that figure, yes.
Q. Right. And what you get when the data is extracted is
not data organised into the form of elaborate reports,
it is raw data which actually needs packaging even to
put it in a spreadsheet. It is very difficult to manage
this kind of data, isn't it?
A. I believe the process is that there is a raw version but
there is also a version that is packaged so it can be
read in Excel.
Q. You mean in a spreadsheet?
A. In a spreadsheet.
Q. Do you mean the spreadsheets that the witnesses -- the
claimant witnesses were taken to during the course of
their evidence at the beginning of the trial? Because
my experience of those spreadsheets is that they are
very difficult to manage your way through, but would you
suggest not?
A. Absolutely. You would have to be reasonably experienced
in interpreting the data that's given to you, it would
be quite a complex spreadsheet. But it can be opened up
in a conventional spreadsheet.
Q. The controls and checks described by Mr Dunks are what
you would expect if the idea is to have a gold standard
store of data that cannot be altered or corrupted or
lost in the meantime, yes?
A. Yes.
Q. Perhaps I could go to your second report now at
{D2/4.1/7}. This is your executive summary of your
second report.
A. Yes.
Q. In paragraph 1.2 you say:
"I consider that Horizon is less robust than as
originally expressed in my first report. My primary
reasons for this are as follows ..."
A. Mm.
Q. And you talk about remote access.
If you go down to paragraph (c).
A. Yes.
Q. "Post Office do not consult the full audit data before
ruling on a discrepancy, instead using third party
client reconciliation data or subsections of the audit
data from within Credence or HORice."
A. Mm.
Q. So this is something -- your discovery that this was
happening is something that caused you to have a change
of heart on robustness, is that right?
A. Yes. It was my original belief that the audit data was
consulted.
Q. So when you drafted your first report you thought that
every time Post Office was faced with some kind of
discrepancy that might lead to a TC, you thought in
every case regard was had to the full audit data that
was held in the audit store, did you?
A. Well, certainly that was my original opinion, yes.
I thought that was the purpose of the audit store, to
actually go back and see what happened at branches.
Q. But you knew, Mr Coyne, that the audit store was copied
from the BRDB and sealed and maintained for seven years,
didn't you?
A. But it only needs to be sealed from a write perspective.
You can seal something and still have read access to it.
There is generally no problem with that. That doesn't
tamper with any seals --
Q. Didn't you know, in fact wasn't it obvious, bearing in
mind all the controls that we just discussed with
Mr Dunk's report, witness statement and so on, that
Post Office would generally rely on its own management
information systems when making decisions on transaction
corrections? Wasn't that obvious to you?
A. No, it wasn't obvious to me. I perceived that the
management information systems would be part of it, but
that to get the true picture of what had happened at the
branch the audit data would be consulted.
Q. Well, if we could go back to your first report, it is
{D2/1/119}.
MR GREEN: My Lord, in fairness to the witness, it does
pre-date the witness statement being referred to. The
witness statement is November.
MR DE GARR ROBINSON: I'm grateful to my learned friend.
Thank you.
If we look at paragraph 6.46, you will see it is
under the heading "Reconciliation Summary". This is
your first report, yes?
A. Mm.
Q. You say:
"In consideration that Branch account positions were
interpreted and reviewed from data flows through to Post
Office back end systems (which would determine whether
Transaction Corrections were to be applied), the
following is considered relevant."
{D2/1/120}
Over the page you say:
"POLSAP – Following investigation by Fujitsu, Logica
and Ingenico, the root cause of a long outstanding
problem with missing data within POLSAP was identified
as out of range dates which failed the Credence
validation (in excess of 90 days). Ingenico has
corrected the data and P&BA has advised that the
mismatches have been cleared ..."
Here you appear to be saying, indeed you appear to
be raising it as a criticism of Post Office, that when
making management -- decisions on transaction
corrections, Post Office were using management data that
could be wrong.
Now I would like you, if you would, to explain why
having made that criticism there you claimed just three
and a half months later in your next report that in fact
you made the opposite assumption, namely, that
Post Office always looked at all the core audit data?
A. Sorry, I don't understand the question.
Q. This is your first report, paragraph 6.46 is your first
report.
A. Yes.
Q. And we just read your second report where you said: when
I produced my first report I believed that when
decisions were made about transaction corrections the
full ARQ data was used. Correct?
A. Yes.
Q. Now we go to 6.46 and here you are saying that
management information systems, the back end systems,
were used to determine whether transaction corrections
were to be applied, and you give as an example, over the
page, POLSAP?
A. Yes.
Q. Now, ARQ data, the core audit store, that isn't back
end, is it? That's not held by Post Office and used by
Post Office for its systems, it is an entirely separate
process that's maintained by Fujitsu, isn't it?
A. Yes.
Q. So here in your first report you appear to be saying
that there is a problem with the process by which
Post Office decides transaction corrections because they
are using Post Office management systems that might be
unreliable?
A. Yes.
Q. But if you believed that when Post Office made those
decisions actually they used the full ARQ audit data,
that criticism would be utterly misconceived, wouldn't
it? So either you were telling the truth -- or either
you believed when you did your first report that
management systems, not ARQ data, was used, or it is the
position that you were making a criticism of the use of
management systems even though you believed that the
full audit data was actually used, but it can't be both.
A. I think it can be both. In my first report it was my
perception that the range of management information
systems and the ARQ data should be used, and in my
second report -- well, before my second report
I discovered that the ARQ data was not used.
Q. I see. So let's look at paragraph 6.46 again. In that
paragraph, forgive me, but it appears to be yet another
criticism of the method by which Post Office conducts
its business and the criticism appears to be that
Post Office is using a form of information which is
unreliable {D2/1/119}.
If you had wanted to be balanced in your approach to
that criticism, would it not have been appropriate for
you to say: but I do of course recognise that this is
only one subset of the information that Post Office used
and I do understand Post Office actually used the full
audit data as well? Would a need for balance not have
required you just to make that point clear?
A. Certainly if I had included that it may have helped the
reader, yes.
Q. If we could now move back to your second report, it is
{D2/4.1/228}. Actually I'm so sorry, I have taken you
to the wrong page. Could we go to 114 rather than 128
{D2/4.1/114}.
You say in paragraph 4.67 under the heading "ARQ
Requests":
"In her statement Ms Mather references the number of
ARQ requests per year. If it is correct that the
contractual limit of 720 per year has never been
exceeded except for this litigation, then in my view
Post Office is not utilising the audit data sufficiently
and certainly is not checking the audit data prior to
issuing transaction corrections."
A. Mm.
Q. Then at 4.68:
"in 2011/2012 using the figure that Dr Worden
produces at his Table 9.3 (section 9.6, page 208) there
were 107,583584 Transaction Corrections but only a
fraction 213 of these were validated by the audit data."
A. Mm.
Q. So you are suggesting, are you, that full audit data
should have been extracted from the database in at least
107,584 occasions during that year?
A. Yes. I believe that the audit data should be consulted
every time there is a potential dispute and need to
issue a transaction correction. In light of now
understanding the process of getting at the audit data
and getting it extracted, I see that it wouldn't be
possible to do that.
Q. It would also cost something like -- well, because of
course you wouldn't only look at ARQ data when actually
issuing a transaction correction. Would I be right in
thinking that your view would be that every time there
is an exception, a discrepancy, a full audit data ought
to be looked at as well?
A. Certainly a section of the audit data, yes. You don't
have to look at the full audit data. On a lot of
systems if you believe something happened between
10 o'clock and 11 o'clock, you can go to a screen, put
10/11 o'clock on a certain date, press go, and it will
give you a list of all the actions that happened on that
day.
Q. I don't believe the audit still works like that. Is
that something you are aware of?
A. No, I now understand the audit data doesn't operate like
that and I now understand there are costs associated
with it, but I don't believe that was understood --
Q. So let's say there are 107,000 TC decisions made a year.
The number of decisions that don't result in TCs, let's
pluck a figure out of the air, I have no idea, it could
be an equivalent number, it could be much more actually.
Let's say 250,000 decisions a year. If each of those
audit requests cost £200, we are looking at £50 million
a year, aren't we?
A. Yes.
Q. Another point that interests me is: is it really the
case that you are assuming that although the audit data
was kept separate, it was nonetheless available in some
kind of information stream in a similar way to POLSAP
and to Credence? Is that how you thought it worked?
Because it bears no relation to how the audit store was
actually operated and maintained.
A. I have got experience of working or designing audit
stores for a number of different systems and they don't
have to work in the way that they have been defined
here. Audit systems are often very easily accessible to
be able to be read by certain users. There's nothing
inherently difficult about that. I accept that the
write aspect of it, you know, you wouldn't want people
writing to an audit database. But having the ability to
read to it is something that's quite simple -- read from
it is quite simple.
Q. And would you accept that the closer you get to raw
data, the more you need specialist knowledge and skills
to interpret that raw data?
A. You do, but the extraction or the report that's run from
the audit data would typically handle the presentation
aspect of it. There might be lots of 0s and 1s at the
back, but the report generator can often put it together
in quite a usable form --
Q. So are you suggesting that when you were giving your
first report, your first opinion, you believed that
there was a process by which the core audit store that
was kept separately by Fujitsu, and there are references
in your report explaining how separately they were kept,
that actually there was a system that extracted data
from that audit store on a regular basis, perhaps on
a continual basis, and packaged that information into
easy to use reports that gave you all sorts of
information that you would need in order to make
transaction correction decisions, is that what you
believed was happening?
A. I would not characterise it in the way you have done
there, but my perception is if Post Office needed to
hone in on a particular area, whether it be an hour or
a day of what happened at a branch, that they would have
a way of viewing that audit data for that period on
a screen or by pulling a report.
Q. What I would like to suggest to you, Mr Coyne, is that
if that had been your apprehension, if that had been
your belief, you would have -- these would have required
their own quite sophisticated systems and you would have
been aware of those systems. You have a vast amount of
technical documents explaining all the different systems
in operation and how they fitted together, including
documents relating to the audit store, you would have
seen that there was a system of that sort. Indeed
I rather imagine that Post Office would have been quite
happy to come forward to explain how that process
happened. But instead, you are saying that you assumed
that all this happened even though you had seen no
documentation to support such a belief at all, and I'm
asking you, Mr Coyne, can that really be right?
A. Well, the purpose of having an audit of what happens at
branch counters is so that if there is a dispute over
what has happened that somebody, presumably this will be
Post Office, can have a very quick look at what happened
and find out the truth. That's the purpose of having
an audit store. There is no other reason for it other
than looking back at what actually happened. It is my
perception that that look back was available to people
at the Post Office.
Q. Could I suggest to you, Mr Coyne, that you knew very
well that the system that Post Office used for the
purposes of having what you describe as a quick look
were its management information systems. The hint is in
the name, MIS, management information systems. And you
would expect, in the absence of being told to the
contrary, that a business such as Post Office would use
its management information systems for making business
decisions of that sort?
A. And the audit database would be part of that management
information system.
Q. Mr Coyne, if that were true you would certainly have
seen documents explaining that amongst the management
information systems of Post Office was an audit store
that was maintained in an entirely separate facility
that was owned by an entirely separate company and was
maintained separately and had no connection with the
outside world, would you not?
A. No, I don't believe that that was the case. If you are
making decisions based purely on a cut-down version of
the data in a management information system you have to
decide what data is going to be cut out of that. So if
everything is in the audit store and just a portion of
that data is in your management information systems,
then you are going to necessarily make a decision based
on a subset of the data and not the whole of the data.
Q. I understand the logic of your position, Mr Coyne. What
I'm seeking to explore with you is whether it bears any
relation to reality.
Data comes out from the BRDB in streams. It comes
out -- copies of data come from the BRDB and go into
Credence. Copies of data come out from BRDB and go into
POLSAP. They go into other management information
systems maintained by Post Office. Entirely separately,
and the word "separate" is in your first report,
information goes out to a sealed audit store, the word
"sealed" is in your report, where it is kept for seven
years.
A. Yes.
Q. And what I'm suggesting to you is that there is no basis
upon which you could ever have thought that the
information in that audit store could be regarded as
a Post Office management information system?
A. I believed that it was a system that Post Office would
look at whenever there was a dispute about what happened
at a branch counter. I believed that they would have
access to that.
Q. Did you see any technical documents indicating a route
by which information from the sealed audit store was
made available on a read only basis to Post Office?
A. No.
Q. Did you see any PEAK or any other document, any -- well,
OCPs, it is too early for that. But did you see any
documents of any sort indicating or referring to the
stream of data flowing on a continual basis out of the
audit store into Post Office's management systems?
A. No, but that's not how things would work. If
Post Office wanted to get access to the data in the
audit store they would go to a screen or go to
an application on their computer and they would run the
request for that data.
Q. Mr Coyne, I would like to suggest to you that it is
completely unrealistic to think that a separate sealed
core audit store of the sort we're talking about should
be cracked open hundreds of times a day in preference to
using management information systems which are designed
for that precise purpose?
A. I think the word "sealed" is misleading and the concept
of cracking something open to get access to it I think
is misleading as well.
Things in an audit store are only -- can be written
to and only written to once, and the term that's often
used is write once read many, WORM. So the process is
written to once, but people can read from that store on
many occasions.
Q. But just to be absolutely clear, you had not and indeed
you have not seen any documents suggesting that
Post Office had the ability to gain access to the audit
store on its own systems, had you? There was no design
facility, there was no -- there were no lines of
communication between the audit store and Post Office in
any document you had ever seen, correct?
A. No, it looks as if the majority of the references to
audit database access was from Fujitsu personnel.
Q. And one final thing. Would I be right in thinking that
now that you understand how the audit store actually
works and the costs and delays associated with
extracting data on a large basis from the audit store,
would you accept that it would be disproportionate to be
using the audit store as a basis for making decisions on
transaction corrections in every single case?
A. Yes, it would seem that it would be very expensive and
very slow to access the audit store, and effectively for
the number of transaction corrections you couldn't do
that, and therefore you accept that you make decisions
on the management information systems rather than the
audit store.
Q. In your evidence yesterday we discussed your approach,
remember, to whether and to what extent Post Office and
Fujitsu did things on a cost benefit basis?
A. Yes.
Q. In the course of that evidence I recall you indicating
that you regarded it as important to ascertain whether
the possibility of error was reduced as far as possible.
Do you remember that exchange that we had?
A. Yes.
Q. Was it your objective in your reports to address that
question?
A. Was it my objective at the outset to address that
question?
Q. To consider not whether the risk was reduced as far as
reasonable or to consider whether the risk was reduced
as far as practicable, but to consider whether the risk
was reduced as far as possible, which is a much more
exacting standard?
A. I believe that was the word that was used in the Horizon
Issues.
Q. So would the answer to my question be yes, that when you
produced both your reports you did so with the objective
of applying that test when determining whether something
constituted a problem in the system or not, whether it
satisfied the test of reducing a risk as far as
possible?
A. Yes.
Q. And not just with -- and did that inform -- does that
inform actually the approach, the criticisms you make of
the use or non-use of ARQ data in your second report?
A. Yes.
Q. But if you take a step back and consider questions such
as proportionality and reasonableness, would you take
a different view on that question and perhaps some other
questions too?
A. As I understand it, the question was reduce as far as
possible.
Q. Yes.
A. So that is the way I answered that question.
Q. Could we go to {C1/1/1}, please. This is the Horizon
Issues. I don't want to take more time than is
necessary, but I would like to give you an opportunity
to tell me which of these Horizon Issues raises that
question as a test.
(Pause)
MR JUSTICE FRASER: Are you looking for it in your report?
A. I am, sir.
MR JUSTICE FRASER: The list of issues is at page 3,
I think, of your first --
A. Thank you.
MR JUSTICE FRASER: You can only see one page at a time on
the screen.
MR DE GARR ROBINSON: Absolutely, my Lord.
A. That's okay.
(Pause)
The reference at Issue 6 at 116 is reduced to
an extremely low level, the risk.
Q. Yes. So it is a factual question as to how low level
the risk was. It is not a question whether Post Office
had reduced the risk to the lowest possible level, is
it? I'm just wondering, Mr Coyne, whether you may have
applied in your entire approach to your reports the
wrong test for the purposes of these proceedings. Do
you think that's possible?
A. No, I don't believe so. I mean, it is not defined what
an extremely low level is.
Q. But you do accept that as low as possible, that was the
test that you used when approaching both your reports.
I think you have already accepted that?
A. Yes.
Q. Thank you. Let's move on to a different subject.
Perhaps I can deal with this quickly. I would like to
talk about PEAKs and KELs.
From what you said yesterday about your change of
mind on robustness between the first joint statement and
your first report, I imagine you would agree that the
system of KELs and PEAKs that Fujitsu developed was
quite a thorough system?
A. Yes.
Q. And that you formed the view that members of the SSC
were very familiar with the Horizon system?
A. Yes.
Q. And they were very familiar with the PEAK and KEL
system?
A. Yes.
Q. And with their training and experience and with using
search facilities they were able to navigate that system
quite well?
A. Yes.
Q. Notwithstanding the limitations that you have fairly
identified. And that using search facilities they were
often able to find PEAKs or KELs addressing similar
problems to the ones that they were facing?
A. Yes.
Q. And would you agree that the PEAKs show, generally show,
the thoroughness with which they generally worked?
A. Yes.
Q. And they tended to keep a written record of what they
did step by step in PEAKs, didn't they?
A. Yes.
Q. It wasn't comprehensive, no one is suggesting it is
comprehensive, but it's quite a process-driven process,
one doesn't often see something significant happening
that isn't somewhere recorded or alluded to in the PEAK
during the different processing steps that are described
as you go down the PEAK from the top.
A. Yes.
Q. So in the scheme of things, compared with other systems
with which you are familiar, you would accept, wouldn't
you, that this is actually quite a well organised, well
run system?
A. Certainly the way of recording the information in the
PEAKs and KELs is a reasonably good system, yes.
Q. Thank you. Now, I would like to ask you about something
you say in your second report which is at {D2/4.1/176}.
It is 5.186, Mr Coyne.
A. 5 point what, sorry?
Q. 5.186 at page 176 of the trial bundle.
A. Yes.
Q. You say:
"At Dr Worden's paragraph 488 he suggests that
serious bugs are rare in the KEL and PEAK records. I
agree, they are rare in the KEL records because the
purpose of KELs are to inform support personnel how to
deal with historic problems, the PEAK's however do show
many serious bugs as I have set out in Section 3 above."
I would like to ask you what you mean by "the
purpose of KELs are to inform support personnel how to
deal with historic problems". Could you explain
precisely what you mean by that?
A. Yes. So the purpose of a KEL is that it is to provide
knowledge for people who -- for SSC support people who
might be searching for things. So if a problem arises
they would search the KELs and either they will find
a KEL that appears to be appropriate, and it shows that
what has happened before has happened again and there
might be instructions on how to deal with it.
Alternatively if they don't find a KEL, they go through
the process of creating a new one.
Q. One possible implication that might be drawn from
paragraph 5.186 is that if there is a bug which has
an effect on branch accounts you will often not find
a KEL that addresses it. But I would like to give you
an opportunity to clarify whether that is what you are
trying to imply or not. I may be reading too much into
it.
A. Because a KEL is a single source of a record of a bug,
error or defect, what you will find is if the fault has
occurred again they will refer back to the KEL and they
will see that that fits their scenario. They often will
not put the details of this particular scenario, this
particular bug, error and defect, back in the KEL. The
KEL is just the single source of knowledge for them to
say, ah, it is that problem.
Q. I see. So what you are saying is that if you get a bug,
you generally speaking -- and of course there are
always -- I'm not suggesting to you that anything is
comprehensive -- but you are saying that generally
speaking if you get a bug of that sort there will be --
once it is detected, there will be a KEL which addresses
it, yes?
A. Yes.
Q. But that KEL will generally address the first instance
in which it arose?
A. Yes.
Q. And when there are other instances in which it arose the
KEL won't necessarily address those?
A. Won't necessarily. Sometimes you see it updated if they
have got a slightly new manifestation of it, or there is
some additional knowledge they have gained and they will
add it to the KEL so that the next time it arises it
might be helpful to the person, but there will only be
one KEL.
Q. I understand.
A. There might be ten instances of that triggering and they
will be in the PEAKs.
Q. That's very helpful. So is this right, if there is
a bug of that sort that's detected you are likely --
there's likely to be a KEL which deals with it?
A. Yes.
Q. Which describes it, put it that way?
A. Mm.
Q. And if there are other manifestations of that bug that
occur in a similar way, the KEL may well not refer to
them?
A. Yes.
Q. But if the bug manifests itself in a slightly different
way, in an odd way, then the KEL will be generally
speaking -- there are always exceptions I am sure, it is
a human system, but generally speaking there will be
an amendment to the KEL to explain the new variance, to
explain the new phenomenon, to enable the users to have
a proper understanding of what they need to look for?
A. That is right. Someone within SSC will decide whether
to add to the KEL that's already there, or that it is
significantly different so they will create a new KEL
for it.
Q. I think we can agree that in some cases KELs give quite
a lot of information and can be very useful?
A. Yes.
Q. In other cases one needs to look at PEAKs to have
a proper understanding of some details that may be
relevant to the inquiry that we are undertaking now?
A. Yes.
Q. So it depends?
A. It does depend. Sometimes a KEL will say: please record
every occurrence of this that you see in this KEL, other
ones you don't have that information.
Q. That's very kind, Mr Coyne.
My Lord, I wonder -- this is a convenient moment,
I wonder whether we can break now and perhaps sit at
1.50 pm. Would that be acceptable to your Lordship?
MR JUSTICE FRASER: Yes. Do I detect an undercurrent of
concern about time on your part?
MR DE GARR ROBINSON: I always have an undercurrent,
my Lord.
MR JUSTICE FRASER: We will come back at 1.50 pm. Usually
it will be a minimum for an hour. It is not for me, it
is not for you, it is for the witness. But today,
because it is the first time it has arisen and you asked
so politely, we will come back at 1.50 pm.
MR DE GARR ROBINSON: I'm grateful, my Lord.
MR JUSTICE FRASER: Mr Coyne, usual arrangements.
A. Yes, my Lord.
MR JUSTICE FRASER: If you could come back for 1.50 pm
I would be very grateful.
Just one housekeeping point. My file of PEAKs and
KELs that were being referred to, obviously we can start
a new one now for the experts, but I just wouldn't like
that to be forgotten about.
So 1.50 pm.
(12.55 pm)
(The short adjournment)
(1.50 pm)
MR DE GARR ROBINSON: My Lord, good afternoon.
Good afternoon, Mr Coyne.
A. Afternoon.
Q. Let's see if we can agree some things. First of all,
can we agree that the parties aren't here spending all
this time and money just to find out if Horizon could
have been improved, yes?
A. Yes.
Q. That might be important to understanding the background
to a particular claim by a particular claimant, but if
no bugs in Horizon caused any non-transient losses to
any claimants, we might as well go home, yes?
A. Yes.
Q. In those circumstances, would you agree with me that it
is useful to know, in fact it is necessary to know, in
this trial, about the likely impact of bugs that have
occurred in Horizon and whether that impact is likely to
have been transient or lasting?
A. Yes.
Q. That's what the Horizon Issues we discussed yesterday
are all about, isn't it? The extent to which it is
likely or unlikely for bugs to cause shortfalls for
which subpostmasters have been held liable?
A. Yes, I think the term is the extent to which it is
possible or likely, yes.
Q. And for that issue to be meaningful don't we have to
settle upon some metric for the likelihood of a bug
causing a lasting shortfall of that sort?
A. The metric I have adopted is to find whether there was
an actual bug, error or defect and see whether it had
an impact. I don't believe there is any other metric.
Q. Don't you need a yardstick to have a proper measure of
extent? For example, the likely impact of bugs in
Horizon across all Post Office branches, the likely
impact in a single branch in a single month, the
likelihood impact across all claimant branches while
they held those branches? Wouldn't those be useful
yardsticks for the purposes of deciding extent?
MR GREEN: My Lord, I'm hesitant to rise, but we
specifically asked whether they were going to try to get
the third report in by the back door.
MR DE GARR ROBINSON: I have no intention of asking any
questions about that.
MR GREEN: That's one of the three questions that has just
been asked.
MR JUSTICE FRASER: Mr de Garr Robinson, your last question
is really a question for me, isn't it?
MR DE GARR ROBINSON: My Lord, it is a question about what
this expert witness has done in approaching the --
MR JUSTICE FRASER: If you do it by reference to his witness
evidence rather than by reference to submissions that
really amount to arguing the case in front of me, that
would probably be more useful.
MR DE GARR ROBINSON: My Lord, if I may, I would like to
follow my own course with my cross-examination of this
witness.
MR JUSTICE FRASER: You can, but your last question to that
witness is an issue for me.
MR DE GARR ROBINSON: Now, Mr Coyne, can we also agree that
there is no realistic prospect of you or anyone else
examining, still less assimilating, every document
that's been disclosed in this case in relation to
Horizon and its operation over the last 20 years?
A. Yes.
Q. That left you and it left Dr Worden with a choice,
didn't it? You can make observations on the documents
you found which may not advance matters very far: here
are some bugs which caused shortfalls in some branch
accounts, so it follows that it is not just possible
that a bug has caused loss, it is a certainty. That
answers the question: is it possible or likely the bugs
have a potential to cause shortfalls, but it is not
an answer to the complete question, is it, because as we
have seen the Horizon Issues include questions of
extent?
A. Yes.
Q. To what extent is this likely or unlikely to happen in
branch accounts in Horizon? To what extent was the risk
faced by a user in Horizon high or low? Do you accept
that those are the sort of issues that are raised in
this trial?
A. Yes.
Q. And to address extent, you can look at a limited portion
of the evidence that you can sensibly review. You can
assess its nature and scale and on the basis of those
assessments you can arrive at overall conclusions that
are generally useful, can't you?
A. Yes.
Q. An analogy with which we are familiar is an exit poll
that is taken on the day of an election. Only a very
small number of people are actually asked how they
voted, but based on that sample useful estimates can be
made about how all the voters voted, do you agree?
A. Yes.
Q. So you can move by a process of sampling from a position
of relatively uninformative certainty, you know, knowing
with certainty how 5% of people have voted, to
a position of much greater certainty or much greater
interest, namely what the actual outcome of the election
is going to be, yes?
A. I believe it would be an indicator, yes. Yes.
Q. In order to be useful, do you agree that the sample you
must choose needs to be an unbiased sample?
A. Yes, in that scenario it would need to be an unbiased
sample, yes.
Q. So if you are trying to work out, for example, how
voters have voted in an election it is no use just
asking people coming out of voting booths wearing blue
rosettes, is it?
A. No, that is true. If you are going down the route of
using sampling then you would have to make sure that
that sample is unbiased.
Q. Once you have an unbiased sample it then becomes
possible, doesn't it, to scale up. So you can scale up
the results that you have got from your unbiased sample
and invite people, invite the court, to make judgments
about what the overall likelihood of something happening
or not happening is, do you agree?
A. Certainly in your election scenario that would scale up
with a reasonable tolerance, yes.
Q. And that's what Dr Worden has done in his first report,
isn't it?
A. Yes.
Q. And it is the sort of question that arises in a case of
this sort where there are so many thousands of KELs and
over 200,000 PEAKs and tens of thousands of OCPs, OCRs
and MSCs, yes?
A. Yes, there is an inherent danger with that in that with
such a large sample size, and in the likelihood that it
is a small fraction of the entirety of the transactions
or branches that have suffered failure, that you might
sample and not find any.
Q. Yes, and there are well known statistical techniques for
dealing with that problem, aren't there? So if you
take -- how is it -- ten samples. The number of the
samples you take will then determine how representative
the results are that you are likely to get from
attempting to scale up. Are you aware of how this
works?
A. Not really with what you have put to me there. Would
you explain that a little bit further?
Q. Let me see if I can put -- you will have to give me
a moment, I'm afraid. Would you give me one moment?
A. Certainly.
MR GREEN: My Lord, I know my learned friend is worried
about time. Mr Coyne has disavowed statistical
expertise in his report.
MR JUSTICE FRASER: If Mr de Garr Robinson wants to use his
time exploring basic elements of statistical analysis
I'm not going to stop him.
MR DE GARR ROBINSON: My learned friend actually is quite
right. Mr Coyne has disclaimed any ability or expertise
in this, so let me move on.
A. Certainly I have very little expertise. I have a broad
ability to understand the concept.
Q. So you have no expertise in what to do with samples and
how to assess whether the sample can be
effectively scaled up or not, is that right?
A. Yes, I can see how that could be effective in certain
scenarios, but I don't believe the scenario that the
application here will work.
Q. Well, isn't it actually what you are trying to do in
your evidence as well, Mr Coyne? Aren't you saying:
I found a number of bugs, and aren't you suggesting that
an inference should be drawn that there could be a great
number of other bugs that you haven't found yet?
A. Yes, but it is from the basis of actually finding bugs
and trying to identify how many branches may be impacted
by those bugs, errors and defects.
Q. What I'm suggesting to you is that when you find certain
hits in your sample, because any sample is necessarily
limited, your ability to be able to say that the court
should scale up and should infer that there are likely
to be a certain number of other hits, or an uncertain --
a certain scale of other hits, that is dependent upon
the quality of the sample that you have chosen in
a particular -- whether it is an unbiased sample, yes?
A. Yes, but in my report I haven't suggested any scaling up
from particular bugs, errors and defects. I have talked
about specific bugs, errors and defects and how many
branches they are recorded to have impacted. There's no
scaling applied to that.
Q. Have you done that? Have you -- you say that you found,
or I should say you say that there have been found 29
bugs, yes?
A. Mm.
Q. Have you given any assessment of how many branches were
affected by those bugs?
A. Yes, Dr Worden and I in I think it is the second joint
statement, the longest joint statement, that has the
bugs in, we have a column in there that attempts to
identify the number of branches that were impacted. And
certainly some of the source documentation will indicate
a number, it might not be the right number, but it does
indicate whether it is 28 or 30 or 32.
Q. What I would like to ask you to do, please, is to look
at your original second report, not your revised
version. This is {D2/4/43}.
A. I don't have a paper copy of that.
MR JUSTICE FRASER: You haven't?
A. Not a paper copy. I will have the second.
MR DE GARR ROBINSON: I'm only going to take you to one
paragraph. It is 3.105. This is the original version.
You have changed it in the revised version.
A. Mm.
Q. You say:
"The PEAKs analysed below are a small portion of the
PEAKs I have identified as causing financial discrepancy
in branch accounts outside of those bugs acknowledged by
Post Office. It should be noted there are potentially
thousands more PEAKs that illustrate financial
discrepancy arising in branch accounts, this is only a
small selected sample from keyword searched PEAKs."
A. Yes.
Q. Now let's take this in stages. You have changed the
wording of the first sentence and I will go to that
change but I want to ask you about what the original
version means first. What you are claiming there is
that you have identified a large number of PEAKs
recording bugs which cause branch shortfalls but you
have only mentioned a small portion of them in your
report.
A. Yes.
Q. That wasn't true, was it?
A. No. By the conclusion of this report there was
a substantial amount that was looked at.
Q. In fact what you had done is you had identified every
single bug that you could and included it in this
report, hadn't you?
A. Within the time available. I mean it is probably quite
possible that there could well be more but we have
certainly had a good search.
Q. So what you say in the first sentence wasn't true, was
it?
A. No, my concern with the way that it read is that --
I was saying that I had only analysed a small portion of
the ones that had caused financial discrepancy.
Q. What you are saying there -- what the words literally
mean, Mr Coyne, is that you've analysed below a small
portion of a larger group of PEAKs that you have
identified as causing financial discrepancy?
A. Yes.
Q. And in fact that wasn't the case. What you did in your
report was you included every PEAK you could, every PEAK
that you were aware of as causing financial discrepancy,
didn't you?
A. Yes.
Q. So this is an important paragraph. You will see that it
is immediately under the heading "Horizon Issue 1
PEAKs", so it is an introductory paragraph, it is
introducing the reader to what comes next. It is not as
if you wouldn't have paid attention to what was in this
paragraph. I would just like to know what possessed you
to make that extraordinary claim that wasn't true?
A. Well, all the PEAKs hadn't been analysed, but of the
portion that had been analysed there was a number that
identified financial discrepancy.
Q. Weren't you seeking to give an impression in that
sentence that wasn't accurate?
A. No, not at all, but I did see that it wasn't as clearly
worded as it should have been.
Q. And do you accept that this was corrected only after my
instructing solicitors wrote to Freeths on 1st February
asking for these other PEAKs to be identified?
A. Yes, clarification was requested. Yes.
Q. And shall we look at Freeths' response. It is at
{C5/36/1}. This is Freeths' response to my instructing
solicitor's letter. If we could go to page {C5/36/2},
please. Picking it up at the bottom, paragraph 3, it
sets out the sentence that we are talking about.
Post Office's request is:
"Please identify the full set of PEAKs that Mr Coyne
has identified as causing financial discrepancy in
branch accounts outside of those bugs acknowledged by
Post Office."
The response comes:
"See response 2.2 above, see the 'yes' entries in
the column ..."
Then if we can go over the page {C5/36/3}:
"Mr Coyne has considered this paragraph in his
Supplemental Report and notes that his opinion has not
been articulated correctly in the sentence extracted in
your client's Request ..."
I'm sorry, my Lord?
MR JUSTICE FRASER: My screen has crashed yet again but I'm
going to deal with it. I still have the common screen
and I still have LiveNote, that's good enough.
MR DE GARR ROBINSON: "As is clear from the sentence which
follows it, Mr Coyne intended to refer to the fact that
he has only reviewed a small proportion of the total
PEAK documents disclosed. As such, Mr Coyne now
clarifies the meaning of this sentence as being: 'I have
analysed a small proportion of the PEAKS, from that
analysis, I have identified the following as causing
financial discrepancies in branch accounts outside of
those bugs acknowledged by Post Office'."
A. Yes.
Q. So was that your intention? Was that what you had
intended to say at paragraph 3.105 and by clumsy
drafting you had said something very different?
A. Yes, what I meant to say was in the second draft.
Q. Well, let's go to the second draft. That's at
{D2/4.1/45}.
I do believe I have the wrong page, I do apologise.
MR JUSTICE FRASER: No, you haven't. It is {D2/4.1/45}, it
is indeed page 45 but it is in the next version.
MR DE GARR ROBINSON: {D2/4.1/45}, please. Here you say:
"I have analysed a small proportion of the PEAKs,
from that analysis I have identified the following as
causing financial discrepancies in branch accounts ...
It should be noted there are potentially thousands more
PEAKs that illustrate financial discrepancy arising in
branch accounts, this is only a small selected sample
from [the keyword searches] ..."
So knowing that it was being said that you have not
found anything like the PEAKs that you would need to
find even to begin to justify the claimants' claim,
because that had been said by Dr Worden in his first
report, hadn't it, you are now arguing in
paragraph 3.105 that this is only a small sample from
a large cohort and the small sample of bugs, the small
number of bugs that you found should be scaled up to
reflect the large size of the cohort, yes?
A. I'm saying that there is the potential.
Q. Could I suggest to you, Mr Coyne, that there's no basis
for taking the fact that you found a small number of
bugs in the PEAKs that you reviewed and inferring there
could be any number of bugs in the PEAKs that you
haven't reviewed because scaling up only works if you
have taken an unbiased sample, I think you have already
agreed that, yes?
A. Yes, and that's why I'm not giving a view on what the
scaling might be. I'm saying that the potential exists.
Q. So you accept that you can scale up from, say, 200 PEAKs
or KELs to a cohort of 220,000 but only if the sample
that you have looked at is chosen at random. Would you
agree with that?
A. No, I don't agree with that, because this scaling is
starting from the basis that there was actual bugs,
errors and defects that did cause financial
discrepancies. So you are scaling up from a positive
position that there are records in there that do show
that and there's the potential for other ones to show
that.
Q. So what you are suggesting is that having found 29 bugs,
it is possible to scale up, it is possible to infer that
there are likely to be thousands more bugs in existence,
is that what you are saying?
A. There's certainly the potential to be.
Q. There is the potential. Because what interests me is
this concept of scaling up. The bugs that you found you
didn't find by reviewing a randomly selected sample, did
you?
A. No.
Q. You did the equivalent of asking everyone coming out of
the polling station who was wearing a blue rosette,
didn't you? Because what did you was you were looking
for bugs that had that effect. You were positively
searching for and excluding all others. You were
searching for bugs that had particular characteristics?
A. It doesn't work when you try and relate it back to the
election scenario where the purpose of that is to try
and establish what the percentage of people voting would
be. In this scenario here we are, as I understand it,
trying to identify real bugs, errors and defects, so
that is what is -- what was done during this exercise.
And what I'm saying here is because I have only analysed
a small number of the totality of the PEAKs, then there
is the potential for many more to be in here.
Q. Could I suggest that the process that you have
undertaken -- first of all, perhaps we can agree this.
Do you agree that the sample, the small sample that you
describe, the small selected sample that you describe in
3.105, that isn't an unbiased sample, it isn't
an unbiased sample from which it is possible to scale up
anything?
A. It is certainly not an unbiased sample, that is correct.
Q. From which it is possible to scale up anything?
A. You wouldn't want to scale up from that and make any
numerical assumptions based on the -- however many,
I think it was less than 10,000, but however many there
is, that that should be the number multiplied by that
percentage of the total number of PEAKs, you wouldn't
want to make that assumption.
Q. What I would like to understand, though, is why you
chose to say there are potentially thousands more PEAKs.
Why didn't you say dozens more or hundreds more? Why
did you choose to say thousands more PEAKs? It seems to
me, Mr Coyne, as if you are inviting the court to infer
that because you found 29 bugs from a small sample, it
is appropriate to think there could well be thousands
more out there that you haven't found, and I would like
to ask you why you think it is appropriate for the court
to think that?
A. I don't believe there is any more appropriate number to
put in there. Nothing would provide any precision in
there as to what the number could or should be.
Q. Are you suggesting that it is likely that there are
thousands more bugs of this sort?
A. No.
Q. In fact are you suggesting that -- well, are you
suggesting that it is more likely that there are
thousands than there are hundreds or dozens, for
example?
A. Yes, I don't -- I would think there would be more than
dozens certainly.
Q. I'm interested that you should say that. So you are
suggesting -- you are now making a claim that having
found 29 you think there will be dozens more. Is that
right?
A. I certainly believe there would be dozens more, yes.
Q. And are you prepared -- but you are not claiming that
there could be more than -- that there are likely to be
more than dozens, that is not a claim you are making?
A. I don't know what the number would be but there
certainly is the potential for there to be thousands
more.
Q. By "potential", you are saying it is not impossible, are
you?
A. Sorry, say again?
Q. By "potential" you are saying -- sometimes when people
say "potential" they mean it is a really viable
possibility and close to a likelihood that something is
going to happen, other times they simply mean it is
simply not impossible. Potentially I could become Prime
Minister. It is possible although it isn't going to
happen. Other times I could say potentially I could
retire when I'm 65, and that would be -- it's not
certain but it is a real -- now, when you say
"potential" you mean not impossible, don't you?
A. It is certainly not impossible and it is on the basis
that there are 200,000 PEAKs, whatever the exact number
might be, that haven't been reviewed. They weren't
responsive to the search terms that were selected at the
time.
Q. But here's what I don't understand, Mr Coyne. As you
explained very helpfully yesterday morning, you and your
team have spent a great deal of time using the
intelligent search functions that you have at your
disposal, which I rather envy, I have to say, in order
to find precisely these kinds of PEAKs and KELs?
A. Yes.
Q. And you are quite good at that. You are certainly
better than I would be. It is the entire raison d'etre
of your e-disclosure business, isn't it, that you can
use what is in the trade called intelligent search
functions? In those circumstances isn't the fact that
you have only been able to find 20 bugs significant?
A. No, I don't believe so. Typically we would be and
I would be assisted by somebody within the organisation
who created the documents, that would be helpful with
things like particular error codes that might indicate
financial discrepancy, certain terminology in code and
things like that. None of those were provided. So
I was starting from the basis of just trying to come up
with words and phrases that may be used, that may
indicate a discrepancy, that may indicate a defect,
an imbalance, but it is entirely possible that there are
words and phrases used that I'm not aware of.
Q. But I presume that by the phrase "intelligent search
functions" you include concepts such as once you have
started finding some and you see how they draft
themselves, you realise there are word patterns or
symbol patterns or report patterns, TPSC256, TPSC268A,
all those automatic report numbers which indicate
receipts and payments mismatches, or CRC failures, or
all the other issues that could be indicative of a bug.
That as you go along and as your knowledge of the PEAKs
and the KELs increases, you become better and better at
finding terms and symbols which will enable you to zero
in on the PEAKs and KELs that you are actually looking
for. Isn't that how it works?
A. That is how it works. One of the documents that
I requested very early on was a document that would
indicate where a financial impact has been discovered.
That was one of the very first documents. And that
simply wasn't provided, that request was --
Q. I'm sorry, why are you making that point?
A. Because that would have assisted with the searching that
I was doing at the time.
Q. Mr Coyne, what document are you talking -- what document
did you request?
A. There was an RFI request that I put in, I think it was
in June or July --
Q. Right, and this RFI request was a request which was
designed to assist your search functions, was it?
A. Yes.
Q. And what did the request seek?
A. We have probably got the document, but it asked for
documents that were returned that would indicate that
a financial impact has been discovered.
Q. I have to say, it may be my fault, but I'm scratching my
head metaphorically, I don't recall that particular
request, but let's not waste any time on it.
Let me ask you a different question. My suggestion
to you is the fact that you have only been able to find
29 bugs, it is significant, because with or without the
document you just referred to you have found bugs which
you think do disclose a lasting shortfall for which
subpostmasters were made liable, is that right?
A. Yes.
Q. So you have seen how PEAKs and KELs relating to those
bugs are worded, yes?
A. Yes.
Q. So it is not as if you have been prevented from making
choices about the form of words and symbols and so on,
not been prevented from alighting upon the kind of
searches you need to do in order to find the bugs you
are looking for, yes?
A. The process would have been far easier if the documents
that I had asked for would have been provided at the
time.
Q. Okay. Let's not talk about the process, let's talk
about what you have actually done.
A. Yes.
Q. Imagine for the sake of argument that your team's
intelligent service system were absolutely brilliant and
that it were perfectly qualified, having become really
familiar with the system and with all the reports that
are generated in the system and all the phrases that
tend to be used and so on, they were absolutely
brilliant at capturing evidence of bugs of the sort you
were looking for. Now if that were the scenario, the 29
bugs that have been found could be very close to the
absolute total number of bugs that are to be found in
the cohort of documents, couldn't they?
A. It is possible that that's the case. I think it is
highly unlikely but it is possible that that's the case.
Q. Then let's assume that you weren't quite that good. It
might be that you only got half of them or perhaps
a third of them.
A. Yes.
Q. But doesn't, with all the intelligent search functions
that you have at your disposal and the people you have
to help you, doesn't the fact that only 29 have been
found strongly suggest that there aren't thousands more
bugs lurking in the PEAKs that you have been unable to
uncover?
A. It is certainly possible that the number is a lot less
than that, yes.
Q. I would suggest to you, Mr Coyne, that it is obvious
that if you have only been able to find 29 PEAKs there's
no way in the world that there are 100 times that number
of PEAKs out there that you have been unable to find?
A. There are hundreds of thousands of PEAKs and the impact
is not always described in the PEAK.
Q. Could you just answer my question before we can move on.
You have segued into the question of impact and I am
going to come to that.
A. Sorry, forgive me.
Q. But just focus on my question for a moment. Isn't it
obvious that however difficult the process has been,
that your team has not been so clumsy and incompetent
that it has only managed with all its intelligent
searches to find 1 in 100 of the bugs that are actually
disclosed in the PEAKs and KELs that you have reviewed?
A. No, I do not think that's inconceivable.
Q. Can you say that again?
A. I don't think it is inconceivable that that might be the
case.
Q. You don't think it is likely, though, do you?
A. It would be a complete guess.
Q. Yes. Here's what interests me, Mr Coyne. Before we
broke for lunch I asked you some questions about the KEL
system and the PEAK system, and I'm afraid I don't have
the transcript in front of me, but I think you helpfully
agreed that if a bug was detected which had branch
impact it would -- the chances were, I think I may be
putting it slightly too low, that it would be likely to
be addressed in a KEL somewhere, yes?
A. A PEAK somewhere.
Q. A KEL. We were talking about KELs at that time.
A. Sorry, could you put your question again then.
I thought you --
Q. Perhaps I should look at the transcript. Could we go
back to just before we broke. Would you give me
a moment, please.
A. Certainly.
Q. If we could go to page {Day15/94:21} of today's
transcript, please.
MR JUSTICE FRASER: Of which page, sorry?
MR DE GARR ROBINSON: 94, my Lord.
MR JUSTICE FRASER: 94, line 21.
MR DE GARR ROBINSON: I ask a question. I say:
"I see. So what you are saying is that if you get
a bug, you generally speaking -- and of course there are
always -- I'm not suggesting to you that anything is
comprehensive -- but you are saying that generally
speaking if you get a bug of that sort there will be --
once it is detected, there will be a KEL which addresses
it, yes?
A. Yes.
Q. And you said "Yes".
A. Yes.
Q. You are not withdrawing that evidence, are you?
A. No, no.
Q. So we have this situation. We have if there is a bug
that has been detected, the chances are it is going to
be described in a KEL somewhere, yes?
A. Yes, if it has been detected, yes.
Q. And there aren't 220 KELs, are there, there are
something like 9 and a bit thousand, is that right?
A. Yes.
Q. And we know that even by the time of your first
report --
MR JUSTICE FRASER: Just give me literally 30 seconds.
MR DE GARR ROBINSON: Of course, my Lord.
(Pause)
MR JUSTICE FRASER: It is all right. Go ahead,
Mr de Garr Robinson.
MR DE GARR ROBINSON: At the time of your first report we
know you had already reviewed yourself 5,114 KELs, yes?
A. Mm.
Q. And members of your team had, would I be right in
thinking, I may have specifically asked you this, and if
so I'm sorry to be going over it, but members of your
team would have reviewed other KELs in addition to that?
A. Yes.
Q. And since your first report you would have looked at
further KELs on top of the --
A. Yes.
Q. And I think I asked you how many you had reviewed and
you said you were unable to tell me. That's my
recollection but forgive me if I'm wrong.
A. No, I think that is right.
Q. Right. So you have looked at more than 5,114 KELs.
Would I be right to infer you probably looked at more
than 6,000?
A. No, it probably is between 5 and 6,000.
Q. And your team had looked at others as well. Are you in
a position to give any kind of assessment of how many
other KELs they are likely to have looked at?
A. It will likely be probably 1,000 more or something like
that.
Q. Okay. So you and your team collectively have looked at
something like between 6 and 7,000 KELs out of a total
of, what, 9,500, that kind of figure? Yes?
A. Mm.
Q. And yet all that has been found is 29 bugs, correct?
A. Yes.
Q. Isn't that a significant indication, Mr Coyne? Doesn't
it suggest quite strongly that the chances are that the
total number of bugs that are out there are not going to
be in the thousands. In fact there are unlikely to be
more than perhaps twice as many in the entire cohort of
KELs, would you agree?
A. That have an impact on branch accounts, yes.
Q. Yes. And if one then were to assume that some error
factor, let's assume there are some PEAKs that don't
make it through to KELs, that's not going to account for
very many, is it, because most of the time you would
expect the PEAK to have resulted in a KEL as soon as the
problem was discovered?
A. Yes.
Q. So actually, just ignoring the PEAKs for a moment, in
that you have reviewed, you and your team, over 6,000
KELs, so more than two-thirds of the available KELs --
A. Yes.
Q. -- and you found, between you and Dr Worden, 29 bugs --
A. Yes.
Q. -- wouldn't it be fair to infer that the total number of
bugs to be found in those KELs is likely to be less than
40?
A. Yes, that sounds reasonable. I'm just concerned that
the confusion here is between KELs, which document
a single instance of a bug, and a PEAK which is what we
are referring to here, which shows how many times that
bug has had an impact on the Horizon system.
Q. So let's take this in stages. Two questions raised.
The first one is how many bugs? The second one is how
many impacts and what's the nature of their impacts?
A. Yes.
Q. Both questions are important building blocks in order to
arrive at an assessment of extent, yes?
A. Yes.
Q. Thank you. I think you have agreed that the chances
are, as a result simply of your examination of KELs,
that there are likely to be no more than 40 bugs which
have been found to have branch impact, yes?
A. Bugs, errors and defects, yes.
Q. So we move on to the next question which is what was the
impact of these 40 bugs? What you say is -- and I fully
understand it -- that you can't get that from KELs, you
get that from PEAKs.
A. Yes.
Q. But here's the interesting thing: because you have got
the KEL, actually the KEL operates as a really useful
way of looking for PEAKs to which the KEL is relevant,
doesn't it?
A. Yes, you will often see the link between the two.
Q. Quite often, as you fairly say, there is actually
a specific link made between the PEAK and the KEL, and
you can search for PEAKs and the PEAKs will -- this
would be right, wouldn't it: PEAKs invariably refer to
the KELs to which the problems they address are
relevant, yes?
A. Yes. There is a better quality of link from PEAKs to
KELs. There's not always that link KEL back to PEAK.
Q. But this is where the beauty of intelligent searching
comes in, isn't it? Because you can intelligently
search through the body of PEAKs, having identified all
the relevant KELs, and there may be a number of them,
there may be one KEL and perhaps two or three others
that are also relevant, you search for all the PEAKs
which refer to those KELs, don't you?
A. Yes.
Q. And by that means you are going to get actually quite
a good sense of -- you are going to get a good hit rate.
You are going to find most, probably more than most, of
the PEAKs considering problems which those KELs address,
yes?
A. It is entirely possible to do that, yes.
Q. I'm not asking you whether it is possible, I'm
suggesting that it is likely that if you undertake that
search you will actually find all the PEAKs that are
relevant -- that exist that are relevant to the problem
addressed in the KEL?
A. Yes.
Q. So you have identified 29 bugs, you do your searches for
all the PEAKs, and by that means you can identify all
the PEAKs which record manifestations of the bug. It's
likely, I'm going to use the word "likely". I'm not
suggesting it can be entirely comprehensive, Mr Coyne.
So can we take it as read that obviously there are going
to be gaps at the margin, aren't there?
A. Yes. A PEAK is typically created when the bug, error or
defect gets to SSC within Fujitsu. So there may be
others that don't get there, but once they get to third
line support the PEAK is created, so yes.
Q. So by this means you were in a good position both to
identify bugs that have been detected in the system --
A. Yes.
Q. -- quite reliably, so with a fair degree of confidence
that there won't be that many more bugs in the system?
A. As long as they hit the search terms that I have used,
yes.
Q. Remember we are talking about the KELs now. The
starting point for the process that I have described is
the KELs.
A. Yes.
Q. And you've physically reviewed those KELs, haven't you?
A. Yes.
Q. So it is not as if you need intelligent search terms to
find the right ones, you have actually looked at them,
haven't you?
A. Yes.
Q. So by physically looking at them you found however many
bugs you found, I think it was -- it must be somewhere
below 20 because of course of the 29 there were also
bugs that were accepted by Post Office and there were
the bugs that were found by Dr Worden as well. So you
found -- if I suggest to you that you found around in
the late teens, would that figure sound about right to
you?
A. I believe that the figure in the second report was 28,
was it?
Q. 28. Well, that would include the bugs that have been
found by -- that have been admitted --
A. Yes, it did --
Q. -- by Post Office, yes?
A. -- the three --
Q. And it would include bugs that have been identified by
Dr Worden in his report?
A. Yes.
Q. Let's not quibble about numbers. The point is by that
process I think you have accepted that it is
a relatively reliable process by which you will have
successfully identified the large majority of the bugs
that have been identified by the SSC during the
operation of the PEAK and KEL system?
A. Yes.
Q. What's more, because having done that you can then look
through the PEAK system, you have the ability to
identify all the PEAKs which represent manifestations of
those bugs?
A. Yes.
Q. And those PEAKs identify -- where there are branch
effects those PEAKS generally will identify the branches
affected, yes?
A. Generally but not always.
Q. Generally speaking, if a branch has a problem then the
PEAK will identify the FAD code of the branch, correct?
A. No, that's not always the case. They will typically say
this might have an impact on branch accounts. They will
sometimes list a FAD code. They will sometimes refer to
a branch by name or location.
Q. I see. Let me park that issue until another day. But
in any event by this means, by moving from the PEAKs to
the KELs, you have quite a good method of identifying
the number of instances in which branches have been
affected by the relevant bug, yes?
A. Yes.
Q. Perhaps half an hour ago you gave me an answer which
surprised me. I wasn't expecting it. You indicated
that in the bug table in joint statement 2 there was
a column which indicated what the extent of each of your
bugs were, in other words the number of branches that
were affected by each of your bugs. Did I misunderstand
your answer?
A. It is either in the joint statement 2 or it is in the
report 2.
Q. You see, I'm struggling to understand what you are
talking about. It may be my fault. But I'm not aware
that anywhere -- that you have anywhere given any
evidence as to how many branches you think were affected
by any particular bug. Have I misunderstood your
evidence?
A. It certainly is in here. There is an attempt to
identify how many branches may have been impacted by
that defect.
Q. It would be helpful if you could tell me because it
might save some time tomorrow or the day after. Should
I be looking at the joint statement?
A. Yes, if you look at joint statement 2. So the page
where the actual table starts, index 1 on the left-hand
side. Then it says receipts and payments mismatch, the
year, and then it says:
"Coyne's opinion as to branch account impact ...
identified approximately 60 branch accounts ..."
Q. That's because Post Office had identified 60 branches.
But if we go --
A. If you go down for example to number 5, 14 examples of
branch impacted.
Q. Oh, I see, and we have got 57 branches impacted. For
6.2 it's one branch impacted.
That's very helpful, Mr Coyne, and by saying it is
very helpful I'm of course conveying that I obviously
haven't read this table properly.
What's interesting about it, though, is that the
numbers of branch impacts you are talking about are
relatively low, aren't they? I mean even 60 branches.
So if we take the receipts and payments mismatch, 60
branches affected. 60 branches out of 30 million
monthly accounts, that represents a 1 in 5 million
chance of a bug impact on a given set of accounts,
doesn't it?
A. You have used two different variables there. You have
used branch accounts --
Q. Yes.
A. -- and you have applied that to branches. If 60
accounts are impacted should that not be compared
against the total number of branches?
Q. Are you suggesting that when 60 branch accounts are --
so what you have done here is you have indicated how
many branches were impacted, but are you suggesting that
lots of these branches were impacted on lots of
occasions, is that --
A. No, I was responding to your -- you gave me an example
of why it was low.
Q. Yes. My suggestion to you, Mr Coyne, is that in
circumstances where you have got a bug that affects 60
branches?
A. Yes.
Q. And let's say it affects 60 branches on one occasion
each, sometimes it will be more, but let's assume it is
on one occasion each. If you look at the entire corpus
of monthly branch accounts, which is 3 million over
20 years, then of the 3 million branches that will have
been affected -- or that could have been affected,
I should say, 60 will have been affected.
A. Yes.
Q. Which means it has a 1 in 5 million chance of hitting
any given branch that you are looking at at any --
A. On any given month. That may well be right, yes.
Q. Okay. Thank you.
MR JUSTICE FRASER: But that's where his evidence was to
where he had identified the numbers.
MR DE GARR ROBINSON: My Lord, I see that.
So moving back to my line of questioning, I was
asking you whether finding only 29 bugs strongly
suggests that there aren't thousands more bugs in the
system in the way that you seem to suggest at paragraph
3.105?
A. No, but that's referring to "potentially thousands more
PEAKs". PEAKs are occurrences of bugs.
Q. I see. But I thought -- I may have misunderstood your
evidence then, Mr Coyne, because I thought you just told
me that once you had a KEL identifying a particular bug
it is relatively easy to find all the PEAKs to which
that KEL is relevant, yes?
A. Yes.
Q. And I think you established with me that you had done
that and that the result of that process is the column
in joint statement 2 that we have just been looking at?
A. Yes.
Q. Could I ask you, Mr Coyne, if you were to add up all the
PEAKs that are referred to in that second column in
joint statement 2, will it demonstrate that there are
thousands more PEAKs that are relevant?
A. I would have to go through and add them up. It is not
something that I have done at this stage.
Q. You are making a claim here, Mr Coyne, that there could
be -- you don't just say -- yes, "potentially thousands
more PEAKs". But even when you wrote that sentence you
had it in your power to actually work out how many more
PEAKs we are talking about, didn't you?
A. No, I have worked out the number of PEAKs that relate to
the KELs and the numbers will be in here. But there
could well be many more PEAKs that don't have the
references to the KELs.
Q. Well, aren't you contradicting some evidence you gave to
me a few minutes ago, Mr Coyne, in order to preserve
your position on that second sentence? Because before
I think you told me that once you identify a KEL it is
actually quite easy to then find all the PEAKs to which
the KEL is relevant.
A. Yes, that is right.
Q. Right. So the simple fact is that in order to
demonstrate the truth of the statement:
"... there are potentially thousands more PEAKs that
illustrate financial discrepancy ... in branch accounts
..."
All I have to do is go to column 2 of joint
statement 2 and add up all the numbers. Do you think
there is a remote possibility of all those numbers
coming to thousands, plural?
A. No, I don't believe -- I'm just looking through now to
see if there's any that has an impact on ... It is
possible that there is a PEAK that has an impact on, for
example, 100 branches but I don't know whether that's
the case or not, we would have to look through.
MR JUSTICE FRASER: One says 88, I think.
Mr de Garr Robinson, do you want the witness to do
a more detailed arithmetical analysis of that column, is
that what you are asking him to do?
MR DE GARR ROBINSON: My Lord, I'm asking the witness to
accept that in actual fact, having done all the work
that he has done, and having produced the results which
are now recorded in the second column which I freely
admit I haven't fully understood and I'm grateful for
Mr Coyne's clarification, it doesn't get anywhere near
thousands more PEAKs.
MR JUSTICE FRASER: So, Mr Coyne, that was a question to
you.
A. I'm content with the answer that I have given that there
is the potential for there to be up to 1,000 PEAKs
because you don't -- you only need to find a few more
KELs that have impacts such as the bug, error or defect
that impacted 88 branches to get to 1,000.
Q. Here's what's interesting, Mr Coyne. What we have is
what might be called an example of evasion. The claim
you make in 3.105 is that there are potentially
thousands, plural, more PEAKs, and do you see what you
did with your answer? You went down to up to 1,000 in
order to maintain your position.
What I'm suggesting to you is on the very process
that you have described to this court, on oath, and your
explanation of the documents and how they work and the
kind of things that they show and the things that they
are likely to contain, it stands to reason as night
follows day that there are not thousands more PEAKs in
the PEAK corpus that illustrate financial discrepancy
arising in branch accounts, would you accept that?
A. I don't accept that. I don't accept that that position
that there are potentially thousands more is incorrect.
Q. Well, I'm not sure I can go any further with this at
this point, Mr Coyne.
Let's analyse other examples where you use words
suggesting that things happened on a large scale where
in fact that might not be the case. Can we go to your
first statement {D2/1/38}, please. At paragraph 3.18 --
A. Sorry?
Q. Of your first report.
MR JUSTICE FRASER: 28. I think you said 38.
MR DE GARR ROBINSON: I'm so sorry.
MR JUSTICE FRASER: Let's go to 28.
MR DE GARR ROBINSON: {D2/1/28}. At 3.18:
"Many ... (KELs) identify that not all errors were
understood even by Fujitsu. In the circumstances, it is
highly unlikely that a Subpostmaster could interpret or
identify the causes of any bugs/errors or defects when
Fujitsu themselves often did not understand the cause of
such or their full effects."
So you have got another use of the word "often", do
you see that?
A. Yes.
Q. And no indication is given of the scale of the word
"many" or the scale of the word "often", what kind of
numbers you are discussing. Would you agree with me,
Mr Coyne, that 10, for example, is hardly material given
the scale of Horizon and the long period over which it
has been in operation, yes?
A. 10 KELs?
Q. Yes.
A. When you say it is material? I don't --
Q. Let me change the question. Use of words like "many"
and "often" are capable of being really dangerous,
aren't they, because they are capable of giving
an impression unless you are clear about the scale of
the occasions which you believe to be shown by the
evidence, yes?
A. Yes.
Q. And what scale -- when you say "many" and when you say
"often", what scale of numbers are you referring to in
that paragraph, can you recall?
A. No, I can't recall. There is a number.
Q. In paragraph 5.64 at page {D2/1/71} of the same
document, the last sentence in that paragraph:
"I have noted that hardware replacement often seemed
to be a 'fix' of last resort where no other explanation
could be given, and therefore there is certainly a
possibility that hardware was at fault."
Now you see there is a footnote there. Do you see
that, footnote 88?
A. Yes.
Q. Perhaps we could have a look at that, it is {F/178/1}.
This is a KEL, it is dated -- it was raised on
18th November 1999, so it is very early in the life of
Horizon.
A. Yes.
Q. It was last updated in January 2004.
A. Yes.
Q. Under "Solution" -- and I see again that Atos is
referred to, which is very curious because Atos wasn't
on the scene for years until after 2004 and I do rather
think that there must have been some word-processing
change made at some point, I don't know how.
It says:
"This appears to be either the PM is typing ahead of
themselves and the system suddenly catches up, or
keyboard or screen fault generating spurious key
presses. Recommend that the PM tries not to type ahead
of the system (or to press the same key a number of
times if there appears to be no response from the
system) or to replace the keyboard and/or screen. PM
should select existing. This functionality has been
removed from CI4 ..."
Which I think would be a release. So there came
a point at which it was no longer a problem, yes?
A. Yes.
Q. Now, that's one example of a possible hardware fault,
yes?
A. Yes.
Q. How can that justify the claim that you make here that
hardware replacements are often a fix of last resort?
A. Well, there's a number of other examples. There is the
phantom transactions example where hardware was changed
because it was -- they were trying to work out whether
it was environmental issues or not that were causing
erroneous transactions. There are a number of examples.
There is only one cited here but there are a number of
examples throughout the report.
Q. Are we talking about five examples or are we talking
about 100 examples?
A. There will certainly be five examples that --
Q. I see. So there "often" means something in the region
of five, does it?
A. Yes.
Q. Then if we move on to page 97, paragraph 5.161
{D2/1/97}:
"Whilst both Horizon and Horizon Online contain a
number of measures and controls designed to check system
integrity, these mechanisms have been shown to have
failed. This is a point agreed upon in the Joint
Statement. It has been identified that known
issues/bugs were often deferred and dealt with on a
cost/benefit basis."
That is a paragraph that we have discussed before
and I have already suggested to you that the evidence
gives no basis for claiming that it happened "often".
But more importantly, I would like to ask you what
you mean by "often" in that sentence. Again you give no
scale, no sense of how many times we are talking about.
Are we talking about five times, ten times, a hundred
times?
A. Quite a few times. There is a document that looks at
defect deferment, so a number of defects have been
identified but they are deferred to be dealt with later,
although they acknowledge that they could have an impact
on branch. This was the point that we discussed
yesterday.
Q. This is the handful of PEAKs that you provided to me
this morning, is it?
A. Yesterday we were taken to an incorrect reference in the
document and --
Q. Do you mean a document you had incorrectly referred to
in your statement or did I take you to a wrong document?
Because if it is the latter, I'm terribly sorry.
A. Sorry, I think it was as a result of -- Mr Green
interjected and directed to a document, but the document
wasn't provided at the side of Magnum, so we should have
gone to the footnote. I would like to go there if
that's possible.
Q. I'm afraid I don't actually know what you are talking
about. Does Mr Green?
MR GREEN: My Lord, I didn't want to press my intervention
yesterday. I will explain it in re-examination. But
5.166 is the paragraph which gives context to what
I mentioned yesterday.
MR DE GARR ROBINSON: The document we looked at just before
we broke?
MR GREEN: No, it is the release note.
MR DE GARR ROBINSON: Oh, I see.
MR GREEN: In the context of which there is an example.
MR DE GARR ROBINSON: Very good.
So in answer to my question what's the scale of
"often" in that sentence, what would your answer be?
What sort of number of cases are we talking about?
A. A number, it will be the number that's actually
contained within that document at footnote 156.
Q. Okay. So the answer is to be found in that footnote, is
it? Thank you, I will look at that later.
Let's move on to your second report at {D2/4.1/14}.
If we could go to page 14. At paragraph 3.13 you say:
"For example, it appears that PEAKs are often closed
or suggested to be closed if analysis has paused or has
not uncovered a full diagnosis despite the Subpostmaster
and/or Post Office not having a conclusion. It is also
not always clear whether a Subpostmaster was informed
..."
Then at the end you say:
"I have seen PEAK records that are closed despite
support not being able to diagnose a root cause whilst
acknowledging that there clearly is some form of
error ..."
A. Yes.
Q. You will I think recall that my instructing solicitors
wrote to Freeths to ask which PEAKs were being referred
to.
A. Right.
Q. If we could look at {C5/36/1}, please. Go to page
{C5/36/2}, paragraph 1. Here is Freeths' answer to that
question. The question is:
"Please identify the ... PEAKs [referred to in that
paragraph]."
And the answer comes, there are nine PEAKs referred
to. Do you see that?
A. Yes.
Q. I don't have time to take you to them, there are
subtleties in those documents which might otherwise be
put. But are you aware that of those nine PEAKs there
have been only two examples since 2002?
A. I don't understand the question. So within those
PEAKs --
Q. Of the nine, seven of them occurred between 1999 and
2001.
A. Right.
Q. One is from 2012 and one is from 2017.
A. Right.
Q. So the truth is that over the past 17 years this has
happened, or there are PEAKs showing this as having
happened twice, yes?
A. Yes, okay.
Q. Bearing in mind you are making a claim about these
things often happening, could I suggest to you it might
have been helpful and balanced for you to have indicated
that that was the position?
A. Yes.
Q. That most of these occasions occurred during the very
early years of the original Horizon. Do you accept
that?
A. Yes, it would have been helpful to include that.
Q. If I can take you to another example just before we
break. At 5.108 at page {D2/4.1/156} it is said:
"At paragraphs 251 to 257 of his report, Dr Worden
refers to the concept of 'User Error Correction'
enabling the facility of correcting many software
errors. It should be noted that this would not apply to
any bugs/errors and defects unbeknownst to Fujitsu or
the Subposmaster. It is evident from the PEAK analysis
that often bugs lay undetected for weeks, months or
years."
My instructing solicitors wrote in the letter that
we have just discussed, wrote a letter asking which
PEAKs show that happening, and the response came at
paragraph 9.2 of the letter, that's {C5/36/5}.
The answer was:
"Please refer to Mr Coyne's Supplemental Report
(particularly paragraph 3.26 to 3.54) which sets out
commentary in respect of various bugs ..."
Now paragraphs 3.26 to 3.54 are the section which
I think is headed "Acknowledged Bugs" but it is actually
the four bugs, the four main bugs, that you focus on in
your report, namely the three bugs identified by
Post Office plus Dalmellington. Do you remember that?
A. Yes.
Q. No particular reference is made to any other bug in this
context. How many other bugs do you say lay undetected
for weeks, months or years?
A. Well, there was certainly Dalmellington.
Q. Yes, that's one of the bugs referred to in those
paragraphs. Let's not worry about weeks because one can
understand why it may take time for a bug to be
detected, but months or years. In your list of 29 how
many other bugs lay undetected for months or years, can
you tell me?
A. I can't. I would have to go through and --
Q. Could you give me a scale? Between one and four? Ten?
Any idea at all? It is just that by using the word
"often" it suggests to me that you have a clear idea in
your head, Mr Coyne.
A. Well, I will have had a clear idea in my head, I just
don't know what the actual number is now that you are --
Q. An approximate number, a scale. Can you give me any
indication?
A. No, I would prefer to work it out properly and give you
a proper answer to that.
Q. That is entirely fair.
Let me ask one last question before the break. In
relation to bugs that are detected after a period of
time there's evidence showing, I am sure you all agree,
that investigations are undertaken by Fujitsu to ensure
that all the branches that are affected in the meantime
are identified, are you aware of that evidence?
A. Yes.
Q. It is said that this is a standard process undertaken by
Fujitsu when they identify a bug that could affect
branches, yes?
A. Yes.
Q. Do you have reason for thinking that that has not
happened in any number of cases?
A. I am aware of one where the data was no longer available
to investigate it.
Q. Which bug was that?
A. I would have to find the example. It is in the report.
Q. I see.
A. I would have to find the example. I know that on
Dalmellington there was I think at least two occurrences
where Fujitsu weren't able to identify what the impact
actually was. They were able to identify the number of
branches --
Q. We will come to Dalmellington. So it is Dalmellington
and one other, those are two examples you are aware of,
is that right?
A. I've certainly got an example of another, yes.
Q. Are you aware of any other examples of this not
happening?
A. No.
MR DE GARR ROBINSON: My Lord, I don't know whether this
would be a convenient moment?
MR JUSTICE FRASER: We will come back at 3.15 pm. 10
minutes.
(3.05 pm)
(A short break)
(3.15 pm)
MR DE GARR ROBINSON: Mr Coyne, I would like to suggest to
you that ultimately the main number in this case is the
impact, the financial extent of bugs in Horizon, do you
agree?
A. Yes.
Q. But it is interesting that you don't address that in
your reports, do you?
A. The actual amount of the impact?
Q. Yes.
A. No.
Q. You have not been prepared to venture any figure which
estimates the total impact in financial terms of bugs in
Horizon, yes?
A. That is right, yes.
Q. Might I suggest that with your experience of IT risk
analysis, you are perfectly capable of setting out at
least in broad terms a view of the extent of the losses
caused by the bugs that you have identified?
A. The best that I could do would be to go through the
PEAKs and write down the numbers that were said to be
wrong but I do not think that would be a very
satisfactory way of doing it.
Q. What I suggest to you is that if you were to do that
process or perform any judgment at all as to financial
impact, you wouldn't find a number which remotely
supports the claimants' case, would you accept that?
A. I haven't looked at the detail of the claimants' case.
MR JUSTICE FRASER: Just hold on one second.
Mr de Garr Robinson, are you pursuing those
questions as part of what ought to have been done on
particular Horizon Issues or just as a general umbrella
question?
MR DE GARR ROBINSON: Both.
MR JUSTICE FRASER: As a general umbrella question it is not
a question for the witness. But if you want to pursue
it in terms of: to answer this Horizon Issue properly
you ought to have done that, then you should do it by
reference to the Horizon Issues.
MR DE GARR ROBINSON: Well, my Lord, I'm putting my case to
the witness and that case is based upon what's in
Dr Worden's expert report.
MR JUSTICE FRASER: No, I --
MR DE GARR ROBINSON: To which I will be coming in due
course.
MR JUSTICE FRASER: Mr de Garr Robinson, this witness is
giving evidence on the Horizon Issues.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: I'm not saying don't put it, I'm saying
if you are doing it in terms of: in order to address the
Horizon Issue correctly, you need to identify it by
reference to a Horizon Issue.
MR DE GARR ROBINSON: My Lord, I have a case to put which is
based upon my expert's report. The questions I am
putting are establishing the building blocks for putting
that case and I would be obliged if your Lordship would
let me do that.
MR JUSTICE FRASER: But Mr de Garr Robinson, the two experts
have approached each of their separate -- the same
exercise, they have approached it in different ways.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: That's the point.
MR DE GARR ROBINSON: And I have to put my case to this
witness, my Lord.
MR JUSTICE FRASER: Yes, but he is called to give evidence
on the Horizon Issues. I'm not saying you can't put the
question, what I'm saying is you need to put it by
reference to the Horizon Issues that he is giving on
rather than just arguing your case.
MR DE GARR ROBINSON: My Lord, I don't want to argue my case
with this witness which is why I would like to ask him
questions rather than engage in argument about
particular Horizon Issues. If your Lordship is saying
that I have to argue with him about particular Horizon
Issues then I will do that, but I would respectfully be
obliged if your Lordship would let me put my case.
MR JUSTICE FRASER: Mr de Garr Robinson, you are slightly
misunderstanding two things. You are misunderstanding
that cross-examination is just arguing with him, which
it isn't.
MR DE GARR ROBINSON: Well, exactly.
MR JUSTICE FRASER: What I'm saying is by reference to
Horizon Issues upon which he gives evidence, if you are
going to put to him: in order to have fulfilled that
properly you should have done X, Y and Z, and you
haven't, then you can put the question, but you need to
peg it back to the Horizon Issues.
MR DE GARR ROBINSON: My Lord --
MR JUSTICE FRASER: I think I have now said that three
times.
MR DE GARR ROBINSON: You have.
MR JUSTICE FRASER: And I do not think it is a controversial
point. If you want to make it a controversial point in
due course in submissions you can.
MR DE GARR ROBINSON: My Lord, let me explain to
your Lordship where I'm going. I'm loath to do that in
front of the witness, but let me explain.
MR JUSTICE FRASER: Hold on a minute. A couple of minutes.
Just for the transcript, I'm asking the witness to
step outside.
(In the absence of the witness)
MR DE GARR ROBINSON: I am going to take the witness to
section 8.5 of Dr Worden's report.
MR JUSTICE FRASER: Yes.
MR DE GARR ROBINSON: In which he says that in order to have
sufficient bugs to even begin to justify the claims
being made by the claimants there would need to be in
the region of 40,000, and I'm going to put it to him
that that's right.
MR JUSTICE FRASER: Yes.
MR DE GARR ROBINSON: Now, is your Lordship going to permit
me to do that?
MR JUSTICE FRASER: Yes, of course. But the question you
asked him was:
"If you were to do that process or perform any
judgment at all as to financial impact, you wouldn't
find a number which remotely supports the claimants'
case ..."
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Now, by "number", I take that to mean
financial number as in pounds, not shillings anymore,
and pence. Is that right?
MR DE GARR ROBINSON: Yes, that's --
MR JUSTICE FRASER: But that is not part of one of the
Horizon Issues.
MR DE GARR ROBINSON: That's the point that's put in
section 8.5 of Dr Worden's report, my Lord.
MR JUSTICE FRASER: Well, if you are going to suggest to
him -- I'm going to deal with it on this basis. As
I made clear, I think, I'm going to let you put the
question and pursue that line by reference to
Dr Worden's evidence, but if you are going to maintain
to this witness that in order properly to have addressed
each of the Horizon Issues he should have come back --
or, sorry, he should have arrived at an financial impact
figure, which is a point I'm saying I'm allowing you to
put, you need to do it by reference to which Horizon
Issue you say he could only address properly if he did
that exercise. Is that clear?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: All right.
MR GREEN: My Lord, just before he comes back in, the
question that was put at {Day15/147:18} was:
"Might I suggest that with your experience of IT
risk analysis, you are perfectly capable of setting out
at least in broad terms a view of the extent of the
losses caused by the bugs that you have identified?"
And the suggestion in cross-examination we hadn't
done that anywhere, there are various examples. At
{D2/4/29} there is a table, and so forth.
MR JUSTICE FRASER: Mr Green, you can --
MR GREEN: I know it is a separate point.
MR JUSTICE FRASER: Mr Green, it is a separate point and,
with respect, you can wrap those points up in your
re-examination. If Mr de Garr Robinson is putting
a point which is clarified by a reference, the time at
which to do that is in re-examination.
Just before we have the witness back in, I think
I've made it quite clear I have a fairly light touch in
terms of your cross-examination. I'm neither steering
you one direction or another, I'm giving you virtually
free rein, but there is a limit to the free rein because
it has to be done by reference to the Horizon Issues
which is what the trial is about. The Horizon trial is
completely different to the individual claimants' cases
or their financial losses, for example.
MR DE GARR ROBINSON: Absolutely, my Lord.
MR JUSTICE FRASER: Right. Can we have the witness back in
please.
(In the presence of the witness)
MR DE GARR ROBINSON: Now Mr Coyne, could we first of all go
to bundle {C1/1/1}, please, which is the Horizon Issues.
I can take any of them, but I would like you to look at
Horizon Issue 1 when it comes up on the screen. I am
sure you have read it many times.
A. Yes.
Q. It begins with the words:
"To what extent was it possible or likely ..."
That's a question which is asking the experts to
explore the likelihood of bugs in Horizon causing
shortfalls in postmaster branch accounts, correct?
A. Yes.
Q. As I suggested to you I think this morning, but it may
have been after the luncheon adjournment, there are many
different ways or there are various different ways in
which an assessment could be made of extent of
likelihood, yes?
A. Yes.
Q. One of those ways that might be thought to be very
helpful in the context of this case is to consider
whether the likely extent of bugs in Horizon has any
chance of justifying any significant part of the claim
that is made by the claimants, would you accept that?
That would be a useful measure to adopt in a case of
this sort?
A. Sorry, could you put the question again? I do not think
I understand the question.
Q. Horizon Issue 1 requires the experts to consider the
extent of the -- and I'm using shorthand now --
A. Yes, that's good.
Q. I hope it is not controversial. The extent of the
likelihood of bugs in Horizon causing shortfalls in
branch accounts.
A. Yes.
Q. And I'm suggesting to you that one useful yardstick for
measuring extent is whether the likelihood in this case
is of any sort which could begin to justify the claims
that these proceedings are designed to decide.
A. Yes.
Q. And do you accept that that could be a useful yardstick
for measuring extent in the context of this case?
A. I can see how it might be one of the contenders for
that, yes.
Q. Thank you. Now you know, because Dr Worden said so in
his first joint statement, that Dr Worden was going to
look at extent in that kind of way, yes?
A. Yes.
Q. He was going to look at financial impact?
A. Mm.
Q. And see whether the likely financial impact of bugs,
which there were likely to exist, would have any chance
of justifying the sort of claim, the sort of assertions
that are being made in the context of these overall
proceedings?
A. Yes.
Q. So you saw that he was going to do that and you have
refrained from doing that, correct?
A. Yes.
Q. What I suggested to you before you very kindly stepped
out was you could have done that. You could, using your
skills as an IT risk analyst, you could have, by
reference to the KELs and the PEAKs that you had
identified, formed an assessment as to the likely
financial impact in each of the instances that you had
identified?
A. Yes, I could. If I could please answer that by way of
illustration to the problem with that approach.
Q. Please do.
A. We will often see a bug, error or defect with a very
wide range of impacts and the impact is typically
whatever the counter was doing at that point in time.
So if the counter was doing a foreign currency
transaction for just £50 and something goes wrong, the
discrepancy may be £50.
By knowing that there is a bug, error or defect in
the Horizon system that leads to problems with foreign
currencies, you can't then say it is only a £50 defect
because that isn't incorrect. If another person was to
be subject to that defect and they were doing a £10,000
foreign currency transaction, they would likely have
that same level of defect.
Now that's an illustration to say you can't value
bugs and their potential impact by looking at what has
happened historically. You can't value it in that way.
Q. But what you can do is form an estimate having regard to
the totality of the PEAKs that you have seen, can't you?
A. But it is a fundamentally flawed approach. If you have
seen three branches that have had an impact because they
were doing three foreign currency transactions, a £20,
a £50 and a £100, but then there is a fourth person that
believes that they have been subjected to that but that
isn't recorded, you can't simply look at the three where
it has been recorded and say the fourth couldn't
possibly have occurred because we know there is a defect
there.
Q. I'm not suggesting that you could arrive at a certain
conclusion of an absolute cast iron number, but I repeat
my question. Can't you form an estimate having regard
to the totality of the PEAKs that you have seen?
A. Yes, but your estimate would have to be based on the
three people where it has been recorded to have
occurred, so you would say £20, £30 and £50, and the
best you could possibly do is come up with an average of
that, and you would say that the value of that defect is
whatever that is.
Q. There is another way that you could do it, isn't there,
which is that you could look at the three bugs, the
receipts and payments mismatch, the suspense account bug
and Callendar Square, the ones that have been thoroughly
investigated, and you could form inferences from the
scale of those bugs, yes? Would that be reasonable?
A. For those types of bugs, potentially yes.
Q. Those are quite large bugs, aren't they? They are not
small bugs in the scheme of things. That's why they
were identified in the letter, because these were major
bugs of which even Post Office was aware?
A. Yes. And carrying on from the one we were not told
about until later, the Dalmellington one, there were
some which were only pounds, just a few pounds, and
I think there was at least one that was £25,000.
Q. But just fixing our attention for the moment on those
three bugs, would you accept that the evidence indicates
that altogether the total financial impact of those
three bugs is no greater than £100,000. Do you agree
with that?
A. No, I haven't done that so I would not know whether that
was right or close to right.
Q. You are aware of the calculations that were made by
Fujitsu and the documents setting out the financial
impact of those three bugs, and you are aware, aren't
you, that that calculation has resulted in a figure that
is less than £100,000? Would you not accept that for
the purposes of forming an estimate and scaling up from
some examples, it would be useful to take that kind of
figure as an example of sizeable bugs and start doing
calculations on the basis of that sort of figure?
A. No, I don't accept that that's --
Q. Do you have any evidence to suggest that the financial
impact of those bugs was more than £100,000?
A. I don't know. Looking at Dalmellington there was
a £25,000 in there, but I don't know what the outcome of
that was, how that was fixed.
Q. Do you not accept -- sorry, you don't know -- you just
made a point about Dalmellington. You don't know how
Dalmellington was fixed?
A. The document talks about -- I think there was only two
that they didn't know how it was fixed. The majority of
them had been fixed by some form of correction to --
Q. All but -- you will remember there are two Dalmellington
documents, the first one covered -- identified 118
branches affected and dealt with 114 of them?
A. Yes.
Q. And as it happens all of those branches had been
actually made good already because of the
countermeasures that existed in the Horizon system, yes?
A. Yes.
Q. So of the 114 branches that were affected by the
Dalmellington bug, in fact there was no lasting impact
on any of those 114 branches, was there?
A. I think there was two that Fujitsu wasn't aware of.
Q. I have asked you about the 114. You are trying to talk
about the other four, aren't you?
A. Yes. They were corrected, yes.
Q. So we can lay the 114 to one side, because the answer to
the question: what was the lasting impact of the
Dalmellington bug on those 114 branches? The answer is
zero, correct?
A. Yes.
Q. So we then move to the other four branches which were
dealt with with another document, which I can tell from
your answers you are completely familiar with. There
were four branches, weren't there? Two of them appeared
to have large impacts?
A. Yes.
Q. And the other two had impacts of around £1, I think one
of them was pennies?
A. There were some very small ones.
Q. So shall we lay the pound and the penny to one side for
a moment?
A. No, because if that indicates a defect then it depends
what transaction it was doing, so we can't lay any of
them to one side.
Q. Let's talk about the other two which I think were the
two you wanted to talk about, yes?
A. Yes.
Q. Those two, it turned out, weren't examples of
the Dalmellington bug and they didn't suffer any loss,
did they? There is another document which contains
an analysis which demonstrates that, do you recall?
A. I don't recall, no.
Q. Very good. Well, let's lay those two aside. So we have
got two bugs, one of which is for about £1 and one of
which is for pennies, and we have 114 branches that were
affected, all of which were made good by the
countermeasures that existed in the system, yes? And
are you suggesting that the two branches that hadn't
been hunted down, that had a £1 deficiency and a
deficiency of two pennies, are you suggesting that it is
to be inferred that those two branches uniquely weren't
corrected by those countermeasures?
A. No, it should be the case that it all was corrected.
Q. Very good. So would you accept that in relation to the
Dalmellington bug, the overwhelming likelihood is that
that bug caused no lasting deficiencies in branch
accounts?
A. By "lasting" -- well, can you help me by saying what you
mean by "lasting"?
Q. A deficiency that wasn't made good either by the SPM
actually reversing the remming error, because of course
Dalmellington was a bug which caused people to rem in
amounts more than once when they -- which is why it
looked like human error, and why it was picked up by the
system and fixed as time went on.
A. Yes.
Q. That's why it took so long. It is one of your examples
of a bug that took a long time to identify.
A. Absolutely.
Q. But the reason why it took a long time to identify was
because it looked exactly like a human error, didn't it?
A. Right.
Q. Right. All of those instances were picked up by the
system and either the SPM himself reversed the rem in
some way and made himself good, or it was picked up by
Post Office and TCs were sent, correct?
A. Yes.
Q. So that's what I mean by saying in relation to the
Dalmellington bug there were no lasting deficiencies, no
lasting shortfalls for which SPMs were ultimately made
liable?
A. Yes, I think that is right. I think once everything was
detected everything was made good.
Q. In fact, Dalmellington is quite a good example of how
countermeasures need to be brought into account and how
it is important to look at financial impact to make
an assessment of the extent question that's raised in
Horizon Issue 1, isn't it? Because it is no good saying
118 branches were affected and some of them were
affected by large amounts, when in fact we all know that
even before the bug was detected the branches involved
were in fact made whole anyway, yes?
A. It does suggest that, but it also suggests that there
were deficiencies with the countermeasures because
I believe it was five years after the first occurrence
of the bug that the defect was finally discovered.
Q. Because, as you have already agreed, to an outside
observer it looks exactly like a human error because it
was a human error. The bug wasn't causing losses, it
was causing errors to be made and those errors were
picked up, would you agree with that?
A. No, it wasn't a human error, it was a defect of the
system. It made it look like a human error.
Q. That's for another day.
Going back to these three bugs. Do you have any
reason for thinking, any evidence to suggest, that the
receipts and payments mismatch bug, the suspense account
bug and the Callendar Square bug had a total net impact
of more than £100,000?
A. As I said previously, I have not gone through and noted
all the impacts of those so I could not give you
a number.
Q. Would you accept that the best evidence is that the loss
was under £100,000?
A. That still requires me to work out what the number is.
All I can tell you is that it would appear that the
receipts and payments mismatch, it was about 60 branch
accounts that were impacted, but without going through
and looking at the numbers I don't know.
Q. Well --
A. It was 30 per Callendar Square.
Q. Dr Worden has done that in his expert report, you
recall, yes?
A. Mm.
Q. Are you aware of any evidence to suggest that
Dr Worden's analysis is wrong? Is there any evidence to
challenge his calculations in relation to those three
bugs?
A. No. I understand the process that Dr Worden has gone
through, he has looked at the numerical values that are
recorded in the PEAKs for the branches that are
available that are recorded in there and he has added
those up, so I do not think his maths is going to be
wrong.
Q. So if we were to take those these bugs as some kind of
indication of fairly sizeable bugs that might appear in
the system, it is fair to say, isn't it, that £100,000
is quite small compared to the £19 million that's
claimed by the claimants in this case. It is less than
1%, correct?
A. Just on the pure numbers, yes.
Q. So these three bugs, which are the ones we know most
about, do not by themselves even begin to support the
claimants' case, do they?
A. But the numbers that are given are only the numbers that
are in the PEAKs, and the PEAKs only reflect where
Fujitsu have become involved and have started to
investigate the impact of those bugs from the branches
that they are aware of.
Q. So assuming that £100,000 represents a fair assessment
of the impact of those bugs, what would you say? You
would say, well, they are the tip of the iceberg. There
are many more bugs that are capable of producing the
kind of financial loss that would justify the claimants'
claim, would you say that?
A. Well, it is my position that there's many more than the
three and I have set out these here.
Q. In paragraph 3.105 of your report you said potentially
thousands, but I think you have moved from that now.
Now you are saying perhaps up to 40, yes?
A. On the logic that we went through before, yes.
Q. Well, you accepted that logic, didn't you?
A. My position as stated in the report is that there is the
potential for more.
Q. Well, I won't go back over the answers you have already
given in cross-examination, Mr Coyne.
Do you accept that 40 bugs are plainly nowhere near
enough to have caused the claimants the shortfalls that
they are seeking to recover?
A. I don't accept that position. Because the bug impacts
the transaction that would be in effect at the time, if
it was a large transaction at the time then the impact
of that bug would be a lot larger. In the alternative,
they may have experienced the bug a number of times but
on smaller transactions.
Q. Well, let's see if we can agree some steps here about
what can properly be done to scale up in this case.
Could I ask you to go to bundle {D3/1/148} at page 148.
A. Yes, I have that.
Q. This is Dr Worden's first report and he says at
paragraph 6.19:
"Over the period 2000-2018 the Post Office network
has consisted of more than 11,000 branches. The mean
number of branches in all years over the period has been
about 13560."
And he explains how the figure is derived.
"If this evidence is accepted, the number of 'branch
months' (a single branch, trading for a single month)
has been ... 3,091,680. This is the number of monthly
branch accounts that have been produced."
I believe you have agreed that figure with Dr Worden
in one of the joint statements, yes?
A. Yes.
Q. That leaves Dr Worden to formulate what he describes as
a scaling factor between on the one hand the number of
bugs on all branches over the lifetime of Horizon and
that's what he calls scope A, and on the other hand the
number of bugs on one claimants' branch in any one
month, and that scaling factor is 3 million. Do you
accept the basic logic as a starting point?
A. I don't believe I do, no.
Q. You do refer in your report, Mr Coyne, to technical
flaws in Dr Worden's analysis?
A. Yes.
Q. If you look at paragraph 620 is there a technical flaw
in what Dr Worden says there {D3/1/148}?
A. No, I don't believe so.
Q. There is no technical flaw?
A. No, if the 3 million has come from the 3 million branch
months.
Q. Then what Dr Worden has done is he has considered where
there is evidence showing the need to adjust that factor
to account for the possibility that the claimants'
branches may not be typical when compared with the
general body of sub-post office branches?
A. Yes.
Q. They might be more or less likely to be hit by bugs than
your average Post Office branch?
A. Yes.
Q. And he sees no such evidence other than in relation to
their size, do you accept that logic?
A. I don't accept that logic, no. We see from the bugs
that are reported that bugs appear to impact branches
differently and one bug may hit a branch a number of
times and only hit a handful of branches, and there
doesn't appear to be any -- well, there will be
an underlying technical reason for that but it is often
down to the way that that branch is configured or the
processes that they follow.
Q. Do you accept -- no, let me ask you this. Are you aware
of some special factor applying to the claimant branches
which marks them out as very different from the rest of
the branch network making their susceptibility to bugs
very different from the wide range of branches in the
rest of the network?
A. I'm not aware of it, no, but it would require -- in
order to look at that it would require a detailed
understanding of the particular processes of the
branches. And I think that's illustrated by what we
know of Dalmellington, that impacted -- I think one
branch was impacted five times, where there was only
a handful of branches -- I think, was it 88 that was
impacted in total?
Q. Mr Coyne, it is quite important not to get confused
between particular instances of things happening and the
law of averages. What I'm asking you about is what's
likely to happen over a large number of cases, do you
understand the difference? So of course if people are
all walking down the streets, some of them are going to
get hit by lightning. Everybody won't get hit by
lightning in the same way. It will be a very small
number of people who will be hit by lightning and
they'll usually be in particular situations when it
happens. But one can make a generalisation about the
likelihood of people being hit by lightning, do you
understand, because of the law of averages?
A. I do understand, but in that illustration it would be
very unusual for one person to be hit by lightning five
times.
Q. But it has happened. I remember, goodness gracious me,
watching a programme, I think it may have been
Blue Peter when I was a child, where precisely such a
thing had happened.
That's the point, that one has to step back from the
particular. When undertaking statistical analyses one
has to step back from the particular and look at the
broad range of consequences applying the law of large
numbers and what's conventionally known as the law of
averages. You do understand that?
A. I do understand that, yes.
Q. And are you suggesting that you are aware of any factor
relevant to the claimants' branches that means that
there's some material, significant -- that they have
some significant feature that takes them away from --
that makes them completely different from the broad
range of branches that exist in the Post Office network,
large and small?
A. No, I'm not aware of it, but my suggestion is that in
order to conduct that you should ensure that they are
representative before using the law of averages.
Q. Well, one thing that Dr Worden has done is he has
considered the size of the branches. Unlike you, and
I'm not making this by way of criticism, but he has
thought about this very question to see whether there
are any real differences between the broad range of
branches in the network and the claimant branches and he
has spotted that claimant branches tend to be smaller,
okay, in the sense that they do fewer transactions per
day on average than the average Post Office branch.
Yes?
A. Yes.
Q. He does that at paragraph 623 on page {D3/1/149} of this
document, and he reaches the conclusion that he sets out
in paragraphs 624 and 625. Could I ask you to read
those three paragraphs, please.
(Pause)
A. Yes, okay.
Q. Do you accept that these calculations that he does there
in principle? There is no technical flaw?
A. I am sure the maths is correct, but again I'm not sure
that transactions is wholly the correct unit to use.
Has it been considered what the value of those
transactions are; whilst they do half the amount, do
they do high value transactions, does that have
an impact?
Q. Isn't that brought into account by -- isn't in forming
a calculation the first question you have to ask
yourself is: how likely it is that this branch is going
to be impacted? And then you have to form an assessment
of what the size of impact is likely to be, yes?
A. Yes.
Q. At this point in the equation what Dr Worden is trying
to do is to work out how likely it is branches are going
to be affected?
A. Yes.
Q. He reasons that branches with more transactions, doing
more transactions, are statistically over a large number
of occasions more likely to be hit by a bug than
a branch doing fewer transactions and would you agree
the principle underlying that observation?
A. I think that's probably a reasonable principle. If we
look at the defects we found though, there is probably
other factors that could be brought into that.
Q. But you are not aware of any, you are not in a position
to suggest a single factor which you have any evidence
to think actually applies in relation to the claimants
as compared with the rest of the branch network?
A. I don't know the make up of the claimant, but one
example might be, do they have an outreach branch?
Q. You are aware, aren't you, how small the number of
outreach branches there is, how insignificant that is in
the context of the Post Office network, aren't you?
A. Well, it wouldn't be insignificant to the people that
are impacted by the defect and I don't know whether any
of the -- because I haven't studied the claimants,
I don't know whether any of the claimants have that or
not.
Q. What you are doing is you are speculating that some of
the claimants might have outreach branches?
A. I'm not. I'm illustrating the potential problems with
the approach that you are taking just simply using the
unit of number of transactions.
Q. Mr Coyne, what I'm suggesting to you is that, in order
to suggest that there is a marked difference in
susceptibility to bugs as between the claimants and the
general -- other Post Office branches, one needs
a reason for doing it. It is not enough to sit in
an armchair and think of possible factors where you have
no basis for knowing whether the factors apply or don't
apply.
A. Yes.
Q. What you must do is simply work with the evidence that
you have and there is no evidence to suggest that there
is any particular preponderance of outreach branches
amongst the claimants as compared with the general
Post Office network, is there?
A. No, I'm not aware of the make up of the claimants. No.
Q. So when it comes to the calculation that's set out --
where is it?
MR JUSTICE FRASER: Are you looking for the smaller than
average?
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Because it is at 6 --
MR DE GARR ROBINSON: It is at 629 on page {D3/1/150}.
Thank you my Lord.
On the basis of the evidence that we actually have
in relation to the claimant branches, the process that
Dr Worden goes to in order to arrive at a scaling factor
of 0.37, there are no technical flaws in that, are
there?
A. No.
Q. Then in his second report, and perhaps we could go to
that, it is at {D3/6/30}, it is paragraph 113, Dr Worden
alighted upon a methodology that was more accurate,
an improvement. Could I ask you to read paragraphs 113
and 114.
A. Mm. (Pause). Yes.
Q. So here he refines his approach by aggregating the size
of all claimant branches across three years for which
data is available and then comparing that to the
aggregate size of all branches across all three years
and his view is that that is a more reliable approach,
would you agree?
A. It would appear to be a more reliable approach than the
approach that was being taken for before yes.
Q. That results in an increased factor of 0.45, yes?
A. Yes.
Q. You accept that that's a better approach in principle?
A. It is a better approach than the approach that was being
taken before, yes.
Q. And do you accept that on the information of which you
are aware, a scaling factor of 0.45 is in the right
ballpark? One can speculate that there might be other
information out there producing a different result but
taking account of the information of which you are
aware, that scaling factor is in the right ballpark,
yes?
A. Scaling based on number of transactions, yes.
Q. Thank you. What that means is that because they have
fewer transactions a claimant branch is less likely to
be hit by a bug than an average branch, you accept the
logic, yes?
A. No, I don't accept that logic, no.
Q. So do you suggest there should be a different scaling
factor?
A. No, I don't accept that because they do less
transactions they are less likely to be hit.
Q. Isn't it rather like going outside -- if we go back to
the lightning analogy. If people spend most of their
time inside a building, they are much less likely to get
hit by lightning than people who spend most of their
time out in the countryside, yes?
A. Yes.
Q. Doing a transaction is a bit like going out into the
countryside, isn't it? It makes you vulnerable to the
elements, yes?
A. Yes, but it is the types of transactions.
Q. You say types of transactions, Mr Coyne. All of these
branches did a wide range of transactions?
A. They do but some will do more of a particular type of
transaction than others.
Q. That's also true of the general body of the Post Office
network?
A. Yes.
Q. If there were some really curious difference between the
kind of business done by the claimant branches and the
kind of business done by the vast -- I mean you do
accept, don't you, that the non-claimant branches in the
Post Office network go from the very small to the very
large and can do a vast range of different kinds of
business?
A. Yes.
Q. If there were some feature that marked out the claimant
branches as different from the general Post Office
network branches, do you not think we would have
identified that by now?
A. It isn't a piece of work that I have done so I wouldn't
have identified it but I don't know whether anyone else
has looked at that or not.
Q. My suggestion to you, Mr Coyne, is that you are raising
an armchair objection on the basis not that you believe
this would actually produce a different result in this
particular case, but merely as an attempt to object to
performing an estimate which it is in fact open to you
and to Dr Worden to perform?
A. My perception is that it is a flawed process because the
units, the inputs to the process I don't believe are
correct. I'm not arguing with the maths, it is the
principles behind it that I'm not happy with.
Q. Let's move on. If you are genuinely saying it is
impossible to arrive at any judgment on these matters,
if you had to make a business decision about risk and
this was the only information available to you, you
wouldn't just sit there and say you couldn't make
a decision, would you? You would perform a judgment on
the best information you have, yes?
A. Yes, I agree with that, if a decision had to be made and
there was no other information available, then I would
use the best information that was available to me.
Q. And you would build in a margin of error, wouldn't you,
to account for the possibility that there may be
unknowns out there that could throw your figures out?
A. Yes.
Q. In the way that Dr Worden has done, correct?
A. Yes.
Q. Let me ask you this, you are suggesting that
susceptibility of bugs may change depending on the kind
of business that's done. Is it your view, having regard
to your close study of the 29 bugs that are in the JS2
bug list, is it your view that those bugs are such that
there is some feature in them which makes it likely that
the claimants are going to be more or less susceptible
to them than anybody else?
A. Not with regard to claimants because as I said I have
not looked at those but there are bugs in there which do
seem to be susceptible to particular branches.
Q. Now let's go back to Dr Worden's first report.
{D3/1/150} please and paragraph 630.
A. Yes.
Q. On Dr Worden's approach:
" ... Claimants' branches, being generally smaller
than Post Office average, have fewer transactions per
month and so are less likely to be hit by a Horizon bug
in a given month."
Here he refers to his 0.37 scaling factor.
"The factor 0.37 increases the scaling factor above,
between scopes (a) (see paragraph 617.1) and (c) (617.3)
from about 3 million to about 8 million."
Yes?
A. Right, yes.
Q. You accept that logic, don't you?
A. I accept Dr Worden's mathematics based on his logic,
yes.
Q. So if you take a bug which has occurred 16 times over
the lifetime of Horizon?
A. Yes.
Q. With a mean financial impact of £1,000 and that's quite
a significant bug compared with most of the bugs you
found, would you agree?
A. It is certainly significant in its impact, yes.
Q. It is in the top five, yes?
A. Quite possibly.
Q. And then you select a claimant branch a month at random,
the chance of that bug occurring in that branch in that
month is 16 in 8 million, correct?
A. If bugs affect branches equally, yes.
Q. And that's around 2 in 1 million and you have just
accepted the logic, thank you.
And the probabilities are obviously additive. So if
there is a second similar bug, the chances become 4 in
1 million and so on. So if there are 100 bugs it is 1
in 5,000, yes?
A. But all this is predicated on accepting that bugs affect
branches equally.
Q. Well let's do this Mr Coyne, let's assume that bugs
don't affect branches equally. I presume you are not
saying it is impossible to say -- I assume you are not
saying that the claimant branches are likely to be 100
times more likely to be susceptible of bugs?
A. As I say I don't know the make up of claimant branches
so I don't know about that. All I do know is that for
the bugs that I looked at they don't appear to impact
branches equally. Dr Worden referred to a rainfall
across a field, that isn't a concept that I accept.
Q. Which is why he changed it in his second report to --
A. Lightning.
Q. Do you remember? Or maybe it was the joint statement,
I can't remember.
A. Yes.
Q. What I'm suggesting to you, Mr Coyne, is that you don't
just throw up your hands and say it is theoretically
possible that a particular claimant branch or particular
set of claimant branches may do a particular kind of
business making them more or less susceptible to bugs
than other branches. You need to have -- it is
possible, isn't it, to have a sense of what the maximum
likely impact of that phenomenon is, yes? You are not
suggesting that the claimant branch is 100 times more
likely than any other branch bearing in mind that the
rest of the Post Office network contain branches from
large to small the entire spectrum of branches that
exist in the network?
A. The way I would approach this would be possibly the way
that Fujitsu did when they were investigating
Dalmellington by way of example, in that they know it
impacted 88 different branches but a number of those
were impacted multiple times.
I would have a look at the make up of those -- the
business process that was followed in the branches that
were impacted multiple times to find out why one branch
was impacted three times and nobody else has been
impacted at all.
Once you understand what it is within that business
process, you can then see from the knowledge you have
got within the Post Office and Fujitsu who else across
the estate operates in that same way.
Q. Mr Coyne, if we were just talking about one bug that
affected a particular event or transaction, then I would
understand what you are saying. But we are not, are we?
We are talking about a whole range of bugs operating and
being triggered in a whole range of different
circumstances?
A. Yes.
Q. So we have bugs which themselves have a scatter gun
effect and we have a scatter gun of branches all over
the country, some of which peppered all over the country
are claimant branches?
A. Yes.
Q. What I'm suggesting to you is that when forming
a judgment, trying the best you can do to make
an assessment on the information available, what you are
going to do in the absence of a strong indication that
there is some factor that justifies the inference that
all of the claimant branches are very different from all
of the branches in the rest of the network, is you adopt
the sort of approach that Dr Worden has adopted.
A. It isn't an approach that I would take. I wouldn't feel
confident in undertaking that type of approach.
Q. If you were making a business decision I think you
accepted that you would form a judgment that would be
the best judgment you could on the information you had,
correct?
A. Yes. I think that is in a different scenario, isn't it?
You are making a business decision.
Q. What it shows is that it is possible to make estimates
that have some materiality and could be of use when
forming judgment about human conduct, yes?
A. Yes.
Q. That's what Dr Worden has done and the calculation he
arrives at is that, as we have said and I think you have
accepted the logic of the position, that the chance of
the bug we have discussed occurring in a claimant branch
in a particular month are 2 in a million, and if there
are 100 such bugs the chance would be 1 in 5,000. And
that's what Dr Worden says at paragraph 634 on page 151.
Again do you accept the logic?
A. I accept the maths, yes.
Q. So for a bug to have even a 1 in 10 chance of hitting
one claimant branch in one month there would need to be
tens of thousands of such bugs, wouldn't there, yes?
A. Based on those mathematics, yes.
Q. Dr Worden says 50,000 in his first report but this
becomes 40,000 in his supplemental report because he has
chosen a different scaling factor, correct?
A. Yes.
Q. If it were to be a 5 in 10 chance there would need to be
200,000 bugs, correct?
A. That's what he says.
Q. If one were to assume that the scaling factor were very
different, you would still need an enormous number. You
would still need thousands of bugs, wouldn't you, to
even begin to have a chance of justifying the sort of
claim that is being made in this case. It is a matter
of commonsense, isn't it?
A. All I'm doing here is effectively just confirming
Dr Worden's maths, but I don't accept the process.
Q. You don't accept the process because you are seeking to
suggest there might be some factor you can't identify
which means that the claimant branches have a different
susceptibility to bugs when doing a transaction than the
branches in the rest of the Post Office network, yes?
A. Yes, quite possibly.
Q. What I'm suggesting to you, Mr Worden --
A. Coyne.
Q. -- is that even if you factored in some enormous number,
a substantial number, assuming the claimants were much
more likely than your average Post Office branch to be
susceptible to bugs, it would still be in the thousands.
There would still need to be thousands of those bugs
wouldn't there in order to justify anything like the
claim made by the claimants.
A. I don't have the detail of the claims by the claimants.
So I don't know the make up of them.
Q. Do you have any evidence that causes you think that
there are in fact that scale of bugs in Horizon,
thousands of bugs in Horizon? I'm thinking as a result
of the evidence you gave after lunch you don't, do you?
A. I don't -- there is the potential for that many in
Horizon but I think it will be likely somewhere lower
than that.
Q. Mr Coyne, the overwhelming likelihood is that there
aren't more than 40 bugs of the sort that you have
identified in Horizon, correct?
A. Yes, but what you have got to remember is each of those
bugs can have an impact on multiple branch accounts. It
is not just one bug, one impact.
Q. So are you suggesting that some of those bugs have
massive impact? Remember, we are not talking about bugs
that affect only the claimant branches. We are talking
about bugs that are in operation over the entire
Post Office network.
A. Yes.
Q. So on any view those bug impacts -- the total bug
impacts is going to be very, very much greater than the
specific impact that might affect the claimants, yes?
A. Yes.
Q. So the total impact of the kind of bug you are
suggesting, to justify the £19 million claim just made
by the claimants alone, the total impact of the kind of
bug you are hypothesising would have to be vast,
wouldn't it, in the tens and tens of millions?
A. If we are using the law of averages to show that it has
impacted everybody equally rather than just impacting
the claimants' branches, yes.
Q. I see. You are now suggesting that there might be bugs
which have only affected the claimants and haven't
affected the wider Post Office network, is that what you
are claiming?
A. I'm saying it is entirely possible because we know from
the bugs that have actually happened that they have only
impacted a small number of branches.
Q. Is it really entirely possible though, Mr Coyne? You
are hypothesising a bug which has had many, many, many
effects in order to justify the suggestion that it has
generated a large number of losses. That's what we are
talking about?
A. Yes.
Q. Those bugs occur at branches because of factors that you
are not prepared yet to identify, yes?
A. I haven't been given the information to enable me to
identify.
Q. You don't have a specific bug in mind which has
a particular feature which means that it only affects
certain kinds of branches. You are not telling me that.
You are saying that it is possible there might be such
a bug?
A. Yes.
Q. With this theoretical bug you are suggesting it is quite
possible that it could affect just the claimants'
branches and not affect the branches in the wider Post
Office network. Is that really your view? Do you
really think that is a likely outcome?
A. It may well have affected other branches in the branch
network.
Q. That's my point, Mr Coyne. It is all very well to say
"I don't know, it is a really difficult judgment to
make", but there are certain features which are just
matters of commonsense. What I'm suggesting to you is
that, bearing in mind the claimants represent such
a small fraction of the total Post Office network over a
period of 20 years, it stands to reason as night follows
day that if there are bugs which justify their claims
those bugs would also have incurred losses in the wider
Post Office network. Would you accept that?
A. Yes.
Q. Would you accept, therefore, that the wider losses that
would have been caused in the Post Office network would
be substantially greater than the £19 million --
A. That's likely, yes.
Q. Yet nowhere do we see any sign of any bugs of the sort
of scale that would be necessary to justify 100 billion,
200 billion of losses caused by these bugs. Do you not
find that surprising? Do you not draw any inferences
from that fact, Mr Coyne?
A. But there are bugs that we have found that have impacted
many branches. So what if there is another -- I keep
using the example of Dalmellington -- but what if there
is another Dalmellington that has impacted 88?
Q. We have talked about Dalmellington and we have agreed
I think that there is no net lasting impact from that
bug.
A. But that was only cleared up in its entirety after five
years.
Q. So you are talking about a bug which affects 88
branches?
A. A number of which were impacted on multiple occasions.
Q. So was it 114 impacts on 88 branches, is that right?
A. I think that is right.
Q. You are suggesting that that phenomenon would justify
the conclusion that there doesn't need to be thousands
of bugs in order to justify the claimants' claim, is
that right?
A. What I'm saying is using the profile of that type of bug
illustrates how there can be a large number of branches
impacted for a relatively long amount of time before it
is dealt with and with a large range of branch impacts.
Q. Mr Coyne, so far you have found 29 bugs and you have
very helpfully accepted that there are unlikely to be
more than 40 bugs if one were to read each and every
document, for which I'm obliged.
The supposition is that 40 bugs are capable of
causing £19 million worth of loss in the claimant
branches without causing any greater loss in the Post
Office network. Is that what you are suggesting? Are
you suggesting that's a viable scenario which might
explain what's happened?
A. You are asking me questions about the actual claim and
I haven't studied the claim. I'm aware of that headline
number that you are talking about but I have not looked
at the detail of the claim.
Q. I see.
A. So there is two possible scenarios. There is probably
many more. But that it has impacted the wider branch
network as well or that it has only impacted the
branches which are claimants'.
Q. Sorry could you say that last point again? I didn't
hear.
A. What I'm saying is that there is a range of scenarios
that go from additional bugs or the bugs that we found
impacting just the claimant branches, is the start of
the spectrum, up to bugs, errors and defects not only
affecting the claimant branches but the wider Horizon
estate.
Q. I suggest to you, and my Lord bearing in mind the speed
with which this cross-examination has come, with
your Lordship's indulgence I'm not proposing to put
Dr Worden's section 8.7 analysis to him unless you
indicate to me --
MR JUSTICE FRASER: To Mr Coyne?
MR DE GARR ROBINSON: Yes, unless your Lordship indicates
that I really need to.
MR JUSTICE FRASER: No, it is entirely up to you. It can't
be said against you, I don't think, if you don't put it,
and as I made clear at the pre-trial review and in a
time limited trial generally a point like that would be
ambitious -- are you concerned that if you don't go
through it chapter and verse it will be said it hasn't
been properly put?
MR DE GARR ROBINSON: Yes. My Lord, important points should
be put in my respectful submission.
MR JUSTICE FRASER: Yes, but this is really a methodological
difference, isn't it? So I'm not going to require you
to put every single --
MR DE GARR ROBINSON: I'm obliged my Lord.
MR JUSTICE FRASER: Is your intention literally not to put
any of it or just to put two or three headline points or
do you want to think about it?
MR DE GARR ROBINSON: Would your Lordship give me one
moment?
MR JUSTICE FRASER: Of course.
MR DE GARR ROBINSON: My Lord, I suspect that I will not be
putting any questions but I'm going to take instructions
overnight to see whether there might be some very short
number of points.
MR JUSTICE FRASER: Mr de Garr Robinson that is entirely
understood and entirely sensible.
MR DE GARR ROBINSON: My Lord, unless you have any further
points this may be a convenient moment.
MR JUSTICE FRASER: All right. That's fine. I mean just to
be clear Mr de Garr Robinson to make it -- well, to try
and help you when you take instructions on the way you
might want to or not to deal with 8.7, one way which is
often adopted is simply to boil it down to two or three
propositions and deal with it like that. But I'm not
saying you have to do that because I think both the
experts have been quite clear about the different way in
which they have and haven't approached the exercise.
I don't know if that's helpful.
MR DE GARR ROBINSON: It is very helpful my Lord and I'm
obliged to your Lordship.
MR JUSTICE FRASER: I have one very minor housekeeping point
which may sound like a joke but isn't. Yesterday was
Day 14 and today is Day 15, what happened to Day 13,
does anyone know?
MR DE GARR ROBINSON: No idea. I was wondering that.
I think it is Day 11 actually.
MR JUSTICE FRASER: It is definitely not Day 11.
MR GREEN: My Lord, wasn't the handing down of the recusal
judgment which technically was counted as a Horizon
day --
MR JUSTICE FRASER: Is that what --
MR GREEN: I think it may have, I will check --
MR JUSTICE FRASER: I'm not suggesting we re-number at all,
as long as we are all working on the same numbering I do
not think it matters. All right. Thank you very much.
So Mr Coyne you are going to come back tomorrow.
A. Yes.
MR JUSTICE FRASER: Can I just raise one point about timing
for both of you to think about. Ordinarily in any time
limited trial, which almost all the trials in this
building, certainly in the QB part of this building are
time limited, re-examination is kept to a very, very
minimum and I think I did tell you Mr de Garr Robinson
at the pre-trial review that although at that stage we
were looking at two days cross-examination of this
witness, which was then changed to four, that you would
have the vast bulk of that time.
MR DE GARR ROBINSON: Yes.
MR JUSTICE FRASER: Just in terms of the court staff, not
for my convenience, can you just liaise between
yourselves about approximately the time you will finish
on Friday afternoon. I'm not making any indications one
way or the other, but it would just be sensible for you
to have a dialogue because Mr Green today I think has
threatened re-examination on at least two and maybe more
occasions.
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: So tomorrow 10.30 Mr de Garr Robinson?
MR DE GARR ROBINSON: My Lord, yes.
MR JUSTICE FRASER: 10.30 tomorrow morning. Thank you very
much.
(4.25 pm)
(The court adjourned until 10.30 am on Thursday,
6 June 2019)