L3 Validation, Regeneration and Sparx Governance

Version: 1.1 Status: Working supporting note Date: 12 September 2026 Document owner: Rob Malcolm Companion guideline: Human-AI Knowledge Base Development Guideline V1.4 Revision 1.1 realigns the supporting note with HAK V1.4 and the repository architecture adopted for the Sparx trial. It retains the validation, Kanban, decision and regeneration disciplines of V1.0 while replacing the former ‘Sparx as projection’ model with a persistent structural repository model and adopting the Common Data Model / Business Object / Entity Type / L3 Subject Area terminology.

1. Purpose and practical significance

The Human-AI Knowledge Base (HAK) method develops shared organisational knowledge that people can test, govern and use. AI can generate broad enterprise structures quickly. Establishing whether those structures reflect real work, what they mean, who may rely on them, and what must change when evidence contradicts them requires sustained human judgement. This supporting note defines the governance needed to make that work credible. It explains how L3 Subject Areas are prepared and validated at Gemba, how validation work is pulled through a Kanban flow, how decisions and evidence are preserved, and how Sparx Enterprise Architect serves as the persistent structural repository for the governed architecture and Common Data Model. The note is intended for practitioners, architects, capability owners, capability and data stewards, facilitators, tool specialists and colleagues who need to understand the depth behind a HAK model. A single relationship on a diagram may embody a pricing rule, an authority limit, a contractual dependency, a lifecycle constraint and a consequence for another stakeholder. Validation must expose those meanings; governance must preserve the evidence and decisions through every regeneration. Use this note with HAK V1.4. The guideline defines the modelling method, semantic acceptance gates, required artefacts and XMI rules. This note provides the detailed operating governance. A coherent model, a successful Sparx import or a polished diagram does not, by itself, constitute organisational approval.

1.1 Governing contract

• Purpose and ethics contain the work. Governance keeps decisions, evidence, authority and consequences answerable to them.
• Generated content remains candidate knowledge until people with relevant knowledge test it and accountable humans decide what may be accepted.
• The Common Data Model (CDM) is the governed integrated enterprise model of what the business deals with. It is maintained with logical data-modelling rigour and may be presented through different views.
• Business Objects provide the mind-sized enterprise semantic anchors of the CDM. The Business Object View is the high-level enterprise map; detailed Entity Types, subtypes, attributes and relationships provide logical detail.
• Each L3 Subject Area belongs to one L3 Capability and is centred on one Root Entity Type.
• The L3 Capability responsible for the Root Entity Type is the Subject Area’s Home L3 Capability.
• An L3 Subject Area is built around one Root Entity Type. It includes the Entity Types needed to understand and validate that Root Entity Type. Other Entity Types may be shown where their relationship to the root matters, but they remain governed elsewhere.
• AI generates holistically. Kanban Architecture limits human validation work in progress based on need, consequence, and available Gemba capacity.
• Sparx is the persistent canonical repository for structured architectural and CDM knowledge. Diagrams and reports are views of that repository; they are not separate models.
• Regeneration may replace controlled candidate structures, but it must not silently overwrite validated meaning, human evidence, decisions, stable identifiers or the Approved Baseline.
• Material changes return affected knowledge to review. Stable identifiers preserve continuity and traceability; they do not automatically preserve the validity of changed meaning.

1.2 Core terminology

Common Data Model (CDM): the governed integrated enterprise model of the business concepts, Entity Types and relationships the organisation needs to understand and share. The CDM is independent of physical database design and is maintained with sufficient logical rigour to preserve semantic integrity.

Business Object: an ArchiMate-aligned business concept of enduring significance, such as Product, Asset, Agreement, Stakeholder or Location. Business Objects provide enterprise semantic anchors and appear in the Business Object View.

Business Object View: the mind-sized enterprise view of the CDM showing major Business Objects and their material relationships. It is the enterprise ‘highway map’, not a separate Conceptual Data Model.

Entity Type: a logically defined type in the detailed CDM, with identity, definition, relationships and, where required, attributes, identifiers, cardinalities, optionality and subtype structure.

Root Entity Type: the one Entity Type that provides the semantic centre and point of entry for an L3 Subject Area.

Core/Dependent Entity Type: an Entity Type whose meaning, identity, composition or lifecycle is materially bound to the Root Entity Type for the purpose of the Subject Area.

Peripheral Entity Type: a canonical Entity Type governed elsewhere but shown because a material relationship to the root or core is necessary to understand and validate the Subject Area.

L3 Subject Area: a mind-sized, root-centred semantic validation view of the CDM associated with exactly one Home L3 Capability.

Gemba: the actual place where work, service, relationship or consequence is experienced.

XMI: an interchange mechanism used to transfer governed model structures into or out of Sparx. XMI is not the semantic source of truth.

1.3 What the work demands

A meaningful validation session requires preparation, access to real work and records, people who understand normal and exceptional cases, and someone with authority to resolve or escalate resulting decisions. The facilitator preserves disagreement and attributable dialogue; the modeller traces consequences across related model elements; owners and stewards determine what is supported, what remains uncertain, and what may be relied upon. Progress is therefore visible in better-tested meaning, bounded uncertainty, traceable decisions, and understood consequences. Counts of generated elements, polished diagrams, completed comment threads, or successful XMI imports are not substitutes for those outcomes.

2. Governing principles

The principles below retain the foundation of the earlier supporting note but use the terminology and repository architecture adopted for HAK V1.4.

2.1 Meaning Before Metadata

Mindset: Business understanding precedes technical representation.

Why: A technically precise model can still be wrong if its terms do not reflect the meaning understood by the people who create, use, govern or experience the business.

What: Establish the business meaning, identity, boundaries and purpose of each element before assigning attributes, formats, identifiers or implementation details.

Where: Across capability, process, data, organisation, system and technology modelling.

When: Before treating detailed specifications, schemas, interfaces, configurations, or implementation artefacts as authoritative.

Who: Business practitioners, subject-matter experts, architects, analysts, data professionals, technology specialists and affected stakeholders.

How: Define terms in context, distinguish what each element is and is not, identify synonyms and conflicting meanings, test definitions through examples and Gemba evidence, and obtain accountable human acceptance before technical detail is treated as governed meaning.

2.2 Reality First

Mindset: Acceptance of reality with humility.

Why: Good decisions depend on understanding reality, not protecting assumptions, established models or preferred narratives.

What: Seek the best available understanding of what is actually happening, including informal practice, workarounds, constraints, exceptions and consequences absent from formal documentation.

Where: Across the organisation and its external environment.

When: Before, during and after significant decisions and changes.

Who: Everyone who contributes to, validates, governs or is affected by the work.

How: Stay connected to Gemba, affected stakeholders, trustworthy information, observable consequences and informed judgement. Compare the official story with lived experience and investigate material differences.

2.3 Single Version of the Truth

Mindset: Seek the single version of the truth and work collectively to make it so.

Why: Competing definitions and duplicate models weaken shared understanding and create hidden inconsistency.

What: Maintain one authoritative enterprise knowledge structure for common definitions, distinctions and relationships. Treat it as the best current shared representation of reality, not as infallible truth.

Where: Wherever the organisation describes, decides upon or changes capabilities, information, work, services, products, systems and relationships.

When: Continuously.

Who: Everyone who creates, uses, interprets, governs or is affected by enterprise knowledge.

How: Reuse canonical repository elements rather than creating project-specific alternatives. Test them against Gemba and evidence, preserve dissent where unresolved, and revise the repository when reality shows the current representation is incomplete or wrong.

2.4 Keep Organisational Views Distinct but Connected

Mindset: Maintain clarity and cohesion by treating different organisational views as distinct but explicitly connected.

Why: Mixing capabilities, processes, activities, roles, data, systems and organisation units produces unstable models and obscures the relationships through which value, information, authority, risk and consequence move.

What: Define each artefact according to what kind of thing it is, apply the rules appropriate to that type, then connect artefacts through explicitly governed relationships.

Where: Across all enterprise models and repository views.

When: During discovery, modelling, validation, integration, implementation and governance.

Who: Business practitioners, owners and stewards, architects, analysts, data professionals, technology specialists and governance bodies.

How: Classify each proposed artefact before modelling it. Keep implementation choices separate from enduring business meaning and use the repository to connect, rather than collapse, different views.

On design, a cautionary note

The architect’s role is not to reproduce the organisation’s current mental model. It is to help the organisation examine, challenge and improve that mental model.

Organisational language, structures, systems and established practices provide important evidence, but they are not automatically sound architecture. Existing models may reflect historical compromises, organisational silos, duplicated responsibilities, inherited terminology or the current organisation chart. Architects and modellers must respect local knowledge while testing it against sound modelling principles, reusable patterns, semantic coherence and Gemba reality.

Gemba evidence establishes how the organisation actually works. It does not require the architecture simply to reproduce current practice. Where the existing mental model is fragmented, ambiguous or inconsistent, the modelling process should make that visible and help the organisation develop a clearer shared understanding.

2.5 Ownership Follows Lifecycle Accountability

Mindset: Ownership and stewardship follow authority over meaning and lifecycle, not system location or usage.

Why: Without explicit accountability, people may change meaning or state without appropriate authority; duplicate ownership claims expose boundary problems.

What: Assign one accountable governance home for each governed lifecycle and named stewardship for maintaining integrity within delegated authority.

Where: Across capabilities, Business Objects, Entity Types, Activities, processes, services, policies and other governed artefacts.

When: From proposal through use, change and retirement.

Who: L1 Capability Owners, L3 Capability Stewards, Data Owners and Data Stewards, supported by custodians, users and governance bodies.

How: Define lifecycle stages and decision rights, distinguish ownership from custody and use, and resolve gaps or competing claims explicitly. For an L3 Subject Area, the lifecycle governance home of the Root Entity Type determines the Home L3 Capability.

2.6 Models Are Negotiated Knowledge

Mindset: Hold different interpretations in constructive tension until the organisation has a more grounded understanding.

Why: Definitions and boundaries reflect experience, interests, assumptions and perspectives. Authority or majority agreement alone does not create shared meaning.

What: Treat models as collective, testable representations whose meaning is proposed, challenged, refined and, where appropriate, approved.

Where: Wherever people interpret the organisation differently or experience different consequences.

When: During discovery, modelling, validation, approval and change.

Who: Model developers, subject-matter experts, decision-makers, affected stakeholders and people at Gemba.

How: Make assumptions and competing interpretations visible, preserve dissent, test proposed syntheses against evidence and lived experience, and record unresolved questions rather than smoothing them away.

2.7 Trace Every Conclusion

Mindset: Treat every conclusion as provisional and traceable.

Why: Without evidence, provenance, context and visible reasoning, a conclusion cannot be reliably challenged, reproduced or revised.

What: Maintain traceability from model elements and decisions to sources, assumptions, evidence, interpretations, dissent and unresolved questions.

Where: Across all HAK work and repository content.

When: From initial discovery through approval, implementation, use and review.

Who: Everyone who proposes, changes, validates or approves model content.

How: Record provenance, distinguish observation from interpretation and AI proposal, link decisions to exact proposition versions, and keep unresolved questions visible.

2.8 Test Before Operational Use

Mindset: Do not rely operationally on untested meaning.

Why: A coherent model can receive formal approval and still fail in practice because documents and forums do not reproduce real constraints, workarounds and consequences.

What: Treat AI-generated and human-generated outputs as proposals until tested at relevant Gemba and accepted by accountable humans for the intended use.

Where: Wherever modelled knowledge influences real work or consequence.

When: Whenever content is generated, inferred, transformed or materially changed.

Who: Practitioners, subject-matter experts, owners, stewards and approvers.

How: Label candidate content, identify assumptions, test it against real cases and stakeholder experience, record the resulting changes, and separate validation from approval.

2.9 Grow Models Purposefully and Organically

Mindset: Grow detail where it adds understanding; do not expand models simply because AI can.

Why: Unbounded detail increases cognitive load and maintenance cost, while overly rigid scope can hide important relationships and reframing opportunities.

What: Develop the repository iteratively, adding elements when they clarify meaning, ownership, relationships, consequences or implementation.

Where: Across model hierarchies, Subject Areas and related enterprise views.

When: Throughout discovery, validation and change.

Who: Modelling teams, owners, stewards, Gemba participants and affected stakeholders.

How: Start with purpose and a provisional boundary. Generate broadly where useful, but expose detail to humans through mind-sized views. Route useful findings to the appropriate part of the repository and reframe scope when double-loop learning requires it.

2.10 Test Consequence

Mindset: Prevention is better than cure.

Why: Initiatives can shift cost, risk or harm beyond their immediate boundary and appear successful while degrading another stakeholder or system.

What: Identify intended, unintended, direct, indirect, cumulative and delayed consequences across Planet, People and Prosperity.

Where: Within and beyond organisational, project, geographic, jurisdictional and generational boundaries.

When: From framing through option development, implementation and continuing operation.

Who: Decision-makers, owners, stewards, affected stakeholders, subject-matter experts and governance bodies.

How: Trace value, information, authority, risk, failure and consequence across boundaries; use Gemba, scenarios and evidence; create early-warning signals; and revise course when credible evidence shows harm.

2.11 Build on What Already Exists

Mindset: Reuse before reinventing.

Why: Duplicating capabilities, Business Objects, Entity Types, relationships and definitions weakens or destroys the Single Version of the Truth.

What: Treat approved BCM and CDM structures as stable enterprise foundations and reuse canonical elements wherever they express the required meaning.

Where: Across architecture, data, process, service, organisation and technology models.

When: Before introducing or approving a new model element, and whenever similar elements are found.

Who: Modellers, architects, analysts, owners, stewards and governance bodies.

How: Search the repository first. Compare definitions, boundaries, lifecycles and relationships; adapt only when the meaning is genuinely different; and create a new element only when existing canonical elements cannot represent the required distinction.

2.12 Generate and Exchange From Governed Repository Structures

Mindset: Technical exchange must preserve governed meaning.

Why: Successful XML or XMI import proves only technical acceptability to a tool.

What: Generate XMI and other interchange artefacts from controlled element and connector manifests derived from the governed repository structures. Treat candidate and approved scope distinctly.

Where: At the boundary between HAK generation, Sparx import/export and other modelling environments.

When: At each material regeneration and before release.

Who: Architecture Stewards, tool specialists, model owners and approvers.

How: Use HAK V1.4 Part X. Preserve stable identifiers, hierarchy, Business Object-to-Entity Type mappings, relationships, validation metadata and history. Treat import as a technical test, not semantic approval.

2.13 Consolidate Value-Flow Constructs Before Promotion

Mindset: Begin with the smallest sufficient value-flow model.

Why: Creating a separate value chain or stream for every stakeholder, product, service, or channel obscures underlying value logic and creates duplication.

What: Apply the Principal Value Stream Promotion and Consolidation Test before creating or approving additional value-flow constructs.

Where: During value-structure development, review, change control and approval.

When: Before promoting, separating or combining value-flow constructs.

Who: Owners, architects, subject-matter experts, stakeholder representatives, governance authorities and AI assistants.

How: Start with the minimum sufficient Enterprise Value Chain and Principal Value Streams. Use Stakeholder Value Views and Scenarios/Playbooks for role- or context-specific differences, as long as they preserve the required meaning.

2.14 Discover Relationships Systematically and Test Subtype Meaning

Mindset: AI achieves breadth; L3 Gemba achieves depth.

Why: An omitted relationship can hide an obligation or dependency, while a parent-level relationship can assert false meaning for a subtype.

What: Test relevant Entity Type pairs in both directions, challenge redundancy and derivability, and place each relationship at the highest level where its meaning is valid for every applicable instance.

Where: Across the detailed CDM, subtype hierarchies and Subject Area interfaces.

When: After the Business Object View and macro Entity Type classification are sufficiently coherent, and whenever meaning changes.

Who: AI performs systematic discovery and consistency checks; practitioners, modellers, Data Owners and stewards resolve meaning.

How: Use the Relationship Discovery and Subtype Refinement Matrix. Preserve pair coverage and disposition, assign stable relationship IDs, use inheritance deliberately and take relevant cases and exceptions to Gemba.

2.15 Validate Through Root-Centred L3 Subject Areas

Mindset: Give people a mind-sized coherent semantic molecule they can understand, challenge and demonstrate.

Why: Enterprise-scale output exceeds human attention, and a capability hierarchy alone does not reveal the semantic structure of the work.

What: Use the L3 Subject Area as the unit of detailed semantic validation. Each Subject Area has one Home L3 Capability, one Root Entity Type, Core/Dependent Entity Types and only necessary Peripheral Entity Types.

Where: At the convergence of CDM Entity Types, Activities, Processes, KPIs, decision rights and stakeholder experience.

When: When preparing Gemba validation and whenever discovery or evidence challenges the Subject Area boundary.

Who: The relevant Gemba community, facilitator, Home L3 Capability Steward, Data Stewards, modellers and accountable owners.

How: Start from the Root Entity Type and its lifecycle. Include only entities necessary to explain and test the semantic structure. Keep peripheral entities shallow: show the material relationship, but don’t drag their internal model into the Subject Area unless needed for the validation question.

2.16 Generate Holistically and Govern Validation Flow

Mindset: AI may generate at machine scale. People can only validate at human scale.

Why: Whole-model generation supports coherence and impact discovery, while excessive validation WIP encourages superficial review.

What: Generate the complete candidate architecture and CDM, then pull L3 Subject Areas for validation according to need, consequence and human capacity.

Where: Across the validation backlog, Gemba sessions and HAK iterations.

When: Continuously, with explicit capacity review before starting additional validation work.

Who: The Governance Owner and Architecture Steward with owners, facilitators and participating Gemba communities.

How: Operate the Kanban in Section 6. Keep blocked and contested work visible and create or reprioritise validation work when regeneration reveals material impacts.

2.17 Preserve Human Evidence and Decisions Through Regeneration

Mindset: A new model version must remain answerable to what people observed, decided and approved.

Why: Regeneration can overwrite hard-won evidence or carry approval onto changed meaning.

What: Separate candidate structures, persistent validation/evidence, and the Approved Baseline, while keeping them linked via stable identifiers and exact proposition versions.

Where: Across the HAK Knowledge Base, Sparx repository and linked evidence stores.

When: Before and after every material regeneration, import and baseline promotion.

Who: Architecture Stewards and tool specialists protect traceability; owners approve meaning; facilitators and stewards preserve evidence and qualifications.

How: Compare candidate and approved versions, retain history, flag affected knowledge, and require explicit human decisions before changed meaning is promoted.

2.18 Remove Drudgery Without Removing Apprenticeship

Mindset: Sustain the human judgement needed to recognise when a plausible model is subtly wrong.

Why: A craftsman develops judgement by working the material, not simply by inspecting the finished object. An apprentice woodworker learns to build a sound mortise-and-tenon joint by measuring, cutting, fitting, correcting mistakes and understanding why one joint holds while another fails. Data modelling develops in much the same way. Manually working through entities, relationships, subtypes, cardinalities and exceptions develops the modeller’s ability to recognise when something is subtly wrong. If AI performs all that reasoning, it may produce the model faster while gradually removing the practice through which human modelling judgement develops.

What: Retain deliberate modelling practice, challenge and reflection alongside AI-assisted discovery and regeneration.

Where: Within modelling teams, stewardship arrangements, Gemba preparation and capability development.

When: Periodically throughout the modelling cycle, particularly for developing practitioners.

Who: Practitioners, experienced modellers, mentors, capability stewards and accountable owners.

How: Have practitioners periodically form and defend an interpretation before seeing the AI proposal, compare both against Gemba evidence, and discuss why an apparently coherent alternative succeeds or fails.

3. Roles and decision rights

Mindset: A name in a field is not governance.

Why: Validation is only credible when the people involved understand the work, can test the model against reality and have the authority to act on what they find. Without knowledge, evidence, time and decision rights, validation becomes theatre: people may comment on the model, but nobody can establish what is true through testing against reality, resolve disagreement or accept responsibility for the consequences.

What: Assign accountability, stewardship, facilitation and escalation for the meaning and consequences being examined.

Where: Across the enterprise model, Common Data Model, each L3 Subject Area and each approval decision.

When: Before work is pulled into validation and whenever ownership, scope or meaning changes.

Who: The roles below, acting within their agreed decision rights.

How: Use lifecycle accountability to establish the decision boundary; preserve evidence and escalate decisions that cross it.

• Board or governing body — ultimate stewardship of purpose, ethics and legitimacy.
• Governance Owner — integrity and effectiveness of the governance system.
• L1 Capability Owner — accountable for the capability pledge, coherence, performance, maturity and consequences of the capability.
• L3 Capability Steward — operational stewardship of one L3 capability and the Home L3 for any Subject Areas rooted there.
• Data Owner — accountability for the meaning, use, integrity and protection of governed information.
• Data Steward — stewardship of Business Object and Entity Type definitions, relationships, rules, quality and issue resolution.
• Architecture Steward — repository coherence, reuse, standards, traceability, canonical identifiers and model lifecycle.
• Enterprise Value Chain Steward — coherence of enterprise value logic and the minimum-sufficient stream set.
• Principal Value Stream Owner — end-to-end accountability from trigger to terminal value state.
• Process Owner — integrity of coordinated work and its result.
• Facilitator — socialisation, Gemba workshop discipline and decision capture.
• Subject-matter participants — lived knowledge, demonstration, challenge and validation.

Each L1 capability has an accountable owner, and each L3 capability has a named steward. Each L3 Subject Area has one Home L3 Capability. The Subject Area may display peripheral Entity Types owned elsewhere, but their presence does not transfer lifecycle authority, CUD authority or stewardship. The facilitator preserves attributable dialogue. The Architecture Steward maintains canonical element identity and dependency coherence. Capability and Data Owners make decisions within their authority. Cross-boundary disputes regarding purpose, ethics and ownership follow the established escalation route. Silence, workbook circulation, AI confidence, repository import or resolved comments do not imply acceptance.

4. Preparing and conducting L3 Gemba validation

Mindset: Ask: ‘Show me how, and why, this works.’

Why: Abstract endorsement cannot expose the transactions, exceptions and decision rights that determine whether a relationship is true.

What: Prepare a focused root-centred semantic package and test it with actual cases and the people who perform, govern or experience the work.

Where: Within the L3 Subject Area and at its material interfaces.

When: When work is pulled into validation and whenever affected meaning requires revalidation.

Who: The facilitator, relevant practitioners, Home L3 Capability Steward, Data Stewards, modeller and accountable owners.

How: Use the Subject Area structure, package and evidence discipline below.

4.1 Subject Area structure

An L3 Subject Area is a root-centred view of the Common Data Model. It is not a duplicate mini-model, and it is not a package of every entity reachable from the root.

• Home L3 Capability — exactly one. It is the lifecycle governance home of the Root Entity Type.
• Root Entity Type — exactly one. It provides the semantic centre and entry point for the Subject Area.
• Core/Dependent Entity Types — included where their identity, composition, lifecycle or meaning is materially bound to the root for validation purposes.
• Peripheral Entity Types — canonical Entity Types governed elsewhere and included only because a material relationship to the root/core must be understood or tested.
• Neighbouring Subject Areas — referenced where a boundary or interface matters; their internal detail remains outside the current Subject Area unless required by the validation question.

Peripheral visibility is determined by semantic necessity, not by relationship reachability. In the L3 capability Product Order Management, ORDER is the Root Entity Type for the Product Order Subject Area. The Subject Area is organised around the Order lifecycle and includes only those other Entity Types needed to understand and validate the capability. 4.2 The validation package

• Subject Area ID, name, purpose, scope and exclusions.
• Home L3 Capability ID and steward.
• Root Entity Type ID and definition.
• Entity Type role within the Subject Area: Root, Core/Dependent or Peripheral.
• Focused diagram showing only the relationships required for understanding and validation.
• Relevant subtype hierarchy, inverse relationship readings, cardinality, optionality, lifecycle dependency and business rules.
• Activities, process fragments and decision points that create, use or change the root/core structure.
• Relevant KPIs, stakeholder roles, risks, controls and material exceptions.
• Interfaces with neighbouring Subject Areas and the canonical ownership of peripheral entities.
• Concrete normal cases and exceptions to test.
• Current evidence, provenance, unresolved questions, validation state, previous decisions and changes since the last tested iteration.

Preserve the canonical IDs of every referenced repository element. A Subject Area view must reuse those canonical elements; it must not clone an Entity Type simply to obtain a convenient diagram.

4.3 Evidence and dialogue

Apply the HAK Guideline socialisation practice wherever the workbook is used: discuss one worksheet or mind-sized proposition set at a time, attach dialogue to stable proposition IDs, and preserve contributor, date, reply and context. Retain the proposition as it stood when the feedback was given.

Distinguish observed or elicited Gemba evidence from research, inference, pattern proposal, assumption and simulated perspective.

A named contribution establishes provenance, not truth. Preserve competing accounts until the evidence and an accountable decision justify a disposition. AI may read the proposition and its dialogue, propose a synthesis, identify contradictions and trace consequences. People test the proposed meaning and determine its disposition. Resolving a comment or circulating a workbook does not constitute validation or approval.

5. Validation states and accountable promotion

Mindset: Generated does not mean true. Coherent does not mean validated.

Why: A “Validated” label can create false confidence unless people can see exactly what was tested, what remains uncertain and which version of the model the validation applies to.

What: Record Subject Area validation state separately from proposition knowledge status and approval.

Where: In the Subject Area register, the list of Subject Areas awaiting validation, evidence records and Sparx repository metadata.

When: At each validation transition and whenever a change in meaning affects a previous finding.

Who: Architecture Steward records coherence; the Gemba community supplies evidence; responsible humans determine validation; accountable owners approve use.

How: Apply the states below and retain evidence, scope and reasons for every transition.

• Generated — produced for the current HAK iteration.
• Candidate — internally coherent and plausible, but not yet Gemba validated.
• Validation Required — material enough to enter the L3 validation queue.
• In Validation — currently being tested with the relevant Gemba community.
• Validated — supported by Gemba evidence for the recorded scope.
• Qualified — generally supported but subject to explicit conditions, limits or exceptions.
• Contested — evidence or stakeholder interpretations conflict.
• Superseded — replaced by a later proposition or iteration, with history retained.

The Subject Area state describes the progress of the validation package; it does not automatically change the status of every contained proposition. A single Subject Area can contain Approved, Validated, Proposed, Qualified and Contested propositions simultaneously. Promotion to the Approved Baseline is a separate, accountable human decision under HAK V1.4 §37. Qualified knowledge may be approved only within its stated limits. Unresolved contested meaning must not be promoted as authoritative.

6. Kanban Architecture and human validation capacity

Mindset: Kanban Architecture limits human validation Work In Progress(WIP), not AI generation.

Why: Human attention, Gemba access and decision capacity constrain meaningful validation even when whole-model generation is fast.

What: Maintain a backlog of L3 Subject Areas and explicit WIP limits aligned with human capacity.

Where: Across the validation queue and participating Gemba communities.

When: Before starting validation, when work becomes blocked, and after each material impact review.

Who: Governance Owner, Architecture Steward, accountable owners, facilitators and relevant practitioners.

How: Pull validation work according to need and consequence, make delays and unresolved issues visible, and update priorities as validation reveals new work. Generate the enterprise architecture and Common Data Model holistically. Use L3 Subject Areas as the principal detailed semantic validation backlog.

Pull work based on organisational need, consequence, known ambiguity, change pressure, and available Gemba capacity. Each Kanban item identifies the Subject Area, Home L3 Capability, Root Entity Type, iteration and scope, priority rationale, steward, participants, required evidence, dependencies, current state, anything preventing progress, and required decision.

Return validated findings and human dispositions to the governed Knowledge Base and Sparx repository. Regenerate candidate structures, compare them with the previous candidate and Approved Baseline, then create or reprioritise affected validation work. Do not create more validation WIP simply because AI can generate more content.

7. Sparx repository and regeneration governance

Mindset: Renew the model without losing organisational memory.

Why: Regeneration must not erase the evidence, decisions and validated meaning on which people rely.

What: Use Sparx as the persistent canonical repository for structured enterprise architecture and Common Data Model knowledge, with controlled candidate, validation/evidence, and approved states.

Where: Across the Sparx repository, HAK workbooks and linked evidence stores.

When: During generation, import, comparison, validation, reporting and baseline promotion.

Who: Architecture Stewards and tool specialists implement controls; owners and stewards retain semantic decision authority.

How: Maintain canonical elements once, generate views from them, separate candidate and approved states, preserve evidence and stable identifiers, and control regeneration via explicit manifests and impact comparison.

7.1 Sparx as the persistent structural repository

The HAK Knowledge Base is the organisation’s comprehensive knowledge system. Within it, Sparx Enterprise Architect serves as the persistent structural repository for the governed enterprise architecture and the Common Data Model. Workbooks, Gemba dialogue, research and other evidence stores provide human-facing evidence and socialisation; Sparx holds the canonical structured elements and relationships that integrate that knowledge.

A diagram is therefore a view of repository knowledge, not the model itself. A Business Object, Entity Type, capability or relationship is created once as a canonical repository element and may appear in many diagrams, Subject Areas and stakeholder views.

The Business Object View provides the mind-sized enterprise semantic map. Detailed Entity Types, subtype structures and relationships underpin the logical CDM.

L3 Subject Area diagrams reuse these canonical Entity Types and show their role in that Subject Area as Root, Core/Dependent or Peripheral.

Capture amendments that change governed meaning as evidence and decisions, and reconcile them with the canonical repository structures. Regeneration must not silently discard manual learning or create competing copies of the same enterprise concept.

7.2 Repository governance layers

Preserve three logical governance layers. They may be implemented as packages, controlled branches, status-managed elements, linked stores or another architecture proven in the Sparx trial, but their semantics must remain distinct:

• Candidate Structure — the complete current AI-assisted architectural hypothesis, including unvalidated Business Objects, Entity Types, relationships and other elements. Safe to regenerate only within the declared controlled scope.
• Validation & Evidence — persistent Gemba evidence, dialogue references, human decisions, qualifications, contested interpretations, validation history and revalidation triggers linked to stable semantic IDs and proposition versions.
• Approved Baseline — the last explicitly accepted state of organisational knowledge. Updated only through an accountable human approval decision and retained for comparison and recovery.

The layers are governance states of one integrated repository environment, not three independent models. Candidate content may coexist visibly with approved content provided status is unambiguous.

7.3 Canonical elements, mappings and views

• Maintain one canonical repository element for each governed capability, Business Object, Entity Type and other reusable architectural element.
• Where a Business Object is elaborated by one or more Entity Types, maintain an explicit governed mapping. Do not duplicate the Business Object as separate departmental meanings.
• Represent subtype inheritance once in the canonical CDM and reuse it in Subject Area views.
• Represent each L3 Subject Area as a navigable view or package that references canonical Entity Types rather than cloning them.
• Record Subject Area role for each displayed Entity Type: Root, Core/Dependent or Peripheral.
• Keep ownership and lifecycle governance independent of view membership.
• Maintain stable semantic identifiers across regeneration when meaning is unchanged; issue successor mappings when a split, merge or material semantic replacement requires a new identity.

7.4 Persistent metadata and visible status

Store and retain, where relevant, the following information for each model element: semantic ID, HAK iteration, proposition version, source evidence references, Business Object mapping, Home L3 Capability, Subject Area membership and role, validation state and scope, validator and date, decision ID, qualifications, contested accounts, approval scope, review triggers, and predecessor/successor references. This information must remain linked to the element through regeneration and version changes. Keep Subject Area validation state, proposition knowledge status and approval as separate fields. Diagrams and generated reports must clearly show the relevant iteration and status. Colour may assist navigation but must not be the sole status indicator.

7.5 Regeneration and XMI

Generate or update repository structures from controlled element and connector manifests. XMI is an interchange format for transferring those structures; it is not a substitute for the governed semantic model. Before each material import or regeneration, preserve the Approved Baseline and the validation/evidence history. After import, reconcile element and connector counts, identifiers, mappings, Subject Area roles, subtype inheritance, status metadata and diagrams. Successful import proves only technical compatibility. It does not validate business meaning, confer approval, or justify carrying approval onto changed semantics.

8. Change impact and revalidation

Mindset: AI traces change across the whole model; humans decide what the consequences mean.

Why: A proposition may still need revalidation even when its wording has not changed. A changed Business Object, Entity Type, relationship or rule elsewhere in the repository may alter what that proposition means or whether it is still true. At enterprise scale, these dependencies are too numerous for people to trace reliably by hand.

What: Use AI to compare each new HAK iteration with the previous iteration and the Approved Baseline, trace the consequences of every material change, and identify the knowledge that may need review or revalidation.

Where: Across Business Objects, Entity Types, subtype structures, relationships, Activities, Processes, ownership, KPIs, stakeholder value and neighbouring Subject Areas.

When: At every material HAK iteration and whenever new evidence, exceptions, qualifications or changes to approved meaning are introduced.

Who: AI performs the systematic change and dependency analysis. Stewards and accountable owners review the findings, determine whether the identified impacts are material, and decide what must be revalidated.

How: AI compares new, changed, removed and unchanged elements and relationships using their stable identifiers. It traces dependencies in both directions through the repository, identifies previously validated or approved knowledge that may be affected, explains the dependency path that caused each alert, and proposes the scope and priority of revalidation.

Stewards review those proposals and decide what action is required. Compare new, changed, removed and unchanged elements and relationships at each material iteration. Record changes to meaning as well as structure. Trace consequences in both directions through Business Object mappings, Entity Type and subtype relationships, ownership and CRUD, Activities and Processes, KPIs, stakeholder value and neighbouring Subject Areas.

A change in a Peripheral Entity Type may affect a previously validated Subject Area even when its Root Entity Type has not changed. Likewise, a change to a Root Entity Type may affect relationships, rules and neighbouring Subject Areas that depend on its meaning. AI should identify these possible consequences systematically rather than relying on people to remember them. Preserve the previous validation decision against the version to which it applied. AI identifies the potentially affected scope; accountable humans decide whether revalidation is required. Unaffected knowledge retains its existing validation status. Only the affected scope returns to Validation Required.

9. Decision records and controlled release

Mindset: Approval is an accountable decision about specified meaning and use.

Why: Approval cannot be reconstructed or safely renewed without its evidence, scope, rationale and conditions.

What: Retain model decisions, regeneration changes and release records linked to exact repository elements and proposition versions.

Where: In the persistent Validation & Evidence layer and governed HAK release pack.

When: At material modelling decisions, proposed replacements, approval and release.

Who: Facilitators preserve dialogue; stewards check coherence; owners decide within authority.

How: Apply the HAK V1.4 semantic gates and preserve a recoverable prior baseline.

9.1 Model decision record

• issue or question
• repository elements and Subject Areas affected
• options considered
• perspectives represented
• evidence and provenance
• assumptions
• decision and rationale
• dissent, qualification or residual risk
• decision-maker and date
• review trigger

9.2 Regeneration change record

• input and output HAK/repository iteration
• stable semantic identifier and proposition version
• original meaning or structure
• source dialogue, evidence and research references
• proposed replacement
• affected Business Objects, Entity Types, relationships, Subject Areas and capabilities
• impact rationale
• unresolved tensions
• decision and disposition
• accountable decision-maker and date
• resulting knowledge and validation status
• revalidation work created
• review trigger

9.3 Release and Approved Baseline promotion

Release checks cover evidence capture, provenance, traceability, alignment with capability pledges, L3 convergence, Business Object and Entity Type integrity, ownership, relationship semantics, Subject Area boundaries, formula checks where applicable, visible unresolved matters, and a recoverable prior baseline.

Apply HAK V1.4 §37 to the exact scope proposed for approval. Record who approves which proposition versions, for which use, with what qualifications and review triggers. Do not promote unresolved contested meaning. Candidate structures may remain visible in the same repository as approved knowledge, but their status must be unmistakable. Approved for XMI Generation means the semantic scope has passed the required approval gates; successful XMI import remains only a technical test.

10. Worked example: Product Order and service pricing

This example is illustrative. It shows how the revised Subject Area and repository rules operate; it does not assert findings for any particular organisation.

10.1 Establish the Subject Area

Assume the Home L3 Capability is Product Order Management and the Root Entity Type is ORDER. The Product Order Subject Area is organised around ORDER because Product Order Management governs its lifecycle.

• Root Entity Type: ORDER.
• Core/Dependent Entity Type: ORDER LINE, because an Order Line exists within and is governed by the Order lifecycle.
• Peripheral Entity Type: CUSTOMER, because a Customer may place an Order but its lifecycle is governed elsewhere.
• Peripheral Entity Type: PRODUCT or SERVICE PRODUCT, because an Order Line references what is being ordered but Product meaning and lifecycle are governed elsewhere.
• Peripheral Entity Type: AGREEMENT, where contractual terms materially determine order pricing, but Agreement governance remains elsewhere.

The Subject Area shows the material relationships to CUSTOMER, PRODUCT and AGREEMENT. It does not expand the Customer, Product or Agreement internal models unless the validation question requires that additional detail.

10.2 Follow a real order and its pricing decision

Start with an Order containing an Order Line for a Service Product. Ask practitioners to show the actual order, the applicable product or service definition, agreement or rate source, the price decision and any subsequent variation.

• Is there one standard rate or several?
• Can a customer-specific Agreement override a standard Rate?
• Can Sales negotiate a lower rate, and under what authority?
• What date or event determines which rate applies?
• Does a discount create a new price decision or alter a standard rate?
• What happens when the service, quantity or duration changes after acceptance?
• How does the amount charged affect invoicing, margin and commission?

The point is not to enlarge the Subject Area indefinitely. If commission logic belongs to a Sales Remuneration Subject Area, show the interface and create follow-on validation work there rather than importing the entire remuneration model into Product Order.

10.3 Preserve disagreement and revise meaning

Suppose one practitioner describes a standard product rate, while another demonstrates a customer-specific negotiated rate. Preserve both accounts. The difference may reveal a missing AGREEMENT relationship, a subtype distinction, an exception, or a separate pricing decision Entity Type. AI may propose revised Entity Types and relationships. Practitioners test those proposals against normal and exceptional cases. Data and Capability Owners resolve meaning within their authority. Any cross-boundary dispute remains visible and follows the escalation route.

10.4 Trace consequences

A validated pricing finding may affect the ORDER or ORDER LINE model, Agreement relationships, price effective dates, discount authority, invoice evidence, commission calculation, controls, KPIs, and neighbouring Subject Areas. Record which dependencies are affected and why. If the meaning of Product changes, the Product Order Subject Area may require revalidation, even though PRODUCT is only peripheral there. Peripheral does not mean unimportant; it means owned elsewhere and included only to the depth required by the local semantic question.

10.5 Approve and regenerate without losing learning

Record the tested scope, evidence, validation disposition, and any qualifications. Promote only the approved proposition versions. Update the canonical Sparx repository structures, regenerate affected views, compare with the prior candidate and the Approved Baseline, and preserve the evidence and decision history. The useful output is not merely a better diagram. It is a traceable explanation of how Product Order pricing works, which parts are owned where, which exceptions matter, what changed in the repository, and what follow-on validation remains.

11. Modelling apprenticeship and capability regeneration

Mindset: AI must remove drudgery without removing apprenticeship.

Why: An organisation still needs people who can recognise when fluent, internally coherent modelling is subtly wrong.

What: Retain deliberate practice, reflection and explicit transfer of modelling judgement.

Where: In modelling teams, stewardship, Gemba preparation and capability development.

When: Periodically throughout discovery and validation, not only after failure.

Who: Practitioners, mentors, experienced modellers, owners and stewards.

How: Form and defend an interpretation before viewing the AI proposal, then compare it with the proposal, the repository structure and Gemba evidence.

Exhaustive manual modelling develops judgement as well as models. AI should remove repetitive discovery and maintenance work, but organisations should retain practice in defining identity, testing subtype meaning, reasoning about cardinality, recognising overloaded terms, and explaining why a plausible relationship fails.

Use real semantic questions: whether a relationship applies to every subtype, whether a duplicated concept is actually a role, whether a peripheral relationship needs deeper modelling, or whether an exception exposes a missing Entity Type. Review whether people can explain the reasoning independently as AI output becomes more sophisticated.

12. Source basis and revision traceability

Primary source for this redraft: HAK Supporting Note — L3 Validation, Regeneration and Sparx Governance V1.0, dated 8 September 2026. Companion guideline for this revision: Human-AI Knowledge Base Development Guideline V1.4. V1.1 retains the governance intent and operating disciplines of V1.0 while incorporating the terminology and repository decisions developed for the HAK V1.4 Sparx trial.

• CDM means Common Data Model throughout. No separate ASF artefact named Conceptual Data Model is introduced.
• Business Object replaces the earlier Principal Entity terminology for the high-level enterprise semantic anchor and is aligned with ArchiMate usage.
• Detailed logical structures are described as Entity Types and subtypes within the Common Data Model.
• The Business Object View is the mind-sized enterprise semantic map of the CDM.
• Each L3 Subject Area has exactly one Home L3 Capability and one Root Entity Type.
• Subject Area membership is classified as Root, Core/Dependent or Peripheral; peripheral inclusion does not transfer ownership.
• Sparx is treated as the persistent canonical structural repository for architecture and CDM knowledge, rather than merely as a regenerable projection.
• Diagrams and reports are views generated from canonical repository elements.
• XMI remains an interchange mechanism and technical control point, not a source of semantic truth.
• Regeneration preserves stable identity, validation evidence, human decisions and the Approved Baseline.

12.1 Cautionary Note

A significant implementation risk is capability erosion. In many organisations, enterprise architecture and data-modelling expertise has been outsourced over decades. As a result, the organisation may retain the ability to procure models without retaining enough internal capability to challenge, validate or maintain them. HAK must not become another mechanism for bypassing that lost capability. Its use requires deliberate regeneration of internal modelling judgement. HAK is not a plug-and-play AI product, a consulting shortcut or a silver bullet. It requires organisations to invest in the human capability and governance needed to challenge, validate and maintain the knowledge AI helps generate. The purpose of HAK training is therefore not merely to teach people how to use the method. It is to rebuild enough enterprise architecture and data-modelling capability inside the organisation for humans to govern AI-generated knowledge responsibly. It is is building the knowledge and learning environment that is crucial to Organisational Regeneration. Organisational Regeneration requires more than restoring lost skills. It requires rebuilding the conditions in which knowledge can be created, challenged, shared, tested at Gemba and continuously renewed. This goes beyond just HAK:

The central risk in AI adoption is not simply that AI may make mistakes. It is that organisations may use AI to bypass or further erode the human capability required to recognise, challenge and correct those mistakes.

Responsible AI implementation should therefore be treated as a capability-regeneration and organisational-learning problem, not merely as a technology deployment problem.

References

Malcolm, R. (2025). Adapt, Survive and Flourish. Green Hill Publishing.

Malcolm, R. (2026). Lead, Transform and Navigate. Green Hill.

ASF Website Detailed source dialogue, evidence registers and decisions for a modelling engagement are governed artefacts of that engagement and must be maintained separately from this methodological note, while remaining linked to the canonical repository elements they support.