Vanillin Studio

Explore systems from the inside.

Programs, data and execution are often treated as separate things. In reality, they continuously shape one another. A program transforms data, data influences what the program does next, and execution is where the two become something real.

Tools are good at looking at individual parts of this picture. Debuggers let you inspect execution, editors show programs, databases let you explore data, and visualizations reveal particular relationships. Each gives a useful window into a complex system.

Vanillin Studio explores what happens when these things are treated as parts of the same structure. Instead of reducing a system to a collection of separate views, it gives you a place to explore its structure directly - from the whole down to the smallest detail.

Execution already has representations. This is a different one.

Debuggers, profilers, flame graphs, traces and timelines are excellent tools. They give accurate, detailed views of what happened. That is not the question here.

The question is what happens when the execution itself - not a view of it - becomes something you can explore spatially, navigate and return to, rather than reconstruct from a collection of separate windows.

Source code, documents and database records can all be stored and revisited. Execution is still usually treated as temporary: a process runs, produces logs, someone investigates them, and eventually the execution disappears.

It can be a first-class artifact instead - something with a structure that can be stored, revisited, compared and explored long after the process has finished.

Text is an excellent medium, but not always the right one

Most existing tools describe execution through logs, events, timelines and stack traces. This works well for many tasks, especially when the process is small.

As processes become larger, relationships become difficult to see, context is constantly lost and understanding depends more on the ability to mentally reconstruct the process than on the information itself. The standard answer is to aggregate and filter - which is useful, but destroys the data it summarises.

A system can be explored

Vanillin Studio represents complex systems as interactive spaces instead of sequences of text. It is built on multiple technologies¹ that keep the rendering layer deliberately close to the structures it visualizes.

The entire structure remains available at all times. Instead of jumping between isolated windows or scrolling through endless logs, you navigate by zooming and panning. A filtered or aggregated view stays connected to the structure it came from - you can move from a summary back to the exact events that produced it without losing your place in the whole.

The experience is closer to exploring a map than searching through a document.

Different questions require different perspectives

There is no single perfect representation of a complex system.

Sometimes every event needs to be inspected. Sometimes only failures, retries or interactions between specific components matter. Sometimes the overall structure is what counts, without getting distracted by individual details.

Vanillin Studio approaches this by creating different perspectives on the same underlying structure. Colors, highlighting, grouping and aggregation are simply different ways of looking at it - they do not replace the original information.

The original structure remains the source of truth.

A real example: an investigation in progress

Vanillin Studio was originally built to understand the execution of its own development process.

The problem: running metaES inside metaES - a meta-circular execution where the interpreter evaluates itself. When function declarations are hoisted, a condition in the evaluator silently returns falsy, so functions are never registered in the environment. The program proceeds without error, calling functions that were never there.

The misleading part is that nothing obviously fails. Execution continues, produces results, and only in specific conditions does the behaviour diverge from what is expected. The relevant state changes are spread across dozens of small steps inside the meta-level evaluator.

Reading logs shows individual events, but not the relationship between them. Visualizing the execution makes it possible to follow the path through the meta-level evaluation and see where the hoisting step produces nothing - but the investigation is not finished. The structure is visible. The root cause is still being traced.

Execution should have memory

Vanillin Studio records execution continuously while it is happening². Instead of treating execution as temporary output, it preserves the process as structured data that can be revisited at any time. Yesterday's execution should be just as accessible as yesterday's source code.

Once recorded, an execution can be replayed, compared with another execution, shared or explored from entirely different perspectives without losing the original information.

AI is one obvious case

An agent can run for an hour, make hundreds of decisions and change state along the way. The final answer tells very little about that journey. Vanillin Studio makes the underlying execution available for exploration - whether the process was driven by a person, a program, an agent or something else.

Complexity should not mean hiding information

As systems grow, the temptation is to summarize and reduce. Sometimes that is useful. Sometimes it hides exactly the part that mattered. The aim is not to reduce complexity but to make it navigable - preserving the complete structure while still making it understandable through better perspectives and representations.

Looking forward

One direction being explored is representing large structures through fractal geometry. Execution trees are recursively self-similar: a call contains calls, each with their own state changes, each potentially as deep as the one above. Conventional trees run out of screen. A fractal coordinate space does not.

Why the name Vanillin?

Vanilla is a complex natural system made from many interacting components. Vanillin is one well-defined component within that complexity - isolated, legible, useful on its own.

The name reflects the approach: when something becomes complicated, look for the simpler structures underneath it and make those visible. There is also a quiet nod to software culture, where vanilla means working with something in its fundamental form, without unnecessary layers built on top.

Start exploring your systems

A small group of teams working with complex systems is being selected to try Vanillin Studio on real problems and help shape where it goes.

Good fit: software, AI agents, automation, simulations, long-running workflows - anything where the final result does not tell the whole story. Also interesting: complex or hierarchical data that needs to be explored rather than simply inspected.

Get in touch to see a demo or discuss a use case: contact@metaes.io