Atomic Content

Building for humans, machines, and everything in between

22 December 2025Series: Content for Humans and Machines

Key observations

Content needs to be designed for machine consumption, not just human readability.
An "atomic content" hierarchy (atoms, molecules, organisms) derived from Atomic Design principles can provide the necessary structure.
Rich, structured metadata (like JSON-LD or front matter) is crucial for explicit meaning and context.
The decomposition of content carries risks such as context collapse, hallucinated joins, and provenance decay, which require deliberate mitigation.
Adopting a content pattern library helps teams refine knowledge, improve editorial awareness, and ensure consistent messaging.

A couple of years ago I published an article about composable content.

The twist - which I tucked neatly into a note at the end - is that I didn’t actually write it.

I asked an AI to “Write an essay on composable content”, and pasted the results into Medium. The images were generated by another AI. Even the alt text came from a third one. I was basically the conductor for a small robot content agency.

This was my Medium debut, and I didn’t post again for a looong time.

At the time, this felt like a novelty. A toy. A slightly guilty experiment in what if I let the machine do the homework and would people recognise it had.

Reading it back now, it feels like something else.

It reads like documentation for the future the AIs were quietly building - a future where content is broken into atomic pieces, remixed across channels, and increasingly consumed by machines before it ever reaches a human.

So this is a sequel.

Not to re-explain composable content, but to ask a more awkward question:

What happens when the main audience for your nicely structured, reusable content isn’t just people any more - it’s the models?

The prequel: Composable content (2022 edition)

That original article described how we could build modular content blocks that could be “reassembled for different contexts and platforms.”

At the time, “different contexts” meant web, social, email, mobile, print.

Now it also means AI.

Back then, I was thinking about human authors and editors- people in CMS interfaces, repurposing content like Lego bricks.

It’s funny how so many of my analogies seem to come back to Lego…

Now, content is being repurposed by models. Indexed, embedded, summarised, hallucinated, repackaged and served back to us through chatbots, voice assistants, and search summaries that don’t even link to the source.

The idea of composable content has never been more relevant - or more ironic.

Because it turns out I wasn’t just building for multi-channel consumption.

I was pre-training a machine.

Atomic design - the missing bridge

Let’s steal a concept from the world of interface design.

Brad Frost’s Atomic Design describes a way of building UI systems out of tiny, reusable parts:

Atoms - the smallest units, like buttons or labels
Molecules - small groups that do one thing, like a search box
Organisms - larger structures that combine molecules, like a header
Templates and pages - the assembled results users actually see

It’s a beautiful model because it scales: change a button, and every instance updates.

But it also scales conceptually - it gives language to the invisible structure behind the UI.

We need the same thing for content.

If design systems gave us atomic UI components, content systems need atomic meaning components.

Translating the hierarchy

Imagine translating Frost’s hierarchy into content design terms:

The trick isn’t just to write in smaller units.

It’s to design so that meaning and context are both explicit - for humans and for machines.

Atoms: The smallest durable unit of meaning

Atoms are the raw ingredients - individual statements, definitions, or claims that stand on their own.

They’re the simplest level you can reuse without losing sense.

Example 1: UX principle (Jakob’s Law)

“Jakob’s Law says users spend most of their time on other sites, so they expect yours to work the same way.”

That’s a perfectly formed atom:

It names the concept.
It states a principle.
It’s factual and complete.
It can be reused across articles, decks, and documentation.

Example 2: Accessibility fact

“A colour contrast ratio of at least 4.5:1 is required for normal text to meet WCAG AA.”

Again, atomic. It doesn’t need supporting context to remain true.

Example 3: Design philosophy

“Simplicity isn’t the absence of complexity, it’s the management of it.”

This one’s opinionated - still atomic, but stylistically yours/mine/ours/theirs.

Atomic content should be marked up with metadata such as:

It’s not glamorous, but this metadata is what lets AI systems (and humans) treat content as structured knowledge.

A single definition atom might live in multiple places - glossary, chatbot corpus, voice assistant training, onboarding tutorial - all pointing back to the same authoritative record.

Molecules: Bundles that travel well

Molecules combine several atoms to express a coherent mini-idea.

They’re small enough to embed in tooltips or chatbot responses, but complex enough to explain something.

Example: UX principle molecule

“Jakob’s Law explains why radical redesigns often fail. Users bring expectations from other sites, so your product feels ‘broken’ when it behaves differently. Use familiar patterns first; surprise them later.”

That molecule combines:

One fact (Jakob’s Law)
One cause-effect statement (why redesigns fail)
One recommendation (use familiar patterns first)

You could reuse this in:

A design principle library
A slide in a design critique
A conversational AI response to “Why do users resist redesigns?”

Another molecule:

“A progress indicator turns waiting into reassurance. It gives feedback, sets expectations, and lowers perceived delay.”

That could appear in a pattern library, a design guideline, or an AI-generated tutorial.

For molecules, metadata gets richer. We might add:

A molecule’s value is in being context-neutral enough to stand alone, but context-aware enough to plug in meaningfully anywhere.

Organisms: Chunks that survive summarisation

Organisms are the sections that make an article feel human.

They’re made of multiple molecules that explore a single theme - a story, a critique, a walkthrough.

For example, this very section is an organism. It could stand alone as:

“Why atomic content needs voice.”

Or imagine this organism in a design system:

“Error messages are small windows into a product’s character.

A terse one signals indifference; a poetic one signals care.

In usability testing, apologetic tones reduce frustration, but over-apologising erodes trust.

Design for clarity first, empathy second, and humour last.”

That organism might contain:

Several fact atoms (testing results)
A few molecules (guidelines)
And a distinct voice (tone guidance)

It’s ideal for human readers but also machine summarisation: even compressed into two sentences, it retains truth and tone.

Organisms are where meaning, data, and voice coexist.

They’re the pieces we need AIs to preserve intact, not shred into featureless paste.

Templates and pages: Structured containers

Templates define how content atoms, molecules, and organisms assemble.

In a CMS, a template might define fields for title, excerpt, author, topic, and section order.

For AI consumption, that same template becomes a schema: it signals the semantic purpose of each block.

A page (like this article) is the final rendered assembly - a specific instance of that template.

What’s powerful about treating content atomically is that the same building blocks can be recombined into different pages without duplication.

The “Jakob’s Law” atom can appear in an onboarding guide, a podcast transcript, and a design pattern index.
If it’s updated, everything updates.
The metadata allows both CMS and AI models to understand what changed and why.

Making metadata practical

Right now, most content management systems treat metadata as decoration - titles, slugs, maybe a tag field.

To build for atomic content, we need something a little more structured. Two simple options work for most teams:

Option 1: JSON-LD or front matter

JSON-LD (JSON for Linked Data) is a standard for embedding machine-readable meaning inside web pages.

It sits invisibly in your HTML so search engines and AI crawlers can understand what your content is, not just what it says.

Front matter (Jekyll docs | Hugo docs) is a simple block of metadata that sits at the top of a content file.

It tells your publishing system things like author, topic, tone, and version before the main text even starts.

Here’s what that looks like in practice:

--- id: ux.jakobs_law.v1 type: principle topic: usability audience: general tone: neutral source: Nielsen Norman Group intent: educate revised: 2025-10-28 --- Jakob’s Law says users spend most of their time on other sites, so they expect yours to work the same way.

Or, if you prefer to expose that same information publicly for search and AI systems, you can add a JSON-LD block:

The first version (front matter) helps your content system organise things.

The second (JSON-LD) helps everyone else’s.

Together they make your atoms both human-manageable and machine-discoverable.

Presenting content for consumption

Here’s where it gets interesting.

If we want atomic content to be useful, we have to expose it in multiple formats.

For humans

Pattern libraries — Treat your writing patterns like UI components: browse by topic, type, or tone.
Style guides that link to atoms — Instead of static rules (“use plain English”), link to approved sentence-level atoms.
Inline surfacing — Imagine an internal wiki where hovering over “Jakob’s Law” reveals the canonical atom, its date, and examples.

For machines

Public API or export feed — Each atom and molecule can be made available via JSON or XML feed.
Embeddings for retrieval — Store atomic content in a vector database for your chatbot or RAG system to use directly.
Sitemaps for meaning — A sitemap of atomic IDs helps crawlers and AI agents identify canonical sources.

You could even publish a content graph view — a web of linked principles, patterns, and examples. Each node shows where it’s reused.

Think of it as an architectural diagram for knowledge.

Why bother?

Because content without structure gets flattened.

And flattened content loses intent.

In an age where generative models remix everything, structure is the only thing that protects context and credit.

Structured content makes retrieval reliable, summarisation accurate, and authorship visible.

It also lets teams see their collective knowledge: which principles repeat, which contradict, which have quietly aged out.

The reward is not just machine legibility, but editorial awareness.

When content becomes a system, you stop rewriting the same idea fifty times.

You start refining it.

The dark side of decomposition

Everything decomposes beautifully until it doesn’t.

Break content down too far, and you risk three problems.

Context collapse

A single sentence like “Remove friction wherever possible” sounds efficient until it appears on a medical consent form.

Atomic content needs guardrails: “Use only with caveat molecule safety_disclaimer.”

Hallucinated joins

LLMs will happily glue unrelated atoms together if they share vocabulary.

To prevent this, link related atoms explicitly: “must_be_used_with”, “contradicts”, “supports”.

Provenance decay

When content is endlessly remixed, authorship blurs.

Keep signatures at every level — authorship metadata, review logs, versioning.

That’s how you prove ownership when your sentence turns up in someone else’s chatbot.

A practical mini-framework: The content pattern library

Design systems have component libraries.

Content systems should have pattern libraries.

Each pattern entry documents:

Start small.

Build a pattern library of ten principles or frequently used explanations.

Tag them manually.

You’ll quickly see how it changes the way you write.

Writers stop thinking “How do I fill this page?” and start thinking “Which molecules do I already have that express this idea?”

That’s system thinking applied to storytelling.

Closing the loop

When I wrote that first piece, AI-generated content felt like a novelty act.

Now, I’m more interested in AI-ready content: information designed to stay intact, truthful, and nuanced when parsed, embedded, and reassembled by machines.

The machines will read everything we make.

The least we can do is make it legible.

But there’s a deeper layer too.

Atomic content isn’t just a technical strategy — it’s a philosophical one.

It asks: what are the smallest pieces of our work that still carry us?

Not just data, but intent.

Not just sentences, but story.

Composable content still matters.

But not because we want to publish faster.

It matters because if we don’t design our content systems deliberately, someone else’s model will cheerfully chew them up and spit out something cheaper, flatter, and wrong.

Closing Thoughts

In 2022 I used AI to generate an article about composable content.

In 2025 I’m using the same idea to design for AI.

Maybe that’s the loop — not just what we make, but how the thing we made comes back to eat it.

Acknowledgment: this article was inspired by my friend and colleague Pencho Belneyski, whose thoughtful work on AI memory palaces has deeply influenced how I think about structure, context, and the way knowledge lives inside systems.

If you enjoyed this piece

Follow me for more articles about design-driven coding, usability, and the messy, wonderful middle ground between aesthetics and logic.

Author’s note:

I am currently deeply interested in using AI to generate both visual and text-based content. I am actively collaborating with AI on multiple platforms to explore my thoughts on what creativity is and is not.

My current approach is to collaborate with AI by using the output as a foundation upon which to build and modify.