Find partners
Content Operations

Content Operations

Hosted by Scriptorium - The Content Strategy Experts

BusinessInterviews guests

Episodes

201

Latest episode

Aug 2026

Language

EN-US

About the show

The Content Operations podcast from Scriptorium delivers industry-leading insights for scalable, global, AI-optimized content.

Listen to episodes

60 recent
August 3, 202622 min

Digital sovereignty in the age of AI

Are you in control of your digital destiny? In this episode, Alan Pringle and Sarah O’Keefe define digital sovereignty. They break down what organizations need to consider as they bring AI into content operations, from data leakage and competitive intelligence to shifting international regulations. Sarah O’Keefe: The working definition that I’m using is that digital sovereignty is control over your own digital assets, digital destiny. That could be you personally, it could be you as an organization, or it could be you as a country or as a group of nations. And when I say group of nations, probably 98% of the time I’m talking about the EU, which has some laws in this regard. Digital sovereignty is your ability to control, own, and manage your digital assets and how they are used, reused, processed, resold, repurposed, and all the rest of it. Related links: AI in the content lifecycle: three years later From ad hoc to autonomous: The AI content ops maturity model Upcoming AI book: The Uninvited Author LinkedIn: Alan Pringle Sarah O’Keefe 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 AP: Hey everybody, I’m Alan Pringle. SO: And I’m Sarah O’Keefe, hello. AP: Hey there. And today Sarah and I want to talk about something that’s really starting to come to the forefront with all of the AI things that are going on in our world. And that is digital sovereignty. And before we get too deep in that, I need to throw up many, many disclaimers. Sarah and I are not lawyers, nor do we play them on television. And we are absolutely not lawyers or experts on anything in regard to international intellectual property. So with those disclaimers out there, Sarah, if you would, would you define what digital sovereignty is? SO: The working definition that I’m using is that digital sovereignty is control over your own digital assets, digital destiny. That could be you personally, it could be you, the organization, or it could be you as a country or as a group of nations. And when I say group of nations, probably 98% of the time I’m talking about the EU, which has some laws in this regard. So it is your ability to control, own, and manage your digital assets and how they are used, reused, processed, resold, repurposed, and all the rest of it. AP: And I’m going to give a very basic example from my personal life in regard to email. Years ago, actually decades ago, when I got set up with an internet service provider, they provided me with an email address. It had their company name in the domain.com. And I used it for years. But when I switched my ISP, guess what? I had to make a decision. Do I continue to pay that old ISP, basically rent, to maintain that old email address? Or should I move to one of maybe the free email providers? So I did a little research, and my ultimate decision was I created my own domain with my name, and I kind of just decided not to ever use again the email provided by an ISP because if you switch it, you’re going to possibly lose control of that email address. And at the time that I made the switch, a lot of the free providers, they would scan your email to provide targeted ads and some other things that was kind of unsavory to me. So I ultimately made the decision I was going to own the domain and set that up myself and pick my own software that I hooked up to it to use to to read it. And I did not use a third-party email provider to basically pull in or reference my account. I am using an open-source standalone email client to kind of minimize who can poke into my email. So that’s one very basic example of how I kind of took control of my digital life as it were. SO: Right. And if we apply that to content ops, again, staying pretty general, you think about cloud systems, like the cloud universe versus on-prem. AP: Yes. SO: And when you talk about, let’s say, a CCMS, a component content management system that is on-premises, the the argument was always, well, that way all of our content lives on our servers, in our organization, we have complete control over it. Along come the cloud services, the cloud-based CCMSs and everything else. And they say, well, yes, but it’s much cheaper for you to put this into the cloud on our systems, which are shared. And you know, there’s advantages of upgrading, and there’s all sorts of advantages to cloud systems, mostly around IT overhead. from a digital sovereignty point of view. You are delegating to that cloud system and you have some sort of a contract or a service level agreement. And again, we are not lawyers, but you have this agreement that says we the cloud provider promise to not scan your information or not use it for evil or not, you know, there’s a bunch of stuff in that contract that governs how cloud provider is or is not allowed to handle your content, your personal information, your credit card information that you might be putting in there and all the rest of it. And with software as a service, with cloud systems, we have for the most part cut over into cloud. You know, that’s that’s kind of the default these days. There’s hardly anybody that is still putting their content, their content and their content management systems on their own proprietary in-house servers. AP: Yes, correct. SO: So we have decided that for cloud, you know, cloud writ large generally, that the advantages of cloud outweigh the disadvantages. Now, moving this a little bit more towards content and slowly towards AI, where things get really interesting with digital sovereignty, if we talk about machine translation for a minute. There are a couple of different ways of doing machine translation, obviously, but big picture, you can have your in-house machine translation system and database, and you can control that and govern it and do things with it. Or you can take your content and you can throw it at a public-facing machine translation system. And the risk that you run when you throw something at a public system is that they will take your proprietary confidential content. And use it. So I throw at it a sentence that says, the XYZ company has developed a special new thing, right? And I need that translated into various languages and I get it translated. But as a result of that, I am leaking information. I am leaking my confidential, potentially information into the machine translation services. And there are some really interesting security issues around that and how you might be able to. As a competitor, extract that back out. But just dialing it back for a for a minute, we understand the concept of leaking information by using public-facing machine translation, right? Publicly available machine translation. But one thing that I think is very often overlooked is that machine translation, the fact that I ask for a specific language, never mind the content, But the fact that I am now asking for a new language provides competitive intelligence in the sense that that means that I or my organization now cares about that locale, that that language. So let’s say that I’ve been consistently submitting European languages for machine translation, right? If you but if you look at my record of what I’m asking for, you will see that all of a sudden, about three months ago, I started adding a bunch of Asian languages. Well, what does that tell you about what I’m up to? Either I’ve decided that Asian languages are interesting and fun, or my organization, I mean, presumably I’m doing this for work and not fun, or my organization is launching into Asia. And I don’t actually need to see the content to sort of get that piece of competitive intelligence out of it. So essentially. The way that I’m using the machine translation, even if we protect or have a contract that says you you are not allowed to look at what I’m processing, but if you can look at the parameters of what I’m processing, that might give you enough information to tell you something about what I’m up to. AP: Yeah, so basically what you request or don’t request, as the case may be, can give away clues that you may not want floating out in the world. SO: Right, exactly. So now we take this to AI and we think about digital sovereignty for AI, and it gets very much more complicated. So t first, taking this example of machine translation, if you think about AI chatbots and prompting and public-facing models, then in the same way that requesting a particular language so well, let’s back up. Let’s say that we have a contract with XYZ model provider and it says we will not use your input as training data. We will not use your output as training data. Cool. But are you going to use my prompts as competitive intelligence? Because think about what I’m prompting on. Hey, tell me about the intellectual property laws in Vietnam. Tell me about how to go to market in a particular country. Tell me about strategy for pricing tiers, right? If I’m doing those kinds of prompts, then you, as my competitor or adversary or whatever we’re dealing with here, can get an awful lot of information out of what I’m up to, right? You can figure out what I’m up to just by looking at my prompts. So we have to worry not just about the protection of the input and the output, but also the actual prompting that I’m using to get the inputs and the outputs, because the prompting itself has competitive information in it. So then when we start thinking about digital sovereignty, you say, okay, well, then what we should probably do is have a restrictions on usage of input, output, or prompting data by the vendor, right? The vendor who’s providing the AI model should have a contract that says we are now not allowed to use this stuff. But then we take that another step forward. Nearly every contract I’ve seen in the past, you know, whatever years, decades says we promise not to use this unless we’re required to by law. So in other words, if a government subpoenas us, we will cough up this information as we are legally obligated to do, that sends us right down the road to something called zero data retention. Which is the idea that you process your AI prompts in such a way that they are not retained, that the inputs and outputs are not retained by the provider, so that if they are subpoenaed, they cannot in fact cough up the information because they don’t have it. And then if you’re more paranoid than that, and some of you, you know, depending on what industry you’re in, should be, you start thinking about bringing the model in-house. So instead of using public-facing with a an enterprise contract of some sort, you think about bringing the model onto again, in-house on premises in the same way. This is right back to cloud versus not cloud. And then we have some questions about what model are you using and do you know what’s going on in the internals of that model, which points you maybe at using something open source or maybe not. It depends. But there’s all these layers of decisions that you have to make around how you’re going to use AI and how concerned you are about leakage from your use of AI to you know your competitors or something else. Now, over the top of that, we start thinking about nations rather than organizations. And we have some of this with just generalized cloud systems. GDPR, the European Data Protection Regulation, says a lot of things about how you process personal information and what the requirements are and what you are and are not allowed to do. Now If you’re a European company inside the EU, you’re clearly subject to GDPR. But many non-European companies are also subject to GDPR because you have a server in the European Union, or you have customers in the European Union, or you operate in some way in the EU, which then that’s enough to have you sort of folded into GDPR. On the AI side, we have something very similar going on where companies are looking at AI models and making decisions based on what jurisdiction does that model belong to. Now, the most prominent of these is that, for example, currently, as of right now, as we’re recording this, the American models, like a ChatGPT, a Claude, that kind of thing, are largely not available in China. and it’s a little bit tricky in terms of is it actually banned or is it just restricted, but broadly not available. The Chinese models are available in the US and are open source, but if I’m an American or actually, let’s say I’m a European company and I’m trying to figure out my AI strategy. Do I use an American model? Do I use a Chinese model? What happens if I’m using a Chinese model and then the US government bans that model in the US and I have operations in the US? And I’m suddenly now what? In reverse, if I’m a an American company and I’m using American US models, and I have, let’s say, a chatbot, and I go to market in the EU. I am now subject to the EU AI Act. And the EU AI Act, with some complications for when it goes into effect, et cetera, has rules that say things like: if you put up a chatbot, you have to disclose that it’s AI. You can’t pretend that people are talking to a human. You have to say this chatbot is AI. This image was generated by AI. there are disclosure requirements in the EU. That are much more stringent than the disclosure requirements, which are none in the in the US. AP: Yeah. In the US. And again, if you were making decisions about what model to get, where you should place your servers, etc., we highly recommend that you speak to your intellectual property attorneys and do not take advice from the two of us. Thank you very much. SO: Right. This entire podcast is just an ad for IP lawyers. You’re welcome, IP lawyers. AP To me, this whole thing is so interesting. You know, we talk about the digital world and globalization and you know, there’s no boundaries anymore. Guess what? They very much apply here because, like you said, if you have customers in the EU, and you may be a US-based company, but that does not give you clearance to absolutely ignore GDPR. So we still have to be aware of geographical boundaries and the laws of all the nations inside those boundaries. SO: Yeah, the thing that keeps me awake at night is the question of what if I build out an entire thing on some model? It it kind of doesn’t matter which one, but I build an entire infrastructure based on some AI vendor and then and then that AI vendor gets banned by a government whose jurisdiction I or my operations are subject to. AP: But there are significant costs. SO: Right. And I’m not picking on any particular country. It it could go every which way that you can imagine. So then as a as an organization, especially if you’re a big international organization, you start thinking about well, maybe we should bring all this stuff in house so that we can control it. AP: And infrastructure involved with that decision. SO: Right, because now we’re talking about you operating your own data center, and that makes you, you know, not so beloved by literally anybody. So I mean, this is a really hard problem. And what’s fascinating to me is that we generally in software, software as a service, generally cloud has pretty much won with some minor exceptions for air-gapped systems, high security systems, network operations centers, or you know, software that runs utilities, that kind of thing. Things where you really, really, really do not want it taken down by external things. So you have this idea of secure systems, air-gapped systems, systems down at the bottom of a mine that are cut off because they’re literally down at the bottom of a mine. AP: Yes, inside the earth, correct. SO: We used to talk about airplane help, but that’s much less of an issue anymore because now, for better or for worse, we have Wi Fi on the planes. AP: Yes. SO: Mostly for the worse. Anyway… AP: At least I haven’t heard a meeting yet, an online meeting. I’m sure it will happen at some point, but I have yet to see that happen. Thank goodness. SO: On a plane? Yeah. Hmm. AP: Yeah. SO: So anyway. So cloud, the risk-reward for cloud versus on-prem has pretty much tilted towards the cloud systems in general, with you know, very specific kinds of exceptions for I would say unique use cases, but it’s kind of like a ninety ten or an eighty-twenty kind of split. Back in the day, it was everything was on-prem and cloud was the exception, but it’s it’s very much shifted. And now with all this AI stuff, everybody’s using currently big picture. As everybody’s adopting AI, they’re using public-facing models, public-facing chatbots, maybe with like some sort of an enterprise license. But I just have this feeling that a lot of this stuff is going to be brought into in-house at least managed models. AP: Exactly. Yeah. SO: So still sort of cloud software as a service, but with a big enterprise contract wrapped around it that says, here’s what you you, the vendor, the AI vendor, can and cannot do with our data. But it’s a it’s just a really interesting problem because we in content we don’t deal with these sort of national issues that much, like sovereignty at the national level. And I think that with AI systems, we’re seeing a lot of concern around, well, what does it mean that this might be regulated differently in different countries? And how do we manage that? I mean, how do you put together an AI content ops strategy if you are not sure whether your model will be available in that country over there next week. AP: Yeah, and I’m just thinking, think about audits are often a component of a contract, and you add AI on top of this, and all of the jurisdictional things you’re talking about, all of the facets of those audits just got even more complicated with AI than they already are, which that is probably a whole other discussion. Again, not a lawyer, don’t want to be, but I can see that being a very contentious something that’s gonna have to be ironed out in the very near future. SO: Yeah, so digital sovereignty, it’s it’s very hard to say and even harder to spell. but I think that it’s something that we should be thinking about as content people and we should at least understand the big picture of what’s going on so that when we go to our corporate legal team and say, Hey, we’re worried about this, we can at least have a reasonable conversation about where this is going. AP: And again, we don’t know where it’s going, but it’s definitely something to keep an eye on. This is a great place to wrap up. Sarah, thank you very much for a conversation that I frankly haven’t heard a lot about in the content world. SO: Well thank you. Not a lawyer. AP: Nor am I. Until the next time everyone, thanks. Bye. SO: Bye everybody. Subscribe to our monthly newsletter for more insights on AI, content ops, and more! var gform;gform||(document.addEventListener("gform_main_scripts_loaded",function(){gform.scriptsLoaded=!0}),document.addEventListener("gform/theme/scripts_loaded",function(){gform.themeScriptsLoaded=!0}),window.addEventListener("DOMContentLoaded",function(){gform.domLoaded=!0}),gform={domLoaded:!1,scriptsLoaded:!1,themeScriptsLoaded:!1,isFormEditor:()=>"function"==typeof InitializeEditor,callIfLoaded:function(o){return!(!gform.domLoaded||!gform.scriptsLoaded||!gform.themeScriptsLoaded&&!gform.isFormEditor()||(gform.isFormEditor()&&console.warn("The use of gform.initializeOnLoaded() is deprecated in the form editor context and will be removed in Gravity Forms 3.1."),o(),0))},initializeOnLoaded:function(o){gform.callIfLoaded(o)||(document.addEventListener("gform_main_scripts_loaded",()=>{gform.scriptsLoaded=!0,gform.callIfLoaded(o)}),document.addEventListener("gform/theme/scripts_loaded",()=>{gform.themeScriptsLoaded=!0,gform.callIfLoaded(o)}),window.addEventListener("DOMContentLoaded",()=>{gform.domLoaded=!0,gform.callIfLoaded(o)}))},hooks:{action:{},filter:{}},addAction:function(o,r,e,t){gform.addHook("action",o,r,e,t)},addFilter:function(o,r,e,t){gform.addHook("filter",o,r,e,t)},doAction:function(o){gform.doHook("action",o,arguments)},applyFilters:function(o){return gform.doHook("filter",o,arguments)},removeAction:function(o,r){gform.removeHook("action",o,r)},removeFilter:function(o,r,e){gform.removeHook("filter",o,r,e)},addHook:function(o,r,e,t,n){null==gform.hooks[o][r]&&(gform.hooks[o][r]=[]);var d=gform.hooks[o][r];null==n&&(n=r+"_"+d.length),gform.hooks[o][r].push({tag:n,callable:e,priority:t=null==t?10:t})},doHook:function(r,o,e){var t;if(e=Array.prototype.slice.call(e,1),null!=gform.hooks[r][o]&&((o=gform.hooks[r][o]).sort(function(o,r){return o.priority-r.priority}),o.forEach(function(o){"function"!=typeof(t=o.callable)&&(t=window[t]),"action"==r?t.apply(null,e):e[0]=t.apply(null,e)})),"filter"==r)return e[0]},removeHook:function(o,r,t,n){var e;null!=gform.hooks[o][r]&&(e=(e=gform.hooks[o][r]).filter(function(o,r,e){return!!(null!=n&&n!=o.tag||null!=t&&t!=o.priority)}),gform.hooks[o][r]=e)}}); Name * First Last Email * Data collection * I consent to my submitted data being collected and stored. Review our privacy policy Consent to subscribe * I consent to the use of my submitted data for marketing emails. I understand that I can unsubscribe at any time. Review our privacy policy Submit The post Digital sovereignty in the age of AI appeared first on Scriptorium .

July 13, 202622 min

The debt crisis: AI edition

What happens when you feed years of messy content into AI? In this episode, Bill Swallow and Alan Pringle dig into the content debt crisis, including increased system costs, neglected localization, and the fallout of “just use AI” mandates. They share practical insights to help organizations get back on track. Alan Pringle: Is your content updated? Does it reflect the latest information? Is it created for all the different locales that your company serves? Is it in different languages? That is another pile of debt that when you start looking at AI, all the problems will be very brutally magnified, and you’re going to have to address them to really have a large language model that works at all. Related links: Balancing automation, accuracy, and authenticity: AI in localization (podcast) Forbes: AI Costs More Than The People It Replaced Taming AI: Using AI for content conversion at scale (podcast) LinkedIn: Bill Swallow Alan Pringle 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 Bill Swallow: Hi everybody, I’m Bill Swallow. Alan Pringle: And I’m Alan Pringle. BS: And today’s episode is going to focus more on the content debt crisis, AI edition. AP: And it’s also going to be the complaint edition, surprise, surprise, because there’s a lot of things in the AI world right now that are still making me cranky. And I am sure we will talk about them at some point. BS: Yeah. So with the rise of AI, I think it’s kind of holding a microscope to a lot of the technical debt that we’ve been seeing over the years in content operations in general, whether you have outdated authoring formats or content that’s not being updated on a regular basis, new delivery formats not necessarily meeting the needs of the users, and so forth. And all of that is kind of compiling or snowballing into a bigger problem once you start feeding all of this stuff into AI. AP: Right. And it’s interesting to me how everyone’s talking about AI as being this productivity tool. In a lot of ways it is, but that’s not what the focus of this is. In a way, it is also sort of a consultant for you. As you just mentioned, Bill, when you start looking at AI and delivering it, treating it as a delivery endpoint for your content, a distribution endpoint, you are going to start to discover that your processes on the back end for creating and distributing your content are not what they should be. So it’s kind of like this consultant saying, Hey, you need to do better over here. And that is where a lot of this debt is coming from, from my point of view. BS: Mm-hmm. The unfortunate part of that consultant is that it’s not offering advice on how to fix it, but it certainly is pointing out the issues. AP: It’s like, “This is screwed up. Full stop.” So, I mean, part of why we’re here is to talk about some of those kinds of debt. And let’s just start with one technical debt. And I’m saying technical in the sense of the way that you perhaps use software to put together your content. Let’s kind of focus on the content operations world. BS: Mm-hmm. AP: For example, if you are delivering content via unstructured desktop authoring tools, of which there are many, and you can templatize things and make your content seem more consistent, but there’s a problem with a lot of desktop published or content generated from the desktop publishing world. It’s more focused on look and feel and fit and finish, particularly if you’re delivering for PDF. And yes, people are still doing that. So there’s a lot of time and effort spent on that look and feel, that fit and finish. And frankly, that time should have been invested in adding intelligence to the content to explain, you know, things under the covers about w hat user is this for? What is the model of this particular thing? All of that kind of metadata, that kind of categorization. Desktop publishing, at least from my point of view, doesn’t really do a great job of helping you catalog that kind of stuff. So that’s a problem. BS: No. It is a problem. Also, with desktop publishing, you can kind of confuse AI a bit if you’re using desktop publishing inconsistently. So if you’re using formatting tools to override formatting to make things look like headings or make certain paragraphs look like children of another paragraph, doing those manual finesses is great for print because, as you know, most people will look at that and understand the hierarchy of information, understand what’s going on with the content that they’re reading. But anything digital isn’t necessarily going to pick that up. AP: Right. Yeah. BS: Especially if you’re looking at something like bare bones HTML, if you’re using CSS to override the size and prominence of a standard paragraph as opposed to using a heading, that is not necessarily going to be picked up as a heading, even though a reader would actually see that as a heading while looking at the HTML page. AP: Right. What a human reader can figure out from formatting cues, if those cues aren’t set up in a way that a large language model, a computer, can understand, there’s that huge disconnect, and that’s where that debt starts piling up. And then another angle here in this content creation world, if you are using multiple different tools to create your content, there’s a good chance that content under the covers is not going to be processed the same by a large language model. So there’s another deficiency right there on top of that. And this is very common, for example, if you have had mergers, acquisitions, and you’ve basically created a larger company from many different companies. And they all still have, especially in legacy content, things created the “old way,” and all the old ways start to pile up and cause problems because your large language model can’t properly basically figure out what is the heading in this particular chunk of docs versus what it is over here. So it can’t parse it as well. And again, this all goes all the way back to the way that you created that content. And it’s a clue, hey, you need you need to fix this. And I I think beyond that more technical, the way that you create it, there also there are also issues with the content itself. BS: Mm-hmm. AP: Is it updated? Does it reflect the latest information? Is it created for all the different locales that your company serves? Is it in different languages? That is another pile of debt that when you start looking at AI, it’s gonna be all the problems in regard to that are also gonna be just very brutally magnified, and you’re going to have to address them to really have a large language model that works at all. BS: Yeah, because not only do you have the technical debt on the source content side and on the published content side, but you also now have technical debt growing on the AI side because you need to spend more time and energy refining the how that model works with your content in order to achieve the correct results. AP: Right. So you’re having to do a lot of overrides and we I don’t know if overrides is the right word, but you’re having to do a lot of additional processing and figuring out so it will parse things correctly. And there are a lot of companies today that still have problems keeping content updated to the latest and greatest. So unfortunately, people turn around and call support. Or today they start hitting up the chatbot. But guess what? BS: Mm-hmm. AP: If the chatbot doesn’t have access to the latest and greatest because frankly it doesn’t exist or it’s not hooked up to it. It’s it’s just like the poor people in support. It’s not going to know what to do and it’s going to spit out probably very authoritatively wrong outdated information. Again, yeah, it’s be it’s goes all the way back to BS: That’s yeah. AP: In your content creation process, how are you accounting for updates? How quickly are you getting them in place? How are you handling them in both your source language and how are you handling them in your other languages? It’s one thing I do want to bring up here, and and and I may be biased here, but I don’t think localization is getting enough attention on the AI distribution side. It’s been talked about for a very long time in regard to machine translation, AI assisted translation. BS: Mm-hmm. AP: But I don’t just like I think sometimes localization is a second thought for a lot of companies, which still blows my mind in 2026. And by the way, we’re recording this in July 2026. So what we say right now may be outdated next month. Who knows? BS: Who knows? AP: There is that issue. I’m curious, you have a more of a localization background than I do, but I do see that being a potential debt problem, part of this debt crisis that we’re talking about here. BS: Definitely, because if you’re pushing your content out to AI, do you have targeted audiences in mind? Or is it going to be a free-for-all of people going in and using that AI to get answers to their questions? if you are localizing your content, I think probably the best practice here would be to somehow bundle for consumption all of the guides in all of the different languages together. So you have product XYZ and you have it translated in three languages. Then you put all of those copies together and give that to the AI so it can draw its associations as well as it builds out you know its understanding or I hate to use understanding because the AI doesn’t understand things. It’s very easy to make slips in that way. But so that AI can actually draw those relationships. So, you know, if you’re looking in English or you’re looking in Spanish or you’re looking in German, the same query in those three languages will retrieve pretty much the same result. That’s proper for that language. And we talked with someone last year on the podcast, Steve Maule from Acclaro, about AI in translation. AP: Yeah. BS: And his focus was more on using AI as not so much a generative tool, but you know, a tool for aiding in AI, basically the next step from machine translation to neural machine translation to AI translation. And kind of the benefits and drawbacks at the time. Again, that was a year ago. So many of these things have probably changed again. But if you are translating content you may want to go back to that podcast and take a listen to what he had to say. and we’ll put a link to that in the show notes for this one. AP: Yeah, again, I keep going back to this idea that we talked about at the beginning, how delivering via AI just puts this magnifying glass to what you’re doing and uncovers things that are wrong. But as you had mentioned, it doesn’t necessarily offer advice on how to fix it. And we will talk about that probably to wrap up the podcast. But what I also want to mention too. More and more, there’s actual real debt involved, not just the more indirect debt we’re talking about with the content debt, the technical debt. The AI companies, the providers, at one time had very generous offerings as far as the amount you could hit their APIs, the amount of tokens that they offered, whatever else. BS: Definitely. AP: But now, the days of I guess you could say subsidized token use, they’re pretty much over. And now the actual real cost is being passed on to the people using these large language models. And as a result, the actual price, the cost of using AI is skyrocketing in all these organizations. And there have been a lot of news reports lately about very BS: Mm-hmm. AP: And there have been a lot of news reports lately about very big firms, and I will not name names, but you know them all, their household names, basically having to do a 180 and tell their employees, hey, you need to chill a little bit on your AI use because you’re burning up the tokens, converting PDF files to PowerPoint. And yeah, I get it. BS: Mm-hmm. AP: Doing that conversion is probably not the most efficient use, productive use of AI tokens. But this gets into kind of, I don’t know if there’s such a thing as cultural debt, but if your company is sending this message, and a lot of companies are, use AI for everything. And you know, they’ve got these leaderboards up showing these people use this much AI this week, you know, that sort of thing. You are encouraging a free-for-all. So, instead of saying, here are the good uses, this is where we think you need to focus your use of AI in coding, in content creation, in whatever else, this whole idea of just use it. You got to use it a lot. And now that’s coming back and biting people in the backside. So companies are scrambling and telling people, calm down. BS: Mm-hmm. AP: Chill out. Don’t use the AI as much. So it, there’s a mixed message there. And it’s because there was not good communication, nor was there good thought put into how workflows should incorporate AI. And I think that cultural thing right now is a huge problem. And everybody’s focus on the cost and the non-subsidized token use when they need to be going back and looking at, well, look at your comms. Look at what you were telling people six, twelve months ago about AI. It’s kinda on you. BS: Mm-hmm. Yeah, basically don’t let your nine-year-old run around in a toy store with your credit card. AP: Yeah, pretty much. BS: That’s pretty much what’s been happening. And yeah, we’ve been seeing lots of reports. There was one in Forbes last week, where, you know, companies are saying that the cost of using the compute power is more expensive now than the people it was supposed to augment. AP: Exactly. So I think the reality of what AI can do maybe is starting to sink in, maybe a little, but at least exposing people to the true cost of it on a corporate level, it may BS: Mm-hmm. AP: I’m probably being too positive here. What? Me being positive? It may result in some recalibration about how companies are telling people to use AI and maybe thinking a little more on a cultural level, all the way starting with communication. Here are the workflows you need to apply AI to. This is where you can apply it. BS: Mm-hmm. AP: And then there’s also the whole vibe coding discussion. I don’t know how much we want to get into it, but we all know, right, there is now an industry, you know, people are now going in to clean up vibe coding because, yeah, just because you can vibe code shouldn’t mean doesn’t mean you should be vibe coding. Because who was going to maintain and clean up that mess? So again. BS: Well, we’re cleaning up a lot of vibe coding now. AP: It’s another cultural issue that should have been addressed, but in this AI rush, everybody was like, use it, use it, use it, without thinking about how they should really how they should really apply it and basically sort of reimagine the way they do work in a productive way. And that does not mean let the AI do everything from my point of view. BS: Mm-hmm. AP: So I guess we probably need to kind of wrap up and talk about what people can do when all of their ugliness is amplified and magnified by AI. And it really it’s about rewinding and going back and looking at from the start, especially in the content world and the content operations world, how are you creating that content? Are you doing it in a consistent way? Are you building in intelligence into your content that an LLM can pick up to better understand the context of that content you’re providing it? Is your localization workflow efficient? Is it getting content turned around quickly so people in other markets are not six or eight months behind in the latest and greatest information. And by the way, yes, that still happens today, believe it or not, that people are months out and getting it because they are in another location. It’s shameful, but it still happens. It does. BS: Mm-hmm. Yeah. And there’s also, you know, how are you feeding your content over to AI? How are you providing it? Are you just having the AI team you know scrape web pages and PDFs, or are you supplying something that’s a little bit more targeted and tied to the content itself, and maybe supplies some of that intelligence over? AP: Yeah, because I think Sarah’s talked about this on a previous podcast. A company was noticing that their LLM was kind of not using PDFs or not weighing them, or and I’m again I’m personifying big time here. my apologies. BS: Yeah. It’s easy. AP: Was yeah, was not really it was not giving the weight to the content in PDFs. And when the company kind of did some reverse engineering, they realized it was because that PDF what they didn’t have a lot of context. BS: Mm-hmm. AP: There wasn’t a lot of basically metadata built in that the LLM could basically parse. So it’s like, I’m gonna kind of put that to the side because it doesn’t have the richness that I need to do things well. So it it’s about looking at how you write. How are you delivering this content? And one possibility here, and it’s, well, there’s several structured content where you have metadata built into your content. You have tagging that offers semantic context. BS: Mm-hmm. AP: That’s one way to do it. And it’s not the only way. I mean, we have a lot of clients who use it, but it absolutely is not the only way to do it. Knowledge graphs can also be part of this solution. And sometimes knowledge graphs and structured content can play together to provide that rich feed of information that LLMs prefer and can do a better job with. So it’s not a one-size-fits-all solution when it comes to how to create that content or how to best hand it over to AI, but I think it is kind of a one-size-fits-all that if you aren’t doing things right foundationally, AI is going to kick your tail. BS: Mm-hmm. Pretty much, yeah. And I think the best way to look at it is to consider AI another delivery target, just like you would a portal, just like you would a PDF or what have you, a help system. When you consider it as another endpoint for your content, another, you know, place to deliver to, it makes it a lot easier to start scoping what you need to do to reach, the requirements for that particular target. AP: Agreed. So content people look at it as a delivery point and also look at as a job aid too to help enforce style guides, to help enforce taxonomy, whatever else. So it’s not just about content creation. BS: Mm-hmm. AP: It’s also that part of your thinking needs to be a content distribution point, like Bill mentioned. And it can be hard to think of it as both of those things, but in the content world, it absolutely is. BS: And I think that’s a good place to leave it. So thank you, Alan. AP: Thanks, Bill. BS: And we’ll see you on the next one. Get more insights on AI and content operations in our monthly newsletter! Name * First Last Email * Data collection * I consent to my submitted data being collected and stored. Review our privacy policy Consent to subscribe * I consent to the use of my submitted data for marketing emails. I understand that I can unsubscribe at any time. Review our privacy policy Submit The post The debt crisis: AI edition appeared first on Scriptorium .

June 22, 202618 min

From ad hoc to autonomous: The AI content ops maturity model

There are five levels of maturity for AI-driven content operations. Which level are you in? In this episode, Sarah O’Keefe and Bill Swallow walk through the AI content ops maturity model, from ad hoc experimentation to fully autonomous workflows. Sarah O’Keefe: We want this automation, right? We want the ability to go in and extract release notes and do something with them. We have to have a certain level of maturity on the software development process so that we can grab the appropriate information. The same thing is true on the content side. You have to have a certain level of maturity in your content development processes, in your content management, so that you can identify the right things to process and the right things to access. Related links: Want to know more about Sarah’s nifty little side project? Register for our upcoming webinar . AI in the content lifecycle Enterprise content strategy maturity model LinkedIn: Sarah O’Keefe Bill Swallow Transcript: 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: I am Bill Swallow. Sarah O’Keefe: And I’m Sarah O’Keefe. BS: And today we’re going to talk about AI in content operations, or more specifically, a maturity model for AI. SO: Everything needs a maturity model, even AI. BS: Even me. SO: I have no comment. BS: My maturity model is written in crayon, what can I say? So okay, so we need a maturity model for AI as far as content operations are concerned, and probably in you know, many different degrees, but we’ll focus on content operations. So what might that look like? SO: I’ve been thinking about this and what it looks like to employ AI as a tool to help you with content. And as I was thinking about what this looks like, you know, you always fall back on that standard five-step model where one is basically mass chaos, and five is the perfect world, generally. also, one is nearly always cheap, and five is nearly always expensive enterprise things. But, you know, let’s go a little beyond mass chaos versus governed, regulated, etc., and sort of sort of back up a little bit and talk about what this might look like. So level one in every maturity model typically is ad hoc. And what that means is that in this case, AI is being used sporadically by some people. It’s inconsistent. And I would say that when we look at AI and content specifically, BS: Mm-hmm. SO: This is going to be things like reprocessing your content using public-facing models. So I wrote a draft of something, I shove it into ChatGPT and I ask it to shorten it or tighten it up or identify areas that are problematic. Or I just say, hey, you know, write my article for me. The outcome that you’re gonna get on an ad hoc model is going to depend on an ad hoc level one. BS: Mm-hmm. SO: AI thing is going to depend on how good you are on the individual’s expertise and their level of interest. So if you want to just go in there and say, hey, I have a bio and it’s too long, and I’ve been asked to produce one that’s only 50 words for a particular conference, for example, then, you know, this is this is actually a really good example of ad hoc, right? BS: Mm-hmm. SO: We have these long multi-paragraph bios and every conference I’ve been to has a different requirement for how that bio needs to be shaped. And the fastest way to success is to just shove it into a chatbot and say, give me a 50-word version. And and then read it and make sure it didn’t invent things or give you a PhD or anything like that, and then ship it off to the conference organizer. But this is much, much faster than rewriting it from scratch by hand. And also I think, it’s a good example of something where I have the extended version and I’m going to summarize down. And that usually works pretty well. So level one is ad hoc. It’s kind of sporadic. There’s no standard across the organization. It’s just me saying, this looks useful, or you’ve probably got some use cases in this space as well. BS: Right. So it it kind of aligns with I guess level one of the the content maturity model that we talked about a while back, where level one is is simply content exists. Could be, you know, someone typing stuff up in Word or, you know, using a myriad of different tools, no style guide, just kind of getting content out there because people need it. SO: Yep. So level two is tactical. And tactical is sort of like we’re using this tool to solve some specific problems. And what you’re going to see here is something like that Bill has invented some nifty time saving tool and he has shared it with other people. Or in a larger organization, maybe somebody invented a nifty validate or or something like that and they’ve rolled it out across maybe the department, probably not the entire organization. Aomething like AI support is being rolled out. Maybe the organization has created a chatbot internally for customers, right? So there’s a chatbot, it’s sitting on the company website, people can use it to get answers, but it’s really bad. And the reason it’s really bad is because nobody thought too carefully about the content going into the chatbot, because again, we’re tactical. So probably this looked like the AI team just raided the local SharePoint, grabbed a bunch of content, did not pay a whole lot of attention to the question of whether this content was up to date in release status. Those things don’t exist, right? It’s just, look, a bucket of PDFs. Cool. Let’s dump them into the AI and go for it. BS: Mm-hmm. SO: And tragically, in many cases, the techcomm team is sitting on rigorous, structured, vetted, approved content, and nobody remembered to go ask them, can we have your content? Or where is your official content source? Or how do I know what version belongs with which document? BS: Right, because you know, in in their point of view there’s a PDF of it, so I don’t need to ask them. SO: Yeah, it’s it’s just PDF. How hard could it be? So something like AI was support was rolled out, but nobody really thought about it. Maybe it’s at a departmental level, probably it’s not enterprise-wide. And nobody has really thought about connecting this AI thing to the assets inside the organization in a reasonable, rigorous, governed, organized kind of manner. BS: And I suppose that’s where you get to the next tier. SO: Right. So the next tier after tactical comes strategic, right? So we have an actual strategy. Now, one of the difficulties in talking about AI is that AI is a tool and it’s kind of like talking about electricity. You can apply it to lots of places and it’s more sensible in some places than others. But when we say what’s your AI strategy, like how do you use water? I mean, come on, and the answer is of course to drive the AI and you know destroy the environment. But there are things that you can do with AI that are useful for content. There are also things that you can do that are not. So if you have a strategic approach to this, a strategic approach to use of AI, backing up to the authors again rather than the delivery side, maybe this looks like a collection of prompts that have been built that are shared. BS: Not with electricity. SO: Maybe this looks like saying this is the workflow that you employ. These are the kinds of things that we do to actually test whether this thing is working. these are the metrics that we’re following. So there’s an actual overarching bigger picture that somebody’s thinking about that goes beyond, let me go shove this into chatbot of the day. BS: Mm-hmm. Right, right. SO: So there’s an actual strategy for the public-facing chatbots. Somebody has thought about the back end. The authors have useful AI tools that add to their you know their productivity. One of the things that I’m hearing a lot now, you know, low-hanging fruit, release notes. Nobody wants to write release notes. It’s a terrible drudge task. It’s and it needs to be done. Well, BS: Mm-hmm. SO: There’s now there are now a lot of solutions that look like look at the diff in the code, look at the delta from you know version one to version one dot one, find the diff in the code, find the changes that have been made, look at the JIRA tickets that have been addressed, that have been solved in release one dot one, and then consolidate that all into a set of release notes that say, here’s what’s been done. And that’s probably 90% of the work, and the last 10% of the work is read that and make sure it’s accurate. Right? Don’t please don’t skip that step. Like actually look at what the thing is generating. Now, what’s interesting to me about level three, this sort of more strategic approach, is that what you’re gonna start to see is that you have prerequisites for this. You can’t do this. BS: Yes. SO: So release notes are good example. Let’s say that hypothetically, and this is gonna sound insane, but let’s say that hypothetically, you have software development and you have no source control. BS: Hmm. SO: Everybody’s screaming, right? Because this is nuts, and why would you ever do this? Okay. But hypothetically, you have no source control. Okay. How do you know what’s changed between version one and version one point one? BS: It’s up here in my head. SO: Excellent, great. Ha okay, cool. so I’m gonna need to connect the AI to your head so that we can pull those changes out of your head. BS: That sounds fun. SO: Yeah. Amazing. Right. So all of a sudden, because we want this automation, right? We want the ability to go in and extract release notes and do something with them. We have to have a certain level of maturity on the software development process so that we can grab the appropriate information. Now, the same thing is of course true on the content side. You have to have a certain level of maturity in your content development processes, in your content management, so that you can identify, you know, the right things to process and the right things to access. And why it is that, you know, we know that software has to be governed, but we’re not so sure about content is a mystery to me. BS: I had never understood that. SO: Yeah. So there we are. Okay, so that’s kind of like a level three. With there’s some sort of strategy emerging across the enterprise. There are some useful tools and they’re shared. This is kind of like in content when you start thinking about templates. We’re gonna have some templates and we’re gonna give them to people and they’re gonna use them and it’s gonna be great. All right, so level four is governed, managed. And so now good understanding of AI. BS: Mm-hmm. SO: It is being applied in a useful, intelligent manner, by which I mean don’t apply it to the wrong problem sets, right? Apply it to the things where it makes sense to apply it. Thinking about governance, thinking about metrics, thinking about success. And then your data sources and your content sources are being managed in such a way that the AI gets good input and can actually generate good output. So I’m actually not a big fan of the term human in the loop because human in the loop implies that the AI is doing all the work and then like the human eventually gets around to QAing it. You know what? We’re terrible at QA. You know who’s good at QA? BS: Mm-hmm. AI. SO: No, computers, not AI. AI is all about probability and whatever. It is actually not very good at QA. What’s good at QA is traditional software, right? One plus one is always two. In an AI, one plus one, sometimes it’s not two. So you manage that stuff and you put those guardrails up and you start putting up the guardrails that say, okay, when the AI kind of wanders off into the wilderness, we’re gonna like bring it back to reality. We’re gonna have, we’re gonna put it in a box, right? Make the AI think inside the box, and we’re gonna govern what that box is. AI is great at thinking outside the box. Unfortunately, that’s usually not what we want from technical content. So it needs to be in in the box and it needs to be consistent and needs to be managed and all the rest of it. BS: Mm-hmm. SO: So we govern it, right? We go in there and we make sure that the processes and the tooling that’s being put in place and the automation that’s being put in place where we’re leveraging or using AI to do things is managed. And so the human in the loop thing. I don’t want the human in the loop to fix things on the back end. I want the human in the loop to fix things on the front end so that what goes in is better, so that there’s less work to do when it comes out. You know, fix it beforehand. Don’t remediate it afterwards. That’s a boatload of work and it is not fun. So fix it ahead of time. BS: Right. Yeah. And likewise you probably wanna have, you know, some guardrails in there so that, you know, your AI, whatever it is, doesn’t go playing around with content that has been approved and released and is not slated for updating. SO: Yeah, you know, don’t fix that. That one’s done. That one’s and you know, we’re not even talking here about what it means to be in a regulated industry or in a regulatory environment. there if you are shipping or sorry, if you are a large organization and you are doing things in Europe, then you are likely subject to the European, the EU AI Act. BS: That’s a completely different beast. SO: And you have to think about what that means for what you’re doing, because the fun gold rush wild, wild west strategy of just throw AI at everything is not gonna fly in Europe. Okay, so that’s governed, you know, hypothetically. And then level five is agentic, which is basically that everything, everything or a lot of it is running autonomously. BS: Mm-hmm. SO: You know, the layman’s explanation of what is agentic AI, the difference is that instead of saying I need to put a prompt into the chatbot, it does it itself because you’ve built out the systems that drive all of that happening. BS: It understands what needs to happen at what point in time. SO: Well, let’s not say understands, but yes. I’m trying so hard. BS: Well, yeah, not understands, but there’s a workflow in place that the AI is following. SO: And it’s so difficult. I think that, you know, there’s, as a side note, the why do we think, why do we impose personality on the chatbots? And the answer is I think that psychologically it’s very, very difficult to interact with something that play acts at human interaction. What a great idea! Good for you. I love your thinking, blah, blah, blah. So it makes you think you’re interacting with a human. And I don’t think that our brains are equipped to say, no, actually, this is a machine. BS: It’s like a scary version of Teddy Ruxpin. SO: It, well, it passes the Turing test. And so we just can’t separate if it feels like you’re interacting with a person, you know you’re not, but it feels as though you are, and feeling is always gonna win over knowledge. So BS: Mm-hmm. Well yeah, the interaction is a lot more organic than you get from, you know, traditional tools. SO: Or, you know, yeah. I mean, think about the difference between a search, typing in a search string, and you know, a conversational search, a conversational interface. It’s quite, quite troubling, actually. Yeah, so this is kind of the five-level model, right? From big mess ad hoc, some things are happening, th some things aren’t, up to it’s completely autonomous. Now, if it’s going to be the more autonomy you want, the better your inputs have to be, which circles us right back to, and therefore, you have to do the work on the content side, because if you don’t do the work on the content side, the AI is going to go off the rails in interesting, unexpected, and potentially disastrous ways. BS: It will play with the mess you leave it. SO: Yep. So that’s where we’re going with this. That’s the AI content ops maturity model as it stands today. I reserve the right to change it tomorrow. BS: Today. Of course.So this model came out of I guess some little nifty side project you’ve been working on recently. SO: I am working on a nifty little side project. We’re not quite ready to announce it. but I’ve got a a co-author and we’re working on a thing. BS: Fair. SO: I could say more but then I’d, you know, be in trouble. BS: When might you be able to say more? SO: I believe that we have a webinar coming July 22nd , where we will say some more things. BS: Alrighty. Well we will learn more things then. SO: I too will learn more things and probably we’ll have to we’ll probably we’ll have to change everything we’ve done up until this point because everything will change by then. BS: Of course. Guess that’s a good place to leave this podcast. Thank you, Sarah. SO: Thank you. Want to know more about Sarah’s nifty little side project? Register for our upcoming webinar . The post From ad hoc to autonomous: The AI content ops maturity model appeared first on Scriptorium .

June 1, 202642 min

Tool selection and the unpredictable variable

How do you really choose the right documentation tool? In this podcast episode, Sarah O’Keefe (Scriptorium) talks with Paweł Kowaluk and Michał Skowron (Guidewire Software) about building a successful tool selection process, the realities of docs as code, and what happens when the technology becomes the unpredictable variable. Paweł Kowaluk: It’s funny how programming used to be deterministic, and it was the people who were messy. We always knew that people are going to be whimsical and maybe harder to rein in, but the technology is going to be predictable. Whereas now, technology is not predictable anymore, and you give it a prompt and you hope it’s going to do what you want. You adjust the system prompts and change the weight of things which are retrieved versus metadata, et cetera, and it doesn’t always work the way you expect it to. Sarah O’Keefe: And now the people are being asked to be the deterministic layer, right? To be the QA on top of the AI. Paweł Kowaluk: That’s actually very insightful. I like that. That is true. The human in the loop or whatever you call it, that’s supposed to be the voice of reason. Related links: Scriptorium: AI in the content lifecycle Tech Writer Koduje podcast Tech Writer Koduje: DITA as code – a modern approach to the classic standard Tech Writer Koduje: Are people abandoning docs as code? Tech Writer Koduje: A tech writing CCMS can also be a broken promise LinkedIn: Host: Sarah O’Keefe Guest: Paweł Kowaluk Guest: Michał Skowron Tech Writer Koduje LinkedIn profile Transcript: 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 welcome to the podcast. In this episode, we are going to talk about tool selection with a couple of special guests. With me today are Paweł Kowaluk, who is a software architect at Guidewire Software, and Michał Skowron, who is a documentation tools developer, also at Guidewire. Both of them are based in Poland. Welcome. Paweł Kowaluk: Hi. Michał Skowron: Hello. SO: I am glad to have you. For those of you on this podcast that speak Polish, you’re probably already aware that they have the one and only techcomm podcast in Polish that is available out there, and Michał and Paweł are also experts on doc process and tool selection, so that’s what we wanted to focus on today. So I will start and throw it to Michał and ask you the big picture question, which is what does a good tool selection process actually look like? MS: For me, good selection tool process would be divided in three stages. The first one would be gathering requirements, looking what’s out there, defining what you want to basically achieve with this new tool. Then I would go to a pilot project where you can actually test the selected tool in the real world. Manufacturers and producers of software will tell you that it can do anything and it will promise that, “Okay, you can meet all your requirements easily and we can fix that, we can improve that, we can adjust that,” so everything can be done is usually what we hear, but then you want to test it in real world on a real project, so that will be a pilot project for you and your team. And the third phase that depends on the outcome of the second phase, which is you either productize the selected solution or you just say, “Okay, that was a bad choice and we don’t need that.” Then we need to go back to the first stage and then say, “Okay, we need to select another tool,” and again, requirements, et cetera, et cetera. So for me, that’s the whole process, and the first stage would be probably the longest one because you need to make sure that you are meeting all your goals. SO: So what’s the most common reason that a pilot doesn’t succeed, that you have to go back and say, “That didn’t work. We have to try something different”? MS: It’s usually because you didn’t see everything when you were planning. For example, you have some projects that are very specific or you didn’t see all the problems or things that are coming your way. It’s hard to say exactly what the reason is, but it can be multiple reasons. For example, using of, I don’t know, branching, let’s say, in a specific tool. When you have multiple versions of your product and you want to keep them separate when it comes to documentation, it can turn out that the feature says, “Okay, you can use branching and then you can do it easily,” and then you start using it and it turns out that it doesn’t work the way you expect it. This is actually a real life example because we had a system that… I’m not going to mention any names or anything like that, but there was a system and they promised us… That was years ago and it was a vendor that promised us that they’re going to introduce a feature called branching, and it turned out after they did that that it wasn’t what we expected. So it can turn out in many cases, in many ways, it can be the problem, but branching is just an example, but it can be many other things that can go wrong. PK: Hey, if I can jump in here, I got a couple of examples. One is I could call it releasing strategy or versioning strategy overall, which is very hard to test in a pilot project. It’s very hard to scope for requirements because the little problems come out after a while, after a year of publishing, after two years of publishing. And another example which is related is reuse, and this one is down to formulating the requirements correctly. Because I think just saying, “We want to reuse something,” is not enough, because you have to say exactly what you want to reuse and how you want to reuse it and what you want the result to be. So for example, if you say, “I want to reuse notes and warnings and things like that.” We sometimes call them admonition. So, “I want to reuse these notes in my docs, and if I update a note, I want it to update in every published version of the doc.” Then only if you have these details, like I want to update it once and then want it to automatically update and publish docs, then you will see it’s not working the way you expect it. Because if you just say, “I want to reuse notes,” every system can reuse notes. Even in docs as code, there’s scripts and macros that allow you to reuse notes. MS: It can be also another thing that, for example, you compare the benefits with the actual cost of implementation, and it can turn out it’s not worth it because people are, for example, reluctant to use your new tool. The training, the cost of licensing, the cost of support is too big, and then you realize, okay, we want to achieve a goal like, I don’t know, reduce the time to market, and then it turns out it doesn’t work because people are struggling with using the product on a real project. And on paper, everything looks cool and you have all these features, you can use them, like Paweł mentioned, for example, reuse conditional formatting and things like that. And then it turns out it’s very hard to use, it doesn’t serve its purpose, and then you have to pay for every additional stuff and people don’t want to use it, so what’s the point? SO: Yeah. And I think we find that the technical problems in general, if you’ve done your requirements work, then usually, the technical problems are solvable if the people engaged in the project want to solve them, and that’s where you run into the change management issues that you’re talking about, that if the team that is being asked to pilot, to test, to try things out is sufficiently disinterested in making it succeed, they will find a way to make it fail. And the reverse is true as well. If they want it to succeed, you can implement tools that are … Well, all tools are imperfect, but you can implement tools that are not perfect solutions and succeed if the team is behind you, and if they’re not, bad, bad things will happen. PK: Oh yeah, that’s true. And I’ve been on projects where we did not do proper change management and I’ve been on projects where we really did it well. If you start early and you involve people, like get the biggest troublemakers, people who are the most opposed to any change, get them on the team, and if you can convince them, that means, one, you are making the right choice because you’re convincing people who are skeptical, and then two, you are set up for success. These people are going to be your biggest champions of the new solution. MS: But it’s good that you mentioned it because I think it’s worth emphasizing that the goal of the pilot project is not to succeed. That’s not the actual goal. The goal is to verify the requirements against the real project, and so the failure is also a success to some extent. It’s not like you have to do everything to prove that the selected tool is the right one. No, you should be aware that the pilot can end up with your let’s call it failure, and then you realize that it’s either a bad choice or you don’t need that at all. For example, you don’t need that tool at all. It can be also the outcome of the pilot project. So there are many different outcomes, so don’t be fixated on the success path that is the only right way. It means, okay, the pilot project was a success because everybody agreed that that was the right tool that we want to use, so keep it in mind. SO: Yeah. I think that there’s … I got into actually a debate with somebody about this. They were telling me that pilot project, proof of concept, and what was the third one? Prototype are not the same thing. Okay. Well, so a pilot project is, “We think this is the right answer and we’re going to try it small and then we’ll expand.” A prototype is, “We’re just going to try it and throw it away,” and a proof of concept is, “We think this is the right answer, but we’re not sure and we’re prepared to throw it away.” And I thought, “This is way too specific for me, but okay, sure.” But to your point, the project, whatever category it belongs in, has different purposes, and it’s important to be clear about what kind of a project is this? Is this essentially beta testing, this is step one, or is this more speculative? We’re just really, really not sure. PK: I think it has to be falsifiable. Like they say in the scientific method, there has to be a failure criteria somewhere. This will fail if ABC happens, because if you don’t have that- MS: Or a success criteria, right? PK: Or a success criteria, but I’ll be more focused on the failure criteria because you can always show, “Yeah, we accomplished this, 30%,” but if your failure criteria is below 50% is fail, then you will say, “I failed this.” You fail five out of six and the project is a no-go. SO: So I wanted to switch gears a little bit and talk about some specific tool chains and problem sets. I think it’s fair to say that the two of you are, I’m going to say mostly but not exclusively, focused on docs as code, so what does that look like? And there’s a lot of debate about docs as code versus structured content and they’re very much pitted against each other, but ultimately, what’s your perspective on the situations where docs as code is appropriate or maybe is not appropriate, and what do you look for in a project or in a problem set that matches the docs as code model? PK: I think the reason people associate us with docs as code is the last eight years, we’ve been working at Guidewire and that’s the strategy we’ve chosen there, so I think we’ve been entrenched in this worldview. My previous job before Guidewire was a consultant, and I would go from a company to company and set up different systems for documentation. That was my specialty, systems for publishing and updating documentation. So yeah, circling back to your question of when it works, when it doesn’t, I guess docs as code is more about it works when the right mix of people are creating the docs and the mix of people includes software developers. So for example, at Guidewire, we have several dozen static websites which are maintained by software teams without any technical writers involved, and those are a variety of internal tools, tools which are almost external, and then tools which go out to customers, and all of these little websites integrate very well with our publication system. And I think this is the main criterion for docs as code fitting is you are giving tools for writing to people where they work. So software developers work in code. You give them tools for writing in their codes so they don’t have to buy extra licenses, get training on anything external, use some alien process, alien to them, just because they follow SDLC, the software development lifecycle to update their docs. And it’s what they’ve been doing, and then it’s easier to convince or it’s easier to fit in a smaller team of technical writers, I don’t know, like 40 technical writers versus 2000 software developers. It’s kind of everyone contributing to the same documentation system. It’s easier for the tech writers to adapt and join the docs as code platform than the other way around. MS: Just like Paweł mentioned, docs as code makes sense in certain environment. It’s not like we are tribal about it. We love this solution because it works for us. So after a few years at Guidewire, we realized that this is the way we want to go, because as I said, it makes sense and it just works. We tried different things before, and before I joined Guidewire, there were different solutions. We used, for example, CCMS and we had more a traditional approach to producing docs, let’s call it this way, and then we started building our own pipelines, our own solutions. We started integrating with what was there that other devs used for their work, not related to documentation, but we decided, “Hey, maybe we can use what’s out there and just plug into the same infrastructure.” So as I said, it’s not for everybody, it doesn’t work in every environment, so I wouldn’t say, “Okay, if you’re in a factory, you should use docs as code.” No, I wouldn’t say that. So maybe we positioned ourselves as docs as code proponents, let’s call it this way, but this is because we use it every day, we build it, and this just works for us. And also maybe I can mention that we decided to end this holy war by putting DITA into Git and CICD pipelines, so we have DITA as code, and now everybody’s happy. PK: Oh, this is actually a great point because Sarah, also mentioned docs as code versus structured. Now we’re doing docs as code in a structured way, and where technical writers are working on the docs, they are free to use DITA and a lot of teams do that with all the reuse and all of that, but even if it’s something simple like some markdown files in a repo, we still impose a metadata structure which allows us to integrate the doc into our publishing pipeline, and the two key aspects of what we’re integrating with our authentication and search, and that needs metadata, right? It needs to know who has access to this content and it needs to know how to filter and direct the searches, and from that, our next project emerged. Like everyone else in this industry, we started working on AI solutions, and the AI solution is a third integration point where this structured approach to content also pays off. SO: Yeah, I did want to touch on AI and so we should probably just jump to that. What are the implications that you’re seeing? What are the effects that you’re seeing on your current processes of the use of AI or the requirement to deliver to AI, and how do you see that working? MS: Paweł, you want to start? PK: Yeah. So the content remains the same that we’ve been working on for years, and the structure, the metadata is all the same. We could not change this overnight, but overnight, we had to introduce this AI which is going to look into the content, find the topics, the chunks we call them. It’s going to find the right chunks of documentation and generate answers based on those chunks. So what happened is we had to adjust the AI, but since we were so structured, it was pretty easy, and then we gained a new source of feedback from customers through the AI. Because when people started using our chatbot, we built a chatbot which is available on docs@guidewire.com, but it’s only available to customers and partners, so you need a login on the website. When you go there, the AI answers questions, and then we monitor the exchanges that people have with the AI and we see what needs to improve as far as content ingestion, as far as content structure. We generate a lot of internal tickets to our tech writing team and identifying gaps, because we’re seeing now that this AI interaction is possible, here’s what people are asking of the content. And other people are asking, “How do I implement X, Y, and Z in the scenario where ABCD?” Which we didn’t know people were looking for before because they had no interaction with the docs. So they just come to the website, they either find or don’t find what they need, and we don’t know anything about that, and we could ask them, but we’re just going to ask a small group of people, whereas now, it’s as if we’re asking everyone. So we’re seeing these new patterns and something emerges out of those patterns, like everyone’s asking for code samples in this specific area, so we go back to the team and we work on adding more code samples, or people are looking for illustrations of these particular workflows, so people create these illustrations. It’s amazing how rich of a source of feedback this has become. MS: And it also adds complexity to even testing all the solutions that we have right now, because with keyword search, I’m not saying it was easy because it wasn’t easy, but now we have another layer where you have this middleman, let’s call this chatbot, let’s say. It’s a middleman that can hallucinate, so you can either have a problem with your content or you can have a problem with the agent that responds. So before, when you had a keyword search and you were missing results, you were going usually to the content and see, “Okay, I’m missing this topic. It wasn’t indexed properly, or I just need to move some knobs in my search engine and just see the fuzziness or something like that.” And now you have this content, it’s being processed by this AI tool, and then it gives you some answers and you don’t know why the answer is wrong. Because it didn’t find the content? Because it’s not there? Because it’s not the right content? Because the content is right, but there is something that it missed? There are so many moving parts right now, more than before that it adds complexity to our job, and this is just one side of it. The second thing is writers using AI for creating content, and we’re also exploring this path because everybody’s trying to incorporate AI solutions into their work. We code mostly on a daily basis and we use some tools that help us with coding that are AI-based, but we also want our writers to benefit from all this development in technology, and we’re exploring, let’s say Oxygen, XML, Positron. Just to clarify, we’re not sponsored anything. We’re just using it so I’m just mentioning the name specifically, but even if you don’t have any specific tool for writing that integrates directly with a AI tool, you can still use, let’s say, Copilot or any other solution that you like and you can just ask it to help you with the content, but it comes with a lot of caveats. It’s not like you just throw a prompt and just get what you need. It involves a lot of fine-tuning, a lot of working on instructions, giving it context, giving it information that it needs to use for producing code or docs. Because I use it for both, for coding and for documenting, for internal purposes mostly, but it takes time to make it work the way you want it. PK: Yeah. It’s funny how programming used to be deterministic and it was the people who are messy and the processes, and working with setting up the process for the doc tools, we always knew, people are going to be whimsical and maybe harder to reign in but the technology is going to be predictable. Whereas now, technology is not predictable anymore, and you give it a prompt and you hope it’s going to do what you want. You adjust the system prompts and change the weight of things which are retrieved versus metadata, et cetera, and it doesn’t always work the way you expect it to. SO: And now the people are being asked to be the deterministic layer, right? To be the QA on top of the AI. PK: That’s actually very insightful. I like that. That is true. The human in the loop or whatever you call it, that’s supposed to be the voice of reason. SO: I don’t know about you, I’m not good at voice of reason. I’m much better at causing trouble. So what you’re describing is a fairly complex and time-consuming approach to this in that you’re saying we have this AI chatbot and we’re looking at the metrics and we’re adjusting accordingly and making changes, and then using the AI on the backend for some productivity kinds of things, but not as a replacement. We’ve seen in the US and in North America, we’ve seen a significant number of people losing their jobs because the idea is that, oh, the AI can just do it, and what you’re describing is not that at all. So are you seeing any of this sort of, “Oh, this will make us more efficient, and therefore, we need fewer people,” or is it a different perspective in your piece of the tech com world? MS: I’m aware of all the layoffs and of all the bad things that are happening right now in the IT world, let’s call it, because it’s not only technical writers because it’s also developers and different jobs, but I think I’m still in this kind of a bubble right now where it’s not happening directly next to me so maybe I’m being too optimistic. But I keep saying maybe I’m going to eat my shirt after some time because I keep saying, “Show me one tech writer that doesn’t have a backlog that is not too long.” So we usually have too much work, and I hope that with the right approach and with a sensible management, these AI tools will be doing all the things that we don’t want to do or we don’t have time to do, and then it will give us time to do something more and something more significant. I’m looking at my job and I’m not saying it’s perfect because of AI, because it has so many challenges right now and it gives you different problems, but I can see that I can speed up my cumbersome tasks very, very easily. And before, I had to … This is a simple example, and I’m doing a lot of infrastructure work and a lot of backend work, so many things go wrong, and very often, I had to debug difficult problems. It was taking me weeks sometimes to nail the actual place where it happened. Now, I can do it much faster. If I have to debug a problem, it takes me, I don’t know, an hour, sometimes even minutes, and I know that I would spend a day, two, or even a week if I didn’t have these tools. But these are good examples, but there are also a lot of bad examples, but I don’t think we have time for that. SO: We’ll take the optimistic view. PK: Yeah, I agree with Michal. The approach we have is these tools can give us tremendous productivity boosts, but not in the sense of getting rid of people. We can redirect people’s work to where it’s more meaningful. And what I mentioned about feedback, identifying these content gaps. Some of these content gaps are going to be very mechanistic and you solve them by generating a bunch of docs out of code, for example, and then you put those docs in the repository where the chatbot can find them, because they’re not going to require a lot of thinking. It’s kind of like API docs where you create the swagger spec and then you generate the dogs out of that. You just grab the source code and you generate some samples, and you use that to generate answers to people. Without people, this wouldn’t work because you need, like we said, the voice of reason, but yeah, people are still required in the process. SO: I think that looking at it across the industry, if you take AI, take a chatbot, especially a public facing chatbot, and ask it for answers on literally anything, it will give you the average of what’s out there in the world because it’s math, so it gives you the average essentially. And so from a content creation point of view, I think the fact of the matter is that there is in fact a lot of below average content out there. Roughly half is below average, or perhaps exactly half. If the information is bad enough, if the content being produced is not of high quality or ungrammatical, and we’ve all seen terrible, terrible documentation that was badly translated and is just incomprehensible, then the AI as a tool for creating content may be able to produce something that is better than terrible. It’s not going to replace a professional, well-trained, highly experienced and knowledgeable product documentation group, or it shouldn’t, but that’s not every company. Not every company has a really good group of tech writers that understand the product and are adding value as they produce the content that goes with that product. And so I suspect that what we’re going to see is a split with commoditization on one end, just auto generated, it’s not great but it’s adequate maybe, and then the higher end stuff, which needs to be done well. PK: Well, there’s definitely documentation which only exists because it absolutely has to, and companies like that can easily generate just some kind of documentation and just use it, right? But in cases where … I think the worth, the value of a technical writer is not just writing and generating the content from below their fingertips. It’s more about the research and understanding, like you said, understanding the needs of the users and understanding how to meet them. You throw AI at a problem which sounds like a generic problem, it’s going to give you a generic answer, not necessarily one that is rooted in the organization you’re in. The list of products that you have, the way those products interact with one another, it’s going to miss all that. It’s just going to give you … It’s like ordering a hamburger and you say, “So what’s in the burger?” And the AI is going to tell you, “Well, usually in a burger, it’s a patty and lettuce.” And it doesn’t mention that at your restaurant, you use pear and avocado. It doesn’t know that. You know that. You’re the chef back in the kitchen and you know why your burger is special. SO: Yeah, I think that’s right. So I did want to touch briefly on the question of, because this is a rare opportunity to talk to some folks that are not based in the US or North America, what differences, if any, do you see in tech writing in the market? Now, you’re based in Poland but working for a, I think, US company, but what kinds of things do you see that are maybe different that especially the people listening to this in the US would not be aware of coming out of Eastern Europe? MS: For me, always, it was the fact that tech com appeared much later than in the United States, in Poland of course, because I’m not talking about Europe in general because there are also differences between countries in Europe. For example, Germany is totally different from I would say the Polish market, because in Germany, you usually have factories and you have technical writing associated with hardware, let’s say. SO: Yeah, heavy industry, machinery. MS: Yeah, heavy industry, that’s right. And in Poland, it’s very often about software, maybe because we have a lot of companies that outsource to Poland when it comes to software development, R&D and stuff like that, so that’s the first thing. And don’t get me wrong, people were doing tech com way before it appeared in the mainstream, but sometimes they were not even aware that this is called technical writing or technical communication. Actually, it happened to me because I moved to techcomm from some kind of IT support job, and then after a year, I was like, “I’m wondering if this is anything regulated or there are some rules or it’s actually a profession.” Then I started digging and here I am. But it turned out there are so many things, so I was also surprised. Okay, this is called that. These are standards. There are books. Well, actually, one of the first books that I read was your book, Technical Writing 101, which I’ll still recommend, although it’s been years since it was published the first time, but I think it still holds a lot of truth about techcomm. The core values of techcomm are still there. So going back to your question, the techcomm scene is relatively young, let’s call it this way, in Poland, which gives us a big opportunity to skip some stages, let’s say. So we don’t have the legacy, we don’t have some things that we used to do a certain way and we like it or we are just accustomed to it. We can just start fresh and just jump. In 2000s, we just jump into techcomm and we say, “Okay, let’s do it this way because now this is the way we do it.” And I think that people are flexible when it comes to looking at things a certain way. Not everybody because there are also people who don’t like changes. But I think also what is unique about Polish techcomm scene is it’s relatively small, so if you do something outside your work, you don’t treat your job as only a means to earn money and just survive and you want to do something else, let’s say just write an article, like give a presentation, go to a meetup. After a year or two, you just keep meeting the same people, you know basically everyone who is in the circle, so it’s much easier to be visible if you do something outside your work. So I think that would be something unique about our techcomm scene. PK: I think what might be a downside of the Polish techcomm scene is a lack of veteran experts, because we don’t have people who have been doing this for 40 years. I’ve been in the industry for 18 years. SO: But you do understand that you two are the veteran experts. MS: That’s what he’s trying to say, that- PK: I’m getting to this. So yeah- MS: Imagine that. PK: Putting on my clown makeup every morning. What I mean is there’s nobody to look to who wrote the book on technical writing and has been there for 40 years. I’ve been here for 18 years doing this thing, and out of the people who are visible publicly and who contribute to the scene, I don’t know if there’s anyone who has more experience than me. Because I know there are people who have more experience but they’re just not visible. They don’t share their knowledge with anyone, and we miss that, so that’s why we look to the West, to people like you guys, like Scriptorium, and we read books which were created there and we see there’s definitely value, even though something is as old as the scene here or older. MS: And people also have this tendency to look at things that were done in the past as like, “This is the old stuff. We don’t need that. This is the old way. Let’s do it this way because it’s better now, because we have all these tools and et cetera.” But I think it’s a big mistake, because what they say? History doesn’t repeat but it rhymes, something like that. So in order to do your job in the present, you just need to look at the past, and this way, you can also be ready for the future. I think it’s worth looking at all this, let’s call it legacy stuff, all the experience that people with 30, 40 years of experience in the field have because it’s valuable. Because usually, when you look at it much deeper, it’s nothing new. It’s usually something that already happened but it’s dressed up as something else. So if you look closer, it’s usually something that let’s say you can understand what happened and then you can apply the same rules, maybe slightly change them or bend them. But my experience is the same happens in software development, in coding. People are inventing new things, and when you look closer, it turns out somebody already said that in the past. It was already done this way, but it’s dressed up as something else or named differently or is hyped more, or it was invented too early and now is the time to use it. So the history gives you a lot of perspective, a lot of things that you can use, so don’t dismiss it. SO: Well, I think that’s a good point, and as we close this out, I want to ask you what you see in the past or where you’re gaining perspective on the introduction of AI. Whether it’s from a delivery point of view or a backend productivity point of view, where do you see that pattern previously, or do you? PK: There are similarities, but they end. They’re not perfect analogies. So going digital was on example, and when I started, it was just on the brink of companies going from print to web, and that was a huge paradigm shift. And we’re seeing reverberations of this even today where teams are still thinking in books and chapters instead of thinking in pages and thinking about even every page is page one, which is, I don’t know, it’s older than me, the idea, but it still hasn’t been adapted to by teams. Now, the AI thing is probably a similar earthquake where it’s the AI reading your docs, giving you answers. You’re using AI to generate these docs, et cetera, et cetera. I don’t think we’re going to get 20 years of leeway to adapt to that and still see people doing things the old way. I think the world maybe moves faster nowadays, but I don’t know, we’ll see. MS: It may be something similar to the invention of computer. So instead of writing let’s say manually, people have got this new device that gives you more power and you can do more things and then programming languages and everything, but as Paweł mentioned, the pace was much, much slower. So we had years of development to, let’s say slowly, maybe this is the bad word, let’s say slowly adjust to the change, and now it’s an earthquake. So every day, every week, there is something new and you need to keep up, keep up, so the pace of development I think is the biggest challenge. Because we tech writers survived many revolutions. I just started reading a book by Sharon Barton about the women in technical communication, and women who talk about their careers, they mentioned many, they start very early because there are a lot of examples from the States. So they started working when they were not even treated equally with men, which was years ago, and they mentioned all those changes, all those revolutions, all those evolutions. And I’m saying, “Okay, this is what we are witnessing right now, but the pace is definitely faster, so we need to just keep up,” which is hard, of course. PK: Well, I have another one which is a good one. I don’t want to not say it. The dot-com bubble. I think maybe we’re in a bubble again, maybe. You’re seeing the inflation of AI prices right now, and I think we’re going to end up in a position where you cannot do all these things with AI which we’re hoping to do with AI, so the surface of usage is going to shrink and there’s only going to be specialized uses and special case scenarios when you use AI because it’s going to be expensive, and a whole lot of AI applications are just going to disappear. This might be a parallel, but I don’t know, it’s always hard to predict, especially the future. MS: I’m also predicting some corrections. Let’s call them corrections. SO: And I three am also predicting some corrections. You touched earlier on the fuzzy. AI is very good at fuzzy problem solving, but it’s being thrown at things that are old problems that we know how to solve with scripting. And scripting from a computing power point of view is cheap or maybe free. You write your script and you run it, and every time you run it, you get the same predictable result. Now, sometimes you don’t want that. Sometimes you need that fuzzy pattern matching thing, but in the cases where that’s not what you want and we’re still using AI, that is part of the bubble, right? Everything looks like an AI-shaped problem. So yeah, I agree with you. I think that any predictions we make on specifics as to where this is going are guaranteed to be wrong, because I’ve tried this before and I’m always wrong. So I want to thank you both. This has been very entertaining and very interesting, and I hope that we will see you again and you’ll come back and tell us more about what you’re up to over there. PK: That would be lovely. I would like that very much. Thank you. MS: Yeah, sure. No problem. Thank you very much. That was fun. SO: Yeah. Thank you both. We will see you soon. Want to learn more? Download our book, Content Transformation. The post Tool selection and the unpredictable variable appeared first on Scriptorium .

May 18, 202624 min

Taming AI: Using AI for content conversion at scale

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 .

May 4, 202619 min

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

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 .

April 27, 202622 min

Make the move successful: Replatforming content ops

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 .

March 30, 202640 min

Who controls your content? AI and content governance

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 .

March 23, 202614 min

Good content = good AI: The fundamentals that never change

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 .

February 16, 202632 min

Check in on AI: The true measure of success for AI initiatives

In this episode, Sarah O’Keefe and Alan Pringle explore how AI transforms content delivery from static documents into dynamic, consumer-driven experiences. However, the need for human-led governance is critical, and Sarah and Alan explore issues of accuracy, accountability, governance, and more. They challenge organizations to define AI success by its ability to deliver accurate, high-impact outcomes for the end user. Sarah O’Keefe: The metrics that are being used to measure the success of AI are all wrong. We should be measuring the success of various AI efforts based on, “Are people getting what they need? Are they having a successful outcome with whatever it is that they’re trying to do?” The metric we actually seem to be using is, “What percentage of your workflow is using AI? How many people can we get rid of because we’re automating everything with AI?” It’s the wrong metric. The question is, how good are the outcomes? Related links: Sarah O’Keefe: AI and content: Avoiding disaster Sarah O’Keefe: AI and accountability Alan Pringle: Structured content: a backbone for AI success Questions for Sarah and Alan? Register for our upcoming webinar, Ask Me Anything: AI in content ops. LinkedIn: Sarah O’Keefe Alan Pringle 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 Alan Pringle: Hey everybody, I’m Alan Pringle, and today I’m here with Sarah O’Keefe, and we want to do something I’ve kind of dreaded to be honest, to do a check-in on AI in the content space. I’m very ambivalent about this topic. There’s still even two, three years in, there’s still a lot of hype, but there’s also been some good things that have emerged. We need to talk about it fairly realistically. So, Sarah, get ready. Let’s see if I can not curse during this. We’ll try. I’ll try my best not to be like that in this. Legitimately, there are some things that we need to talk about, and also about the challenges because I don’t think the content world is completely ready for a lot of what’s going on right now. Sarah O’Keefe: You know that we have AI that can remove cursing from podcasts, so I feel like we’re good here. AP: Well, also, it’s a challenge to me to behave in a PG-13 more family-friendly kind of way. So I’ll do my best. SO: I have no idea what you’re talking about. AP: Yeah. So let’s start with the good and where things are right now with the positives. What is AI doing well right now? And let’s kind of get beyond the summarization. I think we can say objectively right now, i n general, AI does a very good job of summarizing existing content. But I think it’s doing a lot more beyond that, and we should touch on those things instead. SO: The first thing that I would say is that summarization, but specifically the use case of a chatbot or a large learning model, an LLM, so now we’re talking about Claude, Gemini, ChatGPT and all the rest of them, which has the ability to provide an end user with a way of accessing information, an information access point that is different than what we had previously. In the olden days, you had a book, and you had to sort of flip it open and look at a table of contents or maybe an index and navigate to a page. Fine. Then along comes online content, and you can do full text search, or you can then go into an internet search, right? You type into the search bar, you get a bunch of results, you click, and you sort of, no, that’s not quite it. You modify your search string, you search again, and you sort of navigate your way to where you’re trying to go. With the interactivity of the, you know, ChatGPT class of tools. What happens is that I ask it a question and it gives me an answer. And then I say, that’s not quite what I wanted. And I can sort of zero in on exactly what I’m looking for and tell it, but actually make this easier. Or I don’t understand the words you’re using. Use simpler language. Give me more. Give me less. Give me a summary. Use this as a source. Do not use that as a source. It’s a new way to access information. People love it. There is something psychologically helpful about a conversational search. Now, there’s obviously huge issues with this, particularly around people, you know, using chatbots as their therapists, which introduces all sorts of horrifying, horrifying ethical issues. AP: Personifying them as a person on the other end. Right. SO: But in the big picture, used well, it allows you to get to the information you’re looking for and get at it in the way that you want. AP: There’s a control issue here. I don’t think the content consumer has ever had this level of control. SO: Yeah, and as a content consumer, that speaks to me. That is helpful. We’re seeing increasing use of, I would say, guardrails. So, not just slam out the AI with a bunch of stuff, but rather we’ve put some guardrails around it, and there’s various kinds of technologies that you can employ there. And that has been very helpful. And then the third thing I would point to is when we talk about generative AI and generating content, there’s a lot you can do in that sort low fidelity bucket. And what I mean here is I need an image for a presentation, but the background is the wrong color, so I can just swap it out. Now, I can do that with Photoshop. Well, some people can do that with Photoshop. AP: Well, I was about to say, don’t think you or I should be saying we can do the Photoshop because we kind of can’t. SO: Right. Well, and that’s exactly it. So it’s lowered the bar, right? Because I can tell the AI to swap out the background, and it will. And it applies a mid-level Photoshop capability to this image. And now I have the image that I need with a dark background so that the white text shows up in my presentation, that kind of thing. AP: Right. Yeah. SO: We can do low-stakes synthetic audio if this podcast, which for the record we are recording with actual human beings, but let’s say that Alan curses extensively and we need to swap it out well, we could pretty easily generate some synthetic audio that sounds like him and that PG of eyes the original wording into something that is You know cleaner it would be way funnier to just bleep it. So I don’t know why we would do this but… AP: Correct. Well, and it may come to that. The bottom line is what you’re talking about here is things that have very low risk. This is more fun stuff, the thought of doing some of what we’re talking about and stuff that describes how to use a medical device, for example. Not sure I want to go there with that. But for something low stakes like some one-off presentation that you’re giving, maybe some humor is involved, I totally think that’s an acceptable use because there’s no risk there. SO: That’s really the key point because let’s say you’re writing content for a new medical device. Now you probably have a version one of said medical device, and you’re doing a version two. So, okay, fine. We take the version one content and we sort of, you know, say add color because that’s what we added, you know, in version two, and update all this stuff automatically. But it then becomes very important to actually read that, look at that information, look at all the images, make sure that everything is correct. And by the time you do that super carefully, you may have given back all the time that you saved on the back end when you basically made a copy and said generate the new version. There’s some, you have to be really careful with that, especially depending on what your stakes are in terms of regulating regulatory or compliance stuff. You can, of course, get away with using AI, as you said, for low-stakes stuff. Now, the big risk you run there, and we’re seeing this in my favorite example of low-stakes content, which is video games, the video game industry has seen huge amounts of pushback against AI-generated game content, because it’s not fun. It’s not creative. It feels flat. It’s not art, and it’s not fun to play. And so it just becomes a slog. Again, same thing. Did you use it for maybe some backgrounds here and there? Okay. Did you use it to drive the story that you’re trying to establish or set up? You know, the enemies that you’re hypothetically fighting, and then they all have a certain sameness, or they all, you know, you’re sort of stealthing your way around the map. And it turns out that the AI-generated things are really dumb in that once they turn their back, you can do literally anything and they won’t notice because it was poorly designed. AP: Right, yeah. And that’s true even in the film entertainment industry. There’s been a tremendous amount of pushback for the very reason I read a review recently talking about a series of clips about history on, I believe it’s on YouTube, by a fairly well-known director I will not name. SO: Mm-hmm. AP: And some of the AI is frankly not done well. And one reviewer basically said that a lot of the people, when you look at the back of these AI-generated, like an AI-generated King George, the back of his head looks like a melted candle. This is not what we want here. If you’re so focused on that sort of thing, you’re not paying attention to the message. But again, this is low-stakes content. We have started getting into kind of more the content creator point of view. We’ve talked about the consumer and how AI gives them much more control, flexibility in how they receive information. But let’s talk about what that means more for the people that have to create the information because it’s a huge shift on multiple levels and this idea of creating, especially in the product content world, these lovely design page-based PDFs and whatever else, and even webpages, hate to say it, those days are gone, or should be at this point. SO: Yeah, again, you know, we step back to books, and you write the content, it goes through like a manuscript process of some sort, and then it gets poured into a book. It gets printed on paper, which is about the least flexible thing you can imagine, right? Because I, as the book publisher, get to decide what font is on the page and what size. And if you don’t like that font, well, maybe you can get your hands on a large print edition. Maybe you can get your hands on a braille edition. Maybe. But the form factor of the content was determined by the publisher of the content, or technically, the printer. But, you know, that physical book production process. PDF, not that different in the sense that the content is bound into the PDF and it’s fixed. Now. You get a little bit more control because you can zoom in. There’s some things you can do in PDF, but ultimately it’s more or less still a page factor determined by the author/publisher/gatekeeper. So now we talk about the web and HTML. This is all pre-AI, right? HTML goes out there, and there’s actually a decent bit you can do in your browser. You can override the default font. You can override the default font size. You can say, I’m using dark mode or light mode or those kinds of things. AP: Light mode, exactly. SO: If you have an e-book reader, you can override the default font or font size. AP: I need that font size jacked up, please. Thank you. SO: We weren’t going to use that example. Right. Yeah. So you get a little bit more control, right? You have a little bit more control over the presentation. Now, let’s talk about what AI does to this, and particularly the large language models. Now, I, as the author, create a whole bunch of content, and I put it somewhere. And the content consumer says… AP: I’ll use it. SO: Tell me about this concept or tell me about this thing or give me information about whatever. And they get a response to that prompt, which is a paragraph or two of, you know, here’s what you need to know. And then they say, make it easier, make it simpler, write this at a fourth grade level, write this at an eighth grade level. I’m a PhD in microbiology. Give me more detail. Right. You can change the writing level. You can say make the font bigger, make the font smaller, give it to me in a PDF, show it to me in a spreadsheet. AP: I’ve even seen someone create a podcast of this document and have two people talking about it, which was freaky, but you can do that. SO: Right. So as the author and the content creator and the backend people, right, the content people, we’re accustomed to taking our content and packaging it in certain ways. Like, here’s a topic for you, or here’s a PDF, or here’s a book, or here’s a deliverable, right, a package of content. And although with structured authoring, when that came in, we let go of this idea that we, as the author, got to control the page presentation. That got automated into the system. So the person controlling the page presentation was the person who designed the publishing pipelines. But the publishing pipelines were designed on the backend by the authoring people. Now all of a sudden, we have no control over that end product. Just because I thought it should be a PDF or an HTML page, you can turn around and say, like you said, give it to me in a podcast, make me a video, show it to me in French, and the LLMs will do it. AP: The publishing pipeline got moved over the fence basically to more of the content consumer side and they get to do what they want more or less. That’s where things are headed. SO: So pre-AI, we talked about content as a service, right? We load up all the content in a database somewhere, and then you, as the end user of that content or another machine, can reach over and say, give me some content out of there. But it was still a pretty discreet, like, show me that topic or show me that string. And what is fundamentally different about AI and large language models processing that content is the degree to which you can mix and match and rework, reformat, translate, and transform that content to be presented to you, the end user, in the manner of your choice. So as an author, I kind of hate this, right? Hey, you took my stuff and you mangled it and you presented it in Comic Sans, and how dare you? And that’s where we are. That authors get to create information, but they don’t get to control the manner and means of distribution or presentation or formatting or language of that information. AP: On the flip side of that, and here I am going to look on the sunnier side of things, which never happens. This may be a pod person version of me. If you, as a content creator, are no longer on the hook for thinking about the publishing pipelines and all of that sort of thing, theoretically, that should free you up to create better content on the back end because you don’t have to think about all those things. Allegedly. I don’t know if it’s happening, but… SO: It’s very hard as an author to let go of that end product, the target that you’re headed for. But fundamentally, there’s a bigger problem, which is that even if I write the world’s greatest explanation of how to do something, that world’s greatest explanation of how to do something is not being presented to the end user as the thing I wrote. It’s being presented after being run through the transformer, the LLM, the processing that the AI can do when they ask for it. So I could literally write how to do X. And the end user says, hey, tell me how to do X. They are not going to get that chunk of information that I wrote. They’re going to get something reprocessed. Of course, now we ask the fundamental question, which is, is the reprocessed version going to be better or worse than what I wrote? And the answer is, it kind of depends on whether I am an above average writer with an above average understanding of what that end user wants, or whether I’m a below average writer with a below average understanding of what that end user wants. AP: To me, it’s almost irrelevant as a content creator. My version is better because if the person receiving the information via the chatbot or whatever thinks that what it’s getting or what they are getting is what they want, that’s all that really matters. That the person on the receiving end of that information gets what they want and fine-tunes it to what they want. If they’re happy with it, then the content creator’s opinion about that is, I hate to say it, immaterial at this point. SO: Yeah, I kind of hate this timeline because, you know, where does my voice, you know, where does my voice go? And the answer is it’s gone. But you’re right, of course, the purpose of again, what is the purpose of technical and product information that we work on? The purpose is to enable people to use a product successfully. So if shoving it through an AI results in an outcome where that person uses the product successfully, then we’re good. AP: I don’t disagree. SO: That’s the purpose of the kind of thing that we produce. I think, though, that looking at this, and this is where I see some of the big challenges going forward. First of all, we have to acknowledge that an enormous percentage of the technical content that’s out there is really bad. Like, terrible. Really, really bad, and might be improved by a little trip through a chatbot that’s gonna render it into actually grammatically correct English. That’s a thing. AP: Harsh but fair. SO: Yeah, I think you’re not the only one that’s going to have some bleeping issues in this podcast. But the problem that I see right now is that the metrics that are being used to measure the success of AI are all wrong. We should be measuring the success of various AI layers and chatbots and things based on are people getting what they need? AP: Yeah. Yeah. SO: Are they having a successful outcome to whatever it is that they’re trying to do? Is the search or is the process of that conversational, whatever they’re doing, does it get them to the endpoint of, okay, I understand what I need to do and I’m good and I walk away? The metric we actually seem to be using is what percentage of your workflow is using AI? How many people can we get rid of? Because “we’re automating everything with AI” is the wrong metric. The question is, how good are the outcomes? AP: To me the idea of how much AI versus human effort, there’s a lack of, shall we say, human intelligence being applied here because merely applying AI to something is fundamentally not going to make something that is incorrect, bad, whatever. It’s not going to magically fix it. That’s a huge disconnect for me when you’re talking about measuring outcomes. Whatever you dump into your large language model, if it is fundamentally bad, as in outdated and incorrect, right now, I am pretty sure merely applying AI to it is not going to fix those two pretty gaping holes. And there’s, I don’t know what it is, people hear AI and they think there’s some magic involved. No, the underpinnings have to be good for that magic to be useful, basically. SO: And I think all of us have examples of asking the chatbot a question and getting answers that are just flat wrong. Or worse, they look plausible, like they’re in the form of a plausible answer, but then you read it and you read it carefully and you’re like, this doesn’t actually say anything. It’s just word salad. Which, since a chatbot effectively is the average of the database underlying it of content pretty much means that the underlying database of content doesn’t say anything useful on this topic. So I think the place that I kind of go with this is to the question of accountability. AP: Yes. SO: Who is legally responsible for the outcomes? Now, pretty clearly, if I or an organization produces a user guide that covers a specific product and there is wrong information in that user guide, the organization is responsible. I mean, it’s your document, you’re responsible. Okay, if I, as an end user, query a public-facing LLM and get the wrong answer for something, and then I proceed to use that in my life, whose fault is that? Who is at fault when, or, you we saw this with, when the first came out, people were following the map, right, the GPS map, and it would send them off a cliff or it would send them into a construction area and they would drive off the side. Okay, whose fault is that? And the answer was always, well, it’s your fault because look up from the map and don’t drive past the sign that says, not enter construction zone cliff ahead. AP: Or one-way street. Right, yeah. SO: But AI doesn’t come with, I mean, it comes with warning labels, right? But we don’t see them. We don’t process them. What we see is a conversation where we say, tell me more about that. And it tells you more about that. And it feels as though you’re talking to a human. And therefore, when you push on something and say, are you sure? And it says yes, because what’s the typical answer when somebody says, are you sure? It’s yes. Is it actually sure? No, it’s not sentient. So if I query a public-facing LLM, it reprocesses a bunch of content and tells me how to do a thing that is in direct contradiction to what the official user documentation says, whose fault is that? I think it’s mine because I use the public-facing LLM. Now, what if the organization that makes the product puts up a chatbot and I query the organization’s chatbot? How do I do X? And especially if that chatbot is your frontline tech support, like you cannot get to a human. You have to go through the chatbot. I asked the chatbot a question, and it says, do it this way. And it happens to be wrong. Is the organization liable? I don’t know the answer, I think yes, but I’m not sure. And so fundamentally, yeah. AP: The bottom line here, yeah, we’re talking about governance here. The bottom line is governance and there is, there has to be some human AI interaction here. There has to be these guardrails that you mentioned earlier and that’s where humans have to be involved. SO: And the better the AI gets, if it’s accurate half the time, then my hackles are up. I know it’s gonna be wrong. It’s wrong all the time. If it’s accurate 80% of the time, I sort of trend it like psychologically, I just assume it’s accurate all the time. So the better they get, the worse the errors are because we don’t expect them. AP: That’s also dangerous. Yeah, right. Yeah. SO: I see occasionally, very, very occasionally, I had directions to go somewhere. And the directions were literally, put this address into Google Maps, but don’t do A, B, and C because it’s wrong. Like, the directions to get to this location are incorrect. Do not follow them. Because these days, our assumption is that the mapping apps just work. AP: And that’s it’s wrong most of the time, but I think part of this governance angle is we have to realize that AI is going to be wrong. SO: Pretty much just do. AP: And there are lots of reasons we won’t get into all the reasons that can be wrong. So what are you going to do when it is wrong? How are you going to make sure it’s not wrong? Again, there’s this whole process, this whole governance process that has to be in place. And again, I think this is where human intervention is going to be necessary because I don’t think AI at this point has any business correcting itself in these matters. That seems sort of suboptimal to me. SO: Hmm. Yeah, I mean, hypothetically, you can tell it to check itself. And certainly there’s some people doing that type of work. I think for me, fundamentally, the takeaways are that, like any other tool, there’s some really useful productivity enhancements that we can and should be taking advantage of. To your point, there’s some really important governance work that needs to be done to ensure that your QA is appropriately scaled to the level of risk of your product. Medical device, very high. Silly gaming app, pretty low. Don’t really care. And we need to think about guardrails and what it means to inject the right kind of content and the various kinds of enablement tools that you can use to do that. And finally, this issue of AI as a content customer, I think is really, really tricky because it’s a new, from our point as content creators, it is a delivery mechanism, right? Just like a PDF or a piece of HTML or anything else like that. and it’s a delivery mechanism that allows the end user to control how they access the content, which means we have to do way more work around the guardrails of what that means when they query the content and shape it to their own requirements. AP: Yeah, so things have progressed in the past two years, most definitely, especially in the content space. We’ve seen a lot of improvements. But there are still some big picture things we have to work out. And I think it’s gonna be interesting in the next year or two to see what happens. You briefly mentioned there are some companies who are setting up systems that can do a decent job of checking up on itself. That’s not where everything is right now, but I think the better these systems get, the better the guardrails that get in place, they can start to find out, this is wrong, I need to fix it, or I need to update this with the latest information, let me go get it. So that is starting to happen more and more. I think it will become more part of the LLM to chatbot process, but I don’t think we’re quite there yet. And I’m interested to see what happens next with that sort of scenario. SO: It’s definitely gonna be interesting. That much I’m sure about. AP: Yeah, I agree. So we managed to get through this without cursing. So that’s good. I think it turned out to be a more realistic conversation, and we kind of tuned out the hype because that’s what just makes me grit my teeth and sometimes yell at LinkedIn when I see certain promoted posts on LinkedIn that I think are full of you-know-what. So anyways, I think we’ll wrap it up there. Sarah, do you have any final points you would like to sign off with? SO: I think at the end of the day, when you try and contextualize, like, what is this AI thing and what does it mean for us fundamentally, we can look at some of the other sort of big picture shifts that we’ve made. I’ve been known to pretty dismissively compare it to a spell checker, you know? You can use it and it’ll fix some stuff, but you better check because it doesn’t know the difference between affect and effect, although some of the grammar checkers now maybe they do. So there’s that, but I think at the end of the day, if you are looking at content strategy, content operations and enterprise level, you really do have to say, okay, where does AI fit into my strategy and how can we employ it productively to do what we need to do inside this organization to produce, manage, deliver the content that we’re working on. AP: And I think we’re going to wrap up on that very good point. Thank you very much. SO: Thank you. 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 Alan? Register for our Ask Me Anything: AI in content ops webinar ! The post Check in on AI: The true measure of success for AI initiatives appeared first on Scriptorium .

Is this your show?

Claim this listing to keep it up to date, reach guests who want to pitch you, and manage bookings with Guestify.

Claim this listing

More Business podcasts