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. This is not a prediction that websites disappear. The argument is that a content management system can no longer serve as the authoritative operating layer for a company’s digital knowledge.
The page remains useful as an output. It has become the wrong durable unit.
More tools.
Harder operations.
Every new channel increases the number of places where a business fact can be copied, reformatted and forgotten.
Website
Applications
Search
AI systems
The problem grows because each surface can become a separate editorial reality.
2 minutes · Context
Companies keep adding tools because each one solves a local delivery problem. That creates more places where a fact must remain correct. Teams respond by adding integrations, governance meetings and manual checks.
Ask the audience: if one certification changes this morning, can you name every public and machine-facing surface that must change?
2 minutes · The durable unit
The CMS made the page the durable unit. Headless systems improved delivery, but an entry still often behaves like a page-shaped content container.
A claim has a different lifecycle. It needs an owner, source, approval state and validity. The page should be assembled from governed claims.
Three publishing architectures
| Model | Durable unit | What it solved | What remains |
|---|---|---|---|
| Legacy CMS | The page | Editorial publishing | Facts remain fused with presentation |
| Headless CMS | The content entry | Delivery across front ends | Fact governance depends on discipline around the CMS |
| Canon-first | The verified claim | Authority, provenance and consistent propagation | Requires clear ownership and an operating model |
3 minutes · Architecture comparison
Be fair to each architecture. Legacy CMS solved a real publishing problem. Headless solved a real delivery problem. Neither directly governs the fact as an independent object.
Canon-first addresses the layer underneath pages and entries. It does not make the delivery layers useless. It changes what they are allowed to own.
Anatomy of a trusted claim
A fact becomes reusable when the system can explain what it says, who owns it and why anyone should trust it.
2 minutes · Claims
The sentence shown is illustrative. The key point is the structure around it. A claim is useful to a machine because its authority and provenance do not have to be inferred from a paragraph or template.
Confidence can also be recorded where needed. The source document identifies source, confidence, approval state and validity window as core claim metadata.
Ownership boundaries
Domain systems own facts
Product, finance and operational systems remain authoritative for the data they create.
The Canon governs claims
It carries provenance, approval and relationships without pretending to own every source fact.
Rendering stays disposable
Pages, feeds, documents and agent responses can be regenerated from what the organization has approved.
2 minutes · Boundaries
The orchestration layer can assemble output, but it cannot quietly author new facts. Data flows one way from the system that owns a fact into the Canon.
This boundary makes rendered output disposable. Replacing a website no longer means migrating the organization’s authority out of page templates.
The Canon is the only source of truth.
Websites, applications, search, feeds and agent-ready outputs are generated from approved canonical knowledge.
Everything downstream is replaceable and regenerable.
3 minutes · Chapter close
This is the central thesis. StackShift II does not contain or require a CMS. The Canon is the only source of truth, and the orchestration and rendering layers generate every delivery surface from approved canonical knowledge.
When a customer insists on retaining one, Payload CMS can operate downstream as a read-only compatibility layer. It receives approved content from the Canon but cannot author, govern or return changes to it. Payload CMS remains outside StackShift II.
Transition: once the durable layer changes, we still need to solve an operational problem. Knowledge does not move itself from instruction to production.
Where work
gets stuck
The blockage usually comes from insufficient capacity, broken execution or fragmented accountability.
1 minute · Chapter 2
Introduce the three failure modes. They can coexist, but separating them matters because each requires a different proof.
Capacity
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.
2 minutes · Capacity
Nothing may be broken. The work simply arrives faster than the organization can absorb it. Adding another tool can even add to the queue if nobody owns execution.
The proof question: can the operating model create measurable additional capacity without adding another internal role or unmanaged vendor?
Execution
The organization has people and tools. Work slows at the seams.
2 minutes · Execution
Each participant may complete their assigned piece while the overall initiative remains unfinished. The problem lives between tools, teams and definitions of done.
The proof question: can the model shorten the distance between instruction and production?
Accountability
Nobody owns the finish.
Marketing
Owns the objective
IT
Owns infrastructure
Agency
Owns a deliverable
Leadership
Still asks whether the whole thing finished
2 minutes · Accountability
This differs from a simple delay. Activity may be visible everywhere. What leadership cannot see is whether the end-to-end outcome has an owner.
The proof question: can the model make the finish as visible and owned as the activity that precedes it?
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
Use this simple distinction to move from complaint to testable operating problem. Transition to the StackShift II model that puts one operating spine around the work.
From direction to done
2 minutes · Operating model
StackShift II makes the work itself the unit of operation. Each item carries the context needed to move, including its owner, dependencies, approvals, history and completion evidence.
Three parties, three jobs
Your team
Sets priorities, supplies authoritative knowledge and makes decisions only it can make.
WebriQ
Structures the work, drives execution and owns the operating loop through completion.
The system
Preserves state, instructions, history, provenance and evidence across every handoff.
2 minutes · Roles
The customer does not become a project manager for WebriQ. Their team supplies authority where required. WebriQ drives the work. The system makes the process observable.
The seven-step pipeline
Every approved result enriches the record that supports the next cycle.
3 minutes · Pipeline
Advance each stage with the right arrow. Emphasize that approval is not a universal manual gate. Routine work can move according to earned permissions. Exceptions and material decisions return to people.
The record compounds. Month twelve carries more approved context than month one.
Authority is earned
Each kind of work moves through a permission ladder based on evidence, risk and track record.
3 minutes · Autonomy
Autonomy is not one switch. It is set separately for each kind of work, and every rung must be earned. High-risk or novel decisions stay with people. Routine, reversible work can advance after the organization establishes a track record.
Your supplier changed 132 products
New products appeared, some were discontinued and several specifications conflict with what is already live.
2 minutes · Example setup
This is a realistic operating problem rather than a software demo. The customer defines the outcome and the guardrail. StackShift II coordinates the work from there.
Move to the next scene and advance the seven stages manually.
Supplier release to completion evidence
READY · 0 / 76 minutes · Live demonstration
Use the blue “Advance one step” button. The deck arrow remains reserved for changing scenes.
Pause at classification. The example divides 132 items into 114 routine changes, 18 exceptions, including 4 material conflicts. The counts illustrate the source demonstration. Explain that only material conflicts and exceptions return to the customer.
At release, all 132 items have a known outcome. Routine changes complete, approved exceptions complete, and excluded items retain evidence of their state.
132 changes came in.
Nothing disappeared.
Capacity
The operating model absorbed the batch.
Execution
Routine work moved while exceptions followed a decision path.
Accountability
Every item ended with a state and completion evidence.
2 minutes · Example close
The result is not merely that pages changed. The business can account for all 132 inputs and explain the handling of each one.
The six layers
2 minutes · Layers
Each layer owns one job and hands off cleanly. The record holds truth. The orchestration layer moves work. Rendering stays stateless and replaceable.
Human authority in the loop
Scale and consistency
- Parsing and comparison
- Classification and routing
- Assembly and validation
- Evidence capture
Authority and judgment
- Material factual decisions
- Business priorities
- Risk exceptions
- Permission changes
2 minutes · Human loop
The aim is not to keep a human click in every workflow. The aim is to keep human authority where judgment, risk or ownership requires it.
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.
2 minutes · Two tracks
A company should not publish one truth for people and assemble another for machines. Human and machine surfaces can render differently while drawing from the same governed record.
A bounded test of an
operating relationship
Choose one meaningful workload. Put it through the model for eight weeks. Measure what changes before making a larger commitment.
1 minute · Foundry
StackShift II is an operating relationship, so a conventional software demo provides weak evidence. The Foundry uses a real slice of work and a defined outcome.
Capacity Foundry
Bring a bounded backlog or recurring workload the internal team cannot absorb.
Proof: measurable additional operating capacityExecution Foundry
Bring an initiative that should already be finished or moves too slowly.
Proof: shorter distance from instruction to productionAccountability Foundry
Bring a workstream fragmented across teams, vendors or systems.
Proof: a closed and observable accountability loop2 minutes · Three paths
The operating rhythm remains the same. What changes is the failure mode and the measure of success. Pick one problem rather than trying to transform all digital operations in eight weeks.
The eight-week rhythm
Diagnose
Scope the workload, define constraints and establish the baseline.
Instrument
Configure the queue, instructions, access and first live cycle.
Operate
Run live cycles, expose blockers and tune approvals.
Measure
Review what moved, what remained blocked and what a 90-day expansion would require.
3 minutes · Eight weeks
Weeks one and two establish the baseline. Weeks three and four turn the selected workload into live work. Weeks five and six operate and tune the system. The final two weeks measure the selected failure mode and define a possible expansion.
What the Foundry leaves behind
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 observed work.
2 minutes · Deliverables
The Foundry creates assets the customer retains, including the work produced and the operating evidence. It should end with a decision based on observed performance, not a sales promise.
Simple and bounded
A fixed eight-week engagement tied to one failure mode and one agreed definition of success.
Fully creditable
Credited against months 1–3 of a StackShift II engagement signed within 30 days of completion.
Availability: two Foundry slots per month.
1 minute · Commercial terms
State the terms plainly. The fee is fixed and one-time. Conversion credit applies to an engagement signed within 30 days of Foundry completion. Two slots are available per month.
What meaningful work
should we put through the model?
Choose the failure mode. Define the evidence. Let the work answer the question.
1 minute · Close
End on the workload, not the technology. Invite discussion around a real operation that is constrained by capacity, execution or accountability.