One of the cool features of JPEG files is that there's the option to save low frequency components first. This means that a partially downloaded image will be displayed at low resolution instead of being cut off.

In the file, this works by breaking up the compressed data into multiple "scans", each prefixed with a header. Here's the first scan of a representive image:

FF DA - "start of scan" marker
00 0C - Big endian length field (12 bytes) Includes itself
03 - Number of channels in scan (3)
  01 - Global id of first included channel
  00 - Huffman table index #1 (DC: 0, AC: 0)
  02 - Global id of second included channel
  10 - Huffman table index #2 (DC: 1, AC: 0)
  03 - Global id of third included channel
  10 - Huffman table index #2 (DC: 0, AC: 0)
00 - Starting DCT bin (DC)
00 - Ending DCT bin (also DC)
01 - Precision: half, no pre-existing data. 

f8ad 512d d3f1 cd96 - Huffman coded DCT coefficients
bcb0 58df 53d5 5d97
[...and a lot more]

... this one includes the lowest (DC) Fourier bin for all three color channels.

The three color channels are YCbCr instead of the usual RGB. The luminance (Y) seperated because it must be high quality, but the color can be fudged quite a bit while looking fine.

Very roughly: Y = G, Cb = B - G, Cr = R - G

After it, the file contains eight more scans to fill in the rest of the data:

Scan #0 contains a very low resolution preview of the image.

Scan #1 adds some details to the luminance.

Scans number two through five contain full low precision data.

Scan 4 has an unusual spectral range because it's filling in the gap left by #1. That way, number 5 has full quarter precision data to build on.

Scans six through nine add the final missing bit to bring the image to full quality.

Given what I said about color being less important, it might seem weird that my example has the color data first: This works because the the chrominance is saved at half resolution (quarter pixel count). As a result, full chrominance data (Cr + Cb) only weighs half as much as luminance.

Since each scan explicitly sets its spectral range, it should be possible to construct a JPEG file where future scans overwrite already rendered image data.

Actually, it's very easy to do this:

Concatenate multiple images with the same resolution and filter out the start-of-image, start-of-frame and end-of-image markers. This can be done in a hex editor, but I used a quick and dirty C program.

When served over a slow network, this concatenated file will switch between multiple images:

Click to open in new tab

But, most decoders will give up after some number of scans: I think this is done to avoid a zip bomb style problem... but it prevents this from working on more than 9 frames, which is not enough for a proper animation.

To do that, I'd have to minimize the number of scans in each frame. The simplest idea is to start with baseline JPEGs that only have a single scan.

... but it doesn't work:

In progressive mode, a scan can't contain both AC (bins above 0) and DC (bin 0) data at the same time. This limitation doesn't exist for baseline mode, but the baseline decoder stops after the first scan.

Since AC data must follow DC data, the smallest possible "progressive" JPEG contains a single DC-only scan. Because the DCT runs on 16x16 blocks, such an image won't a solid color:

it'll be 1/16th of the original resolution.

Doing this, I can get Chrome to render around 90 frames before giving up. Other browsers like Firefox have more patience, but a 90 scan image seems to work almost everywhere.

As a bonus, this avoids the ghosting of the naive attempt: that happened because AC scans are supposed to refine old data. Normally, this allows images to include multiple precision levels without inflating file size... but doesn't play nicely with my tricks.

If the file only includes DC scans with no actual progression, this isn't a problem.

Since a "DC-only" frame is a standards-compliant images, creating them doesn't require anything special:

cat > frame.scans<<EOF
# DC only scan:
0,1,2:0-0,0,0;
# and nothing else
EOF
jpegtran -scans frame.scans -outfile out.jpg in.jpg

Using these, it's possible to pack a whole video inside a single image:

A 'video' of a black cat walking towards the camera.

Click to open in new tab

Besides unconventional rickrolls and other trolling, this has no practical applications: there's no way to add timing information, so playback is entirely dependent on network delay.

... although there is a lot of fun to be had using partial rendering:

This is a pure HTML video using <dialog> tags: badapple.rose.systems

Of course, there's no rule that the data must be hardcoded: here's a interactive single-page application with no CSS or JavaScript.

TL;DR: I gave Claude Fable 5 and GPT-5.6 Sol the same unpublished NP-hard optimization problem, with and without their native /goal mode. Fable 5 is an absolute beast; /goal is not a game changer.

Context: This is an operations research problem originally submitted to students at a hackathon. I spent a week years ago writing C++ to solve it, so I have a useful human baseline.

Fable 5 was an absolute beast on this benchmark. It produced the best solution overall, and its consistency is unlike anything I have seen from a model on this problem. This is pure raw intelligence. Incredible.

The other result is that /goal is not a generic “try harder” switch. It changes the control loop and the search path. Sometimes that finds a better basin. Sometimes it gives a bad idea more time to mature.

All code, prompts, result tables, exclusions, and trajectory notes are in CLIArena. This is a follow-up to my first article about this benchmark.

The problem

KIRO is a fiber-network design problem I worked on as an engineering student in 2018. Given directed distance matrices for Grenoble, Nice, and Paris, the solver has to connect distribution points and terminals using loops and short chains while respecting several structural constraints. The objective is total cable length. Lower is better.

A valid network consists of redundant loops rooted at distribution hubs, with short branches hanging from towers on those loops. Every tower must appear exactly once, and reversing a cable segment can change its cost.

How large is the search space?

There is no single closed-form count because a solution can use any number of loops, variable loop sizes, and differently anchored and ordered branches. But Paris alone gives a useful lower bound.

Even if we ignore ordering and branches and only assign each of the 532 terminals to one of 11 distribution hubs, there are 11^532 possible assignments.

A stronger lower bound comes from one deliberately restricted family of valid solutions: exactly 19 loops of 28 terminals each, with no branches. This covers all 532 terminals because 19 x 28 = 532, while staying below the 30-terminal limit for a loop. Order the 532 terminals, split that ordering into 19 consecutive groups, divide by 19! because the set of loops is unordered, and choose one of the 11 hubs for each loop:

(532! / 19!) x 11^19 ~= 10^1223

What I tested

The primary experiment was intentionally narrow:

Results

Before concentrating repetitions on the flagship pair, I ran one matched 30-minute no-hint pair for every model in the sweep. For Fable and Sol, the chart uses Pair 1 from the replicated headline set; the other four models have one pair each.

I then repeated the flagship comparison until I had three matched runs for Fable 5 and three for Sol.

Negative means /goal was better. Goal won four of six trials, so win rate alone makes the feature look useful. The means tell the other half:

Both models usually got a small benefit and occasionally suffered a large regression. That is why /goal won most runs but made both means worse.

Fable was also clearly stronger. Its plain mean beat Sol’s by 1,875 points, and its goal mean beat Sol’s by 1,984. More importantly, Fable plain stayed inside a tiny 319-point range while Sol plain spanned 1,958 points. Fable goal produced the best clean score, 31,934; Fable plain was the safest configuration.

Deep dive into the goal command

The same command hides two different systems

Claude Code and Codex both expose /goal, but the implementations are fundamentally different.

Claude Code: a separate evaluator

Claude Code implements /goal as a session-scoped Stop hook. After each main-model turn, a small evaluator model, Haiku by default, reads the condition and conversation. It returns yes or no with a reason. A no starts another turn; a yes clears the goal.

The evaluator cannot use tools or inspect files. It can only judge evidence that appeared in the transcript. That can catch an early exit, but it cannot know whether another ten million solver iterations are worthwhile. Anthropic’s goal documentation

Keep in mind that claude code is not open source, so we rely solely on what Anthropic tells us.

Codex: persisted state and lifecycle tools

I also read the source for the benchmarked release, Codex CLI 0.144.4. Codex treats a goal as persisted thread state:

1. The TUI saves the objective for the active thread, and SQLite stores its status and budget accounting. TUI, schema
2. The working model receives create_goal, get_goal, and update_goal tools. Tool specification
3. If the thread becomes idle while the goal is active, Codex injects a continuation turn with the objective and a completion audit. Runtime, prompt

Claude delegates completion to another model. Codex lets the working model declare completion, then resumes it while the persisted goal remains active. Claude’s evaluator is independent but sees only the transcript; Codex sees the files and tools but effectively grades its own work.

Why /goal can win most runs and still be a bad default

On a normal coding task, progress is often legible: another turn can fix a test or complete a migration. Optimization is different. Once an agent chooses a solver, extra time can amplify either a good decision or a bad one.

That is exactly what happened here. Goal helped when it sustained Fable’s fast compiled portfolio or Sol’s successful chain repartition. It hurt when Fable built a slow solver or Sol committed to an exhaustive anchor sweep. The median moved slightly in the right direction; the bad tail moved much farther in the wrong one.

Limitations

This is one unpublished NP-hard task, not a general coding leaderboard. Only Fable and Sol have three clean matched pairs. Other comparisons mix prompts, wrapper versions, and time limits, and the trials ran sequentially through subscription services that may have drifted.

The containers exposed eight CPUs despite task metadata declaring one, which favored Fable’s parallel portfolios. Every scored Fable and Sol output was valid, partly because the wrapper required early checkpoints and final verification. The benchmark measures the complete system: model, CLI, prompt, subscription service, and harness.

Reproducing this

The benchmark task, wrappers, analysis scripts, figure generator, and full evidence memo are in CLIArena. Raw job directories are excluded from Git because of their size, but the memo records every publishable score, city breakdown, elapsed time, strategy, exclusion, and run ID.

The primary commands are:

RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh

uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...

The result I would put in the headline is not that goal helps or hurts. It is that a persistence feature can win most individual trials while making observed average performance worse. On a hard optimization problem, the quality of the loop matters less than the quality of what the loop keeps doing.

If you pay attention to AI company branding, you'll notice a pattern:

1. Circular shape (often with a gradient)
2. Central opening or focal point
3. Radiating elements from the center
4. Soft, organic curves

Sound familiar? It should, because it's also an apt description of... well, you know.

A butthole.

The circular AI logo epidemic

If you ever thought that AI company logos look like buttholes, you're not alone.

FastCompany noticed this trend in 2023 and published an article about it, but (I could only presume) their editors and lawyers didn't let them title the article the way the wanted it to title, so it got published with a more safe for work title: The AI boom is creating a new logo trend: the swirling hexagon. They also were careful not to mention anything anatomical.

I don't have editors or lawyers, so let's take a closer look at some examples:

OpenAI's logo evolution

OpenAI's original logo was a simple, text-based mark. Then came the redesign: a perfect circle with a subtle gradient and central void.

OpenAI's official explanation is a masterclass in corporate euphemism:

"The Blossom logo is more than just a visual symbol; it represents the core philosophy that guides our approach to design and innovation. At its heart, the logo captures the dynamic intersection between humanity and technology—two forces that shape our world and inspire our work. The design embodies the fluidity and warmth of human-centered thinking through the use of circles, while right angles introduce the precision and structure that technology demands."

Sure, Sam.

Translation: "We made a circular shape with some angles because it looked nice, then wrote flowery language to justify why our butthole-adjacent design is actually profound."

The fluidity and warmth of human-centered thinking through the use of circles is perhaps the most elegant way anyone has ever described making a logo that resembles an anus.

The Big AI companies

Looking at the logos of the Big AI companies, you can see that they almost all of them have a circular or snowflake-like shape and a central opening.

Only DeepSeek and Midjourney don't follow the trend. Interestingly, both are sea-related.

Smoking gun: Anthropic's Claude

Up until this point, the logos have been subtle. You might say that the logos are simply circular and there's not much more to it.

But Anthropic's Claude takes it to the next level.

Here's a side-by-side comparison with a drawing from Kurt Vonnegut's book "Breakfast of Champions". I added Claude's logo below for easy comparison.

Both the drawing and the description in the book are unambiguous. This is not just "a circular shape with a gradient" anymore, is it?

July 2026 update: the smoking gun now moves

Since publishing this article, I've discovered new evidence. Open claude.ai and click on the Claude logo. Just watch what it does:

The Claude logo, when clicked. I have no further questions.

Every click makes the logo clench and relax. It even responds with a slightly annoyed "Yes, yes. What can I do for you?", as if you poked something you weren't supposed to.

At this point, there's no argument you could make that would persuade me this is not a butthole 🙂

It's not just AI companies

Even traditional companies aren't immune. Here are a few notable or funny examples. But the percentage of AI company logos that look like buttholes is still significantly higher than than any other industry.

I especially like the Electrolux one. It's simple, memorable, and once you see a butt and bikini, you can't unsee it.

Why does this keep happening?

There are several factors at play:

Circular design psychology

Circles represent wholeness, completion, and infinity—concepts that align with AI's promise. They're also friendly and non-threatening, qualities companies desperately want to project when selling potentially job-replacing technology.

Unintentional biomimicry

The human brain finds familiar patterns in random shapes (pareidolia), like a face on Mars, taken by the Viking 1 orbiter and released by NASA in 1976.

But sometimes, designers inadvertently recreate biological forms without realizing the... anatomical implications.

The copycat effect

Once a few major players adopted the circular sphincter aesthetic, everyone followed suit. Now we have an industry where standing out means looking exactly like everyone else's butthole.

Basically, the same reason why so many brands change their logos and look like everyone else.

Tech and fashion logos using sans serif fonts

Design by committee

Another factor is how these logos are created. Important corporate decisions involve many stakeholders. The result is often the safest, most inoffensive option, the average of everyone's opinions. In design meetings at AI companies, conversations probably sound like:

• Can we make it more futuristic?
• It needs to feel advanced but approachable.
• Let's add a subtle gradient to convey intelligence.

No single person suggests making a logo that resembles an anus, but when everyone's feedback gets incorporated, that's what often emerges. Risk aversion in corporate environments naturally pushes designs toward familiar, "safe" territory, which apparently means anatomical openings.

What this says about tech branding

This phenomenon reveals something deeper about the tech industry: the fear of standing out too much. Despite claims of innovation and disruption, there's tremendous pressure to look legitimate by conforming to established visual language.

When OpenAI's sphincter-like logo became successful, it created a template that said, "This is what serious AI looks like." Now, any new AI company that doesn't resemble a colorful anatomical opening risks being seen as unserious or unprofessional.

Tech design trends through history

This isn't the first time tech design has gone through a conformity phase. Consider these previous waves:

• 1990s-2000s: 3D and Glossy - Remember when every logo needed a drop shadow and a glassy shine? Apple's aqua interface set the standard.
• 2010-2013: Skeuomorphism - Digital designs mimicking physical objects, with stitched leather textures and realistic dials.
• 2013-2018: Flat Design - Reaction to skeuomorphism brought minimal, clean interfaces with bright colors and no shadows.
• 2018-2022: Neomorphism - Soft shadows and semi-flat design creating subtle, "touchable" interfaces.
• 2022-Present: The Butthole Era - Circular gradients with central focal points dominating AI branding.

Each era started with innovations that were quickly copied until the industry reached saturation point and moved on to the next trend.

Sans serif bags

Logos become increasingly interchangeable (one of the bags is real, but they all look the same)

Historic logo disasters: You're not alone

AI companies can take some comfort in knowing they're not the first to face unintended anatomical comparisons. Logo history is filled with disasters but to keep this consistent with the theme of the article, here's a couple of them.

Logo disasters

• Zune logo, when flipped, says something different. Maybe that's one of the reasons why iPod won?
• Brazilian Institute of Oriental Studies is a stylized pagoda silhouetted against the setting sun. Or so the designers wanted it to look. The final result was much more... anatomical. They since changed it to something less suggestive.

Maybe companies should have a panel of "middle schoolers" on their payroll to review logos before launch. They'll find every possible inappropriate interpretation with ruthless efficiency.

Breaking free from the butthole

For companies brave enough to differentiate, here are some alternatives:

1. Embrace sharp angles - geometric shapes with defined edges create a distinct visual identity
2. Use negative space creatively - think FedEx arrow, not biological openings
3. Avoid radial symmetry - not everything needs to be perfectly circular
4. Skip the gradient - flat design still works
5. Test with diverse audiences - if five different people independently say "that looks like a butthole," it probably does (show it to teenagers if you want to uncover even the most subtle anatomical implications)

Conclusion

Does this mean AI companies should change their branding? Not necessarily. The familiarity clearly works in building trust. But perhaps the next wave of AI innovation could be accompanied by some visual innovation too.

For companies looking to break the mold, consider these approaches that successful tech brands have used:

• Embrace meaningful abstraction - Slack's hashtag-inspired logo communicates collaboration without circular clichés
• Leverage letterforms - Netflix's simple "N" has become instantly recognizable without anatomical confusion
• Tell a story - Stripe's distinctive parallel lines reflect payment flows moving seamlessly
• Use distinctive color combinations - Twitch's purple branding stands out in a sea of blue tech logos

The challenge for the next generation of AI companies isn't just technological - it's finding visual language that communicates innovation without resorting to the same tired sphincter-inspired patterns.

PS. This post is meant to be humorous, but let's not pretend there isn't a serious point here about the depressing sameness in modern design. No actual anuses were consulted during this research, though several designers were clearly thinking about them.

• Fast development with robust practices
• Grows from solo developers to teams of hundreds
• Scales from single servers to global networks
• Built on decades of Erlang reliability and fault-tolerance

Composable data transformations

"Fun to learn, delightful to ship"
|> String.downcase()
|> String.replace(",", "")
|> String.split()
|> Enum.frequencies()

Output

%{"delightful" => 1, "fun" => 1,
  "learn" => 1, "ship" => 1, "to" => 2}

Why Elixir?

Maintenance

Elixir helps developers write clear and purposeful code that focuses on your data and your domain. Thanks to immutability, memory safety, and Elixir's gradual type system, you can build systems that recover from failures and are easy to maintain.

Scalability

A single Elixir codebase can scale vertically (on multi-core machines) and horizontally (communicating across nodes), excelling at message-oriented and web real-time systems. Combined with projects like Numerical Elixir, Elixir scales across cores, clusters, and GPUs.

Loved by developers

Voted one of the world's most admired languages several years in a row.

See survey results

Productivity

Elixir ships with a package manager, code formatter, and best in class documentation. Projects like IEx (interactive shell) and Livebook (interactive notebooks) enable rapid prototyping and live-debugging of running systems.

Elixir in production

Elixir is used by solopreneurs and Fortune 500 companies alike, supporting teams that value developer happiness as well as large-scale operations, across diverse industries and applications.

Use Elixir for

Web development

The Phoenix web framework delivers rapid development, LiveView adds real-time features with minimal code, and Ecto makes your data layer a joy to work with. Ship faster, at scale.

• Phoenix
• LiveView
• Ecto
• Plug

# Update server state from browser events
defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0)}
  end

  def handle_event("increment", _, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end
end

Embedded systems

Nerves packages your entire application into compact firmware, with over-the-air updates and telecom-grade fault-tolerance, while AtomVM brings Elixir to devices as small as microcontrollers.

• Nerves
• AtomVM

# Control hardware from a supervised process
def handle_info(:toggle_led, %{led: led} = state) do
  next_level = 1 - state.level

  :ok = Circuits.GPIO.write(led, next_level)
  Process.send_after(self(), :toggle_led, 500)

  {:noreply, %{state | level: next_level}}
end

Machine Learning

Numerical Elixir (Nx) brings GPU-accelerated tensors to Elixir, while Livebook makes exploration interactive: run pre-trained models, visualize data, and deploy - all in one place.

• Nx
• Livebook
• Bumblebee
• Axon

# Run a pre-trained model with Nx acceleration
{:ok, model} =
  Bumblebee.load_model({:hf, "google/vit"})
{:ok, featurizer} =
  Bumblebee.load_featurizer({:hf, "google/vit"})

serving =
  Bumblebee.Vision.image_classification(model, featurizer,
    compile: [batch_size: 1],
    defn_options: [compiler: EXLA]
  )

Nx.Serving.run(serving, image)

Data and media

Process data at scale with backpressure and concurrency. Broadway handles millions of events from queues, while Membrane gives you composable pipelines for audio, video, and beyond.

• Broadway
• Membrane

# Broadway controls demand and applies backpressure
Broadway.start_link(MyPipeline,
  producer: [
    module: BroadwaySQS.Producer
  ],
  processors: [
    default: [concurrency: 50]
  ],
  batchers: [
    storage: [batch_size: 100, batch_timeout: 1_000]
  ]
)

IoT & Distributed Systems

Thanks to the Erlang VM, Elixir also excels at IoT, distributed systems, and everything Erlang is renowned for. Explore some excellent Erlang projects below.

• EMQX
• RabbitMQ
• Riak

# Connect nodes through Erlang distribution
edge_nodes = [:"edge@factory-1", :"edge@factory-2"]

Enum.each(edge_nodes, &Node.connect/1)

# Execute concurrently across every connected node
:erpc.multicall(
  edge_nodes,
  Sensor, :read_temperature, []
)

What will you build?

The ecosystem grows every day. Explore thousands of community packages on Hex and find the tools for your next project.

Install now See all packages

Shaped by many

Elixir is shaped by the contributions of many. The Elixir Team steers the language and the Erlang Ecosystem Foundation supports Elixir and the broader Erlang community.

Erlang Ecosystem Foundation

Join the foundation

Elixir Open Source Stewards

Companies investing in the Elixir ecosystem by employing or sponsoring developers to work full-time on open-source tooling.

• Membrane, Popcorn, LiveDebugger, Legion. Building Elixir tooling across the whole stack since 2016.

• 
  
  Creators of Elixir, Livebook, Broadway, Plug, and more. Dashbit helps companies adopt and grow Elixir in production.

• Trusted AI for advisors and financial professionals. Contributors to Expert LSP, Quokka, and more.

• Your company

  Learn more

Building instructions. The silent helper that without a single word guides you, step by step, to transform your pile of bricks to fantastic creations. The tool that shows you building techniques and gives you a solid foundation for further exploring the wonders of the LEGO® brick. Let’s take a look at some of the many historic milestones.

Before instructions

The history of building instructions starts with very simplified instructions as early as 1955. Prior to this the only ‘guidance’ for products containing plastic bricks were drawings on the packaging to serve as inspiration for consumers. There were also examples of small leaflets with inspirational material inside some boxes in the 1950s.

box of automatic binding bricks

Example of a set with drawings on the packaging

The company also produced more elaborate inspirational material to hand out or sell separately, the so called “byggebog”, which directly translates to ‘building book’, but perhaps a better term is idea book. The Idea book was first published in 1955 and contained among other things information on different building techniques and inspiration for building houses.

Cover of LEGO® Idea book from 1955

Spread from the book concerning building techniques

Early building instructions

In 1955, the LEGO® System in Play idea was introduced. The groundbreaking idea that among other things makes sure the bricks you buy today will fit with the bricks you bought yesterday and the bricks you buy tomorrow. The first LEGO System in Play products were centered around a town environment (Town Plan no. 1). The town plan and the houses and shops etc. to inhabit the town was the first time the LEGO Group introduced special sets with specific models, as in, the model you saw on the box was also what you could build with the content of the box. This created a need for more instruction to make sure all consumers could reach the wanted result and thus the first simple building instructions were introduced. Although instructions for specific models started to appear there was also a focus on encouraging alternate builds as the below instructions also shows. In the text to the left, it was suggested to build the two buildings together with other buildings on the town plan to create “nice corner shops”.

Example of a simple instruction for a 1955 set intended for the Town Plan

Sketches for some of these instructions found in the LEGO® Group Archives suggest that these early pioneering instructions for LEGO sets were most likely made in-house

Just as the new specialized Town Plan sets with building instructions had a hint of free building/alternate builds in them, the basic sets, with a high degree of free building, started having suggestions for instructions. From 1955 onwards, simple instructions for houses were found in basic sets to serve as inspiration/play starters for consumers. This mirrors the different views present in the company at the time. For example, documents reveal an internal discussion in 1960 where the company’s management have different views on how much “help” consumers should receive when building with LEGO® bricks. Should you only provide inspirational material and let children’s imagination do the rest or do you “educate” children with instructions and thus building techniques in the hope that by doing so you instill confidence in children to investigate the endless building possibilities of the LEGO system later in their play journey. The material available in the early 1960s suggests a compromise and the above-mentioned observation hints at a similar situation in the mid-1950s.

Building instructions for suggestions for houses you could build with various basic sets such as set no. 700/1, 700/2 etc.

More elaborate instructions

From the introduction of the LEGO® brick, we know today, in 1958 and the much-improved stability that came with the ingenious interlocking principle, LEGO sets slowly became bigger and more detailed and this demanded a change in building instructions in the early 1960s. From then the instructions slowly started to contain more building steps than earlier, and the building experience was improved by consistently adding color to the instructions. However, the instructions were still very simplified compared to the ones we have today. The instructions would normally have two sides with one showing steps to build the model depicted on the front of the box and the other side would contain images of alternate builds. Going back to the beforementioned internal discussions it seems we are still looking at the art of compromise.

Building instruction from 1964, set no. 323, showing instructions on one side and alternate builds on the other

Although the material is scarce on the subject, the change in building instructions indicate approximately when the LEGO Group started to team up with external companies to help us draw the instructions.
We know for a fact that from 1967 and until 2003 the main supplier of drawing building steps for the LEGO Group was a company called Palle Munch, Grafisk tegnestue & Reklamebureau based in the Danish town Kolding. However, according to the owner Palle Munch, some instructions were made by another company in Aarhus, Denmark.

Creating Building Instructions

Speaking of drawing building instructions, let’s look at some of the many steps it took to create a building instruction back in the day. Making building instructions was a slow and tedious process. After the designers finished designing and building the model it would be split down into the various building steps – for many years the building steps were decided by the designers themselves. Every building step would be built and put next to each other on a table for review and approval. After being approved pictures would be taken of all the steps, one by one. Each model showing one building step was meticulously placed exactly on the same spot as the previous one and then the next step would follow. Eventually you would be able to match the pictures over each other to form a section by section building instruction. The photos were sent to external partners, like Palle Munch, Grafisk tegnestue & Reklamebureau, who then drew the building steps by hand. The drawings were made in a larger scale (each knob had a diameter of 7,5 mm) to make the detailing easier. Afterwards the drawings of the building steps were scaled down and sent to another company for the finishing touch - coloring. Palle Munch also remembers the physical building steps being shipped to him in boxes, sometimes taking up a lot of room on the company’s premises. This would happen later when Palle and his employees started using other technologies to draw the building steps…

A big change

In the early 1980s, big changes were happening in the world of LEGO® building instructions. In 1983, the LEGO group sets up a specialized building instruction team for the first time who take over creating the building steps from the designers. A few years later a switch is made from hand drawn building steps to doing it in a computer-based tool instead. Palle Munch, the owner of Palle Munch, Grafisk tegnestue & Reklamebureau finds a 3D drawing tool called ‘Monster’ which originally is used to draw stage settings for Danish television. In May 1984, Palle Munch contacted the company who originally created Monster and asked them to help create a new tool suitable for drawing building instructions for LEGO sets. The project started in the fall of 1984 and the intention was to use Monster as the basis to create the new drawing tool. Quickly the company behind the original tool realized that the task of making a tool for drawing building steps required a quite substantial rebuild of Monster and it took more than a year and a half to create the new tool. The tool, eventually called ‘Panter’, was named after Palle Munch, and the name stands for “PAlles Nye TEgneRedskab” which translates to “Palle’s new drawing tool”.

building instruction from 1988

Set no. 6675 from 1988 is an example of a building instruction created with Panter

Panter was used for creating LEGO building instructions for the first time in 1986 and remained in use for the next 17 years. Although Palle Munch and his team drew the various building steps with Panter and later Panter 2, an updated tool that now included colour, it was the building instruction team in the LEGO Group that had the last say. When a new building instruction was being made, Palle Munch and team would send a test instruction to the LEGO Group for review. After review, the building instruction was changed according to the comments made by the building instruction team before the final instruction was created.

image of test building instruction

Example of a test instruction from 1998 made on Panter 2 with handwritten corrections from the building instruction team at the LEGO Group

New tools

In 2003, a new tool ‘3D Vision’ was introduced and replaced Panter. 3D Vision was considered a large step forward. The new tool was much more user friendly than Panter. With Panter a lot of data had to be added in the system manually for each individual LEGO® element, but in 3D Vision this information, such as, dimensions etc. was automatically generated in the system. This made the new tool much more time efficient. In an article in an internal employee magazine in 2003, concerning the introduction of 3D Vision, it was mentioned that the new tool created a building instruction for a new LEGO Technic set in 3 days, and an employee was quoted for saying that with Panter it would have taken 3 weeks. Also, in 2003, 36 years of collaboration with Palle Munch, Grafisk tegnestue & Reklamebureau ended as the LEGO Group wanted to bring the whole process of making building instructions in house.

image from building instruction from 2005

Page from a building instruction made with 3D Vision. Set no. 7239, from 2005

Approximately two years after the rollout of 3D Vision a new tool was introduced. The development of Easy Builder Tool (EBT) started in 2004 and in 2005 it was used to create the first building instructions. Contrary to 3D Vision, EBT was an internally developed tool. The tool was a plugin for an already existing externally developed 3D platform. Compared to 3D Vision the new tool came with more elaborate features but it was also known as a more complex tool to master.

page of building instruction from 2006

Building instruction from 2006 created with Easy Builder Tool

Expansion

In recent years the building instruction team has grown a lot due to, for example, a growing product portfolio. Starting with 2-3 people in 1983, the building instruction team now consists of more than 100 employees across various teams and functions. They use several tools to create the fantastic building instructions you find in LEGO® sets today. One of the main tools being LEGO Digital Designer (LDD) Pro. The first instructions made with LDD Pro go back to 2018 and from 2022 all LEGO building instructions have been made exclusively with the tool. How are current building instructions made you ask? Well… that is a business secret!

Which is which?

Throughout this article, examples have been shown of building instructions made with the different tools we have had over the years. If you are struggling to see a difference in the different instructions from different time periods you are not alone. The “cartoonish” look of the instructions is something, with a few exceptions, we have always aimed for. The simple reason being that it works, and you can easily distinguish various colors and shades from each other. A LEGO® building instruction is not about portraying the model as lifelike as possible, it is about creating the best possible building experience.

LEGO® Builder

Since the 1950s LEGO® building instructions have been a paper-based friend in need for consumers wanting help to tackle the vast possibilities of the LEGO system in Play. Today, building instructions are more than ‘just’ paper instructions. They can also be experienced through the LEGO Builder app giving consumers, no matter their experience level, an easy and intuitive building experience. In the app you will find instructions in both 2D and 3D. The latter allows you to zoom and rotate to view your build from all sides. One of the most intriguing features is unlocked when you press the ‘build together’ button on select sets in the app. This allows consumers to build a LEGO set as a team by delegating each builder a building task to complete. There is a place for everyone, no matter what skill level you have, and the feature is a fantastic tool for family quality time or teambuilding.

Relentless pursuit

LEGO® building instructions have come a long way from the simple instructions in 1955 to LEGO Builder, but to this day one thing has never changed… The relentless pursuit from dedicated employees towards worldclass intuitive building instructions aimed at creating a solid foundation for LEGO builders to further explore the LEGO system in Play.

Or, how to lose money with friends.

When working on my latest book, The Secret Life of Circuits, I wanted to keep the artwork real. My beef with the diagrams in popular electronics textbooks and online tutorials is that most of them are fake. At best, they’re retraced from ancient texts; at worst, they’re sketched from memory and can be charitably described as “inspired by true events”:

An assortment of V-I plots for diodes, collected on the internet.

The Secret Life of Circuits contains about 290 original illustrations and does its best to avoid such shenanigans. I painstakingly gathered real data for everything from quartz crystal frequency response, to battery discharge curves, to signal reflections in a 100 ft run of coax cable strewn around the workshop, to the behavior of vacuum tubes.

A snippet from the sample chapter, available here.

Most of it was straightforward to capture, but I can’t say the same about the parametric plots that show the relation between voltage and current in semiconductor devices. In some portions of the curve, the currents are too miniscule to record with the most common graphing instrument, the oscilloscope. In other portions, the current suddenly skyrockets — and before you know it, the device lets out the magic smoke. Even in the in-between region, there’s no respite: the characteristics of semiconductor junctions change with temperature, and that includes self-heating due to currents as low as 1 mA. Do nothing and watch a point on the oscilloscope screen drift away.

To tackle this problem, I ditched the oscilloscope in favor of a benchtop multimeter (DMM) and pulsed power from a lab supply. The perk of the multimeter is that it can easily measure down to microamps and microvolts; the perk of pulsed power is that heating-indued drift can be kept in check.

Oh — I would also submerge the device under test in non-conductive liquid for cooling purposes. Mineral oil is a sensible choice, but many other options should do:

A close-up of the final setup.

Although I prepared some diagrams by manually writing down currents and voltages, this is obviously tedious and error-prone, so it’s better if one or more of the instruments can be interfaced to a computer. Many benchtop instruments support a simple, text-based protocol called Standard Commands for Programmable Instruments (SCPI). Depending on the age of your gear, the interface may be available over RS-232, via a USB Type B (printer-style) port on the rear, or via Ethernet — in which case, you simply establish a TCP connection to port 5025.

The SCPI protocol uses commands and queries. An example of a query is *IDN? followed by a newline (\n); sending this string causes the device to respond with a line of text describing its make, model, and other identifying information. Another possible query is MEAS:VOLT?, which might return the current voltage reading. In contrast to queries, commands do not return any text; an example may be SOUR:VOLT 1.2 to set the voltage to 1.2 V, or OUTP 1 to turn on output channel 1.

Alas, although I had an SCPI-capable multimeter, my benchtop power supply was more basic and offered no remote control; without it, the process was still half-manual. Fed up, I eventually purchased a source measure unit (SMU) — essentially a combination power supply and a multimeter with a very fast response time. Brand new SMUs are obscenely expensive, but there are virtually no second-hand buyers for them, so it’s easy to find excellent deals on eBay if you haggle a bit. I scored an unmolested Rohde & Schwarz NGU401 unit for a laughably tiny fraction of its astronomical MSRP ($9,000).

This particular SMU can be used by repeatedly setting the output voltage and then querying the DMM for the current on-screen reading, but the reading is updated only at a frequency of about 3 Hz. A better option is to use the device’s data streaming mode; in the Rohde & Schwarz parlance, this is known as FastLog. The API allows sampling rates of 100 to 500k per second (!) and sends voltage-current pairs as binary 4-byte floats.

Of course, as can be expected of a niche feature on a niche device, nothing actually works as documented. The most grievous problem is that the returned binary data is corrupted if you try to use the serial-over-USB interface; after a day of chasing ghosts, I was finally able to get it to work over Ethernet.

My C implementation for capturing the V-I curve of a forward-biased diode can be found here. It uses FastLog at 10 ksps; for currents below 0.3 mA or so, it leaves the supply voltage on and averages 2,500 data points to obtain a noise-free microamp-range reading. For higher currents, it cycles the power on for 5 ms, and averages the best 20 samples from the FastLog buffer.

The following plot shows the actual, positive-side V-I curve for a popular, small 1N4148 diode with a continuous current rating of 300 mA:

Forward bias of 1N4148.

Unedited measurement data can be found here. I was able to effortlessly cover the range from few microamps to nearly 2 A; it’s actually possible to go to 4 A, but it adds no interesting detail to the plot.

Note that although the relation between the applied voltage and current in a diode is often described as exponential, this is true only for modest currents. In the log-current plot on the right, we see that the property no longer holds in the vicinity of 10 mA; the curve diverges from the dashed line that represents an idealized model fitted to the initial, truly exponential slope. That’s because of resistive effects in the semiconductor substrate — and it’s one of many reasons why it pays to have real plots.

Diodes eventually begin to conduct when reverse-biased too, but in the case of 1N4148, the threshold is about -145 V, so it’s hard to capture all of the component’s dynamics on a single well-proportioned plot. We can do it more easily for Zener diodes. For example, the following was captured for 1N4731, a low-voltage Zener rated for 4.3 V at 58 mA:

Real-world behavior of the 1N4731 diode.

In these Zener diodes, the reverse breakdown curve is not as steep as the response in forward bias; if you want to use the component to produce a specific reference voltage, you need to keep the current in the right ballpark too.

The same toolkit also works for transistors. For example, here’s my plot of the admitted current in relation to the drain-source voltage for a small MOSFET, BS170:

VDS-ID curves for BS170.

The plot shows that the transistor is more or less a constant-current device in the bulk of its usual operating range; the current limit is dialed in by the gate-source voltage (VGS) and changes less than 10% for VDS between 1 and 10 V.

We can also show what happens on the tail end of that curve. The spec for the transistor gives its breakdown voltage as 60 V; in textbooks, this is usually shown as a sharp transition to vertical. For example, variants of the following diagram have made it into countless online articles and scientific papers:

Yet, the reality is more nuanced:

BS170 near the breakdown region.

In a nutshell, you get a relatively sharp and spec-compliant breakdown only at very low gate voltages; in fact, the behavior is diode-like for VGS = 0 V (not shown above). But if you’re supplying a more practically useful VGS, the build-up to the danger zone is more gradual and you’ll be in trouble well ahead of 60 V.

As a side note, that last plot required a bit of ingenuity: my source measure unit has a limit of 20 V. To gain extra range, I added a traditional, floating power supply in series with the SMU and then stitched the captures for several voltage spans. This solved one problem but created another: even with the SMU idling, there would be substantial drain-source voltage applied to the device under test, and for some values of VGS, it could be enough to heat up or even destroy the transistor.

To address the issue, I moved from a fixed VGS signal to 5 millisecond pulses delivered by a signal generator at a low duty cycle. I also modified the data logging code to sample the current continuously over the period of about 2.5 seconds, average the best results, and then move to the next voltage set point. Source code for this variant can be found here.

I’m Making Strandfall, a Solarpunk Orienteering Larp

In the twenty years I’ve been making games, I keep returning to the idea of blending the digital and physical worlds through ARGs like Perplex City and location-based games like Zombies, Run! It’s as if the act of mixing worlds enchants them both. That impulse is probably why I recently became fascinated by Nordic Larp (live action role playing), the closest thing we have to a fully embodied, truly participatory avant-garde art form today.

So for anyone who knows me, it’s probably no surprise that my next game, Strandfall, combines all those notes. Strandfall is a highly physical outdoor larp that I’m co-creating with Alex Macmillan as part of our new collective, Experimental Social Scene, supported by Immersive Arts funding.

This September, 30 players will embark on a desperate expedition in a real park in Edinburgh to uncover the nature of mysterious storms that are ravaging the world. Over the course of three hours, they’ll use our custom solarpunk-style “spatial computers” to forecast and investigate the storms, track down missing scientists, connect a long-distance radio network, and make fateful decisions that will change them as individuals and a community.

Our spatial computer, the McNair-Feldman Device (MFD)

As Alex notes, many larps involve science-fictional or fantastical gadgets. Usually, participants rely on the power of imagination and role play to collectively perform their functions. In Strandfall, we’re building our “McNair-Feldman Devices” (named after its fictional inventors) for real. They contain a low-power, long-range radio for mesh networking beyond cellular and wifi service, a GPS radio, accelerometer and compass, a small ePaper display, all housed in a custom 3D-printed enclosure designed to be mounted on a standard camera tripod.

This doesn’t make Strandfall “better” than larps with non-functional devices like the sci-fi blockbuster Eclipse, but it does allow us to introduce new kinds of systems and gameplay into the experience that would be much harder if done manually.

An explorer sets up a laser. Photo by Chiara Cappiello.

Players might deploy MFDs across the park to create a network, use them to forecast the invisible storms, relay that information back to players at the base, and then track and even “storm chase” them while in scanning mode. Other players might use MFDs like surveyors, pinpointing the effects of past experiments in the park or discovering the boundaries of a mysterious Stalker-like exclusion zone.

Wouldn’t it be easier to use cheap smartphones instead of going to the trouble of designing entirely new hardware? That depends. Putting aside their hardware limitations (lack of long-range radios, displays that suffer in direct sunlight, etc.), the problem with smartphones is that people inevitably expect to interact with them like smartphones, which is to say, instantly and effortlessly. If we gave players smartphones, they would expect to be able to use Google Maps to navigate and instant messaging to communicate, rather than dealing with the orienteering-esque challenges of paper maps and walkie-talkies. Even with those functions disabled, we’d have to deal with potential confusion and disappointment.

Smartphones are anti-enchantment devices. All too often during interactive theatre and ARGs, I see participants fixated on their glowing screens, to the wider experience’s detriment. Smartphones, as traditionally used, have no place in an immersive experience that seeks to bring participants together and get them to talk and argue and deliberate with one another. Instead, we’ve designed our devices to appear closer to scientific instruments, with a custom user interface to match.

User interface concept art

Some MFD tasks will be fast, but many will take longer to complete and require intense co-ordination. Sometimes players will need to hurry up and run, and sometimes they’ll have nothing to do but think and talk. We’ve developed a whole backstory to the world, a lot of which will only be exposed in fragments and between different players.

Our players remaining at the base will be working with maps and receiving information via thermal printers. It’s not that we’re completely ruling out traditional screens and computers, but rather that we’ll only use them where they cohere with the overall atmosphere and intention of the experience. It’s low-tech, not no-tech.

Mockup storm warning

We want Strandfall to be a highly physical experience that taps into the pleasure and exhaustion of movement, but we’re also mindful about accessibility. Ideally, every player will feel they have something vital and unique to contribute, not just the most athletic.

We also want Strandfall to incorporate role play. Just because everyone is part of the same expedition doesn’t mean they don’t want different things, or go about things in their own way. Hopefully we can give players the “alibi” to try out roles different from their normal selves, more courageous or argumentative or deferential. Since Alex and I haven’t designed larps before, we’ve brought on board veteran Nordic larp and RPG designer Juhana Pettersson as a consultant.

Wireframe design

While Strandfall is debuting in Edinburgh, it’s a site-responsive experience, not site-specific. It would be fairly straightforward to adapt it to other outdoor spaces and increase its duration and player count. Even though we don’t intend for Strandfall to be played by millions of people – its custom hardware and unique demands prevent that, plus we have more than enough of those games already – we have plenty of ideas of how to add depth and complexity to make it into a highly repeatable and extensible experience.

Before any of that, we have to pull off our first three-hour run in September. It’ll be free to participate, and you can find out more details and follow along on our website – we already have posts up about our influences like Death Stranding and PUBG, the technology and capabilities of our MFDs, and what I learned from this year’s Nordic Larp conference.

Today, we are excited to share an update on our progress towards a new frontier of drug design. We have unlocked a new paradigm of predictive accuracy in understanding our biomolecular world, allowing us to rationally design new medicines on a computer with unprecedented understanding and precision.

We are giving a glimpse at a subset of the powerful and expansive capabilities of the Isomorphic Labs Drug Design Engine (IsoDDE), a unified computational drug-design system, progressing beyond AlphaFold 3 (AF3) in its predictive accuracy and introducing new capabilities which bridge the gap between structure prediction and real-world drug discovery. 

We demonstrate that our IsoDDE more than doubles the accuracy of AlphaFold 3 on a challenging protein-ligand structure prediction generalisation benchmark, predicts small molecule binding-affinities with accuracies that exceed gold-standard physics-based methods at a fraction of the time and cost, and is able to accurately identify novel binding pockets on target proteins using only the amino acid sequence as input. 

IsoDDE offers a scalable foundation for AI drug design, providing the predictive fidelity required to navigate novel biological systems with unprecedented accuracy.

Since our release of AlphaFold 3 in 2024 together with Google DeepMind, the field of AI drug discovery has moved at an extraordinary pace. Whilst AlphaFold 3 delivered a dramatic leap in performance from previous generations of structure prediction models, a key challenge remained: understanding biomolecular structures alone was not sufficient for unlocking real-world drug discovery programs in silico (on a computer). 

Progress in rational drug design - vital for solving human disease - requires highly accurate predictive models, across an expansive range of biochemical properties and interactions, that are able to work in concert with one another. Crucially, with so much of biological and chemical space still unexplored, these models need the ability to generalise their predictive power beyond their training sets to novel, unseen systems.  

As we continue to address these challenges, we are excited to introduce the Isomorphic Labs Drug Design Engine (IsoDDE), and to preview a subset of IsoDDE's capabilities below and in our technical report.

Read Our Technical Report

Structure Prediction of Truly Novel Systems

Accurately predicting the structure of biomolecules and how they interact remains a crucial capability for rational drug design. Many critical downstream tasks are unlocked by being able to accurately model the small nuances in a protein’s geometry - whether understanding the impact of disease-causing mutations, or predicting which molecules will bind to a target protein. 

AlphaFold 3 transformed protein-ligand structure prediction at the time of its release and the freely available AlphaFold Protein Database accelerated science on a scale that was previously unimaginable. To date, it has been used by over 3 million researchers in more than 190 countries. 

Benchmarks have subsequently revealed that there remained a gap in accuracy for structures that were dissimilar to the examples AlphaFold 3 had been trained on. In other words, that it can struggle to generalise to unexplored regions of biomolecular space where some of the biggest challenges and opportunities in drug discovery lie.

IsoDDE demonstrates a step change in the ability to generalise to protein-ligand structures that are highly dissimilar to those in its training set. 

On the 'Runs N' Poses' benchmark (Škrinjar et al. 2025) - designed specifically to test generalisation to novel pockets and ligands - IsoDDE more than doubles the accuracy of AlphaFold 3 on the most difficult systems.

Protein-ligand structure prediction accuracy on hardest generalisation category ((0-20])- most dissimilar to the training set - from the 'Runs N’ Poses' benchmark

In the report, we demonstrate through several examples that we can successfully model complex, out-of-distribution events such as induced fits (where a protein adapts its shape to accommodate a bound ligand) and the opening of cryptic pockets (those hidden in the absence of a bound ligand) - critical biological mechanisms - even when these systems are distant from the training sets of such models.

IsoDDE is able to successfully predict the structure of a protein-protein interaction inhibitor bound to a cryptic pocket on the NKG2D homo-dimer interface (8EA6) from the lowest 0-20 similarity bin of the Runs’n’Poses test set (AlphaFold 3 fails on this example)

Opening a New Window for Complex Biologics

But small molecules (like aspirin) are only one piece of the puzzle. As therapeutic modalities expand toward complex biologics (like insulin), the ability to accurately model antibody-antigen interfaces is paramount. 

IsoDDE provides a step change in accuracy for this domain. It outperforms AlphaFold 3 by 2.3x and Boltz-2 by 19.8x in the high-fidelity regime (DockQ > 0.8) on a challenging, novel antibody-antigen test set. 

Crucially, IsoDDE shows remarkable performance on the CDR-H3 loop - the most variable and difficult part of an antibody to predict - effectively unlocking new possibilities for de novo antibody design.

Antibody-antigen structure prediction accuracy for a challenging, low-homology test set (𝑛=334), showing the fraction of high-quality predictions at the protein interface (DockQ >0.8) as inference-time compute is increased. IsoDDE outperforms AlphaFold 3 by 2.3x and Boltz-2 by 19.8x

A New Gold-Standard for Binding Affinity Prediction

Knowing the 3D structure of a biochemical system is only the first step; effective drug optimisation requires knowing how strongly a molecule will bind to its target. 

Traditional approaches are either limited to chemical space similar to the training data or by their high computational cost and difficulty of execution (e.g., physics-based approaches). Deep-learning based methods have more recently emerged that bring new speed to this task, but still lag behind physics-based approaches for accuracy.  

IsoDDE surpasses all deep-learning methods by a considerable margin on three public benchmarks - FEP+ 4, OpenFE, and the recent CASP16 blind binding affinity prediction task.

In fact, remarkably, IsoDDE can surpass the performance of physics-based methods such as FEP, despite the fact that these require grounding in experimental crystal structures and IsoDDE does not.

By delivering highly accurate binding affinity predictions at speed, IsoDDE allows researchers to rapidly rank and optimise potential molecules across diverse chemical series during drug design programs.

Binding affinity prediction performance across a range of public benchmarks

Expanding the Ligandable Proteome

The ability to identify all of the potential pockets on a protein, in the absence of a known ligand, unlocks a number of unique opportunities. Whether dealing with a first-in-class drug discovery target lacking structural annotation or pursuing a novel way to modulate a well-studied protein, a general pocket identification capability can be used to reveal the full set of possible mechanisms of action to pursue for molecular design.

IsoDDE exhibits the capability to identify novel, ligandable pockets even in the absence of a known ligand and far from the model’s training set. This capacity for ‘blind’ pocket identification demonstrates performance levels approaching experimental techniques like fragment-soaking which require large investments in time, significant cost and real-world experimental work. In comparison, IsoDDE runs on a computer in a matter of seconds. 

We can see the power of this capability in the example of cereblon - a substrate receptor for the CRL4 E3 ligase complex - which plays a key role in tagging damaged or misfolded proteins for proteasomal degradation. For the last 15 years, it was believed that there was one principal way to drug cereblon: through the classic thalidomide-binding pocket. However, a recent study (Dippon et al. 2026) experimentally discovered a novel binding pocket that was both allosteric (away from the traditional binding site) and cryptic (hidden in the absence of a binding ligand). 

IsoDDE was able to recapitulate the discovery of this pocket, predicting the location of both the known and the novel cryptic sites using only the sequence of cereblon as input, without specifying the identity of the ligands. Further, once the ligands were specified, IsoDDE was able to correctly fold them into their respective pockets in the correct orientation.

IsoDDE was able to recapitulate the recent discovery of a novel cryptic site on cereblon (Dippon et al., 2026) predicting the location of both the known and the novel cryptic sites using just the sequence of cereblon as input, without specifying the identity of the ligands.

Advancing Drug Discovery

IsoDDE represents a leap forward in accuracy and capability, bringing deeper understanding to the molecular machines that make up the human body, and advancing the process of designing drugs to modulate them. 

Our dedicated drug design teams at Isomorphic Labs are using these capabilities every day across our programs – to understand unseen structures, identify uncharacterised pockets, and create novel chemical matter in the pursuit of new medicines for patients.

We look forward to continuing to push the frontiers of in silico drug design and bringing our new, more powerful capabilities to bear on historically challenging drug targets.

We thank our friends at Google DeepMind for productive discussions and collaboration.

Please use the following citation if you reference this work:

@manual{isodde2026,
  title = {Accurate Predictions of Novel Biomolecular Interactions with IsoDDE},
  author = {Isomorphic Labs Team},
  month = feb,
  year = 2026,
  doi = {10.5281/zenodo.19699685},
  url = {https://zenodo.org/records/19699685},
}