A practical reflection on Syntax, SharePoint, content curation and the changing role of the Knowledge Manager

One of the most time-consuming parts of Knowledge Management is often not creating knowledge; it is getting existing content into a shape where people can actually find, trust and reuse it.

Before content can become useful organisational knowledge, someone has to find it, understand it, clean it, categorise it, tag it, check it, and move it to the right place.

Recently, I explored an AI automation use case using Syntax with SharePoint. What interested me was not simply that AI could read documents. It was the possibility of using AI to take on the repetitive first layer of content curation—while keeping the Knowledge Manager firmly in the loop.

Check out the detailed PDF Overview...

The use case: from SharePoint folders to curated knowledge

Think about a SharePoint folder with hundreds of files accumulated over time: proposals, case studies, presentations, solution documents, meeting notes, templates, project material, drafts, and older content. Manually, a KM professional may need to open individual files, identify the content type, understand the subject, apply metadata, identify possible restrictions, and decide where the content belongs.

With an AI-assisted workflow, the model changes:

SharePoint folder → AI processing → classification and metadata suggestions → governance flags → human review → curated repository

What AI can help automate

• Identify likely content type—for example, case study, proposal content, solution, SOP, meeting notes or thought leadership.
• Suggest categories based on the organisation’s taxonomy.
• Generate or recommend metadata such as practice, industry, geography, solution, technology and content type.
• Surface potentially duplicate, outdated or low-value content for review.
• Flag content that may contain confidential, client-sensitive, copyright-protected, or proprietary/IP material, subject to appropriate rules and validation.
• Route approved content to the appropriate SharePoint location through workflow automation.

Is it 100% accurate? No—and that is okay.

Based on my exploration, I would describe the initial output as roughly 70% accurate/usable rather than 100%. The exact result will vary with the quality of the taxonomy, instructions, examples, content, and workflow design.

For me, the important point is that AI does not have to be 100% accurate to create value. If it can remove a large part of repetitive discovery, sorting, classification, and tagging, it gives the KM team more time for the work that requires judgement.

AI is only as good as the KM context we give it

This is where the Knowledge Manager’s role becomes even more important. If we expect AI to recognise reusable content, confidential information, copyright restrictions or organisational IP, we have to define what those things mean in our environment.

The KM team provides the taxonomy, content definitions, metadata rules, examples, and governance principles. In other words, we are not simply asking AI to read content. We are teaching it how our organisation manages knowledge.

The model I believe works: AI + human review

I do not see the process as:

AI → Publish

I see it as:

AI → Process → Recommend → Flag → Human Review → Publish

The final responsibility for trusted knowledge should remain with the KM professional or designated content owner. AI can accelerate the work, but the human layer validates accuracy, relevance, reusability, confidentiality, IP, taxonomy, and content quality.

Beyond folders: connecting Forms, Power Automate and SharePoint

The bigger opportunity is to move from one-off content harvesting to continuous knowledge capture. For example, a simple Microsoft Form can capture meeting notes, project decisions, lessons learned, challenges, solutions, and reusable assets. Power Automate can trigger processing, and AI can structure and classify the information before it reaches the KM review queue.

A possible flow is:

Capture → Structure → AI classify/tag → Flag → KM review → Store → Reuse

A use case I see for bid and proposal teams

Bid teams work under pressure and repeatedly need similar knowledge: case studies, credentials, solution descriptions, previous responses, differentiators, delivery models, industry examples, and reusable proposal language.

If content is continuously classified and tagged, the bid team can move beyond searching for filenames and folders. The longer-term goal is to search by intent and meaning—for example, asking for examples of how the organisation helped healthcare clients improve customer experience through digital transformation.

This is where KM can shift from being a repository service to becoming a business enablement capability.

Manual vs AI-assisted curation

What happens to the Knowledge Manager?

This is the question AI naturally raises. My view is that the role does not disappear—it moves up the value chain.

• Less time on repetitive content administration.
• More time on knowledge strategy and architecture.
• More focus on taxonomy and governance.
• More attention to knowledge gaps and content lifecycle.
• More SME engagement and adoption.
• More time to measure reuse and business impact.
• A new responsibility for designing, testing, and improving AI-enabled knowledge workflows.

My biggest takeaway

AI does not replace the Knowledge Manager. It changes what the Knowledge Manager should spend time doing.

The future of KM may be less about manually managing every document and more about designing intelligent knowledge flows that can discover, classify, curate, flag, and route information—while humans provide the judgement, governance, and accountability.

Perhaps the future is not Human versus AI. It is Human + AI = Intelligent Knowledge Management.

We have spent years asking people to contribute knowledge and use repositories. The next opportunity may be to build systems that capture and process knowledge as part of the work people are already doing.

The question is no longer only, ‘Where is the knowledge?’ It is becoming, ‘How intelligently can we move knowledge to where it is needed?’

Also, I have attached my practical guide draft that I have been leveraging to automate content discovery, classification, tagging, governance, and routing.

_____________________

Knowledge management usually splits knowledge into two buckets:

• Explicit knowledge — things that can be written down: procedures, checklists, reports, data. This travels well. You can email it, file it, search it later.
• Tacit knowledge — the experience-based, contextual, often unconscious knowledge that lives in someone’s head. The “why we don’t do it that way,” the pattern recognition built from years of doing the job, the judgment calls. This is exactly what the TV protagonist was worried about losing.

‍

The sad truth is that most organizations are very good at capturing explicit knowledge and very bad at capturing tacit knowledge. A project closes, a case is transferred, an employee leaves — and the parts of the story that mattered most, the ones that would help the next person avoid the same mistake, quietly walk out the door with the person who knew them.

Knowledge that exists but never moves has no operational value. A lesson sitting in someone’s head, or buried in a report nobody reads, is functionally the same as a lesson that was never learned at all.

Why aviation had no choice but to solve this

Most industries can afford to lose a little context in a handoff. Aviation can’t. When the cost of an unlearned lesson is measured in lives, “we’ll write it up eventually” isn’t good enough. That pressure is exactly why aviation has built one of the most mature knowledge-management ecosystems of any industry — worth studying even if you’ve never set foot in a cockpit.

A few of the mechanisms worth knowing about:

Confidential reporting systems. In the US, the Aviation Safety Reporting System (ASRS) is a voluntary, confidential channel that lets pilots, air traffic controllers, cabin crew, dispatchers, and maintenance staff report near-misses and close calls in the interest of improving safety. Crucially, it’s run by NASA rather than the FAA, which gives it the neutrality people need to actually be honest, since NASA has no enforcement power over them. Report something within the right window, and you get limited immunity — the system is built on the premise that a mistake reported openly teaches the whole industry more than a mistake punished quietly. It was created in direct response to a fatal 1974 crash where investigators found that similar warning signs had existed before, but nothing was systematically capturing or circulating them.

Operator-level programs alongside the national one. Airlines run their own internal version, the Aviation Safety Action Program (ASAP), through formal agreements between the airline, employee unions, and regulators. This captures the tacit, day-to-day knowledge — the near-misses that never make headlines — before it’s lost to memory or turnover.

A shared global taxonomy. Different countries and airlines used to describe incidents differently, which made it hard to compare data or spot patterns across borders. ICAO and the European Commission have worked to promote a single shared repository and a common categorization scheme so that all aviation accidents and incidents worldwide can be reported the same way. That sounds like a bureaucratic detail, but it’s the difference between a lesson staying local and a lesson becoming global. Standardizing the “language” of the report is what lets a hazard identified in one country prevent an accident in another.

Institutionalized feedback loops. Incident data doesn’t just sit in a database — it feeds back into training curricula, cockpit procedures, aircraft design, and regulation. Crew Resource Management training, now standard worldwide, exists largely because of hard lessons from accidents where the technical flying was fine but communication and hierarchy in the cockpit weren’t. The knowledge didn’t just get recorded; it got re-injected into the system that produced the next generation of pilots.

The pattern underneath it all

Strip away the aviation-specific detail, and the model is transferable to almost any team, industry or project:

1. Make capturing knowledge low-friction and safe. People share the messy, honest version of what happened only when they trust it won’t be used against them.
2. Capture context, not just conclusions. A checklist item (“check altitude clearance”) is explicit knowledge. The story of why that checklist item exists — the confusion, the assumption that went wrong — is the tacit knowledge that actually changes behavior.
3. Standardize how knowledge is described, so it can be compared, searched, and aggregated across teams instead of staying siloed in one person’s notes.
4. Close the loop. A lesson learned that never gets fed back into training, onboarding, or process design is just an interesting anecdote. It has to change what the next person does.
5. Treat the handoff itself as a risk point. The TV show’s protagonist was right about one thing: transfer is where knowledge degrades. Overlap periods, structured debriefs, and “why” documentation — not just “what” documentation — are how you protect against that.

Knowledge existing in an organization is necessary but not sufficient. What determines whether it actually prevents the next mistake is whether it’s captured with enough context, shared without fear, standardized enough to travel, and looped back into the system before the next person needs it. Aviation didn’t get this right because it’s a more disciplined industry by nature — it got it right because the cost of getting it wrong left no other option. That’s the real lesson for the rest of us: build the system as if the stakes were that high, before something forces you to.

_________________________

A company hires its first employee in another country. Six months later, there are three people there. A year after that, leadership is discussing a local entity.

By then, the employment structure may have changed several times while the knowledge around it has remained informal. Decisions live in inboxes. A local exception is remembered by one HR manager.

‍

A payroll process still makes sense only because someone remembers why it was set up that way. The problem is no longer just administration. The business has created a knowledge continuity risk.

A 2026 paper in Knowledge and Process Management examines knowledge continuity at transition boundaries, where responsibility moves and context can become separated from the knowledge being transferred. International expansion creates exactly these kinds of boundaries. The useful question for Knowledge Management teams isn't simply whether the records exist, but whether the next owner will understand the decisions behind them.

The first hire creates a knowledge boundary

The first international employee may arrive long before the company is ready to establish a legal entity in that country. In that situation, the business may use an employer of record. Under this employment structure, the EOR acts as the legal employer and manages areas such as employment contracts, payroll, benefits, and local employment requirements while the company directs the employee's day to day work.

That split matters to knowledge management. Internal teams need a clear record of which decisions belong to the company and which responsibilities sit with the external provider. If a local allowance is introduced, for example, retaining the final policy is only part of the job. Future owners also need to know why the decision was made, who approved it, and whether it was an exception or something intended to continue.

A growing team exposes what was never captured

One employee can compensate for a weak knowledge system through memory and direct access to headquarters. Five employees expose the gaps much faster.

The first hire may know who to ask, how a local process differs from the standard one, or which workaround keeps a recurring issue moving. New colleagues don't automatically inherit that context. If it remains in private conversations, onboarding starts to depend on whoever happened to join first.

This is the point where local operating knowledge needs a durable home inside the organisation. For some companies, that may be an established knowledge platform; for others, it may mean building a dedicated training or knowledge-delivery platform around their internal processes. That doesn't mean documenting every conversation. Focus on information another person would struggle to reconstruct later, especially recurring exceptions and the reasoning behind local process differences. The aim is continuity, not documentation volume.

Entity planning includes a knowledge inventory

When a company starts considering its own local entity, discussion usually centres on legal structure, cost, and employment administration. Knowledge Management belongs in that planning as well because a new entity changes who owns processes and who performs them.

Work previously handled through external employment infrastructure may move to internal teams. If the transfer is treated as a records migration, the company can bring over the files while leaving behind the operational memory that made those files understandable.

Before responsibilities move, identify what the incoming owner must be able to explain without relying on the previous one. Policy rationale and unresolved employee matters deserve attention, but so do informal dependencies that have quietly become part of local operations. ISO 30401 treats knowledge management as a management system that is established, maintained, reviewed, and improved. That principle fits expansion well because the knowledge system has to evolve with the operating model.

Give the handoff an owner on both sides

A cleaner transition has an outgoing owner who understands the current arrangement and an incoming owner who will carry the responsibility forward. Granting system access or transferring folders doesn't create that understanding on its own.

A useful handoff records both the decision and the reasoning behind it. It also makes unresolved issues visible and names the person who owns the next step. That exposes weak spots before they become inherited problems. If nobody can explain a recurring payroll exception, resolve it before the new entity takes responsibility, ideally by tracking it directly in the company's HR software rather than relying on individual memory.  If a local manager has been handling an unofficial onboarding step for a year, decide whether that practice belongs in the formal process before it disappears into another handoff.

A simple test before the structure changes

Legal structures change as international operations mature. The more useful measure of continuity is whether the next owner can understand the operation without reconstructing its history from scattered files and old messages.

Before transferring employment responsibilities, ask whether the incoming team can explain the important local decisions, the exceptions that still matter, and the reasoning behind current processes without calling the outgoing owner for context. If the answer is no, the transfer isn't finished. That test gives KM teams a practical way to judge readiness before an administrative change becomes a knowledge loss event.

_____________________________

Most KM programs fail at the same step: nobody can see what they actually have. Not for lack of content — organizations are full of knowledge.

The problem is visibility. What exists, where it lives, who owns it, who needs it, and where the gaps quietly sit.

I have put together a Knowledge Mapping Playbook:
a practical framework to map an organization's knowledge, assess it, prioritize the gaps that matter,
and turn findings into action — from SME interviews to
a governance checklist to a one-page operating model.

A map makes knowledge and gaps visible.

A playbook makes it actionable. Sharing the playbook below — curious how others are tackling this...

Knowledge Mapping and Playbook Download....
‍
‍

_______________________

Something happens to organizations in the Summer and most of us feel it without naming it.

The building runs on a smaller crew. Half the people who normally answer within the hour are somewhere with their phone face down and quite a lot of what the organisation knows is away with them.
‍

This is when you find out what your organisation actually knows, as opposed to what a few individuals happen to remember.

For most of the year, the gap is invisible. When everyone is present, missing reasoning gets patched in real time. You don't understand why a process works the way it does, so you ask the person who designed it, and they explain it from memory in thirty seconds. The knowledge was never written down, but it was never missed either, because the carrier was at the next desk.

Summer removes the carrier. The person who could explain in thirty seconds is on a beach, and the same question now takes a colleague half a day of digging or worse, produces a confident guess that turns out wrong.

None of this is a crisis. It is mildly inconvenient, and it resolves itself in September. But it is a useful, low-stakes preview of a much larger problem, because the holiday gap and the permanent gap are the same gap.

When someone goes on leave, their knowledge becomes temporarily inaccessible. When someone leaves for good, or moves roles, or retires, that same knowledge becomes permanently inaccessible and there is no September to look forward to. The reasoning behind a decision they made three years ago doesn't come back from holiday. It is simply gone, and the record that remains confirms that the decision was made without explaining why.

Summer just makes the mechanism briefly visible.

So it is worth paying attention to what the quiet weeks reveal. Which questions can't be answered while a particular person is away? Which processes only really make sense to one individual? Where does the covering colleague say "I'll check when they're back" — and what would happen if they never came back?

Those are not summer problems. They are the year-round problems, wearing a lighter outfit.

The organisations that handle August well are usually the ones that already do the unglamorous work: capturing why things are done the way they are, not only how; keeping the reasoning behind decisions accessible to people who weren't there when they were made. For them, a colleague going on leave is a scheduling matter, not a knowledge outage.

For everyone else, summer is a two-month reminder that quite a lot of what the organisation knows is actually just what specific people remember.

The good news is that it's a gentle reminder. Nothing important usually breaks in August. But it's worth noticing what goes quiet while people are away, because the same silence arrives permanently, eventually, and with far less warning.

For now, though, if you're one of the people currently away-enjoy it. The reasoning will keep until September.

And if you're holding the fort: make a quiet note of every question you couldn't answer this month. That list is more valuable than it looks.

The views expressed in this article are my own and do not represent the position of my employer or any institution I am associated with.

_________________________________________________