The Eulogy of
Any CMS System
The page had a remarkable run. The facts underneath it now need a better home.
The website. The product feed. The spec sheet. The distributor portal. The sales deck. The answer an AI assistant gives your buyer tomorrow.
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.
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.
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.
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. |
The fact itself never had a home.
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.
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.
The failure cycle
Nobody is doing this badly. The cycle is simply what you get when the fact has no home of its own.
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?
Execution
Work cannot move. You have the people and the tools, and it still slows at the seams between them.
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?
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 evidenceA 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.
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.
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.
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.
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.
Authority is earned
Autonomy is not one switch. Each class of work moves up a permission ladder on evidence, risk and track record.
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.
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.
Six layers, one job each
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.
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.
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
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.
Your supplier changed 132 products
New products appeared, some were discontinued, and several specifications conflict with what is already live on your site.
Supplier release to completion evidence
READY · 0 / 7Nothing disappeared.
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 |
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.
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.
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 loopEight 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.
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.
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