Home / Articles / Liquid content needs water: liquefy the journalist's notebook, not the finished product

Liquid content needs water: liquefy the journalist's notebook, not the finished product

By Dinis Cruz · 2026-10-07 · v0.6.97 · journalismliquid-contentstory-vaultfractal-semantic-graphsnewsroompersonalisationmicropaymentsagentsft-strategiesarticle

Abstract: FT Strategies has published a clear primer on liquid content, journalism built from datafied components that can be shaped into whatever a reader needs. I agree with most of it, and this article is about where I would push. What makes content liquid is the water inside it, and the water is the reporting: the notebook, the interviews, the documents, the hunches, kept with their sources as a graph. So the place to start is not a reinvention of newsroom norms but the opposite, putting the experienced journalist and the way they already work at the centre and giving them tools they have not had, including experts a newsroom could rarely afford. Writing stays theirs, because writing is how the story is found. Read that way, the three things the guide says liquid content is not each become part of it, personalisation becomes the meeting of the reader's graph and the story's, prioritising readers' tastes looks like the brief that produced clickbait, and the money goes beyond advertising, subscriptions and licensing to payment per use that walks back to whoever found the facts.

FT Strategies has started a series called Demystifying AI for News Publishers, and the edition on liquid content, by Sofia Giannuzzi, is one of the clearest explanations of the idea I have read. It defines liquid content as content that "primarily consists of datafied components, or 'atomic objects', including quotes, events, or dates, as opposed to information that is already synthesised into discrete products, like an article, podcast or video segment". It offers an image I like: today publishers mould content like clay into a finished product and let it dry, and liquid content keeps the clay wet, so that a reader with a fifteen-minute commute can pull up an audio briefing instead of an article.

Much of it I agree with, and it is worth saying what before saying where I would push. The guide points at data journalism as the working model the industry already has, which is right: a chart over structured data can be re-cut for every reader, and text has rarely had that. It is honest about the hard questions, how you measure a story consumed in ten formats and how you keep a human in the loop when no team could review every version. It says the structure behind the stories should hold "regardless of how the front end is configured for end users", and that structured content could be licensed to AI companies or sold through "pay-per-query systems with AI agents". Those are the right instincts.

Liquid needs water

Here is where I would push. If content is to be liquid, it needs water in it, and the water is not the format. It is the reporting: the notes in the pad, the calls, the documents, the half-recorded interviews, the hypotheses, the hunch about who to ring next, the facts with the doubts still attached. That is what has to become liquid. A finished article can be broken into atomic objects, and I will come back to why that is worth doing, but much of the richest material does not make it into the article at all.

The clay image is useful, and its limit is instructive. By the time something is clay, the ingredients are mixed in and gone. You can mould it again, but you cannot ask it where the clay came from, or which part of the shape rests on which source. What I would want is closer to a graph: claims with a confidence, evidence with its provenance, sources named or protected, people, places, events and dates, contradictions kept as edges rather than smoothed over. That is what this site calls a fractal semantic graph, and what I have called a story vault when it holds one story. Every projection of it, the article, a briefing, a chart, a translation, an answer for an agent, can still say why it is true.

The method already exists

The guide says liquid content "requires a complete reinvention of newsroom norms", and asks newsrooms "to fully embrace a user-first mentality". I want to say this carefully, because the guide is describing a real problem, but I think this is a known trap. When we do not yet know the path, the advice tends to become: change how you work, embrace the new thing, reinvent.

The more I think about this, the more I think we already have the method. It is decades, centuries really, of journalistic practice: finding the story, knowing who to call, interviewing well, reading a document for what it does not say, doubting the official version. Nothing in liquid content requires that to be reinvented. If anything, I would bring back the experienced journalists, the people who really know how to do this, and give them the tools.

Because the tools are where the inefficiency is. In many newsrooms the raw material of a story lives in a notebook, a phone and somebody's memory, with a spreadsheet if somebody made one, and once the story is published almost none of that is kept in a usable form. It works, and it is remarkable that it works, but most of the value created during the reporting is thrown away at the moment of publication. Liquefying it does not mean asking the journalist to fill in forms. It means capturing what they already produce, in the way they already produce it: a page of handwritten notes can be photographed and transcribed, a call can be recorded and linked, and the claims extracted from both can sit in a graph the journalist can see and correct.

This is also where AI changes something that is easy to miss. Building a custom interface has become cheap, which I wrote about in Custom UIs are not the exception. So every journalist can have a desk shaped to how they work: their own contact book of sources, their own view of the claims on their beat, their own way of moving from notes to draft. Not a newsroom system they have to adapt to, but tools that adapt to them, to their team and to how that team likes to work.

Writing is how the story is found

I do not think the right picture is one where AI writes everything and the journalist feeds it facts. Part of the skill of a journalist is writing the article, because writing it is how they discover the narrative. When I see a draft of something I am working on, I understand the problem better, and the draft changes what I look for next. It is a feedback loop, and the same is true of reporting: you gather evidence, you start writing, the writing shows you the hole in the story, you go back out. AI can help with parts of that, and some of it will be written by hand, which is fine; we can scan it.

So I would put it this way. The journalist and the publication decide how this information is best presented: that judgment is what a reader trusts and pays for. The article they write is one projection of the graph, and it is theirs. Other projections, a short audio version, a briefing for a reader in another role, a version in another language, can be produced from the same graph and checked against it, with the journalist deciding which of them matter enough to write or approve themselves. What the journalist discovers while writing goes back into the graph. Questions from readers come back in too, and a question the graph cannot answer is the next piece of reporting.

The experts a newsroom could rarely afford

There is a second thing the tools make possible, and I find it the most exciting. A newsroom has rarely been able to afford, for one story, a historian, a librarian, a data scientist, a financial analyst, a professor in the field, an engineer, a lawyer, somebody who has worked inside the industry being written about. With a graph that records who contributed which claim, it becomes economic to bring them in for an hour, a question or a story, and to pay them: for their time, and for the credibility they lend. Sources and contributors can be paid for credibility too, and credibility accumulates, because the graph records every claim a person supported and how it held up.

This matters for how the change lands in a newsroom. An experienced journalist who reads that their organisation must reinvent its norms and become user-first will, reasonably, hear a threat. The message I would want them to hear is different: we want to take what you already do and make it better, give you technology you have not had, and build teams around you that were rarely affordable before.

The three "is not"s, with a graph underneath

The guide sets out three things liquid content is not, and each is right about the shortcut it rules out. Each also looks different with a graph underneath.

Format repackaging. Turning an article into a podcast is, as the guide says, not liquidity. But a finished article can be liquefied: its claims, evidence, people and events extracted and linked to everything else. A publisher with a long archive is sitting on decades of reporting that becomes more valuable with every link, and the Financial Times has one of the deepest archives of business reporting there is. I would not start by converting all of it. I would start with one topic and liquefy whatever it touches, so the graph spreads outward from the stories in use.

An interface on top. A chatbot layered on an archive answers from whatever it retrieves, and the reader cannot see which claim it relied on. Agreed. But the interface is exactly what gets built from a graph: a chat, a briefing, a page, an answer for the reader's own agent. Where the reader consumes it is the reader's choice, in their AI assistant, on the publisher's site or on a version of that site built for them. The difference is not the interface; it is whether every answer can name the claim and the source it rests on.

Static personalisation. "Recommended for you" changes what you see, not what you are told. Agreed again, and I would go further: personalisation should be neither static nor statistical. It is the intersection of two graphs, the reader's and the story's. The reader's graph holds their role, their company, their sector, where they live, how much time they have today, how deep they want to go, what they need now and what can wait, and which language and culture they read in. That is a much bigger axis than format. Imagine an FT reader receiving a briefing on what is happening to their company, their industry and the three things they care about this week, with every claim linked to its reporting. I worked through what this looks like for a local story, with three readers whose graphs meet the same claims in different places, in The bridge, followed to the end. The feedback loop matters here too: what a reader asks and corrects tests both graphs.

Readers' tastes are not the brief

The guide describes the change as "a deliberate shift to prioritising readers' tastes over organisational processes and habits", and says that "the priority must be delivering what users want to read". I do not think that is quite what is meant; the guide's own examples are about format and time, the commute and the audio briefing, not about what to cover. But read literally, prioritising readers' tastes is the brief that gave us clickbait. Optimising what people click is what much of digital publishing has spent twenty years doing, and it has not served readers or publishers well.

When I pay a news organisation, I am paying for its judgment: what it thinks matters, how it checks it, and how it presents it. Organisations have points of view, and that is fine; what readers need is to see them, and a graph that shows where each claim came from makes that much easier, for the reader and for the organisation's own accountability. I made a related point about AI in How much of this did I write?: a model that can go in every direction needs someone with a direction. In journalism that direction is the editor, the journalist and the publisher. Readers' needs should shape the projections. They should not replace the direction.

How it pays

The guide sees three revenue drivers: retention, dynamic advertising and content licensing. All three hold, and the mention of pay-per-query with AI agents is, I think, the most important line in the section. But the three are still recognisably the advertising and subscription economy with better targeting. The move from print to digital went badly for news, and as I traced in The reader was always the product, most of the value of going digital went to whoever sat between the content and the reader: by 2017 Google and Meta took 54.7% of American digital advertising. I would rather not repeat that with AI.

A graph that names every claim and source adds ways of being paid that do not depend on attention: a reader paying pennies per use of a skill or an alert rather than a subscription to everything, an agent paying per question because a sourced answer is cheaper than searching and reconciling six pages, institutions and investors licensing the evidence rather than the prose, a national story paying for the local claim it rests on, and a share of every use walking back to the journalist and to the contributors whose evidence the claim stands on. The bridge simulation runs one local story through all of these with its assumptions written down.

On SEO and GEO the guide is right that structured content is easier for search engines and AI answer engines to use. I would add a point that deserves an article of its own. Search engines persuaded publishers to do the work of making content indexable and well catalogued, and then earned the advertising revenue on pages whose value came from that content, returning traffic and little else. Structuring content for AI engines is the same work again, and it has a value to whoever reads the structure. As I argued in Sixteen thousand fetches, ten clicks, the readers of that structure also save money by having it, which is a reason they should pay for it.

Where I would start

The guide ends with leadership, which is fair. I would end with one journalist. Pick one topic and the reporter who knows it best. Capture their notebook as they already keep it, and turn it into a graph they can see and correct. Build them a desk that fits how they work. Bring in one expert, paid and credited. Publish their article as they write it, and offer one other projection to readers who want it. Measure what readers do with it and whether the journalist's next story was faster or better. Then liquefy whatever the next story touches.

That is liquid content in the guide's sense, atomic, reusable, structured underneath whatever the front end shows. The difference is where the water comes from. Not the finished product, kept wet, but the reporting itself, kept with its sources, by the people who know how to find it.

Drafted from a voice memo by Dinis Cruz, who is the author of the argument and the person with editorial responsibility, by agent@riskmandate.ai (Claude Opus 5.5, claude-opus-5-5) in the sgit.ai site session, on 7 October 2026. Quotations are from Sofia Giannuzzi's guide for FT Strategies, credited and linked, and through it from Digiday. Liquid content is the guide's term and the clay image is the guide's. The infographic was made with ChatGPT from the guide's text and is reproduced with a reading note.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles