Subject Area: Human–AI Knowledge Base Development

Using guided Human–AI collaboration to develop, socialise, test and continuously refine a shared organisational Knowledge Base.

What it is

Human–AI Knowledge Base Development is a disciplined approach to developing candidate organisational knowledge through collaboration between people and AI.

AI can rapidly research, compare, synthesise, identify patterns, test relationships and propose structures. Humans contribute lived experience, context, relationships, ethical judgement, practical wisdom and accountability.

Neither is sufficient on its own.

The purpose is not for AI to produce an authoritative model. It is to create increasingly useful candidate knowledge, socialise it with the people who know and experience the organisation, and repeatedly expose it to organisational reality.

Knowledge becomes useful when people can understand it, challenge it, connect it to their experience and use it to act.

The Human–AI Knowledge Base Development Cycle

The cycle progressively develops and connects:

→ Candidate Stakeholders
→ Stakeholder Outcomes & KPIs
→ Value Propositions & Value Chain
→ BCM L1 & Capability Pledges
→ BCM L2/L3, KPIs & Data
→ Gemba Validation
→ Learn, Reframe & Revise

The clockwise sequence shows the dominant direction of inquiry, but it is not a waterfall.

Each stage creates questions for the others.

A stakeholder conversation may reveal a missing outcome. A value stream may expose a capability that has been overlooked. A process observation may reveal that the data model does not reflect reality. A Capability Pledge may expose disagreement about what a capability is actually expected to deliver. Gemba may demonstrate that the original framing was wrong.

The cycle therefore loops backwards, forwards and across the Knowledge Base as understanding develops.

The entire cycle operates within Purpose, Ethics and Governance.

Start with stakeholders

The Knowledge Base begins with people and organisations that affect, or are affected by, what the organisation does.

But identifying a stakeholder is not enough. We need to understand the role they play, what they value, what outcomes matter to them and how they experience the organisation.

A deceptively simple question can open the conversation — the Tardis Pub Test:

“It is Friday night five years from now. You are talking to a friend and say, ‘This organisation is brilliant because of these five things.’ What are the five things you would want that stakeholder to say?”

The logic is quite simple: if you are perceived as successful in the eyes of all your stakeholders — including yourself — you are, by definition, successful.

The challenge is discovering what successful means to each of them.

Those answers provide candidate stakeholder outcomes.

They can then be explored, challenged and translated into observable outcomes and meaningful measures.

This moves stakeholder analysis beyond a list of names and influence ratings. It begins to reveal what organisational success looks like from different perspectives.

From value to capability

Stakeholder outcomes lead naturally to questions about value.

What promise is the organisation making?

How is that value created?

The Enterprise Value Chain provides the high-level organisational story. Principal Value Streams then follow value through the organisation from particular stakeholder perspectives.

Different stakeholders may experience the same organisation very differently.

Stakeholder Value Views, scenarios and playbooks allow the Knowledge Base to explore those differences without attempting to force every situation into a single process model.

From these views we can ask:

What must the organisation be capable of doing to deliver this value?

That leads to the Business Capability Model and its connection to the Principal Entities — the people, things, agreements, resources and concepts the organisation must know and manage.

The Capability Pledge

A capability is more than a box on a Business Capability Model.

Someone must ultimately stand behind it.

The Capability Pledge makes that responsibility explicit. It is a negotiated promise from the capability owner to the rest of the organisation and its stakeholders about:

why the capability exists,
who it serves,
what outcomes it supports,
what others should be able to expect from it,
and the standards by which it intends to operate.

It becomes the mission statement for the capability.

The principle is:

Pledge before measure.

Before deciding how a capability should be measured, establish what it is promising to deliver.

KPIs can then become evidence about whether that promise is being kept rather than disconnected measures imposed upon the work.

Why Gemba matters

AI-generated models can be coherent, plausible and persuasive, yet still be wrong.

Gemba provides the reality test.

The relevant Gemba is wherever the work, relationship, service or consequence being modelled is actually experienced — by employees, customers, suppliers, communities or others affected by organisational action.

The discipline is simple:

The model goes to Gemba.
Gemba challenges the model.
Humans and AI learn.
The model changes.

Gemba validation is therefore not a final approval step.

It occurs throughout the development cycle.

A model that cannot survive informed disagreement at Gemba remains a hypothesis.

Socialisation turns models into shared knowledge

Creating a model is not the same as creating organisational knowledge.

Candidate knowledge must be discussed, challenged, combined with experience and incorporated into how people understand and perform their work.

Human–AI collaboration can support this process across the SECI knowledge cycle.

AI can help people articulate tacit knowledge, compare different perspectives, combine explicit knowledge and expose contradictions or gaps.

Humans provide the lived experience, relationships, interpretation, judgement and practical wisdom through which that material acquires meaning.

The Knowledge Base therefore becomes more than a repository.

It becomes a shared object around which organisational dialogue, learning and sensemaking can occur.

What the cycle develops

The cycle progressively connects different views of the same organisation:

Stakeholders and Roles — who matters, how they participate and who experiences consequence.
Outcomes and KPIs — what matters to stakeholders and how it can be observed.
Value Propositions — what value the organisation promises.
Value Chain and Value Streams — how that value is expected to be created and experienced.
Stakeholder Value Views and Scenarios — how different people encounter the organisation in different circumstances.
Business Capabilities — what the organisation must be able to do.
Capability Pledges — what capability owners promise the organisation and its stakeholders.
Principal Entities and Data — what the organisation must know and manage.
Activities and Processes — how capability is enacted in practice.
Gemba Evidence — what actually happens when those assumptions meet reality.

Together these form an increasingly connected organisational Knowledge Base rather than a collection of isolated models.

At L3 in the Business Capability Model, capability, data, activity and measurement begin to converge, creating an important structural connection between what the organisation must be able to do, what it must know, what actually happens and how performance is understood.

Human and AI roles

Human–AI collaboration works because the participants contribute different things.

AI can help to:

research organisations and their environments,
compare analogous organisations and industries,
identify patterns and possible omissions,
propose candidate stakeholders, outcomes and KPIs,
develop candidate value propositions, value streams and capabilities,
identify relationships between capabilities, activities and data,
test consistency and expose contradictions,
support socialisation and structured dialogue,
and accelerate exploration.

Humans remain responsible for:

context,
meaning,
ethical judgement,
relationships,
lived and practical experience,
negotiation and socialisation,
Gemba validation,
decisions,
accountability,
and consequences.

AI can support reasoning.

It does not bear consequences.

People do.

How it works in practice

Using the guideline does not require people to understand enterprise architecture, data modelling or specialist terminology.

It can begin with a well-framed question in ordinary language:

“I run a crash repair and mechanical repair business specialising in insurance repairs, vehicle restoration, taxi compliance and general mechanical repairs. Please give me something my team and I can use to understand how we create value for our customers.”

The guideline provides the underlying structure.

AI uses that structure to turn the question into a candidate, mind-sized model that people can understand and discuss.

For a local small business, this produced a simple shared value story:

understand the need → agree the work → prepare for work → restore or protect the vehicle → assure quality, safety and compliance → return the customer to service.

The result was deliberately presented as candidate knowledge, not a finished answer.

The team can put it on the wall, challenge it, identify what is missing, explore different stakeholder perspectives and test it against what actually happens in the work.

This is Kanban Architecture in action:

Architecture created on demand, when required, in response to a real business question.

The complexity remains in the guideline and the AI.

The human conversation can remain simple.

The Golden Rule

AI changes the scale and speed at which candidate knowledge can be generated.

That creates enormous opportunity — but also the danger of producing more complexity than people can meaningfully understand, challenge, socialise or validate.

The governing rule is therefore:

AI may generate at machine scale. Humans can only validate at human scale.

Outputs must remain mind sized.

Models should be presented in forms that people can:

understand,
discuss,
challenge,
connect to their own experience,
negotiate with others,
and validate at Gemba.

The objective is not maximum model production.

It is shared understanding sufficiently grounded in organisational reality to support better judgement, learning and action.

Adapt, Survive & Flourish