L3 Validation, Regeneration and Sparx Governance

Version: 1.0

Status: Working supporting note

Date: 8 September 2026

Document owner: Rob Malcolm

Companion guideline: Human–AI Knowledge Base Development Guideline V1.3

Revision 1.0 consolidates the governing principles and detailed governance procedures extracted from the formatting-corrected HAK V1.2. It provides the detailed governance reference for HAK V1.3.

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 quickly generate a coherent enterprise model. Establishing whether its propositions reflect real work, who may rely on them and what must change when evidence contradicts them requires sustained human judgement. This note explains the work and the responsibilities that make it credible.

This is for practitioners, architects, owners, stewards, and colleagues who want to appreciate HAK’s depth. A relationship in a diagram may embody a pricing rule, an exception, an authority limit, a contractual dependency and a consequence for somebody else. Validation must expose these meanings, and governance must preserve the evidence and decisions through every regeneration.

This Subject Area is the maintained home of the detailed governing principles, validation workflow, decision records and Sparx repository governance. The companion HAK V1.3 guideline retains the modelling method, minimum governing contract, artefact requirements, semantic acceptance gates and technical XMI rules. Apply both documents together. A working-note version or a successfully generated model does not itself constitute organisational approval.

For a first reading, begin with this section, follow the worked Service Pricing case in Section 10, then examine the roles, validation states and repository controls in Sections 3–9. Section 2 provides the full governing principles in the established Mindset / Why / What / Where / When / Who / How format. Section 11 addresses the human capability needed to sustain the method.

Gemba is the actual place where work, service or consequence is experienced. L3 means Level 3 in the Business Capability Model (BCM); an L3 Subject Area provides the corresponding semantic scope for validation. The Common Data Model (CDM) describes shared business concepts and their relationships. Create, Read, Update and Delete (CRUD) identifies how work uses or changes authoritative data. Sparx Enterprise Architect is the modelling environment; XMI is the interchange format used to transfer the architectural projection.

1.1 The governing contract

• Purpose and ethics contain the work. Governance keeps decisions, evidence, authority and consequences answerable to them.
• Generated content remains candidate knowledge. Coherence, Gemba validation and accountable approval establish different things and must remain distinguishable.
• An L3 Subject Area is the mind-sized unit of semantic validation. Both capability context and entity relationships inform its boundary.
• AI generates holistically. Kanban limits human validation work in progress (WIP) according to need, consequence and available Gemba capacity.
• The governed HAK Knowledge Base is the semantic source. Sparx is its regenerable architectural projection; human evidence, decisions and approved knowledge survive regeneration.
• Material changes return affected knowledge to review. Stable identifiers preserve traceability; they do not automatically preserve the validity of changed meaning.

1.2 What the work demands

A meaningful validation session requires preparation, access to actual work and records, people who understand normal and exceptional cases, and someone with authority to resolve the resulting decisions. The facilitator preserves disagreement and named dialogue; the modeller traces consequences across related concepts; owners and stewards determine what is supported, what remains uncertain, and what may be used.

Progress is therefore visible in better-tested meaning, resolved or clearly bounded uncertainty, traceable decisions, and understood consequences. Counts of generated entities, polished diagrams or completed comment threads cannot establish those outcomes.

2. Governing principles

The original thirteen HAK principles remain the detailed foundation. Principles 2.14–2.18 express the relationship-discovery, L3 validation and regeneration disciplines introduced in V1.2 using the same format. These principles apply throughout the method; the later sections explain the operating procedures.

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 creating detailed specifications, schemas, interfaces, configurations or implementation artefacts.

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 obtain business agreement before specifying metadata or technology.

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 practices, workarounds, constraints and consequences that may not appear in official documentation.

Where: Across the organisation and throughout its external environment.

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

Who: Everyone.

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: Shared mental models begin with agreement on language, concepts and meaning. When different parts of the organisation use competing definitions or models, they may appear to agree while understanding the organisation differently. A common, consistent enterprise language provides a shared foundation for communication, decision-making and change.

What: Establish and maintain an authoritative enterprise model that contains common definitions, distinctions and relationships. The Single Version of the Truth is the best current shared representation of reality; it is neither an imposed official story nor a claim to permanent or infallible truth.

Where: Everywhere the organisation describes, discusses, decides upon or changes its capabilities, data, processes, services, policies, products, systems and relationships.

When: All the time—during everyday work, modelling, decision-making, change, implementation and review.

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

How: Establish truth in the reality of Gemba. Use consistent enterprise definitions, test them against observable work, evidence, lived experience, and consequences, resolve duplication and conflicting meanings through dialectical dialogue, reuse authoritative elements rather than creating project-specific alternatives, and revise the enterprise model whenever reality shows that its current representation is incomplete or incorrect.

2.4 Keep Organisational Views Distinct but Connected

Mindset: Maintain clarity and cohesion by treating capabilities, processes, activities, roles, systems and organisational units as distinct but connected views of the organisation.

Why: Conceptually distinct but explicitly connected organisational views create clarity and coherence. Mixing different kinds of artefacts produces ambiguity and unstable models whose structures and meanings change whenever implementation arrangements change. It also obscures the relationships through which work, information, authority, value, risk and consequence move.

What: Define every artefact according to what kind of thing it is and the meaning appropriate to that view. A capability describes what the organisation must be able to do, a process describes how workflows, an activity describes work performed, a role describes responsibility or participation, data describes things about which the organisation records facts, a system provides an enabling implementation, an organisational unit describes structural responsibility, and an outcome describes a resulting condition. Keep these meanings distinct, then connect the artefacts through explicit relationships.

Each capability is also a pledge that the organisation will establish, sustain and govern that ability sufficiently to fulfil its purpose and responsibilities. For an example of the capability pledge in practice, see Adapt, Survive and Flourish (Malcolm, 2025).

Where: Across all enterprise models and wherever their artefacts are referenced, compared, integrated or used to support decisions.

When: During the discovery, definition, decomposition, modelling, validation, integration, implementation and governance of every artefact.

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

How: Determine what kind of thing each proposed artefact is before modelling it. Define what it is and is not, apply the rules appropriate to that artefact type, test whether its children and relationships preserve its meaning, keep implementation choices separate from enduring business meaning, and connect distinct views through explicit, governed relationships.

2.5 Ownership Follows Lifecycle Accountability

Mindset: Ownership and stewardship are crucial for maintaining accountability and integrity throughout an element’s lifecycle.

Why: Without clearly assigned ownership and stewardship, people may create, interpret or change an element without appropriate authority or accountability. When nobody is accountable for decisions, and nobody is responsible for maintaining the element, its meaning, consistency, and integrity are at risk. Assigning responsibility based on system location, reporting convenience, or greatest usage creates further gaps and conflicts.

What: Assign an owner who is accountable for the element’s meaning, integrity, authorised use and lifecycle decisions. Assign stewards who maintain its quality, consistency and appropriate application within their delegated authority. As a minimum governance requirement, each L1 capability must have one accountable owner, and each L3 capability must have a named steward.

Where: Across capabilities, data, processes, services, policies, products, systems and all other governed enterprise artefacts.

When: Throughout the lifecycle of an element—from proposal and creation through use, sharing and change to retirement.

Who: A single accountable business owner for each L1 capability, supported by named L3 capability stewards, custodians, users and appropriate governance bodies. Establish equivalent ownership and stewardship arrangements for other governed enterprise artefacts.

How: Agree and define lifecycle stages and decision rights, assign one accountable owner to each L1 capability and a named steward to every L3 capability, specify the authority and responsibilities of each role, distinguish ownership and stewardship from custody and use, control who may create, approve and change governed elements, establish clear escalation from steward to owner, and resolve gaps, overlaps and competing claims explicitly.

2.6 Models Are Negotiated Knowledge

Mindset: Engage in dialectical thinking by analysing complexity and contradictions. Maintain opposing viewpoints in constructive tension, aiming for a synthesis that enhances collective understanding. Stay curious, respectful, and reflective, embrace patience with ambiguity, and remain open to revising your stance.

Why: Definitions and boundaries represent a range of experiences, interests, assumptions, and perspectives. Technical approval, authority, or majority consensus alone do not create shared understanding or legitimacy. Differences can uncover crucial insights about the organisation that no single perspective can fully explain.

What: Consider models as collective, testable representations whose meanings are continuously proposed, examined, compared, and refined. Negotiation isn’t about choosing the most dominant view or settling for a quick compromise. Instead, it involves creating a clearer, more consistent understanding by integrating evidence, lived experiences, and diverse perspectives.

Where: Wherever individuals or groups interpret the organisation in different ways or face varying outcomes from its functioning.

When: During discovery, modelling, validation, approval, and subsequent changes—especially when disagreements, contradictions, or ambiguities arise.

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

How: Make assumptions and competing interpretations clear, encourage challenge and dissent, explore what each perspective uncovers or conceals, keep contradictions open to understand them better, evaluate proposed syntheses with evidence, experience, and outcomes, and document both agreements and unresolved issues.

2.7 Trace Every Conclusion

Mindset: Treat every conclusion as provisional—the best current interpretation of reality, open to testing, challenge and revision as new evidence, experience and perspectives emerge.

Why: Every conclusion is a provisional interpretation based on the reality understood at that time. As circumstances, knowledge, and perspectives change, we may need to reconsider. Without evidence, provenance, context and visible reasoning, a conclusion cannot be reliably validated, challenged, reproduced or revised.

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

Where: Across all modelling activities, outputs, decisions and AI-generated material.

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

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

How: Record where information came from, distinguish observation from interpretation, identify AI-generated content, preserve relevant alternatives and dissent, link decisions to evidence, and keep unresolved questions visible until they are addressed.

2.8 Test Before Operational Use

Mindset: Do not use anything operationally until you have tested it in Gemba and shown it works under real-world conditions.

Why: A model, decision or solution may appear coherent and receive formal approval while still failing in practice. Documents, systems and governance forums cannot fully reproduce the constraints, workarounds, interactions and consequences experienced by people doing or affected by the work. Bruno’s experience in LTN demonstrates the human cost of implementing an apparently sound solution without adequately testing it against operational reality (Malcolm, 2026).

What: Treat every AI-generated or human-generated output as a proposal. Test it in Gemba with the people who will use it, depend upon it or experience its consequences. Validation establishes whether it reflects reality and works in practice; approval establishes whether an accountable person accepts responsibility for its use. Both are required before operational adoption.

Where: Wherever a model, definition, process, decision, system or other artefact will influence real work or produce real-world consequences.

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

Who: AI users, model developers, subject-matter experts, accountable owners and approvers.

How: Label candidate content clearly, identify assumptions and uncertainty, test it against evidence, Gemba and stakeholder perspectives, record changes made during validation, and require accountable human approval before authoritative use.

2.9 Grow Models Purposefully and Organically

Mindset: Enable models to develop through deliberate cycles of exploration, testing, learning, and refinement. Ensure each addition justifies its place, while staying receptive to insights that question the model’s assumptions, purpose, or scope.

Why: Models that gather excessive detail without clear purpose tend to become complex, hard to manage, and disconnected from decision-making. If their initial scope too tightly limits models, they might miss unexpected insights that could reveal key relationships, expose flawed assumptions, or suggest a need to reframe the initiative. Learning can either refine the model within its current scope or indicate that the scope needs adjustment.

What: Develop models gradually and iteratively, incorporating new elements only when they enhance decision-making, clarify meaning or ownership, reveal significant relationships or consequences, or aid implementation. Keep valuable insights that don’t fit the current model, and direct them to suitable areas for review. When an insight questions the fundamental assumptions or system boundaries, employ double-loop learning to re-evaluate the model’s purpose and scope.

Where: Across different model hierarchies, related enterprise viewpoints, initiative boundaries, and the broader system in which the organisation functions.

When: Throughout discovery, modelling, validation, decision-making, implementation and review, whenever new evidence, experience or perspectives emerge.

Who: Modelling teams, decision-makers, owners, stewards, people working in Gemba and affected stakeholders.

How: Start by defining the purpose, questions, and provisional system boundary. Then run repeated cycles of observation, externalisation, modelling, testing, and refinement. Please ensure each proposed element proves its relevance, and add detail only if it adds value. Record and direct useful insights outside the current scope, and check whether unexpected findings reveal faulty assumptions. Be deliberate in revising the purpose or boundary when double-loop learning indicates that change is necessary.

2.10 Test Consequence

Mindset: Prevention is always better than cure. Test decisions and actions in Gemba against reality to surface and address potential consequences before harm occurs.

Why: Apparently successful initiatives can shift costs, risks, or harm onto other people, places, systems, or future generations. These impacts, occurring outside the initiative’s scope or system boundary, might be overlooked until they become difficult, costly, or impossible to reverse. Those initially excluded from consideration may later face the harm and challenge the initiative legally, through regulation, or in protests.

What: Identify, assess, and respond to the intended, unintended, direct, indirect, cumulative, and delayed impacts on the Planet, People, and Prosperity. Consider both the benefits gained and the costs, risks, or harms that might be shifted elsewhere. Prevention doesn’t need absolute certainty; credible signs of serious consequences justify investigation and appropriate caution.

Where: Wherever consequences may arise—within and beyond organisational, project, geographic, jurisdictional and generational boundaries.

When: From the earliest framing of purpose and scope, through option development, decision-making, implementation and operation, and during subsequent review. Testing must occur early enough to prevent harm and continue as reality changes.

Who: Decision-makers, owners, stewards, people working in Gemba, affected and potentially affected stakeholders, risk specialists, subject-matter experts and governance bodies. Make a particular effort to include people who lack formal power but may experience the consequences.

How: Engage directly at Gemba to grasp current conditions and lived experiences. Trace the flow of value, information, authority, risk, failure, and harm. Research similar initiatives and identify stakeholders initially overlooked. Validate assumptions using scenarios, experiments, and alternative viewpoints. Consider different geographic and time perspectives. Develop preventive controls and early warning signs. Monitor actual outcomes versus expectations. When evidence shows harm is happening or likely, pause, revise, or change course.

2.11 Build on What Already Exists

Mindset: Little is new under the sun. Build on what is already there rather than reinventing it; much of what appears new is a reinterpretation, adaptation, recombination or development of what has gone before.

Why: Creating another capability, data entity, definition or model element when a suitable one already exists introduces redundancy, ambiguity and unnecessary rework. Multiple elements representing the same thing weaken the Single Version of the Truth and make enterprise knowledge harder to understand, govern and change.

What:  Treat the approved Business Capability Model and Common Data Model as stable enterprise foundations. Reuse their elements wherever they express the required business meaning. Where an existing element is ambiguous, incomplete or inconsistent with reality, question and resolve it rather than working around it by creating a duplicate.

Where: Across business capability, data, process, service, organisation and technology models, and wherever enterprise concepts are used.

When: Before introducing, naming or approving a new model element, and whenever apparently similar elements are discovered

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

How: Begin with existing internal models and relevant models from the same, parallel or apparently unrelated industries. Look beyond terminology to identify comparable purposes, constraints, relationships and operating patterns. Determine what can be reused directly, what can be adapted and what is genuinely different, compare definitions, boundaries, relationships and lifecycles, test transferred patterns against the organisation’s context and Gemba reality, resolve ambiguity with the relevant owner and steward, and create a new element only when existing models and adaptable precedents cannot adequately represent the required distinction.

External models provide precedent and insight; they do not automatically override the meaning established and tested within the organisation.

2.12 Generate XMI From a Governed Semantic Model

Mindset: Reuse proven, working interchange standards and formats wherever practical, while ensuring that technical exchange preserves validated business meaning.

Why: Successful XML or XMI import only proves that an artefact is structurally acceptable to a tool. It does not prove that the underlying business model is coherent, complete or correct.

What: Generate XMI and other exchange formats from governed semantic element and connector manifests. A complete candidate projection may support discovery and validation; only meaning that has been validated and explicitly approved may enter the Approved Baseline or be presented for authoritative use.

Where: At the boundary between business modelling and modelling-tool implementation, during candidate regeneration and whenever approved knowledge is transformed or imported into another environment.

When: During each material candidate regeneration and before importing or releasing an approved architectural projection.

Who: Business model owners, architects, tool specialists, implementers and approvers.

How: Generate XMI using controlled transformation under HAK V1.3 Part X. Check that identifiers, hierarchies, definitions, relationships and validation history are preserved. Label candidate projections explicitly, protect the Approved Baseline and treat successful import as a technical test, not business approval.

2.13 Consolidate Value-Flow Constructs Before Promotion

Mindset: Begin with the smallest sufficient value-flow model. Preserve material differences, but do not manufacture distinctions merely because different stakeholders, services, products or organisational arrangements are present.

Why: Creating an Enterprise Value Chain or Principal Value Stream for every stakeholder, service, product, channel, organisational unit, supplier class or regulatory regime produces duplication and obscures the enterprise’s underlying value logic. Many apparent differences are better represented as Stakeholder Value Views, Scenarios / Playbooks, configurations or variants of an existing Principal Value Stream.

What: Apply the Principal Value Stream Promotion and Consolidation Test before creating, approving, separating or combining Enterprise Value Chains and Principal Value Streams. Create an additional construct only when evidence shows materially different value logic, triggers, terminal value states, governance, outcomes, or consequences.

Where: During candidate value-structure development, value-flow modelling, stakeholder analysis, service and product modelling, model review, change control and approval.

When: Before promoting, separating or combining value-flow constructs, and whenever new evidence challenges their boundaries.

Who: Business model owners, architects, subject-matter experts, Stakeholder representatives, process owners, governance authorities, AI assistants and model approvers.

How: Begin with one Enterprise Value Chain for a coherent scoped business system and the minimum number of Principal Value Streams needed to represent Outcomes of prime importance. Test each proposed addition against existing constructs. Represent role-specific perspectives as Stakeholder Value Views and contextual differences as Scenarios / Playbooks wherever those constructs preserve the required meaning.

2.14 Discover relationships systematically and test subtype meaning

Mindset: AI achieves breadth. L3 Gemba achieves depth.

Why: A relationship omitted from a plausible model can hide an obligation, dependency or decision boundary. A parent-level relationship can also assert meaning that is false for a subtype.

What: Test each relevant entity pair in both directions, record provenance and uncertainty, challenge redundant or derivable relationships, and place each relationship at the highest level where its meaning is valid for every applicable instance.

Where: Across the Common Data Model, its subtype hierarchy and the interfaces between L3 Subject Areas.

When: After macro entity classification, before detailed relationship finalisation and whenever entity or subtype meaning changes.

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

How: Use the Relationship Discovery and Subtype Refinement Matrix in HAK §19.2. Preserve pair coverage and discovery dispositions, assign stable candidate relationship IDs and take the relevant cases and exceptions to L3 Gemba.

2.15 Validate through mind-sized L3 Subject Areas

Mindset: Give people a mind sized coherent piece of actual work that they can understand, challenge and demonstrate.

Why: Enterprise-scale output exceeds human attention. A capability hierarchy alone may conceal the semantic relationships through which work crosses boundaries.

What: Treat the L3 Subject Area as the unit of semantic validation, reconciling its logically related entities and rules with the operational capability boundary.

Where: At the convergence of entities, subtypes, Activities, Processes, KPIs, decision rights and stakeholder experience.

When: When preparing Gemba validation and whenever relationship discovery or operational evidence challenges a boundary.

Who: The relevant Gemba community, facilitator, L3 stewards, modellers and accountable owners.

How: Prepare the focused package in Section 4. Ask people to show concrete transactions and exceptions, record neighbouring interfaces and trace the consequences of changed meaning. Shared Subject Area membership does not transfer ownership or CUD authority.

2.16 Generate holistically and govern validation flow

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

Why: Whole-model generation supports coherence and impact discovery, while excessive human validation WIP encourages shallow review and apparent agreement.

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

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

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

Who: The Governance Owner and Architecture Steward agree WIP limits with owners, facilitators and the participating Gemba community.

How: Operate the Kanban in Section 6, retain blocked and contested work visibly, return findings to HAK 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 unless validation history and approved scope are protected.

What: Separate generated structures, persistent validation and evidence, and the Approved Baseline. Link decisions to stable IDs, exact proposition versions and explicit scope.

Where: In the governed HAK Knowledge Base, Sparx projections and their evidence and release records.

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

Who: The Architecture Steward and tool specialists protect traceability; owners approve meaning within their authority; facilitators and stewards preserve evidence and qualifications.

How: Apply Sections 7–9: compare candidate and approved versions, retain history, flag affected knowledge and require a separate human approval decision before promotion.

2.18 Remove drudgery without removing apprenticeship

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

Why: Manual modelling developed the modeller as well as the model. Automating the work can remove the practice through which semantic judgement is formed.

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, especially when new practitioners are learning the method.

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

How: Use the practice in Section 11: form and defend an interpretation before viewing the AI proposal, compare reasoning with evidence and discuss why an apparently coherent alternative fails.

3. Roles and decision rights

Mindset: A name in a field is not governance.

Why: Validation and approval need people with relevant knowledge, explicit authority and the capacity to act.

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

Where: Across the enterprise model and each L3 Subject Area.

When: Before pulling work into validation and whenever ownership or scope 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.
• Capability Owner: coherence, performance, maturity and consequences of a capability.
• Data Owner: accountability for the meaning, use, integrity and protection of governed information.
• Data Steward: operational stewardship of definitions, rules, quality and issue resolution.
• Architecture Steward: coherence, reuse, standards, traceability and model lifecycle.
• Enterprise Value Chain Steward: coherence of the enterprise value logic and the minimum-sufficient stream set.
• Principal Value Stream Owner: end-to-end trigger-to-terminal flow and material outcome; Process Owner: integrity of the coordinated work and its result.
• Facilitator: socialisation, workshop discipline and decision capture.
• Subject-matter participants: lived knowledge, testing and validation.

Ownership must include decision rights, time, competence, evidence access and escalation routes. A name in a field is not governance.

Each L1 capability has one accountable owner and each L3 capability has a named steward. Entity and Activity ownership remains singular as defined in HAK §§12 and 20. Being included in a Subject Area, using data or hosting a system does not create ownership. AI may propose and trace consequences; it does not assume ownership authority or approve a proposition.

The facilitator preserves attributable dialogue, the Architecture Steward checks dependency coherence and identifier continuity, Capability and Data Owners decide within their assigned authority. Refer cross-boundary or purpose and ethics disputes through the established escalation route. Do not infer acceptance from silence, workbook circulation, AI confidence or comment resolution.

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 semantic package and test it with actual cases and the people who perform or experience the work.

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

When: When work is pulled into validation, and again when affected meaning requires revalidation.

Who: The facilitator, relevant practitioners, modeller, owners and stewards.

How: Follow the package and evidence discipline below; Section 10 illustrates the complete cycle.

4.1 The validation package

An L3 Subject Area is a logically related group of entity types and their connected work, rules and evidence. Its semantic boundary is derived from relationships and reconciled with the operational L3 capability boundary. Use HAK §12.5 for its formal definition and canonical artefact links.

• Subject Area ID, name, purpose, scope and exclusions, linked L3 capability IDs, responsible steward and participating Gemba community.
• Relevant entities, subtypes and relationships, shown in a focused diagram and linked to the discovery-matrix rows, inverse readings, inheritance exceptions and redundancy dispositions.
• Activities, process fragments, decision points, cardinality, optionality, lifecycle rules, decision rights, controls and material exceptions.
• Relevant KPIs and measures, Stakeholders and roles, and interfaces or dependencies with neighbouring Subject Areas.
• Concrete cases and exceptions to test; AI-identified ambiguity, contradictions, high-consequence assumptions and unresolved questions.
• Current evidence and provenance, named source dialogue, validation state and tested scope, previous decisions and changes since the last validated iteration.

Preserve the canonical IDs and owning L3 capability of every referenced entity and Activity. Include only enough surrounding context for the case to make sense; one Subject Area package can draw on several worksheets without requiring review of the whole enterprise model.

4.2 Evidence and dialogue

Apply the workbook practice in HAK §1.8: socialise one worksheet at a time, attach threaded comments to the exact propositions, and retain contributor and recorder names, dates, replies and stable record anchors. Preserve the statement as it stood when the feedback was given. Verify that the reading method exposes full threads; retain a linked export where necessary and report any capture gap.

Distinguish observed or elicited Gemba evidence from research, inference, pattern proposals, assumptions and simulated perspectives. A named contribution establishes provenance, not truth. Retain competing accounts in their original wording, with appropriate access and attribution for sensitive material.

AI reads the proposition and its full dialogue, proposes a synthesis and traces consequences. Humans test the proposed meaning and determine its disposition. Resolving a thread or circulating a workbook does not establish validation or approval.

5. Validation states and accountable promotion

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

Why: The status of a package can conceal uncertainty unless its tested scope and proposition versions are explicit.

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

Where: In the Subject Area register, Kanban, evidence records and Sparx views.

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

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

How: Apply the states and transition rules below, retaining the reasons, evidence and exact scope.

Keep Subject Area validation state distinct from the proposition knowledge statuses in HAK §1.3 and from approval. A Subject Area state describes the scope and progress of its validation work; it does not automatically change every contained proposition. Preserve the iteration and proposition versions each finding applies to.

• Generated — produced from the current governed 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, with explicit conditions, limits or exceptions.
• Contested — evidence or stakeholder interpretations conflict.
• Superseded — replaced by a later HAK iteration, with history retained.

The Architecture Steward records Generated → Candidate after coherence checks, with unresolved questions visible. The relevant owners and steward identify material need and consequence to move Candidate → Validation Required. Please pull into In Validation only when a facilitator, relevant practitioners, and validation capacity are available.

Record Gemba evidence and the responsible human determination before moving In Validation to Validated, Qualified or Contested. Qualified findings retain their conditions and affected propositions. Contested findings retain competing accounts and follow the existing escalation route; neither AI confidence nor majority agreement resolves them. Revised or newly affected scope returns to Validation Required, then In Validation.

Promotion to the Approved Baseline is a separate accountable human decision under HAK §37 and Section 9 of this SN. Qualified knowledge may be approved only for its explicitly accepted limits and intended use. Do not promote unresolved contested meaning. Mark replaced versions as Superseded while retaining decisions and links to their successors.

Proposition knowledge statuses remain Proposed, Reviewed, Validated, Approved or Retired under HAK §1.3. A Subject Area may contain propositions at different statuses; do not use its validation state as a blanket approval label. Record the actual tested scope and show excluded, qualified and contested propositions.

6. Kanban Architecture and human validation capacity

Mindset: Kanban enables people to address the architecture in mind-sized chunks. It limits validation work in progress, not AI generation.

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

What: Maintain a backlog of L3 Subject Areas and explicit WIP limits that reflect available human capacity.

Where: Across the validation queue and participating Gemba communities.

When: Before starting validation, when work is blocked and after every material iteration impact review.

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

How: Pull by need and consequence, make blockers visible and replenish the backlog from validated learning and impact comparison.

Generate the enterprise architecture holistically. Use L3 Subject Areas as the validation backlog, and pull work based on organisational need, consequence, and available Gemba capacity. The Governance Owner and Architecture Steward agree and record explicit WIP limits with the participating owners and facilitators; size the limits to the actual human capacity rather than the rate of AI output.

Each validation work item identifies the Subject Area, iteration and scope, priority rationale, responsible steward, participants, evidence needed, dependencies, current state, blockers and decision required. Make blocked and contested work visible and review its capacity impact. Do not start more work to hide a blocked item or obtain superficial sign-off.

Return validated findings and human dispositions to the governed HAK Knowledge Base. Regenerate the complete candidate architecture, compare it with the previous iteration and Approved Baseline, and create or reprioritise affected L3 validation work. Kanban limits validation work in progress, not AI generation.

7. Sparx repository and regeneration governance

Mindset: Preserve the repository of organisational learning while renewing its architectural representation.

Why: Replacing generated structures must not erase the evidence and human decisions that establish what may be relied upon.

What: Maintain the governed HAK semantic source, a complete candidate Sparx projection and protected validation and approved layers.

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

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

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

How: Use the three logical layers, persistent metadata and presentation rules below. Apply HAK Part X for technical XMI generation and validation.

7.1 Source and candidate scope

The governed HAK Knowledge Base remains the semantic source. Sparx is the integrated architectural projection and navigation environment. Generate from versioned semantic element and connector manifests rather than directly from narrative material. Preserve the complete candidate architecture so cross-enterprise relationships and impacts remain discoverable.

Generate the complete candidate architecture for each material HAK iteration, including unvalidated structures with their actual status, provenance and unresolved questions. The controlled generation manifest authorises the transformation scope, not the truth of its contents. Label this delivery Candidate projection for validation. Only the explicitly approved semantic scope under HAK §37 may enter the Approved Baseline or be represented as authoritative knowledge.

Preserve three logical repository layers, whether implemented as separate packages, controlled views or linked stores:

• Generated Model — the complete AI-generated architectural hypothesis for the current HAK iteration; safe to regenerate within its controlled scope.
• Validation & Evidence Layer — persistent Gemba evidence, named human decisions, qualifications, contested interpretations and validation history linked to proposition IDs and versions.
• Approved Baseline — the last accepted state of organisational knowledge against which candidate change is assessed; updated only through explicit human approval.

Regeneration replaces controlled generated structures, not the Validation & Evidence Layer or Approved Baseline. Preserve stable semantic-to-XMI mappings, snapshots and human history before import. Route human amendments back through the governed HAK Knowledge Base so regeneration does not silently discard learning or make Sparx a competing semantic source.

7.2 Persistent metadata and visible status

Persist semantic ID, HAK iteration and proposition version, source evidence references, Subject Area memberships, validation state and scope, validator and date, decision ID, qualifications, contested accounts, approval scope and review triggers. Store history separately from replaceable generated content and link it by stable ID and version.

Define the chosen Sparx profile mappings for this metadata in HAK §41. Expose Subject Area validation state and proposition knowledge status as distinct labelled properties or tagged values, and show approval separately. Diagrams and generated reports must display the iteration and a status legend, retain visible qualifiers and identify mixed-status scope. Colour may assist navigation but must not be the only status indication.

Compare each regenerated projection with the previous candidate iteration and Approved Baseline. Deliver new, changed, removed and unchanged elements and relationships, affected validation decisions and revalidation flags under Section 8. An unchanged identifier does not justify carrying approval onto changed meaning.

Represent L3 Subject Areas as navigable views or packages referencing canonical elements. Do not clone entities merely to obtain separate diagrams. Keep ownership independent of view membership. Preserve semantic-to-XMI mappings and represent subtype inheritance and exceptions according to the agreed target profile. Technical serialisation, identifier and import checks remain in HAK §§41–46.

8. Change impact and revalidation

Mindset: A stable identifier preserves continuity, not the validity of changed meaning.

Why: A change elsewhere in the model can invalidate a proposition whose own wording has not changed.

What: Compare iterations and approved scope, trace dependencies and record the decision on revalidation.

Where: Across entities, subtypes, relationships, work, measures, ownership and neighbouring Subject Areas.

When: At every material HAK iteration and when evidence, exceptions or qualifications change.

Who: AI assists impact discovery; stewards and owners determine materiality, affected scope and revalidation needs.

How: Use the comparison, triggers and history rules below and create or reprioritise Kanban work.

Compare new, changed, removed and unchanged elements and relationships by stable identifier at each material iteration. Record changes to meaning as well as structure. Trace consequences in both directions through entity and subtype relationships, ownership and CRUD, Activities and Processes, KPIs, stakeholder value and neighbouring Subject Areas.

Flag previously validated or approved knowledge where a changed definition, subtype population, relationship, cardinality, lifecycle, business rule, decision right, interface or source evidence may invalidate the recorded finding. New exceptions, contradictory Gemba evidence and expired qualifications also trigger review. The responsible owner or steward records whether revalidation is required, its scope, and the rationale; the absence of a textual change does not establish that dependencies remain valid.

Link affected SA-L3-nnn and proposition IDs to the change record, evidence, previous decision and validation work item. Preserve the old validation decision against its original version and return affected scope to Validation Required. Carry forward validation only where unchanged meaning and unaffected dependencies are demonstrated.

9. Decision records and controlled release

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

Why: Approval cannot be reconstructed or safely renewed without the evidence, scope, rationale and conditions that supported it.

What: Retain model decisions, regeneration changes and release records linked to exact 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, and owners decide within their authority.

How: Use the records below, apply the HAK §37 semantic gates and preserve a recoverable previous baseline.

9.1 Model decision record

Record material modelling decisions with:

• issue or question,
• options considered,
• perspectives represented,
• evidence and provenance,
• assumptions,
• decision and rationale,
• dissent or residual risk,
• approver and date, and
• trigger for review.

9.2 Regeneration change record

Extend the model decision record for every material regenerated change with:

• input and output version,
• stable proposition identifier,
• original statement,
• source comment or reply identifiers and research references,
• proposed replacement,
• evidence category,
• affected downstream identifiers and rationale,
• unresolved tensions,
• decision and disposition,
• accountable decision-maker and date,
• resulting knowledge status,
• and review trigger.

Also identify the affected L3 Subject Areas, proposition versions, validation scope and state, qualifications, contested findings and revalidation work. Link the human decision to its source evidence; do not overwrite its original context when a successor proposition is generated.

9.3 Release and Approved Baseline promotion

Release checks must cover the completeness of comment and reply capture, provenance and anchor retention, before-and-after traceability, pledge alignment, L3 convergence, entity and Activity ownership, relationship integrity, formula checks where applicable, and the visibility of unresolved matters. Preserve the prior baseline so you can reconstruct or reverse a change.

The HAK §37 gates cover scope and stakeholder meaning; BCM integrity; L3 convergence and ownership; CDM integrity and relationship evidence; value and consequence; and governance. The modelling checks remain in the guideline. Apply them to the exact scope proposed for approval, including the dependencies needed for its intended use.

Record who approves which proposition versions, for which use, with what evidence, qualifications and review triggers. Qualified knowledge may be approved only within its explicitly accepted conditions. Do not promote unresolved contested meaning. Please leave all unapproved content visible to the candidate, even when it appears in the same holistic projection.

Distinguish Candidate projection for validation from Approved for XMI Generation. A successful technical import doesn’t validate business meaning or authorise operational use. Reconcile generated counts and identifiers, protect human history and confirm that the promoted scope matches the approval decision.

A release record identifies the HAK and companion SN versions used, input and output iterations, approved scope, candidate remainder, retained evidence, unresolved matters, impact comparison, revalidation decisions, responsible approver and recovery baseline. Where an essential owner, evidence item or decision remains pending, defer the affected approval.

10. Worked example from service pricing to governed knowledge

The following case is illustrative. It develops the Service Product / Order Line probe in HAK V1.2 to show the work required; it does not report findings or approvals from a particular organisation. Each proposed relationship and possible finding remains a hypothesis until you test it.

10.1 Prepare a proposition that people can challenge

Begin with an Order Line specifying a Service Product. The discovery pass may propose that SERVICE PRODUCT is priced by RATE. Test the inverse reading, the applicable subtype population and whether the proposed rate belongs instead to a Rate Card, Customer Agreement, Contract or the particular Order Line. Assign stable candidate IDs and preserve the question and its provenance.

A Service Pricing Subject Area provides the focused context. Commission Arrangement may belong more strongly to Sales Remuneration while depending on the rate actually charged. Show that interface and the relevant stewardship responsibilities; don’t force both into a single capability just to make the diagram look tidy.

10.2 Follow a real transaction and its exceptions

For an Order Line specifying a Service Product, ask how the price is established is it: a standard rate, Rate Card, Customer Agreement, Contract or the particular Order Line? Test who may negotiate a lower rate, under which authority and limits, and whether a discount creates a new price instance or changes an existing standard.

Follow changes in quantity, duration, customer class, urgency and service conditions, including variation after acceptance. Trace the rate actually charged to commission: is it based on list price, invoice value, margin, collected revenue or another measure? Ask who determines that rule, when it applies and what exceptions or workarounds occur.

In a real session, ask practitioners to show the order, applicable agreement, rate decision and subsequent variation. Follow who acted, which information they used, what they were permitted to change and what happened when the normal route did not fit. Ask where an informal workaround substitutes for the documented rule.

10.3 Preserve disagreement and revise meaning

Suppose one account describes a standard product rate while another shows customer-specific negotiated terms. Preserve both accounts and their record references. The discrepancy may reveal different lifecycle stages, a missing agreement relationship or an exception. Choosing the more senior account or asking AI to merge them into agreeable wording isn’t sufficient.

AI proposes a revised relationship set and identifies its consequences. Practitioners test the proposal with normal and exceptional cases. Data and Capability Owners resolve the meaning and authority within their remit; a pricing-to-commission dispute follows the cross-boundary escalation route. Record any remaining conflict as Contested, or supported limits as Qualified, against the exact scope.

10.4 Trace what else must change

A finding about negotiated rates may affect the price entity boundary, relationship cardinality, effective dates, discount authority, order variation, invoice evidence, commission calculation, Activity ownership, controls and KPIs. Examine each affected connection and the neighbouring Sales Remuneration Subject Area. Record why each item is affected, or why a suspected impact does not require change.

The resulting validation work must fit available Gemba capacity. A newly affected neighbouring Subject Area enters or is reprioritised in the backlog; it does not become validated because the Service Pricing session has finished.

10.5 Approve scope and regenerate without losing learning

For the tested Subject Area scope, record Validated or Qualified with evidence and the responsible human determination. Record the knowledge status and any qualifications of each proposition separately. An accountable owner then decides what may be approved for the intended use under the semantic gates. Retain rejected alternatives, unresolved questions and accepted conditions with that decision.

Return the findings to the governed HAK Knowledge Base, regenerate the complete candidate Sparx projection and compare it with the prior candidate and Approved Baseline. Preserve evidence and previous decisions. Flag any previously validated proposition whose assumptions or dependencies changed, even where its wording and identifier remained the same.

The useful output is a traceable package: a tested explanation of how pricing works, explicit authority and exceptions, justified model changes, an approval with clear limits, and visible follow-on validation work. The diagram makes that knowledge navigable; the evidence and decisions establish what to rely on.

11. Modelling apprenticeship and capability regeneration

Mindset: AI must remove drudgery without removing apprenticeship.

Why: An organisation needs people capable of challenging fluent, internally coherent but incorrect model proposals. Think of a woodworker learning to make mortise-and-tenon joints by hand at the bench on the journey to mastery. Apprenticeship is the journey every master has taken.

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

Where: In modelling teams, stewardship and capability development.

When: Periodically throughout discovery and validation, not only after a 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 and Gemba evidence.

AI must remove drudgery without removing apprenticeship. Exhaustive manual modelling developed judgement as well as models. Where modelling capability must be sustained, practitioners should periodically form and defend their own interpretations before seeing the AI proposal, then compare their reasoning with the proposal and Gemba evidence.

Include deliberate practice and reflection in capability development. Review whether faster model production is accompanied by erosion of the human ability to recognise subtle semantic error. Sophisticated output is not evidence that modelling judgement is being regenerated.

Use actual semantic questions such as whether a pricing relationship applies to every subtype, whether an apparent duplicate preserves a distinct lifecycle fact, or whether an exception exposes a different entity. Discuss the reasoning and evidence that distinguish the alternatives. Review whether the team can recognise and explain errors independently as AI output becomes more sophisticated.

12. Source basis and extraction traceability

Primary source: Human–AI Knowledge Base Development Guideline V1.2, dated 8 September 2026, using the formatting-corrected copy supplied through the shared workspace. The companion guideline is V1.3; this SN begins at V1.0.

The relationship-discovery and L3 governance material derives from HAK Working Note — Relationship Discovery, Subtypes and L3 Gemba Validation and HAK Update Working Note — L3 Subject Areas, Sparx Repository and Validation Governance, both dated 8 September 2026 and incorporated in HAK V1.2. Their Adelaide Bank precedent remains the working notes’ source basis.

The original thirteen governing principles and operational rules are extracted and consolidated here. The additional principle statements and illustrative cases explain how they apply. The issue of a document does not assert that the described governance arrangements have already been implemented or approved by a particular organisation.

12.1 Where the V1.2 material now lives

• HAK V1.2 §9, original thirteen Governing Principles → SN §2.1–2.13. HAK V1.3 §9 retains the minimum governing contract and reference.
• HAK V1.2 §28.1, Required roles → SN §3. HAK V1.3 §28 retains the governance interface.
• HAK V1.2 §§12.5 and 29.1, L3 package and Gemba probe → SN §§4 and 10 for operating practice; HAK retains the semantic definition and validation principle.
• HAK V1.2 §28.4, Validation states and promotion → SN §5 and approval detail in §9.
• HAK V1.2 §28.5, Kanban Architecture governance → SN §6.
• HAK V1.2 §§40.1–40.2, repository layers and validation metadata → SN §7; technical XMI generation remains in HAK Part X.
• HAK V1.2 §28.6, Change impact and revalidation → SN §8.
• HAK V1.2 §§28.2–28.3, decision and release records → SN §9. HAK §37 retains the semantic acceptance gates.
• HAK V1.2 §29.2, apprenticeship and capability regeneration → SN §§2.18 and 11; HAK retains the principle and reference.

12.2 References retained with the original principles

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

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

The references above support the examples already present in the extracted principles. The detailed source dialogue, evidence registers, and decisions for a modelling engagement are governance artifacts of that engagement and must be maintained separately from this methodological note.