Every advisory firm does a great deal of research. Someone reads the regulator's latest guidance before a workshop, compares three cloud providers' regional services for a proposal, or studies how other organisations have structured an AI governance board. The research is often excellent. It is also usually used once, buried in a slide deck or a proposal appendix, and rediscovered from scratch the next time someone needs it.
The waste is obvious. The risk is less obvious. When research is reused informally, by copying a slide from an old proposal, nobody knows whether its claims are still true, where they came from or whether they contain detail from a previous client. A slide that was accurate and appropriate eighteen months ago can be wrong, stale and confidential today.
This part describes how we turn research into reusable assets that stay trustworthy, and why the client-specific step always comes last.
This article describes CloudNala's practice. Where an example involves another organisation, it is fictional and its details are illustrative.
Six steps from research to asset
We think of research as moving through six steps. Each step produces something useful on its own, which means research that stops early still leaves something behind.
Capture sources. Every source is recorded with its URL or reference, its publication date, the date we checked it and what we took from it. This is the cheapest step and the one most often skipped. Without it, nothing later can be verified.
Synthesise the argument. Raw notes become a short written argument: what we now believe, why, and what remains uncertain. The synthesis separates facts from our inferences and our recommendations, because those three age at different rates.
Build a reference architecture. Where the research concerns a system or capability, we express it as a neutral reference architecture: components, boundaries, data flows and controls, with generic names rather than any organisation's real systems.
Produce a decision framework. Most clients do not need our research; they need to make a decision. A framework turns the research into questions, criteria and trade-offs a client can apply to their own situation.
Create a visual explainer. A diagram or one-page explainer communicates the argument to people who will not read the synthesis. We author diagrams from a typed source where we can, so they can be revised and checked rather than redrawn.
Adapt for one client. Only at this point does client context enter. The adaptation applies the framework and reference architecture to the client's situation, using their approved material, inside their engagement workspace.
Why client adaptation comes last
The order matters for one reason above all: it keeps reusable material clean. If client context enters early, the synthesis, architecture and framework absorb details that cannot be reused. The next time the asset is needed, someone has to remember which parts came from where, and they usually do not.
By keeping the first five steps generic and public-safe, we can reuse them across clients and publish parts of them as articles. The sixth step is where engagement-specific value is created, and it stays inside that engagement. We describe the context tiers behind this in Part 2.
This discipline is also what lets us publish. Articles in this site's series are built from the first five steps, using fictional organisations and public sources, never from adapted client material.
The record that keeps an asset honest
An asset is only reusable if the next person can tell what still holds. For each material claim in an asset, we keep a small record.
Claim: what exactly the asset asserts. Source: where it comes from. Checked on: the date it was last verified. Volatility: how fast it is likely to go stale. Prices, product versions, regional availability and regulations are high-volatility; architectural principles are low. Fact or view: whether it is evidence, our inference or our advice. Reuse rule: whether the claim is public, internal or client-only.
Volatility is the field that saves the most embarrassment. A reference architecture that says a service is available in a South African cloud region may have been true when written and false now. The volatility flag tells the next user that this claim must be rechecked before it reaches a client. We followed exactly this practice for our article on AI models available in South Africa, which carries its verification dates in the text.
Where AI helps, and where it does not
AI tools help at several steps. They summarise long sources quickly, propose a first synthesis, draft framework questions and generate diagram source from a description. They are also useful for checking an asset against its source register: does every claim in the synthesis have a source, and has any source been cited for something it does not say?
AI does not help with the judgement steps: deciding what we actually believe, choosing between conflicting sources, and deciding what is safe to reuse. It is also prone to producing confident claims without sources, which is exactly the failure the record exists to catch. The rule we follow is that an AI-drafted claim without a source entry is treated as unverified until a person traces it.
A worked example
Suppose a fictional client, Karkloof Health Network, asks for advice on governing AI use across its clinics. The research covers POPIA's treatment of health information, the AI governance approaches published by standards bodies, and patterns for approving AI use cases.
The source register records each regulation, standard and article with dates. The synthesis states that health information is special personal information under POPIA, notes the absence of AI-specific legislation, and records our view on use-case approval. The reference architecture shows a neutral approval workflow with generic roles. The decision framework becomes a set of questions for any healthcare organisation weighing an AI use case. The explainer is a one-page diagram of the approval flow.
Only the final adaptation names Karkloof's committees, clinics and systems, and it lives in Karkloof's engagement workspace. The first five outputs can be reused for the next healthcare client, after their volatile claims are rechecked, and some of them could become a public article.
The point of view
Research becomes valuable when it outlives the occasion that prompted it. That requires a source register, a synthesis that separates fact from view, neutral architecture and frameworks, and a record of when each claim was checked and how quickly it ages. Client adaptation comes last and stays separate, which is what keeps everything before it reusable and safe to share.
Next: Part 5, A tool-neutral AI operating system for a small business. All parts are on the series page.
How CloudNala can help
We help advisory, bid and architecture teams turn their research into reusable assets: source registers, synthesis templates, reference architectures, decision frameworks and diagram sources, with clear rules for verification and reuse. The result is a knowledge base that the next proposal or workshop can draw on safely, rather than a folder of old slides.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Talk to CloudNala or write to us at consult@cloudnala.co.za