Opening — From AI-generated hypotheses to shared organisational knowledge
The NaturFlourish Knowledge Base was developed through a collaborative Human–AI modelling exercise using the Human–AI Knowledge Base Development Guideline (HAK V4), an existing Sparx Enterprise Architect repository exported in XMI format, and a detailed research query describing the proposed organisation and its operating environment.
AI was tasked with investigating the proposed business in the context of its industry, markets, products, technologies, supply chains, competitors, regulatory obligations and wider social and environmental environment. Drawing on commonly available research, relevant standards, industry practices and comparable organisations, it was asked to identify candidate stakeholders, investigate their likely interests and concerns, and propose the outcomes they might reasonably expect or seek to avoid.
The existing Sparx models provided an architectural starting point, while HAK V4 supplied the methodology and modelling disciplines. AI could examine and extend the emerging knowledge structure, identify inconsistencies and missing relationships, and propose connections among stakeholder outcomes, value propositions, capabilities, information and work.
The exercise also illustrates the principle of Prefabricated Architecture: beginning with an existing integrated architectural base rather than recreating familiar capabilities and information structures from scratch. The reusable foundation accelerates investigation and model development, while HAK and Kanban Architecture provide the disciplines for contextualisation, validation and continuing regeneration.
The resulting models were not intended to represent authoritative knowledge of NaturFlourish. They were working hypotheses, informed by available evidence and explicitly subject to challenge.
This distinction is fundamental. AI can investigate and generate candidate knowledge at a scale and speed that would otherwise require considerable human effort. But publicly available information cannot fully explain an organisation’s lived reality, tacit knowledge, stakeholder relationships or operational circumstances.
The models are therefore a means to an end, not an end in themselves.
Their purpose is to provide coherent, accessible and testable propositions that people can discuss, challenge and progressively validate at Gemba. Through this interaction, previously disconnected perspectives can be brought together, assumptions exposed, consequences examined and shared organisational knowledge developed.
The following Sparx Enterprise Architect views illustrate how the NaturFlourish Knowledge Base connects different aspects of that emerging understanding. They are different views of one repository, not seven independently constructed models.
Using the Human–AI Knowledge Base Tool: A NaturFlourish Example
The Human–AI Knowledge Base Tool uses guided collaboration between people and AI to develop candidate organisational knowledge quickly, connect it across different organisational views, and test it against reality.
NaturFlourish provides a practical example of what the cycle produces at each stage.
The objective is not to create an authoritative AI-generated model.
It is to progressively develop a shared, connected and testable Knowledge Base that people can understand, challenge and improve.
The Human–AI Knowledge Base Cycle
The cycle begins with candidate stakeholders and progressively connects:
Stakeholders → Outcomes & KPIs → Value Propositions & Value Flow → Capabilities, Data & KPIs → Process Step Mapping → Gemba Validation → Learning, Reframing & Revision
The sequence provides a disciplined direction of enquiry, but it is not a waterfall. Any stage may reveal evidence that requires reconsidering an earlier assumption, boundary, or model element.
The entire cycle operates within Purpose, Ethics and Governance.
Every output begins as candidate knowledge. AI can research, compare, synthesise and propose structures rapidly. Humans contribute context, lived experience, practical judgement and accountability. Gemba provides the reality test.
Figure 1 — The Human–AI Knowledge Base Cycle
The Human–AI Knowledge Base Cycle provides the organising method for the investigation. It begins with candidate stakeholders and their perceived outcomes, develops propositions about how value might be created, and identifies the capabilities, information and activities required to realise that value.
Purpose, Ethics and Governance provide the containing framework. Gemba validation connects every stage to the people who perform, depend upon or experience the work and its consequences.
The cycle is iterative rather than sequential. Evidence arising anywhere in the model may challenge an earlier assumption, requiring confirmation, revision or reframing.
Figure 1. The Human–AI Knowledge Base Cycle — developing and regenerating connected organisational knowledge through Human–AI collaboration and validation at Gemba.
Figure 2 — Stakeholder Management Capability Hierarchy
The Business Capability Model provides a relatively stable description of what an organisation must be able to do, independently of its current organisation chart, systems and processes.
This view shows the decomposition of Stakeholder Management into distinct capabilities focused on stakeholder profiles, relationships, engagement, communication, and associated responsibilities.
The coloured containers distinguish Level 1 (green), Level 2 (blue) and Level 3 (orange) capabilities. Each level progressively clarifies the capability’s boundary and responsibilities.
The model provides the structural foundation for identifying the information, activities and evidence associated with individual L3 capabilities.
Figure 2. NaturFlourish Stakeholder Management — the governed decomposition of a Level 1 capability into L2 and L3 responsibilities.
Figure 3 — Product Management Capability Hierarchy
Product Management provides a second example of capability decomposition, this time directly supporting the NaturFlourish product-development scenario.
Its L2 capabilities distinguish New Product Development from Product Lifecycle, Claims and Information Management. Their L3 capabilities identify specific responsibilities, including Product Concept and Requirements Management, Formulation Development, Product Evidence and Testing Management, Product Specification Management, and Product Claim and Evidence Management.
This decomposition is important because it establishes where information is governed, rather than merely where it is used.
Under HAK, canonical Entity Types are located with the L3 capability responsible for their lifecycle governance. Other capabilities may reference and use that information without acquiring separate ownership or creating duplicate definitions.
Figure 3. NaturFlourish Product Management — the L1–L3 capability structure used to establish responsibility for product development and lifecycle knowledge.
Example of L3 Convergence — Product Evidence & Testing Management
At L3, three views come together:
L3 Capability = Entity Ownership + Activity Set + KPI Cluster
Capability — Product Evidence & Testing Management
The ability to plan, obtain, evaluate, maintain and govern the evidence required to support product-development decisions.
Principal information
Product Evidence Package — the governed collection of evidence relating to a product or product concept, including its scope, status, limitations and review history.
Candidate Activities
- Define product evidence requirements.
- Plan and coordinate product testing.
- Collect and evaluate evidence.
- Maintain the Product Evidence Package.
- Review evidence completeness and limitations.
- Provide evidence for product-development decisions.
Candidate KPI evidence
- Evidence completeness against agreed requirements.
- Percentage of evidence with traceable provenance.
- Outstanding evidence gaps.
- Timeliness of evidence reviews.
- Percentage of product candidates with sufficient evidence to support an accountable decision.
This connects what NaturFlourish must be able to do, what it must know, the work performed, and the evidence used to judge the effectiveness of that capability.
Status: The capability and principal Entity Type are drawn from the candidate NaturFlourish architecture. Activities and KPI measures are proposed patterns requiring Gemba validation.
Figure 4 — Gut Health Part 1: Stakeholder, Outcome and Value Proposition
| Stakeholder | Candidate outcome | Candidate evidence |
| Customers | Customers can obtain safe, effective and understandable products they can trust. | Repeat purchase, complaints, product-quality incidents, OTIF delivery |
| Employees | People can perform required work safely with manageable workload, reliable information and appropriate authority. | Safety indicators, engagement, fatigue/workload signals, rework |
| Suppliers | Suppliers can meet clear requirements without unreasonable transfer of cost, uncertainty or quality risk. | Supplier conformance, delivery reliability, disputes, corrective actions |
| Regulators | Regulators can rely on complete, traceable and trustworthy evidence of compliance. | Compliance incidents, deviations, release evidence, audit findings |
| Owners / Board | NaturFlourish remains viable while protecting trust, quality and organisational resilience. | Revenue growth, gross margin, innovation conversion, compliance |
| Environment | Products and operations avoid unacceptable waste, resource depletion and displaced environmental harm. | Carbon/waste intensity, energy use, yield and material loss |
No single measure tells the whole story. Speed must be read with quality, cost with stakeholder outcome, and throughput with human and environmental burden.
The following view form Sparx begins with the Consumer / End User stakeholder and the more specific Prospective Gut-Health Consumer role.
The proposed outcome, Safe and Credible Consumer Benefit, describes what matters from the consumer’s perspective: making a well-grounded choice without misleading efficacy assertions.
The corresponding value proposition, Evidence-Informed Gut-Health Offering, describes how NaturFlourish proposes to contribute to that outcome. The Consumer Value and Consequences view preserves the consumer’s perspective, including potential benefits, uncertainties and harms.
The Product Business Object connects to the canonical information architecture.
The view illustrates a fundamental HAK principle: stakeholder outcomes should pull the development of value propositions and capabilities, rather than the organisation assuming that what it already produces must be valuable.
Figure 4. Gut Health — candidate stakeholder roles, desired outcomes, potential consequences and the value proposition they inform.
Figure 5 — Gut Health Part 2: Value Chain and Value Stages
The second Gut Health view follows the same Evidence-Informed Gut-Health Offering into the proposed enterprise value-creation structure.
Four candidate Value Stages are shown: Understanding Stakeholder Needs, Developing Product Candidates, Generating and Assessing Evidence, and Approving and Transitioning Products.
These stages describe how value is progressively developed and protected. They are not detailed process steps and should not be confused with the organisational capabilities required to perform the work.
The view provides a bridge from stakeholder expectations to the Principal Value Streams, capabilities, information and decisions through which NaturFlourish proposes to deliver value.
The four-stage structure is a candidate product-development-focused view. Its relationship to the wider enterprise value chain remains subject to business validation.
Figure 5. Gut Health — a proposed value-creation structure connecting the consumer value proposition to the stages of product development and accountable decision-making.
Figure 6 — From Strategic Opportunity to Accountable Product Decision
The Common Data Model provides the governed information structures underpinning the value architecture.
In this example, opportunities arising through Scenario Planning can become Product Development Candidates. Candidates are assessed against relevant criteria, and accountable human decisions determine whether they should progress, be reconsidered, be placed on hold, or be rejected.
The model distinguishes a candidate, its assessments, the resulting decisions and the Product Concept concerned. Their relationships allow the rationale for product-development activity to be traced back to the original opportunity and supporting evidence.
An assessment informs judgement; it does not replace the decision-maker’s accountability.
Figure 6. NaturFlourish Product Development Candidate — the canonical information relationships supporting strategic traceability, assessment and accountable human decision-making.
Figure 7 — Evidence Governance and Claim Traceability
An essential feature of the NaturFlourish Knowledge Base is the distinction between a proposed product, the evidence available to support it, and the claims that may legitimately be made about it.
The Common Data Model connects Product Evidence Packages with Claim Evidence Packages and individual Product Claims. These relationships support traceability to the evidence on which a claim depends, including its limitations, jurisdiction, review status and approval history.
This demonstrates how the Knowledge Base can support responsible product-development decisions while preserving the distinction between an assertion and its substantiation.
It also provides a basis for reconsidering previously accepted knowledge when new evidence, changed circumstances, or regulatory requirements emerge.
Figure 7. NaturFlourish evidence governance — the relationship between product-development evidence, claim-specific evidence and the claims requiring substantiation.
From Models to Work
The preceding figures illustrate how different organisational perspectives can be connected through a shared Knowledge Base.
The Business Capability Model describes what NaturFlourish must be able to do. The Common Data Model identifies what it must understand and govern. Stakeholder outcomes, value propositions and value-flow models explain why these capabilities matter, while evidence and decision structures make their supporting rationale traceable.
However, capabilities and information structures do not, by themselves, describe how work is performed.
To understand the organisation in operation, we must examine how capabilities, activities, information and decisions come together in processes that create and deliver value.
Process Step Mapping
Question: How do capabilities combine when real work is performed?
Capabilities are not processes. The Process view shows how activities from different capabilities are coordinated through conditions, decisions and sequence to achieve a particular outcome.
Example — Assess and Decide a Product Development Candidate
Trigger: A stakeholder need, market opportunity or strategic option has been identified.
- Identify and describe the stakeholder need or opportunity.
- Register a Product Development Candidate.
- Establish candidate product requirements and intended stakeholder outcomes.
- Investigate formulation, packaging and manufacturing options.
- Identify regulatory requirements, potential claims and evidence needs.
- Generate and assess available evidence, including feasibility and stakeholder consequences.
- Evaluate alternatives, uncertainties and trade-offs.
- Make and record an accountable decision to progress, revise, defer or reject the candidate.
- Where approved, authorise the appropriate next stage of product development.
Outcome: An accountable product-development decision supported by traceable evidence, recorded assumptions and an understanding of potential consequences.
The process draws upon New Product Development, Product Evidence & Testing Management, Product Claim & Evidence Management and other relevant capabilities. It uses the canonical Entity Types without transferring their lifecycle ownership to the process.
Status: Pattern Proposal — the sequence, decision rights, exceptions, information requirements and actual work practices remain subject to Gemba validation.
Question: How do capabilities combine when real work is performed?
Capabilities are not processes. The Process view shows how stable work from different capabilities is coordinated through conditions and sequence.
Gemba Validation
Question: Where does our model fail to describe what actually happens?
NaturFlourish already provides a useful example of why this matters. This is taken from the book Lead, Transform & Navigate, when Bruno’s updated BCM is taken to the Manufacturing Gemba for review.
Initial framing
Packaging may seem like a downstream choice made after product formulation.
Reality challenged the framing.
When NaturFlourish examined real product options, packaging and formulation could not be separated.
A packaging option that worked mechanically required excipients that would undermine a proposed 100% organic claim.
Sachets could control dosage without some of those binders, coatings, or flow agents—meaning the packaging could do work otherwise imposed on the formulation.
Compostable formats introduced another trade-off: they better protected the environmental promise but created tighter operational and shelf-life constraints.
What changed
The issue was no longer:
Which package should we use?
It became:
How do formulation, packaging, manufacturing, claims, customer trust, environmental consequence, shelf life and economics remain coherent as one connected value system?
That is a reframe, not merely a correction to one specification.
It demonstrates the learning loop:
Model → Reality → Challenge → Reframe → Revised Knowledge Base
The model did not become weaker because reality contradicted its original framing.
It became more useful.
The discipline is simple:
- The model goes to Gemba.
- Gemba challenges the model.
- Humans and AI learn.
- The model changes.
A coherent model that has not survived informed challenge at Gemba remains a hypothesis.
What this example demonstrates
The NaturFlourish example shows that Human–AI collaboration can help an organisation:
The six deliverables together
WHO MATTERS? Candidate Stakeholders
→ WHAT MATTERS TO THEM? Stakeholder Outcomes & KPI Evidence
→ HOW IS VALUE CREATED? Value Propositions & Enterprise Value Chain
→ WHAT MUST WE BE ABLE TO DO AND KNOW? BCM + L3 Capabilities + Entities + Activities + KPIs
→ HOW DOES THE WORK COME TOGETHER? Process Step Mapping
→ DOES IT SURVIVE REALITY? Gemba → Confirm / Revise / Reframe
↺ The Knowledge Base changes
All of this remains contained by: Purpose · Ethics · Governance
AI may generate at machine scale. Humans can only validate at human scale.
The Knowledge Base must therefore remain mind-sized, discussable and testable.
Explore the NaturFlourish HAK Workbook
Open the candidate Human–AI Knowledge Base used in this worked example. The workbook is deliberately presented as a strawman for socialisation, challenge and Gemba validation.
Open the NaturFlourish HAK Workbook
Explore further
- 📝 Human–AI Knowledge Base Development
- 📝 Knowledge Operating System
- 📝 Gemba
- 📝 Stakeholder Engagement
- 📝 Value Stream
- 📝Business Capability Model
- Source Note: Human–AI Knowledge Base Development Guideline