How Business Knowledge Becomes Automated Content

Business knowledge becomes content by passing through six states in order: said out loud, captured, stated as a claim, made findable, briefed, and drafted. Each handoff loses something specific, and most automated content fails at a handoff rather than at the writing. This guide follows one piece of knowledge through all six, names what goes missing at each step, and then runs the chain backwards, so that when a fact changes, every published piece that used it can be found in minutes rather than by memory.

How to turn business knowledge into content, and why uploading your documents isn't the answer

To turn business knowledge into content, you move each thing the business knows through a fixed sequence of states, and you keep a record of which source each published sentence came from. The sequence matters more than the model. Most teams start at the last step, pasting a brochure into a chat window and asking for a post. What comes back is fluent and wrong in small ways, because the brochure never held the knowledge that made the business worth hiring.

The knowledge that makes a specialist business valuable sits in a few people's heads and in the way they answer questions on a call. It includes the reason behind a recommendation, the exception they always mention, and the case where the usual advice is wrong. None of that is in the brochure. So the work of building content from it is mostly the work of getting it out, writing it down in a form a draft can use, and keeping it honest as it changes. Writing the post is the short, cheap part at the end.

It helps to be precise about what this post covers. Deciding how to organise what a business knows is its own subject, covered in how to organise business knowledge, and the layered model behind it is in the knowledge architecture framework. Here we follow a single piece of knowledge on its journey to a published page, and then back.

From business knowledge to content: the six states every fact passes through

Every fact a business publishes passes through six states, and each handoff between them loses one specific thing if nobody guards it. A fact starts as something an expert says. It becomes something captured, then a claim with its evidence, then something a system can find, then an item a brief allows a piece to use, then a sentence in a draft. Each state has an owner and a typical failure, and you can name the failure before you build anything.

A draft that says something vaguely true but useless lost its specificity at state six. A draft that states a rule the expert would never state without a qualifier lost its hedge at state three. A draft that quotes the right fact about the wrong service lost its context at state four. When automated content goes wrong, ask which handoff it went wrong at; the fix lives there.

Getting tacit knowledge said out loud

Tacit knowledge is what an expert knows but has never written down, and the only reliable way to capture it is to make them say it in answer to a real question. Ikujiro Nonaka's The Knowledge-Creating Company, in Harvard Business Review, made the distinction between tacit and explicit knowledge a management idea, and the practical consequence for content is simple: you will not get the tacit part by sending someone a questionnaire.

So capture starts where the knowledge is already being spoken. Sales calls, onboarding sessions, internal reviews and client emails are all places where an expert explains something to someone who needs it, with the reasoning attached because the listener asked. A transcript of one good sales call usually holds more usable knowledge than any number of attempts to write a company overview from scratch. The skill is in choosing which conversations to record and in asking one follow-up question at the moment the expert says "it depends".

The loss to guard against here is the reason. A captured answer that says "we recommend replacing rather than repairing" is half a fact. The useful half is why, and in which situations the opposite is true. Whoever runs capture should mark the reasons as they hear them, even crudely, because the next state turns these transcripts into claims, and a claim without its reason cannot be defended when a customer pushes back. If a founder is the main source, the founder-specific version of this is in how capture works for a founder-led business.

Turning what was said into claims a draft can use

A claim is one statement the business is willing to publish, written with its evidence and its limits, and given an ID so that anything built from it can point back to it. This is the state most teams skip, and skipping it is why their content contradicts itself across platforms. A transcript is a conversation, and a model reading it will happily lift a half-sentence that was a joke, an aside, or an answer the expert later corrected. A claims file removes that ambiguity before any writing starts.

The format can be plain. Each claim is a short line, followed by the source it came from, the situations it covers, the situations it does not, and the name of the person who confirmed it. Extracting first drafts of those claims from a transcript is work a model does well: the Information Extractor node in n8n's documentation is built to pull structured fields out of incoming text, and OpenAI's guide to Structured Outputs describes making a model's response follow a JSON schema you supply. Either way, the output is a list of candidate claims, each in the same shape.

The loss at this handoff is the hedge. A model extracting claims tends to strip qualifiers, because "usually" and "in most cases" look like filler. They are not filler. They are the expert's judgement about where the rule stops working, and a published sentence without them is a promise the business never made. This is why the expert reviews the claims rather than the drafts. Reviewing a batch of short claims takes far less time than reviewing the finished posts built from them, and every claim they approve is reused many times.

We run a version of this in our own publishing, labelled here because it is our own build rather than a client's. Each piece of research becomes a file of facts, every fact on its own line under an ID, and the plan for a post names which fact IDs each paragraph may use. A check refuses to build a post if any number in it is not present in that source file. It is a small mechanism, and it removes a whole class of correction: a draft cannot carry a number nobody supplied.

Making knowledge findable, then deciding what each piece may draw on

Making knowledge findable means storing approved claims where a system can retrieve the right one by meaning, with enough context attached that a retrieved fragment still says what it is about. Briefing means a person, or a rule, deciding which of those claims a specific piece is allowed to use. These are two separate states, and treating retrieval as a substitute for briefing is the most common way the wrong fact ends up in the right post.

Retrieval is well documented. n8n's guide to retrieving relevant context explains how a vector store splits documents into chunks and converts each chunk into a vector with an embedding model, and Hugging Face's Getting Started With Embeddings defines an embedding as a numerical representation of a piece of information, which is what lets a system match a question to a claim by meaning rather than by shared words.

None of this is new. The approach goes back to the 2020 paper on retrieval-augmented generation for knowledge-intensive tasks, and hosted versions such as OpenAI's file search tool now let a model search a knowledge base of uploaded files without you running the search yourself. The choice of tool matters less than what goes into it.

The loss at state four is context. A chunk that reads "we no longer recommend this for older buildings" is useless if retrieval has separated it from the sentence naming the service. Anthropic's write-up of contextual retrieval describes exactly this problem and fixes it by having a model write a short note situating each chunk in its source document before it is indexed. Writing claims as self-contained statements at state three gets you most of the same benefit for free, which is one more reason not to skip it.

The loss at state five is selection. Even good retrieval returns several plausible entries, and a model left to choose will pick the one that reads best, not the one that is current or relevant to this audience. A brief closes that gap by listing the claim IDs a piece may use and, just as usefully, the ones it must not. There is a second reason to keep the brief short. Research on how language models use long contexts found that models use information at the start and end of a long input more reliably than information in the middle, so handing a model every claim you have tends to dilute the few that matter for this piece. Grouping claims into topics a site can rank for is a different job again, and it is set out in how content clusters bridge knowledge and content.

Once the brief exists, drafting is the cheapest state in the chain. The model writes from a short list of approved claims, and its job is phrasing and structure for one platform rather than knowing anything. Specificity is the thing to watch: a draft that drifts from the claims into general advice has filled a gap the brief left open, and the remedy is a better brief rather than a better prompt. Turning one approved claim into many platform-native pieces is a separate technique, described in what content atomization is, and it works only because the claim underneath each piece is the same.

Running the chain backwards when a fact changes

Running the chain backwards means that when a claim changes, you can list every published piece that used it, because each piece recorded the claim IDs it drew on when it was made. This is the step that turns a content pipeline into something you can trust for years, and almost nobody builds it.

The mechanism is a single field. Every published piece, whether a website article, a LinkedIn post, a newsletter issue or a video script, carries a list of the claim IDs its brief allowed and its draft actually used. Store that list alongside the piece, in its front matter or in a table of published content. When someone edits a claim, the question "what did this touch?" becomes a lookup rather than an investigation.

The tooling for noticing a change already exists in the standards. The Model Context Protocol's specification for resources lets a server expose data such as files and schemas to a model, and defines notifications for when a resource list or a subscribed resource changes. On the drafting side, Claude's citations feature returns the passages in your source documents that support each part of an answer, which is the same provenance record produced at draft time instead of by hand.

This is also where this post stops short of a neighbouring one. Why automated content stops working explains how a stale source quietly degrades the content you are about to make. Running the chain backwards deals with the content you have already published, which is the larger and less visible problem, because published pieces keep being read long after anyone remembers what they said.

What the machine carries, and what only the expert decides

The machine carries the handoffs, and the expert keeps every judgement about whether something is true and whether the business should say it. In practice that means automation does the moving, sorting, extracting, retrieving, drafting and lookup, while a named person approves claims, decides which ones a piece may use, and signs off what gets published. The broader version of where that line sits for any content system is in what to automate in your content, and what not to.

Split by state, the division is consistent. Capture can be automated end to end: recordings, transcripts and filing need no judgement. Extraction can be drafted by a model, but approval of a claim is the expert's, always, because only they know where the hedge belongs. Storage and retrieval are entirely mechanical. The brief is a judgement about audience and purpose, so a person sets it, even if a template proposes it. Drafting is the model's. Approval is a person's, by name. The backwards lookup is mechanical, but deciding whether an old piece should be edited, annotated or left alone is an editorial call.

The part businesses most want to automate, and should not, is the claim review. It feels like a bottleneck, in the way a signature is one. A short, regular block of an expert confirming claims is what makes every piece downstream safe to publish without a second read of the facts, and it is the content a business can stand behind. Everything else in the chain exists to make that block of time count. Designing the chain so the expert's attention lands only where it is needed is most of what a content automation specialist designs.

One roofing answer, from a sales call to every piece that used it

The clearest way to see the chain is to follow one fact at an illustrative business, so here is a commercial roofing contractor, invented for this example, with no numbers attached. On a sales call, the owner explains why they sometimes recommend laying a new membrane over an existing flat roof instead of stripping it: the survey shows the deck underneath is dry and sound, so an overlay is quicker and less disruptive for a building that stays occupied. That answer, said out loud, is state one.

The call is recorded and transcribed automatically, and an n8n workflow drops the transcript into the business's knowledge folder. In Claude Code, a skill reads new transcripts and proposes claims in a fixed format. One of them reads, in plain words: an overlay is recommended only when the survey confirms the existing deck is dry and structurally sound; otherwise the roof is stripped. It records the call it came from, notes that it does not cover pitched roofs, and waits for the owner's approval. The owner adds one qualifier the model dropped, approves it, and it becomes claim K-014.

Over the following weeks, K-014 is used by several pieces. A website article on overlay versus replacement cites it in two paragraphs. A post on the LinkedIn company page uses it as its main point. A Substack newsletter issue on planning roof work around tenants mentions it in passing, and a short video script repeats it in the owner's own phrasing. Each piece's brief listed K-014 as allowed, and each piece's record lists it as used.

Months later, the owner changes the policy. From now on, every overlay recommendation requires a core sample, not just a visual survey, because of a problem they saw on a job. They edit K-014 and the change is committed. A second n8n workflow notices the edit, looks up every published piece whose record includes K-014, and opens one review task per piece for the named approver, with the old sentence and the new claim side by side. The approver updates the article and the script, adds a short note to the newsletter archive, and leaves the LinkedIn post as a dated statement of what they said at the time.

Nothing in that sequence needed anyone to remember where the overlay answer had been published. The cost was the claim review at the start and four small edits at the end. Done by memory, the same change would have been caught in whichever pieces someone happened to reread, and the rest would have kept saying the old thing to every reader who found them, including the website articles written for search that are, by design, the pieces read longest after publication.

What keeping the chain intact costs the expert each month

Keeping the chain intact costs the expert a short, regular block of review time, and it costs the business one person who owns the claims file. Neither is large, but both are recurring, and the chain fails quietly when either one stops. The money side of a build like this is set out on the Custom Content OS pricing page; this section is about the time, which no build removes.

The recurring work falls into three parts. The expert approves new claims as capture produces them, which is a weekly habit of reading short statements and correcting a few qualifiers. Someone owns the claims file: merging duplicates, retiring claims that no longer apply, and making sure every edit triggers the backwards lookup. And an approver works through review tasks when a claim changes, which is uneven, quiet for weeks and then busy after a policy change or a new service.

The thing that goes wrong in month two is predictable. Capture keeps running, so transcripts pile up, but claim review slips because the expert is busy. Drafts then start drawing on unreviewed material, either because someone loosened the brief or because a writer pasted from a transcript directly. Within a few weeks, the content sounds less like the business and the backwards lookup no longer covers what was published. The fix is to treat an empty review queue as a condition for drafting, not an aspiration, and to let publishing slow down rather than let unreviewed claims through.

There is also an upfront cost in decisions. Someone has to agree the claim format, decide which conversations get recorded, and set the rule for what happens to an old piece when a claim changes. A business that already has its knowledge mapped, as described in how to identify your knowledge pillars, gets through them much faster, because it already knows which claims matter most.

None of this is a reason not to automate. It is the honest shape of the work: the system takes over the moving and the writing, and leaves the business with a smaller, sharper job. The other business knowledge guides cover the parts of that job this post does not.

Frequently asked questions

What does it mean to turn business knowledge into content?

It means moving what a business's experts know, much of it never written down, through a sequence of states until it becomes published writing, and keeping a record of which source each piece used. The states are said, captured, claimed, findable, briefed and drafted. The record of sources is what lets the content stay accurate when the knowledge behind it changes.

Can AI capture tacit knowledge on its own?

No, AI can transcribe and organise tacit knowledge once someone says it, but it cannot draw it out of an expert who has not been asked the right question. The capture step depends on recording real conversations and asking a follow-up when the expert says "it depends". A model is excellent at what happens after that: transcribing, extracting candidate claims and filing them.

Do we need a vector database to do this?

Not at the start. A business with a few dozen approved claims can brief pieces from a plain claims file, and a person can choose the claim IDs directly. Retrieval with embeddings becomes worth adding when the claims file grows past what anyone can scan, or when many pieces are briefed automatically. Self-contained claims make either approach work better.

What is the difference between a claims file and a content brief?

A claims file holds everything the business is willing to say, each statement approved and given an ID. A brief is the plan for one piece, naming which of those claims it may use and which it must not. The claims file is shared by every piece and changes slowly; a brief is written per piece and is what stops the wrong fact being picked.

How do you find every published piece that used an outdated fact?

You record, at publication, the claim IDs each piece used, and then search that record when a claim changes. It is a lookup, not an investigation, provided the record was kept from the start. A workflow can watch the claims file for edits and open a review task for each affected piece automatically, so nobody has to remember where the fact appeared.

Who should approve content built from business knowledge?

A named person who knows the subject approves the claims, and a named person approves each piece before it is published; often these are different people. The expert's time is best spent on claims, because one approved claim feeds many pieces. The piece approver checks fit, tone and audience, trusting that the facts were already settled upstream.

What should happen to an old post when a claim changes?

Each affected piece gets one of three decisions: update it, add a dated note, or leave it as a record of what was said at the time. Evergreen pages such as website articles are usually updated, while social posts are often left as dated statements. The rule should be agreed in advance so the approver is not deciding it from scratch under pressure.

Where to start

Pick one fact your business repeats on nearly every sales call, and walk it through the six states by hand this week. Write down where it was last said, capture it in the expert's own words, turn it into one claim with its limits, and then list every place it has already been published. Where that exercise stalls is the first thing to build. If it stalls at the last step, because nobody can say where the fact appears, you have found the reason your content will drift, and the cheapest point at which to fix it. When you are ready to make the whole chain run on its own, that is what a Content OS built around what your business knows is for.

Keep reading

• How to organise business knowledge — the structure the claims in this post live inside.
• The knowledge architecture framework — the four layers that decide which knowledge feeds which content.
• Why automated content stops working — what happens to future drafts when the source behind them goes stale.