Speculative design gives engineers a way to threat-model the consequences of a system before it exists at scale. Instead of asking how an attacker could break what you are building, it asks what the world looks like once your system works, everywhere, for ten years, and then works back to the decisions in this quarter's RFCs, APIs and risk registers that would make that world safer, fairer or simply less surprising.
Paul Virilio's line about invention applies to engineers more literally than to anyone: to invent the ship is to invent the shipwreck. Engineers choose the materials and decide how many passengers it carries, so the shipwreck is, in a precise sense, an engineering artefact. It just arrives later than the release notes. This guide covers what is specific to engineering. The shared workflow is in the speculative design methodology, and the definition in what speculative design is.
What engineers already have
Engineering has more formal rituals for imagining failure than any other profession we teach. An RFC is a written argument about a system that does not exist yet, with alternatives considered. A threat model, built from STRIDE categories or attack trees, is structured adversarial imagination. Risk registers give each risk an owner. Pre-mortems assume the project failed and ask why. Blameless postmortems trace contributing causes. Chaos engineering stages failure in production on purpose, and machine learning teams add red-teaming and evaluation suites.
That is a real head start. The habits speculative design has to teach other professions, such as assuming the bad outcome, tracing causes past the first one and writing it all down, are already in the culture.
What limits these rituals is scope and horizon. A threat model asks what can happen to the system. It rarely asks what the system does to the world when it works perfectly. And nearly all of them are bounded by the release, the incident or the deprecation window. Speculative design keeps the rigour and moves both boundaries.
The horizon problem: your code outlives your plan
Engineers plan in sprints and quarterly roadmaps. What they build lasts decades. Storing Unix time as a signed 32-bit count of seconds since 1970 was a sensible choice once. It now sets a hard limit, at 03:14:07 UTC on 19 January 2038, for any system still using it, and that date falls well within the service life of embedded devices installed this year. Engineers call this kind of inherited future technical debt, but they count it as a cost to whoever inherits the code. The consequences that matter for speculative work land on everyone else.
The second half of the problem is feasibility. An engineer's sense of the possible is calibrated against today's stack and today's bill of materials. That makes engineers the best-informed people in the room about the probable future and the most likely to rule out the possible one. Amara's Law names the error: we overestimate a technology in two years and underestimate it in ten. This is why we set the work beyond ten years, far enough that today's constraints stop binding the conversation.
Where it fits in an engineering process
Speculative design does not need a new phase. It attaches to the rituals that govern decisions with long tails: the RFC for a new platform or data model, the architecture review, the threat-model refresh, and the protocol you will be locked into for years.
The nearest existing practice is Consequence Scanning, which the UK think tank Doteveryone first ran in January 2019 and published as a lightweight agile practice. In it, a team asks about the intended and unintended consequences of a product or feature, which to focus on and which to mitigate. Adopt it as it stands. Speculative design differs in its horizon, a decade rather than a sprint, and in making a specific future concept for the consequences to attach to.
It also treats regulation as a design input rather than a compliance task. The EU AI Act entered into force on 1 August 2024. Since the AI Omnibus amendments took effect in July 2026, its high-risk obligations for Annex III systems apply from 2 December 2027. Annex III includes AI used as a safety component in the supply of electricity, gas, heating and water. An architecture fixed in 2026 will spend most of its life under rules that were still being negotiated when it was drawn.
| You already use | Its speculative counterpart | What it adds |
|---|---|---|
| RFC or design doc | A design doc dated 2037 | Alternative futures alongside alternative implementations |
| Threat model | A future wheel as a consequence threat model | Harm from the system working as designed |
| Risk register | Implications across the social, ethical and political | Risks with no CVE that still decide whether a system may exist |
| Pre-mortem | The shipwreck question, asked of a concept | Failure of a product before anyone builds it |
| Game days, red-teaming | A speculative prototype at minimum fidelity | How people react to a future, not how a system survives a fault |
| Technical roadmap | A backcast from the concept | Regulatory and standards rungs with owners, beside the technical ones |
A worked example: a dispatch platform in 2037
Take a hypothetical platform team at a UK energy supplier. Call it Northwold. Its software schedules customers' heat pumps, EV chargers and home batteries against half-hourly prices, and it is about to re-platform the dispatch service. The API it ships this year is the one it will live with for a decade.
The brief. The source of change is software-controlled household load at national scale. The domain is Northwold's dispatch platform, the horizon is 2037, and the audience is the architecture review board.
Signals. Three real, dated events:
- •On 23 January 2023 Great Britain's electricity system operator ran the first live event of its Demand Flexibility Service, paying people through their suppliers to cut peak demand. That winter 1.6 million households and businesses took part.
- •In August 2018 Princeton researchers Saleh Soltan, Prateek Mittal and H. Vincent Poor presented BlackIoT at USENIX Security. In simulations on real grid models, compromised high-wattage devices switched together caused local outages and, in the worst cases, large-scale blackouts.
- •On 10 December 2025 the UK government published draft regulations for a load control licence, enforced by Ofgem, for organisations controlling EV chargers, heat pumps and home batteries. It cites the risk to grid stability and aims for the requirement to be in force by the end of 2027.
The future wheel. At the centre: by 2037, most homes' flexible load is dispatched by software as a matter of course. The first ring is the one in every supplier's brochure. Bills fall and peaks flatten. The second ring is more useful. A household's comfort becomes a term in someone else's objective function, a single deploy can move gigawatts, and homes without flexible kit, often rented ones, keep paying peak prices. The third ring is where the engineering surprises are. A bad config push becomes a grid event. Households with medical equipment need guaranteed exclusion, which means holding data the platform should not want. Attackers target controllers rather than homes. (How to run a future wheel.)
The concept.
- •Name: Holdfast, from a hypothetical controls maker called Kestrel.
- •Tagline: "Your house keeps the last word."
- •Description: A unit fitted between the home's devices and whichever licensed controller is dispatching them. The household sets a few rules, for example never below 18°C overnight and never interrupt the back-bedroom socket. Commands that break a rule are refused, the refusal goes back with a reason code, and both are logged for disputes.
- •Sketch: A grey box with one dial and a two-line display: "3 commands today, 1 refused: comfort floor."
Implications. Start with a person. A care worker on nights comes home to a warm house because Holdfast refused a 5am turn-down. Her neighbour has no Holdfast and gets turned down twice as often, because the platform routes around homes that can refuse. Comfort has become a purchasable exemption from being the grid's buffer, and no threat model would have found that. Technologically, the flexibility forecast becomes a forecast of human rules the platform cannot see. Politically, one lobby wants interlocks mandated and another wants them restricted on grid-stability grounds. Then the shipwreck: if regulators require a remote emergency override in every interlock, that override becomes the most valuable switch in the country. It is BlackIoT again, with one compromised channel instead of thousands of compromised heaters.
Backcasting. Work back from 2037 and ask what had to be true (more on backcasting). There is a regulatory rung, the load control licence, which has a real owner and a stated date. There is a standards rung, because somebody had to add a field to a device protocol that lets a heat pump refuse and say why. There is a threshold, the share of controlled homes at which one platform's config push counts as a grid incident. And there may be a disruption, a cold-snap failure that compresses a decade of policy into a winter.
What changes this quarter. None of these needs Holdfast to exist:
- 1.Make "refused" and "partially honoured" first-class states in the new dispatch API and the flexibility forecast. That change is cheap now and expensive after re-platforming.
- 2.Add synchronous dispatch to the threat model and the risk register, with familiar mitigations: randomised start offsets, ramp-rate limits on large batches, and staged rollout for dispatch config exactly as for code.
- 3.Add a consequences section to the RFC template for any change that widens how many devices one command can reach, answered for ten times today's fleet.
- 4.Name an owner to track the licence conditions. Where they touch the roadmap, bring in product early. Our guide for product managers covers their side.
Where it goes wrong for engineers
"That's not possible" in the first hour. This comes from expertise, not cynicism. Someone correctly notes that today's hardware cannot do what sits at the centre of the wheel, and the session falls back into the probable. Do not ban feasibility. Postpone it to backcasting, where it becomes the list of what would have had to become possible.
Every implication becomes a ticket. This is techno-solutionism. Each consequence gets a patch, such as an opt-out toggle or a fairness dashboard, and the wheel turns into a backlog. Holdfast's political implications cannot be fixed with a feature flag, and treating them as if they could means nobody escalates them.
The demo that works too well. A working prototype gets a code review. The conversation turns to latency and edge cases instead of whether the thing should exist. A mocked-up display and a printed dispute log start a better argument. Designers hit the same trap with interfaces, which our guide for UX designers covers.
Modelling only the adversary. Threat-modelling habits pull the analysis back towards attackers. Holdfast's neighbour, though, is harmed by a platform doing exactly what it was built to do.
A first exercise
Allow two hours, a whiteboard and your RFC template.
- 1.Pick a system you own whose design decisions will still be running in 2037, such as a data format, protocol, device fleet or model in a decision loop.
- 2.Assume it runs at ten times today's scale and every competitor has one.
- 3.Run a three-ring future wheel for 45 minutes. Park feasibility objections on a separate list.
- 4.Mark each third-ring item with one question: who is harmed when this works as intended?
- 5.Choose one item and write a one-page design doc dated 2037 for a named product in that world.
- 6.Backcast it, and find the regulatory, standards or threshold rung that has an owner and a date today.
- 7.Bring one change to your next architecture review.
Where to learn it
Speculative Design Basics teaches the whole workflow in 42 self-paced lessons, taught by J. Paul Neeley, with lifetime access and no prior experience assumed. For engineers three parts matter most. The opening chapter on Amara's Law and futures cones counters feasibility-filtering. The Tools & Methods chapters on signals, future wheels, future prototyping and backcasting are the working equivalents of the threat model and the roadmap. The Ethical Imperative argues that the people who build a system have a particular obligation to look at what it does. Guides for the people you work alongside are collected at speculative design for every role.
Key takeaways
- •Engineers build the ship and therefore the shipwreck. Speculative design lets you look at the shipwreck while it is still a design decision.
- •Engineering already rehearses failure well. Speculative design widens the scope from what happens to the system to what the system does, and the horizon from the release to the decade.
- •The engineer's horizon problem has two halves: artefacts outlive the plan, and feasibility judgement is anchored to today's stack.
- •Use the future wheel as a consequence threat model, treat regulation as a dated design input, and postpone feasibility to backcasting rather than banning it.
- •A good backcast ends in engineering language: an API state, a rate limit, a risk-register entry, an RFC section.
- •The failure modes to watch are feasibility-filtering, turning every implication into a ticket, prototypes that work too well and modelling only the adversary.
Frequently asked questions
How do engineers use speculative design?
Engineers use speculative design to model what a system does to the world once it works at scale, ten or more years out. The future wheel works like a threat model for consequences rather than attackers, a named speculative concept makes those consequences specific, and backcasting turns them into decisions available now: an API state, a rate limit, a risk-register entry or a new section in the RFC template.
Is a future wheel just a threat model with a different name?
No. A threat model asks how an adversary could make a system fail. A future wheel assumes the system succeeds, at scale and for years, and maps the consequences of that success two and three steps out. Most of what it finds involves nobody acting maliciously: costs shifting to people who cannot opt out, control concentrating in one place, or new single points of failure created by the system working exactly as designed.
How is speculative design different from consequence scanning?
Consequence Scanning, published by the UK think tank Doteveryone in 2019, is a lightweight agile practice in which a team considers the intended and unintended consequences of a product or feature. Speculative design works at a longer horizon, usually beyond ten years, and makes a specific future concept to argue about. The two fit together: consequence scanning for the feature in this sprint, speculative design for the platform decision you will live with for a decade.
Why should an AI or machine learning team look ten years ahead?
Because the systems outlive the planning window and the rules around them are still moving. The EU AI Act entered into force in August 2024, yet its obligations for high-risk systems listed in Annex III now apply from December 2027. A system put into a decision loop today will spend most of its working life under conditions of regulation, scale and use that were not fixed when its architecture was set.
What is the best way for an engineer to learn speculative design?
Speculative Design Basics, the School of Critical Design's self-paced online course taught by J. Paul Neeley, covers the whole workflow in 42 lessons with lifetime access and no prior experience assumed. For engineers the most useful parts are the opening theory on Amara's Law and futures cones, the Tools and Methods chapters on signals, future wheels, future prototyping and backcasting, and the chapter called The Ethical Imperative.