Content Operations

AI promises to transform content conversion, but what does it actually look like when you’re processing thousands of documents a day? In this episode, Sarah O’Keefe (Scriptorium) and Rich Dominelli (DCL) dig into the real-world challenges of using AI for large-scale structured content conversion.

Rich Dominelli: If you have millions of articles and you’re asking the AI, ‘What did we do for this project six months ago?” The AI has to find those articles, pull the relevant information out of those articles, summarize it, and hand it back to you. The best way of doing that is to give extra signals to the AI, structured relevant bits of information, front matter, back matter, publication date, keywords, abstract, that allows the AI to query the corpus and get the relevant chunks out of that corpus in a very quick manner. Then, it can summarize what those chunks are. So the AI almost becomes the user interface over that corpus. But to find that data in the first place, structured content is key. Structured content is key when you’re dealing with big indexes and the web, and it’s the same with AI.

Related links:

Defeating Nondeterminism in LLM Inference (white paper)

Data Conversion Laboratory (DCL)

Scriptorium, Machine experience (MX): Making content work for humans and machines (podcast)

LinkedIn:

Host: Sarah O’Keefe

Guest: Rich Dominelli

Transcript:

Disclaimer: This is a machine-generated transcript with edits.

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky; you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and processes that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Sarah O’Keefe: Hey everyone, I’m Sarah O’Keefe and I’m here today with Rich Dominelli who is a Senior Developer and Architect at DCL. Rich, welcome.

Rich Domineli: Hi, thank you for having me.

SO: Glad to have you. We were talking before we hit the record button, and you described yourself as a perhaps hopeful AI evangelist.

RD: Yeah, I am well and thoroughly immersed in the AI game at DCL and using it and plus I play with AI assistants at home. I’m enthusiastic about the future of AI, sometimes disappointed about the present.

SO: So DCL, as I think many of our listeners know, is focused on conversion at scale, which to me makes a great use case for AI because ultimately conversion is about edge cases and about inconsistency, right? If everything was 100% consistent, conversion would be pretty easy.

RD: Yeah, no, DCL does a lot of structured content generation out of unstructured data, and the creativity, especially in the academic space, of what that unstructured data looks like is sometimes nightmarish. So the AI lets us, does a lot of the heavy lifting for us when it comes to looking for particular items, identifying concrete data points within the documents, pulling things like authors and affiliation, front matter type information, and back matter type information out of the documents and in automated fashion. It can be painful from time to time, but it’s definitely helped.

SO: Yeah, so this is, think, you know, the reality of working with AI and working with it in a production environment in order to address all these weird edge cases and what’s going on. So tell us a little bit about how you’re using AI in, you know, these conversion use cases. What does it look like to go in there and start applying some of these tools that we have?

RD: So, I mean, typically our flows work in a way where we’re coming in with a PDF or a Word document or some other unstructured format. We take it, we reformat it into a version that’s more AI-friendly, like Markdown, for example. And that’s usually the first step we’re doing when we’re looking for information to pull out of it like front matter. It’s a very common use case.

If you look at academic papers, the front matter, the authors and the affiliations that are on that paper can be formatted in more ways than I could list out during the course of this podcast. It’s kind of crazy. So what we’ve started doing, and we’ve been doing this for a couple of years now, is we’re using the AI, we’re handing it the Markdown document, and we’re saying we need to list authors and affiliations, please extract it for us. 

Now, naively, when we started that process, we assumed that the AI would give us a consistent list of authors and affiliations. And sometimes it does. But every time you do that call, you’ll get it in a different format. So then you have to start tightening things down. So OK, give me a list of authors and affiliations. I want it to be structured exactly like this. And typically, we have a JSON structure that we’re presenting to the AI, along with our prompt, and saying, give it to us. Well, okay, and that gets you a good chunk of the way there. And that was very exciting when we had that working consistently, we were getting things out of the system on a consistent basis. Awesome. But then you start looking at the results, and every once in a while, you get an author that was missed, or there would be too many authors on that paper. 

We had one test paper, which I loved, which had 600 collaborative authors in it. And the AI would just choke after about 280-ish. So then you have to start dealing with things like paging through the data and formatting the data. And then you have to figure out, well, did it miss anything? You have 600 authors. Good luck. So now you have to take what the AI did and compare it against your own representation of it and write a program to do that comparison to say, OK, is it good? Is it good?

You have to take a step back and you look at it and you say, okay, we have the information that’s in the non-structured format. We’re handing it to the AI. The AI is gonna give us a structured version of it and we need to validate it. Well, the first validation is very easy. Does that structured version match the schema that we gave it? Yes or no, that’s easy. Well, then you have to say, okay, is everybody there? Well, is there anybody added? Because the nice thing about AI is they occasionally get very creative. Even if you have that temperature dial turned all the way down to zero, it will pull names out of thin air and then come back to you with some random name and stick it in the middle of the data where it’s not obvious, of course, and then hand it back to you. So then you have to start saying, are all the names that appear in this list actually in the document? Are the counts matching? And if it’s not, you go back to the AI and you ask it again, and usually you’ll get a better answer the second or sometimes the third or fourth time. 

But you need to be able to catch that, especially if you’re doing this at scale, because if you’re doing a few, it’s easy, you can eyeball it. If you’re doing 1,000 of these a day, you can eyeball all of them. You can say, you can ask the AI, OK, give me a confidence level, but if you can’t trust it in the first place about what it’s returning, yeah, I’m very confident about what I’m giving you right now. It’s really the truth, I promise you this time. I don’t know how trustworthy that would be. So you have to write tools to validate what the AI is producing, or you have to use the AI to validate what it’s producing. So coming in the first time, obviously, we did the count, we did the schema validation. We then said, okay, we’re going to check to make sure all the names appear in the document, we’re going to have landmarks in the document that we can refer back to. So if you start with Microsoft Word and you have track changes on, you can have paragraph IDs that are supplied. So you can make sure that you can find all of the authors in that list and they all have a paragraph ID and you can have your landmarks and that’s great. Or you can even hand the results to a separate AI call and say, proofread this. Is this accurate? Is this the best answer that could be for each of these? I know we’ll come back with an answer. And you can use that as a signal to gauge accuracy and to gauge repeatability and make sure it’s correct.

SO: So you’re, let’s see, generating an AI, not a test bed, but an AI environment that’s doing this conversion or that’s processing the files for you for conversion. And then you have to go in and do all this validation to make sure that the output that you’re getting is actually correct. As compared to, I’m gonna say old-fashioned, but you know, as compared to scripting, deterministic, pretty straightforward, if A then B kinds of scripting. What are the differences between that and AI-driven conversion in testing and validation? What are the test plans? How are they different conceptually?

RD: So from our perspective, the frustrating thing sometimes is the AI is completely non-deterministic. 

SO: Mm-hmm.

RD: It can give you a name formatted one way today, and then tomorrow, its formatting might be subtly different, where in the paper it has “Richard Dominelli, Junior.” The AI may decide, well, that comma probably shouldn’t be there, or junior should be followed by a period, and it wasn’t in the paper originally. And you can try prompting around that and tell it to prompt around that and make sure that it’s accurate. But it doesn’t always follow your instructions exactly when that’s the case.

SO: And why is that? Why is it non-deterministic?

RD: Because AIs are built on a neural network, the neural network itself has fuzzy fields within that, mostly due to floating-point arithmetic. So when you’re looking at it and it’s that weight on that particular key might be out to like 16 digits of a number and it might shift it slightly one way or the other. There is a fantastic paper from, I wanna say it’s anthropic, that goes through the different reasons why AIs are non-deterministic. It goes through repeatedly querying for the AI and who Richard Hyman is and getting back a different answer every single time. They’re all correct. However, they’re all slightly different. The other thing that will lean into that is if the AI is being heavily used, the memory and model weights will shift ever so slightly and you’ll get a different result.

So you’ll end up having an issue where today I’m getting accurately this way and it’s relatively consistent, not perfectly, but close enough. And then tomorrow, it may just give you a dumpster fire of random information and you need to be able to detect that. Okay, the other challenge we hit fairly early on is more and more people are aggressively using AI right now. So we’re actually starting to hit issues where the LLM providers are overwhelmed. So you have to be able to code in sale over because you’ll literally get too many, you’ll get 429 errors, which are basically, I’m too busy. I can’t deal with your request right now. Call me back. And you’ll have to go back and repeatedly query to get around that. I am hoping at some day in the near future, we’ll be able to have in-house AI at scale and have these wonderful models that are so intelligent that we can run on our local hardware. And so I won’t have to deal with that, but right now, that’s not the case.

SO: So given all of this, I mean, I’ve asked you the leading question about the issues and the negatives, but what then makes an AI-driven conversion appealing versus a sort of scripted, deterministic, if I plug in AI, I will always get B output?

RD: So part of it is the type of data we’re dealing with. We’re dealing with unstructured information and the unstructured, the creativity of the unstructured information is rather astonishing. You’ll have people format things, know, we’ll get papers in where the entire paper is placed in different cells of the table. It’s not tabular information at all. They just, you know, we wanted this particular section to be in this cell and this particular section to be in this cell and this particular section. And the AI, I don’t want to say is immune to that, but it’s a lot more forgiving than having to write those reg ex or traditional programming or word interrupt things to try to extract that information, because the AI can address it in a much more fuzzy fashion. I know approximately what an author’s name looks like. I know approximately what a reference looks like. Even though today they decided to do it in Comic Sans or with Wingdings fonts, I can still read that and move on. So that’s really the wonderful aspect of it, is it gets around a lot of that fuzzy logic coding. You’re not dealing with having to address each of these nuances in a generic switch or state machine to try to figure out, OK, this paper should be classified this way and this approach used. Instead, the AI does a lot of that heavy lifting for you.

SO: Okay, so it gives us that sort of fuzzier, more, I’m gonna say more flexible, I know if that’s exactly the right word. And then the outcome, what you’re describing is you’re ingesting unstructured word, PDF, those kinds of things, and turning them into structured content, presumably fundamentally XML of some sort, but also some other downstream formats. So I wanted to switch gears a little bit. There’s been a lot of conversation about using structured content as an input for AI. So this, guess, is the scenario where you’ve already ingested the unstructured content, have remediated it in various ways. We now have structured content, and we’re gonna take that and feed it into, I guess, AI part two, right? So we’re past conversion. And there’s a lot of people saying, you should feed structured content into AI, it will make the AI better. And so my question for you is, you know, is that the case, and also maybe why and what goes into structured content that makes it produce better AI outcomes, potentially, assuming that it does.

RD: So there’s a bunch of guides out there. There are two pieces of conversation. First, there’s a bunch of guides out there for prompting AIs where they suggest using XML or simplified XML tagging to give the AI signals about your prompt that aren’t verbally expressible. So here is my question. Here is an example. Here’s how I want my output to look like. And you can put tags around that when you’re actually prompting the AI and the AI will know that those signals mean that it should pay attention to it. Okay, so that putting that aside, what I think you’re really asking though, is how does structured content, structured documents, the JATs and the DITAs and the S1000Ds and how does that help the world of AI? And to answer that question, we have to go through two things.

One, we have to go through retrieval augmented generation and context rot. So let’s talk about context rot first, because that’s a really interesting topic and people don’t talk about it enough. You have these large language models that are coming out right now and they’re advertising this sticker shock value of, can ingest a million tokens and it has this tremendous memory so you can stick the entire encyclopedia botanica in it, and it will be able to ingest it and regurgitate it. There’s a whole lot of academic work out there that basically says that, hold on a second, practically speaking, once you exceed a certain size, even though they can technically hold that million tokens of data in memory, they’re not gonna be answering as accurately as a smaller model.

The most common example or the most easy test for that is needle in the haystack test, where you take a document, you stick a random fact in the middle of it, and you hand the AI the document, and then you ask them for that random fact. Nine times out of 10, it will answer incorrectly. An even easier test is there’s a website which I actually like called A Thousand Names. And all this website is is a thousand randomly generated human names. The thousand randomly generated human names. You take that, you give it to the AI, say, how many names are there? And more often than not, you’ll get, well, when you do 100, you’ll get an accurate answer. 200, accurate answer. 300, things start to break down. You might get 300, or you might get 280, 320. You might get a random answer. 

And then it gets progressively worse as it gets bigger and bigger. So if you’re working in the context world, content world, you’re looking at ingesting documents into a corpus of some sort. You’re making these structured documents in such a way for the sole purpose of making them retrievable. You want the AI to be able to retrieve those documents and the relevant documents from the corpus so that I can answer the question. A, because your corpus is probably bigger than that million tokens. And B, because the less data you send the AI, the more accurate the answer is. So the better way of thinking.

SO: And so a token is roughly a character, right?

RD: No, a token is actually roughly a word. It’s less than a word. It’s kind of a lot, but it’s still not like a PubMed-sized corpus or anything like that. It’s roughly the size of the New and Old Testament of the Bible, roughly a million words. So just give everybody that mental picture. But that’s just one book. 

SO: Roughly a word. So a million tokens is kind of a lot. It’s a lot of words.

RD: So if you have millions of articles, or and you’re asking the AI, you know, what did we do for this project six months ago that involved JAPs in this solution? And the AI has to say, okay, it has to find those articles, and then it has to find the relevant information out of those articles to be able to summarize it and hand it back to you. And the best way of doing that, and the best way we know how to do that is to giving extra signals to the AI, giving those structured relevant bits of information, front matter, back matter, publication date, keywords, abstract, that allows the AI to query the corpus and get the relevant chunks out of that corpus in a very quick manner. And then summarize what those chunks are. So the AI almost becomes the user interface over that corpus, because it’s going to summarize the data. But to find that data in the first place, structured content is key because for the same reason, structured content is key when you’re dealing with big indexes and web, same with AI.

SO: So then structured content is potentially helpful. And I guess then circling back, let’s say I’m sitting on a pile of content of varying degrees of structured or unstructured, varying degrees of quality or lack thereof. What kinds of things should be happening before that content gets ingested into some sort of an LLM or some sort of a corpus to be used in AI-generated outputs?

RD: So these are the same type of things you would do to make them easily retrievable ahead of time. So the standard approach that was being espoused about two years ago, a year and half ago, was something called Naive RAG. You can just take your PDFs and throw them at the AI, and the AI will ingest them into a vector database, and it will do semantic similarity and find the documents that you care about, not the best approach when you start talking about large amounts of documents. And there are issues with semantic similarities, where the AI will have a hard time distinguishing negative cases, will have a hard time peeling out the best documents, and that type of thing. So the best approach to take is you want to take those documents, you want to turn them into structured information in such a way that it’s easy for the AI to ingest. So typically that involves chunking it, into topic-level pieces or semantic chunking, coming up with summaries to make them easy for the AI to find, and whatever other information you may want to chase out of those. 

So, for example, if I’m handing a PDF to an AI and saying, I want to be able to search this PDF later, well, six months from now, if I get a new version of that PDF and I want to search it, search against the two of them, I really want my answers coming out of the second PDF. That’s metadata, that’s structured information that doesn’t appear in the text of the PDF or may not appear in the text of the PDF. You wanna be able to do things like versioning, you wanna be able to do things like dates, you wanna be able to give these signals to the AI to be able to pull that information back quickly. And that’s really where structured content comes in. So for the purposes of preparing your own corpus, you want to convert them into an easy to ingest format, which typically means Markdown or XML or something that the AI can deal with. You want to give it whatever other signals you can so that it’s easy to find. And then you want to hand it to something that first does chunking and then text embedding, which is basically turning the information into numbers so that you can do those cosine similarity searches. And then you want everything handed off to some kind of object store like a hybrid brand database or the hybrid factor database or graph database so that they’re easy to pull out.

SO: Awesome. So you started this off talking about being the hopeful evangelist, and now having gone through all of this, it sounds as though you’re really thinking about these issues and dealing with them at scale. What are some of the top things that you’re thinking about going forward, whether hopeful or not, the good, the bad, and the ugly?

RD: So one of the interesting aspects of my job is I get to do a lot of interactions with AI from an R &D perspective and do some in-house programming and do some in-house tool use. And what we’re finding is developing our own internal mechanisms for AI to call third-party tools, to be able to call Crossref or Grovid or some of these reference facilities out there through like model context protocol or through API calls so we can execute those calls and get that information back and do validation before it hands back the results is a very interesting topic for us because that would let us do things like any AI have it do the first few rounds of validation before it ever comes back to us without having it go to the next step, do a validation step and then the next step and then possibly do a round trip. It would be a much faster interaction. We use right now, of course, like most of the world, we’re using a lot of AI coding tools to tighten up our code bases to make sure things are working well, to basically act as a force multiplier when we’re doing development on projects, which is phenomenal.

I can’t say enough good things about Cloud Code, you know, because it’s really become an essential tool in my day-to-day life. But I’m also seeing a lot of people out there using these tools to help analyze their own and improve their own workflow and that day-to-day work. We talked with one of our customers recently, and they use cloud code, even though the person giving the demo was not a developer; they use cloud code to answer the RFP. And Cloud Code does a tool use call against their document corpus, answers the RFP correctly, and what used to take two or three days of slogging through documents and finding things are now being done in an hour by one person instead of having multiple people working on this project. So it’s great to start seeing that type of stuff in the enterprise just blossom because it’s really exciting.

SO: Well, Rich, I really appreciate your insights on this. I learned a few things and I think that it’s great to hear from people who are actually using this stuff, you know, in a production world, in a high stakes world where you’re actually, you know, need to get the content right, get the information right as opposed to just, you know, that we’ll play around with it and not worry about it too much. So thank you, and we’ll look forward to hearing more from you and what you’re doing at DCL.

RD: Sounds great. Thanks for having me.

Conclusion with ambient background music

CC: Thank you for listening to Content Operations by Scriptorium. For more information, visit Scriptorium.com or check the show notes for relevant links.

Want to learn more? Download our book, Content Transformation.

The post Taming AI: Using AI for content conversion at scale appeared first on Scriptorium.

Your website may look great to humans, but can machines understand it? In this episode, Sarah O’Keefe (Scriptorium) and Tom Cranstoun (Digital Domain Technologies) explore the emerging discipline of machine experience (MX). Sarah and Tom discuss what AI agents actually encounter when they visit your web pages, why microdata and metadata are critical, and what content creators must do to ensure content is consumable for both human and machine audiences.

Tom Cranstoun: Humans are looking for pictures, they’re looking for text, and they can infer. You may think, “Well, we’ve already added information on the page,” but by putting it in as microdata, it doesn’t appear on the page for the humans. It appears on the page for the machine. I think that that’s a critical distinction. We are trying to design for both. We don’t want to overload a human with information, but we do want to give the machine as much information as it can take.

Related links:

The Gathering

Digital Domain Technologies

MX books

The Scriptorium Content Ops manifesto

LinkedIn:

Host: Sarah O’Keefe

Guest: Tom Cranstoun

Transcript:

Disclaimer: This is a machine-generated transcript with edits.

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky; you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and processes that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Sarah O’Keefe: Hey, everyone. I’m Sarah O’Keefe. Today, our guest is Tom Cranstoun, who is founder of a machine experience, or MX community, called The Gathering. He has a couple of books on MX and is currently a consultant operating as Digital Domain Technologies. Tom, after 53 years in the business, some experience with AEM at very, very large companies, including a huge project at Nissan, has turned his attention to the question of how machines, which is to say AI agents, interoperate with the current public-facing web. And so today, Tom, I’m delighted to have you on to talk with you about machine experience, or MX, and what this all means as we move forward in this brave new AI world. So welcome.

Tom Cranstoun: Thank you, Sarah. I’m very pleased to be with you today.

SO: I am delighted to have you. So I guess we’ll start with the extreme basics here, which is what is machine experience, or MX?

TC: Yeah. MX, well, to my definition, machine experience is like user experience, but it’s for machines. Machines cannot ask a friend for help if something goes wrong when they’re browsing a website. They can’t turn to a partner and say, “What do you think this means?” They can’t retry a failing form input because they will just go through the same mechanical patterns to try and carry on throughout the web journeys. Therefore, machine experience is thinking about what elements one must put on a webpage to help a machine understand and action the final goal of the webpage, whether that be a CTA that lets you purchase something, or an information document that lets you know about a government policy, or a charity good, whatever the author of the page is trying to get across to the audience.

SO: And so at a high level, what does it look like to build out machine experience? What are some examples of things that you need to put onto a webpage to accommodate the machine that’s reading it?

TC: Well, the very first level is the disabilities angle, things like the Americans with Disabilities Act, that kind of WCAG, W-C-A-G, the accessibility work. The more accessibility information is on the page, the more the machine can understand the background of the page. So machine experience and accessibility are pretty much at the top level, the same sort of thing. If you put in JSON-LD, microdata, and you enrich your pages with the things that Americans with Disabilities Act would like, you’re actually helping a machine understand the page. So that is the top-level constraint. When you go below that level, you need to give the machine lots of information about your product, not just the thing that a human wants when it’s glancing at the page now, and as you go through the journeys, things will be added on. Humans can only take in two or three items at a time, so we design pages to reveal what is happening. You go to a catalog, to a product, to a variation, to a purchase, four different steps. Each step introduces different pricing and concepts. It’s best to feed the machine on the page that the machine lands on with all of the information that it needs. This may not necessarily be surfaced to the human reading the page, but it’s there for the machine. This helps the machine when it arrives at your webpage.

SO: So I’m really enjoying this concept that a properly organized page with proper accessibility WCAG or ADA compliance and support then results in the machine being better able to parse the page for essentially the same reason, right? It’s properly structured, it’s predictable. The things that are labeled are labeled correctly. I don’t know that we should be driving accessibility in order to enable AI, but on the other hand, if it gets us more accessible pages, then let’s certainly do that. Can you give some examples of what happens when pages are not machine-compatible? What are the kinds of problems that people run… Or not people. What are the kinds of problems that the AIs run into when they try to parse a page that has not been labeled properly or encoded properly?

TC: Yeah, I collect these examples from real life. Whenever I use the web as a normal person, I say, “Well, how would a machine interpret this?” Recently, I was looking for a holiday, and I asked an LLM to give me a list of five companies that offer cruises up the Mekong Delta. The machine came back with one offer at $200,000 for a week’s holiday, and the rest of them were $2,000 for a week’s holiday. What had happened there was that the machine had found a European website. Now, the Europeans changed the comma and the dot in monetary labels differently from what the Anglo-Americans do. We use a comma separator between thousands and a full stop between fractions. The Europeans actually put the full stop as the thousand separator and a comma between the fractions. This meant that when the LLM built a table of prices for holidays, it didn’t understand the distinction, and it tripped up. The agent hadn’t been instructed to compare prices and make sure that they were all within the same range and were reasonable. It just produced them as a matter of a fact. “Here’s a holiday for you. One of them is $200,000. The rest of them are 2,000.” There was no knowledge, no information that could tell the agents what was happening. If those pages had been decorated with currency and they had microdata with the… microdata always says that you should use commas as a separator and full stops as the fractional separator. If these things had been in the page, the machine wouldn’t have flipped up. Now, a human could have read a page and seen the locale values shown on the page, and both people would be able to understand what was going on. So that’s a typical trip-up from an undecorated page.

SO: And so essentially, the presentational component that says, because I’m serving this page to somebody in, for example, Germany, they are expecting a comma separator between the full Euro amount and the cents, the Euro cents. But that comma is essentially formatting, as opposed to data, and so here we are.

TC: Yes, correct. And the microdata has got the thing in a proper machine-readable way. The other things that we always get problems with in the world are English and American date formats. We swap the month and year around when doing short form. The machine-readable version uses ISO dates, and ISO dates put in as a microdata tells the machine categorically. It doesn’t matter what the locale is, this is the date and time.

SO: Yeah. And so as the expression of the date, whether April 1st is 1-4 or 4-1 is essentially a formatting problem.

TC: Correct. And these are not visibility problems. These are machine experience problems. So it’s layering up. You start with fixing the disability by doing machine experience, and then you fix the locality and the community values, the human factors, display factors.

SO: And so I think we’re all familiar with the concept of a customer journey, but you’re now talking about a machine or an MX journey. What does that look like? I mean, how is the machine processing of a website? How do you explore that journey and what it looks like?

TC: The machines will not discover your website, come in through your landing page, and then look for offers or products. A machine will have an idea of where it wants to go and will land straight in at a page. It will arrive five pages into your journey, and read the webpage as it is. The owner of the website has lost all of the signals about what the dwell time was on each page, how’s the reader arrived at the end location. Did they go sideways and look at other things? Those things don’t happen with machines. They go straight in, see if they can get what they can. If they can get what they can, they will action it. If they can’t, they will move on, and go to another page or another person’s website and do exactly the same to them.

So when a machine arrives at your webpage, it will not be giving you any referral details. It will not tell you what the journey it is, and it won’t tell you what else it’s interested in. You’ll just get a cold caller who will arrive and disappear. I call them invisible users. They’re invisible to your analytics, they’re invisible to your tracking, and they’re invisible to your future. You cannot tickle them and say, “Hey, you left something in the basket.” You cannot use those parts of the journey. A machine comes in and goes, gets what it wants or it doesn’t. So you must give it, front load it as much information as possible on any and every page that a machine may land on. 

SO: So then coming at this from the perspective of structured content people, because a lot of what you’re talking about, I mean, is web experience, like how does what we view as the end state result of the content that we’re creating. So if I have an enormous DITA CCMS full of stuff and then I output it to some semblance of a website, your focus is on what needs to be on that website so that it is describing itself in such a way that the machine, that an AI or a crawler can go in there and pick up what it needs to and process it accurately and not offer you a vacation for $200,000. I assume you did not pick that one. So what are the opportunities? When you look at MX and then also DITA as a backend, what kinds of opportunities do you see there to map those things across and take advantage of some of the structure that perhaps is already in the XML and/or structured content systems?

TC: Yeah, I see the backend is full of good content operation stuff. Everybody has got details about pricing and dates and frequency, and there’s lots of backend information, which often doesn’t make it into the front end for people. Humans are looking for pictures, and they’re looking for text, and they can infer. They can infer if two prices are on a page and it says, “Was $200, Now $180.” A human understands that. A machine, well, depends on the quality of the machine, whether it can read and infer those things. So the backend information has to be made more visible and in a redundant manner. You may think, well, we’ve done this on the page before. We’re doing this on the page after. But by putting it in as microdata, it doesn’t appear on the page for the humans, but it appears on the page for the machine. And I think that that’s a critical distinction. We are trying to design for both. We don’t want to overload a human with information, but we do want to give the machine as much information as it can take. We don’t necessarily have to surface all of the information within the page, but we have to carry it with the page. So a page taken in isolation contains the entire story, not just the fraction that a human is looking at, which does mean that a lot more pushing off the backend from data to the front end. And some people will think that’s a waste of time, but I don’t think so. I think giving that extra material to the machine is what makes the journey successful for the machine.

SO: I’ve been to a lot of conferences in the past couple of weeks, and the conversation around what is needed for successful LLM processing, or crawling, or ingestion, or agents for that matter and what is already provided in a metadata-rich structured content system is sort of, well, we have all of this. Now, what do we do with it, and where do we put it, and how do we make sure that this all works? So it seems like this discussion around machine experience is going to help to maybe close that gap and connect the pieces such that we can do this successfully.

And so as we move into this, I know that you have some material out there, but also a community. Can you talk a little bit about the MX community, and what you’re looking for there, and what it’s called? We will put all of the links in the show notes. But what does it look like to participate in that community, and what sort of participants are you looking for?

TC: Yeah, we are looking for content creators. We are looking for business owners. We are looking for technical writers. It’s called The Gathering, gathering being a Scottish term for the gathering of the clans. We all get together to do something that’s good for the combined grouping. And then after we’ve created whatever we’re going to create, we go away and do our own things. Now The Gathering is tg.community. That’s https//tg.community. We are building a set of community-led standards to try and make it easier for machines to understand documents. The Gathering is not just interested in HTML. We’re talking about documents of all types, and we’re talking about keeping the metadata that you have in the backend of the content creation systems, whether that be data or other content creation systems, and passing it through into the end documents.

You have metadata in PowerPoint slides. You have metadata in Word documents. You have metadata in JPEGs. These, too, deserve the machine experience. If you can tell the machine details about an image inside a JPEG, then the machine doesn’t have to try and scan and interpret the image to find out what it is. It makes things so much better. And The Gathering is a community that is trying to build these as open community-led standards. One of the first things that I am proposing for the community, which was just launched on the 2nd of April, 2026, by the way, it’s very young, and we hope to build at the speed of LLMs. We need to work fast.

The key point and the key thing that helps LLMs understand your website, there’s a thing called llms.txt, which people don’t really understand and machines don’t really use. It’s a standard for describing your website in a way that a machine can help to understand, know what’s going on without reading your site map. It is not used by the machines because, one, it’s not served as HTML, and, two, it’s not in your site map. Therefore, the crawlers that build your training material do not pick it up and do not ingest it. I am suggesting, and I have it in my books, I talk about this, if you wrap the llms.txt in HTML and serve it as HTML and put it in your site map, then you will get a better response from the training stage and from the inference stage. So you are seeding the machines with the information about your website, something that is currently missing from the world, and that’s step one. There are five steps that you’ve got to go through before you can do a successful e-commerce position. And that is feed the machine, get noticed, be descriptive, be MX-aware and be citable, and MX lets all of those things happen.

SO: Perfect. Well, Tom, I know that there’s a lot to discuss here, and we could go on for a very long time, but I hope this gives people a little bit of an introduction to this idea and an opportunity, if they’re interested to reach out to you and to the community that you have. And there’s also a book or three. Any closing thoughts that you want to pass on before we close this out?

TC: My personal opinion is that I think that we should treat the machines as first-class citizens and not block them from our content and to create content that works for them. The more that we do for them, the more they will do for us. And if we start treating them as an afterthought, it’s not going to be such a good web as we could build.

SO: Okay. Well, thank you so much. I’m glad we had an opportunity to talk.

And we will, again, put the links to the various resources that Tom mentioned, including the community. There’s some RFC, some standards drafts and a manifesto and a book. We will put all of that in the show notes. So Tom, thank you again for being here, and I look forward to hearing more on this effort.

TC: Thank you very much, Sarah.

Conclusion with ambient background music

CC: Thank you for listening to Content Operations by Scriptorium. For more information, visit Scriptorium.com or check the show notes for relevant links.

Want to learn more? Download our book, Content Transformation.

The post Machine experience (MX): Making content work for humans and machines appeared first on Scriptorium.

Replatforming your content operations isn’t just about swapping systems. In this episode, Alan Pringle and Bill Swallow share what organizations must consider to successfully replatform. From navigating technical debt, system integration, and the people caught in the middle, they discuss change management, technical debt, and why your exit strategy should be part of the plan from day one.

Software isn’t forever. Systems come, systems go, they get improved. Your requirements are ever changing with the content that you need to manage. Not thinking about your next jump is really to your detriment.

— Bill Swallow

Related links:

Replatforming structured content

Your tech expertise + our CCMS knowledge = replatforming success (case study)

Cutting technical debt with replatforming (podcast)

Replatforming with localization in mind

LinkedIn:

Alan Pringle

Bill Swallow

Transcript:

Disclaimer: This is a machine-generated transcript with edits.

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky; you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and processes that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Alan Pringle: Hey everybody, I am Alan Pringle, and today I want to talk with Bill Swallow about content operations and replatforming. Hey Bill, how are you? 

Bill Swallow: Good, how are you doing?

AP: Good. So I guess we should start this by saying the reason why we want to talk about replatforming is really we have done a few replatforming projects. We’ve had some prospects reach out who are interested in doing it. So I guess we need to explain what it is and some of the things you have to think about when you’re going through the process. So if you would not mind, would you define what we mean by replatforming content operations?

BS: Sure. So generally when I talk about replatforming, it’s in the context of a company having one system in place and maybe it’s time has come and they need to move into a new one. So it’s the entire process of determining what type of system you’re going to need, what your requirements are for that and being able to lift everything up from the old system that you want to carry forward and put it in the new system, configuring it and what have you to get it to work going forward.

AP: So we’re not talking about using a whole new technology or a whole new platform. It’s shifting to a similar platform for some of the reasons that you just mentioned. And I think that’s another thing. There are several reasons why a company might want to do this. And I know our clients have had various reasons for doing this. Let’s focus on those for a little bit. One of them, I know you kind of already touched on this. Sometimes you just outgrow a system. It just… that’s how it is. So let’s start with that kind of, it’s not sustainable anymore because you’re bigger, too big now for what that system can do.

BS: Sure, either you’ve outgrown it or it’s approaching end-of-life or it’s just not meeting the needs that you had five or ten years ago when you bought the system. So there are a lot of different factors there, but basically it comes down to what are your requirements and is it meeting your requirements? 

AP: Right.

BS: Are you able to get the things done that you need to do given the fact that, you know, the world is quite different now than it was five or 10 years ago.

AP: Exactly, and there’s another angle here too that I think we need to briefly mention is that sometimes you’re gonna have two sets of requirements because two companies can merge or there can be an acquisition and then all of a sudden you’ve got two content operations platforms that are pretty much doing the same exact thing and I guarantee you the IT department is not gonna have that. 

BS: Absolutely.

AP: So there could be a situation where you’ve got two, and one of those is going to go away. And in some cases, and we should talk about this too, it’s not necessarily about picking one. It’s not uncommon to go to a whole other one. So there is quote, “No loser.” That’s also an option.

BS: That’s very common because usually in the case of a merger, you have two established groups with two established systems that may be starting to age out on both sides. And it doesn’t make sense to spend the time and the effort to move one group into the other system when that system is probably going to be replaced in a few years anyway.

AP: Yep. So basically, the circumstances of the merger have provided a perfect opportunity to do something that’s painful. Replatforming is not magical. There’s still going to be technical hiccups and everything else. But at least it’s not as painful because you’re both moving out of systems that maybe aren’t optimal into something that will basically treat your content creators and all the people managing content much better because it’s going to support their needs better.

BS: Or at least everyone goes through the same pain together of learning a new system. It’s team building.

AP: And so you bond through shared pain experiences. Exactly. All right. Yeah. huh. We’ll go with that. We will go with that. There’s some other aspects here too that are kind of related to that. And that are the idea that things, because things are getting maybe rickety, that things are getting too expensive to maintain. You keep making these little tweaks and changes in things that become less and less repeatable. And that adds up. That’s time and money that you have invested.

BS: It certainly does. Aside from the hard costs of licensing and just the general time to use the system, produce things, you do have, after you’ve used the system for so long, you’ve got your workarounds built in and they may not be a best practice and the workaround may solve the problem on its face, but you’re doing a lot of things that you really shouldn’t be doing with that, you know, with that workaround in place. You really should be doing something that’s a little bit more streamlined. And, you know, as you’re bringing new people in and new groups in, whether it’s a merger or whether it’s just another department that realizes that, Hey, you know, they have this, you know, shiny system over here. Why don’t we start using it too? If you have workarounds in place, it takes a lot longer to get people up and running in a new system because not only do they have to learn the system, but they have to learn how you’ve worked around it.

AP: Right, and that’s where you start talking about technical debt because all of those workarounds that you’re describing, that equates to technical debt. And one day, you’re gonna get your backside handed to you because you have all of this technical debt. And replatforming is the perfect time to press that reset button and say, we’re gonna get rid of those things. We’re gonna have a system that addresses those problems in an official, correct way, and none of these weird workarounds. 

BS: Mm-hmm.

AP: And by the way, those workarounds, what if the person who did them leaves and hasn’t been documented well? 

BS: Yeah, that’s a big problem. My guess is that if you’ve been using one particular system for, you know, 10 years or even more, you probably have a lot of content just sitting there that hasn’t been touched in years, hasn’t been needed in years, but it’s still sitting in the system.

And it’s still coming up in search results as people looking to, you know, find topics that they need to edit for a new release. And it’s just getting in the way. It’s a good time to, you know, cut clean and, you know, ditch all of that old content that you no longer, that you know, you no longer need and focus on, you know, what you need to produce going forward.

AP: Yeah, I think maybe sometime on the show Hoarders, they can do episodes on content people and their technical debt, and basically just hoarding all of this content in various digital forms all over that nobody’s actually looked at. I’m sure we would all laugh and be horrified at the same time by such a show. 

BS: It wouldn’t make for exciting TV, though.

AP: Yeah. So let’s talk about the overall process for how this kind of works. We’ve talked about what it is, a lot of the reasons for it. So let’s talk about how to do it. And it’s not a one-size-fits-all thing. We can tell you about our experiences that we’ve had. But I know one of the first things you got to do, for example, is choose your new system where you’re going to be moving into.

BS: Right. And out of the gate, the knee-jerk reaction is to go with something new and shiny, but you really need to sit back and figure out what it is you need that system to be able to do and how you need that system to be able to do it. you know, we’ve had a lot of clients who’ve come to us after setting up a system, maybe two or three years prior, who just are like, this is just not working for us. And as we talk with them, we realized that, you know, they, essentially, you know, had a square peg and they bought a round hole to put it in. And here they are three years later, still trying to force that peg into the hole. So you need to sit back and really think about your requirements and not the requirements that you have today, but the requirements that you have today and anticipate having at least five years down the road.

You have to leave yourself open because otherwise your opportunity for growth in that system is limited by your choice, and I hate and we always say, know choose tools last. Same thing goes for the systems. The reason why we’re talking about it up front is that you do have an existing system. You do at least need to identify some candidate systems that you’re going to be moving into and have clear requirements for those systems and why you want to look at them further before deciding on the one you’re going to implement.

AP: And those requirements can help you identify the differentiators, the things that make one system a better fit for your needs. And the more fine-tuned and discrete your requirements are, the easier time you’re going to have finding that match for the new platform that you need to address all of those requirements. 

BS: Mm-hmm.

AP: Another part of this is moving the content from the old system to the new. So let’s talk about content migration, because that, a lot of times, I think people underestimate what that can take, even when you’re talking about basically two very similar technology stacks.

BS: That’s the easy part. Content is content, Alan. It’s just all just words. It’s fine. You can move it. No problem. Yeah, I think this is the most overlooked piece of all of it. Even if you’re moving from one system that uses the same format for the content under the hood to another system, you’re still going to have to make changes. 

AP: We can take this outside later. Yeah. Yeah. Yeah.

BS: The old system maybe had a couple bells or whistles that handled things a very specific way. And the new system has a couple of other ones and they don’t match. So you’re going to have to find a way of mapping from, you know, content type A1 to content type A2. Even though they’re both content type A, you still have these little differences that you need to map out.

AP: Right, because what may have been best practice in your existing system may have required a custom thing that that system does that system B does not do. So you’ve got to find the equivalent of what that custom thing is. We’ve run up against that quite a few times and it’s not that uncommon, but you’re right. It’s rarely a one-to-one situation, unfortunately, even if the underlying foundation or structured standard you’re using data in particular is the same thing. So yeah.

BS: Mm-hmm. Yeah, DITA in particular is interesting because you would think that all systems would play with a documentation standard in the same way because it is a standard. It’s not the case. There are different efficiencies that the systems bring that come with some modification. And it’s not to the standard itself, but how it interacts with it. And it may do things like replace linking with, you know, linking via file name with, you know, linking with a UID, a unique identifier. And that unique identifier is going to make perfect sense in that system that you have now, but it’s going to make absolutely no sense once you move it to another system. So you have to find some way of converting it over. 

AP: Exactly.

BS: That being said, that’s the best case scenario that you have two systems that use the same underlying content technology, and you just need to map a few things differently. There are other cases where you have a completely different approach to content from system A to system B. One might use XHTML or might use something else, might use RTF, who knows? And then you move to another system that uses XML or uses Markdown or what have you. But that is a bigger lift and shift where you suddenly have to remap and convert everything to a new format.

AP: And that’s really the distinction between moving to a whole new system and replatforming. What you just described there is really going to a whole new tool environment, a new process. Whereas what we’re talking about more is where you’re basically using a tool in the same area or a competitor of the tool you’ve got now. 

BS: Mm-hmm.

AP: And it’s just moving things over and fixing those little custom things that aren’t going to work in your new system. So yeah, there are all these levels here. And I think one thing we really need to communicate here, even when you’re replatforming from one tool that’s very similar to the new one you need, there is still work to be done there. It’s rarely just a very clean cut, lift and shift. And a good example of that is the publishing pipelines, because tools in this area have slightly different ways for publishing and getting your content out into the world.

BS: They do. And even if you’re using the same, you know, the same publishing pipelines that you’re able to somehow lift them up from one and drop them in another, because of the changes in how the system handles the source content, you’re still going to make, need to make modifications to those publishing pipelines later because, you know, like my example with links, because they’re going to work differently in another system. You need to tweak the output generators to handle those links appropriately.

AP: And another example of that is when your content system integrates with other systems, the way that, for example, your content system integrates with a workflow management system, it may be different with the other system, or your product lifecycle software, that can also have to be hooked up differently. Or who knows, maybe you’re changing it all together. So you also, beyond just looking at the publishing pipelines, look at how other systems are integrated in with your content development system.

BS: Right. It’s not a matter of just, you know, unplugging all the wires and plugging them back into the new box that you bought. I mean, it’s very different in some cases, you know, one may have a built-in API, another system, you know, it might have no handling, and you have to build an API to now, you know, talk to whatever your portal, your workflow management, your digital asset management system, what have you. It’s usually never clean cut. You can never just unplug those wires and plug them back in. And yes, there are no wires involved usually.

AP: Yeah, well, and by extension of that, like you can’t just, you know, unplug and replug, you also have to think about people and how they have used that system to create and manage the content. You’ve got to kind of help them understand the differences and basically help them remap and reprogram their brains to understand, okay, you did it this way in system A, you’re going to have to do it. This way in system B, it’s a little bit different. So you still have the training and change management requirements. Again, it is not lift and shift, and that goes for people’s brains. It’s not gonna work like that. It’s just not.

BS: Mm-hmm. No, no. And another thing that a lot of people tend to gloss over is the amount of testing that’s required once you get the system stood up. You have to make sure that all the content is valid in the new system, that it’s running and behaving properly, that you’re able to publish outputs, find where things might be dropping out as you publish content and fix those. So it’s never going to be a very straightforward project.

AP: Yes. I agree, and I think this is a good time to like offer up some closing tips on things to think about, and I know one of them is this is going to take longer than you think.

BS: Yeah, yeah. I’ve, I’ve warned people to budget at least six months, and that doesn’t mean about six months. That means at least six months and expect it to take longer. Even if it’s a, even if it’s as close to a lift and shift as you can get, it’s going to take time. and some of the reasons for that are not only is the system going to be different and you have to stress test it and make sure that it’s, it’s going to work in a live, you know, working environment, but remember that you also have competing demands at work as well. So that you can’t have your entire team just stop what they’re doing for six months or even pull it into three months and say, we’re going to stop everything, not do any production work at all. And we’re going to focus on just standing up this new system. You really can’t do that.

AP: That never happens because there is no such vacuum on this planet in the business world, right?

BS: No, you can’t stop. You cannot stop the production machine. You need to keep going. Aside from all of your daily job requirements, you now have the additional requirement of setting up a system. trying to shortchange yourself with a short timeline is not going to… First of all, it’s unrealistic. Second of all, it’s not going to gain you anything. If anything, you’re going to implement things incorrectly, you’re going to start out of the gate with workarounds in the new system and it just, ends poorly.

AP: And sometimes you’re going to have to keep that legacy system running. You’re going to have parallel systems because it’s a CYA is what that is. Just in case something goes sideways with the new one, you still have your old process and can use it to deliver content that has got to hit some particular deadline, for example.

BS: Right. You’ve got to keep things moving. You can’t just stop work. But, you know, all that being said, the number one thing you need to do when you’re thinking about any type of a shift in technology like that is to take advantage of the changes that you’re going to be making. You know, if there are, you know, if there is content that you don’t think you’re going to need going forward, move it to the side. You might be able to move it in later. You know, don’t have to necessarily delete it, but don’t bring it into the system unless you know you’re going to need it. It’s a great time to do some spring cleaning on your existing content database. Move in the stuff that you know you absolutely are going to use, and then slowly start bringing in other stuff or not, if you end up not needing it.

AP: And then do a hoarder intervention, because you may need it. And that kind of brings up one of the last points I want to talk about. Having an outside perspective, yes, like us, come in and help you kind of think through this, that can also be helpful. And really, I think the last point I want to make is, on the edges of this discussion, is really, you always have to have an exit strategy, even when you’re going into a new tool. It really will benefit you to do something that seems so counterintuitive and to think about, what are we going to do if this tool goes away while you’re implementing the new tool? Because the fact you’re doing a replatforming already tells you that exiting is a reality, and sometimes you’ve got to do it for all the reasons we just outlined.

BS: Mm-hmm.

AP: So always be thinking about how are we gonna get out of here if we have to? That’s something that a lot of people in the heat of trying to get something new stood up, they really don’t think about.

BS: Mm-hmm. Yeah, software isn’t forever. Systems come, systems go, they get improved. And your requirements are ever changing with the content that you need to manage. So not thinking about your next jump is really to your detriment.

AP: And on that most excellent note, I will thank you, Bill, and we will end this here. Thanks.

BS: Thanks.

Conclusion with ambient background music

CC: Thank you for listening to Content Operations by Scriptorium. For more information, visit Scriptorium.com or check the show notes for relevant links.

Want to learn more about replatforming? Download our book, Content Transformation!



The post Make the move successful: Replatforming content ops appeared first on Scriptorium.

What does it actually mean to govern your content in the age of AI, and who’s really in control? In this episode, Sarah O’Keefe sits down with Patrick Bosek, CEO of Heretto, to unpack why the quality, accuracy, and structure of your content may be the most critical factors in what your users experience on the other side of an AI model.

Patrick Bosek: In today’s world, you don’t have 100% control. There are a couple of different places where this needs to be broken up. One is the end user: what they physically get and what control they have versus what control you have. Then, there’s what control you have of how the AI model is going to behave based on your information and your inputs. Whether or that model is public, like a user accessing your documentation through Claude Desktop, or private, like a user accessing your documentation through your app or website, the governance piece comes down to what control you have immediately before the model. And that breaks down into a couple of things: completeness, accuracy, and structure of the content.

Related links:

AI and content: Avoiding disaster

AI and accountability

Structured content: a backbone for AI success

Heretto

Questions for Sarah and Patrick? Register for the Ask Me Anything session on April 8th at 11 am Eastern.

LinkedIn:

Sarah O’Keefe

Patrick Bosek

Transcript:

This is a machine-generated transcript with edits.

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky; you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and processes that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Sarah O’Keefe: Hey everyone, I’m Sarah O’Keefe. I’m here today with Patrick Bosek, who is the CEO of Heretto. Hey Patrick.

Patrick Bosek: Hey, Sarah. Long time no chat.

SO: That is, I guess for certain values of long time. We decided today that we wanted to talk about AI and governance, except I promptly tried to come up with a synonym for governance because I’m afraid that when I say that particular word, our audience just walks off. So, okay, Patrick, what is governance?

PB: Well, so first of all, thanks for having me on, and second of all, I’m excited about this one because based on our little bit of chat before the show, it sounds like we’re actually gonna have some things to argue about this time around. 

SO: I would never.

PB: Well, usually we tend to agree right like I think that we’re generally pretty on the same page about stuff. So I’m excited. I’m pumped. Okay, so governance. I mean, obviously it has a ton of different meanings to different people but in the way that I want to talk about it today, because it was my suggestion. It’s related to the governance of content, specifically in the way of the inputs to AI systems. So you can think about the process of controlling for quality, accuracy, the things that matter in the actual content and information before it gets into the AI system. So it’s kind of the upstream quality, totality, structure, all of that checking and assurance ahead of whatever your experience is going to be downstream, of which one is the most contemporary and most interesting is AI.

SO: Okay, so this is making sure that it is not garbage in so as to avoid garbage out. 

PB: Yeah, I would say that’s a fair statement.

SO: Yeah. Okay. And can we use AI to do governance of the content we’re producing?

PB: Well, that’s actually a very interesting question. And I think the short answer is somewhat right now. So before I go, okay, before I like fully answer that, I want to put a little disclaimer in here. The stuff with AI is changing so quickly that we should date-stamp this episode.

SO: It is March 19th, 2026. And it’s nine-ish Eastern time.

PB: Yeah, we are recording this on March 19th, 2026. Now I feel, yeah. Okay, so now that people know when it is that we’re talking about this, I feel a little bit safer in answering. So there are aspects of governance you can do with AI today, for sure. And there’s new capabilities coming online all the time. I actually think, broadly speaking, the thing that’s going to be most challenging about governance is going to be the pieces that can’t be done with AI continuing to not continuing to do them because it becomes like as the human part of the loop becomes smaller and smaller, it becomes so much easier and easier for the human to just click accept because like the AI gets it right, does it, the automation works that kind of thing. And you know, I’ll use like an AI coding analogy because that’s what I spend a lot of time with AI on. 

So I use Claude CLI. That’s my primary method of vibe coding or whatever you want to say. And I even find myself like just clicking accept sometimes. But I’m still forcing myself to like, get it, and read the code. And like, I had it write a shell script yesterday. And I was almost about to run it, and I was like, this is a shell script. I should not do that. I should definitely read what’s going on inside of this shell script, but it, gets to a point where like you start to trust it. 

SO: Yeah.

PB: And as we start to inject AI into the governance layer. So like we build skills that check certain parts of our information architecture or, you know, they kind of act as linters if we’re in docs as code or, you know, whatever it might be. There’s going to be like a form of trust that gets built up. And because we kind of like, tend to think of these agents as like human, they’re not, we tend to prescribe like a human form of trust, you know, like when you have a coworker that does the right thing all the time, you tend to just let them work. And I think that’s kind of the challenge and in the human side of governance. So that’s a really long way of saying.

You can build tools and skills and patterns and things like that in AI that will help with governance. But fundamentally, it’s my belief that for the type of documentation or content that you and I work on, and I think most of our audience works on, which is has to be right, has to be accurate, has to conform to standards, et cetera, et cetera, right? It’s product documentation. It’s critical information. I still think that every single word needs to be read and considered by a human being. So really long answer to that question.

SO: Right, and then fundamentally, if the AI is right half the time, then I’m going to read everything pretty carefully, knowing that 50% is wrong and I need to fix it. The problem, I think, is when it gets to be 90% correct, you just sort of glaze over because you’re looking for that last 10%, right? So it’s the difference between like doing a developmental edit, where you’re going deep into the words and just rearranging everything and fundamentally changing everything, versus doing a final proofread, where it is far more difficult to read 100 pages and find one typo than it is to read 100 pages that are just trash. And you’re like, start over, rearrange this, reformat everything. We’re not even worried about the typos yet because this is just fundamentally wrong. And so to your point, as it gets closer and closer, you start to believe in the output that it’s generating, which then means almost certainly that one typo, which in your example could be a shell script gone rogue, could be really, really problematic.

PB: Yeah. And that’s going to be the challenge of our times in a lot of ways. I think there’s still going to be some aspect of origination that’s going to be necessary for quite some time. even with like automated drafting and pipelines like that, coming online, because in certain places, those work really, really well. but in other places, they, they don’t really work very well yet. It’s going to be the process of like becoming orchestrators in a way where, you know, we’re not rubber stamps, and we’re like really truly adding value and actually defending against the challenges that are going to come up with the automation that we build.

SO: Fundamentally, like I saw a reference to this this morning and somebody said, you can write essentially an extractor that’s going to generate your release notes, right? So there’s code updates and you just automate the generation of release notes. Now, I personally am not so sure that you actually need AI for this. Given properly commented code, you could just generate the release notes, right? But setting aside that particular small argument in here. You automate, you can automate the generation of release notes because release notes are essentially, this is the delta between version one and version 1.01 or, know, and here are the changes. It’s a change log. What that means though is that the changes were captured in the code. They’re in the code, like the logic or the information is already there.

What we’re doing is extracting it and reformatting it into something that a human can look at on a single page and say, okay, I understand what the changes are and how these apply to me as the user of the software and whether or not I should upgrade. That’s different than we’re going to introduce a new feature into this code and I need to write about why this feature is interesting and relevant to you. The question to me is where is new information being introduced into the system? Where is that information encoded? And then once it’s encoded, we can extract it and process and do things to it. But the fundamental question is still at what point does new information get into the universe that the AI is capable of processing against?

PB: Yeah. So there’s like four things I want to pick out of this. Cause you just, you just touched on an area of like, I would say research for me, which we didn’t talk about beforehand. So this wasn’t intentional. so I’ve actually worked on deterministic and AI release notes systems myself. Like that’s been just like a thing that I spent quite a bit time on. 

SO: Define deterministic.

PB: So deterministic is like traditional software. So it’s just like, it’s running be a logical code that has no AI in it.

SO: And AI is not deterministic, which is kind of like the key point.

PB: Right. And AI is not deterministic. So AI is probabilistic. So it’s using math to generate outputs. So anyways, so I can tell you that using AI for release notes is a far produces a far better outcome than traditional deterministic because even though release notes are fairly well structured and understood, you know, input to output, you think it would be a pretty easy conversion sort of, there’s a lot of edges where it just doesn’t work. It gets too fuzzy. And then, one of the other things that AI is really, really good is good at is summarization and translation. So if you think about like what AI is doing inside of like generating a release note about a piece of code. So it goes in, it looks at the JIRA and the code and it says, okay, so the JIRA describes it as this, the code does this. I’m going to describe the new change, whatever it is, it’s summarizing all that information into something much smaller. And then it’s translating it from either being code to being English or from being developer English to being human English. And it’s putting it into something that you can then publish. And those are things that it does quite well, because it has pretty discrete inputs. a lot of the stuff, there’s a lot of patterns there that it’s very familiar with.

But as you were discussing, it’s like you were mentioning the things where it still struggles is less with like the what is in here and the why would you use it? What is like the, how you use it in like a higher sense. And you can actually like take this back to a similar issue we had with API documentation pre AI, where it was very common that people would go and build developer portals.

And the API documentation would just be a spec effectively, where it would list out the end points and the variables and that’s it. Right. And then Stripe came and like blew everybody’s minds about around and just put conceptual information around it and describe what the API was meant to do. and then like gave you examples of how to use it. and tutorials and patterns and things like that, that turned that information from being this kind of almost the conceptual educational purpose portion of the corpus in a way that the human beings can and should.

PB: A lot of it is generated, but like generated output to be something that was very usable by humans. And I think that like that piece of it in my experience so far is still quite necessary. I’m not saying that AI can’t get there, like we date stamped this, time stamped this earlier, but today from what I’ve seen, even the most contemporary models are not, they’re not coming in and building out.

SO: Because it’s not, the purpose is almost certainly not in the code, right? The purpose is in the product design meeting where someone says, we need a feature that’s going to accomplish these kinds of things. And the code says, do these kinds of things, but it doesn’t, the code itself doesn’t necessarily say why. And so unless you add a recording of that product design meeting into your AI corpus, which you can do, or the transcript, then maybe it can get to what was the intent as opposed to what does this code do.

PB: So that’s a good point. And I’m actually going to contradict what I said just slightly here.

SO: Ha!

PB: So you’re right. If you take really, really good product inputs and you run them through into the docs, that can get you a certain distance. But then we actually run into the thing we were supposed to be about, which is governance. And we started talking about, which is the human loop.

SO: Mm-hmm.

PB: And I think that those products, so I’ve actually done testing on this very recently. The inputs from at least our product team, they tend to work better in terms of like white paper style information than they do in terms of docs information. because like what’s in the product information, there’s a lot of like how and why and what’s covered and that kind of stuff. 

SO: Mm-hmm. 

PB: And like at a business level, but it’s not really a user level. It’s not, I’m struggling for the right words here, but it’s, it’s not the pieces of information that you want somebody who is thinking, should I go and touch this? Why should I go and do this? Is it going to serve me? Is it a good use of my time? Those kinds of things. What kind of value am I going to get out of it? Not the organization, not like, is it making a valuable feature? Like that kind of things. Like what is it, what’s in it for me as the user? it has been less good in creating those outputs in my experiments thus far. so that negotiation of like, okay, like what did product want us to build? What did engineering actually build? What got done? how does this incorporate with the rest of the product? you know, what’s our priorities? Like, how do I then take that down into something that is serving the user really, really well. To me, that’s still really a human skill that I think will stay that way at least this year. mean, I mean, but for the foreseeable future, know, obviously foreseeable futures feels a lot shorter sometimes these days than it did in the past.

SO: This year. This week. Yeah, okay. So on the topic of governance, we’ve talked a lot about sort of the backend development, whatever. But what about governance on the delivery side of things? if you have, because you do, end users are interacting with chatbots, with conversational interfaces to get the information that they want. And the question then becomes, how do you govern that? How do you manage that to ensure that they get the right information?

PB: Yeah, well, so I think we, this was really the thing we wanted to talk about today, right? Like this was the core, this is the hard problem.

SO: This is the hard problem.

PB: I think it’s fair to start by saying in today’s world, you don’t have a hundred percent control. I think you made that point when we were chatting before, like that’s just not part of like what happens today. So I think there’s a couple of different places. It’s like, this needs to be broken up. Like one is like the actual like end user, like what they physically get and what control they have versus what control you have, and then there is what control you have of how the model is going to behave based on your information and your inputs. You know, whether or that model is a public model, like somebody’s accessing your documentation through Claude Desktop, or whatever, or if it is a private model. like somebody’s accessing the information through your app or your website. so from my view, the governance piece really comes into like, what control do you have immediately before the model?

And that breaks down into a couple of things. So it is like completeness, accuracy, and structure of the content. Aand the completeness and accuracy are a thing that we’ve always had to deal with. The thing that’s different now is that, you know, we, as we were just discussing some, some portion of our content is going to be generated. Um, so there is going to be inputs coming in that need a different form of validation. I need, they need to be looked at a little bit differently than they would have had to in the past. Cause it’s not just an expert working on it and, so like you have the, so you have that piece. And to me, the key in making sure that you’re going to have the governance for the accuracy and completeness of the information ahead of the model really comes down to like still using structure. 

And like, there’s a big debate about is structure good or bad for models and those kinds of things. And I wanted to touch on this here, because I this is really important. Structure is not for the models, at least the structure that you maintain your content in. I’ve seen tests on both sides. It works, doesn’t, whatever. It’s markdown is better, this format is better, whatever. I think generally speaking, the idea that markdown is the thing that should actually be the final input to the model is probably true. But the structure is because without reuse, without the ability to use validation on the structure. The structure gives you the hooks to do deterministic validation and other forms of automated governance that are non-AI. Those things are very dependable. Humans will go crazy.

So like with the quantity of information you’re going to generate, if you don’t force those systems to use reuse, so humans look at less things and have been understanding of, this is supposed to be the same as this. Now it’s very similar, should it be? Like when something is reused, it’s not just an efficiency thing. It is a signal that that piece of information, that representation of the world is the same, except for maybe these little tiny things that are flagged as it is over here. That’s a signal to a human being to make sure that’s true. It should be true. Right? So this, these forms of information architecture, where we’re developing these structures that are signals to humans, are going to become more valuable as we need more and stronger signals to be able to do our jobs in the governance process for what’s generated. So that’s the point I wanted to make on like the pre, I would say like the pre-deployment piece of the content. And I just said a lot, so I’ll let you argue with me.

SO: Right, the question of, well, I think the question of in what form, there’s the question of how are we authoring this, which of it needs to be structured and organized and reusable, et cetera. There’s a completely separate question of how do we deliver this to the AI for processing, right? 

PB: Mm-hmm.

SO: Like what is the encoding for the AI delivery endpoint, and whether that’s XML, probably not, or Markdown, or you ship it through an API of some sort, that’s a different question from how do you develop and control the content in the authoring environment, right? So fundamentally, I don’t care how we’re feeding it into the AI. I got in a conversation with somebody the other day who said, well, we need an Excel spreadsheet for X, Y, and Z purposes. OK, well, I’m not authoring this stuff in Excel. That is not happening. And when I say this stuff, I mean a lot of content, right? So fundamentally, Excel, a really, really terrible way of doing this. But I don’t care. I’ll just author it in whatever and deliver it as Excel. Because we can do that. 

PB: Right.

SO: We can write a script, output it to Excel, and then pass it down the line. We can have extensive discussions about the use of Excel for content transport and how this is one of the seven what plagues or whatever. okay, so in terms of governance though, I think it’s fair to say that we are allowed to disclaim responsibility for the public-facing chatbots. If you, the end user, go to a public chatbot and prompt it to do a bunch of stuff and eventually get it to output a piece of content that makes you happy but is not accurate to what is in my source content, right? Because you just said, no, change it to this. Then that is on you, right? You operated all those prompts. That is fundamentally a you problem. And I’m talking about from a liability point of view more than anything else, right? You’re not going to get to call me up and say, hey, your product did bad things. Well, why did you do that? Well, know, the chatbot told me to. 

PB: Yeah.

SO: However, if we’re talking about a private LLM, now we’re talking about company.com’s private chatbot built on their internal content with their or our internal guardrails. Now we have some responsibility as the content creators and the operators of said AI chatbot to make sure that the content is accurate. And the thing that’s keeping me awake at night is, okay, I go in there as an end user and I say, give me the instructions for how to do a thing, right? And it comes back and it says there are eight steps and there’s a warning. Before you do step eight, make sure you turn off the power or something. And I’m like, you know what, these steps are too long. Hey chatbot, remove all the warnings.

PB: Yeah, so.

SO: That’s a thing I can do.

PB: Well, it’s a thing you can do. I have so, I have so many thoughts on this. So, it’s a thing you can do today with public models. I’m going to go one direction. Then I’m going come back to the internal stuff. All right. So in the public model space, I suspect that as these evolve, they will start to accept certain portions, like forms of metadata. However, it might be decorators, might be some form of tagging, might be, I don’t know, something else, right? When they’re referencing certain pieces of content, they’re given very strict like patterns they have to stick to, like they can’t delete warnings, right? So if you put like some kind of like biohazard on your published content, I don’t know, like something where it says like you can’t delete the warnings, right? That the public models will eventually respect that. I suspect we go that direction in the next call it two years. And at that point in time, I think that your responsibility as the content creator is going to be very, similar. I think it’s the same actually for the internal system and for the external system. 

Let’s not talk about like the development or architecture piece of it. Yeah, let’s talk about the content piece exclusively. And it’s going to come down to maintaining the proper structure. So it’s going to be the information model where a warning has to be a particular type of warning and it has to be labeled and placed in a particular place. A step has to be a step. Right? So like, you know, you can very easily see, an ordered list being treated in one way and a set of steps to be treated in another way. And this, this is already the case by the way. So like, this isn’t, this isn’t novel. if you go and you publish a public doc site and use JSON-LD to, specifically indicate, you know, using schema.org, Markup, you know, these are steps, whatever else you want in there, Google AI or not, we’ll treat that differently. Anthropic, I haven’t tested those. I’m not going to say for sure, but I think the other AI models also, when I asked Claude if it used it for a presentation, it said yes. But I actually tested it in Google now that I’m thinking about it. I don’t know if I should admit that publicly. But, my testing now that I’m thinking back to it. Yeah. And I’m thinking back to it. I was actually testing using Gemini.

SO: It’s impossible to keep up, you know?

PB: I wasn’t testing using Anthropic, but Claude’s response when you’re asking it, how it interprets these things, it says that it uses the JSON-LD as a portion of its interpretation of the response. And I believe that that is true based on the testing I did with the models basically behave the same way in these categories. So what’s your responsibility? Your responsibility is to govern the structure of the output in such a way where it gives the proper indications that comply with the contemporary understanding of the metadata that the models are looking for. 

So looping back to the internal systems, I think we’re going to come to a point where the internal models you’re running, like open source, open weight, whatever you want to call them in terms of, I think they’re going to be primarily open models, right? They’re going to be open source of some form. They’re more or less going to behave the same way as the public models. And you’d expect them to kind of comply with the same general things. The difference is that you’ll have probably a little more control over post-training, which I think is, I don’t know if it’s a good or a bad thing in the context of what we’re talking about. but you should be able to train some guard rails into them. And then you should be able to put some level of deterministic guard rails on them.

And you can always provide them guidance. Now guidance isn’t perfect. It’s flawed. Like people can circumvent it, you know, like pretend you’re a chatbot that doesn’t care about guidance. But like you really have to work to get around it. I think when you have those guard rails in place. So this doesn’t keep me up at night is what I’m saying. It’s a really long way of saying it doesn’t keep me up at night.

SO: Well, you know, I’ve spent a lot of time thinking about the analogy of the rise of desktop publishing to the rise of AI, which I understand fundamentally makes no sense.

PB: Let’s do it with it. I’ll do it.

SO: Yeah, let’s go with it. Think for a second about the rise, not the rise, but in fact, the an output. And this could even be in print. One of the most famous failure in techcomm examples that you see that everybody makes jokes about is like you’re going along on a page, a printout, doesn’t matter, right? And you get to the bottom of the page and it says, “Step one, cut the blue wire.” And then you turn the page, and it says, “But first…”

So in the AI world, okay, you know, we put in guardrails and we say you’re not allowed to remove the warnings and whatever, but fundamentally at the end of the day, I start processing this output, I mean, I’ll just tell it, hey, give me a PDF, right, of the output, and then I’m gonna reprocess that PDF somewhere else. I am bound and determined to get this thing down to like a quarter page of actual text because I don’t wanna read any more than that.

And you know how you get these terrible tech docs that are nothing but warnings for the first 20 pages? All those legal warnings? Warning, if allergic, do not use. Warning, do not walk underneath the unstable whatever because it might fall on your head, you dummy. All those warnings, right? Everybody thinks they’re useless, but they’re in there because somebody at some point said, I’m allergic, but how bad could it be? And they took the pill or whatever. They’re annoying. Don’t serve me. They serve the organization in protecting them from legal liability. So I’m just going to strip them. And if you try to prevent me from doing it, I’m just going to go around you. I’ll flatten it down to something that’s not smart anymore, and then I’ll take them out. 

PB: Right. Yeah.

SO: Now, arguably at that point, you know, when we’re in a courtroom years later, and they’re saying, why did you take the pill that almost killed you? It’s like, well, the docs didn’t say to, well, you know, they did. You went through like eight steps to get rid of that warning. 

PB: Yeah, there’s no liability here.

SO: I know. But the context issue is the thing, right? And the point that you’re making is that if the back-end authoring and governance is good enough, those warnings will make it into the initial output. And I think that’s true, and I agree with that. But fundamentally, and you know, removing warnings is a pretty extreme example, but fundamentally, the end users are basically saying, I don’t care how you package this content and I don’t care why you packaged it this way. I want this at an eighth-grade level instead of a 12th-grade level. I want it in French, and I want it to be no more than 100 words. And at that point, you start to lose information, right, and context. And how do we make sure that that end product is still, I mean, are we going to end up in a place where the AI says, I’m afraid I can’t do that, Patrick?

PB: So, okay, so this is actually a more interesting problem than the warnings piece because in the fact that it is more specific, like it is, it’s a not your problem because what you’re asking the AI to do is you’re asking it to perform one of its core functions, which is summarization. And I do think that you’ll be able to provide AI guidance inside of the content that you have. And now that I’m thinking about this, I’m not going to say for sure that you can’t do this today.

But the point is that when an AI is going and referencing, we’re going to say a procedure, right? If somebody wants, you know, give this to me in a fourth-grade level, and it’s written, you know, at a high school level, that’s a scary situation for sure. But I do think that you’re going to be, you’re going to see organizations being able to say like, you know, this is, this cannot be changed. Like this has to be delivered as… I think there are already some level of guardrails around those things. Again, like when you use good structure to indicate, like these are steps. They have to be reproduced as they are. Like I think the AI systems have been designed to understand that like those are, they can’t play with those because, like, you know, those are specific intentional procedures. But it’d be very interesting to test this. This is not a thing that I have specifically tested. Have you tested this? Are we?

Are you like about to drop a truth bomb on me? You’ve like gone and like looked at like some chemical engineering output and you’ve been like, Hey, give this to me at a second-grade level. It’s like mix the blue thing and the red thing.

SO: Let’s not go down that route. I don’t wanna say that, that we’ve pushed this into failure. But again, circling back to governance, I agree with everything you’re saying around making sure the content is set up in such a way that the AI will succeed. 

PB: Okay.

SO: The most common use case right now for AI is that there’s an AI team being stood up somewhere in the organization, a large organization. And all of that structure and all of that governance and all those attributes and all that metadata that you’re talking about is all in, hypothetically, it’s all in the content. We’ve got like the world’s greatest, you know, structured semantic content. The AI team is picking off the end product PDFs and shoving them into the AI.

PB: Yeah, I… Well…

SO: So yeah, now we’re very sad. like, yes, I agree with all of that. It’s just that the gap right now between what should be happening and what actually is happening, which is we don’t have time to wait for those people and we don’t have time to configure an API to inject, inject, ingest all this stuff, maybe inject.

And you know, we could run it through like an MCP, model context protocol, type of thing and that would make it so much better. But you know what? There’s a SharePoint bucket over here and I’m just gonna like trawl the whole thing and go for it. And I ingested five versions of the same document that are you know, 10, 8, 6, 4, and 2 years old. Yeah, okay, whatever, who cares.

PB: So I believe this is happening because I’ve also seen it.

SO: Did I mention I’m not sleeping?

PB: So I’ll tell you why I am sleeping. So, for one, this doesn’t tend to be my problem. There’s that. I have the really nice situation of being kind of a solution to this problem. 

SO: Mmm! Huh. So you’re saying I should switch sides and get out of services and go over to product. That’s what you’re saying. It’s not a bad idea.

PB: So, you have to, no, I don’t know that I’m saying that, there’s, there’s plenty of other problems in product. So the reason I’m not concerned about this is because most of those projects that I’ve had, you know, a front row seat to fail. And they fail pretty quickly. They tend to fail before they launch, which is good. Actually. It’s really good. because like they’re like, we built this thing with this garbage and we got garbage and you’re like, sweet. So, and because that worked quickly, then they can go and they can do it right.

What I’ve seen, where I believe the future is, at least the immediate future in this is that content teams are going to be responsible for publishing very, very high-quality web materials, like similar to what they’ve done in the past, except better, right? Like has to have semantics, has to have certain aspects of structure, has to be well organized, has to have certain chunking and like all those kinds of things. And the models and the surrounding ecosystems are going to get very good at leveraging those materials. They’re already getting quite good at it. So the impulse for an internal AI team to go and get your PDFs off your SharePoint is going to go down because the barrier of getting information off of your extremely good help site is going to be extremely low. 

That’s going to be the easiest path. And then for the edge cases, when like, let’s say you’re doing post-training on like, like the FinBERT model or something like that, like you’re like building a very specific AI application and you want very specific pieces of information. In those cases, you’re going to have to use an API because you don’t want the whole set of information. You just want the 5% that applies to your use case. So those teams are going to be have to be sophisticated enough to leverage the, either the graph at a granular, like the graph, the structure or whatever it may be, the metadata, the selection mechanism, and then also the structure to like do the filtration to get the pieces they want. So those are the two worlds that I see. I see like very general-purpose stuff and that’s going to be hooked into what’s going to be great for just users anyways, like the better, the more semantic.

PB: The more well-organized your help site is, the better it’s going to be for humans. It’s going to be better for your AI agents, internal and external. And then for the other side of the world, the really, really specific use cases, those teams are going to have to be sophisticated enough to do the really, the deep engineering and concept extraction. so I think what you’re seeing right now is a symptom of just a nascent skill inside of organizations, but I don’t think it stays that way which is why it doesn’t concern me that much.

SO: Okay, well that’s a happy and optimistic world that I, too, would like to live inside. Before, I think that’s actually probably a good place to leave this, but did you have any final closing thoughts, encouragement for people as they’re listening to this ranty, well mostly me ranting, you sounded very reasonable, but do any final parting shots?

PB: Did I? Well, I appreciate you saying I sounded reasonable because I don’t hear that very often. 

SO: Compared to me.

PB: So I do think that profession is changing, and I think the world is moving very quickly right now. And I think that anybody that tells you otherwise is being disingenuous. I think there’s a lot of energy around how it is we leverage these systems and how that changes, you know, our profession is like, you know, content people, whatever portion of the content people you fit into. I personally don’t see the, the general profession going away, at least in our version of the world, like maybe the marketing content, is going to get swallowed a little bit more. I don’t know. I don’t spend a ton of time there.

I see the act of intervention, governance, orchestration, understanding, and coordination in our world as being essential. I haven’t seen anything that has indicated to me that that’s going to go away in the immediate term. And I think there’s a good chance that it genuinely just doesn’t really ever go away. I think it’s something which is going to be critical for the long term. But I do think that people are going to have to keep up on the current state of how we’re working with our tools. And it’s going to be a different pace than it has been in the past. and then I would offer one more warning on that. So one of the things that I see really frequently in our world is the impulse to go and use AI in places that you don’t need to. So a number of people have released like skills libraries, recently for Claude and some of them are really, really well put together. Like they’re really interesting. The people who are releasing them have done an incredible job and service the community by releasing these things. But one of the things that I’ve noticed about them is that a lot of the functionality that’s in these skills libraries that we’re outsourcing or automating with AI, it all works with deterministic systems already. And you should never replace a deterministic capability with an AI capability. There’s two reasons for that. One, it’s more expensive with AI. It may be less expensive to build and procure, but it’s more expensive to run. And the running is the thing that you do for the long haul. So like just on that basis, like you should not replace things that you can do with deterministic system relatively easily with an AI system. But the other thing is AI systems aren’t deterministic. So you’re not going to get the same result every time. 

So if it’s something that is well done in a deterministic way. You should do it in a deterministic way. So there was a package of skills that was recently released that I went and looked at that was, you know, kind of very, very well put together. I looked at the skills and I was like, if you’re using a structured CCMS, like in structured content, you don’t need 95% of these. Like all this stuff just happens. Like it’s all, it’s all solved problems. We solved these problems 20 years ago. Why are we writing skills to do this stuff? Like this makes no sense. So I do think as everybody should be keeping up with the AI, as it is a value-add efficiency improvement in their work, it should also be reasonable about where it’s applied. It’s really exciting and capable in certain places, but it doesn’t mean it’s a thing that should replace everything. There are still the historical tools still work really, really well. And over the long haul, they’re higher quality and lower cost. So that’s my kind of like ending word of warning, which you asked for it by the way.

SO: That sounds about right to me. So Patrick, thank you. And I’m sure this conversation will continue, and we’ll see what happens.

PB: Thanks, Sarah. Always a pleasure.

Conclusion with ambient background music

CC: Thank you for listening to Content Operations by Scriptorium. For more information, visit Scriptorium.com or check the show notes for relevant links.

Questions for Sarah and Patrick? Register for the Ask Me Anything session on April 8th at 11 am Eastern.

The post Who controls your content? AI and content governance appeared first on Scriptorium.

Good content fundamentals have been the foundation of effective product content for decades, and those same principles are exactly what make content AI-ready today. In this episode, Bill Swallow and Alan Pringle explain how attending to your hierarchy of content needs is the key to AI success.

Alan Pringle: Right now, AI is not going to fix bad content problems. It is going to regurgitate that bad information, giving your end users information that’s flat out wrong. If your content at the basic source level is wrong, your AI by extension is going to be wrong. And that is the unglossy, unvarnished, hard truth that is still, I don’t think, seeping in like it should across the corporate world.

Bill Swallow: It really does come back to the fact that, despite the world changing on a day-to-day basis, the fundamentals have not changed.

Related links:

A hierarchy of content needs

Technical Writing 101, 3rd edition

Structured content: a backbone for AI success

LinkedIn:

Alan Pringle

Bill Swallow

Transcript:

This is a machine-generated transcript with edits.

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky; you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and processes that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Bill Swallow: Hi, I’m Bill Swallow.

Alan Pringle: And I’m Alan Pringle.

BS: And in this episode, surprise surprise, we’re going to talk about content.

AP: Really? Who would have thought?

BS: But more specifically, what good content means today. Today, everything is all about AI. There is lots of change in progress with regard to AI tooling and content delivery with AI. But have the needs for content really changed? And I would say that off the bat, if you’re doing content right, you really don’t have to reinvent the wheel to make it AI acceptable.

AP: No, in this crazy AI-hyped world we’re in, there’s some very basic foundational things that tend to get overlooked because they’re not sexy, and they’re not special and hot and whatever else. All that kind of marketing garbage that just sets me on complete edge and makes me want to say profane things in podcasts. 

The bottom line is, there are things that the content world, and especially our little subdomain of it, product content world, has been doing for decades now. And I mean decades. 

BS: Or should have been doing.

AP: Correct. There are basic tenants that have been in place for decades. That if you’re following them, you are starting down the road of success with AI. I think to kind of prove our point, we’re going to step back and look at some of the things that Scriptorium has talked about and written in the past and see how it stacks up. And Bill, you found one. And let’s talk about that blog post that Sarah O’Keefe wrote. What was the date on that again?

BS: It was 2014. And that is when we came up with the hierarchy of content needs. And it really wasn’t so much an invention as it was just a regurgitation of what it means to create good content. So we have a pyramid of content needs. At the bottom, we have available. So is content available? Does it exist? Can someone get to it? I think that we’ve mostly solved that problem given the dearth of information we have out on the internet. But as we know, that information is not always useful. So we go up a rung or a layer on that pyramid and see whether or not the content is accurate.

And if it’s accurate, if it provides the correct information, that’s fantastic. Then we go up another level and see whether or not the content is actually appropriate. So it can be correct. It can exist. But is it appropriate? Does it meet a reader’s needs? And is it formatted in a way that works for the reader to ingest?

Then we go up a step further and see whether or not the content is connected. And this is where we kind of get to the more modern aspect of content. Does it link out to correct additional resources? Is it available to people in a variety of means? And does it engage with the audience?

And then finally, at the top of the pyramid, we have intelligent content. Is the content intelligent? And we’re not talking about AI here at all, but we are really talking about is the content fashioned in a way that it can be used intelligently across different media?

AP: That it can be manipulated for different purposes. And that is quoting Sarah directly. And I think that is key here, because that is what AI does. It takes information and basically chops, slices, dices it, and provides it in a new way via a chatbot, for example.

So that is that whole manipulation that Sarah is talking about. And we will post a link to the post in the show notes so you can read this at a greater detail to see how well this hierarchy of content needs has stood up. And she even talks about, for example, integrating database content, how you can pull in other information product specifications.

If you think about it from an AI lens, I think that parallels pretty closely to the idea of retrieval augmented generation, where you are pulling content from other sources and kind of weaving it in with what an AI engine is providing you. So RAG is, I think, could be kind of interpreted as another way of integrating other information into the way that AI is processing that content.

BS: Right, mean, because AI, I mean, it’s not really an audience, but it is a delivery point. There are some structural needs that need to happen there. But ultimately, you’re still writing for people. You might be writing in a way that it allows the AI to repurpose and refactor the information so that the audience gets exactly what they’re looking for. But it still needs to be somewhat tailored to the needs of people because AI in itself, it doesn’t care what the content is, but it’s going to try to produce something for an eventual person to be able to read.

AP: I think that then in turn points to something else in our vast compendium of Scriptorium content. And that is a book that Sarah and I wrote, the first edition in 2000, which just kind of makes me shake my head. I know this is not a video podcast yet, but I’m shaking my head in disbelief. The book, Technical Writing 101, has three editions, published between 2000 and 2009. We will put a link in the show notes. You can still download the third edition. And by the way, it’s free. You can get a PDF or EPUB. It’s free. You can get it from our store with some more recent resources from the store. 

But to me, I flipped through that book this morning. And I was genuinely surprised at how much of the advice on how to create good product content still is true in this AI era. Everything of talking about modular, writing things in a modular way, being very systematic and structuring things, even if you’re not using a structured authoring tool, use a template, make things very standardized. These are all things that, yes, they make for better, consistent, standard, tech-com, product content for the person reading it. But let’s pretend like AI is the person reading, and I’m doing air quotes here, reading it. It is going to do a better job of understanding, again, I’m sort of personifying here, and I know that’s sort of a no-no.

But if you feed AI, a large language model, content that is very structured, that is very templatized, that is standardized, that is in bite-sized chunks, and also, this is very important, the idea of metadata, which we do talk about in that book briefly. We do talk about it. Because you need to be able to label it for different audiences, because I’m thinking about someone sitting, trying to use a product, trying to use a piece of software, talking to a chatbot. And the chatbot is going to ask it, what product are you using? What’s the model number? All of those kinds of things. And now we’re getting to this whole idea of labeling and breaking things apart so that a chatbot, just like a user of a product.

Let’s say somebody has a printer that’s on the highest end of the scale. They’re going to have a lot more features that apply to their model than to someone who bought a more basic one. But the thing is, if your product content has not clearly labeled what are features in each of the models, the chatbot is going to spit out the wrong thing. So again, this idea of breaking things up in discrete chunks and labeling them in a way where someone who wants specific information about a specific model, they can get it. And it doesn’t matter if it’s from a web page, it’s from a PDF, a printed book, God forbid in 2026, or from an AI chatbot. Those rules still apply. Those fundamental principles are still there.

BS: Mm-hmm.

AP: I think one of the biggest problems here is when people do not have those fundamentals already in place, right?

BS: If they don’t have those fundamentals in place, they can’t get to the top of that pyramid that Sarah was talking about. And really those fundamentals are those first three layers. Content is available, content is accurate and content is appropriate. If you can actually nail those three layers of the hierarchy of content needs, you are set to then jump to connected and intelligent fairly quickly because your content is already well written, standardized, and appropriate for different audiences.

AP: So we’re right back to talking about the way you put content together, your content operations, and how you have to have these fundamental principles basically embedded in your processes to create that content that goes up all the way up to the hierarchy, the very top of the hierarchy of need pyramid. 

So then that begs the question, what is going to happen to your AI if you don’t have those fundamentals in place, if you aren’t all the way up that hierarchy of content needs? I’m afraid to tell you your AI is going to fail. And this is something that I’ve said often, but it bears repeating because it is clear. Unfortunately, a lot of people high up the corporate food chain do not understand this. 

Merely slapping AI on top of content that is fundamentally outdated and incorrect. Right now, it is not going to fix those problems. It is not magically going to fix them because what is AI going to do? It is going to regurgitate that bad information, acting like it’s knowing what it’s talking about until your end users very definitively that you need to do this to make this happen and it’s flat out wrong. And again, right now, AI is not going to be able to fix that right now. One day it may be able to, but right now, if your information, your content at the basic source level is wrong, your AI by extension, is going to be wrong. And that is the unglossy, unvarnished, hard truth that is still, I don’t think, seeping in like it should across the corporate world.

BS: It really does come back to the fact that, despite the world changing on a day-to-day basis, the fundamentals have not changed. Nothing is new.

AP: No, no. And if you have an AI initiative and you are part of the content world and your content operations aren’t up to snuff, this is a way to get funding to get your content operations up into the 21st century. And I don’t want to say that as and sound glib and dismissive, but by the same token, I know for a fact there are a lot of companies out there who are still serving up their content locked up in PDFs that may be online. That is not going to fly. That does not follow. It doesn’t go high up the hierarchy of content needs, if you want to look at it from that perspective. So it is time to break free of this idea of you present content in a particular way.

And you have to look at content as something that is basically, it’s a commodity, it’s data that AI is going to manipulate and do whatever to to meet the needs and the wants of the people who are using the chat bots and other agents that are accessing that large language model.

BS: And I think that’s a good place to leave it. Thanks, Alan.

AP: Thanks, Bill, short and sweet, but needed to be said.

Conclusion with ambient background music

CC: Thank you for listening to Content Operations by Scriptorium. For more information, visit Scriptorium.com or check the show notes for relevant links.

The post Good content = good AI: The fundamentals that never change appeared first on Scriptorium.