<div dir="ltr">





<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Must the Cheshire Cat reappear - sigh!</span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Peter</span></p>
<p class="gmail-p2" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span class="gmail-s2" style="font-variant:normal;font-size-adjust:none;font-feature-settings:normal;font-stretch:normal;line-height:normal;font-family:Helvetica;font-kerning:none;color:rgb(0,0,0)">RE: “</span><span class="gmail-s3" style="font-kerning:none">Y</span><span class="gmail-s4" style="font-kerning:none">ou seem to have a prejudice for working with numbers when it comes to state machines</span><span class="gmail-s5" style="font-variant:normal;font-size-adjust:none;font-feature-settings:normal;font-stretch:normal;line-height:normal;font-family:Helvetica;font-kerning:none;color:rgb(0,0,0)">”</span></p>
<p class="gmail-p3" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">You are correct. I do. This originates from 10 years of lived experience, in many chemical processing plants dealing with hundreds of state engines.<span class="gmail-Apple-converted-space">  </span>A plant would have up to 5 state engines operating in parallel (we called them ”sequence control units (SCUs)” for operator cognition), each comprising around 10 states (we called “steps”). Courtesy of our state chart implementation, walking into a control room, you could determine the complete status of the plant by scanning 3 to 5 current step numbers. A site manager supervising say, five plants, could, in real time, determine the status of his complete chemical processing complex by glancing at a single screen provided by our supervisor systems. Numbers ruled the lives of everyone in the complex. A great shorthand for, "where are we up to?" A small subset of numbers, usually one, would put a chill down your spine, indicating a dangerous condition such as a gas release or an explosive state within a reactor. There could be no ambiguity here. Hence, my violent opposition to synonyms of any kind in a Safety-Critical control system. Your EUC example has no currency in an environment riding herd on a reaction kinetics that can tear your body into subatomic particles or fill your lungs with hydrochloric acid. To be clear, we used one synonym and one synonym only. If you mentioned state or mode in a control room, the operator would stare at you blankly – and a good thing too.</span></p>
<p class="gmail-p3" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Keeping it that simple was always a great intellectual challenge. In the American operations I worked in, our greatest single challenge was helping plant engineers simplify their state engines, avoiding state explosion. Harel solved this problem with state hierarchy - super-states and sub-states. We avoided this architecture as it would introduce more complexity into operations. Referring to my previous post, we often had operators without a high school education. I got a great kick out of working with these salt-of-the-earth guys. Despite their disinterest in academia, they were, to a man/woman, decent people who were smart and dependable, a non-negotiable attribute for people who ran plants processing dangerous chemicals 24/7 - 16 hours a day with no engineers present. So cognition/ease-of-use were the fundamental objectives of all our control systems. This is why we embraced the simplified state engine - a marvellous invention.<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p4" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;min-height:17px"><span class="gmail-s1" style="font-kerning:none"></span><br></p>
<p class="gmail-p2" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span class="gmail-s5" style="font-variant:normal;font-size-adjust:none;font-feature-settings:normal;font-stretch:normal;line-height:normal;font-family:Helvetica;font-kerning:none;color:rgb(0,0,0)">Re: formal methods …. “</span><span class="gmail-s4" style="font-kerning:none">For almost all formal verification techniques for the last 57 years use them or some equivalent.</span><span class="gmail-s5" style="font-variant:normal;font-size-adjust:none;font-feature-settings:normal;font-stretch:normal;line-height:normal;font-family:Helvetica;font-kerning:none;color:rgb(0,0,0)">”</span></p>
<p class="gmail-p3" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">State charts are a visual formalism, though not a formal method. This is the closest we ever got. Our problem was program size, lack of perceived benefit and cognition. The control code was comprehensively documented and became the plant operations manual. You would find a thick pile of fanfold paper on the desk of every control room. Operators could actually read it. The International success of this discipline was directly due to our focus on human beings and understanding. The single greatest success factor was that we had plant engineers write programs and live with them. In this context, teaching them all formal methods was impractical.</span></p>
<p class="gmail-p3" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">If anyone on this list has implemented formal methods in a large system, I would love to hear about the experience.<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p4" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;min-height:17px"><span class="gmail-s1" style="font-kerning:none"></span><br></p>
<p class="gmail-p3" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Your point reminds me of other academic protestations I experienced on a two-year, hundred-million-dollar rail project with SIL 2 subsystems. We were short on V&V staff, so my client company hired many V&V types from a local university research group. They kicked down our door, feisty and arrogant, damming our Jurassic hides for not formally proving all our software. Other than that, they were good, smart kids. We got along well. Over time, I could see their attitudes change as they realised how impractical that approach would be in a project that had tripley redundant supervisory computers communicating with 250 remote terminal control units within embedded systems and micro code configured - all in a constant state of change.<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p4" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;min-height:17px"><span class="gmail-s1" style="font-kerning:none"></span><br></p>
<p class="gmail-p3" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">As I fade out … again … I think it is worth reflecting on the future of “correctness” determination in systems as a whole in the context of AI. I recommend a book, The Infinity Machine [1].<span class="gmail-Apple-converted-space">  </span>It chronicles the rise of Demis Hassabis and DeepMind. Demis’ defining insight in seeking out artificial general intelligence, when all others believed it was impossible, was that human beings are seldom computational engines [1]. They are mostly inductive creatures who have survived through pattern matching, and any attempt at artificial intelligence should follow that path rather than the computational deductive path that we would follow with formal methods. He believes this was the core reason for the failure of symbolic AI in the 1980s and the reason for his team winning at Go, a pattern-matching exercise that is computationally </span><span class="gmail-s6" style="font-kerning:none">intractable - Legal Positions (State Space) - 10^{172}.</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">In partnership with Claude code, I am developing a crypto trading platform in JavaScript and Python. I am rusty on JavaScript and have never written Python. I started with good intentions, given that this code will spend my money. I was determined to review every line. I soon gave up, there was too much of it. All my time was spent developing a 74,000-word specification that merged a phased implementation strategy with software requirements and critical architectural decisions. All in partnership with Claude's code, followed by seven cycles of Claude's Fagan review. Research reveals my experience is typical.<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">What then of formal methods? Given the productivity improvements – I can now achieve in minutes what used to take me days - is this the end of that path? Or only the beginning with AI enhancement of formal methods?</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Over to those wiser than me …</span></p>
<p class="gmail-p6" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;min-height:17px"><span class="gmail-s1" style="font-kerning:none"></span><br></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Cheers<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Les.</span></p>
<p class="gmail-p6" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;min-height:17px"><span class="gmail-s1" style="font-kerning:none"></span><br></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">[1] Mallaby, Sebastian. The Infinity Machine: Demis Hassabis, DeepMind and the Quest for Superintelligence (p. 25). Penguin Books Ltd. Kindle Edition.<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none"><span style="font-size:14px">After all, humans engage in deductive logic only a small fraction of the time. Mostly, they take in jumbled images, words, smells, and sensations; then they extract meaning from the noise—a process that logicians call induction and lay people might call pattern recognition.</span><br><br><span style="font-size:14px">PS: Given your computer science background, and advocacy for </span>formality in definition,<span style="font-size:14px"> I look forward to your </span>entity, attribute<span style="font-size:14px"> analysis of the terms </span>mode and state.<span style="font-size:14px"> As per </span><span style="box-sizing:border-box;border-style:solid;border-width:0px;border-color:rgba(39,26,0,0.14);font-weight:740;color:rgb(39,37,30);font-family:pplxSerif,pplxSerif,ui-serif,Georgia,Cambria,"Hiragino Mincho ProN","Yu Mincho","Songti SC",SimSun,"Songti TC",PMingLiU,"Songti TC",MingLiU_HKSCS,"Songti TC",PMingLiU,AppleMyungjo,Batang,serif">IEEE Std 1016 or any other formalism you care to implement.</span></span></p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 22 May 2026 at 20:05, Paulo Carvalho <<a href="mailto:paulovfc@gmail.com">paulovfc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hello gents,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">pardon my intromission, but I see the INCOSE Systems Engineering Handbook as a domain agnostic reference/guideline, and in that sense would see reasonable that text distinguishes between "state" and "mode" even if not providing a definitive definition for each. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Thus, leaving the user to define those terms for the particular /application/domain/system they are working on.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I could see a situation where a system has different operating <b>modes </b>(nominal, degraded, power-off, etc.) and each of these modes includes different internal <b>states. </b></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Cheers</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Paulo</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><b><br></b></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 22, 2026 at 10:19 AM Prof. Dr. Peter Bernard Ladkin <<a href="mailto:ladkin@causalis.com" target="_blank">ladkin@causalis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2026-05-22 01:27 , Les Chambers wrote:<br>
><br>
> In these contexts, synonyms abominate the functional Safety countryside. They must be hunted down <br>
> and eliminated with extreme prejudice - along with the “qualitative state machine(s)” they rode in <br>
> on.<br>
><br>
First, it seems silly to me to renounce synonyms. In the 61508 context, it would be ridiculous to <br>
insist people say/write Equipment Under Control when they can write EUC and even more ridiculous to <br>
insist they say/write Equipment Under Control Control System when they can say/write EUCCS.<br>
<br>
Second, you seem to have a prejudice for working with numbers when it comes to state machines. <br>
That's fine, I guess, as a personal preference. But if you perform any system development using <br>
formal methods (which 61508 now says is "highly recommended" for any safety function) you will very <br>
quickly have to get used to manipulating state machines which work on symbols which are not numbers. <br>
For almost all formal verification techniques for the last 57 years use them or some equivalent.<br>
<br>
PBL<br>
<br>
Prof. Dr. Peter Bernard Ladkin<br>
Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany<br>
Tel: +49 (0)521 3 29 31 00<br>
<br>
_______________________________________________<br>
The System Safety Mailing List<br>
<a href="mailto:systemsafety@TechFak.Uni-Bielefeld.DE" target="_blank">systemsafety@TechFak.Uni-Bielefeld.DE</a><br>
Manage your subscription: <a href="https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety" rel="noreferrer" target="_blank">https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</a></blockquote></div>
</blockquote></div>