The company in question is a medium-sized enterprise in the knowledge industry. The tool that wowed them in the demo was supposed to revolutionise how the company accessed, shared, and collaborated on internal knowledge.

Instead, it scaled chaos. Incoherence. Inaccurate answers. More noise than signal.

The root cause? The knowledge base the tool was feeding from was itself chaotic. Contradictory terminology. Duplicated resources. Conflicting definitions and messaging across departments.

The AI faithfully synthesised everything it found – which is to say, it faithfully synthesised the confusion it was given to work from.

AI doesn’t create organisational knowledge. It reveals how well it already exists.

The recommended fixes from the vendor: better data quality upstream. Consider creating a knowledge graph.

Both are the right tools for a different class of problem to this one, though.

Data engineering is the right tool for AI applications that process quantitative data. Predictive analytics, financial forecasting, fraud detection, and so on.

It solves for quantitative systems: forecasting, fraud detection, optimisation.

But knowledge AI operates on language.

That’s a different class of problem.

Similarly, knowledge graphs only add value once the foundational fundamentals of canonical substance, clean taxonomy, and content modelling have been applied to the knowledge base.

If either condition is present, the constraint isn’t engineering.

It’s editorial.

Most knowledge-industry companies begin by framing AI investment decisions as an engineering conversation, with the first-order action being: build a system or procure one.

Then, when performance doesn’t meet expectation, they work backwards through failure layers until they reach the root cause: the organisation’s knowledge material is the bottleneck, not the AI itself.

The transformation they’re chasing is more epistemological than technical.

This is an article about the sequence that prevents that.

The sequence less-followed

There is a sequence to knowledge AI implementation that works. It runs in this order:

1. Editorial substance

Content is canonical, coherent, accurate, current, and consistent enough, not only for human users to easily understand and use it, but for AI users too. This is the foundational layer. It’s the least exciting investment, but nothing can actually be built above this foundation if it’s broken.

You cannot structure incoherence. You cannot retrieve meaning from noise.

2. Information architecture & content modelling

Once the substance is sound, this layer structurally organises it: mapping the territory so retrieval systems can navigate it. Information architecture sets the organising logic – category schema, taxonomy, navigational labelling, metadata. A content model defines what different types of content are, how they relate to each other, and what they mean within the broader business domain. Together, they produce the semantic architecture that knowledge representation can encode.

3. Knowledge representation

The encoding of that modelled content in formats that retrieval and AI systems can process: embeddings, indexes, knowledge graphs, context packages. This layer is where the engineering work begins – but it is entirely dependent on having something worth encoding.

4. Retrieval and context

The AI tool. The interface. The thing that gets demo’d in procurement conversations, evaluated by vendors, celebrated in launch announcements… and blamed in post-mortems.

The sequence matters because each layer is a prerequisite for the one above it.

Retrieval cannot outperform the knowledge representation feeding it. Knowledge representation cannot impose structure on content that has none. Content modelling cannot organise material that is incoherent at the substance level.

Remove the foundations and the ceiling drops. Categorically.

The tool doesn’t perform slightly worse. It fails in a way that no subsequent engineering investment can fix, because the constraint sits below the engineering layer entirely.

What’s happening instead

Almost nobody is currently following the sequence that would enable successful knowledge AI implementation.

In practice, the process runs in the opposite direction. An organisation identifies an AI technical capability (not necessarily analogous with an actual business opportunity) – usually through a vendor demonstration, a competitor announcement, or a board directive. Then, they procure a tool.

Layer 4 arrives first.

Layer 3 is addressed as implementation begins, when the tool’s appetite for structured data becomes apparent.

Layer 2 becomes visible when the retrieval results are incoherent and someone diagnoses a taxonomy problem.

Layer 1 – the substance layer – surfaces last, in the post-mortem. And even then, often misdiagnosed as a “data quality issue” in the absence of any content expertise sitting at the table.

By that point, the pattern is set.

The organisation has already invested in tooling and knowledge representation – building technical infrastructure on top of knowledge base content that was never assessed.

The fix requires going back to the beginning: what does this content actually say, and is it fit for purpose for the tool’s use case?

But that’s not what happens.

What happens is a doubling down on what the organisation already knows how to do: more engineering.

More structure. More systems. More attempts to impose order downstream.

The result: a second round of spend, a longer timeline, and the persistent belief that the problem must still be technical.

It isn’t.

The problem began before the engineering started.

Why the sequence produces a predictable outcome

The backwards pattern produces a specific failure mode that is observable, consistent, and well-documented – even if rarely diagnosed correctly.

When retrieval is built on fragmented content, the AI synthesises the fragmentation.

If Marketing uses five product names and Product uses two, and none of them overlap exactly, the tool will return contradictory answers because the source material is contradictory.

That’s not “hallucination”. The model is working correctly and within a perfectly manageable context window.

The problem is editorial source quality – which the technical post-mortem will call a data quality problem, because that’s the vocabulary available.

When knowledge representation is built before content modelling, the semantic architecture reflects whatever structure the content had when it was indexed – which is usually the structure of accumulated accident, not intentional design.

Adding embeddings on top of an unorganised, bloated knowledge base indexes the disorganisation and bloat.

And when content modelling is attempted without editorial substance underneath it, the taxonomy becomes an exercise in mapping multiple content items that shouldn’t be there in the first place.

You can assign ‘clean’ metadata to content that contradicts itself. You can seamlessly link relationships between thousands of content assets via a vector database and have it beautifully represented on a knowledge graph – even where half of the corpus added is irrelevant, contradictory, off-message, strategically at cross-purposes, outdated or just plain incorrect.

The structure works. The retrieval quality is excellent.

It’s the actual source content that’s the problem.

Why the backwards pattern keeps happening

The backwards sequence is a structural outcome of who leads AI implementation decisions and what vocabulary they use.

Many of the organisations advising enterprises on AI readiness – major consultancies, system integrators, and a lot of AI vendors – literally built their frameworks for quantitative applications and according to best practices defined through the lens of technical architecture.

Predictive analytics. Fraud detection. Recommendation engines. Process automation.

These are applications where “data quality” is precisely the right diagnosis. Where clean pipelines and normalised schemas directly determine performance.

Language-based AI – enterprise search, knowledge retrieval, document synthesis, question answering – is a different category.

The input isn’t numerical records. It’s the content of the corporate brain: knowledge bases, the website, reams of documentation, policies, external and internal communications assets, procedures, policies.

Whether that content is clear, consistent, and task-oriented is not a data engineering question. It’s an editorially-defined user experience question.

Consulting frameworks developed for the first category were applied to the second without adaptation.

And both the vocabulary and the frameworks they describe – data readiness, data governance, data quality – have been carried across, unchanged.

Because the vocabulary frames the diagnosis, the diagnosis stays in territory that data engineers can comfortably address – even when the actual problem sits way beyond what they can comfortably solve.

The actual builders of frontier AI models don’t actually have this problem. Quite the opposite.

Anthropic, OpenAI, Google, and the companies that train AI through human feedback – they value the role of content and knowledge management expertise as being at the heart of everything they’ve built. They hire content designers, content strategists, content reviewers, editors, linguists, academics, and subject domain experts.

Training AI to produce coherent outputs requires linguistic judgement and taste. The enterprises implementing those models face the same requirement.

But the consultants advising them come from a discipline that doesn’t have those capabilities – and so frames the problem in terms of the capabilities it does have.

This is how a rational system produces a consistent error. Every participant follows their own incentives correctly. The outcome is still illogical.

What this means for the next investment

Most organisations reading this have already been through at least one backwards implementation. Or are in the middle of one.

The instinct, coming out the other side, is to find a better tool. A more capable model. A vendor with a more robust retrieval architecture. These will not fix a substance problem. They will perform the same failure more expensively.

Before the next procurement decision, a content infrastructure assessment changes what gets measured. It works backwards from the question the AI will be asked – not the question of whether the technology is capable, but whether the content it will synthesise is capable.

Three things it surfaces:

Substance. Is the content coherent, consistent, and accurate enough for AI to synthesise without producing wrong answers? Are there conflicts between what Marketing says and what Product says? Are policies updated across all the documents that depend on them? Is the knowledge base 30% signal and 70% accumulated noise?

Structure. Is the content organised in a way that allows retrieval to work? Not “is there a taxonomy” – there usually is. Is the taxonomy doing the job: connecting related content, distinguishing overlapping concepts, making relationships machine-navigable?

Governance. Are there processes that will prevent the content from degrading the day after implementation? A knowledge base that passes a readiness assessment today will fail within six months without operational ownership. AI doesn’t improve content governance. It exposes its absence.

These questions should be asked before any retrieval architecture is specified, before any vendor is evaluated, before any contract is signed.

They’re not more important than the technical questions. This is not another ‘content-first’ rallying cry. Their answers determine whether the technical investment will land.

You cannot engineer your way out of a lack of editorial substance, coherence, and quality.

The engineering layer assumes quality exists. Content strategy creates it. These are not sequential options. They are a dependency chain.

The forward sequence

The backwards pattern is expensive to correct once you’re inside it. The forward sequence is not particularly complicated before you start.

Assess the content infrastructure before specifying the technical architecture. Understand what the AI will actually ingest before deciding how to encode it. Identify the editorial gaps before commissioning the retrieval system.

This sequence requires bringing content expertise into conversations that currently exclude it – not as a ‘nice-to-have supplement’ to the engineering conversation, but as the prerequisite upstream input that makes downstream engineering decisions meaningful.

It also changes the timeline. Organisations that follow the forward sequence spend longer in assessment before procurement. They invest earlier in work that has no interface, no demo, no vendor celebrating the contract.

It looks slower. It isn’t. It's simply the only way to build a system that actually works..

The implementations that deliver measurable return after twelve months are not the ones with the most sophisticated retrieval architecture.

They’re the ones that knew what their content could support before they built anything on top of it.

Most organisations try to fix AI at the system layer.

The constraint doesn’t live there.

It sits below it – in what the organisation actually knows, and how well it knows it.

Cloud computing took a decade to stabilise. DevOps sparked years of argument. Microservices still divides opinion at the edges.

But in every case, the disagreement was about implementation. The engineering community converged quickly on what the root problem was – even when how to solve it remained hotly contested.

NIST had a workable definition of cloud computing by 2011. DevOps arguments were fierce, but nobody was confused about the goal. Microservices debates were architectural – not definitional.

Engineering disciplines generate implementation debates that last years. What they don’t do is spend 24 months unable to stabilise the definition of the problem they’re solving.

Now look at AI implementation that runs on language models.

2024: prompt engineering – the problem is how you phrase the question.

2025: context engineering – no, hang on… the problem is how you architect the information environment.

And the sequence continues – in more niche corners, off-shoots of the same debate appear.

‘Intent engineering’ (no, the real skill is articulating the objectives and outcome constraints to your agent), and even ‘specification engineering’ (yes but also… let’s remember about precise specifications).

That’s not an implementation debate. It’s a discipline encountering a problem it doesn’t yet have the vocabulary to resolve.

Each new iteration a fresh attempt to name what the previous one couldn’t: the actual requirement in each case boils down to providing AI systems with coherent, relevant content assets that machines can read.

And the master skill in question is more editorial than architectural.

The category error hiding in plain sight

When disciplines fail to converge on problem definition, it usually means the problem sits outside the domain attempting to define it.

The divergence here – at the level of what the problem is – points toward a boundary condition: tools developed for one class of problems being applied to a fundamentally different class.

The current dominant term gives the game away.

Because context engineering contains a category error in its own name. Engineering implies construction – specify requirements, build components, assemble a system.

But ‘good context’ isn’t something you build. Context is what good content infrastructure produces.

You cannot engineer the output while skipping the process that generates it.

This is not an argument against context engineering. The technical discipline is real. The optimisation is legitimate.

But it operates downstream of something it cannot itself produce – and that upstream dependency is where most AI implementations hit their ceiling.

The name encodes the mistake. 18 months of core definitional language iteration, with no sign of convergence, encodes the proof.

The course correction that still can’t hold

Prompt engineering arrived first, and with confidence. Better inputs, better outputs. Courses launched overnight. Job titles appeared. The implicit assumption: the problem is how you phrase the question.

It didn’t hold. It couldn’t. Output quality turned out to depend far more on what the system could access than on how you asked.

Context engineering was the legitimate correction. The problem isn’t the question – it’s the information environment the system operates in. Retrieval architecture. Memory management. Knowledge graphs. The implicit assumption revised: fetch the model the right information, and it will produce the right output.

This is closer. It’s also the point where the unexamined premise becomes visible.

Context engineering presupposes that the information being retrieved is coherent, consistently structured, and organised in ways the system can navigate. When the underlying content contradicts itself across systems, sophisticated retrieval doesn’t solve the problem. It retrieves the contradiction efficiently.

The correction was real. The upstream assumption was still unexamined.

The engineering community hasn’t been secretly ‘doing content strategy’.

It’s been building technically legitimate systems that keep encountering the same upstream constraint – and reaching for new vocabulary each time it does.

That’s not a failure of engineering. It’s a boundary condition.

To understand the challenge of context engineering, let’s look at Pokémon.

Said no one, ever.

Oh hang on, except (checks notes)… Anthropic.

Anthropic’s guidance on context engineering is rigorous and precise. It defines the task of context engineering for AI agents as:

“Find the smallest possible set of high-signal tokens that maximise the likelihood of some desired outcome.”

That is a valid optimisation problem. Context windows are finite. Attention budgets degrade with scale. Token management matters.

But the formulation contains an unexamined premise.

High-signal… relative to what?

Signal doesn’t exist independently. It depends on coherence, consistency, and accuracy in the source material.

The guidance treats context as something to compress and route efficiently inside a model’s attention window. It does not address how that context is produced – or degraded – upstream.

The most revealing illustration appears in the article’s long-horizon task example: Claude playing Pokémon. The agent maintains detailed tallies across thousands of steps. Tracks objectives. Builds maps. After context resets, reads its notes and resumes multi-hour strategies without losing coherence.

Impressive. Except Pokémon is a completely closed system.

Every rule is defined. Every entity is specified. Terminology is perfectly consistent across the entire environment. The content infrastructure of a video game is structurally flawless.

Enterprise environments are not Pokémon.

Multiple departments. Conflicting terminology. Fragmented systems. Unclear ownership of accuracy. Policies that contradict each other.

Applying techniques proven in a perfectly specified environment to a structurally incoherent one – and expecting similar coherence – is not an engineering failure.

It is a domain mismatch.

The enterprise challenge isn’t just scale

The current engineering discourse handles the challenge of applying the principles of context engineering to enterprise scale with a kind of confident equivalence.

Solo practitioners: just get your file repos and docs into shape.

Enterprises: same challenge basically, just at a larger scale.

As if scale were the only difference. But the logical gap between them is the entire problem.

Taking a fragmented, multi-departmental, politically contested, terminologically inconsistent corpus of organisational knowledge accumulated over decades across incompatible systems – and making it coherent, consistent, and machine-readable – isn’t a ‘context engineering challenge’.

It’s a content infrastructure crisis.

The problem isn’t how you spec in work and ‘context assets’ to the agent. The problem is that the underlying content that defines context is usually not fit to be worked on by any agent.

The specification vocabulary describes what needs to happen. It has nothing to say about how.

You cannot specification-engineer your way out of thirty departments using different terminology for the same product.

You cannot intent-engineer around a substantial knowledge base when nobody owns organisational truth.

You cannot context-engineer coherent retrieval from content that contradicts itself across systems.

Why the loop keeps running

The problem iteration sequence has a structural explanation.

Engineering Bias is the first driver. When AI implementation fails, organisations reach for engineering solutions. Engineering has solved most technology adoption problems of the last three decades.

But knowledge-based AI failures aren’t technology problems. They’re editorial problems wearing technology symptoms.

The instinct to fix them technically is well-funded but consistently insufficient. The engineering quality is fantastic. It’s just applied to a problem that sits upstream of where engineering begins.

Interface Bias compounds it. Decision-makers evaluate AI by what’s visible: chatbot demos, generative interfaces, customer-facing features.

The operational applications where the majority of value lives have no demo, no vendor pitch, no competitive urgency. Investment follows visibility. Visibility is not the same as value.

Together, they guarantee that content infrastructure rarely gets assessed. Almost never prioritised.

Engineering Bias ensures the solution always stays technical.

Interface Bias ensures the problem being solved is always a visible one.

Neither registers content infrastructure as an urgent priority – so it never makes the agenda.

The problem definition iteration loop is what this compound blind spot looks like from inside a single discipline: making genuine progress, encountering the same upstream ceiling, reaching for another technical layer.

Coining another term when the reaching doesn’t land on anything solid.

The Anthropic guidance is what it looks like from the top of the stack: technically rigorous, beginning at the exact point where content infrastructure has been assumed into existence.

This is the mechanical explanation for why the majority of AI implementations stall.

Not inadequate engineering. Systemic oversight built on decades of institutional bias that favours engineering and visual design inputs over editorial judgement – even when mounting evidence shows that editorial judgement is the exact ‘hard skill’ unlock this moment requires.

Organisations investing in the engineering stack while the editorial foundation remains unassessed. Each correction technically sound. Each one discovering, eventually, that the prerequisite input expertise remained out of the picture, just as it was desperately needed the most.

The missing layer

The proliferating terms are the signal: the problem sits one layer above the domain attempting to solve it.

Engineering isn't the right domain for solving content problems. Content is.

Each iteration of the problem definition names a real prerequisite. But the pain lies in discovering each one after the expensive AI investment has been made, rather than before it.

Before deep-diving into context engineering or following the latest guidance on token efficiency – ask a more fundamental question: what can your content infrastructure actually deliver today, and what gap exists between that and your intended AI outcomes?

That’s a content infrastructure strategy question. The engineering community is multiple iterations into discovering the same thing, even if wrapped in language that makes it ‘sound engineering’.

Engineering isn’t failing to solve AI implementation.

It’s just discovering – one layer at a time – that the problem begins before engineering does.

But it isn’t the same thing.

To be clear, semantic layer engineering, linked metadata, structured context, taxonomy design, ontologies These are essential capabilities carried out by brilliant people.

They are also only one layer of the multi-faceted content ecosystem that I refer to as content infrastructure.

Content architecture or content engineering is an integral part of content infrastructure. It is not the whole of it.

Collapsing the two leads to an expensive category error. And right now, the collapse is what’s happening in most AI discourse.

Why architecture rose to the surface

AI strategy is currently shaped primarily by engineering disciplines. Not a criticism – an observation of a pattern that played out in the web era, too.

Engineering defines the technology. So engineering defines the vocabulary. And for a period, before adjacent disciplines catch up and assume authority over specific use cases, engineering effectively gatekeeps every aspect of how the technology gets applied.

The web went through this transition visibly.

1995: The internet is here. A team of developers will help us figure out how to build a website. They’ll manage it. They’ll own every aspect of it, in fact.

2005: A dedicated website team with no coding capability manages the website using a CMS. Obviously.

AI is at 1995.

When engineers evaluate what “content infrastructure” means, they pattern-match to what their discipline recognises. Semantic layers. Structured context. Taxonomy modelling. Linked data. Explicit knowledge representation. These have direct analogues in how engineers already think about systems. So they land immediately. “Ah right – LLMs require a semantic layer of engineering. Makes sense.”

“Editorially review, cut down, curate and revise your bloated, inconsistent, low-value knowledge base content” has no engineering analogue. Whatsoever.

It sounds like someone else’s job. It sounds like a much ‘softer’ job. A job without scientific rigour, at that.

In a system where funding, vocabulary, and decision rights sit inside engineering functions, architecture will always rise first. Not because it’s wrong – but because it’s most legible to the functions currently defining the vocabulary.

The result is a systematic distortion of what content infrastructure actually requires, driven not by evidence but by disciplinary resonance. Architecture rose to the surface because it speaks engineer. The other layers sank because they don’t.

This is Engineering Bias producing a measurable market outcome.

Rail infrastructure isn’t just tracks

Let’s (casually, as we all do every now and again when we’re in a philosophical mood, right?) think about what rail infrastructure actually is.

Tracks. Overhead cables. Stations. Vehicles. Maintenance schedules. Staff. Ticketing systems. Safety protocols. Operational governance.

Remove any one of those components and the system fails. No cables means no power. No maintenance schedules means vehicles break down. No operational governance means the whole thing runs erratically regardless of how well-laid the tracks are.

Content infrastructure works the same way. Three layers. Each dependent on the others.

Substance is the editorial layer – whether content is accurate, clear, consistent, relevant, and purposeful. Does the same product get described the same way across Marketing, Product, and Support – or does it have four names, three sets of specs, and two contradictory pricing structures? Can a system trust what it’s being fed?

Structure is the architectural layer – taxonomy, metadata, content models, information architecture. Whether content can be found, filtered, and connected. This is what content engineers build. It’s essential work.

Governance is the operational layer – who owns what, how content gets maintained, what happens when something changes. Without it, whatever you build in the Structure layer degrades the moment organisational reality asserts itself.

These layers operate in inter-dependence, rather than strict hierarchy or sequencing logic. They constrain and enable each other. Governance gaps degrade structure over time; structure gaps make substance harder to maintain at scale; substance failures mean the architecture is organising the wrong things.

Neglect any one layer while investing heavily in another and you’re not truly building infrastructure.

You cannot semantically engineer meaning out of nonsense

For most organisations, the root cause preventing their content from being fit for knowledge AI isn’t that it’s not semantically mapped.

It’s that the content (by machine standards if we’re being polite; but in all reality, by most human standards if we’re being truthful) is bad.

Not structurally lacking. Editorially lacking. The basics: unclear, bloated, circular, irrelevant, dense, impenetrable information. Half of which was the product of either internal politics or corporate vanity (or both), rather than the result of what anyone actually needed to know about, care about, or do anything with.

And if that’s the experience of a human reader on the average corporate website, customer support knowledge base, employee intranet – what chance does an AI stand of making sense out of it?

Linked data is a graph of semantic relationships between entities. An entity is a node. A node contains meaning.

What happens to the graph when the nodes contain the type of editorial bloat and waffle described above?

When information is inconsistent, unclear, duplicative across departments, contains non-canonical messaging, and conflicting definitions, and term variances, and basic discrepancies in core product and service names…

Is that a semantic connection and contextual retrieval problem? Yes. But more fundamentally? It’s a core meaning problem that originates in the basic production of the substance, not in the structure that’s wrapped around it.

Even an elegantly constructed semantic graph doesn’t resolve that.

Structure work amplifies whatever’s in the substance layer. Which is enormously valuable when the substance is sound. But a liability when it isn’t.

I’ve seen this in practice. Enterprise search tools deployed on content that contradicts itself across departments. The tool works. The results are reliably unreliable. Users stop trusting it within weeks. The implementation gets blamed. The real problem – that the actual substance of what’s being queried is itself, inherently incoherent – goes unexamined.

Increasing signal means decreasing noise

There’s a related insight that follows directly from this.

One of the most powerful things most organisations can do to prepare their content for knowledge AI isn’t necessarily to semantically map it. It’s to cut a significant proportion of it.

Semantic architecture applied to content bloat doesn’t resolve the bloat – it encodes and indexes it. AI retrieves the redundant alongside the relevant, synthesises across contradictions it has no way to reconcile, and produces output that faithfully reflects the input. At speed.

Humans compensated for this for decades. The redundant departmental update that nobody read or used in the first place… nor retired. The five-year-old policy document that still ranks in search. The three contradictory product descriptions that exist because Marketing, Product, and Support each wrote their own takes, in silo.

Human skimmed past all of it and extracted the signal anyway. In spite of the bloat. Inefficiently, but functionally.

AI can’t do that. Every orphaned asset, every politically-motivated page, every duplicate that survived a migration because deleting things ‘felt risky’ – all of it enters the corpus as signal.

It ingests with equal weight — no organisational memory, no basis to decide which of two contradictory descriptions is authoritative, no way to recognise an orphaned asset without a governance signal.

It will then produce output that looks like ‘bad AI’. It isn't. It's accurate AI, reporting faithfully on bad content. The AI says: you are bloat. Therefore, I will become bloat.

Increasing signal sometimes means decreasing noise. Not adding structure to it. That’s an editorial decision. It requires editorial judgement. No taxonomy schema or graph substitutes for someone deciding what the organisation actually needs to communicate – and retiring the rest.

Editorial curation is itself a form of context engineering. Maybe the most powerful form of context engineering available. But nobody’s really talking about it. Why? Because it doesn’t sound engineering enough.

The case for completeness

None of this is an argument against content engineering. The argument is for completeness.

Taxonomy design, IA, metadata systems, linked data – structure layer expertise is essential, and it requires specialist skill that most content strategists don’t have. The organisations doing this work well are ahead of most of the field.

An organisation that has invested seriously in semantic architecture – taxonomy design, linked metadata, content models – but left substance and governance untouched hasn’t completed its content infrastructure work. It has completed one layer of it.

The architecture will surface contradictions faster. It will make the substance problems more findable, not less. And without governance in place, the architectural work degrades the moment the organisation starts changing – which it always does.

Each layer makes the others work. Structure-layer engineering succeeds or fails based on what’s in the substance layer – and degrades over time without the governance layer maintaining what’s been built. That’s not a criticism of any particular layer. It’s a systems observation that each layer is important – and inter-dependent, for the whole to succeed.

Content infrastructure is a complete system. The discourse is describing one layer of it as if it were the whole – and organisations are making investment decisions on that basis.

The architecture will tell them what’s missing. It just won’t tell them in time.

Engineers built the infrastructure.
↓
Designers crafted the interface.
↓
Content got plugged in at the end.

This worked because interfaces were most of the value. A well-designed, intuitive website could succeed with mediocre content. Users forgave unclear copy if the experience was smooth. Content was important, but it was the 5% you sorted out once the ‘real work’ was done.

AI inverted this.

The flip

With AI, the interface is commodity. Every chatbot looks roughly the same. Every search box works similarly. The visible layer – what organisations obsess over in demos – is perhaps 20% of the value.

The other 80%? The content infrastructure underneath.

‘Content infrastructure’ isn’t a term that arrived with the AI hype cycle. It describes a specific, multi-layered system of capabilities.

Substance – the editorial quality layer

Where maturity starts.

• Do you have a consistent, coherent, relevant body of content to feed an AI system?

• Is the writing clear enough for AI to synthesise?

• Does terminology stay consistent across departments?

• Do marketing promises align with what support documentation actually says?

Without substance-layer maturity, nothing else works. You can’t structure what isn’t coherent. You can’t govern what nobody has made consistent. Most organisations stall here – they’ve never invested in making their content accurate, consistent, and current across the enterprise.

Bottom line: quality gaps at this layer set an absolute ceiling. No amount of technical tuning compensates for contradictory or outdated source material.

Structure – the semantic architecture layer

Once content is coherent, it needs to be organised for AI retrieval and understanding.

Is there a unified taxonomy and metdata schema, or do five departments use five different names for the same product?

Is content semantically mapped and modelled so AI can understand relationships between concepts?

This is where content architecture and knowledge engineering live. But this work presupposes that the substance layer is already sound.

Architecture organises meaning. It does not create it.

Bottom line: structural fragmentation means AI retrieves the wrong content – or nothing at all.

Governance – the content operations layer

Content needs governance to stay coherent over time. Who owns accuracy? What happens when products change – does documentation update, or does outdated content accumulate alongside current content? Are there workflows ensuring quality control?

Knowledge AI governance operates on two surfaces.

Organisational content governance covers the human ownership model: workflows, standards, and policies that define how content gets created, maintained, and kept current.

AI system context governance covers the system’s own operating parameters: role scope, skills, workflows, and guardrails that define how it executes within that organisational context.

Both are content governance problems. Both deteriorate without active ownership.

Bottom line: even when substance and structure are strong, governance gaps mean quality decreases. Performance isn’t just about current state – it’s about sustaining that state over time. Most organisations are managing neither surface.

The maturity sequence

Rather than being independent, these layers represent a sequential progression:

1. Substance first: Get content consistent, accurate, and current

2. Structure second: Architect content for AI retrieval and semantic understanding

3. Governance third: Establish the operations that keep it coherent over time

Most organisations want to jump straight to structure – hiring content architects and knowledge engineers to build taxonomies and ontologies.

But you cannot semantically engineer meaning out of incoherent source material. The sequence exists because each layer sets a limit on what the next can achieve.

A content infrastructure assessment reveals not just what’s broken, but which layer the problem originates in – and what sequence of work will actually address it.

The questions to ask:

• What does the AI learn from?

• How accurate and consistent is that knowledge?

• Who governs what’s authoritative?

• How do contradictions get resolved?

These questions didn’t matter much in the web era. A human could paper over inconsistencies. A support agent could interpret confusing documentation. A sales rep could translate between Marketing-speak and Engineering-speak.

AI can’t. It synthesises exactly what you feed it. Incoherent foundations produce incoherent outputs – at scale, instantly, to every user.

This is the inversion: content went from ‘the thing you plug in at the end’ to the infrastructure everything else plugs into.

Most organisations are still operating as if the old model applies. Still evaluating AI by interface quality. Still assuming content will sort itself out. Still treating the 80% as an afterthought.

Content debt: Twenty years of shortcuts

The inversion wouldn’t be so consequential if organisations had solid content foundations. Most don’t.

For two decades, content strategy was systematically squeezed out of digital investments. ‘Hire designers and engineers – content will happen.’

Every year, a little more fragmentation. A little more inconsistency. A little more debt accumulating.

Content debt – the accumulated cost of shortcuts, fragmentation, and underinvestment in content operations – compounds like financial debt. And like financial debt, you can ignore it for a surprisingly long time. Until you can’t.

Consider a mid-sized B2B software company evaluating AI-enhanced enterprise search. The interface demos cleanly. Results look instant. AI-powered ranking seems intelligent. The vendor promise is the same whether they’re buying an off-the-shelf product or building their own agentic search capability: make all your content findable, in days.

They commit £120,000.

Three months later, the project sits unused. Search results are incoherent. Employees still message colleagues on Slack to find anything. The implementation is quietly shelved.

Nothing was wrong with the technology. Nothing was wrong with the implementation team. The constraint applied regardless of the approach they chose – bought or built.

The problem: twenty years of content debt, now exposed.

• The same product described five different names across departments

• Contradictory information and messaging between departments

• No governance over what’s authoritative

• Metadata so inconsistent the AI couldn’t map relationships

The tool worked. It faithfully surfaced exactly what it found: chaos.

Content debt has been able to accumulate subtly. Marketing and product use slightly different terminology – nobody notices because the website still works.

Engineering documents in one system, support in another, sales in a third – nobody notices because each team finds their own materials.

A merger happens, two taxonomies collide, nobody reconciles them because there’s no budget. Years later: seven different definitions of ‘onboarding,’ three competing product terminologies, orphaned content everywhere.

Nobody paid attention because websites still worked. Suboptimal – users complained that content was hard to find, terminology was confusing, information contradictory. But functional.

The human buffer compensated. Users browsed broken navigation, reconciled contradictory information, called support when content fell short. That labour masked the constraint for decades.

AI removed the buffer. The debt has always been there. It’s the consequences that have changed.

The web-era cost of content debt was: suboptimal websites, confused customers, frustrated employees. Annoying, but manageable.

The AI-era cost of content debt is: failed six-figure implementations, missed opportunities, competitors who addressed their content foundations pulling ahead.

AI systems don’t just display content the way websites do. They ingest it, index it, retrieve it, synthesise it, generate responses from it.

When that content is fragmented, inconsistent, and ungoverned, AI has nothing coherent to work with. The technology works fine. The foundations don’t.

Twenty years of content debt. Now the bill is due.

The urgency trap

Every organisation is facing AI pressure. Boards asking ‘what’s our AI strategy?’ Competitors announcing initiatives. Vendors promising transformation in weeks.

That pressure creates urgency. And urgency is where the content debt trap deepens.

Organisations feel they must act on AI now – but without understanding what those investments actually demand of their content infrastructure, urgency compounds the problem rather than solving it. Interface quality doesn’t predict operational value.

Technical sophistication doesn’t compensate for substance-layer gaps. And implementations on unassessed foundations tend to surface the debt rather than sidestep it.

What organisations can do is get clear on what their AI investments will require before the contract is signed.

The organisations succeeding with AI are focused on sequencing correctly, rather than speed. Which starts with addressing the foundations of what AI readiness for language-based systems means.

Content isn’t the 5% you plug in at the end. It’s the 80% that everything else plugs into.

Coming up

This is the first of a series laying out a complete framework for understanding AI’s content-shaped performance constraints.

Coming in the series: why content infrastructure is being conflated with content architecture across AI strategy discourse, why the engineering community has spent 18 months iterating on problem definition rather than implementation, the backwards implementation pattern, two blindnesses and two wrong turns, the 29 knowledge AI opportunities most organisations don’t know exist, and the assessment methodology and investment sequence that works.

By the end, you’ll have a complete picture: why implementations fail, what organisations miss, and what the sequencing looks like when it works.

But something has been shifting. As understanding deepens about what knowledge AI systems actually require – context, strong organising schema, scaled governance of information quality – something the industry has been circling for two years is now unavoidable.

Knowledge AI has exposed something the industry overlooked for twenty years: enterprise content strategy was never optional infrastructure. It was deferred infrastructure.

Knowledge AI needs enterprise content strategy. Not the narrowed, interface-focused content design version or the ‘content strategy = marketing content strategy’ versions that came to dominate current practice.

I mean: the full-scope, cross-departmental, infrastructure-grade version of enterprise content strategy that the discipline was originally built to deliver.

The prompt engineering moment

If you had even a passing interest in AI business trends through 2024 and into 2025, you encountered prompt engineering. It was everywhere. LinkedIn courses, enterprise workshops, job titles.

The framing was seductive and intelligent: AI gives better outputs when you give it better inputs.

Prompt engineering was advice about how individuals should talk to chatbot interfaces for better results. And for individual use, it works. Anyone who has compared a vague prompt with a structured one knows the difference is real.

But the moment AI moves beyond individual productivity, the limitation appears: the system can only operate within the context it’s been provided.

If you wanted to start using AI to assist with actual project or organisational-scale operations, then it doesn’t matter how well individual employees can phrase a query. The system needs access to quality, well-structured, and maintained information as its starting point for any incoming prompts.

Enter context engineering.

The context engineering correction

By late 2025, the conversation had evolved. Context engineering emerged as the more robust answer to the question of how to feed an AI with the right set of background information it requires to perform the more sophisticated role it was being primed to perform.

This is the threshold moment where AI output quality switched from being a matter of individual tactics to a matter of infrastructure preparation.

Prompt engineering focused on the question, context engineering focused on the infrastructure that feeds AI the right information, at the right time (right information, at the right time... content professionals in the room: starting to sound familiar?).

This was a meaningful advance. Engineers correctly identified that the quality of an AI system’s outputs is determined far more by what it can access than by how you phrase the request. A perfectly prompted query against a poorly organised knowledge base still returns poor results. A mediocre query against well-structured, well-curated information returns something useful.

What the engineering conversation often leaves implicit is this: context isn’t something that just exists.

Context is in itself an outcome effect of providing the right information, at the right time, to achieve a stated goal or output. What is it, the source material, that’s defining that context at an infrastructure level? Content.

Context is downstream of content. The substance, structure, and governance of organisational content is what determines context quality at scale.

But before getting to that, it’s worth noting a historical parallel. Because this isn’t the first time an industry has discovered that content needs infrastructure-grade treatment.

A familiar pattern

If you were working in digital in the early 2000s, you watched something remarkably similar play out.

The first generation of web projects was technology-led. Build the CMS. Design the interface. Launch the site. Content was assumed to be available – something that would fill the containers once the real work of engineering and design was complete.

It wasn’t available. Or rather, it was available in the way that most enterprise content is available: scattered across departments, inconsistent in quality, contradictory in terminology, owned by nobody in particular. The sites launched. The content was a mess.

The last time the industry made this mistake, a discipline emerged to correct it.

Ann Rockley’s Managing Enterprise Content in 2002 and Kristina Halvorson’s Content Strategy for the Web in 2008 articulated the same core insight:

Content is not a commodity that fills containers. It’s a strategic asset requiring coordination, editorial standards, structural planning, and governance across organisational boundaries.

That insight was revolutionary. It was, in hindsight, also ahead of its market. Through the 2010s, the economics of digital product development favoured tactical focus.

Content design instead emerged as a more immediately actionable practice – crafting interface language, standardising product content patterns, streamlining task flows, aligning content with user journeys. This was the flavour of content work that the market favoured and rewarded.

Content strategy practitioners adapted accordingly. The enterprise-level lens – the cross-departmental editorial strategy, information architecture work, and content governance frameworks – gradually lost their organisational home.

Nothing to do with professional failure. Everything to do with rational market signals.

In the web application era, the cost of ungoverned enterprise content was high but largely tolerable. Users compensated for content gaps through their own effort – browsing, comparing, exercising judgement. The business case for enterprise-wide content coordination was theoretically sound – but practically difficult to quantify against the immediate, visible returns of optimising the performance of product user journeys.

The discipline contracted. The problems it was built to address didn’t go away. They accumulated.

And now – as with the early web – a new technology is exposing exactly what was left unaddressed.

What individual AI users are already discovering

Back to context engineering – and what’s happening as it matures beyond the engineering community.

Individual users are figuring something out. Not in theory, but through daily practice.

Anyone who has spent serious time using AI as a working tool – a research assistant, a writing partner, a thinking aid – has gone through a version of the same learning curve. Early on, you focus on prompts. How do I phrase this to get a better answer? That’s the prompt engineering phase. And it works, up to a point.

Because what happens next is that you start realising the bottleneck isn’t how you ask. It’s what the system has been given to work with before you ask a thing.

So you begin curating those materials. The context. You feed it past report examples so it understands the format you need. You provide writing guidelines so outputs match your voice. You upload organisational context – your personal website, blog articles, planning documents, branding, product specs – so the system has the reference material it needs to produce something genuinely useful rather than generically plausible.

In other words: you build a personal content infrastructure. A curated, organised, governed set of reference materials for your AI system to draw from and cohere against.

This skillset and effort may have quickly come to be known as context engineering – but anyone with any sort of background in content strategy knows: this is doing content strategy for a team of one.

Selecting what materials matter in support of stated goals (and vice versa), structuring it for the highest-signal consumption, and maintaining it as things change and feedback loops point to incremental improvement.

The content dependency is the lesson everyone learns: the quality of AI output is constrained by the quality, completeness, and coherence of the content you feed it. Not by the model. Not by the prompt. By the substrate.

Now let’s scale that realisation.

An individual curating context for their personal AI assistant is manageable. One person’s reference materials. One person’s quality standards. One person’s judgement about what’s current and what’s outdated.

An organisation with 2,000 employees across six departments and four geographies faces the same dependency at a completely different order of complexity.

The knowledge that feeds the enterprise AI system needs the same coherence that an individual user painstakingly builds for their personal setup – but across multiple content platforms, departmental boundaries, content ownership silos, inconsistent editorial standards, and two decades of accumulated, ungoverned material.

Gulp.

Nobody is curating the organisational equivalent. Nobody is governing the reference materials that the enterprise retrieval system treats as ground truth. Nobody is ensuring that the product definitions, organisational messaging, and knowledge base materials are consistent, accurate, relevant, and up-to-date across departments and global regions.

The individual user’s learning curve – prompt craft matters less than context quality, and context quality depends on content infrastructure – is a leading indicator of what enterprises are about to confront at scale.

The dependency is identical. The complexity scale difference is monumental.

But there’s a professional practice that is pre-qualified to address content substance, structure, and governance quality at that scale.

It’s just been dormant in the AI space up until now.

Enterprise content strategy.

Content as infrastructure: three layers, three performance ceilings

When you treat content not as a commodity output but as infrastructure that sets performance ceilings for knowledge AI systems, a different assessment framework emerges.

Quantitative AI – the kind that processes numerical data, detects patterns in structured datasets, optimises logistics – requires data infrastructure. Clean, structured, governed data. Most enterprises have invested decades in building this capability. Data engineering is a mature discipline with established practices, tooling, and organisational recognition.

Enterprises would never run quantitative AI on unclean, ungoverned data. And yet. They routinely deploy knowledge AI against unstructured, unowned, and unmaintained content — and are surprised when performance degrades.

Knowledge AI – the kind that processes qualitative content, retrieves information, synthesises guidance, generates responses grounded in organisational knowledge – requires content infrastructure. And most enterprises have built almost none of it.

Content infrastructure has three layers. Each sets a ceiling that determines what AI can achieve – and each constrains the layers above it.

Substance is the editorial foundation. Completeness, accuracy, readability, accessibility, strategic relevance, voice and tone consistency. This layer determines whether AI responses are meaningful, accurate, and useful. It’s the equivalent of data quality in quantitative AI – and it’s the layer most organisations assess least. An AI system grounded in incomplete, outdated, or contradictory content will produce incomplete, outdated, or contradictory outputs. No amount of architectural sophistication changes this.

Structure is the organising schema. Taxonomy, metadata, information architecture, content models, semantic relationship mapping. This layer determines whether retrieval is precise – whether the system consistently surfaces the right information in the right context rather than returning everything vaguely related. Structure is where context engineering and content infrastructure overlap, and where engineers most often discover gaps they didn’t anticipate. Without coherent structure, retrieval degrades from “find the answer” to “find twenty things that might contain the answer.”

Governance is the operational framework. Content ownership, standards and guidelines, workflows, maintenance cycles, cross-departmental coordination. This layer determines whether performance is sustained as the system scales and content evolves. It’s the most chronically neglected layer because it’s the least visible. Governance failures don’t produce dramatic crashes – they produce slow degradation. The AI that worked brilliantly in the pilot gradually becomes less reliable as ungoverned content drifts from accuracy.

The dependency logic matters: each layer constrains the one above it. You cannot meaningfully structure incoherent content – taxonomy applied to inconsistent terminology just organises the mess more neatly. You cannot govern what nobody owns – workflows for content maintenance require someone to maintain. And you cannot engineer around a lack of substance – retrieval architecture that efficiently surfaces poor-quality content just delivers poor quality faster.

Where this leads

Three implications follow from this.

First: any enterprise assessing “AI readiness” without assessing content infrastructure is likely running a glaringly incomplete diagnostic. Context engineering without content infrastructure is building a delivery system for cargo that hasn’t been loaded.

The most sophisticated retrieval architecture in the world cannot compensate for source material that’s incoherent, contradictory, or unmaintained. Readiness assessments that evaluate only technical architecture and data pipelines are answering half the question.

Second: the widely reported high failure rates of enterprise AI initiatives aren’t primarily a technology problem. The technology works. Context engineering works. What fails is the assumption – almost never examined – that organisational content is ready to be processed at scale. It rarely is.

Twenty years accumulation of content debt across platforms, departments, and business units, without the infrastructure-grade governance that’s applied to data, has produced exactly the foundation you’d expect.

Fragmented, inconsistent, ungoverned, and invisible to the teams making six-figure procurement decisions.

Third: the expertise required to assess and remediate content infrastructure exists and is available. It emerged from a discipline that contracted its scope during an era when the market didn’t reward the work. The market now demands it.

The question facing enterprises isn’t whether content infrastructure matters for knowledge AI – it does, structurally and unavoidably – but whether they recognise the gap before or after the next implementation underperforms.

The trajectory from prompt engineering through context engineering pointed in this direction all along. Each step got closer to the actual constraint.

The final step – acknowledging that content itself is infrastructure, with its own assessment requirements and its own performance ceilings – is the one the industry has yet to take.

It will. The industry will get there.

The only variable is how much underperformance happens first.

Months (or even years) later, the same constrained performance levels remain. Plans are made to remediate and optimise. And yet the structural constraint was never diagnosed.

The constraint is content.

Why content infrastructure stays invisible

Two inherited biases from the web era explain why content infrastructure stays invisible in transformation planning.

Interface Bias – organisations evaluate digital performance by what’s visible: redesigned homepages, chatbot demos, polished UI. Meanwhile, the operational layer where the majority of durable value lives – retrieval, synthesis, quality assurance, compliance, knowledge management – gets no demo, no vendor pitch, and no board attention.

Engineering Bias – when asked “how to transform,” organisations default to “how do we build?” – custom models, ML teams, proprietary infrastructure, platform migrations, semantic engineering. This focuses attention on technical infrastructure constraints whilst wider content infrastructure constraints remain unassessed.

The compound effect: attention flows to the visible layer, investment flows to the build layer, and the structural constraint remains untouched.

From commodity output to infrastructure foundation

When content is treated as a byproduct of digital products and services, it behaves like one – fragmented, reactive, chaotic.

When content is treated as infrastructure, a different assessment framework emerges. Content-as-infrastructure has three interdependent layers:

1. Substance

2. Structure

3. Governance

1. Substance

The content quality layer

Is core content accurate, complete, and internally consistent? Can downstream systems – websites, search engines, AI tools – trust what they’re being fed?

Quality gaps here set a hard ceiling. No amount of platform tuning or interface optimisation compensates for contradictory or outdated source material.

2. Structure

The semantic architecture layer

Is there a unified content model across domains? Are taxonomy, metadata, and information architecture aligned – or has each department built its own structural logic?

Structure determines whether information can be found, filtered, synthesised, and reused at scale. Without structural coherence, every digital surface becomes a manual assembly exercise.

3. Governance

The content operations layer

Who owns content across domains? What happens when positioning shifts, products evolve, policies update?

Digital content governance now operates on two surfaces:

1. Organisational governance – the human ownership models, workflows, and editorial standards that determine how content stays aligned

2. Platform governance – how tool configurations and encoded features and rules either enforce or undermine that coherence.

Without governance, substance and structure deteriorate. With it, they compound.

What this publication explores

This publication examines digital performance through the lens of content infrastructure.

We’ll start with knowledge AI – mapping the operational applications most organisations overlook, and the infrastructure constraints most AI strategies fail to measure.

From there, we’ll apply the same three-layer model to website and content platform transformation – explaining why redesign cycles plateau, why migrations replicate fragmentation, and what the structural alternatives look like.