Witness Name: Jeremy Peter Folkes
Statement Number: WITN05970300
Dated: 11 January 2023
POST OFFICE HORIZON IT INQUIRY
THIRD WITNESS STATEMENT OF JEREMY PETER FOLKES
I, Jeremy Peter Folkes, will say as follows:
Introduction
1. This is my third statement to the Post Office Horizon IT Inquiry (‘the Inquiry”),
which I am making at the Inquiry's request to formalise a number of observations
which I made informally in December 2022, having participated in Phase 2 and
having reviewed the various Phase 2 Closing Submissions by the Core
Participants.
2. Specifically, I make observations on the Submissions created on behalf of Fujitsu
Services Ltd and Post Office Ltd, which both make reference to my own written
and oral evidence from Phase 2.
Closing Submission on behalf of Fujitsu Services Ltd
3. In this section I refer to the “Phase Two Closing Submissions on behalf of Fujitsu
Services Ltd’ (SUBS0000020), and make comments under a number of separate
headings.
Page 1 of 10
WITN05970300
WITN05970300
WITN05970300
WITN05970300
Comments on Alan D’Alvarez’s Statement re Information Sharing
4. At§16(b) of SUBS0000020, reference is made to Alan D’Alvarez’s Witness
Statement stating that “he personally encouraged the sharing of design
information with Post Office among the ICL security team, who were ‘quite
open”.
5. This largely concurs my own First Witness Statement (WITN05970100) where at
§80 I highlighted that on the POCL Infrastructure side and the Security areas we
had more success in obtaining information for Assurance than in other areas -
and Alan D’Alvarez was indeed one of our contact points on Security.
6. However, the key point I feel needs to be made is that Alan D’Alvarez worked at
this time (at least up to Acceptance in 1999) within the Technical Security area,
in the ICL Security Team, and, to my knowledge, had no substantive
involvement in the development of the EPOSS Application which is the primary
subject of this much of this Inquiry.
7. As\stated in §82 of my First Witness Statement (WITN05970100), and
reinforced by other witnesses, the situation with the Applications (and, in
particular, EPOSS) was very different, where we had explicit refusals from
Pathway Management to allow access to design documentation. If the EPOSS
team had shown the level as openness as we had from Mr D’Alvarez’s Security
team it is likely that POCL would have had far greater success in our Assurance
activities.
Page 2 of 10
8.
WITN05970300
WITN05970300
So, whilst not disagreeing with Mr D’Alvarez’s statement, I do question the
relevancy of this being quoted by Fujitsu in SUBS0000020 §16(b) in the same
paragraph as talking about EPOSS.
Comments on use of RAD (Rapid Application Development)
10.
11.
At §15.2 of SUBS0000020, the suggestion is made that “...the adoption of a
RAD methodology is unlikely to have had a material impact on the final form of
the Horizon IT System’.
Given that the use of RAD for EPOSS appeared to have led to the absence of a
suitable (‘up front’) design documentation which could be shared with POCL, and
therefore prevented an adequate level of technical assurance by POCL of the
EPOSS application (including its exception handling and operation under fault
conditions), I find it inconceivable that the use of RAD could not have had a
material impact on the quality of EPOSS and therefore of Horizon. The
absence of such timely design documentation would also surely have had
detrimental effects on Pathway’s own ability to assure its own product.
That Pathway were having problems with EPOSS in both 1998 (resulting the
Task Force) and 1999 (with their internal discussions on the need for a re-write),
and specifically the problems which emerged in mid-1999 with Acceptance (and
specifically Al376 on Data Integrity), suggests fundamental issues with EPOSS
which might have been avoided had a more appropriate design approach been
followed for such a key area of the system.
Page 3 of 10
WITN05970300
WITN05970300
Mention of Riposte Bug re Malformed Messages
12.
13.
14.
15.
16.
§14.1 of SUBS0000020 there is mention, pulled from other witnesses’
statements, of “malformed messages being generated within the message store’
and that this being “a difficulty arising from the Riposte product’.
I believe this is a reference to the “missing attribute” problem which has been
mentioned by various witnesses. My understanding is that this occurred when
Applications (such as EPOSS) sent/wrote incorrect or incomplete data to Riposte
for storage, akin to passing a record with certain empty fields to a database in a
more conventional system.
As a result, other applications (including the central ‘agents’ which fed data to
TIP) which selected data based on the content of such fields failed to perform
the correct processing.
Whilst not disputing that such problems occurred (and may have been one of the
root causes of AI376), I do not believe that it is correct to characterise this as a
Riposte problem.
It would be, I believe, more correct to describe this as an EPOSS Application
problem, and more specifically an Application Design problem as covered by
David McDonnel in his written First Witness Statement (WITN00620100 at §19)
and oral evidence (“Transcript from 16'" November 2022”, INQ00001019, p60-
64), in that best practice would have been to have an intermediate API layer to
validate message contents and completeness, rather than individual applications
Page 4 of 10
WITN05970300
WITN05970300
writing directly and independently to Riposte in an apparently rather uncontrolled
manner.
17. I suspect that it may have been known as a ‘Riposte problem’ by those
responsible for processing messages at the back end (as an attribute was
missing when a message was returned from Riposte), whereas, this was a result
of the application failing to add this data in the original message.
18. I know from my subsequent work with Riposte that there are a range of
protection mechanisms in Riposte to prevent the contents of a message being
changed without detection, providing a high level of confidence in the
immutability of the content of individual messages once written.
19. I would suggest this is another example where the RAD approach, rather than a
properly documented and reviewed up-front design approach, failed to enforce
such best practice. A proper design approach would have ensured the
presence of documented message formats (other witnesses have mentioned the
lack of a Data Dictionary) to define what fields would be necessary.
Choice of and Dependency on Escher/Riposte
20. At §14 of SUBS0000020 there is discussion of the use of third-party software,
and in particular of Riposte from Escher. Whilst POCL was fully aware of the
proposed use of Riposte by Pathway, it is important to note that the choice to
base the BA/POCL solution on Riposte was purely a Pathway decision, and not
Page 5 of 10
21.
22.
23.
WITN05970300
WITN05970300
in any way suggested or mandated by BA/POCL in their requirements. It was
therefore Pathway’s role to manage Escher and their use of Riposte.
§14.1 quotes Terry Austin that “/CL Pathway was not itself able to review the
Riposte code, but would have to make a request for modification through
Escher.”. I do not disagree with Mr Austin’s comment but this would (or should)
have been known by Pathway from the start, as it would be standard across
almost all third-party software products — I doubt if Pathway would have access
to the source code from Microsoft or Oracle, for their parts of the system, for
example. This restriction should therefore not be a surprise to anyone.
I note that in Terry Austin’s questioning (“Transcript from 27° October 2022”,
INQ00001008, p78-79) there was again reference to Pathway having ‘to go to
the Riposte system people’ for any problems with Riposte. Again, Mr Austin is
perfectly correct here but this would be the case with almost any third-party
product being integrated as part of an overall solution.
BA/POCL did indeed raise a number of formal risks around the use of Riposte
and the relationship with Escher (as stated at §14.2 of SUBS0000020), and a
number of these are listed in my First Witness Statement (WITN05970100) at
§51. These were managed by the Programme going forward under the topic
“Escher Dependency”.
Page 6 of 10
WITN05970300
WITN05970300
State of EPOSS and EPOSS Rewrite
24.
25.
26.
27.
One of the surprises (at least to me) which emerged in Phase 2, and which I was
questioned on during my oral testimony (“Transcript from 24 November 2022”,
INQ00001016 p99 and p139), related to the view from key staff in Pathway in the
second half of 1999 that EPOSS should be re-written — around the same time as
Pathway pushing for Acceptance of the system by POCL.
At §18.4 of SUBS0000020, it states that “/CL Pathway ultimately took the
decision not to re-design or re-write the EPOSS product. I believe itis
important to understand that this decision appears to have been taken after the
contract ceased to be PFI and the risk transfer inherent in PFl had ceased, and
when a more conventional contractual relationship should have been in place.
I do not believe that there was any discussion at this time (1999) with POCL
regarding either the potential need for a re-write or the underlying root causes or
concerns; indeed, at this point Pathway were pushing for Acceptance of the
system including the very same EPOSS that some of their staff wanted to re-
write.
Given that at §18.5 of SUBS0000020 it is stated that “that Post Office were
aware.... of significant concerns regarding quality of the EPOSS product it
seems inappropriate that POCL were not consulted when, at least a year later,
key players in Pathway were still recommending a re-write.
Page 7 of 10
WITN05970300
WITN05970300
Service Review Books and Meetings
28. At various points in SUBS0000020, including §17.3 and §18.5, there are
mentions of “service review books’ and “service review meetings’ and their role
in sharing information. My understanding is that these were periodic reviews of
the live service and in particular of incidents (failure, issues etc) which occurred
in live operation, and would only therefore cover incidents which occurred in
software which had been released into the live estate and were in real use by
branch staff and SPMs. I would therefore not expect the Service Review
Books/Meetings to cover EPOSS (for instance) until EPOSS had actually been
released into the live (and so not during the testing periods). From an EPOSS
point of view, I believe the Service Review process would potentially only
therefore have become relevant in 1999 once the live trial commenced.
Closing Submissions on Behalf of Post Office Ltd
29. In this section I refer to the “Phase End’ Closing Submissions: Phase 2 On Behalf
Of Post Office Ltd’ (SUBS0000016).
Acceptance and Readiness for Live
30. At §69 of SUBS0000016, my First Witness Statement is quoted where I had
answered questions in the Rule 9 Request related to Acceptance, referencing
my §151, §183 and §185 from WITN05970100. The POL submission states of
me that “he thought that going cautiously to the next stage was not
unreasonable’.
Page 8 of 10
WITN05970300
WITN05970300
31. I think it is important to read this in the context of the following/final sentence in
§185 where I question “whether due caution was applied once rollout
recommenced’ and alongside the statement at §186 where I said “To a degree,
we had lost the previous battles and the only option was now trialling in live
operation” (my emphasis).
32. I believe the crucial question is whether and what “caution was applied” and in
particular whether the rollout and operation in (say) 2000-2001 was properly
regarded and managed as a ‘trial’. For instance, in a trial I would expect close
monitoring and thorough investigation of potential issues as problems are
identified, together with more frequent fixes, until the system was fully proven.
This would be particularly important for a system as we had here with the
chequered development history and very limited up-front assurance.
33. This is an aspect which I do not feel was not covered in detail in Phase 2, and I
presume that this will be explored in more detail in Phase 3.
Statement of Truth
I believe the content of this statement to be true
Signed
Dated 411" January 2023
Page 9 of 10
Index to Third Witness Statement of Jeremy Peter Folkes
Phase 2 On Behalf Of Post Office
Ltd
No I URN Document Description Control
Number
01 SUBS0000020 Phase Two Closing Submissions on
behalf of Fujitsu Services Ltd
02 = WITN05970100 First Witness Statement of Jeremy
Peter Folkes
03. WITN00620100 First Witness Statement of David
McDonnel
04 ~~ INQ00001019 Transcript from 16 November 2022
(including David McDonnel oral
evidence)
05 —INQ00001008 Transcript from 27" October 2022
(including Terry Austin oral
evidence)
06 = INQ00001016 Transcript from 2°? November 2022
(including Jeremy Folkes oral
evidence)
07 I SUBS0000016 ‘Phase End’ Closing Submissions:
Page 10 of 10
WITN05970300
WITN05970300