The Eulogy of
Any CMS System
The page had a remarkable run. The facts underneath it now need a better home.
1 minute · Opening
Open with the title, then pause. Let the word eulogy sit there.
Be clear about what this is not: it is not a prediction that websites disappear. It is an argument that a content management system can no longer be the authoritative operating layer for what a company knows.
The page stays useful as an output. It has become the wrong durable unit.
The website. The product feed. The spec sheet. The distributor portal. The sales deck. The answer an AI assistant gives your buyer tomorrow.
1 minute · The hook
Ask it and wait. Nobody in the room can answer it, and everybody has felt it.
Then name the reason, plainly: this is not a discipline problem and it is not a staffing problem. It is what happens when the durable unit of your digital operation is the page.
Digital work fails in three ways
Everything in the next hour comes back to these three — including the part where I show you how to prove it, on your own work.
2 minutes · The memory hook
This is the slide the room should still be able to repeat next week. Say the three words slowly and let each one land.
Tell them plainly that you are going to return to these three at the end, and that the middle of the talk is the explanation of why they happen and what to do about it.
Naming the takeaway up front is not a spoiler. It gives everything that follows somewhere to attach.
From pages
to canon
This is not a history of how websites were built. It is a history of one thing: what the industry treated as the unit worth keeping.
1 minute · Chapter open
Set the frame explicitly so nobody expects a nostalgia tour. We are tracing one variable across forty years — the durable unit.
It has changed three times. It is changing again now, and that fourth change is the whole reason we are in this room.
The unit of truth has changed three times
The file
A person edited a document and uploaded it. Truth lived wherever the last edit happened.
The page
A database assembled a page for every visitor. Anyone could publish without a developer.
The content entry
Content separated from presentation so one entry could serve a site, an app and a feed.
The verified claim
A single statement that carries its own source, owner, state and validity.
2 minutes · The four units
Walk left to right. Each step was a genuine advance and each one was the right answer to the problem in front of it.
The file solved distribution. The page solved editorial access. The entry solved delivery.
Then stop on the fourth column and say: this one is different in kind, not degree. The first three are all containers for prose. The fourth is a fact that can be checked.
Three publishing architectures
| Model | Durable unit | What it solved | What remains unsolved |
|---|---|---|---|
| Legacy CMS | The page | Editorial publishing — anyone could publish without a developer | Facts stay fused to presentation. Change one, hunt for the rest. |
| Headless CMS | The content entry | Delivery across many front ends from one source | An entry is still a page-shaped container. Fact governance depends on discipline. |
| Canon-first | The verified claim | Authority, provenance and propagation that happen by architecture | Requires clear ownership and an operating model to run it. |
2 minutes · Architecture comparison
Be fair to every row. Legacy CMS solved a real publishing problem. Headless solved a real delivery problem. Neither was ever trying to govern a fact as an object, because nobody needed them to.
Canon-first is not a better CMS. It works at the layer beneath pages and entries, and it changes what the delivery layer is allowed to own.
This is the slide that answers "how is this different from headless" — expect that question and pre-empt it here.
The fact itself never had a home.
1 minute · The turn
This is the hinge of the first chapter. Deliver it slowly and do not soften it.
A file, a page and an entry are all boxes that hold words. None of them knows what a fact is, where it came from, who owns it, or when it stops being true.
So the question becomes: what would it look like if the fact had a home of its own?
Anatomy of a trusted claim
A fact becomes reusable the moment a system can say what it asserts, who owns it, and why anyone should trust it.
A sentence on a page carries none of that. A machine reading it has to infer authority from a paragraph and a template — and it will infer wrong.
2 minutes · What a claim is
Do not skip this. Everything for the next forty minutes depends on the room holding a picture of what a claim actually is.
The sentence is illustrative. The structure around it is the point — source, owner, state, validity. Confidence can be recorded too where it matters.
That structure is the entire difference between content and canon.
Where work
gets stuck
The unit is an architecture problem. What it does to your week is an operating problem — and that is the part the business actually feels.
1 minute · Chapter open
Move from architecture to operations. Nobody in a leadership seat cares about durable units in the abstract; they care that things take too long and nothing closes.
1 minute · The core sentence
This is the single most important sentence in the keynote. Say it once, pause, and do not explain it immediately — the next slide explains it.
The failure cycle
Nobody is doing this badly. The cycle is simply what you get when the fact has no home of its own.
2 minutes · The cycle
Walk it once, then ask the room how many of them have personally been step three. Hands go up, and the rest of the chapter lands on people who have already agreed with you.
Make the last line generous. This is not a competence problem in anybody’s organisation.
Capacity
Work cannot start. The queue expands faster than the team can absorb it.
open items
Product pages wait on content. Search improvements wait on developers. Application changes wait on IT.
The proof question. Can the operating model create measurable additional capacity without adding an internal role?
2 minutes · Capacity
Nothing is broken here. Work simply arrives faster than the organisation can absorb it — and adding another tool usually lengthens the queue rather than shortening it, because nobody owns execution.
The number is illustrative. If you have a real one from a client, use it and say so.
Execution
Work cannot move. You have the people and the tools, and it still slows at the seams between them.
2 minutes · Execution
Everyone completes their own piece and the initiative still stays open. The problem does not live inside any one team — it lives between tools, teams and definitions of done.
The proof question: can the model shorten the distance between instruction and production?
Accountability
Work cannot close. Everyone owns a piece. Nobody owns completion.
The proof question. Can completion become as visible and owned as the activity leading up to it?
2 minutes · Accountability
Draw the distinction carefully: this is not lateness. Lateness has an owner. This is work where nobody owns the word done.
Activity is visible everywhere. What leadership cannot see is whether the end-to-end outcome has an owner at all.
Name yours before you fix anything
Work cannot start
The queue grows faster than it clears.
Measure added throughputWork cannot move
Handoffs and decisions consume the schedule.
Measure cycle timeWork cannot close
Completion has no single observable owner.
Measure closure and evidence1 minute · Diagnostic close
Give this away as something they can use on Monday whatever they decide about us. It turns a complaint into a testable operating problem.
Ask them, silently, to pick their own. Then make the connection back: all three get worse when the durable unit is the page, because all three are really questions about facts living in too many places.
A new
operating model
Two changes, and they only work together. The unit of truth changes from the page to the claim. And the system, not the person, becomes the thing that moves the work.
1 minute · Chapter open
Flag that these are two separate changes and that either one alone fails. A canon nobody operates is a database. An agentic system with nothing trustworthy to operate on invents plausible nonsense.
We call it a canon
A canon is the authoritative body of work — the accepted texts, as against everything else anybody ever wrote.
Your complete, verified, machine-legible body of claims
Each one bound to the thing it concerns, carrying its own source, owner, state and validity. Every page, feed and answer is composed from it.
How you know whether you have one
Point at a single fact about your business. Can you say where it came from, who owns it, and when it stops being true? Then it is canon. If it only exists as a sentence inside a page, it is prose — and prose does not survive.
2 minutes · Naming the canon
The etymology does the work — one sentence and the word stops feeling invented. It also has a foot in vocabulary developers already have: canonical URL, canonical source of truth.
Say "a canon", never "our Canon". No possessive and no trademark. A term that sounds owned dies; a term that sounds needed travels, and the credit comes from being the person who defined it in the room.
Hand them the test so they can apply the word without you. People adopt terms they can use themselves.
Ownership boundaries
Domain systems own facts
Your product, finance and operational systems stay authoritative for the data they create. Nothing downstream writes back to them.
The canon governs claims
It carries source, owner, state and relationships — without trying to own every source fact in the business.
Rendering stays disposable
Pages, feeds, documents and agent responses are all regenerable from approved knowledge. None of them is precious.
Orchestration cannot invent
The layer that assembles output is never allowed to author a new fact of its own. It composes; it does not assert.
2 minutes · Boundaries
These four are the ownership argument, and they are what make the system safe to run continuously.
The last card is the trust anchor. An assembly layer that can author facts is a liability. This one composes and never asserts — say that sentence exactly.
The practical consequence: replacing a website stops meaning migrating your company’s authority out of page templates.
Three parties, three jobs
Direction and authority
Sets priorities, supplies authoritative knowledge, and makes the decisions only you can make.
The operating loop
Structures the work, drives execution, and owns it through to completion.
State and evidence
Preserves instructions, history, provenance and completion evidence across every handoff.
The customer does not become a project manager for WebriQ.
2 minutes · Who does what
Read the last line out loud. It is the most reassuring sentence in the whole model and it is the difference between an operating partner and one more vendor to manage.
The second column is where the honest answer to "can we build this ourselves" lives. The parts are buyable. Running the loop week over week is the hard part.
How work moves, end to end
Every approved result enriches the canon that supports the next cycle. Month twelve carries more approved context than month one.
2 minutes · The pipeline
The work itself is the operational unit here. Each item carries what it needs to move: owner, dependencies, approvals, history and evidence of completion.
Step seven is what makes this infrastructure rather than a campaign. Evidence comes back, and what comes back is added to the canon.
Authority is earned
Autonomy is not one switch. Each class of work moves up a permission ladder on evidence, risk and track record.
1 minute · Governed autonomy
State the limits before anyone asks. Volunteering them unprompted is what makes the rest believable.
Three things never bend. Any brand-new public claim about the business stays at human-approves permanently, whatever the track record. Contradictions surface rather than resolve themselves. And levels fall as easily as they rise — spot-checks continue, and a class of work drops back automatically if they start failing.
If asked how a level is earned: roughly 98% approval across the last two hundred items of that specific kind of work.
How it actually works
I am going to name every part of this. Not because you need it to make a decision — because if I do not name it, this is just somebody telling you he has magic.
1 minute · Transparency
Thirty seconds, and do not skip it. This buys more credibility than the architecture slides themselves.
Everything ahead is built from named, mostly open-source parts. You could assemble them yourself. What is hard is not the parts.
Two ways in. One canon. Two tracks out.
Above the canon sits the review queue: nothing enters unapproved, and every approval is recorded and reversible.
2 minutes · The system
Walk it left to right and take your time. This is the most important picture in the keynote.
The two ways in behave differently and never blur. Product truth is copied one way only. Expertise is read and separated into claims that each carry a source.
Then the line that matters most: delete every page you have. If the canon survives, you have lost nothing, because the pages regenerate.
Six layers, one job each
2 minutes · Layers
Each layer owns one job and hands off cleanly. The canon holds truth. Orchestration moves work. Rendering stays stateless and replaceable.
The same six, with the real names on them
| Layer | Named components | What they do |
|---|---|---|
| Sources | PIM, ERP, APIs, documents, websites, calls and media | Supply product data, business knowledge and evidence. StackShift II reads them and does not write back. |
| Ingestion | Parsers, normalisation pipelines and AI extraction agents | Convert source material into proposed facts, claims, relationships and metadata. Nothing becomes canonical here. |
| Canon | Supabase, PostgreSQL and pgvector | Holds approved semantic objects, sources, relationships and approval history. The Canon is the only source of truth. |
| Orchestration | StackShift II workflow and composition engine | Turns business instructions into planned work, routes decisions, applies permissions and defines each required output. |
| Operations | AI agents, automation and WebriQ specialists | Execute the work. People retain approval wherever business authority, judgment or risk requires it. |
| Surfaces | Next.js, Vercel, applications, APIs, feeds, JSON-LD and MCP | Render human and machine outputs from the Canon. Every surface remains replaceable and holds no independent truth. |
No CMS is required. If a customer insists on Payload CMS, it receives approved content as a read-only delivery surface. Payload remains outside StackShift II and never becomes a source of truth.
1 minute · The named stack
The technologies matter less than their boundaries. Source systems provide input, but the Canon alone holds approved truth. pgvector belongs inside the Canon rather than forming a separate layer.
Orchestration determines what work must happen and routes the required decisions. Agents, automation and WebriQ specialists execute that work. Human authority remains wherever judgment or risk requires it.
The delivery layer can use Next.js and Vercel, applications, feeds, APIs or MCP endpoints. StackShift II does not require a CMS. Payload CMS can be connected as a read-only output when a customer requires it, but Payload is not part of StackShift II and cannot author or override canonical knowledge.
One truth, two tracks
Rendered experiences
Web pages, applications, articles, FAQs, documents, newsletters and social content.
Retrievable knowledge
Structured claims, APIs, feeds, search indexes and context for agents.
Both tracks resolve to the same approved knowledge. You should never publish one truth for people and assemble another for machines.
1 minute · Two tracks
Anyone can bolt structured data onto a website — that is an SEO plugin and it has existed for a decade. Bolted on, it is a second copy maintained by hand and it drifts the moment somebody misses one.
Generated from the canon, the two tracks cannot disagree, because they are the same facts rendered more than once. Accuracy stops being a discipline and becomes a property of the system.
Human authority stays. Human labour does not.
Scale and consistency
- Parsing and comparison
- Classification and routing
- Assembly and validation
- Evidence capture
Authority and judgment
- Material factual decisions
- Business priorities
- Risk exceptions
- What counts as done
1 minute · The boundary
The aim is not to keep a human click in every workflow. It is to keep human authority exactly where judgment, risk or ownership requires it — and nowhere else.
Land the reframe: you stop producing and start deciding. Deciding takes minutes. Producing never fitted into anyone’s week to begin with.
How would you know it works?
Not a software tour. A piece of real work, with a real instruction, and an outcome you can audit afterwards.
1 minute · Chapter open
Say plainly that this is an operating relationship, so a feature tour proves very little. The only evidence that counts is real work moving.
Your supplier changed 132 products
New products appeared, some were discontinued, and several specifications conflict with what is already live on your site.
2 minutes · Example setup
Ask who in the room has lived this week. Hands go up, and the demonstration then lands on people who already believe the problem.
Point at how short the instruction is: an outcome and a guardrail. No ticket, no spreadsheet of assignments, no project plan. The customer defines done and where the line is; everything after that is the operating model’s problem.
Supplier release to completion evidence
READY · 0 / 75 minutes · The demonstration
Use the blue button. Advance one step at a time and narrate what changes in the four counters — that is where the story lives.
Do not rush to the end. The moment that matters is step three, when 132 unclassified items resolve into 114 routine and 18 exceptions. Everything before that is setup; everything after is consequence.
If the room is quiet, ask: how long would this batch normally sit?
Nothing disappeared.
2 minutes · The result
Say the second line slowly. In most organisations some fraction of a batch like this simply evaporates, and nobody can say which fraction.
The point is not that a machine did 114 things. It is that 132 things arrived, every one of them ended in a known state, and only four of them needed you.
One batch. All three answered.
| Failure mode | What the batch would normally do | What happened instead |
|---|---|---|
| Capacity | 132 items join a queue nobody has room for | The operating model absorbed the batch |
| Execution | Everything stalls at the first conflicting specification | Routine work moved while exceptions took the decision path |
| Accountability | Some items get done; nobody can say which | Every item ended with a state and completion evidence |
1 minute · Closing the loop
This is the payoff for naming the three words at minute three. One piece of work, all three failure modes answered, and the room can see the connection without being told.
How you would test it
This part is not a pitch. It is how I would tell anyone to evaluate an operating change — ours or somebody else’s.
1 minute · Chapter open
Say the second sentence exactly as written. This chapter is a procurement-literacy section, not a close.
If it starts feeling like a sales pitch, you have lost the room. Keep it in the second person and keep it general.
A proof of concept and a pilot answer different questions
| Approach | The question it answers | What it runs on | Where it falls short |
|---|---|---|---|
| Proof of concept | Does the technology function? | Sample data, a sandbox, the vendor driving | Proves the software works. Says nothing about whether your work moves. |
| Pilot | Can we run the product? | Your environment, limited scope and users | You end up evaluating software, while the real constraint is capacity, execution or accountability. |
| Operating test | Does our work actually move? | Real workload, real decisions, real evidence | Needs a named failure mode and a real workload — you cannot test it on a hypothetical. |
An operating relationship cannot be proven by a demo, because the thing being tested is not the software. It is whether work finishes.
2 minutes · PoC vs pilot vs operating test
This is the most useful slide in the chapter and it works whether or not anybody ever buys from us. Deliver it as a framework, not an offer.
Be genuinely fair to the first two rows. A proof of concept is the right instrument when the question really is "does this technology function". A pilot is right when you are buying a product.
The distinction that matters: when you are buying an operating model rather than a licence, the only meaningful evidence is real work with real decisions in it.
Bring the backlog
A bounded backlog or a recurring workload the internal team cannot absorb.
Prove: measurable additional capacityBring the stuck initiative
Something that should already be finished, or that moves far too slowly.
Prove: a shorter distance from instruction to productionBring the fragmented workstream
Work split across teams, vendors and systems, where nobody owns completion.
Prove: a closed and observable loop1 minute · Pick one
The operating rhythm is the same in all three. What changes is the failure mode and the measure of success.
Say the warning plainly: pick one problem. Trying to transform all of digital operations in eight weeks is how these tests fail.
Eight weeks is usually enough
Weeks 1–2
Diagnose. Scope the workload, define constraints, establish the baseline you will measure against.
Weeks 3–4
Instrument. Configure the queue, the instructions and access. Run the first live cycle.
Weeks 5–6
Operate. Run live cycles, expose the blockers, tune the approvals.
Weeks 7–8
Measure. What moved, what stayed blocked, and what a larger commitment would actually require.
1 minute · The rhythm
Weeks one and two are the ones people skip, and skipping them is why tests end in argument — with no baseline, nobody can agree afterwards whether anything changed.
What you keep, whatever you decide afterwards
Baseline
A clear picture of how the selected work moved before the test.
Operating queue
Live work with owners, states, dependencies and decisions.
Completion evidence
A record of outputs, unresolved items and outcomes.
Expansion plan
A grounded view of the next 90 days, based on work you actually watched move.
These are assets you keep. That is what separates a test from a pitch — and it is the only reason a test is worth running at all.
1 minute · What survives
End the chapter here. Do not put a price on a slide at Tech Week — if somebody asks the number, answer it directly and move on.
The point of this whole chapter is that they should demand these four artefacts from anyone selling them an operating change, including us.
Capacity. Execution. Accountability.
The page could never fix any of the three, because it was never built to hold a fact. A canon can, and an operating model around it is what makes that real.
Alex Belding · WebriQ · webriq.com
2 minutes · Close
Return to the three words and say them in the same order you used at minute three. That repetition is the whole reason the room will remember this talk next week.
Then end on the work, not the technology. The closing question invites a conversation about real operations, and it is a far better last line than a thank-you slide.
Hold the room for questions. The ones to expect: is WordPress dead, does the AI publish on its own, is the machine track just SEO, can we build this ourselves, and what does it cost.