Thursday 11th April – Horizon Trial Day 12
The transcript for this trial as well as expert commentary on proceedings is available at http://www.postofficetrial.com. Without the efforts of journalist Nick Wallis we would not have access to this information and he relies on money to survive unlike POL who seem to rely on Subpostmasters to survive. So it would be very kind of you all to put a little something in his paypal jar in order that he can continue to provide us with the coverage we need.
Stephen Parker is now the head of Fujitsu Post Office Application Support. As a witness called by Post Office Ltd hi job was to counter the allegations made by Richard Roll who was a witness for the claimants and worked at Fujitsu in the early 2000s when Mr Parker was his line manager. Mr Parker was clearly impressed with Mr Roll’s work. So much so that he went so far as to give him a personal reference despite the fact that this was against Fujitsu HR policy at the time.
The first part of the cross examination was to do with the several changes Mr Parker had made to his witness statement. For some unknown reason a very diligent chap in the Fujitsu Support Centre, a Mr Simpkins, allegedly took it upon himself to look further into the PEAK log to see if he could find more instances of transactions being injected into the counter records of branches. Well he found a few more and on the 20th of March, the day before Mr Parker was due to give evidence, Wombles informed the court of this and Mr Parker’s witness statement was duly updated.
A technical point here was revealed in that the additional search used to find the extra transactions included the following terms; “RiposteMessageFile, RiposteImport and RiposteMessage”. Very specific terms which it appears were not originally used by this highly experienced team to locate the additional injected transactions.
The RiposteImport command in particular was quite an amazing omission from the original search criteria because it is one of the few methods available for injecting transactions into a counter. Why it would be left out of the original search criteria is astonishing and worthy of further interpretation.
Mr Parker’s witness statement also revealed that over a period of 4 years, the Post Office Service Support Centre at Fujitsu received over 27,000 calls which would equate to more than 20 per day. Quite a figure for a robust computer system.
Systemic Errors?
In an article for the Digital Evidence and Electronic Signature Law Review (http://journals.sas.ac.uk/deeslr) (http://journals.sas.ac.uk/deeslr/article/download/2303/2256) I wrote:
“The Post Office consistently claims that the system is used by thousands of operators each day to process millions of transactions and must therefore be considered to ‘be in order’ as the law puts it. This, they suggest, proves there are no ‘systemic’ bugs in the system.”
The Post Office has misused the term ‘systemic’ repeatedly over the years so it came as a surprising revelation in court when Mr Parker stated:
“there were only rare circumstances where a coding issue had an estate wide impact and, in those instances, Mr Roll would have been involved in executing avoidance actions to mitigate impact to the estate”
They may be rare in Mr Parker’s opinion but his evidence is that they do exist and occur. There is however more to read into this statement. These system wide errors were by definition in the system for some time before they were noticed and fixed. There is no evidence to suggest – and as a former subbpostmaster I can attest to this – that the ‘estate’, the network of subpostmasters, were ever informed that these errors existed before they were fixed.
Mr Green goes on to question Mr Parker about how he set about trying to decide 15 years later how many actual software errors Mr Roll worked on while he was at Fujitsu. Without access to the referenced spreadsheet it is impossible to comment but this line of questioning did however reveal something else.
“
Q And at the bottom we can see that there is an agreement
at least with Mike Crowshaw’s explanation of the
imbalances in periods 10 and 11 which were due to
a stock transfer of £12,000 which was not settled
correctly to the presence of a corrupt DLL file on the
PC involved.
A That’s what the notes say, indeed.
In my opinion, and that of others I have spoken to, there appears to be an underlying and recurring theme of major errors occurring in the system when it comes to stock transfers. These could be between stock units within the branch (the ‘Falkirk’ error) or between the cash centre and the branch (the ‘Dalmellington’ error –although that was slightly different in that it was between two branches). However in both cases, transfers and remittances, the values involved can be significantly high and involve, initially, a one way transaction out until it is accepted at the receiving end. The Falkirk error was investigated in court in the trial of Seema Misra (see transcript published at http://journals.sas.ac.uk/deeslr/article/view/2217) where Mr Gareth Jenkins of Fujitsu attempted to prove to the court that the same error had not occurred at Seema’s branch at West Byfleet by examining NT Logs for possible hardware failures. In the example quoted above they are also looking at a hardware error as a possible cause of the problem, but in this case a corrupt DLL file (dynamic link library which contains many different modules of code that can be used by the calling program). Without going into detail there is not a cat in hell’s chance of Fujitsu, or anyone else for that matter, being able to go back in their history files and determining for certain whether or not a corrupt DLL file was to blame or not. I think this is one of the more revealing bits of evidence to date in the trial.
Fujitsu Support Centre is in a bit of a mess
With so few people dealing with so many problems you can perhaps begin to understand (if the consequences had not been so serious) why the administration of the department became a bit lax shall we say. Perhaps the trial was not a good time to rely on the internal records of their performance to have a go at Richard Roll’s testimony.
Q Okay. He says:
“This Peak is the regression of the Peak PC0234448”;
yes?
A Indeed he does, yes.
Q And underneath he has put:
“Category 41 — product error diagnosed”?
A He does indeed, yes.
Q The reason he does that is because there has been
a regression to a problem that had previously happened
as a result of a subsequent software release not having
caught a fix?
A That’s the note that the developer has made, yes.
Q And if we look on page {F/1326/5} please, towards the
bottom of the first blue box, penultimate paragraph:
“Risks (of releasing and of not releasing proposed
fix): Without this fix, there will be possibilities of
system errors at counter and while doing reversal
transaction”; yes?
A That’s what it says indeed.
This is not a one off. This is a service support centre making a balls up of a fix for an error they had already spotted and thought they had fixed. It happens all the time in the industry and an excellent example comes from a relatively unknown little software company that provided the underlying operating system (NT) to the Horizon network called Microsoft. In 2004 they withdrew support for the NT operating system but before they did they sent out one final update to correct errors that had been reported to them. Within 6 months of what was supposed to be the final release of NT, Microsoft were forced to send out another ‘fix’ to solve the problems that the previous upgrade had caused. Since 2004 to 2018 when the last counter using NT in the Post Office network was upgraded, worldwide users of NT had noted many more additional bugs including some very interesting ones with relation to the evidence that has been produced in court to date. (https://nt4ref.zcm.com.au/bugs.htm)
Whose fault is it?
Fujitsu supply the software but that is not the only component of the overall computer system known as Horizon. It needs a computer to run on, a keyboard to enter data and a printer to produce the output as well as many other bits and pieces. If software is not the problem though, Fujitsu wash their hands of it and somebody else has to sort it out even if the problems have created an inconvenient loss to the subpostmaster. Mr Parker helps Mr Green with this conundrum ….
“The system is still playing up in that the screen
is hanging in the middle of transactions — PM did
transaction … but left office for 1 hour — when he
came back the monitor had 141 first-class stamps on
screen totalling £38.07″, see that?
A Yes. I see that.
Q You would accept that that is not how the system is
supposed to work. Is that fair?
A That’s fair.
Phantom Transactions
Let me assume that the lay reader understands the concept of a phantom transaction e.g. a faulty keyboard ‘accidentally’ enters a transaction into the computer overnight while the subpostmaster is not present. Not an everyday occurrence mind you and not one that you would be expecting to look out for if you hadn’t been warned about it (which we never were). In practice though this would give rise to a discrepancy in the branch accounts – might not be serious but a discrepancy all the same. The real problem though is identifying the source of the error because if the phantom transaction occurred after close of business the effect would only be noticeable the following evening when stock was declared again and who would think of looking back to the previous days transactions?
Screen Calibration Problems
The Horizon user interface is predominantly touch screen. When the calibration goes out it is possible to think you are pressing one icon when in fact the system thinks you are pressing another.
It takes someone who has read the transcripts of this trial to understand the significance of this statement by Mr Parker:
Q And the PM says calibration is fine, not out of
alignment, because that was an issue that sometimes
happened, wasn’t it?
A There were screen calibration issues, yes.
The expert witness in Seema’s trial made a point about potential problems with calibration of the screen but POL (the prosecution in Seema’s trial) attacked this premise and appeared to persuade the jury that this was not an issue to be concerned with. This is certainly evidence that the CCRC should take note of.
Duplicate Pouches
In late 2015 I and others became aware of a software error in Horizon that generated substantial losses to the affected subpostmistress because the system had generated duplicate Remittance Pouch Receipts. Some 5 years earlier this occurred …
Can we just briefly, please, look at {F/589/1}? You
will see this is non-critical and closed with Solicited
Known Error. Do you see that?
A I do.
Q That is a problem of duplicated pouches, as you see
underneath the two tram lines.
A Yes.
Q And the amount that was renned in twice was £25,000.
A That’s what the notes says, yes.
Q It’s pretty serious for the SubPostmaster?
A I would think so, yes.
Q But category priority is C, non-critical?
A That’s correct.
Q And at {F/589/3} if you look down the penultimate blue
box, 5 March 2010, 12.33:
“POL have been informed of the error. Hopefully
they’ll issue a TC to correct loss at the branch. The
underlying problem caused by using previous button
during or just after scanning pouch barcodes, is still
under investigation”.
It is closed as Solicited Known Error?
Apart from the fact that this error seems identical to the earlier Falkirk error and the later Dalmellington issue it raises the question of errors known to be in the system yet the network were never informed about them and what to look for. Again, from the Misra trial transcript, POL as the prosecution, made the point that if her losses had been caused by an error in Horizon then she WOULD HAVE NOTICED IT. This was a key point made to the jury and would certainly have had an influence on their final decision which was to find Seema guilty and ultimately to send her to prison.
Conclusion
The major part of this whole cross examination of Mr Parker was to cast doubts on his interpretation of the categorisation of errors and in doing so support Mr Roll’s evidence as being reliable. As I point out above some major flaws in Horizon were revealed and these may or may not be commented on later by the expert witnesses so I will leave further analysis on these for another day.
However they all lead to the very safe conclusion in my opinion that the Horizon computer system was and remains unreliable and I use the word ‘unreliable’ deliberately because it lies at the heart this trial and how the law as it stands interprets the reliability of a computer system. Whatever decision the judge reaches in this trial will set an example for years to come in the legal profession because it is such a debatable point.
The barrister Stephen Mason has spent some time investigating this issue – which the judges and lawyers have ignored – and a most notable reference on the reliability of computers in litigation can be found here and is well worth reading – in particular Chapter Six of Electronic Evidence, now it its fourth edition and available as a free download from http://humanities-digital-library.org/index.php/hdl/catalog/view/electronicevidence/16/93-1
The evidence so far in this trial also points undeniably to the fact that Seema Misra’s conviction is completely unsafe and should be returned to the Appeal Court by the CCRC without delay.
problemswithpol 