The inherited loop 3 – The half nobody designed
THE INHERITED LOOP SERIES · PART THREE OF FIVE
You press Pay. A small circle starts to turn. Ten seconds. That is already long; you expected the page to change almost at once. Thirty seconds, and the first question arrives: is it still working, or has it stopped? A minute, and your hands are not quite steady, because this is your money, and you do not know where it is. You cannot press Back, because that might cancel something that has already gone through. You cannot press Pay again, because that might charge you twice. You can only wait, and watch the circle. Three minutes, and you are about to give up — and then, without a word, the page you started from comes back. The basket is empty. Nothing says paid. Nothing says failed. You go to the basket to see whether it is really empty. You go to your orders, if you can find them. You open your email and wait for a message that may or may not come.
Every screen in that sequence worked. The payment page was designed, reviewed and built. The page you landed on was designed, reviewed and built. The product still failed, and it failed in the gap between them — in the three minutes when it knew something you did not, and had no rule for telling you. That gap is what this piece is about.
Part 1 — The half nobody designed
You know this half from the times it failed you
Nobody has to be taught that the layer exists. You have met it every time it broke.
You pressed Save, and nothing told you whether it saved. You submitted a form, and the error appeared on a field you had already scrolled past. A box asked "Are you sure?" for the fifth time that afternoon, so you stopped reading it and pressed Yes — and one day that will be the time it mattered. A message said "Something went wrong", and not what, and not what to do now. A red line appeared under a field, but you had not finished typing, so it was red before you had done anything wrong. A page said "Saved two minutes ago" at the top and "Unsaved changes" at the bottom, and both were true.
None of those moments was designed. Each was decided on the afternoon the ticket was open, by whoever had the ticket, and the next screen was decided by someone else, on a different afternoon, with a different idea of what "saved" should look like. Multiply that across a product and you get software that is inconsistent in the one place it cannot afford to be: in what it tells you about what just happened. A system that does not say what to expect, or says it differently every time, never gives you the feeling that you are in control of it. And people do not keep using what they do not trust. They find a way round it, they keep a spreadsheet on the side, they call someone instead.
That is the stake. Not polish. Trust, and the cost of losing it one small silence at a time.
Two halves, and only one was ever designed
Communication has a sender and a receiver, and it has had them since before there was software. When we design a product, we design one side of that exchange with enormous care: what the person can see, press, type, choose, and in what order. There is a discipline for it, and job titles, and forty years of method behind it.
The other side — what the system says back, when, where on the screen, how loudly, and in how much detail — was never given the same treatment. It was assembled. Case by case, screen by screen, by whoever held the code, from whatever the component library happened to offer that year.
I want to say exactly what I mean by that other side, because the whole piece depends on it.
A system response is what the system does in the time between the screens. It is the set of rules that never appear on any screen as themselves, that run in the background, and that show up only as changes to things you can already see: a border turns red, a row turns yellow, a small icon appears on a heading you have collapsed, a button goes grey and stops responding, a bar slides in above the content, a circle starts to turn — and, just as important, stops. Sometimes the change is subtle, a shade of colour. Sometimes it is strong, a box you cannot get past. The visible things — the border, the row, the icon, the bar, the box — I will call carriers, because they carry the message. The rules that decide when a carrier changes, where, why, and how loudly are the system response. Together they are a rulebook: the system's half of the dialogue, written down.
The discipline of writing that rulebook, before the product is built, I call system response design. The name is deliberately plain. There is a field called behavioural design, and it is a real one, but it is about the other direction: changing how the person behaves — nudges, habit loops, the small pushes that make you tap once more.[1] This is not that. System response design changes nothing about you. It specifies the system.
Here is what you get from the rest of this piece. In Part 2, how the layer actually works: the first rule of it, taught from a room full of lights; where the carriers live and where the rules do not; and what happens at the moment that breaks every improvised version, when three things change at once. In Part 3, why the layer just became ten times harder — because the same product now answers you in a conversation on one side and in forms on the other, and the rules have to hold across that seam. In Part 4, what a framework for it has to do, an honest account of what is tested and what is not, and the question I cannot yet answer.
Where we are. Every product has two halves: what the person can do, and what the system says back. The first has been designed for forty years; the second was assembled by whoever held the code. The second half is the system response: rules that run between the screens and show only as changes to carriers — a border, a row, an icon, a bar, a turning circle. Writing those rules down before building is system response design. The stake is trust, lost one silence at a time. Next: how the layer works, starting with a red lamp.
Part 2 — How the layer works
A red lamp in a control tower
A colleague of mine — a UX designer, like me — once told a room of us about a visit to an airport control tower. Monitors everywhere, panels of lights, the kind of room you imagine. In one corner, a red lamp. He asked a controller what it was for. The controller had to stop and think for a moment before he could say: it showed whether the barriers were up or down at the point where a service road crosses the taxiway.
The lamp was not the interesting part. The interesting part was that he had to think. A man who sat beside that indicator every working day needed a moment to remember what it meant. It had stopped being information and become furniture.
That is the first rule of the layer, and I want to state it plainly because everything else follows from it: you do not show what is working. If everything is fine, nothing should be lit. A signal earns its place by marking a change — something that was one way and is now another — and it loses its place the moment it is always on. The failure mode has a name: the Christmas tree. A wall of lamps, most of them lit, most of them meaning "still fine", until the one lamp that finally matters is one of a thousand and nobody sees it. Put that wall in front of a fighter pilot and he would never leave the ground.
The rule looks like a design preference. It is not. It has been found at least three times, independently, by people who were not looking for each other. Motivation researchers found, across more than a hundred experiments, that rewarding every step of a task undermines the wish to go on with it for its own sake: when everything you do earns a signal, you stop trying the things that might not.[2] Interface practice arrived at the same place on its own, when the habit of putting a red mark on every field that was not yet valid produced forms where red meant nothing, because it was everywhere — people found the crosses "quite annoying" when they had not finished typing, and forms that waited until they had were filled in faster.[3] And alarm engineering had it before either, in control rooms and hospital wards: an alarm that sounds too often is an alarm that gets switched off. The standard for a control room allows about one alarm every ten minutes in normal running; in the eleven minutes before the Milford Haven refinery explosion in 1994 the two operators had 275 to act on.[4] Three fields, three vocabularies, one law. A signal is worth exactly as much as the silence around it.
So the first question in the rulebook is not "what should the system say?" It is "what has changed — and is it worth breaking the silence for?"
FIGURE 1 — One row of the rulebook. A single system-response rule laid out as a row: trigger (what changed), condition (when this rule applies and when it yields to another), carrier (border / row / icon / bar / box / circle), place (where on the screen), strength (subtle → blocking), depth (a colour → a line of text → a full explanation), text (the exact words, referenced from a library, not written here), test (how you would check it). Underneath, one line: the row is the unit; the rulebook is the set of rows and the rules for when two rows meet.
Where the carriers live, and where the rules do not
If you work in product, you may be thinking: we have this. We have a design system.
You have half of it. A design system holds the carriers. It has a toast — the small message that slides in and fades — and a banner, and an inline error line, and a badge, and a disabled state for a button, and a spinner. It specifies how each one looks, in every colour and size, in light and dark, and says in general terms what each is for.[5] What it does not hold, anywhere, is the when. Nothing in a design system says that a failed save on this screen uses the banner and not the toast; that the badge on a collapsed section appears only when the section holds something the person has not seen; that the spinner is allowed ten seconds of silence and then must say something. Those are rules, and a component library has no place to put a rule.
The same is true of interaction patterns — the published catalogues of how a login, a search, a wizard usually behave.[6] They are useful, and I use them. But a pattern gives you the common case. It is a phrasebook: here is how one says "your file was saved". It does not tell you when to say it, whether to say it here or on the next screen, or what to say instead when the file was saved but the thing it belonged to was not. A phrasebook is not a conversation.
I should say, in one sentence, where this way of thinking comes from, so that you know it has been run for real and not only argued. In 2013 I traced every place one enterprise application would have to speak — sixty-one events — classified each one, wrote thirty-two messages once into a library that every screen referenced instead of writing its own, attached a test case to every identifier, and shipped it complete in October of that year. That is the whole memoir. What matters is what it showed: the rulebook is small, it is finite, and once it exists the carriers can do far more than they did before, because every carrier now has a reason to appear and a reason to stay away. Good carriers do not make a product quieter. They make it able to say more, and be believed.
When three things land at once
Everything so far could, in principle, be improvised. A good developer, given one event — the file saved — will pick a reasonable carrier and put it in a reasonable place. That is why the layer survives without a discipline for as long as it does: one response at a time, improvisation is nearly good enough.
It stops being good enough at the first moment two or three things change at once.
Go back to the payment, and this time look behind the screen. When you pressed Pay, three parties went to work, and each of them knew its own part. The shop sent the request to the payment service — PayPal, Stripe, Google Pay, whichever you picked. The payment service said yes; you saw its page, you typed the six-figure code, it said approved. The payment service then asked your bank, and the bank said no. In the case I know best it said no because it had blacklisted the shop, which I learned by ringing the bank the next day; the shop was a service abroad I had never used, everything about it had felt serious, and I tried three methods before I gave up and went to check my own accounts instead. The bank's refusal went back to the payment service. From there, nothing reached the shop. So the shop did the only thing it had a rule for: it waited, and when the wait ran out it timed the session out and put you back where you started. Three true things, one moment, one screen — and the one party that knew the reason was two steps away from the one that was talking to you.
This is the shape of the real problem, and it is not "what message do we show". It is conditions on conditions, across parties that do not share a screen. If the payment service has said yes and the bank has not answered, then say so, and hold the basket. If the bank refuses, then say that it was the bank and not the card, so that the person does not spend the evening checking balances and trying other cards. If no answer comes back at all, then say that too — "we have not heard from your bank" is a sentence — and never reset the page while any of this is open. Each rule is simple. But the last one cannot be written until someone has drawn the chain — shop, payment service, bank, card — and asked at each link what comes back, and what should be said when nothing does. The rulebook is the set of rules plus the rules for when they meet, and it is that second set that nobody writes, because there is nowhere natural to write it, and no single party owns the chain.
The same silence runs at every scale. In one interview at work, a group of people described to me a system that takes a large specification and breaks it down into smaller ones for different factories. The breakdown can take hours. You start it, a wheel turns, and that is all you get. They told me it might start at one on a Friday afternoon, and at five, when everyone wants to go home, the wheel is still turning — and nobody in the room knows whether it is nearly done, stuck, or failed an hour ago. Consumer and enterprise, three minutes and four hours: the same missing rule. The system knew, at every moment, which of its smaller tasks it was on. It had no rule for saying so.
Here is why this layer survives the one review where catching it would be cheap. A prototype cannot show it. A prototype is a set of screens with paths between them; it shows you places. The system response lives in time — in what happens during the three minutes, in what is said when nothing comes back — and a screen has no way to hold a duration or a precedence. A written specification, the kind a business analyst produces, cannot show it either; it can list the three parties, but it cannot make you see the answer failing to come back, and a list of conditions three levels deep is exactly the thing a reviewer's eye slides over. So the layer passes design review, because design review looks at screens, and it passes specification review, because the words are all there, and it arrives in the code as a set of afternoons.
FIGURE 2 — The payment that never answered. Three lanes on one clock. Middle: the screens in order — basket, payment method, the payment service's page, the spinning wheel, the basket again, then the person's own bank app and PayPal. Right: the person's thoughts beside each screen, with timestamps, from confident to "what is happening?". Left: the event log nobody saw — request sent, approved, charge requested, bank refused, refusal sent, nothing arrives at the shop, session timed out. Built in Claude Design 2026-09-24: figures/POST-3_fig2-the-payment-that-never-answered_claude-design_2026-09-24.html. Caption: Three parties, one of them knew why. The reason never came back, so the only response the shop had was a timeout — and the person went looking for it themselves.
Where we are — what to take from this half. If you stop here, take these with you:
-
- The first rule of the layer: show what has changed, never what is working. A signal is worth what the silence around it is worth. Found three times independently; it is a law, not a taste.
- Design systems hold the carriers — toast, banner, inline line, badge, disabled state, spinner — and never the rules. Patterns hold the common case and never the when. The rulebook is a separate thing, and it is small.
- One response can be improvised. Three parties on one moment cannot, and the rule for the answer that never comes back is the part nobody writes.
- The layer lives in time, and neither a prototype nor a written specification can display time. That is why it passes every review and arrives in the code as a set of afternoons.
Next: why this just got ten times harder — the same product now speaks in a conversation on one side and in forms on the other, and you cannot find the points on the conversational side by walking the screens, because there are no screens to walk.
Part 3 — The seam
Two kinds of system, and you can only walk one of them
Everything in Part 2 assumed something I did not say out loud: that the product is a set of screens.
In a product made of screens, the system response has a rail to run on. There is a finite number of places, a finite number of things that can happen at each place, and if you are patient you can walk every path and write down every point where the system will have to speak. That is what the 2013 register was: a walk through the whole application with a notebook. Sixty-one events, because sixty-one was how many there were. The layer was invisible, but it was countable. You could find the points by place.
A system that answers you in a conversation has no rail.
I mean that precisely. When you type a question into an AI assistant, or speak one, there is no screen you are on and no next screen you go to. There is an exchange, and the exchange can go anywhere. You cannot walk the paths, because there is no fixed set of paths to walk. So the method that found sixty-one points in 2013 — start at the first screen, go everywhere, write down every place the system must speak — finds nothing here. Not because there is nothing to find. Because there is no where.
And yet the layer is still there, and it still breaks in the same way. The system says something it cannot back, and does not say so. It quietly loses a piece of what you told it ten minutes ago, and carries on as if it had not. It corrects itself mid-answer, and the correction is buried in the middle of a paragraph. It is about to do something that will take four minutes, and the circle turns, and you are back at the payment page. Every one of those is a moment where the system knows something you do not, and has no rule for telling you. The tower rule still holds — say what changed, not what is working — and the escalation still holds: two of those landing in the same reply cannot be improvised.
So the question is not whether the conversational side needs the rulebook. It plainly does. The question is how you find the points when there are no places.
Specify by reason, not by place
The answer, as far as I have taken it, is this: on the screen side you specify by where; on the conversational side you specify by what kind of thing just happened.
A rule on the screen side reads: on this screen, when the save fails, show the banner, here, and keep it until dismissed. The trigger is a place and an event.
A rule on the conversational side cannot name a place. It reads instead: whenever the system has made a claim it cannot verify, it says so, at this strength, before the claim and not after. Or: whenever the system has dropped something the person said earlier, it says what it dropped, and asks, rather than continuing. Or: whenever the system is about to do work that takes longer than a few seconds, it says what it is doing and how far along it is — and it keeps saying so until it is done. The trigger is a reason: a kind of thing that can happen in an exchange, wherever in the exchange it happens.
That last one you have already seen. Look at the panel in the AI coding tools that appeared this year, where the system shows its agents fanning out into their separate tasks — reading this file, running that check, waiting on the other — while the work runs.[7] That panel is a system response. It is the same rule as the spinner that is not allowed ten seconds of silence, finally taken seriously, because the work now takes minutes and the person will not sit through four minutes of a turning circle. It exists because someone decided that the time between the question and the answer is part of the product. That decision is exactly what was missing in the payment, and in the Friday breakdown. The conversational tools got there first, out of necessity, and the rest of software should notice.
FIGURE 3 — The seam. Left column: a chain of screens, with system-response points marked on the rail between them (by place). Right column: an exchange with no rail, and the same kinds of points marked by reason — unverified claim, dropped context, self-correction, long-running work. Across the middle: one event that lands on both sides at once — a long-running job started in conversation, whose result must appear on a screen — and one rule holding across the seam. Caption: same rulebook, two ways of finding the points.
Why this is the same product, not two
If the two sides lived in different products, you could keep two rulebooks and be done. They do not. The real product today has a form on one side and a conversation on the other, and the same event crosses the seam.
You ask the assistant to prepare a report. It starts work — long-running, so the conversational rule says it must show progress. The work finishes while you are on a different screen, filling in a form. Now what? Does the confirmation arrive in the conversation, where you are not? On the screen you are on, interrupting the form? Both? And if, in the same moment, the form you are filling in fails to save, which one is said first? This is the payment moment again — three parties, one screen, an answer that has to travel — except that now the parties live on different sides of the seam, and the rule for their meeting has to be one rule, held by nobody in particular, or it will be two rules held by two teams and the person will see both, or neither.
That is what I mean when I say the bar has gone from one to ten. Not that the old layer got harder. That a second kind of system arrived, with no rail to walk, and the same product now has to hold one rulebook across both, with rules for what happens when events from the two sides land on one moment. The old way of holding this — a specification written by a business analyst, a document with the events listed in it — was already the weakest point in the old world. It cannot hold the new one at all.
The screens now arrive before the rules
One more thing changed this year, and I saw it directly. In March, two product owners came to a meeting with complete screens for a new feature — every state drawn, every button in place, generated by an AI design tool from a description. They were good screens. When I asked what the business rules were behind them — what happens when this succeeds and that fails, what the system says when the two collide — neither of them could say. Not because they were careless. Because the screens had arrived first, and the screens looked finished, and a finished-looking screen does not ask you what happens between it and the next one.
This is the payment problem moved upstream. It used to be that the rules were missing from the code because nobody wrote them before the afternoon of the ticket. Now they are missing from the design, because the design was produced without them, faster than anyone could ask. And an AI that builds from that design fills nothing from experience. A human developer, handed a screen with no rule for the failed save, would have improvised one, badly or well. An AI builds what is written. What is not written is not improvised; it is absent. I wrote about that in the Loop piece, for thinking tools. It applies to every product now: the system response is either specified or it is not there.
Where we are. On the screen side, the system response runs on a rail: you find the points by walking the places, and there is a finite number. On the conversational side there is no rail, so you find the points by reason — the kinds of thing that can happen in an exchange: an unbacked claim, a dropped thread, a self-correction, work that takes minutes. The progress panels in this year's AI tools are that last rule taken seriously. The real product has both sides, and one event crosses the seam, so it needs one rulebook with rules for the meeting. And the screens now arrive before the rules, generated in minutes, so the gap is no longer in the code; it is in the design. Next: what a framework has to do about it, and what I do and do not know.
Part 4 — What a framework has to do
The outcome first
Before the method, the outcome, because the method is only worth having for this.
A product whose system response has been designed behaves coherently: the same kind of event gets the same kind of answer, at the same strength, wherever it happens. It is inspectable: you can open the rulebook and see, for any moment, what the system will say and why — before the code exists, and after it has shipped, and when the tenth developer joins in year three. And it is decided before it is built: the three-events moment has a ruled answer in the specification, not an improvised one in the code.
Coherent, inspectable, decided before built. Everything below is in service of those three, and if a method does not deliver them it is the wrong method.
Three jobs
A framework for system response design has three jobs. I will give each one plainly, with what I know about it and what I do not.
Find the points before building. On the screen side this is the walk: every place, every event, a row for each. On the conversational side it is the list of reasons: every kind of thing that can happen in an exchange that the person needs to be told about. The first list is finite and I have made one. The second I have drafted — fifteen kinds so far — and I have not yet run it against a real system, which means I do not yet know whether fifteen is the number, or whether the kinds hold up when the system starts doing them. The next step in this work is exactly that: take a real product that has both sides, and go through it with the notebook, and see what the conversational side actually produces. I have one to hand — the thinking tool I have been building — and the inventory is the next piece.
Set the rules. A row per point — trigger, condition, carrier, place or reason, strength, depth, the words, the test — and, separately, the rules for when rows meet: which yields, which waits, which stays silent. The second set is the one nobody writes, and it is the one that decides the payment moment, so a framework that gives you only the rows has given you the phrasebook again. What the meeting rules look like when written down properly — as precedence, as a small table, as something else — is a form I have not settled. Figure 2 in Part 2 is one attempt: the three lanes, on one clock.
Keep them true over a long development. This is the job the 2013 register was actually built for, and it is the one I would put first if I had to choose. A rulebook written once and then left is a document; a rulebook with a test attached to every row is a check, and it stays true because the tests fail when someone breaks it. Thirty-two messages written once and referenced everywhere meant that when a message changed, it changed everywhere at once, and when a screen wanted to say something new, the question "is there already a row for this?" had to be asked. That is what keeps the layer coherent across three years and ten developers. It is also the one part of this that a conversational system makes genuinely harder, because a test for "the system said so when it dropped something" is not the same kind of test as "the banner appeared" — and I do not yet know what it is.
What is tested, and what is not
I said in the Loop piece that a concept that comes through research unchanged is one that was never really tested. I have not yet run this one. So here is the ledger as it stands, so that you know what you are holding.
Run for real. The screen-side method: the walk, the register, the message library, the test per row. One enterprise application, 2013, shipped complete, kept coherent through the years that followed. That is one product, not a study, and I would not claim more than that. It shows the method is finite and can be done; it does not by itself show it generalises.
Found three times. The first rule — show what changed, never what is working. Motivation research, interface practice, and alarm engineering each arrived at it separately. I am confident of the convergence, and the individual sources are in the list at the end — the meta-analysis, the form study, the control-room standard and the refinery report.
Hypothesis. Everything on the conversational side. The fifteen kinds. The claim that one rulebook can hold across the seam. The idea that you specify by reason where you cannot specify by place. These are the concept as I hold it, and they are stated as such. The inventory over a real system is what turns them into something else, one way or the other.
Not yet looked. Whether anyone has written the system-side rulebook for a product that has both a screen side and a conversational side, with the meeting rules across the seam. I have not found it, and I have not searched hard yet. Silence in the literature is not evidence that it is not there; it is a task on my list.
The tool that had it
I have given two reasons the layer passes every review: a prototype shows places and cannot show time, and a written specification lists the events and hides the collision. There is a third, and it is the plainest of the three. There was never a tool for it.
Almost never. Around 2015 I built prototypes in Axure, and Axure had something no tool I have used since has kept. On any interactive component — a dropdown, a button, a field — you could set conditions: if this is selected, show that form; if this state holds, disable that control. The prototype ran on those conditions. And then you could generate a specification from the prototype, and the report wrote out, component by component, what happened when: the events and the rules behind them, more or less the rows of the rulebook, produced from the thing you had built rather than written beside it.[8]
That was the picture, or the first draft of it. Nobody carried it forward. Figma, XD, UXPin — the tools that came after are better at almost everything and have nothing like it: you can put a function on a button, but there are no rules connected to it, and no report that writes them out. I think I know why. The feature was expensive to use. Writing the conditions by hand, for every component, was a great deal of work, and most of the people who might have done it were the business analysts who were already writing some of those rules into the requirements document — the part that a document, as I have said, cannot make you see. High complexity, high cost, one tool, and so the layer fell back to whoever had the ticket.
What is now possible
The cost that killed that feature has just gone away.
What Axure asked a person to do by hand — find every point, write the condition, write what happens — is exactly the kind of work an AI agent, given a skill for it, does well and does in the background. Walk the product, screen side by place and conversational side by reason. Detect the points. Write a row for each: trigger, condition, carrier, strength, depth, the words, the test. Write the rules for when rows meet. Attach the tests and run them, so that the rulebook stays true through the long development instead of decaying into a document. None of that needs to live inside the prototype any more, or inside anyone's afternoon. It can be a check that runs beside the build, the way the register of 2013 was a check, but without the sixty-one hours it took to make it.
I want to be careful here, because "an agent could do it" is the cheapest sentence in software this year. So, plainly: I have not built it. What I have is the screen-side list, which is finite and has been run once for real; the conversational list of reasons, fifteen so far, which has not been run at all; and a thinking tool of my own with both sides in it, which is where the first run will happen. That is the next piece. Building the skill that detects and writes the rows is the work; the inventory over a real product is what tells me whether the fifteen are the fifteen.
One thing follows for anyone building a conversational product now, and I will state it as a requirement rather than a thought: the list of reasons is the first job of that agent, not an afterthought. The conversational side has no rail, so the points have to be found by kind, and the kinds have to exist before the build. And a rulebook can only say "banner" if there is a banner — so the carriers have to exist before the first row is written too. Which brings me to the thing that has been happening in plain sight while I wrote this.
The standard forming under our noses
The deterministic world had one carrier per level. A toast for the small thing, a banner for the bigger one, an inline line for the field, a box for the thing that must stop you. Each level had its own component, and the rulebook's job was to pick the right one.
The conversational tools have collapsed that whole set into two. Look at any of the leading ones this year — Claude, ChatGPT, Gemini, the coding tools — and you find the same pair. Inside the stream, an expandable block: collapsed by default, a line that says what is happening or what happened, opened only when you want the depth — which files it read, which steps it took, why it changed its mind. Beside the stream, a panel: the plan, the steps, the progress, the outcome, standing still while the conversation scrolls. Two carriers, carrying everything the toast, banner, line and box used to carry between them, and the depth that none of them could. Nobody designed this standard. Each tool watched the others, took what worked, made its own version, and within about a year they had converged.[9] It is still moving. But it is recognisably one thing now, and any product with a conversational side will be measured against it.
What the two carriers do not settle is the harder question, and it is the one this discipline exists for. A deterministic system tracked one process. You saved a file; the system told you about the file. A conversational tool tracks several at once, and they run on different clocks: the task you just asked for, the plan it sits inside, the longer arc underneath — in a thinking tool, the path you have taken between kinds of thinking, the thing you predicted and have not yet checked, how the work is going over weeks and not minutes. All of those are true at the same moment, and all of them could be shown. That is the Christmas tree again, one level up: not which lamp, but which process earns a lamp, at what strength, in the block or in the panel, and which stays dark until it changes. Deciding that — before the build, per product, by what the product is for — is the first job of system response design on the conversational side. The carriers are converging. What they carry is still every product's own decision, and most products have not made it.
I have one such product to hand, and the panel in it already holds more than the task. What it should hold, how loudly, and whether the dialogue itself is even the right surface for a long piece of thinking — or whether a map of the work, with the threads and their connections visible, replaces the scroll — is the next piece, and it needs a proper look at how the leading tools actually do it before I say more than this.
Where this leaves you
If you take five things from this piece, take these.
Every product has two halves, and only one was ever designed. The other — what the system says back, when, where, how loud — was assembled by whoever held the code.
That half has a first rule, found three times over: show what changed, never what is working. A signal is worth what the silence around it is worth.
Design systems hold the carriers and never the rules. The rulebook is a separate thing, it is small, and one response at a time you can get away without it. Three parties on one moment, you cannot.
The layer lives in time — in the three minutes, in what is said when the answer never comes — and neither a prototype nor a written specification can display time. That is why it passes every review.
And a second kind of system has arrived with no rail to walk, so the points are found by reason, not place; the real product has both sides; and the screens now come before the rules. That is why the bar went from one to ten this year, and why the discipline needs a name.
The name is system response design. The tool that once held part of it was dropped because writing the rules by hand cost too much; that cost is gone. And a standard for the carriers is forming in front of us — the block in the stream, the panel beside it — while what they carry is still every product's own undecided question.
The next piece takes that question on: how the leading tools actually answer today, what they show and what they keep dark, which processes a thinking tool has to track beyond the task, and whether the dialogue is even the right surface for long work. The inventory — an agent with a skill for it, run over one real product with both sides — runs alongside, and feeds it.
The open question
I will end where I am honestly stuck, because it has moved.
A year ago the question was whether this layer could be written down at all for a system with no rail. I now think it can — by reason, not by place — and that an agent can do most of the writing. So the question is no longer whether the rulebook can exist. It is what you put in front of a review once it does. A rulebook is a document, and I have already said what a document cannot do: make you see three things landing on one moment. A test suite is a set of checks, not a picture. The panel that shows agents fanning out is a live view of one product running, not a surface for the product before it runs. Axure's generated report was closer than anything since, and it was still a list.
And yet the picture is half there. The panel beside the stream — the plan, the steps, the progress — is, at runtime, exactly the surface I said nobody had: several processes, on one screen, at their own strengths, with the depth one click away. It shows the moment while the product runs. What it does not do is exist before the product runs. Somewhere between a screen, which shows a place, and a document, which lists events, there ought to be a way of showing a *moment* before the build — the payment through, the address failed, the session gone, and the rule that decides which is said first — so that a reviewer's eye does not slide over it, so that the product owner with the finished-looking screens can see what is missing, so that the layer gets caught in the one review where catching it is cheap. Whether the panel that is now standard at runtime can be turned round and used as that design surface is the question the next piece has to answer.
When I told the payment scene to a colleague this week, he finished it for me — the waiting, the empty basket, the trip to the inbox — before I got to the end. Everyone has the memory. Nobody has the picture. The agent can write the rulebook. Finding the picture is still ours.
FIGURE 4 — The whole of entry 1 on one sheet, drawn for the podcast episode. Click on the picture to open it full size.
Disclaimer
About this piece. This is a personal exploration, not a research paper. The views are my own, and the concept I describe — STIMULUS, and the interaction contract inside it — is my own work in progress, tested against the research but not proven by it. Where the research says no, I have tried to say so as plainly as where it says yes; where it is silent, I have said that too, and a hypothesis is still a hypothesis.
How AI was used. This piece was researched, thought through and drafted with AI assistance, and I want to be exact about how. The eight research rounds were run as deep-research briefs across four tools — Claude, ChatGPT, Gemini and Perplexity — and the four reports for each round were compared against each other and against my own concept before anything was written. Claude, in Anthropic's Cowork mode, was my research partner through the comparison, the drafting and the citation checks, and drew the figures. The text was dictated with Wispr Flow and worked into shape in dialogue with Claude; the voice, the concept, the rulings and the mistakes are mine. Every study cited was verified against its published source before it went into the text; the numbers quoted are the published ones.
Sources. The research spans learning science, cognitive load, decision-making under pressure, human factors in aviation and control rooms, the games industry, and the neuroscience of motivation and reward. The key studies are listed under Links below, with the journal and year, so that anyone can check them.
Sources & further reading
The inherited loop — this essay is part three of five.
The full journey:
-
https://www.stimulus.se/2026/09/29/the-inherited-loop-1-we-named-it-chat-and-built-it-to-fit-the-name/ (part one)
-
https://www.stimulus.se/2026/09/29/the-inherited-loop-2-the-borrowed-drive-and-a-tool-built-for-leaving/ (part two)
-
https://www.stimulus.se/2026/09/29/the-inherited-loop-3-the-half-nobody-designed/ (part three)
-
https://www.stimulus.se/2026/09/29/the-inherited-loop-4-where-the-two-halves-meet/ (part four)
-
https://www.stimulus.se/2026/09/29/the-inherited-loop-5-who-is-steering/ (part five)
Sources
- Thaler, R. H. & Sunstein, C. R. (2008). Nudge: Improving decisions about health, wealth, and happiness. Yale University Press. Fogg, B. J., Fogg Behavior Model — "Behavior happens when Motivation, Ability, and a Prompt come together at the same time." behaviormodel.org
- Deci, E. L., Koestner, R. & Ryan, R. M. (1999). A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation. Psychological Bulletin 125(6), 627–668 — engagement-, completion- and performance-contingent rewards "significantly undermined free-choice intrinsic motivation". Murayama, K. et al. (2010). Neural basis of the undermining effect of monetary reward on intrinsic motivation. PNAS 107(49), 20911–20916 — reward "undermines intrinsic motivation, as assessed by the number of voluntary engagements in the task."
- Wroblewski, L. (2009). Inline validation in web forms. A List Apart, 1 Sep 2009 (research with Etre) — "validating inputs prematurely can be harmful"; a participant: "I found it quite annoying how red crosses came up when you hadn't finished typing"; the after-the-field variant "completed the form seven to ten seconds faster". alistapart.com/article/inline-validation-in-web-forms
- Health and Safety Executive, Better alarm handling, Chemicals Information Sheet 6 (EEMUA 191 summarised) — "the long-term average alarm rate during normal operation should be no more than one every ten minutes"; "In the last 11 minutes before the explosion the two operators had to recognise, acknowledge and act on 275 alarms." HSE (1997), The explosion and fires at the Texaco Refinery, Milford Haven, 24 July 1994. Cvach, M. (2012). Monitor alarm fatigue: an integrative review. Biomedical Instrumentation & Technology 46(4), 268–277 — "the number one medical device technology hazard in 2012".
- Google, Material Design 3, Snackbar — guidelines ("Snackbars show short updates about app processes at the bottom of the screen"), m3.material.io/components/snackbar/guidelines; Atlassian Design System, Banner — usage ("Use banners sparingly at the top of the screen to display critical messaging"), atlassian.design/components/banner/usage.
- Tidwell, J., Brewer, C. & Valencia, A. (2020). Designing Interfaces: Patterns for effective interaction design, 3rd ed. O'Reilly. ui-patterns.com — "recurring solutions that solve common design problems".
- Anthropic, Claude Code documentation, Create custom subagents — "Each subagent runs in its own context window", progress shown in the task list; code.claude.com/docs/en/sub-agents. OpenAI, Subagents — "spawning specialized agents in parallel and then collecting their results in one response … Subagent activity appears in the ChatGPT desktop app, Codex CLI, and the IDE extension."
- Axure RP documentation, Conditional logic — "Conditional logic is a system of rules you can use to specify when an interaction you've built should occur"; The Word specification — "an automatically generated Microsoft Word document that serves as the functional specification component", with "a text summary of the widget's interactions". archive.axure.com/axure-rp/reference/conditional-logic · …/word-specification (RP 7–8, 2014–2016).
- OpenAI, Introducing canvas, 3 Oct 2024 ("opens in a separate window"); Anthropic, Introducing Claude 3.5 Sonnet, 21 Jun 2024 (Artifacts "in a dedicated window alongside their conversation"); OpenAI, Introducing OpenAI o1-preview, 12 Sep 2024 (the collapsible thinking summary); Anthropic, Claude 3.7 Sonnet and Claude Code, 24 Feb 2025 ("step-by-step thinking that is made visible to the user").
THE STIMULUS EFFECT | Podcasts
The inherited loop 1 – We named it chat, and built it to fit the name
The inherited loop 2 – The borrowed drive, and a tool built for leaving
The inherited loop 4 – Where the two halves meet
0 Comments