Two-Stage Content Modeling

A key way for humans and AI to co-exist in relation to a CMS repository

By Deane Barker • • 6 min read •
Author Description

By admitting that some parts of our content models are more important than others, we can structure the models to allow humans and AI to share control of them.

I’ve been wrestling with a question: how much power should AI have over your CMS repository? In particular, how much access should it have to your content models?

There’s an argument that we should let AI do whatever it wants to our models. I’ve seen lots of stories about how people are just letting AI engines modify their content models to fit the requirements of whatever output they want.

I’ve argued against this –

Queen Bees: The Resurgence of CMS Repositories in the Age of AI

My concern is that content models are foundational. Lots of things depend on them. If you change a type carelessly, you can easily break some functionality you might not even know existed.

For example –

One day, you decide not to show the “Date Published” on your blog post pages anymore. So you let AI delete that from the model – since you don’t see it, you don’t need it right? It makes it easier for editors, since it simplifies the interface.

Unfortunately, unbeknownst to you…

But, you claim, the date was a required field for these exact reasons! It was safe!

…well, it was required and safe when it existed. No property at all means no validation.

And this is my biggest concern with not being jealously protective of our content models. It’s short-sighted to build them based only on what you can see or what output you want. It’s just as short-sighted to modify them based on the same criteria.

I had a debate about this some years ago with my friend Allan Thraen. I think it was just after I taught a CMS class for Hack Your Future in Copenhagen. In that class, we were letting students add stuff to their models all they liked.

The students had a great time, and I briefly caught myself thinking that maybe we were too strict over our models? That led to a discussion that resulted in this post:

Repouring the Foundation: The Perils of Content Modeling on the Fly

And Allan responded with this:

The Curious Case of Content Modelling

Which brings me back to the core question: should we let AI into our models?

Sure, sure, in a perfect world, the AI engine would have a ton of context. In our example from above, it would know that the “Date Published” property was being used in all those different ways and would know not to touch it.

But in my earlier post, I also made this point:

I get a little skeptical when people talk simply of “AI” as if they can guarantee that all their employees will be using the same engine with the same settings and the same context.

In reality, I think we need to say “an AI” to represent that every AI is like a new freelance contractor that shows up to do a job, without knowing any other contractor that has worked in the past or may be working right now.

One solution, of course, is just to deny content model permissions to anyone but a selected few technically-minded people. And this is great… but now we’re back to the original state of not allowing AI in either.

Something else I said in that post:

AI will simply magnify the volume of activity a single human can initiate

Put another way: with AI, people can do stupid things at scale.

So, how do CMS and AI get along? How do we empower the amazing things that AI will allow and prevent disasters?

I got to thinking about this out loud on a Content Matters podcast episode with Dave Hillis, the CMO of Ingeniux. Dave and I go way back, and he thinks pretty deeply about CMS. He had read the blog post from above, and that kind of framed our conversation about how CMS and AI are going to get along in this brave new world.

An example I always use in modeling is a field for “Mood.”

Let’s say we want to add “Mood” to our content model, to represent the mood the CEO was in when she wrote whatever she wrote. This is kind of silly, but it represents something that might be added to a model on a whim only to be deleted later. Also, it doesn’t affect anything else – it’s harmless, essentially. As a developer, I don’t much care if they have this property on their model or not.

So, how do we enable this level of manipulation? How do we let an editor tell AI to add a “Mood” property so they can type stuff in a textbox and have it output on the page?

I think the solution is two-stage modeling. We’re going to need to concede that not all parts of our model are equally important – some parts of it need to be protected and some don’t.

We can divide the properties on our types into two “stages” then (in quotes because I don’t know if that’s the right nomenclature; I’m still thinking about it):

Implicit in this is that AI acting as an agent of the user (…right?!) would have delegated access to Level 2, but no access to Level 1. Level 2 would effectively be a “sandbox” where nothing structural was attached.

The key is that the effective content model is the combination of those two. The actual model of content delivered downstream is both levels together, as one unit. Nothing outside of the modeling system even needs to know they exist at different levels of import.

For a blog post, what goes in Level 1? I’m thinking just Title and Date Published? Those are basically required – the date for the reasons we mentioned above, and the title just because we have to list content objects somewhere (lots of systems will default to “Untitled” because without a name, content gets hard to work with).

What about Body? …meh. Maybe?

You technically don’t need a body for a blog (a tweet might be considered a title with no body?). Additionally, as a developer, I’m not sure I care much about the body? It needs to be output in the template, sure, but that might not be my concern. And by putting this on Level 2, editors can change it – they might want different validation or different rich text options or whatever. If someone else is doing the templating, then a lot of becomes less crucial.

Now, to be clear, lots of systems can already do this via various features.

But, of couse, this all comes down to granular modeling permissions. If you don’t have that – meaning users just have binary, all or nothing access to modify the models – then I’m not sure any of this matters.

Assuming we have that level of permissions control, these model architectures work well. In addition to being efficient and reducing repetition, they have some neat two-stage implications and allow you to segregate parts of your model into the important stuff… and all the other stuff.

Given that the required permissions and architectures already exist, then what are we talking about here, in terms of CMS evolution?

Nothing, really. We’re just talking about modeling practices, effective permission management, and making sure we treat AIs as extensions of humans – no AI should have more access than the person who can give it a prompt.

With this in place, we’re a step closer to living in harmony.

Links from this – Queen Bees: The Resurgence of CMS Repositories in the Age of AI August 10, 2025
We're gonna need to get back to the boring basics if we're going to survive the next decade.
Links from this – Repouring the Foundation: The Perils of Content Modeling on the Fly April 7, 2019
Editors sometimes want to change content models on the fly. This is rarely a good idea.
Links from this – Case Studies of CMS-to-SQL Decoupled Publishing December 28, 2016
Two examples of updating SQL databases from a CMS.
Links from this – Multi-stage Templating as Progressive Denormalization March 21, 2017
Templating often isn't single-step. Progressive refinement has a necessary place in content delivery.
Links from this – What Is and Isn't Considered "Content"?
Not everything in a system is treated as "first order" content.