Building a map for the thing we keep losing — and why

We have never been able to make things this quickly. Idea to sketch, sketch to prototype, prototype to something a stakeholder can click — the distance has collapsed. Generative tools now sit inside the design-to-code pipeline, and a rough concept can become a reactable artefact in an afternoon.

What we lose at that speed is quieter, and harder to notice until it's gone: the thread. The why behind what we shipped. Somewhere between the client need that started everything and the feature that finally lands, the chain of reasoning frays — an insight becomes a hypothesis becomes a story becomes code becomes an outcome, and by the time you're staring at the outcome, nobody can walk it back to the need that justified it. We’ve built with AI without documenting why.

“Provenance Atlas” is my attempt to make that thread visible, and to work out where AI can help hold it together rather than snap it faster.

The Atlas is a live, interactive map of every artefact a cross-functional product team produces on its way from discovery to release — the research notes, the insight statements, the hypotheses, the stories, the prototypes, the merge requests, the outcome signals. Around a hundred and seventy of them sourced from end-to-end mapping exercises and workshops, across Design, Product, Research, Content, Engineering, Solutions Architecture and design system teams.

It’s best to follow the built in guide that shows that each dot on the map is an artefact. Each line is a hand-off. And the map can be recoloured through different lenses to answer different questions: who owns each piece of work, when in the lifecycle it happens, where the chain of evidence survives or breaks, and where AI could realistically carry, reconstruct or verify the provenance between one artefact and the next.

The centre of gravity is a single measure I've come to think of as the evidence gap — how many manual hops it takes to get from a shipped output back to the insight that justified building it. Zero or one is the goal. Today, honestly, it's often unbounded. You can find the feature. You cannot always find the reason.

The Atlas doesn't just diagnose this. It lets you configure a specific workstream, surfaces the few load-bearing "anchor" artefacts that must carry proof for the chain to hold, and proposes small, testable AI experiments against the exact points where the thread currently leaks — each one a fill-in-the-blank hypothesis with a measurable before-and-after.

Design and Strategy

We're trained, as designers, to care about two things above all: the artefact (the work-work, an empathy map, a user flow…) and the user. We obsess over the ‘rooms’. We rarely design the ‘corridors’ — the connective tissue between artefacts, the hand-offs where meaning is quietly dropped or reworded or lost. That in-between space isn't anyone's deliverable, so it becomes nobody's craft.

Building the Atlas forced me to treat provenance itself as a design material — something with states, edges, failure modes and affordances, something you can shape rather than merely lament. Once you look at the process that way, the map almost draws itself. You start seeing that the problem isn't a bad artefact; it's a good artefact that arrived with its lineage stripped off.

There's a second, more personal reason. We often work from second-hand debriefs and dummy datasets, and the outcome signal — did the thing actually work? — comes back to us indirectly, if at all. In the Atlas I call this the severed loop: the red, dashed line where evidence of impact can't flow back to the origin. Mapping it didn't fix it. But naming it, and showing exactly where it breaks, turned a low-grade professional ache into something addressable.

AI has made the making almost free* and the tracing more fragile than ever.

*credits are expensive.

If you're going to invest in AI across a design-to-delivery workflow, you need two things a lot of teams skip. First, a shared, legible picture of the workflow you're actually optimising — not a tidy diagram of how it's supposed to work, but the real thing, with all its informal artefacts and lossy hand-offs. Second, a way to make every AI bet earn its place: a hypothesis, a target, and a logged result you can point to later. The Atlas is built so that both live in the same place, and so that a shipped feature can, in principle, always be traced back to a real, proven need.

How it's made (because I couldn't resist)

There's a pleasing reflexivity to the build. The Atlas is a working force-directed map that makes live model calls to sharpen its own experiment suggestions, scout current tooling, and score the write-ups people log against it. In other words: I used AI to build a tool about keeping AI honest. The map, the lenses and the metrics all work without a connection; the intelligence layers on top. That felt like the right ethic for the subject — the structure should stand on its own, and the AI should be legible, optional, and accountable rather than load-bearing and mysterious.

What I'm taking from it

The Atlas started as a mapping exercise and turned into a small manifesto. Speed is not the scarce resource any more. Provenance is. The teams that will get the most from AI aren't the ones who generate the most artefacts — they're the ones who can still explain, months later, why each one exists.

That, it turns out, is a design problem.